CMS-0057-F: What Provider Organizations Should Do This Quarter

The Advancing Interoperability and Improving Prior Authorization Processes final rule was published in the Federal Register on February 8, 2024 and took effect on April 8, 2024. Its substantive obligations arrive in two waves, and the first has already landed.

Since January 1, 2026, impacted payers must decide expedited prior authorization requests within 72 hours and standard requests within seven calendar days, must include a specific reason when they deny, and must report prior authorization metrics publicly each year.

From January 1, 2027, the same payers must operate four FHIR application programming interfaces: Patient Access, Provider Access, Payer-to-Payer, and a Prior Authorization API that carries documentation requirements, submissions and status.

The impacted payers are Medicare Advantage organisations, state Medicaid and CHIP fee-for-service programmes, Medicaid and CHIP managed care entities, and qualified health plan issuers on the federally facilitated exchanges. Commercial group plans outside those categories are not covered, which is the single most misunderstood thing about this rule. The detail sits on the CMS prior authorization rule page.

CMS also finalised a new electronic prior authorization measure in its interoperability reporting programmes, applying to MIPS eligible clinicians under the Promoting Interoperability performance category and to eligible hospitals and critical access hospitals under the Medicare Promoting Interoperability Program. That is the one place the rule reaches providers directly. Confirm the performance period that applies to you against current CMS guidance rather than against a 2024 summary, because CMS has adjusted reporting periods in subsequent annual rules.

One clarification that saves arguments internally: drugs are outside the prior authorization API scope. The rule's prior authorization provisions exclude authorizations for drugs, which means your pharmacy authorization workflow does not change on January 1, 2027 and should be planned separately.

Because the benefit is not automatic. A payer can stand up a compliant Prior Authorization API on December 31, 2026 and you can still be faxing in March 2027 if nobody on your side connected to it.

Three things have to be true for you to capture the change. Your practice management or EHR estate has to be able to call the API, or your vendor has to. Somebody has to know which of your payers is covered and which is not, because a mixed payer panel means a mixed workflow for years. And you have to know what prior authorization costs you today, or you will never be able to show what the change was worth.

The third is the one that gets skipped, and it is the cheapest. Run your current volume, staff time and denial rate through the prior authorization cost calculator and save the output with a date on it. It takes twenty minutes and it becomes the baseline for every automation business case you write for the next three years.

There is a second reason providers should treat this as their problem rather than their payers'. Payer readiness will be uneven, and unevenness is a workflow cost you absorb. If four of your eight major plans have a working Prior Authorization API in January 2027 and four do not, your staff run two processes, your training doubles, and any automation you have bought has to handle both. Knowing which side each payer will be on, a year in advance, is the difference between designing for that and discovering it.

Six things, in order, none of which require a budget.

Do them in that order. The payer list determines whether the rest is worth doing at all: if 70 percent of your prior authorization volume sits with plans outside the rule, your automation case has to stand on the old world rather than the new one.

In writing, to a named person, with a date by which you would like an answer. Five questions cover it.

1. Which of the four APIs will you have in production on January 1, 2027, and which are already available?
2. Do you have a developer sandbox, and how does a provider organisation or its vendor get credentials?
3. Which implementation guides are you building to, and which version?
4. Will your Prior Authorization API publish documentation requirements, or only accept submissions?
5. Who is the technical contact our EHR vendor should speak to?

The fourth question separates a genuine implementation from a compliance minimum. An API that tells you what documentation a payer needs before you submit removes far more work than one that only accepts a submission and returns a status, because most of the cost in prior authorization is assembling the wrong packet twice.

Expect uneven answers. Large national plans will have a programme office and a public developer portal. Regional Medicaid managed care entities may not have started. Both answers are worth having, and the gap between them is what your prior authorization automation scope has to absorb.

The rule has created a category of vendors whose pitch is essentially a countdown clock. The questions that separate them are specific.

1. Which payers are you connected to today, by name, and by what method: FHIR API, portal automation, or clearinghouse?
2. What happens to your product when a payer turns on its Prior Authorization API? Does your value go up or does it disappear?
3. Which EHRs do you write the authorization back into, and is that native or a workaround?
4. What is your position when a payer changes a portal and your automation breaks? Who fixes it, and in what timeframe?
5. What do you charge, and does the price change when the API work becomes easier for you?

Question two is the honest one. A vendor built entirely on scraping payer portals has a business that the 2027 APIs erode. A vendor built on documentation assembly and clinical criteria matching has one the APIs make better. Ask which they are, and listen for whether they have thought about it.

Question three matters more than people expect. Writing the authorization number back into the chart is where the time actually saves, and integration depth varies sharply by EHR. Our Epic integration page covers what native access requires in practice, and the same questions apply to any of the systems in our EHR integration index.

From 2026 the covered payers report prior authorization metrics publicly, including approval and denial rates and average turnaround. That is a negotiating asset most provider organisations have not picked up.

Three uses. In contracting, a payer whose published denial rate is well above its peers has a harder time arguing that your appeal volume is your problem. In staffing, published turnaround times tell you where to put your follow up effort. In your own board reporting, they give you an external benchmark rather than an internal opinion.

Pair them with your own denial data. If your denial rate for a payer materially exceeds its published average, the cause is usually a documentation pattern on your side that is cheap to fix, and it is exactly the kind of finding that denial management work is built on. Our denial rate benchmark gives you the comparison in a form you can put in a slide.

Sampling beats analysis here. Take thirty authorizations per major payer over one month, record the date submitted, the date decided, whether it was expedited, and whether the denial reason was specific enough to act on. That gives you a defensible compliance picture against the 72 hour and seven day clocks in about a week of clerical effort, and it is the evidence a payer relations conversation needs. An analysis built from a claims extract will take a quarter and be argued with.

It changes the ceiling, not the floor. Today most prior authorization automation is doing one of three things: filling a payer portal, assembling a documentation packet from the chart, or chasing status. The first is brittle, the second is valuable, the third is tedious and easy.

A Prior Authorization API that publishes documentation requirements moves the work upstream. Instead of submitting and waiting to be told what is missing, the agent can ask what is required for this service, this plan and this patient, then assemble against that list before submitting. That is a different and much better automation problem, because it turns rework into a check.

Two consequences for how you scope a project now. Design the agent so the packet assembly logic is separable from the submission channel, because the channel is what changes in 2027 and the assembly logic is what you are actually paying for. And instrument the workflow so you can see first-pass approval rate, not just submission volume, since first-pass approval is the number that should move.

The same argument applies to the neighbouring workflows. Authorization failures show up later as denials, so a project that only automates submission and never closes the loop with denial management or the wider revenue cycle tends to report activity rather than money. Decide up front which of those you are buying.

Do not buy a prior authorization automation platform on the strength of the 2027 deadline alone. The deadline binds your payers. Buying eighteen months early means paying for eighteen months of a workflow that is about to change shape, and the vendors know it.

Do not assume your EHR vendor will be ready. HTI-4, finalised as part of the FY2026 Hospital Inpatient Prospective Payment System final rule and effective October 1, 2025, added certification criteria for electronic prior authorization on the health IT side. Certification is not the same as your instance being upgraded, configured and licensed for it. Ask for the version and the date.

Do not let the deadline slip out of the roadmap because it is a year away. The work that has to happen before January 2027 is payer relationship work and baseline work, both of which take months and neither of which can be compressed at the end.

If the honest answer is that nobody owns this, the sequencing question is bigger than prior authorization, and a three week AI readiness audit will tell you whether this workflow is even the right one to attack first. For many practices it is not, and the regulation tracker is the wider calendar this date sits inside.