How prior authorization automation
actually works.

1. Step 1 · Intake validation

   Validate that the incoming request is structurally correct. CPT/HCPCS codes against active code sets, ICD-10 against current versions, beneficiary identifiers against eligibility systems, X12 278 transactions against the schema. The most common failure mode in legacy PA stacks is silent intake failure — bad inputs propagate downstream and surface as inscrutable denials weeks later. Automated intake validation is high-leverage, low-risk, and almost universally underspecified in vendor pitches.

2. Step 2 · Eligibility verification

   Verify that the beneficiary is enrolled, the requesting provider is enrolled and credentialed (PECOS for Medicare), and the service is within scope of coverage. Eligibility is a deterministic question — the answer is in a database somewhere — and the automation pattern is therefore an API call, not an LLM. The architectural choice that matters is: which eligibility system is authoritative for this case, and what happens when its data is stale?

3. Step 3 · Duplicate request detection

   Detect whether this exact case has been submitted before by this provider for this beneficiary in a defined lookback window. Duplicates are a major source of waste in legacy PA workflows — a clinical reviewer spending fifteen minutes on a case that was already decided last week. Detection is straightforward (matching on CPT/ICD/date-range/provider/beneficiary) but requires careful tuning of the deduplication window and the equivalence rules.

4. Step 4 · Criteria evaluation

   Evaluate the case against the applicable medical policy: NCD, LCD, payer medical policy, or commercial criteria like InterQual or MCG. This is the step where most "AI prior auth" deployments fail — not because the LLM cannot read the criteria, but because criteria evaluation requires evidence-grounded reasoning, not generative reasoning. The production pattern is to decompose each criterion into atomic clinical questions and answer each question with explicit evidence citations.

5. Step 5 · Evidence assembly

   Assemble the clinical evidence supporting the determination — medical record excerpts, imaging reports, lab results, prior treatment history. Evidence must be bound to specific criteria and timestamped, so the audit packet can be regenerated months later. Most production failures happen here: the model says "the criteria are met" but the evidence trail does not actually contain the documentation a reviewer would need to validate the claim.

6. Step 6 · Determination

   For cases where the criteria are clearly met, an auto-affirmation agent issues the determination in seconds. For cases that do not clearly meet criteria, the case routes through a non-affirm research agent to a human reviewer. Auto-deny is architecturally prohibited — see The Auto-Deny Problem for the full argument.

7. Step 7 · Audit packet generation

   Emit a structured artifact for every decision: rule pack version, evidence chain, agent reasoning trace, human-review record (where applicable), and the regulatory citations that justified the determination. The audit packet is the artifact a CMS auditor would review — and it is generated for every case, not just the cases that get audited. Most PA stacks treat audit as a backstop; production-grade systems treat it as a primary output.

A specialist eligibility agent can be evaluated against eligibility ground truth. A specialist criteria agent can be evaluated against criteria evaluation. A specialist auto-affirmation agent can be evaluated against the cases it should affirm and the cases it should escalate. A monolithic LLM that handles everything cannot be audited at this level of specificity — and an architecture that cannot be audited at this level of specificity will not survive a CMS audit.

The other property that matters is determinism. Criteria evaluation in a production system is not pure LLM reasoning — it is LLM reasoning constrained by deterministic rule packs that cite NCD/LCD/medical-policy text verbatim. The rule pack is version-controlled. The version is logged in every audit packet. A determination from June can be reproduced in December because the rule pack version, the evidence chain, and the agent reasoning trace are all preserved.