Interoperability is scored, so vendor agnostic is a requirement

Most vendors say they are open. It costs nothing to say. What is different about this program is that CMS actually scores it, and it scores it again every year.

Data infrastructure is one of three technology factors in the CMS scoring framework, each worth 3.75 percent. It is an initiative-based factor, which means your state begins at 50 percent of the available points and earns the rest by implementing and hitting milestones. So a state that buys something it cannot get data out of has not just made an architecture mistake. It has capped its own score.

That is the thing I want to make concrete here, because “interoperability” is one of those words that gets nodded at and never priced.

What interoperability actually means in 2026

It is no longer a matter of opinion. CMS published an Interoperability Framework defining what modern health data exchange has to do, and networks meeting it are listed as CMS-Aligned Networks. Several of its criteria took effect on 4 July 2026. If you are spending this money on data infrastructure and building to anything less, you are buying something CMS already considers behind.

The technical requirements are specific and testable, which makes them exactly the right questions to put to a vendor before you sign:

• FHIR APIs conforming to US Core, with a full capability statement, not “we have an API.”
• USCDI version 3 or later, with real terminology binding. Labs in LOINC, medications in RxNorm, conditions in SNOMED.
• Bulk FHIR for whole-record exchange, so you are not paginating a population one patient at a time.
• FHIR subscriptions for appointment and encounter notifications.
• Record locator functionality, so a query does not have to guess where the data lives.
• IAL2 identity and AAL2 authentication for patients and providers, using passkeys or mobile driver's licenses. A verified credential should return records without making a patient register for yet another portal.

Ask for the capability statement. Ask which USCDI version. Ask about Bulk FHIR. Vague answers to those three questions are the most reliable early warning you will get.

One provision worth knowing if you are considering a partner

The framework explicitly supports a delegated model. A provider may use any application or technology partner of their choice to execute transactions. Those partners are business associates under HIPAA with an executed agreement in place, and their actions are treated as equivalent to the provider's own.

That is CMS saying, in its own document, that bringing in a technology partner is a legitimate way to participate. Useful to have in writing when somebody in the room says they would rather wait for their EHR vendor to get round to it.

What connecting to a state exchange actually costs

In Georgia, essentially every telehealth project has to reach GaHIN eventually. Most states have an equivalent. Here is what that work is, roughly in the order it bites.

• Onboarding and data use agreements. Paperwork and legal review, and it is a queue, not a task. Start it before you need it.
• Patient identity matching. This is where the real cost is. Your Mary Johnson and their Mary Johnson have to be the same person, reliably, without a national identifier.
• Terminology mapping. Your local codes to the standard ones. Tedious, unglamorous, and the thing that quietly determines whether anyone can use the data.
• Transport standards. Comparatively easy. This is the part everyone budgets for.
• Ongoing conformance. It does not end at go-live. Standards move, and a connection that conformed in 2026 needs attention in 2028.

Notice that the connection itself is nearly the cheapest item on that list. Identity matching and terminology are where the money goes, and they are almost never in the original estimate.

The closed platform trap, described mechanically

I am not going to name vendors. The mechanic is what matters, and it is simple.

A platform you cannot export from fails twice, for the same reason. It fails the data infrastructure score now, because the data does not move. And it fails in 2030, when the funding stops and you discover that everything the initiative produced lives inside something you were renting. Same property, two failures, five years apart.

This is why I keep saying that being technology agnostic is a scored requirement rather than a sales posture. We integrate with what our clients already run. In our own platform that means PointClickCare and Gehrimed in production, with MatrixCare and Netsmart reached through FHIR, HL7 and ADT. Not because agnostic sounds good in a meeting, but because a rural hospital is not replacing its EHR to accommodate a five-year grant, and it should not have to.

What “we own our data” has to mean to be worth anything

Everyone will tell you that you own your data. Push on it. Four questions turn that sentence into something enforceable, and they belong in the contract rather than the sales deck:

• Schema. In what structure? A PDF export is not your data.
• Format. Standards-based, or a proprietary dump only they can read?
• Cadence. On demand, or once a year if you ask nicely?
• Termination. What happens on the day the contract ends, and how long do you have?

If those four answers are not written down, you do not own your data. You have been told you do.

One last thing worth flagging. Security validation requirements attach to the network itself, not only to the software connecting to it, so ask early which validations a given program actually requires and who is required to hold them. Ask any partner to answer that in writing, and be suspicious of a fast yes.

The title is the argument. Interoperability is scored, annually, on a testable standard that is already in effect. That makes vendor agnostic a requirement in your procurement, not a preference. Buy nothing you cannot disconnect.