Notes from automating prior authorization

American healthcare requires two separate permissions for most specialty care: permission to treat (prior authorization) and permission to get paid (claim adjudication and remittance). Physicians spend nearly two hours on electronic health record and desk work for every hour with a patient, and much of that administrative tax comes from moving the same clinical and coverage facts between charts, payer portals, and clearinghouses by hand.

Over the past couple of years, I worked on automating this layer of healthcare operations — founding Foresight in 2025 (where I am now a shareholder; today I lead an AI × life sciences division at another business). Across the specialty and telehealth clinics we served at Foresight, deterministic rules and clinical extraction models handled 85% of volume end-to-end with a 92% first-pass approval rate. This entry lays out why automating prior authorization in production requires following the authorization all the way through claim scrubbing and remittance reconciliation, followed by the four architectural lessons that held up under live payer volume:

1. Map the data before the model: Why unstructured charts and uncollected intake facts set the ceiling on automation quality.
2. Rules first, models where the work is reading, people where it's judgment: Why deterministic gates handle 80%+ of volume and where models and clinicians belong.
3. Three answers only (true, false, not sure): Why floating-point confidence scores fail operators and how three-valued logic protects an authorization from intake to bank deposit.
4. Fix the intake: How clustering downstream claim and remittance verdicts rewrites upstream prior authorizations and intake forms.

Why does automating prior authorization require covering eligibility, claim scrubbing, and remittance reconciliation? Because in production, a prior authorization is not an isolated form. It is the front gate of one continuous clinical and financial transaction:

• Pre-service (270/271 · 278 · NCPDP ePA): Verifying active coverage, routing between the medical benefit and the pharmacy benefit, and assembling medical-necessity proof from the chart.
• Mid-course (Authorization ledger · 837P): Tracking approved visits across multi-week treatment courses by both calendar window and unit budget, and attaching the authorization number (loop 2300 REF*G1) to every outgoing claim.
• Post-service (277CA · 835 ERA · PLB): Verifying that the payer honored the authorization on the electronic remittance, catching retroactive clawbacks in the provider-level adjustment segment (PLB), and feeding line-level denial verdicts back upstream to fix the prior-authorization packet and patient intake.

Automating the prior-authorization form in isolation fails if the clinic still loses payment when an authorization silently expires at visit 16 of 20, when a payer drops pre-service prior authorization and shifts enforcement to post-service medical-necessity audits, or when a remittance claws back an approved treatment months later. Conversely, the only way to make prior-authorization automation smarter over time is to feed downstream claim and remittance verdicts back into upstream intake.

Four national benchmarks show the scale of the administrative load across US practices: hospitals spent $25.7 billion fighting claim denials in 2023 (+23% year-over-year, up from $19.7B); a typical practice spends 13 hours of a 40-hour week handling ~40 prior authorizations (and 40% of practices employ staff who work exclusively on prior authorizations); the share of physicians in physician-owned practices fell from 60.1% to 42.2% between 2012 and 2024 (with 70.8% of sellers citing inadequate payer rates and 63.6% citing administrative burden); and while 80.7% of appealed Medicare Advantage prior-authorization denials win, only 11.5% are ever appealed (overturning just 9.3% of all denials).

Appeals win 80.7% of the time; only 11.5% are filed. The constraint is not clinical merit. The constraint is staff time.

Before we deployed automation at Foresight, we mapped the manual workflow at two specialty clinics on opposite ends of that pipeline:

• Pre-service bottleneck (a digital weight-loss clinic writing 100,000+ GLP-1 prescriptions/yr): Fifty full-time coordinators spent 20–30 minutes per case across eleven manual steps. Requests sat in a queue for days while staff copied demographics, BIN, PCN, and Rx Group numbers across the EHR, e-prescribing tool, and payer portals; re-typed policy numbers off phone photos of insurance cards (generating "Member Not Found" rejections); hunted through free-text notes for dated weigh-ins and failed diets; and polled portals every 48 hours.
• Post-service bottleneck (a specialized infectious-disease clinic): The clinic ran its EHR, clearinghouse, and document store as disconnected silos. Investigating an underpaid claim meant an EOB treasure hunt across a dozen portals, and every month the financial controller compared PDF bank statements on one monitor against claim spreadsheets on the other by eye — the single largest operational bottleneck in the business. Because denials returned as a black box, clinicians never learned which documentation gap or code pairing caused a rejection upstream.

To show how the full transaction fits together, we will follow one treatment course from order to bank deposit: a repetitive transcranial magnetic stimulation (rTMS) course for major depressive disorder at a behavioral-health clinic (CPT 90867 for cortical mapping and motor threshold, followed by 90868 for daily treatment delivery), cutting to the weight-loss and infectious-disease clinics where a lesson shows more clearly.

The quality of automation in this work is set by where the data lives, the order you ask questions in, and knowing where to stop — not by the model. Nothing below is about models.

1. Map the data before the model

A prior-authorization form asks for structured fields. A medical chart contains prose, faxes, and photographs. Before you touch a model, you have to map one to the other.

On a commercial prior-authorization request for an initial rTMS course, the form asks for four core items that live in four completely different formats inside the chart: two failed antidepressant trials in the current episode live in narrative prose on page 3 of an uploaded psychiatric evaluation (psych-evaluation.pdf, where "triale[d] spring of last year" is prose rather than a date an X12 278 or portal date-picker accepts, while the EHR medication list only stores active drugs); the baseline depression score (PHQ-9: 18 · 03/12) sits in a semi-structured visit note where different plans demand different scales (PHQ-9 vs. MADRS or HAM-D, a 14-day recency window, or Y-BOCS when Deep TMS treats OCD); evidence of prior psychotherapy sits inside a 14-page inbound fax (inbound-fax.tif) scanned at an angle at 200 dpi; and active coverage identifiers sit in a phone photo of an insurance card (insurance-card.jpg) taken on a kitchen table.

Mapping existing documents is the easy half of Lesson 1. The harder half is the data the clinic never collected — clinical and coverage facts that payers weigh heavily but standard intake forms omit:

Most telehealth and specialty RCM automation fails at this input layer: one payer stored under six string variations, subscriber IDs typed into policy-number fields, diagnoses in free text, and provider credentials buried in spreadsheets. Without canonical input validation (normalizePayer, cleanMemberId, placeOfService), automation is just a fast denial generator. Meanwhile, payers rewrite hundred-page policy PDFs mid-quarter without notice; early on at Foresight, we watched a veteran biller spend four months reverse-engineering by phone the exact code and modifier combinations 21 payers expected for her specialty. Every rule lived in her spiral notebooks.

Automation quality asymptotes to data quality.

2. Rules first, models where the work is reading, people where it's judgment

There is no prize for choosing between deterministic rules and AI. Across our production clinics, deterministic rules handled more than 80% of prior-authorization and revenue-cycle volume: they are fast, free, repeatable to the bit, and trivial to audit. Models belong second, restricted to reading unstructured documents into typed fields. People belong third, where the work is clinical or credentialing judgment.

Tier 1: Deterministic rules (no model, 80%+ of volume)

Because a prior authorization and the claim that bills against it are judged against the same payer rulebook, every encounter ran through five deterministic gates before touching a model:

These rules are public; what breaks in production is reference-data staleness. Every gate depends on an external dataset with its own refresh clock:

Tier 2: Models, where the work is reading

Once deterministic gates pass, models did three reading jobs in our pipeline:

1. Reading doses, dates, and drug classes out of clinical prose. Treatment-resistant depression criteria on Spravato and rTMS require two failed antidepressant trials in the current episode from distinct pharmacologic classes. Keyword search counts sertraline and escitalopram as two drugs; clinical extraction recognizes both as SSRIs (one class), whereas sertraline plus bupropion (an NDRI) counts as two. At the weight-loss clinic, "Is BMI > 30?" was answered deterministically from vitals and Z68.x/E66.x codes, while "Describe prior failure on Metformin" was drafted by a model citing trial dates, dose, and GI intolerance from visit notes.
2. Reading identifiers off pictures and paper. Vision models extracted member IDs, group numbers, and BIN/PCN codes off phone photos of insurance cards, while our document extraction pipeline pulled line-level CPT codes, allowed amounts, and adjustment reasons off paper EOBs and PDF remittances.
3. Reading hundred-page payer policies into structured checks. Models parsed unstructured payer policy PDFs into decision trees checked against diagnoses, labs (HbA1c, lipids), medications, and clinical notes (PA platform). In the infectious-disease clinic's "Submit & Listen" pipeline, structured EHR fields extracted deterministically while models verified ICD-10 and CPT support inside unstructured encounter notes before submission.

Tier 3: People, where the work is judgment

Software cannot enroll a clinician with a payer. Modifiers 25, 59, and XE/XS/XP/XU were never auto-applied to bypass an NCCI edit without an explicit clinic-approved payer rule; high-cost infusion and biologics lines defaulted to supervised mode (audit framework); and a clinician reviewed and signed every prior authorization before transmission.

Automation owns assembly; the clinician owns the clinical content that ultimately reaches the payer.

All three tiers meet when a single incoming 99213 encounter on a commercial PPO fails pre-submission scrubbing in three places at once (claims platform) — missing modifier -25 on a same-day procedure (auto-fixed by Tier 1 rule pack), an unenrolled rendering NPI (routed to a person in the credentialing queue), and a terminated primary policy (resolved automatically via a 270/271 secondary-payer check):

Each fix is logged with the rule that made it. That log is what you show a payer or an auditor.

3. Three answers only

When you compile a payer policy into checks and run it against a chart, what should each check return?

On our commercial rTMS course, the policy approves initial treatment if either Path A (adult unipolar major depression: two failed medication trials across ≥2 classes, baseline severity score, and functional impairment within 90 days) or Path B (retreatment after a prior response) holds in full, provided Safety prerequisites pass. When two checks in Path A evaluate to TRUE, Safety evaluates to TRUE, and the functional-impairment check evaluates to NOT SURE because no note was found in the chart, the entire request collapses to one named task for a clinician: "Add functional-impairment note from the last 90 days." Nobody re-reads the 14-page fax from page one.

Why three answers instead of a 0-to-100% confidence score? Because "87% confident" means nothing to a coordinator staring at a $9,000 treatment course. A floating-point score or colored badge (rules vs. AI architecture) still leaves the operator asking: should I submit this or not?

Instead, every check evaluates under Kleene three-valued logic (true, false, unknown):

type Check = "true" | "false" | "unknown";
function evaluateClause(results: Check[]): "APPROVE" | "REVIEW" | "DENY" {
  if (results.every((r) => r === "true")) return "APPROVE";
  if (results.some((r) => r === "unknown")) return "REVIEW";
  return "DENY";
}

The same gate ran on HIV viral-load monitoring (APPROVE when diagnosis, antiretroviral context, and testing interval verified; REVIEW when the prior lab date was missing from the local EHR, naming that date as the task; DENY when the covered diagnosis was absent). Even where workflows (vendor comparisons, self-pay insurance discovery) exposed a "confidence tier", every extracted field underneath carried a discrete readiness level (1 missing, 2 incomplete, 3 high certainty) where only level 3 drove automation: electronic 835 remittances posted at level 3, while paper EOB scans extracted at level 2 and waited in a verification queue.

Keeping unknown (NOT SURE) strictly separate from false protected the authorization across every stage of the transaction:

Once the clinician signed the functional-impairment note on our rTMS packet, the 278 approved, sessions were delivered against the unit ledger, and the 837P claim went out — archiving the full 837P → 999 → 277CA receipt chain past the 90-day clearinghouse purge window.

Two weeks later, the final test of that prior authorization arrived on the 835 electronic remittance: the ERA reported $12,400 paid across the claims in the batch, but the bank showed an EFT deposit of $11,847. The missing $553 sat in the tail PLB (Provider-Level Balance) segment — prior overpayment recoupments (PLB*WO), forward balances (PLB*FB), interest (PLB*L6), or reversed adjustments (PLB*72) — which claim-level posting (CLP) ignores. That segment is where commercial GLP-1 post-payment audits and retroactive Cigna TMS rate adjustments (via Carelon, MultiPlan, and Evicore) claw back previously authorized care. Without PLB segment parsing, ERA-to-bank matching plateaus near 80%, yet 30 days of 835 files contain only 4–7 distinct PLB03-1 codes. Mapping those codes to deterministic ledger rules and halting any batch where Sum(CLP04) − Sum(PLB) ≠ BPR02 cut monthly reconciliation time at the infectious-disease clinic by 90%.

4. Fix the intake: how downstream verdicts rewrite upstream prior authorization

Why track a prior authorization all the way through claim adjudication and 835 remittance? Because downstream verdicts are the training signal that fixes upstream prior authorizations.

Every incoming 835 and 277CA in our denials and analytics pipeline fed a four-stage loop:

1. Predict: Scrub outgoing prior authorizations and claims against active rule packs before submission.
2. Observe: Ingest 835 and 277CA verdicts at the service-line level (SVC), preserving payer control numbers through posting — because claim-level posting hides line-level denials where an evaluation visit paid but the procedure or drug line denied.
3. Learn: Increment per-payer, per-CPT, per-CARC counters across rolling 30-, 90-, and 365-day windows (~5 hits in 30 days flagged a pattern cluster and ranked it by dollar exposure).
4. Propose: Roughly ten hits drafted a candidate pre-submission rule into the operator queue, where a person approved every rule before it ran.

Running that loop across clinics revealed the central finding of Lesson 4: the root cause of repeated prior-authorization and claim failures was almost always upstream intake data, not the model.

Our largest single measured gain at Foresight came from clustering prior-authorization outcomes at the weight-loss clinic. Approval rates on specific GLP-1 payer cohorts were lagging — not because of prompt phrasing or OCR accuracy, but because those payers weighed cardiovascular comorbidity history heavily and the patient intake questionnaire never asked about it. Across a controlled A/B test of roughly 190,000 patients, adding targeted cardiovascular comorbidity questions to patient intake produced a 56% increase in prior-authorization approval rates without touching the model.

That is the kind of improvement people mislabel as "better AI." It is usually better system design. A bigger model will not solve for a missing intake question; collecting the data will.

Clustering outcomes by payer, procedure code, and failure reason exposed the same upstream pattern across every workflow:

5. Two architectural rules the four lessons add up to

Stepping back, the four field lessons reduce to two architectural requirements: never chain point solutions without shared state, and never automate a decision you cannot audit.

1. Why chained point solutions fail

If three separate tools are each "95% accurate" and chained in sequence, the probability that a request passes all three cleanly is $0.95^3 = 85.7%$. That leaves 14.3% of cases — roughly 1 in 7 — with an error ($1 - 0.95^3 = 14.3%$). Chain five tools at 95% each and 22.6% of all cases fail.

We repeatedly saw clinics running a five-vendor stack: Benefit Check Vendor A → Benefit Check Vendor B → an AI phone-caller → a standalone PA bot → a clearinghouse. Five vendors, zero shared state. When a claim rejected downstream — or when a corrected claim (frequency code 7) denied as a duplicate (CARC 18) because the clearinghouse's remote_claimid (REF*D9), the clinic's trace number, and the payer's original control number (835 CLP07) all disagreed — no tool could say where the error started.

When no tool can say where an error started, staff re-check everything by hand, and the automation savings disappear.

That compounding failure rate explains why 63% of healthcare organizations already use AI in the revenue cycle, yet only 15% of those adopters report a positive return (comparing RCM and ePA vendors). The fix was one pipeline writing to an append-only ledger: querying Stedi, pVerify, Claim.MD, Availity, Optum, authorization unit balances, and live payer calls into a single record with source, scope, and expiration under fixed precedence (live payer call with reference number > 271 response > plan document; two plans are never merged). The same ledger discipline governed self-pay insurance discovery: checking a 42 CFR Part 2 substance-use suppression list first, enforcing a monthly spend cap, purging raw payloads after 90 days, and auto-attaching coverage only at the highest certainty tier.

2. What an audit demands

State utilization-review AI laws and payer post-payment audits do not accept "the model generated that summary." Every automated request in our five-layer verification framework had to produce a complete audit package in minutes: (1) clinical claim grounding to a chart document, page, and timestamp; (2) a timestamped snapshot of the exact payer policy active on the date of service; (3) deterministic cross-validation between CPT/HCPCS and ICD-10 codes against chart evidence (catching BMI Z68.x drift or Spravato two-hour REMS observation windows) with zero silent auto-upcoding; (4) full v1 → v2 resubmission lineage linked to the payer's 835 CLP07 or 277CA control number; and (5) the named clinician's edits and signature timestamp. Any system that cannot answer at least four of the seven verification questions in that framework should not run specialty volume on autopilot — and for the same reason, our live RCM assistant over unpaid claims, pending prior authorizations, and CARC buckets was built strictly read-only with every PHI read logged.

If you automate this work, start here

1. Map where the data lives before you pick a model.
2. Deterministic before probabilistic. Rules for black-and-white gates (80%+ of volume), models only where the work is reading, people where the work is judgment.
3. Three answers only: true, false, or "not sure, and here is the missing item."
4. Route work by the named gap, not by a confidence score.
5. Turn repeated downstream denials into upstream rules — and require a person to approve every rule before it runs.
6. If you couldn't explain the decision to a payer or an auditor, don't automate it.

At the digital weight-loss clinic writing 100,000+ prescriptions a year, putting those six rules into production changed the operation end-to-end:

The two hours of desk work that shadow every hour with a patient are not a law of nature. They are the thing to give back.

Sources: Sinsky et al., "Allocation of Physician Time in Ambulatory Practice: A Time and Motion Study in 4 Specialties," Annals of Internal Medicine (2016); Premier Inc., Hospital Claims Denial Analysis (2025); American Medical Association, Prior Authorization Physician Survey (fielded December 2025) and Physician Practice Benchmark Surveys (2012–2024); KFF, Medicare Advantage Prior Authorization Analysis (2024 CMS data); HFMA / FinThrive, Revenue Cycle Automation Survey (2025); CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F); Noridian Healthcare Solutions, Local Coverage Article A57692 (Billing and Coding: Transcranial Magnetic Stimulation); Evernorth / Cigna Medical Coverage Policy EN0383.