Healthcare AI Prior Authorization Automation, A Practice’s Integration Guide

Executive Takeaway and Scope

Prior authorization (PA) is a high value automation candidate for practices where volume, payer connectivity, and integration readiness support the investment. AI prior authorization is an integration problem first. Most of the value in prior authorization automation comes from workflow automation, deterministic policy rules, and interoperability. Generative AI accelerates specific steps such as extraction from clinical notes and drafting of appeal narratives.

The regulatory floor is also moving. CMS-0057-F sets operational transparency requirements taking effect in 2026 for impacted payers, and Prior Authorization API compliance dates that generally begin in 2027 and vary by payer type (CMS-0057-F fact sheet). Drugs are excluded from the current final rule. The American Medical Association (AMA)’s 2025 physician survey reports roughly 40 PA requests per physician per week and roughly 13 hours of physician plus staff time per week spent on prior authorization, with 94 percent of physicians reporting PA contributes to burnout and 26 percent reporting a PA related serious adverse event (AMA 2025 physician survey).

Who this is for

Healthcare operations leaders, RCM directors, practice managers, and health tech operators evaluating what to buy, what to build, and what to prepare for the 2027 API deadlines.

What follows

Medical benefit PA, pharmacy benefit ePA, claim denials, and payer utilization management are covered as four distinct workflows with different vendors and standards. Six practical vendor archetypes organize the market for this analysis. The CRD DTR PAS pattern from the HL7 Da Vinci implementation guides is the recommended architectural approach. buy versus build economics turn on PA volume and payer mix. A readiness gated implementation plan with exit criteria at each phase moves a program from discovery to production.

Four defensible summary points

Fig 1 – The AMA 2025 baseline beside the CMS-0057-F timeline, 2026 operational requirements and 2027 API requirements

Define the Categories, Medical PA, Pharmacy ePA, Claim Denials, Payer UM

Four workflows commonly get collapsed into one bucket labeled “prior authorization.” They are not the same. Each carries a distinct vendor set, standard, data flow, and decision authority. Buying or building for one does not solve the others.

Medical benefit prior authorization

Approval before a service is delivered under the medical benefit. Applies to imaging, surgeries, physical therapy, durable medical equipment, and other services billed on medical claims. Some clinician administered drugs, including infusions given in a clinical setting, are billed under the medical benefit, but sit outside the CMS-0057-F final rule, which excludes drugs regardless of benefit type. The provider or facility submits the request to the payer.

The standards in use are FHIR through the HL7 Da Vinci PAS implementation guide, recommended under CMS-0057-F and referenced in ONC HTI-4 certification criteria on the provider side, alongside X12 278 request and response and the legacy channels of payer portal and fax. SamaCare and Rhyme are examples of vendors that specialize here.

Pharmacy benefit ePA (electronic prior authorization)

Approval before a medication is dispensed under the pharmacy benefit. Runs through the health plan or its pharmacy benefit manager as decisioning authority and pharmacies as fulfillment.

The primary standard is NCPDP SCRIPT, specifically the ePA transaction set between prescribers, PBMs, and pharmacies, though portal, fax, and phone workflows still exist alongside it. CoverMyMeds and Surescripts are the major standards based networks. Infrastructure, EHR vendors, clearinghouses, and orchestration layers can overlap with medical PA even where the transaction standards and decision paths differ.

This workflow is architecturally distinct from medical PA and requires a different integration path, typically via the EHR eRx module.

Claim denials

Denials issued by the payer after the claim is submitted. These are separate from prior authorization events, and they frequently get conflated with prior authorization in vendor pitches and industry commentary. The denials workflow spans claim scrubbing, denial routing, root cause analysis, and appeal generation, and different vendors specialize in different pieces of it.

Some prior auth failures cascade into claim denials later, which is where the workflows connect operationally, but the systems and vendors are distinct.

Payer utilization management (UM)

The payer side function that evaluates submitted PA requests against clinical criteria and issues determinations. UM staff mix varies by plan and case category. Automated determinations run against pre approved rules for clean cases, while more complex cases route to nurses, other qualified reviewers, or physician reviewers per plan rules.

UM platforms are primarily licensed by payers. Provider sponsored health plans, delegated risk organizations, and health systems that operate their own utilization review functions may also license them. Independent physician practices generally integrate with UM through the interfaces payers expose.

Why the separation matters

A vendor demo that shows “we handle prior authorization” is answering across all four categories only when the vendor holds capabilities in each, which most do not.

The reliable distinction runs along medical benefit versus pharmacy benefit. A distinction drawn along service versus medication will misclassify cases. A pharmacy ePA network does not handle medical benefit imaging. A specialty PA vendor may or may not handle medication PAs, depending on whether the drugs are billed under the medical benefit or the pharmacy benefit; SamaCare, for instance, focuses on medical benefit drug prior authorization. A denials management tool does not prevent PA denials, it processes them after the fact. Products, EHRs, clearinghouses, and orchestration platforms can span more than one workflow even where the transactions and decision paths differ.

Reading a demo through the four category lens above filters most vendor overreach in the first meeting.

Fig 2 – Medical benefit PA and pharmacy ePA rest on different transaction bases, which is why they stay separate workflows

Terminology

A compact glossary for the acronyms used throughout this piece.

Table 1 – Terms used throughout this playbook

Baseline Volume and Economics

Before evaluating vendors, evaluate your own numbers. The vendor conversation gets shaped by what you already know about your PA volume, your payer mix, your clean case rate, and where your staff time actually goes.

The industry baseline

The AMA’s 2025 physician survey is the industry reference for physician reported PA burden. It is a self reported cross sectional survey of roughly 1,000 practicing physicians, useful as a directional national reference for physician reported PA burden and not an operational floor every practice should expect to match. The four numbers below are what practices commonly measure their own operations against.

• Roughly 40 PA requests per physician per week
• Roughly 13 hours of physician plus staff time per week spent on prior authorization
• 94 percent of physicians report PA contributes to physician burnout
• 26 percent report the process has led to a serious adverse event for a patient in their care

These numbers frame what every practice should measure its own operations against.

The metrics your own model needs

Before the math on buy versus build runs on anything, the last twelve months of practice data has to be captured across four dimensions, and skipping any one of them means the model lies. What follows is what to pull for each.

Volume and mix

Start with annual PA volume, then break it into medical benefit PA versus pharmacy benefit ePA share. Sort by payer contribution and by service, procedure, or drug. Track the share of eligibility checks that surface a no PA required result. That volume still touches eligibility and coverage discovery, and it avoids the preparation and submission workload, so it changes the buy versus build math when you count it. Note seasonal peaks and expected volume growth so the ROI is not calibrated to a low quarter.

Case flow

Clean case percentage sits at the top of case flow, meaning the share submitted the first time without additional documentation. Alongside it, track requests for additional information from payers per submission, the human touch percentage that requires clinician or staff intervention, and average handling time by case type. Payer connectivity coverage is the fifth number that matters. Which of your payers already support X12 278 or FHIR PAS shapes how much of your volume can automate cleanly. Connectivity alone does not decide automation coverage. Documentation quality, supported service categories, payer policy digitization, and EHR integration depth all move that ceiling too.

Outcomes

Approval rate before appeal and approval rate after appeal give the pass through picture. Denial volume and appeal volume against denials tell you where the friction sits. Abandoned treatment and scheduling fallout are clinically important signals worth tracking alongside the ROI numbers. Attribution to PA delays specifically is difficult, so keep them separate from hard dollar ROI unless the organization has a defensible attribution method. Patient wait time breaks into three latency segments worth measuring on their own, from clinical order to submission, from payer receipt to decision, and from approval to delivered service.

Cost and effort

Fully loaded staff cost by role, per hour, is the direct labor figure. Clinician interruption time per week, covering peer to peer reviews, escalations, and urgent authorization requests, is the hidden labor figure. Both belong in the ROI baseline because a vendor comparison that only counts staff hours misses where the specialty time actually goes.

Why this matters before the vendor call

A vendor that shows you a 40 percent reduction in handling time cannot commit to that outcome without knowing what your handling time looks like today. A vendor that quotes a per submission price cannot be evaluated without your submission volume. A vendor that promises straight through processing cannot deliver it on payers whose systems only support fax and portal.

The buyer who walks in with the metrics above has vendor conversations that stay grounded.

What the ROI math actually looks like

Annual Total Cost of Ownership (TCO) is the right frame for the cost side of the ROI question because a headline license fee hides where PA money actually goes. TCO covers costs only. Benefits and savings sit in a separate annual benefit calculation on top of it, and net benefit is annual benefits minus annual TCO.

Cost side, annual

Year one implementation cost, amortized when the evaluation runs on a multi year TCO, sits on top of recurring vendor license fees and per transaction fees. Add cloud infrastructure and integration hosting, ongoing support and maintenance, and the retained staff cost for the human touch portion of the workflow. Exception and appeal handling cost is a line worth pulling out explicitly. Different vendor pitches denominate it differently, and once it is on the same basis across candidates, it can change the relative economics of the shortlist.

Value side, annual

Hard dollar savings from reduced staff hours materialize only when the hours reduce overtime, contractor spend, headcount, or future hiring; for salaried staff whose hours simply free up, the value is capacity. Reallocated staff capacity becomes available for other work, which is real value even when it does not show up as a savings line on the P&L. Revenue protected through fewer PA related claim denials downstream is the closest thing to a direct financial return. Cost avoided from fewer delayed or abandoned care events accrues most often to the patient, payer, or broader system. The practice’s P&L rarely captures it. Count it in a practice ROI only where the practice can demonstrate financial exposure, such as risk based contracting or measurable incremental contribution margin. Do not double count the same freed hours as both reduced staff expense and reallocated capacity value; each hour goes into only one line.

Three cost per PA measures

Table 2 – The 3 cost per PA measures and what each one answers

One denominator sometimes chosen for headline vendor comparisons is cost per approved request, which flatters the vendor by excluding effort spent on cases that never resolve.

Run the math against three scenarios

Three volume scenarios keep the math honest. Current is the actual PA volume today. Low is the last twelve months’ minimum quarterly volume annualized. High is the peak quarterly volume annualized plus expected growth. Run each through the same buy versus build math, and the answer that holds across all three is the one worth acting on.

Three scenarios frame the decision under uncertainty better than a single point estimate does.

What Changed in 2026, and What Changes in 2027

The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F), finalized in January 2024, established a phased set of requirements for impacted payers.

Who is impacted

The rule applies to Medicare Advantage organizations, state Medicaid and CHIP fee for service programs, Medicaid and CHIP managed care plans, and QHP issuers on federally facilitated exchanges.

The requirements land in two waves.

Wave one, effective in 2026

The CMS-0057-F fact sheet lays out operational requirements aimed at transparency and decision timelines. These take effect for impacted payers in 2026, ahead of the API build that arrives in 2027, and they change the shape of provider workflows immediately even before a single line of API code ships.

• Denial reasons – Impacted payers must provide a specific reason for prior authorization denials.
• Decision timeframes – Payers must return prior authorization decisions within a maximum of 72 hours for expedited requests and within 7 calendar days for standard requests. These are maximum windows. Payers must decide sooner when the patient’s condition requires it, and extensions may be available under program specific conditions. QHP issuers on federally facilitated exchanges are excluded from these decision timeframe requirements in the current final rule.
• Public metrics reporting – Impacted payers must publicly report aggregate metrics on prior authorization, including approval rates, denial rates, average decision times, and appeal outcomes.

These are operational rules that land on the payer side. Providers see the effect in changed payer behavior on their existing PA workflow. A payer that must return denials with specific reasons gives your appeal workflow better inputs than it had in 2024.

Wave two, compliance dates generally beginning in 2027

The 2027 wave sets technical API requirements built on FHIR. This is where CMS-0057-F becomes an engineering deliverable on the payer side, on top of the operational rules that landed in wave one. It is also where the integration surface starts to move from bespoke X12 278 mappings and portal and fax fallbacks toward a standard FHIR path.

• Prior Authorization API – Impacted payers must expose a FHIR prior authorization API that supports the PA request and response lifecycle. CMS-0057-F strongly encourages the HL7 Da Vinci CRD, DTR, and PAS implementation guides for this API and the associated workflows, though it does not require a specific implementation guide. The final rule does not mandate a specific implementation guide.
• Patient Access API and Provider Access API – These are treated distinctly under the rule. The existing Patient Access API is expanded to include certain prior authorization information. Provider Access is a new required API that shares claims, encounters, USCDI data, and specified prior authorization information.
• Payer to payer data exchange – This was extended to include prior authorization information for members transitioning between plans. Drugs and denied prior authorizations are excluded from the payer to payer exchange requirements.

The 2027 wave is what actually changes provider architecture. When a critical mass of impacted payers exposes a FHIR based PA API, the integration surface can shift from bespoke X12 278 mappings plus fax and portal fallbacks toward a standard FHIR path. The extent to which the resulting integration is cheaper and more maintainable depends on how consistently payers implement the recommended guides and on the tools available on the provider side to consume them.

What is not in the rule

Drugs are excluded from CMS-0057-F. CMS does not prohibit payers from voluntarily including drug workflows in the same APIs, so some payers may extend coverage on their own. A separate proposed rule (CMS-0062-P) announced in 2026 would extend prior authorization requirements to certain drug workflows, with medical benefit drug support proposed via FHIR APIs and pharmacy benefit support via NCPDP SCRIPT, Formulary & Benefit, and Real-Time Prescription Benefit (RTPB) standards, but that rule remains proposed and not final as of this writing (CMS interoperability FAQs). Pharmacy benefit ePA continues to run over NCPDP SCRIPT and its associated networks.

Who has to build what

CMS-0057-F applies directly to impacted payers. Ordinary provider practices do not carry the payer API implementation deadline.

Providers may have related 2027 reporting or attestation obligations through MIPS and the Promoting Interoperability program, and providers who work with impacted payers benefit from preparing the integration surface on their side of the wire. The payer deadline itself remains a payer deadline.

What providers should be doing in 2026

1. Test denial capture – Confirm your current PA workflow captures denial reasons in a structured way. The 2026 rule gives you better inputs. Your workflow needs to use them.
2. Measure decision times – Baseline your decision times against payer performance. Public metrics let you compare your experience to plan level averages.
3. Inventory payer connectivity by transport – Which use X12 278 through your clearinghouse, which require portal login, which still require fax, which already expose FHIR endpoints. That inventory is what your 2027 FHIR readiness assessment builds on.
4. Plan the FHIR PAS integration – Vendor selection and internal build decisions on FHIR PA APIs should be scoped in 2026 and delivered through 2027 as impacted payers stand up their APIs.

Fig 3 – CMS-0057-F arrives in two waves: payer operational requirements in 2026 and payer API requirements generally beginning in 2027. Provider organizations should use 2026 to improve denial capture, measure decision times, inventory connectivity, and prepare their integration surface

_{Scope note. CMS-0057-F applies directly to impacted payers; ordinary provider practices do not carry the payer API implementation deadline. QHP issuers on federally facilitated exchanges are excluded from the 72 hour and 7 calendar day decision time requirements. Drugs are excluded from the current final rule, although payers may include drug workflows voluntarily. Denied prior authorizations are excluded from the payer to payer exchange requirement. API compliance dates generally begin in 2027 and vary by payer type. CMS strongly encourages CRD, DTR, and PAS but does not mandate a specific implementation guide.}

Prior Authorization AI Vendors, 6 Archetypes

For evaluation purposes, the market can be divided into six practical categories. Vendors in different categories are not interchangeable. Compare within the category that fits the workflow you are trying to change.

Table 3 – The 6 vendor archetypes and the buyer each one fits

Notes on specific vendors that get frequently misrepresented

CoverMyMeds

The direct ePA service is free to providers and pharmacists. Supported through partnerships with health plans, PBMs, and pharmaceutical manufacturers. EHR vendors may still impose integration or module costs on top of the direct service (CoverMyMeds pricing FAQ).

Do not include a provider or pharmacy subscription line item in your budget for the direct CoverMyMeds ePA service, though EHR integration and module costs may still apply.

Availity AuthAI

Availity describes AuthAI as a recommendation engine that provides policy aligned recommendations to speed the PA process. It does not approve or deny requests. Approval and denial authority remains with the payer’s UM process (Availity Intelligentum page).

Abridge Real-time Prior Authorization

Announced in August 2025 as a collaboration between Abridge, Highmark Health, and Allegheny Health Network (Abridge and Highmark announcement). Clinicians review AI generated recommendations before submission.

The announcement describes a payer and provider collaboration. It does not describe a generally available product. Its enduring 2026 availability status was not established by the initial announcement and should be confirmed with the vendors before treating it as buyable off the shelf.

athenahealth PA workflow

Athenahealth reports a decrease in time spent on the prior authorization process of 45 percent using its AI features, as a vendor reported customer outcome (athenahealth blog).

Treat as one vendor’s stated result for its own customers. It is not an independent industry benchmark.

MCG, InterQual, and XSOLIS

These are not interchangeable products.

• MCG and InterQual publish clinical criteria and decision support content licensed by many payers and used by some health systems in their own utilization review.
• XSOLIS provides utilization review analytics and concurrent authorization support to both payers and health systems.

Evaluate each on the specific criteria coverage, decision support depth, and integration surface it offers. Different vendors serve different case profiles across the six archetype framework.

How to read the table

Read the archetype column first. Establish which one your workflow fits before comparing vendors.

A specialty practice with high infusion volume shortlists provider selected workflow tools first. A primary care practice with high medication volume shortlists pharmacy ePA networks after assessing existing EHR or eRx access, since pharmacy ePA typically flows through the eRx module. Provider workflow tools remain for the medical benefit slice. A practice standardized on a single EHR with a native PA module shortlists that module first. An RCM operation across many practices and payers looks at clearinghouse platforms first.

Fig 4 – Start with the vendor archetype that matches the workflow being changed, then compare products within that category. The marks shown are representative examples. They do not constitute rankings or endorsements

_{Vendor and pricing note. Other examples in the six categories include Rhyme; InterQual and XSOLIS; Surescripts; Waystar and Change Healthcare; and eClinicalWorks, Epic Payer Platform, and the Abridge payer provider collaboration. Categories can overlap, and capabilities, connectivity, availability, and commercial terms can change. Pricing is contract specific unless stated otherwise. CoverMyMeds describes its direct electronic prior authorization service as free to providers and pharmacists; EHR integration or module costs may still apply. Confirm current scope and terms with each vendor.}

CRD, DTR, PAS, and the Legacy Channel Architecture

Prior authorization AI is not a single model making a decision. It is an integration stack that combines:

The stack has coordinated layers that fit together. Deterministic policy rules sit at the base, with payer policy as the authoritative source and the rules engine as its deterministic implementation. Three coordinated FHIR implementation guides (CRD, DTR, PAS) carry the modern payer workflow. Extraction from clinical notes pulls the evidence the criteria need, and human review handles the cases that criteria do not cleanly cover. Legacy transport catches payers that have not moved to FHIR yet. Each is treated in detail below.

The stack, layer by layer

1. Deterministic coverage and policy rules – Payer criteria applied through rule engines. Some payers now publish criteria in machine consumable form. Many still publish only as PDFs or portal content, which requires ingestion and mapping before rules can execute. Payer policy remains the source of truth.
2. CRD (Coverage Requirements Discovery) – The Da Vinci workflow that answers whether prior authorization is required for a specific service on a specific member’s plan, before the practice invests any effort in preparing a request.
3. DTR (Documentation Templates and Rules) – The Da Vinci workflow that surfaces payer specific questionnaires, executes their rules against clinical data, and collects the documentation the payer needs to support the PA request. AI extraction from clinical notes commonly plugs in here to prefill the questionnaires.
4. PAS (Prior Authorization Support) – The Da Vinci workflow that carries the request and response between provider and payer systems over FHIR.
5. NLP or LLM extraction from clinical notes – Pulls the specific clinical evidence DTR requests from encounter documentation, discharge summaries, prior imaging reports, and problem lists.
6. Document classification and OCR – For attachments (prior imaging PDFs, external records, faxed prior authorizations from referring providers) that need to reach the payer as structured or reviewed evidence. Attachments in FHIR terms are carried in DocumentReference, Binary, and attachment elements within other resources.
7. Workflow orchestration – The queue, escalation, retry, and human handoff logic that sits above the earlier layers.
8. Provider side clinical and administrative review – Clinical staff and clinicians reviewing the assembled package before submission where policy requires it, or where the case falls outside a defined auto submission slice. This is separate from payer side utilization management, which is covered in the next section.
9. Payer decisioning – The payer’s UM function makes the actual determination. AI vendors on the provider side prepare and submit. Approval and denial authority stays with the payer.

The three Da Vinci workflows are not a strictly linear pipeline. CRD can return no authorization required, conditional results, or an already satisfied authorization. DTR is invoked only when documentation gathering is necessary. PAS can be implemented without every preceding component invoked in every transaction. Treat them as coordinated capabilities. They do not run as fixed sequence steps.

FHIR resources typically required

A production build touches more of the FHIR spec than a demo suggests. Depending on workflow, the resources involved commonly include Coverage, ServiceRequest, Practitioner, Organization, Observation, Condition, MedicationRequest, DiagnosticReport, Procedure, Encounter, DocumentReference, Binary, Questionnaire, QuestionnaireResponse, and the PAS Claim and ClaimResponse structures. MedicationRequest applies to voluntarily supported drug workflows or implementations that go beyond the CMS-0057-F minimum, since drugs are excluded from the final rule requirement.

An integration limited to Patient, Encounter, Condition, and MedicationRequest handles only a narrow slice of the workflow.

Legacy channels remain a real part of the architecture

Table 4 – Submission channels and what each one allows automation to do

The architecture that survives production ingests responses from every channel your payers actually use, normalizes them into a common internal decision state, and writes them into the same audit surface.

Do not assume machine consumable responses from any channel that is not explicitly FHIR PAS or X12 278.

Payer response types beyond a simple approve or deny

Payer responses in production include several states beyond the three shown in most vendor demos:

Payer responses come in more shapes than approval or denial. Approvals with modifications land approved for a shorter duration, a different quantity, or a different site of service. Requests for additional information stall the case until the ordering practice responds. Partial approvals cover a subset of the requested services and force a separate decision on the rest. Administrative closures happen when the request lapses without a clinical determination. Authorization modifications after initial approval and authorization expirations before the service is delivered are the two variants that catch practices unprepared most often.

Design the response ingestion parser to recognize and route all of these states, preserving the original payer response and reason codes.

Where AI actually sits

AI’s role in this stack is to accelerate the parts of the workflow that involve reading, extracting, drafting, or routing.

• Coverage rules and payer policy remain deterministic sources of truth.
• Payer decisions stay with the payer.
• Human review remains for cases the criteria do not clearly cover, for policy required attestations, and for submissions that fall outside the practice’s defined auto submission slice.

Fig 5 – A common Da Vinci prior authorization pattern coordinates coverage requirement discovery, conditional documentation gathering, and electronic submission while current X12 278, portal, and manual channels continue in parallel

_{Architecture and standards note. CMS-0057-F strongly encourages CRD, DTR, and PAS but does not mandate a specific implementation guide. The components are not a compulsory linear pipeline: CRD can return no authorization required, DTR is used when documentation gathering is needed, and PAS can operate without every preceding component. AI can assist extraction, drafting, and routing; the payer remains the decision maker. Standards names identify the referenced specifications and do not imply endorsement. HL7 and FHIR are registered trademarks of Health Level Seven International.}

Human Decision Rights and Governance

The question of who decides what runs through every serious PA workflow discussion. Three parties hold decision authority in different parts of the loop. AI vendors on the provider side operate within the boundaries those three parties set.

Who decides what

The payer decides whether to approve or deny. That authority is contractual, sitting in the health plan’s medical policy, and regulatory, sitting in state and federal insurance law and CMS requirements. Payer auto approval on clean cases is a genuine automated determination executed under payer approved rules, and provider side vendors do not carry approval authority on behalf of the payer.

The ordering clinician decides what to request and how to characterize medical necessity. The clinical judgment behind a PA request stays with the clinician who ordered the service. AI can prepare a package that reflects the clinical evidence in the record, and clinician confirmation requirements vary by workflow. Some routine submissions are completed by authorized staff under practice policy. Complex cases and non standard requests route to the ordering clinician for review before submission.

The provider organization decides its own operational thresholds. That covers which cases go straight to submission after automated preparation, which go to staff review, which go to clinician review, and which trigger an outreach to the payer for pre submission clarification. Those thresholds are calibration decisions, and they need to be validated against the provider’s own case mix and against payer requirements.

Peer to peer reviews and who participates

Peer to peer eligibility, timing, and required participant vary by payer and by state law.

Peer to peer policies vary in two ways that shape the workflow. Some payers allow peer to peer before a formal denial, and others only after. Some require the ordering physician on the call, and others accept another physician in the same practice or a qualified reviewer designated by the practice.

AI should not substitute for a credentialed clinician where the payer requires clinician participation. AI can prepare the physician’s brief with:

• The payer’s stated rationale (when a denial has been issued)
• The relevant clinical evidence from the record
• The specific clinical criteria that support the appeal

The clinician participates in the call directly.

Governance for AI in this loop

An AI system operating inside a PA workflow needs a governance loop that runs independently of daily submission traffic.

1. Policy update – When a payer publishes updated criteria, the criteria library updates first. AI extraction and submission behavior updates only after the criteria change is validated.
2. Validation – A change to the model, the prompt, the criteria mapping, or the confidence threshold runs in offline evaluation on a curated set of historical cases before it touches production. Validation metrics are calculated against reviewer confirmed labels for the specific extraction or classification task. Payer approval outcomes are not a valid ground truth label for model correctness, since approval reflects payer rules applied to the submission and does not measure extraction accuracy.
3. Approval – A named clinical or compliance reviewer approves the change against the offline evaluation results.
4. Versioning – Each approved change gets a version identifier that flows into the audit surface for every subsequent submission.
5. Monitoring – Precision and recall on the specific classification or extraction tasks, denial rate trending, appeal overturn rate, and unsupported evidence rate all track after release. Drift in any of these against the pre release baseline triggers investigation.
6. Rollback – A tested and time bounded rollback and recovery process is in place. Rollback readiness is validated periodically.

Additional governance coverage that belongs in the loop

The six step loop above is the skeleton. What follows is the coverage floor. Each control prevents a specific failure mode, leaves an audit trail a reviewer can inspect, and belongs in the design from day one.

• Unsupported or hallucinated clinical evidence – Extracted claims are traceable to a source note reference and reviewed before submission on any case above a defined risk threshold.
• Source note citations – Every AI extracted or generated clinical field in the submission carries a pointer to the specific source in the record from which it was drawn. Administrative or calculated fields may have different provenance.
• Human overrides – Overrides by staff or clinicians are logged with the override reason and feed into the review cycle.
• PHI minimization – Only the PHI required for the specific PA is sent to the model provider. Everything else stays behind the extraction boundary.
• Prompt and output retention – HIPAA audit controls require mechanisms to record and examine activity in systems containing ePHI, and that requirement does not extend to retaining every full prompt and model output. Retention is risk based and follows organizational policy, and it may use metadata, identifiers, access logs, hashes, or selected content instead of full clinical text. Access to whatever is retained is logged.
• Model provider changes – A model version change from the model provider triggers offline re evaluation before production submission behavior shifts.
• Incident response – Documented process for what happens when a submission goes wrong, who notifies the payer, and how the audit surface supports the remediation.
• Fairness across patient groups and payers – Monitor for patterns in denial or delay rates by patient demographic and by payer where sample sizes are adequate, lawful access to the underlying attributes exists, and appropriate risk adjustment is applied. Different denial rates across payers can reflect payer policy or case mix as much as model drift or upstream bias, so treat patterns as questions to investigate. A pattern on its own is not a conclusion.

One anti pattern to avoid

Payer policy stays the source of truth for model behavior.

A model that learns “we tried this and got denied last month, so submit something different this month” drifts away from the payer’s own criteria and toward correlations in prior denial noise. Feedback loops on production PA belong in the criteria update process (with human review) and in the audit surface (for analysis). They do not belong in continuous model retraining on denial outcomes.

Fig 6 – Payers, treating clinicians, and provider organizations retain different decision rights. AI can support evidence extraction, submission drafting, exception routing, and response tracking without inheriting clinical, coverage, or governance authority

_{Authority note. A payer may automate determinations under payer approved policy and controls; that does not transfer approval authority to a provider side AI system. Clinical rationale and attestations remain the treating clinician’s responsibility, while the provider organization governs submission workflows, automation boundaries, workflow overrides, rollback, and audit access.}

Volume Based Buy, Build, and Hybrid Economics

The buy versus build decision on PA is an architectural decision that also carries an economic envelope.

Engineering fit factors decide fit. Volume, payer mix, and case flow decide envelope.

Engineering fit factors, in the order they should be evaluated

The order matters because an unstable workload character makes every other factor answer differently, and a stable one lets you move through the rest quickly. Work through the four below in sequence.

1. Workload character and stability – Which of medical benefit PA, pharmacy benefit ePA, and hybrid cases dominates your workload sets the starting position for buy versus build. A single dominant category with stable workflow maps cleanly to one vendor archetype. A balanced or shifting mix usually means a stack of vendors, or a custom orchestration layer that ties archetypes together. Payer criteria evolve, specialty mix and service lines may shift, and value based care contracts change what gets prior authorized and how. A stable environment favors buy. An evolving environment favors build or hybrid.
2. Training data provenance and shared responsibility – For any AI component involved, the data used to train and evaluate it must be documented, auditable, and legally usable for the intended purpose. Buying from a vendor creates a shared responsibility relationship with vendor due diligence obligations, and buying does not transfer legal or compliance responsibility to the vendor. Building keeps documentation in house, which is easier to explain to auditors when the data governance can support it.
3. Architectural control and integration depth – A vendor holds the workflow logic, the model versioning, and often the audit surface itself. Custom builds keep those under your control. HIPAA does not require the audit surface to reside inside the provider’s own infrastructure, and many regulated deployments still choose that arrangement for control and evidence purposes. Integration depth is the other half. When the PA system needs deep hooks into the EHR, the practice management system, the quality register, the billing system, the clearinghouse, and the ambient scribe, that pushes toward build or hybrid. Bounded integration favors buy.
4. Governance discipline and support capacity – The rollback, versioning, monitoring, and shadow evaluation discipline described in the previous section is where vendor offerings vary most, and practices with mature governance requirements often build to hold that discipline in house. Support and maintenance capacity is the counterweight. Custom systems require sustained engineering attention for criteria updates, payer connectivity changes, model refresh, and monitoring. Buying transfers most of that to the vendor. Building requires named engineering owners on the practice or health system side over the life of the system.

Only after those four factors is the shortlist narrowed. Volume and cost then decide envelope.

Break even, expressed as a formula

That formula gives a positive break even volume when the numerator and denominator have the same sign. The typical case has both positive, meaning custom fixed cost exceeds vendor fixed cost and vendor variable cost per PA exceeds custom variable cost per PA. The reverse case, both negative, also yields a positive crossover but with the buy/build advantage inverted. If numerator and denominator have opposite signs, the formula returns a negative volume and no positive break even exists. A zero denominator (vendor and custom variable costs equal) produces no finite crossover unless fixed costs are also equal, in which case the two paths are cost equivalent at every volume. The model also assumes linear variable costs on both sides; vendor pricing may include minimums, tiers, usage bands, volume discounts, or outcome based components, and under those structures one clean break even may not exist. Automation coverage and exception handling belong inside the variable unit costs on both sides. They do not belong in separate line items added after the fact. Adjust for the six inputs below before treating any specific number as a recommendation.

• Vendor fixed fees (minimums, license floors, implementation cost amortized annually)
• Custom system ongoing support and maintenance cost
• Automation coverage percentage on your specific payer and service mix
• Human exception handling cost per case
• Payer connectivity coverage (higher coverage on either path reduces exception cost)
• Three year implementation risk and cost of capital

Run the calculation against both hard dollar savings and reallocated staff capacity, since a program can pay back on either dimension.

Illustrative Volume Scenarios Only

The following scenarios are for planning conversation only. The volume bands are illustrative. They are not benchmarked recommendations, and the underlying vendor fixed fee, vendor per PA fee, custom fixed cost, custom per PA cost, human touch rate, and automation coverage assumptions that produce them are not published here. Real break even for a specific practice depends on the four engineering fit factors above, the six adjustment inputs, and the practice’s actual payer contracts.

Table 5 – Illustrative volume bands and the factors that move the decision

Cost envelope for the Clixlogix services line, illustrative

The following ranges are illustrative planning estimates calculated at Clixlogix’s hourly rates. They represent scope archetypes for planning use and are not case data from specific completed engagements. Vendor licenses, cloud infrastructure, EHR API fees, security assessments, and internal practice labor show as separate line items in every real budget.

Table 6 – Illustrative engineering scope and effort by deliverable

Two formulas that the buy versus build math actually needs

Costs only. Savings and protected revenue do not belong in this line.

Reallocated capacity counts only to the extent the practice can actually avoid hiring, reduce overtime, or generate additional revenue with the freed time.

Annual net benefit divides by an annual investment measure; multi year net benefit divides by a multi year investment measure. When initial implementation investment is the denominator, exclude its amortization from the net benefit numerator so the implementation cost is not counted twice. Initial implementation investment, single year TCO, and multi year TCO each answer a different question, so state which denominator (and which horizon) the reported ROI uses.

Calculated before that implementation investment is amortized into TCO, so the same dollars are not counted in both numerator and denominator.

Track separately as cost per submitted request, cost per resolved request, and cost per approved request.

Run these formulas against three volume scenarios (current, low, high) and against the payer connectivity coverage you actually have today. Three scenarios frame the decision under uncertainty better than a single point estimate does.

Fig 7 – Volume changes how fixed costs are recovered, but it does not create a universal buy versus build threshold. The chart shows illustrative linear cost shapes only; replace them with actual vendor quotes, implementation estimates, payer connectivity, automation coverage, and human touch assumptions

_{Break even and rate note. The illustrated crossover uses Q* = (custom fixed cost − vendor fixed cost) ÷ (vendor variable cost per PA − custom variable cost per PA). A positive finite crossover requires a nonzero denominator and numerator and denominator with the same sign. If both signs reverse, the direction of the cost advantage reverses. A zero denominator produces no finite crossover unless fixed costs are also equal, in which case the two linear paths are cost equivalent at every volume. Nonlinear or tiered vendor pricing can produce no single clean crossover. The Clixlogix engineering services rate of $25 to $50 per hour belongs only in the custom implementation and maintenance estimate; it is not a practice labor cost benchmark.}

Readiness Gated Implementation Plan

Calendar week plans imply false certainty. A more defensible model is a phased plan with exit criteria at each gate. Move to the next phase only when the exit criteria of the previous phase are met.

Five phases with their gates.

Phase 1. Discovery and readiness assessment

Discovery is where the plan gets grounded in the practice’s own data. Before any vendor is shortlisted or any FHIR client is written, the current volume, payer mix, and connectivity have to be captured against the metrics from the Baseline Volume section. The exit criteria below are the receipts that discovery actually happened.

Exit criteria for moving to Phase 2:

• The metrics from the Baseline Volume section are collected from your last 12 months
• Vendor archetype shortlist is complete against the six category framework
• FHIR PA API readiness of your major payers is inventoried
• A named clinical or compliance reviewer is in place for the governance loop
• Payer connectivity coverage target is defined against your specific payer mix. There is no universal percentage; the target is what makes the pilot economically viable given the payers you actually use.

Typical duration: 2 to 6 weeks for a mid size practice with existing data availability. Discovery may run longer if the metrics require new data collection or if payer connectivity requires clarification from clearinghouse partners.

Phase 2. Integration and technical build

Integration is where the path chosen in discovery becomes running code, configured payer connections, and a working audit surface. The exit criteria below draw the line between a demo that runs in a sandbox and a system that can carry real payer traffic once shadow mode starts.

Exit criteria for moving to Phase 3:

• The chosen vendor or custom build is integrated with the EHR for the specific subset of FHIR resources from the CRD DTR PAS architecture section that this practice’s PA workflow actually needs
• Payer connectivity is established for the payer set defined in Phase 1
• The audit surface is stood up in the location decided during discovery (vendor hosted, practice hosted, or hybrid, depending on control and evidence requirements)
• Rollback capability is tested end to end

Typical duration: 6 to 12 weeks. Duration is driven primarily by EHR developer program onboarding and sandbox provisioning timelines, which vary substantially by EHR vendor, by the specific product tier, and by the practice’s existing relationship with the vendor. Confirm current onboarding steps with each vendor’s developer portal before committing to a Phase 2 timeline.

Phase 3. Shadow mode

Shadow mode runs the new system in parallel with the existing workflow, without touching a real submission. It is the last window to catch failure modes before payer facing traffic starts. The exit criteria below force the shadow to match production behavior across a real cross section of cases, and to be reviewed daily against the current workflow.

Exit criteria for moving to Phase 4:

• The AI runs on every in scope PA in parallel with the current process, without submitting. If medical benefit PA and pharmacy benefit ePA remain separate workstreams, each has its own shadow
• Daily disagreement review is running against a defined sample
• Critical field extraction accuracy meets a target defined for your specific case mix and payer set
• Unsupported evidence rate stays below a defined threshold
• Missing document rate stays below a defined threshold
• A simulated criteria change control exercise runs through validation, approval, versioning, and monitoring. A live criteria update may not happen inside the observation window, so a controlled exercise substitutes to prove the loop works.

Typical duration: 2 to 6 weeks. Longer for specialties with higher case variability. Aggregate agreement with staff decisions is one signal only. It is not a sufficient gate on its own, since staff are not automatic ground truth and aggregate numbers hide class imbalance.

Phase 4. Assisted submission

Assisted submission is where humans stay in the loop on every case, and the system prepares the package for staff or clinician review. The exit criteria below establish that the assisted output is measurably better than baseline on clean submission and denial rates, and that reviewers trust it enough to hold pace with volume.

Exit criteria for moving to Phase 5:

• AI prepares submission packages that staff reviews and submits
• Time saved per PA is measured against baseline and meets your target
• Clean submission rate on AI prepared packages holds steady or improves against baseline, compared like for like on payer mix and case mix over a sufficient case count
• Denial rate holds steady or improves against baseline, compared like for like on payer mix and case mix over a sufficient case count
• Request for additional information rate stays flat or drops
• Staff override rate is captured and reviewed weekly
• Human review queue is scoped for realistic staff throughput based on shadow mode arrival patterns

Typical duration: 4 to 8 weeks.

Phase 5. Narrow production auto submission

Narrow production is the first slice where the system submits without human review, and only on a tightly bounded allowlist of cases. The exit criteria below make sure the slice stays narrow, its performance is watched daily by payer and service category, and rollback still works end to end.

Exit criteria for expanding:

• An allowlist governs which cases are eligible for auto submission. Allowlist criteria include single payer, single service or service category, deterministic completeness checks passed, no critical extraction errors flagged, and case eligibility validated against payer policy.
• At least two weeks of daily monitoring, over a case count sufficient to detect meaningful change, show first pass approval rate at or above baseline for the slice, compared like for like on payer mix and case mix
• Performance by payer and service category tracks separately, with any category level regression triggering pause

Typical duration before expansion: 2 to 4 weeks per additional slice.

Expansion

Additional payers, services, and case categories move into auto submission one slice at a time, with the same monitoring and exit criteria. Full deployment across a mid size practice’s PA volume completes 6 to 12 months after Phase 1 kicks off in the best case reference plan; that number is a planning heuristic. It is not an externally validated benchmark, and payer connectivity, specialty complexity, and internal change management capacity drive the actual range.

Do not skip

• Shadow mode – Turning on auto submission without a shadow period is an engineering risk for any AI system operating on production PA traffic. Practices should treat shadow mode as design guidance for that reason, without relying on any specific claimed pattern about first month denial spikes.
• Rollback testing – Validate rollback works before production. Discovering a broken rollback during an incident is a costly discovery.
• Governance loop – A one time setup that is not exercised is not a governance loop. Run at least one full cycle, live or simulated, in Phase 3.

Fig 8 – The implementation advances through discovery, integration, shadow mode, assisted submission, and narrow production only when the preceding phase's exit evidence is sufficient. Each additional payer or service slice returns to controlled validation. Nothing bypasses the gates

_{Planning note. The gates and phase criteria are engineering and governance recommendations. They are not regulatory requirements or validated universal benchmarks. Connectivity targets, quality thresholds, minimum case counts, and acceptable performance ranges must be defined for the practice’s payer mix and case mix. The duration ranges in the article are planning heuristics; elapsed calendar time alone does not satisfy an exit gate.}

Metrics, Failure Modes, and Vendor Questions

Three things every serious PA program needs to hold in view. The metrics that measure whether the system is working. The failure modes that recur across deployments. The questions to bring to every vendor demo.

Metrics that matter.

Table 7 – The program metrics worth baselining before a vendor call

Fig 9 – A balanced PA scorecard tracks economics, workflow quality, payer outcomes, and patient delivery together. Populate the baseline, target, and 90 day trend columns from the practice's own data, and do not rely on universal benchmarks

_{Measurement note. Track cost per submitted, resolved, and approved PA as separate denominators. Released staff capacity is not cash savings unless overtime, contractor spend, headcount, or future hiring actually falls. Compare denial, clean submission, additional information, and decision time measures like for like on payer mix and case mix over a sufficient case count. Time to therapy and authorization expiration have causes beyond PA automation, so do not attribute their full movement to the system. Evaluate extraction using task specific precision and recall on a labelled set representative of the practice’s case mix, alongside critical field accuracy and unsupported evidence rate. Track false negatives with the no PA required rate.}

Accuracy on its own is deliberately absent from this list. As a headline metric it misleads when the base rate matters, as it does with denials. Use precision and recall on the specific classification or extraction task the AI is doing, measured on a labelled evaluation set representative of the practice’s own case mix.

Failure modes and fixes.

Table 8 – Common failure modes and the corresponding fix

Questions to bring to every vendor demo.

1. Which of the six archetypes are you? Do not accept a “we do all of them” answer without evidence.
2. Which FHIR resources do you read from the EHR, and which do you write back?
3. Where do you stand on each of these, and against which product version? CMS-0057-F Prior Authorization API compliance, Da Vinci CRD, DTR, and PAS implementation guide conformance, and ONC HTI-4 certification status. Treat them as related but not identical.
4. What is your approach when a payer only supports X12 278, portal, or fax? Show the fallback path.
5. Do you handle pharmacy ePA over NCPDP SCRIPT? If not, what is your recommended stack partner for that workflow?
6. Who owns the audit surface, the vendor or the practice? Where does model decision data live? What is the data export path if the practice leaves the platform?
7. What is your rollback capability if we need to revert a model or criteria change? How is it tested and how often?
8. How does your criteria library update when a payer changes their policy? Automatic, human reviewed, or notification only?
9. What is the scope of your HIPAA BAA, and will you sign one? Which subprocessors on your side create, receive, maintain, or transmit PHI? Do you maintain appropriate downstream BAAs with those subprocessors so the practice does not have to sign directly with each of them? Which services are covered? What happens to PHI after termination?
10. What extraction quality metrics (critical field accuracy, unsupported evidence rate) do you publish or share with customers on their own case mix?

Where Clixlogix Fits

FAQs