AI做医学随访管理：从提醒、分层到异常上报，流程怎么设计

随访系统最容易被低估的环节不是“发一条提醒”，而是提醒之后没人接、反馈散落在多个入口、异常信息升级慢。本文从技术架构角度复盘一个 AI 辅助随访管理流程示例，重点讨论任务编排、问卷回收、示例分层规则、异常上报和人工接管闭环。以下内容仅作为工程流程示例，不提供诊断、治疗、分诊或用药建议，真实项目中的阈值和规则应由医疗专业人员及机构规范确认。

问题背景：提醒发出后，流程为什么还是断

我做随访流程设计时，最常见的断点有三个。

第一，提醒只记录了“已发送”，没有记录患者是否打开、是否填写、是否需要补发。第二，问卷、电话备注、人工处理结果分散在不同表或不同系统里，后续很难追踪一次随访的完整链路。第三，异常反馈进入系统后，没有明确的升级策略，导致运营人员靠人工筛选，延迟不可控。

所以随访自动化不应只建一个通知服务，而要把它设计成状态机加事件流：

创建随访计划 -> 生成随访任务 -> 到期提醒 -> 收集反馈 -> 示例规则分层 -> 正常归档 / 需要补问 / 异常上报 -> 人工接管 -> 处理完成并留痕

这里的 AI 更适合放在“文本摘要、意图归类、异常线索辅助识别、坐席建议生成”等位置，而不是替代专业判断。

技术目标与边界

本文示例采用 Python、FastAPI、PostgreSQL、消息队列和规则引擎。目标不是实现完整生产系统，而是给出一条可落地的主链路。

核心约束建议先写清楚：

• 所有随访动作都要可追踪，包括提醒、回复、分层、升级和人工处理。
• 示例风险分层只能作为流程触发条件，不能写成医学结论。
• 升级规则要可配置，不能硬编码在业务接口里。
• AI 输出必须保存原始输入、模型版本、提示词版本和人工确认结果。
• 人工接管节点必须有 SLA、责任人和处理状态。

一个简化架构如下：

如果 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 app=FastAPI()classTaskStatus(str,Enum):pending="pending"reminded="reminded"responded="responded"escalated="escalated"closed="closed"classFollowupResponse(BaseModel):task_id:intchannel:stranswers:dictfree_text:str|None=Nonedefevaluate_rules(answers:dict,free_text:str|None)->dict:""" 示例规则：仅用于工程流程演示。 真实项目中的阈值、关键词、升级级别必须由医疗专业人员和机构规范确认。 """reasons=[]level="normal"score=int(answers.get("self_report_score",0))missed_contact=bool(answers.get("missed_contact",False))ifscore>=8:level="review_required"reasons.append("self_report_score_reaches_configured_threshold")ifmissed_contact:level="review_required"reasons.append("missed_contact_needs_manual_followup")iffree_text:keywords=["不适","加重","无法联系"]ifany(kinfree_textforkinkeywords):level="review_required"reasons.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):result=evaluate_rules(resp.answers,resp.free_text)ifresult["level"]=="review_required":# 生产环境应写入 escalation_case，并投递人工处理队列next_action="create_escalation_case"else:next_action="archive_response"return{"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文档翻译】。