CMS‑0057‑F readiness Is advancing, but execution risk Is growing

As health plans race to meet the CMS) Interoperability and Prior Authorization Final Rule (CMS-0057-F) requirements, many are discovering that compliance is only part of the challenge. The real test lies in how we adjust operation to capture value.

Results from WEDI’s interoperability and prior authorization survey shed light on where the industry stands today. In this article, I analyze what the results say about adoption, usability and the work still required to scale interoperability across the healthcare ecosystem.

Operational readiness

In WEDI's most recent payer survey released in March 2026, 10% have not yet started their work, compared to 33% in October 2025. Although this is progress towards technical compliance, there remains significant operationalizing gaps. With the January 1, 2027 deadline looming, there remains a disconnect between early-stage momentum and execution maturity. On paper, CMS‑0057‑F looks like a series of discrete tasks, such as standing up application programming interfaces (APIs) aligning to standards, and meeting the deadline.

Execution reveals a much more complicated picture. After teams leave the planning phase and get into building and testing, they discover hidden dependencies: governance approvals that impact architecture, security rules that lengthen partner onboarding, workflow changes that need alignment across various teams.

CMS Interoperability and Patient Access Final Rule (CMS‑9115‑F) and the Patient Access API provide a clear example of how implementation can uncover complexity.

Patient access

Many health plan leaders assumed Patient Access APIs would be one of the easier requirements to extend to CMS-0057-F application. After all, Patient Access was already required under the CMS Interoperability and Patient Access Final Rule (CMS‑9115‑F) mandate. That assumption is now proving costly.

Under CMS‑9115‑F, Patient Access APIs were largely built to check a compliance box, not to support day‑to‑day operational use. As long as a managed FHIR store and an API technically existed, it met the requirement. This created the foundational requirements for national interoperability through standardized data storage in a format purpose-built for exchange and APIs to access it. Real‑world adoption, consistent performance, data quality, and workflow integration were not the primary focus.

As a result, many patient access API implementations were never stress‑tested. Gaps in onboarding, trust, data readiness, and downstream workflows were easy to overlook because the APIs weren’t being used at scale.

CMS-0057-F builds complexity onto the CMS-9115-F foundation. However, since those capabilities were not tested, building more upon that infrastructure is proving more complex and costly than originally anticipated. CMS‑0057‑F exposes what earlier compliance efforts never required organizations to solve.

The WEDI survey reflects this reality: 35% of payers report being only 25% complete, or less, on implementing the Patient Access API.

CMS‑9115‑F largely resulted in interoperability for interoperability’s sake. However, CMS‑0057‑F positions interoperability as a means to business value, not the end goal itself. When Patient Access APIs are tied to outcomes that matter to both providers and health plans, adoption becomes real and so do the gaps.

Building APIs

For many organizations, this is the moment when execution feels harder than expected. Not because industry implementation guides are unclear, but because the work touches more of the enterprise than initially anticipated.

In conversations with health plans, the more common challenge isn’t technical; it’s structural. APIs are often delivered as endpoints but not operated as ongoing capabilities. Ownership is fragmented across teams, governance decisions trail technical build, and funding is scoped for delivery rather than sustained use and inevitable evolution.

What’s often missing is the network layer required to make those APIs work in practice. APIs don’t exchange data on their own. They depend on reliable connectivity between organizations, consistent onboarding and identity verification, shared expectations around data quality, and operational support when something breaks. Without that connective tissue, even well‑built APIs struggle to achieve meaningful adoption.

This helps explain why prior interoperability efforts produced compliant endpoints with limited real‑world use. The technology functioned as designed, but the surrounding ecosystem was never activated. Providers and partners weren’t consistently onboarded, trust frameworks varied, and workflows weren’t aligned to support sustained exchange at scale.

More fundamentally, there was little structural incentive for either health plans or providers to invest beyond minimum compliance. Adoption required real operational effort, while the benefits were diffused and long‑term. The value proposition was largely aspirational, good for patients in theory, but not tied to measurable outcomes or near‑term business value.

CMS‑0057‑F raises the bar by increasing both volume and expectations around timeliness and usability. As APIs are pushed into daily workflows, the absence of a live, operational network becomes harder to ignore.

The rule and making it work

Ultimately, CMS‑0057‑F isn’t just an API delivery effort; it’s an ecosystem execution test. Health plans can publish compliant endpoints and still watch exchange stall because APIs don’t move data on their own. That’s why health plans that treat CMS‑0057‑F as a networked operating model decision, not just mandatory compliance, will be better positioned to scale interoperability, sustain adoption, and avoid rebuilding the same capabilities with every new mandate.

To support that shift, the CMS‑0057‑F Blueprint is a readiness‑based guide health plan leaders can use to align teams, surface dependencies, and sequence execution so required APIs work in real‑world workflows, not just developer portals.

Chris Kenyon is director of clinical solutions at Availity, which bills itself as the largest healthcare information network in the U.S.