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.
📅 One-Week Trigger
The new payer must request data from the previous payer no later than one week from the start of coverage, or at the patient's request — whichever comes first.
🗂️ Five-Year Lookback
Payers exchange up to five years of patient data. CMS modified this from the proposed rule (which would have required the entire record), determining five years is sufficient for care continuity.
🔄 Quarterly Concurrent Exchange
If a patient has two or more concurrent payers, those payers must exchange the patient's data at least quarterly to maintain a complete record across all plans.
✅ Patient Opt-In
Data exchange requires patient permission. Payers must implement opt-in processes and disseminate educational resources explaining the purpose of the exchange.
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.
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