Prior Authorisation: Where the Days Actually Go

Prior authorisation sits at the intersection of clinical workflow, payer policy, and legacy integration. Most engineers who touch it once come away surprised by how much calendar time a single approval can consume — and how little of that time is actual decision-making.

What Actually Happens During a Prior Auth Request

A physician's office submits a PA request. The payer's system receives it. Somewhere between 24 hours and 14 business days later, an answer arrives. That window is not filled with careful clinical review. Most of it is waiting: waiting for the request to land in the right queue, waiting for supporting documents to be attached, waiting for a reviewer to pick it up, waiting for a peer-to-peer call to be scheduled if the first decision is a denial.

The American Medical Association's 2023 survey found that physicians complete an average of 43 prior authorisations per physician per week, and 94% of physicians reported that PA delays patient care. The average turnaround for non-urgent requests sits between 2 and 3 business days under manual workflows. Urgent requests nominally get 24-hour turnaround, but that clock starts only after the payer acknowledges receipt, which itself can take hours.

The actual clinical decision — the moment a reviewer reads the clinical notes and applies the payer's criteria — takes minutes. The rest is queue management.

Where the Time Actually Goes

Breaking the timeline down honestly:

Stage	Typical Duration	Why It Stalls
Provider submits request	0–4 hours	Incomplete forms, portal login friction
Payer acknowledges receipt	0–8 hours	Fax-to-queue conversion, batch processing
Request enters clinical queue	4–24 hours	Queue prioritisation, workload
Initial clinical review	5–15 minutes	Criteria matching, policy lookup
Additional info requested	1–5 business days	Back-and-forth with provider
Peer-to-peer scheduling (if needed)	1–3 business days	Physician availability on both sides
Final decision communicated	0–4 hours	Fax, portal update, phone call

The actual clinical decision time in a straight-through approval is under 20 minutes. Everything else is handoff latency.

The peer-to-peer step deserves its own mention. It exists because payers allow physicians to speak directly with the reviewing clinician when a denial is issued. In practice, scheduling that call often takes longer than the original review. Both sides need to find overlapping availability. The call itself typically runs 10 to 15 minutes. But the scheduling lag can add 48 to 72 hours to the total cycle.

Why Can't Systems Just Automate This?

The honest answer is that some of it can be automated, and some of it genuinely cannot.

What Automation Handles Well

Rule-based criteria matching is straightforward. Payers publish clinical criteria in documents like MCG (Milliman Care Guidelines) or InterQual. If a request includes a valid ICD-10 code, a matching CPT code, and clinical notes that meet the step-therapy or diagnosis criteria, an algorithm can approve it without human review. This is called "auto-adjudication," and payers have been doing it for years for pharmacy benefits. Medical benefit PA has lagged behind because the clinical data required is messier — free-text notes, scanned documents, inconsistent EHR outputs.

FHIR R4 and the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F, effective 2026 for most provisions) mandate that payers expose PA decision APIs. The HL7 Da Vinci project has published implementation guides for Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR), and Prior Authorization Support (PAS). When these are implemented correctly, a provider's EHR can query the payer in real time during the prescribing workflow, get the PA requirements surfaced inline, and submit the request with structured clinical data — no portal, no fax.

In that ideal path, turnaround can drop to under an hour for cases that meet criteria.

Where Automation Breaks Down

The hard cases are hard for a reason. A request for an off-label biologic for a rare autoimmune condition may have no published criteria. The reviewer has to exercise clinical judgement against a sparse evidence base. No current production system handles that well without a human in the loop.

There is also the problem of criteria interpretation. Payer policies are written in natural language. "Failure of two prior therapies" sounds unambiguous until you ask whether a drug taken for three weeks before being stopped due to side effects counts as a failure. These edge cases generate most of the peer-to-peer calls.

What Does a Modern PA System Look Like Technically?

A well-engineered PA system today has a few distinct layers.

The intake layer handles structured submission. It translates EHR output (CDA documents, FHIR resources, or HL7 v2 messages) into a normalised internal representation. If the payer has implemented the Da Vinci PAS guide, this is a FHIR transaction. If not, you are still dealing with X12 278 EDI transactions or, in the worst cases, screen-scraping a web portal.

The decision layer applies criteria. For auto-adjudicable cases, this is rule execution against a criteria library. For borderline cases, it routes to a clinical review queue. The split between auto-adjudicated and manually reviewed cases varies by payer and service type; for radiology, some payers report auto-adjudication rates above 70%. For complex surgical procedures, manual review remains dominant.

The communication layer handles the back-and-forth. Requesting additional information, sending denial notices, scheduling peer-to-peer calls. This is where most of the calendar time accumulates, and where asynchronous messaging (as opposed to synchronous API calls) becomes the right model. A request that needs more information will sit in a pending state for days. The system needs to track that state reliably and send reminders without spamming either side.

Audit and logging sit underneath all of this. CMS regulations require payers to report PA metrics — approval rates, average decision times, denial reasons — starting in 2026. That means every decision needs a structured record that can be queried for reporting.

Is Real-Time PA Actually Possible?

For a narrow category of requests, yes. Pharmacy PA has had real-time decision capability for over a decade via NCPDP SCRIPT and the Surescripts network. The medical benefit side is getting there. The Da Vinci PAS workflow, when implemented against a payer that has built the server side, can return a decision synchronously in seconds for cases that hit the auto-approval path.

The realistic picture for 2025: a well-integrated provider will get immediate decisions on maybe 30 to 50 percent of requests. The remainder will go into an asynchronous workflow. Real-time does not mean universal; it means the happy path is fast and the exception handling is explicit rather than a black hole.

Conclusion

Most of the time lost in prior authorisation is not review time. It is queue time, handoff time, and the scheduling overhead of exception workflows. Fixing that requires two things in parallel: structured data at submission time (so criteria can be matched programmatically) and explicit state management for requests that need human review (so they do not disappear into a fax queue).

If you are building or evaluating a PA system, the first question to ask is not "can we automate the decision?" It is "can we see exactly where every open request is right now?" Visibility comes before automation. Without it, you cannot measure what you are trying to fix.

---

FAQ

What is the average time for a prior authorisation decision? Under manual workflows, non-urgent prior authorisations average 2 to 3 business days from submission to decision. Urgent requests are nominally 24 hours, but that clock typically starts after payer acknowledgement, not submission. Well-integrated electronic workflows can cut this to hours for auto-adjudicable cases.

What is the Da Vinci PAS implementation guide? PAS (Prior Authorization Support) is an HL7 FHIR implementation guide produced by the Da Vinci project. It defines how a provider's EHR can submit a PA request as a FHIR bundle to a payer's endpoint and receive a synchronous or asynchronous decision. It builds on X12 278 semantics but wraps them in FHIR R4 resources.

Why do so many PA requests require additional information? Payer clinical criteria are written against specific documentation requirements — progress notes, lab values, prior treatment records. When a provider submits without that documentation attached, the payer issues an additional information request rather than denying outright. Structured EHR data and DTR (Documentation Templates and Rules) workflows reduce this by surfacing requirements at the point of ordering.

What is a peer-to-peer review in prior authorisation? A peer-to-peer is a call between the requesting physician and the payer's reviewing clinician, typically requested after an initial denial. The requesting physician argues the clinical case directly. Approval rates after peer-to-peer vary widely by specialty and payer, but the process reliably adds 1 to 3 business days of scheduling latency to the cycle.

Will CMS-0057-F actually change how prior auth works? The rule requires most payers (Medicare Advantage, Medicaid managed care, exchange plans) to implement FHIR-based PA APIs and to report decision-time metrics publicly starting in 2026. It sets a 72-hour decision requirement for urgent requests and 7 calendar days for standard requests. Enforcement and payer readiness will determine real-world impact, but the technical mandate is concrete and the deadlines are firm.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.