HIPAA合规技能

一、技能概述

该技能在任务明确涉及美国医疗健康合规时使用，主要覆盖 PHI/PII 处理、数据分类、审计日志、加密和泄露预防等核心合规领域。它作为医疗合规知识体系的顶层入口，与以下技能协同工作：

二、核心功能

1. 触发条件

以下情况应使用此技能：

• 请求明确提及 HIPAA、PHI、受保实体（covered entities）、业务伙伴（business associates）或 BAA

• 构建或审查存储、处理、导出或传输 PHI 的美国医疗软件

• 评估日志记录、分析、LLM 提示、存储或支持工作流是否产生 HIPAA 风险暴露

• 设计面向患者或临床医生的系统，其中最小必要访问（minimum necessary access）和可审计性至关重要

2. 工作方式

将 HIPAA 视为在更广泛的医疗隐私技能之上的叠加层：

• 首先：从 healthcare-phi-compliance 开始，获取具体的实现规则

• 然后：应用 HIPAA 特定的决策门控（decision gates）：

  • 这些数据是否属于 PHI？

  • 该参与者是否是受保实体或业务伙伴？

  • 供应商或模型提供商在接触数据之前是否需要 BAA？

  • 访问是否限制在最小必要范围内？

  • 读/写/导出事件是否可审计？

• 升级：如果任务影响患者安全、临床工作流或受监管的生产架构，升级至 healthcare-reviewer

3. HIPAA 特定防护栏（Guardrails）

技能强制执行以下合规规则：

三、主要用途

1. 医疗软件合规设计 —— 在构建面向美国诊所或医院的软件时，确保符合 HIPAA 要求

2. 供应商/工具决策评估 —— 评估第三方供应商（如分析工具、LLM 提供商）是否可接触 PHI 数据

3. AI 功能合规审查 —— 在设计 AI 辅助临床功能（如 AI 生成的就诊摘要）时，审查 PHI 流向、日志记录、存储和提示边界

4. 日志与可观测性审计 —— 确保日志记录、分析和崩溃报告不包含 PHI

5. 代码与架构审查 —— 对代码、架构或产品行为进行医疗感知的二次审查

6. BAA 决策支持 —— 判断供应商是否需要 BAA 才能接触数据

四、重要原则

1. PHI 绝不进入日志 —— 日志、分析、崩溃报告、提示和客户端错误字符串中不得包含 PHI

2. PHI 绝不暴露在 URL/浏览器存储中 —— URL、浏览器存储、截图或示例 payload 中不得包含 PHI

3. 第三方默认阻止 —— 直到 BAA 状态和数据边界明确之前，第三方服务不得接触 PHI

4. 最小必要访问 —— 用户只能看到完成任务所需的最小 PHI 片段

5. 使用不透明 ID —— 优先使用不透明内部 ID，而非姓名、MRN、电话号码等可识别信息

6. 所有 PHI 操作可审计 —— 读/写/导出事件必须可审计追踪

7. 安全审查仍适用 —— 通用认证、输入处理、密钥管理、API 和生产加固仍需遵循 security-review

五、典型应用示例

示例 1：AI 功能合规

用户请求：为临床医生仪表盘添加 AI 生成的问诊摘要，服务美国诊所，需要保持 HIPAA 合规。

响应模式：

• 激活 hipaa-compliance

• 使用 healthcare-phi-compliance 审查 PHI 流动、日志记录、存储和提示边界

• 在发送任何 PHI 之前，验证摘要生成提供商是否受 BAA 覆盖

• 如果摘要影响临床决策，升级至 healthcare-reviewer

示例 2：供应商/工具决策

用户请求：能否将支持工单和患者消息发送到分析平台？

响应模式：

• 假设这些消息可能包含 PHI

• 阻止该设计，除非分析供应商已批准用于 HIPAA 绑定的工作负载且数据路径已最小化

• 尽可能要求脱敏或使用非 PHI 事件模型

六、总结

HIPAA Compliance 是 ECC 项目中美国医疗健康数据合规的顶层入口技能，通过将 HIPAA 要求作为医疗隐私技能的叠加层，提供了一套完整的合规决策框架。它覆盖 PHI 识别、访问控制、审计追踪、第三方供应商 BAA 评估和最小必要访问等核心领域，并强制执行“PHI 绝不进入日志/URL/浏览器存储”、“第三方默认阻止”等严格防护规则。该技能适用于医疗软件开发、供应商评估、AI 功能合规审查和代码架构审查等场景，需与 healthcare-phi-compliance、healthcare-reviewer 和 security-review 等技能协同使用。