AI做医学随访管理从提醒、分层到异常上报流程怎么设计在随访系统里最容易被低估的不是“怎么发提醒”而是提醒之后没人接、反馈散落在不同渠道、异常信息升级慢。本文从技术架构角度复盘一个医学随访自动化流程示例重点放在任务编排、问卷回收、示例风险分层和人工接管闭环。本文不提供诊断、治疗、分诊或用药建议所有阈值和升级规则均为工程示例真实项目必须由医疗专业人员和机构规范确认。问题背景随访不是通知系统做随访管理时开发团队通常会先实现短信、App Push、企微消息或电话外呼接口。但上线后常见问题会集中在三个地方提醒发出去了但患者是否填写、是否读懂、是否需要再次触达不可追踪。问卷结果回来了但异常项混在普通反馈里人工处理靠导出表格。不同随访计划的周期、表单、升级规则不同代码里写死后很难维护。因此随访自动化更适合按“工作流”建模而不是按“消息发送”建模。一个可维护的流程至少要覆盖计划生成、触达提醒、反馈采集、规则分层、异常上报、人工接管、审计留痕。技术目标与边界本文示例面向医疗健康技术开发者和技术架构师使用的技术栈如下FastAPI提供随访任务、问卷提交、异常事件接口。PostgreSQL保存随访计划、任务、问卷结果和处理记录。Message Queue解耦定时提醒、重试、规则计算和通知。Rules Engine将分层和升级规则从业务代码中拆出来。AI Component用于文本摘要、随访问卷结构化辅助和优先级提示但不直接给出医疗结论。边界要提前写清楚AI 只参与流程辅助例如把自由文本反馈转成结构化字段、提示运营人员关注点、生成客服沟通摘要。任何风险等级、异常升级、人工处理动作都应该遵循机构确认的规则并保留可审计记录。总体流程设计可以把随访自动化拆成 7 个节点随访计划创建 - 生成随访任务 - 到期提醒 - 问卷/反馈回收 - 规则引擎分层 - 异常事件上报 - 人工接管与闭环记录这里建议把“任务”和“事件”分开设计。任务表示某个对象在某个时间点需要完成一次随访事件表示过程中发生的状态变化例如已提醒、已提交、超时、触发异常、人工关闭。一个简化的数据模型可以这样设计followup_plan: 随访计划模板 followup_task: 具体随访任务 questionnaire_response: 问卷或反馈结果 risk_event: 示例风险事件 manual_action: 人工处理记录状态机也要尽量清晰PENDING - REMINDED - SUBMITTED - CLASSIFIED - ESCALATED - TIMEOUT - CLOSED不要把所有逻辑塞进一个status字段。实际落地时可以用状态字段表达当前节点用事件表保存完整轨迹方便排查“为什么这个任务没有升级”。核心实现任务生成与提醒入队随访任务一般来自计划模板例如“第 3 天、第 7 天、第 30 天各一次”。计划创建后系统生成具体任务到期任务由定时器扫描并投递到消息队列。下面是一个简化的 FastAPI 示例演示任务提交后如何进入分层流程。代码只展示核心结构真实项目需要补充认证、脱敏、权限控制和幂等处理。fromenumimportEnumfromtypingimportOptional,Dict,AnyfromfastapiimportFastAPIfrompydanticimportBaseModel appFastAPI()classTaskStatus(str,Enum):PENDINGPENDINGREMINDEDREMINDEDSUBMITTEDSUBMITTEDCLASSIFIEDCLASSIFIEDESCALATEDESCALATEDCLOSEDCLOSEDclassQuestionnaireSubmit(BaseModel):task_id:strpatient_id:stranswers:Dict[str,Any]free_text:Optional[str]Nonedefsave_response(payload:QuestionnaireSubmit)-None:print(fsave response task{payload.task_id})defpublish_event(topic:str,data:dict)-None:print(fpublish{topic}:{data})app.post(/followup/questionnaire/submit)defsubmit_questionnaire(payload:QuestionnaireSubmit):save_response(payload)publish_event(followup.response.submitted,{task_id:payload.task_id,patient_id:payload.patient_id})return{task_id:payload.task_id,status:TaskStatus.SUBMITTED}这个接口不直接计算风险而是发布事件。这样做的原因很实际问卷提交是在线请求应该尽快返回分层、摘要、通知、人工工单创建都可以异步执行避免接口超时。示例规则引擎把分层逻辑配置化随访系统里最容易反复改的是分层规则。为了避免每改一次规则就发版可以将规则做成配置。下面的示例仅用于说明工程实现不代表任何医学判断标准。defclassify_followup(answers:dict)-dict:score0reasons[]ifanswers.get(missed_followup)isTrue:score1reasons.append(未按计划完成上一次随访)ifanswers.get(symptom_score,0)7:score2reasons.append(示例症状评分达到配置阈值)ifanswers.get(need_callback)isTrue:score2reasons.append(用户主动请求人工回访)ifscore3:levelHIGH_ATTENTIONelifscore2:levelMEDIUM_ATTENTIONelse:levelLOW_ATTENTIONreturn{level:level,score:score,reasons:reasons}真实项目中这段逻辑更适合放到规则表或规则服务中例如rule_code condition_expression score_delta event_type enabled version reviewed_by需要特别注意版本管理。随访任务生成于某个时间点执行分层时应记录命中的规则版本否则后续复盘时会出现“当前规则看不出当时为什么升级”的问题。异常上报与人工接管异常上报不建议只发一条消息给运营群。更可靠的做法是生成可追踪的risk_event并进入人工处理队列。一个异常事件至少应包含关联的随访任务 ID。示例风险等级和命中原因。原始问卷结果引用。创建时间、处理状态、负责人。人工备注和关闭原因。审计字段例如规则版本、处理人、处理时间。处理流程可以设计为规则命中 - 创建 risk_event - 分配给随访人员或队列 - 记录首次响应时间 - 人工确认处理方式 - 关闭事件并写入 manual_action这里的“人工确认”是关键节点。系统可以提示优先级但不应替代专业人员完成判断。对于机构有明确规范的升级流程应以机构规则为准例如升级给指定岗位、触发电话回访、标记为需复核等。AI 组件放在哪里更稳AI 在随访管理里比较适合做三类辅助能力将自由文本反馈提取成结构化标签例如“请求回访”“信息不完整”“表达不清”。对长文本沟通记录生成摘要减少人工接管时的阅读成本。根据历史处理记录给出工作流建议例如“建议补充联系方式核验”。不建议让 AI 直接决定最终风险等级。更稳妥的做法是AI 输出候选标签和解释规则引擎基于可审计字段做分层人工节点负责确认和闭环。工程上可以把 AI 输出当作普通输入字段例如ai_tags: [need_callback, unclear_answer] ai_summary: 用户填写不完整并表达希望人工联系 ai_confidence: 0.82然后在规则配置里明确哪些字段可参与计算哪些字段只用于展示。踩坑记录上线前要补的工程细节第一提醒要有幂等键。短信、Push、外呼任务都可能重试如果没有task_id channel round这样的幂等键很容易重复触达。第二超时不是失败。随访任务超时后通常还要进入再次提醒、人工补访或关闭流程不能简单标记为异常。第三人工处理要能反写流程。很多系统只记录“已处理”但没有记录处理动作、处理时间、关闭原因后续统计响应时效和流程质量会很困难。第四规则调整要走审核。即使是示例阈值也应支持版本、启停、审批和灰度不要让配置后台变成高风险入口。总结AI 做医学随访管理核心不是多发几次提醒而是把提醒后的反馈、分层、异常上报和人工接管串成可追踪闭环。推荐的工程路径是任务状态机负责流程推进事件表负责审计留痕规则引擎负责可配置分层AI 组件负责结构化和摘要辅助。真实项目中所有阈值、分层和升级规则都应由医疗专业人员和机构规范确认技术系统的职责是稳定执行、完整记录、及时交接。本文文献检索、文献挖掘以及文献翻译采用的是【超能文献| AI文献检索|AI文档翻译】。