hipaa-audit

HIPAA 审计 —《健康保险流通与责任法案》

HIPAA 规定了在美国医疗保健体系中如何处理受保护健康信息（PHI）。工程层面的工作范围很广，因为 PHI 的范围比人们通常认为的更大：标明患者预约的日历条目属于 PHI；患者访问的门户网站记录的 IP 地址，若与某种健康状况结合，也可能属于 PHI。

本技能围绕 HIPAA 的四项规则展开，重点关注安全规则的三类保障措施（管理、物理和技术）——工程工作主要集中在这里。隐私规则、违规通知规则和 HITECH 法案也在此基础上发挥作用。

最终的合规判定应由法律顾问和隐私官负责；本技能提供技术工程层面的支持。

交叉参考：privacy-engineering 介绍常与此重叠的 GDPR / CCPA 相关隐私工作；iam-audit 介绍访问控制和身份验证；crypto-audit 介绍静态和传输中加密的详细信息；secrets-audit 介绍密钥管理；siem-detection 介绍审计日志工程；incident-triage 和 security-comms 介绍违规事件响应。

授权

仅审计用户所在组织（受覆盖实体或业务伙伴）拥有的系统和代码，或该组织委托用户审查的系统和代码。切勿将真实 PHI 读入、导出或粘贴到对话记录中：应通过架构、配置和合成记录追踪其流向及保护方式。如果发现真实 PHI，请记录其位置，但不要复制内容。合规和违规通知方面的结论应交由隐私官和法律顾问处理。

范围 — 适用对象及 PHI 的定义

谁必须遵守

• 受覆盖实体（CE） — 健康计划、医疗保健信息交换中心，以及在 HIPAA 定义的交易中以电子方式传输健康信息的医疗服务提供者
• 业务伙伴（BA） — 代表受覆盖实体创建、接收、维护或传输 PHI 的任何一方（持有 PHI 的云托管服务商、SaaS 分析服务、EHR 供应商、计费服务，甚至某些律师和顾问）
• BA 的分包商 — 同样属于 BA。责任链会继续延伸；每个环节都必须与其上游环节签署 BAA

如果某个系统在没有 BAA 的情况下为 CE 处理 PHI，无论处理方式多么安全，都构成违规。

什么是 PHI / ePHI

PHI = 由 CE 或 BA 持有或传输的可识别个人身份的健康信息。ePHI = 电子形式的 PHI。

HIPAA 规定的 18 项标识符（安全港去标识化清单——全部移除后，数据不再属于 PHI）：

1. 姓名
2. 小于州级的地理区域（街道、城市、县、ZIP——若人口少于 20,000，则包括完整 ZIP；多数情况下保留前 3 位即可）
3. 精确到年份以下的日期（出生、入院、出院、死亡）——对于 89 岁以上的个人，即使年份也必须汇总处理
4. 电话号码
5. 传真号码
6. 电子邮件地址
7. 社会安全号码
8. 病历号
9. 健康计划受益人编号
10. 账号
11. 证书 / 许可证编号
12. 车辆标识符和序列号（包括车牌号）
13. 设备标识符和序列号
14. URL
15. IP 地址
16. 生物特征标识符（指纹、声音）
17. 正面全脸照片及类似图像
18. 任何其他唯一标识编号、特征或代码

**重要：**通过安全港移除这 18 项标识符，是两种去标识化方法之一。另一种方法是专家判定（通过统计分析确认再识别风险较低）。去标识化数据不属于 PHI；假名化数据仍属于 PHI（因为用于将替代标识符关联回个人的密钥仍保存在某处）。

范围缩减模式

最常见的范围缩减方式：

• 限制收集的数据类别 — 如果不需要出生日期，就不要收集、传输或存储
• 在监管机构允许的情况下，在内部进行假名化，但要了解内部使用的假名仍属于 ePHI（关联表由 CE / BA 持有）
• 尽可能使用已签署 BA 协议的服务 — AWS、Google Cloud、Azure、Stripe Healthcare 和某些分析服务供应商会签署 BAA；许多 SaaS 工具不会
• 使用在合同中承诺绝不接收 PHI 的服务 — 例如在数据接入时清理数据的分析平台，以及严格过滤 PII 的错误报告工具

安全规则 — 三类保障措施

管理保障措施（计划层面）

这些是政策和计划控制措施。工程团队提供相关材料；隐私负责人负责该计划。

• §164.308(a)(1) 安全管理流程 — 风险分析（基础工作；发生重大变更时重新进行）、风险管理、制裁政策、信息系统活动审查
• §164.308(a)(2) 指定安全责任人 — 指定一名安全负责人
• §164.308(a)(3) 员工安全 — 授权 / 监督、终止雇用程序
• §164.308(a)(4) 信息访问管理 — 访问授权、权限变更
• §164.308(a)(5) 安全意识与培训 — 包括安全提醒、恶意软件防护、登录监控、密码管理
• §164.308(a)(6) 安全事件处理程序 — 参见 incident-triage
• §164.308(a)(7) 应急计划 — 备份、灾难恢复、紧急模式运行、测试
• §164.308(a)(8) 评估 — 定期进行技术和非技术评估
• §164.308(b)(1) 业务伙伴合同 — 与每个 BA 签署 BAA

工程审计输入： 为风险分析准备证据包（资产清单、威胁模型、控制措施清单）、员工安全记录（访问权限审查、入职 / 调岗 / 离职证据）、培训完成记录。

物理保障措施（数据中心 / 设施）

对于现代 SaaS，大多数物理保障措施由云服务供应商的合规状态涵盖（纳入云服务的 BAA）。请核实：

• §164.310(a) 设施访问控制 — 适用于处理 ePHI 的任何办公区域
• §164.310(b) 工作站使用 — 针对访问 ePHI 的工作站制定政策
• §164.310(c) 工作站安全 — 对这些工作站实施物理安全保护
• §164.310(d) 设备和介质控制 — 处置、介质再利用、责任追踪、数据备份与存储

工程审计输入： 确认云服务供应商的 BAA 涵盖相关物理保障义务；确认任何接触 ePHI 的员工笔记本电脑均启用磁盘加密和远程擦除功能。

技术保障措施（工程审计重点）

本技能主要关注这一部分。

§164.312(a) 访问控制

• 唯一用户标识 — 必须实施。每个访问 ePHI 的人员都必须拥有唯一 ID。不得使用共享账户
• 紧急访问程序 — 为紧急访问 PHI 设置紧急解锁途径，并记录日志
• 自动注销 — 可酌情实施；终止空闲会话
• 加密和解密 — 可酌情实施；对静态存储的 ePHI 进行加密。“可酌情实施”并不代表可以不做：实体必须实施该措施，或记录说明为何该措施不合理或不适当，以及改用何种等效措施（§164.306(d)(3)）。OCR 执法将缺少加密且未进行此类分析视为违规；无论如何，未加密的 ePHI 都无法享受数据泄露免责保护

审计 grep 模式：

• 使用共享服务账户访问 PHI 表：从非个人账户搜索 SELECT.*patient、SELECT.*encounter
• 缺少会话超时：搜索未明确设置超时时间的会话配置
• 静态存储的 ePHI 未加密：确认每个数据存储均启用了数据库级和存储桶级加密

§164.312(b) 审计控制

• 用于记录和检查包含 ePHI 的系统中活动的硬件、软件和程序机制

实践中：每次读取、每次写入以及每项涉及 ePHI 的访问决策都要记录日志。日志至少保留 6 年（HIPAA 的一般文件保留期限）。工程实现请参见 siem-detection。

§164.312(c) 完整性

• 用于验证 ePHI 的机制——确认 ePHI 未遭到未经授权的篡改或销毁
• 实践中属于可寻址要求——对关键 ePHI 记录采用哈希／签名控制，并使用不可变日志存储

§164.312(d) 个人或实体身份验证

• 验证访问 ePHI 的个人或实体的身份
• 《安全规则》文本未明确要求 MFA，但 2013 年后的执法实践和 HHS 指南强烈建议对任何远程访问 ePHI 的情况启用 MFA；应将其视为实际上的强制要求。HHS 的新指南（2024 年及以后）正推动将 MFA 列为明确要求

实现请参见 iam-audit。

§164.312(e) 传输安全

• 完整性控制——属于可寻址要求；保护传输中的 ePHI，防止遭到不当修改
• 加密——属于可寻址要求，适用相同的实施或记录规则；实践中，任何经网络传输的 ePHI 都应使用 TLS 1.2+

请参见 crypto-audit。

隐私规则——PHI 可以如何使用

《隐私规则》规定 PHI 的使用和披露规则。《安全规则》要求“保护 PHI”；《隐私规则》则规定“只能将 PHI 用于这些特定目的”。

与工程相关的要点：

• 最少必要标准——将 PHI 用于治疗以外的目的时，只能使用或披露最少必要的信息。工程实现包括：基于角色的访问控制、查询级范围限定（不要从患者表中执行 SELECT *）、只返回调用方所需字段的 API 契约
• TPO 例外——治疗、支付和医疗运营无需授权。大多数其他用途则需要授权
• 个人权利——访问权（类似 GDPR DSAR——30 天内交付）、修改权、披露记录查询权
• 隐私实践通知——须予以发布，并在首次交互时提供

审计 grep 模式：

• 范围过宽的 PHI 查询：SELECT \*.*patient、SELECT \*.*encounter、SELECT \*.*observation——几乎总是违反最少必要标准
• 调用方只需要特定字段，API 端点却返回完整患者记录
• 分析平台／监控工具在没有 TPO 依据的情况下接收 PHI

违规通知规则

违规是指未经授权获取、访问、使用或披露未受保护的 PHI，从而危及 PHI 安全或隐私的行为。“未受保护”＝未按照 HHS 指南加密（加密是安全港）。

通知时限：

接收方	时限
受影响个人	不得无故拖延，且不得晚于发现后的 60 个日历日
卫生与公众服务部（HHS / OCR）	影响 ≥ 500 人的违规事件，须在发现后的 60 天内通知；影响 < 500 人的违规事件，须每年通知
媒体	影响某个州或辖区内 > 500 人的违规事件，须在同一个 60 天期限内通知
业务伙伴通知受监管实体	不得无故拖延，且不得晚于 60 天

“违规”包括未经授权的访问，而不仅仅是数据外泄。如果工作人员查看了其无须查看的记录，即构成违规（除非适用少数例外情形之一）。

**工程切入点：**快速确定违规范围的能力。审计日志（Security Rule §164.312(b)）是事实依据。确定范围所需的时间会直接影响 60 天的时限。

**安全港：**如果 PHI 按照 HHS 认可的标准加密（且密钥也未遭泄露），未经授权的获取可能不构成违规。这是全面加密静态 ePHI 的最有力理由。

参见 incident-triage（响应）、security-comms（通知草稿——需经过法律审查）、breach-patterns（事件后模式提取）。

HITECH 层

HITECH（2009 年）在多个相关方面强化了 HIPAA：

• 规定 BA 对许多 Security Rule 违规行为直接承担责任（此前只有 CE 承担责任）
• 提高民事罚款（分级处罚，每项规定每年最高达 150 万美元）
• 将 Breach Notification Rule 纳入联邦法规（取代部分州级零散规定）
• 加强患者获取其 PHI 电子副本的权利

对于现代工程工作，HITECH 意味着：处理 ePHI 的 BA 直接受大多数 Security Rule 条款约束。供应商不能以 CE 为挡箭牌。

常见审计发现（现实场景中的初步假设）

• PHI 出现在未签署 BAA 的供应商数据管道中——Sentry、Datadog、Mixpanel、Segment、Slack 接收 PHI，却未签署 BAA（Sentry 可签署 BAA；Datadog 提供医疗健康服务；Mixpanel 默认不提供——请核实各供应商对 BAA 的立场）
• 通过共享服务账户违反唯一用户 ID 要求——工程团队使用共享管理员账户临时访问 PHI
• 对 PHI 表执行 SELECT *——违反最低必要原则；API 序列化器在调用方只需少数字段时返回所有字段
• 只需要年龄范围，却存储了出生日期——数据最小化存在缺口
• 备份已加密，但密钥与备份存放在一起——安全港取决于密钥是否分开存放
• 用生产数据填充低环境——预发布数据库包含从生产环境转储的真实 PHI
• 并非所有 ePHI 访问路径都强制启用 MFA——2024 年之前的环境可能存在缺口；趋势是普遍要求启用 MFA
• 审计日志保留时间少于 6 年——HIPAA 要求将规则规定的文档保留 6 年，其中包括证明合规性的审计日志
• 访问 ePHI 的工作站／临床应用未启用自动注销
• BA 链条断裂——供应商的分包商处理 ePHI，但 BA 未与该分包商签署自己的 BAA

先核实，再记录

按照 references/findings-format.md 中的定义，为每个候选项确定一种结论；在确认任何内容之前，按照 references/verification.md 执行反证检查。 与必需实施规范存在差距即为一项发现。 规范是预期的控制措施。应根据其对 ePHI 造成的暴露来评定严重程度，使用 references/severity-calibration.md，而不是依据审计或处罚后果：将 PHI 发送给没有 BAA 的供应商属于真实披露；缺少制裁政策本身并不构成暴露。没有造成暴露的差距（没有指定安全官员、没有记录风险分析、培训记录逾期）属于文档差距：在报告的专门章节中列出，不评定严重程度，也不创建 findings.json 记录。缺少风险分析是 OCR 最常指出的差距，因此应列在第一项。若其他层已能阻止暴露，则纵深防御方面的差距属于加固建议。

可寻址规范。 可寻址规范（自动注销、静态加密、传输加密、完整性控制等）必须实施，或者实体必须记录为何该规范不合理且不适当，以及采取了哪些替代措施（§164.306(d)(3)）。如果规范未实施，但存在记录在案的等效措施或基于风险的理由，则候选项为 rejected，且 ruled_out_by.location 应指向该文档。如果控制措施和文档都不存在，则应像处理必需规范一样处理：存在暴露时列为发现，不存在暴露时列为文档差距。使用 ext.addressable 记录该规范的状态。

以下是此处各类判定的示例：

• confirmed：代码或导出的配置显示，ePHI 正在流向规则不允许的人员或位置，或者通往 ePHI 的路径缺少必需的控制措施。
  • 值班工程师使用一个共享的 phi_admin 数据库角色临时查询 patients（唯一用户标识，§164.312(a)(2)(i)，必需）。证据：该角色的导出内容，以及分发密码的运行手册。
  • analytics.track("appointment_booked", { email, diagnosis }) 将 PHI 发送到 Mixpanel，而证据文件夹中的 BAA 登记表没有 Mixpanel 条目（§164.502(e)、§164.308(b)(1)）。
  • GET /api/patients/:id 将完整记录（包括 SSN 和诊断信息）返回给一个仅显示姓名和时间的排班视图（最少必要原则，§164.502(b)）。
  • 不安全的已发布默认值，例如默认 PHI_AUDIT_LOG=false，若未被覆盖，则判定为 confirmed，并注明 system_configuration 条件（“未设置 PHI_AUDIT_LOG=true 的部署”），置信度为 medium。无法查看的部署情况会降低置信度，但不会改变判定或严重程度。
• needs_validation：代码支持该说法，但还有一项事实需要从代码之外确认。请指出该事实，并指定负责核查的人员。
  • Sentry 会接收来自 /api/patients 的请求正文，但尚未有人提供 BAA 登记表。阻碍因素：与 Sentry 签署的 BAA 是否涵盖此项目。核查方式：由隐私官确认 BAA 及其生效日期，并将经过脱敏的登记表条目保存到证据文件夹。
  • 生产数据库是在控制台中创建的，而非通过 Terraform 创建。阻碍因素：存储加密是否已启用。核查方式：运行 aws rds describe-db-instances --query 'DBInstances[].[DBInstanceIdentifier,StorageEncrypted,KmsKeyId]' --output text，并将结果保存到证据文件夹。
• rejected：某个指定位置的具名控制措施或文档可以排除该问题。
  • 临床医生使用的桌面应用没有空闲自动注销功能（§164.312(a)(2)(iii)，可处理），且风险分析记录了等效措施：所有受管理设备均由 MDM 在 5 分钟后锁定屏幕。ruled_out_by.location 指向风险分析中的该部分。
  • “错误报告器会接收 PHI”：src/lib/sentry.ts 中的 beforeSend 会在每个事件离开进程前删除 event.request.data 和 event.user。ruled_out_by.location 指向该行。
  • 依赖项内部的控制措施（例如 SDK 自带的脱敏钩子）也可排除候选项：ruled_out_by.location 指向锁文件或清单中锁定版本的那一行，control 则注明库函数和版本。
  • 对“永远无法访问”的排除项，ruled_out_by.location 应指向相关证据：唯一的导入或调用位置；如果没有任何使用，则指向依赖项声明。

假名化数据仍属于 PHI，因此假名本身不能单独排除候选项。排除一项可处理规范记录，不会改变违规后果：未加密的 ePHI 仍属于《违规通知规则》所指的“未受保护信息”。请在“违规响应准备情况”中说明这一点。

已部署资源和文档的证据。 许多 HIPAA 发现涉及的并非源文件：数据库和存储桶的加密设置、IdP 和 MFA 策略、日志保留期限、BAA 登记表、风险分析、政策和程序。将只读命令的输出或导出内容脱敏后，保存到 <audit dir>/evidence/<name>.json 或 .txt（例如 audit/hipaa/evidence/rds-encryption.txt、audit/hipaa/evidence/baa-register.json），并将 location 和 evidence[] 指向该文件及相关行。若风险分析或政策已存在于仓库中，可直接引用其所在位置。切勿在证据、findings.json 或报告中保存 PHI 或凭据值；应记录其存放位置及所含标识符类别。只有在获得授权且仅执行只读操作时才能进行实时检查；仅描述但未执行的检查应标记为 needs_validation。 指纹的格式为 hipaa-audit/<class>/<file or resource>/<symbol or name>，用斜杠分隔，不含行号。验证器会拒绝包含 :<digits> 的段，因此 ARN 和 host:port 应使用斜杠表示。使用简短的类别，例如 phi-to-non-baa-vendor、shared-account、min-necessary、encryption-at-rest、transmission-security、audit-log-gap、no-auto-logoff、mfa-gap、phi-in-logs、phi-in-lower-env、baa-chain-break：

hipaa-audit/phi-to-non-baa-vendor/src/lib/analytics.ts/mixpanel
hipaa-audit/min-necessary/src/serializers/patient.ts/PatientSerializer
hipaa-audit/shared-account/postgres/patients-prod/phi_admin
hipaa-audit/encryption-at-rest/aws/123456789012/us-east-1/rds/patients-prod

对于已部署的资源，应根据资源（提供商、账户或数据库、名称）构建指纹，而不是根据证据文件名构建，这样在重新采集证据后指纹仍保持一致。

ext 字段（可选对象，可用于任何记录；不要重复已有字段中的信息，例如 cwe 或 location）：

键	值	示例
standard	45 CFR 条款或实施规范	"164.312(b)"、"164.312(a)(2)(iv)"、"164.502(b)"
addressable	对于可选实施的规范为 true，对于强制要求为 false；隐私规则和违规通知规则的记录省略此字段	true
rule	该记录所属的 HIPAA 规则	"security"、"privacy"、"breach-notification"

然后：

1. 编写按 fingerprint 排序的 findings.json，并设置 skill: "hipaa-audit"。验证并修正所有错误：node references/validate-findings.mjs findings.json（references/validate-findings.mjs）。
2. 可选导出 SARIF：node references/to-sarif.mjs findings.json -o findings.sarif（references/to-sarif.mjs）。
3. 将文档缺失项和加固说明整理成简短列表，与 JSON 文件放在一起（例如 notes.md）。它们不是记录。

处置方式（通常稍后由 finding-triage 设置）：Fixed / Deferred / Accepted Risk / Mitigated (platform/config) / Requires major migration。HIPAA 下极不建议接受风险：大多数“已接受风险”都应作为剩余风险记录在风险分析中，并附上补偿性控制措施和重新评估触发条件。误报应记录为 rejected，而不是处置方式。

输出格式

先编写 findings.json。根据它生成报告；报告文字不得更改 JSON 中未体现的结论、严重性或阻断项。

# HIPAA Technical Readiness Review
## Entity: [name]   ## Entity type: Covered Entity / Business Associate / Subcontractor
## Date: [date]   ## Reviewer: [name]   ## Scope: [full | partial, what was left out]
## findings.json: [path], validated: [yes]   ## Evidence folder: [path]

### Summary
- Confirmed: [N] (Critical [n] | High [n] | Medium [n] | Low [n])   Needs validation: [N]   Rejected: [N]
- Documentation gaps: [N]   Hardening notes: [N]

### Confirmed findings
#### [SEVERITY] [Title]  `fingerprint`
**Standard:** [ext.standard] ([required | addressable])   **Rule:** [ext.rule]
**Location:** `path:line` (source or evidence file)   **Confidence:** [medium | high (reproduced)]
**What and why it matters:** [the trace or the config evidence, in a few lines; the ePHI exposed and to whom]
**Fix:** [concrete change]
**Verify the fix:** [the check that proves it]

### Needs validation
| Finding | Standard | Blocker | Check for the owner to run |
|---|---|---|---|

### Hardening notes (not findings)
- [gap] — [why it isn't a finding] — [effort]

### Documentation gaps (not findings)
| Standard | What's missing | Owner | Evidence expected |
|---|---|---|---|

### Rejected (do not re-raise)
| Fingerprint | Ruled out by | Location |
|---|---|---|

### Scope
- [ ] ePHI inventory complete (every data store containing PHI)
- [ ] Data flow diagrams for PHI transmission paths
- [ ] BAA in place with every BA (and BA's subcontractors where required)
- [ ] Cloud provider BAA on file (AWS / GCP / Azure / etc.)
- [ ] Risk analysis (§164.308(a)(1)(ii)(A)) current

### PHI flow map
| Store or flow | Identifier classes | Vendor / BAA | Encrypted at rest | Encrypted in transit | Records |
|---|---|---|---|---|---|

### Administrative safeguards
| Subsection | Confirmed | Needs validation | Documentation gaps |
|------------|-----------|------------------|--------------------|
| Security Management Process | | | |
| Assigned Security Responsibility | | | |
| Workforce Security | | | |
| Information Access Management | | | |
| Security Awareness and Training | | | |
| Security Incident Procedures | | | |
| Contingency Plan | | | |
| Evaluation | | | |
| BA Contracts | | | |

### Technical safeguards
| Subsection | Confirmed | Needs validation | Documentation gaps |
|------------|-----------|------------------|--------------------|
| Access Control — unique IDs | | | |
| Access Control — emergency access | | | |
| Access Control — automatic logoff | | | |
| Access Control — encryption at rest | | | |
| Audit Controls | | | |
| Integrity | | | |
| Person / Entity Authentication (MFA) | | | |
| Transmission Security (encryption in transit) | | | |

### Addressable specifications
| Spec | Implemented? | Equivalent or rationale (document, location) | Record |
|---|---|---|---|

### Privacy Rule
- [ ] Minimum necessary applied in code (no SELECT * on PHI tables)
- [ ] Notice of Privacy Practices published and presented
- [ ] Individual access path implemented (30-day delivery)
- [ ] Amendment / accounting of disclosures process exists

### Breach response readiness
- [ ] Audit logs sufficient to scope a breach within the 60-day clock
- [ ] Incident-response procedures tested
- [ ] Notification templates drafted (see security-comms)
- [ ] Encryption-as-safe-harbor verified across ePHI stores (list stores that are unsecured, including any covered by a rejected addressable-spec record)

### Prioritized remediation plan
1. [highest first: PHI to non-BAA vendors, unencrypted ePHI reachable from outside, shared accounts]

保障措施表根据 findings.json 中的记录（按 ext.standard）和文档缺失项列表中的条目计数。它们不代表独立的判断。

边界

• 此技能用于工程审计和准备工作。对于受 HIPAA 约束的实体身份、业务伙伴关系和通知决策，由隐私官／法律顾问作出最终判定
• 拒绝帮助构建违反 HIPAA 的流程——将 PHI 发送给未签署 BAA 的供应商、通过共享账户访问 PHI、在授权范围狭窄的例外之外使用面向终端用户的消息技术（个人电子邮件、SMS、聊天）传输 PHI，以及未经授权将 PHI 用于营销
• 对于违规事件：此技能负责界定事件范围并提供通知所需的工程信息；通知本身由 security-comms 和法律顾问处理
• 自 2013 年以来，HIPAA 执法机构 OCR 的执法范围有所扩大；监管解释也在不断演变。如果此技能的内容滞后于 OCR 的现行指导，应以 OCR 的现行指导为准
• 州法律可能规定更严格的要求（例如 Texas HB 300、California CMIA）——仅在州法律保护力度较弱时才会被联邦法律优先适用；否则，州法律要求将叠加适用
• 遗传信息受 GINA 的额外保护——不在此范围内，请参阅专门指导

参考资料

• HHS HIPAA 规则 — hhs.gov/hipaa（法规文本、常见问题、OCR 和解协议）
• HHS / OCR 审计规程 — OCR 审计人员使用；可作为自我评估的实用清单
• HHS 安全风险评估工具 — 面向中小型服务提供者的免费工具
• NIST SP 800-66 Rev. 2（2024）—《实施 HIPAA 安全规则：网络安全资源指南》— 最新的技术指南
• HITRUST CSF — 与 HIPAA 安全规则对应的通用控制框架；许多业务伙伴（BA）会申请 HITRUST 认证，作为合规证明
• OCR 和解协议 — 已公布的执法行动；可作为 OCR 对重大事项认定的参考先例
• HHS 耻辱墙 — 公开的违规通报门户；可用于了解行业模式
• 45 CFR 第 160 和 164 部分 — 法规原文
• OCR 网络安全简报 — 季度指南更新
• 《HIPAA Plain & Simple》 — Carolyn P. Hartley — 从业者参考资料
• 共享参考资料（构建时复制到 references/）：references/findings-format.md、references/verification.md、references/severity-calibration.md、references/findings.schema.json