随访系统最容易被低估的环节不是“发一条提醒”而是提醒之后没人接、反馈散落在多个入口、异常信息升级慢。本文从技术架构角度复盘一个 AI 辅助随访管理流程示例重点讨论任务编排、问卷回收、示例分层规则、异常上报和人工接管闭环。以下内容仅作为工程流程示例不提供诊断、治疗、分诊或用药建议真实项目中的阈值和规则应由医疗专业人员及机构规范确认。问题背景提醒发出后流程为什么还是断我做随访流程设计时最常见的断点有三个。第一提醒只记录了“已发送”没有记录患者是否打开、是否填写、是否需要补发。第二问卷、电话备注、人工处理结果分散在不同表或不同系统里后续很难追踪一次随访的完整链路。第三异常反馈进入系统后没有明确的升级策略导致运营人员靠人工筛选延迟不可控。所以随访自动化不应只建一个通知服务而要把它设计成状态机加事件流创建随访计划 - 生成随访任务 - 到期提醒 - 收集反馈 - 示例规则分层 - 正常归档 / 需要补问 / 异常上报 - 人工接管 - 处理完成并留痕这里的 AI 更适合放在“文本摘要、意图归类、异常线索辅助识别、坐席建议生成”等位置而不是替代专业判断。技术目标与边界本文示例采用 Python、FastAPI、PostgreSQL、消息队列和规则引擎。目标不是实现完整生产系统而是给出一条可落地的主链路。核心约束建议先写清楚所有随访动作都要可追踪包括提醒、回复、分层、升级和人工处理。示例风险分层只能作为流程触发条件不能写成医学结论。升级规则要可配置不能硬编码在业务接口里。AI 输出必须保存原始输入、模型版本、提示词版本和人工确认结果。人工接管节点必须有 SLA、责任人和处理状态。一个简化架构如下Follow-up PlanTask SchedulerMessage QueueReminder WorkerPatient Response APIRules EngineNormal ArchiveNeed More InfoEscalation CaseHuman ReviewClosed with Audit Log如果 CSDN 环境不渲染 Mermaid也可以把它当作流程文本阅读。数据模型先把链路留痕设计好随访表设计不需要一开始就复杂但至少要区分“计划”“任务”“反馈”“升级单”。CREATETABLEfollowup_task(id BIGSERIALPRIMARYKEY,patient_refVARCHAR(64)NOTNULL,plan_codeVARCHAR(64)NOTNULL,due_atTIMESTAMPNOTNULL,statusVARCHAR(32)NOTNULL,retry_countINTDEFAULT0,created_atTIMESTAMPDEFAULTnow(),updated_atTIMESTAMPDEFAULTnow());CREATETABLEfollowup_response(id BIGSERIALPRIMARYKEY,task_idBIGINTNOTNULL,channelVARCHAR(32)NOTNULL,payload JSONBNOTNULL,ai_summaryTEXT,rule_result JSONB,created_atTIMESTAMPDEFAULTnow());CREATETABLEescalation_case(id BIGSERIALPRIMARYKEY,task_idBIGINTNOTNULL,levelVARCHAR(32)NOTNULL,reasonTEXTNOTNULL,statusVARCHAR(32)NOTNULL,ownerVARCHAR(64),created_atTIMESTAMPDEFAULTnow(),closed_atTIMESTAMP);这里patient_ref建议使用业务侧脱敏标识不在随访服务里直接存储不必要的敏感信息。payload保存问卷原始结果rule_result保存规则命中的版本和原因便于审计和复盘。任务编排不要在接口里直接发送提醒生产环境里提醒发送最好走队列。接口负责创建任务调度器扫描到期任务worker 负责具体发送。这样可以处理重试、限流、失败补偿和渠道切换。fromdatetimeimportdatetimefromfastapiimportFastAPIfrompydanticimportBaseModelfromenumimportEnum appFastAPI()classTaskStatus(str,Enum):pendingpendingremindedremindedrespondedrespondedescalatedescalatedclosedclosedclassFollowupResponse(BaseModel):task_id:intchannel:stranswers:dictfree_text:str|NoneNonedefevaluate_rules(answers:dict,free_text:str|None)-dict: 示例规则仅用于工程流程演示。 真实项目中的阈值、关键词、升级级别必须由医疗专业人员和机构规范确认。 reasons[]levelnormalscoreint(answers.get(self_report_score,0))missed_contactbool(answers.get(missed_contact,False))ifscore8:levelreview_requiredreasons.append(self_report_score_reaches_configured_threshold)ifmissed_contact:levelreview_requiredreasons.append(missed_contact_needs_manual_followup)iffree_text:keywords[不适,加重,无法联系]ifany(kinfree_textforkinkeywords):levelreview_requiredreasons.append(free_text_contains_configured_keywords)return{level:level,reasons:reasons,rule_version:followup_rule_demo_v1}app.post(/followup/responses)defsubmit_response(resp:FollowupResponse):resultevaluate_rules(resp.answers,resp.free_text)ifresult[level]review_required:# 生产环境应写入 escalation_case并投递人工处理队列next_actioncreate_escalation_caseelse:next_actionarchive_responsereturn{task_id:resp.task_id,rule_result:result,next_action:next_action}这段代码没有把规则写成医学判断只表达“满足配置条件后进入人工复核”。在真实系统里evaluate_rules应改成独立规则服务规则来自后台配置并支持灰度发布和版本回滚。分层策略规则引擎比大模型更适合做主控随访分层通常会被问到能不能让大模型直接判断风险等级工程上不建议让大模型做唯一主控。更稳妥的方式是规则引擎负责可解释、可审计的流程分支AI 负责辅助处理非结构化信息。推荐拆成三层结构化规则问卷选项、未回复次数、超时天数、配置阈值。文本辅助对自由文本做摘要、关键词提示、情绪或意图标签。人工确认所有升级单由授权人员确认处理不让模型直接关闭异常。示例规则可以长这样{rule_code:FOLLOWUP_REVIEW_DEMO,version:v1,conditions:[{field:self_report_score,operator:,value:8},{field:missed_contact,operator:,value:true}],action:create_manual_review_case}注意这里的8只是演示配置值不代表任何通用医学标准。上线前应由机构按业务规范确认并配合权限控制、审计日志和变更审批。异常上报升级单要像工单一样管理异常上报不是发一条内部消息就结束。更合理的模型是“升级单”它至少包含来源任务、触发原因、级别、负责人、状态、处理记录和关闭原因。我一般会把升级单状态设计为created - assigned - processing - closed - transferred - timeout_escalated其中timeout_escalated很关键。随访系统的风险不只来自用户反馈也来自反馈后无人处理。可以通过定时任务扫描超过配置 SLA 的升级单再推送到更高一级工作队列。示例伪流程1. response 写入成功 2. rule_result 命中 review_required 3. 创建 escalation_case 4. 投递 manual_review.created 事件 5. 分配给人工队列 6. 人工填写处理结果 7. 关闭 escalation_case 8. 回写 followup_task 状态这样后续做报表时才能回答“多少提醒未回复”“多少反馈进入复核”“平均接管耗时是多少”“哪些规则产生了过多误报”。调试与踩坑随访系统最怕状态不一致第一个坑是重复提交。用户可能多次打开链接消息队列也可能重试所以响应接口要做幂等。可以用task_id response_round或业务流水号做唯一约束。第二个坑是规则版本不可追踪。规则变化后如果旧数据只保存了结果没有保存规则版本复盘时会说不清当时为什么升级。第三个坑是人工处理结果没有结构化。只保存一段备注后续无法统计。建议至少提供处理类型、处理状态、是否需要再次随访、关闭原因等字段。第四个坑是 AI 摘要覆盖原文。工程上应保留原始反馈AI 摘要只能作为辅助字段不能替代原始记录。性能与扩展建议早期可以用 PostgreSQL 加一个轻量消息队列完成主流程。任务量上来后再把提醒发送、AI 文本处理、升级单分配拆成独立 worker。接口层只做校验和落库耗时操作全部异步化。可观测性建议从第一天加上每个任务的 trace_id。提醒发送成功率和失败原因。问卷回收率和超时率。规则命中次数和人工关闭结果。升级单从创建到接管的耗时分布。这些指标比单纯统计“发送了多少条消息”更接近随访流程质量。总结AI 做医学随访管理重点不是把提醒自动发出去而是把反馈、分层、异常上报和人工接管串成可追踪闭环。规则引擎负责稳定分支AI 负责辅助整理非结构化信息人工节点负责确认和处置。如果要继续扩展可以从三个方向入手规则配置后台、升级单 SLA 监控、AI 摘要与人工确认的对照评估。随访自动化的价值最终体现在反馈被看见、异常被接住、处理过程可复盘而不只是提醒触达率。本文文献检索、文献挖掘以及文献翻译采用的是【超能文献| AI文献检索|AI文档翻译】。
AI做医学随访管理：从提醒、分层到异常上报，流程怎么设计
发布时间：2026/5/27 11:15:31
随访系统最容易被低估的环节不是“发一条提醒”而是提醒之后没人接、反馈散落在多个入口、异常信息升级慢。本文从技术架构角度复盘一个 AI 辅助随访管理流程示例重点讨论任务编排、问卷回收、示例分层规则、异常上报和人工接管闭环。以下内容仅作为工程流程示例不提供诊断、治疗、分诊或用药建议真实项目中的阈值和规则应由医疗专业人员及机构规范确认。问题背景提醒发出后流程为什么还是断我做随访流程设计时最常见的断点有三个。第一提醒只记录了“已发送”没有记录患者是否打开、是否填写、是否需要补发。第二问卷、电话备注、人工处理结果分散在不同表或不同系统里后续很难追踪一次随访的完整链路。第三异常反馈进入系统后没有明确的升级策略导致运营人员靠人工筛选延迟不可控。所以随访自动化不应只建一个通知服务而要把它设计成状态机加事件流创建随访计划 - 生成随访任务 - 到期提醒 - 收集反馈 - 示例规则分层 - 正常归档 / 需要补问 / 异常上报 - 人工接管 - 处理完成并留痕这里的 AI 更适合放在“文本摘要、意图归类、异常线索辅助识别、坐席建议生成”等位置而不是替代专业判断。技术目标与边界本文示例采用 Python、FastAPI、PostgreSQL、消息队列和规则引擎。目标不是实现完整生产系统而是给出一条可落地的主链路。核心约束建议先写清楚所有随访动作都要可追踪包括提醒、回复、分层、升级和人工处理。示例风险分层只能作为流程触发条件不能写成医学结论。升级规则要可配置不能硬编码在业务接口里。AI 输出必须保存原始输入、模型版本、提示词版本和人工确认结果。人工接管节点必须有 SLA、责任人和处理状态。一个简化架构如下Follow-up PlanTask SchedulerMessage QueueReminder WorkerPatient Response APIRules EngineNormal ArchiveNeed More InfoEscalation CaseHuman ReviewClosed with Audit Log如果 CSDN 环境不渲染 Mermaid也可以把它当作流程文本阅读。数据模型先把链路留痕设计好随访表设计不需要一开始就复杂但至少要区分“计划”“任务”“反馈”“升级单”。CREATETABLEfollowup_task(id BIGSERIALPRIMARYKEY,patient_refVARCHAR(64)NOTNULL,plan_codeVARCHAR(64)NOTNULL,due_atTIMESTAMPNOTNULL,statusVARCHAR(32)NOTNULL,retry_countINTDEFAULT0,created_atTIMESTAMPDEFAULTnow(),updated_atTIMESTAMPDEFAULTnow());CREATETABLEfollowup_response(id BIGSERIALPRIMARYKEY,task_idBIGINTNOTNULL,channelVARCHAR(32)NOTNULL,payload JSONBNOTNULL,ai_summaryTEXT,rule_result JSONB,created_atTIMESTAMPDEFAULTnow());CREATETABLEescalation_case(id BIGSERIALPRIMARYKEY,task_idBIGINTNOTNULL,levelVARCHAR(32)NOTNULL,reasonTEXTNOTNULL,statusVARCHAR(32)NOTNULL,ownerVARCHAR(64),created_atTIMESTAMPDEFAULTnow(),closed_atTIMESTAMP);这里patient_ref建议使用业务侧脱敏标识不在随访服务里直接存储不必要的敏感信息。payload保存问卷原始结果rule_result保存规则命中的版本和原因便于审计和复盘。任务编排不要在接口里直接发送提醒生产环境里提醒发送最好走队列。接口负责创建任务调度器扫描到期任务worker 负责具体发送。这样可以处理重试、限流、失败补偿和渠道切换。fromdatetimeimportdatetimefromfastapiimportFastAPIfrompydanticimportBaseModelfromenumimportEnum appFastAPI()classTaskStatus(str,Enum):pendingpendingremindedremindedrespondedrespondedescalatedescalatedclosedclosedclassFollowupResponse(BaseModel):task_id:intchannel:stranswers:dictfree_text:str|NoneNonedefevaluate_rules(answers:dict,free_text:str|None)-dict: 示例规则仅用于工程流程演示。 真实项目中的阈值、关键词、升级级别必须由医疗专业人员和机构规范确认。 reasons[]levelnormalscoreint(answers.get(self_report_score,0))missed_contactbool(answers.get(missed_contact,False))ifscore8:levelreview_requiredreasons.append(self_report_score_reaches_configured_threshold)ifmissed_contact:levelreview_requiredreasons.append(missed_contact_needs_manual_followup)iffree_text:keywords[不适,加重,无法联系]ifany(kinfree_textforkinkeywords):levelreview_requiredreasons.append(free_text_contains_configured_keywords)return{level:level,reasons:reasons,rule_version:followup_rule_demo_v1}app.post(/followup/responses)defsubmit_response(resp:FollowupResponse):resultevaluate_rules(resp.answers,resp.free_text)ifresult[level]review_required:# 生产环境应写入 escalation_case并投递人工处理队列next_actioncreate_escalation_caseelse:next_actionarchive_responsereturn{task_id:resp.task_id,rule_result:result,next_action:next_action}这段代码没有把规则写成医学判断只表达“满足配置条件后进入人工复核”。在真实系统里evaluate_rules应改成独立规则服务规则来自后台配置并支持灰度发布和版本回滚。分层策略规则引擎比大模型更适合做主控随访分层通常会被问到能不能让大模型直接判断风险等级工程上不建议让大模型做唯一主控。更稳妥的方式是规则引擎负责可解释、可审计的流程分支AI 负责辅助处理非结构化信息。推荐拆成三层结构化规则问卷选项、未回复次数、超时天数、配置阈值。文本辅助对自由文本做摘要、关键词提示、情绪或意图标签。人工确认所有升级单由授权人员确认处理不让模型直接关闭异常。示例规则可以长这样{rule_code:FOLLOWUP_REVIEW_DEMO,version:v1,conditions:[{field:self_report_score,operator:,value:8},{field:missed_contact,operator:,value:true}],action:create_manual_review_case}注意这里的8只是演示配置值不代表任何通用医学标准。上线前应由机构按业务规范确认并配合权限控制、审计日志和变更审批。异常上报升级单要像工单一样管理异常上报不是发一条内部消息就结束。更合理的模型是“升级单”它至少包含来源任务、触发原因、级别、负责人、状态、处理记录和关闭原因。我一般会把升级单状态设计为created - assigned - processing - closed - transferred - timeout_escalated其中timeout_escalated很关键。随访系统的风险不只来自用户反馈也来自反馈后无人处理。可以通过定时任务扫描超过配置 SLA 的升级单再推送到更高一级工作队列。示例伪流程1. response 写入成功 2. rule_result 命中 review_required 3. 创建 escalation_case 4. 投递 manual_review.created 事件 5. 分配给人工队列 6. 人工填写处理结果 7. 关闭 escalation_case 8. 回写 followup_task 状态这样后续做报表时才能回答“多少提醒未回复”“多少反馈进入复核”“平均接管耗时是多少”“哪些规则产生了过多误报”。调试与踩坑随访系统最怕状态不一致第一个坑是重复提交。用户可能多次打开链接消息队列也可能重试所以响应接口要做幂等。可以用task_id response_round或业务流水号做唯一约束。第二个坑是规则版本不可追踪。规则变化后如果旧数据只保存了结果没有保存规则版本复盘时会说不清当时为什么升级。第三个坑是人工处理结果没有结构化。只保存一段备注后续无法统计。建议至少提供处理类型、处理状态、是否需要再次随访、关闭原因等字段。第四个坑是 AI 摘要覆盖原文。工程上应保留原始反馈AI 摘要只能作为辅助字段不能替代原始记录。性能与扩展建议早期可以用 PostgreSQL 加一个轻量消息队列完成主流程。任务量上来后再把提醒发送、AI 文本处理、升级单分配拆成独立 worker。接口层只做校验和落库耗时操作全部异步化。可观测性建议从第一天加上每个任务的 trace_id。提醒发送成功率和失败原因。问卷回收率和超时率。规则命中次数和人工关闭结果。升级单从创建到接管的耗时分布。这些指标比单纯统计“发送了多少条消息”更接近随访流程质量。总结AI 做医学随访管理重点不是把提醒自动发出去而是把反馈、分层、异常上报和人工接管串成可追踪闭环。规则引擎负责稳定分支AI 负责辅助整理非结构化信息人工节点负责确认和处置。如果要继续扩展可以从三个方向入手规则配置后台、升级单 SLA 监控、AI 摘要与人工确认的对照评估。随访自动化的价值最终体现在反馈被看见、异常被接住、处理过程可复盘而不只是提醒触达率。本文文献检索、文献挖掘以及文献翻译采用的是【超能文献| AI文献检索|AI文档翻译】。
