朋友在信息科干的，上个月找我喝酒，说花了三十多万做的脱敏项目翻车了。我说怎么翻的，他说做完拿到数据一跑时间序列，所有日期变成了1970-01-01，我当场没忍住笑出来，他说你别笑，我好几年随访数据全废了。后来我想了想这事，其实不怪他们科室，脱敏工具不懂医学文本，看见日期就替换，后面能不能做生存分析它不管，也管不了，毕竟大部分通用脱敏工具就是按字段类型一刀切的，它不知道这个日期字段跟病人的治疗方案、随访周期全掛着钩，动了日期等于动了整条数据链。
刷GitHub的时候看到OpenMed，涨得挺猛顺手翻了一下，方向跟我预期完全不一样，不是又一个大模型，专注在做实体抽取加隐私脱敏，而且全离线跑。出院小结丢进去，疾病、药物、解剖部位、检查指标这些抽出来，姓名身份证住院日期同步脱敏，全程不联网，甚至不用插网线。我之前也关注过BioGPT，微软做的，便利性确实拉满了，但数据得过它的服务器，Google的Med-PaLM更封闭，权重都不给你看，你怎么处理我的数据我完全看不到。OpenMed走了一条绕远的路，得自己部署，换来的是数据从出炉到脱敏全在你自己的网络边界以内。这三条路线其实没必要比性能，完全是三种对待数据主权的态度。
代码库翻完有个意外发现。一千多个生物医学模型，CPU支持，CUDA支持，苹果MLX跑起来比CPU快三十倍，而且它有个Swift包叫OpenMedKit，iPhone和iPad上可以直接离线做临床文本抽取加隐私脱敏。我拿家里iPad Pro试了一下，拍一张出院小结当场出结果，实体抽取加PII脱敏同时完成，两三秒一页，速度快到我有那么一瞬怀疑是不是在做本地缓存而不是真正的离线推理，后来断掉Wi-Fi再跑一遍结果一样，确实是纯本地运算。当时拍了五份不同科室的出院小结，心血管的、骨科的、肿瘤科的，格式差异挺大的，结果都认得出，没有出现那种换个科室就识别率暴跌的状况。社区医生上门随访的场景终于有解了，随访做完当场处理不需要回医院再补录，中间隔几个小时信息容易丢这事我听不止一个人吐槽过了，而且以前随访记录要么手写要么拍照传回去再由专人录入，整个流程拉得太长，等录完有些细节早就记不清了，这种信息衰减在实际工作中比想象中严重得多。
HIPAA 18类全覆盖，247个检查点，12种语言脱敏，连葡萄牙语CPF、荷兰BSN、印度Aadhaar都能认，做到这个程度确实不多见。GDPR第9条把健康数据归进敏感个人信息，处理门槛本身就高，OpenMed直接从架构上回避了数据传输这个环节，合规成本趋近于零。这一点在欧洲市场尤其关键，任何涉及健康数据的跨境流转都需要DPIA评估，光是文书流程就能拖上几个月，本地跑直接绕过了这层麻烦。不过话说回来，国内开源医疗AI的团队太少了，大部分走的是SaaS或者私有化部署百万起步的模式，赚钱没问题，但凡涉及医疗数据，本地化就是刚需，逼着医院花大钱买方案不如把基础能力开源了大家一起建设。国内也有做开源医疗模型的，不过多半只在预训练这一步就停了，面向真实应用场景的工具链几乎没有着落。OpenMed从预训练一路到微调部署隐私脱敏全串起来了，Apache-2.0协议代码全给，单卡GPU十二小时训完，碳排放不到1.2公斤，光这一点在圈内就算异类。
我特别想聊一个细节，智能实体合并这个东西看着不起眼，解决的问题很实际。日期「01/15/1970」，别家的模型经常拆成「01」「15」「1970」单独标注，OpenMed能把整个日期作为一个实体保住。四种脱敏模式各有用途，掩码替换用[FNAME][DATE]这类占位符做匿名化，Faker替换填充假数据格式不变拿来做科研挺顺手，哈希加密脱敏适合需要可追溯的场景，还有日期偏移就是所有日期随机推后180天。朋友那个三十万的项目毁在日期全变成1970-01-01上，Faker替换保格式才是正确的做法，时间字段一乱整条时间线就废了，踩过这坑的人才知道有多疼，数据清洗团队花了一周才发现问题根源，删掉的数据已经没办法恢复了。
DeBERTa-v3、PubMedBERT、BioELECTRA拿来做骨干，35万篇医学文献预训练再加LoRA微调，只动不到1.5%参数，说人话就是一张3060显存够跑微调了。12个基准数据集10个拿了新SOTA，BC5CDR疾病数据集提了2.7个点，基因和细胞系那种更偏门的场景提了5到9个点。我原来一直觉得全参数微调肯定是默认优选，OpenMed这个实验结果反复打脸，后来跟做NLP的朋友讨论了一下，他的猜测是医学文本分布本身就集中，不需要海量参数去覆盖长尾分布，具体到每个任务当然还得自己验证，但至少LoRA不该再被默认排除了，这对很多没有大算力资源的课题组来说意义很大。
434M和109M参数，Docker一拉就跑，不用A100也不用签BAA，对中小医疗机构来说硬件门槛从想象中的级别直接掉到一台普通工作站，3060能跑，这点我验证过了，同事那台10400的台式机都跑得起来，只是推理慢了两秒。对比那些动辄70B的通用大模型，OpenMed的体积小到有点不像医疗AI，但正是这种小让它能在边缘设备上真正落地，不需要云服务商的承诺书也不需要医院的网络审批流程，装上就能用。
中文缺席这件事我犹豫要不要写，因为写出来像在挑刺，但事实就是12种语言里没有中文，国内电子病历标准化、科研清洗、DRG分组全缺一个好用的开源工具。三甲医院每年出院病历千万级的文本量等着结构化，开发者要么用闭源方案要么从头训，两条路成本都不低，尤其从头训标注数据就是超级大坑。如果后续加了中文支持，价值立刻不一样，毕竟国内电子病历体量摆在那里，却说没有对应的开源基建，这事本身就真的挺讽刺的。还有一些事得提前知道，OpenMed只做文本结构化和脱敏，临床决策和辅助诊断不在范围内，拿着工具怎么搭上层应用是你的事，别期待它帮你做诊断。
Issues里有人贴了自家医院的测试数据，也有人在加新的PII语种规则，社区在动。上周还有人提了个PR加了一种新的脱敏策略，虽然还没合进去但是方向是对的在往实用性走。Maziyar Panahi在Hugging Face上积累了不少医疗微调模型，OpenMed算是把这些年的碎片整合成了一个完整系统，调试和适配做得比预期好不少，至少我没碰到那种README写一行结果跑不起来还得自己猜依赖版本的情况。这类开源项目我特别怕的就是半成品感，拉下来一跑缺这缺那，OpenMed倒是少见地把从头到尾的流程跑通了，文档也跟得上，不是那种代码写完了文档还停留在TODO状态的项目。
301医院数据出境被查的事圈内传了好几年了，每次提医疗数据安全都有人拿这个当案例。去年还有一个更近的，某三甲医院用了一家SaaS做病历质控，结果发现质控平台把数据存在了境外服务器上，医院被卫健委约谈整改了三个月，过程中所有科研项目暂停数据调权限，影响面比预想的大得多。医生抵触数据上云这事我一直觉得不完全是因为不懂技术，被罚过才知道怕，这话可能说得直白，但事实就是这样。F1值多0.5个点在医院场景里真没那么重要，数据别泄露才是底线，OpenMed把文本处理从需要一个云服务变成了只需要一台电脑就够了。
来源
OpenMed GitHub 仓库 — github.com/maziyarpanahi/openmed
OpenMed NER 论文 — arXiv:2508.01630
OpenMed 官方文档 — openmed.life/docs
HIPAA Privacy Rule — U.S. Department of Health & Human Services
GDPR Article 9 — EUR-Lex, europa.eu
作者 AISet
