/hipaa-audit

name: hipaa-audit
description: "Audit applications and infrastructure handling Protected Health Information against HIPAA — Security Rule (administrative, physical, technical safeguards), Privacy Rule, Breach Notification Rule, plus HITECH. Covers ePHI scoping, the 18 HIPAA identifiers, Business Associate Agreement (BAA) chain-of-liability, minimum-necessary standard, and breach notification timing. Use when the user mentions 'HIPAA,' 'HIPAA Security Rule,' 'HIPAA Privacy Rule,' 'PHI,' 'ePHI,' 'protected health information,' 'BAA,' 'business associate agreement,' 'covered entity,' 'business associate,' 'minimum necessary,' 'HIPAA breach,' 'HITECH,' 'healthcare compliance,' 'medical data,' 'patient data,' or audits any system that creates, receives, maintains, or transmits PHI."
allowed-tools: Read, Grep, Glob, Bash, Write, WebSearch

HIPAA Audit — Health Insurance Portability and Accountability Act

HIPAA governs how Protected Health Information (PHI) is handled in the United States healthcare ecosystem. The engineering surface area is large because PHI is broader than people often realize: a calendar entry naming a patient's appointment is PHI; an IP address logged on a portal accessed by a patient may be PHI in combination with a health condition.

The skill is structured around the four HIPAA rules with emphasis on the Security Rule's three safeguard categories (Administrative / Physical / Technical) — that's where engineering work happens. Privacy Rule, Breach Notification Rule, and HITECH layer on top.

Final compliance determinations stay with counsel and your privacy officer; this skill is the technical engineering layer.

Cross-references: `privacy-engineering` for the GDPR / CCPA-shaped privacy work that often overlaps; `iam-audit` for access control and authentication; `crypto-audit` for encryption-at-rest and in-transit detail; `secrets-audit` for key management; `siem-detection` for audit-log engineering; `incident-triage` and `security-comms` for breach response.

Scope — who is covered and what is PHI

Who must comply

• **Covered entity (CE)** — health plans, healthcare clearinghouses, healthcare providers who transmit health info electronically in connection with HIPAA-defined transactions
• **Business associate (BA)** — anyone who creates / receives / maintains / transmits PHI on behalf of a covered entity (cloud hosts holding PHI, SaaS analytics, EHR vendors, billing services, even some attorneys and consultants)
• **Subcontractor of a BA** — also a BA. The chain extends; every link needs a BAA with the link above

If a system handles PHI for a CE without a BAA, that's a violation regardless of how secure the handling is.

What is PHI / ePHI

PHI = individually identifiable health information held or transmitted by a CE or BA. ePHI = the electronic form.

The 18 HIPAA identifiers (Safe Harbor de-identification list — if all are stripped, data is no longer PHI):

1. Names 2. Geographic subdivisions smaller than state (street, city, county, ZIP — full ZIP if population < 20,000; first 3 digits OK in most cases) 3. Dates more specific than year (DOB, admission, discharge, death) — for individuals over 89, even the year requires aggregation 4. Phone numbers 5. Fax numbers 6. Email addresses 7. Social Security numbers 8. Medical record numbers 9. Health plan beneficiary numbers 10. Account numbers 11. Certificate / license numbers 12. Vehicle identifiers and serial numbers (including license plates) 13. Device identifiers and serial numbers 14. URLs 15. IP addresses 16. Biometric identifiers (finger, voice) 17. Full-face photographs and comparable images 18. Any other unique identifying number, characteristic, or code

**Important:** removing the 18 identifiers via Safe Harbor is one of two de-identification methods. The other is Expert Determination (statistical analysis confirming low re-identification risk). De-identified data is not PHI; **pseudonymized data is still PHI** (because the key linking the surrogate back to the individual is still held somewhere).

Scope reduction patterns

The most common scope reductions:

• **Limit data classes collected** — if you don't need DOB, don't collect it; don't transmit it; don't store it
• **Pseudonymize internally** where regulators allow, but understand that internal pseudonyms are still ePHI (the linking table is held by the CE / BA)
• **Use BA-signed services** where possible — AWS, Google Cloud, Azure, Stripe Healthcare, certain analytics vendors sign BAAs; many SaaS tools do not
• **Use services that contractually commit to never receive PHI** — analytics platforms that scrub on ingest, error reporters with strict PII filtering

Security Rule — the three safeguard categories

Administrative safeguards (program-level)

These are policy and program controls. Engineering teams contribute artifacts; the privacy officer owns the program.

• **§164.308(a)(1) Security Management Process** — risk analysis (the foundation; redone on material change), risk management, sanction policy, information system activity review
• **§164.308(a)(2) Assigned Security Responsibility** — a named Security Official
• **§164.308(a)(3) Workforce Security** — authorization / supervision, termination procedures
• **§164.308(a)(4) Information Access Management** — access authorization, modification
• **§164.308(a)(5) Security Awareness and Training** — including security reminders, malicious software protection, log-in monitoring, password management
• **§164.308(a)(6) Security Incident Procedures** — see `incident-triage`
• **§164.308(a)(7) Contingency Plan** — backup, disaster recovery, emergency mode operation, testing
• **§164.308(a)(8) Evaluation** — periodic technical and non-technical evaluation
• **§164.308(b)(1) Business Associate Contracts** — BAA with every BA

**Engineering audit input:** evidence packages for risk analysis (asset inventory, threat model, controls list), workforce-security records (access revi