/skill

HIPAA Compliance

Use this skill for work about HIPAA or US protected health information (PHI).

HIPAA rules can depend on facts and contracts. Do not claim that code is fully compliant. State what you checked, what is not known, and what needs legal or security review.

When to Use

Use this skill when a task:

• Names HIPAA, PHI, a covered entity, a business associate, or a BAA
• Stores, reads, changes, sends, prints, or deletes PHI
• Uses patient data in logs, reports, support tools, AI prompts, or test data
• Builds tools for patients, doctors, clinics, health plans, or billing teams
• Needs strict access rules or audit records

Do not use it only because an app is about health. First check if the data can identify a person and is tied to health care, payment, or treatment.

Other Skills

Use these skills with this one when they are available:

• healthcare-phi-compliance for data labels, safe storage, encryption, audit logs, and leak control
• healthcare-reviewer for a health care review of code, system plans, or product behavior
• security-review for login, access, secrets, input checks, APIs, and hosting safety
• healthcare-emr-patterns for health record system design
• healthcare-eval-harness for tests of health care flows

If a named skill is not available, apply the same checks in this file and say which review is still needed.

Review Steps

1. Map the data.

   List where PHI comes from, where it goes, where it is stored, who can see it, and when it is deleted.

2. Check if the data is PHI.

   Include direct facts, free text, files, images, audio, video, and metadata. A mix of harmless fields may still identify a person.

3. Check each party.

   Find the covered entity, business associates, staff roles, vendors, and model providers. Do not guess that a BAA exists.

4. Limit access.

   Give each user and service only the smallest data set and set of actions needed for its job.

5. Protect the data.

   Require secure transit and storage, safe key control, backups, timeouts, and a clear delete plan.

6. Add audit records.

   Record who read, made, changed, sent, printed, downloaded, or deleted PHI. Record time, action, object ID, and result. Do not copy PHI into the audit record.

7. Check every output.

   Review logs, error text, URLs, alerts, emails, files, exports, print views, AI prompts, and support screens.

8. Test failure cases.

   Test wrong users, old links, shared devices, lost network links, retries, partial saves, duplicate jobs, and vendor failures.

9. List open risks.

   Mark any missing BAA, unclear data owner, weak delete rule, or unreviewed vendor as blocked.

10. Ask for expert review when needed.

    Use legal, privacy, or security staff for final HIPAA findings. Use healthcare-reviewer when patient safety or care work may change.

Guardrails

• Never put PHI in logs, usage data, crash reports, source code, test fixtures, AI prompts, or error text unless the full path is approved for PHI.
• Never put PHI in a URL, page title, file name, browser storage, screenshot, copied sample, or chat message.
• Do not use real patient data in local work, demos, tests, or bug reports. Use fake data.
• Use opaque IDs instead of names, record numbers, phone numbers, email addresses, or home addresses.
• Require login and role checks for every PHI read and write. Hiding a button is not an access check.
• Check access again for downloads, exports, print views, search results, and background jobs.
• Block third-party tools by default until their BAA status, data use, data location, and delete rules are clear.
• Do not send PHI to a vendor just because the vendor offers a BAA. Confirm that the right product, account, and data path are covered.
• Do not use PHI to train a model unless the use is approved and covered by the right terms.
• Remove PHI from queues, caches, temp files, backups, and failed jobs under a clear life-cycle rule.
• Make links short-lived when they can open PHI. Do not place secret access keys in URLs.
• Plan for staff access changes. Remove access fast when a role changes or a worker leaves.
• Treat free text, file notes, voice clips, and images as likely PHI.
• Treat de-identified data as PHI until the removal method has been checked.
• Keep audit records safe from edits. Limit who can read them.
• Do not say a system is “HIPAA certified.” Give a list of checks, proof, gaps, and owners.

Concrete Example

User request:

Add AI visit notes to our doctor page. We serve US clinics.

Apply the skill like this:

1. Mark the visit text and result as PHI.
2. Map the path from the clinic to the app, model provider, data store, and doctor.
3. Check that the model provider and exact service are covered by a signed BAA.
4. Send only the visit text needed for the note.
5. Do not store prompts or results in model logs unless that storage is approved.
6. Encrypt saved notes and limit them to the care team.
7. Log the user ID, patient object ID, action, time, and result. Do not log note text.
8. Test a user from another clinic, an old session, a retry, and a failed model call.
9. Add human review before the note becomes part of the health record.
10. Ask healthcare-reviewer to review the flow if the note may guide care.

A safe audit event may look like this:

{
  "actor_id": "usr_42",
  "patient_id": "pat_91f2",
  "action": "visit_note.create",
  "result": "success",
  "time": "2026-09-14T15:30:00Z"
}

Do not include the patient name, visit text, diagnosis, or note in this event.

Vendor Example

User request:

Can we send patient support chats to our usage tool?

Treat the chats as PHI until proven otherwise. Block the data path until the vendor, product plan, BAA, storage rules, and delete rules are approved. Prefer sending a safe event such as support_chat_opened with an opaque account ID. Do not send the chat text.