Payer Record Requests: AI Agent vs Biller vs Outsourced

By Jude Lee · · Workflow

Office manager assembling a payer documentation request packet at a clinic back-office desk

The request that arrives on a Tuesday and is due before you notice

A fax lands in the queue. It’s an Additional Documentation Request from your Medicare Administrative Contractor, or a commercial payer asking for records on eight claims, or a dental plan wanting bitewings and a narrative before it will adjudicate a crown. Nobody is assigned to it. It sits in a pile for nine days. Then someone discovers the deadline, drops everything, and spends an afternoon pulling charts.

That pattern — not the difficulty of any single request — is what costs practices money. CMS describes Targeted Probe and Educate as a review process in which MACs select claims for prepayment or postpayment review and request supporting documentation; see the program page at cms.gov/medicare/audits-education/targeted-probe-educate. Critically, the response window is stated in the letter you received — confirm deadlines in your MAC’s letter and instructions rather than relying on what someone remembers from last year or what a vendor assumes is standard. Miss it and the claim is typically denied for non-response, which is the most irritating kind of denial: the money was there, the documentation existed, and the loss was purely operational.

Where an AI agent earns its keep on this workflow

An AI agent, in the sense that matters here, is not a chatbot. It’s an assistant that takes multi-step actions against your systems: read this fax inbox, classify the document, look up these claims in the practice management system, retrieve these chart sections, write a draft, and put it in a review folder. The capability that makes this practical is connecting the assistant to your systems through something like MCP — the Model Context Protocol, an open standard for giving an AI governed, scoped access to specific tools and data instead of pasting records into a chat window.

Concretely, the pieces an agent handles well:

  1. Intake and classification

    Reads the inbound fax or portal download, distinguishes an ADR from a denial letter from a routine records request, and identifies the payer, claim numbers, dates of service, and stated due date.
  2. Tracker entry with a deadline

    Creates a row in whatever you already use — a spreadsheet, a task in your PM system — with the due date and an internal deadline set earlier than the payer’s.
  3. Checklist from the policy

    Turns the payer’s documentation requirements for that service into a plain checklist: signed order, progress note for the date of service, prior conservative treatment, imaging, provider signature and credentials.
  4. Gap check against the chart

    Pulls the relevant records and flags what’s missing or illegible — the unsigned note, the order dated after the service, the referral that isn’t in the chart.
  5. Packet assembly and draft cover letter

    Assembles pages in the requested order and drafts a cover summary that cites page numbers for each required element. A human reviews and signs.

Where it breaks: scanned handwriting, portals with MFA and CAPTCHA that resist automation, and wrong-patient risk when names are similar. And the one true hard stop — an agent must never generate clinical content that wasn’t documented. Addenda and late entries have to follow your documentation policy, be labeled and dated as such, and be authored by the clinician. If an agent’s “gap check” is quietly becoming a drafting assignment, stop and involve your clinician and compliance lead.

An agent that assembles the packet and a human who signs it is a completely different thing from an agent that decides what the chart says.

The three realistic options, side by side

Your biller or office manager does it manually. Full judgment, full accountability, zero integration risk. The failure mode isn’t quality — it’s triage. Requests compete with claim follow-up and the phones, and the pile wins when someone is out. If you get a handful of requests a month, this plus a shared tracker and a per-payer checklist template is probably the correct answer, and you should stop reading about agents and go build the checklist.

Outsource to an RCM or audit-response vendor. You get people who have seen a lot of TPE letters and know what a MAC wants. You give up visibility, and you still supply the records, so your staff time doesn’t go to zero. The specific way this goes wrong is a calendar mismatch: the vendor quotes a standard turnaround built around a 45-day window, your letter gives 30, and the clock is already eight days old by the time the fax is scanned and handed off. Add two days for a records pull your office has to do anyway, a day for a clarifying email about which encounters are in scope, and the buffer is gone. Before signing, ask who signs the cover letter, what turnaround they commit to measured against your letter’s deadline rather than their standard SLA, how they escalate when records don’t arrive, and whether a BAA covers every subprocessor and any AI tooling they use.

Run an AI agent over your own systems. This is the middle path: the agent does retrieval and assembly, your biller does judgment and sign-off. Within that option there’s a real build-versus-buy fork.

Off-the-shelf AI in your EHR/PM or RCM tool
Already under your existing BAA. No engineering. If your PM, EHR, or clearinghouse already ships a records-release or documentation-request feature, that is the cheapest place to start — check the vendor’s own product documentation for what it actually does rather than assuming. Limits: you get the workflow the vendor shipped, it usually only sees data inside that vendor’s walls, and your fax inbox, scanned imaging, and payer policy PDFs may live outside it entirely.
Custom agent connected via MCP
You define the packet standard, and the agent can reach across fax, document storage, PM, and EHR. Costs real setup: scoped credentials, a BAA with your model provider, logging, and someone to own it. Worth it when the same two or three payers send the same request shape every week and the assembly rules are stable enough to write down.

If you build it, build it narrow

A custom MCP server here should expose a handful of read-focused tools — look up claim, fetch encounter note, fetch imaging, list documents for patient — scoped to minimum necessary, with writes limited to creating a draft document in a review queue. Our general view on access design is laid out in the breakdown of read-only, approval-gated, and full-auto permission models.

We’d keep final submission in human hands, and the obvious objection deserves an answer: if you upload forty near-identical bitewing packets a month to the same portal, a human click looks like theater. Two reasons we’d still keep it. First, the submission is effectively an attestation that the enclosed records are the right patient’s and support the service billed — a judgment the agent didn’t make. Second, portal submissions are hard to retract, and a packet sent to the wrong payer or attached to the wrong claim is an impermissible disclosure, not a typo. That’s a compliance event to work through with your privacy officer, and a one-second click is a cheap control against it. If your volume genuinely makes that untenable, batch the review — one person approving twenty queued packets in a sitting is still a human in the loop.

The second building block is a skill: a packaged, reusable instruction set that teaches the assistant to produce the same packet the same way every time — your page order, your cover-letter format, your evidence checklist per payer. A skill is what turns “the AI wrote something” into “the AI produced our standard packet.” On connectivity: certified health IT is required to support standardized FHIR-based APIs under ONC’s 21st Century Cures Act Final Rule, so most practices have some programmatic path into the chart. Dedicated MCP endpoints from clinical software vendors are a different story — in our own evaluations through early 2026 we’ve found them rare, and most builds wrap an existing API or export and treat MCP as the layer above it. Check your own vendor’s developer documentation before assuming either way.

Model the money before you model the agent

Don’t take anyone’s savings figure, including ours. Count your own inputs for one quarter. The three numbers below are invented placeholders to show the arithmetic — overwrite every one of them:

12 / month
Placeholder: documentation requests received — count yours from the fax log and payer portals
Illustrative input, not a benchmark
2.5 hours
Placeholder: staff time per response cycle, including interruption cost to other billing work
Illustrative input, not a benchmark
$32 / hour
Placeholder: loaded hourly rate for whoever does the assembly
Illustrative input, not a benchmark

With those assumptions: 12 × 2.5 = 30 hours a month on assembly, and 30 × $32 = $960 a month, or $11,520 a year, in staff cost. If an agent removes half the retrieval time — your mileage will differ, and you should pilot before assuming it — that’s 15 hours a month returned. The question is what those hours get reallocated to; aged AR follow-up usually beats everything else on the list.

Then add the two line items people forget. Revenue protected: claims under review × your average allowed amount × the share you currently lose to non-response. Error cost avoided: packets that went out missing a signature page and came back denied anyway. Subtract the annual cost of whichever option you’re weighing. If the result isn’t obviously positive at your volume, the honest recommendation is the checklist and the tracker.

What this does to the billing role

The retrieval work shrinks. The judgment work does not. The people who do well through this shift are the ones who move up the stack: reading payer policy, spotting the documentation pattern that’s driving repeat reviews, and feeding that back to clinicians so the next hundred claims don’t get pulled. A practice whose biller spends the day photocopying is at a structural disadvantage. One whose biller spends the day analyzing why the requests keep coming is not.

Start with the smallest version: one payer, one request type, an agent that only reads and drafts, and a human who signs everything. If that runs clean for a month, widen it. If it doesn’t, you’ve spent very little to learn that your real problem was the tracker.

Related reading: the HIPAA-aware MCP build guide and what payer-side AI agents mean for your claims.

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