Automating Prior Authorization: What We Cut by 75%

Prior authorization looks like a data problem and behaves like a queue problem. The clinical decision takes a physician ninety seconds. The authorization takes a staff member two days, most of which is spent on hold, re-typing information that already exists in the chart, and refreshing a portal to find out whether anything happened.

Zee Palm built Previa, a prior-authorization automation product that cut processing time by 75% working against payer APIs including Humana and UnitedHealthcare. This page explains where that 75% actually came from, because the interesting part is that almost none of it was clever algorithms — and the parts we could not automate are the parts most vendors in this category are quietest about.

Where the time actually goes

Break a single authorization into its real stages and the distribution is not what people assume.

Four of those seven stages are pure information logistics. One is a queue. Only two need clinical judgment. That ratio is the entire opportunity, and it is why the automation win is large and also bounded — you cannot automate below the floor set by the two clinical stages.

The four places the 75% came from

1. Eliminating re-keying. The single largest line. Every field a human types into a payer portal that already exists in the EHR is waste with a typo rate attached. Pulling demographics, coverage, diagnosis codes, procedure codes, ordering provider and supporting observations directly from the source and assembling the submission removes both the minutes and the rework caused by transposition errors. Rework is the hidden half: a rejected submission for a wrong member ID costs the whole cycle again.

2. Determining the requirement programmatically instead of by phone. "Does this need auth?" is a question that historically got answered by calling. When a payer exposes coverage requirements programmatically, the answer arrives in the workflow before the order is placed, which also prevents the worst outcome in the whole process — a service delivered without an authorization that should have had one.

3. Assembling documentation from templates rather than from memory. Payer policies specify what evidence supports a determination. Turning those into structured prompts, pre-populated from the chart, converts a "gather everything and hope" exercise into a checklist that either completes or tells you exactly what is missing before submission.

4. Replacing polling humans with polling software. Status checking is machine work. Humans should be interrupted by a state change, not employed to look for one. Building the queue so a case surfaces when it needs a human — and is invisible when it does not — is unglamorous and is a very large share of the measured saving.

Notice what is absent from that list: no model predicting approvals, no large-language-model writing medical necessity letters, no claim that we made a payer decide faster. The 75% is operational time inside the provider's four walls. Anyone promising to compress the payer's own determination clock should be asked, precisely, how.

The standards you build against

If you are building in this space in 2026, three acronyms define your architecture.

X12 278 is the long-standing EDI transaction pair for a health care services review request and response. It is the transaction most payer and clearinghouse infrastructure already speaks, and for many payers it remains the substrate underneath anything more modern.

The HL7 Da Vinci implementation guides are the FHIR-native layer:

• CRD (Coverage Requirements Discovery) — CDS Hooks fired from the ordering workflow that tell the clinician, at the moment of ordering, whether authorization is required and what the payer expects.
• DTR (Documentation Templates and Rules) — payer-supplied questionnaires and logic that pre-populate from the patient's record, so the documentation gathering is structured rather than freeform.
• PAS (Prior Authorization Support) — the FHIR interface for submitting the request and receiving the response, mapped onto the X12 278 transaction underneath.

Together those three cover exactly the four stages above: is it required, what do you need, here it is, what happened. If a vendor tells you they have "AI-powered prior auth" and cannot tell you which of CRD, DTR and PAS they implement, you are looking at a screen-scraper with a chat interface.

The regulatory driver is CMS's interoperability and prior authorization rulemaking, which obliges impacted payers to stand up FHIR-based prior authorization and related APIs, to communicate specific denial reasons, to meet decision timeframes, and to publish metrics.

Write the structural sentence in your deck — federal rulemaking is pushing payers toward standardized FHIR prior authorization APIs on a defined compliance timeline — and check the current CMS materials for the dates and specifics before you put them in front of a customer. Getting a compliance date wrong in a sales conversation with a payer is worse than not mentioning it.

What we could not automate, and would not

This is the section the category avoids.

Payers without an API. Coverage is uneven. Some payers, some lines of business and some plan types will still be a portal, a fax number, or a phone tree for the foreseeable future. A production system needs a graceful degradation path — the same case object, the same audit trail, the same queue, with a human executing the last mile. Products that only handle the API-enabled payers look excellent in a demo and leave the staff running two systems in real life.

The clinical narrative. Medical necessity argumentation, especially on appeal, is a physician's work product. You can assemble the evidence, surface the payer's stated criteria, and remove every minute of retrieval — you should not generate the clinical assertion. We build the human-in-the-loop boundary explicitly: nothing that constitutes a clinical attestation leaves the system without a named clinician approving it, and the audit trail records who approved what, when, on what basis.

Peer-to-peer review. A scheduled conversation between two physicians. Software's contribution is getting the right case in front of the right person with the right documents at the right time, and then getting out of the way.

Judgment about what to appeal. Denial data can tell you which denials are commonly overturned in your own history. Deciding to spend clinician time on this patient's appeal is not a throughput optimization.

Being clear about these four is not modesty. It is the difference between a system clinical staff adopt and a system they route around, and routing around is what happens when software claims authority it has not earned.

What to build, in order

If you are scoping a prior authorization product or an internal automation, the sequence that survives contact with reality looks like this.

1. Instrument before you automate. You cannot claim a 75% reduction without a defensible baseline. Measure current touch time, cycle time, rework rate and first-pass approval rate per payer, per service line, before you write a line of code. Half the value of the first phase is discovering that 60% of your volume is three payers and two procedures.
2. Build the case object and the audit trail first. Every state change, every submission artifact, every human decision, immutable and attributable. This is what makes the system defensible, and it is architecture, not a feature you add later. It is the same discipline behind every HIPAA-aware system we build.
3. Automate the requirement determination. Highest leverage, lowest clinical risk, and it prevents unauthorized services rather than merely processing them faster.
4. Automate packet assembly with structured documentation. Pre-populate; do not generate. Show the clinician what is being submitted on their behalf.
5. Automate status tracking. Then delete the spreadsheet.
6. Add the manual fallback lane for non-API payers, in the same queue, with the same audit trail.
7. Only then look at prediction. Once you have clean historical outcome data of your own, likelihood-of-approval scoring becomes a real prioritization tool. Before that, it is a guess wearing a lab coat.

The other honest recommendation: if you process fewer than a couple of hundred authorizations a month, do not build this. Buy a clearinghouse or an established service, and spend the money on whatever is actually constraining your clinic. Custom prior authorization automation pays back on volume and on organizational specificity — a mix of payers and service lines that a general-purpose tool models badly. Below that threshold you are funding a build to save a fraction of one person's week.

What it costs to build

Our prices are published and the planning is deliberately cheap because it is where the wrong scope gets caught.

The compliance boundary, stated plainly because it matters here more than anywhere: Zee Palm builds HIPAA-aware, compliance-conscious systems and maps sensitive-data and clinical boundaries during planning. We do not issue certifications, we do not provide legal sign-off, and we do not determine your obligations under any payer contract or federal rule. Our security posture and BAA position are on the trust page.

Previa is one of the engagements we will walk you through in detail on a call, alongside the State of New Hampshire immunization platform we built over HL7 with 50+ schools live. Both are on the case studies page, and both are the reason we can talk about clinical and telehealth builds from experience rather than from a whitepaper. If you have a prior authorization workflow that is eating a team, tell us what your volume and payer mix look like and we will tell you whether it is worth building.

Frequently asked questions

How much time can prior authorization automation actually save?

Zee Palm's Previa cut processing time by 75% against payer APIs including Humana and UnitedHealthcare. The saving is concentrated in four places — eliminating re-keying, determining requirements programmatically, assembling documentation from templates and replacing human status polling. It does not compress the payer's own determination time, and any vendor claiming otherwise should be asked exactly how.

What is the difference between X12 278 and Da Vinci PAS?

X12 278 is the established EDI transaction pair for authorization requests and responses. Da Vinci PAS is the FHIR interface for the same exchange, mapped onto 278 underneath, and it sits alongside CRD for discovering whether authorization is required and DTR for gathering the documentation. In practice a modern build speaks FHIR to the clinician-facing side and tolerates 278 wherever the payer infrastructure requires it.

Do all payers support electronic prior authorization APIs?

No. Coverage is uneven across payers, lines of business and plan types, and federal rulemaking is changing that on a defined timeline — check the current CMS materials for scope and dates. Any production system needs a manual fallback lane for non-API payers that uses the same case object, queue and audit trail, or your staff will end up running two systems.

Should we automate prior authorization or outsource it?

Below roughly a couple of hundred authorizations a month, outsource or use a clearinghouse. Custom automation pays back on volume and on organizational specificity — an unusual payer and service-line mix that general-purpose tools handle badly. Instrument your current process first: cycle time, touch time, rework rate and first-pass approval by payer will tell you within a week which category you are in.

Can AI write the medical necessity documentation?

It should not write the clinical assertion. Software can assemble evidence, surface the payer's stated criteria and remove every minute of retrieval, but the attestation is a clinician's work product and must leave the system under a named clinician's approval with an audit trail. Systems that blur that boundary get routed around by the clinical staff who are supposed to use them.

How long does it take to build a prior authorization automation MVP?

A bounded version one — one service line, the two or three payers that carry most of your volume, requirement determination plus packet assembly plus status tracking — is a matter of weeks after a planning sprint, and starts at $12,000. A full multi-payer platform with fallback lanes, analytics and appeal workflow is a larger engagement from $25,000 and should be sequenced, not attempted in one release.