一家医疗初创公司在2023年初给我打了电话。创始人不错，预算充足，简报清晰：患者就诊表单、预约调度，也许以后还会加入远程医疗小工具。"我们用的是WP Engine，"CTO告诉我。我问WP Engine是否已签署他们的BAA。长时间的沉默。"BAA是什么？"
问题就出在这里——不在代码中，不在插件堆栈中，而在于大多数开发人员从不阅读、大多数主机悄悄回避的文件记录中。
关键是：HIPAA合规性不是你可以切换的功能。它是一个法律框架，而业务伙伴协议是使你的托管提供商成为该框架正式部分的合同。如果没有签署的BAA，即使你的服务器运行TLS 1.3，你已加密数据库中的每个字段，也没关系。你仍然有风险。你的客户也是。
让我逐步讲解我真正了解的关于哪些平台在2026年会签署，以及——更重要的是——哪些平台说对了话但不会签署。
---
BAA 实际是什么（以及不是什么）
业务关联协议是 HIPAA 隐私规则下的合同，将供应商与受保护健康信息 (PHI) 相关的具体义务联系在一起。当你托管医疗保健网站时，你的托管提供商会接触 PHI —— 即使只是在基础设施层面。这使得他们成为业务关联方。就这么简单。Business Associate Agreementis a contract under the HIPAA Privacy Rule that binds a vendor to specific obligations around Protected Health Information (PHI). When you host a healthcare site, your hosting provider touches PHI — even if only at the infrastructure layer. That makes them a Business Associate. Full stop.
BAA 的作用不是自动让你合规。我经常看到这个被误解。BAA 意味着主机接受其责任份额并同意采取保障措施。你的应用层、你的表单、你的 WordPress 插件、你的日志 —— 那些都由你负责。theirshare of liability and agrees to safeguards. Your application layer, your forms, your WordPress plugins, your logging — that's still on you.
Seahawk 在 2022 年有一个项目是为一个美国的物理治疗组织运营一个 WordPress 网站。客户与他们的电子邮件提供商签订了 BAA（很好），与 EHR 供应商签订了 BAA（显然），但与网络主机没有签订任何协议。他们的网站通过 Gravity Forms 收集症状数据。每个提交都被发送到 Gmail 账户。一个工作流中的三个独立违规。我们花了大约六周时间才理清这一切。
---
2026 年实际会签署的主机商
AWS、GCP 和 Azure —— 严肃的选择
如果你需要 BAA 并且需要确定性，超大规模云服务商是你的答案。这三个 —— Amazon Web Services、Google Cloud Platform 和 Microsoft Azure —— 都提供 BAA 并维护 HIPAA 合格服务列表。Amazon Web Services, Google Cloud Platform, and Microsoft Azure — offer BAAs and maintain lists of HIPAA-eligible services.
AWS 是我最常选择的。BAA 涵盖了一系列扎实的服务：EC2、RDS、S3、CloudFront、Lambda 等等。至关重要的是，并非每个 AWS 服务都符合条件。DynamoDB 在列表中；并非所有实验性服务都在。在你进行任何架构设计之前，你必须查看当前的合格服务页面。
GCP 的 BAA 涵盖 BigQuery、Cloud SQL、Compute Engine 和 Cloud Storage 等服务。Azure 在医疗保健领域拥有最广泛的企业采用 —— 他们的 BAA 和合规文档成熟，如果你的客户已经在 Microsoft 生态系统中（大多数企业医疗保健组织都是如此），Azure 通常在组织上是有意义的。
这三个平台都有个问题：你得到的不是托管型 WordPress。你得到的是基础设施。必须有人来构建和维护整个堆栈——操作系统补丁、WAF 配置、备份、静态加密和传输加密。在 Seahawk，我们为医疗保健客户使用了 AWS，配置了加固的 EC2 实例，运行 Nginx、PHP-FPM 和 MySQL。这套方案可行。但比起直接给某人一个 WP Engine 登录账号，运维开销要大得多。
Kinsta——有条件可以
Kinsta 运行在 GCP 上。他们为更高级别计划（Business 1 及以上，最后一次检查时如此）的客户提供 BAA 签署。这很重要，因为 Kinsta 确实是一流的托管型 WordPress 主机。快速。可靠。很好的测试环境。
但是——这值得强调——Kinsta 的 BAA 覆盖范围比你直接使用 GCP 要窄一些。你依赖的是 Kinsta 的内部控制和 GCP 的控制。对于很多医疗保健 WordPress 项目，这就足够了。但如果涉及大量极为敏感的数据，在承诺之前，我会想精确了解他们的安全文档都说了什么。
Cloudways——不行
Cloudways 在代理商圈子里很受欢迎。性价比不错。我们在几十个非敏感项目上用过。但根据我最后的了解，Cloudways 不提供 HIPAA BAA。他们甚至运行在底层的 AWS 和 GCP 上，这有点讽刺。托管层引入了不确定性，他们不会为 HIPAA 目的在合同上为此担责。
Pantheon——不行（大多数计划）
Pantheon 对 Drupal 和 WordPress 代理商来说非常优秀。HIPAA 合规不是他们的市场。他们已经把这说得很清楚了。别被企业级的品牌宣传迷惑了。
WP Engine——不行
我知道。他们有合规文档。他们谈论安全。他们不会签署 HIPAA BAA。他们的服务条款明确禁止在他们的平台上存储 PHI。这使其不符合任何真正的医疗保健用例资格。我在这篇文章开头提到的那个初创公司？这正是他们所处的情况。
Liquid Web / Nexcess — 可能，但有需要注意的地方
Liquid Web 提供过符合 HIPAA 的托管主机服务，附带 BAA 签署，通常是在他们的专用服务器或 VPS 产品上而不是共享计划。值得直接与他们的销售团队交谈。他们的合规态势已经改善。但在我构建任何东西之前，我想先拿到 BAA。
---
你的 WordPress 堆栈在 BAA 之外需要什么
BAA 是基础，不是建筑本身。以下是在应用层对符合 HIPAA 要求的 WordPress 站点实际需要发生的事情。
表单和数据收集
- Gravity Forms 在适当的设置下是可以使用的，但原生 Gravity Forms 默认将提交存储在 WordPress 数据库中。对于 PHI，你要么需要禁用数据库存储并将数据安全地传送到符合 HIPAA 的目的地，要么仔细使用他们的加密字段附加组件。with the proper setup can be used, but native Gravity Forms stores submissions in the WordPress database by default. For PHI, you either need to disable database storage and pipe data securely to a HIPAA-compliant destination, or use their Encrypted Fields add-on carefully.
- Cognito Forms 和 FormAssembly 都提供符合 HIPAA 的层级和 BAA。如果表单是主要的数据收集点，这些通常比与 GF 争论更简洁。andFormAssemblyboth offer HIPAA-compliant tiers with BAAs. If the form is the primary data-collection point, these are often cleaner than wrestling with GF.
- 永远不要使用免费的联系表单插件，这些插件在没有检查其合规态势的情况下将数据发送到第三方服务器。
电子邮件
这一点会害死人。你的WordPress网站很可能通过wp_mail()发送电子邮件，该函数默认使用PHP mail或连接的SMTP插件。标准Gmail、标准Mailchimp、标准SendGrid——这些在入门级套餐中都不会签署HIPAA BAA。
Paubox是我一直向中小型医疗保健客户推荐的。HIPAA合规的电子邮件，包含BAA，定价直白。Google Workspace也为其医疗保健客户提供BAA，但需要特定的套餐和正式的请求流程——不适用于标准Google账户。is the one I recommend consistently for small-to-mid healthcare clients. HIPAA-compliant email, BAA included, straightforward pricing. Google Workspace also offers a BAA for their healthcare clients, but it requires a specific plan and a formal request process — it doesn't apply to a standard Google account.
插件和第三方集成
每个会回传数据的插件、每个分析脚本、每个实时聊天小部件——所有这些都可能接触到PHI，取决于页面上有什么数据。进行适当的审计。我使用Query Monitor来识别哪些在进行外部请求，然后与每个供应商的合规文档进行交叉引用。Query Monitorto identify what's making external requests, then cross-reference against each vendor's compliance documentation.
HubSpot会签署BAA。Intercom不会（在标准套餐中）。Hotjar在没有经过非常仔细的范围界定的情况下，几乎肯定不应该在医疗保健网站上运行。
---
如何实际获得签署的BAA
这比较偏向程序性而非技术性，但我见过项目在这里停滞。
- 确定每个接触或可能接触PHI的供应商——主机、CDN、电子邮件、表单、分析、支持聊天、备份提供商。that touches or could touch PHI — host, CDN, email, forms, analytics, support chat, backup provider.
- 从每个供应商的销售或合规团队请求BAA文档。不要假设。要求书面形式。from each vendor's sales or compliance team. Don't assume. Get it in writing.
- 审查范围——只覆盖某些服务或某些数据类型的BAA需要在你签署之前理解清楚。— a BAA that only covers certain services or certain data types needs to be understood before you sign.
- 将签署的协议存放在你客户法务团队能够访问的地方。不只是放在你的收件箱里。somewhere your client's legal team can access. Not just in your inbox.
- 每年重新审视一次——供应商会改变他们的政策，服务会被弃用，一份在2024年覆盖你整个技术栈的BAA在2026年可能会有漏洞。— vendors change their policies, services get deprecated, and a BAA that covered your stack in 2024 might have gaps in 2026.
HHS关于业务合伙人的指导实际上是可读的。如果你是新手，花三十分钟读一下是值得的。HHS guidance on Business Associatesis actually readable. Worth thirty minutes of your time if you're new to this.
---
没人谈论的CDN问题
你已经搞定了主机。你有了BAA。你锁定了应用层。然后你在它前面放上了Cloudflare。
Cloudflare会签署BAA——但仅限于他们的企业计划，起价点对大多数小型医疗保健客户来说太高了。免费和专业版本呢？没有BAA。这意味着在没有BAA的情况下，Cloudflare在技术上是在解密和检查你的HTTPS流量的，而这个网站可能在传输中有PHI。Enterprise plan, which starts at a price point that rules it out for most small healthcare clients. The free and Pro tiers? No BAA. Which means Cloudflare is technically decrypting and inspecting your HTTPS traffic without a BAA in place, on a site that may have PHI in transit.
对于较小的项目，我通过使用AWS CloudFront（符合BAA条件）作为CDN层来解决这个问题，当网站已经在EC2上或在应用负载均衡器后面时。这不如Cloudflare仪表板那么花哨，但从合规的角度来说是干净的。
---
我在2026年真正会做的事
如果一个医疗客户明天找我提出WordPress需求，大致上我会这样架构：
- 主机：AWS EC2（签署了BAA）运行加固的LEMP堆栈，或者Kinsta Business并持有他们的BAAAWS EC2 (with a signed BAA) running a hardened LEMP stack, or Kinsta Business with their BAA in hand
- 电子邮件：Paubox用于事务性和提供商面向的电子邮件Paubox for transactional and provider-facing email
- 表单：FormAssembly或Gravity Forms，禁用数据库存储并加密提交路由FormAssembly or Gravity Forms with database storage disabled and encrypted submission routing
- CDN：AWS CloudFront，不用Cloudflare免费版或Pro版AWS CloudFront, not Cloudflare free/Pro
- 分析：在同一个BAA覆盖的基础设施上自托管Matomo——对于URL或参数中有任何PHI风险的任何东西都不用Google AnalyticsSelf-hosted Matomo on the same BAA-covered infrastructure — no Google Analytics for anything that has even a chance of PHI in the URL or parameters
- 备份：AWS S3（符合BAA资格）配合服务器端加密AWS S3 (BAA-eligible) with server-side encryption
这比标准WordPress构建更贵吗？是的。操作复杂度更高吗？也是。但另一种选择是让客户面临HIPAA违规通知流程、可能的罚款（每次违规每天最低100美元起），以及一次非常尴尬的谈话，解释为什么他们的开发者从未提及这些。HIPAA breach notificationprocess, potential fines starting at $100 per violation per day, and a very uncomfortable conversation about why their developer never mentioned any of this.
---
常见问题
"符合HIPAA的托管"在法律上有意义吗?
没有。这是一个市场营销用语。有法律意义的是签署的BAA(业务关联协议)。任何主机提供商都可以称自己为HIPAA就绪、HIPAA友好或HIPAA某某。没有BAA，这些词语只是装饰性的。始终明确询问："你们会与我们签署业务关联协议吗?"
如果我的网站只有一个联系表单，还需要BAA吗?
如果联系表单收集可能构成PHI(受保护的健康信息)的信息——症状、诊断、预约原因，或任何与患者身份和健康状况相关的内容——那么是的，该数据链中的每个供应商都应该有BAA。只收集姓名、电话和偏好时间的常规"预约"表单属于灰色地带，但我仍然建议获取BAA。
我可以使用WordPress.com做医疗保健网站吗?
WordPress.com(托管平台，不是自托管的WordPress软件)不提供HIPAA BAA。句号。这不同于在符合要求的基础设施上运行的自托管WordPress。软件本身没问题。托管平台不适合PHI。
如果我正在使用的供应商被收购，新所有者取消了BAA，会怎样?
这是一个真实风险，我见过它发生在较小的SaaS工具上。你的BAA应该有终止条款，在供应商无法再满足HIPAA义务时触发。当你收到收购公告邮件时，别删除它——检查新实体是否保持了合规承诺。
HIPAA只是美国的问题吗?
是的,HIPAA 是美国联邦法律。但如果你为英国或欧盟医疗客户开发产品,等效的标准——NHS Digital 标准、数据安全与保护工具包,以及应用于健康数据的 GDPR——在数据处理器协议方面有相似的要求。框架不同,逻辑是一样的。
---
大多数开发者,如果诚实的话,在有人问起之前根本不会想到 BAA。到那时要么你幸运地没问题,要么你在紧张的客户催促下仓促地改造整个技术栈。
最好在项目开始前就了解这些要求,而不是在开发到一半时才发现你的主机商拒绝签署那份真正重要的文件。