Payer-Provider Data Exchange with FHIR: What the CMS Payer-to-Payer API Actually Requires

The Regulatory Earthquake — CMS-0057-F Changes Everything

The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F), published in February 2024, requires regulated payers—Medicare Advantage, Medicaid, CHIP, and Qualified Health Plans on the federal exchange—to implement three distinct FHIR-based APIs by January 1, 2027.

This is not optional. CMS has enforcement authority, and operational requirements kicked in January 1, 2026. If you are a regulated payer, you need to be building now. If you are a provider or health IT vendor, you need to understand what data becomes available and how to consume it.

This guide covers what each API requires, which FHIR Implementation Guides apply, how to map claims data to FHIR resources, and how $member-match works in practice.

The Three CMS-Mandated FHIR APIs

CMS-0057-F mandates three APIs, each serving a different data consumer. Understanding their distinct purposes is essential before writing a single line of code.

Patient Access API

The Patient Access API gives patients direct access to their own health plan data through third-party applications. This API was originally mandated by the 2020 Interoperability and Patient Access Rule, but CMS-0057-F expands its scope significantly.

What must be exposed:

• Claims and encounter data (as ExplanationOfBenefit resources)
• Clinical data including conditions, medications, allergies, lab results
• Prior authorization decisions and status
• Provider directory information
• Drug formulary data (as InsurancePlan and MedicationKnowledge)

Auth requirement: SMART on FHIR with patient-facing OAuth 2.0. Patients authenticate through a member portal and authorize third-party apps to access their data. The FHIR interoperability standards we have covered previously form the foundation for this API.

Provider Access API

The Provider Access API is new under CMS-0057-F. It gives in-network providers access to payer-held data about their attributed patients. This is a significant advantage for care coordination—providers can now see claims from other providers, prior authorization status, and clinical data the payer has received from other sources.

What must be exposed:

• Claims and encounter data (non-financial view—no provider remittances)
• All USCDI data classes and elements the payer holds
• Prior authorization decisions (excluding denied and drug-related)

Auth requirement: SMART Backend Services (OAuth 2.0 client credentials). No patient interaction required. The provider system authenticates directly with the payer's FHIR server.

Payer-to-Payer API

The Payer-to-Payer API enables health plans to exchange member data when a patient switches coverage. When a member enrolls with a new plan, the new payer can request the member's historical data from the previous payer—with the member's consent.

Notably, what exchanged:

• Claims and encounter data (excluding provider remittances and cost-sharing)
• All USCDI data classes and elements
• Prior authorization decisions (same exclusions as Provider Access)

Auth requirement: mTLS for server-to-server trust, OAuth 2.0 Dynamic Client Registration, then client credentials for ongoing access. The $member-match operation identifies the member across payers.

For members with concurrent coverage, payers must share relevant data at least quarterly—this is an ongoing obligation, not just a one-time transfer.

FHIR Implementation Guides — Which IGs Apply Where

CMS references specific HL7 Implementation Guides that payers must conform to. Understanding which IG maps to which API is critical.

The CARIN Blue Button IG focuses on claims data as FHIR ExplanationOfBenefit resources with adjudication details. The Da Vinci PDex IG uses US Core profiles to represent clinical data from claims, prior authorizations, and clinical exchanges. Understanding HL7 and FHIR standards helps contextualize how these IGs fit the broader landscape.

Data Mapping — Claims to FHIR Resources

The hardest part is not standing up a FHIR server—it is mapping existing claims data into conformant FHIR resources.

Claims to ExplanationOfBenefit

The ExplanationOfBenefit (EOB) resource is the workhorse of payer FHIR APIs. It represents a processed claim, including what was billed, what was covered, and what the patient owes. The CARIN Blue Button IG defines four EOB profiles based on claim type:

• Inpatient Institutional — hospital admissions
• Outpatient Institutional — outpatient facility services
• Professional NonClinician — physician and supplier claims
• Pharmacy — prescription drug claims

{
  "resourceType": "ExplanationOfBenefit",
  "id": "eob-professional-example",
  "meta": {
    "profile": [
      "http://hl7.org/fhir/us/carin-bb/StructureDefinition/C4BB-ExplanationOfBenefit-Professional-NonClinician"
    ]
  },
  "status": "active",
  "type": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/claim-type",
      "code": "professional"
    }]
  },
  "use": "claim",
  "patient": {
    "reference": "Patient/member-123"
  },
  "billablePeriod": {
    "start": "2025-11-01",
    "end": "2025-11-01"
  },
  "insurer": {
    "reference": "Organization/payer-acme"
  },
  "provider": {
    "reference": "Practitioner/dr-smith"
  },
  "outcome": "complete",
  "item": [{
    "sequence": 1,
    "productOrService": {
      "coding": [{
        "system": "http://www.ama-assn.org/go/cpt",
        "code": "99213",
        "display": "Office visit, established patient, low complexity"
      }]
    },
    "servicedDate": "2025-11-01",
    "adjudication": [
      {
        "category": {
          "coding": [{
            "system": "http://terminology.hl7.org/CodeSystem/adjudication",
            "code": "submitted"
          }]
        },
        "amount": { "value": 150.00, "currency": "USD" }
      },
      {
        "category": {
          "coding": [{
            "system": "http://terminology.hl7.org/CodeSystem/adjudication",
            "code": "benefit"
          }]
        },
        "amount": { "value": 120.00, "currency": "USD" }
      },
      {
        "category": {
          "coding": [{
            "system": "http://terminology.hl7.org/CodeSystem/adjudication",
            "code": "copay"
          }]
        },
        "amount": { "value": 30.00, "currency": "USD" }
      }
    ]
  }],
  "total": [
    {
      "category": {
        "coding": [{
          "system": "http://hl7.org/fhir/us/carin-bb/CodeSystem/C4BBAdjudication",
          "code": "paidtoprovider"
        }]
      },
      "amount": { "value": 120.00, "currency": "USD" }
    }
  ]
}

Key mapping decisions you will face:

• Adjudication categories: The CARIN IG defines specific adjudication slice codes (paidtoprovider, paidbypatient, memberliability). Your claims system likely uses different internal codes—build a mapping table.
• Provider references: EOB references both the billing and rendering provider. If your claims system stores NPI numbers, you need to resolve them to FHIR Practitioner or Organization resources.
• Diagnosis coding: Claims carry ICD-10 codes. These map to EOB diagnosis elements with type codes distinguishing principal, admitting, and secondary diagnoses.

Formulary to InsurancePlan

The Drug Formulary IG maps formulary data to two FHIR resource types. The InsurancePlan resource represents the overall plan and its cost-sharing tiers, profiled as usdf-PayerInsurancePlan. The MedicationKnowledge resource (profiled as FormularyDrug) represents each drug with its tier placement, prior authorization requirements, and quantity limits. Coverage benefits are categorized by drug tier (generic, preferred-brand, non-preferred-brand, specialty) using the usdf-DrugTierCS code system.

The $member-match Operation — Identifying Members Across Payers

Before any payer-to-payer data exchange can happen, the new payer must identify the member in the old payer's system. This is what the $member-match operation solves. It is defined in the Da Vinci HRex IG and is mandatory for the Payer-to-Payer API.

How $member-match Works

The operation accepts three input parameters:

1. MemberPatient: The patient demographics as known by the requesting (new) payer—name, date of birth, gender, address.
2. CoverageToMatch: The old coverage information—typically the member ID and payer identifier from the old plan.
3. CoverageToLink: The new coverage information—the new plan's member ID and payer identifier.

POST [old-payer-fhir-base]/Patient/$member-match
Content-Type: application/fhir+json

{
  "resourceType": "Parameters",
  "parameter": [
    {
      "name": "MemberPatient",
      "resource": {
        "resourceType": "Patient",
        "name": [{
          "family": "Johnson",
          "given": ["Sarah"]
        }],
        "gender": "female",
        "birthDate": "1985-03-15"
      }
    },
    {
      "name": "CoverageToMatch",
      "resource": {
        "resourceType": "Coverage",
        "status": "active",
        "beneficiary": {
          "reference": "Patient/placeholder"
        },
        "payor": [{
          "identifier": {
            "system": "http://hl7.org/fhir/sid/us-npi",
            "value": "1234567890"
          }
        }],
        "identifier": [{
          "system": "https://old-payer.example.com/memberid",
          "value": "OLD-MEM-98765"
        }]
      }
    },
    {
      "name": "CoverageToLink",
      "resource": {
        "resourceType": "Coverage",
        "status": "active",
        "beneficiary": {
          "reference": "Patient/new-member-456"
        },
        "payor": [{
          "identifier": {
            "system": "http://hl7.org/fhir/sid/us-npi",
            "value": "0987654321"
          }
        }]
      }
    }
  ]
}

If the old payer finds a unique match, it returns the member's Patient resource with a unique identifier that the new payer can use for subsequent data requests. If no match is found, or multiple matches exist, the operation returns a 422 Unprocessable Entity status.

Security Requirements for $member-match

The security chain follows five steps: (1) mTLS—both payers present X.509 certificates, (2) Dynamic Client Registration using the mTLS connection, (3) Client Credentials Grant for an access token, (4) $member-match call to identify the member, and (5) data retrieval using the matched member ID. If you are building healthcare integration platforms, this security chain is a critical requirement.

Consent Management for Payer Data Exchange

CMS-0057-F requires that payer-to-payer data exchange only happens with the member's consent. The FHIR Consent resource captures this permission electronically.

When Consent Is Required

Consent is required in two scenarios: when a member enrolls in a new plan (member-initiated exchange), and for members with concurrent coverage (quarterly data sharing). CMS specifies a "per policy" consent model—the member consents to sharing all data for a specific coverage period. Granular data-type opt-out is not required.

{
  "resourceType": "Consent",
  "id": "p2p-consent-example",
  "status": "active",
  "scope": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/consentscope",
      "code": "patient-privacy"
    }]
  },
  "category": [{
    "coding": [{
      "system": "http://loinc.org",
      "code": "64292-6",
      "display": "Release of information consent"
    }]
  }],
  "patient": {
    "reference": "Patient/member-123"
  },
  "dateTime": "2026-01-15T10:30:00Z",
  "performer": [{
    "reference": "Patient/member-123"
  }],
  "organization": [{
    "reference": "Organization/new-payer-org"
  }],
  "policy": [{
    "authority": "https://www.cms.gov",
    "uri": "https://www.cms.gov/priorities/burden-reduction/overview/interoperability"
  }],
  "provision": {
    "type": "permit",
    "period": {
      "start": "2024-01-01",
      "end": "2025-12-31"
    },
    "actor": [
      {
        "role": {
          "coding": [{
            "system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType",
            "code": "IRCP"
          }]
        },
        "reference": {
          "reference": "Organization/new-payer-org"
        }
      }
    ],
    "action": [{
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/consentaction",
        "code": "access"
      }]
    }]
  }
}

Provider Access API — Architecture Deep Dive

The Provider Access API is architecturally distinct from the Patient Access API because it uses backend services authorization rather than user-facing OAuth flows.

Attribution and Access Control

CMS requires that payers establish attribution—linking members to their treating providers—and only return data for attributed patients. Attribution can be based on primary care assignment, recent claims history, active referrals, or provider network contracts.

Bulk Data Export for Provider Access

For providers who need data for large patient panels, the Provider Access API supports FHIR Bulk Data Export via the $export operation, returning data as NDJSON files.

GET [payer-fhir-base]/Group/attributed-panel-dr-smith/$export
Accept: application/fhir+json
Prefer: respond-async
Authorization: Bearer {backend-services-token}

# Response: 202 Accepted
Content-Location: https://payer.example.com/fhir/bulkstatus/export-job-789

# When complete, response includes download links:
{
  "transactionTime": "2026-01-15T10:00:00Z",
  "requiresAccessToken": true,
  "output": [
    {"type": "ExplanationOfBenefit", "url": "https://payer.example.com/fhir/bulkdata/eob.ndjson", "count": 15420},
    {"type": "Patient", "url": "https://payer.example.com/fhir/bulkdata/patient.ndjson", "count": 2300},
    {"type": "Condition", "url": "https://payer.example.com/fhir/bulkdata/condition.ndjson", "count": 8750}
  ]
}

This bulk access pattern is valuable for clinical decision support systems that need comprehensive patient data for population health analytics.

Implementation Architecture

A production-grade implementation of all three APIs requires careful architectural planning. Here is a reference architecture that separates concerns appropriately.

Core Components

When teams evaluating technology stacks for this kind of system, our guide on choosing the right technology stack for healthcare software covers the trade-offs between managed FHIR services and custom implementations.

Data Pipeline Architecture

Claims data from the adjudication system must be continuously mapped to FHIR resources. A practical pipeline follows this pattern: resolve references (member ID to Patient, NPI to Practitioner/Organization), map claim type to the correct CARIN profile (Inpatient Institutional, Outpatient Institutional, Professional NonClinician, or Pharmacy), build the EOB resource with item-level adjudication, validate against the CARIN profile, and store in the FHIR server.

# Claims-to-FHIR Pipeline (Python pseudocode)
def process_adjudicated_claim(claim_event):
    patient = resolve_patient(claim_event.member_id)
    provider = resolve_provider(claim_event.billing_npi)
    
    profile_map = {
        'I': 'C4BB-ExplanationOfBenefit-Inpatient-Institutional',
        'O': 'C4BB-ExplanationOfBenefit-Outpatient-Institutional',
        'P': 'C4BB-ExplanationOfBenefit-Professional-NonClinician',
        'R': 'C4BB-ExplanationOfBenefit-Pharmacy'
    }
    profile = profile_map[claim_event.claim_type]
    
    eob = build_eob(claim_event, patient, provider, profile)
    validation = validate_resource(eob, profile)
    if validation.is_valid:
        fhir_client.update(eob)
    return eob

CMS-0057-F Compliance Timeline

Understanding the phased compliance deadlines is critical for project planning.

Realistic Implementation Timeline

For a mid-size health plan, expect 14-20 months total: Discovery and gap analysis (2-3 months), core infrastructure (3-4 months), Patient Access API (2-3 months), Provider Access API (2-3 months), Payer-to-Payer API (3-4 months), and testing/certification (2-3 months). If you started in January 2026, you are cutting it close for the January 2027 deadline.

Testing and Validation

CMS references the ONC Inferno testing framework for validating FHIR API conformance. Key test suites include US Core Server Tests, SMART App Launch Tests, CARIN Blue Button Tests for EOB conformance, and Bulk Data Tests for $export validation. Beyond Inferno, conduct partner testing with at least two other payers to validate the payer-to-payer exchange flow end-to-end—especially the $member-match operation and mTLS handshake.

Common Implementation Pitfalls

Having worked with health plans implementing these APIs, here are the four most common pitfalls:

• Treating FHIR as a thin API layer: FHIR resources have complex reference networks—an EOB references Patient, Practitioner, Organization, and Coverage resources. You need a FHIR-native data store or a robust pre-computation pipeline, not a simple translation layer.
• Ignoring the non-financial view requirement: The Provider Access API requires stripping provider remittances and cost-sharing from claims data. This requires a separate transformation, not just field removal.
• Underestimating $member-match complexity: Members change names, addresses, and insurance IDs. You need a Master Patient Index with probabilistic matching—not exact string comparison.
• Consent as an afterthought: Consent management must be designed in from the start. It affects $member-match (consent evaluation before returning a match), data retrieval (consent scope), and audit logging.

Frequently Asked Questions

What is the CMS Payer-to-Payer API?

The CMS Payer-to-Payer API is a FHIR-based interface mandated by the CMS-0057-F rule that enables health plans to exchange member health data when a patient switches coverage. It uses the Da Vinci PDex Implementation Guide and the $member-match operation to identify members across payers. The API must be operational by January 1, 2027.

What payers are affected by CMS-0057-F?

The rule applies to Medicare Advantage organizations, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plans on the federally-facilitated exchange. Fee-for-service Medicare and commercial plans not on the exchange are not directly regulated, though many voluntarily adopt the standards.

How does $member-match handle name changes?

The $member-match operation uses probabilistic matching via a Master Patient Index (MPI) that considers name, date of birth, gender, address, and old member ID. The CoverageToMatch member ID is typically the strongest matching signal. Implementations should handle name variations and common data entry errors.

What data must be excluded from the Provider Access API?

The Provider Access API must exclude provider remittance information, enrollee cost-sharing amounts, denied prior authorizations, and drug-related prior authorizations.

Can patients opt out of payer-to-payer data exchange?

Yes. CMS-0057-F requires explicit member consent. The opt-out is all-or-nothing at the policy level—granular data-type opt-out is not required but may be offered.

What FHIR version do the APIs require?

All three APIs require FHIR R4 (version 4.0.1). All referenced IGs (CARIN Blue Button, Da Vinci PDex, Da Vinci HRex) are built on R4.