From the Front Lines: What Health Plans Are Learning as CMS-0057-F Becomes a Reality

The Centers for Medicare & Medicaid Services (CMS) Interoperability and Prior Authorization Final Rule (CMS-0057-F) started with a clear objective: build APIs that meet regulatory requirements and align with Fast Healthcare Interoperability Resource (FHIR) standards. But as organizations move from planning to testing, and from testing to exchanging real data, many are discovering that compliance is only the starting point.

Blog Key Takeaways

• “Compliant” implementations can still create friction
• Data usability, not just data exchange, determines value
• Early design decisions have long-term consequences
• Provider experience is the real adoption driver

The real challenge is not whether an API can be built. It is whether interoperability can be sustained across a growing network of payers, providers, and partners making different but equally valid implementation decisions.

That distinction matters because compliance alone doesn’t prevent rising integration costs, onboarding delays, provider friction, increased support demands, or weaker returns on interoperability investments.

In our blog series, From the Front Lines of CMS-0057-F, we’ll share what the builders and enablers behind implementation are seeing in real time; where complexity is starting to surface and what they want their leaders to understand now to avoid turning today’s decisions into tomorrow’s business problems.

In this first installment, I highlight three early lessons that have emerged from my work with our Payer-to-Payer Connectivity Hub cohort, a group of health plans actively working to operationalize payer-to-payer data exchange.

Lesson #1: Compliance Doesn’t Eliminate Variability

The HL7 Da Vinci Payer Data Exchange (PDex) Implementation Guide (IG) defines a standard framework for FHIR-based APIs, but because it doesn’t define every implementation detail, it allows for interpretation and introduces variability.

As health plans begin connecting with trading partners, providers, and other health plans, they are discovering that multiple organizations can be fully compliant while still making very different decisions about how data is exchanged, secured, and retrieved.

What We’re Seeing

One example is the handling of unstructured content such as PDFs, scanned documents, and images. FHIR supports multiple valid approaches through DocumentReference. Organizations can either:

• Embed documents directly within API responses
• Provide links to the referenced (not included) document

Both approaches satisfy the standard, but they introduce different requirements for authentication, access, security, and retrieval. The same pattern is emerging in how health plans implement the steps required for CMS-0057-F APIs.

Even when organizations follow the same standard, they may interpret and implement key requirements differently. For example, choosing whether to include steps like the Request Access Token before exchanging data. Because the PDex specification uses “SHOULD” rather than “MUST,” both approaches may still be considered compliant.

However, some payers choose not to support the Request Access Token because their security models grant access broadly, not at the patient level. Supporting this capability would require reworking enterprise-wide gateway controls built over time.

While these decisions may align with internal security models, they can create gaps when interoperating with partners that expect patient-scoped tokens. Even when compliant, these differences can break down in practice. If one system requires a step that another has skipped, the exchange may fail.

As variation increases, so does complexity. At scale, success depends less on having the “right” approach and more on the ability to adapt to the decisions of others.

The Business Risk Leaders Should Know

When organizations plan only for their own preferred approach, they risk:

• Slower partner onboarding and longer time to value
• Higher integration and support costs as exceptions accumulate
• Greater operational burden on internal teams
• Reduced ability to scale connectivity efficiently across trading partners

Interoperability is, in essence, health IT’s version of “plug-and-play.” But when organizations interpret standards differently, that promise breaks down.

Imagine if a USB device didn’t support standard power requirements, it may appear compliant, but it wouldn’t actually work when plugged in.

At that point, the issue shifts from technical compliance to a business question: How much variability can your organization absorb before interoperability becomes too costly or complex to sustain?

Lesson #2: Today’s Decisions Can Create Tomorrow’s Interoperability Challenges

Many of the decisions health plans are making today will shape how interoperability works in practice, not just at go-live, but long after compliance deadlines have passed.

The challenge is that some of the most important decisions are being made while the industry is still converging on how these capabilities should function.

That creates tension.

Health plans are building toward compliance, but at the same time, they are making architectural choices that may need to evolve as provider expectations, workflows, and market norms take shape.

What looks like a near-term implementation decision can quickly become a long-term constraint.

What We’re Seeing

Provider Access is one of the clearest examples. Today, health plans are effectively choosing between two models:

Version 1:

• Payer-managed attribution
• Pre-established provider-member relationships

Version 2:

• Provider attestation at the time of request
• Better aligned with real-world workflows

Version 2 is generally more intuitive, but it’s emerging later in the implementation cycle. That creates a timing and investment decision:

• If you’re early in implementation, it may be more efficient to prioritize Version 2
• If you’re further along, you may need to support both models to avoid creating provider friction

What looks like a technical choice quickly becomes a question of how easily providers can engage with your APIs.

Decisions made today can also lock in assumptions about how access works, assumptions that may not hold as the market evolves. And when they don’t, organizations don’t replace those models; they layer on top of them.

The Business Risk Leaders Should Know

When design decisions are made without accounting for how the market is evolving, health plans risk:

• Creating friction for providers, leading to slower adoption of interoperability services
• Having to support multiple access models simultaneously, increasing cost and operational complexity
• Making additional investments to retrofit flexibility into systems that were optimized for a single approach
• Limiting their ability to adapt as industry expectations and usage patterns mature

The key consideration is not just implementation effort. It is the experience on the other side of the exchange.

Because providers will not adapt their workflows to accommodate every payer’s unique approach, and the organizations that reduce friction will be the ones that see adoption, utilization, and long-term value.

Lesson #3: Exchanging Data Is Not the Same as Delivering Usable Data

As health plans move beyond connectivity and begin exchanging data at scale, a new challenge is emerging.

Early interoperability efforts focused on whether systems could connect and data could move between them. Now, as those connections become real and volumes increase, attention is shifting to a more fundamental question:

Is the data being exchanged actually usable?

Because interoperability doesn’t fail when APIs don’t work. It fails when the information they return can’t be trusted, interpreted, or acted on within real workflows.

What We’re Seeing

FHIR APIs can successfully exchange information regardless of whether the underlying data is complete, accurate, or clinically meaningful.

While interoperability partners and vendors can help standardize and enrich data, they cannot correct fundamentally inaccurate source information. As exchange volumes grow, health plans are recognizing that technical interoperability and data usability are not the same.

At scale, poor data quality doesn’t stay isolated; it becomes harder to troubleshoot, more expensive to fix, and more disruptive to operations.

The Business Risk Leaders Should Know

Organizations that treat data quality as a secondary concern may experience:

• Reduced trust in exchanged information
• Increased manual intervention
• Inaccurate information influencing decisions
• Lower value from interoperability investments

Ultimately, the success of interoperability depends not only on connectivity, but on the quality and usability of the information being exchanged.

How Availity Helps Health Plans Navigate Interoperability at Scale

As health plans move from compliance to real-world data exchange, these challenges are proving to be patterns, not edge cases. The difficulty isn’t building APIs; it’s making them work consistently across a fragmented ecosystem where different organizations make different implementation decisions.

Availity helps health plans navigate this complexity at scale by combining network reach, adaptable interoperability infrastructure, and real-world collaboration. Through one-to-many connectivity, support for multiple implementation approaches, and a focus on data quality at the point of ingestion, we help reduce the operational burden of variability and ensure data continues to flow, even as the ecosystem evolves.

If you’re exploring how to make interoperability work in practice, not just in theory, schedule time with our team, to learn more.

LEARN MORE

About the Author

Michael Taylor, Senior Clinical Product Owner at Availity, has over a decade of experience in Health IT. He has successfully navigated roles such as Interoperability Engineer, HL7 Analyst, Product Manager, and Senior Product Marketing Manager. His expertise spans a wide range, including FHIR provider directories, social determinants of health, and electronic consent management. 

Outside of his professional life, Michael enjoys hiking and kayaking. One of his favorite pastimes is modifying and playing with foam blasters. He enjoys dedicating time to enhance their performance and appearance, which showcases his unique blend of technical skills and creativity.