hipaa-compliance

name hipaa-compliance description HIPAA-specific entrypoint for healthcare privacy and security work. Use when a task is explicitly framed around HIPAA, PHI handling, covered entities, BAAs, breach posture, or US healthcare compliance requirements. metadata {"version":"1.0.0","origin":"ECC direct-port adaptation"} 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