hipaa-compliance

hipaa-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:

• 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-compliance

• healthcare-reviewer

• healthcare-emr-patterns

• healthcare-eval-harness

• security-review

Weekly Installs528Repositoryaffaan-m/everyt…ude-codeGitHub Stars157.6KFirst Seen11 days agoSecurity AuditsGen Agent Trust HubPassSocketPassSnykPassInstalled oncodex496opencode480gemini-cli477cursor477kimi-cli476antigravity476