How Does AI Check Whether Prior Authorization Is Required?

This page is part of our PA Automation Complete Guide. Start there for the full six-step workflow; this deep dive covers Step 1: the requirement check.

AI determines whether a service needs prior authorization by reconciling six inputs: payer, plan, CPT/HCPCS/J-code, diagnosis, place of service, and the payer’s current policy on the date of service. It compares those inputs against a live repository of payer rules, code-lookup tools, and historical outcomes. No single source is authoritative, so a well-designed system compares several and reasons about conflicts with citations.

Overview

PA required? The answer should cite sources and flag human review when needed.

1

Payer

Canonical payer identity from eligibility, card, and EHR data.

2

Plan

Commercial, MA, Medicaid, Exchange, or ASO plan details.

3

Code

CPT, HCPCS, J-code, drug, or procedure being ordered.

4

Diagnosis

ICD-10 and clinical context that may change routing.

5

Site of care

Office, ASC, hospital outpatient, home, or infusion site.

6

Policy date

The payer rule effective on the date of service.

Key takeaways

• Six variables determine the answer, not one. Change any of payer, plan, code, diagnosis, place of service, or policy date, and the answer can flip.
• State and diagnosis can change the outcome even for the same payer and code.
• Coverage and authorization are separate. A plan can cover a service and still require a PA that, if skipped, leads to a retroactive denial.
• Unlisted codes need payer-specific review (J3490, J3590, J9999, C9399), because they are coding fallbacks that can require extra documentation, PA, pricing review, or non-covered routing depending on payer and setting.
• Policy refresh cadence matters. Payer PA lists have effective dates and change over time; cached rules need versioning and monitoring.
• Output should show cited sources and review routing. The reviewer needs to see why.

Inputs And Decisioning

What determines whether a service requires prior authorization?

Six inputs determine whether a service requires prior authorization: payer, plan, service code, diagnosis, place of service, and policy date. A lookup that checks payer and CPT alone misses common routing changes caused by diagnosis, site of care, or plan-specific overrides.

Six variables:

Variable	Why it matters
Payer	The PA list lives with the payer
Plan / product	Commercial vs. Medicare Advantage vs. Medicaid rules differ inside one payer
CPT / HCPCS / J-code	The service or drug being billed
Diagnosis (ICD-10)	Some PAs route by diagnosis in addition to code
Place of service	Office vs. ASC vs. hospital outpatient changes the answer
Policy on date of service	Today’s PA list is not last quarter’s PA list

Four examples show how one variable can flip the answer:

• State changes the answer. UnitedHealthcare’s commercial PA list effective January 1, 2026 applies site-of-service review to arthroscopic CPTs 29805-29819 in most states but exempts Alaska, Guam, Massachusetts, Puerto Rico, Rhode Island, Texas, Utah, the Virgin Islands, and Wisconsin. Same payer, same code, different answer by state. (UHC PA Requirements)
• Diagnosis changes the reviewer. BCBS Montana’s 2026 specialty pharmacy list routes some specialty-drug requests to BCBSMT and some oncology or supportive-care requests to Carelon; examples include drugs where oncology diagnosis changes the review path. Same drug family, different PA pathway. (BCBSMT Specialty Rx)
• Site of care is part of the determination. BCBS Michigan’s April 2026 medical drug list describes site-of-care requirements for certain drugs, including administration in lower-cost settings such as physician office or home rather than hospital outpatient facility. Approving a drug is not approving the room. (BCBSM Medical Drug List)
• Policy date changes the answer. Humana’s South Carolina Medicaid policy for superficial radiation therapy lists an effective date of March 9, 2026 for SRT codes 77436-77439 and limits image-guided SRT. In oncology, Highmark Blue Cross Blue Shield’s FEP update moved selected drugs, including Keytruda and Opdivo, from post-service medical-necessity review to pre-service prior authorization effective February 1, 2026. (Humana SRT policy, Highmark BCBS FEP update)

What are the six inputs and where does AI get them?

AI gets PA requirement inputs from EHR demographics, eligibility responses, insurance cards, orders, diagnosis data, scheduling systems, payer PA lists, code-lookup tools, and policy PDFs. The work is reconciling conflicts when those sources disagree.

Input	Typical source	Common failure mode
Payer identity	EDI 271 response, insurance card image, EHR demographics	Name mismatches (“BCBS NJ” vs. “Horizon BCBS of New Jersey”)
Plan / product	271 benefit detail, member card, payer portal	271 often returns group-level data; plan-level variations are missed
CPT / HCPCS / J-code	Order, scheduled service, drug ordered	Unlisted/NOC codes (J3490, J3590, J9999, C9399) need payer-specific lookup, extra documentation, and sometimes PA
Diagnosis	EHR problem list, order, pathology	Diagnosis may still be pending when PA starts
Place of service	Scheduling system, order, referral	POS mismatches are a top denial reason
Policy on Date of Service	Payer PA lists, code-lookup tools, policy PDFs, EDI 278	Cached rules can go stale after payer policy updates

Payer identity breaks most often. A system that maps the EHR insurance name to the wrong canonical payer produces wrong answers for every downstream check.

How does the AI pipeline make the call?

A production AI pipeline normalizes the payer, resolves plan and benefit type, checks the code, applies diagnosis and site-of-care gates, compares historical outcomes, and emits a cited determination. Conflict should trigger escalation; silent guessing creates denial risk.

A workable pipeline follows this sequence:

1. Normalize the payer. Map EHR insurance name + subscriber ID to a canonical payer/plan. Most “phantom PAs” start here.
2. Resolve plan product and benefit type. Medical benefit vs. pharmacy benefit decides who reviews: the medical plan, a PBM, or a specialty-drug carve-out like Carelon or OncoHealth.
3. Look up the code. Check the CPT/HCPCS/J-code against the payer’s current PA list, code-lookup tool, and any vendor-delegated list.
4. Apply diagnosis and site-of-service gates. Branch on conditional rules such as specialty-drug routing by oncology diagnosis or site-of-service review by state.
5. Cross-check with historical outcomes. If this practice submitted the same code for the same payer in the last 90 days and it was accepted without PA, weight that signal. Payer lists are imperfect.
6. Emit an answer with citations. “PA required. Sources: UHC Commercial Advance Notification effective 2026-01-01; 271 showing plan XYZ effective 2026-01-01.” If sources conflict, escalate.

Each step has its own failure mode. A lookup that says “yes” when payer policy says “no” creates avoidable submission work; the CAQH 2024 Index reports that medical PA takes 24 minutes by phone, fax, mail, or email and 16 minutes through portals or IVR. A lookup that says “no” when it should say “yes” risks a no-auth-on-file denial at claim time, and the AMA recommends checking PA requirements before services or prescriptions to prevent denials, claim loss, and treatment delays.

1

Source signals

PA list, portal or code-lookup tool, 271 response, and history.

2

Compare sources

Look for agreement, recency, citations, and conflicts.

3

Outcome

Return a cited determination or escalate with evidence.

Good automation surfaces source disagreement as a reviewable exception.

Edge Cases And Review

What edge cases break naive implementations?

Naive PA requirement checks break on unlisted codes, bundled medications, code crosswalks, policy changes, benefit-type switches, and self-funded plan overrides. These cases turn yes/no lookup tables into wrong answers.

• Unlisted codes. J3490, J3590, J9999, and C9399 cannot be handled as a simple yes/no rule. Some payers publish miscellaneous-code PA lists; CMS contractors require NOC drug details such as drug identity, dosage, NDC, diagnosis, and label support where applicable; and Texas Children’s Health Plan has made J3490 threshold-dependent rather than always PA-required. A system that checks named code lists alone fails here without warning. (Washington HCA miscellaneous HCPCS list, CMS MCD A54880, Texas Children’s Health Plan provider alert)
• Medications bundled with procedures. Highmark’s own guidance: “Medications necessary for procedures may require prior authorization separate from or in addition to authorization requirement(s) for procedure(s).” One encounter, two PAs on two tracks. (Highmark Wholecare)
• Crosswalked codes. UHC allows CPT-code substitution on an existing approved PA if the swap is on their published crosswalk and made within 5 business days of service. A system that re-triggers a whole new PA here manufactures busywork.
• Policy changes during treatment. Payer lists update throughout the year. Humana’s SRT policy lists a March 9, 2026 effective date for SRT codes 77436-77439, and Highmark BCBS’s FEP update moved selected oncology drugs from post-service review to pre-service PA effective February 1, 2026. A system that caches payer rules without effective dates will answer from stale policy. (Humana SRT policy, Highmark BCBS FEP update)
• Benefit-type switches. A drug on the medical benefit for one plan year can move to pharmacy benefit the next. The same J-code answer flips.
• Self-funded employer overrides. ASO plans can override payer defaults. The PA list is a starting point; the member’s benefit booklet has the final word.

Kairos POV

Return a cited determination, not a lookup answer. The requirement check should show which payer policy, member context, code, diagnosis, site, and policy date drove the answer. If sources disagree, the case should route to human review with the evidence visible.

Treat payer policy as versioned data. The answer depends on date of service. Humana’s 2026 SRT policy and Highmark BCBS’s February 2026 FEP oncology-medication update show why requirement checks need effective dates, prior versions, and auditability.

Connect the requirement check to documentation readiness. Once the system knows whether PA is required, it should identify the relevant policy criteria and check whether the patient record supports the next step before submission. Missing or ambiguous support should become a review task, not a silent automation guess.

Bottom line

Checking whether a service requires PA is a six-variable reasoning problem, not a database lookup. AI systems that treat it as a lookup create wrong answers that are expensive to discover. The public baseline already shows high friction: CAQH reports 16-minute portal/IVR and 24-minute phone/fax/mail/email PA transactions, while one specialty-clinic study found a median 30 minutes per PA and a median 12-day delay to treatment access. Measure systems that reconcile multiple sources, cite evidence, and escalate on conflict against those baselines. (CAQH 2024 Index, specialty-clinic PA study)