What AI-Assisted Prior Authorization Really Costs per Case

At 8:40 on Monday, a team receives a request for outpatient cardiac imaging. The order is in the electronic health record. The note describing the reason for the study is somewhere else, and the payer's current documentation rule has changed since the last similar request. An AI assistant can draft a summary quickly. Whether it saves the team time depends on whether it finds the right record, recognizes the missing detail, and stops before submitting a confident but incomplete packet.

That is why a model's price per token is a poor purchasing metric for healthcare operations. The bill is for a working process: integration, retrieval, validation, model calls, exceptions, staff time, monitoring and corrections. A useful pilot counts those costs against a defined outcome. For a provider-side prior authorization team, that outcome may be a complete and accurate submission, not an approval decision that remains with the payer.

Prior authorization is often represented as one row in a work queue. In reality, that row may pass through eligibility checking, coverage-rule lookup, chart retrieval, coding, clinical summary, submission, payer questions and an appeal. If a dashboard counts the first AI call but leaves out the employee who repairs the packet, it is measuring software activity rather than the cost of the case.

Decide where your measurement starts and ends. For a provider, a sensible start is the request entering the authorization queue. A sensible first endpoint is a submission accepted as complete by the payer, with a separate record of the ultimate decision and any later appeal. Keep those outcomes apart. A good provider process cannot guarantee approval; payer benefit design and clinical review are outside the provider's control. It can reduce avoidable missing information, manual copying and repeated questions.

The American Medical Association's 2025 Prior Authorization Physician Survey, released in 2026, asked 1,000 practicing physicians about this work. Respondents reported an average of 40 prior authorizations per physician per week and 13 hours of physician and staff time. Those are survey averages, not a cost estimate for your hospital or a measure of what an AI product will save. They are a reason to collect a local baseline before vendors demonstrate an ideal case.

Take four weeks of your own queue and record volume by payer and service type, the time to gather records, the number of requests returned for missing information, the number of staff touches, and the time to reach a complete submission. Include rejected or abandoned runs. If the current process uses fax or a portal for some payers and an API for others, keep those lanes separate. A blended average can hide the one lane that consumes most of the team's day.

The easiest way to waste model calls is to ask an agent to rediscover a procedure that the organization already knows. A case has several kinds of work. Some are deterministic: identify the payer, check whether authorization is required for the service, retrieve a versioned policy, confirm identifiers, and validate that required fields are present. Some require reading less structured material, such as finding relevant evidence in a clinician's note. Some require a person to resolve ambiguity, add a missing clinical fact or decide whether to appeal.

Make the handoffs explicit. For the cardiac imaging request, a rules layer can check the member and service, then retrieve the current payer checklist. A retrieval step can fetch the order and relevant record sections. The model can propose a short, cited summary against that checklist. A validator can compare the summary with the actual fields and attached evidence. If the prior test result is missing, the workflow should ask a staff member for it. Repeatedly querying the model with the same incomplete chart will not manufacture a missing record.

This is an operational design, not a claim that one model architecture is always cheaper. The point is to choose which step needs language interpretation and which step needs a reliable rule. A model may help locate a relevant sentence in a long note; a standard field check can determine whether the request contains the member ID. Logging the step and its policy version makes a later correction possible. An unlogged conversation that happens to produce a polished letter is hard to audit when a payer asks what information it used.

The Peterson Health Technology Institute's April 2026 industry workshop on administrative AI identified a real danger in automating both sides of prior authorization: providers can send more requests while payers can send more automated questions, increasing activity without lowering system cost. The report also says there is not yet evidence that faster individual steps lower average cost per claim once the AI solution is included. This is a workshop finding, not a controlled trial, but it is a useful challenge for a pilot: does the system remove work or merely make the back-and-forth faster?

Record costs at the case level and roll them up by payer, service and difficulty. At minimum, the ledger should capture model input and output usage, retrieval and document-processing calls, software and integration fees, infrastructure, staff review minutes, rework, exception handling and support. Amortize the one-time integration and validation effort over a stated number of cases and months. Keep that assumption visible. A pilot with a large setup bill can look expensive at 100 cases and reasonable at 10,000; a pilot that needs constant manual rescue can move the other way.

One practical formula is total workflow cost divided by complete, accurate submissions. The numerator includes failed attempts, retries and human time. The denominator excludes cases still waiting for missing documentation or bounced back for an avoidable omission. Track the cost per attempted case as well, but do not use it as the only success measure. A cheap attempt that creates another work item is not a cheap outcome.

Consider a hypothetical team with 1,000 monthly cases. Suppose its pilot groups 600 as routine, 300 as missing-document cases and 100 as clinically contentious. If routine cases take two model calls, missing-document cases take four, and contentious cases take eight, the month uses 3,200 calls. A budget based on two calls for every case would predict 2,000, undercounting call volume by 60 percent. These counts are planning assumptions, not measured healthcare benchmarks. Replace them with your own pilot distribution before buying capacity.

Now add the people. Suppose the same three groups need five, 14 and 35 staff minutes per case. The month consumes 10,700 minutes, or about 178 hours and 20 minutes. A plan that budgeted five minutes per case would have allowed only 5,000 minutes. The difference is not primarily a model-price problem; it is the cost of missing evidence and complex decisions. The finance team can multiply measured minutes by its own fully loaded labor rate and add actual vendor, hosting and support charges. Publishing a single national dollar figure for this mix would obscure more than it explains.

The ledger should preserve the 90th or 95th percentile, not only the average. A handful of looping cases may drive a month's bill and delay care. Tag every retry by reason: EHR timeout, document not found, payer rule conflict, model answer lacking support, or human correction. Put a cap on automatic attempts and send cases that exceed it to an accountable owner. A retry limit is a cost control, but it is also a way to keep a patient request from getting stuck in a machine-only loop.

Approval rate is an attractive dashboard number and a poor sole measure for provider-side automation. It changes with patient mix, payer policy, clinical criteria and benefit design. Start with first-pass completeness: did the submission include the required identifiers, codes, evidence and attachments for that payer and service? Then measure the fraction returned for more information, time from order to complete submission, staff touches, and the number of corrections after human review. Track denials and appeals separately, with reasons.

For the pilot, have reviewers inspect a sample of cases where the model seemed most certain as well as the ones it escalated. A system that only asks for help when it says it is unsure can still miss an obvious required field. Compare the assistant's evidence references with the underlying record. Keep a version of the payer rule used for each case; a submission can be technically complete under last month's rule and incomplete under today's. If a rule changes, identify affected queued cases rather than hoping the model notices.

The PHTI report distinguishes straightforward requests from clinically contentious ones. It cautions that tools which speed simple requests may have limited impact on the cases that require nuanced review and create the most expensive back-and-forth. Your results should therefore be reported by case group. A vendor's high automation percentage in straightforward work should not be used to promise the same result for a complicated appeal.

The Centers for Medicare & Medicaid Services' 2024 Interoperability and Prior Authorization final rule, CMS-0057-F, has two different timelines. Certain operational provisions for impacted payers generally began in 2026, including decision timeframes and specific reasons for denials. Its prior authorization API requirements generally begin in 2027. The rule's prior authorization provisions concern medical items and services other than drugs, and the exact obligations depend on the payer type.

For covered standard requests, CMS describes a maximum of seven calendar days for a decision; for expedited requests, 72 hours, subject to the rule's conditions and payer exceptions. A faster submission process may leave more of that time for payer review, but it does not change a payer's clinical decision. CMS's own FAQ says the final rule does not require impacted payers to make real-time decisions through the Prior Authorization API. Do not buy an agent on the promise that a 2027 interface means instant approval.

What the API can change is the exchange of requirements and responses. CMS describes an API through which impacted payers identify covered items and documentation requirements and return approval, a denial reason, or a request for more information. Ask the vendor how its product will handle those response types, policy versions and payer coverage gaps. Until a particular payer and electronic health record support the path you need, the workflow may still involve portals, phone calls or fax. That is another reason to pilot the route with your actual payer mix.

Before uploading records to any AI service, map where protected health information goes. The U.S. Department of Health and Human Services' cloud-computing guidance says that a cloud service provider creating, receiving, maintaining or transmitting electronic protected health information for a covered entity or business associate generally needs a HIPAA-compliant business associate agreement. Encryption alone does not remove that business associate status. The organization must also conduct its own risk analysis and understand the shared responsibilities of the service.

Ask concrete questions: Is patient information sent to a third-party model or a subcontractor? Which region processes it? How long are prompts, retrieved documents and logs retained? Who can inspect them? How are access, deletion, backups and incident response handled? Can the organization retrieve its data if the agreement ends? Is the proposed deployment covered by the relevant agreement, rather than a similarly named consumer product? Have privacy, security and legal staff review the answers before the pilot carries real patient data.

Retrieve only what the task needs, because excess chart material increases reading cost, exposure and error opportunities. Do not oversimplify that into a universal HIPAA slogan. HHS explains that the Privacy Rule's minimum necessary standard has exceptions, including disclosures to or requests by a healthcare provider for treatment. Whether it applies to a particular use or disclosure depends on the purpose and parties. Configure access and retrieval with the organization's privacy team, and make data minimization a practical control even where a particular legal exception applies.

Human review is also a design choice that needs precision. The HHS and CMS documents cited here do not establish one reviewer rule for every AI-prepared provider submission. An organization may require staff or clinician review for its own safety, contractual or professional reasons, especially when the model interprets clinical notes or identifies a disputed criterion. Define exactly which cases require which role, what evidence the reviewer sees, and whether the reviewer can correct the packet without rerunning the whole workflow.

A useful 60- to 90-day pilot begins with a sample that resembles the production queue. Include at least three payer lanes and a mix of routine, missing-document and clinically contentious cases. If the organization handles only one narrow service, say so and avoid generalizing the result to every authorization. Use de-identified historical cases for early testing where feasible, then progress to live cases only after privacy and operational controls are approved.

Write the acceptance measures before the vendor sees the test set. Examples include first-pass completeness, staff minutes per complete submission, return-for-information rate, total case cost, median and tail latency, exact-policy retrieval, privacy events and time to recover from a failed integration. Decide what constitutes a critical error, such as attaching the wrong patient's record or claiming a clinical fact unsupported by the chart. A product can meet a cost target and fail the safety threshold; both results belong in the decision.

The National Institute of Standards and Technology's voluntary AI Risk Management Framework is a useful prompt for naming the people behind those thresholds. Assign an owner who can pause the workflow after a payer-rule change, someone who reviews evidence quality, and someone who decides when a failed case returns to the manual queue. Governance is not a slide in the kickoff deck if nobody knows who may stop the system on a busy Monday.

Give the pilot a manual comparison group drawn from similar payers and services. Record staff time and outcomes for both groups using the same definitions. Do not compare an AI-assisted batch of easy cases with the team's hardest historical month. Ask the people who fix exceptions to keep a short reason code for each intervention. Their notes will tell you whether the product needs a better retrieval rule, an EHR integration, a changed prompt or a decision to leave that case type with humans.

At the end, show the distribution, not just a total. Report how many cases finished, how many required rescue, how much time and money each class consumed, and what happened when a payer changed its rule. A purchase decision should include the cost of the controls that made the pilot acceptable. If the vendor asks to remove those controls to meet an ROI target, the target is not a fair representation of the production design.

Some teams will use a hosted service under an appropriate agreement. Others will evaluate local inference or keep parts of retrieval and orchestration on their own infrastructure. A local server does not make a workflow compliant by itself, and a cloud service is not automatically unsuitable. The choice turns on data flows, agreements, model support, security operations, performance and who will maintain the system.

If the team is testing a self-hosted path, separate the hardware roles. A workstation with a supported GPU can be a controlled model evaluation station. A server can run integration or orchestration services, but it may not have the accelerator needed for the intended model. Power protection and backup are separate decisions. The Lenovo ThinkStation P5 Gen 2, ThinkSystem ST50 V3 and Vertiv PowerUPS listings below are examples of those distinct components, not a validated clinical AI stack. Model memory fit, software compatibility, storage encryption, high availability and the facility's power design still need engineering review.

The request for quote should state which steps run where, how patient data is protected, expected monthly case volume and peak load, the intended model or service, EHR and payer interfaces, audit retention, recovery target and who owns exceptions. Ask the supplier to quote the necessary integration and acceptance work alongside any hardware. Otherwise a low equipment price can hide the work that determines whether the project functions.

Bring three real workflow shapes to the demonstration: one routine case, one with missing evidence, and one that needs a clinical decision or appeal. Ask the vendor to show the policy source, every model and retrieval step, a failed-tool retry, the human handoff, and the final submission packet. Then request the case-level ledger. Uniqcli can help scope the compute, network, storage and endpoint requirements that follow from that tested design.