Every vendor selling refill automation is answering the same question: what percentage can you auto-approve?
It's the wrong question, and you can see why from a single sentence a staff member said to us while walking through her actual workflow:
"I open each one up and I see if it's something from CoverMyMeds, or if it's a refill request, or if it's an approval for something we already did."
Three completely different jobs, indistinguishable until a human opens the document. The refill request has no identity until someone reads it.
The short answer
A refill request is not a task with an approval rate. It's a trigger that resolves into one of at least six different workflows:
| Outcome | What actually has to happen |
|---|---|
| Approve | Confirm the medication matches the chart and monitoring is current, then authorize |
| Bring the patient in | Schedule a visit or order labs first, then authorize |
| Change the prescription | Clinical decision: adjust the dose, switch the drug, or stop it |
| File a prior authorization | The payer has to say yes before the pharmacy can dispense |
| Reconcile | The pharmacy's request doesn't match the chart, or it's a duplicate |
| Redirect | Wrong prescriber, or the patient isn't established |
Only the first row is "approving a refill." An automation rate measures performance on one row and stays silent about the other five — which is where both the clinical risk and the staff time live.
The number you'll see quoted, and why we're not quoting it
Search for refill benchmarks and you'll find confident figures attributed to MGMA: refills per provider per week, the share that's "fully automatable," staff hours consumed. We went looking for the sources.
We could not locate them in any MGMA publication. They appear on vendor blogs — companies selling refill automation — citing MGMA without a report, table, or date. One such statistic claims a specific percentage of practices find their auto-approval rate falls short of what vendors projected, which is a conveniently self-serving thing to attribute to a trade association.
What MGMA does publish freely is a March 2026 Stat poll of 294 practice leaders asking which phone task consumes the most time:
- Eligibility and prior authorization — 45%
- Scheduling — 31%
- Intake — 9%
- Prescription refills — 6%
Refills came last. That's the real data, and it's inconvenient for anyone selling a refill product — including us. We think it's explained by the taxonomy above: refills rank low as a phone task because the moment one becomes real work, it has already turned into something else. Usually prior authorization, the item ranked first.
We wrote a whole post on how to verify an AI vendor's claims. Citing an unsourced number would fail our own test.
What our classifier actually does
We run an inbox triage agent in production at Valley Diabetes & Obesity, a specialty practice that also serves as our live testing environment. The current version was refined against 454 real faxes and 93 real voicemails, and has run roughly 3,000 times.
It classifies every inbound fax, voicemail, and email into one of 43 categories — 19 for fax, 15 for voicemail, 9 for email.
Six of those categories are refill requests wearing different clothes:
| Channel | Category | What it actually is |
|---|---|---|
| Fax | Prescription Refill Request | Pharmacy asking for authorization |
| Fax | Prior Authorization Request | The same drug, now needing payer approval |
| Fax | Pharmacy New Rx / Clarification | Pharmacy wants an alternative or a clarification |
| Fax | DME / Supply Order | CGM sensors and pump supplies — a different form entirely |
| Voicemail | Prescription / Medication Request | The patient calling about the same medication |
| Prior Auth Notification | The outcome coming back |
These are separate categories because they need separate handling and carry different urgency. A refill authorization form is routine. A prior authorization with an appeal deadline is not. They can concern the identical prescription for the identical patient in the same week.
Why the refill and the prior auth are the same event
This is the part that surprised us when we mapped it.
The practice doesn't file most prior authorizations because it decided to. The sequence runs:
- The physician prescribes
- The prescription goes to the pharmacy
- The pharmacy attempts the fill, and the claim rejects
- That rejection generates an electronic prior authorization request
- It arrives back at the practice as a fax with an access key
- Someone has to notice it, open it, and recognize what it is
The refill and the prior authorization are one clinical event arriving as two documents, often days apart, through the same fax line as everything else.
And there's a reason nobody gets ahead of it. We asked whether the practice ever pre-files a prior authorization for a drug they know will need one. The answer was no — and the reasoning was correct. The payer-generated request arrives pre-filled with the right form, and the form is the thing that matters. Pick the wrong one and it's rejected outright without being read. Form selection depends on pharmacy benefit identifiers that the practice often doesn't have current, especially in January when plans change.
So waiting is the rational strategy. Any vendor promising to "get ahead of your prior auths" is proposing something an experienced person already considered and rejected for good reasons.
Where classification stops
Here is the boundary, stated plainly, because it's the part most vendor descriptions blur.
Our classifier reads the document. It does not open the chart.
It knows a refill request for a specific medication arrived from a specific pharmacy, how urgent it is, and who should handle it. It does not know the patient is ninety days overdue for an A1C, that the dose was supposed to be titrated in March, or that this drug was supposed to be stopped.
That's a real limitation with real consequences — published data suggests roughly a third of refill requests carry a clinical finding, and document classification cannot see any of it. Chart-aware routing is something we're building, not something we're claiming.
What we do have is the escalation logic, which is clinical rather than clerical:
- Patient reports being out of medication → HIGH
- An existing authorization may expire → HIGH
- Insulin or pump supplies → escalated
- Repeat caller with no response to the first message → escalated
That last one exists because someone was calling twice.
The system declines to guess
Every classification carries a confidence score. Below the threshold, the message is marked Uncategorized and routed to a human with an explanation rather than assigned a category.
The example in our own skill definition is the genuinely hard case: a fax containing both a refill request and medication adherence data, where it's ambiguous whether the pharmacy is requesting action or sending an advisory report.
A system that declines to classify is more useful than one claiming high accuracy, because you can act on "I don't know." You cannot act on a confident wrong answer you have no reason to check.
Two rules in our pattern library exist purely as scar tissue:
- A pharmacy supply order listing CGM sensors is a refill request, not a DME order — unless it carries a CMN form number
- An adherence report with fill-history scores is a refill request only if it asks for action; otherwise it's advisory
Both exist because we got them wrong on real documents first.
What happens after classification
Classification isn't the product. It's the routing layer, and its value is entirely in what it hands off to.
When the triage agent identifies a prior authorization with a CoverMyMeds key, a human queues it, and a downstream agent opens the request by key, checks the pre-populated fields, fills in what's missing from the chart, and saves it as a draft.
It does not submit. That's an explicit, hard-coded rule — the agent is forbidden from clicking any button that sends the request to the plan or routes it to the prescriber, and it's instructed to interpret even a direct human instruction to "submit" as "save the draft." If it can't complete the form because a required clinical value is missing, it stops and reports rather than guessing.
Two humans stay in the loop: one queues the work, one reviews and submits it. The agent does the typing and the copying between systems — which is the part that took an hour and had nothing to do with anyone's clinical judgment.
Other agents will follow the same pattern. That's the architecture: one classifier at the front door, specialized agents behind it, a human at every decision point. It's also why buying each agent separately doesn't work — a standalone refill bot has nowhere to hand off to. It can do row one of that table and abandon the other five, with the context already thrown away.
Frequently Asked Questions
What percentage of prescription refills can be automated?
This is the wrong question to optimize against, and the figures circulating online are unreliable. Many blogs attribute precise automation rates to MGMA that do not appear in any MGMA publication we could locate. More importantly, an auto-approval rate only describes requests where approval was the correct answer. It says nothing about requests that should have triggered a lab order, a dose change, a prior authorization, or an appointment, which is where both the clinical risk and the staff time actually sit.
What are the different outcomes of a prescription refill request?
At least six. Straightforward approval; approval only after the patient comes in for a visit or labs; a clinical decision that the medication should be changed, adjusted, or stopped; a prior authorization that must be filed before the pharmacy can dispense; a reconciliation problem where the pharmacy's request does not match the chart; and a redirect because the request belongs to a different prescriber or is a duplicate. Each is a different workflow with a different owner.
Why does a refill request turn into a prior authorization?
Because the prior authorization is usually generated by the pharmacy's failed fill attempt, not by the practice. The prescription is sent, the pharmacy runs it against the patient's benefit, the claim rejects, and that rejection generates an electronic prior authorization request that arrives back at the practice as a fax. The refill and the prior authorization are the same clinical event arriving as two separate documents, often days apart.
How does an AI inbox triage agent classify a refill request?
By reading the document and matching it against known patterns: the sending pharmacy's form layout, headers such as RESPONSE REQUESTED, the presence of a CoverMyMeds key, or whether a supply order carries a CMN form number. Our production classifier assigns a category, a sub-type, a priority, and a confidence score, and extracts patient identifiers and medication details into structured fields. When confidence falls below a threshold it declines to classify rather than guessing.
Can an AI agent approve prescription refills automatically?
It should not, and ours does not. Classification determines what kind of request arrived and how urgent it is, then routes it to a person. Downstream agents can prepare work such as filling out a prior authorization form, but the terminal action is saving a draft for human review rather than submitting it. The clinical decision and the submission both stay with a licensed human.
What should never be automated in a refill workflow?
Controlled substances are the clearest boundary, because they carry prescriber-identity, PDMP-check, and refill-limit requirements that sit outside routine protocol handling. Published pharmacist-managed refill protocols also exclude medications for acute conditions, pain medications, and antibiotics, because a refill request for an acute course usually signals that something did not resolve rather than that a renewal is due.
Why do refill requests arrive through so many channels?
Because every party involved uses a different one. The pharmacy faxes a refill authorization form, the patient leaves a voicemail or sends a portal message, the benefit manager emails a prior authorization notification, and durable medical equipment suppliers use their own ordering platforms. The same underlying request for the same medication can arrive three separate times through three separate channels, which is why deduplication has to happen before anyone counts volume.
What to do next
Before evaluating any refill automation, count your own outcomes. Take fifty refill requests from last month and sort them into the six rows above. You will know within an afternoon whether an auto-approval rate describes your problem.
Then ask any vendor the only question that matters: what happens to the ones you can't approve? If the answer is "they go to a queue," you've bought a sorter, not a solution.
We wrote up what the clinical evidence says about those requests, and how a specialty practice's inbox actually behaves over ten months.
