Prior authorization automation

The form is not the work

When people say they want to automate prior authorization, they usually picture the form. Someone in the office is typing patient demographics, a procedure code and a diagnosis into a plan portal, and it is obviously mechanical, so it obviously ought to be automated. That part is real, and it is also the smallest part of the job. The expensive part is deciding whether authorization is required at all, finding out what evidence this particular plan wants for this particular code, pulling that evidence out of the chart, and then waiting — often several days — for a human being at the plan to read it. Automating the typing while leaving the other four steps alone produces a system that is faster at the cheap part of a slow process.

Break it into the five things that actually happen and the picture gets clearer immediately.

One: does this need authorization? A decision that depends on the plan, the specific product within the plan, the code, sometimes the place of service, and sometimes the patient's history. Getting it wrong in one direction wastes a submission; getting it wrong in the other direction produces a denial after the service is delivered, which is worse.

Two: what does this plan want to see? The rules exist. They are published somewhere — a policy PDF, a portal page, a medical policy library, occasionally a machine-readable feed. They differ by plan and they change without telling you.

Three: assemble the evidence. Prior conservative therapy, imaging results, dates, failed alternatives, a note that says the words the policy requires. This lives in the chart, in scanned outside records, in a fax from a referring office, and in a physician's head.

Four: submit it. Portal, fax, phone, or an electronic transaction. This is the typing.

Five: track it to a decision. Pended, needs more information, peer-to-peer review requested, approved with a different code than you asked for, approved for a shorter duration than you asked for. Then somebody has to notice and act.

Which stages automate, and which only look like they do

Automation potential is not uniform across the five stages. It tracks one property: whether the correct output is determined by data you can obtain, or by a judgment somebody has to make.

Stage	What it actually is	How far software gets
Is authorization required	A lookup against plan rules that change and are published inconsistently	Far, if you maintain the rule data. The engineering is easy; the data curation is the whole job
What evidence is needed	Reading a medical policy and turning it into a checklist	Partly. Language models are genuinely good at turning policy prose into structured criteria, with a human confirming each one before it goes live
Assembling evidence	Finding facts scattered across structured fields, notes, scans and faxes	Partly, and this is where the real value is. Retrieval and extraction find the candidate evidence; a person still decides it is sufficient
Submitting	Data entry into a portal, a fax, or a standards-based transaction	Nearly all of it, where an interface exists. Where it does not, browser automation works and breaks whenever the portal changes
Tracking to decision	Polling, reading responses, routing exceptions to the right person	Nearly all of it, and this is the cheapest win in the list

Notice which two are marked nearly all. Submission and tracking are mechanical, they have well-defined success conditions, and they are boring enough that people do them badly. The middle three are where the clinical judgment lives, and a system that pretends otherwise will be turned off within a quarter by the first nurse who catches it asserting something the chart does not support.

What the electronic standards actually cover

There is a HIPAA-adopted transaction for this. The X12 278 health care services review carries the request and the response, and its companion transactions carry attachments. It has existed for a long time and adoption has been uneven, for a reason worth understanding: the 278 is very good at carrying a structured request and a structured answer, and much less good at carrying the clinical narrative that the answer actually depends on. A plan that needs to read three progress notes before deciding cannot get what it needs from the request alone, so the transaction ends in a pend and the work moves back to fax and portal.

The newer work attacks exactly that gap. The HL7 Da Vinci project publishes a set of implementation guides for the pieces: Coverage Requirements Discovery answers “is this authorized, and what is needed,” usually triggered from inside the ordering workflow; Documentation Templates and Rules delivers the questionnaire the plan wants and prefills what the record already knows; Prior Authorization Support wraps the submission itself and maps onto the underlying X12 transaction. Written down that way it is a clean design: ask at order time, fill from the chart, submit, get an answer.

Regulation is pushing on this too. The Centers for Medicare & Medicaid Services finalized a rule that requires certain payers — Medicare Advantage organizations, state Medicaid and CHIP programs and their managed care plans, and issuers of qualified health plans on the federally facilitated exchanges — to shorten decision timeframes, to state a specific reason when they deny, to publicly report authorization metrics, and to stand up FHIR-based interfaces including one for prior authorization. The compliance dates are staged across more than one year and the API obligations land later than the timeframe obligations.

Three things about that rule matter more to your planning than the details. First, it does not cover every plan you bill. Commercial group business and self-funded employer plans are largely outside it, and for many provider organizations that is the majority of the payer mix. Second, drugs are handled differently from medical items and services, so a pharmacy authorization workflow is a separate project with a separate standard. Third, an API existing is not the same as an API being useful — the first releases of a new payer interface tend to be thin, and you will discover which ones return real content only by connecting to them. Read the rule text and your own plan contracts rather than a summary, including this one, before you build a roadmap on it.

Where the time actually goes, and why that reorders the project

Instrument an authorization before you automate it. Take a few hundred recent cases and record five timestamps: order placed, authorization work started, first submission, last plan response, final determination. Then look at the gaps.

In most organizations that do this, the distribution is lopsided in a way that surprises the people who commissioned the study. A meaningful share of total elapsed time sits between order placed and work started — a queue problem, not a technology problem. Another large share sits between submission and response, which is the plan's clock and outside your control. The actual keystrokes, the thing the portal robot addresses, are usually a small fraction of elapsed time even when they are a large fraction of staff time.

That distinction — elapsed time versus staff time — decides what you should buy. If your problem is that patients wait, the levers are queue design, earlier initiation at the point of ordering, and getting submissions right the first time so they do not pend. If your problem is that authorization staffing is expensive, then yes, the keystrokes matter, and so does the tracking work that nobody counts because it happens in five-minute pieces all day.

Where a language model helps, and where it is the wrong tool

Three uses hold up in production.

Turning policy prose into structured criteria. A medical policy is a document written for a human reader, full of conditionals. Converting it into a set of checkable criteria is exactly the kind of reading task current models do well, and the output is reviewed once by a person and then reused thousands of times. The economics are excellent because the review cost amortizes.

Finding candidate evidence in the record. Given a criterion — six weeks of documented conservative therapy, say — searching the chart for passages that might satisfy it, and returning them with a citation to the source note and date. Note the framing: candidate evidence, with a pointer. The system's job is to save the twenty minutes of hunting, not to conclude.

Drafting the narrative. Assembling the found evidence into the letter, in the plan's preferred structure, with every assertion traceable to a note the reviewer can open.

Two uses do not hold up. The first is deciding medical necessity, which is not your decision to make and is a liability you should not accept. The second is generating clinical content that is not in the record. A model asked to write a persuasive justification will write one, and it will sound correct, and some fraction of the time it will assert a therapy trial that never happened. That is a documentation integrity problem with consequences well beyond a denied authorization. The design rule that prevents it is simple and should be non-negotiable: every clinical claim in a submitted packet points at a specific source document, and the interface shows the reviewer that source before they approve the send.

The portal automation question

Most plans still expect a portal, so most vendors demonstrate a robot driving one. It works. It is also the most brittle thing you will own, and the failure modes are ugly — a layout change silently drops a field, and you find out three weeks later from a batch of denials.

If you go that way, three conditions make it survivable. Every session must be recorded well enough to reconstruct what was submitted, because “the robot said it succeeded” is not evidence. There must be a per-payer canary that runs a known case daily and alerts on any change in the response shape. And there must be an explicit account-hygiene review with each plan, because credential sharing and automated access sit inside terms of use that vary by payer and are worth reading before you scale.

Where a plan offers a real interface, take it, even if it covers fewer service lines than the portal. A narrow interface that is stable beats a broad one that is not.

Measure these five things, before and after

Almost every disappointing automation project in this area shares a cause: nobody wrote down the baseline, so nobody could tell what changed. Five numbers are enough.

First-pass approval rate, by payer and by service line. The single most useful number in the whole workflow, because everything else is downstream of a submission that had to be redone.

Pend rate and the reason for the pend. Group them. A handful of causes usually explains most of the volume, and they are frequently things like a missing date or the wrong ordering-provider identifier rather than anything clinical.

Touches per authorization. Count human interactions, not minutes. It is easier to collect honestly and it correlates with cost better than self-reported time.

Elapsed time, split at the submission boundary. Your clock and their clock, separately. Combining them hides which half you can actually influence.

Authorization-related denials at the claim stage, which is the failure the whole process exists to prevent, and which shows up weeks later against a different department's numbers. If this does not go down, nothing else you measured mattered.

Mistakes we see

• Automating submission while requirement lookup stays manual — faster typing of the wrong packet
• Treating a pend as a failure of the plan rather than reading the pend reasons, which are usually specific and fixable
• No baseline, so the before-and-after conversation becomes a matter of opinion
• Model-generated clinical assertions with no source citation in a packet somebody signs
• Portal robots with no canary and no session record, discovered broken by the denial batch
• Building for one payer's interface and finding the abstraction was wrong on the second
• Ignoring the queue between order and work start, which is often the largest single block of elapsed time
• Counting staff minutes saved while patient wait time is unchanged, and reporting it as the same thing

When you do not need a vendor for this

Some organizations should not buy anything here, and it is worth saying plainly.

If your volume is concentrated in two or three plans that both offer working electronic interfaces, the work is two integrations, a queue, and a status dashboard. That is a few months of ordinary engineering by a team you may already have, and it will outperform a general-purpose product because it is shaped like your actual payer mix.

If your authorization volume is genuinely small — a specialty practice with a narrow procedure set — the highest-return move is usually a good checklist per procedure per payer, maintained by the person who already knows the answers, plus a tracking board so nothing sits. Software will not beat that for a long time, and it costs nothing.

And if your data is disorganized enough that nobody can produce the five baseline measurements above, fix that first. Every automation project on top of unmeasured work becomes an argument about whether it helped.

What a serious build looks like

• A rule store for authorization requirements, versioned, with a date and a source for every entry
• Criteria extracted from policy documents, reviewed once by a clinician, then reused
• Evidence retrieval that returns citations, never conclusions
• A human confirmation step before anything clinical is transmitted
• Standards-based submission where available, portal automation only as fallback
• Per-payer canaries that detect an interface or portal change within a day
• Full request and response capture, retained, reconstructable months later
• Pend and denial reasons coded and trended, not just counted
• The five baseline measurements, taken before the first line of code
• An owner for rule maintenance, because plan rules change and stale rules are worse than none

Bottom line

Prior authorization is a data problem wearing a workflow costume. The typing is visible and cheap; the requirement knowledge and the evidence assembly are invisible and expensive; the waiting belongs to somebody else. Automate tracking and submission first because they are safe and they pay immediately. Invest the real engineering in requirement data and evidence retrieval with citations, and keep the clinical judgment where it belongs. Then check the number that actually matters, which is authorization-related denials on claims weeks later — if that did not move, the project was about staff comfort rather than outcomes, and it is worth knowing that before the second phase is funded.

Frequently asked questions