Prior authorization fails in the gap between the order and the payer, not inside the EMR. The fix, in order, is: name an owner for every authorization, make the authorization a discrete tracked object rather than a note or a fax in someone's pile, and only then ask the software to remove keystrokes. Buying a prior-auth module before you have fixed ownership just gives an unowned process a nicer interface.
Where prior auth actually breaks
- Nobody owns it. The order is placed, and the authorization becomes everybody's problem, which is to say nobody's.
- The requirement is discovered late. At scheduling if you are lucky, at check-in if you are not, with the patient already in the waiting room.
- Status lives in a person's inbox. Or a fax tray, or a sticky note. When that person is on vacation, the authorization does not exist.
- The clinical documentation is not attached. The note that justifies the service is in the chart, and the authorization request goes out without it, guaranteeing a round trip.
- Nothing tells you an authorization is aging. No worklist, no queue, no alert. You find out it stalled when the patient calls.
- The approval never reaches the claim. The authorization was granted, the number sits in a scanned document, the claim goes out without it, and you get denied for a service you were authorized to perform. This is the most infuriating one, and it is entirely preventable.
Assign ownership before you touch the software
Name a role, not a person, so the process survives resignations. Then write down the handoffs explicitly:
- The ordering provider attaches the clinical rationale at the time of the order. Not later, not on request.
- The authorization coordinator owns the request from submission to decision, and owns the next-action date at every step.
- Scheduling does not book the service until status is approved, or until someone with named authority documents a decision to proceed at risk.
- Define "proceed at risk" and who may authorize it. Practices that never define this end up doing it accidentally, repeatedly, and then discovering the pattern in their write-offs.
What the EMR should be doing for you
| Capability | What good looks like | How to test it in the demo |
|---|---|---|
| Authorization flag on the order | Placing an order for a service that requires authorization automatically generates a task, based on payer and service rules you can configure yourself | Ask them to place such an order live and show the task appearing |
| Authorization as discrete data | Authorization number, effective and expiration dates, visits or units approved, and status are structured fields, not free text in a note | Ask for a report of every authorization expiring in the next fourteen days |
| A worklist | A queue sortable by days pending, owner, and payer, with an aging view | Ask to see an item that has been pending ten days, and how it surfaces |
| Document attachment | Attach the relevant note or imaging to the request without rekeying anything | Watch them do it end to end, without cutting away |
| Authorization number flows to the claim | It auto-populates on the claim, and the claim is stopped if it is missing | Ask what happens if you try to bill an authorized service without the number |
| Decision capture | The decision, and the specific denial reason, land in the chart rather than only in a fax queue | Ask where a denial reason is stored and who is notified |
| Expiration alerts | Alerts before a visit count or date expires, which matters enormously in therapy and behavioral health | Ask to see the alert, not the roadmap slide about the alert |
What CMS-0057-F changes, and what it does not
CMS released the Interoperability and Prior Authorization final rule, CMS-0057-F, on January 17, 2024. It is worth understanding precisely, because it is routinely oversold to practices.
- It applies to payers, not to you. The obligations fall on impacted payers. It does not require your practice or your EMR to do anything.
- It does not cover every payer. Impacted payers are Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs and managed care plans, and qualified health plan issuers on the federally facilitated exchanges. Most employer-sponsored commercial plans are not impacted payers under this rule. It will not fix your whole authorization workload.
- The timeline is staged. Per CMS, impacted payers are required to implement certain provisions beginning January 1, 2026, and have primarily until January 1, 2027 to meet the application programming interface requirements.
- What it adds. A FHIR-based Prior Authorization API, a Provider Access API, a Payer-to-Payer API, an expanded Patient Access API, shortened decision timeframes, a requirement that payers give a specific reason for a denial, and public reporting of prior authorization metrics by payers. Check the CMS fact sheet for the exact decision timeframes that apply to a given payer type.
- A useful piece of trivia. CMS's National Standards Group issued an enforcement discretion statement so that covered entities implementing an all-FHIR-based prior authorization API are not pursued for declining to use the X12 278 standard. If a vendor tells you a FHIR prior-auth workflow is impossible because of X12, that is worth a follow-up question.
- What it does not do. It does not eliminate prior authorization. Payers still decide what requires it.
Questions for your EMR vendor
- Do you support, or have a committed date to support, the FHIR-based Prior Authorization API workflow described in CMS-0057-F?
- Is the authorization number a discrete field, and does it flow automatically onto the claim?
- Can we report on pending authorizations by age and by payer, without a custom report request?
- Is prior authorization included in our license, or an add-on with its own fee and its own implementation?
Tracking that survives turnover
- Everything lives in the system. Never a personal inbox, never a paper tray, never a spreadsheet on one person's desktop.
- Every authorization has an owner and a next-action date. An authorization with no next-action date is not being worked, it is being hoped about.
- A ten-minute queue review every morning, and an aging review every week.
- A written payer cheat sheet covering which payers require authorization for the services you actually perform, owned by a named role and reviewed quarterly. Payer rules change constantly, and an unowned cheat sheet is stale within two quarters and actively harmful within four.
Metrics worth watching
- Authorizations pending more than seven days: the count, and the age of the oldest.
- Share of authorization-required services identified before scheduling, versus at check-in.
- Denials attributed to a missing or invalid authorization. This number should approach zero. If it does not, your authorization numbers are not reaching your claims, and no amount of faster submission will fix that.
- Appointments rescheduled or cancelled because an authorization was still pending.
- Turnaround time by payer.
The takeaway
Prior authorization is an ownership and tracking problem wearing a technology costume. Name the owner, make the authorization a discrete object with a status and a next-action date, force the authorization number onto the claim automatically, and measure denials caused by missing authorizations until that number is near zero. Understand CMS-0057-F accurately, including the fact that it binds your payers and not you, and that it leaves most commercial plans untouched. A worklist with a named owner beats an unowned API integration every single time.
Common questions
Does CMS-0057-F apply to commercial insurance?
Generally no. The rule applies to Medicare Advantage organizations, Medicaid and CHIP fee-for-service and managed care plans, and qualified health plan issuers on the federally facilitated exchanges. Most employer-sponsored commercial plans are not impacted payers under it.
When do the CMS-0057-F requirements take effect?
Per CMS, impacted payers must implement certain provisions beginning January 1, 2026, and have primarily until January 1, 2027 to meet the API requirements. Confirm the specifics for a given payer on the CMS rule page.
Will the rule end prior authorization?
No. It standardizes and accelerates parts of the process, requires impacted payers to give a specific denial reason, and requires them to publicly report prior authorization metrics. The decision to require authorization for a service remains with the payer.
Should we fix the workflow or buy a prior-auth module first?
Fix ownership and tracking first. If nobody owns an authorization and nothing tells you it is aging, a new module will simply automate an unowned process.