hipaa-compliance

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

HIPAA Compliance

HIPAA 合规

Use this as the HIPAA-specific entrypoint when a task is clearly about US healthcare compliance. This skill intentionally stays thin and canonical:

```
healthcare-phi-compliance
```
remains the primary implementation skill for PHI/PII handling, data classification, audit logging, encryption, and leak prevention.
```
healthcare-reviewer
```
remains the specialized reviewer when code, architecture, or product behavior needs a healthcare-aware second pass.
```
security-review
```
still applies for general auth, input-handling, secrets, API, and deployment hardening.

当任务明确涉及美国医疗合规时，可将此作为HIPAA专项入口。该技能刻意保持轻量且权威：

```
healthcare-phi-compliance
```
仍是处理PHI/PII、数据分类、审计日志、加密和数据泄露防护的核心实现技能。
```
healthcare-reviewer
```
仍是针对代码、架构或产品行为需要医疗领域二次审核时的专用审核工具。
```
security-review
```
仍适用于通用身份认证、输入处理、密钥、API和部署加固场景。

When to Use

适用场景

The request explicitly mentions HIPAA, PHI, covered entities, business associates, or BAAs
Building or reviewing US healthcare software that stores, processes, exports, or transmits PHI
Assessing whether logging, analytics, LLM prompts, storage, or support workflows create HIPAA exposure
Designing patient-facing or clinician-facing systems where minimum necessary access and auditability matter

请求中明确提及HIPAA、PHI、受保实体、业务伙伴或BAA
构建或审核用于存储、处理、导出或传输PHI的美国医疗软件
评估日志、分析、LLM提示词、存储或支持工作流是否存在HIPAA合规风险
设计面向患者或临床医生的系统，这类系统对最小必要访问权限和可审计性有要求

How It Works

使用方式

Treat HIPAA as an overlay on top of the broader healthcare privacy skill:

Start with
```
healthcare-phi-compliance
```
for the concrete implementation rules.
Apply HIPAA-specific decision gates:
- Is this data PHI?
- Is this actor a covered entity or business associate?
- Does a vendor or model provider require a BAA before touching the data?
- Is access limited to the minimum necessary scope?
- Are read/write/export events auditable?
Escalate to
```
healthcare-reviewer
```
if the task affects patient safety, clinical workflows, or regulated production architecture.

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

首先调用
```
healthcare-phi-compliance
```
获取具体的实现规则。
应用HIPAA专项决策门槛：
- 该数据是否属于PHI？
- 该主体是否为受保实体或业务伙伴？
- 供应商或模型提供方在接触数据前是否需要签订BAA？
- 访问权限是否限制在最小必要范围内？
- 读/写/导出事件是否可审计？
如果任务会影响患者安全、临床工作流或受监管的生产架构，升级至
```
healthcare-reviewer
```
处理。

HIPAA-Specific Guardrails

HIPAA专项防护规则

Never place PHI in logs, analytics events, crash reports, prompts, or client-visible error strings.
Never expose PHI in URLs, browser storage, screenshots, or copied example payloads.
Require authenticated access, scoped authorization, and audit trails for PHI reads and writes.
Treat third-party SaaS, observability, support tooling, and LLM providers as blocked-by-default until BAA status and data boundaries are clear.
Follow minimum necessary access: the right user should only see the smallest PHI slice needed for the task.
Prefer opaque internal IDs over names, MRNs, phone numbers, addresses, or other identifiers.

切勿将PHI放入日志、分析事件、崩溃报告、提示词或客户端可见的错误字符串中。
切勿在URL、浏览器存储、截图或复制的示例payload中暴露PHI。
PHI的读写操作需要经过身份认证访问、范围化授权，且需留存审计轨迹。
第三方SaaS、可观测性、支持工具和LLM供应商默认禁止使用，直到明确其BAA状态和数据边界。
遵循最小必要访问原则：相应用户仅应访问完成任务所需的最小PHI片段。
优先使用不透明的内部ID，而非姓名、MRN、电话号码、地址或其他标识符。

Examples

示例

Example 1: Product request framed as HIPAA

示例1：涉及HIPAA的产品需求

User request:

Add AI-generated visit summaries to our clinician dashboard. We serve US clinics and need to stay HIPAA compliant.

Response pattern:

Activate
```
hipaa-compliance
```
Use
```
healthcare-phi-compliance
```
to review PHI movement, logging, storage, and prompt boundaries
Verify whether the summarization provider is covered by a BAA before any PHI is sent
Escalate to
```
healthcare-reviewer
```
if the summaries influence clinical decisions

用户请求：

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

响应模式：

激活
```
hipaa-compliance
```
调用
```
healthcare-phi-compliance
```
审核PHI流转、日志、存储和提示词边界
在发送任何PHI前确认摘要提供方是否受BAA覆盖
如果摘要会影响临床决策，升级至
```
healthcare-reviewer
```
处理

Example 2: Vendor/tooling decision

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