Why healthcare’s interoperability moment feels different
Common FHIR foundations and a more open, voluntary CMS-led ecosystem are shifting healthcare’s test from simply moving data to making it useful.
For years, healthcare interoperability was largely measured by a straightforward question: Can the data move? Could one organization send a clinical document to another, could an electronic health record expose information through an application programming interface, and could a network locate a patient’s record outside its own walls? Those were necessary questions, and the progress that came from answering them created the foundation we have today.
But moving data was never the ultimate goal. The goal was to help someone make a better decision, reduce unnecessary work or help a patient receive care without avoidable delay. Too often, the industry proved that an exchange was technically possible without proving that the information arriving on the other side was timely, understandable or integrated into the workflow where a decision actually occurred.
What feels different now is that three conditions are converging. The technical foundation is more mature, government and private-sector participants are increasingly working through shared use cases, and the patient is becoming a more explicit organizing principle for exchange. That does not mean the difficult work is finished; it means healthcare has a better opportunity to move from data exchange to data utility.
The foundation is no longer hypothetical
Healthcare has spent years assembling the building blocks for a more connected system. FHIR provides a standardized, API-oriented framework for representing and exchanging health information. The USCDI defines a baseline set of data classes and elements for nationwide exchange, while the US Core Implementation Guide translates U.S. interoperability requirements into FHIR profiles and minimum interactions for accessing patient data.
These are no longer experimental concepts at the edge of the market. Since January 1, 2023, certified health IT users have been required to have standardized APIs for patient and population services available. In 2024, approximately nine in 10 non-federal acute-care hospitals enabled patient access to health information through an API, and seven in 10 reported using a standards-based API such as FHIR for patient access. USCDI Version 3 became the baseline standard in the ONC Health IT Certification Program on January 1, 2026.
Those numbers should not be mistaken for complete operational interoperability. An available API is not the same as a workflow that people use successfully, and a technically conformant payload is not automatically useful when it arrives. What has changed is that the industry no longer has to begin every new conversation by debating whether a modern API model is possible; there is now a common technical floor from which more difficult workflow questions can begin.
Once organizations share a basic method for requesting, returning and interpreting information, the work shifts toward purpose. Leaders can spend more time asking what information is needed, when it should appear, who should act on it, what context is necessary and what outcome the exchange is supposed to improve.
Collaboration is becoming part of the operating model
The second difference is how participation is being structured. Past interoperability efforts often required an organization to join a particular network, execute a specific set of agreements, absorb a cost or commit to a defined exchange model. Those networks created important capabilities, but they also reinforced separate lanes in which payers, providers, EHR developers, data networks and consumer applications often worked on different parts of the same problem in different rooms.
MEDITECH manager of interoperability development Jason Vogt has participated in many of the workgroups shaping the current environment. In an interview for this article, he described the change in unusually simple terms: “The only barrier to entry is that you’re going to pledge that you’re actually going to do the work.” The point is not that participation is literally barrier-free; organizations still have to meet technical, legal and operational requirements. It is that the CMS model is built around public commitments to shared implementation goals rather than admission to a single proprietary exchange.
CMS describes its Health Technology Ecosystem as a voluntary ecosystem of networks, providers, EHR developers, payers and patient-facing applications. The initial categories include CMS Aligned Networks and organizations connecting to them, while the framework itself sets common criteria for patient access, identity, claims and clinical-data exchange. CMS reports that numerous early adopters reached general availability in July 2026.
At the ecosystem’s one-year anniversary, CMS also launched additional workgroups and pledge use cases for modern scheduling, Bulk FHIR, clinical-trial matching, real-time benefits, pharmacy connectivity and other functions. CMS is explicit that some of these criteria are still less mature and that early adopters are expected to collaborate on implementation guidance. That distinction matters because the framework is an operating experiment as well as a technical blueprint.
This does not eliminate competition, and it should not. Competition can accelerate development and produce better experiences, but the more useful contest is no longer simply over who can establish a connection first. It is increasingly about who can use a shared foundation to create a safer, more understandable and less burdensome experience for patients and care teams.
There will still be disagreement because EHR developers, health plans, provider organizations, networks and app developers see workflows through different operational lenses. Bringing those perspectives into the same implementation process does not guarantee consensus, but it makes it harder for any one constituency to define success solely from its own technical perspective and gives policymakers a clearer view of what happens when a specification reaches frontline work.
The patient is becoming the organizing principle
The most consequential shift is philosophical. Earlier interoperability efforts focused heavily on institutional exchange, often for treatment, while patient access developed alongside that work through portals and later applications. The organization holding the data remained the practical center of many workflows.
The newer model starts from a different premise: patients should be able to access their information through applications they choose and use that information across organizational boundaries. They should not need to maintain a separate portal relationship with every place they have received care simply to reconstruct their own history, and they should be able to bring claims, clinical information, prior authorization details and other relevant data into tools that help them understand what comes next.
The CMS framework makes that direction explicit. Its patient-access criteria envision commercial and noncommercial apps retrieving information across CMS Aligned Networks without requiring the app to hold special network status, and its identity criteria are intended to reduce dependence on separate provider-specific portal credentials. The same ecosystem is now testing real-time scheduling capabilities that would allow patients to discover, book, reschedule and cancel appointments through standardized FHIR APIs rather than relying only on portals and phone calls.
Patients do not need to know what FHIR, US Core or an identity-assurance level means. They experience interoperability in much simpler terms: Can I obtain my information, understand it and use it to prepare for a visit, schedule the next step or avoid repeating work that has already been done? Those questions move the standard of success away from whether a connection exists and toward whether the connection changes the patient’s experience.
I think of the patient as the orchestrator of this data journey. That does not mean asking the patient to perform the technical integration or manage every exchange; it means designing systems so information can follow the person and support the decisions that person and the care team need to make. A large clinical document that arrives at the wrong time or in the wrong place may satisfy an exchange requirement while offering very little practical value.
That is a higher standard than access alone. Data becomes useful when it is trustworthy, sufficiently complete and presented inside the clinical or administrative workflow where someone can act on it. The more interoperability moves toward that standard, the less meaningful it becomes to count connections without also measuring what those connections accomplish.
Momentum is not the same as completion
There is good reason for optimism, but momentum should not be confused with completion. National API adoption is broad, yet implementation capacity remains uneven, which means the same technical standard can produce very different experiences depending on the hospital, vendor and resources available to support it.
The latest ONC data show that medium and large hospitals, system-affiliated organizations and hospitals using a market-leading EHR were more likely to report standards-based API use in 2024. A related patient-access brief found that smaller, rural, Critical Access and independent hospitals continued to lag in some app-based and FHIR-enabled capabilities. A common technical floor does not automatically create a common capacity to implement it.
As an EHR vendor, MEDITECH has an obvious role in that implementation gap, and so do other technology companies, networks and policymakers. If the next phase of interoperability is intended to produce broad patient utility, the design cannot assume that every organization has a large interface team, extensive capital or dedicated staff available to absorb new specifications.
The CMS framework acknowledges the same challenge by labeling some of its criteria visionary and by asking early adopters to help develop implementation guidance where standards and workflows are less mature. That is appropriate. The industry needs to learn from real deployment rather than assume that technical conformance alone guarantees operational success.
Friction is inevitable. Digital identity has to work across organizations, privacy and consent requirements have to be respected, data must be reliable enough for the intended use, and new capabilities have to fit clinical and administrative work without simply moving burden from one screen to another. What gives me hope is not a belief that those problems have already been solved; it is a willingness to expose them and make implementation feedback part of the work.
A new test for interoperability
Healthcare leaders should evaluate this next phase with questions that go beyond connectivity. The first question is what patient, clinician or operational decision an exchange is supposed to improve; the second is whether the recipient can actually use the information rather than merely receive it. Leaders should also ask whether the people responsible for the real workflow have tested the capability and whether organizations with fewer technical and financial resources can implement it successfully.
The final question is measurement. If a new exchange does not reduce burden, improve access, shorten a process or make a decision more reliable, leaders should be willing to ask what value the connection is producing. Those measures will differ by use case, but defining them before implementation is what separates interoperability as infrastructure from interoperability as an outcome.
If healthcare can answer those questions, interoperability can become more than a series of interfaces, mandates and network connections. It can become an operating capability that allows information to support care wherever the patient goes, while still respecting the governance and privacy rules that make that exchange trustworthy.
That is why this moment feels different. We are no longer asking only whether healthcare data can move; we are beginning to ask whether it moves with enough purpose, context and usability to change what happens next. The answer will determine whether patients become meaningful orchestrators of their information and whether the industry finally measures interoperability by the decisions and experiences it improves.
Mike Cordeiro is Senior Director of Interoperability Market and Product Strategy at MEDITECH, where he focuses on interoperability products and services intended to improve patient and caregiver access to health information.