AI Healthcare Workflow Engines: Referrals to Prior Auth

Most discussions of “AI in healthcare” stay abstract – bigger context windows, better diagnostic accuracy, multimodal clinical reasoning. Useful research, but disconnected from what actually eats a care coordinator’s or physician’s day: referrals that sit in a queue, prior authorizations that require assembling documentation from three different places, encounter notes that need turning into a clean summary, and follow-ups that fall through the cracks because nobody was tracking a deadline.

These are administrative workflows, not clinical decisions – and that distinction turns out to be exactly where AI can add value safely and immediately, without wading into the much harder and more fraught territory of autonomous clinical judgment.

Here’s what that looks like as a concrete system, walking through four workflows on top of one shared engine.

The Pattern, Stated Once

Every one of these workflows – referral triage, prior authorization, documentation, follow-up – follows the same shape:

Healthcare Event
  -> Workflow Trigger
  -> Gather Context
  -> AI Analysis / Recommendation
  -> Proposed Action
  -> Human Review / Approval
  -> Execute Action
  -> Audit Trail

That repetition is the whole architectural insight. If you build four independent “AI features,” you get four different approval UIs, four different audit implementations, four different ways of representing AI confidence, and four times the maintenance surface. If you instead build one workflow engine with a state machine, a step model, and a human-approval checkpoint, then a referral workflow and a prior-authorization workflow become configurations of the same engine, not separate systems.

Referral Automation

A referral arrives – say, a cardiology referral for chest pain with an abnormal ECG noted, but no ECG report attached. The workflow engine picks it up (REFERRAL_RECEIVED), gathers whatever context is available, and hands it to the AI step for analysis. The AI’s job here is narrow and well-defined: extract the specialty, judge urgency from the stated reason, and identify what’s missing.

{
  "urgency": "routine",
  "specialty": "Cardiology",
  "missingInformation": ["Recent ECG report"],
  "recommendedAction": "REQUEST_DOCUMENTATION",
  "confidence": 0.91
}

Notice what the AI is not doing: it’s not deciding whether the chest pain is cardiac. It’s not triaging clinical severity beyond a coarse routing signal. It’s doing exactly the kind of pattern-matching-over-text task language models are good at – extraction and classification – and leaving the judgment call (is this recommendation right?) to the coordinator or physician reviewing it. The workflow sits in AWAITING_APPROVAL until a human acts. Only then does it move to executing the (simulated, in a POC) documentation request.

Prior Authorization

This is the workflow where AI earns its keep most obviously, because prior auth is fundamentally a documentation-assembly problem. An MRI lumbar spine order comes in with eight weeks of documented conservative treatment behind it. The AI’s role is to draft the pieces a human would otherwise write from scratch: a clinical summary, a list of supporting evidence points, and an explicit list of what’s still missing before the packet is submission-ready.

The critical design decision here isn’t the drafting – it’s what happens to that draft. It never auto-submits. It’s labeled, structurally and visibly, as AI-GENERATED, and it sits in front of a clinician who can approve it as-is, edit it, or reject it outright. The system tracks that distinction permanently: an approved-as-drafted recommendation and a clinician-edited one are not the same audit event, and they shouldn’t be treated the same way downstream.