如果你在一家医院的信息科或者在医疗信息化企业做产品过去两年大概率已经上过一套“智能随访”或“AI 患者管理”系统。一开始的流程很顺畅把患者名单导进系统上线电话随访、短信提醒、App 推送管理人员终于能在大屏上看到“今日计划随访 800 人已完成 760 人完成率 95%”。但这个数字说明不了疗效。院领导真正关心的是随访完成率从 95% 降到 90%患者管理到底有没有改善临床结局辖区高血压患者的血压控制率有没有提升糖尿病患者的糖化血红蛋白达标率是不是真的涨了90 天内非计划再入院率有没有下降一旦问到这一层很多系统答不上来。这就是“AI 患者管理驶入深水区”的真实含义。浅水区解决的是“管得住”患者有没有被纳入管理、该随访的有没有随访、通知有没有触达。深水区要回答的问题变成了“管出疗效”这些管理动作是否真正改善了患者的治疗结局。本文从工程和产品视角拆解AI 患者管理从“管得住”走向“管出疗效”需要什么样的数据底座、智能引擎、执行闭环和评估机制并给出可落地的代码示例。读完本文你应该能完成三件事第一说清楚“管得住”与“管出疗效”在指标体系上的本质区别第二搭出一个包含风险分层、随访任务生成、大模型文案生成、疗效指标统计的最小系统原型第三知道上线这类系统时最常见的坑以及哪些工程红线不能碰。1. 从「管得住」到「管出疗效」到底差在哪1.1 先看一个最常见的场景某医院上线了一套慢病管理系统AI 会自动给高风险患者打电话或发短信提醒他们按时复诊、按时吃药。三个月后信息科汇报系统覆盖了 1.2 万患者随访任务完成率 96%短信触达率 99%。这个成绩单看起来非常漂亮。但如果继续追问问题很快暴露这些提醒真的转化成复诊了吗患者收到短信后有多少人挂了号系统判断的“高风险”依据是什么是只看“超过多少天没来复诊”还是结合了糖化血红蛋白、血压、用药依从性等指标当 AI 标记“该打电话”护士打电话时说什么说的内容和患者当前风险到底是不是匹配的随访任务完成后临床结局有没有变化血压控制率、血糖达标率、再入院率这些数字系统里根本查不到。多数系统在第二阶段就卡住了。原因不是算法不够强而是整个系统的设计目标是“完成任务”不是“改善结局”。1.2 两类指标为何会脱节“管得住”和“管出疗效”在指标设计上就是两套逻辑。维度过程指标管得住疗效指标管出疗效典型指标随访完成率、短信触达率、电话接通率、覆盖率血压控制率、血糖达标率、药物依从性、再入院率回答的问题管理动作做了没有管理动作有没有用数据来源任务系统和通话记录EMR、检验检查、随访量表、医保/住院记录优化难度做提醒、排任务就能提升需要风险分层、个性化干预、闭环反馈两类指标脱节通常有四个原因。第一临床结局数据没有打通。很多随访平台只有患者的联系方式没有 LIS 检验结果、没有 HIS 就诊记录所以根本算不出“控制率”。第二干预内容是“一刀切”模板。所有患者收到的短信几乎一样“请按时复诊”对刚出院的重症患者和病情稳定的老患者价值完全不同。第三缺少升级机制。高风险患者被 AI 标记之后消息推给了患者但没有送到真正能做临床判断的医生或护士面前错过了早期干预窗口。第四评估方法太粗。上线前后直接对比“血压控制率”不可靠因为入组患者本身可能有选择偏倚。需要更严谨的队列定义和对照设计这一点后面会展开。1.3 谁最应该读这篇文章医院信息科和信息中心的工程师需要理解患者管理系统的整体架构和数据集成方式。医疗 AI 公司的算法工程师需要知道模型不只是训练完就结束还要接入任务路由和疗效评估。产品经理和运营人员需要设计“过程指标 疗效指标”双层指标体系。医学生、计算机专业学生需要了解 AI 在真实医疗场景里如何落地的边界和约束。2. AI患者管理的基础概念与核心原理2.1 什么是 AI 患者管理患者管理在医疗场景里不是简单的“发通知”而是一组连贯动作患者入组建档、风险识别、随访提醒、健康宣教、用药依从性管理、并发症筛查、异常情况升级医生。传统方式依靠护士手工打电话、手工登记效率低而且患者多时只能覆盖部分人群。AI 患者管理是把这组动作拆成可计算、可执行、可评估的流程。AI 在这里至少承担三类角色感知角色理解患者的检验指标、就诊记录、量测数据形成患者画像。决策角色判断谁风险高、谁该被优先干预、下一次干预应该做什么。执行角色生成随访文案、创建任务、通过电话/短信/App 触达患者并把结果反馈给医护工作台。其中“决策 执行”的组合越来越接近 AI Agent 的形态不只是给出一个预测分数而是规划任务、调用工具、生成内容、推动闭环。2.2 「管得住」和「管出疗效」的本质区别“管得住”是过程管理。它的逻辑是系统定了规则任务被执行就认为管理到位。问题在于医疗场景中“动作完成”和“结局改善”之间隔着一整条因果链。举一个简单例子系统给所有糖化血红蛋白超过 9% 的患者发短信请他们来复诊。短信发出去了触达率 99%这是“管得住”。但患者收到短信后看到短信的人不一定是患者本人患者可能不知道怎么挂号患者到院后医生可能没有在门诊里看到这条提醒复诊后如果用药没调整指标也不一定改善。只有把上述环节一个一个补上并且把最终指标的变化计算出来才叫“管出疗效”。所以真正的转变不是加一个更先进的模型而是把系统从“以任务为中心”改造成“以结局为中心”。2.3 核心机制风险分层、干预路由、结果反馈疗效导向的 AI 患者管理有三个核心机制缺一不可。第一是风险分层。不是所有患者都需要同样的干预强度。高危患者需要电话随访、尽快复诊、医生复核中危患者需要消息提醒和健康宣教低危患者只需要周期性随访。分层的依据可以先用规则再用机器学习模型排序。第二是干预路由。分层之后系统要回答“谁来做、做什么、什么时候做、通过什么渠道做”。这需要一张策略表把风险等级映射到任务类型、优先级和截止时间而不是把所有人都塞进同一个通知模板。第三是结果反馈。干预完成后系统要把下一次的临床数据拿回来重新评估风险判断上一轮干预是否有效。只有这个环路转起来系统才具备持续优化能力。2.4 AI Agent 在患者管理中的作用大模型出现后很多人以为 AI 患者管理就是“用一个聊天机器人回答患者问题”。这个理解偏窄了。更贴近工程实践的理解是AI Agent 是一个能调用工具、完成多步任务的智能体。在患者管理场景里它可以做类似这样的事从患者时间线里取最近一次糖化血红蛋白值调用风险模型得到风险分数判断当前应该“电话随访”还是“发送教育内容”生成一段符合医疗话术规范的随访文案把任务写入护士工作台并设置 3 天后的复评提醒。这个过程它不是“聊两句”而是一个编排引擎。真正难的不是大模型本身而是它背后的工具、数据、权限和校验流程。3. 总体架构设计疗效导向的四层模型把“管出疗效”落到系统上可以抽象成四个层级数据底座层、智能决策层、任务执行层、疗效评估层。层级核心组件需要回答的问题数据底座层患者主索引、EMR/HIS/LIS 数据接入、IoT 量测数据、患者自报量表数据是否完整、可信、及时智能决策层风险分层模型、依从性预测、干预策略引擎、LLM Agent谁该被干预、该做什么任务执行层任务调度、电话/短信/App 触达、护士工作台、医生复核动作是否执行、是否闭环疗效评估层KPI 看板、队列分析、A/B 实验、模型监控是否真正改善结局数据流大致是这样患者在医院就诊产生检验和诊断数据IoT 设备持续上传血压、血糖量测值患者通过问卷或随访电话回报自我感受这些数据汇入统一的患者时间线智能决策层读取时间线输出风险分层和干预建议任务执行层把建议变成具体任务分发给护士和系统自动触达一段时间后新的临床数据回到时间线疗效评估层计算控制率、达标率、再入院率等指标反过来校准决策层。这里有一个容易被忽视的设计患者主索引。医院的 EMR、LIS、随访系统可能分别来自不同厂商同一患者在不同系统里的 ID 不一样没有统一主索引上面的所有层级都没法工作。患者管理的底层首先是数据治理而不是模型。4. 环境准备与前置条件这个最小原型不需要太重的环境核心是展示“风险分层 → 任务生成 → 文案生成 → 疗效统计”的链路。建议使用 Linux 或 macOS 作为开发环境Windows 也可以运行但部分命令需要调整。技术选型参考如下编程语言Python 3.9 及以上示例代码按 3.9 编写Web 框架FastAPI Uvicorn数据处理Pandas、scikit-learn模型保存joblib数据库PostgreSQL示例 SQL 使用窗口函数MySQL 8.0 也可改写大模型通过 OpenAI 兼容接口调用本地可使用 vLLM 或 Ollama 部署也可接入符合规范的云端模型服务安装依赖的命令如下pip install fastapi uvicorn pandas scikit-learn joblib httpx pydantic psycopg2-binary建议的项目目录结构ai-patient-management/ ├── app/ │ ├── main.py │ └── services/ │ ├── patient_risk.py │ ├── followup_service.py │ └── dialogue_generator.py ├── scripts/ │ └── train_risk_model.py ├── sql/ │ └── outcome_kpi.sql ├── data/ │ └── patient_demo.csv ├── models/ └── requirements.txt“环境版本以实际项目为准”这句话不是套话。医疗项目里后端往往要对接医院现有的 HIS/EMR数据库版本和 Python 版本经常受限。本文下面的代码是可运行的最小示例不绑定任何商用系统。5. 核心流程拆解与代码实现5.1 第一步患者风险分层规则 机器学习患者分层的起点应该简单、可解释。先用规则兜底再用模型细化排序是医疗项目中比较稳妥的做法。写一个规则函数放在app/services/patient_risk.py# 文件路径app/services/patient_risk.py def risk_label_by_rule(patient: dict) - str: 先用规则兜底后续可以用模型输出替换其中的一部分。 if patient.get(readmission_90d, 0) 1: return HIGH if patient.get(visit_gap_days, 0) 90: return HIGH if patient.get(latest_hba1c, 0) is not None and patient[latest_hba1c] 9.0: return HIGH if patient.get(visit_gap_days, 0) 30: return MEDIUM return LOW规则的优势是透明医生和护士能理解劣势是阈值固定不能刻画多因素联合风险。所以在规则之上通常再加一个机器学习模型做排序。# 文件路径scripts/train_risk_model.py import pandas as pd from sklearn.ensemble import GradientBoostingClassifier from sklearn.model_selection import train_test_split from sklearn.metrics import classification_report import joblib FEATURES [ age, latest_hba1c, visit_gap_days, adherence_rate_30d, comorbidity_count, ] if __name__ __main__: df pd.read_csv(data/patient_demo.csv) X df[FEATURES] # 示例标签90 天内是否发生非计划再入院实际业务中需要临床专家参与定义 y df[readmission_90d] X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.2, random_state42, stratifyy ) model GradientBoostingClassifier( n_estimators200, max_depth3, learning_rate0.05, random_state42, ) model.fit(X_train, y_train) y_pred model.predict(X_test) print(classification_report(y_test, y_pred)) joblib.dump(model, models/risk_model_v1.joblib)这段代码的关键点有三个stratifyy保证训练集和测试集的标签分布一致避免正样本太少时测试集里一个阳性都没有。classification_report不能只看准确率。高风险患者识别的核心是“召回率”因为漏掉一个高风险患者的代价远大于多打一个电话。模型文件单独保存后续提供预测服务时动态加载不要在 Web 请求里重复训练。特征列表里的latest_hba1c、adherence_rate_30d等都是示例。真实项目中特征定义必须由医生和数据分析师一起评审比如“依从率”到底是用处方数据算还是用服药日志算口径不同结果完全不同。5.2 第二步随访任务生成与优先级路由风险分层的直接产出不是“电话通知患者”而是生成一条带优先级的随访任务。不同风险等级对应不同的任务类型、优先级和截止时间。# 文件路径app/services/followup_service.py from datetime import datetime, timedelta RULE_TABLE { HIGH: {task_type: phone_call, priority: 5, due_days: 1}, MEDIUM: {task_type: wechat_message, priority: 3, due_days: 3}, LOW: {task_type: education_push, priority: 1, due_days: 7}, } def build_followup_task(patient_id: str, risk_level: str): rule RULE_TABLE[risk_level] due_at datetime.now() timedelta(daysrule[due_days]) return { patient_id: patient_id, risk_level: risk_level, task_type: rule[task_type], priority: rule[priority], channel: nurse_workbench, due_at: due_at.isoformat(), }这里值得注意的不是代码本身而是“路由”的设计思路高危患者不只是收到短信而是进入护士工作台由护士电话联系并在必要时推送给医生。中危患者可以通过微信模板消息或 App 推送但要带上一键预约入口。低危患者只做周期性健康宣教避免过度打扰。另外任务生成必须考虑幂等性。同一患者同一天不能因为模型重复调用而生成多条一样的任务。实际做法是给任务设置唯一键比如patient_id task_type 业务日期数据库唯一索引兜底。5.3 第三步大模型生成随访文案提示词工程有了任务还要有内容。大模型在这里的价值是批量生成个性化文案替代原来的“请输入姓名”式模板。但医疗场景对内容安全要求极高提示词必须做严格约束。# 文件路径app/services/dialogue_generator.py import os import httpx LLM_API_URL os.getenv(LLM_API_URL, http://localhost:11434/v1/chat/completions) LLM_MODEL os.getenv(LLM_MODEL, qwen2.5:7b) FOLLOWUP_PROMPT_TEMPLATE 你是一位慢病管理随访助手。请根据患者信息生成一段不超过60字的随访提醒文案。 要求 1. 语气温和、专业不制造焦虑 2. 必须包含下次随访时间或检查项目 3. 不得给出具体用药建议 4. 只做提醒和健康宣教不替代医生判断 5. 不得使用恐吓、夸张的表达。 患者信息 - 患者编号{name} - 疾病{disease} - 风险等级{risk_level} - 最近一次糖化血红蛋白{latest_hba1c} - 下次随访时间{next_followup} def generate_followup_text(patient_info: dict) - str: prompt FOLLOWUP_PROMPT_TEMPLATE.format(**patient_info) resp httpx.post( LLM_API_URL, headers{Authorization: fBearer {os.getenv(LLM_API_KEY, )}}, json{ model: LLM_MODEL, messages: [{role: user, content: prompt}], temperature: 0.2, }, timeout30, ) resp.raise_for_status() return resp.json()[choices][0][message][content]这段代码做了几件重要的事把temperature降到 0.2减少随机性。在提示词里明确“不得给出具体用药建议”。要求输出不超过 60 字方便短信和微信直接发送。把患者姓名替换为编号尽量降低个人敏感信息进入第三方模型服务的风险。但提示词不是安全边界只是第一道防线。生产环境还要在模型输出后增加规则校验比如用正则判断是否出现“停药”“减量”“加量”等禁词一旦命中就退回人工审核。大模型生成的内容必须被当作“草稿”而不是最终发给患者的文字。5.4 第四步疗效指标计算管理者看什么随访做完闭环 AI患者管理深水区：从管得住到管出疗效的工程实践
如果你在一家医院的信息科或者在医疗信息化企业做产品过去两年大概率已经上过一套“智能随访”或“AI 患者管理”系统。一开始的流程很顺畅把患者名单导进系统上线电话随访、短信提醒、App 推送管理人员终于能在大屏上看到“今日计划随访 800 人已完成 760 人完成率 95%”。但这个数字说明不了疗效。院领导真正关心的是随访完成率从 95% 降到 90%患者管理到底有没有改善临床结局辖区高血压患者的血压控制率有没有提升糖尿病患者的糖化血红蛋白达标率是不是真的涨了90 天内非计划再入院率有没有下降一旦问到这一层很多系统答不上来。这就是“AI 患者管理驶入深水区”的真实含义。浅水区解决的是“管得住”患者有没有被纳入管理、该随访的有没有随访、通知有没有触达。深水区要回答的问题变成了“管出疗效”这些管理动作是否真正改善了患者的治疗结局。本文从工程和产品视角拆解AI 患者管理从“管得住”走向“管出疗效”需要什么样的数据底座、智能引擎、执行闭环和评估机制并给出可落地的代码示例。读完本文你应该能完成三件事第一说清楚“管得住”与“管出疗效”在指标体系上的本质区别第二搭出一个包含风险分层、随访任务生成、大模型文案生成、疗效指标统计的最小系统原型第三知道上线这类系统时最常见的坑以及哪些工程红线不能碰。1. 从「管得住」到「管出疗效」到底差在哪1.1 先看一个最常见的场景某医院上线了一套慢病管理系统AI 会自动给高风险患者打电话或发短信提醒他们按时复诊、按时吃药。三个月后信息科汇报系统覆盖了 1.2 万患者随访任务完成率 96%短信触达率 99%。这个成绩单看起来非常漂亮。但如果继续追问问题很快暴露这些提醒真的转化成复诊了吗患者收到短信后有多少人挂了号系统判断的“高风险”依据是什么是只看“超过多少天没来复诊”还是结合了糖化血红蛋白、血压、用药依从性等指标当 AI 标记“该打电话”护士打电话时说什么说的内容和患者当前风险到底是不是匹配的随访任务完成后临床结局有没有变化血压控制率、血糖达标率、再入院率这些数字系统里根本查不到。多数系统在第二阶段就卡住了。原因不是算法不够强而是整个系统的设计目标是“完成任务”不是“改善结局”。1.2 两类指标为何会脱节“管得住”和“管出疗效”在指标设计上就是两套逻辑。维度过程指标管得住疗效指标管出疗效典型指标随访完成率、短信触达率、电话接通率、覆盖率血压控制率、血糖达标率、药物依从性、再入院率回答的问题管理动作做了没有管理动作有没有用数据来源任务系统和通话记录EMR、检验检查、随访量表、医保/住院记录优化难度做提醒、排任务就能提升需要风险分层、个性化干预、闭环反馈两类指标脱节通常有四个原因。第一临床结局数据没有打通。很多随访平台只有患者的联系方式没有 LIS 检验结果、没有 HIS 就诊记录所以根本算不出“控制率”。第二干预内容是“一刀切”模板。所有患者收到的短信几乎一样“请按时复诊”对刚出院的重症患者和病情稳定的老患者价值完全不同。第三缺少升级机制。高风险患者被 AI 标记之后消息推给了患者但没有送到真正能做临床判断的医生或护士面前错过了早期干预窗口。第四评估方法太粗。上线前后直接对比“血压控制率”不可靠因为入组患者本身可能有选择偏倚。需要更严谨的队列定义和对照设计这一点后面会展开。1.3 谁最应该读这篇文章医院信息科和信息中心的工程师需要理解患者管理系统的整体架构和数据集成方式。医疗 AI 公司的算法工程师需要知道模型不只是训练完就结束还要接入任务路由和疗效评估。产品经理和运营人员需要设计“过程指标 疗效指标”双层指标体系。医学生、计算机专业学生需要了解 AI 在真实医疗场景里如何落地的边界和约束。2. AI患者管理的基础概念与核心原理2.1 什么是 AI 患者管理患者管理在医疗场景里不是简单的“发通知”而是一组连贯动作患者入组建档、风险识别、随访提醒、健康宣教、用药依从性管理、并发症筛查、异常情况升级医生。传统方式依靠护士手工打电话、手工登记效率低而且患者多时只能覆盖部分人群。AI 患者管理是把这组动作拆成可计算、可执行、可评估的流程。AI 在这里至少承担三类角色感知角色理解患者的检验指标、就诊记录、量测数据形成患者画像。决策角色判断谁风险高、谁该被优先干预、下一次干预应该做什么。执行角色生成随访文案、创建任务、通过电话/短信/App 触达患者并把结果反馈给医护工作台。其中“决策 执行”的组合越来越接近 AI Agent 的形态不只是给出一个预测分数而是规划任务、调用工具、生成内容、推动闭环。2.2 「管得住」和「管出疗效」的本质区别“管得住”是过程管理。它的逻辑是系统定了规则任务被执行就认为管理到位。问题在于医疗场景中“动作完成”和“结局改善”之间隔着一整条因果链。举一个简单例子系统给所有糖化血红蛋白超过 9% 的患者发短信请他们来复诊。短信发出去了触达率 99%这是“管得住”。但患者收到短信后看到短信的人不一定是患者本人患者可能不知道怎么挂号患者到院后医生可能没有在门诊里看到这条提醒复诊后如果用药没调整指标也不一定改善。只有把上述环节一个一个补上并且把最终指标的变化计算出来才叫“管出疗效”。所以真正的转变不是加一个更先进的模型而是把系统从“以任务为中心”改造成“以结局为中心”。2.3 核心机制风险分层、干预路由、结果反馈疗效导向的 AI 患者管理有三个核心机制缺一不可。第一是风险分层。不是所有患者都需要同样的干预强度。高危患者需要电话随访、尽快复诊、医生复核中危患者需要消息提醒和健康宣教低危患者只需要周期性随访。分层的依据可以先用规则再用机器学习模型排序。第二是干预路由。分层之后系统要回答“谁来做、做什么、什么时候做、通过什么渠道做”。这需要一张策略表把风险等级映射到任务类型、优先级和截止时间而不是把所有人都塞进同一个通知模板。第三是结果反馈。干预完成后系统要把下一次的临床数据拿回来重新评估风险判断上一轮干预是否有效。只有这个环路转起来系统才具备持续优化能力。2.4 AI Agent 在患者管理中的作用大模型出现后很多人以为 AI 患者管理就是“用一个聊天机器人回答患者问题”。这个理解偏窄了。更贴近工程实践的理解是AI Agent 是一个能调用工具、完成多步任务的智能体。在患者管理场景里它可以做类似这样的事从患者时间线里取最近一次糖化血红蛋白值调用风险模型得到风险分数判断当前应该“电话随访”还是“发送教育内容”生成一段符合医疗话术规范的随访文案把任务写入护士工作台并设置 3 天后的复评提醒。这个过程它不是“聊两句”而是一个编排引擎。真正难的不是大模型本身而是它背后的工具、数据、权限和校验流程。3. 总体架构设计疗效导向的四层模型把“管出疗效”落到系统上可以抽象成四个层级数据底座层、智能决策层、任务执行层、疗效评估层。层级核心组件需要回答的问题数据底座层患者主索引、EMR/HIS/LIS 数据接入、IoT 量测数据、患者自报量表数据是否完整、可信、及时智能决策层风险分层模型、依从性预测、干预策略引擎、LLM Agent谁该被干预、该做什么任务执行层任务调度、电话/短信/App 触达、护士工作台、医生复核动作是否执行、是否闭环疗效评估层KPI 看板、队列分析、A/B 实验、模型监控是否真正改善结局数据流大致是这样患者在医院就诊产生检验和诊断数据IoT 设备持续上传血压、血糖量测值患者通过问卷或随访电话回报自我感受这些数据汇入统一的患者时间线智能决策层读取时间线输出风险分层和干预建议任务执行层把建议变成具体任务分发给护士和系统自动触达一段时间后新的临床数据回到时间线疗效评估层计算控制率、达标率、再入院率等指标反过来校准决策层。这里有一个容易被忽视的设计患者主索引。医院的 EMR、LIS、随访系统可能分别来自不同厂商同一患者在不同系统里的 ID 不一样没有统一主索引上面的所有层级都没法工作。患者管理的底层首先是数据治理而不是模型。4. 环境准备与前置条件这个最小原型不需要太重的环境核心是展示“风险分层 → 任务生成 → 文案生成 → 疗效统计”的链路。建议使用 Linux 或 macOS 作为开发环境Windows 也可以运行但部分命令需要调整。技术选型参考如下编程语言Python 3.9 及以上示例代码按 3.9 编写Web 框架FastAPI Uvicorn数据处理Pandas、scikit-learn模型保存joblib数据库PostgreSQL示例 SQL 使用窗口函数MySQL 8.0 也可改写大模型通过 OpenAI 兼容接口调用本地可使用 vLLM 或 Ollama 部署也可接入符合规范的云端模型服务安装依赖的命令如下pip install fastapi uvicorn pandas scikit-learn joblib httpx pydantic psycopg2-binary建议的项目目录结构ai-patient-management/ ├── app/ │ ├── main.py │ └── services/ │ ├── patient_risk.py │ ├── followup_service.py │ └── dialogue_generator.py ├── scripts/ │ └── train_risk_model.py ├── sql/ │ └── outcome_kpi.sql ├── data/ │ └── patient_demo.csv ├── models/ └── requirements.txt“环境版本以实际项目为准”这句话不是套话。医疗项目里后端往往要对接医院现有的 HIS/EMR数据库版本和 Python 版本经常受限。本文下面的代码是可运行的最小示例不绑定任何商用系统。5. 核心流程拆解与代码实现5.1 第一步患者风险分层规则 机器学习患者分层的起点应该简单、可解释。先用规则兜底再用模型细化排序是医疗项目中比较稳妥的做法。写一个规则函数放在app/services/patient_risk.py# 文件路径app/services/patient_risk.py def risk_label_by_rule(patient: dict) - str: 先用规则兜底后续可以用模型输出替换其中的一部分。 if patient.get(readmission_90d, 0) 1: return HIGH if patient.get(visit_gap_days, 0) 90: return HIGH if patient.get(latest_hba1c, 0) is not None and patient[latest_hba1c] 9.0: return HIGH if patient.get(visit_gap_days, 0) 30: return MEDIUM return LOW规则的优势是透明医生和护士能理解劣势是阈值固定不能刻画多因素联合风险。所以在规则之上通常再加一个机器学习模型做排序。# 文件路径scripts/train_risk_model.py import pandas as pd from sklearn.ensemble import GradientBoostingClassifier from sklearn.model_selection import train_test_split from sklearn.metrics import classification_report import joblib FEATURES [ age, latest_hba1c, visit_gap_days, adherence_rate_30d, comorbidity_count, ] if __name__ __main__: df pd.read_csv(data/patient_demo.csv) X df[FEATURES] # 示例标签90 天内是否发生非计划再入院实际业务中需要临床专家参与定义 y df[readmission_90d] X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.2, random_state42, stratifyy ) model GradientBoostingClassifier( n_estimators200, max_depth3, learning_rate0.05, random_state42, ) model.fit(X_train, y_train) y_pred model.predict(X_test) print(classification_report(y_test, y_pred)) joblib.dump(model, models/risk_model_v1.joblib)这段代码的关键点有三个stratifyy保证训练集和测试集的标签分布一致避免正样本太少时测试集里一个阳性都没有。classification_report不能只看准确率。高风险患者识别的核心是“召回率”因为漏掉一个高风险患者的代价远大于多打一个电话。模型文件单独保存后续提供预测服务时动态加载不要在 Web 请求里重复训练。特征列表里的latest_hba1c、adherence_rate_30d等都是示例。真实项目中特征定义必须由医生和数据分析师一起评审比如“依从率”到底是用处方数据算还是用服药日志算口径不同结果完全不同。5.2 第二步随访任务生成与优先级路由风险分层的直接产出不是“电话通知患者”而是生成一条带优先级的随访任务。不同风险等级对应不同的任务类型、优先级和截止时间。# 文件路径app/services/followup_service.py from datetime import datetime, timedelta RULE_TABLE { HIGH: {task_type: phone_call, priority: 5, due_days: 1}, MEDIUM: {task_type: wechat_message, priority: 3, due_days: 3}, LOW: {task_type: education_push, priority: 1, due_days: 7}, } def build_followup_task(patient_id: str, risk_level: str): rule RULE_TABLE[risk_level] due_at datetime.now() timedelta(daysrule[due_days]) return { patient_id: patient_id, risk_level: risk_level, task_type: rule[task_type], priority: rule[priority], channel: nurse_workbench, due_at: due_at.isoformat(), }这里值得注意的不是代码本身而是“路由”的设计思路高危患者不只是收到短信而是进入护士工作台由护士电话联系并在必要时推送给医生。中危患者可以通过微信模板消息或 App 推送但要带上一键预约入口。低危患者只做周期性健康宣教避免过度打扰。另外任务生成必须考虑幂等性。同一患者同一天不能因为模型重复调用而生成多条一样的任务。实际做法是给任务设置唯一键比如patient_id task_type 业务日期数据库唯一索引兜底。5.3 第三步大模型生成随访文案提示词工程有了任务还要有内容。大模型在这里的价值是批量生成个性化文案替代原来的“请输入姓名”式模板。但医疗场景对内容安全要求极高提示词必须做严格约束。# 文件路径app/services/dialogue_generator.py import os import httpx LLM_API_URL os.getenv(LLM_API_URL, http://localhost:11434/v1/chat/completions) LLM_MODEL os.getenv(LLM_MODEL, qwen2.5:7b) FOLLOWUP_PROMPT_TEMPLATE 你是一位慢病管理随访助手。请根据患者信息生成一段不超过60字的随访提醒文案。 要求 1. 语气温和、专业不制造焦虑 2. 必须包含下次随访时间或检查项目 3. 不得给出具体用药建议 4. 只做提醒和健康宣教不替代医生判断 5. 不得使用恐吓、夸张的表达。 患者信息 - 患者编号{name} - 疾病{disease} - 风险等级{risk_level} - 最近一次糖化血红蛋白{latest_hba1c} - 下次随访时间{next_followup} def generate_followup_text(patient_info: dict) - str: prompt FOLLOWUP_PROMPT_TEMPLATE.format(**patient_info) resp httpx.post( LLM_API_URL, headers{Authorization: fBearer {os.getenv(LLM_API_KEY, )}}, json{ model: LLM_MODEL, messages: [{role: user, content: prompt}], temperature: 0.2, }, timeout30, ) resp.raise_for_status() return resp.json()[choices][0][message][content]这段代码做了几件重要的事把temperature降到 0.2减少随机性。在提示词里明确“不得给出具体用药建议”。要求输出不超过 60 字方便短信和微信直接发送。把患者姓名替换为编号尽量降低个人敏感信息进入第三方模型服务的风险。但提示词不是安全边界只是第一道防线。生产环境还要在模型输出后增加规则校验比如用正则判断是否出现“停药”“减量”“加量”等禁词一旦命中就退回人工审核。大模型生成的内容必须被当作“草稿”而不是最终发给患者的文字。5.4 第四步疗效指标计算管理者看什么随访做完闭环