CMS Prior Authorization API Requirements

Someone in your office is on hold with a payer right now, chasing a prior authorization that was faxed eleven days ago. They will call again tomorrow, because there is no way to see where the request sits.

A federal rule is supposed to end that, and most of what has been written about it is addressed to health plans. This is the version for the practice on the other end of the fax line: what actually changes, when, and what it will not fix.

What is the CMS prior authorization API?

It is one of four application programming interfaces that certain health plans must operate under the CMS Interoperability and Prior Authorization final rule, known as CMS-0057-F.

All four are built on FHIR, the modern healthcare interoperability standard your EHR vendor already talks about. The Centers for Medicare & Medicaid Services (CMS) finalized the rule in January 2024, after a proposed rule in December 2022.

The Prior Authorization API is the one that matters most day to day. It lets a provider system ask a payer what is required, submit the prior authorization request, and receive authorization decisions back electronically.

No fax machine, no payer portal login, and no second phone call to ask where it went.

The important thing to understand is who the rule binds. It regulates payers, not practices.

Which payers the rule applies to

The requirements fall on impacted payers, a specific list rather than every plan you bill.

• Medicare Advantage organizations
• State Medicaid and CHIP fee-for-service programs
• Medicaid managed care plans and CHIP managed care entities
• Qualified Health Plan issuers on the Federally-facilitated Exchanges

Most commercial and employer-sponsored plans sit outside the final rule. That single fact shapes everything else: your practice will get a faster, electronic prior authorization process with some payers and the old one with others, at the same time, for years.

Your practice has no compliance duty here. Nothing in CMS-0057-F requires you to build or buy anything. What it creates is new capability on the payer side that you can use if your systems can reach it.

What already changed in January 2026

The first set of provisions is already in force, and they are worth knowing because you can hold payers to them now.

Requirement	What it means at the front desk
72 hours for expedited requests	Urgent decisions have a hard clock
7 calendar days for standard requests	Down from timelines that often ran longer
Specific denial reasons	A denial must say why, which makes appeals answerable
Public reporting of prior authorization metrics	Approval, denial and turnaround rates are published

That last row is quietly useful. When a payer's published numbers do not match your experience, you have something concrete to raise with your provider representative.

The four APIs arriving January 1, 2027

By that date, impacted payers must run four FHIR APIs. They are separate interfaces doing different jobs, and together they are the data exchange the rule is really about.

API	What it carries	Who benefits
Prior Authorization API	Requirements, submission and the prior authorization decision	Your staff, directly
Provider Access API	Claims, encounters and clinical data for patients you treat	You, at the point of care
Patient Access API	The same data, to an app the patient chooses	Patients
Payer-to-Payer API	History that follows a patient who changes plans	You, through fewer gaps

The Provider Access API deserves attention alongside the prior authorization one. It is the first time many plans will expose a patient's claims history to the treating practice in a structured way, which is exactly the context missing when a new patient arrives.

What this means for your practice

Prior authorization APIs on the payer side do nothing for you until something on your side can talk to them. That is the whole practical question, and it belongs to your EHR vendor rather than to CMS.

Most practices will get this as a feature in an existing product. Your EHR or practice management vendor builds the connection, and electronic prior authorization appears as a screen rather than a project. Ask when, and ask whether it costs extra.

Practices running their own integrations, or building around an older system, are looking at real work. Our healthcare API integration guide covers what connecting to a FHIR interface involves, and the difference between FHIR and HL7 v2 explains why this generation of interfaces is cheaper to work with than the last.

What to ask, and when

Two conversations are worth having in the next six months.

Ask your EHR vendor: Will you support the CMS Prior Authorization API, and on what timeline? Will it be included or priced separately?

Which payers will be connected at launch? Will requirements lookup and status tracking appear in the existing prior authorization screen?

Ask your largest impacted payers: When will your Prior Authorization API be live? Which EHR vendors are you working with? What is the fallback while it is being rolled out?

Medicare Advantage plans are usually the largest impacted block in a small practice's payer mix, so start there.

Write the answers down with dates. A vendor that says "we are evaluating it" in late 2026 is telling you that January 2027 will change nothing in your office.

What the rule will not fix

Set expectations honestly, because the gap between the headline and the experience will be wide for a while.

• Payers still decide. The rule changes how requests travel and how fast authorization decisions come back. It does not change medical necessity criteria or make approvals more likely.
• Coverage is partial. Commercial plans outside the impacted list keep working the way they do today.
• Rollout will be uneven. An application programming interface existing on January 1 is not the same as your vendor having connected to it.
• Drugs are largely outside it. The prior authorization provisions exclude drug prior authorizations, which are a large share of the burden in many practices. CMS excluded them because the timeframes and standards differ, and has since proposed extending the requirements to drugs in a separate rule.

What to do between now and January

1. Measure your baseline. Count prior authorizations per week, average days to decision and hours of staff time. Without it you cannot tell whether anything improved.
2. List your payers and mark which are impacted by the rule. That tells you how much of your volume this can touch.
3. Put the vendor question in writing and set a reminder for the answer.
4. Hold payers to the 2026 timelines now. The 72-hour and 7-day clocks already apply.
5. Do not wait to fix the process. Automation that helps today keeps helping afterward, as our guide to prior authorization automation covers.

The rule is a genuine step forward for healthcare interoperability, arriving slowly and unevenly. Practices that know their numbers and have asked their vendor the direct question will convert it into recovered staff time. Practices that wait to be told will find the date has passed and the fax machine is still warm.

If connecting your systems to payer interfaces is work you would rather hand over, our FHIR integration practice does exactly this kind of build.