Prior Authorization Automation with AI Agents

The 2024 CAQH Index measures the cost of each standard administrative transaction on both the plan and provider side. Prior authorization is the most expensive one providers perform, and the gap between manual and electronic is wider than for any other transaction.

Mode	Provider cost per transaction	Provider saving if fully electronic	Reported staff time
Manual (phone, mail, fax, email)	$12.88	$7.50	24 minutes
Partial (web portal, IVR)	$8.93	$3.55	16 minutes
Fully electronic (X12 278)	$5.38	Baseline	Not separately reported

Source: 2024 CAQH Index, medical industry. The same report puts the average time saving available to medical providers at 14 minutes per prior authorization transaction, and the total medical industry savings opportunity for this one transaction at 515 million US dollars a year.

Two things follow. First, the biggest single lever is not artificial intelligence, it is getting off the phone: manual to portal saves more per transaction than portal to fully electronic. Second, only 35 percent of medical prior authorizations were conducted fully electronically in the 2024 Index, up four percentage points on the prior year, so most practices still have that first lever available.

On the clinician side, the 2025 AMA Prior Authorization Physician Survey reports that physicians and their staff spend around 13 hours a week on prior authorization, that physicians handle roughly 40 requests a week, and that around 40 percent of practices employ staff who work on prior authorization exclusively. If you want to model your own numbers rather than borrow ours, the prior authorization cost calculator takes your volume and staff cost and shows the range.

The Interoperability and Prior Authorization Final Rule, CMS-0057-F, was published in the Federal Register on 8 February 2024 and became effective on 8 April 2024. Its obligations fall on payers, not on you, which is precisely why it matters to your build versus buy decision: the plumbing you would have to build today is being mandated into existence around you.

Date	What changes	Codified at
1 January 2026	Standard prior authorization decisions for items subject to the rule must be issued within 7 calendar days. Expedited decisions remain at 72 hours.	42 CFR 422.568(b)(1)(ii)
1 January 2026	A denial response to the provider must include a specific reason for the denial, whatever channel it arrives on.	42 CFR 422.122(a)
From 2026, by 31 March each year	Impacted payers publish prior authorization metrics for the previous calendar year, including approval, denial and overturn-on-appeal percentages and average and median decision times.	42 CFR 422.122(c)
1 January 2027	Impacted payers implement a FHIR based Prior Authorization API that lists items requiring authorization, identifies required documentation, and returns approval, denial or a request for more information.	42 CFR 422.122(b)

The rule reaches Medicare Advantage organizations, state Medicaid and CHIP fee for service programs, Medicaid and CHIP managed care entities, and Qualified Health Plan issuers on the federally facilitated exchanges. It does not reach commercial employer sponsored plans, so a practice with a mostly commercial payer mix will feel less of this than a practice with a heavy Medicare Advantage book. Work out your own mix before you assume the tailwind applies to you.

The public reporting requirement is the underrated one. From 2026 you can read a payer's own published approval, denial and appeal overturn rates and use them in contract negotiation, in referral routing and in deciding which payers deserve an agent pointed at them first. The full timeline, applicability and what to do in each quarter is on the CMS prior authorization rule page.

Rank the four jobs by how much time they consume and how tolerant they are of a machine getting it wrong, and the sequencing writes itself.

• Status checking is the safest and dullest win. Nobody's care is harmed by a bot politely asking a portal whether a request has moved. It is pure hold time removal, it needs no clinical judgement, and it is where voice agents such as those built for payer calls have the clearest case.
• Documentation assembly is the largest win. It is also the one that needs review, because an agent that attaches the wrong imaging report has created a clinical error, not an administrative one. Assemble automatically, submit after a human glance, at least until your error log says otherwise.
• Determination is high leverage and high maintenance. Getting the rules right prevents work rather than accelerating it. Getting them stale creates denials. Whoever owns this needs a process for keeping payer policy current, and that is a staffing decision as much as a software one.
• Appeal drafting has the best return per hour and the tightest guardrails. A denial overturned is revenue recovered. In its analysis of Medicare Advantage data, KFF reported that a small minority of denials are appealed at all, and that the large majority of those appeals succeed. That gap is the opportunity, and it is why appeal drafting belongs in the same programme as denial management rather than in a separate project.

If your practice is also drowning in eligibility checks and registration, sequence patient intake first: it is cheaper, lower risk, and it cleans the insurance data that prior authorization depends on.

There are two integrations in every prior authorization project and they fail in different ways.

The EHR side. The agent needs to read the chart and write the authorization number back onto the order or the encounter, otherwise your staff still open the EHR to close the loop and the saving evaporates. In practice this is a FHIR read plus a write path that your EHR vendor has to sanction. Timelines are governed by your vendor's app review and your own security review, not by the agent vendor's sales cycle. The specifics for the largest system are on the Epic integration page, and the same three questions apply everywhere: what can be read, what can be written, and who signs off.

The payer side. Today this is a mixture of clearinghouse connections, the X12 278 transaction, portal automation and the telephone. From January 2027 impacted payers must expose a FHIR Prior Authorization API, which will make a portion of this clean. Until then, portal automation is doing real work and is genuinely brittle: a payer redesigns a page and your automation stops. Ask any vendor how many payer connections they maintain, how quickly they repair a broken one, and whether that repair is included or billed.

A practical test for a demo: ask the vendor to show a request going out and the authorization number arriving back in the EHR without a human touching a keyboard between the two. Many products can do the first half convincingly. Fewer can do the second.

The temptation to build is strong, because the individual steps look simple and because language models make documentation assembly feel like a weekend project. The steps are simple. The maintenance is not.

Consideration	Build	Buy
Payer connections	You maintain each portal integration and every rule change, forever	Amortised across the vendor's customer base
Time to first value	Months, and the first month is spent on credentials and access	Weeks for a narrow scope, if the EHR path already exists
Fit to your specialty	Exact, because you wrote it	Variable, and worth testing on your five highest volume procedures
Regulatory change	You track CMS-0057-F and implement the FHIR API client yourself	Vendor roadmap risk, so ask for their 2027 API plan in writing
Where building genuinely wins	A single high volume, single payer, single procedure workflow that your team already understands end to end	Anything spanning multiple payers

Our honest position: build the determination rules if you are a single specialty group with a concentrated payer mix, because you know your own rules better than any vendor does. Buy the connectivity. Nobody has ever won a strategic advantage by maintaining a portal scraper.

If the decision is genuinely open, it is worth an hour of structured comparison rather than a procurement process. That is what our vendor selection engagement exists to shorten.

The category splits by who writes the cheque, and buyers routinely evaluate products that were never designed for them.

• Revenue cycle platforms. Broad automation across eligibility, authorization, claim status and denials, usually priced against transaction or claim volume, and usually already connected to your EHR. Strong if you want one throat to choke across the whole cycle.
• Payer connectivity networks. The rails many practices already use for eligibility and claim status, sometimes with a free portal tier. Often the cheapest way to move from manual to partially electronic, which the CAQH figures above say is the single biggest cost step.
• Voice agents for outbound payer calls. Purpose built to sit on hold so your staff do not. Narrow, measurable and easy to pilot, usually priced per completed call.
• Payer side decisioning platforms. Sold to health plans. Providers meet them as the plan's intake and review path rather than as something they buy. Worth understanding, not worth evaluating as a purchase.
• Workflow automation suites. Configurable agents across intake, registration and referrals that can be pointed at authorization as one workflow among several.

We keep an evaluated shortlist, with pricing where it is published and an explicit note where it is not, on the best prior authorization software page. We take no vendor commissions, which is why some cells there say we could not verify a claim rather than repeating a marketing page.

Most prior authorization business cases are written in dollars saved and evaluated in vibes. Pick four numbers, measure them for a month before anything is installed, and hold the baseline.

Metric	Definition	Why it matters
Turnaround time	Median hours from order placed to authorization decision recorded	The only metric a patient experiences. Track median and the 90th percentile, because the tail is where care gets delayed.
Touch rate	Share of requests that a human opened at any point	The honest measure of automation. A product that submits automatically but needs a human to check status has not reduced touches.
Denial overturn rate	Share of appealed denials that are overturned	Tests whether appeal drafting is working, and tells you whether you are appealing too few.
Cost per authorization	Loaded staff cost plus software cost, divided by completed authorizations	Comparable to the CAQH benchmarks above, which is what makes it defensible to a board.

Two traps. Do not count avoided phone minutes as recovered salary unless someone's job actually changes, and do not compare a pilot month against a baseline month with different volume or a different payer mix. From 2026 you will also have payer published approval, denial and overturn statistics to benchmark against, which is a genuinely new capability.

Five failures, in rough order of how often we hear about them on a first call.

• The rules go stale. Payer policy changes and nobody owns updating it, so the agent starts requesting authorizations that are not required and missing ones that are. This is the most common quiet failure and it is a staffing gap, not a product defect.
• Portal automation breaks and nobody notices. Requests silently stop going out. Set an alert on submission volume per payer per day. If volume drops to zero on a Tuesday, you want to know on Tuesday.
• The write back was never built. The agent gets an approval and a human types the number into the EHR. Half the saving disappears and nobody put that in the business case.
• Documentation assembly is trusted too early. An agent that attaches the wrong report generates a denial that costs more to unwind than the request cost to file. Review assembled packets until your own error log justifies stopping.
• Nobody measured the baseline. Without a pre-pilot month of turnaround time and touch rate, the evaluation becomes an argument about whether things feel better. They usually do, for the first six weeks.

None of these are reasons to avoid the category. Prior authorization is the clearest commercial case for an agent anywhere in a medical practice, precisely because the work is repetitive, measurable and expensive. They are reasons to run it as a project with a named owner and a stopping rule.

A prior authorization agent reads the chart and transmits clinical detail to a third party, so it handles protected health information from the first minute. The compliance work belongs before the pilot.

• A signed business associate agreement with the vendor and with any subprocessor that touches the clinical documentation, including any model provider.
• A clear answer on whether your clinical text is used to train shared models, and whether you can decline.
• Minimum necessary discipline on documentation assembly. An agent that attaches an entire chart because it is easier than selecting the relevant notes is a disclosure problem, not just a sloppy one.
• Audit logging that records what the agent read, what it submitted and to whom, at the same standard you hold your staff to.
• If you operate in California, note that state law restricts how payers may use algorithms in utilization review. It constrains the other side of this transaction, and it is useful context when a denial arrives.

Each of these is worked through against the rule text on the HIPAA and AI compliance page, and the state layer is covered on the California AI healthcare laws page.

Pick one payer and one procedure family. Not one specialty, not one department. The narrowest scope that still produces enough weekly volume to see a trend, which in most practices is somewhere between thirty and eighty requests a week.

Weeks one to four: measure. Turnaround time, touch rate, denial rate and staff hours, by payer. Do not install anything. This month is the only chance you get to know what normal looked like, and every business case that skips it ends in an argument.

Weeks five to ten: run status checking and documentation assembly only, with human submission. This is the low risk half of the workflow and it will tell you whether the EHR read path works, whether the assembled packets are correct, and whether staff trust the output. Keep a log of every correction. That log is the artefact that decides whether you widen scope.

Weeks eleven to thirteen: decide. Widen to automatic submission for the payer and procedure where the error log is clean, or stop. Write the stopping rule down in week one, before anyone is emotionally invested, and name the person who gets to apply it. Sequencing this against your wider agent roadmap, your EHR contract and the 2027 API deadline is exactly the ground an AI readiness audit covers, and it is where most practices find they were about to automate the second most expensive workflow rather than the first.