HIPAA 合规¶

当任务明确涉及美国医疗合规时，请将本技能作为 HIPAA 专属切入点。本技能刻意保持精简而权威：

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

何时使用¶

• 请求中明确提及 HIPAA、PHI、受保实体（covered entities）、业务伙伴（business associates）或 BAA
• 构建或审查存储、处理、导出或传输 PHI 的美国医疗软件
• 评估日志记录、分析、LLM Prompt、存储或支持工作流是否产生 HIPAA 暴露风险
• 设计面向患者或面向临床医生的系统，其中最小必要访问和可审计性至关重要

工作原理¶

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

1. 从 healthcare-phi-compliance 入手，获取具体的实施规则。
2. 应用 HIPAA 专属决策关卡：
3. 这些数据是否属于 PHI？
4. 该行为主体是否为受保实体或业务伙伴？
5. 供应商或模型提供商在接触数据之前是否需要签署 BAA？
6. 访问权限是否限制在最小必要范围内？
7. 读取/写入/导出事件是否可审计？
8. 如果任务影响患者安全、临床工作流或受监管的生产架构，则升级到 healthcare-reviewer。

HIPAA 专属护栏¶

• 绝不要将 PHI 放入日志、分析事件、崩溃报告、Prompt 或客户端可见的错误字符串中。
• 绝不要在 URL、浏览器存储、截图或复制的示例负载中暴露 PHI。
• 对 PHI 的读取和写入要求经过身份验证的访问、限定范围的授权以及审计跟踪。
• 在 BAA 状态和数据边界明确之前，默认将第三方 SaaS、可观测性工具、支持工具和 LLM 提供商视为禁止接入。
• 遵循最小必要访问原则：合适的用户只应看到完成任务所需的最小 PHI 片段。
• 优先使用不透明的内部 ID，而不是姓名、病历号（MRN）、电话号码、地址或其他标识符。

示例¶

示例 1：以 HIPAA 为框架的产品请求¶

用户请求：

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

响应模式：

• 激活 hipaa-compliance
• 使用 healthcare-phi-compliance 审查 PHI 流转、日志记录、存储和 Prompt 边界
• 在发送任何 PHI 之前，核实摘要生成提供商是否受 BAA 覆盖
• 如果摘要影响临床决策，则升级到 healthcare-reviewer

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

用户请求：

我们可以将支持聊天记录和患者消息发送到我们的分析技术栈中吗？

响应模式：

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

相关技能¶

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