CMS-0057 Payer-to-Payer Data Exchange: Why API Compliance Is Not Enough

The CMS-0057 Payer-to-Payer Data Exchange API deadline is January 1, 2027. Technically speaking, most health plans affected by the rule are on track to comply with it. 

But here’s what nobody is saying loudly enough: having a compliant Payer-to-Payer Data Exchange API and actually exchanging member data are two completely different outcomes. The regulation only guarantees the first.

CMS-0057 Payer-to-Payer Data Exchange Requirements: What’s Missing

CMS-0057 was designed to solve a real patient problem: when a member changes health plans, their clinical history shouldn’t disappear. The intent is clear, and the patient benefit is real.

What the regulation didn’t do is build the infrastructure to make that exchange actually happen at scale. 

• There’s no shared directory of where each payer’s API lives. 
• There’s no requirement to build connections in advance, only to respond when requests arrive. 
• There’s no data quality standard, meaning a payer sending malformed or incomplete FHIR resources is technically compliant. 
• And there’s no common testing environment, so every connection has to be arranged independently.

The result is thousands of health plans building to the same specification with no shared mechanism to find each other, no neutral quality layer, and no guarantee that a compliant endpoint translates into a functioning exchange. The gaps aren’t edge cases. They’re foundational, and they fall entirely on whoever doesn’t have a plan for them.

CMS-0057 vs. CMS-9115: Payer-to-Payer Data Exchange Compared to Patient Access APIs

Patient Access APIs under CMS-9115 have been live for years with minimal utilization. The reason is simple: adoption depended entirely on individual members independently connecting their data to third-party apps. Plans could build the endpoint. They couldn’t manufacture consumer behavior.

CMS-0057 Payer-to-Payer Data Exchange is categorically different. The other end of a connection isn’t a consumer making a personal decision. It’s an organization required by regulation to exchange member data when a member opts in. That changes everything.

Plans have direct agency over member opt-in, something they never had with Patient Access. Opt-in can be embedded directly into enrollment workflows, presented at the moment of highest member engagement. How and when a plan asks for consent — and how clearly it explains the benefit — directly determines how much prior coverage data the plan actually receives. Member consent isn’t a marketing function. For Payer-to-Payer Data Exchange, it’s an operational one.

What Payer-to-Payer Data Is Actually Worth and What It Costs When It Doesn’t Arrive

For Medicare Advantage plans, risk adjustment accuracy depends directly on the completeness of member data at enrollment. When prior chronic condition histories arrive on day one, HCC codes are captured before the first risk score runs. When they don’t, member complexity is understated, and for a large plan processing tens of thousands of transitions annually, that gap is not a rounding error. It accumulates.

The same pattern plays out across HEDIS performance, Star Ratings, and care management effectiveness. In each case, the plan that receives complete member histories at enrollment builds on a solid foundation. The plan that doesn’t starts every enrollment cycle reconstructing what should have been available from the start.

The gap between those two outcomes isn’t a technical question. It’s a network question, and it’s one that a compliant FHIR endpoint alone doesn’t answer.

Building the endpoint gets a health plan to the starting line. What comes after — connecting to other payers, maintaining those connections, ensuring incoming data is actually usable — is an ongoing operational challenge that most API builds don’t address. Most vendor solutions are thinner here than they appear. The questions that expose the gap aren’t about features. They’re about who owns the ongoing work, and most vendors don’t have a good answer.

CMS-0057 Readiness: The Early Mover Advantage in Payer-to-Payer Data Exchange

Here’s what makes this moment strategically significant: the advantage doesn’t accrue gradually. It compounds.

A plan that connects now and drives strong member opt-in during the 2026 open enrollment period enters 2027 with a richer longitudinal member record than a plan that waits. Two or three enrollment cycles with complete member transition data means more accurate risk adjustment revenue, stronger HEDIS performance, and better member retention. None of those advantages reset when a late adopter finally connects.

The plans that treat CMS-0057 Payer-to-Payer Data Exchange as a strategic investment, not a compliance line item, will look back on this period as the moment interoperability stopped being a cost and started being a competitive advantage. The plans that treat it as a deadline to clear will spend the years that follow catching up.

What to Do Before the CMS-0057 Deadline

We put everything we know about closing that gap into a new playbook — covering the specific questions every health plan should be asking their vendor or internal team right now, a framework for evaluating whether your current solution actually closes the network gap, and a real-world look at how one large national payer solved it.

If you’re serious about Payer-to-Payer Data Exchange, it’s worth reading before you assume you’re covered. Read the Full Playbook: The Payer-to-Payer Gap