AI prior authorization: where it fits, how to build it, and what it saves

AI prior authorization works best as assistive automation: software reads the chart, finds what the payer's criteria ask for, drafts and submits the request, and a person on your staff approves anything clinical before it goes out. CMS-0057-F already holds most impacted payers to 72-hour and seven-day decisions, and FHIR Prior Authorization APIs are due by January 2027. This guide covers where AI fits, the architecture, HIPAA-safe review and one production result.

By Kanika Mathur, Head of Service Delivery

Reviewed by Resourcifi engineeringPublished Sep 24, 2026Updated Sep 24, 202613 min read

Healthcare

Key takeaways

The short version

The burden is measurable. Practices complete an average of 40 prior authorizations per physician per week and spend 13 hours of physician and staff time on them (AMA physician survey, 2025).
The rules changed in 2026. Under CMS-0057-F, most impacted payers must decide urgent requests within 72 hours and standard ones within seven calendar days, and give a specific denial reason; FHIR Prior Authorization APIs are due January 1, 2027 (CMS).
AI belongs in the unstructured steps. Evidence extraction from notes, justification drafts and denial responses; rules and the Da Vinci CRD, DTR and PAS standards handle the rest, and a person approves before submission.
Plan for portals and APIs side by side. Plans expect 26% of prior authorizations over FHIR in 2026 and 60% in 2027; providers expect 23.3% and 33.4% (2025 CAQH Index).
One production result: a three-engineer Resourcifi pod at SamaCare, from October 2025, cut manual effort per prior authorization submission by 65% (SamaCare case study).

The prior authorization problem, in numbers

Prior authorization is mostly clerical work done under clinical pressure. In the 2025 AMA survey, practices completed an average of 40 prior authorizations per physician per week and spent 13 hours of physician and staff time on them, and 40% of physicians had staff who work on nothing else. Phone is still the most common way practices complete requests for medical services. Most of that work is repetitive, which is where AI prior authorization can take hours out of the week.

The volume is not falling. Medicare Advantage insurers made 52.8 million prior authorization determinations in 2024, and 4.1 million of them (7.7%) were denied in full or in part, according to KFF's analysis of CMS data.³ Only 11.5% of those denials were appealed, yet 80.7% of the appeals were partly or fully overturned. KFF offers two readings: the first request should have been approved, or it lacked the documentation to justify the service. The second is a fixable engineering problem.

Physician and staff time spent on prior authorizations each week, at an average of 40 requests per physician.

AMA physician survey, 2025

80.7%

Share of appealed Medicare Advantage prior authorization denials that were partly or fully overturned in 2024.

KFF, January 2026

Less effort per prior authorization submission in the SamaCare engagement, delivered by a three-engineer pod.

Resourcifi SamaCare case study

The human cost shows up in the same survey. 94% of physicians said prior authorization increases burnout, 92% said it hurts clinical outcomes, and 26% said it had led to a serious adverse event for a patient in their care.² The HL7 Da Vinci project describes the mechanics behind those numbers plainly: requests go by fax or through payer-specific portals where clinicians re-key information, fax requires manual transcription on the payer side, and re-keying causes data entry errors.⁵

If you want to cut the time your practice spends on prior authorizations, start by timing one week of requests from order to decision. In our reading of the workflow, the hours sit in three places: finding out whether a service needs approval, pulling the evidence out of the chart, and typing it into a portal. Target those first.

What the CMS prior authorization rule requires

The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F), released January 17, 2024, applies to Medicare Advantage organizations, Medicaid and CHIP programs and plans, and QHP issuers on the federal exchanges. Since January 1, 2026, most impacted payers must decide urgent requests within 72 hours and standard requests within seven calendar days, give a specific reason for every denial and publish prior authorization metrics. By January 1, 2027, they must run a FHIR Prior Authorization API.

Operational deadlines are already live; API deadlines arrive in 2027. Exact dates vary by payer type, and none of these provisions apply to drugs.¹

What CMS-0057-F requires of impacted payers, and when
Requirement	Compliance date	What it means for your workflow
Decisions within 72 hours (expedited) and seven calendar days (standard)	January 1, 2026	Faster answers, so a complete first submission matters more than a fast follow-up
Specific reason for every denial, by any channel	January 1, 2026	Denial text becomes structured input for a resubmission or appeal
Public prior authorization metrics	Initial set by March 31, 2026	You can compare payers before you prioritize which to automate
Prior Authorization API listing covered items, documentation rules, request and response	January 1, 2027	Direct submission from the EHR replaces portal re-keying where the payer is live
Prior authorization data in Patient Access and Provider Access APIs	January 1, 2027	Status and history become queryable instead of trapped in portals
Electronic Prior Authorization attestation measure for clinicians and hospitals	CY 2027 reporting period	MIPS clinicians attest to at least one request through the API, or claim an exclusion

Two details shape the technology choice. First, the rule requires HL7 FHIR Release 4.0.1 and US Core, and CMS recommends the Da Vinci Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) and Prior Authorization Support (PAS) implementation guides. Second, HHS has announced enforcement discretion for the HIPAA X12 278 standard, so a payer that builds an all-FHIR Prior Authorization API will not face enforcement for skipping X12.¹

The EHR side moved too. ASTP/ONC finalized the HTI-4 rule on July 31, 2025, adding certification criteria for electronic prior authorization built on the same Da Vinci guides: request coverage requirements from the payer, assemble the documentation the payer asks for, submit the request and check its status.⁷ Drugs remain the gap. CAQH notes that CMS-0057-F did not address drug prior authorization and that CMS proposed closing it in April 2026.⁴

Where AI prior authorization fits in the workflow

Prior authorization automation with AI belongs in the unstructured steps: reading clinical notes to find the evidence a payer's criteria ask for, drafting the medical necessity summary, filling payer forms, and turning a denial reason into a resubmission plan. Rules engines and standards handle the structured steps, such as whether a service needs approval at all. A person on your staff approves anything clinical before it is submitted.

The common design mistake is putting a language model where a lookup would do, or a lookup where judgement is needed. The split below is how we would scope a build.

Prior authorization, step by step: what to automate and what stays human
Step	Standard	Best automation	AI's role	Human role
Is approval required?	Da Vinci CRD	Payer rules lookup at order entry	Small: match free-text orders to codes	Confirm edge cases
Gather documentation	Da Vinci DTR	Questionnaire prefilled from the chart	Large: find evidence in notes, cite the source	Review and correct
Write the justification	None	Template plus drafted narrative	Large: summarize history against criteria	Clinician signs off
Submit the request	Da Vinci PAS, or payer portal	API call, or portal automation until the API exists	Small: map fields to each portal	Handle exceptions
Track and follow up	PAS status check	Polling and alerts against the 72-hour and seven-day windows	Small: classify payer messages	Answer requests for more information
Respond to a denial	Specific denial reason	Route by reason code	Medium: draft a resubmission or appeal	Decide whether to appeal

The DTR guide already anticipates this design. It lets payers express documentation rules computably and supports automatically extracting existing EHR information for review and confirmation, using FHIR Questionnaires with embedded CQL logic.⁶ A language model is worth its cost on what structured data misses: the failed conservative therapy buried in a progress note, the imaging result in a scanned PDF. Every extracted answer should cite the note it came from, so the reviewer checks a citation instead of re-reading the chart.

A clinic back office desk with two monitors showing a blurred form layout and a blank document viewer, a stack of printed pages with coloured index tabs, a desk phone, a fax machine, a coffee cup and an amber banker's lamp beside a bright window, no people — Most prior authorization hours are spent between the chart, the payer's criteria and the portal.

For a wider view of where language models help in care delivery and administration, see our guide to AI use cases in healthcare. Prior authorization is narrower and easier to measure: minutes per submission, first-pass approval rate, turnaround.

Architecture of an AI prior authorization system

A production AI prior authorization system has six layers: EHR integration over FHIR, a coverage rules service, an evidence extraction service with source citations, a submission layer that speaks both the FHIR Prior Authorization API and payer portals, a human review queue, and an audit and evaluation layer. The portal layer matters because payer APIs arrive unevenly; CAQH found plans expect only 26% of prior authorizations to run over FHIR in 2026.

EHR integration. Read orders, problems, medications, results and notes as FHIR R4 resources through US Core, and launch inside the clinician's workflow with SMART on FHIR, which the DTR guide names as one way to render payer questionnaires.⁶ Scope reads to the order in hand.
Coverage rules. A deterministic service that answers "does this need approval, and what does this payer want?" from payer rules, CRD responses and your denial history. Keep it out of the model.
Evidence extraction. The language model reads the scoped notes and documents, answers each criterion, and returns the answer, a confidence score and the exact source passage. Low-confidence answers go to a person, never to the payer.
Submission. Where a payer is live on the Prior Authorization API, submit through PAS. The PAS guide allows an intermediary to convert FHIR to X12 278 when needed.⁵ Everywhere else, use browser automation against the payer portal, with screenshots of each submission stored as evidence.
Review queue. One screen per request: the criteria, the drafted answers with citations, the justification and a single approve or edit action. Time spent here is your real effort metric.
Audit and evaluation. Log every read, draft, edit, approval and submission against a named user. Keep a test set of past requests with known outcomes and rerun it before every model or prompt change. Our guide to AI evaluation covers how to build that set.

The portal layer is not a stopgap you can skip. In the 2025 CAQH Index, almost 63% of medical plans were developing a FHIR-based prior authorization API, but provider readiness remained early, and expectations for FHIR adoption ranged from under 10% to 100%.⁴ The chart shows the averages.

Plans expect FHIR prior authorization to take off in 2027, providers expect a slower climb

Average expected share of prior authorizations conducted over HL7 FHIR. Orange is plans, blue is providers.

Data behind this chart
Year	Medical plans	Medical providers
2026	26.0%	23.3%
2027	60.0%	33.4%
2028	72.0%	41.4%

Source: CAQH, 2025 CAQH Index FHIR and Interoperability Chartbook Module. Plan averages were estimated from numeric responses, excluding "don't know".

Our reading: even on the plans' own forecast, about four in ten prior authorizations still travel outside FHIR in 2027. Build the submission layer so each payer is a configuration, API where live and portal where not, and the switch is a flag rather than a rewrite. The same CAQH module found that plans cite technology and system integration as their top barrier, while providers more often cite resource constraints and a lack of FHIR expertise.⁴

Portal automation is closer to robotic process automation than to AI, and it breaks when a payer redesigns a page. For prior authorization that brittleness is usually acceptable, because the alternative is a person typing the same fields.

Is AI prior authorization HIPAA compliant? PHI controls and human review

AI prior authorization can be HIPAA compliant, but compliance comes from how the system and its contracts are built, not from the model. Every vendor that touches protected health information needs a written business associate agreement, requests must be limited to the minimum necessary PHI, and the system must record who accessed what. On top of HIPAA, keep a person accountable for every clinical statement the software sends to a payer.

The HIPAA Privacy Rule lets a covered entity allow a business associate to create, receive, maintain or transmit PHI only with satisfactory assurance, documented in a written contract, that the business associate will safeguard it, and the same applies down the chain to subcontractors.¹⁰ In practice that means a signed agreement with your model provider, your cloud host and any automation vendor before a single note is sent. The Security Rule adds technical safeguards: unique user identification, audit controls that record and examine activity in systems holding electronic PHI, and encryption as an addressable specification.¹¹

A checklist we would hold any prior authorization build to:

Contracts first. Business associate agreements with every party in the PHI path, including subcontractors, and a written no-training term for model providers.
Minimum necessary by design. The rule requires reasonable efforts to limit PHI to the minimum necessary for the purpose.¹⁰ Send the model the notes for this order and this payer's criteria, not the full chart.
Named users, full trail. Every draft, edit, approval and submission tied to a unique user and kept in an audit log you can export.
Encryption in transit and at rest, including stored portal screenshots and model logs.
Citations or it does not ship. An extracted answer without a source passage is treated as unanswered.
Human approval before submission. The software drafts; a staff member or clinician approves. No auto-submission of clinical justifications.

Human review also matches where regulators have landed on the payer side. CMS told Medicare Advantage plans in February 2024 that an algorithm can assist coverage decisions but the decision must rest on the individual patient's circumstances, and that AI alone cannot be the basis to deny an inpatient admission.⁸ CMS's own WISeR model, which runs from January 1, 2026 through December 31, 2031 in six states, pairs AI and machine learning with human clinical review, and all recommendations for non-payment are made by licensed clinicians.⁹ Physicians are watching: 60% told the AMA they are concerned AI increases or will increase denial rates.²

Our healthcare builds are engineered to HIPAA's requirements, and the evidence matters as much as the controls. Our piece on AI for compliance explains how to treat that evidence as a build deliverable, and the AI agent for healthcare guide covers the broader governance limits.

SamaCare results: 65% less effort per prior authorization submission

From October 2025, Resourcifi embedded a pod of one full stack developer and two data engineers at SamaCare, a prior authorization platform for specialty practices. The pod built Python Playwright automation for submitting prior authorizations across payer portals, repaired the AI prior authorization engine's data and denial response fields, and cut manual effort per prior authorization submission by 65%.

The case data, as published:¹²

SamaCare engagement: the published case data
Item	What the case study reports
Starting problem	Manual PA submissions, an unmaintained dbt data dictionary and inaccessible NPS data slowing the team
Team	Dedicated pod of three: one full stack developer, two data engineers
Timeline	From October 2025, ongoing
Scope	Eight workstreams across PA automation, NPS reporting and LLM tooling
PA submission	Python Playwright automation submitting prior authorizations across payer portals
AI engine	Fixes to engine data, denial response fields, a gender value bug and false positive analysis
LLM tooling	An LLM wrapper that maintains the dbt data dictionary, integrated with DataHub
Stack	Snowflake, dbt, Airflow, Superset, DataHub, Pendo; React, Node.js, GraphQL, PostgreSQL; Playwright, Python, TypeScript
Headline outcome	65% less effort per PA submission
Quality finding	3.6% false-positive rate identified
Delivery pace	Story points per sprint rose from 22 in sprint one to 46 by sprint twelve, tracked in Jira

Three lessons carry over to any AI prior authorization build.

The headline result is about submission. The outcome is measured per PA submission, and the workstream behind submission was portal automation. That fits the architecture above: until Prior Authorization APIs are live, the portal is where the typing happens, and removing it is the most direct effort cut.
The AI engine needed data work before it needed a better model. The fixes the case study lists are data fields, a value bug and false positive analysis. Measuring a false-positive rate is what lets a team decide which outputs a reviewer must check.
Small pods can move this. Three engineers working inside SamaCare's own stack delivered the result. Prior authorization is integration-heavy, so continuity with one stack and one team counts for more than headcount.

The case study does not publish how the 65% was measured or the per-submission minutes, so treat it as one engagement's reported result rather than a benchmark. The full write-up is in the SamaCare case study.

Build vs buy for AI prior authorization

Buy when your prior authorization volume is ordinary, your payers and specialties are well covered by an existing product, and it plugs into your EHR. Build, or extend a product with custom work, when prior authorization is part of what you sell, when your specialty's criteria are unusual, or when you need the data and the evaluation evidence to stay yours. As a rule of thumb, a provider group usually buys and a health tech company usually builds.

Decision matrix: when to build and when to buy (our judgement)
Factor	Points to buy	Points to build
Who you are	A practice or health system automating its own work	A health tech company where prior authorization is the product
Payer and specialty mix	Common payers and high-volume services	Specialty drugs, rare procedures or regional payers a product covers poorly
EHR	A major EHR with an existing integration	A niche or in-house system, or several EHRs across clients
Data and evaluation	Vendor dashboards are enough	You need your own test sets, error rates and audit exports
API timing	Vendor commits to Prior Authorization API support by January 2027	You need a portal and API layer you control, payer by payer
Team	No engineers to own integrations	A product team that can own the system after hand-off

If you buy, ask each vendor four questions. Which Da Vinci guides do you support, and from what date for each of our payers? Who signs the business associate agreement for each PHI hop? Can we export the audit log and the evidence behind each submission? What is your measured false-positive rate on extracted criteria?

If you build, start narrow: one specialty, the three payers with the most volume, and a review queue your staff will actually use. Our build vs buy AI framework covers the general trade-offs. Our healthcare AI development team scopes prior authorization builds against your payers, your EHR and your review workflow before any code is written.

Frequently asked

AI prior authorization questions

How does AI automate prior authorization?

AI automates the unstructured parts of prior authorization. It reads the clinical notes tied to an order, finds the evidence each payer criterion asks for, cites the source passage, drafts the medical necessity summary and fills the payer's form. Rules and standards handle the structured parts: Da Vinci CRD tells you whether approval is needed, DTR defines the documentation and PAS carries the request. A staff member or clinician reviews and approves before anything is submitted.

Is AI prior authorization HIPAA compliant?

It can be, but compliance comes from the build and the contracts, not the model. HIPAA requires written business associate agreements with every party that handles protected health information, reasonable efforts to limit PHI to the minimum necessary, unique user identification and audit controls. In practice that means signed agreements with your model and cloud providers, sending only the notes relevant to the order, and logging every draft, edit and submission against a named user.

What does the CMS prior authorization rule require?

CMS-0057-F, released January 17, 2024, applies to Medicare Advantage, Medicaid and CHIP programs and plans, and QHP issuers on the federal exchanges. Since January 1, 2026, most impacted payers must decide expedited requests within 72 hours and standard requests within seven calendar days, give a specific reason for each denial and publicly report prior authorization metrics. By January 1, 2027, they must run a FHIR Prior Authorization API. Drugs are excluded.

How can our practice cut time spent on prior authorizations?

Time one week of requests from order to decision first, so you know where the hours go. Then automate three steps: checking whether a service needs approval, pulling the evidence out of the chart, and entering it into the payer portal or API. Keep a review queue so staff approve each request in one screen. The AMA's 2025 survey puts the average load at 40 requests and 13 hours of physician and staff time a week.

What are the Da Vinci CRD, DTR and PAS standards?

They are HL7 FHIR implementation guides that CMS recommends for the Prior Authorization API and that the HTI-4 rule uses for EHR prior authorization criteria. Coverage Requirements Discovery (CRD) tells the provider whether a service needs approval and what the payer requires. Documentation Templates and Rules (DTR) expresses the payer's documentation rules as questionnaires that can be prefilled from the EHR. Prior Authorization Support (PAS) submits the request and checks its status.

Can AI deny a prior authorization request?

Not as the sole basis for an inpatient admission denial under current CMS guidance for Medicare Advantage. In February 2024 CMS said an algorithm can assist coverage decisions, but every decision must rest on the individual patient's circumstances, and AI alone cannot be the basis to deny an inpatient admission. In CMS's WISeR model, which uses AI in traditional Medicare prior authorization, all recommendations for non-payment are made by appropriately licensed clinicians.

Kanika Mathur

Head of Service Delivery, Resourcifi

Kanika Mathur is Head of Service Delivery at Resourcifi. She leads the engineering pods that scope, build and run client software, from mobile apps to AI systems, and she reviews the process and figures in our engineering guides for accuracy.

Resourcifi on LinkedIn →

Sources

Centers for Medicare & Medicaid Services, CMS Interoperability and Prior Authorization Final Rule CMS-0057-F (fact sheet) (Impacted payers; 72-hour and seven-day decision windows; specific denial reason; metrics by March 31, 2026; operational provisions from January 1, 2026; Prior Authorization API and other APIs by January 1, 2027; drugs excluded; ePA measure from CY 2027; X12 278 enforcement discretion; FHIR R4.0.1, US Core and recommended Da Vinci CRD, DTR and PAS guides; rule released January 17, 2024 (companion overview page); X12 278 enforcement discretion announcement corroborated on the CMS HIPAA Transaction Enforcement Discretion FAQ).
American Medical Association, 2025 AMA Prior Authorization Physician Survey (40 prior authorizations per physician per week; 13 hours of physician and staff time; 40% with dedicated staff; phone most common for medical services; 94% burnout; 92% negative clinical outcomes; 26% serious adverse event; 60% concerned AI increases denials).
KFF, Medicare Advantage Insurers Made Nearly 53 Million Prior Authorization Determinations in 2024 (52.8 million determinations in 2024; 4.1 million (7.7%) denied in full or in part; 11.5% of denials appealed; 80.7% of appeals overturned; the missing-documentation reading).
CAQH, 2025 CAQH Index Report: FHIR + Interoperability Chartbook Module (Almost 63% of medical plans developing a FHIR prior authorization API; provider readiness early; expected share of prior authorizations over FHIR for plans and providers in 2026 to 2028 (chart); top implementation barriers; drug prior authorization gap and the April 2026 CMS proposal).
HL7 International, Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide (Fax and payer portal re-keying and its data entry errors; direct submission from the EHR over FHIR; intermediary conversion to X12 278).
HL7 International, Da Vinci Documentation Templates and Rules (DTR) Implementation Guide (Computable payer documentation rules; automatic extraction of existing EHR information for review; FHIR Questionnaires with CQL; SMART on FHIR rendering; how CRD, DTR and PAS connect).
ASTP/ONC, HTI-4 Final Rule: Overview Fact Sheet (HTI-4 finalized July 31, 2025; electronic prior authorization criteria based on Da Vinci guides; request coverage requirements, assemble documentation, submit and check status).
Centers for Medicare & Medicaid Services, Frequently Asked Questions related to Coverage Criteria and Utilization Management Requirements in CMS Final Rule (CMS-4201-F) (February 2024 guidance: algorithms may assist Medicare Advantage coverage decisions, decisions must rest on the individual patient's circumstances, AI alone cannot deny an inpatient admission).
Centers for Medicare & Medicaid Services, WISeR (Wasteful and Inappropriate Service Reduction) Model (AI and machine learning with human clinical review; January 1, 2026 to December 31, 2031 in six states; licensed clinicians determine all non-payment recommendations).
Electronic Code of Federal Regulations, 45 CFR 164.502 Uses and disclosures of protected health information: General rules (Minimum necessary standard; business associate satisfactory assurances documented in a written contract; subcontractors).
Electronic Code of Federal Regulations, 45 CFR 164.312 Technical safeguards (Unique user identification; audit controls; encryption as an addressable specification).
Resourcifi, SamaCare case study (65% less effort per PA submission; three-engineer pod (one full stack developer, two data engineers); from October 2025, ongoing; eight workstreams; Playwright portal automation; AI engine fixes; LLM data dictionary; stack; 3.6% false-positive rate identified; velocity 22 to 46 story points).