Physicians complete an average of 39 prior authorization requests per week and spend 13 hours on the process (AMA Prior Authorization Survey). At a 500-bed health system, that translates to more than $250,000 in annual administrative overhead from manual processing alone based on typical PA volumes, staffing requirements (3–5 FTEs dedicated to manual PA processing), and per-transaction administrative costs before denied claims, before rework, before the staff turnover that follows sustained administrative overload.

At many health systems, this means three to five full-time staff whose entire job is processing PAs for the payers the existing tool doesn’t cover.

Most health systems reading this have already made an automation investment. The problem is that the investment was scoped against the wrong target. PA automation tools built in 2022 and 2023 were designed to replace a manual payer process. That process stopped being manual a long time ago. Payers now deploy machine learning models that issue denial decisions in seconds, evaluating diagnosis specificity, documentation patterns, treatment history, and risk indicators with no human reviewer in the loop. The health system is running an automated workflow against an automated adversary. The scorecard is not close.

This piece is about the specific architecture gap that creates that imbalance, what it actually costs, and what the health systems narrowing it are building.

Where Your Current Automation Stops

Partial ePA integrations cover as little as 31 percent of authorization work at complex health systems. The commercial tools that anchor most health system PA workflows are built for the highest-volume payers in the national market UnitedHealthcare, Aetna, Cigna, the major Blues plans. That coverage is genuine and delivers real throughput for routine commercial cases. It does not reach the specialty payers with portal-only submission requirements, the regional payers with proprietary criteria formats, or the payers whose rules change quarterly without publishing an updated API.

The cases that fall outside the ePA coverage rate are not marginal. They are disproportionately complex, disproportionately high-value, and disproportionately likely to result in a denial when processed slowly. A specialty oncology authorization that sits in a manual queue for four days while a payer’s ML system processes similar requests in seconds is not an administrative inconvenience. It is a clinical access delay and a revenue exposure at the same time.

One additional entry point the automation coverage misses entirely: in approximately 40 percent of cases, AI-assisted eligibility review can determine that authorization is not required before a PA request is even filed. The efficiency opportunity starts upstream of submission, and most existing tools are not positioned there.

This is how the problem is described inside health systems: can you build middleware for the rest without replacing Epic Systems?

Why Your Denial Rate Reflects a Documentation Problem

Payer ML denial engines in 2026 do not primarily evaluate whether care was appropriate. They evaluate whether the documentation proves it was appropriate by the specific evidentiary standards the model was trained on. 

A clinical note that accurately reflects care delivered can fail automated payer review because it uses narrative language where the model expects a structured data point, or because it omits conservative therapy documentation that the payer’s algorithm treats as a required step-therapy indicator.

The distinction matters for architecture. Building a clinical extraction layer that reads unstructured documentation and maps it to payer criteria is necessary but not sufficient. The extraction layer also needs to evaluate the documentation against the payer’s known evidentiary requirements before submission flagging gaps that correlate with denials for that specific payer and indication, not generic missing fields. This is denial risk intelligence, and it runs before the request is filed, not after the denial comes back.

The operational consequence: organizations that treat their denial rate as a submission problem are solving the wrong problem. The denial was determined at the point of documentation, not at the point of submission. The Optum deployment at Allina Health, announced in February 2026, achieved a 96 percent first-pass approval rate by addressing documentation quality at the point of clinical extraction. That is the benchmark health system revenue cycle teams are now being measured against.

Six Components Addressing a Specific Failure Mode.

The architecture that closes the payer coverage gap and addresses the documentation quality problem is a middleware layer that integrates with what is already in place and handles the cases it cannot. In current market language, this is an agentic architecture , autonomous orchestration across payer rules, clinical extraction, denial risk assessment, submission routing, and human escalation. Here is what each component does and what it protects against.

1. Payer Rules Engine

A continuously updated mapping library covering the payers outside the commercial tool’s ePA coverage. Each payer’s submission requirements, criteria formats, and documentation standards are maintained on a defined update cycle that is not dependent on a SaaS vendor’s roadmap. At complex health systems, this layer also functions as a payer criteria monitoring system tracking when payer denial algorithms shift their evidentiary patterns so the extraction and submission layers can adapt before the denial rate reflects the change.

2. Clinical Extraction Layer

NLP and LLM processing that reads unstructured clinical documentation, notes, specialist letters, imaging reports and maps evidence to payer-specific medical necessity criteria with citations for audit. Structured criteria route through the rules engine. Cases with unstructured or ambiguous documentation route through the extraction layer. The two systems are complementary, not interchangeable. An LLM-only approach introduces hallucination risk at a point where a wrong determination has clinical and legal consequences. A rules-engine-only approach fails on any documentation that does not conform to a structured format.

3. Denial Risk Intelligence

ML models trained on historical PA outcomes that evaluate each request for elevated denial risk before submission. These models identify documentation gaps that correlate with payer denials for specific drug and plan combinations, flag missing step-therapy documentation, and surface evidence types that reliably support approval for a given indication. The output is a pre-submission risk score and a specific gap list. This is the component that shifts the workflow from reactive denial management to proactive documentation optimization, which is where the first-pass approval rate improvement actually comes from.

4. Submission and Tracking Layer

Omni-channel submission covering FHIR-based ePA APIs where available, portal RPA for payers with no API access, clearinghouse routing for standard formats, and AI-assisted fax and phone-based outreach for payers that have not moved to digital submission. Active status monitoring across all channels with automated follow-up for requests that have not received a determination within the payer’s committed response window. The submission layer also feeds outcome data back to the denial risk intelligence models every approved and denied request improves the next prediction.

5. Human-in-the-Loop Routing

Intelligent triage that routes routine, high-confidence cases to straight-through processing, escalates clinical judgment calls to reviewers with pre-populated evidence packages, and routes denials directly into the appeals workflow. This component has gained a regulatory dimension in 2026: Texas, Arizona, and Maryland have passed legislation prohibiting the use of automated systems as the sole basis for a PA denial without human clinical oversight. Building compliant human review into the architecture is  a legal requirement.

6. CMS-0057-F Compliance Layer

CMS-0057-F operational requirements are not a 2027 deadline. The first public reporting requirement prior authorization metrics for calendar year 2025  was due March 31, 2026. FHIR R4 Prior Authorization API implementation and full interoperability requirements are required by January 1, 2027. Any PA system deployed now without FHIR-native data exchange, audit-ready logging at every decision point, and public metrics reporting infrastructure will require a compliance rearchitecture before the end of the year. The work to avoid that rearchitecture is shorter than the rearchitecture itself.

Architecture summary: Payer rules engine for the cases outside ePA coverage. Clinical extraction for unstructured documentation. Denial risk intelligence before submission. Omni-channel submission and tracking. Human review for clinical judgment calls and legally mandated oversight. FHIR R4 compliance embedded throughout.

What Closing the Gap Is Worth

Manual PA processing costs $10.97 per provider transaction. Fully electronic processing costs $5.79 a 47 percent reduction per the 2024 CAQH Index. On the payer side the gap is more extreme: $3.41 manual versus $0.05 automated. At a health system processing 2,000 PAs per month with a 35 percent manual processing rate on uncovered cases, the transaction cost gap alone runs $65,000 to $105,000 annually.

Denied claims add a separate cost layer. Each rework transaction averages $118. A 15 to 20 percent reduction in denial rates on complex cases the range that denial risk intelligence systems have demonstrated in production environments compounds quickly at health system PA volumes. Those are the numbers a health system CFO is now comparing against status quo performance.

Build Cost and Payback

Middleware layer build cost: $80,000 to $150,000 depending on payer count, EHR integration complexity, and whether denial risk intelligence is in scope.

Annual maintenance: $15,000 to $30,000 covering payer rules updates, portal RPA maintenance when payer interfaces change, and EHR API version management.

Payback period at health system scale: 12 to 18 months. At higher PA volumes or denial rates, shorter. The build cost is less than a platform migration and does not require decommissioning working infrastructure.

The comparison is not build versus status quo. It is build versus a payer environment that is investing in automated denial optimization while the provider side waits for a SaaS vendor roadmap update.

Buy when requirements are standardized, off-the-shelf tools cover more than 70 percent of payer scenarios, and vendor roadmaps align with compliance timelines.

Build when automation coverage drops below 70 percent, EHR workflows require middleware that vendors do not provide, and regulatory deadlines such as CMS-0057-F cannot be met through vendor timelines alone.

How Ideas2IT Builds PA Automation Middleware

Ideas2IT is an AWS GenAI Specialist Partner and HIPAA-compliant engineering firm. The engagement model is Forward Deployed Engineers, engineers who embed inside the client’s existing EHR environment from day one, working within the client’s stack, compliance architecture, and operational OKRs. For PA middleware, that distinction matters at the payer rules engine layer: the team that designed the criteria mapping needs to own the maintenance cycle post-launch. Rules drift when maintenance is handed off. A team that built the mapping and owns the update cycle is structurally less likely to fall behind quarterly payer criteria changes.

For health systems evaluating where to start, the relevant first step is understanding the actual ePA coverage rate in their specific environment which payers are outside it, what their submission requirements are, and where the denial rate is concentrated by payer and indication. Ideas2IT’s AI healthcare software development practice covers the full middleware stack: payer rules engine build and maintenance, LLM-based clinical extraction, denial risk intelligence, FHIR R4 compliance architecture, and compliance-grade QA testing across all payer integration scenarios.

‍

Engagement Reference

A regional health system with an existing Epic-based PA workflow needed to extend automation coverage to 18 specialty payers outside the ePA coverage of the existing module. The uncovered payers included three with portal-only submission requirements, seven with quarterly rules update cycles, and eight where supporting documentation was primarily unstructured clinical notes and specialist letters.

Ideas2IT built a middleware layer integrating with the existing Epic module via FHIR R4 APIs, a payer rules engine covering all 18 payers, LLM-based clinical extraction for unstructured documentation with pre-submission documentation gap flagging, and a human-in-the-loop routing system for complex cases and denial management. CMS-0057-F FHIR API compliance was scoped in from kickoff.