Payer-to-Payer Data Exchange: Full Guide for 2026

Payer-to-payer data exchange became a regulatory priority as more individuals began moving between health plans.

In these transitions, important clinical and administrative data often stayed siloed with the former payer, leaving new plans with limited visibility into a member’s care history.

CMS introduced payer-to-payer data exchange requirements under its broader push for payer interoperability to address this. The goal is to ensure that when members switch plans, their data can follow.

For payer organizations, this is both a compliance mandate and a practical solution to long-standing challenges with fragmented member information. With a CMS deadline of January 1, 2027, impacted payers must act right now. This article covers everything you need to know about payer-to-payer data exchange coverage, from the legislative process to practical implementation steps.

What is payer-to-payer data exchange, and why does it matter

Payer-to-payer Data Exchange is transferring clinical health data from one health insurance payer to another when a patient changes their insurance plan. It involves sharing information such as diagnoses, treatments, allergies, immunizations, and lab results with the new insurer.

Payer-to-payer data exchange matters as it:

• Ensures uninterrupted patient care. The new payer has access to a complete medical history so that tests and procedures are not repeated unnecessarily.
• It provides patient access to their health information regardless.
• It complies with CMS rules, as it is mandated by the Centers for Medicare & Medicaid Services (CMS) as part of interoperability and information access regulations. Payers must implement it to stay compliant.

Where payer-to-payer data exchange fits within CMS rules

​From the legal standpoint, the payer-to-payer Data Exchange is a part of the CMS Interoperability and Patient Access Final Rule (CMS-9115-F), not to be confused with the CMS interoperability and Prior Authorization Final Rule (CMS-0057-F). This requirement mandates that certain health insurers, referred to as "impacted payers," facilitate the electronic exchange of a patient's clinical data when the patient transitions between health plans.

In May 2020, CMS finalized the Interoperability and Patient Access Rule (CMS-9115-F), which included the CMS payer-to-payer data exchange requirement. This rule mandated that impacted payers implement a process for data exchange beginning January 1, 2022. ​

However, in December 2021, CMS paused enforcement of the payer-to-payer provision. The decision was based on industry feedback and unresolved challenges (identity matching, patient consent, technical readiness). The decision was paused until implementation challenges can be addressed in full capacity.

In January 2024, CMS released the Interoperability and Prior Authorization Final Rule (CMS-0057-F), which reintroduced the payer-to-payer exchange requirement with updated deadlines and clearer technical expectations.

The new enforcement date for payer-to-payer API implementation is January 1, 2027.

Key requirements and current deadlines (as of 2026)

As of 2026, payer-to-payer Data Exchange is a required process under CMS rules. The goal is to ensure members' clinical and administrative data follow them across health plans. Below are key legal and technical requirements, along with the deadline for the ones that have it:

Member consent collection

Impacted payers must obtain explicit opt-in consent from members before requesting data from their previous or concurrent health plan.

• Consent must be collected within one week of the coverage start date.
• Members must receive plain-language materials explaining the process and the right to opt out at any time.
• No automatic or implied consent is permitted.

During the enrollment process, payers must also collect:

• Consent authorization
• Prior health plan information (e.g., from a prior coverage card)ю
• This allows the requesting payer to initiate proper member-matching operations later.

Consent may be initiated through a member portal, mobile app, or customer service call and should be reinforced with follow-ups post-enrollment.

Structured data transfer (USCDI)

Payers must exchange the following data, covering at least five years of member history:

• Clinical data conforming to USCDI v1
• Adjudicated claims and encounter data
• Cost-sharing information
• Prior authorization information, excluding denied or pharmacy-specific requests

Payer scope and responsibilities

The rule applies to:

• Medicare Advantage (MA) plans (e.g., UnitedHealthcare, Humana)
• Medicaid-managed care organizations (e.g., Molina Healthcare, Centene)
• CHIP-managed care entities (e.g., Texas Children's Health Plan)
• Qualified Health Plans (QHPs) on the Federally Facilitated Exchanges (FFEs) (e.g., Ambetter)

Responsibilities include:

• Data exchange at the start of coverage
• Quarterly exchanges for concurrent payers
• Accurate member matching using prior plan info
• Secure OAuth 2.0-based registration and payer data exchange API access setup

API implementation and integration

Payers must implement a payer-to-payer API capable of:

• Identifying and authenticating previous or concurrent payers
• Requesting, receiving, and ingesting structured health data
• Performing secure OAuth 2.0 dynamic client registration
• Managing mTLS (mutual TLS) endpoint discovery and authentication

Key workflow components:

The following five steps represent the real-world sequence through which the payer-to-payer API executes its core responsibilities:

• Step 1: Consent + Coverage info

Member consent + prior plan details are collected at enrollment.

• Step 2: Mutual authentication

Each payer must generate an mTLS endpoint bundle, signed by a Certificate Authority and optionally published to TEFCA or a National Endpoint Directory.

• Step 3: OAuth 2.0 registration

The requesting payer submits a signed JWT to the prior payer and receives Client ID credentials

• Step 4: Member matching request

Matching is done using demographics, coverage info, and consent.

Uses profiles like:

• HRex Patient Demographics
• HRex Coverage Profile
• PDex Consent Profile
• Step 5: Data exchange

Once matched the prior payer shares an FHIR ID for claims, encounters, cost-sharing, and prior authorization data.

Member authentication

Because data can be requested up to five years post-discharge, payers must support identity verification for former members:

• IdP login using portal credentials
• Zero-knowledge authentication using name, DOB, ZIP code, and member ID

Authentication must also support OAuth 2.0 workflows and mutual trust certificates (mTLS).

Frameworks: HL7 FHIR payer API

All APIs must comply with the following:

• HL7® FHIR® Release 4.0.1
• US Core Implementation Guide (STU 3.1.1)
• Da Vinci PDex Implementation Guide (STU 1.0.0)
• HRex and PDex Consent Profiles for matching and consent validation

FHIR R4 is strongly preferred due to prior investment in the Patient Access API, which uses the same data structure.

Current deadlines and status

• January 1, 2026
• Begin annual Patient Access API reporting.
• January 1, 2027
• Full compliance with all payer-to-payer API requirements:
• Consent workflows
• Identity and endpoint authentication
• Member matching
• Secure data exchange

Technical challenges: Consent, identity, and integration

Implementing payer data introduces several technical and operational challenges for impacted payers. These challenges extend beyond API setup and touch on consent workflows, identity matching, and system integration:

Consent management

Payers must collect explicit, member-initiated consent within one week of the coverage start date and allow members to opt out at any time.

Key challenges include:

• Ensuring consent is traceable, revocable, and compliant with PDex Consent Profiles
• Capturing consent consistently across portals, apps, and call centers while maintaining audibility
• Supporting real-time consent validation during API calls
• Collecting prior plan details (e.g., ID cards or coverage data) during enrollment to facilitate future member matching

Identity matching

Because there is no national patient identifier in the U.S., payers must rely on demographic matching to identify former members in other systems.

Challenges include:

• Matching based on name, date of birth, address, and prior coverage information
• Handling inconsistent or incomplete records across payers, which can lead to missed or incorrect matches
• Aligning matching logic with HRex Patient Demographics and HRex Coverage Profiles
• Dealing with former members who have never registered digitally and have no existing credentials (making identity resolution more complex)

Integration into existing systems

Even when consent and identity matching are successful, payers must be able to ingest and use the data from other health plans.

Challenges include:

• Normalizing and validating FHIR data for use in claims, care management, or data warehouse environments
• Integrating with systems that may not support modern API frameworks
• Implementing mutual TLS (mTLS) endpoint discovery and OAuth 2.0 dynamic registration
• Managing scalability as member volume increases, especially in bulk data exchange scenarios

In many organizations, these technical requirements involve coordination across compliance, IT, architecture, and development teams, creating both operational complexity and opportunities for modernization.

How a tech partner helps simplify payer-to-payer compliance

Given the complexity of CMS payer-to-payer requirements, a specialized technology partner in healthcare software development can significantly reduce implementation time and risk. Binariks delivers end-to-end payer interoperability solutions—from secure API development to modular integration. Here is what we can do:

API implementation and security

• Design and deploy FHIR-compliant APIs (HL7 R4, US Core IG, Da Vinci PDex IG)
• Ensure alignment of health plan payer API integration with CMS specifications and best practices
• Set up secure authentication, mTLS, and OAuth 2.0 protocols

Modular architecture

• Build plug-and-play modules for consent collection and member matching
• Integrate with existing systems without complete overhauls

Seamless system integration

• Complete FHIR integration: Connect incoming FHIR data to your care management systems
• Automate data reconciliation to support continuity of care

Advanced identity matching

• Apply robust matching algorithms to reduce false matches
• Standardize demographic data to improve accuracy and member identification

Ongoing support and compliance

• Maintain and update APIs as standards and CMS rules evolve
• Monitor system performance and assist with CMS reporting

Key steps to prepare your organization for payer-to-payer

Here are the key payer-to-payer integration steps a vendor should know about:

Step 1: Assess existing infrastructure

Begin by evaluating your current systems.

• Can your architecture support FHIR-based APIs?
• Do you already have reusable components from the Patient Access API?
• Are your consent, authentication, and identity systems integrated or siloed?
• Review your API gateway, data flows, member records, and internal integrations.
• Identify gaps in payer-to-payer exchange interoperability, security, and consent tracking that could block payer-to-payer implementation.

This foundational step helps you scope the level of investment needed and whether to build or partner.

Step 2: Analyze data accessibility

Once infrastructure is assessed, ensure your data is accessible and structured for exchange.

• Can your systems extract and structure USCDI v1 data?
• Is clinical, claims, encounter, and prior authorization data available for the past five years?
• Are legacy records complete and standardized?
• Audit your databases and storage systems to confirm they can support real-time data queries.
• Identify any gaps in completeness or consistency that could disrupt compliance or downstream matching.

Step 3: Build or integrate FHIR gateways

With infrastructure and data readiness confirmed, begin implementing your payer-to-payer interoperability layer.

• Have you adopted HL7 FHIR R4, US Core IG, and Da Vinci PDex IG?
• Can your system support mutual TLS (mTLS) for endpoint authentication?
• Are you prepared for OAuth 2.0 dynamic registration and secure client credentialing?
• Configure endpoints, FHIR profiles, and data payloads in line with CMS specifications.
• Decide whether to build internally or integrate a third-party solution to accelerate delivery.

Step 4: Implement consent mechanisms

Now that your systems are able to access data, make sure to enable this functionality.

• Do you capture explicit opt-in consent during enrollment or within one week of coverage start?
• Can members revoke consent at any time via the portal, app, or phone?
• Are you using PDex Consent Profiles to structure consent in FHIR format?
• Do you collect prior health plan details (e.g., plan ID from insurance cards) to support matching?
• Establish consent-tracking workflows with full auditability and standardization.
• Train staff and configure portals to support both digital and offline consent collection.

Step 5: Pilot integration with a partner payer

Validate real-world functionality before scaling across all payer connections.

• Have you tested consent validation, mTLS handshakes, OAuth registration, and member matching?
• Can your systems handle incoming FHIR data—retrieve, ingest, and apply it correctly?
• Are you using HRex Patient Demographics, Coverage, and PDex Consent profiles during matching?
• Run a complete exchange scenario with a known partner to surface technical and operational issues early.
• Use lessons from the pilot to refine your implementation and finalize documentation.

A successful pilot proves your systems are ready for production.

Final thoughts

While the CMS payer-to-payer data exchange requirement is complex, it's also an excellent vendor opportunity. It is not just about compliance: it opens the door to better member experiences, more transparent healthcare data sharing , and long-overdue modernization of payer IT systems in every aspect.

If you're looking to assess your organization's readiness or seeking an implementation partner for a scalable, standards-aligned solution, Binariks offers the technical expertise and industry insight to support your journey. Contact us today to explore how we can help you turn compliance into a competitive advantage.