The deadline for implementing the API for payer-to-payer data exchange under CMS-0057 is January 1, 2027. From a technical standpoint, most health plans affected by the rule are on schedule and will meet the deadline.
But here is what no one is saying out loud: having a compliant API for data exchange and actually performing that exchange are two completely different things. Regulation only guarantees the former.
CMS-0057 Payer-to-Payer Exchange Requirements: What Is Missing
The CMS-0057 standard was developed to solve a real patient problem: when a member changes health plans, their clinical history should not disappear. The intent is clear, and the benefit to the patient is real.
What the regulation did not do is create the infrastructure that would allow this exchange to take place at scale.
- There is no common directory that lists the location of each payer's API.
- There is no requirement to establish connections in advance; there is only an obligation to respond when requests are received.
- There is no data quality standard, which means a payer sending incorrect or incomplete FHIR resources is technically compliant.
- There is no common testing environment, so every connection must be organized independently.
As a result, thousands of health plans are building solutions to the same specification without a common mechanism to find each other, a neutral quality control layer, or guarantees that a compliant endpoint will turn into a functioning exchange. These gaps are not edge cases. They are fundamental, and the entire burden falls on those who have no plan to address them.
Comparing CMS-0057 and CMS-9115: Payer-to-Payer Exchange vs. Patient Access APIs
Patient Access APIs under CMS-9115 have been running for years with minimal usage. The reason is simple: adoption depended entirely on whether individual members would independently connect their data to third-party applications. Plans could build an endpoint, but they could not control consumer behavior.
Payer-to-Payer exchange under CMS-0057 is fundamentally different. On the other end of the connection is not a consumer making a personal decision. It is an organization that is legally required to exchange member data when the member provides consent. This changes everything.
Plans have direct influence over member consent—an opportunity they never had under the Patient Access program. Consent can be embedded directly into enrollment workflows, requesting it at the moment of the member's highest engagement. How and when a plan requests consent—and how clearly it explains the benefit—directly determines how much prior coverage data the plan will ultimately receive. Member consent is not a marketing function. For payer-to-payer exchange, it is an operational task.
What Is the Real Value of Payer-to-Payer Data and What Does Its Absence Cost?
For Medicare Advantage plans, the accuracy of risk adjustment depends directly on the completeness of member data at enrollment. When a history of chronic conditions arrives on day one, HCC codes are captured before the first risk score is calculated. If this does not happen, the complexity of the member's condition is misestimated, and for a large plan processing tens of thousands of transitions annually, this gap is not a rounding error. It accumulates.
The same trend appears in HEDIS scores, Star Ratings, and medical management efficiency. In each case, a plan that receives a full member history at enrollment relies on a solid foundation. A plan that does not receive it begins each enrollment cycle by reconstructing what should have been available from the very beginning.
The gap between these two outcomes is not a technical issue. It is a networking issue, and a compliant FHIR endpoint alone will not answer it.
Building an endpoint only gets a health plan to the starting line. What happens afterward—connecting to other plans, maintaining those connections, ensuring the incoming data is actually usable—represents an ongoing operational task that most API developments do not address. Most vendor solutions are shallower in this regard than they appear. The questions that expose this gap are not about features. They are about who is responsible for this ongoing work, and most vendors do not have a good answer.
CMS-0057 Readiness: The First-Mover Advantage in Payer-to-Payer Exchange
What makes this moment strategically important is that the advantage does not grow gradually. It compounds.
A plan that connects now and drives active member consent during the 2026 open enrollment period enters 2027 with a more complete longitudinal record of the member than a plan that waits. Two or three enrollment cycles with full member transition data mean more accurate risk adjustment revenue, better HEDIS scores, and higher member retention. None of these advantages are reset when a latecomer finally connects.
Plans that view CMS-0057 data exchange as a strategic investment rather than a compliance expense will remember this period as the time when interoperability ceased to be a cost and became a competitive advantage. Plans for which this is merely a deadline to be checked off will spend the following years playing catch-up.
What to Do Before the CMS-0057 Deadline
We have gathered everything we know about bridging this gap in a new guide. It addresses the specific questions every health plan should ask their vendor or internal team right now, provides a framework for assessing whether your current solution truly addresses the network gap, and presents a real-world example of how one large national payer handled this task.
If you are serious about payer-to-payer data exchange, this is worth reading before assuming you are fully protected. Read the full version of the guide: Bridging the Payer-to-Payer Gap