Prior authorization automation data quality: what AI approvals require

Every prior auth AI decision is a bet on data nobody scored

A prior authorization decision touches at least four data domains: the patient's clinical history, the provider's credentials and network status, the payer's medical policy criteria, and the procedure or drug code being requested. If any one of those domains contains stale, incomplete, or mismatched data, the AI system built on top of it produces a decision that looks fast but is clinically or administratively wrong.

The industry is racing to automate prior authorization. CMS is mandating it. Vendors are selling it. But almost nobody is asking the prerequisite question: what trust score does the underlying data need before an algorithm acts on it?

Can AI do prior auths?

Yes. AI systems can and do process prior authorization requests today. Large language models parse clinical notes, extract relevant diagnoses and procedure codes, match them against payer medical policies, and return approve or deny recommendations in seconds rather than days.

But capability is not the same as reliability. An AI system that auto-approves a knee replacement based on a clinical note from 2021, matched against a provider record that lists the wrong specialty, has not improved prior authorization. It has automated a mistake.

The real constraint on PA automation AI is not the model. It is the data supply chain. When the input records lack provenance, recency, and concordance, the output decisions inherit every error in the pipeline. The UnitedHealth Group AI denial controversy demonstrated exactly what happens when automated decisions run on data nobody verified.

What are the requirements for CMS prior authorization in 2026?

The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) sets a January 1, 2026 compliance deadline with several concrete requirements:

72-hour standard decisions. Payers must respond to non-urgent prior authorization requests within 7 calendar days, and urgent requests within 72 hours.

Real-time electronic exchange. Health plans must implement a Prior Authorization API using HL7 FHIR standards, enabling providers to submit and receive prior auth decisions electronically.

Reason codes for denials. Payers must include a specific reason for every denial, not a generic rejection.

Public reporting. Plans must publish prior authorization approval rates, denial rates, and average processing times.

Patient access. Prior authorization information must be available through the Patient Access API.

These requirements assume that the data exchanged through these APIs is accurate. CMS does not prescribe a data quality standard for the clinical inputs feeding the decision. That gap is where most PA automation AI systems will fail, because FHIR APIs do not guarantee the quality of what flows through them.

Key statistics

DTI dimension weights for prior authorization data scoring

These numbers frame the data quality crisis underneath prior authorization automation:

50% of provider directory records contain errors in address, phone, specialty, or network status, according to CMS audits. Every PA decision that checks network status against a directory inherits that error rate. (source)

34% of prior authorization requests are initially denied, according to a 2023 KFF analysis of Marketplace plans. The denial rate itself is not the problem. The problem is how many denials result from data mismatches rather than genuine clinical criteria failures.

93% of denied prior auths that go through appeal are eventually overturned in some clinical categories, suggesting the original denial was often based on incomplete or misinterpreted data.

Claims data lags 30 to 90 days behind the clinical event it represents. An AI system checking a patient's recent utilization history against claims data is working with a record that may be one to three months stale. (source)

3 weeks to 2 hours: SuperTruth reduced data standardization time by 95% across 105,000 diagnostic records for imaware, demonstrating what trust-scored data processing looks like at scale.

The four data domains that break PA automation

Prior authorization data quality failure rates by domain

Prior authorization sits at the intersection of four data domains, each with its own quality problems.

1. Clinical data: the patient record

The clinical justification for a prior auth request typically comes from EHR notes, lab results, imaging reports, and diagnosis codes. Each source carries its own trust deficit.

EHR notes are unstructured. NLP models extract meaning from them, but extraction quality depends on the underlying data trust. A clinical note that says "patient reports worsening symptoms" does not carry the same evidentiary weight as a structured lab value, but many PA systems treat extracted text and structured data identically.

ICD-10 codes carry billing incentives that distort clinical accuracy. Coding practices vary by institution, and the same clinical presentation can be coded differently depending on who documents it and when.

2. Provider data: who is requesting and who is performing

The PA system needs to confirm that the requesting provider is credentialed, in-network, and authorized to order the requested service. Provider directory data is the weakest link in this chain.

When half of provider directory entries contain errors, an AI system that auto-denies because it cannot confirm network status is denying care based on an administrative data failure, not a clinical judgment.

3. Payer policy data: the rules the AI enforces

Medical necessity criteria change. Formularies update. Coverage policies vary by plan, by state, and by employer group. The AI system must match the request against the correct, current version of the relevant policy.

Most PA automation vendors treat payer policy as a static lookup. But policies have temporal validity. A drug that was covered last month may require step therapy this month. If the policy data lacks versioning and effective dates, the AI enforces rules that may no longer apply.

4. Procedure and drug data: what is being requested

CPT codes, HCPCS codes, and NDC codes identify the service or drug. CPT code integrity problems propagate through every system that touches them. A PA system that receives a CPT code with a modifier mismatch may deny a valid request or approve an inappropriate one.

RxNorm mapping errors create the same problem on the pharmacy side. A medication reconciliation error that maps to the wrong NDC can trigger an incorrect formulary check.

How can AI be used to improve data quality?

AI can improve data quality in prior authorization workflows, but only if the improvement happens before the approval decision, not as part of it.

Specific applications include:

Record matching and deduplication. AI can identify when the same patient appears under slightly different names, dates of birth, or MRN numbers across systems, reducing duplicate or conflicting records that cause PA confusion.

Completeness detection. Models can flag when a PA submission is missing required clinical documentation before the request reaches a reviewer, reducing back-and-forth that delays decisions.

Temporal validation. AI can check whether clinical data cited in a PA request is current enough to support the decision. A lab result from 18 months ago should not justify a treatment decision today.

Code validation. Models can verify that diagnosis codes, procedure codes, and modifier combinations are internally consistent before submission.

Concordance checking. AI can cross-reference data across sources to identify conflicts. If the EHR says one thing and the claims record says another, that discordance needs resolution before a decision is made.

The critical distinction is that these functions improve the data feeding the decision. They do not replace the need to score and validate the data before the model acts on it.

Which AI is best for analyzing medical records?

No single AI system is best for analyzing medical records in the context of prior authorization. The question conflates two distinct problems: extracting structured information from unstructured clinical text, and evaluating whether that extracted information is trustworthy enough to base a coverage decision on.

For extraction, large language models fine-tuned on clinical text (such as Med-PaLM, GPT-4 with clinical prompting, or domain-specific models like those from Abridge or Ambience) can parse physician notes, operative reports, and discharge summaries with increasing accuracy.

But extraction accuracy is not the same as data trust. A model can perfectly extract a diagnosis from a clinical note, and that diagnosis can still be wrong because the note was copied forward from a prior encounter, dictated by a covering physician who did not examine the patient, or coded for billing optimization rather than clinical precision.

The AI that matters most for prior authorization is not the one that reads the record. It is the one that scores the record before anything else reads it. That is what the DTI Engine does across eight dimensions: provenance, consent, recency, quality, concordance, validation, breadth, and stability.

The trust threshold for automated approval

Not every prior authorization decision carries the same risk. A PA for a generic medication refill carries different stakes than a PA for a spinal fusion. The data quality threshold should reflect that risk gradient.

A tiered trust model for PA automation would look like this:

Tier 1: Auto-approve eligible. Low-cost, low-risk, high-frequency requests (routine labs, generic refills, standard imaging). These can be auto-approved when the DTI score across all input records exceeds 80 and the clinical data is less than 90 days old.

Tier 2: AI-assisted with human review. Moderate-cost procedures, specialty drugs, and services with clinical ambiguity. The AI prepares the recommendation, but a human reviewer confirms. Required when any input record scores below 70 on the DTI scale.

Tier 3: Human-only with AI support. High-cost, high-risk, or clinically complex requests (organ transplants, gene therapies, experimental treatments). AI organizes and presents the data, but the decision is fully human. Required when clinical data provenance cannot be confirmed or when concordance across sources falls below 60.

This is not a theoretical framework. It is the minimum viable architecture for PA automation that does not produce systematic harm.

What happens when you automate without scoring

The failure mode is predictable. An AI system processes a prior authorization request. It checks the patient's diagnosis codes against the payer's medical policy. The codes match. The system approves or denies.

But the diagnosis code was assigned by a billing coder who never saw the patient. The provider record lists a specialty that was updated 14 months ago. The clinical note was copied forward from three encounters back. The payer policy version is from Q3, but Q4 updates changed the step therapy requirement.

Every one of those data quality failures is invisible to the AI system. It sees valid codes, valid formats, valid fields. It has no mechanism to evaluate whether the data is true.

This is the difference between data quality and data trust. Quality asks whether the fields are filled correctly. Trust asks whether the filled fields reflect reality.

The provenance problem specific to prior auth

Prior authorization data moves through more hands than almost any other healthcare transaction. The clinical data originates in the EHR. It is extracted by middleware. It is reformatted for FHIR transmission. It is received by the payer's intake system. It is parsed by the PA engine. Each step is a point where provenance can break.

By the time the AI system evaluates the data, it may be four or five transformations removed from the original clinical event. Without a chain of custody record for each data element, the system cannot distinguish between data that was faithfully transmitted and data that was corrupted, truncated, or silently modified in transit.

DTI's provenance dimension, weighted at 25% of the total score, exists precisely for this use case. Every record gets a provenance score based on its source, transmission path, and transformation history. A PA system that enforces a minimum provenance score before acting would catch the failures that format-level validation misses.

The recency trap in utilization review

Utilization management depends on knowing what has already been tried. Step therapy protocols require evidence that first-line treatments failed before authorizing second-line options. But the clinical evidence of prior treatment attempts may exist only in claims data, which lags reality by 30 to 90 days.

An AI system checking whether a patient completed step therapy by querying claims data may find no evidence of the required first-line treatment, because the claim has not been submitted or adjudicated yet. The system denies the request. The patient waits. The provider appeals. Everyone loses time.

Recency scoring, weighted at 15% of the DTI score, flags exactly this risk. Data elements that are temporally insufficient for the decision at hand receive lower scores, signaling to the PA system that the data may not reflect current clinical reality.

Building the data trust layer before the automation layer

The sequence matters. Most PA automation implementations start with the automation layer: connect to payer systems, ingest policies, build decision logic. Data quality is addressed retroactively, if at all.

The correct sequence is:

Score every input data source across eight trust dimensions.

Set minimum DTI thresholds by decision risk tier.

Build automation logic that only executes when data meets the threshold.

Log every decision with the DTI scores of the data that informed it.

Surface decisions where data trust was marginal for human review.

This architecture does not slow down automation. It makes automation defensible. When CMS requires payers to publish denial reasons, a trust-scored data pipeline produces reasons that trace back to verified clinical facts rather than administrative artifacts.

The explainable data provenance that regulators, auditors, and patients increasingly demand starts at the data layer, not the model layer.

The 2026 compliance clock is also a data trust clock

January 2026 is not just a technology deadline. It is a data trust deadline. Health plans that build FHIR APIs without scoring the data flowing through them will meet the letter of the CMS rule while creating a new category of audit exposure.

The plans that score every record before it enters the PA decision pipeline will be the ones that can explain their approvals and denials in terms regulators accept. The ones that do not will find that automation without trust produces automated liability.

The DTI Engine scores every record 0 to 100 across eight dimensions before your AI model sees it. For prior authorization, that means every clinical note, every provider record, every policy document, and every procedure code gets a trust score before a decision is made. If your team is building or evaluating PA automation and needs to answer the data quality question before the compliance question answers it for you, talk to the SuperTruth commercial team. Schedule a conversation or call (215) 918-4140.

Further reading:

DTI™ Engine

Health plans solution

Provider directory accuracy: the 50 percent error rate problem in health plan data

Explainable data provenance: why health AI has to show where every record came from

Claims data lags 30 to 90 days. Here is what it costs AI models