OpenMed - 本地醫療 AI 去隱私化與臨床實體提取
maziyarpanahi/openmed
完全離線執行的醫療 AI 工具包,支援 2200+ 模型、21 語言的臨床 NER 與 HIPAA 隱私脫敏,資料不出本地網路
成熟度:維護活躍,最近提交 0 天前,open issues 669 個,持續迭代中
项目体检
部署 · Docker Compose 一键启动,包含 app(8080) 和 MCP 服务(8081),需挂载 HuggingFace 缓存卷,可选 HF_TOKEN 环境变量加速模型下载
成本 · 核心离线运行,首次需从 HuggingFace 下载模型(可选 HF_TOKEN),支持 CPU/CUDA/MLX/ONNX 多后端,无强制外部服务依赖
技术 · Python 3.10+,基于 Hatchling 构建,可选 Swift(OpenMedKit)、Kotlin(Android)、Transformers.js(浏览器),支持 FastAPI 服务化
许可 · Apache-2.0 协议,SDK 源码可商用,但各模型与数据集许可需单独审查
活跃 · 最新 release v2.1.0 于 2026-08-12 发布,70 位贡献者,最近提交 0 天前,活跃开发中
解決什麼
醫療機構處理電子病歷、出院小結、檢驗報告時,面臨三大痛點:患者姓名、身份證號、地址等 PII(個人可識別資訊)必須脫敏才能用於科研或 AI 訓練,但傳統方案要麼依賴雲端 API(資料出境風險),要麼規則匹配準確率低。OpenMed 提供完全本地化的醫療 NLP 工具包,核心推理在本地硬體完成,支援 18 類 HIPAA 識別符號檢測(姓名、日期、電話、醫保號等)與臨床實體提取(疾病、藥物、症狀),資料不離開你的伺服器或裝置。
為何火
- 隱私合規剛需:HIPAA、GDPR 等法規要求醫療資料不得隨意上雲,OpenMed 的 "Your Data. Your Model. Your Hardware." 理念直擊痛點,5072 stars 反映醫療機構與研究者的真實需求。
- 多端覆蓋:除 Python 外,提供 Swift(OpenMedKit + MLX)、Android(ONNX Runtime Mobile)、瀏覽器(Transformers.js)原生支援,iPhone 演示中即時掃描病歷並脫敏的效果極具衝擊力。
- 模型生態豐富:2200+ 預訓練模型覆蓋 21 語言,包括中文 PII 檢測、臨床 NER、疾病分類等,HuggingFace 託管的模型庫降低了定製門檻。
- 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 的模型生態更聚焦醫療且提供移動端支援。
已知坑
- 模型許可需逐個審查:SDK 是 Apache-2.0,但 HuggingFace 上的 2200+ 模型各有許可(如 CC-BY-NC 禁止商用),README 明確要求 "部署方驗證模型與資料集條款"。
- 首次下載體驗:國內訪問 HuggingFace 不穩定,建議配置映象站或提前下載模型到
OPENMED_CACHE_DIR,否則首次執行可能卡住。 - 中文分詞依賴 jieba:對於罕見醫學術語可能切分不準,影響下游 NER 效果,需根據業務語料自定義詞典。
- Safe Harbor 非自動合規:雖支援 18 類識別符號檢測,但 HIPAA 合規需人工審查脫敏效果、建立 BAA 協議、配置審計日誌等,工具只是技術手段之一。
- 資源佔用:載入多個模型會佔用數 GB 記憶體,Docker Compose 配置中
OPENMED_SERVICE_MAX_RESIDENT_MODELS需根據硬體調整,避免 OOM。 - MLX 限 Apple Silicon:M 系列晶片才能用 MLX 加速,Intel Mac 或其他平臺回退到 CPU/CUDA,效能差異顯著。
- Android 模型格式:需手動匯出 ONNX(參考
docs/export-onnx-android.md),官方倉庫未預置所有模型的移動端版本,增加整合工作量。
來源: GitHub 倉庫 + README + Docker Compose 配置 + pyproject.toml 技術清單
安装方式:pip