The FHIR Provider Access API Under CMS-0057-F

What Is the CMS Provider Access API?

The Provider Access API is a FHIR-based application programming interface that CMS-0057-F requires impacted payers to build so that in-network providers can retrieve the data a payer holds about their attributed patients — claims and encounter data, USCDI clinical data, and prior authorization information. Today, providers lack a standardized mechanism to retrieve patient data held by payers, which creates redundant testing, delayed care decisions, and fragmented records. The Provider Access API closes that gap by exposing a standards-based FHIR endpoint providers can query from their own systems, using the same technical standards that already underpin EHR interoperability.

It is one of the four APIs mandated by the rule. For how it sits alongside the others, see the CMS-0057-F fact sheet; for the underlying standards, see FHIR for CMS-0057-F.

Who Must Implement the Provider Access API?

The same impacted payers covered by the rest of the rule must build the Provider Access API:

• Medicare Advantage organizations
• State Medicaid and CHIP fee-for-service (FFS) programs
• Medicaid managed care plans (MCOs, PIHPs, PAHPs) and CHIP managed care entities
• Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs)

Stand-alone dental plans, FF-SHOP issuers, and State-based Exchange issuers are excluded. Medicare FFS is not directly mandated, though CMS has stated its intent to comply voluntarily.

What Data Must Be Exposed Through the Provider Access API

Patient Opt-Out Rights

Patients must have the ability to opt out of having their data shared with providers through this API. Payers are required to implement a clear opt-out process and disseminate educational resources to both patients and providers about the API's purpose, the types of data shared, and how to exercise opt-out rights.

Compliance Dates

• MA organizations & state Medicaid/CHIP FFS programs: January 1, 2027
• Medicaid managed care plans & CHIP managed care entities: Rating period beginning on or after January 1, 2027
• QHP issuers on the FFEs: Plan years beginning on or after January 1, 2027

How FHIR Is Used

The Provider Access API is a FHIR R4 API. Payers expose the required data as conformant FHIR resources — ExplanationOfBenefit for adjudicated claims, US Core clinical resources (Condition, Observation, MedicationRequest, and the rest) for USCDI data, and Claim/ClaimResponse for prior authorization information. Because providers query by attributed patient population rather than one patient at a time, the FHIR Bulk Data Access (Flat FHIR) specification is central: it lets a provider organization export data for a group of patients efficiently. For a deeper treatment of how FHIR maps to existing payer data, see FHIR for CMS-0057-F.

Required Standards

The Provider Access API must conform to the same base technical standards as the Patient Access API:

• HL7 FHIR Release 4.0.1 (45 CFR 170.215(a)(1))
• US Core IG STU 3.1.1 (45 CFR 170.215(b)(1)(i)) — payers may serve a later version as a superset
• FHIR Bulk Data Access IG v1.0.0 (45 CFR 170.215(d)(1)) — for bulk data retrieval by provider organizations

Authentication and Authorization

Unlike the Patient Access API — which uses SMART App Launch for consumer-facing OAuth 2.0 flows — the Provider Access API is a system-to-system integration and uses the SMART Backend Services authorization profile. Backend Services relies on asymmetric client authentication (a registered client key rather than an interactive login) and the OAuth 2.0 client_credentials grant, which is the appropriate pattern for a provider organization pulling data on behalf of many attributed patients.

Key authorization concerns for payers:

• Provider attribution — the payer must resolve which patients a requesting provider is entitled to, and scope every response accordingly.
• Patient opt-out — opt-out status must be enforced at the authorization/scoping layer, before any data is released.
• Client registration and key rotation — trading partners register keys; plan for rotation and revocation.

Recommended Implementation Guides

CMS strongly recommends payers use the HL7 Da Vinci Payer Data Exchange (PDex) Implementation Guide and the Da Vinci Prior Authorization Support (PAS) IG to profile the FHIR resources exposed through this API. These IGs define payer-specific resource profiles, search parameters, and capability statements that help ensure consistent implementation across payers.

Provider Access API Architecture

A defensible implementation treats the FHIR endpoint as a boundary in front of an interoperability layer that adapts to your existing payer systems — it should not be a direct window onto the core administration database.

For how this layered approach maps onto an established core platform, see CMS-0057-F with QNXT.

Provider Access vs. Patient Access API

The two APIs share a technical foundation but differ in audience, authorization, and scope. The Provider Access API is not simply "Patient Access for providers."

Relationship to Value-Based Care

The Provider Access API is explicitly designed to accelerate the transition to value-based care models. By giving providers real-time access to adjudicated claims and prior authorization data, payers enable risk-bearing providers to manage population health more effectively, reduce unnecessary utilization, and close gaps in care — all without building custom point-to-point integrations with each payer.

Payer Implementation Checklist

• Stand up a FHIR R4 endpoint with a published CapabilityStatement for the Provider Access API.
• Implement SMART Backend Services authorization with client registration and key rotation.
• Build provider attribution resolution and enforce it on every response.
• Implement patient opt-out and enforce it at the scoping layer.
• Support FHIR Bulk Data export for attributed-patient populations.
• Map claims, USCDI clinical data, and PA records to conformant US Core / PDex / PAS profiles.
• Exclude provider remittances and patient cost-sharing from the payload.
• Add Provenance, audit logging, and conformance testing before onboarding trading partners.