accidental-PHI

Rule

PHI never enters persistent stores. PHI never enters this repo. PHI never enters chat logs. PHI never enters local cache files. PHI never enters Bash command output. If anything that could be PHI surfaces, halt the work, scrub it, then continue.

The bar is could be, not is. Better to stop on a false positive than miss a real one.

What counts as PHI

Per HIPAA's 18 identifiers:

Identifier	Examples
Names	First + Last name combinations not obviously fictional
Dates of birth	DD/MM/YYYY, MM-DD-YY, "born in 1958", anything with "birthday" + numbers
Telephone numbers	(XXX) XXX-XXXX, XXX-XXX-XXXX in a patient context
Addresses	Street + city + state combos (especially with name nearby)
Email addresses	When tied to a patient
SSN, MRN, account numbers	XXX-XX-XXXX, any 8-12 digit string in clinical context
Health plan / insurance IDs	"Blue Cross #...", "Medicare ID..."
Prescription numbers, NDC codes	Rx #, anything that looks like NDC
Specific dosing for a specific person	"John takes 500mg <med> BID"
Vehicle / license / device identifiers	when tied to a patient
Photos, biometrics	not relevant in text-only chat but flag if mentioned
Any geographic subdivision smaller than state	tied to a patient

Workplace context signals:

• Filenames or paths that contain patient, Rx, script, MRN, EHR, clinical, <employer>-internal
• Paste from clinical / pharmacy / EHR systems
• "for patient X" / "the patient" / "Mrs. Y picked up"
• Site numbers + clinical detail combo

Trigger patterns (regex-style)

Fire on ANY of these matched against current chat content, file content being created, or Bash command output:

• \b\d{3}[-.\s]?\d{3}[-.\s]?\d{4}\b (phone-shaped)
• \b\d{3}[-]\d{2}[-]\d{4}\b (SSN-shaped)
• \b(0?[1-9]|1[0-2])[\/\-](0?[1-9]|[12]\d|3[01])[\/\-](19|20)\d{2}\b (DOB-shaped MM/DD/YYYY)
• \bRx\s*#?\s*\d{6,}\b (Rx number)
• \bMRN\s*#?\s*\d+\b (MRN)
• Any <title> <first-name> <last-name> pattern in a healthcare-context document (Mrs. Mary Smith, Dr. James Lee, Mr. / Ms.)
• "patient" + any number sequence in 50 chars

Suppression rules

Do NOT fire when:

• Content is clearly fictional or test data AND the operator has explicitly named it as such ("this is dummy data", "fake patient", "lorem ipsum patient")
• Numbers are in code that's clearly NOT PHI (port: 5170, version: 1.2.3, hex colors)
• Discussing the rule itself (this very SKILL.md mentions PHI patterns; that's discussion, not data)
• Discussing PHI as an abstract concept (HIPAA training, policy discussion)

When unsure: fire. False positives are cheap; false negatives are catastrophic.

Response when fired

HARD STOP. Do not output the suspect content. Do not log it.

Script:

1. Halt immediately. If mid-Bash, do not run the command. If mid-write, do not write the file. If mid-chat-response, drop the response.
2. Quote nothing. Do not echo the suspect text back to the operator in the chat — that would persist it in the chat log.
3. Name the trigger generically: "Stopped — that looks like it could be PHI (<generic pattern type — phone-shaped, name+DOB, etc.>)."
4. Ask for explicit clearance: "Confirm one:
   • 'fake / test data' — proceed (logged as confirmed-test)
   • 'real, scrub it' — I'll wait while you remove and re-paste
   • 'real, but in a way that's HIPAA-permitted for this work' — talk it through; do not proceed yet"
5. Wait. Do not proceed until the operator picks.

If real PHI was about to be written somewhere persistent, also say:

"If real PHI was already pasted, the message is in this conversation's log — let's scrub the original message and start fresh. Tell me when you're ready."

Override

There is NO override for "trust me, log it anyway." The skill never accepts that.

The only paths forward:

1. The operator confirms "fake / test data" — log this confirmation; proceed
2. The operator scrubs the real PHI — proceed with scrubbed version
3. The operator halts the work entirely

What this skill never does

• Echo the suspect content back in the chat (would persist PHI)
• Log the suspect content anywhere (would persist PHI)
• Accept "I know it looks like PHI but it's not" without explicit confirmation of fake / test data
• Soft-deliver. There is no soft version. Always hard, always immediately.
• Consolidate with other skills. PHI fires alone — it interrupts everything else firing same turn.

Cross-references

This skill suppresses other skills firing same turn. Whatever else might have fired, accidental-PHI fires alone and resolves first. Other skills can re-fire after PHI is resolved.

• commit-message-honesty — if PHI was about to land in a commit message, both fire; PHI takes precedence.

Why this earns its keep

Operators who work in healthcare contexts (clinicians, pharmacists, payer-adjacent roles, healthtech operators) handle PHI as a daily constraint. Data leakage in any form (chat, code, repo, logs, screenshots, anything) is a fireable offense and a HIPAA violation. The cost of a single leak is enormous; the cost of a false positive is 30 seconds of confirmation. The math is overwhelming.

This skill has the highest priority in the system because the failure mode is the most severe. Adjacent sensitive-data skills (financial / PCI, regulated industry data, customer PII) follow the same hard-stop pattern.