共病管理系统：把风险提示接进门诊引导与住院会诊

摘要　共病风险常藏在一次就诊的检验检查里，难点在于发现之后谁核实、谁通知、谁接手。某综合医院的共病管理平台依托现有临床决策支持系统、医院信息系统和短信平台，一期以临床规则预警为主：门诊患者收到专科就诊提醒，住院预警进入医生工作站并可直接发起共病会诊，处理选择留有记录。本文介绍它的角色分工、两条流程、截至 2026 年 9 月的实施范围与后续方向，以及效果该怎样观察。

风险被看见之后，谁来接手

医院按专科分科，患者却常常同时带着几种慢病或风险因素。因消化问题来看门诊，或者因外科手术住院，检验检查里都可能出现需要另一个专科评估的信号。

在这套平台建设之前，这类信号大致是这样处理的：

• 发现靠经验：医生查房或接诊时人工翻看检验检查结果，凭经验判断，没有统一的识别标准。
• 会诊靠手填：医生手动开立会诊医嘱，手工填写会诊目的和邀请科室，没有统一模板。
• 记录难统计：会诊意见没有“共病”分类，事后很难筛出哪些会诊因共病发起。
• 后续靠科室自己记：会诊之后的跟进，主要依靠科室内部的手工记录。

门诊还多一个断点：有些结果出来时，患者已经离开医院。信息停在系统里，患者不知道，相关专科也不知道。

所以这套产品要解决的不是“发现更多异常”，而是让一条风险提示有明确的接收人、处理入口和处理记录。

产品定位：在现有系统里搭一条协作链

平台没有另起一套独立系统，而是依托医院已有的临床决策支持系统（CDSS）、医院信息系统（HIS）医生工作站和短信平台改造流程：CDSS 按规则识别风险，HIS 把提示放进医生的工作界面并承接会诊，短信平台通知已经离院的门诊患者。项目由医务部门提出需求，信息部门评估实施，相关临床科室参与。

角色	在系统里做什么	判断与责任
接诊或管床医生	在工作站看到预警，查看原因，发起共病会诊或选择暂不处理	判断提示的临床意义，决定是否会诊
共病相关专科医生	接收共病会诊，查看病历与检验检查，书写意见；门诊场景在后台查看触发名单	专科评估与诊疗意见，必要时主动联系患者
门诊患者	收到就诊提醒短信和挂号入口	自己决定是否前往进一步评估
医务与信息团队	提供并维护规则和短信内容，查询触发、通知与会诊记录	规则口径、流程质量与持续改进

首批场景分三类，每一类走的路径并不相同：

血糖管理出现在整体规划和规则清单中，属于后续拓展方向，不在首批场景之内。

从规则命中到临床处理

整条流程可以概括为五步：规则识别 → 提示送达 → 医生核实与选择 → 门诊引导或住院会诊 → 记录与统计。

这张图里最重要的是分工：

• 系统负责：按已确认的规则找出候选风险；把提示送到对应的人和界面；预填会诊信息；按病种提醒复核；记录每一步的处理。
• 医生负责：判断提示是否成立、对眼前这位患者是否有意义；决定发起会诊、暂不处理还是采取其他措施；完成专科评估和后续诊疗决定。

规则命中只说明“值得核实”，不等于诊断。触发条件由医务部门统一提供、经临床确认，类型包括检验指标、检查结论、病历记录的诊断和特定用药等。

门诊：短信提醒与专科就诊引导

门诊路径针对的是“患者已经离院，风险信号才出现”的情况。

1. 规则识别出符合专项条件的门诊患者。
2. 短信平台向患者发送提醒，说明建议到哪个专科进一步评估，并附挂号入口。
3. 对应专科在后台看到触发名单和具体指标，必要时主动联系患者。
4. 患者到专科就诊，由专科医生问诊、检查并作出判断。

短信的作用是提醒和引导，不是告知诊断。现有模板写的是“系统提示您为某类风险人群，建议及时到对应专科进一步就诊评估”，并附预约挂号链接，没有使用确诊的说法。需求设计还要求记录推送情况，发送失败的交由管理部门处理。

住院：工作站预警、共病会诊与处置留痕

住院患者有管床医生和连续的诊疗过程，提示被放进医生每天都要打开的界面。

预警进入工作站。 CDSS 把预警信息和建议科室推送给 HIS，医生打开患者进行日常处理时看到弹窗：写明触发依据和建议会诊的科室，由医生选择是否发起会诊。

发起会诊少填一步。 医生选择发起会诊后，预警内容默认带入会诊目的，建议科室默认作为受邀科室；医生补充本次会诊要回答的问题后发出，记录带上“共病”标记。

暂不处理也要说明。 医生判断暂不需要时，可以选择暂不执行并说明理由。设计中预设了患者不愿纳入、当前情况不适合、指标属一过性波动等选项；选择其他原因时须手动填写，不少于 10 个字。

专科接手。 被邀请科室查看病历和检验检查，书写会诊意见，并可按“共病”筛选本科室的共病会诊患者。

按病种提醒复核。 感染管理在患者纳入满三天时提醒专科医生复核病情、诊疗和用药，评估是否调整方案；痛风病程周期较长，三天复核意义不大，不设这一提醒；心血管高危按首批设计只走门诊路径。

“暂不处理”这一分支很关键：它承认医生的判断可以和规则不同，同时把理由留下来，供后续调整规则参考。

示意场景：同一条风险信息的两种交接

以下为说明流程而虚构的情景，不对应任何真实患者，也不构成诊疗建议。

门诊：一位患者看完某专科门诊后离院，当天的检查结果符合心血管高危专项的触发条件。患者收到短信，建议到心血管专科进一步评估，并附挂号入口；心血管专科也在后台名单里看到了这位患者。去不去由患者决定；去了之后怎么评估、怎么处理，由接诊医生决定。

住院：另一位住院患者的用药记录触发了感染管理专项。管床医生打开患者信息时看到弹窗，认为需要专科意见，便从弹窗发起会诊，补充了希望专科回答的问题。专科医生查看资料后写下会诊意见；三天后，系统提醒专科医生再看一次这位患者。如果管床医生认为这只是一过性波动，也可以暂不处理并留下理由。

五个功能模块，各对应一个断点

模块	做什么	对应原来的断点
共病规则管理与预警	医务部门提供专项触发条件，CDSS 按条件识别并推送	识别没有统一标准
门诊短信提醒	向已离院的患者发送专科就诊提醒和挂号入口	患者离院后，信息无人传达
共病会诊申请	从预警入口发起，预填原因与邀请科室，加共病标记	会诊目的和科室全靠手填
会诊管理与复核提醒	专科查看资料、书写意见，适用病种按时提醒复核	会诊之后缺少跟踪
共病查询统计	按共病标记查询会诊记录，查看触发、处置人与处置方式	共病会诊无法筛选统计

合起来，产品价值落在三件具体的事上：提示到达能处理的人，不再停在某张报告单上；发起协作的成本更低，会诊信息预填，患者拿到建议科室和挂号入口；处理过程可以核对，管理团队能看到风险停在了哪一步。

它不负责的事也要说清楚：不替医生诊断，不自动开立治疗，也不保证患者一定到诊。

已实施范围与后续演进

根据 2026 年 9 月的建设汇报，平台在 2026 年 8—9 月上线试运行，开放三类场景，能力集中在临床规则预警、门诊短信引导、住院共病会诊与处置留痕，以及共病会诊的查询统计。以下描述以该阶段资料为准，不代表此后的实时状态。

同一份汇报也列出了四类不足：预警依赖单指标阈值和疾病条件，分级口径偏宽、存在重复提醒；缺少多病共存的组合规则，存在漏筛；住院端主要靠会诊推进，共同查房、用药重整和营养、康复、护理协同还没有接上；虚拟共管病区、跨科权限和知情同意仍待建设，共管考核与随访还没有连起来。

对应的后续方向都还是规划：纳入血糖等更多病种并延伸到院后；细化规则分级、校准阈值；引入大模型辅助识别多病共存组合，与规则协同而不是取代规则；建设跨科共管；接入用药提醒、指标自我上报、复诊预约等患者端服务。

一项独立探索：共病候选识别与医生标注原型

误报、漏筛和口径偏宽，最终都要靠医生的判断来校正。另有一个独立原型，在探索怎样把这些判断沉淀下来。

它的设计是：规则从临床数据中生成候选标签和证据，进入审核队列；医生查看患者摘要、时间线和原始证据后，选择确认、否定、修改、信息不足或暂缓判断，也可以补上规则漏掉的标签。否定时须选择原因，例如把既往史或家族史当成当前疾病、单项检验不足以支持判断。每次复核保存数据快照和规则版本，让规则和未来的模型能在同一口径下做离线评估。

它的边界需要说清楚：

• 它和院内平台是两个不同的产品对象。2026 年 8 月的需求规格仍是 MVP 评审稿，首期建议标签的定义还需临床负责人确认。
• 现有资料是原型的设计与开发材料，不能证明它已接通医院真实数据、已在临床常态使用，也不意味着医疗大模型已训练完成或上线。
• 原型输出的是候选标签，不形成正式诊断，不生成治疗方案，也不修改医院的原始数据。

产品效果应该怎样观察

预警数、短信数、会诊人次和就诊人次最容易拿来报告。这些数字有用，但各自只回答一个环节的问题。

几件事最好事先约定：

• 分清人数与人次，口径前后一致。
• 设定基线：没有平台时，一部分患者本来也会去相关专科，召回人次不能直接算作增量；业务量和费用也不等于临床获益。
• 看“暂不处理”的理由：理由集中在某一类，往往说明规则口径需要调整。
• 抽样评估漏筛：只看被提示的病例，无法知道漏了谁。
• 临床结局单独设计：并发症、住院日、再入院等变化，需要对照、时间范围和数据来源明确的专门评估。

在这些评估完成之前，更稳妥的说法是：平台已经把风险提示接进了门诊和住院的工作流程；它有没有改善患者结局，还需要用数据回答。