Provider Access API (CMS-0057-F)

CMS-0057-F (Interoperability and Prior Authorization Final Rule, 2024) introduced an obligation that has no precedent in earlier interoperability rules: payers must proactively share patient data with treating providers, without requiring the patient to initiate the request. This is the Provider Access API.

The distinction from the Patient Access API — which already exists under CMS-9115-F — is the requester. Patient Access is patient-initiated: the patient authorizes an app to retrieve their data. Provider Access is provider-initiated: a treating clinician’s system requests data from the payer directly, using the provider relationship to the patient as the authorization basis. The patient doesn’t need to act; the treating relationship is sufficient.

Compliance deadline: January 1, 2027.

For broader CMS interoperability obligations context, see CMS Interoperability Rules. For the patient-initiated equivalent, see Patient Access (US).

What the obligation requires

Covered payers must implement a FHIR-based API that allows an attributed treating provider to request and receive their patients’ data from the payer. The payer must respond with:

Claims and encounter data — adjudicated claims (ExplanationOfBenefit)
Clinical data — clinical information in the payer’s possession (US Core profiles)
Prior authorization data — pending and approved prior authorizations, including the reason for denial on denied PAs

The API must be available without a per-request patient consent step. The treating relationship — established through the payer’s attribution or network data — is the authorization basis.

Which payers are covered

The Provider Access API obligation applies to:

Medicare Advantage organizations
State Medicaid fee-for-service programs
CHIP
Qualified Health Plan (QHP) issuers on the Federally Facilitated Exchanges

Fee-for-service Medicare (Traditional Medicare / CMS directly) is not subject to this rule in the same way — CMS operates its own data-sharing mechanisms.

Technical implementation: PDex IG

The designated technical standard is the Da Vinci PDex (Payer Data Exchange) Implementation Guide, built on top of HREX (Health Record Exchange), the Da Vinci base IG.

The PDex data model

PDex defines how payer-held data maps to FHIR resources:

Payer data	FHIR resource (PDex profile)
Adjudicated claims	ExplanationOfBenefit (CARIN Blue Button or PDex EOB profiles)
Medications from claims	MedicationDispense
Clinical data received from providers	US Core profiles (Condition, Observation, Procedure, etc.)
Prior authorizations	Claim (use: preauthorization) + ClaimResponse
Coverage	PDex Coverage
Provider directory	DaVinci PDex Plan Net (Organization, Practitioner, Location)

The member match operation

The core challenge of Provider Access is identity: a provider system knows a patient by their name and local MRN; the payer knows them by member ID and demographics. The HREX $member-match operation resolves this.

The provider submits a request to POST /Patient/$member-match with:

MemberPatient — patient demographics (name, date of birth, gender) from the provider’s system
CoverageToMatch — the plan/payer information, constructed from the insurance information in the provider’s system
CoverageToLink — optionally, the provider’s own Coverage representation to link in the response

{
  "resourceType": "Parameters",
  "parameter": [
    {
      "name": "MemberPatient",
      "resource": {
        "resourceType": "Patient",
        "name": [{ "family": "Doe", "given": ["Jane"] }],
        "birthDate": "1965-04-12",
        "gender": "female"
      }
    },
    {
      "name": "CoverageToMatch",
      "resource": {
        "resourceType": "Coverage",
        "status": "active",
        "subscriberId": "MEMBER-789",
        "payor": [{ "reference": "Organization/payer-acme" }]
      }
    }
  ]
}

The payer returns the matched patient with their internal member ID attached as an identifier. The provider system uses this identifier for all subsequent data requests.

If no match is found, or if the match is ambiguous (multiple possible patients), the operation returns an error. Payers must not return a match unless they have sufficient confidence — a false positive match means disclosing another patient’s data.

Retrieving patient data

After a successful member match, the provider system queries the payer’s FHIR server using standard FHIR search with the matched patient reference:

GET /ExplanationOfBenefit?patient=Patient/payer-internal-id-456&_count=50
GET /Condition?patient=Patient/payer-internal-id-456
GET /Claim?patient=Patient/payer-internal-id-456&use=preauthorization

The payer’s FHIR server is scoped by the provider’s authorization — only the provider’s attributed patients are accessible. A provider cannot query for patients they do not have an active treating relationship with.

Bulk vs on-demand

PDex supports both exchange patterns:

On-demand: Single patient queries at the point of care — a clinician pulls a specific patient’s payer data during an encounter. Low latency, specific to one patient.

Bulk (attribution-based): The provider organization submits a Group-level $export request for all their attributed patients. The payer exports all current data for the attributed population as NDJSON. Suited for care management, population health, and pre-visit data enrichment.

For bulk, the provider must first retrieve their attributed patient list from the payer. PDex defines a Group resource representing the attributed population, accessible via GET /Group?managingEntity=Organization/provider-org.

Authorization model

SMART Backend Services

Provider Access API uses SMART Backend Services (also called SMART App Launch for Backend Services) — the OAuth2 client credentials grant with asymmetric key authentication. This is appropriate for system-to-system access where no human user session is present.

The provider organization registers with the payer’s authorization server, providing a public key. Subsequent access token requests are signed with the corresponding private key. There is no per-encounter user authentication — the provider’s organizational credentials authorize access to their attributed patient population.

How this differs from Patient Access API authentication

Patient Access uses the authorization code grant — a patient logs in, consents, and the app gets a token scoped to that patient. Provider Access uses client credentials — no patient login, no individual consent step, organizational authorization based on the treating relationship.

This distinction matters for implementation: Patient Access requires an OAuth2 flow that surfaces to end users; Provider Access is a server-to-server integration that runs in the background.

Attribution: how the payer knows who qualifies

The payer determines which patients a provider is authorized to access based on their attribution list — typically derived from claims history (patients who have had claims adjudicated for services from this provider in the last 12 months) or from network credentialing data.

Payers must maintain attribution lists and update them regularly. Providers must be able to retrieve their current attributed patient list. The rule does not prescribe a specific attribution methodology, but the payer must be able to defend their attribution logic.

Data scope

Required data

CMS-0057-F requires the following data to be accessible via the Provider Access API:

Claims data — adjudicated claims for the patient from the payer. ExplanationOfBenefit using CARIN Blue Button or PDex profiles. This includes medical claims, pharmacy claims, and dental claims where available.

Clinical data — clinical information the payer has received from other providers (lab results, diagnoses, procedures) that the payer holds. The source of this data is typically prior claims and encounter data from other treating providers. US Core profiles apply.

Prior authorization data — all pending and active prior authorizations for the patient, including the reason for denial on denied authorizations. This is new in CMS-0057-F — prior authorization data was not required in the CMS-9115-F Patient Access API.

What is excluded

Mental health and substance use disorder records protected under 42 CFR Part 2 require separate handling and may be excluded
Confidential communication requests from patients may restrict certain data elements
Data the payer doesn’t actually hold — the rule requires sharing what the payer has, not soliciting data from third parties to fulfill the request

Provider Access vs Patient Access: a comparison

Dimension	Patient Access API	Provider Access API
Who requests	Patient (via authorized app)	Treating provider (system-to-system)
Authorization	Patient consent (OAuth2 auth code)	Provider organization credential (SMART Backend Services)
Patient action required	Yes — patient must authorize	No — treating relationship is sufficient
Data scope	Same (claims, clinical, PA)	Same (claims, clinical, PA)
Mandate	CMS-9115-F (2021)	CMS-0057-F (2027)
Technical IG	CARIN Blue Button + US Core	PDex + HREX
Bulk access	Not typically required	Yes — attributed population export

The data that a patient can retrieve about themselves via Patient Access is the same data a treating provider can retrieve via Provider Access. The authorization mechanism and the initiator differ.

Implementation considerations

For payers

Attribution management: Maintaining accurate, current attribution lists is the operational foundation of the API. An incorrect attribution list means providers either can’t access patients they should, or can access patients they shouldn’t. Both are failures — one operational, one a potential privacy violation. Attribution updates should reflect new claims data within days, not months.

Member match reliability: A low match rate means providers can’t access data and fall back to manual processes. A high false-positive rate means potential data disclosure errors. Member match threshold tuning is a launch-readiness criterion, not an afterthought. Test against realistic demographic data quality — names with special characters, non-standard date formats, demographic mismatches between systems.

Prior authorization data completeness: CMS-0057-F specifically requires that prior authorization data — including pending authorizations and denial reasons — is accessible. Payers whose PA data is in a separate system from their claims system need to integrate that data into the Provider Access API response. Denial reasons must be structured (not free text) to meet the rule’s requirements.

Bulk export capacity: Attribution-based bulk export for large provider organizations will generate significant data volume. The bulk export infrastructure must handle concurrent exports across the provider population without degrading on-demand query response times.

For provider systems (EHRs and care management platforms)

Member match integration: This is typically the first thing to implement and test. Demographic data quality from the provider’s system determines match success. Common failure modes: middle names included in the family name field, date of birth off by one day from insurance enrollment data, subscriber ID format mismatches.

Data integration into clinical workflow: Retrieved payer data (claims-derived conditions, prior authorizations, medication dispense records) needs to reconcile with data the provider already has. Duplicate detection and reconciliation logic is necessary — a clinician shouldn’t see the same condition listed twice because it came from both the EHR and the payer.

Attribution list maintenance: Provider systems should retrieve and cache their attribution list rather than running member match on every patient encounter. The list changes as claims are adjudicated; a weekly refresh cadence is typically sufficient.

PA data surfacing: Prior authorization status from the payer should be visible in the ordering and referral workflow — a clinician ordering a service that has a pending PA from a different episode shouldn’t submit a duplicate PA request.

Compliance timeline

Requirement	Deadline
Provider Access API live (MA, Medicaid, CHIP, QHP)	January 1, 2027
Prior authorization data included in Provider Access	January 1, 2027
Attribution list available to providers	January 1, 2027
Bulk access capability	January 1, 2027

The January 2027 deadline provides meaningful lead time relative to the 2024 rule publication — but PDex implementation, member match tuning, attribution system build-out, and provider onboarding are each multi-quarter efforts. Payers who haven’t started planning by mid-2025 are likely to be late.

Evidence checklist

PDex IG conformance validation passing for ExplanationOfBenefit, Claim, Coverage, clinical resources
$member-match operational with documented match confidence thresholds
Attribution list available as FHIR Group resource, updated at defined cadence
SMART Backend Services authorization server operational
Bulk export ($export) available for attributed Group
Prior authorization data (pending, active, denied with reason) included in responses
Mental health / 42 CFR Part 2 data handling documented
Provider onboarding process documented

Provider Access API (CMS-0057-F)

Provider Access API (CMS-0057-F)

What the obligation requires

Which payers are covered

Technical implementation: PDex IG

The PDex data model

The member match operation

Retrieving patient data

Bulk vs on-demand

Authorization model

SMART Backend Services

How this differs from Patient Access API authentication

Attribution: how the payer knows who qualifies

Data scope

Required data

What is excluded

Provider Access vs Patient Access: a comparison

Implementation considerations

For payers

For provider systems (EHRs and care management platforms)

Compliance timeline

Evidence checklist

See also