Prior Auth Tracking: EHR Fields vs AI Agent vs Manual

By Jude Lee · · Comparison

Office manager and colleague reviewing an authorization tracking list on a computer screen in a small clinic

The expensive half of prior authorization isn’t the submission

Submitting the request is a discrete, visible task. Somebody owns it. The part nobody owns is what happens over the following ninety days: a behavioral health client approved for 12 sessions books a 13th; a PT auth expires on the 30th and the patient is on the schedule for the 2nd; the auth names Dr. A but the patient sees the covering NP; the approved CPT is 97110 and the note supports 97140.

Each of those becomes a denial you find out about six weeks later, when the appeal window is tighter and the clinical documentation is colder. If you’ve already read our take on AI denial triage versus scrubber rules, this is the upstream version of the same problem: it is dramatically cheaper to catch an auth mismatch the day before the visit than to appeal it after.

What each approach actually catches

Three options, honestly described.

The spreadsheet. A tab with patient, payer, auth number, approved units, date range, and a running count. It works — right up to the point where one person is out for a week, or somebody forgets to decrement after a visit. The failure mode isn’t stupidity, it’s that the spreadsheet is a second system that has to be hand-fed from the first one.

PM/EHR authorization fields. Most practice management systems have an authorization record you can attach to a case, with units and a date range, and some will warn at check-in when units are exhausted. If your PM does this well and your staff enter auths consistently, you may not need anything else. Use it before you buy anything.

An AI agent over your practice data. A scheduled agent that reads scheduled appointments, billed claims, and auth records, reconciles them against each other, and produces a short exception list for a human each morning. The agent’s advantage isn’t intelligence — it’s that it reconciles three sources nightly without getting bored.

PM/EHR authorization module
Already under your BAA. Enforces at the point of check-in. Zero new vendors. But: it only knows what staff typed in, counts units the way the vendor decided to count them, and usually can’t tell you “this auth names a provider who isn’t on next Tuesday’s schedule.” Reports are static and someone has to run them.
Scheduled AI agent over the same data
Cross-checks the schedule, the ledger, and the auth record; can read a scanned approval letter and compare it to what was keyed in; drafts the renewal packet with the right clinical attachments. But its errors are quieter than a report’s: it can misread “12 units” as “12 visits” off a low-quality fax, treat a superseded auth record as the current one, or return a clean-looking exception list that silently omits every patient from a payer whose nightly data export failed. It also needs governed access to your data, it adds an oversight job, and it cannot log into a payer portal or sit on hold for you.
An authorization agent is not an approval machine. It is a reconciliation machine with a drafting habit — and that is a narrower, far more reliable thing to buy.

How the agent is actually wired

This is where the plumbing matters. An AI assistant like Claude doesn’t natively know your schedule. You connect it through MCP — the Model Context Protocol, an open standard for giving an AI governed, auditable access to specific tools and data. MCP is an open specification rather than one vendor’s proprietary connector, so the server you build is portable in principle — but verify your assistant vendor’s current MCP support, and the terms under which it can touch PHI, before you commit to it as of 2026.

  1. Expose four read-only queries, not your database

    A custom MCP server over your PM data should offer narrow tools: list_active_authorizations, list_scheduled_visits_in_range, list_billed_visits_for_auth, get_auth_document. Minimum necessary, enforced in code — not in a prompt. Our guide to connecting Claude to an EHR via MCP covers the BAA and access-scoping groundwork.

  2. Define the reconciliation as a skill, not a prompt

    Write the logic once as a packaged skill: how your practice counts units versus visits, which modifiers consume an auth, what the renewal lead time is per payer, what counts as an expiring auth. Same rules every run, versioned, reviewable by your biller.

  3. Run nightly and produce an exception list

    Output is a short list: auths with fewer than N units remaining against upcoming scheduled visits, auths expiring within your lead time, visits scheduled with a rendering provider not named on the auth, and code-level mismatches — the auth document approves 97110 but the scheduled or billed service is 97140, or the approved code set simply doesn’t include what the clinician plans to do.

  4. Let it draft, let a human send

    The agent assembles the renewal or continued-authorization packet — dates of service used, progress notes, outcome measures, the specific medical-necessity language that payer tends to accept — and stops. A human reviews and submits. Keep writes out of the loop early on; see the read-only vs approval vs full-auto permission models for how to stage this.

  5. Log every run, and alarm on silence

    Store what the agent read, what it flagged, and what the human did with it. Build in a mechanical sanity check that runs every night, not just a weekly human spot-check: did each source query return any rows at all, is the payer list complete, is the record count within range of yesterday’s? An empty exception list should trigger a “prove the pipeline ran” alert, because the most dangerous failure here looks exactly like good news. Weekly, have your biller re-verify a sample of flags against the source documents.

Modeling whether it’s worth building

You have the inputs; we don’t. Fill these in from your own data before anyone quotes you a price.

(visits/mo denied for auth issues) × (avg allowed amount)
Monthly leakage — pull the denial codes from your clearinghouse
Illustrative formula
(hrs/wk on auth tracking) × 52 × (loaded hourly rate)
Annual labor currently spent reconciling — your numbers
Illustrative formula

The recovered-hours side only counts if those hours go somewhere that produces value — filling cancellations, working aged AR, actually answering the phone. If the hours just evaporate into general slack, the honest ROI is the denials avoided and nothing more. Say that out loud when you build the case.

Choosing without overbuying

If you run a handful of auths a month, use your PM fields and a check-in prompt. The spreadsheet is fine at that volume and a custom build is a hobby, not an investment.

If you’re a behavioral health, PT, chiropractic, or specialty practice carrying dozens of live authorizations with unit counts, your PM’s static reports will reliably miss the cross-system mismatches — and that’s the specific gap an agent fills. Check first whether your PM vendor already ships an auth-tracking AI feature; if it covers your payers and your unit math, buy it and move on. The case for custom is usually that your counting rules are idiosyncratic, your auth documents arrive as scans, or your PM’s data is reachable only through an export.

And if your real bottleneck is submitting authorizations rather than tracking them, start there instead — our piece on prior authorization automation with AI agents is the better entry point.

Not sure where to start?

Get a free automation audit: we map your scheduling, intake, insurance, billing, and patient communication and show you what's worth automating — before you spend a dollar.

Get a free automation audit

Related guides