引言“临床数据永不离开设备。”这是每日一个开源项目系列的第129篇文章。今天的主角是OpenMed——一个本地优先的医疗 AI 库由 HuggingFace 研究员 Maziyar Panahi 开发专门解决医疗场景下的隐私问题。医疗 AI 的现状绝大多数工具需要把患者数据发送到云端换回结构化结果。这在合规层面是个持续的风险点——HIPAA、GDPR、各国的数据保护法规对患者数据的处理方式有明确约束而数据上云本身就已经触碰了很多医疗机构的红线。OpenMed 的设计方向是把处理能力搬到本地1000 多个生物医学 NLP 模型全部在设备上跑不发出任何网络请求支持从 Python 服务到 iOS App 的多种部署场景。你将学到什么OpenMed 的核心架构为什么选择编码器 Transformer而非生成式模型13 个临床 NLP 域从疾病到基因组的 NER 覆盖PII 脱敏的工程设计如何覆盖全部 18 个 HIPAA Safe Harbor 标识符多平台支持Python/MLX、Swift/OpenMedKit、Docker/FastAPIv1.2.0 引入的零样本能力ZeroShot NER 和关系抽取在 Apple Silicon 上的性能表现前置知识了解基本的 NLP 概念命名实体识别、Transformer有 Python 使用经验对医疗数据隐私合规有基本了解HIPAA、数据脱敏的背景项目背景项目简介OpenMed 是一套本地优先的医疗 AI 工具库定位是把临床文本变成结构化洞察且数据全程不离开安全环境。它的核心不是生成式 AI而是用编码器 TransformerBERT、ELECTRA、DeBERTa 系列做提取和分类。这个技术选型背后有具体原因医疗场景里最常见的任务是从文本里找到什么而不是生成新的文本——识别病名、提取药物、定位患者 ID这些任务用分类模型做更精准、更可控、也更容易审计。arXiv 论文2508.01630报告在 12 个生物医学 NER 基准测试中 10 个达到 SOTA。作者/团队介绍作者: Maziyar Panahi背景: HuggingFace 研究员生物医学 NLP 领域SpaCy 和 HuggingFace Transformers 社区贡献者License: Apache-2.0最新版本: v1.5.52026年6月项目数据⭐ GitHub Stars:2,800 Forks: 274 HuggingFace 模型: 1,000 支持语言: 12 种 License: Apache-2.0主要功能核心作用OpenMed 的工作流很直接临床文本输入 ↓ 本地模型推理BERT/ELECTRA/DeBERTa ↓ ┌─────────────────────────────────┐ │ NER识别疾病、药物、基因等实体 │ │ PII 脱敏检测并处理患者标识符 │ │ 关系抽取实体间的语义关系 │ └─────────────────────────────────┘ ↓ 结构化输出数据全程不离开本地使用场景临床文本结构化从病历、出院记录中抽取疾病名称、药物、解剖位置支持 13 个生物医学 NER 域化学品、疾病、基因、蛋白质、物种、解剖、肿瘤学等患者数据脱敏覆盖全部 18 个 HIPAA Safe Harbor 标识符支持遮蔽[NAME]、替换Faker 合成假数据、哈希、日期偏移四种处理方式iOS/macOS 医疗 App 开发OpenMedKit Swift 包提供原生接口PHI 数据不离开设备v1.2.0 内置的 iOS Scan Demo扫描 → OCR 审查 → 脱敏 → 临床抽取 → 导出五步完整工作流企业级医疗系统集成Docker/FastAPI REST API方便嵌入现有工作流AWS SageMaker Marketplace 托管版本sub-100ms 延迟端点快速开始安装# CPU 版本pipinstallopenmed# Apple SiliconMLX 加速pipinstallopenmed[mlx]# CUDA GPUpipinstallopenmed[cuda]基础 NERfromopenmedimportanalyze_text# 疾病识别resultanalyze_text(Patient started on imatinib for CML.,model_namedisease_detection_superclinical)# 输出{entities: [{text: CML, label: DISEASE, start: 30, end: 33}], ...}# 药物识别resultanalyze_text(Prescribed metformin 500mg twice daily for type 2 diabetes.,model_namepharma_detection_superclinical)PII 脱敏fromopenmedimportdeidentify textPatient John Smith (DOB: 1985-03-15, SSN: 123-45-6789) was admitted...# 遮蔽模式resultdeidentify(text,methodmask)# Patient [NAME] (DOB: [DATE], SSN: [SSN]) was admitted...# Faker 替换保持文本可读性同时完全匿名化resultdeidentify(text,methodreplace)# Patient Michael Johnson (DOB: 1972-08-22, SSN: 987-65-4321) was admitted...批量处理fromopenmedimportBatchProcessor texts[record1,record2,record3,...]processorBatchProcessor(operationextract_pii,model_namepii_superclinical_large,on_progresslambdap:print(f{p:.0%}complete))resultsprocessor.run(texts)Swift/iOSimportOpenMedKitletanalyzerOpenMedNER(model:.diseaseDetectionSuperClinical)letresulttryawaitanalyzer.analyze(Patient presents with hypertension and T2DM)// result.entities: [{text: hypertension, label: DISEASE}, {text: T2DM, label: DISEASE}]支持的 NER 模型模型检测域参数量HuggingFace 下载量disease_detection_superclinical疾病/症状434M104Kpharma_detection_superclinical药物/化合物434M—pii_superclinical_largePII 标识符434M—chemical_detection_electramed化学品33M117Kanatomy_detection_electramed解剖部位109M—genomic_detection_pubmed基因/基因组109M103Koncology_detection_multimed肿瘤学实体568M102K项目详细剖析架构设计为什么是编码器不是生成式 LLM这是 OpenMed 最值得关注的技术选择。生成式 LLMGPT-4、Claude 等在医疗文本问题上有一个根本性的问题输出不可控。让生成式模型做 PII 检测它可能会在某些情况下把患者姓名生成到输出里或者幻觉出不存在的药物名称。OpenMed 选择编码器 Transformer 做命名实体识别本质上是一个分类问题对每个 token 判断它属于什么类别。这类模型输出是确定性的给定输入输出固定不会幻觉只做分类不生成新 token参数量小33M-568M本地推理可行可以精确审计每个实体都有来源位置对医疗场景来说这些特性比能生成流畅文本重要得多。Privacy Filter 架构OpenMed 的 PII 检测不只是跑一个 NER 模型还有几层工程处理上下文感知检测在实体前后 100 个字符范围内做关键词增强。SSN:后面跟着数字序列置信度比单纯的数字序列高得多。校验和验证减少误报。美国社保号SSN格式验证印度 AadhaarVerhoeff 校验算法巴西 CPF/CNPJLuhn 校验意大利 Codice Fiscale格式 字母校验德国 Steuer-ID格式验证Smart Entity Merging解决子词分词器的分片问题。BERT 类模型会把 “O’Brien” 切成 [“O”, “”, “Brien”]实体合并逻辑把这些片段重新拼回完整实体避免输出残缺的 PII 检测结果。三种 Privacy Filter 变体基础版通用 PII 检测Nemotron 微调版更高精度多语言版v1.4.0支持 16 种语言的统一模型多平台运行时┌─────────────────────────────────────────────────┐ │ OpenMed 运行时 │ ├──────────────┬──────────────┬───────────────────┤ │ Python/MLX │ Swift │ Docker/FastAPI │ │ │ OpenMedKit │ │ │ • CPU │ • macOS │ • REST API │ │ • CUDA │ • iOS │ • 批量处理端点 │ │ • Apple MLX │ • iPadOS │ • 模型生命周期管理│ │ │ │ /models/loaded │ │ 24-33x │ PHI 不离 │ /models/unload │ │ vs CPU PyTorch│ 开设备 │ keep_alive 控制 │ └──────────────┴──────────────┴───────────────────┘ ↑ ↑ 共享 MLX 模型文件含 8-bit 量化版Swift 和 Python 路径共享同一套 MLX 模型文件这意味着同一个医院系统可以用 Python 服务跑服务端推理同时用 OpenMedKit 在 iPad 上跑本地推理模型文件不需要维护两套。零样本能力v1.2.0v1.2.0 版本引入了零样本接口不再要求用预定义的实体类别fromopenmedimportzero_shot_ner# 不用预训练的医疗 NER 模型用自定义的类别标签resultzero_shot_ner(textThe patients creatinine level was 2.3 mg/dL, suggesting CKD.,labels[LAB_VALUE,UNIT,CONDITION])# 能识别 2.3 mg/dL 为 LAB_VALUECKD 为 CONDITIONfromopenmedimportextract_relations# 抽取实体间的语义关系relationsextract_relations(textMetformin was prescribed for type 2 diabetes.,entity_pairs[(DRUG,DISEASE)])# [{drug: Metformin, relation: prescribed_for, disease: type 2 diabetes}]对于不在预定义 NER 模型覆盖范围内的临床实体零样本接口提供了一个灵活的出口。微调设计OpenMed 的模型训练用了领域自适应预训练DAPT加 LoRA 微调预训练数据350K 段落的生物医学语料库LoRA 微调只更新不到 1.5% 的参数训练时间单块 GPU12 小时内完成碳排放整个训练过程低于 1.2 kg CO₂e这个数据对想在自己数据集上微调的用户有参考意义不需要多卡集群一块消费级 GPU 加几个小时就能完成。版本演进版本时间核心变化v0.x2025年下半年初期开发基础 NERv1.0.02026年4月首个稳定版MLX 后端Swift 包v1.2.02026年4月零样本 NER/分类/关系抽取iOS Scan Demov1.4.02026年5月多语言 Privacy Filter16 种语言v1.5.02026年5月阿拉伯语/日语/土耳其语 PII247 个模型v1.5.22026年5月安全加固trust_remote_code 默认 Falsev1.5.52026年6月批量 PIIREST 生命周期管理13 个 README 翻译项目地址与资源官方资源GitHub: maziyarpanahi/openmed入门教程: maziyarpanahi/openmed-starter官网: openmed.lifeAgent 工具预览: agent.openmed.life论文: arXiv:2508.01630☁️AWS SageMaker: Marketplace 托管版本参考标准HIPAA Safe Harbor18 个患者标识符OWASP 医疗数据安全STRIDE 威胁建模Privacy Filter 安全设计总结OpenMed 解决的问题有明确的边界医疗 NLP且数据不能离开本地。这个约束在很多行业是选择在医疗行业经常是法规要求。OpenMed 把解法做成了库——编码器模型做分类、MLX 做本地加速、Swift 包做移动端原生集成、校验和逻辑减少误报、Smart Entity Merging 处理分词碎片。每一层都在处理医疗场景里真实存在的工程问题。对于在做医疗 AI 应用的开发者或者在研究临床文本处理的研究者OpenMed 是目前开源生态里覆盖最全的本地化方案之一。即使不是医疗场景它的 PII 脱敏能力和多语言支持在金融、法律等同样有数据敏感性要求的领域也有直接的参考价值。探索 PrimeSkills —— 精选 AI Agent 与技能的市场每一个都经过真实企业工作流验证去掉浮夸留下真正有用的。欢迎访问我的个人主页发现更多有价值的见解和有趣的产品。
每日一个开源项目（第129篇）：OpenMed - 永不离开设备的医疗 NLP
引言“临床数据永不离开设备。”这是每日一个开源项目系列的第129篇文章。今天的主角是OpenMed——一个本地优先的医疗 AI 库由 HuggingFace 研究员 Maziyar Panahi 开发专门解决医疗场景下的隐私问题。医疗 AI 的现状绝大多数工具需要把患者数据发送到云端换回结构化结果。这在合规层面是个持续的风险点——HIPAA、GDPR、各国的数据保护法规对患者数据的处理方式有明确约束而数据上云本身就已经触碰了很多医疗机构的红线。OpenMed 的设计方向是把处理能力搬到本地1000 多个生物医学 NLP 模型全部在设备上跑不发出任何网络请求支持从 Python 服务到 iOS App 的多种部署场景。你将学到什么OpenMed 的核心架构为什么选择编码器 Transformer而非生成式模型13 个临床 NLP 域从疾病到基因组的 NER 覆盖PII 脱敏的工程设计如何覆盖全部 18 个 HIPAA Safe Harbor 标识符多平台支持Python/MLX、Swift/OpenMedKit、Docker/FastAPIv1.2.0 引入的零样本能力ZeroShot NER 和关系抽取在 Apple Silicon 上的性能表现前置知识了解基本的 NLP 概念命名实体识别、Transformer有 Python 使用经验对医疗数据隐私合规有基本了解HIPAA、数据脱敏的背景项目背景项目简介OpenMed 是一套本地优先的医疗 AI 工具库定位是把临床文本变成结构化洞察且数据全程不离开安全环境。它的核心不是生成式 AI而是用编码器 TransformerBERT、ELECTRA、DeBERTa 系列做提取和分类。这个技术选型背后有具体原因医疗场景里最常见的任务是从文本里找到什么而不是生成新的文本——识别病名、提取药物、定位患者 ID这些任务用分类模型做更精准、更可控、也更容易审计。arXiv 论文2508.01630报告在 12 个生物医学 NER 基准测试中 10 个达到 SOTA。作者/团队介绍作者: Maziyar Panahi背景: HuggingFace 研究员生物医学 NLP 领域SpaCy 和 HuggingFace Transformers 社区贡献者License: Apache-2.0最新版本: v1.5.52026年6月项目数据⭐ GitHub Stars:2,800 Forks: 274 HuggingFace 模型: 1,000 支持语言: 12 种 License: Apache-2.0主要功能核心作用OpenMed 的工作流很直接临床文本输入 ↓ 本地模型推理BERT/ELECTRA/DeBERTa ↓ ┌─────────────────────────────────┐ │ NER识别疾病、药物、基因等实体 │ │ PII 脱敏检测并处理患者标识符 │ │ 关系抽取实体间的语义关系 │ └─────────────────────────────────┘ ↓ 结构化输出数据全程不离开本地使用场景临床文本结构化从病历、出院记录中抽取疾病名称、药物、解剖位置支持 13 个生物医学 NER 域化学品、疾病、基因、蛋白质、物种、解剖、肿瘤学等患者数据脱敏覆盖全部 18 个 HIPAA Safe Harbor 标识符支持遮蔽[NAME]、替换Faker 合成假数据、哈希、日期偏移四种处理方式iOS/macOS 医疗 App 开发OpenMedKit Swift 包提供原生接口PHI 数据不离开设备v1.2.0 内置的 iOS Scan Demo扫描 → OCR 审查 → 脱敏 → 临床抽取 → 导出五步完整工作流企业级医疗系统集成Docker/FastAPI REST API方便嵌入现有工作流AWS SageMaker Marketplace 托管版本sub-100ms 延迟端点快速开始安装# CPU 版本pipinstallopenmed# Apple SiliconMLX 加速pipinstallopenmed[mlx]# CUDA GPUpipinstallopenmed[cuda]基础 NERfromopenmedimportanalyze_text# 疾病识别resultanalyze_text(Patient started on imatinib for CML.,model_namedisease_detection_superclinical)# 输出{entities: [{text: CML, label: DISEASE, start: 30, end: 33}], ...}# 药物识别resultanalyze_text(Prescribed metformin 500mg twice daily for type 2 diabetes.,model_namepharma_detection_superclinical)PII 脱敏fromopenmedimportdeidentify textPatient John Smith (DOB: 1985-03-15, SSN: 123-45-6789) was admitted...# 遮蔽模式resultdeidentify(text,methodmask)# Patient [NAME] (DOB: [DATE], SSN: [SSN]) was admitted...# Faker 替换保持文本可读性同时完全匿名化resultdeidentify(text,methodreplace)# Patient Michael Johnson (DOB: 1972-08-22, SSN: 987-65-4321) was admitted...批量处理fromopenmedimportBatchProcessor texts[record1,record2,record3,...]processorBatchProcessor(operationextract_pii,model_namepii_superclinical_large,on_progresslambdap:print(f{p:.0%}complete))resultsprocessor.run(texts)Swift/iOSimportOpenMedKitletanalyzerOpenMedNER(model:.diseaseDetectionSuperClinical)letresulttryawaitanalyzer.analyze(Patient presents with hypertension and T2DM)// result.entities: [{text: hypertension, label: DISEASE}, {text: T2DM, label: DISEASE}]支持的 NER 模型模型检测域参数量HuggingFace 下载量disease_detection_superclinical疾病/症状434M104Kpharma_detection_superclinical药物/化合物434M—pii_superclinical_largePII 标识符434M—chemical_detection_electramed化学品33M117Kanatomy_detection_electramed解剖部位109M—genomic_detection_pubmed基因/基因组109M103Koncology_detection_multimed肿瘤学实体568M102K项目详细剖析架构设计为什么是编码器不是生成式 LLM这是 OpenMed 最值得关注的技术选择。生成式 LLMGPT-4、Claude 等在医疗文本问题上有一个根本性的问题输出不可控。让生成式模型做 PII 检测它可能会在某些情况下把患者姓名生成到输出里或者幻觉出不存在的药物名称。OpenMed 选择编码器 Transformer 做命名实体识别本质上是一个分类问题对每个 token 判断它属于什么类别。这类模型输出是确定性的给定输入输出固定不会幻觉只做分类不生成新 token参数量小33M-568M本地推理可行可以精确审计每个实体都有来源位置对医疗场景来说这些特性比能生成流畅文本重要得多。Privacy Filter 架构OpenMed 的 PII 检测不只是跑一个 NER 模型还有几层工程处理上下文感知检测在实体前后 100 个字符范围内做关键词增强。SSN:后面跟着数字序列置信度比单纯的数字序列高得多。校验和验证减少误报。美国社保号SSN格式验证印度 AadhaarVerhoeff 校验算法巴西 CPF/CNPJLuhn 校验意大利 Codice Fiscale格式 字母校验德国 Steuer-ID格式验证Smart Entity Merging解决子词分词器的分片问题。BERT 类模型会把 “O’Brien” 切成 [“O”, “”, “Brien”]实体合并逻辑把这些片段重新拼回完整实体避免输出残缺的 PII 检测结果。三种 Privacy Filter 变体基础版通用 PII 检测Nemotron 微调版更高精度多语言版v1.4.0支持 16 种语言的统一模型多平台运行时┌─────────────────────────────────────────────────┐ │ OpenMed 运行时 │ ├──────────────┬──────────────┬───────────────────┤ │ Python/MLX │ Swift │ Docker/FastAPI │ │ │ OpenMedKit │ │ │ • CPU │ • macOS │ • REST API │ │ • CUDA │ • iOS │ • 批量处理端点 │ │ • Apple MLX │ • iPadOS │ • 模型生命周期管理│ │ │ │ /models/loaded │ │ 24-33x │ PHI 不离 │ /models/unload │ │ vs CPU PyTorch│ 开设备 │ keep_alive 控制 │ └──────────────┴──────────────┴───────────────────┘ ↑ ↑ 共享 MLX 模型文件含 8-bit 量化版Swift 和 Python 路径共享同一套 MLX 模型文件这意味着同一个医院系统可以用 Python 服务跑服务端推理同时用 OpenMedKit 在 iPad 上跑本地推理模型文件不需要维护两套。零样本能力v1.2.0v1.2.0 版本引入了零样本接口不再要求用预定义的实体类别fromopenmedimportzero_shot_ner# 不用预训练的医疗 NER 模型用自定义的类别标签resultzero_shot_ner(textThe patients creatinine level was 2.3 mg/dL, suggesting CKD.,labels[LAB_VALUE,UNIT,CONDITION])# 能识别 2.3 mg/dL 为 LAB_VALUECKD 为 CONDITIONfromopenmedimportextract_relations# 抽取实体间的语义关系relationsextract_relations(textMetformin was prescribed for type 2 diabetes.,entity_pairs[(DRUG,DISEASE)])# [{drug: Metformin, relation: prescribed_for, disease: type 2 diabetes}]对于不在预定义 NER 模型覆盖范围内的临床实体零样本接口提供了一个灵活的出口。微调设计OpenMed 的模型训练用了领域自适应预训练DAPT加 LoRA 微调预训练数据350K 段落的生物医学语料库LoRA 微调只更新不到 1.5% 的参数训练时间单块 GPU12 小时内完成碳排放整个训练过程低于 1.2 kg CO₂e这个数据对想在自己数据集上微调的用户有参考意义不需要多卡集群一块消费级 GPU 加几个小时就能完成。版本演进版本时间核心变化v0.x2025年下半年初期开发基础 NERv1.0.02026年4月首个稳定版MLX 后端Swift 包v1.2.02026年4月零样本 NER/分类/关系抽取iOS Scan Demov1.4.02026年5月多语言 Privacy Filter16 种语言v1.5.02026年5月阿拉伯语/日语/土耳其语 PII247 个模型v1.5.22026年5月安全加固trust_remote_code 默认 Falsev1.5.52026年6月批量 PIIREST 生命周期管理13 个 README 翻译项目地址与资源官方资源GitHub: maziyarpanahi/openmed入门教程: maziyarpanahi/openmed-starter官网: openmed.lifeAgent 工具预览: agent.openmed.life论文: arXiv:2508.01630☁️AWS SageMaker: Marketplace 托管版本参考标准HIPAA Safe Harbor18 个患者标识符OWASP 医疗数据安全STRIDE 威胁建模Privacy Filter 安全设计总结OpenMed 解决的问题有明确的边界医疗 NLP且数据不能离开本地。这个约束在很多行业是选择在医疗行业经常是法规要求。OpenMed 把解法做成了库——编码器模型做分类、MLX 做本地加速、Swift 包做移动端原生集成、校验和逻辑减少误报、Smart Entity Merging 处理分词碎片。每一层都在处理医疗场景里真实存在的工程问题。对于在做医疗 AI 应用的开发者或者在研究临床文本处理的研究者OpenMed 是目前开源生态里覆盖最全的本地化方案之一。即使不是医疗场景它的 PII 脱敏能力和多语言支持在金融、法律等同样有数据敏感性要求的领域也有直接的参考价值。探索 PrimeSkills —— 精选 AI Agent 与技能的市场每一个都经过真实企业工作流验证去掉浮夸留下真正有用的。欢迎访问我的个人主页发现更多有价值的见解和有趣的产品。
