---

name: hipaa-compliance description: HIPAA 特定入口，用于医疗隐私和安全工作。当任务明确围绕 HIPAA、PHI 处理、受保护实体、BAA、违规态势或美国医疗合规要求时使用。 origin: ECC direct-port adaptation version: "1.0.0"

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