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 app=FastAPI()classTaskStatus(str,Enum):PENDING="PENDING"REMINDED="REMINDED"SUBMITTED="SUBMITTED"CLASSIFIED="CLASSIFIED"ESCALATED="ESCALATED"CLOSED="CLOSED"classQuestionnaireSubmit(BaseModel):task_id:strpatient_id:stranswers:Dict[str,Any]free_text:Optional[str]=Nonedefsave_response(payload:QuestionnaireSubmit)->None:print(f"save response task={payload.task_id}")defpublish_event(topic:str,data:dict)->None:print(f"publish{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:score=0reasons=[]ifanswers.get("missed_followup")isTrue:score+=1reasons.append("未按计划完成上一次随访")ifanswers.get("symptom_score",0)>=7:score+=2reasons.append("示例症状评分达到配置阈值")ifanswers.get("need_callback")isTrue:score+=2reasons.append("用户主动请求人工回访")ifscore>=3:level="HIGH_ATTENTION"elifscore==2:level="MEDIUM_ATTENTION"else:level="LOW_ATTENTION"return{"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文档翻译】。
