数字健康平台的 HIPAA 合规性

准确了解触发 HIPAA 义务的因素，以及如何在现代数字健康架构中实施安全规则的技术保障措施，对于该领域的任何团队建设都至关重要。

要点

• HIPAA 适用于涵盖实体及其业务伙伴 — 数字健康平台通常是 BA
• 受保护的健康信息 (PHI) 包括与健康、治疗或支付数据相关的 18 个特定标识符
• 安全规则要求对电子 PHI (ePHI) 采取管理、物理和技术保障措施
• 在与第三方共享任何 PHI 之前，法律要求必须签署业务伙伴协议 (BAA)
• HITECH (2009) 大幅增加处罚力度，并将 HIPAA 义务扩展到 BA 分包商
• 需要在 60 天内向 HHS 和受影响的个人发出违规通知
• OCR 审计越来越多地针对数字医疗公司，而不仅仅是医院
• 使用安全港或专家判定方法进行去识别化，消除了 HIPAA 的适用性

---

谁必须遵守 HIPAA

HIPAA（健康保险流通与责任法案，1996 年）和 HITECH 法案（2009 年）定义了义务实体的两个主要类别：

涵盖实体 (CE)：

• 以电子方式传输健康信息的医疗保健提供者（医院、诊所、医生、药房）
• 健康计划（保险公司、雇主健康计划、医疗保险/医疗补助）
• 医疗保健信息交换所

商业伙伴（BA）： 代表所涵盖实体创建、接收、维护或传输 PHI 的任何实体。数字健康公司通常属于这种情况。示例：

• 可以访问患者记录的 EHR 软件供应商
• 促进提供者与患者沟通的远程医疗平台
• 医疗账单和编码服务
• 健康数据分析平台
• 存储 ePHI 的云存储提供商
• IT 支持具有潜在 PHI 访问权限的公司

HITECH 扩展：HITECH 法案将直接 HIPAA 责任扩展至业务伙伴分包商（有时称为“subBA”）。如果您是 BA，并且使用云提供商来存储 ePHI，则该云提供商是具有直接 HIPAA 义务的 subBA。

消费者健康应用程序和 HIPAA：一个常见的误解是所有健康应用程序均受 HIPAA 约束。如果消费者直接下载您的应用程序并输入他们自己的健康数据（没有涉及实体的参与），HIPAA 通常不适用于该数据。但是，如果医院将您的应用程序部署给患者，您就成为 BA。 FTC 健康违规通知规则（2024 年更新）适用于消费者健康应用，无论 HIPAA 状态如何。

---

受保护的健康信息：18 个标识符

PHI 是与个人过去、现在或未来的身体或心理健康状况、医疗保健提供或医疗保健付款相关的个人可识别健康信息。以下 18 个标识符与健康信息结合起来构成 PHI：

1. 姓名
2. 小于州的地理数据（地址、邮政编码、地理编码）
3. 与个人相关的日期（年份除外）（出生日期、入院日期、出院日期、死亡日期）
4. 电话号码
5. 传真号码
6. 电子邮件地址
7. 社会安全号码
8. 病历号码
9. 健康计划受益人号码
10. 账号
11. 证书或执照号码
12. 车辆识别码（VIN、车牌）
13. 设备标识符和序列号
14. 网址 15.IP地址
15. 生物特征识别（指纹、声纹）
16. 全脸照片和类似图像
17. 任何其他唯一的识别号码、特征或代码

去识别化去除所有18个标识符，需要专家判定或统计验证，重新识别风险很小。去识别化数据不是 PHI，也不属于 HIPAA 的范围——这是健康分析平台的一个重要架构考虑因素。

---

HIPAA 隐私规则

隐私规则（45​​ CFR 第 164 部分，子部分 A 和 E）管辖 PHI 的使用和披露方式。

未经授权允许的使用和披露：

• 治疗、支付和医疗保健运营 (TPO) — 核心目的例外
• 公共卫生活动（向州卫生部门报告疾病）
• 虐待、忽视或家庭暴力的受害者举报
• 健康监督活动（CMS 审核、OCR 调查）
• 司法和行政诉讼（具有适当的法律程序）
• 执法（有限情况）
• 对健康或安全造成严重威胁
• 基本政府职能

需要个人授权的使用和披露：

• 使用 PHI 进行营销
• 出售 PHI
• 大多数研究用途（除非获得 IRB 豁免）
• 上述允许类别之外的任何用途

最低必要标准：当出于治疗以外的目的披露 PHI 时，您必须做出合理努力，将披露限制在该目的所需的最低限度。这也适用于 BA——您的平台应该只处理您的特定功能所需的 PHI 元素。

隐私规则下的患者权利：

• 有权访问其 PHI（30 天内；2021 年规则消除了许多访问障碍并降低了费用）
• 有权修改他们认为不准确的 PHI
• 对披露进行会计处理的权利（在 TPO 之外，过去 6 年）
• 要求限制某些用途的权利
• 保密通讯的权利
• 选择退出设施目录的权利

---

HIPAA 安全规则

安全规则（45​​ CFR 第 164 部分，子部分 A 和 C）特别适用于电子 PHI (ePHI)，并要求所涵盖的实体和 BA 实施管理、物理和技术保障措施。

行政保障

安全官：指定一名负责 HIPAA 安全策略制定和实施的人员。记录此指定。

员工培训：对所有员工进行 HIPAA 政策和程序培训。维护带有完成日期的培训记录。

访问管理程序：记录员工对 ePHI 的访问权限是如何授权、建立、修改和终止的。

安全意识培训：对所有用户进行与其角色相关的安全主题培训：网络钓鱼识别、密码卫生、报告事件。

应急计划：制定记录的数据备份计划、灾难恢复计划、紧急模式操作计划以及测试和修订程序。

评估：定期对您的安全防护措施满足安全规则要求的程度进行技术和非技术评估。

物理保障

设施访问控制：实施政策，限制授权人员对包含 ePHI 的设施和系统进行物理访问。对于基于云的部署，此义务将转移给您的云提供商（需要 BAA）。

工作站使用：记录在可访问 ePHI 的工作站上执行的适当功能及其周围环境的物理属性。

设备和媒体控制：包含 ePHI 的硬件和电子媒体移动的文档程序；移动前数据备份；处置前数据擦除/销毁。

技术保障

访问控制：实施技术机制以仅允许授权人员访问 ePHI：

• 所有 ePHI 系统用户的唯一用户标识
• 紧急通道程序
• 闲置一段时间后自动注销
• 加解密能力

审核控制：实施硬件、软件和程序机制来记录和检查包含 ePHI 的系统中的访问和活动。审核日志保留至少 6 年。

完整性控制：实施机制来证实 ePHI 未被以未经授权的方式更改或破坏。校验和、数字签名或同等内容。

传输安全：实施技术安全措施，防止对通过网络传输的 ePHI 进行未经授权的访问。适用于所有 ePHI 传输的 TLS 1.2+。

加密：虽然技术上是“可寻址的”（不是无条件要求），但考虑到替代文档负担，静态和传输中的 ePHI 加密被认为是标准做法，并且事实上是必需的。使用 AES-256 传输静态数据，使用 TLS 1.2+ 传输数据。

---

业务伙伴协议

BAA 是与业务伙伴共享 PHI 之前所需的书面合同。它必须包括：

• BA 允许和要求使用和披露 PHI 的规范
• 要求 BA 不得使用或披露 PHI，除非合同允许或要求
• 要求 BA 实施适当的保障措施以防止未经授权的使用或披露
• 要求向 CE 报告任何违反或涉嫌违反 PHI 的行为
• 要求确保分包商同意相同的限制
• CE 的访问、修改和记账权
• 所有 PHI 终止、返还或销毁时（或者如果不可行，则继续保护）

需要避免的关键 BAA 差距：

• 没有提及分包商链（您的 BA 使用 AWS — AWS 必须与您或您的 BA 一起拥有自己的 BAA）
• BAA 仅限于特定服务，而不是根据该关系收到的所有 PHI
• 未指定违规通知期限
• 没有明确声明允许的用途
• 终止时无销毁/归还义务

主要云提供商（AWS、Azure、Google Cloud）为其医疗保健客户提供 BAA - AWS 的 BAA 涵盖符合 HIPAA 要求的特定服务列表。验证堆栈中涉及 ePHI 的每项服务都包含在 BAA 中。

---

违规通知规则

根据 HITECH 修订的违规通知规则（45 CFR 第 164 部分，D 子部分），涵盖实体必须通知：

1. 受影响的个人：在发现漏洞后 60 个日历日内，不得无故拖延。一流的邮件（或电子邮件，如果个人选择加入）。必须包括所发生事件的描述、涉及的 PHI 类型、个人应采取的步骤以及联系信息。

2. HHS (OCR)：如果违规行为影响到 500 多人，请通过 HHS 门户网站与个人同时通知（60 天内）。如果少于 500 个，请维护日志并于次年 3 月 1 日之前提交。

3. 媒体：如果违规行为影响到某个州或司法管辖区的 500 多名居民，请通知服务该地区的知名媒体（以及个别通知）。

BA 必须在发现后 60 天内立即通知所涵盖的实体，不得无故拖延。

违规推定：根据 HITECH，任何未经许可的 PHI 访问、使用或披露均被推定为违规，除非 CE 或 BA 使用四因素风险评估证明 PHI 受到损害的可能性很低：(1) PHI 的性质和范围，(2) 谁使用或访问了它，(3) PHI 是否实际获取或查看，(4) 风险已降低的程度。

加密的安全港：解密密钥未受损的加密 ePHI 违规行为被排除在违规通知要求之外，这使得静态 ePHI 加密成为一种特别强大的风险缓解策略。

---

HIPAA 技术实施清单

• PHI 清单已完成 — 所有数据元素、系统和流程均已记录
• 去识别化分析已完成 - 在适合去识别化的情况下将 PHI 最小化
• HIPAA 指定安全官员并记录在案
• 风险分析已完成并记录（§164.308(a)(1) 要求）
• 实施风险管理计划
• 与所有处理 ePHI 的供应商签署 BAA（云提供商、分析工具、电子邮件服务）
• 使用唯一用户 ID 为所有 ePHI 系统用户实施访问控制
• 对所有 ePHI 系统访问强制执行 MFA
• 在所有 ePHI 系统上启用审核日志记录（保留 6 年）
• 配置自动会话超时（最长 15 分钟）
• ePHI 静态加密 (AES-256) 和传输加密 (TLS 1.2+)
• 备份和灾难恢复程序已记录并经过测试
• 员工 HIPAA 培训已完成并记录
• 记录事件响应/违规通知程序
• 向患者发布并提供隐私声明 (NPP)
• 实施患者权利程序（访问、修改、核算）
• 分包商协议适当级联 HIPAA 义务

---

常见问题

我们的远程医疗应用程序需要遵守 HIPAA 吗？

如果您的远程医疗应用程序促进患者与 HIPAA 涵盖的实体（医生、医院、健康计划）之间的沟通，并且您在此过程中处理 PHI，那么您几乎肯定是受 HIPAA 约束的业务伙伴。分析取决于您是否代表涵盖实体创建、接收、维护或传输 PHI。如果您的应用程序的用户仅相互交互（不涉及 CE 的消费者健康应用程序），HIPAA 可能不适用，但 FTC 健康违规通知规则可能适用。

违反 HIPAA 的处罚是什么？

HIPAA 下的民事罚款按罪责分级： 未知违规（每次违规 100 至 50,000 美元，每年上限 25,000 美元）；合理原因（每次违规罚款 1,000 美元至 50,000 美元，年度上限为 100,000 美元）；故意疏忽已得到纠正（$10,000–$50,000，$250,000 年度上限）；未纠正的故意疏忽（每次违规罚款 50,000 美元，每个相同违规类别的年度上限为 150 万美元）。明知披露并意图出售 PHI 的刑事处罚（通过 DOJ）可包括最高 10 年监禁。

我们可以将 ePHI 存储在 AWS 或 Azure 中吗？

是的，有 BAA。 AWS 和 Azure 都提供涵盖符合 HIPAA 要求的特定服务的 BAA。对于 AWS，请验证您的架构中的每项服务是否均列在符合 HIPAA 要求的服务的 AWS BAA 附表中 — 某些服务（如某些 Lambda 层、某些 S3 功能）可能不包括在内。您的团队仍然负责安全地配置这些服务； BAA 转移了一些法律责任，但不会自动使您的实施符合要求。

最低必要标准是什么？它如何影响应用程序设计？

最低必要标准要求您仅访问、使用或披露特定目的所需的 PHI 元素。在实践中，这意味着：如果您的分析功能仅需要去识别化的聚合数据，则不要提取完整的患者记录；如果您的计费功能需要索赔数据，则它不应该访问临床记录。设计您的系统以按角色和功能（而不仅仅是按策略）强制执行数据最小化。基于角色的访问控制和按功能进行数据分段是主要的技术实现。

HIPAA 如何与全球数字健康平台的 GDPR 互动？

它们并行运行。 HIPAA 适用于美国医疗保健数据，无论其在何处处理。 GDPR 适用于欧盟居民的个人数据，无论控制者或处理者位于何处。如果您有欧盟患者数据，则两者可以同时适用。 GDPR 的法律依据和数据主体权利是独立于 HIPAA 的最低必要义务和患者权利条款的义务。实际含义：您可能需要使用符合这两个框架的流程来满足同一患者的 HIPAA 患者访问请求和 GDPR 主题访问请求。

我们的营销分析工具是 HIPAA 业务伙伴吗？

如果收到 ePHI，则可能是的。许多数字健康公司无意中通过 URL 参数、事件元数据或包含 PHI 的用户属性标签与分析工具（Google Analytics、Mixpanel、Amplitude）共享 PHI。这引发了 2022 年至 2023 年针对使用将 PHI 发送到 Meta 和 Google 的跟踪像素的医院的重大 OCR 执法行动。审核所有分析集成，确保 PHI 不会流向没有 BAA 的分析工具，并考虑使用仅对聚合或去识别化数据进行操作的隐私保护分析。

---

后续步骤

构建符合 HIPAA 要求的数字健康平台需要从一开始就做出仔细的架构决策 - 将安全和隐私控制改造到现有系统中比内置它们要昂贵得多。ECOSIRE 的团队可以帮助您为数字健康平台设计、实施和记录符合 HIPAA 的技术架构。

我们的经验涵盖患者门户开发、EHR 集成架构、远程医疗后端系统和健康分析平台——所有这些都以 HIPAA 合规性作为基本设计约束来实施。

了解更多：ECOSIRE 服务

免责声明：本指南仅供参考，不构成法律建议。 HIPAA 要求既复杂又具体。聘请合格的医疗保健法律顾问和 HIPAA 合规官员，以获得针对您的组织的指导。