ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

OpenMed OpenMRS与DHIS2集成指南:非洲健康数据去标识化落地

OpenMed OpenMRS与DHIS2集成指南:非洲健康数据去标识化落地 OpenMed OpenMRS与DHIS2集成指南非洲健康数据去标识化落地【免费下载链接】openmedLocal-first healthcare AI: clinical NER HIPAA PII de-identification that runs 100% on-device. 2,200 medical models, 21 languages, Apple MLX Python, no cloud, no patient data leaving your network. Apache-2.0项目地址: https://gitcode.com/GitHub_Trending/ope/openmedOpenMed是一个本地优先的医疗 AI 开源项目专注临床命名实体识别Clinical NER与 HIPAA PII 去标识化100% 在设备端运行不经过云端、不让患者数据离开你的网络。本文将带你完成OpenMed 与 OpenMRS、DHIS2 的集成从机构本地 EMROpenMRS拉取病历在本地完成去标识化再导出可审查的 DHIS2 聚合/追踪器载荷实现非洲健康数据上报的隐私安全落地。为什么选择本地去标识化非洲许多医疗机构的网络不稳定、电力受限且南非 POPIA、尼日利亚 NDPA 等数据保护法规对健康数据有特殊要求。传统先把原始病历传到云端再脱敏的方案风险极高——原始 PHI受保护健康信息一旦离网就可能无法召回。OpenMed 的核心思路是去标识化发生在数据离网之前。OpenMRS 适配器和 DHIS2 导出器都运行在机构自己的机器上只有脱敏后的副本才能离开机构网络KenyaEMR / UgandaEMR机构局域网 ↓ REST 或 FHIR2 拉取 OpenMed 部署在机构机器上 拉取 → 去标识化 → 审查清单 ↓ 仅脱敏后的载荷 目标 OpenMRS / FHIR 事务 Bundle / NDJSON / DHIS2 聚合与追踪器整个流程不缓存原始载荷、不向日志写入原始 PHI且导入模块时不发起任何网络请求。官方对这条链路的完整说明见 docs/openmrs-adapter.md。整体数据流7 个阶段工件官方提供了一个完全合成、离线、可复现的参考实现虚构的 Mtoni 区3 家机构、50 名患者入口在 examples/africa-openmrs-dhis2/run_demo.py。运行一次会生成 7 个阶段工件每一道边界都有无 PHI 门禁阶段工件隐私边界101-raw-openmrs.json仅限机构内部的合成原始数据202-deidentified-fhir-bundle.json标准 FHIR 事务 Bundle303-openmrs-deidentification-manifest.json无 PHI 的路径与计数清单404-dhis2-aggregate.json泛化到区级的聚合导入体505-dhis2-tracker.json泛化到区级的追踪器导入体606-dhis2-export-manifest.json无 PHI 的转换摘要707-demo-manifest.json前 6 个文件的稳定哈希关键安全设计源码见 run_demo.py 的边界校验区级泛化任何机构级level-4orgUnit都会被替换为区级level-3祖先精确的geometry/latitude/longitude直接删除区级 UID 以外的一律失败关闭fail closed数据不出网。小单元抑制数值 ≤4 的聚合单元格自动剔除避免通过小样本反推个人。确定性输出相同种子与参数两次运行产出字节级一致的工件便于审计与回归测试。本地运行离线参考 Demo3 步无需 Java、Docker、凭据、模型下载或联网。只需在开发环境中安装 OpenMRS 附加依赖uv pip install openmed[openmrs]第 1 步生成合成数据集可单独预览输入形态python examples/africa-openmrs-dhis2/synthetic_data.py \ --seed 875 --patient-count 50 \ --output /tmp/openmed-africa-recording.json第 2 步运行完整流程python examples/africa-openmrs-dhis2/run_demo.py \ --output-dir /tmp/openmed-africa-reference \ --seed 875 --patient-count 50第 3 步审查 7 个工件。命令行只打印计数绝不打印载荷内容或种子标识符合成数据的边界约定见 fixtures/README.md。⚠️ 注意01-raw-openmrs.json故意保留了合成姓名、身份证号、GPS 坐标用于让你检查隐私边界的输入。切勿用真实患者数据替换它也绝不把它传到国家报告系统。如果你想在隔离实验室里体验真实 API 往返仓库附带了可选的live容器档案OpenMRS Reference Application DHIS2 Core仅绑定 127.0.0.1定义在 examples/africa-openmrs-dhis2/docker-compose.yml官方部署文档见 docs/deploy/africa-reference-deployment.md。对接真实 KenyaEMR / UgandaEMROpenMRS 适配器生产场景中适配器同时支持legacy REST API和FHIR2 R4 模块源码位于 openmed/interop/。典型流程配置连接在 base URL 中包含 OpenMRS 应用上下文常见为/openmrs使用最小权限服务账号凭据从密钥存储读取拉取资源先拉Patient、Encounter、Observation三类 FHIR2 资源保证 Bundle 内部引用都有目标去标识化每条结果附带 OperationOutcome 风格的已变换路径清单——审计时看路径计数而不是原文干跑写回先dry_runTrue审查 ID 与变换路径确认无泄漏后再执行真实写入。完整的环境变量驱动脚本可以直接参考 examples/openmrs_deid_handoff.py它演示了OPENMRS_BASE_URL、OPENMRS_PATIENT_UUID等配置项的用法以及拉取→导出 NDJSON→干跑写回的最小闭环。两条实用红线不要把患者姓名、电话、身份证号等直接标识符用作 Bundle 的doc_id——它会派生确定性 URL 并残留在运维元数据中TLS 校验保持开启生产环境安装机构 CA而不是关闭证书校验。DHIS2 导出地理、日期与小单元策略DHIS2 不接收任意 FHIR Bundle因此 OpenMed 的导出器是传输无关的读取本地 JSON 载荷 组织单元层级快照在内存中应用隐私策略返回确定性的 JSON策略实现位于 openmed/clinical/API 文档见 docs/dhis2-export.md。导出前必须按顺序完成 5 步将机构聚合/追踪器 JSON 导出到受保护的本地工作区导出/api/organisationUnits本地快照包含id、level、parent.id运行export_dhis2自由文本先经 HIPAA Safe Harbor 管线脱敏、精确地理删除、机构 UID 泛化为区级祖先、日期偏移或粗化、小单元抑制本地审查端点载荷与无值清单之后才把端点载荷交给机构既有的鉴权上传工具。命令行参考只写本地文件绝不上传python examples/dhis2_district_export.py \ --aggregate facility-aggregate.json \ --tracker facility-tracker.json \ --org-units organisation-units.json \ --output-dir deidentified-dhis2可调节的核心隐私旋钮配置项作用推荐值generalization_level机构 UID 泛化到的层级默认 3 区级先确认本地层级编号small_cell_threshold低于该值的聚合单元格被抑制5date_modeshift确定性偏移或coarsen粗化到月/年首日按数据用途选择period_granularity报告周期粗化粒度month或year清单manifest只含策略设置、计数与结构路径不包含注释、属性值、用户名、组织 UID 或被抑制的单元值——这正是审计审查的证据来源。合规映射从技术控制到法律审查OpenMed 的策略档位是技术控制不是法律认证。针对非洲部署官方给出了意图→策略映射详见 docs/africa-onboarding.md部署意图策略档位行为要点最保守的出口/接收方未知strict_no_leak直接标识符准标识符临床概念全部遮罩机构内授权诊疗流程clinical_minimal_redaction遮罩直接标识符保留多数日期/地点/临床概念已批准的研究/公卫数据集research_limited_dataset遮罩直接标识符需小单元与再识别风险评估健康数据假名化起点gdpr_art9_health可逆映射映射表必须独立受保护策略的真实定义在 openmed/core/policies/ 下的 JSON 中上线前务必逐字段审查动作而不是只看档位名。配套的国家级检查清单如 ke-dpa-identifier-checklist.md可作为字段级复核的起点。设施端硬件与上线清单 官方建议的机构边缘起点试点基线非生产保证独立 OpenMed 边缘节点4 核现代 CPU、8 GB 内存、加密 SSDEMR 与边缘节点合并部署8 核、16 GB、加密 SSD电力与网络UPS、测试过的关机流程、局域网运行、出站传输排队——保证断电或 WAN 中断时去标识化仍然可用。上线前逐项确认包与模型工件已锁定、传输并校验哈希断网目标机能成功运行本地语言与本地标识符格式的合成泄漏测试集通过含姓名、电话格式、地址、机构标识符、身份证号选定的策略动作已逐字段审查POPIA/NDPA 等法律审查已记录OpenMRS / DHIS2 映射在非生产环境验证过凭据最小权限且不进源码库日志、追踪、错误与审计导出中确认无原始 PHI。小结OpenMed 把去标识化从云端后置改成了设施边缘的前置门禁OpenMRS 适配器负责拉取与写回DHIS2 导出器负责地理泛化与小单元抑制中间每一道边界都有无 PHI 清单与失败关闭机制。从离线参考 Demo 到真实 KenyaEMR/UgandaEMR 接入整条链路都可以先在本地、用合成数据完整演练一遍再逐步走向生产。延伸阅读OpenMRS 适配器详解docs/openmrs-adapter.mdDHIS2 去标识化导出docs/dhis2-export.md非洲开发者入门低带宽安装、模型预取docs/africa-onboarding.md参考部署与安全清单docs/deploy/africa-reference-deployment.md示例代码目录examples/africa-openmrs-dhis2/【免费下载链接】openmedLocal-first healthcare AI: clinical NER HIPAA PII de-identification that runs 100% on-device. 2,200 medical models, 21 languages, Apple MLX Python, no cloud, no patient data leaving your network. Apache-2.0项目地址: https://gitcode.com/GitHub_Trending/ope/openmed创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表