A physician writes a prescription. The pharmacy tries to fill it. The claim rejects because the plan requires prior authorization. That rejection generates a request that arrives back at the practice as a fax.
Same patient. Same drug. Same clinical decision. Two separate documents, days apart, in the same pile as everything else.
The short answer
The refill and the prior authorization are one event wearing two documents. Neither one announces which it is until someone opens it.
CoverMyMeds documents the mechanism in their own materials: when a pharmacy's claim rejects for prior authorization, the pharmacy's system sends the rejection to CoverMyMeds, which uses the plan and rejection data to select the proper form, auto-populate fields, and share the request with the prescriber. The practice receives a fax carrying a short alphanumeric key, and staff enter that key with the patient's last name and date of birth to open a partly pre-filled request.
This isn't an edge case. It's the dominant path. CoverMyMeds' own provider survey found just 17% of providers start a prior authorization at the point of prescribing — meaning roughly five out of six requests originate downstream, from a rejection nobody at the practice saw happen.
What this looks like from the inbox
We asked a staff member at a specialty practice how she identifies what's in front of her. Her description of the process:
She opens each fax and determines whether it's a prior authorization notification, a refill request, or an approval for something already submitted.
Three different jobs, one queue, no way to tell them apart without reading each one. When a patient calls saying they need a medication urgently, the search is manual — through a stack of documents that all look identical from the outside.
That's the actual cost, and it isn't the typing. It's that the document carrying urgency looks exactly like the twenty that don't.
Why one event produces two documents
The two documents come from different systems answering different questions:
| Document | Asks | Sender |
|---|---|---|
| Refill request | Will you authorize another fill? | Pharmacy, to the practice |
| Prior authorization request | Will the plan pay for it? | Generated by claim rejection, routed to the prescriber |
A practice can answer the first and still have the patient leave empty-handed, because the second hasn't been answered yet. From the patient's side there's one question — can I get my medication — and it's being adjudicated in two places that don't know about each other.
There's often a third document: the outcome, arriving later as an approval or denial, through the same channel, looking much like the first two.
And a device follows a different path entirely
The routing changes again for continuous glucose monitors and durable medical equipment, in a way that catches practices out.
Under a pharmacy benefit, these typically route through electronic prior authorization tools like the drugs do. Under a medical or DME benefit, they don't. CMS documentation for DMEPOS prior authorization identifies the supplier, not the prescriber, as the requester. Some payers say so directly to physicians — one plan's provider FAQ for CGM products states that determinations are made on requests submitted by contracted DME suppliers, and that as the prescribing provider, you don't need to submit a prior authorization request at all.
Which path applies depends on how a specific plan assigns the benefit. The same device can follow different routes for two patients seen the same morning. So "we handle prior auth" is an incomplete claim unless it specifies which benefit — the pharmacy path and the DME path share a name and almost nothing else.
What we built for it
Our inbox triage agent reads every inbound fax, voicemail, and email and classifies it before a person sees it. Refill requests and prior authorization requests are separate categories with separate priorities, because they are separate work — and the classifier distinguishes an incoming prior authorization request from the notification announcing its outcome, since those are different jobs too.
It escalates on clinical signals rather than document type: a patient reporting they're out of medication, an authorization approaching expiry, insulin or pump supplies, a caller who has already called once with no response.
When it identifies a prior authorization with an access key, a human queues it and a downstream agent takes over: open the request by key, check what the payer already populated, fill the gaps from the chart, and save a draft.
It does not submit. That's hard-coded — the agent is forbidden from clicking anything that sends the request to the plan or routes it to the prescriber, and is built to interpret even a direct human instruction to "submit" as "save the draft." If a required clinical value is missing, it stops and reports rather than guessing.
The person still decides and still sends. What they stop doing is retyping information that already exists in two other systems.
What this doesn't fix
Classification reads the document. It does not open the chart.
It knows a prior authorization arrived for a specific drug and how urgent it is. It doesn't know whether the patient is overdue for the labs that justify the therapy, or whether the request should have prompted a clinical conversation instead of an approval. That's a different capability, and we're building it rather than claiming it.
It also doesn't fix the two-document problem at its root. That's structural. The pharmacy adjudicates against the benefit and the practice authorizes the clinical decision, and those will remain separate acts generating separate paper. What routing does is stop the second document from arriving as a surprise.
Frequently Asked Questions
Who initiates a prior authorization, the doctor or the pharmacy?
Most often the pharmacy, indirectly. CoverMyMeds documents that when a pharmacy's claim is rejected because prior authorization is required, the pharmacy's dispensing system can send the rejection to CoverMyMeds, which uses the plan and rejection data to select the proper form, auto-populate fields, and share the request electronically with the prescriber. CoverMyMeds' own provider survey found only 17% of providers start a prior authorization at the point of prescribing, meaning the large majority of requests originate downstream of a rejected claim.
What is a CoverMyMeds key and how does a practice get one?
It is a short alphanumeric code that uniquely identifies a specific prior authorization request. When a pharmacy starts a request for one of your patients, the practice receives a fax containing that key, and may also get an email notification. Staff enter the key along with the patient's last name and date of birth to open the request, which arrives partly pre-populated from the pharmacy's claim data.
Why does the same prescription generate two separate documents?
Because the refill authorization and the prior authorization are handled by different systems at different moments. The pharmacy first asks the practice to authorize the refill, and separately, when the pharmacy attempts to adjudicate the claim, a rejection can generate a prior authorization request that returns to the practice as its own fax. One clinical decision produces two pieces of paper, often days apart, arriving through the same channel as everything else.
How do practices tell a refill request from a prior authorization request?
Traditionally by opening the document and reading it, because both arrive as faxes in the same queue with no distinguishing envelope. The difference matters because they carry different urgency and different work. Automated classification can separate them by matching layout and content patterns, such as the presence of an access key, the sending pharmacy's form structure, or headers indicating a response is required.
Why do prior authorization requests get missed in a medical practice?
Because they arrive undifferentiated among dozens of other faxes, and nothing about their arrival signals urgency. A prior authorization sitting unopened means a patient is not receiving a medication their physician already prescribed, and if the request is a denial with an appeal window, the clock is running while the document sits. The failure is rarely a decision to deprioritize it and almost always a failure to notice it.
Does the prior authorization for a CGM or DME work the same way as for a drug?
No. Under a pharmacy benefit, requests typically route through electronic prior authorization tools such as CoverMyMeds. Under a medical or durable medical equipment benefit, Medicare documentation identifies the supplier rather than the prescriber as the requester, and some payers state explicitly that the prescribing provider does not submit the request at all. Which path applies depends on how the specific plan assigns the benefit, which is why the same device can follow different routes for different patients.
Can an AI agent handle prior authorization paperwork?
It can prepare the work, and that is where we draw the line. An agent can open a request by key, check which fields the payer already populated, fill in what is missing from the chart, and save a draft. Our agents are explicitly prohibited from submitting to the plan or routing to the prescriber, and are built to interpret even a direct instruction to submit as an instruction to save the draft, so a person reviews and sends every request.
What to do next
Pull last week's faxes and sort them into three piles: refill requests, prior authorization requests, and outcomes of requests you already sent. Then check how many of the third pile you'd already chased by phone.
That number is what the two-document problem costs you.
Related: why a refill request isn't a task at all, and why experienced staff wait for the payer's request instead of filing early.
