The CMS-0057-F mistakes we keep seeing, and what to do instead 

There is no shortage of content explaining what CMS-0057-F requires. Most of it stays pretty high level, and the gap between what the regulation says and what actually happens when you try to implement it can be significant.

We recently hosted a webinar with Rakesh Mathew and Nate Hecker from HIKE HEALTH, alongside Mat Osmanski from Firely, to talk about exactly that. A frank conversation about what we’re seeing in the field right now, what’s catching organizations off guard, and what good implementation actually looks like with nine months left on the clock.

These are the things that came up most.

This is two different projects, not one

One of the things we hear from organizations early in planning is that they think of CMS-0057-F as a single initiative. It isn’t. Mat Osmanski put it plainly: there are two fundamentally different problem spaces here, and they need separate thinking.

The first is the access API work: patient access, provider access, payer-to-payer. If you’ve been live on 9115 since 2020, you have a head start. But consent management and identity still trip people up, and they often sit with different teams than the ones driving the technical work.

Prior authorization is a genuinely different challenge. It requires integrating with your delegated vendors, and most payers have a lot of them. As Rakesh mentioned, some payers have 5, 10, up to 15 delegated vendors, which starts to become very complex.

A dental vendor, a vision vendor, a behavioral health vendor, a long-term care vendor, each covering a different clinical area, each with their own timelines and capabilities. If you haven’t started mapping those out, that’s where to begin.

The governance gap is bigger than the technical one

Governance came up a lot throughout the conversation. That tells you something.

What we’re consistently seeing is that organizations are treating this as an IT project. IT gets handed the mandate, IT builds the APIs, and then six months in, the business hasn’t been involved, nobody owns the data that’s now flowing in and out, and compliance shows up at the end asking why certain boxes weren’t checked.

Nate had a straightforward take on this:

“Who owns this? And it better not be IT. IT is responsible for supporting and enabling it for the business. But who are your business stakeholders, the ones who are going to drive this to operational excellence?”

Rakesh’s practical advice: stop looking for owners by API. Nobody naturally owns “the Patient Access API.” Start by data type. Who owns claims? Who owns clinical data? Who owns risk? Those people exist, they have budget, and they have a reason to care once you explain the impact.

The facade model worked for 9115. It won’t work forever.

A lot of payers built their 9115 implementation on what’s called a facade model, meaning the FHIR APIs sit on top of existing systems but the underlying data was never converted into FHIR. For the 2020 requirements, it worked.

For CMS-0057-F, it’s likely to create limitations down the line. Rakesh was direct:

“I highly recommend you move away from the facade model and go into a CDR model, because that is the future. Even if you look at the new CMS-0053 regulation that came out last week, there is a lot of focus on that.”

A Clinical Data Repository (CDR) means FHIR is the actual system of record, not a layer on top of something else. It’s the foundation for payer-to-payer exchange, for prior auth, and for everything after 2027.

As Mat pointed out:

“You don’t want to have a plan just to meet compliance for CMS-0057-F and not be able to take advantage of all the other FHIR functionality coming in the future. Flexibility is really important.”

Solutions locked to compliance-only FHIR may help you hit January 1, but they’ll limit what you can build on top afterward.

Being API ready and being business ready are not the same thing

This is the thing that sticks with me most from this conversation. Nate talked about going live with the first HIE endpoints back in 2015, the celebration when the feeds came on, and then the immediate realization that the hard part hadn’t started yet. Data quality questions nobody had answers to. Matching logic nobody had thought through.

As Nate mentioned: “There is a huge difference between being API ready and being business ready, or clinical ready. Great, you’re compliant. But is this going to be valuable to your company?”

Compliance is the starting line. The organizations that get the most out of this are thinking now about what comes after: digital quality measures (dQMs) on real FHIR data, longitudinal member histories, prior auth automation that actually reduces friction. The opportunity is real. But only if the foundation is right.

If you’re worried about the deadline, here’s where to start

• Assess your 9115 foundation. If it’s strong, you’re further along than you think. CMS requires capability by January 1, not live connections. A strong 9115 base plus consent process plus ready APIs means you’re in reasonable shape.
• Get a full account of your delegated vendors. Today. Find out what each one can do, what their timeline is, and what it will cost. Don’t plan any vendor changes close to the deadline.
• Think state first. More than 90% of your data exchange will happen within your state. Start those conversations with neighboring payers before waiting on a national solution that may not arrive in time.
• Watch for hard-coded systems. If your vendor can’t demonstrate support for new implementation guides with a clean demo, that’s a red flag worth taking seriously.

And, as Nate put it: you don’t know what you don’t know. Getting an external assessment of your roadmap before the final stretch is not a sign of weakness. It’s how you find the gaps before they find you.

Want to go deeper?

We covered a lot more in the full session, including the DTR gap that most payers haven’t planned for, a practical workaround for the CQL problem in EMRs, and a live Q&A where attendees already mid-implementation asked some sharp questions. Watch the full recording on demand.

If you’d like to talk through where your program stands, we’re happy to have that conversation. Speak to Firely’s CMS experts or reach out to the HIKE HEALTH team.