What is prior authorization automation?

Prior authorization automation is software that handles the approval a payer requires before a test, procedure or drug is covered: checking whether authorization is needed, assembling the clinical documentation, submitting the request, tracking its status and routing denials. In 2026 it increasingly means AI on both sides, with a provider-side agent drafting the request from the chart and a payer-side agent scoring it against coverage criteria. The automation only works when the criteria, the status of each request and the reason for each denial are written down in a form both systems can read.

Does AI increase prior authorization denials?

It can, and physicians expect it to. In the AMA's May 2026 survey of 1,000 physicians, six in ten said they were concerned AI may further increase denial rates, and 74% said denials have risen over the past five years. The early Medicare evidence points the same way: records obtained by the EFF show two WISeR vendors denied 5,944 requests in the program's first three months, and one vendor denied more requests than it approved. AI applies whatever criteria it's given faster. If the criteria are unpublished or the incentive rewards denial, speed raises the denial count.

Is AI prior authorization accurate?

The extraction and matching steps are accurate enough to be useful: reading a chart, pulling the relevant history and mapping it to a published criterion. Accuracy breaks where the criterion itself is ambiguous, out of date or never shown to the provider. A payer-side model that scores a narrative against a rule the clinician can't see produces a decision nobody can check. Under CMS's interoperability and prior authorization rule, affected payers must give a specific reason for every denial regardless of the method used, which makes an unexplainable AI denial a compliance problem, not just a quality one.

What is the Medicare WISeR model?

WISeR (Wasteful and Inappropriate Service Reduction) is a CMS Innovation Center model that adds technology-vendor prior authorization to selected services in Original Medicare. It runs from January 1, 2026 to December 31, 2031 in New Jersey, Ohio, Oklahoma, Texas, Arizona and Washington. Vendors are paid a percentage of the expenditures associated with averted care, adjusted by performance metrics, and CMS says every non-payment recommendation is determined by a licensed clinician. It does not apply to Medicare Advantage.

What does CMS require for prior authorization by January 1, 2027?

Under the CMS Interoperability and Prior Authorization final rule (CMS-0057-F), impacted payers (Medicare Advantage organizations, Medicaid and CHIP programs and managed care plans, and Qualified Health Plan issuers on the federal exchanges) must implement a Prior Authorization API by January 1, 2027. The API has to identify documentation requirements, support requests and responses, and communicate decisions. Decision timeframes of 72 hours for expedited requests and seven calendar days for standard requests, plus a specific denial reason, already apply from January 1, 2026.

AI prior authorization vs electronic prior authorization: what's the difference?

Electronic prior authorization (ePA) is the pipe: a structured, standards-based exchange of the request, the documentation requirements and the decision between provider and payer, which is what the 2027 CMS API mandate builds. AI prior authorization is what runs on either end of the pipe: a model that drafts the justification or one that scores it. ePA without AI still removes the fax and the status call. AI without ePA just writes faster narratives into the same fax queue.

How do you automate prior authorization without raising denials?

Write the process down before adding a model. Keep a maintained map of which payer, plan and code combinations require authorization and where each rule is published. Define one structured request record with explicit status states. Store every denial reason as structured data and feed it back into the submission check. Track decision time against the 72-hour and seven-day clocks per payer. Then use AI for extraction and drafting on top of that record, with a human reviewing anything the system can't map to a published criterion.

Healthcare admin

Prior authorization automation is now AI on both sides. The rules in the middle still aren't written down.

Prior authorization automation now means AI writing the request and AI scoring it. Medicare's WISeR records show what breaks: the criteria, the clock and the denial reason.

Alexey Yushkin May 20, 2026 Updated October 2, 2026 7 min read

TL;DR: Prior authorization automation is software that checks whether a payer needs approval, builds the request, submits it, tracks it and handles the denial. In 2026 it has become AI on both sides: a provider-side agent writes the justification from the chart, and a payer-side agent scores it against coverage criteria. Medicare’s AI prior-authorization pilot shows what happens when the layer in between isn’t defined. Two vendors denied 5,944 requests in three months, and one request sat unanswered for 83 days against a 72-hour target. The model isn’t the bottleneck. The unpublished criterion, the missing status record and the unstructured denial reason are. CMS’s January 1, 2027 API deadline forces payers to build the pipe. Providers still have to write down what flows through it.

Updated October 2, 2026, with the Medicare WISeR records, the AMA’s 2026 physician survey and the CMS 2027 prior authorization API deadline. First published May 20, 2026.

When I first wrote this piece in May, the argument was simple. The AI opportunity in healthcare isn’t the chart, it’s the admin layer, and prior authorization is the most expensive part of that layer. Four months later the industry agrees on where the opportunity is. The problem is that both sides went after it with models at the same time.

AI now writes the request and AI scores it

The shape of prior authorization changed this year. A provider-side agent pulls the history, the last note, the labs and the payer’s published guideline language, then writes a justification that reads like a careful human wrote it. On the payer side, another agent parses that narrative, maps its phrases to coverage criteria, and either approves it or sends it to a reviewer with a suggested disposition. Economist Matt Hasan laid out this exact loop in a KevinMD essay in September 2026. His point was that the contract questions now matter more than the model questions.

From an operator’s seat, this is two systems negotiating over a document neither one owns. The provider’s agent is optimizing a narrative for a criterion it can only partly see. The payer’s agent is matching phrases against a rule the clinician never got. Both get faster. Nothing in the middle gets more legible.

The volume they’re working against is not small. The AMA’s May 2026 survey of 1,000 physicians found physicians handle an average of 40 prior authorizations a week, eating about 13 hours of physician and staff time every week. 95% said prior authorization delays access to necessary care. 26% said it has led to a serious adverse event. And six in ten said they were concerned AI may push denial rates higher still.

What Medicare’s own AI pilot shows

The clearest evidence so far comes from Medicare itself. CMS’s WISeR model (Wasteful and Inappropriate Service Reduction) started on January 1, 2026 in six states: New Jersey, Ohio, Oklahoma, Texas, Arizona and Washington. It runs through 2031. Technology vendors run prior authorization on selected services in Original Medicare, and CMS pays them a percentage of the expenditures associated with averted care.

In September 2026 the Electronic Frontier Foundation published roughly 1,000 pages of contracts, status reports and provider complaints it obtained through FOIA litigation. Per the EFF’s write-up, two vendors denied 5,944 requests in the first three months. One vendor, Virtix, denied more than it approved and was put on a corrective action plan. One request went 83 days without an answer against a 72-hour standard. STAT reported the same week that a vendor had warned CMS it was unrealistic to expect a working product by the launch date the agency wanted.

None of that is a model failure. It’s a process that launched before its own parts existed. Here’s what was missing:

a working intake system on day one
a clock that someone watched
an incentive structure that didn’t reward the denial itself

A licensed clinician still signs every non-payment recommendation, per CMS. But a reviewer handed a queue of AI-suggested denials faces the same approval-fatigue problem I wrote about in human-in-the-loop AI agent approval: by the fiftieth file, the suggestion is the decision.

The regulator already named the layer that matters

The federal rule that governs most of the commercial side says nothing about models. It’s about the process around them.

CMS’s Interoperability and Prior Authorization final rule (CMS-0057-F, January 2024) requires Medicare Advantage plans, Medicaid and CHIP programs and managed care plans, and exchange-based QHP issuers to decide expedited requests within 72 hours and standard requests within seven calendar days, starting January 1, 2026. Payers must also give a specific reason for every denial, “regardless of the method used,” and publish their prior authorization metrics every year, with the first report due March 31, 2026. By January 1, 2027, they must run a Prior Authorization API that publishes documentation requirements and exchanges requests and decisions electronically.

Read that list again as an operator: a clock, a reason, a published requirement, a shared status. That’s a data contract. The regulator wrote the spec for the layer the AI was supposed to skip. A payer-side model that can’t produce a specific reason for its score isn’t compliant just because a person clicked approve on it. Lending went through the same thing in May, when CFPB Circular 2026-03 made the lender, not the model vendor, responsible for specific, accurate adverse-action reasons. I covered that in AI lending agents and the loan file.

Where prior authorization breaks, layer by layer

The step	Who’s automating it in 2026	What it inherits if nobody owns it	What writing it down looks like
Does this need authorization?	Provider rules engines, payer API (from 2027)	Payer rules in PDFs that change without notice	A maintained map of payer × plan × code requirements, with the source and last-checked date
Assemble the justification	Provider-side AI drafting from the chart	Whatever the chart documents, or doesn’t	A documentation checklist per service, checked before drafting starts
Score against criteria	Payer-side AI with clinician sign-off	A criterion the provider never saw	The published criterion attached to the decision, quoted in the denial
Track status	Portals, fax, phone calls	No shared state; staff chase by phone	One request record with explicit states, timed against 72 hours and seven days
Handle the denial	Appeals staff	A free-text reason nobody aggregates	Structured denial reasons fed back into the submission check

Every row has the same pattern. The automation is real. The thing it inherits is unowned. The fix is a written definition, not a better model.

The working version

The order of operations from my original piece still holds. The 2026 evidence just makes it sharper.

Start by making the requirement legible: which payer, plan and code combinations need authorization, where each rule is published, and when someone last checked it. Most provider organizations have never written this down. That’s why a provider-side agent ends up drafting beautiful narratives for criteria that changed last Tuesday.

Then define the request as a record, not a fax. Fields, documentation requirements, status states, timestamps. The 2027 API gives payers a reason to accept structured requests. Providers who already hold their requests in that shape can plug in. Everyone else ends up building a translation layer on deadline.

Feed every denial back as structured data. A denial for missing documentation should stop the next submission that lacks it. This is the loop that separates automation from a faster fax machine. It’s also where you find out whether a payer’s AI keeps denying on a criterion its own published policy doesn’t contain.

Only then point a model at the work: extraction from payer documents, drafting from the chart, flagging likely denials before submission. AI is good at all three. It’s the last step on three layers of process and integration, which is the whole method. The same pattern shows up one step downstream in AI medical coding. There, the code is only as right as the note.

ROI is the step you delete

Count the steps removed, not the people. Re-keying the chart into a portal: gone. The status phone call: gone once the status is a record. The resubmission for a knowable denial: cut. The decision time per request: measured against the CMS clock instead of guessed. Thirteen hours of physician and staff time a week is the size of the prize. None of that number requires anyone to lose a job. It requires someone to own the process.

The operator read

Prior authorization automation stopped being a question of whether to use AI. Both sides already do. What’s left is whether the rules, the clock and the reason are written down somewhere both machines can read, and Medicare’s own pilot just showed what happens when they aren’t. The payers get their API mandate in January. The providers who already know their requirements, hold their requests as records and track their denials by reason will be the ones who can actually use it. If your prior-auth backlog is the problem in front of you, start the conversation with the map, not the model.

FAQ

What is prior authorization automation?: Prior authorization automation is software that handles the approval a payer requires before a test, procedure or drug is covered: checking whether authorization is needed, assembling the clinical documentation, submitting the request, tracking its status and routing denials. In 2026 it increasingly means AI on both sides, with a provider-side agent drafting the request from the chart and a payer-side agent scoring it against coverage criteria. The automation only works when the criteria, the status of each request and the reason for each denial are written down in a form both systems can read.
Does AI increase prior authorization denials?: It can, and physicians expect it to. In the AMA's May 2026 survey of 1,000 physicians, six in ten said they were concerned AI may further increase denial rates, and 74% said denials have risen over the past five years. The early Medicare evidence points the same way: records obtained by the EFF show two WISeR vendors denied 5,944 requests in the program's first three months, and one vendor denied more requests than it approved. AI applies whatever criteria it's given faster. If the criteria are unpublished or the incentive rewards denial, speed raises the denial count.
Is AI prior authorization accurate?: The extraction and matching steps are accurate enough to be useful: reading a chart, pulling the relevant history and mapping it to a published criterion. Accuracy breaks where the criterion itself is ambiguous, out of date or never shown to the provider. A payer-side model that scores a narrative against a rule the clinician can't see produces a decision nobody can check. Under CMS's interoperability and prior authorization rule, affected payers must give a specific reason for every denial regardless of the method used, which makes an unexplainable AI denial a compliance problem, not just a quality one.
What is the Medicare WISeR model?: WISeR (Wasteful and Inappropriate Service Reduction) is a CMS Innovation Center model that adds technology-vendor prior authorization to selected services in Original Medicare. It runs from January 1, 2026 to December 31, 2031 in New Jersey, Ohio, Oklahoma, Texas, Arizona and Washington. Vendors are paid a percentage of the expenditures associated with averted care, adjusted by performance metrics, and CMS says every non-payment recommendation is determined by a licensed clinician. It does not apply to Medicare Advantage.
What does CMS require for prior authorization by January 1, 2027?: Under the CMS Interoperability and Prior Authorization final rule (CMS-0057-F), impacted payers (Medicare Advantage organizations, Medicaid and CHIP programs and managed care plans, and Qualified Health Plan issuers on the federal exchanges) must implement a Prior Authorization API by January 1, 2027. The API has to identify documentation requirements, support requests and responses, and communicate decisions. Decision timeframes of 72 hours for expedited requests and seven calendar days for standard requests, plus a specific denial reason, already apply from January 1, 2026.
AI prior authorization vs electronic prior authorization: what's the difference?: Electronic prior authorization (ePA) is the pipe: a structured, standards-based exchange of the request, the documentation requirements and the decision between provider and payer, which is what the 2027 CMS API mandate builds. AI prior authorization is what runs on either end of the pipe: a model that drafts the justification or one that scores it. ePA without AI still removes the fax and the status call. AI without ePA just writes faster narratives into the same fax queue.
How do you automate prior authorization without raising denials?: Write the process down before adding a model. Keep a maintained map of which payer, plan and code combinations require authorization and where each rule is published. Define one structured request record with explicit status states. Store every denial reason as structured data and feed it back into the submission check. Track decision time against the 72-hour and seven-day clocks per payer. Then use AI for extraction and drafting on top of that record, with a human reviewing anything the system can't map to a published criterion.