The Payer-to-Payer API Under CMS-0057-F

Core Requirements

The Payer-to-Payer API establishes a bidirectional data exchange obligation between impacted payers. When a patient enrolls with a new payer, the new payer must request data from the previous payer — with the patient's permission — and integrate that data into the patient's record.

Data Scope

The Payer-to-Payer API must exchange:

• Adjudicated claims and encounter data — excluding provider remittances and patient cost-sharing information
• All USCDI data classes and elements (45 CFR 170.213) — clinical data including labs, medications, conditions, procedures, and more
• Prior authorization information — active and historical PA decisions, enabling the new payer to honor or extend existing authorizations

Compliance Dates

• MA organizations & state Medicaid/CHIP FFS programs: January 1, 2027
• Medicaid managed care plans & CHIP managed care entities: Rating period beginning on or after January 1, 2027
• QHP issuers on the FFEs: Plan years beginning on or after January 1, 2027

Technical Architecture

System-to-System Exchange

Unlike the Patient Access API (which is consumer-facing), the Payer-to-Payer API operates as a backend service-to-service integration. CMS requires FHIR R4 as the base standard and strongly recommends the SMART Backend Services authorization profile for mutual authentication between payer systems.

Data Integration Obligation

Receiving payers are not just required to accept data — they must integrate the received information into the patient's record. This means incorporating claims history, clinical data, and PA information into the payer's core administrative and clinical data systems in a way that supports downstream care coordination, utilization management, and patient access via the Patient Access API.

Previous/Concurrent Payer Discovery

Payers must implement processes to gather information about a patient's previous and concurrent payers. CMS acknowledges this is operationally complex and allows payers flexibility in how they collect this information — whether through enrollment forms, patient attestation, or other mechanisms.

Member Consent

Payer-to-payer exchange is permission-based. Before the new payer requests data, the member must opt in, and payers must provide clear educational materials explaining what the exchange is for, what data moves, and how to decline. Consent must be tracked as a durable, auditable record — at the scale of every new enrollee with one or more prior payers. Treat consent state as a first-class data object that gates every retrieval, not a checkbox buried in enrollment.

Data Retrieval & FHIR-Based Exchange

The exchange is a FHIR R4, system-to-system integration authorized with the SMART Backend Services profile. The new payer discovers and calls the source payer's endpoint to pull up to five years of adjudicated claims and encounters (excluding remittances and cost-sharing), all USCDI clinical data, and prior authorization information. Because the payload spans a member's history, implementations typically use FHIR Bulk Data / $export-style patterns rather than single-resource reads. For how these resources map to existing payer data, see FHIR for CMS-0057-F.

Source Payer vs. New Payer Responsibilities

The exchange has two roles, and a given plan is constantly both — a source payer for departing members and a new payer for arriving ones.

Data Persistence, Reconciliation & Provenance

Receiving a payload is not the end of the obligation — the new payer must integrate it into the member's record so it flows downstream to care management, utilization management, and the member's own Patient Access API. Three concerns dominate:

• Persistence — store received clinical and claims data durably, versioned, and retrievable, not as a transient import.
• Reconciliation — de-duplicate and merge records that arrive with different coding practices and data models across source systems, without losing or double-counting history.
• Provenance — retain FHIR Provenance so every element carries its origin. This matters for clinical trust, auditability, and avoiding "telephone-game" degradation as data passes between multiple payers over time.

Identity Matching

Before any exchange, both payers must be confident they are talking about the same person. There is no national patient identifier, so payers rely on demographic matching (name, date of birth, address, and plan identifiers). Weak matching risks either missing a member's history or, worse, commingling two members' records. Plan for a deliberate identity-matching strategy with tunable thresholds and a fallback for low-confidence matches — this is one of the highest-risk parts of the workflow.

Security

Enforce TLS, mutual authentication between payer systems via SMART Backend Services (asymmetric keys with rotation and revocation), least-privilege scopes, and full audit logging of every request and release. Because consent gates access, the consent check and the authorization check must be evaluated together before data leaves the source payer.

Implementation Architecture

A durable design puts an interoperability layer between the FHIR exchange endpoint and your core systems — handling discovery, consent, mapping, reconciliation, and provenance — rather than wiring peer payers directly into a core administration database.

Operational Monitoring

Instrument the exchange end to end: request and retrieval success rates by trading partner, identity-match confidence distributions, reconciliation conflicts, consent state changes, payload volumes, and the quarterly concurrent-exchange cadence for dual-eligible and multi-plan members. These signals catch silent failures — a partner endpoint quietly returning empty bundles, or a match-rate drop after a demographic-data change — before they become care-continuity gaps.

Operational Challenges

The Payer-to-Payer API introduces several unique operational challenges that differentiate it from the other mandated APIs:

• Payer identity resolution — determining which FHIR endpoint belongs to the patient's previous payer
• Data reconciliation — merging claims and clinical data from different systems with different coding practices and data models
• Consent management at scale — tracking opt-in status across potentially millions of members with multiple prior payers
• Concurrent exchange cadence — establishing quarterly batch processes for dual-eligible and multi-plan populations

Build vs. Buy for Payer-to-Payer Data Exchange

Payers generally reach these capabilities by one of three routes. This is an educational framing, not a recommendation — the right path depends on your existing systems and modernization roadmap.

1. Build interoperability capabilities internally. Maximum control over discovery, consent, matching, and reconciliation; also the highest engineering and ongoing conformance cost as specifications evolve.
2. Add an interoperability layer in front of an existing core system. An overlay provides the FHIR exchange, identity matching, reconciliation, and provenance while your core administration platform (QNXT, Facets, HealthEdge, or custom) stays in place.
3. Use a broader modern payer platform. Where a plan is modernizing, a modern backend can provide these capabilities natively rather than as an overlay.

These approaches are not mutually exclusive. A modern payer platform such as CloudHealthOffice can serve as either an interoperability layer integrated with an existing core administration system or, depending on the implementation model, as part of the core backend itself. The CMS-0057-F with QNXT guide walks through the overlay pattern in detail.