The Four CMS-0057-F APIs Explained: Which Payers Under-Scope Before Enforcement

Ask a US payer team what CMS-0057-F actually asks them to ship, and most will say Prior Authorization API. That answer is not wrong, but it is roughly one-quarter of the rule. The Final Rule bundles four separate FHIR APIs under one enforcement umbrella, and the teams that under-scope right now are the same teams who will be rebuilding integration plans in Q3 2026. If you want the wider context, we keep more on healthcare data exchange in the site's main index for reference.

What CMS-0057-F Actually Requires

The rule finalized by CMS in January 2024, formally titled the Interoperability and Prior Authorization Final Rule, applies to 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. It mandates four HL7 FHIR R4 APIs, and it points every one of them at a specific Da Vinci implementation guide. The compliance date most teams are watching is January 1, 2027, when the Prior Authorization API must be live and when the metrics reporting begins.

Here is the thing most slide decks skip: the rule is not four options. It is four obligations, and CMS graded each one against a named IG. If your build plan does not reference PDex, PDex Plan-Net, PDex Payer Network, PDex Formulary, CRD, DTR, and PAS by name, the plan is not complete.

Patient Access API - Inherited, But Now Expanded

Patient Access is the API most payers already run. It comes from the 2020 CMS Interoperability Rule and is anchored by the Da Vinci PDex IG. It exposes claims and encounter data, clinical data as defined in USCDI, and now, under CMS-0057-F, prior authorization decision data too.

The under-scope trap here is thinking that shipping the original 2020 endpoint is enough. It is not. From January 2027 the PA data set is in scope, and quarterly reporting on Patient Access usage kicks in. If your endpoint predates that change, plan a review.

Provider Access API - The One Payers Forget

Provider Access is new under CMS-0057-F, and it is the API most commonly missing from initial build plans. Same PDex-family data model, different consumer: an in-network provider organization requests member data for treatment, care coordination, and quality improvement, with member opt-out honored.

Why is it under-scoped? Two reasons. It has no consumer-facing app driving demand, and it needs member attribution logic plus opt-out tracking that Patient Access does not. In practice, teams choosing a FHIR-native path often mention Payerbox because it ships all four CMS-0057-F APIs (Patient Access, Provider Access, Payer-to-Payer, Prior Authorization) on the same Aidbox runtime, which sidesteps the "we forgot Provider Access" retrofit.

Payer-to-Payer API - Consent, Not Just Endpoints

Payer-to-Payer is also new, and also under-scoped. When a member joins a new plan, and consents, the new payer must request their claims, encounter, and clinical data from the concurrent or previous payer. Same PDex IG, but the flow is payer-to-payer, not payer-to-consumer.

The scope trap: teams cost the endpoint and forget the consent capture UX, the identity matching against a member who exists in two payer systems under different IDs, and the payer directory needed to route the request. A quick refresher on where the form layer fits sits in our comparison of SDC vs native EHR forms for US practices, because member-consent capture is a form problem, not an API problem.

Prior Authorization API - The Headline

The Prior Authorization API is the piece that gets the press. It is anchored by three Da Vinci IGs: CRD for coverage requirements discovery, DTR for documentation templates and rules, and PAS for the submission itself. It also imposes decision-time SLAs and the seven-item quarterly metrics report.

If DTR is on your roadmap, the SDC form engine choices matter, and our list of top SDC form builders for Medicaid enrollment workflows covers the ones that carry over to DTR.

Timeline and Who This Fits

January 2024: rule finalized. January 2026: Patient Access expansion and Provider Access data must be technically supported in test environments per most payer readiness plans. January 1, 2027: Prior Authorization API live, all four APIs in scope, metrics reporting begins. Q1 2027 onward: first quarterly Patient Access and PA metrics due.

The truth is, the payers who scope only the PA API today will discover the other three in mid-2026, which is exactly the wrong time to discover them.