Can AI actually do prior authorization, or just the paperwork around it?

The short version

• Physicians and their staff complete about 39 prior authorizations a week, taking roughly 13 hours, according to the AMA's 2024 survey of 1,000 physicians.
• Eighty-nine percent of surveyed physicians said prior authorization increases burnout, and more than a quarter reported it leading to a serious adverse event for a patient.
• Most of those 13 hours is assembly rather than clinical judgement: locating documents that already exist and formatting them for one payer.
• The clinical attestation cannot be automated, and it is also the part that takes the least time.
• A system that submits an incomplete packet saves nothing. It moves the delay to the denial.

How much time does prior authorization actually take?

The AMA surveyed 1,000 practising physicians in late 2024. Respondents reported completing an average of 39 prior authorization requests a week, and spending about 13 hours of physician and staff time on them. Eighty-nine percent said the process somewhat or significantly increases burnout.

The part that gets quoted less often is the clinical consequence. More than a quarter of those physicians reported that prior authorization had led to a serious adverse event for a patient in their care. Broken down, 23 percent reported a hospitalisation, 18 percent a life-threatening event, and 8 percent a disability, permanent damage, birth defect or death. Ninety-three percent reported that it delays access to care.

Thirteen hours a week is most of two working days. For a three-clinician practice without a dedicated authorisation specialist, that work is being absorbed by people who were hired to do something else.

Which part is clinical judgement and which part is clerical?

Split a single request into its steps and the proportions become obvious. Somebody identifies which payer rule applies to this procedure for this plan. Somebody finds the prior conservative treatment in the notes and confirms it meets the duration the payer requires. Somebody locates the imaging report and the referring note. Somebody assembles all of it into whatever format this payer accepts. Somebody attests that the treatment is medically necessary. Somebody submits it and tracks it.

Only one of those is clinical, and it is the fastest. The rest is retrieval, checking and formatting, performed by a human because no single system can see the record, the payer rule and the submission channel at once.

That is the actual shape of the opportunity, and it is a narrower claim than the one usually made. The thirteen hours are not thirteen hours of medical decision making.

What can a system genuinely do today?

It can read the chart and pull out what the payer's criteria ask for, with each element linked back to the note it came from. It can check the packet against the criteria and say which required element is missing before anything is submitted. It can draft the letter of medical necessity from the clinical facts already in the record. It can track what has been submitted and what has gone quiet, which is otherwise a spreadsheet somebody maintains by hand.

The connecting idea is that each of those produces a draft for a clinician to approve, not a decision. The clinician still reads it, still attests, still submits. What changes is that they start from an assembled packet with the gaps already flagged rather than from an empty form and a search box.

What can it not do?

It cannot make the attestation. Medical necessity is a clinical judgement with a named clinician behind it, and no part of that should be delegated to a system, including in the sense of a clinician rubber-stamping something they did not read.

It cannot invent documentation that does not exist. If the record genuinely does not contain six weeks of conservative treatment, no amount of assembly produces it, and a system that submits anyway has converted a visible gap into an invisible one that arrives back as a denial two weeks later.

And it cannot always submit. Where a payer has no API, somebody keys the packet into a portal or sends a fax. The assembly still saves the time; the submission does not.

Does this have to touch the EHR, and what if it cannot?

Mostly yes, because the documents it needs to assemble live there. Where the EHR exposes an API this is routine. Where it does not, the alternatives are exports and document drops, and all of them are more fragile and more expensive than an API.

This is the point at which the honest answer is sometimes that it is not worth building yet. An integration that breaks on every vendor update costs more in maintenance than it saves in assembly. We would rather say the integration is the blocker than ship something that quietly degrades.

Is any of this about to change on its own?

Partly, and on a published timetable. Under the CMS Interoperability and Prior Authorization Final Rule, impacted payers were required to implement certain prior authorization provisions by 1 January 2026, and have until 1 January 2027 to meet the rule's application programming interface requirements.

What that means in practice is that the submission channel improves before the assembly problem does. An API to submit into does not find the conservative treatment note or check it against the criteria. It removes the keying, which is real, and leaves the thirteen hours largely intact.

It is also worth knowing where electronic adoption currently stands. The 2025 CAQH Index, covering 2024 activity, put electronic prior authorization adoption at 40 percent. That is the direction of travel, and it is also a reminder that most of this is still being done by hand today.

How would you know it is working?

Count two things before you change anything, because afterwards you will not be able to reconstruct them. How many minutes it takes to assemble a packet, measured on a sample rather than estimated. And what proportion of submissions come back asking for something that was already in the record.

The second number is the honest measure. It is the one that tells you whether assembly is actually the bottleneck, and it is the one that should fall first. If it does not move, the problem was never assembly and the project was aimed at the wrong thing.

Approval rate is a tempting third metric and a misleading one. A system should not change whether a medically necessary treatment is approved. If approval rate jumps, look closely at what is being claimed.

Is this worth doing for a practice with three clinicians?

Sometimes. The arithmetic is the number of requests a week multiplied by the assembly minutes, against the cost of a build and the state of your EHR integration. At 39 requests a week the time is real. At five it probably is not, and the better answer is a written checklist per payer that a human follows.

What does not change with practice size is the governance. Every packet gets reviewed by the ordering clinician before submission, every assembled element links back to its source note, and the system says plainly when a required element is missing rather than submitting and waiting for the denial. Those are the same rules at three clinicians as at thirty.