简而言之： 数据保护影响评估 (DPIA) 是您描述一项处理操作、证明其必要性和相称性、评估使用其数据的人员面临的风险，并记录降低这些风险的措施的文件。根据《通用数据保护条例》(GDPR) 第 35 条，当处理可能导致高风险时，DPIA 是强制性的，其中提到了大规模处理特殊类别数据（包括健康数据）的情况。实际上，任何用户数量超过少数的健康应用程序和健康数据平台都需要进行 DPIA，在处理开始之前进行，并在处理发生变化时进行审查。下面的模板遵循 GDPR 第 35(7) 条和欧洲指南；请在文末下载。
何时需要进行 DPIA
根据《通用数据保护条例》第 35 条，当处理可能导致高风险时，就需要进行数据保护影响评估（DPIA)。大规模处理健康数据等特殊类别的数据是自动触发因素。《欧洲数据保护委员会》的标准认为，健康应用程序通常符合多项标准（敏感数据、大规模处理、弱势群体)，因此几乎所有健康应用程序在处理数据之前都需要进行 DPIA。
GDPR 第 35(3) 条列出了三个自动触发因素：系统化和广泛的画像分析，并产生重大影响；大规模处理特殊类别数据（第 9 条）或犯罪数据；系统化大规模监控公共区域。欧洲数据保护委员会的标准（来自前第 29 工作组）增加了六项；如果两项或多项适用，则进行 DPIA：评估或评分；具有法律或类似效力的自动化决策；系统化监控；敏感数据；大规模处理；数据集匹配或组合；关于弱势人群的数据（患者算在内）；创新的技术使用；阻止人们行使权利或使用服务。健康应用程序通常涉及敏感数据、大规模处理、弱势人群以及经常创新的技术。国家主管机关也会发布总是需要 DPIA 的处理清单（GDPR 第 35(4) 条）；大多数清单都包括健康应用程序和联网设备。
清单
健康应用程序 DPIA 清单遵循《通用数据保护条例》第 35(7) 条的四个要素：处理的描述（目的、数据、参与者、技术)、必要性和比例性的评估（法律依据、最小化、权利、处理者、保留期)、对数据使用者的风险评估以及应对这些风险的措施，然后是咨询、签署和定期审查。
1. 描述处理操作 (GDPR 第 35(7)(a) 条)
- 目的，逐一列出：存储个人记录；与诊所共享；提醒；匿名统计数据；人工智能功能。
- 每个目的对应的数据类别，并标明健康数据；来源（个人、诊所、可穿戴设备、文件）；接收者；每个类别的保留期限；向欧盟以外的传输及其机制。
- 参与者：控制者、处理者（托管、分析、支持工具、人工智能提供商）及其合同；数据保护官 (DPO)。
- 技术：架构、数据存储位置、加密、身份验证、日志记录。数据流图是找出遗漏之处的最快方法。
2. 必要性和相称性 (GDPR 第 35(7)(b) 条)
- 根据 GDPR 第 6 条和第 9(2) 条的法律依据，按目的区分（GDPR 第 9 条解释）。
- 数据最小化：说明每个数据元素的必要性；以及您决定不收集的内容。
- 向个人提供的信息（GDPR 第 13-14 条）以及如何在产品中行使权利（访问、更正、删除、可携带性、反对、撤回同意），而不是通过电子邮件发送给支持部门。
- 处理者：已签订的 GDPR 第 28 条合同；列出的子处理者；审计权。
- 保留和删除：具体的期限和强制执行机制。
3. 对个人的风险 (GDPR 第 35(7)(c) 条) 评估每个目的下，三种经典事件的发生可能性和严重性：
- 非法访问（泄露、内部人员、过度共享、诊所看到超出授权范围的信息）；
- 不当修改（记录中存在临床医生依赖的错误数据、同步错误、人工智能功能写入记录）；
- 丢失（个人依赖的记录丢失；账户被盗；供应商倒闭）。 然后是健康数据特有的风险：对“匿名”统计数据的重新识别；根据行为推断病情；数据被保险公司或雇主获取而导致的歧视；儿童数据造成的伤害；诊所周围的地理位置数据；应用程序中的第三方 SDK 将数据发送到广告网络（这是健康应用程序监管审计中最常见的发现）。
4. 措施 (GDPR 第 35(7)(d) 条) 针对每项风险，列出控制措施和剩余风险：静态和传输中的加密；强大的身份验证；根据同意和时间范围限制访问，并提供个人可读取的日志；分析和日志中的假名化；不使用第三方广告或跟踪 SDK；开发环境使用隔离环境和合成数据；具有已测试恢复功能的备份；供应商审查；包含 72 小时时钟的事件响应；安全开发实践；员工培训和保密协议；产品中的数据导出和删除功能；集成功能的“终止开关”。
5. 协商
- 记录 DPO 的建议（GDPR 第 35(2) 条）；在适当情况下征求个人或其代表的意见（GDPR 第 35(9) 条），例如通过用户小组或患者协会。
- 如果存在高剩余风险，则在处理前咨询监管机构（GDPR 第 36 条）。大多数控制良好的健康应用程序不会达到这一点；为多家诊所处理数据的平台有时会。
6. 签署和审查
- 由控制者的管理层批准；注明日期；版本化。
- 在目的、数据、技术或接收者发生变化时进行审查，并且至少每两年审查一次（GDPR 第 35(11) 条）。
健康应用程序 DPIA 中的典型发现
健康应用程序 DPIA 中最常见的发现包括：将标识符与健康信息一起接收的分析和崩溃报告 SDK；在锁屏上会显示病情的推送通知；拥有不受限制数据库访问权限的支持人员；在欧盟以外的备份；账户关闭后仍保留的数据；捆绑了多个目的的同意屏幕；以及仍然可以识别个人的“匿名化”数据集。
这些问题中的每一个都有具体的解决方案，而 DPIA 就是承诺实施这些解决方案的地方。
模板
本页面的 DPIA 模板是一个可填写的 Markdown 文档，适用于健康应用程序，分为六个部分（处理的描述、必要性和比例性、对使用者的风险、措施、咨询、签署和审查)，包含一个风险表和一个措施表。它遵循《通用数据保护条例》第 35(7) 条和《欧洲数据保护委员会》的标准，是一个初步结构，并非法律建议。
下载 DPIA 模板。它可以导入到任何文档工具中；您的数据保护官会对其进行调整。
在 Anpheros
Anpheros 为 Anpheros Daily 和 Anpheros Platform（作为处理者）维护 DPIA，结构如上，其选择在产品中可见：按目的进行同意管理、范围限定和记录的访问、无广告 SDK、欧盟托管、应用程序内的数据导出和删除。请参阅 健康透明度。
本页面面向产品和工程团队解释相关法规。它不构成法律建议；链接的“来源”文本具有权威性，您的数据保护官、通知机构或法律顾问将根据您的具体情况做出决定。最后审查日期：2026 年 10 月。
相关页面
来源
- GDPR 第 35 条和 36 条，EUR-Lex
- 第 29 工作组 / EDPB：关于 DPIA 的指南 (WP248 rev.01)
- CNIL：PIA 方法论和软件
- ICO：数据保护影响评估
- EDPB：指南、建议和最佳实践
常见问题
我需要为用户很少的小型应用程序进行 DPIA 吗？
如果它处理健康数据，几乎总是需要的：敏感数据加上弱势人群已经满足了双重标准测试，并且一些国家清单明确提到了健康应用程序。小型应用程序的 DPIA 只是内容更简短。
谁来撰写 DPIA？
控制者负责；实际上，产品负责人和工程主管会在 DPO 的建议下撰写，因为他们了解数据流。完全外包会产生一份没有人能及时更新的文件。
DPIA 是否必须公开？
否。它是一份内部问责文件，应监管机构要求时出示。许多组织会发布摘要；欧洲健康数据空间 (EHDS) 和一些国家法规要求对某些处理操作进行透明化。
DPIA 与 ISO 27001 下的风险评估有何不同？
ISO 评估关注对组织本身的风险；DPIA 关注对其数据进行处理的个人的风险。它们共享控制措施和证据，良好的安全计划可以为 DPIA 的措施部分提供支持。
在沙盒中免费试用
5 分钟完成第一次 FHIR 调用. 一个内置患者授权的 HL7 FHIR R4 API：先在沙盒中试用，然后连接您自己的应用或诊所系统。
免费 · 30 位合成患者 · 无需信用卡
Anpheros 致力于打造一个由患者掌控的医疗记录，并可在欧盟的 HL7 FHIR R4 平台上与任何诊所共享。这些指南旨在帮助您理解和整理您的健康信息，但不能替代您的医生。
关于 Anpheros →