How to automate prior authorization with AI agents: a practical guide for healthcare operations teams

Prior authorization consumes an average of 13 staff hours per physician each week, time that comes directly at the expense of patient care. This article walks healthcare operations teams through the deployment of AI agents in healthcare to automate the prior authorization workflow end to end: from the structural reasons the manual process fails, through multi-agent architecture and EHR integration, to compliance alignment with CMS-0057-F and a practical four-phase implementation roadmap.

Key takeaways: McKinsey confirms that AI-enabled prior authorization can automate 50 to 75 percent of manual tasks; CMS mandates FHIR-based prior authorization APIs by January 2027; and operations teams that begin building now will have production-grade systems in place before the compliance window closes.

The prior authorization bottleneck is an operational, not a clinical, problem #

Prior authorization was designed as a cost-control checkpoint. In practice, it has become one of the most resource-intensive administrative processes in healthcare. According to an AMA survey of 1,000 physicians conducted in late 2024, the average practice completes 39 prior authorization requests per physician per week, with staff spending 13 hours completing them, with the IDC estimating the total cost to the US healthcare system at between $41.4 billion and $55.8 billion annually.

The scale of this burden reflects a workflow design failure, not a staffing issue. The problem is structural: payer-specific documentation requirements, no standard submission format, fragmented EHR data, and a process built around fax machines and phone queues. IDC's analysis is direct: the healthcare industry has repeatedly confused digitisation with modernisation, converting paper into PDFs without questioning the process design behind them.

AI agents in healthcare offer the first genuinely structural solution: not just another portal layer, but an autonomous system capable of redesigning the workflow itself.

How prior authorization is handled today #

Understanding the current process is a prerequisite for meaningful healthcare workflow automation. Today, a prior authorization request requires the following sequence of manual steps.

1. A staff member checks payer-specific guidelines to determine whether a PA is required for the procedure and payer combination — a step that varies by insurer and changes frequently.
2. Clinical documentation is then gathered from multiple systems: physician notes, diagnostic results, treatment history, and insurance details.
3. Staff complete payer-specific forms, each structured differently, before submitting via portal, phone, EDI, or, still common, fax.
4. The request is tracked manually, with staff following up directly with payers when responses are delayed.
5. When a denial arrives, a separate appeals workflow begins: drafting letters, compiling supporting clinical documentation, and resubmitting.

According to the AMA's 2024 survey, 93 percent of physicians report that prior authorization delays patient care, and 82 percent say it sometimes leads to treatment abandonment entirely.

This is the operational baseline that prior authorization automation is built to replace.

What AI agents do in the prior authorization workflow #

McKinsey's primary analysis confirms that AI-enabled prior authorization automation can handle 50% to 75% of manual tasks. The critical design question is which tasks map to which agent and where human oversight remains essential.

A production-grade prior authorization agent system operates across five stages.

1. A requirement check agent queries real-time payer rules to determine whether a PA is needed for the specific procedure and payer combination, eliminating manual guideline reviews entirely.
2. A documentation assembly agent connects to the EHR, pulls structured and unstructured clinical data, such as physician notes, diagnostic results, or relevant history, formats it to each payer's submission requirements, and flags missing items before the request leaves the system.
3. A submission agent sends the completed request through the appropriate channel: payer API, clearinghouse (EDI 278), or portal automation, adapting to each payer's accepted method without staff intervention.
4. A status monitoring agent checks for updates continuously, alerts staff when action is required, and surfaces exceptions rather than requiring manual follow-up on every open case.
5. When a denial arrives, the denial and appeals agent drafts appeal letters with supporting clinical documentation and logs outcomes, creating a continuous learning loop that improves approval rates over time.

Critically, none of this eliminates clinical judgment. Complex cases and edge conditions are surfaced to human reviewers. The agents handle the routine volume that currently consumes the majority of staff time. This is intelligent triage, not full automation.

Lauren Hackenberg, Senior Director of Provider Capabilities at Optum, articulated the clinical accuracy case clearly at HIMSS25: pulling clinical information directly from the EHR, rather than relying on manual entry, produces a more rigorous submission from the start. In her words:

"We would actually argue that there's more clinical rigor when we're pulling that clinical information from the EHR — versus the manual entry that goes on with prior authorization today." — Lauren Hackenberg, Senior Director of Provider Capabilities at Optum, via Surescripts

Vstorm has deployed integrated agentic systems in a live healthcare environment. A US-based provider serving more than 100,000 members used a multi-channel AI agent in healthcare to automate pre-appointment workflows, saving each doctor more than five hours per week and lifting patient engagement by more than 20 percent. You can read the full case study here.

Integration requirements and technical architecture #

For prior authorization automation to function reliably in production, three integration layers must be in place before any agent is deployed.

EHR integration is the foundation. Agents connect to the provider's EHR via HL7 FHIR R4 APIs to pull patient data without duplication or manual entry. The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) establishes FHIR as the mandatory standard for PA data exchange. Any automation built today on non-FHIR infrastructure will require rework before 2027.

Payer connectivity is the second layer. Agents must connect to payer portals or clearinghouses with sufficient coverage, meaning integration with hundreds of national and regional payers is the baseline for meaningful automation. The Da Vinci implementation guides, comprised of Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR), and Prior Authorization Support (PAS), provide the recommended technical framework for compliant PA workflows under CMS-0057-F. CMS explicitly references these guides as the preferred path for prior authorization API implementation.

Observability is the third layer, and the one most commonly overlooked at the design stage. Every agent decision must be logged, traceable, and auditable. This satisfies HIPAA requirements and provides the operational data needed to identify payer-specific denial patterns and improve agent performance over time. HIPAA compliance and SOC2 certification are design-time requirements, they cannot be retrofitted after deployment without significant rework.

Regulatory context: what CMS-0057-F means for operations teams #

CMS-0057-F, the Interoperability and Prior Authorization Final Rule, was finalised in January 2024. It applies to Medicare Advantage organisations, Medicaid Managed Care, CHIP, and Qualified Health Plan issuers on Federally Facilitated Exchanges. Three dates define the operational window.

From January 1, 2026, impacted payers must report PA metrics publicly, i.e. approval rates, denial rates, and decision timeframes, published annually on their websites. This creates accountability that was previously absent and establishes benchmarks against which all operational performance will be measured.

From January 1, 2027, full compliance with FHIR-based PA APIs is required. Decision timelines are set at 72 hours for urgent requests and seven calendar days for standard requests. CMS projects $15 billion in savings over ten years from digital PA adoption across the system.

The practical implication for operations teams is straightforward: any automation system built now should be FHIR-native. This is not future-proofing, it is avoiding a known compliance rework deadline within the current planning horizon.

From pilot to production: a practical implementation sequence #

The most common failure in healthcare workflow automation is attempting full automation before the underlying process is mapped. Teams that skip this step inherit the inefficiencies of the current manual workflow inside the agent and those inefficiencies become harder, not easier, to correct once automation is running.

A four-phase sequence aligned with Vstorm's TriStorm methodology reduces this risk and delivers measurable ROI at each stage.

Phase one: process mapping. Identify the highest-volume PA procedures and the payers generating the most manual work. This is the foundation, not the technology selection. Without it, subsequent phases automate the wrong things.

Phase two: requirement determination pilot. Deploy an agent for the single task of determining whether a PA is required for a given procedure and payer combination. This is the lowest-risk, highest-frequency decision in the PA workflow. A national imaging network using an AI-powered determination agent achieved 98.5 percent accuracy on this task alone, immediately reducing unnecessary manual work downstream.

Phase three: EHR-integrated submission. Extend the agent to pull documentation from the EHR and submit electronically for the highest-volume payers where API connectivity exists. This is where the majority of staff hour savings are realised.

Phase four: full workflow deployment. Add status monitoring and denial drafting, implement human-in-the-loop escalation routing for complex cases, and connect the observability layer. At this stage, organisations typically see positive ROI within 90 days.

Measuring what matters #

Deploying AI agents in healthcare without defined performance benchmarks is a common mistake. The following KPIs provide a practical baseline for tracking progress from initial pilot through full deployment.

Baseline figures are drawn from the AMA's 2024 prior authorization physician survey and Surescripts 2025 data brief. Target figures are indicative and will vary by payer mix, specialty, and implementation scope.

Prior authorization is solvable, not manageable #

The default position in most healthcare operations is to manage prior authorization by hiring on additional staff, distribute the load, and absorb the cost. But that approach has not worked. Practice spending on PA staffing increased 43 percent over five years while the process itself remained structurally unchanged.

Prior authorization automation does not require a large-scale transformation to deliver results. It requires a disciplined process mapping exercise, a phased deployment that starts with the highest-volume decisions, and FHIR-native architecture that positions the organisation ahead of the 2027 CMS compliance deadline. The CMS-0057-F rule has set the timeline. Healthcare workflow automation of the PA process is no longer a long-term strategic initiative, it is a near-term operational and compliance priority.

Operations teams that begin now will have production-grade AI agents in healthcare integrated with their EHR and payer systems before the mandate takes effect. Those that wait will face the same implementation work under regulatory pressure and on a shortened timeline.

Explore Vstorm's healthcare AI agent case study to see how a production-grade agentic system was deployed inside a live healthcare operation serving more than 100,000 members.