What is CMS-0057-F
One final rule, four new APIs, and a deadline that isn't moving
CMS-0057-F turns "interoperable health data" from a talking point into a set of FHIR endpoints every regulated payer has to stand up, test, and keep running.
Finalized by CMS on January 17, 2024, the rule builds on the 2020 Interoperability and Patient Access final rule (CMS-9115-F). That earlier rule required a Patient Access API; this one expands it, adds three more APIs, and, for the first time, puts hard turnaround-time and public-reporting requirements on the prior authorization process itself.
It applies to Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid and CHIP managed care plans, and Qualified Health Plan issuers on the federally-facilitated exchanges. Traditional Medicare fee-for-service and employer-sponsored commercial plans are outside its scope.
None of it is optional, and none of it arrives with new federal funding attached. For a regional or provider-sponsored plan without a dedicated interoperability team, the engineering work is identical to a national payer's, just without the headcount.
The APIs
Five pages, five things to get right
Four of these are CMS-0057-F's own mandated APIs. The fifth, Provider Directory, predates this rule (it's a CMS-9115-F requirement from 2020), but the new Provider Access API now depends on that same data to verify who's actually in-network. Each gets its own page below.
FHIR API
Patient Access API
The member-facing API from the 2020 rule, now required to also expose prior-authorization requests, statuses, and denial reasons.
Read the API →FHIR API
Provider Access API
A new FHIR endpoint that lets a member's in-network provider pull that member's payer-held data directly, instead of chasing it by fax.
Read the API →FHIR API
Provider Directory
A public, query-only FHIR API exposing a payer's provider network, required since 2020, that the new Provider Access API now leans on to decide who's actually in-network.
Read the API →FHIR API
Payer-to-Payer API
Moving a member's data from their old payer to their new one automatically, with consent, instead of it just disappearing when they switch coverage.
Read the API →FHIR API
Prior Authorization API
Automating prior auth end to end, from a provider checking if it's needed to getting a decision back, on the Da Vinci CRD, DTR, and PAS standards.
Read the API →Underneath the compliance checklist
The APIs are the easy part to point to. What's underneath them is the part that actually gets audited.
Every page above describes a FHIR endpoint. None of them describe what has to happen before that endpoint returns anything: confirming who's asking, checking their authorization, checking the member's actual consent or opt-out status, resolving exactly which record they're allowed to see, and logging all of it in a way that survives an audit request months later.
That sequence, not the FHIR resource format, is usually where an implementation actually fails a CMS review or a security assessment. A vendor RFP that only asks "do you support FHIR R4" will get a yes from almost everyone. It won't tell you whether consent is enforced on every request or bolted on as an afterthought, or whether "secure" means a genuinely isolated deployment or a shared database with a tenant column.
Who this applies to
If you're one of these, the deadline is yours
Medicare Advantage organizations
State Medicaid fee-for-service programs
State CHIP fee-for-service programs
Medicaid managed care plans
CHIP managed care entities
Qualified Health Plan issuers on the FFEs
Timeline
Two dates, in order
—Days
—Hours
—Minutes
—Seconds
Until the January 1, 2027 API compliance deadline.
Jan 1, 2026
In effect
Prior-authorization process requirements take effect
Shorter decision timeframes (72 hours for urgent requests, seven calendar days for standard ones), a specific reason required for every denial, and the start of the public-reporting clock all become active, a full year ahead of any new API requirement.
Mar 31, 2026
In effect
First public prior-auth metrics are due
Affected payers must publicly report prior-authorization metrics (approval and denial rates, average decision time, and more) on their own website, annually, starting with this reporting cycle.
Jan 1, 2027
Upcoming
Full API compliance deadline
The Patient Access API enhancements, the new Provider Access API, the Payer-to-Payer API, and the Prior Authorization API all have to be live, tested, and able to handle real production traffic.
Who's behind PayerNetwork.org
PayerNetwork.org is an independent resource from Health Chain, built for the small, regional, and provider-sponsored health plans most CMS-0057-F content ignores in favor of national-carrier case studies.
It's not affiliated with CMS or HHS. Always check the Federal Register for the authoritative rule text. What's here exists to get you to a scoped, fundable project faster, whether or not you ever talk to us.