Skip to main content
Call
Complianceaka P2P API, Payer Data Exchange API, Payer-to-Payer Data Exchange

What is Payer-to-Payer API? Definition, Formula, and Benchmark

Reviewed by QuickIntell RCM Editorial Team · Last reviewed

Updated

Definition

The Payer-to-Payer API is a CMS-mandated FHIR API enabling members who switch plans to request that their clinical and claims data be transferred from their old plan to their new one. Established by CMS-9115-F and expanded by CMS-0057-F with compliance dates rolling forward through 2026–2027.

Overview

The Payer-to-Payer API is a CMS-mandated FHIR R4 API that enables members switching health plans to direct their former plan to transfer clinical and claims data to their new plan. The original CMS-9115-F Final Rule established payer-to-payer exchange in concept; the CMS-0057-F Prior Authorization Final Rule (2024) substantially expanded the scope, technical requirements, and compliance dates. Final implementation dates roll forward through 2026 for clinical data and 2027 for broader claims data exchange.

Covered plans include Medicare Advantage, Medicaid managed care, CHIP managed care, and Qualified Health Plans on the federally-facilitated exchange. The exchange mechanism allows a new plan to request — on member authorization — that the former plan transfer the member's data directly via FHIR API, avoiding the need for the member to manually compile records or authorize separate retrievals.

Data scope includes clinical data (USCDI elements — problems, medications, allergies, labs, immunizations, procedures), claims and encounter data (typically five years), and prior-authorization data (active PAs and PA decision history — a CMS-0057-F addition). Clinical data flows via US Core FHIR profiles; prior-authorization data flows via Da Vinci Prior Authorization Support (PAS) profiles.

The member-authorization workflow is a critical design element. CMS-0057-F requires plans to enable member-driven data transfer requests through the Patient Access API; once requested, the source plan has specified timeframes to respond (varying by data type and rule component). Members need not compile records themselves — the plans coordinate the transfer.

Operational implementation is non-trivial. Plans must maintain FHIR-accessible clinical data (typically requiring integration between claims systems, utilization-management systems, and provider-sourced clinical data), implement secure plan-to-plan FHIR connections, handle authorization workflows, and report compliance metrics. Most plans are partnering with vendor infrastructure providers rather than building entirely in-house.

Use cases extend beyond the pure member-switch scenario. Payer-to-payer exchange supports care-continuity when members transition between Medicaid and Medicare, annual open-enrollment plan changes, employer-initiated plan changes, and regional-migration plan changes. Starting data capital exists from the start of the new plan year rather than building up over months of encounter data accumulation.

CMS-0057-F also introduced provider-to-payer API requirements where payers expose their data (especially prior-authorization data) to providers. The combined effect is a more transparent, FHIR-based payer ecosystem where data flows where it is needed with proper authorization.

Payer-to-Payer API is one of the compliance areas where documentation discipline determines audit outcomes more than policy sophistication. Practices that invest in clean Payer-to-Payer API records, consistent patient access api workflows, and auditable fhir api evidence come out of OIG, RAC, and MAC audits with materially smaller recoupment exposure than practices with equivalent policies but weaker paper trails.

Industry benchmark

CMS-9115-F original compliance: January 2022. CMS-0057-F expanded compliance: Clinical data January 2026, prior-authorization data January 2026, claims data January 2027 (dates subject to rule modifications).

Worked example

A member switches from Medicare Advantage Plan A to Medicare Advantage Plan B at annual open enrollment. The member authorizes data transfer during Plan B's onboarding workflow. Plan B requests the member's clinical, claims, and active-PA data from Plan A via the Payer-to-Payer API. Plan A transfers the data within required timeframes, enabling Plan B to begin care management with full context rather than starting from scratch.

Frequently asked questions — Payer-to-Payer API

Which plans must support the API?

Medicare Advantage, Medicaid managed care, CHIP managed care, and Qualified Health Plans on the federally-facilitated ACA marketplace. Commercial self-insured plans are not directly covered.

Does the member need to authorize every transfer?

Yes — member authorization is required. The new plan typically facilitates the authorization workflow during onboarding rather than requiring the member to navigate independently.

What happens to prior authorization data under CMS-0057-F?

Active PAs and PA decision history are transferred so the new plan can honor the existing authorizations. This addresses a longstanding pain point where members had to redo PAs when switching plans even for ongoing therapy.

Disclaimer

This glossary entry is operational reference for revenue-cycle and medical-billing professionals. It is not legal, clinical, or contractual advice. Industry benchmarks cite named public sources where available; always verify against the current guidance from the authority body before relying on a number in a contract, policy, or compliance filing.