5,072· 637 forks· Python· Apache-2.0开源替代

OpenMed - 本地醫療 AI 去隱私化與臨床實體提取

maziyarpanahi/openmed

完全離線執行的醫療 AI 工具包,支援 2200+ 模型、21 語言的臨床 NER 與 HIPAA 隱私脫敏,資料不出本地網路

成熟度維護活躍,最近提交 0 天前,open issues 669 個,持續迭代中

GitHub 仓库 → HN 讨论 · 7 点对标:AWS Comprehend Medical、Google Healthcare API

项目体检

部署 · 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 識別符號檢測(姓名、日期、電話、醫保號等)與臨床實體提取(疾病、藥物、症狀),資料不離開你的伺服器或裝置。

為何火

  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 合規",部署方需自行驗證模型行為與臨床適用性。

選型對比

維度OpenMedAWS Comprehend MedicalGoogle 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 技術清單

安装方式:pip