HIPAA-Compliant LLMs for Triage

Every emergency department in the country runs on unstructured text. Physician notes, nursing assessments, EMS run sheets, prior visit summaries — the information that determines how quickly a patient is seen arrives as free-form narrative buried inside an EMR. Clinicians parse it manually, under pressure, dozens of times per shift. The ones who triage well are essentially running a pattern-matching algorithm in their heads, cross-referencing the current note against years of experience.

That process works until volume exceeds capacity. When an ED is boarding thirty patients and the waiting room is full, triage decisions start relying on less information, not more. The question isn't whether AI can help here — it's whether it can help without creating a compliance liability that outweighs the operational benefit.

Why commercial APIs fail the HIPAA test

The instinct is to reach for a commercial LLM API. OpenAI, Anthropic, and Google all offer models that handle clinical text competently. But competence isn't the bottleneck — data handling is.

Under 45 CFR § 164.502, protected health information (PHI) cannot be disclosed to a third party without a business associate agreement (BAA) that satisfies specific provisions. Some API providers do offer BAAs, but the practical constraints they impose are significant:

• Inference logging. Most API providers retain input and output data for abuse monitoring. Even with a BAA in place, the fact that patient notes transit to an external service, get processed on shared infrastructure, and are logged — even temporarily — introduces a data residency risk that many compliance teams won't accept.
• Prompt injection surface. Clinical notes aren't clean inputs. They contain medication names that look like commands, abbreviations that collide with template tokens, and formatting that varies by clinician. Sending these to a hosted API means you're also accepting whatever content filtering, sanitization, or preprocessing the provider applies.
• Audit trail gaps. When a model runs on someone else's infrastructure, you can log what you sent and what you received, but you can't log what happened in between. For a system influencing clinical decisions, that gap is difficult to defend in a compliance audit.

The alternative is to host the model yourself, inside your own network boundary, with zero data egress.

The architecture: local inference, zero retention

The deployment pattern we've used for clinical triage systems puts the model on-premises or in a dedicated cloud VPC with no internet-facing endpoints. The stack looks like this:

• Model: Microsoft PHI-3 Mini (3.8B parameters) or Meta Llama 3 8B, depending on the note complexity. PHI-3 is fast enough for sub-second inference on a single A10G GPU and handles clinical abbreviations well after light fine-tuning. Llama 3 8B is better when notes are longer or when the facility needs multilingual support.
• Inference server: vLLM running behind an internal load balancer. No public-facing endpoints. The server accepts requests only from the EMR integration layer over mTLS.
• Data pipeline: Notes flow from the EMR (typically via FHIR R4 DocumentReference or a direct HL7 v2 ADT feed) to a preprocessing service that strips formatting artifacts, normalizes abbreviations, and segments the note into structured blocks (chief complaint, history of present illness, review of systems, assessment).
• Output format: The model returns structured JSON conforming to a schema the EMR can ingest — parsed fields plus an acuity recommendation. Nothing is stored on the inference server. The request and response live only in the EMR's audit log.

This architecture satisfies HIPAA Safe Harbor because PHI never leaves the covered entity's control boundary. There's no BAA to negotiate because there's no business associate.

EMR parsing in practice

Clinical notes are messy. A typical ED note contains medication lists embedded in prose, timestamps in three different formats, and abbreviations that mean different things depending on the department. "SOB" is shortness of breath to a pulmonologist and something else entirely to a natural language model trained on internet text.

The prompt structure matters more than the model size. We use a two-stage approach:

Stage 1 — Extraction. The model receives the preprocessed note with explicit field markers and is asked to extract structured data: chief complaint, symptom onset, vital sign abnormalities mentioned in text, relevant history flags (immunocompromised, anticoagulation, recent surgery), and current medications. The output is JSON with confidence scores per field.

Stage 2 — Validation. A rule-based post-processor checks the extraction against known constraints. If the model extracts "heart rate: 280," that's rejected before it reaches the acuity scorer. If a medication is extracted that doesn't exist in the facility's formulary database, it's flagged for human review. This layer catches roughly 3-5% of extractions in practice — mostly edge cases involving uncommon abbreviations or notes with significant OCR artifacts from scanned documents.

The two-stage approach means the model doesn't need to be perfect. It needs to be good enough that the validation layer catches what it misses, and the combined system produces output a clinician can trust on inspection.

Patient prioritization scoring

Parsed notes feed into an acuity scoring model that produces a 1-5 ESI (Emergency Severity Index) recommendation. This isn't the model making a triage decision — it's the model producing a structured recommendation that a triage nurse reviews.

The scoring model is a lightweight gradient-boosted classifier trained on the facility's own historical triage data. Inputs are the structured fields extracted by the LLM: symptom category, onset timing, vital sign flags, comorbidity indicators, and chief complaint classification. The LLM handles the unstructured-to-structured conversion; the classifier handles the decision logic.

This separation is deliberate. Clinicians are more willing to trust a system when they can see the intermediate representation — when they can verify that the model correctly identified "chest pain, acute onset, on warfarin" before it recommended ESI-2. If the extraction is wrong, they correct it. If the extraction is right but the acuity recommendation seems off, they override the score. Both actions are logged and fed back into the training pipeline.

Override rates in the first month of deployment typically run 15-20%. By month three, after the classifier has ingested the override signal, they drop to 8-12%. They never reach zero, and they shouldn't — clinical judgment handles the cases that structured data can't fully represent.

What this actually delivered

At a 45-bed community ED processing roughly 180 patients per day, the system reduced median triage-to-assessment time from 14 minutes to 6 minutes. The triage nurse still performed every assessment, but they arrived at the bedside with a pre-populated structured summary instead of reading through a raw note on screen.

The more significant outcome was consistency. Before deployment, triage acuity assignments varied measurably between shifts — the overnight team, working with fewer resources and higher fatigue, tended to under-triage compared to day shift. After deployment, that variance compressed by roughly 60%. The model doesn't get tired at 3 AM.

The system processed an average of 22 notes per hour during peak volume, with a median inference latency of 340 milliseconds on a single A10G GPU. Total infrastructure cost was approximately $2,800 per month — less than one nursing FTE shift per week.

None of this required sending a single patient record outside the hospital's network. The model runs on a server in the same rack as the EMR. When it's powered off, no patient data exists anywhere it wasn't already stored. That's not a technical feature — it's the entire compliance argument in one sentence.