What is the CMS-0057-F Final Rule?
CMS-0057-F is the rule that turns prior authorization and payer data exchange into an engineering deadline. Published in the Federal Register on February 8, 2024, the CMS Interoperability and Prior Authorization Final Rule gives regulated health plans a fixed date, January 1, 2027, to run four production FHIR APIs, plus a set of operational prior authorization rules that have been in force since a year earlier. CMS estimates the rule will save the health system roughly $15 billion over ten years, most of it by taking friction out of prior authorization.
At the center of the rule are four HL7 FHIR R4 APIs. One of them you may already run in some form. Three are new.
- Patient Access API: lets members pull their claims, clinical data, and prior authorization information into third-party apps.
- Provider Access API: shares claims and clinical data for a provider's attributed members, in bulk.
- Payer-to-Payer API: moves a member's history to their new plan when they switch.
- Prior Authorization API: runs the electronic prior authorization workflow end to end.
The pattern across all four is the same. Each one exposes data you already hold, through a standard interface, to a specific audience. That is why the real work is less in standing up the APIs than in the data behind them. What that work looks like differs by API, and the sections below take each one in turn.
Who must comply, and who is exempt
The rule applies to six kinds of payer: Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care organizations, CHIP managed care entities, and issuers of Qualified Health Plans on the federally facilitated exchanges. If you run one of those, you are building all four APIs.
Plenty of organizations sit outside the rule. Traditional Medicare, employer-sponsored ERISA self-funded plans, standalone Part D drug plans, and Medigap are not covered. Delegated entities are a more common source of confusion. A utilization management vendor, TPA, MSO, or IPA is not itself regulated by CMS-0057-F. The obligation stays with the payer, even for the functions the payer hands off. In practice that means a plan which delegates prior authorization still has to expose a compliant Prior Authorization API, so it either builds that API over the vendor's system or requires the vendor to provide it. The vendor gets pulled in commercially, not because the rule names it.
There is one exception worth pinning down, because it is the detail most people get wrong. QHP issuers on the exchanges are not held to the prior authorization decision timeframes. Those apply to Medicare Advantage, Medicaid, and CHIP. Everything else still applies to QHPs: all four APIs, the specific-denial-reason rule, and the public metrics reporting. So if you run a QHP, scope the API work in full and leave the decision clock out.
Two deadlines, two kinds of work
The rule put two dates on the calendar, and they call for different teams.
The first, January 1, 2026, is already behind us. Since then, impacted payers (QHPs aside, on the timeframes) have had to return prior authorization decisions within 72 hours for urgent requests and seven calendar days for standard ones, state a specific reason for every denial, and publish prior authorization metrics on their website each year. The first of those public reports was due March 31, 2026, covering the 2025 calendar year, and it recurs annually. This is policy and process work. You can meet it with workflow and governance changes.
The second, January 1, 2027, is the API deadline, and it is the harder one. It is engineering, and you cannot close it with a memo. The four sections that follow are what that engineering actually covers.
Patient Access API
Patient Access is the one API most impacted plans already run, because it dates back to the 2020 rule. A member authorizes a third-party app, and the plan returns their data to it through a SMART on FHIR flow secured with OAuth 2.0. The member holds the authorization and can revoke it.
What flows through it is broad: adjudicated claims and encounter data in the CARIN Blue Button format, clinical data as USCDI, and, for plans with drug coverage, formulary information. CMS-0057-F adds one thing by January 1, 2027: prior authorization information, the status and the specific reason, for everything except drugs.
The work is rarely the endpoint. It is the data quality behind it: mapping claims correctly, keeping the feed current, and owning the gaps. Plans also report Patient Access usage metrics to CMS each year. Done well, this API is more than a compliance surface. The same clean, member-facing data layer can back your own member app or portal.
Provider Access API
Provider Access is new, and it is where teams underestimate the effort, because it is not just an endpoint. It gives an in-network provider the claims, encounter data, USCDI clinical data, and prior authorization information for the members attributed to them, delivered in bulk.
The authentication model is different from Patient Access. No patient clicks approve. The plan authenticates the provider organization as a system, through SMART Backend Services, and runs a FHIR Bulk Data export over the provider's attributed member group. The effort is not the export, it is the governance around it:
- Attribution. The plan has to know which providers have a treatment relationship with which members, and keep those attributed lists current.
- Opt-out. Members can decline to share their data with providers, and the plan has to honor and track that choice.
Get those two right and the export itself is routine.
Payer-to-Payer API
Payer-to-Payer is an identity and consent project before it is an API project. When a member joins your plan, you have one week to ask their previous payer for up to five years of history, claims, clinical data, and prior authorization records, so you start with context instead of a blank chart. When a member leaves, you are on the other side of that call, answering the new plan. Cost data, provider remittances, and enrollee cost-sharing stay out.
The transfer is the easy part. The hard parts are the two gates in front of it. Member matching: you and the other plan have to agree you are talking about the same person across different identifiers, with no shared key. Consent: unlike Provider Access, nothing moves unless the member opts in, so you need a way to capture that opt-in and honor it. For members carrying coverage from more than one plan at once, the exchange runs at least quarterly rather than once at enrollment.
Prior Authorization API
The first three APIs publish or move data. The Prior Authorization API is a different animal: it runs a transaction. A provider asks your plan a question, and your plan has to answer with a real decision, inside a clock. This is business-process integration, not data exposure, which is why it is the hardest of the four and carries the deepest set of standards.
Three Da Vinci implementation guides chain together to run that process. It starts with CRD, Coverage Requirements Discovery. When a provider orders an item or service, or schedules one, a hook fires from the EHR and your plan answers in real time: is prior authorization required, and what documentation does it need. If it is, DTR, Documentation Templates and Rules, hands the EHR a smart questionnaire and prefills what it can from the chart, so the provider is not retyping data the system already has. Finally PAS, Prior Authorization Support, submits the request and returns the decision: approved, denied with a specific reason, or pended for more information. CMS recommends these guides but does not formally mandate them.
This is also where a common misreading needs correcting. FHIR does not replace X12. The PAS guide is designed to carry the HIPAA-mandated X12 278 transaction, so the underlying request and response are still X12 underneath the FHIR. A payer can run the back end as FHIR-only, X12-only, or a hybrid of the two and still meet the rule. Additional clinical documentation rides along through a separate Da Vinci mechanism, CDex, rather than being crammed into the authorization message itself.
One more piece connects the payer side to providers. Starting with the 2027 performance period, eligible clinicians and hospitals attest, under the Medicare Promoting Interoperability program, that they requested at least one prior authorization electronically through a Prior Authorization API. That measure is the demand signal. It is why your Prior Authorization API is not just a compliance endpoint but something your provider network is now expected to use.
What changed from the 2020 rule
If CMS-0057-F feels familiar, that is because it builds on CMS-9115-F, the 2020 Interoperability and Patient Access rule. That earlier rule established the Patient Access API and the Provider Directory API. It also called for payer-to-payer data exchange, but CMS never enforced that provision and it was never API-based.
CMS-0057-F finishes the job. It keeps the earlier APIs, rebuilds payer-to-payer as an enforceable FHIR API, adds Provider Access and Prior Authorization, folds prior authorization data into Patient Access, and layers on the operational timeframes and public reporting. The direction is consistent. The scope and the teeth are new. CMS did not attach a specific fine to the rule, but it enforces through the authorities it already holds over each program, Medicare Advantage contracts, Medicaid and CHIP oversight, and QHP certification. The exposure is contractual and regulatory rather than a published dollar figure.
How Health Samurai helps
Payerbox is Health Samurai's CMS-0057-F platform for health plans, built on our FHIR R4-native Aidbox core. It implements all four APIs, with production support for the Da Vinci prior authorization guides, CRD, DTR, and PAS.
The design principle is the one a compressed timeline actually calls for: integrate, do not replace. Your claims platform, your UM system, and your directory stay where they are. Payerbox sits in front of them, reads their data, and translates it into conformant FHIR for each API. The value is not in moving records into a new system, it is in exposing the records you already have, correctly, through a standard interface.
That FHIR layer keeps paying off after the deadline. The store you build for the four APIs is also an analytics store: the same normalized data feeds risk adjustment, Stars and quality measures, and population health. Compliance spend turns into a reusable data asset instead of a single-use wrapper, and the next regulatory requirement lands on data you have already standardized.
This is production software, not a slideware promise. Payerbox is live with payers today. VillageCareMAX serves its Patient Access API on Payerbox and placed #2, at 91 out of 100, on Flexpa's independent November 2025 payer scorecard, so it is not just live but scored among the best. A delegated prior authorization vendor runs the full Payerbox ePA stack, CRD, DTR, and PAS, in production. And we keep the stack conformant by taking it to the HL7 Da Vinci Connectathon Burden Reduction track.
See the full solution on the Payerbox page for CMS-0057-F. When you want an architect-to-architect read on where your plan stands against the January 2027 deadline, schedule a call: we will map your obligations, look at your source systems, and show you what a Payerbox implementation looks like against your remaining timeline.
