CMS-0057-F: what payers must demonstrate as the federal rule goes live

01What the rule actually does — and what it does not

CMS-0057-F is not an AI rule. It is an interoperability and prior authorization rule. But by mandating real-time decision timeframes, specific denial reasoning, public metric reporting, and four FHIR APIs that surface prior authorization decisions to providers, members, and successor payers, it transforms the operational environment in which AI-assisted utilisation review now sits.

The rule, formally titled "Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes," was published at 89 FR 8758 on January 17, 2024, after a proposed rule (CMS-0057-P) issued in December 2022. It builds on the 2020 CMS Interoperability and Patient Access final rule (CMS-9115-F) and adds substantially to both its technical and operational scope.

The rule's operational consequence is that, for the first time, the prior authorization activity of every regulated federal payer is visible in machine-readable, standardised, publicly-comparable form.

What CMS-0057-F does not do is regulate the substantive standards for prior authorization decisions themselves. It does not say that an AI tool may or may not be used. It does not say what the medical necessity standard must be. It does not impose substantive non-discrimination requirements on the decisioning logic. Those questions are addressed by the state AI laws covered elsewhere in this series — California SB 1120, Maryland HB 820 — and by the EU AI Act. CMS-0057-F is the infrastructure layer; the state and EU laws are the substantive layer.

02Who is regulated, and at what reporting level

The rule defines five categories of "impacted payer," each with reporting obligations at a specified granularity. The reporting level matters operationally because it determines whether the payer is comparable to its peers in the public metrics — and therefore whether outlier denial rates are visible to providers, journalists, plaintiff-side counsel, and regulators at a glance.

What is not directly named in the rule, but is operationally captured, is the third-party administrator and vendor ecosystem that operates UM infrastructure on behalf of impacted payers. A Medicare Advantage organisation that delegates its prior authorization workflow to a UM vendor remains the reporting entity to CMS; the vendor's operational capability is what enables or disables the carrier's compliance. CMS-0057-F has pulled every UM vendor serving federal payers into the compliance perimeter, even though none of them appears in the rule's text.

Group health plans regulated under ERISA, employer self-funded plans, and commercial fully-insured plans operating outside the FFE exchanges are not impacted payers. Their prior authorization activity remains structurally invisible at the federal level — the most consequential exemption in the rule.

03The operational provisions live since January 1, 2026

3.1 Faster decision timeframes

Impacted payers (excluding QHP issuers on the FFEs) must now send prior authorization decisions within:

• 72 hours for expedited (urgent) requests
• 7 calendar days for standard (non-urgent) requests

The 7-calendar-day standard is a 50% reduction from the previous Medicaid managed care 14-calendar-day requirement. According to KFF analysis, at least 18 states needed to update their state-level Medicaid managed care prior authorization timeframe requirements to align with the new federal standard. Workflow architectures designed around 14-day decision windows — including human-in-the-loop clinical review patterns that several major UM vendors had built their products around — required redesign through late 2025 and early 2026.

3.2 Specific denial reasoning, regardless of submission method

Impacted payers must now provide a specific reason for every prior authorization denial, regardless of how the request was submitted — fax, portal, electronic submission, phone, or API. This eliminates the previously-common practice of generic denial language ("does not meet medical necessity criteria") that left providers without actionable information for appeals or resubmission.

A denial reason that does not reference specific clinical findings is, after January 1, 2026, simultaneously a federal compliance gap and a state-level vulnerability. Under California SB 1120 and Maryland HB 820, AI-assisted denials must be grounded in the enrollee's individual clinical picture — a denial reason that does not reference specific clinical findings fails both standards at once.

3.3 Patient Access API metric collection

The 2020 Patient Access API has been live for five years; CMS-0057-F added a usage-metrics reporting layer effective January 1, 2026. Impacted payers must collect — and report annually to CMS — the number of unique members who used the Patient Access API, the number of repeat users, and aggregate usage volumes.

04Public reporting — and what the first cycle revealed

The most consequential single deadline arrived on March 31, 2026: impacted payers were required to post aggregated prior authorization metrics for calendar year 2025 on their public-facing websites. The 2026 cycle will land March 31, 2027.

4.1 What must be reported

For medical items and services subject to prior authorization (excluding drugs), each impacted payer must report:

4.2 What the first cycle revealed

The aggregate public data published between February and March 2026 produced the first national, comparable view of prior authorization performance across the federal payer ecosystem. Headline numbers: Medicare Advantage plans reported approval rates around 95% after appeals; Medicaid managed care plans around 90%–92%; QHP issuers on the FFEs around 80%, with substantial variation across issuers.

The numbers hide significant service-level variation. High-cost procedures (inpatient admissions, advanced imaging, chemotherapy) show denial rates considerably above the headline average, while routine prior authorizations skew the aggregate approval rate upward. Providers, journalists, and plaintiff-side counsel have begun building service-specific analyses on top of the published plan-level aggregates.

4.3 The transparency dynamic that has emerged

Within the first month of public-reporting availability, two dynamics emerged. First, provider organisations have begun using the published metrics as procurement input — health systems negotiating with MA plans reference the plans' own published denial rates in contract discussions. Second, plaintiff-side counsel litigating wrongful-denial cases have begun citing the published metrics in pleadings, treating the plan's own statement of its denial pattern as admission for the purpose of demonstrating systematic-denial allegations.

05The four FHIR APIs arriving January 1, 2027

The most technically demanding component arrives on January 1, 2027: four FHIR-based APIs that must be live and operational. CMS deferred the API deadlines from the originally-proposed January 2026 by one year to allow additional implementation time. As of mid-2026, the API build is the dominant payer-side technology workstream.

5.1 What CMS specifies — and what it leaves to industry

The rule specifies the capabilities each API must support and the FHIR R4 baseline standards, but it does not mandate a single implementation guide. CMS strongly recommends the HL7 Da Vinci Project implementation guides — Prior Authorization Support (PAS), Coverage Requirements Discovery (CRD), and Documentation Templates and Rules (DTR) — for the Prior Authorization API workflow, but stops short of requiring them. Da Vinci PAS/CRD/DTR is the de-facto standard payers should target because it provides the interoperability layer EHR vendors are integrating against.

5.2 The consent, identity, and access governance layer

The four APIs share a common technical substrate: consent management, member identity verification, access logging, and provider attribution. The Patient Access API requires OAuth 2.0 and SMART app launch security. The Provider Access API requires a provider-attribution process and opt-out management. The Payer-to-Payer API requires patient opt-in. The Prior Authorization API requires authentication and audit logging of every request and decision.

The plans furthest along are those treating this layer as a single coherent platform rather than four separate API projects. The plans struggling are those building each API as a discrete deliverable and discovering, in late 2026, that the consent and identity layer needs to be redesigned to operate across all four.

06How CMS-0057-F changes the AI evidence environment

CMS-0057-F does not regulate AI in prior authorization. But the operational and reporting requirements change the environment in which state and EU substantive questions are asked, in three structurally important ways.

6.1 The 7-day / 72-hour standard makes AI-assisted decisioning effectively mandatory at scale

The previous 14-calendar-day standard accommodated workflows in which substantial human clinical review preceded most decisions. The 7-day standard — and especially the 72-hour expedited standard — forces decision velocity that human-only workflows cannot sustain at the volume modern federal payers process. AI-assisted decisioning is therefore no longer a competitive advantage; it is a structural requirement. The state AI laws regulate the AI tooling that the federal timeframes have made operationally indispensable.

6.2 Specific denial reasoning makes AI behaviour visible per-decision

A denial reason that does not reference specific clinical findings is, after January 1, 2026, a federal compliance violation. A denial reason that does reference specific clinical findings but the findings do not match what the AI tool actually conditioned on is a state-level substantive violation under SB 1120 and HB 820. The two regimes together create structural pressure toward AI tooling that produces auditable, decision-specific reasoning at the moment of decision — the same property that the EU AI Act's Article 12 record-keeping mandate requires from a different angle.

6.3 Public reporting makes outlier patterns visible to plaintiffs and providers

The first-cycle public reporting data has been live for two months. Plans whose denial patterns shifted dramatically between cycles, or whose AI-assisted denial rates diverged from peer benchmarks, will be visible in the March 31, 2027 second-cycle data. The infrastructure that makes this comparison possible is the public-record substrate on which enforcement, litigation, and regulatory attention will be built across 2026 and 2027.

07The full compliance stack: federal × state × cross-border

7.1 The federal infrastructure layer enables state substantive enforcement

California's DMHC, Maryland's MIA, and the analogous state regulators have always had statutory audit authority over plans operating in their jurisdictions. CMS-0057-F's public reporting requirements produce a structured data substrate that state regulators can — and will — use as the starting point for state-level enforcement. A California DMHC audit team in late 2026 will know, before it walks in, how the plan's published metrics compare to its peers and to its own prior cycles.

7.2 The CMS-0057-F reporting calendar drives the state-level audit calendar

The March 31 annual public reporting deadline produces a predictable wave of analysis: from late March through early summer each year, journalists, plaintiff-side counsel, provider trade associations, and patient advocacy organisations publish comparative analyses of the data. State regulators read those analyses. Outlier plans face state-level enforcement attention beginning in the second quarter and running through the third. Plans should complete internal review and remediation in advance of public reporting rather than after.

7.3 The architecture that satisfies all four regimes is the same architecture

The compliance posture that produces CMS-0057-F-compliant public metrics, SB 1120- and HB 820-compliant substantive evidence, and EU AI Act Article 12-grade logs is not three different architectures. It is one architecture: per-determination structured evidence, generated at decision time, retained durably, tamper-evident, and verifiable by an independent party. Plans that build to this standard satisfy all four regimes as a side effect. Plans that build to the federal minimum produce the public metrics on time but cannot withstand state-level audit or EU-level inspection.

08What to do in the next 12 months

8.1 Stand up the four FHIR APIs and the consent/identity substrate

The January 1, 2027 deadline is non-discretionary. The plans that will hit it without disruption are those that began their FHIR API build in 2024 or 2025. Whichever cohort you are in, the next twelve months are about completing the four APIs against Da Vinci PAS/CRD/DTR-compatible specifications, building the consent and identity layer as a coherent platform, conducting end-to-end testing with EHR-side partners, and beginning provider education in advance of go-live.

8.2 Architect the per-determination evidence regime now, not in 2027

The Prior Authorization API will surface every PA decision, with structured denial reasoning, to providers and members in real time from January 1, 2027. The published metrics aggregate the same decisions for public reporting annually. The state AI laws require demonstrable substantive grounding for every AI-assisted denial. The EU AI Act requires automatic logs over the lifetime of every high-risk system. The architecture that satisfies all four is the same: per-determination, structured, generated at decision time, retained durably, tamper-evident.

Payers that build this architecture for CMS-0057-F compliance alone will produce something that meets the federal floor but leaves them exposed in California, Maryland, and any other state with an active AI-in-UM statute. The architectural decisions made in the next twelve months determine which posture you arrive at January 1, 2027 with.

8.3 Pre-position for the next reporting cycle's analytical pressure

The March 31, 2027 reporting cycle will produce the first year-over-year comparison. Plans whose patterns shift dramatically — whose denial rates climb, whose appeals-overturn rates fall, whose extension utilisation rises — will be visible. The internal-audit work that surfaces those patterns before they appear in public reporting gives compliance teams the opportunity to remediate before external scrutiny arrives. The work begins now, in the second quarter of 2026, not in the first quarter of 2027.