HIPAA业务关联协议(BAA):模板与完整指南
如果您正在开发涉及受保护健康信息的软件——在2026年，这涵盖了大量SaaS产品、患者门户、远程医疗平台，甚至营销工具——您需要一份业务关联协议。不是"应该有"。而是"需要"。如果处理不当，罚款从每次违规141美元起，最高可达每个违规类别每年2,134,831美元。这不是打字错误。
我曾在医疗相关项目上工作过，BAA讨论发生得太晚了。团队构建了整个平台，到了合规审查时才意识到他们的云提供商没有BAA，他们的分析工具在没有BAA的情况下摄取PHI，他们的日志服务以纯文本存储患者数据。这是一团糟。这份指南是我第一次作为开发人员处理HIPAA合规时，希望有人能交给我的内容。
我们将涵盖BAA实际上是什么(以及不是什么)、谁需要它、其中必须包含什么，以及提供一个实用的模板供您调整。无论您是评估供应商的涵盖实体，还是试图了解您义务的业务关联，这都是您需要的指南。
目录
- 什么是业务关联协议?
- 谁需要BAA?
- 涵盖实体vs业务关联vs分包商
- HIPAA BAA的必需组成部分
- 带注释的BAA模板
- 使BAA失效的常见错误
- 技术实施考虑事项
- 监测和执行您的BAA
- 按供应商类型的BAA要求
- 常见问题
什么是业务关联协议?
业务关联协议(BAA)是HIPAA要求的具有法律约束力的合同，由涵盖实体(想想:医院、健康计划、医疗清算机构)与任何第三方(业务关联)之间签署，该第三方代表涵盖实体创建、接收、维护或传输受保护的健康信息(PHI)。
法律基础来自45 CFR § 164.502(e)和§ 164.504(e)。HIPAA隐私规则强制要求这些协议。安全规则增加了特定于电子PHI(ePHI)的要求。在HITECH法案和2013年综合规则之后，业务关联成为直接承担HIPAA合规责任的方——不仅通过BAA在合同上承担责任，而且直接受民权办公室(OCR)的执法约束。
以下是BAA"不是"的内容:它不是一个选中的框。它不是您下载、签署然后忘记的东西。BAA建立了特定的义务，限制PHI的使用和披露方式，定义了违规通知程序，并创建了审计权。如果您将其视为标准条款，您就为自己设置了麻烦。
为什么BAA在2026年更重要
执法格局已发生重大变化。OCR一直在加强审计和和解。在2024年，他们与多个案件达成了和解，这些案件特别涉及处理ePHI的多个供应商缺少或不足的BAA——包括与一个未能与多个处理ePHI的供应商签订BAA的卫生系统签署的155万美元和解。这一趋势已继续进入2025年和2026年，对云服务、AI工具和网络跟踪技术的审查日益增加。
2022年12月OCR关于跟踪技术的公告(在2023年更新)明确指出，即使是网站分析和像素跟踪，如果收集PHI——包括IP地址与来自预约排期页面的健康状况信息的组合——也会触发BAA要求。
谁需要BAA?
这是事情变得棘手的地方，也是我看到最多混淆的地方。
涵盖实体必须与每个业务关联签订BAA。涵盖实体是:
- 以电子方式传输健康信息的医疗提供者
- 健康计划(保险公司、健康维护组织、医疗保险、医疗补助)
- 医疗清算机构
业务关联是代表涵盖实体执行涉及PHI的功能或活动的个人或组织。这包括:
- 有权访问ePHI的IT服务提供商
- 存储PHI的云主机提供商
- 账单和索赔处理公司
- EHR/EMR供应商
- 处理健康数据的数据分析公司
- 访问PHI的律师事务所和会计师
- 碎纸和文件存储公司
- 需要访问PHI的顾问
- 构建患者端应用程序的网络开发人员(是的，当我们在Social Animal构建医疗保健平台时，这包括我们)
业务关联的分包商也需要BAA。如果您是业务关联，并且您聘用云提供商来托管您正在处理的PHI，您需要与该提供商签订BAA。这是2013年综合规则的重大变化。
谁不需要BAA?
并非所有供应商关系都需要BAA:
- 导管例外:仅传输PHI(如邮政服务或互联网服务提供商)而不访问PHI的实体不需要BAA。
- 雇佣关系:您自己的员工不是业务关联——他们是您员工队伍的成员。
- 患者指导的披露:如果患者要求您将他们的记录发送到特定应用，该应用不是您的业务关联(尽管这在TEFCA和健康信息交换中变得复杂)。
- 供应商之间的治疗目的:当一个供应商与另一个供应商分享PHI用于治疗时，这不是一个BA关系。
涵盖实体vs业务关联vs分包商
理解责任链至关重要。以下是关系如何分解的:
| 角色 | 示例 | 需要与之签署BAA的对象 | 直接HIPAA责任? |
|---|---|---|---|
| 涵盖实体 | 医院、健康计划、清算机构 | 所有业务关联 | 是——完全责任 |
| 业务关联 | EHR供应商、云主机、账单公司 | 涵盖实体(上游) + 分包商(下游) | 是——自2013年综合规则以来 |
| 分包商 | BA下的云基础设施、子聘开发人员 | 业务关联(上游) | 是——自2013年综合规则以来 |
| 导管 | ISP、邮政服务、快递 | 无 | 否(导管例外) |
| 员工队伍成员 | 员工、志愿者、实习生 | 无(不是BA) | 否(由实体政策覆盖) |
该链可以深入多个级别。一家医院使用EHR供应商(BA)。EHR供应商使用AWS(分包商/BA)。AWS使用特定的基础设施合作伙伴。链中的每一个环节都需要一个BAA。
HIPAA BAA的必需组成部分
HHS提供了必须包含的内容指导，并发布了值得审查的更新模型BAA。以下是强制和建议的组成部分:
强制元素(根据45 CFR § 164.504(e))
允许的使用和披露:明确说明BA可以如何处理PHI。这必须限于合同中的内容、法律要求或隐私规则以其他方式允许的内容。
禁止未经授权的使用/披露:BA不能以协议未许可的方式使用或披露PHI。
保护措施要求:BA必须使用适当的保护措施——特别是为ePHI实施安全规则要求——以防止未经授权的使用或披露。
报告义务:BA必须报告任何协议未提供的使用或披露，包括安全事件和违规。
分包商义务:BA必须确保任何处理PHI的分包商同意相同的限制和条件。
PHI访问:BA必须使PHI对涵盖实体(或直接对个人)可用，以满足个人在45 CFR § 164.524下的访问权利。
PHI修正:BA必须使PHI可用于修正，并在涵盖实体指示时纳入修正。
披露会计:BA必须提供信息来说明按照45 CFR § 164.528要求的披露会计。
HHS访问:BA必须使其实践、簿籍和记录对HHS可用以进行合规性确定。
PHI的退回或销毁:协议终止时，BA必须退回或销毁所有PHI。如果这不可行，保护必须延续到终止之后。
终止条款:涵盖实体必须能够在BA违反协议的实质性条款时终止协议。
建议(但明智)的补充
- 违规通知时间表:HIPAA要求BA在"合理不延迟"的情况下报告违规给CE，最迟60天。但60天是一个很长的时间。聪明的协议指定更短的窗口——5到10个工作日很常见。
- 网络保险要求:越来越标准。指定最低覆盖金额。
- 审计权:超越HHS要求，给自己审计或请求SOC 2 + HIPAA报告的权利。
- 赔偿条款:出问题时谁支付费用?
- 数据驻留要求:PHI将存储在哪里?这对州法律也很重要。
- 培训要求:要求BA培训其员工关于HIPAA。
- 加密标准:指定最低加密(静止时AES-256，传输中TLS 1.2+)。
带注释的BAA模板
这是一个实用的BAA模板结构。这不是法律建议——您需要律师为您的具体情况完成任何BAA。但这基于HHS模型协议和我见过有效的真实实施提供了坚实的起始框架。
业务关联协议
本业务关联协议("BAA")由以下双方在[日期]订立:
[涵盖实体名称],一个[州][实体类型]("涵盖实体")
和
[业务关联名称],一个[州][实体类型]("业务关联")
(统称为"各方")
前言
鉴于,涵盖实体是根据45 CFR § 160.103定义的HIPAA涵盖实体;
鉴于,业务关联为涵盖实体执行涉及受保护健康信息(PHI)的创建、接收、维护或传输的某些功能或活动;
鉴于,各方意图遵守1996年《健康保险可携带和责任法案》(HIPAA)、《健康信息技术促进经济和临床健康法案》(HITECH)及其实施条例;
现在,各方同意如下:
---
第1节:定义
本BAA中使用但未定义的条款应具有45 CFR第160和164部分中指定的含义。
"违规"应具有45 CFR § 164.402中给出的含义。
"指定记录集"应具有45 CFR § 164.501中的含义。
"PHI"是指45 CFR § 160.103中定义的受保护健康信息。
"ePHI"是指电子受保护健康信息。
"安全事件"应具有45 CFR § 164.304中的含义。
"分包商"应具有45 CFR § 160.103中的含义。
---
第2节:业务关联的义务
2.1允许的使用和披露。业务关联应仅按本BAA许可或要求、基础服务协议或法律要求的方式使用或披露PHI。
2.2保护措施。业务关联应实施行政、物理和技术保护措施,这些措施合理且恰当地保护ePHI的机密性、完整性和可用性,符合45 CFR第164部分C分编。
[注释:这里要具体。考虑添加最低要求,如静止时AES-256加密、传输中TLS 1.2+、管理访问MFA等。]
2.3报告。业务关联应向涵盖实体报告:
(a)本BAA未提供的PHI的任何使用或披露,在发现后[5/10]个工作日内;
(b)任何安全事件,在发现后[5/10]个工作日内;
(c)任何未受保护PHI的违规,在发现后[10]个工作日内,包括45 CFR § 164.410(c)要求的信息。
[注释:HIPAA默认值为60天。您希望这更短。10个工作日是激进的但可实现的。一些组织已达到确认违规的48小时。]
2.4分包商。业务关联应与代表业务关联创建、接收、维护或传输PHI的任何分包商达成书面协议,包含基本相同的限制和条件如本BAA。
2.5访问。业务关联应在指定记录集中提供PHI,在接到请求后[15]个工作日内,使涵盖实体能够履行其在45 CFR § 164.524下的义务。
2.6修正。业务关联应使PHI可用于修正,并在涵盖实体指示后[30]天内在指定记录集中纳入对PHI的修正。
2.7披露会计。业务关联应记录并提供根据45 CFR § 164.528进行披露会计所需的信息。
2.8记录可用性。业务关联应向HHS秘书提供其与PHI的使用和披露相关的内部实践、簿籍和记录,以确定合规性。
2.9最小必要。业务关联应将其对PHI的使用、披露或请求限制为完成预期目的的最小必要,符合45 CFR § 164.502(b)。
2.10培训。业务关联应确保其处理PHI的所有员工队伍成员在招聘时和之后每年接收适当的HIPAA培训。
2.11审计报告。根据请求,业务关联应向涵盖实体提供其最新SOC 2 + HIPAA报告、HITRUST认证或其他双方同意的独立第三方审计报告的副本。
---
第3节:允许的使用和披露
3.1业务关联可仅为执行基础服务协议中描述的服务目的使用或披露PHI。
3.2业务关联可按法律要求使用或披露PHI。
3.3业务关联可为其适当的管理和行政或执行其法律责任使用PHI,前提是披露法律要求或业务关联从接收者获得合理保证。
3.4业务关联可按45 CFR § 164.504(e)(2)(i)(B)许可提供数据聚合服务使用PHI。
3.5业务关联可按45 CFR § 164.514(a)-(c)去识别PHI。
---
第4节:涵盖实体的义务
4.1涵盖实体应通知业务关联其隐私实践通知中可能影响业务关联使用或披露PHI的任何限制。
4.2涵盖实体应通知业务关联其隐私实践通知中的任何变化或撤销。
4.3涵盖实体应通知业务关联涵盖实体在45 CFR § 164.522下同意的对PHI使用或披露的任何限制。
---
第5节:期限和终止
5.1本BAA自上面首次书写之日起生效,并应继续直到基础服务协议终止或按以下规定终止。
5.2如果涵盖实体确定业务关联违反了本BAA的实质性条款,涵盖实体可以终止本BAA和基础服务协议。
5.3终止时,业务关联应退回或销毁从涵盖实体收到的所有PHI或代表涵盖实体创建/接收的PHI。如果退回或销毁不可行,业务关联应将本BAA的保护延伸到此类PHI,并将进一步使用和披露限制为使退回或销毁不可行的那些目的。
---
第6节:杂项
6.1赔偿。[根据谈判自定义]
6.2保险。业务关联应维持网络责任保险,最低覆盖额为$[金额]。
6.3管辖法。[州]
6.4修正。本BAA仅可以书面修正。
6.5生存。与PHI的退回/销毁和赔偿相关的条款应在终止后继续有效。
这是一个起点。您的医疗保健律师将希望根据您的特定使用情况、州法律(某些州如加利福尼亚、德克萨斯和纽约有额外的卫生隐私要求)和提供的服务性质自定义它。
使BAA失效的常见错误
我已经审查过数十份BAA,这些错误不断出现:
1.使用未自定义的通用模板
从互联网上获取模板而不根据您的实际关系定制允许的使用和披露。用于云托管提供商的BAA看起来与用于账单服务的BAA非常不同。
2.未能包含分包商要求
在2013年之后,这是强制性的。如果您的BAA没有解决分包商,就是不足的。我见过来自大型SaaS公司的BAA完全忽略了这一点。
3.没有违规通知时间表
依赖默认的60天窗口是个坏主意。到您在第59天听说违规时,您已经失去了关键的事件响应时间。指定更短的时间表。
4.未在共享PHI之前执行BAA
这似乎是显而易见的,但它经常发生。一个开发人员启动一个新的分析工具,开始从患者门户收集数据,没有人考虑BAA直到几个月后。PHI已经在流动。您已经在违反。
5.忘记更新BAA
条例改变。服务改变。您的2019 BAA可能不反映当前要求。至少每年审查一次。
6.混淆BAA和数据处理协议(DPA)
GDPR的DPA和HIPAA的BAA是具有不同要求的不同工具。拥有一个不满足另一个。如果您处理来自也是美国系统中的患者的欧盟个人的数据,您可能需要两者。
技术实施考虑事项
作为构建医疗保健应用程序的开发人员,BAA对您的架构有直接影响。以下是协议在实践中意味着什么:
基础设施要求
# 示例:HIPAA-合格的AWS服务配置
# 并非所有AWS服务都在其BAA下被覆盖
# ✅ AWS BAA下覆盖
services:
compute: [EC2, ECS, EKS, Lambda, Fargate]
storage: [S3, EBS, EFS, Glacier]
database: [RDS, DynamoDB, Aurora, Redshift]
networking: [VPC, CloudFront, Route 53, API Gateway]
security: [KMS, CloudTrail, CloudWatch, GuardDuty]
# ❌ AWS BAA下未覆盖(截至2026年)
# 始终检查当前列表:
# https://aws.amazon.com/compliance/hipaa-eligible-services-reference/
主要云提供商——AWS、Google Cloud和Microsoft Azure——都提供BAA,但您必须显式启用它们。在AWS上,您通过AWS Artifact启用它。在Google Cloud上,您通过您的组织设置接受BAA。在Azure上,它是符合条件服务的在线服务条款的一部分。
加密要求
您的BAA可能指定加密。以下是它在实践中的样子:
# 静止时加密 - 最低AES-256
# 传输中加密 - 最低TLS 1.2
# 示例:在数据库存储前加密PHI
from cryptography.fernet import Fernet
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC
import base64, os
def derive_key(password: bytes, salt: bytes) -> bytes:
kdf = PBKDF2HMAC(
algorithm=hashes.SHA256(),
length=32, # AES-256
salt=salt,
iterations=600_000, # OWASP 2023建议
)
return base64.urlsafe_b64encode(kdf.derive(password))
def encrypt_phi(data: str, key: bytes) -> bytes:
f = Fernet(key)
return f.encrypt(data.encode())
访问控制和审计日志
您的BAA承诺您实施访问控制和维护审计日志。对PHI的每次访问都应记录谁访问了它、何时访问以及为什么。这不是可选的——这是您在OCR审计期间如何证明合规性的方式。
如果您在Next.js或另一个现代框架上构建,在API层实施基于角色的访问控制,并将审计日志作为中间件。不要依赖客户端控制。
监测和执行您的BAA
签署BAA是第一步。监测合规是持续的工作。
年度审查流程
- 清点所有BAA:维护所有活跃BAA的集中寄存器,包括业务关联名称、提供的服务、访问的PHI类型、生效日期和最后审查日期。
- 请求审计报告:要求提供SOC 2 Type II + HIPAA报告、HITRUST认证或等效的第三方评估年度。
- 验证分包商链:确认您的BA具有与其分包商的BAA。
- 为监管变化更新:HIPAA法规在演变。HHS对HIPAA隐私规则的建议修改仍在2026年最后确定中,可能需要BAA更新。
- 记录所有内容:如果OCR敲门,您的文档就是您的防御。
风险评估
根据每个业务关联访问的PHI数量和敏感性进行风险评估。不是所有BA关系都承担相等的风险。您的EHR供应商访问数百万条记录需要比文件碎纸公司更多的审查。
| 风险因素 | 低风险 | 中等风险 | 高风险 |
|---|---|---|---|
| PHI数量 | < 500条记录 | 500-50,000条记录 | > 50,000条记录 |
| PHI类型 | 去识别数据 | 有限数据集 | 完整PHI与SSN |
| 访问类型 | 仅加密存储 | 读取访问 | 读取/写入访问 |
| 位置 | 本地,仅US | US云 | 多地区/离岸 |
| 审计报告 | SOC 2 Type II当前 | SOC 2 Type I | 无独立审计 |
按供应商类型的BAA要求
以下是常见供应商关系的实用分解及其BAA要求:
| 供应商类型 | 需要BAA? | 常见陷阱 |
|---|---|---|
| 云托管(AWS, GCP, Azure) | 是 | 必须显式激活;并非所有服务都符合条件 |
| EHR/EMR供应商 | 是 | 验证分包商链 |
| 电子邮件服务(如果发送PHI) | 是 | 大多数标准电子邮件提供商不签署BAA;使用HIPAA-合规的电子邮件服务 |
| 网站分析 | 也许 | 如果跟踪技术收集PHI(IP +健康状况),是 |
| 支付处理器 | 是(如果他们看到PHI) | Stripe,例如,有医疗保健的BAA |
| 网络开发机构 | 是(如果在开发过程中访问PHI) | 使用合成测试数据以避免此要求在开发阶段 |
| 文件存储/碎纸 | 是 | 经常被忽视 |
| 法律顾问 | 是(如果访问PHI) | 律师不会自动免除 |
| 应答/电话服务 | 是 | 他们在呼叫中听到PHI |
| AI/ML工具 | 是 | 一个快速发展的领域——对基于LLM的工具要非常小心 |
对于网络开发具体而言,如果我们在Social Animal构建无头CMS驱动的医疗保健门户,我们构建项目以最小化开发过程中的PHI暴露。合成测试数据、环境隔离和PHI-free分段环境意味着我们通常可以避免在开发阶段需要BAA,同时仍然交付HIPAA-ready的生产系统。
常见问题
什么是HIPAA业务关联协议? BAA是HIPAA下法律要求的合同(45 CFR § 164.504(e)),在涵盖实体和任何创建、接收、维护或代表涵盖实体传输受保护健康信息的第三方之间签署。它建立了业务关联可以和不能对PHI做什么,要求适当的保护措施,并定义违规通知程序。没有它,无论是否实际发生违规,双方都违反了HIPAA。
谁负责启动BAA——涵盖实体还是业务关联? 法律义务落在涵盖实体身上,以确保与所有业务关联的BAA到位。然而,在实践中,许多业务关联(特别是SaaS供应商)已经准备了标准BAA。任何一方都可以启动对话,但如果BAA不存在,涵盖实体承担监管风险。业务关联也有义务确保与其自己的分包商的BAA到位。
我可以按原样使用HHS模型BAA模板吗? HHS发布的更新模型BAA是一个坚实的起点,但它明确描述为模型——不是一个适用于所有人的文件。您应该为您的特定关系、服务、PHI类型和风险概况自定义它。需要自定义的关键领域包括违规通知时间表(HHS模型使用60天最大值,大多数组织缩短),特定安全要求,和赔偿条款。始终让医疗保健律师审查您的最终版本。
如果业务关联违反BAA会发生什么? 涵盖实体必须采取合理措施来补救违规。如果违规无法补救,涵盖实体必须终止BAA和基础合同,或者如果终止不可行,向OCR报告问题。除了合同救济外,业务关联面临直接HIPAA责任,因为2013年综合规则——意味着OCR可以直接调查和处罚BA。罚款范围从141美元到每个违规类别每年2,134,831美元(2026年调整金额),加上对知情违规的潜在刑事处罚。
网络开发人员或机构是否需要BAA? 取决于开发人员是否访问、存储或传输PHI。如果您正在构建患者门户,您的开发环境使用真实患者数据,是的——您需要一个BAA。如果您正在构建应用程序但使用合成测试数据并且从不接触实际PHI,您可能不需要开发阶段的BAA。但是,处理生产中PHI的生产托管和任何服务绝对需要BAA。这是为什么环境隔离和合成数据策略在医疗保健应用程序开发期间很重要。
BAA应该多久审查和更新一次? 至少每年一次。每当提供的服务有实质性变化、适用法规有变化、涉及业务关联的安全事件或BA的分包商链有变化时,您还应该审查BAA。HHS已提出对HIPAA隐私规则的更新建议,一旦最终确定,可能需要现有BAA的更新。维护日历提醒并将BAA审查纳入您的年度合规工作流。
即使我加密所有内容,我也需要与云提供商签署BAA吗? 是的。加密不会消除BAA要求。即使PHI被加密且云提供商无法读取,提供商仍在维护ePHI。AWS、Google Cloud和Azure都提供BAA——您只需要显式激活它们。一个狭隘的例外是仅传输数据的实体(如ISP)的"导管"例外,但存储数据的云提供商不符合导管例外资格。
BAA和数据处理协议(DPA)之间的区别是什么? BAA是美国HIPAA要求,管理受保护的健康信息。DPA通常是GDPR要求,管理欧盟/欧洲经济区个人的个人数据。他们在不同的监管框架下服务相关但不同的法律目的。拥有DPA不满足BAA要求,反之亦然。如果您的组织处理也是美国系统中患者的欧盟个人的健康数据——例如,一个与欧盟患者合作的美国卫生系统——您可能需要与同一供应商签署两个协议。一些供应商提供合并协议,但确保每个监管要求都独立满足。