OpenMedCheck：用本地Gemma为急诊医生读病历的开源处方检查器

急诊处方安全的盲区：写在自由文本里的关键信息

急诊科的处方往往在时间压力下开出，而真正决定某个药是否合适的线索，常常只存在于自由文本中：今天病程记录里一句尚未编码的「疑似急性冠脉综合征（ACS）」，或者既往史中一行「2021年十二指肠溃疡导致的上消化道出血」。传统的处方审查模块主要基于编码数据检查药物配对，读不懂这些文本；而它们发出的警报又经常被医生直接覆盖。据一项2025年的系统综述，药物相互作用警报在患者重要结局上并未带来显著改善。开源项目 OpenMedCheck 的作者由此提出一个不同的判断：问题不在于警报太多，而在于警报缺少患者上下文。

药物相互作用（DDI）警报与「警报疲劳」：临床决策支持系统（CDS）根据药物配对规则自动弹出的提示，本意是拦截潜在有害的联合用药。但在实际部署中，这类警报的阳性预测值往往偏低，医生久而久之形成「习惯性覆盖」（alert override），即不看内容直接关闭。2025 年的系统综述所指的「未带来显著改善」，正是针对这一现象：警报数量增加并不等于患者结局改善，反而可能因关键警报被淹没而产生反效果。这也解释了 OpenMedCheck 为何把「减少无效警报、补上患者上下文」而非「增加检查项」作为设计出发点。

ICD 编码与自由文本的鸿沟：医院信息系统中的诊断、既往史通常以 ICD-10 等标准编码存储，便于统计和规则匹配；但急诊场景下，医生常在病程记录中以自然语言描述尚未确诊的怀疑（如「疑似 ACS」），这些内容要等到出院或明确诊断后才被编码，存在时间滞后甚至永久缺失。基于编码数据的审查模块因此天然看不到「当下正在怀疑什么」，这正是文章所说「读不懂这些文本」的技术根源。

一个输入，一张决策卡

OpenMedCheck 的交互设计非常克制：输入一条拟开的医嘱和患者病历，输出一张决策卡，状态为 NO_ISSUE、WARNING 或 BLOCKED，附带原因、医生原话作为证据，以及在规则表允许时给出的、经过重新校验的替代方案。当没有冲突时，它只显示一行「No issue found by these checks」，然后让开。

项目用两个合成患者说明了价值所在。Bed 3 是一位胸痛患者，记录中有每日服用阿司匹林，今日病程写道「疑似ACS，心电图和肌钙蛋白待查」，而拟开药物是 NSAID 类止痛药右酮洛芬。由于信息尚未编码，纯规则判断为 NO_ISSUE；一旦 Gemma 读到病程记录，卡片变为红色 BLOCKED，引用医生原话，并给出已复检的替代方案对乙酰氨基酚。Bed 5 则是腕关节扭伤患者，今日就诊看似常规，但既往史中藏着上消化道出血记录，规则同样漏判，Gemma 找到该行后给出琥珀色 WARNING。

三层架构：模型只负责读，代码负责校验，规则负责决策

OpenMedCheck 的技术核心是一个清晰的三段式分工，这也是它能在 8GB 显存的笔记本 GPU 上运行 Gemma 4 E4B 的前提。

第一层：Gemma 读取自由文本

Gemma 通过 Ollama 在本地运行，读取就诊原因、既往史和今日病程，回答一组固定的问题，输出严格 JSON。每个答案都必须包含文本中的原话。

第二层：普通代码校验答案

一个不含 AI 的程序逐条验证模型答案：这些词真的出现在原文中吗？它们是否指向模型声称的内容（「轻微」不等于「心梗」）？它们是否被否定（「ACS已排除」）、属于亲属（「父亲有心梗」），或是把旧事件当作当前事件？任何未通过校验的答案都会被丢弃，防止误读变成警报。

第三层：规则表做最终决定

由药品说明书和已发表指南编写的 25 条 if-then 规则在病历和已验证事实之上重新运行，每条规则标注来源和审核状态。临床专家审核了其中 23 条，两条既往史规则为后加、标记为未审核。

整个设计的保证是「只升不降」：Gemma 的意见只能让卡片更严格，不能更宽松；规则判定的 BLOCKED 是最终结果；剂量只来自规则表，绝不来自模型；如果模型宕机、超时或连续两次回答异常，应用仍以纯规则作答，此时干净结果会显示「Free-text note not checked」，因为一个没能读取病程的检查不能看起来像通过了。

接地（grounding）与引用校验：让大模型输出结论时附带原文出处，是降低幻觉的常用手段，称为「接地」。但仅仅要求模型「引用原话」并不足够——模型仍可能引用真实存在的文字却赋予其错误含义（文中「轻微不等于心梗」即属此类）。OpenMedCheck 的第二层校验本质上是一个确定性的字符串与语义一致性检查器：先验证引用片段确实出现在原文，再检查否定词（「已排除」）、主体归属（「父亲有」）和时间指向（旧事件 vs 当前事件）。这种「模型提议、代码裁决」的模式，是把不可靠生成组件约束在可验证边界内的典型工程实践。

if-then 规则表与可审计性：规则表是把药品说明书和临床指南中的适应证、禁忌证转写为「若患者满足条件 X，则医嘱 Y 状态为 Z」的确定性逻辑。与模型不同，规则表可逐条标注来源文献与审核状态（如「已由临床专家审核」或「未审核」），从而支持版本固定与复测。对于可能被纳入医疗器械软件（SaMD）监管的系统，这种可追溯性往往是合规的前提条件之一。

为什么必须是开放权重

对 OpenMedCheck 而言，开放模型不是更便宜的选择，而是唯一可行的选择。急诊病程属于 GDPR 第 9 条规定的特殊类别健康数据，许多医院不会把每一条医嘱和记录发送给第三方模型 API。使用开放权重，Gemma 运行在医院自己的 GPU 上，应用只绑定 127.0.0.1，唯一对外调用是本地模型，患者上下文不被记录、存储或缓存。

作者在同一台机器上用 76 个合成病例对比了三个 Gemma 变体：Gemma 4 E4B 达到 97%，Gemma 3 4B 为 78% 并出现 5 次误报，Gemma 4 12B 为 80% 且有 32 次调用超时。切换模型只需改一个配置项。此外，医院可以固定、审查并复测它运行的确切模型，配合药剂师可读的规则表——对于未来可能被作为医疗器械软件监管的系统，这一点很重要。

GDPR 第 9 条与特殊类别数据：欧盟《通用数据保护条例》第 9 条将「与健康相关的数据」列为特殊类别个人数据，原则上禁止处理，除非满足明确同意、医疗目的等例外条件，且对跨境传输有额外限制。将每条急诊医嘱和病程发送至第三方云 API，意味着数据离开医院控制范围，需要复杂的法律依据与数据处理协议，许多医院直接选择不这么做。因此本地部署开放权重模型不是省钱，而是绕开数据外发这一合规障碍。

开放权重 vs 开放源代码：开放权重指模型参数可下载并在本地运行，但训练数据与训练代码未必公开；这与完全开源的软件许可证不同。对医院而言，开放权重的关键价值在于：可以固定某个确切版本、在自有硬件上审查其行为、并在模型更新后重新跑回归测试，而不必依赖供应商的静默升级。

效果数据与需要保留的保留意见

在 76 个合成急诊病例的开放集上，加入 Gemma 读病程后，与预期结果的一致率从纯规则的 72% 提升到 97%，漏判从 42 例中的 21 例降至 1 例，34 个本应保持安静的病例中 0 误报，模型步骤中位耗时 1.87 秒。

作者明确列出了局限：病例、提示词和检查器是一起构建的，因此这是开发集而非临床验证；这些数字早于既往史步骤的加入，该步骤尚未测量。这些保留意见如实呈现，是项目可信度的一部分。

开发集与临床验证的区别：文中 76 个合成病例上的高一致率属于「开发集」结果——病例、提示词和校验器是同一团队共同构造的，模型与规则可能无意中适配了这些样本的特性，乐观偏差难以避免。临床验证通常要求在真实患者数据、前瞻性或外部数据集上评估，并报告敏感性、特异性及对临床结局的影响。作者主动标注这一点，是把开发演示与临床证据明确区分的负责任做法，也提示读者不应把 97% 直接外推为真实世界性能。

从失败中学到的设计

早期提示词让 Gemma 自己判断冲突，结果它不断把「NSAID 与 ACS」关联到任何被开具的药物上，包括对乙酰氨基酚。修复方式是停止让模型做代码已经知道的事：Gemma 做它擅长的事——读杂乱文本并引用，规则做决定。

谁会为此付费

买单的不是急诊医生，而是医院里负责用药安全的人：药学与用药安全团队、临床信息学团队。他们承担用药错误和无效警报的成本，却无法扩展供应商处方模块内部的检查逻辑。EHR 和临床决策支持供应商也可以将其作为开放、可审查的组件嵌入。商业模式为开放核心：引擎保持开源，医院为维护更新的带引用规则表、与记录系统集成（HL7 FHIR、CDS Hooks）以及支持和监管路径付费。作者坦承，这一假设尚未与买家验证。

项目采用 Apache-2.0 许可，Python 3.12、FastAPI、Ollama、Pydantic，约 1080 个自动化测试。需要再次强调：这是概念演示，仅用于合成患者，不是医疗器械，不得用于任何真实患者。