你把几份病历交给 AI：门诊笔记写着一种诊断，另一家医院的记录却不同；化验值后来改过，日期只写了“一月”。普通软件很容易替你“补齐”或合并。可在医疗场景里，一次自作聪明，就可能把错误带进患者档案。OpenMed 3.0 想做的，是让 AI 在本地整理这些资料，同时把“不确定”原样留下。
OpenMed 不是一个负责诊断的单一模型，而是一套临床 AI 工具包：开发者可以用它组合模型运行、文档处理和工作流。项目维护者称，3.0 采用 Apache-2.0 许可证，可全程在本地和离线环境运行，不需要 API key，也不会在本地模型不可用时悄悄转向云端。本文涉及的功能与表现均来自维护者发布材料，目前没有独立测试或安全审计佐证。
把散落的病历拼成一条时间线
3.0 的核心更新叫 Patient Journey。现实中的患者资料不会整齐地待在一份文件里：临床笔记、FHIR 和 HL7 医疗数据交换记录、实验室 CSV 表格、影像报告，可能分散在不同系统中。Patient Journey 会把这些来源整理成一条患者时间线，并在用户自己的硬件上完成处理。
这里最值得注意的不是“拼起来”，而是它怎样处理模糊地带。维护者称，即使两份资料的身份匹配度达到 99%，系统也不会自动认定它们属于同一人，而会交给人工复核。原因很直接：一旦错合并，甲患者的过敏信息可能进入乙患者的档案。
不同来源给出冲突诊断时，系统会同时保留两条记录并标记复核。化验结果从 6.8 修正为 4.4，它会保存修正前后的值，让人仍能看到记录怎样变化。资料若只写“January”，它也不会为了填满数据库字段，擅自改成 January 1st。换句话说，它宁可承认不知道，也不制造一种虚假的整齐。
本地不只是模型放在哪里
本地推理，指模型在医院或用户控制的设备上运行，原始资料不必交给第三方云端。OpenMed 还把“工具调用”纳入同一套设计——也就是让模型按规定格式请求搜索、计算或数据库等软件功能，把文字理解接到实际工作步骤上。
维护者称，OpenMed 可连接 Hugging Face 上 2,200 多个开放模型，并支持 Transformers、ONNX、GGUF/llama.cpp，以及通过 WebGPU、WASM 或手机运行。WebGPU 让网页调用本机 GPU，WASM 则让编译后的程序在浏览器中执行。不过，“支持 2,200 多个模型”只表示兼容范围，不能理解为这些模型都经过临床验证，或都适合医疗用途。
项目方还表示，如果用户要求本地模型生成摘要，而对应模型尚未下载，OpenMed 会直接拒绝，不会静默调用云端 API。这一点把隐私选择重新交还给使用者：缺少本地能力时，系统停下来，而不是代替医院或患者决定把数据发出去。
为什么这次更新值得看
OpenMed 早期更像一组逐份处理文档的工具，例如从一份笔记中识别诊断，或从 PDF 中移除姓名。3.0 把范围扩展到跨来源的患者记录、模型调用和临床工作流。项目官网还把语言包、各国身份证件校验器、翻译和移动端支持归功于社区贡献者。它试图把分散的研究组件，拼成普通开发者也能部署的离线工具箱。
维护者展示的演示中，五个混乱的合成数据源约用 0.07 秒整合成一条 Patient Journey。这个数字只能说明演示可以快速跑通：材料没有交代硬件、数据规模、重复次数和统计方法，不能外推为真实医院里的性能。
局限与未知
- 演示患者和 3.0 的摘要流程都只使用合成数据；维护者明确表示，摘要流程尚未准备好处理真实临床数据。
- “数据留在本机”和“绝不回退云端”目前属于项目方的架构承诺，尚缺独立安全审计或网络行为测试；日志、存储、权限、模型下载和依赖组件仍会影响整体隐私。
- 身份匹配、冲突保留和日期不补全等行为，目前也只有维护者陈述。标题所称 3.1 有 422 个 open issues，因缺少统计口径、查询时间和可核验列表，不宜视为确定的项目指标。