The CMS Interoperability and Prior Authorization Rule (CMS-0057-F)

The rule has two halves with different deadlines, and confusing them is the most common mistake in vendor conversations.

The process half, in force since January 1, 2026. Impacted payers must respond to prior authorisation requests for items and services within fixed timeframes, must send notices to providers when they make a decision including a specific reason when they deny, and must publish aggregated metrics about their prior authorisation processes on their own websites each year by March 31. These apply regardless of whether the request arrived through an API, which is the detail that makes them useful immediately.

The technology half, due January 1, 2027. Impacted payers must implement and maintain four FHIR based APIs: an expanded Patient Access API that includes prior authorisation information, a Provider Access API, a Payer-to-Payer API, and a Prior Authorization API.

Both halves phase in the same way by payer type. The stated date applies directly to Medicare Advantage organisations and state Medicaid and CHIP fee for service programs. Medicaid and CHIP managed care plans comply from the rating period beginning on or after that date, and QHP issuers on the Federally-facilitated Exchanges from plan years beginning on or after it. In practice that means a managed care plan with a July rating period is on a different clock to a Medicare Advantage plan, which matters when you are chasing a specific payer.

Scope is where most provider organisations lose time, because the rule covers a large share of government funded volume and almost none of the commercial book.

Two implications follow. First, if your payer mix is heavily commercial, this rule will not fix your prior authorisation problem and you should not size a business case as though it will. Second, for the government funded share it creates a hard, dated obligation you can hold a payer to by name, which is a considerably stronger position than the one providers had in 2023.

For covered items and services, excluding drugs, the timeframes finalised in CMS-0057-F are:

• 72 hours for expedited requests, unless a shorter minimum timeframe is established under applicable state law.
• 7 calendar days for standard requests, with the possibility of an extension of up to 14 days in certain circumstances.

For Medicare Advantage this is a meaningful compression of the standard timeframe. For Medicaid managed care, extensions of up to 14 calendar days remain available under existing rules in defined circumstances. QHP issuers on the Federally-facilitated Exchanges were deliberately left out of the timeframe changes: commenters objected, and CMS declined, pointing to the existing internal claims and appeals standards at 45 CFR 147.136 that already require notification within 15 days for standard determinations and 72 hours for expedited requests.

Alongside the clock, payers must send a notice to the provider on every decision and include a specific reason when they deny. That single requirement is quietly the most useful part of the rule for anyone running denial management, because a specific reason is machine readable in a way that a generic denial code is not, and it is the raw material an appeals workflow needs.

Note what the rule does not do. It does not tell payers what to require prior authorisation for, and it does not constrain how they decide. Constraints on using algorithms in utilisation review are coming from state law rather than from CMS, which is why the California statutes on AI in utilisation review are worth reading next to this one.

All four are due by January 1, 2027 on the phasing described above, and all four are FHIR based, building on the technical standards CMS finalised in the 2020 CMS Interoperability and Patient Access final rule.

A caution on implementation guides. CMS-0057-F requires FHIR based APIs but stopped short of mandating every associated HL7 implementation guide, recommending several instead. That flexibility is why two compliant payers can still be awkward to integrate with in different ways. The CMS-0062-P proposed rule of April 2026 would require certain implementation guides that are currently only recommended, which if finalised would materially improve interoperability in practice. Until then, assume per payer integration work and budget for it.

You have no obligations under this rule, which means your entire leverage is in what you ask for and when. Six requests are worth making now.

From each impacted payer. One, the URL of the published prior authorisation metrics, which were first due March 31, 2026. Two, their Prior Authorization API roadmap with a named date inside the 2027 window and a sandbox availability date. Three, written confirmation of which implementation guides they will support, since the rule leaves several as recommendations. Four, the format of the specific denial reason they now send, so your revenue cycle automation can parse it rather than route it to a human.

From your EHR or automation vendor. Five, whether their electronic prior authorisation capability is certified to the HTI-4 criteria that took effect October 1, 2025, and if not, when. Six, how the product behaves when a payer is not yet live on the Prior Authorization API, because through 2026 and much of 2027 that will be the normal case and a product that only works against a compliant payer solves nothing this year.

Ask these in writing, in vendor selection rather than after signature, and expect uneven answers. The published metrics in particular tend to surprise people: comparing approval rates and appeal overturn rates across the plans you contract with is now possible with public data, and it changes which contracts you argue about.

No, and this is the single most common misreading. CMS explicitly excluded drugs from the Prior Authorization API and from the process requirements in CMS-0057-F. The timeframes, the specific denial reason requirement and the published metrics all apply to medical items and services excluding drugs covered under the relevant benefit.

CMS proposed to close that gap on April 14, 2026 in CMS-0062-P, published at 91 FR 19890, with comments closing June 15, 2026. The proposal would require impacted payers to make electronic prior authorisation available for drugs and would extend many of the existing interoperability requirements for non-drug items and services to cover drugs. It would also require payers to report API endpoints for the Patient Access, Provider Directory, Provider Access, Payer-to-Payer and Prior Authorization APIs to CMS, collect API usage metrics, bring small group market QHP issuers on the FF-SHOPs into scope, and require several HL7 FHIR implementation guides that are currently only recommended.

As of early August 2026 none of that is law. Plan your drug prior authorisation workflows on the assumption that the current manual and NCPDP based routes persist through 2026, and treat the proposal as a reason to ask vendors whether their architecture could absorb a drug pathway rather than a reason to wait.

Being clear about the limits saves a great deal of misplaced optimism.

• It does not reduce what requires prior authorisation. Payers still set their own lists. The rule requires that the list be published, not that it shrink.
• It does not require providers to use the APIs. There is no mandate on your side. The nearest thing is the Electronic Prior Authorization measure in the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program, beginning with the calendar year 2027 performance period and the 2029 MIPS payment year.
• It does not touch commercial plans. For most hospitals and practices, a large share of prior authorisation volume sits outside the rule entirely.
• It does not regulate how payers decide. Nothing here constrains the use of algorithms in utilisation review, which is being addressed at state level instead.
• It does not cover drugs. See the section above.

What it does give you is dated, enforceable behaviour from a defined set of payers, and a public dataset to hold them to. That is enough to make a real difference to a prior authorisation automation business case, provided the case is built on your actual payer mix rather than on the rule's headline.

A sequenced plan for the rest of 2026 and 2027.

1. Now: segment your prior authorisation volume by payer type. How much sits with Medicare Advantage, Medicaid and CHIP managed care, and QHPs on the Federally-facilitated Exchanges, and how much is commercial or Medicare fee for service and therefore untouched. Everything downstream depends on this number, and the prior authorisation cost calculator is a quick way to put a figure on the addressable share.
2. Now: pull the published metrics for every in-scope payer you contract with. They were due on payer websites by March 31, 2026. Compare approval, denial and appeal overturn rates and take the outliers into contract discussions.
3. Now: capture the specific denial reasons payers have been required to send since January 2026, and check whether your intake process is storing them in a structured field rather than a scanned letter.
4. Q4 2026: get written API roadmaps from your top payers with sandbox dates, and confirm which implementation guides each will support.
5. Q4 2026: confirm your EHR's HTI-4 electronic prior authorisation certification status and decide whether you integrate natively or through a separate automation layer.
6. 2027: plan for the Electronic Prior Authorization Promoting Interoperability measure from the calendar year 2027 performance period, and for staged payer go lives rather than a single switch.

The organisations that get value from this rule are the ones that treat 2026 as the year to prepare data and contracts rather than the year to buy software. If you want that sequencing done against your own payer mix, with the build or buy decision made on evidence, that is the work in our deployment roadmap.