HIPAA support triage
Ticket triage for healthcare environments — classifies, prioritizes, and routes support tickets with PHI-aware handling: automatic PHI detection, redaction defaults in shared views, and routing restricted to authorized queues. Use when the user operates under HIPAA or handles patient data in support, mentions PHI in tickets, healthcare support triage, or BAA-covered support operations.
In healthcare support, the routing decision and the compliance decision are the same decision. A ticket containing patient data routed to the wrong queue isn't a delay — it's a reportable event. This skill triages like the standard router but treats PHI as radioactive by default: detected on arrival, masked in every shared surface, and routed only within the authorized boundary.
When to run
- Continuous on new-ticket arrival in BAA-covered support environments
- Batch: PHI-aware sweep of an existing queue before broadening its visibility
Computer scopes
- Support: incoming tickets, authorized-queue map with PHI-clearance flags
- Docs: the org's PHI-handling policy and minimum-necessary standard (the rulebook)
- Directory: agent authorization roster for PHI queues
- Audit log: every detection, masking, routing, and access event (write)
Workflow
- On arrival, scan for PHI: identifiers in combination with health context — names, MRNs, dates of care, conditions, medications, insurance details. Tag the ticket's PHI status before any other processing.
- Apply masking defaults: PHI-tagged content is redacted in list views, notifications, search snippets, and any surface visible beyond the authorized roster. The unmasked record lives only inside the authorized queue.
- Triage as usual — type, severity, priority — but with the constraint hierarchy inverted: the routing set is first filtered to PHI-authorized queues, then optimized for fit. A better-skilled but unauthorized queue is not a candidate.
- Reason codes cite both the classification precedent and the PHI-handling rule applied — the audit trail must show compliance was structural, not incidental.
- Below confidence threshold, route to the *authorized* human triage lane with analysis attached; never to general triage.
- Log every event; produce the weekly PHI-handling summary for the compliance owner: volumes, maskings, any access-boundary events.
Guardrails
- Autonomy: L2 for triage within the authorized boundary; anything requiring boundary exceptions is L3-gated to the compliance owner, individually.
- Minimum necessary is the design principle: no PHI in notifications, digests, or this skill's own summaries — counts and categories only.
- PHI detection errs toward over-tagging; untagging is a human act with reason logged.
Output
Per ticket: PHI status, masked shared views, routed destination within boundary, dual reason code. Weekly: compliance summary (volumes, masking stats, boundary events) — PHI-free.Eval fixtures
- Set: 150 labeled healthcare tickets — 55 with seeded PHI of varying subtlety, 15 with health context but no identifiers, 10 requiring the skilled-but-unauthorized routing test.
- Rubric: PHI detection recall (weighted to zero-miss on direct identifiers); over-tag rate within tolerance; routing never selects unauthorized queues; summaries contain zero PHI.
- Ship gate: PHI recall ≥ 0.98 with direct-identifier misses 0; unauthorized-routing rate 0.
