Only 43% of Hospitals Routinely Achieve Full Healthcare Data Interoperability
Sending some patient data to some partners some of the time is common. Complete, routine healthcare data interoperability across every connected application is still rare. The Office of the National Coordinator for Health IT tracks this every year. In 2023, only 43% of non-federal acute care hospitals routinely engaged in all four interoperability domains, sending, receiving, finding, and integrating patient data [1].
A single practice researching EMR data integration and a health system researching EHR data integration are usually describing the same underlying interface problem, just at a different scale.
The gap widens the farther the data has to travel from the EHR. Only 42% of clinicians at hospitals with external access actually use that data routinely, even when the hospital reports having it. Exchange with long-term and post-acute care providers sits at 16%. Exchange with behavioral health providers sits at 17% [1]. A health system’s EHR is rarely where this breaks down. The lab system, the imaging platform, the pharmacy system, and the billing platform sitting around it usually are.
This piece covers why that failure recurs across different systems and different health systems, and lays out the modernization options for actually closing it.
Five Points Where Patient Data Interoperability Breaks Inside a Health System
The failure above shows up in specific, recognizable moments, not as an abstract statistic. Five are common across health systems of every size.
- A specialty practice acquisition. The acquired group’s lab information system needs to talk to the acquiring health system’s EHR within weeks of close. The interface team discovers the LIS has never exchanged data outside its original four walls.
- A revenue cycle clearinghouse switch. Moving to a new RCM clearinghouse exposes years of custom billing interface logic that nobody currently on staff wrote or fully understands.
- A PACS upgrade. Replacing the radiology imaging system breaks a Mirth Connect channel that has quietly routed studies to a referring physician group for a decade. No one on the current team remembers configuring it.
- A medication reconciliation gap. A pharmacy interface mismatch drops a subset of medication orders during transcription, surfacing as a patient safety event before anyone identifies the interface as the source.
- A post-acute or behavioral health referral. ONC’s 16-17% exchange rate with these providers describes something health systems experience directly. A discharge summary needs to reach a skilled nursing facility or a behavioral health provider, and often does not arrive.
Five different systems. Five different failure points. The same underlying cause sits under all of them.
Health systems generally have three paths to fixing broken patient data interoperability. They can replace the legacy interface engine outright, wrap it with a modern FHIR-based API layer that leaves existing routing logic in place, or modernize the underlying data and integration layer itself.
The safer sequence assesses and documents every interface first, then modernizes the integration layer, then validates that patient data still moves with full functional parity before cutover.
Most of these environments run on years of undocumented HL7 v2 logic spanning the EHR, lab, imaging, pharmacy, and billing systems. Skipping the assessment or the validation step is the most common reason interoperability projects break clinical workflows or fail Cures Act information-blocking scrutiny.
Undocumented HL7 Interface Logic: The Root Cause of Broken EHR Data Integration
HL7 v2 is still the dominant standard for real-time clinical messaging inside most US hospitals, admissions, lab results, orders. It is loosely structured and customized per institution, which is exactly why undocumented, brittle interface logic accumulates over years.
AHRQ describes the resulting reality plainly: multiple standard versions across institutions, non-standard message formats, and substantial human intervention requirements to keep messages flowing correctly [2]. Health systems still hire dedicated HL7 interface engineers years after most of this logic was written, because the knowledge of what an interface does tends to live with specific people, not in documentation.
When those people leave, the ability to safely change the interface leaves with them. Interface engine modernization has to start with recovering that knowledge before any routing rule gets rewritten.
Health systems typically run both standards today: HL7 v2 internally, FHIR at the edges.
| Dimension | HL7 v2 | FHIR |
| Typical use today | Real-time internal clinical messaging (admissions, orders, results) | Patient-facing and payer-facing API access, growing external exchange |
| Message structure | Loosely structured, customized per institution | RESTful, resource-based, standardized |
| Maturity inside most health systems | Deeply embedded, decades of custom logic | Expanding at the edges, rarely a full internal replacement yet |
The $0 Modernization Assessment maps every interface your EHR, lab, imaging, pharmacy, and billing systems actually depend on, in 2 to 5 days, entirely inside your own environment, before you commit to any of the three options below.
Cures Act Information Blocking Enforcement Makes Healthcare Data Interoperability a Compliance Deadline
Information-blocking disincentives under the 21st Century Cures Act took effect for hospitals and health systems on July 31, 2024. A hospital determined to have engaged in information blocking loses meaningful-EHR-user status, costing three-quarters of the annual Medicare market basket payment increase.
Clinicians receive an automatic zero score in the MIPS Promoting Interoperability category, roughly a quarter of their total MIPS composite score, and ACOs face restrictions on participant additions or termination of their MSSP agreements [3].
Enforcement moved from theoretical to operational in 2026. On February 11, 2026, ASTP and ONC began issuing the first letters of nonconformity to certified health IT developers over API and interoperability concerns [4]. A health system whose interface layer cannot reliably move patient data on request now carries real regulatory exposure.
HIPAA Security Rule updates under consideration in 2026 add further pressure, tightening encryption and technical safeguard requirements for these same systems. TEFCA continues moving toward operational reality this year as well, with additional Qualified Health Information Network designations issued in 2026 [5]. Fixing the interface layer now is part of the same program as addressing 2026 HIPAA Security Rule requirements for legacy systems.
Three Modernization Options for the Patient Data Integration Layer
Three paths exist for the interface layer underneath every scenario above. Each resolves part of the problem. The one most competitor content already recommends resolves less than it appears to.
Option 1: Replace the interface engine. Moving off Mirth Connect or Corepoint onto a modern integration platform eliminates the accumulated custom logic structurally. The constraint is scope. A health system running dozens or hundreds of active interfaces cannot replace all of them at once without real risk to clinical data flow during the transition.
Option 2: Wrap it with a FHIR API layer. A FHIR facade in front of the existing engine is the fastest option and satisfies external, patient-facing access requirements quickly. What it does not resolve: the undocumented routing logic still running underneath it, the engine’s own maintainability, or the audit trail an information-blocking inquiry would actually need. A facade changes what the outside world sees. It does not change what is running the interface layer.
Option 3: Modernize the underlying data and integration layer. This path applies comprehension, transformation, and validation to the interfaces themselves. It takes longer to plan than Option 2. It is the only path that produces both a modern integration layer and the documentation an information-blocking inquiry or a HIPAA Security Rule audit would require, generated as a byproduct of the work itself. For health systems pursuing this path, modernizing the API and middleware layer underneath the interface engine is the specific mechanical work involved.
| Option | What it resolves | Typical timeline | What remains after |
| Replace the interface engine | Eliminates accumulated custom logic in the interfaces replaced | Months per major interface, longer across a full estate | Interfaces not yet replaced still carry the same risk |
| Wrap with a FHIR API layer | Satisfies external, patient-facing access quickly | Weeks to a few months | Undocumented routing logic and audit trail gap remain underneath |
| Modernize the data and integration layer | Produces a modern layer and audit documentation together | Longer to plan, phased in execution | Requires the most upfront comprehension work |
A Technical Demo walks through how a five-agent lifecycle assesses, documents, and modernizes a legacy interface layer, so the choice between these three options is based on what your interfaces actually need, not a guess.
Matching the Modernization Option to Your Health System’s Integration Scenario
The right option depends on the scenario, not on a fixed preference. The table below maps the five moments from earlier in this piece to the option that fits each one.
| Scenario | Best-fit option | Why |
| Specialty practice acquisition (LIS to EHR) | Modernize the data and integration layer | A permanent new connection is worth building correctly rather than patching around |
| RCM clearinghouse switch | Replace the interface engine | The clearinghouse relationship is already changing, a natural point to retire the old logic |
| PACS upgrade breaking a Mirth channel | Replace the interface engine, scoped | A single broken channel is usually a targeted fix, not a full re-platform |
| Medication reconciliation gap | Modernize the data and integration layer | Patient-safety-critical logic warrants comprehension and validation, not a quick patch |
| Post-acute or behavioral health referral gap | Wrap with a FHIR API layer, as a step toward Option 3 | External partners with limited integration capacity often need a standards-based interface before a full internal rebuild is justified |
The common thread across all five: someone has to actually know what an interface currently does before choosing how to change it.
How Legacyleap Modernizes Healthcare Data Interoperability From Assessment to Validated Parity
Option 3 only matters if modernizing a health system’s actual interface layer is executable on a realistic timeline. Legacyleap’s five agents map directly onto that work. The Assessment Agent and Documentation Agent handle the comprehension most health systems in this position lack. Together they produce a real dependency map, risk indicators, and reconstructed documentation for interfaces that were never formally documented, typically completed in 2 to 5 days rather than months of manual discovery.
The Modernization Agent then executes the transformation as diff-based, human-reviewed pull requests, never a direct or autonomous write to a production interface. That distinction matters most for interface-routing logic, where a silent behavioral change can mean a lab result or a medication order routes to the wrong place. The QA Agent validates functional parity before any modernized interface reaches live patient data, closing the validation step Option 2’s facade skips entirely.
A healthcare and life sciences organization modernized a Delphi 2007 application to .NET as part of Legacyleap’s dead-language re-platform capability proof. Separately, a medical imaging platform was modernized from .NET Framework 4.7.2 to .NET 9, preserving clinical functionality throughout.
A health system that does not yet know which of the three options its interface layer actually needs can get that answer directly. The $0 Modernization Assessment runs before any commitment, entirely inside the organization’s own environment, with no source code leaving its infrastructure. Some health systems’ real question is whether to replace the EHR itself, rather than the interoperability layer around it. For that decision, a full framework for deciding whether to replace, wrap, or modernize the EHR itself covers it directly.
Next Steps for Modernizing Healthcare Data Interoperability
The same undocumented interface layer sits underneath every scenario in this piece, whether it surfaces as an acquisition, a clearinghouse switch, a PACS upgrade, or a referral that never quite arrives. The Cures Act has turned leaving that layer alone into an active, present liability.
Replacing the engine, wrapping it in FHIR, and modernizing the underlying layer each solve a different part of the problem, and the right choice depends on the scenario in front of you.
Health systems ready to find out which option their interface layer actually needs can start with the $0 Modernization Assessment. A Technical Demo shows the five-agent lifecycle applied to a real interoperability problem.
FAQs
EMR describes records built for use inside a single practice. EHR describes records built to move between providers, which is why interoperability is discussed almost entirely in EHR terms.
HL7 v2 is a decades-old, loosely structured messaging standard still used for real-time clinical data inside most hospitals. FHIR is a modern, RESTful API standard used mainly for patient-facing and payer-facing data access.
Timelines vary by scope. Assessment and documentation of an existing interface layer typically completes in 2 to 5 days, and modernization then proceeds roughly 50 to 70 percent faster than a manual rebuild.
Only partially. A FHIR facade satisfies external access requirements but leaves the undocumented routing logic and audit trail gap underneath it unresolved, which is exactly what an information-blocking inquiry examines.
References
[1] ONC/ASTP. Interoperable Exchange of Patient Health Information Among U.S. Hospitals, 2023
[2] AHRQ. Interface Engines
[3] Federal Register. 21st Century Cures Act: Establishment of Disincentives for Health Care Providers That Have Committed Information Blocking
[4] Alston & Bird. Information Blocking Enforcement in 2026
[5] Becker’s Hospital Review. What’s New With TEFCA in 2026: 3 Updates
