Why CMS-0057-F uses APIs
The CMS Interoperability and Prior Authorization final rule (CMS-0057-F) does not simply ask payers to "share more data." It requires standards-based application programming interfaces so that patients, providers, and other payers can retrieve data programmatically, on demand, using off-the-shelf clients. The rule builds on the 2020 CMS Interoperability and Patient Access rule, which first mandated a FHIR-based Patient Access API.
APIs matter because the alternative — bespoke files, portals, and faxes — does not scale across hundreds of payers and thousands of trading partners. By standardizing on HL7 FHIR, CMS lets a single provider EHR or patient app work against every impacted payer without custom integration for each one. It is worth being precise about what is mandated: CMS mandates the API outcome and the standards, not a specific internal architecture. How you assemble the services behind the API is an implementation decision.
Where FHIR fits across the four APIs
All four required APIs are FHIR APIs, but they differ in who calls them, how they authorize, and which resources they surface. Treat the table below as the anchor for the rest of this guide.
| API | Primary caller | Authorization pattern | Representative FHIR resources |
|---|---|---|---|
| Patient Access | Patient's chosen app | SMART App Launch (user-facing OAuth 2.0) | Patient, ExplanationOfBenefit, Coverage, USCDI clinical resources |
| Provider Access | Provider system / EHR | SMART Backend Services (system-to-system) | ExplanationOfBenefit, USCDI clinical resources, PA via Claim/ClaimResponse |
| Payer-to-Payer | Another payer | SMART Backend Services (system-to-system) | Same clinical + claims set, exchanged as a bulk/query payload with Provenance |
| Prior Authorization | Provider system / EHR | SMART Backend Services + CDS Hooks (CRD) | Claim, ClaimResponse, Questionnaire, QuestionnaireResponse, Bundle |
A single member's data therefore needs to be projectable into FHIR for three very different audiences. That is the central engineering fact of CMS-0057-F: you are building one FHIR data layer with several authorization surfaces on top of it.
US Core and USCDI
The rule's clinical data requirement is expressed through the content standard at 45 CFR 170.213 (USCDI) and profiled with the HL7 US Core Implementation Guide. USCDI defines what data classes and elements must be exchangeable; US Core defines how those elements are represented as FHIR profiles (for example, US Core Patient, Condition, Observation, and MedicationRequest).
CapabilityStatement, and confirm current expectations against the 2026 status page and official ONC/ASTP guidance rather than assuming a single fixed version.
Relevant Da Vinci implementation guides
CMS strongly recommends the HL7 Da Vinci implementation guides to profile payer FHIR resources consistently. You are not strictly required to use them, but interoperability with providers is far easier if you do.
- PDex (Payer Data Exchange) — profiles for exchanging clinical and claims data; the backbone of Provider Access and Payer-to-Payer payloads.
- CARIN Blue Button —
ExplanationOfBenefitprofiles for consumer-facing claims in the Patient Access API. - CRD, DTR, and PAS — the three prior authorization IGs. These get a dedicated treatment in CRD, DTR and PAS explained.
- Formulary / plan-net — supporting directories where applicable.
SMART on FHIR & OAuth
Authorization is where the four APIs diverge most. Two patterns cover the rule:
SMART App Launch (Patient Access)
The Patient Access API is consumer-facing, so it uses the SMART App Launch framework — an OAuth 2.0 profile with OpenID Connect for identity — to let a member authorize a third-party app to read their data. The member authenticates, consents to scopes, and the app receives a token scoped to that member's compartment.
SMART Backend Services (Provider, Payer-to-Payer, PA)
The system-to-system APIs use the SMART Backend Services authorization profile: asymmetric client authentication (a registered client key), the OAuth 2.0 client_credentials grant, and no interactive user. This is the right pattern for a provider organization or a peer payer pulling data on behalf of many patients.
Terminology
FHIR is only interoperable when codes are. Payer source systems frequently carry proprietary or legacy code sets that must be normalized to the standard terminologies providers expect: ICD-10-CM, CPT/HCPCS, LOINC, SNOMED CT, RxNorm, NDC, and the various FHIR/US Core value sets. Plan for a terminology service (or a well-governed mapping layer) as a first-class component, not an afterthought — mismatched or missing codes are among the most common causes of failed provider integration.
Mapping FHIR APIs to existing payer data models
Most impacted payers already hold the required data — in claims systems, care management systems, enrollment systems, and clinical repositories. The work is projecting that data into conformant FHIR resources. A few mappings recur:
| Payer source concept | Typical FHIR representation |
|---|---|
| Member / enrollment record | Patient + Coverage |
| Adjudicated claim / encounter | ExplanationOfBenefit (CARIN BB / PDex profiles) |
| Clinical data (labs, conditions, meds) | US Core Observation, Condition, MedicationRequest, … |
| Prior authorization record | Claim (use=preauthorization) + ClaimResponse |
| Data source / lineage | Provenance |
The mapping layer is also where you enforce scoping rules that the rule requires — for example, excluding provider remittances and cost-sharing detail from the Provider Access and Payer-to-Payer payloads.
Reference architecture: integration with legacy core administration platforms
A defensible CMS-0057-F architecture treats the FHIR API as a boundary, with an interoperability/orchestration layer behind it that adapts to whatever payer domain services and core administration platform you already run. It should not be thought of as exposing the core administration database directly.
The interoperability layer can sit in front of an existing core system as an overlay, or a modern payer backend can provide these capabilities natively. A modern payer platform such as CloudHealthOffice can serve as either an interoperability layer integrated with an existing core administration system or, depending on the implementation model, as part of the core backend itself. Either way, the vendor-specific integration is an adapter concern — do not assume any core administration product natively provides CMS-0057-F FHIR APIs unless that product's documentation states so.
Operational considerations
Security
Enforce TLS, strong client registration and key rotation for backend services, granular OAuth scopes, and audit logging of every access. Treat the Patient Access consent event and the member's app authorization as security-relevant records.
Observability
Instrument request latency, error rates by resource type, token issuance, and per-partner volumes. The rule also requires reporting Patient Access API usage metrics to CMS, so capture unique-member counts by design.
Testing
Validate resources against the declared profiles (US Core, CARIN, PDex, PAS) using the HL7 validator and tools such as Inferno/Touchstone. Test the full SMART flows, not just resource reads. Include negative tests for opt-out and consent.
Implementation roadmap
- Confirm scope and versions. Which payer lines are in scope; which US Core / USCDI versions you will serve; which Da Vinci IGs you will conform to.
- Stand up the FHIR gateway and OAuth. SMART App Launch for Patient Access; SMART Backend Services for the system-to-system APIs.
- Build the mapping + terminology layer. Project members, claims, and clinical data into conformant resources with
Provenance. - Deliver the APIs in dependency order. Patient Access first (it reuses the most existing work), then Provider Access, Payer-to-Payer, and Prior Authorization (CRD → DTR → PAS).
- Wire consent and opt-out. Patient opt-out for Provider Access; member permission for Payer-to-Payer.
- Validate, load-test, and instrument. Conformance testing plus the CMS usage metrics you must report.