Payer-to-Payer Data Exchange is the most technically complex of the four CMS-0057-F APIs and the one with the fewest production deployments going into 2026. The flow looks straightforward in the IG: when a member switches health plans, the receiving payer requests a five-year history from the prior payer, the member opts in, the data transfers as FHIR Bundles, and the receiving payer ingests it. In practice, every step has operational depth that surfaces during real deployment. This guide lays out what Payer-to-Payer actually requires for the 5-year history reference on this site.
What the IG Actually Requires
CMS-0057-F requires that when a member enrolls in a new health plan, the new plan must request the member's five-year clinical and claims history from the prior plan if the member opts in. The transfer happens within one business day of the formal request. The data set excludes denied PAs and cost-sharing detail. Concurrent coverage adds quarterly sharing rules. The member must be educated about the option during enrollment.
The transport layer uses FHIR Bulk Data Access for the export, FHIR Member Match for identity confirmation, and FHIR Consent for the opt-in record. The conformance bar is set by HL7 PDex IG, CARIN BB IG, and FHIR Bulk Data Access IG together.
The Member Match Problem at the Center
Member Match is the gate that determines whether the transfer happens at all. The receiving payer sends a Patient and Coverage Bundle representing the member, and the prior payer's Member Match implementation has to confirm identity. A miss returns no data. A false positive returns another patient's history, which is a privacy incident.
The honest assessment is that Member Match accuracy varies widely across vendors. Most implementations support both deterministic matching (exact identifiers, name, DOB) and probabilistic matching with confidence scoring. The threshold for what counts as a match is configurable, and the tuning has operational consequences.
For deeper coverage of matching strategies, the Top 5 Member Match strategies for Payer-to-Payer lays out the options.
The Five-Year History That Most Plans Cannot Produce Cleanly
The five-year history requirement assumes the prior payer has the data, in FHIR-compatible form, retrievable for a single member, exportable as a clean FHIR Bundle. Most US health plans have the data, but not all of those conditions. Claims data may live in X12, not FHIR. Clinical data may live in claims-attached documents that have not been parsed into FHIR resources. Five years of history may span multiple internal systems that the payer has not unified.
Plans that can produce the five-year history cleanly are the exception in 2026. Plans that cannot have to choose between producing partial history (and risking CMS audit) or investing in data integration before the transfer flow is operational.
For practical patterns that work in production, the Best practices for 5-year history transfer covers the deployments that have shipped.
The Member Opt-In Flow That Sits in the Member Portal
CMS-0057-F requires the receiving payer to capture member opt-in for the transfer. The opt-in flow typically lives in the member portal during enrollment, with educational materials explaining what data will transfer and what the member is consenting to. Payers that treat this as a checkbox tend to have low opt-in rates and weak audit trails. Payers that treat it as a designed flow have higher opt-in rates and cleaner audit positions.
The educational materials require coordination across the payer's legal, marketing, and member-experience teams. Most plans underestimate this work during vendor selection.
The Transport Question: Direct API or TEFCA
Two transport models are emerging in 2026. The direct API model has receiving and prior payers running paired FHIR endpoints with point-to-point authentication. The TEFCA model uses a Qualified Health Information Network (QHIN) as the intermediary, with each payer connecting to TEFCA rather than to each other directly.
The direct API model gives payers more control. The TEFCA model reduces per-payer engagement work substantially.
For the deeper comparison, the TEFCA vs Direct API for Payer-to-Payer transfer covers which fits where. Most large-scale 2026 deployments are choosing a hybrid: TEFCA for the network discovery and authentication, direct API for the actual data transfer.