CMS-0057-F: What the Prior Authorization Rule Means for Providers Before January 2027

CMS’s Interoperability and Prior Authorization final rule, known as CMS-0057-F, is mostly a rule about what payers must do. It sets decision deadlines, requires a specific reason for every denial, makes payers publish their prior authorization results, and requires them to stand up four FHIR-based APIs. Providers are largely not regulated by it — with one exception, covered below — but providers are the ones who live with the result. The first requirements took effect on January 1, 2026; the biggest technical deadline is January 1, 2027.

Who the rule covers — and who it doesn’t

CMS applies the rule to “impacted payers”: Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and qualified health plan issuers on the federally facilitated exchanges. Employer-sponsored commercial plans are not on that list, and the prior authorization requirements generally do not cover drugs. If a large share of your prior authorizations go to commercial payers or are for drugs, much of this rule will not reach them directly.

CMS’s own FAQ is blunt about commercial coverage: the only commercial payers affected are qualified health plan issuers on the federally facilitated exchanges. Separately, in June 2025 AHIP announced voluntary commitments from 53 health plans, including cutting prior authorization requirements for some services from January 1, 2026 and answering at least 80% of electronic prior authorization approvals in real time in 2027. That is a pledge by the plans, not a regulation, so hold them to it through your contracts and your own data.

What has been in effect since January 1, 2026

• Decision timeframes. Impacted payers (other than qualified health plan issuers on the federal exchanges) must send prior authorization decisions within 72 hours for expedited requests and seven calendar days for standard requests. CMS says this is calendar time, not business hours, and that the clock starts when the payer receives the request.
• Specific denial reasons. A denied prior authorization must come with a specific reason, regardless of how the request was submitted. CMS has not published a definition of “specific”, so expect the quality of these reasons to vary by payer.
• Public reporting. Payers must post prior authorization metrics on their websites every year, on a page anyone can read. The first set, covering calendar year 2025, was due by March 31, 2026. It includes the list of items and services that need prior authorization (drugs excluded), approval and denial percentages, and average and median decision times for standard and expedited requests.
• Patient Access API usage reporting. From January 1, 2026, payers also report annual Patient Access API usage metrics to CMS.

For a provider organization, the practical value is measurement. There is now a published standard to hold payers to, and a public report to compare with your own experience. If your turnaround and denial data tell a different story from a payer’s published metrics, that is worth a conversation with the payer.

What arrives on January 1, 2027

By January 1, 2027, impacted payers must implement four APIs built on HL7 FHIR: a Patient Access API, a Provider Access API, a Payer-to-Payer API and a Prior Authorization API. CMS describes what a Prior Authorization API response must do: approve the request and state when the authorization ends, deny it with a specific reason, or ask for the additional information needed to decide.

• Patient Access API. Adds prior authorization information (drugs excluded) to the data patients can already reach through apps they choose.
• Provider Access API. Lets in-network providers with a treatment relationship retrieve a patient’s claims, encounter data, clinical data (USCDI) and prior authorization information. Payers must run an attribution process to match patients to providers, and patients can opt out, so the data a provider sees may be incomplete.
• Payer-to-Payer API. Moves a patient’s data to a new plan, only with the patient’s opt-in permission, and only for dates of service within five years of the request.
• Prior Authorization API. Publishes which items and services need prior authorization and what documentation is required, accepts the request electronically and returns approval, denial or a request for information.

The rule requires FHIR Release 4.0.1 together with US Core (STU 3.1.1), USCDI, SMART App Launch 1.0.0, FHIR Bulk Data Access 1.0.0 and OpenID Connect Core 1.0, and lets payers use newer ONC-approved versions where that does not disrupt access. CMS also recommends implementation guides, including Da Vinci Coverage Requirements Discovery (CRD) and Prior Authorization Support (PAS). Because those guides are recommended rather than required, details can differ between payers — confirm each payer’s approach rather than assuming they will behave identically. Providers also find each payer’s endpoints payer by payer, not through one directory.

One more detail to plan around: HHS announced enforcement discretion for the HIPAA X12 278 prior authorization transaction, so payers may build FHIR-only APIs or FHIR plus X12. Do not assume X12 278 or the payer portal is going away on January 1, 2027; plan to run old and new channels side by side until each payer has proven its API.

The one thing the rule asks of providers

Providers are not required to build anything under CMS-0057-F, but a new measure rewards using the new APIs. CMS adds an Electronic Prior Authorization measure, and its timing differs by provider type. For MIPS clinicians it begins with the 2027 performance period (the 2029 payment year): clinicians report it by attesting “yes” to having requested at least one prior authorization electronically through a Prior Authorization API, using data from certified EHR technology, for a medical item or service (drugs are excluded). For eligible hospitals and critical access hospitals, the FY 2027 inpatient payment rule (final, released July 31, 2026) makes the measure an optional bonus measure for the 2027 EHR reporting period and mandatory beginning with the 2028 EHR reporting period. It is based on hospital discharges and medical items.

What is changing next: the drug rule proposal (CMS-0062-P)

On April 14, 2026, CMS published a proposed rule, CMS-0062-P, that would extend the same approach to drugs; comments closed on June 15, 2026. As proposed, impacted payers would support electronic prior authorization for medical-benefit drugs through the Prior Authorization API, and for pharmacy-benefit drugs through NCPDP standards, from October 1, 2027, with shorter drug decision timeframes and a specific reason for every drug denial. It would also add numeric counts to the existing public metrics, add new reporting of Provider Access, Payer-to-Payer and Prior Authorization API usage to CMS beginning in 2028 with 2027 data, and have payers report their API endpoints to CMS. CMS’s summary shows no change to the January 1, 2027 deadlines.

Where providers will feel the gap

The rule obliges payers to build APIs; it does not make your workflow ready to use them. In our reading, three gaps are likely. First, your EHR or practice management system may not yet be able to send a prior authorization request through an API. Second, prior authorization work is often spread across staff, portals and phone calls and is not written down, so there is nothing yet to automate. Third, faster decisions and specific denial reasons produce more data, but only organizations that track it will learn from it.

A readiness checklist for the next 90 days

1. Map your payers. List the payers behind most of your prior authorizations and mark which are impacted payers under the rule. Commercial employer-sponsored plans may sit outside it.
2. Baseline your numbers. Measure prior authorization turnaround and denial reasons by payer now, so you can see what changes after the deadlines and compare with the payers’ published metrics.
3. Ask your EHR and practice management vendors, in writing, whether they support a FHIR-based Prior Authorization API, when, at what cost, and whether it counts toward the measure.
4. Ask each payer for its Provider Access and Prior Authorization API details: endpoints, how to get onboarded, which services it covers and when it goes live. Keep the portal and X12 278 route as your fallback.
5. Write down the workflow. Document who requests prior authorizations, in which systems, with what documentation, and where staff re-key information. You cannot automate what is not written down.
6. Pick a pilot. Start with a high-volume, non-drug service where delays and denials are costly, and run it with a defined audit sample.
7. Close the loop on denials. Feed specific denial reasons back into documentation, coding and appeal workflows, and track appeal deadlines.
8. Watch CMS-0062-P. If it is finalized, drug prior authorization and new reporting follow from October 2027 for payers, so note it in your plan without acting early.
9. Govern any AI. If an AI tool drafts or submits prior authorization requests, keep named human review of anything consequential, and an audit trail.

Frequently asked questions