HIPAA Compliance

Use this as a HIPAA-specific entry point when tasks explicitly involve US healthcare compliance. This skill is intentionally kept lean and prescriptive:

• healthcare-phi-compliance remains the primary implementation skill for handling PHI/PII, data classification, audit logs, encryption, and breach prevention.
• healthcare-reviewer remains the specialist reviewer when code, architecture, or product behavior requires healthcare-aware secondary review.
• security-review still applies to general authentication, input handling, keys, APIs, and deployment hardening.

When to Use

• 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 risk
• Designing systems for patients or clinicians where minimum necessary access and auditability matter

How It Works

Think of HIPAA as an overlay layer on top of the broader healthcare privacy skills:

1. Start with healthcare-phi-compliance to get concrete implementation rules.
2. Apply HIPAA-specific decision gates:
   • Is this data PHI?
   • Is the actor a covered entity or business associate?
   • Does a vendor or model provider need a BAA before touching the data?
   • Is access restricted to minimum necessary?
   • Are read/write/export events auditable?
3. If the task affects patient safety, clinical workflow, or regulated production architecture, escalate to healthcare-reviewer.

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 any read or write of PHI.
• Treat third-party SaaS, observability, support tools, and LLM providers as off-limits by default until BAA status and data boundaries are explicit.
• Follow minimum necessary access: the right user should see only the smallest slice of PHI needed to complete the task.
• Prefer opaque internal IDs over names, MRNs, phone numbers, addresses, or other identifiers.

Examples

Example 1: Product requirement framed around 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 flow, logging, storage, and prompt boundaries
• Verify the summary-generation provider is covered by a BAA before any PHI is sent
• Escalate to healthcare-reviewer if summaries influence clinical decision-making

Example 2: Vendor / tool decision

User request:

Can we send support chat transcripts and patient messages to our analytics platform?

Response pattern:

• Assume those messages may contain PHI
• Block the design unless the analytics vendor is approved for HIPAA-constrained workloads and the data path is minimized
• Require de-identification or a non-PHI event model whenever possible

Related Skills

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