Every 1upHealth customer hit the CMS-0057 March 31, 2026 deadline. They stood up Patient Access API reporting, submitted utilization data, and moved on. That CMS deadline measured one thing: could you build the infrastructure. It was a fair question, and the answer for many interoperability vendors and their customers was yes.
The January 1, 2027 deadline asks a harder question. Electronic Prior Authorization, Provider Access, and Payer-to-Payer Data Exchange all go live — and unlike Patient Access reporting, the value of these APIs isn’t determined by whether you built them correctly. It’s determined by whether anyone on the other end shows up.
That’s a new kind of risk, and it’s one most compliance timelines don’t account for.
The Lesson Nobody’s Applying from CMS-9115
When CMS-9115 mandated the original Patient Access API, the industry learned a hard lesson: building the infrastructure doesn’t guarantee adoption. Utilization stayed low for years, largely because activation depended on individual members discovering a third-party app, understanding its value, and navigating an authorization flow on their own. Payers had built the pipes. They had almost no ability to influence whether water flowed through them.
Here’s what’s different this time around: the parties on the other end of the CMS-0057 APIs aren’t individual consumers making one-off personal decisions. They’re organizations. Provider groups. Health systems. Delegated UM vendors. Other payers. Entities that can be identified, recruited, onboarded, and activated on a timeline you control.
In other words: this time, low utilization isn’t something that happens to payers. It’s something they can influence.
What Zero Connectivity Actually Costs
It’s worth sitting with what “technically compliant, functionally unused” looks like for each API, because the consequences aren’t abstract:
- A Payer-to-Payer Data Exchange API with no connected payers can’t pull prior coverage histories for new enrollees, which means care gap closure programs restart from zero every enrollment cycle, with direct downstream impact on HEDIS and risk adjustment scores.
- An Electronic Prior Authorization API with no provider onboarding doesn’t reduce prior authorization volume, decision times, or administrative burden. None of the cost savings materialize, because nobody’s using the door you built.
- A Provider Access API nobody queries delivers no data to treating physicians, doesn’t support care coordination, and generates no evidence of clinical utility.
Most plans right now are tracking toward the first kind of readiness: technical compliance. The vast majority are tracking toward the second: actual connectivity. That gap is exactly where payers should be focused over the next 5 months.
CMS-0057 is a Mile Marker, Not a Finish Line
It’s also worth zooming out, because treating January 1, 2027 as the destination is its own kind of mistake. The regulatory runway already extends well past it.
For example, with CMS-0062-P (October 1, 2027 proposed date), Prior Authorization FHIR specs go from advisory to required, Electronic Prior Authorization requirements cover drugs, endpoint reporting to the National Healthcare Provider and Services Directory becomes mandatory, and Electronic Prior Authorization reporting gets more granular.
Payers who treat CMS-0057 as a single event will find themselves rebuilding the same muscle — network, not infrastructure — for every rule that follows.
The Real Prerequisite: A Network, Not an API
Here’s the uncomfortable math. The naive version of CMS-0057 compliance is every payer connecting directly to every other payer and every provider in the country — thousands of bespoke point-to-point integrations. No payer’s engineering team has the bandwidth for that, and no provider group wants to maintain a separate connection for every plan they bill.
That’s the actual bottleneck. Not the FHIR spec. Not the API build. The network.
So what separates the plans that will have real utilization data by January 1, 2027 from the ones that will have technically valid, functionally empty endpoints? It comes down to a short list of unglamorous, operational questions.
We highlight these questions and break down exactly what “ready” looks like against each of them — plus highlight how a regional Blues plan, a large national carrier, and a small regional Medicare payer are each approaching this differently based on their starting point — in the full ebook, “CMS-0057 Compliance: Why FHIR APIs Are Not Enough”. Download the ebook for the full picture and contact us to talk more about network strategy, provider relationships, and member workflows.