OpenMed HIPAA 合规检查清单实战指南逐项对照 45 CFR Part 164 安全与隐私规则【免费下载链接】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本指南以 OpenMed 仓库中 checking-hipaa-compliance 技能 及其 HIPAA safeguards checklist45 CFR Part 164 为核心面向任何计划在真实受保护健康信息PHI上部署数据处理管线的团队。你将掌握如何按行政、物理、技术三大保障组逐项自评合规状态理解 Safe Harbor 与 Expert Determination 两条不再是 PHI的法定路径并学会用 OpenMed 的deidentify(policyhipaa_safe_harbor)与带 HMAC 签名的AuditReport落地去标识化与审计控制最终产出一份可交给隐私官Privacy/Security Officer的差距报告gap report。清单是什么控制项、R/A 语义与使用边界这份清单是一份控制项级control-by-control自评工具覆盖 HIPAA 安全规则Security Rule45 CFR Part 164 Subpart C与隐私规则Privacy Rule45 CFR Part 164 Subpart E对处理 PHI 的管线提出的全部要求。每一行都给出控制编号如 A1、T3、V2便于在差距报告中引用控制内容如风险分析、审计控制、最小必要法规条文引用如 164.308(a)(1)(ii)(A)供审计时回溯R/A 标记R Required必须实施A Addressable必须实施、采用等效替代方案、或书面记录为何不合理——绝不是可选Met?是否满足自评勾选列OpenMed fit列标注 OpenMed 在何处满足或支撑该控制。清单在仓库中的位置是 skills/checking-hipaa-compliance/references/hipaa-checklist.md其配套的 SKILL.md 则给出了从映射数据流到输出差距报告的完整工作流。需要特别强调边界这是自评辅助工具self-assessment aid不是法律意见。最终合规判定由机构的隐私官/安全官做出若走 Expert Determination 路径还需合格统计师qualified statistician签字。本文及清单只能帮助你系统化地收集证据、识别缺口。一、行政保障Administrative Safeguards— 45 CFR 164.308行政保障关注组织层面的安全管理过程、人员职责与制度。完整清单如下#控制引用R/AMet?OpenMed fitA1安全管理流程执行准确、彻底的风险分析164.308(a)(1)(ii)(A)R☐去标识化步骤不引入外部处理方on-deviceA2风险管理——将风险降至合理水平164.308(a)(1)(ii)(B)R☐尽早去标识化缩小 PHI 暴露面A3针对员工违规的制裁政策164.308(a)(1)(ii)(C)R☐—A4信息系统活动审查审计日志审阅164.308(a)(1)(ii)(D)R☐带签名的AuditReport供审查使用A5指定安全责任明确 Security Official164.308(a)(2)R☐—A6员工授权/监督/权限审查164.308(a)(3)A☐—A7信息访问管理——隔离、授权、调整访问164.308(a)(4)R/A☐对去标识化输出实施 RBACA8安全意识与培训提醒、恶意软件、登录、口令164.308(a)(5)A☐—A9安全事件处置程序——识别、响应、上报164.308(a)(6)R☐—A10应急计划——备份、灾难恢复、应急模式、演练164.308(a)(7)R/A☐—A11评估——定期技术与非技术审查164.308(a)(8)R☐变更后重跑本清单A12与每个接触 PHI 的供应商签订业务伙伴协议BAA164.308(b)(1), 164.314(a)R☐端侧 NLP 无需新增 BAA其中A12BAA与 OpenMed 的local-first定位直接相关OpenMed 的 NLP 去标识化完全在设备端/本地运行不把文本发送给第三方云模型因此在数据流映射中这一步不会引入新的业务伙伴business associate也就无需为该环节新增 BAA。这一点同时被 A1无外部处理方与 A2缩小 PHI 暴露面两条控制引用是 OpenMed 管线在合规审查中的明显加分项但前提是你能在数据流图中证明没有任何第三方含云存储、LLM API接触原始 PHI。二、物理保障Physical Safeguards— 45 CFR 164.310物理保障关注设施、工作站与设备的实体安全#控制引用R/AMet?OpenMed fitP1设施访问控制——应急、安全计划、验证164.310(a)A☐—P2工作站使用政策规定适当用途/方式164.310(b)R☐—P3工作站安全访问的物理防护164.310(c)R☐—P4设备与介质控制——处置、复用、责任清单、备份164.310(d)R/A☐擦除曾承载 PHI 的模型缓存P4 是最容易被忽略的一项OpenMed 在本地加载模型、缓存中间结果若缓存目录或临时文件曾接触原始文本它们在物理层面与 PHI 同等对待。仓库中 openmed/core/model_cache_policy.py 定义了模型缓存策略openmed/core/deletion_verify.py 提供了删除验证逻辑可用于支撑处置后不可恢复的证据链。处置与复用设备前务必执行缓存清理与验证。三、技术保障Technical Safeguards— 45 CFR 164.312技术保障是 OpenMed 参与最深的一组也是与代码证据结合最紧密的部分#控制引用R/AMet?OpenMed fitT1访问控制——唯一用户 ID、紧急访问、自动登出164.312(a)(1)R/A☐—T2静态加密/解密164.312(a)(2)(iv)A☐加密去标识化输出及任何映射关系T3审计控制——记录并检查系统活动164.312(b)R☐带签名AuditReportauditTrue记录每次脱敏T4完整性——防止 PHI 被不当篡改/销毁164.312(c)R/A☐AuditReport.verify() 防篡改证据HMACT5个人/实体身份认证164.312(d)R☐—T6传输安全——完整性控制 传输中加密164.312(e)R/A☐任何导出走 TLS仅经 HTTPS 访问 OpenFDA 等外部服务T3/T4 的源码级支撑签名审计报告技术保障的核心落地是 OpenMed 的审计报告机制实现在 openmed/core/audit.py 中AuditReport类第 981 行起包含policy、spans、residual_risk、openmed_version、input_hash、deidentified_text_hash、repro_hash等字段是本次去标识化运行发生了什么的完整、确定性记录。签名算法为 HMAC-SHA256文件头部定义了_SIGNATURE_ALGORITHM HMAC-SHA256并要求non-empty HMAC release key才能签名/验签_MISSING_KEY_ERROR。sign()与verify()方法第 1213/1232 行即对应清单 T3/T4 行的AuditReport.sign()/AuditReport.verify()。PHI-free 保障审计报告在序列化前经过消毒处理_AUDIT_RAW_VALUE_KEYS中列出的原始值字段original_text、value、surface、replacement、raw等不会进入报告报告只保留偏移量、类别、动作与哈希。这意味着你可以把签名报告直接放进合规文件柜或日志系统而无需担心它本身泄露 PHI。可复现哈希span 按(start, end, canonical_label, action)稳定排序后再计算repro_hash两次逻辑相同的运行产出完全一致的哈希供审计回溯与复现核验。T2 的配套输出加密与映射保管hipaa_safe_harbor策略默认keep_mapping: false、reversible_id: false见 openmed/core/policies/hipaa_safe_harbor.json即去标识化过程不保留可逆映射。若你的场景确实需要保留映射例如有限数据集场景该映射文件必须按 T2 要求加密存放——它本身是 PHI 级别的敏感物。四、隐私规则控制Privacy Rule— 45 CFR Part 164 Subpart E#控制引用Met?OpenMed fitV1最小必要——将 PHI 限制在与目的相符的范围164.502(b), 164.514(d)☐屏蔽任务不需要的字段V2去标识化——Safe Harbor18 项标识符或 Expert Determination164.514(a)–(c)☐deidentify(policyhipaa_safe_harbor)V3有限数据集Limited Data Set 数据使用协议若保留日期/ZIP164.514(e)☐仍属 PHI——适用不同控制V4使用与披露需经授权或属于允许情形164.502, 164.506, 164.508☐—V5披露会计记录Accounting of disclosures164.528☐审计轨迹支持记录V6泄露通知评估与义务164.400–414☐NIST 级加密可能避免触发通知两条不再是 PHI的法定路径HIPAA 承认两种去标识化方法45 CFR 164.514在差距报告中必须明确记录你选的是哪一条及理由Safe Harbor安全港——移除全部18 类标识符且无实际知识表明剩余数据可重新识别个体。确定性、可程序化验证是常见路径。Expert Determination专家判定——由合格统计师认证非常小的再识别风险。当必须保留部分准标识符如完整日期、乡镇级地理信息时使用。OpenMed 的deidentify(..., policyhipaa_safe_harbor)在端侧针对 Safe Harbor 标识符集合执行去标识化deidentify(..., auditTrue)则产出签名、无 PHI 的AuditReport记录移除了什么——这正是 Safe Harbor 证明与安全规则审计控制164.312(b)都需要的证据。五、18 类 Safe Harbor 标识符与 OpenMed 的逐类覆盖Safe Harbor 要求全部移除以下 18 类标识符164.514(b)(2)姓名Names小于州级的地理细分街道、城市、县、区、ZIP 及等价物——仅当该区域人口 20,000 时可保留 ZIP3与个人直接相关的所有日期要素年份除外年龄 89 以及指示该年龄的日期要素聚合为 90电话号码传真号码电子邮件地址社会安全号码SSN病历号Medical record numbers健康计划受益人号码账户号码证书/执照号码车辆标识符与序列号含车牌设备标识符与序列号网页 URLIP 地址生物识别标识符指纹/声纹全脸照片及可比图像任何其他唯一识别号码、特征或代码外加残余条件无实际知识表明剩余数据仍可识别个体。仓库实现如何保证恰好 18 类OpenMed 将这份清单工程化成了可执行代码。在 openmed/compliance/safe_harbor.py 中SAFE_HARBOR_CATEGORY_ORDER以法规顺序非集合顺序枚举了 18 个类别常量NAME、GEOGRAPHIC_SUBDIVISION、DATE_ELEMENT、TELEPHONE_NUMBER……UNIQUE_IDENTIFIER模块导入时执行_validate_category_table()若类别数量不等于 18、与核心标签集合HIPAA_SAFE_HARBOR_CLASSES不一致、或类别名表不完整直接抛出RuntimeError——从结构上杜绝漏掉某一类的编码错误核心标签到类别的映射定义在 openmed/core/labels.pyLABEL_TO_HIPAA并在导入期校验映射必须恰好覆盖 18 个类别第 1297、1312 行附近;每个 span 可通过顶层hipaa_safe_harbor_class/safe_harbor_class字段或regulatory_tags显式指定类别便于专用检测器区分传真号等细类同时保留规范标签PHONE。类别级证明SafeHarborAttestationgenerate_safe_harbor_attestation(audit_report)同文件第 215 行起从一次去标识化运行的审计报告生成Safe Harbor 证明对 18 个类别逐一输出detection_count检测数、applied_action_counts实际执行的动作分布、policy_actions策略规定的动作。原始文本、span 偏移、上下文、替代值、检测器证据一律不进入证明模块 docstring 明确承诺证明中只有类别元数据、聚合计数、策略动作与哈希。两个值得注意的机制残余风险residual_risk自动标记若某类别没有规范标签映射No canonical OpenMed labels map to this category或存在keep动作的检测结果该类别会被标记为residual_riskTruerequires_expert_determination属性随之变为True——证明会诚实地说需要专家评审而不是假装全部达标。与审计报告哈希绑定证明携带source_report_hash来自审计报告的repro_hash并用verify_repro_hash校验确保证明对应的就是那次具体运行。想逐类核对哪个检测标签覆盖了哪类 Safe Harbor 标识符请使用相邻技能auditing-safe-harbor-checklist见 skills/auditing-safe-harbor-checklist/SKILL.md它把 OpenMed 的检测标签映射到这 18 个类别可用于交叉核对 span 覆盖是否完整。六、实操运行清单并产出差距报告以下代码与工作流来自 SKILL.md可直接复制到你的管线预部署检查中。快速开始import openmed # 管线中的代表性记录合成数据——切勿记录真实 PHI。 sample John Doe (MRN 1234567), DOB 1970-01-15, seen 2024-03-02 in Boston. # 1) 在 Safe Harbor 策略下端侧去标识化。 result openmed.deidentify(sample, methodreplace, policyhipaa_safe_harbor) print(result.deidentified_text) # 标识符已被移除/替代 # 2) 为合规档案生成带签名、无 PHI 的审计记录。 report openmed.deidentify(sample, policyhipaa_safe_harbor, auditTrue) report.sign(brelease-hmac-key-from-vault, key_idhipaa-2026) # 3) 逐项对照清单见 references/hipaa-checklist.md并记录缺口。 controls { encryption_at_rest: True, encryption_in_transit: True, access_controls_rbac: True, audit_logging: True, # 由带签名 AuditReport 部分满足 minimum_necessary: False, # -- 缺口管线拉取了完整病历 baa_in_place: True, deidentification_method: safe_harbor, } gaps [name for name, ok in controls.items() if not ok] print(GAPS:, gaps)要点说明policyhipaa_safe_harbor加载的是 openmed/core/policies/hipaa_safe_harbor.json。该策略default_action为mask遮罩policy_label_actions对DIRECT_IDENTIFIER、QUASI_IDENTIFIER、SENSITIVE_ATTRIBUTE、CLINICAL_CONCEPT全部置为masksafety_sweep_mandatory: true强制安全清扫forced_cascade_tiers依次执行 R0→R1→R2 三档级联检测。策略的阈值画像为balancedthreshold_profile: balanced。签名密钥来自你的密钥管理系统vault示例用brelease-hmac-key-from-vault占位key_idhipaa-2026用于密钥轮换时的标识参见 openmed/core/audit_key_rotation.py 与 openmed/core/key_lifecycle.py。若你需要把 Safe Harbor 策略用于 FHIR 或 OMOP 映射管线仓库还提供 openmed/core/policies/fhir_hipaa_safe_harbor.json 与 openmed/core/policies/omop_hipaa_safe_harbor.json。六步工作流映射数据流绘制 PHI 被创建、接收、维护或传输的每一个位置——包括模型缓存、临时文件与日志。确认法律基础运营方是 covered entity 还是 business associate每个接触 PHI 的下游供应商是否都有BAAOpenMed 端侧运行意味着 NLP 环节没有第三方处理方——在差距报告中记为有利控制项。运行三大保障组从清单执行行政风险分析、员工培训、制裁、物理设施/设备控制、技术访问控制、审计控制、完整性、传输安全。落实最小必要只拉取任务所需字段其余遮罩在使用场景允许的前提下尽早去标识化。记录去标识化方法Safe Harbor 还是 Expert Determination并附上带签名的AuditReport作为证据。输出差距报告逐控制标注 met / not-met / N/A附 45 CFR 条文引用与整改负责人交给隐私官。七、边界情况与常见坑Edge Cases Gotchas这些是审计中最常被挑出的问题清单作者特意列出务必逐条自查去标识化数据不在范围内——但前提是做对了Safe Harbor 要求全部 18 类移除且无再识别实际知识。残留的稀有 ZIP3 或模型漏掉的自由文本姓名会让数据重新变回 PHI。必须验证覆盖度不能想当然。有限数据集仍然是 PHI在数据使用协议164.514(e)下保留日期和 ZIP 的数据不是去标识化数据适用完全不同的控制。日志和缓存也是 PHI模型缓存、异常消息、含原始病历的临时文件都在范围内。这是最常见的缺口。每个供应商都需要 BAA凡代你创建/接收/维护/传输 PHI 的供应商含云存储和任何 LLM API都需 BAA。OpenMed 端侧运行让 NLP 环节无需新增 BAA——但这条只对你真正全程本地运行的部署成立。最小必要是义务不是加分项164.502(b)问题清单够用时不要拉取整本病历。泄露通知时钟未受保护的 PHI 泄露会触发 164.400-414 的通知义务达到 NIST 标准的加密可使数据被视为已保护secured从而可能避免触发通知。不是法律意见清单支持但不替代隐私官的判定Expert Determination 路径还需要合格统计师。八、与 OpenMed 相邻能力的衔接去标识化核心控制是deidentifying-clinical-text技能openmed.deidentify、policyhipaa_safe_harbor它将 PHI 在端侧转换为非 PHI——这是 HIPAA 管线的心脏见 skills/deidentifying-clinical-text/SKILL.md。标识符覆盖核对auditing-safe-harbor-checklist将检测 span 映射到 18 类 Safe Harbor见 skills/auditing-safe-harbor-checklist/SKILL.md。审计控制auditing-deidentification-runsauditTrue→AuditReport.sign()/.verify()提供安全规则审计控制标准164.312(b)要求的防篡改、无 PHI 记录见 skills/auditing-deidentification-runs/SKILL.md。无 PHI 日志enforcing-nophi-logging阻止标识符进入日志与追踪审计中的高频发现项见 skills/enforcing-nophi-logging/SKILL.md。引用与进一步阅读本清单全文skills/checking-hipaa-compliance/references/hipaa-checklist.md技能说明与工作流skills/checking-hipaa-compliance/SKILL.mdSafe Harbor 证明生成器实现openmed/compliance/safe_harbor.py签名审计报告实现openmed/core/audit.pySafe Harbor 策略配置openmed/core/policies/hipaa_safe_harbor.json标签到 18 类别的映射openmed/core/labels.py相关合规文档docs/compliance/hipaa-safe-harbor-attestation.md、docs/compliance/audit-envelopes.md、docs/compliance/21-cfr-part-11-audit-trail.md法规依据本清单对应的标准为 45 CFR Part 164安全规则 Subpart C164.308/164.310/164.312隐私规则 Subpart E164.502–164.528以及 45 CFR 164.400–414 的泄露通知条款。具体条文请以美国卫生与公众服务部HHS官方文本为准并以机构隐私官/安全官的最终判定为准。【免费下载链接】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），仅供参考
OpenMed HIPAA 合规检查清单实战指南：逐项对照 45 CFR Part 164 安全与隐私规则
OpenMed HIPAA 合规检查清单实战指南逐项对照 45 CFR Part 164 安全与隐私规则【免费下载链接】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本指南以 OpenMed 仓库中 checking-hipaa-compliance 技能 及其 HIPAA safeguards checklist45 CFR Part 164 为核心面向任何计划在真实受保护健康信息PHI上部署数据处理管线的团队。你将掌握如何按行政、物理、技术三大保障组逐项自评合规状态理解 Safe Harbor 与 Expert Determination 两条不再是 PHI的法定路径并学会用 OpenMed 的deidentify(policyhipaa_safe_harbor)与带 HMAC 签名的AuditReport落地去标识化与审计控制最终产出一份可交给隐私官Privacy/Security Officer的差距报告gap report。清单是什么控制项、R/A 语义与使用边界这份清单是一份控制项级control-by-control自评工具覆盖 HIPAA 安全规则Security Rule45 CFR Part 164 Subpart C与隐私规则Privacy Rule45 CFR Part 164 Subpart E对处理 PHI 的管线提出的全部要求。每一行都给出控制编号如 A1、T3、V2便于在差距报告中引用控制内容如风险分析、审计控制、最小必要法规条文引用如 164.308(a)(1)(ii)(A)供审计时回溯R/A 标记R Required必须实施A Addressable必须实施、采用等效替代方案、或书面记录为何不合理——绝不是可选Met?是否满足自评勾选列OpenMed fit列标注 OpenMed 在何处满足或支撑该控制。清单在仓库中的位置是 skills/checking-hipaa-compliance/references/hipaa-checklist.md其配套的 SKILL.md 则给出了从映射数据流到输出差距报告的完整工作流。需要特别强调边界这是自评辅助工具self-assessment aid不是法律意见。最终合规判定由机构的隐私官/安全官做出若走 Expert Determination 路径还需合格统计师qualified statistician签字。本文及清单只能帮助你系统化地收集证据、识别缺口。一、行政保障Administrative Safeguards— 45 CFR 164.308行政保障关注组织层面的安全管理过程、人员职责与制度。完整清单如下#控制引用R/AMet?OpenMed fitA1安全管理流程执行准确、彻底的风险分析164.308(a)(1)(ii)(A)R☐去标识化步骤不引入外部处理方on-deviceA2风险管理——将风险降至合理水平164.308(a)(1)(ii)(B)R☐尽早去标识化缩小 PHI 暴露面A3针对员工违规的制裁政策164.308(a)(1)(ii)(C)R☐—A4信息系统活动审查审计日志审阅164.308(a)(1)(ii)(D)R☐带签名的AuditReport供审查使用A5指定安全责任明确 Security Official164.308(a)(2)R☐—A6员工授权/监督/权限审查164.308(a)(3)A☐—A7信息访问管理——隔离、授权、调整访问164.308(a)(4)R/A☐对去标识化输出实施 RBACA8安全意识与培训提醒、恶意软件、登录、口令164.308(a)(5)A☐—A9安全事件处置程序——识别、响应、上报164.308(a)(6)R☐—A10应急计划——备份、灾难恢复、应急模式、演练164.308(a)(7)R/A☐—A11评估——定期技术与非技术审查164.308(a)(8)R☐变更后重跑本清单A12与每个接触 PHI 的供应商签订业务伙伴协议BAA164.308(b)(1), 164.314(a)R☐端侧 NLP 无需新增 BAA其中A12BAA与 OpenMed 的local-first定位直接相关OpenMed 的 NLP 去标识化完全在设备端/本地运行不把文本发送给第三方云模型因此在数据流映射中这一步不会引入新的业务伙伴business associate也就无需为该环节新增 BAA。这一点同时被 A1无外部处理方与 A2缩小 PHI 暴露面两条控制引用是 OpenMed 管线在合规审查中的明显加分项但前提是你能在数据流图中证明没有任何第三方含云存储、LLM API接触原始 PHI。二、物理保障Physical Safeguards— 45 CFR 164.310物理保障关注设施、工作站与设备的实体安全#控制引用R/AMet?OpenMed fitP1设施访问控制——应急、安全计划、验证164.310(a)A☐—P2工作站使用政策规定适当用途/方式164.310(b)R☐—P3工作站安全访问的物理防护164.310(c)R☐—P4设备与介质控制——处置、复用、责任清单、备份164.310(d)R/A☐擦除曾承载 PHI 的模型缓存P4 是最容易被忽略的一项OpenMed 在本地加载模型、缓存中间结果若缓存目录或临时文件曾接触原始文本它们在物理层面与 PHI 同等对待。仓库中 openmed/core/model_cache_policy.py 定义了模型缓存策略openmed/core/deletion_verify.py 提供了删除验证逻辑可用于支撑处置后不可恢复的证据链。处置与复用设备前务必执行缓存清理与验证。三、技术保障Technical Safeguards— 45 CFR 164.312技术保障是 OpenMed 参与最深的一组也是与代码证据结合最紧密的部分#控制引用R/AMet?OpenMed fitT1访问控制——唯一用户 ID、紧急访问、自动登出164.312(a)(1)R/A☐—T2静态加密/解密164.312(a)(2)(iv)A☐加密去标识化输出及任何映射关系T3审计控制——记录并检查系统活动164.312(b)R☐带签名AuditReportauditTrue记录每次脱敏T4完整性——防止 PHI 被不当篡改/销毁164.312(c)R/A☐AuditReport.verify() 防篡改证据HMACT5个人/实体身份认证164.312(d)R☐—T6传输安全——完整性控制 传输中加密164.312(e)R/A☐任何导出走 TLS仅经 HTTPS 访问 OpenFDA 等外部服务T3/T4 的源码级支撑签名审计报告技术保障的核心落地是 OpenMed 的审计报告机制实现在 openmed/core/audit.py 中AuditReport类第 981 行起包含policy、spans、residual_risk、openmed_version、input_hash、deidentified_text_hash、repro_hash等字段是本次去标识化运行发生了什么的完整、确定性记录。签名算法为 HMAC-SHA256文件头部定义了_SIGNATURE_ALGORITHM HMAC-SHA256并要求non-empty HMAC release key才能签名/验签_MISSING_KEY_ERROR。sign()与verify()方法第 1213/1232 行即对应清单 T3/T4 行的AuditReport.sign()/AuditReport.verify()。PHI-free 保障审计报告在序列化前经过消毒处理_AUDIT_RAW_VALUE_KEYS中列出的原始值字段original_text、value、surface、replacement、raw等不会进入报告报告只保留偏移量、类别、动作与哈希。这意味着你可以把签名报告直接放进合规文件柜或日志系统而无需担心它本身泄露 PHI。可复现哈希span 按(start, end, canonical_label, action)稳定排序后再计算repro_hash两次逻辑相同的运行产出完全一致的哈希供审计回溯与复现核验。T2 的配套输出加密与映射保管hipaa_safe_harbor策略默认keep_mapping: false、reversible_id: false见 openmed/core/policies/hipaa_safe_harbor.json即去标识化过程不保留可逆映射。若你的场景确实需要保留映射例如有限数据集场景该映射文件必须按 T2 要求加密存放——它本身是 PHI 级别的敏感物。四、隐私规则控制Privacy Rule— 45 CFR Part 164 Subpart E#控制引用Met?OpenMed fitV1最小必要——将 PHI 限制在与目的相符的范围164.502(b), 164.514(d)☐屏蔽任务不需要的字段V2去标识化——Safe Harbor18 项标识符或 Expert Determination164.514(a)–(c)☐deidentify(policyhipaa_safe_harbor)V3有限数据集Limited Data Set 数据使用协议若保留日期/ZIP164.514(e)☐仍属 PHI——适用不同控制V4使用与披露需经授权或属于允许情形164.502, 164.506, 164.508☐—V5披露会计记录Accounting of disclosures164.528☐审计轨迹支持记录V6泄露通知评估与义务164.400–414☐NIST 级加密可能避免触发通知两条不再是 PHI的法定路径HIPAA 承认两种去标识化方法45 CFR 164.514在差距报告中必须明确记录你选的是哪一条及理由Safe Harbor安全港——移除全部18 类标识符且无实际知识表明剩余数据可重新识别个体。确定性、可程序化验证是常见路径。Expert Determination专家判定——由合格统计师认证非常小的再识别风险。当必须保留部分准标识符如完整日期、乡镇级地理信息时使用。OpenMed 的deidentify(..., policyhipaa_safe_harbor)在端侧针对 Safe Harbor 标识符集合执行去标识化deidentify(..., auditTrue)则产出签名、无 PHI 的AuditReport记录移除了什么——这正是 Safe Harbor 证明与安全规则审计控制164.312(b)都需要的证据。五、18 类 Safe Harbor 标识符与 OpenMed 的逐类覆盖Safe Harbor 要求全部移除以下 18 类标识符164.514(b)(2)姓名Names小于州级的地理细分街道、城市、县、区、ZIP 及等价物——仅当该区域人口 20,000 时可保留 ZIP3与个人直接相关的所有日期要素年份除外年龄 89 以及指示该年龄的日期要素聚合为 90电话号码传真号码电子邮件地址社会安全号码SSN病历号Medical record numbers健康计划受益人号码账户号码证书/执照号码车辆标识符与序列号含车牌设备标识符与序列号网页 URLIP 地址生物识别标识符指纹/声纹全脸照片及可比图像任何其他唯一识别号码、特征或代码外加残余条件无实际知识表明剩余数据仍可识别个体。仓库实现如何保证恰好 18 类OpenMed 将这份清单工程化成了可执行代码。在 openmed/compliance/safe_harbor.py 中SAFE_HARBOR_CATEGORY_ORDER以法规顺序非集合顺序枚举了 18 个类别常量NAME、GEOGRAPHIC_SUBDIVISION、DATE_ELEMENT、TELEPHONE_NUMBER……UNIQUE_IDENTIFIER模块导入时执行_validate_category_table()若类别数量不等于 18、与核心标签集合HIPAA_SAFE_HARBOR_CLASSES不一致、或类别名表不完整直接抛出RuntimeError——从结构上杜绝漏掉某一类的编码错误核心标签到类别的映射定义在 openmed/core/labels.pyLABEL_TO_HIPAA并在导入期校验映射必须恰好覆盖 18 个类别第 1297、1312 行附近;每个 span 可通过顶层hipaa_safe_harbor_class/safe_harbor_class字段或regulatory_tags显式指定类别便于专用检测器区分传真号等细类同时保留规范标签PHONE。类别级证明SafeHarborAttestationgenerate_safe_harbor_attestation(audit_report)同文件第 215 行起从一次去标识化运行的审计报告生成Safe Harbor 证明对 18 个类别逐一输出detection_count检测数、applied_action_counts实际执行的动作分布、policy_actions策略规定的动作。原始文本、span 偏移、上下文、替代值、检测器证据一律不进入证明模块 docstring 明确承诺证明中只有类别元数据、聚合计数、策略动作与哈希。两个值得注意的机制残余风险residual_risk自动标记若某类别没有规范标签映射No canonical OpenMed labels map to this category或存在keep动作的检测结果该类别会被标记为residual_riskTruerequires_expert_determination属性随之变为True——证明会诚实地说需要专家评审而不是假装全部达标。与审计报告哈希绑定证明携带source_report_hash来自审计报告的repro_hash并用verify_repro_hash校验确保证明对应的就是那次具体运行。想逐类核对哪个检测标签覆盖了哪类 Safe Harbor 标识符请使用相邻技能auditing-safe-harbor-checklist见 skills/auditing-safe-harbor-checklist/SKILL.md它把 OpenMed 的检测标签映射到这 18 个类别可用于交叉核对 span 覆盖是否完整。六、实操运行清单并产出差距报告以下代码与工作流来自 SKILL.md可直接复制到你的管线预部署检查中。快速开始import openmed # 管线中的代表性记录合成数据——切勿记录真实 PHI。 sample John Doe (MRN 1234567), DOB 1970-01-15, seen 2024-03-02 in Boston. # 1) 在 Safe Harbor 策略下端侧去标识化。 result openmed.deidentify(sample, methodreplace, policyhipaa_safe_harbor) print(result.deidentified_text) # 标识符已被移除/替代 # 2) 为合规档案生成带签名、无 PHI 的审计记录。 report openmed.deidentify(sample, policyhipaa_safe_harbor, auditTrue) report.sign(brelease-hmac-key-from-vault, key_idhipaa-2026) # 3) 逐项对照清单见 references/hipaa-checklist.md并记录缺口。 controls { encryption_at_rest: True, encryption_in_transit: True, access_controls_rbac: True, audit_logging: True, # 由带签名 AuditReport 部分满足 minimum_necessary: False, # -- 缺口管线拉取了完整病历 baa_in_place: True, deidentification_method: safe_harbor, } gaps [name for name, ok in controls.items() if not ok] print(GAPS:, gaps)要点说明policyhipaa_safe_harbor加载的是 openmed/core/policies/hipaa_safe_harbor.json。该策略default_action为mask遮罩policy_label_actions对DIRECT_IDENTIFIER、QUASI_IDENTIFIER、SENSITIVE_ATTRIBUTE、CLINICAL_CONCEPT全部置为masksafety_sweep_mandatory: true强制安全清扫forced_cascade_tiers依次执行 R0→R1→R2 三档级联检测。策略的阈值画像为balancedthreshold_profile: balanced。签名密钥来自你的密钥管理系统vault示例用brelease-hmac-key-from-vault占位key_idhipaa-2026用于密钥轮换时的标识参见 openmed/core/audit_key_rotation.py 与 openmed/core/key_lifecycle.py。若你需要把 Safe Harbor 策略用于 FHIR 或 OMOP 映射管线仓库还提供 openmed/core/policies/fhir_hipaa_safe_harbor.json 与 openmed/core/policies/omop_hipaa_safe_harbor.json。六步工作流映射数据流绘制 PHI 被创建、接收、维护或传输的每一个位置——包括模型缓存、临时文件与日志。确认法律基础运营方是 covered entity 还是 business associate每个接触 PHI 的下游供应商是否都有BAAOpenMed 端侧运行意味着 NLP 环节没有第三方处理方——在差距报告中记为有利控制项。运行三大保障组从清单执行行政风险分析、员工培训、制裁、物理设施/设备控制、技术访问控制、审计控制、完整性、传输安全。落实最小必要只拉取任务所需字段其余遮罩在使用场景允许的前提下尽早去标识化。记录去标识化方法Safe Harbor 还是 Expert Determination并附上带签名的AuditReport作为证据。输出差距报告逐控制标注 met / not-met / N/A附 45 CFR 条文引用与整改负责人交给隐私官。七、边界情况与常见坑Edge Cases Gotchas这些是审计中最常被挑出的问题清单作者特意列出务必逐条自查去标识化数据不在范围内——但前提是做对了Safe Harbor 要求全部 18 类移除且无再识别实际知识。残留的稀有 ZIP3 或模型漏掉的自由文本姓名会让数据重新变回 PHI。必须验证覆盖度不能想当然。有限数据集仍然是 PHI在数据使用协议164.514(e)下保留日期和 ZIP 的数据不是去标识化数据适用完全不同的控制。日志和缓存也是 PHI模型缓存、异常消息、含原始病历的临时文件都在范围内。这是最常见的缺口。每个供应商都需要 BAA凡代你创建/接收/维护/传输 PHI 的供应商含云存储和任何 LLM API都需 BAA。OpenMed 端侧运行让 NLP 环节无需新增 BAA——但这条只对你真正全程本地运行的部署成立。最小必要是义务不是加分项164.502(b)问题清单够用时不要拉取整本病历。泄露通知时钟未受保护的 PHI 泄露会触发 164.400-414 的通知义务达到 NIST 标准的加密可使数据被视为已保护secured从而可能避免触发通知。不是法律意见清单支持但不替代隐私官的判定Expert Determination 路径还需要合格统计师。八、与 OpenMed 相邻能力的衔接去标识化核心控制是deidentifying-clinical-text技能openmed.deidentify、policyhipaa_safe_harbor它将 PHI 在端侧转换为非 PHI——这是 HIPAA 管线的心脏见 skills/deidentifying-clinical-text/SKILL.md。标识符覆盖核对auditing-safe-harbor-checklist将检测 span 映射到 18 类 Safe Harbor见 skills/auditing-safe-harbor-checklist/SKILL.md。审计控制auditing-deidentification-runsauditTrue→AuditReport.sign()/.verify()提供安全规则审计控制标准164.312(b)要求的防篡改、无 PHI 记录见 skills/auditing-deidentification-runs/SKILL.md。无 PHI 日志enforcing-nophi-logging阻止标识符进入日志与追踪审计中的高频发现项见 skills/enforcing-nophi-logging/SKILL.md。引用与进一步阅读本清单全文skills/checking-hipaa-compliance/references/hipaa-checklist.md技能说明与工作流skills/checking-hipaa-compliance/SKILL.mdSafe Harbor 证明生成器实现openmed/compliance/safe_harbor.py签名审计报告实现openmed/core/audit.pySafe Harbor 策略配置openmed/core/policies/hipaa_safe_harbor.json标签到 18 类别的映射openmed/core/labels.py相关合规文档docs/compliance/hipaa-safe-harbor-attestation.md、docs/compliance/audit-envelopes.md、docs/compliance/21-cfr-part-11-audit-trail.md法规依据本清单对应的标准为 45 CFR Part 164安全规则 Subpart C164.308/164.310/164.312隐私规则 Subpart E164.502–164.528以及 45 CFR 164.400–414 的泄露通知条款。具体条文请以美国卫生与公众服务部HHS官方文本为准并以机构隐私官/安全官的最终判定为准。【免费下载链接】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），仅供参考
