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

jaxzheng

341人浏览 · 2026-05-27 09:01:36

jaxzheng · 2026-05-27 09:01:36 发布

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

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

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

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

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

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

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

技术目标与边界

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

核心约束建议先写清楚：

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

一个简化架构如下：

如果 CSDN 环境不渲染 Mermaid，也可以把它当作流程文本阅读。

数据模型：先把链路留痕设计好

随访表设计不需要一开始就复杂，但至少要区分“计划”“任务”“反馈”“升级单”。

CREATE TABLE followup_task (
    id BIGSERIAL PRIMARY KEY,
    patient_ref VARCHAR(64) NOT NULL,
    plan_code VARCHAR(64) NOT NULL,
    due_at TIMESTAMP NOT NULL,
    status VARCHAR(32) NOT NULL,
    retry_count INT DEFAULT 0,
    created_at TIMESTAMP DEFAULT now(),
    updated_at TIMESTAMP DEFAULT now()
);

CREATE TABLE followup_response (
    id BIGSERIAL PRIMARY KEY,
    task_id BIGINT NOT NULL,
    channel VARCHAR(32) NOT NULL,
    payload JSONB NOT NULL,
    ai_summary TEXT,
    rule_result JSONB,
    created_at TIMESTAMP DEFAULT now()
);

CREATE TABLE escalation_case (
    id BIGSERIAL PRIMARY KEY,
    task_id BIGINT NOT NULL,
    level VARCHAR(32) NOT NULL,
    reason TEXT NOT NULL,
    status VARCHAR(32) NOT NULL,
    owner VARCHAR(64),
    created_at TIMESTAMP DEFAULT now(),
    closed_at TIMESTAMP
);

这里 patient_ref 建议使用业务侧脱敏标识，不在随访服务里直接存储不必要的敏感信息。payload 保存问卷原始结果，rule_result 保存规则命中的版本和原因，便于审计和复盘。

任务编排：不要在接口里直接发送提醒

生产环境里，提醒发送最好走队列。接口负责创建任务，调度器扫描到期任务，worker 负责具体发送。这样可以处理重试、限流、失败补偿和渠道切换。

from datetime import datetime
from fastapi import FastAPI
from pydantic import BaseModel
from enum import Enum

app = FastAPI()

class TaskStatus(str, Enum):
    pending = "pending"
    reminded = "reminded"
    responded = "responded"
    escalated = "escalated"
    closed = "closed"

class FollowupResponse(BaseModel):
    task_id: int
    channel: str
    answers: dict
    free_text: str | None = None

def evaluate_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))

    if score >= 8:
        level = "review_required"
        reasons.append("self_report_score_reaches_configured_threshold")

    if missed_contact:
        level = "review_required"
        reasons.append("missed_contact_needs_manual_followup")

    if free_text:
        keywords = ["不适", "加重", "无法联系"]
        if any(k in free_text for k in keywords):
            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")
def submit_response(resp: FollowupResponse):
    result = evaluate_rules(resp.answers, resp.free_text)

    if result["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 状态

这样后续做报表时，才能回答“多少提醒未回复”“多少反馈进入复核”“平均接管耗时是多少”“哪些规则产生了过多误报”。