HIPAA合规 是做什么的?
当任务明确涉及美国医疗合规时,将其作为HIPAA专用入口点。此技能有意保持简洁和权威性:
healthcare-phi-compliance仍然是处理PHI/PII、数据分类、审计日志、加密和防泄漏的主要实施技能。healthcare-reviewer仍然是专门的审查者,当代码、架构或产品行为需要医疗感知的二次检查时使用。security-review仍然适用于一般的认证、输入处理、密钥、API和部署加固。
使用时机
- 请求明确提及HIPAA、PHI、覆盖实体、业务伙伴或BAA
- 构建或审查存储、处理、导出或传输PHI的美国医疗软件
- 评估日志、分析、LLM提示、存储或支持工作流是否产生HIPAA暴露
- 设计患者或临床医生使用的系统,其中最小必要访问和可审计性至关重要
工作原理
将HIPAA视为更广泛的医疗隐私技能的覆盖层:
- 从
healthcare-phi-compliance开始,获取具体的实施规则。 - 应用HIPAA特定的决策门:
- 这些数据是PHI吗?
- 这个参与者是覆盖实体还是业务伙伴?
- 供应商或模型提供商在接触数据前是否需要BAA?
- 访问权限是否限制在最小必要范围?
- 读取/写入/导出事件是否可审计?
- 如果任务影响患者安全、临床工作流或受监管的生产架构,则升级到
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-compliancehealthcare-reviewerhealthcare-emr-patternshealthcare-eval-harnesssecurity-review