CoverMyMeds publishes a clear recommendation: start prior authorizations at the point of prescribing, and patients access their medications 13.2 days sooner on average.
Their own provider survey found that just 17% of providers do it.
Five out of six prescribers ignore the vendor's advice, backed by the vendor's own data. The interesting question isn't whether they're wrong. It's whether anyone has written down why they do it — and as far as we can find, nobody has.
The short answer
Waiting produces a better-formed request with less work.
When a pharmacy's claim rejects, the system selects the payer-specific form using the plan and rejection data, populates fields from the live claim, and routes it to the prescriber with an access key. The practice opens a request that is already correct.
Filing prospectively means doing that work yourself — including choosing the form, which is the part that decides whether the submission is considered at all.
Both facts are documented. The vendor publishes the pre-population benefit as a mechanism and the 13.2-day figure as a recommendation. It has never, as far as we can find, published the tradeoff between them.
The form is the product
CoverMyMeds' own support documentation on finding the right request tells users to enter the BIN, PCN, and RxGroup numbers from the patient's insurance card, and states plainly:
"The BIN, PCN and RxGroup numbers will yield the most accurate results. If more than one form populates, choose the one that best fits the patient's circumstance."
Read that carefully, because two things are hiding in it.
First, a human is choosing. "Choose the one that best fits" is a judgment call, made from a list, by someone who may be looking at an insurance card that changed in January.
Second, accuracy depends on identifiers practices don't reliably have. BIN, PCN, and group live on the pharmacy benefit card. They are not part of a standard eligibility check. Practices frequently don't have them current, and the start of a plan year is the worst case — coverage changes, cards are reissued, and patients arrive with last year's information.
A payer-generated request skips this entirely. The form was selected by the system that just adjudicated the claim, using the plan data that produced the rejection. There is no guessing, because the guess already got made correctly by a system with better information.
Staff who do this work report that a mismatched form is rejected without the clinical content being read, requiring a restart. We should be careful here: CoverMyMeds does not publish a specific consequence for form mismatch, and public discussion of BIN/PCN/group errors tends to focus on claim-level misrouting. Treat the rejection account as practitioner experience, not vendor-documented behavior. But note that the vendor's own instruction to choose carefully implies a cost to choosing wrong.
What the 13.2 days doesn't count
The statistic is real. It's also measuring one thing and being read as measuring another.
13.2 days is the time saved on prescriptions that went through prior authorization. It compares prospective initiation against retrospective for requests that happened.
It does not count:
- Prior authorizations filed for prescriptions that would have adjudicated cleanly. No delay avoided, because there was no delay. The work is pure loss.
- Prior authorizations for prescriptions the patient never picked up. Abandonment at the counter happens for cost, for changed minds, for reasons the practice never learns. A prospectively filed request for an abandoned prescription is work done for a fill that never occurs.
- The cost of a wrong form. If a prospectively filed request goes out on the wrong form and comes back to be redone, the delay is worse than waiting would have been.
None of that makes the 13.2 days false. It makes it a numerator without its denominator — a per-request saving that says nothing about how many requests shouldn't have been filed.
This is the same shape of problem we wrote about in denial reporting: a metric that's accurate about what it measures and silent about the cases it structurally cannot see.
When filing early is right
The waiting argument isn't universal, and treating it as a rule would be as wrong as treating the vendor's advice as one.
File prospectively when all three hold:
- You know the drug requires authorization for that plan — not that it usually requires one, but that it does for this coverage
- You have current benefit identifiers, so form selection isn't a guess
- The delay would genuinely harm the patient
Medications with near-universal authorization requirements are the clear case. If a drug essentially always needs approval, the probability of doing unnecessary work is low and the time saved is real.
Wait when:
- Coverage details may be stale, especially early in a plan year
- The drug may not require authorization for that particular plan
- The request would be one of many and staff time is the binding constraint
The honest framing: prospective initiation trades staff certainty for patient speed. That's a real trade with a real winner in some cases, and the vendor's guidance is defensible whenever the patient-speed side dominates. What's missing from the published discussion is that the other side exists at all.
The 83% aren't confused
It's worth saying plainly, because the framing in most industry writing treats retrospective initiation as a failure to adopt best practice.
Five out of six prescribers wait. The explanation offered is usually inertia or lack of awareness. That's a poor explanation for a behavior this consistent among people who do this work daily and whose incentive is to get patients medicated.
The better explanation is that waiting is locally rational and the published metric doesn't capture what it optimizes for. Staff aren't minimizing days-to-medication across all prescriptions. They're minimizing rework on a queue they can't get to the bottom of, with information they know is incomplete.
You can disagree with that priority. You shouldn't mistake it for ignorance.
Where automation actually helps
Notice that the waiting argument is entirely about cost of preparation, not about the clinical decision. That's the part software can change.
Our agents work the payer-generated request: open it by its access key, check which fields arrived pre-populated, fill the remaining fields from the chart, and save a draft for a person to review and submit.
That preserves what makes waiting attractive — the correct form, arriving pre-filled — while removing the part that made it costly, which is a person retyping chart data into a browser form.
It also doesn't submit. That's hard-coded: the agent cannot click anything that sends the request to the plan or routes it to the prescriber, and is built to read even a direct instruction to "submit" as "save the draft." If a required clinical value is missing, it stops and reports instead of guessing. A submitted prior authorization is a clinical and financial assertion to a payer, and that stays with a person.
Whether the calculus should change once preparation is nearly free is a fair question, and we don't have data on it yet. It's the kind of thing we'd want to measure before claiming.
Frequently Asked Questions
Should you start a prior authorization before the pharmacy requests one?
It depends on what you are optimizing for, and reasonable people disagree. CoverMyMeds publishes research that patients access medications 13.2 days sooner when requests are initiated prospectively at the provider's office. But their own provider survey found only 17% of providers do this, and the reason is that a payer-generated request arrives with the correct form already selected and fields pre-populated from live claim data, while a prospectively filed request requires staff to choose the form themselves from benefit identifiers they may not have current.
Why do most providers wait for the pharmacy to start a prior authorization?
Because waiting produces a better-formed request with less work. When a pharmacy claim rejects, the system selects the payer-specific form from the plan and rejection data and auto-populates fields from the claim. Filing prospectively means selecting the form manually using the BIN, PCN, and group numbers from the patient's pharmacy benefit card, which practices frequently do not have in current form, particularly at the start of a plan year when coverage changes.
What does the 13.2 days sooner statistic actually measure?
It measures time to medication access among prescriptions that went through prospective prior authorization compared with retrospective. It does not measure the staff cost of prior authorizations filed for prescriptions that would have adjudicated without one, or for prescriptions a patient never picked up. Those cases produce no time saving because there was no delay to avoid, and the work still had to be done.
How is the correct prior authorization form selected?
CoverMyMeds instructs users to enter the BIN, PCN, and RxGroup numbers from the patient's insurance card, stating those numbers yield the most accurate results and that if more than one form populates, the user should choose the one that best fits the circumstance. When a request is generated from a pharmacy claim rejection instead, the system selects the form using the plan and rejection data rather than requiring a person to choose.
What happens if you submit the wrong prior authorization form?
Staff who do this work report that a mismatched form is rejected without the clinical content being considered, requiring the request to be restarted on the correct form. CoverMyMeds does not publish a specific consequence for form mismatch, and industry discussion of BIN, PCN, and group errors focuses on claim-level misrouting and denials, so treat the operational account as practitioner experience rather than vendor-documented behavior.
When does filing a prior authorization prospectively make sense?
When you already know the drug requires authorization for that plan, you have current benefit identifiers, and the delay genuinely harms the patient. Medications with near-universal authorization requirements are the clearest case, since the probability the request turns out to be unnecessary is low. The calculation changes when a practice cannot confirm current coverage details or when the medication may not require authorization for that particular plan.
Can prior authorization work be automated?
The preparation can be. An agent can open a payer-generated request by its access key, verify which fields arrived pre-populated, fill remaining fields from the chart, and save a draft for review. What should not be automated is submission, because a submitted request is a clinical and financial assertion to a payer. Our agents are prohibited from submitting and stop to report when a required clinical value is missing rather than guessing.
What to do next
Take last month's prior authorizations and split them two ways: which were filed prospectively, and of those, how many turned out to be unnecessary — either the claim would have gone through, or the patient never filled it.
If that second number is small, file early; the vendor's advice fits your situation. If it's large, you now know what waiting is buying you, and you can say so when someone tells you that 83% of your peers are doing it wrong.
Related: why the refill and the prior auth are the same fax, and why a refill request isn't a task at all.
