OpenMed - 本地医疗 AI 去隐私化与临床实体提取

解决什么

医疗机构处理电子病历、出院小结、检验报告时,面临三大痛点:患者姓名、身份证号、地址等 PII(个人可识别信息)必须脱敏才能用于科研或 AI 训练,但传统方案要么依赖云端 API(数据出境风险),要么规则匹配准确率低。OpenMed 提供完全本地化的医疗 NLP 工具包,核心推理在本地硬件完成,支持 18 类 HIPAA 标识符检测(姓名、日期、电话、医保号等)与临床实体提取(疾病、药物、症状),数据不离开你的服务器或设备。

为何火

1. 隐私合规刚需:HIPAA、GDPR 等法规要求医疗数据不得随意上云,OpenMed 的 "Your Data. Your Model. Your Hardware." 理念直击痛点,5072 stars 反映医疗机构与研究者的真实需求。
2. 多端覆盖:除 Python 外,提供 Swift(OpenMedKit + MLX)、Android(ONNX Runtime Mobile)、浏览器(Transformers.js)原生支持,iPhone 演示中实时扫描病历并脱敏的效果极具冲击力。
3. 模型生态丰富:2200+ 预训练模型覆盖 21 语言,包括中文 PII 检测、临床 NER、疾病分类等,HuggingFace 托管的模型库降低了定制门槛。
4. Apache-2.0 协议:SDK 源码可商用,对比 AWS Comprehend Medical 等按 API 调用计费的云服务,长期成本更可控。

核心功能

• 临床实体识别(NER):从非结构化文本中提取疾病、药物、症状、检查项目等,示例中 disease_detection_superclinical 模型可识别 "chronic myeloid leukemia" 并标注置信度。
• PII 脱敏:Nemotron Privacy Filter 系列模型实时标记并替换姓名、地址、身份证号、账单信息等,支持 Safe Harbor 方法论的 18 类标识符。
• 多语言支持:内置 jieba(中文分词)、OpenCC(繁简转换),模型覆盖中文、日语、阿拉伯语等 21 种语言的 PII 检测。
• 多后端加速:Apple Silicon 用 MLX 可比 CPU PyTorch 快 24-33 倍(见 README 性能图),CUDA/ONNX/CoreML 按硬件自动选择。
• 服务化与批处理:提供 FastAPI 服务接口(默认 8080 端口)、MCP 协议服务(8081 端口)、命令行工具与 Dask 批处理支持。

安装

Python 环境(推荐 3.10+):

pip install openmed
# Apple Silicon 加速
pip install "openmed[mlx]"

Docker 部署:

# 克隆仓库后
docker compose up -d
# 访问 http://localhost:8080 使用 API

Swift(iOS/macOS): 在 Package.swift 中添加:

dependencies: [
    .package(url: "https://github.com/maziyarpanahi/openmed.git", from: "2.2.0")
]

Android:参考 docs/export-onnx-android.md,通过 JitPack 集成 OpenMedKit Kotlin 库。

首次运行注意:模型从 HuggingFace 下载(可能需梯子),设置 HF_TOKEN 环境变量可加速;下载后缓存到 ~/.cache/huggingface/openmed,之后完全离线。

适合谁

• 医疗机构 IT 部门:需要本地化部署 NLP 能力,满足 HIPAA/等保合规要求,避免患者数据上云。
• 医学研究团队:从电子病历中批量提取结构化数据(疾病、用药、检验值)用于回顾性研究,同时自动脱敏。
• 医疗 SaaS 开发者:集成到 PACS、HIS、EMR 系统中,提供智能标注、敏感信息检测等增值功能。
• 隐私敏感场景:法律、金融、政务等领域需要类似 PII 检测能力,但不限于医疗行业(模型需自行验证适配性)。

不适合:需要实时低延迟(<10ms)的在线诊断场景,或硬件资源极度受限的嵌入式设备(虽支持移动端,但模型体积仍需数百 MB)。

社区评价

暂无足量社区公开讨论,以下为基于项目本身的中立评估:

技术亮点:

• 多端适配策略务实,MLX 在 Apple Silicon 上的性能提升有实测数据支撑(24-33× CPU),Android ONNX Runtime Mobile 路径也提供完整导出工具链。
• 模型命名可移植(MLX 模型名在非 Apple 硬件自动回退到 PyTorch),降低跨平台开发成本。
• 提供 MCP(Model Context Protocol)服务接口,方便 AI Agent 调用,llms.txt 文档索引对 LLM 友好。

潜在争议:

• 669 个 open issues 显示项目快速迭代但问题积压较多,生产环境需评估稳定性。
• README 强调 "核心推理本地化",但模型下载、可选的远程适配器、遥测路径仍可能涉及网络,需逐项审查配置。
• "Safe Harbor-aligned" 表述谨慎,明确指出 "使用 SDK 本身不构成 HIPAA 合规",部署方需自行验证模型行为与临床适用性。

选型对比

维度	OpenMed	AWS Comprehend Medical	Google Healthcare API
部署方式	本地/私有云	云端 API	云端 API
数据出境	否(核心推理本地)	是	是
成本	硬件+模型验证	按请求计费($0.01/单位)	按请求计费
定制性	高(可微调模型)	低(预设类别)	中(可训练 AutoML)
多语言	21 语言(含中文)	主要英语	英语为主
许可	Apache-2.0(SDK)	商业闭源	商业闭源

取舍:云服务开箱即用、免运维,但长期成本高且数据必须上云;OpenMed 初期需投入模型验证与硬件配置,适合有合规硬约束或大规模批处理需求的场景。对比开源同类如 spaCy 的医疗扩展,OpenMed 的模型生态更聚焦医疗且提供移动端支持。

已知坑

1. 模型许可需逐个审查:SDK 是 Apache-2.0,但 HuggingFace 上的 2200+ 模型各有许可(如 CC-BY-NC 禁止商用),README 明确要求 "部署方验证模型与数据集条款"。
2. 首次下载体验:国内访问 HuggingFace 不稳定,建议配置镜像站或提前下载模型到 OPENMED_CACHE_DIR,否则首次运行可能卡住。
3. 中文分词依赖 jieba:对于罕见医学术语可能切分不准,影响下游 NER 效果,需根据业务语料自定义词典。
4. Safe Harbor 非自动合规:虽支持 18 类标识符检测,但 HIPAA 合规需人工审查脱敏效果、建立 BAA 协议、配置审计日志等,工具只是技术手段之一。
5. 资源占用:加载多个模型会占用数 GB 内存,Docker Compose 配置中 OPENMED_SERVICE_MAX_RESIDENT_MODELS 需根据硬件调整,避免 OOM。
6. MLX 限 Apple Silicon:M 系列芯片才能用 MLX 加速,Intel Mac 或其他平台回退到 CPU/CUDA,性能差异显著。
7. Android 模型格式:需手动导出 ONNX(参考 docs/export-onnx-android.md),官方仓库未预置所有模型的移动端版本,增加集成工作量。

来源: GitHub 仓库 + README + Docker Compose 配置 + pyproject.toml 技术清单