HIPAA-合规

HIPAA 合规

当任务明确涉及美国医疗合规时，将此作为 HIPAA 专用入口点使用。本技能刻意保持精简和规范化：

• healthcare-phi-compliance 仍是处理 PHI/PII 数据分类、审计日志、加密和防泄漏的主要实施技能。
• healthcare-reviewer 仍是专用审查者，用于代码、架构或产品行为需要医疗合规二次审核的场景。
• security-review 仍适用于通用身份验证、输入处理、密钥、API 和部署加固。

使用时机

• 请求明确提到 HIPAA、PHI、覆盖实体、业务关联方或 BAA
• 构建或审查存储、处理、导出或传输 PHI 的美国医疗软件
• 评估日志、分析、LLM 提示词、存储或支持工作流是否造成 HIPAA 暴露
• 设计面向患者或临床医生的系统，其中最小必要访问和可审计性至关重要

工作原理

将 HIPAA 视为医疗隐私技能的覆盖层：

1. 从 healthcare-phi-compliance 开始，获取具体实施规则。
2. 应用 HIPAA 专用决策点：
   • 此数据是否为 PHI？
   • 此行为者是覆盖实体还是业务关联方？
   • 供应商或模型提供方是否需要 BAA 才能接触数据？
   • 访问权限是否限制在最小必要范围内？
   • 读/写/导出事件是否可审计？
3. 如果任务影响患者安全、临床工作流或受监管的生产架构，升级到 healthcare-reviewer。

HIPAA 专用护栏

• 切勿将 PHI 放置于日志、分析事件、崩溃报告、提示词或客户端可见的错误信息中。
• 切勿在 URL、浏览器存储、屏幕截图或复制的示例负载中暴露 PHI。
• 要求对 PHI 的读取和写入进行经过身份验证的访问、范围限定的授权和审计跟踪。
• 默认阻塞第三方 SaaS、可观测性、支持工具和 LLM 提供商，直到其 BAA 状态和数据边界清晰。
• 遵循最小必要访问原则：正确用户应仅看到完成任务所需的最小 PHI 片段。
• 优先使用不透明的内部 ID，而非姓名、MRN、电话号码、地址或其他标识符。

示例

示例 1：产品请求涉及 HIPAA

用户请求：

在临床医生仪表板中添加 AI 生成的访问摘要。我们服务美国诊所，需要保持 HIPAA 合规。

响应模式：

• 激活 hipaa-compliance
• 使用 healthcare-phi-compliance 审查 PHI 移动、日志记录、存储和提示词边界
• 在向摘要生成提供方发送任何 PHI 前，确认其是否受 BAA 覆盖
• 如果摘要影响临床决策，升级到 healthcare-reviewer

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

用户请求：

我们能否将支持记录和患者消息发送到分析栈中？

响应模式：

• 假设这些消息可能包含 PHI
• 除非分析供应商已获批准用于 HIPAA 工作负载且数据路径已最小化，否则阻止该设计
• 尽可能要求进行脱敏处理或使用非 PHI 事件模型

相关技能

• healthcare-phi-compliance
• healthcare-reviewer
• healthcare-emr-patterns
• healthcare-eval-harness
• security-review