Pod 1: Prior Authorization

Prior auth is the largest single AI category in payer/provider automation, driven by CMS-0057-F. The technical center of gravity is the HL7 FHIR Da Vinci implementation guide series.

The four Da Vinci implementation guides for PA

IG	Full name	What it does
CRD	Coverage Requirements Discovery	EHR queries payer at order-time: "is auth needed for this service for this member?"
DTR	Documentation Templates & Rules	Payer returns the structured questionnaire the provider must complete to support the request.
PAS	Prior Authorization Support	FHIR-based PA submission and response (replaces or wraps X12 278).
PDex / Provider Access / Payer-to-Payer	Various	Member-controlled or provider-facing access to PA history, including across payers.

The PA flow under CMS-0057-F

Order placed in EHR for a service requiring auth.
EHR calls CRD → payer responds with auth requirement and pointer to the relevant DTR questionnaire.
EHR launches DTR; clinician/coordinator answers questions, pulling clinical data from the chart where possible (CDS Hooks make this seamless).
Completed bundle submitted via PAS to payer.
Payer adjudicates: auto-approve if criteria clearly met, route to clinical review if not.
Response returns through PAS with one of: approved, denied (with reason), or pended for more information.

Where AI fits in PA

Payer-side: criteria evaluation assistance. Read the submitted clinical evidence + the criteria (licensed InterQual/MCG or proprietary) and identify met/unmet criteria for the reviewer. Cannot make the final coverage decision.
Payer-side: auto-approval pathways. Cases where evidence clearly meets criteria; auto-approve with audit trail. Approvals don't trigger the same human-decision requirements as denials.
Provider-side: gold carding qualification. Models that identify physicians with consistently approved requests for specific services, enabling gold-card programs that exempt them from PA.
Provider-side: questionnaire completion. Auto-populate DTR questionnaires from the chart, with citations to source spans for clinician review.
Provider-side: appeal generation for denied PAs. Overlap with the Appeals pod.

Key X12 278 segments to know

Even with FHIR PAS, you'll still see 278 in many payer systems. Critical segments:

UM — utilization management category (admission, service review).
HCR — review certification (the response: approved, denied, modified, pended).
HSD — services authorized (counts, days, dates).
MSG — free-text messages from the payer, often the reason for denial.

What CMS-0057-F specifically demands by 2027

Patient Access API — includes PA information (decision, status, items/services).
Provider Access API — provider organizations can pull a member's PA history with member consent.
Payer-to-Payer API — when a member changes plans, the new payer can pull PA history from the old.
Prior Authorization API (the big one) — Da Vinci PAS-aligned FHIR endpoint for submitting and tracking PAs.
Public PA metrics reporting — including approval/denial rates by service category.

▶ Implementation reality

Most affected payers are not on track for the 2027 PAS API requirement. There's significant vendor opportunity in (a) FHIR conversion / facade layers that map legacy 278 + portal flows to PAS, and (b) tools that help providers leverage the new APIs once they exist. Build for the spec, not the current state.

Pod 2: Payment Integrity

Payment integrity (PI) is the umbrella for everything that prevents or recovers improper payments. Three sub-disciplines:

The PI spectrum

Approach	Timing	Mechanism	Typical recovery
Pre-pay edit	Before adjudication	Automated rules (NCCI, MUE, plan policy)	2–4% of paid claims
Pre-pay clinical review	Before adjudication, but flagged for human	Coder/clinician validates DRG, level of care, code support	1–3% of paid dollars on reviewed claims
Post-pay audit	After payment, often months later	Statistical sampling, targeted audits, extrapolation	0.5–2% of paid dollars, recovery is harder
FWA (Fraud, Waste, Abuse)	Anytime	Outlier detection, pattern analysis, SIU referrals	Variable; high $ per case

Major PI use cases for AI

DRG validation (covered in Step 2): does the documentation support the DRG billed?
Clinical validation: does the documentation support each diagnosis billed (especially for inpatient and SNF claims)?
Itemized bill review: line-by-line audit of high-dollar facility bills against billing rules and contract.
Coordination of Benefits (COB): identifying when another payer should be primary; recovering payments made in error.
Subrogation: identifying claims that should be paid by liability/workers' comp/auto insurance.
Hospital-acquired condition (HAC) detection: payment reduction for present-on-admission (POA) coding errors.
Outlier and FWA detection: providers billing patterns that deviate sharply from specialty norms.

The PI vendor landscape (incumbents to know)

When you sell or build in this space, you're displacing or integrating with these:

Cotiviti — broadest payment integrity platform; pre-pay + post-pay + COB.
Optum (UnitedHealth Group) — large in-house plus vendor offering.
Lyric (formerly ClaimsXten) — pre-pay editing engine, widely embedded in payer adjudication.
Zelis — payment integrity, network management, claims.
EXL / EXL Health — broad payer services including PI.
Multiplan / Claritev — out-of-network and PI services.
Performant — recovery audit contracting.

What "good" PI AI looks like

Auditable findings. Every flag must be defendable to the provider; the explainability standards from Step 3 apply doubly here.
Specificity over recall. A 90% false-positive rate makes the AI useless; reviewers burn out fast. Tune for precision, accept lower recall, increase recall over time as you build trust.
Contract-aware logic. The same code combination can be appropriate under one payer-provider contract and incorrect under another. Don't ship a model blind to contract terms.
Provider abrasion management. Aggressive PI alienates providers, who then push back through contracts. Sophisticated payers care about provider abrasion metrics; your AI should help minimize it.

Pod 3: Appeals

When a coverage decision goes the wrong way, the affected party (provider on behalf of the patient, or the patient directly) can appeal. The mechanics are highly structured and vary by plan type. AI for appeals automates the document-heavy parts while keeping clinical judgment human.

Medicare appeals — 5 levels

Level	Where it goes	Timing
1. Redetermination	The MAC (for FFS) or the plan (for MA)	120 days to file; 60 days to decide
2. Reconsideration	Qualified Independent Contractor (QIC) for FFS; Independent Review Entity (IRE) for MA	180 days to file; 60 days to decide
3. ALJ hearing	Office of Medicare Hearings & Appeals	60 days to file; significant amount-in-controversy threshold (indexed annually)
4. Medicare Appeals Council	HHS Departmental Appeals Board	60 days to file
5. Federal District Court	US District Court	60 days; amount-in-controversy threshold

Commercial / ERISA appeals

Employer-sponsored plans subject to ERISA generally have two internal levels followed by an external review by an Independent Review Organization (IRO). The ACA standardized the external review process for non-grandfathered plans.

NSA Independent Dispute Resolution (IDR)

For out-of-network claims under the No Surprises Act, the provider and payer enter a baseball-style arbitration through a federal IDR process. Different process, different documentation, different incentives — and a real category for AI given the volume.

AI use cases in appeals

Denial classification and routing. Read the denial letter / 835 / EOB; identify the denial reason; route to the right appeal workflow.
Appeal letter drafting. Pull relevant chart documentation, criteria, code definitions, and policy citations. Draft a structured argument. Clinician reviews and signs.
Likelihood-to-win scoring. Prioritize appeals work based on probability of overturn × dollar value.
Evidence assembly. Compile the medical record extracts, chronologies, and supporting attachments required by the appeal level.

Appeals letter anatomy

A defensible appeals letter contains:

Claim identifiers (member, claim number, dates of service, billed/paid amounts)
Specific denial reason being appealed (CARC, RARC, denial letter language)
Clinical narrative supporting medical necessity, with documentation cited by date and page
Coding justification citing applicable code definitions and modifier rules
Policy citation: applicable NCD, LCD, plan medical policy, or contract section
Specific requested action (overturn denial and pay; reprocess at correct DRG; etc.)
Signature of the appropriate credentialed signer

▶ Appeals AI must be citation-verified end to end

Hallucinated NCD numbers, fabricated section citations, and incorrect code definitions in appeals letters get caught — often the first time — and damage your customer's standing with the payer. The verification layer from Step 3 is not optional here. Tier-1 source-grounded citations only.

Pod 4: Provider-side Denial Prevention

On the provider side, denials are AR-aged dollars and clinician/admin frustration. The economics: avoiding a denial is roughly 10x cheaper than working one. Prevention AI lives at the front-end (eligibility, auth status, code combinations) and at the charge-capture / pre-bill stage.

The denial taxonomy that matters

Category	Examples (CARC)	Where to prevent
Eligibility / registration	CARC 27 (coverage terminated), 31 (patient not identified)	Front desk — 270/271 check; member ID verification
Authorization	CARC 197 (no precert/auth)	Pre-service — auth requirement lookup; auth status check
Coordination of Benefits	CARC 22 (covered by another payer)	Front desk — accurate COB capture
Medical necessity	CARC 50, often with LCD/NCD citation	Pre-bill — LCD/NCD check vs documented diagnosis
Coding / bundling	CARC 97 (bundled), 16 (missing info)	Pre-bill — NCCI edits, modifier rules
Timely filing	CARC 29	Workflow — claim submission SLA monitoring
Duplicate	CARC 18	RCM — claim status (276/277) before resubmission

AI use cases

Real-time auth requirement lookup integrated into scheduling and EHR ordering. Da Vinci CRD where supported.
Pre-bill claim scrubbing with NCCI, MUE, payer-specific edits, and code-combination patterns.
Documentation gap detection — for a given billed code, is the documentation sufficient?
Denial root-cause clustering — group denials by underlying cause (specific physician, specific service, specific payer) and route to remediation.
Charge capture validation — comparing the chart against the charges to find missed billing or overbilling.
Appeals prioritization (overlap with Appeals pod).

Key KPIs your customers track

Initial denial rate — percent of claims denied on first submission. Best-in-class < 4%; many systems run 7–12%.
Final denial write-off rate — denials that ultimately become bad debt.
Denial overturn rate — percent of appealed denials reversed.
Cost-to-collect — administrative cost per dollar collected.
AR days > 90 — aging buckets; denied claims age fast.

▶ Sell to the right KPI

A pre-bill scrubbing product wins on initial denial rate. A workqueue prioritization product wins on AR days. A denial root-cause analytics product wins on long-term structural improvement. Mismatch your pitch to your KPI and your buyer's CFO won't see the value. The Client Engagement track expands on this.

Cross-pod data & integration patterns

Healthcare AI rarely lives in one pod cleanly. Common cross-pod patterns:

Denial → Appeal handoff. Provider-side denial prevention misses a denial; the appeal pod takes over. The provenance (why the denial happened) is the input to a better appeal.
PA denial → Appeal. A denied PA flows into an appeal workflow with the same evidence assembly but different timelines and recipients.
PI finding → Provider notification → Appeal. Payer-side PI raises a recovery; provider's denial-management system receives it; if the provider disagrees, an appeal launches.
Shared knowledge base. NCCI, LCDs, NCDs, coding rules, and payer policies are needed by every pod. Build a single, versioned, citeable knowledge layer and reuse.

Step 4 Glossary

Da Vinci PAS: HL7 FHIR Da Vinci Prior Authorization Support implementation guide. FHIR-based PA submission and response.
CRD: Coverage Requirements Discovery. Da Vinci IG for point-of-order auth requirement lookup.
DTR: Documentation Templates and Rules. Da Vinci IG for structured PA questionnaires.
CDS Hooks: Standard that lets EHRs call external decision-support services at defined workflow points.
X12 278: HIPAA-mandated transaction for healthcare services review (the legacy PA submission format).
Gold carding: Program that exempts high-approval-rate physicians from prior authorization for specific services.
FWA: Fraud, Waste, and Abuse. Payer department and AI category.
SIU: Special Investigations Unit (within a payer or PI vendor) that investigates suspected fraud.
QIC / IRE: Qualified Independent Contractor (FFS Medicare) / Independent Review Entity (Medicare Advantage) — the level-2 appeals reviewer.
ALJ: Administrative Law Judge. Level-3 Medicare appeals hearing.
IRO: Independent Review Organization. External reviewer for commercial/ERISA appeals.
IDR (under NSA): Federal Independent Dispute Resolution process for OON payment disputes under the No Surprises Act.
COB: Coordination of Benefits. Determining which of multiple insurance plans is primary.
POA: Present On Admission indicator on each inpatient diagnosis. Drives HAC payment adjustments.

Frequently asked questions

If we only have bandwidth for one pod, which should we start with?

Match the pod to your distribution. If you have payer relationships, prior auth or payment integrity have the strongest budget. If you have provider relationships, denial prevention has the clearest ROI story. Appeals is a strong wedge into either side because the document automation pain is universal and the value is easy to demonstrate.

Are there open data sets we can use to bootstrap models?

For codes and policies: yes (CMS publishes NCCI, MS-DRG, HCC models, NCD/LCD libraries, fee schedules). For claims data: limited — CMS releases LDS files and synthetic data, but real claims data requires either data partnerships or your customer's data under a BAA. The Synthea project produces synthetic patient data useful for FHIR development.

How does the CMS-0057-F timeline interact with our roadmap?

Backwards from January 2027 for FHIR APIs and January 2026 for shortened turnaround times. If you sell to MA / Medicaid managed care / CHIP / QHPs on FFEs, your roadmap should help them hit those dates. If you sell to commercial-only plans, the rule doesn't bind them — but commercial plans are watching and many will follow voluntarily.

What clearing house / EHR integrations should we plan for?

Clearinghouses for claims/remits: Availity, Change Healthcare/Optum, Waystar, Trizetto. EHRs for clinical data: Epic (largest share), Oracle Health (formerly Cerner), Meditech, athenahealth, Veradigm. Each has its own integration model — FHIR R4 is the converging standard but legacy integrations (HL7 v2, custom APIs) remain common. Plan for integration as a multi-quarter effort per major partner.

Self-check · End of Step 4

Did you absorb Step 4?

Questions grounded in real curriculum material. No certificate at this stage — the certificate is earned at the end of the track via the final exam. Honor system. Unlimited retakes. Wrong answers come with explanations.

You've completed the Builders track

You now have the foundation, depth, production discipline, and use-case specialization to ship healthcare AI that holds up to clinical and regulatory scrutiny. From here:

Set up your team's certification path (CPC / CRC / CPMA / CCS) per Step 2.
Hire or contract a Medical Director if you haven't yet — see Step 3.
Build the deliverables checklist artifacts from Step 3 into your release process.
Our Healthcare FDEs are encouraged to work through the Client Engagement track too — when our engineers and our account teams share vocabulary, customer conversations get sharper and deployments land faster.