CMS Interoperability: Seamless Continuity of Care for New Members Through Payer-to-Payer Exchange

Introduction

The Payer-to-Payer Data Access API enables seamless health information exchange between current and previous/concurrent health plans when a member transitions coverage. Mandated under CMS Rule CMF 0057-F, impacted payers must implement and maintain a FHIR-based API that supports secure transmission of claims, encounter data, USCDI elements, and prior authorization information (excluding provider remittances and patient cost-sharing details).

In this blog, we focus on automating the entire payer-to-payer data exchange process between the previous payer (KindCover Health Insurance) and the current payer (UnitedCare Health Insurance). We demonstrate how Bulk Data Export can be leveraged to import a patient’s claims history. Additionally, we walk through each phase of the workflow alongside our reference implementation, developed using Ballerina.

Scenario

John Smith, a 42-year-old patient with chronic hypertension and diabetes, recently switched his health insurance plan from KindCover Health Insurance (previous payer) to UnitedCare Health Plan (current payer). To ensure continuity of care, avoid duplicative testing, and understand his treatment history, UnitedCare Health initiates a payer-to-payer data request to retrieve his prior health data from KindCover Health.

Patient/ Member: John Smith
Current Payer/ Requesting Payer: UnitedCare Health Insurance
Previous Payer: KindCover Health Insurance

Workflow

Figure 1: Sequence diagram of the payer-to-payer data exchange workflow

Assumptions

• John Smith is an active member of the UnitedCare Health Plan.
• UnitedCare has sufficient demographic data for matching.
• KindCover Health supports the Bulk Data Access API and follows the PDex Implementation Guide.

1. Enrollment and Information Collection

• John Smith enrolls in the UnitedCare Health Plan (current payer).
• As part of the enrollment process, John provides his demographic details along with his previous coverage ID from KindCover Health Insurance (previous payer).
• This information is collected by UnitedCare Health to initiate the data retrieval process and it can be included in the Member Portal.

2. Member Resolution

• UnitedCare Health’s Bulk Data Export Client uses John’s demographic and coverage information to perform a Member Match operation by sending a request to KindCover Health’s FHIR Server.
• The FHIR Server processes the request and, if a match is found, returns a member ID.
• This member ID uniquely identifies John within KindCover Health’s system, enabling accurate linkage for future data retrieval.

3. Data Request and Export Preparation

• Using the obtained member ID, UnitedCare Health initiates a bulk data export by triggering a request to KindCover Health’s FHIR Server (/Patient/$export endpoint).
• The export request is asynchronous, allowing time for the server to process and compile the data.
• The FHIR Server aggregates John’s historical health data (e.g., Encounters, Coverage) and formats it in NDJSON for large-scale transfer.
• Once the data is ready, the FHIR Server stores the NDJSON files (Encounter.ndjson, Coverage.ndjson, etc.) on a secure Output File Server.
• These files represent John’s past clinical and coverage history.
• The FHIR Server returns a status URL, which UnitedCare Health polls to monitor export progress.

4. Data Export and Integration 

• Once the export is complete, KindCover Health’s FHIR Server returns a URL pointing to the Output File Server where the NDJSON files are available for download.
• UnitedCare Health’s Bulk Data Export Client initiates the download of the NDJSON files.
• After a successful download, UnitedCare Health ingests the data into its internal systems.
• The data is integrated into UnitedCare Health’s systems of record, such as FHIR Server, Claims management systems, Clinical and health databases.
• This integration ensures continuity of care, allowing providers to access John’s medical history without requiring duplicate tests or re-submission of prior records.
• It enables a seamless and compliant transition between payers under the CMS-0057-F mandate.

Reference Implementation

Figure 2: Architecture diagram of the reference implementation

The reference implementation architecture focuses on two key stakeholders: 

Current Payer: The patient logs into the Member Portal provided by the current payer, UnitedCare Health. The portal displays a list of previous payers that UnitedCare has integrated with. The patient selects their previous payer (KindCover Health) and provides the necessary information, such as their previous coverage ID.

This information is passed to UnitedCare Health’s Bulk Data Export Client, which performs a Member Match operation by sending a request to the FHIR Server of KindCover Health to verify the patient’s identity. If a successful match is found, the FHIR Server returns a member ID uniquely identifying the patient within KindCover’s system.

With the obtained member ID, the Bulk Data Export Client then initiates a bulk data $export request to KindCover Health’s FHIR Server. The request is asynchronous, and the client receives a status URL, which it uses to poll for export job completion. Once the export is complete, the client receives a download URL pointing to the Output File Server, from which it retrieves the patient’s historical health data in NDJSON format.

Previous Payer: Upon receiving a bulk data $export request at its FHIR Server, the previous payer, KindCover Health, begins processing the request asynchronously. The FHIR Server integrates with existing systems of record, including databases, FHIR repositories, claims management systems, and billing platforms, and serves as a facade layer to expose internal data in a standardized FHIR format to external clients.

The FHIR Server compiles the requested historical data (e.g., Encounters, Coverage) and prepares it in NDJSON format for structured transfer. A status URL is returned to the current payer, which it polls to check the progress of the export job.

Only after the export is complete, the FHIR Server responds with a download URL pointing to the Output File Server, where the NDJSON files are hosted. These files are then accessed and downloaded by the current payer for ingestion into its internal systems.

Core Components

The core components required for the above scenario are outlined below.

Payers should implement these components as appropriate to support the Payer-to-Payer data exchange workflow in compliance with CMS-0057-F.

Current Payer

Previous Payer

A complete reference implementation for the Payer-to-Payer Data Exchange scenario has been built using the WSO2 Accelerator for Healthcare. This implementation demonstrates key components such as the member match process, bulk data export using FHIR, and secure retrieval of historical patient data between payers. It is publicly available via GitHub and includes a hosted demo setup, where users can experience the full end-to-end workflow, including a member portal frontend application for patient-driven data sharing.

The video below will provide a walkthrough of the demo setup. 

Glossary

Request a Demo Request a Demo