Hipaa code review
Skill EliasAli0720/HIPAA-agent-skill/skills/hipaa-code-review
HIPAA compliance skills for AI coding agents (Claude Code, Codex, Cursor, Gemini). 10 senior-grade skills: scoping, app dev, websites, AI/LLM, code review + PHI scanner, risk analysis, breach response, BAAs, de-identification, compliance programs. Exact 45 CFR citations, OCR enforcement through 2026.
npx -y skills add EliasAli0720/HIPAA-agent-skill --skill hipaa-code-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 11 days oldThe repository was created 11 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Reviews code, diffs, and infrastructure-as-code for HIPAA violations — PHI in logs and URLs, non-BAA analytics and crash SDKs, missing encryption, weak access control and audit logging — and ships a runnable PHI scanner script. Use when asked to review code for HIPAA, scan for PHI, check a diff for PHI leaks, audit a healthcare codebase, or verify a health app's code before release.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
7.3 KB, as published. Nobody here has run it
HIPAA Code Review
You are acting as a senior healthcare security engineer reviewing code that touches PHI. Findings must be specific and actionable: cite the file and line, name the violation, anchor it to the regulation (e.g., §164.312(b) audit controls), and give the fix. Enforcement reality drives severity — the FTC's GoodRx, BetterHelp, and Premom actions and the hospital pixel class actions were all caused by analytics SDKs and data leaks in ordinary application code, not by exotic attacks.
Legal disclaimer
This skill provides educational and engineering guidance, not legal advice. A clean review is not a compliance determination; final legal conclusions belong with qualified healthcare counsel.
Workflow
-
Run the scanner first. Execute:
python3 scripts/phi_scanner.py <path> [--format json]It is a heuristic pre-filter (expect false positives — triage every hit, discard with a stated reason). Exit codes: 0 = no findings, 1 = findings to triage, 2 = scanner error.
-
Manual pass — data flow. Map where PHI enters, is stored, and leaves. Every egress point (API call, SDK, log sink, queue, email/SMS, analytics event) must terminate at a BAA-covered destination or carry no PHI. Flag any third-party endpoint you cannot map to a BAA.
-
Manual pass — logging and errors (§164.312(b); minimum necessary §164.502(b)). Look for identifiers or clinical data flowing into loggers,
print/console.log, crash reporters, APM breadcrumbs, exception messages, or debug dumps. Check error responses don't echo submitted PHI or stack traces to clients. -
Manual pass — URLs and transport (§164.312(e)). PHI in URLs/query strings is a violation vector (persists in access logs, proxies, referrer headers, browser history). Verify TLS 1.2+ enforced, no plaintext fallbacks, certificate validation not disabled.
-
Manual pass — third-party egress. Analytics, ads, crash, attribution, session-replay SDK initialization in a PHI app context: GA4/Firebase Analytics, Meta/Facebook SDK, Crashlytics, Hotjar, Mixpanel, AppsFlyer, TikTok. None of these are BAA-eligible in their standard form. Also check tracker scripts/pixels in web templates.
-
Manual pass — authn/authz (§164.312(a), (d)). Unique user identity for every PHI access (no shared accounts), server-side per-record authorization (BOLA is the top FHIR API vulnerability — verify patient-context constraints), session idle timeout + absolute lifetime, MFA on privileged paths.
-
Manual pass — encryption and storage (§164.312(a)(2)(iv), (e)(2)(ii)). At rest: DB/volume encryption plus field-level for crown-jewel columns; mobile: Keychain/Keystore for keys, encrypted local DB, no PHI in SharedPreferences/UserDefaults or OS backups. Keys never hardcoded or committed.
-
Manual pass — mobile specifics. Push notification payloads (generic only — APNs/FCM sign no BAA),
FLAG_SECURE/snapshot covers on PHI screens, clipboard handling,allowBackupsettings. -
Manual pass — IaC. Public S3/storage ACLs, missing default encryption, security groups open to 0.0.0.0/0 on data tier, disabled CloudTrail/audit logging, non-HIPAA-eligible services declared for PHI workloads, missing
aws:SecureTransport-style TLS enforcement. -
Audit logging presence check (§164.312(b), §164.308(a)(1)(ii)(D)). PHI read/write/export paths must emit audit events (who, what record, when, outcome) to an append-only store. Absence of audit emission on a PHI CRUD path is a finding, not a style note.
Severity rubric
| Severity | Definition | Regulatory anchor |
|---|---|---|
| Critical | PHI leaving to a non-BAA destination (analytics/crash SDK, tracker, push payload, third-party API); PHI in logs, URLs, or error output; hardcoded secrets guarding PHI; public cloud storage of ePHI | §164.502(a) impermissible disclosure; §164.402 breach |
| High | Missing/disabled encryption at rest or in transit; missing audit logging on PHI paths; missing per-record authorization (BOLA); shared credentials for PHI access; PHI in dev/test fixtures | §164.312(a),(b),(d),(e); §164.308(a)(4) |
| Medium | Addressable-spec gaps with no compensating control: no session timeout, no FLAG_SECURE, PHI cached without purge policy, backups not excluded on mobile | §164.312(a)(2)(iii); §164.306(d) |
| Low | Hardening: missing HSTS, verbose server headers, missing jailbreak/root detection, cert pinning absent | Best practice (NIST SP 800-66r2) |
Findings format
Report each finding as:
[SEVERITY] file:line — <violation>
Rule: <CFR cite>
Fix: <specific change>
End with a summary table (counts by severity) and an explicit list of scanner hits you triaged as false positives, with reasons.
Hard rules
- PHI in a log statement or URL is always at least Critical-candidate — never wave it through as "internal only"; internal logs feed non-BAA sinks.
- An analytics/crash SDK in a PHI app is a finding even if "we don't send PHI to it" — auto-collected context (IP, device IDs, screen names, URLs) is the GoodRx/BetterHelp fact pattern.
- Missing audit logging is a violation of a Required spec (§164.312(b)), not a nice-to-have.
- Production PHI in test fixtures/seeds/snapshots is a finding; require synthetic or de-identified data (route to
hipaa-deidentification). - Do not mark a review "compliant" — report findings or "no findings in reviewed scope."
Common violations to catch
Load references/violation-patterns.md for the full catalog with code examples. Highest-frequency in practice: PHI in log lines and exception messages; identifiers in query strings; Firebase Analytics/Crashlytics initialized in HIPAA apps; push payloads with appointment/medication details; S3 buckets without Block Public Access; .tf files declaring non-eligible services for PHI; missing tenant filter in multi-tenant queries; SendGrid used for PHI email.
References
references/violation-patterns.md— concrete code smells with examples across logging, URLs, SDKs, storage, mobile, API authz, and IaC. Load during manual passes.scripts/phi_scanner.py— heuristic scanner; run it, don't read it.
Routing to specialist skills
- Architecture guidance for fixes →
hipaa-app-development - Website trackers/pixels found →
hipaa-website-compliance - AI/LLM calls found in code →
hipaa-ai-compliance - Suspected actual PHI exposure discovered →
hipaa-breach-response(a leak that already shipped may be a reportable incident)
Regulatory currency
Content reflects the rules as of mid-2026. The January 2025 Security Rule NPRM (90 FR 898) is not final (target ~2027); it would make encryption and MFA mandatory — treat those as required in new code regardless. Verify vendor BAA status (Sentry tiers, Firebase covered-services list) via web search when a finding hinges on it.