Prior authorization is the most-hated workflow in American healthcare, and the industry is about to spend two years re-plumbing it. Most teams are focused on the wrong layer.
Physicians now complete an average of 39 prior authorization requests each per week, burning roughly 13 staff hours per physician in the process; 40% of practices employ people who do nothing else. In the AMA's 2024 survey, 93% of physicians said prior auth delays care and 82% said it can push patients to abandon treatment altogether (AMA, 2024). Regulators have finally moved: the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) mandates a FHIR-based Prior Authorization API — and three other APIs — live by January 1, 2027, on top of operational turnaround rules that already began in 2026.
So every payer and a lot of provider organizations are now racing to stand up a FHIR API. Here is the uncomfortable part: the API is the easy layer. A conformant PAS endpoint is a few weeks of work. The thing that actually decides whether prior auth gets faster — or just gets a new façade — is the stateful workflow engine behind the endpoint. That is where we want to spend this article, because it is the part almost nobody writes about, and it is the part we have spent years building in regulated, high-volume decisioning systems.
Why prior authorization breaks the request/response model
The instinct is to treat a prior auth like an API call: submit a request, get a decision. Real prior authorization is nothing like that. A single authorization is a long-running, multi-party, stateful process that can span minutes or two weeks, and it looks like this:
- Coverage discovery (CRD) — at the moment of ordering, the provider's system asks the payer whether this service even needs authorization, and what the rules are.
- Documentation (DTR) — a "smart" questionnaire pulls what it can straight from the chart and asks the clinician only for what's missing.
- Submission (PAS) — the request goes to the payer as FHIR, which — where required — is still carried as an X12 278 under the hood.
- Adjudication — the payer runs it against medical-necessity criteria.
- The pend — very often the answer is not yes or no but "pended for clinical review," which parks the request on a human utilization-management nurse or physician for hours or days.
- Decision, and maybe appeal — approve, or deny with a specific reason, which may loop into an appeal.
That flow crosses two or three organizations, at least one human reviewer, and an asynchronous wait measured in days. It has to survive a process restart without losing its place, and every step of it has to be auditable — CMS-0057 now requires payers to send a specific denial reason and to report prior-auth metrics publicly. None of that is a request/response problem. It is a workflow-engine problem.
The architecture: an orchestrator owns the sequence, capabilities own the domain
The pattern that survives contact with this reality — and the one we have run in production across regulated, multi-step decisioning journeys handling millions of applications — is a clean split between an orchestrator and a set of pluggable capabilities.
The orchestrator is a workflow engine. It owns the sequence: what happens next, what can run in parallel, what to do on failure, when to pause and when to resume. It knows nothing about the clinical detail of an eligibility check or a medical-necessity rule.
Each capability is an independent service that owns one domain — eligibility, coverage requirements (CRD), documentation (DTR), medical-necessity rules, PAS submission, human review. A capability exposes two things to the orchestrator: an init call to start its work, and it emits a terminal event when it is done. Critically, each capability is its own state machine with at least one terminal state, so it can be developed, tested, scaled, and reused across many workflows without the orchestrator reaching inside it.
This is not architectural neatness for its own sake. It is what lets you reuse the same eligibility or medical-necessity capability across radiology, cardiology, and pharmacy prior-auth flows, and swap a payer-specific rule set without touching the engine. Orchestrator owns sequence; capabilities own domain.
The engineering that actually matters
Once you accept that prior auth is a long-running workflow, a specific set of hard problems shows up — and how you solve them is the difference between a system that reduces burden and one that just relocates it.
1. Async hold states — you cannot block a thread for seven days
When a request is pended for clinical review, or a payer takes two days to respond, you cannot hold an open connection or a database transaction waiting for it. Every external wait has to be modeled as an asynchronous step with a durable hold state: the workflow persists exactly where it is, releases everything, and is re-awoken by an inbound signal — a FHIR Subscription notification, a polling result, or a human clicking "approve." The moment you model waits as first-class, resumable states instead of blocked threads, the SLA clocks (72 hours for urgent, 7 days for standard) become timers and escalations on those states rather than hope.
2. Straight-through vs. pended — an explicit, auditable branch
The single biggest lever on turnaround is auto-approving the requests that should never have needed a human. If CRD said authorization was required and DTR gathered documentation that clearly satisfies the criteria, the request should route straight through. If anything is ambiguous, it should route to a human. This branch — call it straight-through vs. pended — must be an explicit decision node with a recorded reason, not an emergent side effect of code paths. Recording why a request auto-approved or pended is both an audit requirement and the data you need to safely widen the straight-through band over time.
3. Human review as a first-class node, not an escape hatch
Utilization-management review is not an exception to the workflow; it is part of it. That means a real review queue with role-based access (nurse vs. physician reviewer, level, grade), optimistic locking so two reviewers don't collide, comments, and a state machine of its own: open → submitted → approved / denied / request-more-info (rework). When the reviewer acts, that decision has to flow back into the paused workflow and resume it — approve continues, deny routes to the denial path with its reason, and "rework" loops back to documentation. The human step is a resumable node inside the automated pipeline, fully audited, never a dead end.
4. Event sourcing — the audit trail you get for free
Every state transition in the workflow should be written as an event before it is acted on. Two things fall out of this. First, crash recovery is deterministic: if a service dies mid-authorization, the workflow is reconstructed by replaying its event log and picks up exactly where it left off — no orphaned or duplicated authorizations. Second, the compliance reporting CMS-0057 now demands — specific denial reasons, turnaround metrics, an immutable record of who decided what and when — is a query over that event log rather than a bolt-on. Store the log encrypted, and your HIPAA audit controls are satisfied by construction.
5. Idempotency, retries, and circuit breakers — because payer endpoints are flaky
Clearinghouses and payer gateways go down, time out, and return duplicates. A prior-auth engine that submits twice because a response was slow is a clinical and financial hazard. Three primitives are non-negotiable: idempotency keys so a retried submission is recognized and never creates a second authorization; durable retries with a dead-letter queue so a transient payer outage self-heals instead of dropping requests on the floor, with a distributed lock ensuring only one instance re-drives a message; and circuit breakers so one slow payer integration cannot exhaust threads and take down the whole engine.
6. The anti-corruption layer — one payer's "278" is not another's
The FHIR PAS specification standardizes the envelope, but payer rules, code sets, and X12 278 variants differ in maddening detail — and CMS granted enforcement discretion so payers can accept FHIR without the 278 in some cases and not others. You do not want that variation leaking into your core engine. A translation / anti-corruption layer maps each payer's dialect and each inbound event schema into one canonical internal model, so the orchestrator and capabilities only ever see clean, normalized data. This is the same discipline that keeps HL7 v2, X12, and FHIR interfaces from turning a codebase into a swamp.
7. PHI security as a platform property, not a checklist
Prior authorization moves clinical detail, member identifiers, and diagnoses. The right place to enforce protection is the platform, not each feature: field-level encryption of PHI at rest (annotate the field, the platform encrypts on write and decrypts on read), encryption in transit for every payer hop, and an encrypted, append-only audit journal. When compliance is inherited from platform libraries, every new capability is HIPAA-aligned on day one instead of being retrofitted before an audit.
How this maps to CMS-0057 and the Da Vinci guides
None of the above is theoretical against the regulation — it is exactly what the standards assume. The Prior Authorization API in CMS-0057-F is meant to be built on the HL7 Da Vinci Burden Reduction guides, which are themselves a workflow: CRD (Coverage Requirements Discovery) at order time, DTR (Documentation Templates and Rules) to gather what's needed, and PAS (Prior Authorization Support) to submit — with PAS still wrapping X12 278 for transport where required. All of it sits on FHIR R4, US Core, and SMART on FHIR.
The rule's operational teeth — 72-hour urgent and 7-day standard turnaround, specific denial reasons, public metrics — are precisely the parts that a stateful, event-sourced workflow makes tractable and a stateless API façade makes painful. If you build the API without the engine, you will be compliant on paper in 2027 and still drowning in pended requests.
Build vs. buy, honestly
The FHIR façade is a reasonable thing to buy or generate — it is a well-specified, commoditizing layer. The resumable, auditable, decisioning workflow behind it is not, and it is where both the compliance and the actual burden reduction live. Our view, from having built exactly this class of system: buy or generate the standards adapters, and invest your best engineering in the orchestration engine, the capability boundaries, and the reliability primitives. That is the part that will still be yours — and still be working — when the next rule lands.
See it in code — this engine is open source
We didn't only write about this architecture; we built it and open-sourced a runnable reference implementation. It is a small, event-sourced workflow engine (Kotlin) that embodies everything above — the orchestrator-plus-capabilities model, asynchronous holds, human-in-the-loop review, deterministic resume, a parallel fork–join intake, editable jumps and checkpoints, an auto-generated flow diagram, and a live operator console that shows an authorization moving through the process in real time. Read the code, run the offline demo, or build on it: github.com/Nirmitee-tech/fhir-prior-auth-engine.
Where we come in
We build FHIR-native, standards-first healthcare platforms — and, underneath them, the kind of resumable, event-sourced, human-in-the-loop workflow engines that regulated decisioning actually requires. If you are staring down the 2027 deadline and want a prior-auth system that reduces burden instead of relocating it, let's talk.