Improving interoperability in healthcare requires coordinated action across technology, governance, and policy. The good news: real progress is happening. The share of U.S. hospitals that can send, find, receive, and integrate health data from other systems jumped from 46% in 2018 to 70% in 2023. But that still leaves nearly a third of hospitals struggling to exchange information effectively, and even connected systems often fail to make exchanged data truly usable. Here’s what organizations can do at every level to close those gaps.
Understand the Four Levels of Interoperability
Not all data exchange is created equal. HIMSS defines four distinct levels, and most frustrations stem from confusing one level with another or stopping too early.
- Foundational (Level 1): One system can receive data from another. This is the bare minimum, essentially a working network connection.
- Structural (Level 2): The data arrives in a standardized format so the receiving system can parse it correctly. Think of it as agreeing on the same file structure.
- Semantic (Level 3): Both systems interpret the data identically. A lab result coded one way in System A means the exact same thing in System B, with no ambiguity.
- Organizational (Level 4): Governance, legal agreements, consent policies, and integrated workflows allow organizations to actually trust and act on the data they exchange.
Most healthcare organizations have achieved Level 1 or 2. The real payoff comes from reaching Levels 3 and 4, where clinicians can pull in an outside record and use it without manually re-entering or reinterpreting information. Every strategy below targets one or more of these higher levels.
Adopt FHIR as Your Core Standard
FHIR (Fast Healthcare Interoperability Resources), now at version 5.0, is the standard published by HL7 for healthcare data exchange. It uses modern web technology, specifically RESTful APIs, to let applications communicate the way most of the internet already does. That matters because it dramatically lowers the barrier for developers to build connections between systems.
FHIR organizes health data into “resources” that map to real-world concepts: patients, practitioners, medications, care teams, devices, organizations. It supports multiple exchange patterns including REST APIs with search, document sharing, messaging, and real-time subscriptions. This flexibility means it works whether you’re building a patient-facing app, connecting two hospital EHRs, or feeding data into a population health dashboard.
The economics favor adoption. There are no licensing costs for the FHIR framework itself. Standard deployments typically take 2 to 8 weeks. Organizations implementing FHIR-based solutions report $3.20 in return for every $1 invested, with some seeing payback within 14 months. Administrative inefficiencies related to data sharing can drop by 60 to 70 percent. Prior authorization alone costs payers $80 to $120 per transaction to process manually. CMS estimates that automating prior authorizations could save the industry $15 billion annually, and full FHIR implementation across the U.S. system could save over $51 billion per year.
Use Open APIs to Connect Systems
APIs are the bridges between software applications. In healthcare, standardized open APIs let EHRs, patient portals, lab systems, and third-party apps share data without requiring custom-built interfaces for every connection. Instead of negotiating a unique integration each time two systems need to talk, you publish an API that any authorized application can connect to.
This approach creates an ecosystem where patient information flows between applications, providers, and patients themselves. It also extends EHR functionality beyond what any single vendor offers. A hospital running one EHR system can use APIs to pull pharmacy data, specialty notes, or imaging results from entirely different platforms. The key is using standardized APIs built on FHIR rather than proprietary ones that lock you into a single vendor’s ecosystem.
Comply With Information Blocking Rules
The 21st Century Cures Act created enforceable rules against information blocking, defined as any practice likely to interfere with, prevent, or materially discourage the access, exchange, or use of electronic health information. This applies to healthcare providers, health IT developers, health information networks, and health information exchanges.
For health IT developers specifically, the law requires them to publish APIs that allow health information to be accessed and exchanged without special effort. Developers must not restrict communications about the usability, interoperability, or security of their products. They must conduct real-world testing of interoperability in the settings where their systems are actually used, and they must attest to compliance twice a year.
The rule does include eight exceptions where restricting data access is permissible: preventing harm, protecting privacy, maintaining security, technical infeasibility, and preserving system performance. Three additional exceptions cover how requests are fulfilled, including reasonable content and manner requirements, fees, and licensing terms. If your organization restricts data sharing, you need to confirm the restriction fits squarely within one of these exceptions. Otherwise, you’re exposed to enforcement action.
Connect to a National Exchange Network
TEFCA, the Trusted Exchange Framework and Common Agreement, is the federal government’s effort to build a “network of networks” for nationwide health information exchange. At its core are Qualified Health Information Networks (QHINs), which serve as central connection points. Any U.S. entity can apply to become a QHIN, though the designation process typically takes about 12 months and requires signing the Common Agreement that governs how data flows across the network.
For individual health systems, connecting through a QHIN means you can exchange data with any other organization on the TEFCA network without negotiating separate data-sharing agreements with each one. This is particularly valuable for organizations that treat patients who move between regions or see providers across multiple health systems. Rather than building dozens of point-to-point connections, you plug into one network and gain access to all of them.
Standardize Terminology and Data Quality
Semantic interoperability only works when everyone uses the same vocabulary. CMS has set a concrete deadline: by July 4, 2026, networks must provide data through FHIR APIs that adheres to the US Core implementation guide and USCDI Version 3 or later. That means lab results coded in LOINC, medications in RxNorm, and conditions in SNOMED. If your systems currently use local or proprietary codes, mapping them to these standard terminologies is essential groundwork.
Beyond terminology, identity matching remains one of the hardest practical problems. When a patient’s records exist across five different systems, each with slightly different spellings, addresses, or identifiers, matching those records to the same person is error-prone. CMS is pushing toward identity-verified credentials at IAL2 level (the same identity assurance standard used for government-issued digital IDs) to support more reliable matching. Where legally permissible, queries should be fulfilled automatically and in real time.
Clinical documents, including radiology reports, scanned labs, and specialist notes, should be returned in both machine-readable and human-readable formats. USCDI v3 specifies support for PDF, TIFF, and JPG alongside structured data. This dual approach ensures that even unstructured documents can flow through interoperable channels while still being readable by clinicians on the other end.
Enable Patient Access
Patients are a powerful but underused force for interoperability. Under the CMS Interoperability and Patient Access rule, Medicare Advantage organizations, Medicaid and CHIP programs, managed care plans, and qualified health plan issuers on federal exchanges must make claims, encounter data, and clinical data (including lab results) available through a Patient Access API. This includes all data with a service date from January 1, 2016 forward for current enrollees. Vision and dental claims are not excluded.
When patients can access their own data through third-party apps, they become the connective tissue between fragmented systems. A patient seeing a new specialist can share their complete claims history, medication records, and lab results directly from their phone. This doesn’t replace system-to-system interoperability, but it fills gaps where institutional connections don’t yet exist.
Build Organizational Governance Around Data Sharing
Technology alone won’t solve interoperability if organizational policies work against it. Level 4, organizational interoperability, requires shared consent frameworks, trust agreements, and integrated workflows that make data exchange part of routine care rather than a special request.
Start by auditing where your organization currently blocks or slows data flow, whether through overly restrictive consent policies, manual fax-based processes, or IT systems that technically support exchange but aren’t configured to use it. Then establish clear internal governance: who owns data quality, who maintains API connections, who monitors compliance with information blocking rules, and who resolves identity matching errors. Organizations that treat interoperability as a technical project rather than an ongoing operational function tend to build connections that degrade over time as systems update, staff turn over, and standards evolve.
The 43% of hospitals that routinely engage in all four domains of interoperable exchange (up from 28% in 2018) have generally made this shift. They treat data sharing not as a compliance checkbox but as infrastructure, maintained and monitored the same way they maintain their networks and physical plants.