Building AI-Driven Healthcare Workflow Engines: From Referrals to Prior Authorization

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.

Documentation and Follow-ups

The documentation workflow generalizes the same idea to clinical write-ups – SOAP notes, assessment summaries, referral letters. Source data goes in, AI produces a draft, a human reviews and finalizes it. The one rule that can’t bend anywhere in this workflow: AI output never silently overwrites source clinical documentation. Draft and final are always distinguishable, and finalization is always a deliberate human act.

Follow-ups close the loop on the other three. A referral sent four days ago with no response isn’t something a person should have to remember to check – it’s exactly the kind of deadline-tracking a workflow engine handles natively. When the engine detects an overdue state, it hands context to the AI to draft a follow-up message, and – same pattern again – that draft waits for human approval before anything goes out.

Why “Human Approves, AI Drafts” isn’t just a Compliance Checkbox

It would be easy to read the human-approval step as a legal hedge bolted onto an otherwise autonomous system. It’s actually load-bearing for a more basic reason: AI output in this domain is genuinely sometimes wrong, and the cost of being wrong ranges from “a slightly awkward follow-up email” to “an incorrect basis for a coverage decision.” A workflow engine that treats every AI recommendation as a proposal rather than an action is what makes it acceptable to point AI at healthcare administrative work at all. It’s also what makes the system auditable in a way regulators, payers, and risk teams can actually evaluate – every recommendation, every edit, every approval, every rejection is a timestamped event with a clear actor: AI, or a named human.

What this Buys you in Practice

Once the engine exists, adding a fifth workflow – say, appointment scheduling optimization, or denial appeals – isn’t a rebuild. It’s a new trigger, a new AI prompt, and a new proposed-action type plugged into the same state machine, the same approval UI, and the same audit log. That reusability is the actual payoff of building a workflow engine instead of four standalone AI features: the hard parts (state management, human-in-the-loop enforcement, auditability) get built once, and every new workflow after the first is comparatively cheap.

The honest summary: AI doesn’t need to make clinical decisions to be valuable in healthcare operations. It needs to reliably do the repetitive extraction, summarization, and drafting work that currently consumes clinician and coordinator time – inside a system architected so a human is always the one who decides what actually happens next.