主机写着“安全”或“符合 HIPAA”，并不代表部署后自动合规。选型的起点应是美国医疗应用主机的HIPAA控制项核对：明确哪些服务会创建、接收、维护或传输电子受保护健康信息（ePHI），再确认供应商承担什么责任、应用团队还需落实什么控制。
HIPAA《安全规则》要求受监管机构及业务伙伴保护电子健康信息，但没有一张适用于所有应用的主机配置清单，也没有替单个产品颁发通用合规认证。判断重点是风险分析、书面安排和可验证的运行控制。
先划定主机服务与数据边界
画出数据流：患者门户、预约服务、后台接口、数据库、对象存储、备份和日志分别处理什么数据。即使主机无法解密加密数据，只要替业务维护相关数据，仍可能构成业务伙伴关系；符合条件时，通常需要与主机服务商签订BAA（业务伙伴协议）。
不要只核对云平台公司名称。AWS、Microsoft Azure 和 Google Cloud 提供多类服务，但某项服务能否纳入其协议范围，要看供应商当前公布的服务清单、合同和具体用法。未纳入范围的日志、监控、邮件或备份工具，也可能把数据带出原有边界。
按控制项比较，而不是按“云或自建”判断
| 核对项 | 需要确认的配置 | 比较时的差异 |
|---|---|---|
| 身份与访问 | 唯一账号、最小权限、管理员多因素认证、离职撤权流程 | 托管平台可能集成身份管理，部署方仍须设角色、审批和定期复核；自建环境的配置自由度更高，维护责任也更多。 |
| 审计与监测 | 记录登录、权限变更、数据访问及管理操作，并限制日志修改和访问 | 基础主机日志未必覆盖应用和数据库活动；需确认日志保留、告警、导出及调查流程。 |
| 加密与密钥 | 传输和存储加密、密钥权限、轮换及恢复方式 | 供应商管理密钥较省运维；客户自管密钥控制更强，但遗失或权限配置错误会影响可用性。 |
| 备份与恢复 | 备份范围、隔离、恢复权限及定期恢复测试 | 自动备份减少操作负担，不等于已验证可恢复；应依据业务可接受的停机和数据丢失范围设目标。 |
| 事件与分包商 | 通知渠道、响应协作、分包商管理和数据处置方式 | 合同应说明责任边界；仅有技术功能说明，不能替代协议和事件流程。 |
HIPAA 安全规则中的部分实施规范标为“可处理（addressable）”，并非可以不管；应根据风险判断采用该措施，或记录采用替代措施的理由。不要把“主机支持加密”误当成整个应用已完成风险评估。
按顺序做一轮可留档核对
- 列数据：标出 ePHI 所在的服务、环境和备份，区分生产、测试与开发数据；非生产环境尽量使用去标识或合成数据。
- 查合同与服务范围：取得适用的 BAA，逐项核对云主机、数据库、存储、日志和支持服务是否被覆盖，并确认分包商条款。
- 做配置验证：检查管理员 MFA、最小权限、加密、日志告警、网络访问限制和备份权限；把配置截图、策略导出或审计记录纳入证据。
- 演练故障场景：实际测试备份恢复、账号失陷后的撤权与事件升级，记录负责人、时间线和整改项。恢复测试频率应依据风险及业务要求确定。
- 持续复核：服务或数据流变化、增加新供应商、调整权限时重新评估；不要把一次上线检查当成永久结论。
不同主机模式的取舍
自管虚拟机适合需要细粒度系统控制、且团队能持续修补和监测的场景，代价是运维责任较重。托管数据库可减少底层维护，但仍须核实服务范围、账号权限、审计能力和备份设置。容器或无服务器服务便于弹性扩展，却可能牵涉更多日志、身份和分包服务；应逐个确认服务是否纳入协议，而不是仅凭平台整体名称判断。
因此，美国医疗应用主机的HIPAA控制项核对应形成一张责任矩阵：供应商提供什么、应用团队配置什么、双方如何处理事件。价格和性能可以最后比较；若 BAA、服务范围或关键审计证据无法确认，就不应仅因部署方便而把 ePHI 放入该方案。
常见问题
签了 BAA，应用就符合 HIPAA 吗？
不是。BAA 明确双方责任，但不会代替风险分析、访问控制、审计、培训和应急安排。
HIPAA 是否要求数据必须存放在美国？
HIPAA 本身没有一般性的美国境内存储要求。仍需评估合同、州法律、跨境访问和组织政策的限制。
加密后，主机就不算业务伙伴吗？
不能这样推断。若服务商维护 ePHI，即使无法读取内容，也可能承担业务伙伴义务，应结合实际服务和合同判断。
供应商给出合规证明，是否还要自己留记录？
要。应用方仍需保存风险评估、配置证据、访问复核、恢复测试及事件处理记录，并定期检查服务变化。
