AI Prior Authorization in 2026: What AI Agents Automate and What Stays Human

AI prior authorization is software, usually a large language model agent working inside rules and an audit trail, that does the paperwork side of a prior authorization request: it checks whether an authorization is needed, pulls the clinical evidence from the chart, fills the payer's form, submits it and chases the status. On the provider side it gives staff hours back. On the payer side it is used to review requests, and that is where regulators now draw a hard line: in a growing number of places, a medical necessity denial must be made by a licensed clinician, not by the model.

This guide is written for the people who have to make it work: revenue cycle leaders, health IT teams and product teams building for them. It covers what an AI agent can safely automate today, what stays human, what compliance needs to sign off, and how CMS-0057-F changes the plumbing by 2027.

What is AI prior authorization?

AI prior authorization means using machine learning, and increasingly LLM-based agents, to run the steps of a prior authorization request that used to need a person at a keyboard or on the phone. The agent reads payer rules, reads the patient record, drafts the request and follows it through to a decision, while a person approves anything that involves clinical judgment.

The volume explains the demand. In the 2025 AMA prior authorization physician survey of 1,000 physicians, practices reported an average of 40 prior authorizations per physician per week, taking 13 hours of physician and staff time, and 40% of physicians have staff who work only on prior authorization. The same survey found that 60% of physicians worry AI will increase denial rates. Both numbers matter: the first is why teams buy automation, the second is why every design decision below keeps a clinician in control of the outcome.

If you want the service view rather than the engineering view, our prior authorization automation team scopes these agents for providers, payers and the vendors who sell to them.

Provider-side AI vs payer-side AI

AI prior authorization means two different things depending on which side of the request you sit on, and the rules are different for each. Provider-side AI prepares and submits requests faster; payer-side AI reviews incoming requests and recommends a decision.

The asymmetry is deliberate. An AI that approves a clearly covered MRI faster harms no one. An AI that denies care without a clinician looking at the case is what state legislators, KFF and the AMA are focused on. Build for the first; never build the second.

The six prior authorization steps an AI agent can run

An AI agent can run most of the six steps in a prior authorization request end to end; the clinical sign-off and the peer-to-peer conversation on a denial stay with people. The split below is the one we see work in production: automate the retrieval and the paperwork, keep humans on judgment.

1. Detect whether prior authorization is required

The agent checks the ordered service (CPT or HCPCS code, place of service, plan) against the payer's published code lists and rules. Where a payer supports Da Vinci Coverage Requirements Discovery, the answer comes back through a CDS Hooks call from the EHR; everywhere else, the agent works from the payer's published lists, which is why keeping those lists current is a job in itself (see what payers publish in 2026). Fully automatable.

2. Gather the clinical evidence

The agent reads the chart through FHIR APIs (Condition, Observation, MedicationRequest, DocumentReference, prior imaging) and extracts what the payer's criteria ask for: failed conservative therapy, duration of symptoms, lab values, prior treatments. This is where LLMs earn their place, because the evidence is usually buried in free-text notes. Automatable, with every extracted fact linked back to its source document so a reviewer can check it in seconds.

3. Complete the payer's questionnaire

The agent pre-fills the payer's form or, where supported, the Da Vinci Documentation Templates and Rules (DTR) questionnaire. A person reviews and attests. The attestation is the point where a clinician takes responsibility, so it is never automated away.

4. Submit the request

Submission goes by whatever channel the payer accepts: portal, fax, the X12 278 transaction or, from 2027, the FHIR Prior Authorization API. Agents that drive payer portals through the browser work, but they break when the portal changes and some portals prohibit automated access in their terms, so treat portal automation as a bridge until the API is available. Fully automatable.

5. Track status and answer requests for more information

The agent polls status, reads pended responses and answers administrative questions itself. When the payer asks a clinical question, the agent escalates to a named person with the question, the evidence it already sent and a drafted answer. This escalation rule is the one buyers ask about most: an agent that knows CPT codes is useful; an agent that knows when to stop is safe.

6. Handle a denial

The agent reads the denial reason (payers subject to CMS-0057-F must now give a specific one), checks it against the evidence, and drafts the appeal letter with citations to the chart. The decision to appeal, and any peer-to-peer call, belongs to the clinician. For the denial side of the revenue cycle, see our 2026 denial trends playbook.

Is anyone running prior authorization through an AI agent in production?

Yes. AI agents are handling prior authorization in production today on both sides of the request, and the federal government is running one on traditional Medicare. The honest answer to "is it fully touchless?" is: for a slice of high-volume, clearly documented requests, yes; for most requests, the agent does the work and a person approves it before it goes out.

• Traditional Medicare. CMS started the WISeR model on 1 January 2026 in six states (Arizona, New Jersey, Ohio, Oklahoma, Texas and Washington). Technology vendors use AI together with clinical review to process prior authorization for a defined list of services. It has drawn legal and legislative pushback, and it remains in effect.
• Health plans. In June 2025, plans organized through AHIP and the Blue Cross Blue Shield Association committed that in 2027 at least 80% of electronic prior authorization approvals with complete documentation will be answered in real time. Real-time answers at that scale are only possible with automated review of the clear cases.
• Providers and vendors. Health systems run agents for the retrieval, form-filling and status-chasing steps, with staff reviewing before submission. Public architectures such as AWS's multi-agent prior authorization design follow the same pattern: specialised agents for eligibility, evidence and submission, with a human checkpoint.

What separates the teams that get to production from the ones stuck in a pilot is rarely the model. It is access to the chart through proper EHR integration, a current source of payer rules, and an audit trail good enough for compliance to say yes.

How an AI prior authorization agent is wired

An AI prior authorization agent is five parts: a trigger from the EHR, a payer-rules source, an evidence retriever over FHIR, an LLM that reasons over the evidence and fills forms, and a policy layer that decides what can go out without a person. The model is the smallest part of the build; the rules source and the policy layer are where most of the engineering time goes.

• Trigger. A new order in the EHR (a ServiceRequest or MedicationRequest), picked up by a CDS Hooks order-sign call, a subscription or an HL7 v2 ORM feed from an interface engine.
• Payer-rules source. Da Vinci CRD where the payer offers it, otherwise a maintained table of each payer's code lists and criteria, versioned so you can show which rule set a decision used.
• Evidence retriever. Targeted FHIR reads, not a full chart dump. The payer's criteria decide which resources the agent pulls.
• LLM reasoning and form filling. The model maps evidence to criteria and drafts answers, and must cite a source resource for every answer.
• Policy layer. Deterministic rules, outside the model, that decide whether a draft can be submitted, needs review or must escalate.

For a lumbar spine MRI, for example, the evidence retriever needs the diagnosis, the duration of symptoms, conservative therapy tried and prior imaging. That is four focused queries rather than the whole record:

GET /Condition?patient=Patient/123&code=http://hl7.org/fhir/sid/icd-10-cm|M54.50&clinical-status=active
GET /MedicationRequest?patient=Patient/123&authoredon=ge2026-06-01
GET /Procedure?patient=Patient/123&code=http://www.ama-assn.org/go/cpt|97110&date=ge2026-06-01
GET /DiagnosticReport?patient=Patient/123&category=RAD&date=ge2025-09-01

The policy layer is the part compliance will read, so keep it as plain configuration rather than prompt text. A minimal version:

{
  "service_line": "advanced-imaging",
  "auto_submit_when": {
    "all_criteria_met": true,
    "every_answer_has_source": true,
    "payer_rule_version_age_days_max": 30
  },
  "always_review": ["oncology", "pediatrics", "out-of-network"],
  "escalate_to_human_when": [
    "payer_requests_clinical_information",
    "criteria_partially_met",
    "conflicting_evidence_in_chart"
  ],
  "never_automated": ["clinical_attestation", "appeal_decision", "peer_to_peer"]
}

Because the policy sits outside the model, you can tighten or relax it per payer and per service line without retraining anything, and you can show an auditor exactly why a given request went out without review.

Where AI prior authorization goes wrong

AI prior authorization fails in five predictable ways, and each has a design answer. Most failed pilots hit one of these, not a weakness in the model itself.

The healthcare AI agent failures write-up covers the wider pattern, and the real-time guardrails architecture shows how to enforce the policy layer at run time.

What compliance needs to sign off before an AI prior authorization agent goes live

Compliance needs to see that the agent only touches the minimum PHI, that every action is logged against a person and a source, that clinical decisions stay with clinicians, and that the vendors in the chain are under a business associate agreement. The checklist we use with clients:

1. Business associate agreements with every party that sees PHI, including the model provider. Use model endpoints offered under a BAA, with no training on your data.
2. Minimum necessary access. Scope the agent's EHR access with SMART on FHIR backend services to the resources the payer's criteria need, not the whole chart.
3. A complete audit trail. Log each tool call, each document read, each field filled and each submission, with timestamps and the reviewer who approved it. Our write-up on agent audit trails shows the schema.
4. Human-in-the-loop rules written down. Which service lines may submit without review, which always need review, and what triggers escalation. See where the human belongs in healthcare AI.
5. Output validation. Every clinical fact the agent puts on a form must trace to a source document; unsupported facts block submission.
6. Channel terms. Confirm each payer portal permits automated access, or use the API, X12 278 or a clearinghouse instead.
7. Payer-side only: decision rules. If you are a health plan, medical necessity denials go to licensed reviewers (California SB 1120, CMS Medicare Advantage rules), and you disclose how AI is used.

For the full architecture behind these controls, read building HIPAA-compliant AI agents.

Where the law draws the line on AI in prior authorization

US rules allow AI to prepare, triage and approve prior authorization requests, and increasingly require a qualified human to make any denial based on medical necessity. Three rules shape the design today.

• California SB 1120, the Physicians Make Decisions Act, in effect since 1 January 2025, requires that a denial, delay or modification based on medical necessity be made by a licensed physician or other qualified health care professional, and that plans disclose their use of AI (Senator Becker's office). Other states have introduced similar bills.
• CMS Medicare Advantage rules require coverage decisions to be based on the individual patient's circumstances, so an algorithm cannot be the sole basis for denying a Medicare Advantage request.
• CMS-0057-F sets decision deadlines and requires a specific reason for every denial, which rewards automation that produces complete requests and structured reasons.

How CMS-0057-F changes AI prior authorization by 2027

CMS-0057-F moves prior authorization from portals and fax to FHIR APIs, which turns AI agents from screen-scrapers into API clients. The final rule applies to Medicare Advantage organizations, state Medicaid and CHIP programs and their managed care plans, and Qualified Health Plan issuers on the federal exchanges.

• From 1 January 2026: decisions within 72 hours for expedited and 7 calendar days for standard requests (QHP issuers on the federal exchanges are excluded from the timeframes), and a specific reason for every denial.
• From 31 March 2026: payers publish prior authorization metrics every year, including approval and denial rates and average decision times.
• From 1 January 2027: a Prior Authorization API built on FHIR and the Da Vinci CRD, DTR and PAS implementation guides, so providers can find out whether an authorization is needed, get the documentation rules and submit, all from the EHR.

For an agent, the 2027 API is the difference between a brittle portal bot and a clean integration: the same three questions (is it needed, what do you need, here it is) become three API calls with structured answers. The detail of each piece is in our CMS-0057-F explainer, the Da Vinci PAS implementation guide and our guide to testing a Prior Authorization API.

Build, buy, or both

Buy an off-the-shelf AI prior authorization product when your workflows are standard and your payer mix is mainstream; build, or extend a product, when your EHR, specialty or payer mix is unusual or when prior authorization is part of the product you sell.

If you are building, our step-by-step AI prior authorization agent architecture covers the FHIR queries, the LLM prompts and the orchestration. To compare cost models, see the true cost of prior authorization, and for vendor evaluation, the prior authorization software buyer's guide.

A pilot checklist for AI prior authorization

A good AI prior authorization pilot picks one service line, one or two payers and a baseline you can measure, then runs the agent with human review on every request for the first weeks.

1. Pick one high-volume service line with clear criteria (advanced imaging is the usual first choice).
2. Record today's baseline: requests per week, staff minutes per request, first-pass approval rate, days to decision.
3. Connect the agent to the chart through FHIR and to one submission channel.
4. Run with human review on 100% of requests; measure how often the reviewer changes the draft.
5. Relax review only for request types where reviewers stop making changes.
6. Report the same four metrics monthly, next to the payer's own published metrics once they appear under CMS-0057-F.

Planning an AI prior authorization agent? Our healthcare AI agents team designs the agent, the human checkpoints and the audit trail, and our healthcare interoperability engineers connect it to the EHR, X12 and the new FHIR APIs. Book an architecture review and we will map your prior authorization workflow and show which steps an agent can take over first.