Federal Interoperability is Moving. Will HIEs Get Left Behind?

For the past several months, I’ve had a front seat to critical conversations happening across the health information exchange (HIE) and health data policy community that share a common undercurrent of unease. The federal momentum around interoperability is real: more CMMI models, more payment incentives, more policy signals that data should move. Yet the organizations that have spent years building the infrastructure that makes that movement possible are increasingly anxious about whether they will have a seat at the table.

That anxiety is not unfounded. And it deserves a more direct conversation than it's been getting.

Stated plainly: as federal programs take shape and early adopters emerge, commercial health data vendors are capturing attention and opportunity at a pace that local and regional HIEs and health data utilities (HDUs) cannot match. Not because commercial vendors are doing the work better. But because they are more visible, better resourced for federal engagement, and operating in an environment that has never been particularly good at recognizing the value of local infrastructure, even when it depends on it.

A dynamic I've been hearing across multiple conversations recently crystallized something I'd been sensing for a while. Federal model design is beginning to name HIEs explicitly as necessary infrastructure. For example, the ACCESS model specifies that participants must “integrate with a Health Information Exchange (HIE) or similar trusted network.” But there is a persistent gap between that inclusion and knowing which HIEs are ready to participate. Those gaps are being filled by commercial vendors.

The federal government has written HIEs into model requirements, which means the category is recognized as necessary. And yet CMS cannot readily identify which HIEs are positioned to participate or even what capabilities they have. So commercial vendors step in, not necessarily because they are better suited to the work, but because they attract attention. And they have CMS’ attention.

This is not a story of federal hostility toward HIEs. It's more complicated than that. Federal interoperability policy has structurally undervalued local infrastructure for years, orienting investment toward large EHR vendors, national exchange frameworks, and FHIR-based APIs while leaving the governance, consent management, and cross-sector data work that local HIEs do largely outside the frame of what gets resourced and recognized. That's a pattern with a long history. And alongside it, the HIE community has a visibility and readiness-signaling problem that can't be entirely blamed on federal inattention.

Both things are true. The window is open right now, and if neither gets addressed, local infrastructure loses ground it will not easily recover.

The Reality of HIE and HDU Infrastructure

Before making the case for why HIEs and HDUs should be centered in federal interoperability strategy, it's worth being clear about what this field has actually built. Many people's picture of an HIE is frozen somewhere around 2009, the early days of HITECH-funded infrastructure, when exchange meant moving clinical data between hospitals and physician practices. What exists today is considerably more sophisticated.

In 2023, Civitas Networks for Health published the Health Data Utility Framework, a detailed, field-developed guide to what it means for an HIE to evolve into an HDU. The framework defines HDUs as “models with cooperative leadership, designated authority, and advanced technical capabilities to combine, enhance, and exchange electronic health data across care and service settings — for treatment, care coordination, quality improvement, and community and public health purposes.”

That definition matters because of what it encompasses. HDUs are not clinical data pipes. They integrate data across a wide range of sources — e.g., claims, pharmacy, public health, social risk and needs, community services, and all-payer claims databases — and they do so under governance structures that are multi-stakeholder, transparent, and accountable to the communities they serve rather than to market incentives. They are designated through state authority — via legislation, executive order, or rulemaking — which gives them a layer of formal accountability that a vendor contract does not.

The framework also describes an evolution: HDU is what happens when an HIE matures its capabilities, broadens its data sources, deepens its governance, and takes on the full complexity of cross-sector data exchange for whole-person care. The field has done the work of defining what that progression looks like and what it takes to get there.

And it extends beyond HDUs. The broader ecosystem includes regional health information collaboratives, community information exchanges, 211 networks, and other community data infrastructure organizations that contribute to the layered architecture that makes cross-sector data exchange possible at the local level. HIEs and HDUs are the center of gravity for this ecosystem: the organizations with the technical infrastructure, governance structures, and data agreements that hold the rest of it together.

What Commercial Vendors Can and Can’t Do

None of this is an argument against commercial health data vendors. They bring real capabilities: technical sophistication, speed, scale, and an ability to navigate federal procurement that community-based nonprofits often lack. There is a legitimate role for commercial players in the interoperability ecosystem.

The problem is not their presence. It's the assumption, implicit in how federal programs are currently taking shape, that commercial vendors can substitute for local infrastructure rather than build on top of it.

Here is the distinction that matters: commercial vendors can move data efficiently between systems that are already connected, consented, and willing to share. What they generally cannot do is the harder upstream work: negotiating data sharing agreements across unaffiliated organizations, building consent architecture for sensitive data types such as behavioral health and substance use, sustaining community trust relationships that make data sharing governable at the local level, and maintaining governance accountability to a defined community rather than to a board and investors.

The ACCESS model's deliberate use of the phrase "trusted network" is not incidental. It reflects something real about the accountability relationship that a community-governed HIE has with its participants and the populations it serves. You cannot acquire that through a contract or replicate it through a better API.

What local HIEs and HDUs have — cross-sector data aggregation, community relationships, consent architecture for sensitive data, neutral governance — is precisely what whole-person care models require. These are complementary, not competing, operating at different layers of the same system. The question is whether federal programs are designed to recognize that, or whether they default to whoever shows up most effectively.

The federal policy community and the HIE/HDU field both have work to do here, and it's worth being honest about that.

For federal programs, writing HIEs into model language is necessary but not sufficient. If CMS cannot identify who is ready and what they can do, the answer is not to default to whoever arrives first with a capabilities deck. Understanding the ecosystem — who HIEs and HDUs are, what they have built, and how to create program pathways that don't systematically advantage scale and visibility over substance and community accountability — is part of the job. The window is open. The infrastructure already exists. Build on it.

For the field, the visibility problem is real and it is partly ours to solve. The organizations that shaped the backbone of this system shouldn't be watching from the outside while others fill the space. The current moment — more models, more mandates, more federal attention than we've seen in years — is not a time to wait to be discovered.

The national interoperability system being built right now assumes a local governance capacity that market forces alone will not sustain. Clinical exchange frameworks, FHIR-based APIs, and commercial data networks are all part of what's needed. So is the trusted, community-aligned infrastructure that HIEs and HDUs have spent years building.