In January 2024 CMS finalized the Interoperability and Prior Authorization rule, CMS-0057-F, with two sets of deadlines. The first arrived on January 1, 2026: impacted payers must decide standard prior authorization requests within seven calendar days and expedited ones within 72 hours, must give a specific reason for every denial, and had to publish their first annual authorization metrics by March 31 of this year. The second set arrives on January 1, 2027, and it is the technical one: the payers must offer a prior authorization API built on the HL7 FHIR standard that lets a practice's EHR find out whether authorization is required, what documentation is needed, submit the request and receive the decision without leaving the record. The same date brings the Provider Access API, which lets a practice pull a patient's claims and clinical data from the plan, and the Payer-to-Payer API for patients who switch plans.
Separately, on June 23, 2025, AHIP and the Blue Cross Blue Shield Association announced commitments from roughly fifty health plans covering about 257 million people to reduce and standardize prior authorization. Several of those commitments, including standardized electronic submissions through FHIR APIs and real-time answers for at least 80 percent of electronic requests with complete documentation, are dated to January 2027. In April the two associations reported that participating plans had eliminated 11 percent of authorizations, about 6.5 million fewer requests, with Medicare Advantage volume down more than 15 percent. Aetna says it has standardized 88 percent of its authorization volume; UnitedHealthcare says more than half, with 70 percent by the end of 2026; Cigna expects more than 70 percent by year-end. UnitedHealthcare also said on May 5 that it would remove authorization requirements for 30 percent of services by the end of the year.
So a lot is supposed to happen in the next five months. Here is our honest assessment of what will change on the practice side and what will not.
Key takeaways
- The rule obligates payers to build the API. It does not obligate your EHR vendor to connect to it. The vendor question is the one that decides whether January changes anything for you.
- Plan for a mixed environment through 2027: some payers and some services electronic, the rest on portals and fax.
- The technology speeds up whatever process you have. Orders on paper, documentation in free text and stale portal logins will slow it down.
- Keep your own turnaround log. Payer-published metrics are annual and aggregated; yours are the only practice-level data.
Which payers are covered
CMS-0057-F applies to Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid and CHIP managed care plans, and qualified health plan issuers on the federally facilitated Marketplaces. It does not apply to employer-sponsored group plans, which are governed by state law and contract, or to Original Medicare, which has its own WISeR process in six states. The AHIP pledge covers commercial business at the participating plans, so between the two, most of a typical practice's authorization volume is in scope for something. Not all of it, and not on the same timeline.
What changes, realistically
| Today | After January 1, 2027 (if payers and vendors deliver) |
|---|---|
| Staff look up whether a code needs authorization on a payer portal or a PDF | The EHR queries the payer's coverage requirements API at order entry and displays the answer |
| Staff assemble documentation from the chart and upload it to a portal or fax it | The payer's documentation requirements are returned as a questionnaire the EHR can pre-fill from the chart |
| Staff check portals for decisions and record authorization numbers by hand | The decision and authorization details return to the EHR through the API and attach to the order |
| Practices track payer performance themselves, if at all | Payers publish annual metrics: approval rates, denial rates, average decision times, appeal outcomes |
| Prior payer history is unavailable when a patient switches plans | The new plan can pull authorization history from the old one through the payer-to-payer API |
The phrase that matters is "if payers and vendors deliver." The rule obligates payers to build the API. It does not obligate your EHR vendor to connect to it, and it does not obligate the payer to make the API cover every service. In our experience with earlier interoperability deadlines, payers meet the letter of the requirement on the date and the useful part arrives over the following year or two, unevenly. Practices should plan for a mixed environment through 2027.
The five questions to ask your EHR vendor this month
- Will you support the FHIR prior authorization workflows (coverage requirements discovery, documentation templates and rules, and prior authorization support) in our version, and in which release?
- Which payers will you be connected to on January 1, 2027, by name?
- Is there a separate cost, per transaction or per provider, and where is it documented?
- How will authorization numbers and validity dates received through the API flow to the claim, so that billing staff do not re-key them?
- What happens when a payer's API is down or returns an error: does the workflow fall back to the portal, and is the attempt logged?
Get the answers in writing. A vendor who cannot name payers in August is not going to be live in January. A vendor who names three large national plans and no regional ones is telling you what your January will look like: electronic for those three, manual for everyone else.
What to do on the practice side
The technology does not fix a bad process; it speeds up whatever process you have. Before January, clean up the basics. Make sure every order that may need authorization is placed in the EHR, not on paper, because an API cannot see a paper order. Standardize the documentation for your top twenty authorized services so that when a payer's questionnaire arrives the answers are in structured fields, not buried in free text; a payer asking for "date conservative therapy began" wants a date, not a paragraph. Keep your turnaround log running. And keep the portal logins current, because you will need them for the payers and services that are not electronic yet.
A worked example
A cardiology group submits about 250 authorizations a month: 40 percent Medicare Advantage, 35 percent commercial group, 15 percent Medicaid managed care, 10 percent Marketplace. Its EHR vendor says it will connect to two MA plans and one Marketplace issuer on January 1. Those three payers account for about 30 percent of the group's MA and Marketplace volume, or roughly 40 requests a month. So in January about 40 of 250 requests go through the API, and 210 do not. If the electronic requests save twenty minutes each, that is about thirteen staff hours a month, which is real but is not a headcount. The group's plan is to measure those 40 requests closely, push the vendor for the next three payers, and keep the manual process fully staffed. That is what realistic looks like.
The MIPS angle
CMS-0057-F also created a MIPS Promoting Interoperability measure for electronic prior authorization: an attestation that the clinician requested at least one authorization through the API, or claimed an exclusion. It starts with the 2027 performance year, and the CY 2027 physician fee schedule proposed rule would make it required in 2028. It is a small measure, but it is the first time a practice's MIPS score depends on whether its EHR talks to payers, and it is a reasonable question to ask the vendor alongside the five above.
Our view
We are cautiously positive. The 2026 deadlines already changed behavior: denial letters from Medicare Advantage plans are more specific than they were a year ago, and the seven-day clock has given practices something to cite. The 2027 API deadline will help the practices whose EHR vendors take it seriously and will do very little for the others. The insurers' voluntary commitments are real but self-reported, and 70 or 88 percent "standardized" is not the same as 70 or 88 percent easier. Judge them by your own log in mid-2027.
Questions we hear
Will this reduce the number of authorizations we need?
The API does not. The insurers' pledges to cut authorization lists might, and UnitedHealthcare's announced reductions are specific. Watch each payer's bulletins for removed codes and update your requirements list; a request you did not need to file is the fastest one to process.
Should we buy a separate prior authorization automation tool?
Ask the EHR vendor first. If they will connect to your major payers, a separate tool adds cost and an integration. If they will not, a tool that speaks FHIR to the payer APIs and falls back to portals may be the practical bridge. Our denial management team helps practices evaluate both paths, and our technology team can review what your current systems are capable of before you sign anything.
What about the Provider Access API? Is that useful to us?
Potentially more useful than the authorization API in the first year. It lets you pull a patient's claims history from the plan, including services other providers billed, which helps with gap-in-care work and with medication reconciliation. Ask the vendor the same question: will you connect to it, and for which payers.
What to do this month
- Send the five questions to your EHR vendor in writing and ask for a written answer by September 15.
- Count your authorizations by payer and plan type for the last three months so you can estimate what share will be electronic in January.
- Audit your top twenty authorized services for structured documentation and fix the free-text fields.
- Confirm every order that may need authorization is entered in the EHR, and stop any paper order paths.
- Check that your turnaround log is current and that portal logins for every payer are working and documented.
