尧图网站建设 
OpenMed GDPR DSAR 主体访问导出基于伪名化 Vault 的 Article 15/17 合规实现指南【免费下载链接】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 提供的 GDPR 数据主体访问请求DSAR导出组件openmed.compliance.dsar当 OpenMed 维护跨文档的伪名化替代库surrogate vault时如何依据 GDPR Article 15 在本地组装该数据主体持有的全部个人数据包将导出动作写入防篡改哈希链审计日志并提供不具破坏性的 Article 17 删除预案。读完本文你将掌握主体匹配的哈希原理、assemble_dsar_package与plan_erasure的完整调用方式、审计链的验证机制以及该组件的合规边界。GDPR Article 15/17 与 OpenMed 的本地优先定位GDPR Article 15 要求控制者controller产出其持有的关于某数据主体的全部个人数据。当 OpenMed 维护跨文档的 surrogate vault 时关于某主体的持有数据就是一组伪名化 vault 条目其来源表面source surface哈希值命中该主体已知标识符中的某一个。OpenMed 的 DSAR 助手在本地完成 Article 15 数据包组装将导出记录到防篡改审计链并提供 Article 17 擦除配套功能。必须强调OpenMed 不自我认证合规该助手不验证请求者身份也不发现 OpenMed 之外的数据。在对外发布任何导出前须依据自身数据、司法辖区和法律顾问意见进行校验见 docs/compliance/gdpr-dsar-export.md。主体匹配的工作原理surrogate vault 以(canonical_label, lang, text_hash)为键其中text_hash是单一来源表面的 HMAC 摘要。vault 本身没有任何主体分组因此助手采用如下策略取控制者已持有的主体标识符表面姓名、MRN、出生日期等通过既有 vault 配置为每个标识符重新计算text_hash仅选出哈希命中的 vault 条目作为数据包内容。这样数据包只包含与所请求标识符绑定的数据。由于 vault 存储的是 HMAC 哈希与替代值surrogate而非原始值数据包与审计日志均不携带原始 PHI。源码实现见 openmed/compliance/dsar.py_matching_entries先通过vault.key_for(ident.surface, labelident.label, langident.lang)重建主体的 vault 键集合再对vault.entries()做键级过滤——注意匹配是键级entry.key in subject_keys因此 canonical_label 与 lang 都会参与判定。测试 tests/unit/compliance/test_dsar_export.py 验证了这一点同一表面12345在id_num/phone标签及en/fr语言下形成不同条目只有id_numen的标识符会命中MRN-90001。text_hash的底层实现是 HMAC-SHA256见 openmed/core/surrogate_vault.py 的HMAC_SCHEME hmac-sha256以及hmac_text_hash对当前 epoch linkage key 的派生使用openmed/core/surrogate_vault.pyvault 文件落盘时替代值还按版本化 epoch 密钥加密文件本身不暴露替换标识符。组装访问数据包官方用法如下完整可运行from openmed.compliance import ( HashChainAuditLog, SubjectIdentifier, assemble_dsar_package, render_dsar_summary, ) from openmed.core.surrogate_vault import SurrogateVault vault SurrogateVault.from_file(vault.json, hmac_secretSECRET) audit HashChainAuditLog() identifiers [ SubjectIdentifier(John Smith, first_name), SubjectIdentifier(MRN-12345, id_num), ] package assemble_dsar_package( identifiers, vault, audit_sinkaudit, audit_references[deid-run-2026-07-01], ) print(render_dsar_summary(package)) assert audit.verify()各构件说明SubjectIdentifier(surface, label, langen)控制者持有的一个已知标识符值lang默认enopenmed/compliance/dsar.pySurrogateVault.from_file(path, hmac_secret..., createTrue, autosaveTrue, ...)从加密 JSON 文件打开 vaulthmac_secret为必填且永不落盘openmed/core/surrogate_vault.pyaudit_references调用方提供的、与本次导出相关的审计制品引用会被原样写入数据包与审计记录。DsarPackage 字段assemble_dsar_package返回DsarPackage定义见 openmed/compliance/dsar.py字段含义subject_ref由标识符哈希推导出的稳定、非 PHI 引用entries命中的DsarEntry持有项canonical label、lang、text_hash、surrogatecategories该主体持有的去重 canonical label 集合audit_references调用方提供的相关审计制品引用audit_record传入audit_sink时为本次导出追加的AuditRecord其中subject_ref由stable_hash(sorted(set(text_hashes)))计算openmed/compliance/dsar.py保证同一批标识符总是得到同一引用确定性且原始值如 John Smith、MRN-12345不会出现在引用中——测试 tests/unit/compliance/test_dsar_export.py 对这两点均有断言。DsarEntry只暴露 vault 的隐私安全字段canonical label、HMACtext_hash与 surrogate原始来源表面既不存储于 vault也绝不会出现在条目中openmed/compliance/dsar.py。render_dsar_summary输出确定性的可读摘要包含标题、subject reference、记录数、类别列表、每条条目的label [lang] - surrogate (hash)与审计引用并附加DSAR_ADVISORY合规提示openmed/compliance/dsar.py。审计日志哈希链的防篡改机制导出生成通过注入的AuditSink记录。默认实现HashChainAuditLog是只追加账本每条记录提交其前驱的哈希因此任何事后篡改都能通过verify()检出openmed/compliance/audit_chain.py。链的构造要点首条记录的previous_hash锚定到GENESIS_HASH由固定链标识推导的创世锚点每条AuditRecord.compute_hash()对{sequence, event_type, payload, previous_hash}做稳定哈希因此一条记录的改动会破坏其后所有记录的一致性verify()依次校验序号连续、前驱哈希衔接、记录哈希自洽返回True即链条完好。记录的载荷只含主体引用、计数、类别与内容哈希绝不包含原始 PHI测试 tests/unit/compliance/test_dsar_export.py 对 payload 序列化后不含 John Smith/MRN-12345/Robert Jones 做了断言。AuditSink协议刻意保持最小openmed/compliance/audit_chain.py只需实现append(event_type, payload) - AuditRecord。这样未来 OpenMed 共享审计链接入时可直接替换默认实现而无需改动调用方代码。Article 17 擦除配套非破坏性的删除预案plan_erasure列出一次擦除会移除的内容默认不删除任何数据它返回可擦除的持有项并保持 vault 原样openmed/compliance/dsar.py。from openmed.compliance import plan_erasure plan plan_erasure(package, vault, audit_sinkaudit) assert plan.executed is False for entry in plan.erasable: print(entry.canonical_label, entry.text_hash)实现上plan_erasure以当前 live vault 内容为准live_hashes只把仍存在于 vault 中的package.entries标记为可擦除预览会以非破坏性的dsar.erasure_preview事件写入审计日志其 payload 携带destructive: False测试 tests/unit/compliance/test_dsar_export.py 验证了事件类型与标志位。测试 tests/unit/compliance/test_dsar_export.py 还证明生成预案前后len(vault.entries())不变vault 完全未被触碰。实际的删除是控制者在自己的密钥保管与治理控制下对 vault 存储执行的独立、刻意操作plan_erasure只是配套预案。合规范围与边界请求者身份验证不在范围内助手假设控制者已确认数据主体身份OpenMed 之外的跨系统数据发现不在范围内助手只聚合本地 vault 中的数据不自我认证合规导出发放前须由你方数据、司法辖区和法律顾问进行最终校验。这也与 OpenMed 本地优先的整体定位一致数据包组装、审计记录均在本机完成不外发任何患者数据原始 PHI 不落入数据包与审计日志仅以 HMAC 哈希与替代值形式存在。相关资源组件实现openmed/compliance/dsar.py审计链实现openmed/compliance/audit_chain.pysurrogate vault 实现openmed/core/surrogate_vault.py单元测试tests/unit/compliance/test_dsar_export.py、tests/unit/compliance/test_audit_chain.py合规文档索引docs/compliance【免费下载链接】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 GDPR DSAR 主体访问导出：基于伪名化 Vault 的 Article 15/17 合规实现指南
OpenMed GDPR DSAR 主体访问导出基于伪名化 Vault 的 Article 15/17 合规实现指南【免费下载链接】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 提供的 GDPR 数据主体访问请求DSAR导出组件openmed.compliance.dsar当 OpenMed 维护跨文档的伪名化替代库surrogate vault时如何依据 GDPR Article 15 在本地组装该数据主体持有的全部个人数据包将导出动作写入防篡改哈希链审计日志并提供不具破坏性的 Article 17 删除预案。读完本文你将掌握主体匹配的哈希原理、assemble_dsar_package与plan_erasure的完整调用方式、审计链的验证机制以及该组件的合规边界。GDPR Article 15/17 与 OpenMed 的本地优先定位GDPR Article 15 要求控制者controller产出其持有的关于某数据主体的全部个人数据。当 OpenMed 维护跨文档的 surrogate vault 时关于某主体的持有数据就是一组伪名化 vault 条目其来源表面source surface哈希值命中该主体已知标识符中的某一个。OpenMed 的 DSAR 助手在本地完成 Article 15 数据包组装将导出记录到防篡改审计链并提供 Article 17 擦除配套功能。必须强调OpenMed 不自我认证合规该助手不验证请求者身份也不发现 OpenMed 之外的数据。在对外发布任何导出前须依据自身数据、司法辖区和法律顾问意见进行校验见 docs/compliance/gdpr-dsar-export.md。主体匹配的工作原理surrogate vault 以(canonical_label, lang, text_hash)为键其中text_hash是单一来源表面的 HMAC 摘要。vault 本身没有任何主体分组因此助手采用如下策略取控制者已持有的主体标识符表面姓名、MRN、出生日期等通过既有 vault 配置为每个标识符重新计算text_hash仅选出哈希命中的 vault 条目作为数据包内容。这样数据包只包含与所请求标识符绑定的数据。由于 vault 存储的是 HMAC 哈希与替代值surrogate而非原始值数据包与审计日志均不携带原始 PHI。源码实现见 openmed/compliance/dsar.py_matching_entries先通过vault.key_for(ident.surface, labelident.label, langident.lang)重建主体的 vault 键集合再对vault.entries()做键级过滤——注意匹配是键级entry.key in subject_keys因此 canonical_label 与 lang 都会参与判定。测试 tests/unit/compliance/test_dsar_export.py 验证了这一点同一表面12345在id_num/phone标签及en/fr语言下形成不同条目只有id_numen的标识符会命中MRN-90001。text_hash的底层实现是 HMAC-SHA256见 openmed/core/surrogate_vault.py 的HMAC_SCHEME hmac-sha256以及hmac_text_hash对当前 epoch linkage key 的派生使用openmed/core/surrogate_vault.pyvault 文件落盘时替代值还按版本化 epoch 密钥加密文件本身不暴露替换标识符。组装访问数据包官方用法如下完整可运行from openmed.compliance import ( HashChainAuditLog, SubjectIdentifier, assemble_dsar_package, render_dsar_summary, ) from openmed.core.surrogate_vault import SurrogateVault vault SurrogateVault.from_file(vault.json, hmac_secretSECRET) audit HashChainAuditLog() identifiers [ SubjectIdentifier(John Smith, first_name), SubjectIdentifier(MRN-12345, id_num), ] package assemble_dsar_package( identifiers, vault, audit_sinkaudit, audit_references[deid-run-2026-07-01], ) print(render_dsar_summary(package)) assert audit.verify()各构件说明SubjectIdentifier(surface, label, langen)控制者持有的一个已知标识符值lang默认enopenmed/compliance/dsar.pySurrogateVault.from_file(path, hmac_secret..., createTrue, autosaveTrue, ...)从加密 JSON 文件打开 vaulthmac_secret为必填且永不落盘openmed/core/surrogate_vault.pyaudit_references调用方提供的、与本次导出相关的审计制品引用会被原样写入数据包与审计记录。DsarPackage 字段assemble_dsar_package返回DsarPackage定义见 openmed/compliance/dsar.py字段含义subject_ref由标识符哈希推导出的稳定、非 PHI 引用entries命中的DsarEntry持有项canonical label、lang、text_hash、surrogatecategories该主体持有的去重 canonical label 集合audit_references调用方提供的相关审计制品引用audit_record传入audit_sink时为本次导出追加的AuditRecord其中subject_ref由stable_hash(sorted(set(text_hashes)))计算openmed/compliance/dsar.py保证同一批标识符总是得到同一引用确定性且原始值如 John Smith、MRN-12345不会出现在引用中——测试 tests/unit/compliance/test_dsar_export.py 对这两点均有断言。DsarEntry只暴露 vault 的隐私安全字段canonical label、HMACtext_hash与 surrogate原始来源表面既不存储于 vault也绝不会出现在条目中openmed/compliance/dsar.py。render_dsar_summary输出确定性的可读摘要包含标题、subject reference、记录数、类别列表、每条条目的label [lang] - surrogate (hash)与审计引用并附加DSAR_ADVISORY合规提示openmed/compliance/dsar.py。审计日志哈希链的防篡改机制导出生成通过注入的AuditSink记录。默认实现HashChainAuditLog是只追加账本每条记录提交其前驱的哈希因此任何事后篡改都能通过verify()检出openmed/compliance/audit_chain.py。链的构造要点首条记录的previous_hash锚定到GENESIS_HASH由固定链标识推导的创世锚点每条AuditRecord.compute_hash()对{sequence, event_type, payload, previous_hash}做稳定哈希因此一条记录的改动会破坏其后所有记录的一致性verify()依次校验序号连续、前驱哈希衔接、记录哈希自洽返回True即链条完好。记录的载荷只含主体引用、计数、类别与内容哈希绝不包含原始 PHI测试 tests/unit/compliance/test_dsar_export.py 对 payload 序列化后不含 John Smith/MRN-12345/Robert Jones 做了断言。AuditSink协议刻意保持最小openmed/compliance/audit_chain.py只需实现append(event_type, payload) - AuditRecord。这样未来 OpenMed 共享审计链接入时可直接替换默认实现而无需改动调用方代码。Article 17 擦除配套非破坏性的删除预案plan_erasure列出一次擦除会移除的内容默认不删除任何数据它返回可擦除的持有项并保持 vault 原样openmed/compliance/dsar.py。from openmed.compliance import plan_erasure plan plan_erasure(package, vault, audit_sinkaudit) assert plan.executed is False for entry in plan.erasable: print(entry.canonical_label, entry.text_hash)实现上plan_erasure以当前 live vault 内容为准live_hashes只把仍存在于 vault 中的package.entries标记为可擦除预览会以非破坏性的dsar.erasure_preview事件写入审计日志其 payload 携带destructive: False测试 tests/unit/compliance/test_dsar_export.py 验证了事件类型与标志位。测试 tests/unit/compliance/test_dsar_export.py 还证明生成预案前后len(vault.entries())不变vault 完全未被触碰。实际的删除是控制者在自己的密钥保管与治理控制下对 vault 存储执行的独立、刻意操作plan_erasure只是配套预案。合规范围与边界请求者身份验证不在范围内助手假设控制者已确认数据主体身份OpenMed 之外的跨系统数据发现不在范围内助手只聚合本地 vault 中的数据不自我认证合规导出发放前须由你方数据、司法辖区和法律顾问进行最终校验。这也与 OpenMed 本地优先的整体定位一致数据包组装、审计记录均在本机完成不外发任何患者数据原始 PHI 不落入数据包与审计日志仅以 HMAC 哈希与替代值形式存在。相关资源组件实现openmed/compliance/dsar.py审计链实现openmed/compliance/audit_chain.pysurrogate vault 实现openmed/core/surrogate_vault.py单元测试tests/unit/compliance/test_dsar_export.py、tests/unit/compliance/test_audit_chain.py合规文档索引docs/compliance【免费下载链接】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），仅供参考