HIPAA Compliance
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.
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
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-Specific Guardrails
- 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.
Examples
Example 1: Product request framed as 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
Example 2: Vendor/tooling decision
User request:
Can we send support transcripts and patient messages into our analytics stack?
Response pattern:
- Assume those messages may contain PHI
- Block the design unless the analytics vendor is approved for HIPAA-bound workloads and the data path is minimized
- Require redaction or a non-PHI event model when possible
Related Skills
healthcare-phi-compliancehealthcare-reviewerhealthcare-emr-patternshealthcare-eval-harnesssecurity-review
---
name: hipaa-compliance
description: Provides HIPAA-specific decision gates and guardrails for healthcare software, directing users to implementation and review skills for PHI handling, audit logging, and compliance.
---
# HIPAA Compliance
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.
## 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
## How It Works
Treat HIPAA as an overlay on top of the broader healthcare privacy skill:
1. Start with `healthcare-phi-compliance` for the concrete implementation rules.
2. 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?
3. Escalate to `healthcare-reviewer` if the task affects patient safety, clinical workflows, or regulated production architecture.
## HIPAA-Specific Guardrails
- 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.
## Examples
### Example 1: Product request framed as 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
### Example 2: Vendor/tooling decision
User request:
> Can we send support transcripts and patient messages into our analytics stack?
Response pattern:
- Assume those messages may contain PHI
- Block the design unless the analytics vendor is approved for HIPAA-bound workloads and the data path is minimized
- Require redaction or a non-PHI event model when possible
## Related Skills
- `healthcare-phi-compliance`
- `healthcare-reviewer`
- `healthcare-emr-patterns`
- `healthcare-eval-harness`
- `security-review`
