How to evaluate your FHIR vendor for CMS-0057-F compliance

Many payers either have a FHIR vendor or are close to choosing one. Some are already mid-implementation. A smaller number are still in evaluation mode, looking at options before making a call.

Whether you’re in the first camp, the second, or somewhere in between, the question on the table is essentially the same: is the solution you’re building toward actually going to hold up before January 2027?

That’s less than eight months away. Long enough to course-correct if you need to. Short enough that the window is closing.

The questions below are framed for both situations. If you’re still evaluating, they’re criteria. If you’ve already committed, they’re a diagnostic. Either way, the answers are important to consider.

Do they have genuine FHIR expertise, or just a FHIR layer?

There’s a difference between a vendor who has built a FHIR server and a vendor who has been working with HL7 FHIR since the specification was being written. The former can get you endpoints.

The latter can tell you why a particular IG conformance decision will cause problems six months from now, or why your data model is going to create issues for the Payer-to-Payer exchange you haven’t built yet.

A FHIR layer on top of a legacy system is not the same thing as a FHIR-native platform. If your vendor’s answer to every question is “we’ll map that,” that’s worth understanding in more depth.

Can it handle all five APIs, not three?

The January 2027 requirement is five APIs in production: Patient Access (enhanced with prior auth data), Provider Access, Payer-to-Payer Data Exchange, Prior Authorization (CRD, DTR, and PAS), and Provider Directory.

Some vendors have strong coverage on two or three and limited experience with the rest. Ask specifically about the ones you’re less confident about.

This comes up a lot in conversations we have with payers. A solution that was scoped around Patient Access and Provider Directory may not have been designed with Payer-to-Payer data exchange or PA automation in mind. The work to extend it is not always straightforward.

Does it work across your provider network, or just part of it?

The Prior Authorization API only delivers value if providers can actually use it. That means it has to work with the range of EHR systems across your network, not just the one or two it was tested against in a sandbox.

Ask your vendor: which EHR systems have you tested this against? What happens when a provider’s EHR doesn’t support CDS Hooks natively? The answer tells you a lot about how production-ready the solution actually is.

How do they handle IG updates?

Implementation Guides (IGs) get updated. The Provider Directory API already required a migration from US Core 3.1.1 and Plan-Net 1.1.0 to newer versions by January 2026. That won’t be the last migration.

CMS-0062-P, the proposed 2026 Interoperability Standards and Prior Authorization for Drugs rule published in April, goes further. For the first time, CMS is proposing to require the Da Vinci IGs that were previously only recommended (covering all five APIs) with current versions due January 1, 2027 and updated versions (CRD v2.2.1, DTR v2.2.0, PAS v2.2.1, and others) required from January 1, 2028. There is also a proposed Standards Version Advancement Process for future updates.

That’s a versioning cadence, not a one-time migration. A vendor who can validate conformance against current IGs, flag drift early, and support you through version transitions is a very different proposition from one where every IG update becomes a custom project. This is an area where tooling depth really matters.

What does their implementation track record actually look like?

Every vendor has references and case studies. What you’re looking for is specificity: similar payer type, similar scale, similar complexity. A vendor who has implemented for a large Medicaid plan is not automatically the right fit for a commercial insurer, or vice versa.

Ask for references from payers in a similar situation to yours, and ideally ones who went through a challenging implementation, not just a successful one. How a vendor handles problems tells you more than how they describe their wins.

If you’re already underway: what should you be seeing right now?

If you’ve already chosen a vendor and you’re into the work, here are a few things that should be visible eight months out from the deadline:

• A clear sequencing plan across all five APIs, not just the ones you’ve started
• At least one API in a real testing environment, not just designed on paper
• Your data quality and governance gaps identified and being addressed, not deferred
• Evidence that the solution has been tested against more than one or two EHR systems in your provider network
• A process for staying current with IG updates, not just a promise that the vendor will handle it

If several of these aren’t landing well, it’s worth having that conversation with your vendor now — or reconsidering your options before Q4 makes the decision for you.

And it’s worth noting the regulatory horizon extends well beyond January 2027: CMS-0062-P proposes to add drugs under the medical benefit by October 2027, and to replace X12 278 with FHIR under HIPAA for all covered entities. The direction of travel is clear. A vendor built for where the standard is today is a different proposition from one built to evolve with it.

We’ve put together a more detailed CMS-0057-F Readiness Checklist that covers the full scope of what January 2027 actually requires. If you’re not sure where your program stands, it’s a useful place to start. And if you want to talk through what you’re seeing, get in touch.