Payer-to-Payer Data Exchange

When a patient changes health plans, their clinical and coverage history doesn’t automatically follow them. Payer-to-payer data exchange is the mechanism that closes that gap: the new plan requests the patient’s longitudinal record from the old plan, ensuring continuity of care information, medication history, and prior authorization history travels with the patient.

CMS has mandated this exchange for covered payers under two successive rules. The January 2027 compliance deadline under CMS-0057-F is the operative target for current implementation efforts.

For context on how payer-to-payer fits within the broader CMS regulatory picture, see CMS Interoperability Rules. For the closely related Provider Access API (also CMS-0057-F, also January 2027), see Provider Access API.

Regulatory history

Understanding the two-rule history matters because CMS-0057-F v2 requirements differ substantively from the CMS-9115-F v1 requirements — particularly on concurrent coverage and on technical approach.

CMS-9115-F (2020): the original mandate

CMS-9115-F, published March 2020 and effective July 2021, established the first payer-to-payer exchange requirement. The obligation: when a patient switches plans, the new plan must request the patient’s data from the prior plan, upon patient request.

Compliance deadline: January 1, 2022

The CMS-9115-F version was intentionally limited. It covered only the prior-to-new transition (not concurrent coverage), and the technical approach was less prescriptive than v2. Implementation quality across covered payers was inconsistent; CMS acknowledged the v1 requirement as a stepping stone rather than an end state.

CMS-0057-F (2024): expanded scope and concurrent coverage

CMS-0057-F, published February 2024, replaced the v1 approach with a fully FHIR-based model and expanded the obligation in two important ways:

Concurrent coverage: Not just prior-to-new transitions, but also simultaneous coverage periods. A patient with Medicare Advantage and a state Medicaid plan at the same time can trigger data exchange between them.
Prior authorization data: The old plan must share pending and previously approved prior authorizations, not just claims and clinical data.

Compliance deadline: January 1, 2027

Which payers are subject

Both rules apply to the same set of covered payers:

Payer type	Covered?
Medicare Advantage organizations	Yes
State Medicaid fee-for-service programs	Yes
CHIP fee-for-service	Yes
QHP issuers on Federally Facilitated Exchanges	Yes
Commercial/employer group health plans	No
Fee-for-service Medicare (Traditional Medicare)	No
Medicaid managed care organizations	Separate CMS managed care rules

Compliance timeline

Requirement	Rule	Deadline
P2P v1 (prior-to-new transitions, patient request)	CMS-9115-F	January 1, 2022
P2P v2 (FHIR PDex, concurrent coverage, PA data)	CMS-0057-F	January 1, 2027

The member match operation

The fundamental challenge in payer-to-payer exchange is identity: the new plan knows the patient by their enrollment demographics; the old plan knows them by their member ID and their own enrollment record. These may not match cleanly because of name variations, date-of-birth discrepancies in enrollment data, or different identifier systems entirely.

The HREX $member-match operation is the FHIR-specified solution.

Why member match is necessary

Without a standardized identity resolution step, each payer would need to implement ad hoc matching — proprietary demographic comparison logic, different thresholds, different error handling. The result would be a fragmented ecosystem where match success rates vary wildly by payer pair.

$member-match standardizes the inputs (what demographics and coverage information the requesting plan sends), the resolution logic (the responding plan determines the match), and the output (a matched patient identifier that can be used for subsequent data requests).

POST /Patient/$member-match

The operation is defined in the HREX IG and implemented as a FHIR operation at the patient endpoint:

POST [base]/Patient/$member-match

The requesting plan sends a Parameters resource with three inputs:

{
  "resourceType": "Parameters",
  "parameter": [
    {
      "name": "MemberPatient",
      "resource": {
        "resourceType": "Patient",
        "name": [{ "family": "Ochoa", "given": ["Maria"] }],
        "birthDate": "1971-09-03",
        "gender": "female"
      }
    },
    {
      "name": "CoverageToMatch",
      "resource": {
        "resourceType": "Coverage",
        "status": "active",
        "subscriberId": "OPM-887654",
        "payor": [{ "reference": "Organization/old-payer-org" }]
      }
    },
    {
      "name": "CoverageToLink",
      "resource": {
        "resourceType": "Coverage",
        "status": "active",
        "subscriberId": "NPM-112233",
        "payor": [{ "reference": "Organization/new-payer-org" }]
      }
    }
  ]
}

Input: MemberPatient and CoverageToMatch

MemberPatient: Patient demographics the requesting plan has on file — name, date of birth, gender, and any identifiers (like SSN or national ID) that might aid matching. The quality of these demographics determines match success rate. Common failure modes include:

Name field contains middle name or suffix
Date of birth off by one day due to time-zone issues in enrollment data
Gender coded differently between plans (male/female vs M/F)

CoverageToMatch: The insurance coverage record from the requesting plan’s perspective — the subscriber ID and payor reference that the responding plan should match against their own records. This is the most reliable matching anchor when it’s available.

CoverageToLink (optional): The requesting plan’s own coverage record for this patient. When present, the responding plan can include a reference to this coverage in the match response — useful for linking the patient record back to the requesting plan’s member in subsequent interactions.

Output: matched patient with NewCoverage reference

A successful match returns a Parameters resource containing the matched Patient with the responding plan’s internal member identifier attached:

{
  "resourceType": "Parameters",
  "parameter": [
    {
      "name": "MemberIdentifier",
      "valueIdentifier": {
        "system": "http://old-payer.example.org/members",
        "value": "OLD-MEMBER-543210"
      }
    }
  ]
}

The requesting plan uses OLD-MEMBER-543210 as the patient reference for all subsequent FHIR queries to the old plan’s API.

Match confidence and failure handling

The responding plan must not return a match unless confidence is sufficient — the specification doesn’t prescribe a specific algorithm, but requires that payers not match ambiguous cases. A false positive match means exposing one patient’s data to a requestor authorized for a different patient; this is a privacy violation.

Match failure responses:

Scenario	HTTP status	Typical OperationOutcome
Match found	200	Parameters with member identifier
No match found	422	OperationOutcome: match-not-found
Multiple candidates (ambiguous)	422	OperationOutcome: multiple-matches
Insufficient demographics	422	OperationOutcome: missing-required-data

Requesting plan handling: On a match-not-found, don’t retry immediately with the same data — the demographic data is what it is. Options: (a) prompt a manual enrollment verification, (b) queue for retry after plan-level data reconciliation, (c) treat as no prior coverage found. On multiple-matches, the requesting plan cannot disambiguate further without more information from the patient.

What data must be shared

CMS-9115-F scope (prior payer only)

Under v1, the old plan was required to share data it had received from providers for the patient:

Claims and encounter data (adjudicated)
Clinical data received from providers and in the payer’s possession

The v1 requirement did not include prior authorization data and applied only to the prior coverage period — not concurrent coverage.

CMS-0057-F additions

CMS-0057-F adds two categories to the mandatory data scope:

Concurrent coverage periods

A patient with overlapping coverage periods — for example, a dual-eligible patient with both Medicare Advantage and Medicaid — can request data exchange between simultaneously active plans. Each plan must respond to a valid data request from the other.

Concurrent coverage creates an important operational implication: payers can no longer assume “the requesting plan is always the new plan.” A payer may be the responding plan while the patient is still actively enrolled — the exchange is about sharing a copy of the record, not about a plan transition.

Prior authorization decisions

Prior authorization data must be included in the payer-to-payer exchange:

Active pending prior authorizations (the new plan needs to know what’s in flight)
Historical PA decisions (approved and denied)
Structured denial reasons — not free text, but coded reasons that are machine-readable

The structured denial reason requirement is specifically aimed at preventing continuity failures where a patient needs a service at their new plan and the new plan denies it without knowing the old plan already approved an identical request.

PDex IG (Da Vinci Payer Data Exchange)

The technical standard for CMS-0057-F payer-to-payer exchange is the Da Vinci PDex IG, built on the HREX base IG.

Overview and scope

PDex defines the data model and API patterns for payer-held data sharing — originally focused on payer-to-provider exchange, extended in subsequent versions to cover payer-to-payer. The same IG governs both the Provider Access API and payer-to-payer exchange because the data model and many of the technical patterns are identical.

Relationship to HREX

HREX (Health Record Exchange) is the foundational Da Vinci IG that PDex depends on. HREX defines:

The $member-match operation
Common Da Vinci profiles for shared data elements
The SMART Backend Services authorization pattern for system-to-system exchange

Think of HREX as the plumbing; PDex as the content-level specification built on top.

PDex profiles for Coverage, ExplanationOfBenefit, MedicationDispense

PDex defines specific profiles for the resources most commonly exchanged in payer-to-payer scenarios:

PDex resource	Base FHIR resource	What it represents
PDex Coverage	Coverage	The patient’s coverage record at the responding plan
PDex ExplanationOfBenefit	ExplanationOfBenefit	Adjudicated claims — four types (professional, institutional, pharmacy, oral)
PDex MedicationDispense	MedicationDispense	Medications filled — based on pharmacy claims
US Core profiles	Various	Clinical data (Condition, Observation, Procedure, etc.)

The ExplanationOfBenefit profiles are shared with CARIN Blue Button — payers implementing the Patient Access API under CMS-9115-F are likely already conformant with these profiles.

MedicationDispense vs MedicationRequest for payer data

Payers typically hold pharmacy claim data, which records what was dispensed — not what was prescribed. The correct FHIR resource for this is MedicationDispense, not MedicationRequest.

MedicationRequest represents an order/prescription. A payer seeing a pharmacy claim knows a medication was dispensed; it doesn’t always know the prescribing details (prescriber, dose instructions) unless those were included in the claim. Use MedicationDispense for pharmacy-claims-derived medication data and avoid over-populating MedicationRequest elements you don’t actually have.

The exchange workflow

Member-initiated trigger at enrollment

The CMS-0057-F payer-to-payer exchange is member-initiated — the patient triggers the request, typically at enrollment or through a member portal. The new plan should present the request option during the enrollment flow and make it accessible afterward through member-facing channels.

The patient provides their prior coverage information (plan name, member ID), which the new plan uses to construct the $member-match request. In practice, patients often don’t have their old member ID handy — the new plan must be able to work with demographics alone when the subscriber ID is unavailable.

Identifying the prior payer

The new plan needs to know the old plan’s FHIR endpoint to send the $member-match request. PDex does not mandate a universal payer directory, but the FHIR endpoint URL must be discoverable. Practical sources:

CMS’s established payer registry (for covered payers)
CARIN Alliance or similar industry registries
Bilateral registration between payers with frequent member transitions

Member match → data request → response

The complete exchange sequence:

New plan sends POST /Patient/$member-match to old plan’s endpoint
Old plan returns matched member identifier (or error)

New plan queries old plan’s FHIR server using the matched ID:

GET /ExplanationOfBenefit?patient=[matched-id]
GET /Condition?patient=[matched-id]
GET /MedicationDispense?patient=[matched-id]
GET /Claim?patient=[matched-id]&use=preauthorization

Old plan responds with FHIR resources; new plan ingests the data

The requesting plan’s access is scoped to the matched patient only. The authorization server enforces this — the bearer token issued after member match is scoped to the specific patient, not to the requesting organization broadly.

Bulk vs on-demand exchange options

On-demand: Individual queries per patient at the time of enrollment. Appropriate when patient-initiated requests arrive one at a time. Lower operational complexity but cannot pre-fetch population-level data.

Bulk: For plans processing high volumes of membership transitions (e.g., annual enrollment periods), bulk exchange using FHIR $export is more efficient. The requesting plan submits a Group-level export request for a cohort of newly enrolled members who have consented to data exchange.

PDex supports bulk export via FHIR Bulk Data Access IG patterns. The responding plan exports NDJSON for all members in the request Group; the requesting plan fetches and ingests the results asynchronously.

Bulk is more complex to operate but essential for plans that process thousands of new enrollments simultaneously during open enrollment periods.

Authentication and authorization

SMART Backend Services for payer-to-payer

Payer-to-payer exchange uses SMART Backend Services — OAuth2 client credentials with asymmetric key authentication. There is no patient-facing login step; the authorization is between the two plan systems.

The requesting plan registers with the responding plan’s authorization server before any exchange can happen. Registration involves:

The requesting plan provides its public key (JWKS endpoint or direct key)
The responding plan provisions an organization-level client (not patient-level)
The requesting plan signs JWT assertions with its private key to obtain access tokens

POST [auth-server]/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=[signed JWT]
&scope=system/Patient.$member-match system/ExplanationOfBenefit.read ...

OAuth2 scopes for P2P

SMART Backend Services scopes for payer-to-payer exchange follow the system/[ResourceType].[permission] pattern:

system/Patient.$member-match
system/ExplanationOfBenefit.read
system/Condition.read
system/MedicationDispense.read
system/Claim.read
system/Coverage.read

The responding plan’s authorization server enforces that tokens issued to a specific requesting plan are scoped only to resources the requesting plan is authorized to access for the matched patient.

CMS-0057-F frames payer-to-payer exchange as member-initiated: the patient requests the exchange. This is a consent model (the patient affirmatively requests their data be shared), not a universal access model.

Practical implications:

The new plan should document the patient’s consent/request in their member record
The responding plan should be able to verify that the data request is backed by member authorization — typically satisfied by the member match step (the requesting plan wouldn’t know the patient demographics and coverage unless the patient provided them)
Patients can opt out; the exchange should not proceed without patient authorization

Implementation considerations

Payer acting as client vs server

Both payers must implement both roles — every covered payer is simultaneously:

A client (new plan) that initiates member match and data requests
A server (old plan) that receives and responds to member match and data requests

This is architecturally distinct from the Provider Access API, where the payer is always the server and the provider is always the client. Build the P2P client capability as a first-class integration concern, not an afterthought — it’s as important as the server capability.

Data vintage and completeness

The responding plan should share data it actually holds — not attempt to reconstruct a complete record by soliciting data from other parties. CMS guidance is explicit: share what you have.

Practical tension: A patient may have switched from a plan that has only 18 months of history (e.g., a recently established Medicare Advantage plan). The requesting plan receives a legitimately incomplete record. Design the ingestion side to handle partial history gracefully — a record with two years of claims history is useful even if it doesn’t extend back 10 years.

Date scoping: Neither CMS-9115-F nor CMS-0057-F specifies a look-back period for the data that must be shared. In practice, payers share data from the member’s entire coverage period with that plan.

Handling member match failures gracefully

Match failure rates in production are often higher than expected, particularly for:

Members with recent name changes (marriage, divorce)
Pediatric members where the subscriber is a parent (demographics submitted may be the parent’s, not the child’s)
Non-standard name formats (hyphenated surnames, diacritics)
Demographic data entry errors at original enrollment

Design the requesting plan’s workflow to not dead-end on match failure. Options:

Manual verification path: Route to member services who can resolve discrepancies by phone
Enhanced demographics request: If the initial match fails, prompt the patient for additional identifiers (SSN, prior member ID)
Deferred retry: Queue the request and retry after the patient confirms their old plan enrollment details
Graceful absence: Treat no data as a valid state — the new plan proceeds without prior history

Common mistakes

Confusing $member-match with patient search: $member-match is an operation, not a search. Don’t substitute GET /Patient?name=...&birthdate=... — it’s not equivalent, it doesn’t enforce the privacy controls of member match, and the responding plan’s patient search may be restricted.

Not pre-expanding value sets in the terminology server: P2P exchange involves clinical data using SNOMED, LOINC, and RxNorm codes. Terminology validation at ingestion will time out or fail if the responding plan’s terminology server can’t expand these value sets quickly. Pre-expand and cache.

Returning data that isn’t yours to share: The responding plan must exclude data received under 42 CFR Part 2 (substance use disorder treatment) from P2P exchange unless the patient has specifically authorized that data’s disclosure. Build the exclusion logic before going live, not as a post-launch patch.

Over-scoping the access token: Issuing tokens with broad system-level read scope rather than scopes tightly bound to the matched patient creates a security surface. The token issued post-member-match should be scoped to that patient only.

Not testing with realistic demographic variation: Member match tests that use perfectly formatted, unambiguous demographics will pass. Production will not be perfectly formatted. Build your test suite with name variations, date format edge cases, and demographic mismatches. Measure your match rate against a realistic dataset before launch.

Payer-to-Payer Data Exchange

Payer-to-Payer Data Exchange

Regulatory history

CMS-9115-F (2020): the original mandate

CMS-0057-F (2024): expanded scope and concurrent coverage

Which payers are subject

Compliance timeline

The member match operation

Why member match is necessary

POST /Patient/$member-match

Input: MemberPatient and CoverageToMatch

Output: matched patient with NewCoverage reference

Match confidence and failure handling

What data must be shared

CMS-9115-F scope (prior payer only)

CMS-0057-F additions

Concurrent coverage periods

Prior authorization decisions

PDex IG (Da Vinci Payer Data Exchange)

Overview and scope

Relationship to HREX

PDex profiles for Coverage, ExplanationOfBenefit, MedicationDispense

MedicationDispense vs MedicationRequest for payer data

The exchange workflow

Member-initiated trigger at enrollment

Identifying the prior payer

Member match → data request → response

Bulk vs on-demand exchange options

Authentication and authorization

SMART Backend Services for payer-to-payer

OAuth2 scopes for P2P

Implementation considerations

Payer acting as client vs server

Data vintage and completeness

Handling member match failures gracefully

Common mistakes

Checklist

See also

Payer-to-Payer Data Exchange

Payer-to-Payer Data Exchange

Regulatory history

CMS-9115-F (2020): the original mandate

CMS-0057-F (2024): expanded scope and concurrent coverage

Which payers are subject

Compliance timeline

The member match operation

Why member match is necessary

POST /Patient/$member-match

Input: MemberPatient and CoverageToMatch

Output: matched patient with NewCoverage reference

Match confidence and failure handling

What data must be shared

CMS-9115-F scope (prior payer only)

CMS-0057-F additions

Concurrent coverage periods

Prior authorization decisions

PDex IG (Da Vinci Payer Data Exchange)

Overview and scope

Relationship to HREX

PDex profiles for Coverage, ExplanationOfBenefit, MedicationDispense

MedicationDispense vs MedicationRequest for payer data

The exchange workflow

Member-initiated trigger at enrollment

Identifying the prior payer

Member match → data request → response

Bulk vs on-demand exchange options

Authentication and authorization

SMART Backend Services for payer-to-payer

OAuth2 scopes for P2P

Member consent requirements

Implementation considerations

Payer acting as client vs server

Data vintage and completeness

Handling member match failures gracefully

Common mistakes

Checklist

See also