How to Solve Interoperability Challenges in Healthcare Systems

Key Takeaways

• The API is the beginning, not the answer: Adopting FHIR or HL7 standards closes the technical gap, but interoperability fails when the organizational and regulatory layers underneath remain broken.
• Access and use are two different problems: Most hospitals can now exchange clinical data. The harder gap is that clinicians routinely use it at the point of care far less often than the data is available.
• Information blocking is still an active barrier: The 21st Century Cures Act made interoperability the legal default, but enforcement, governance, and awareness of exceptions are still catching up in many systems.
• Interoperability enables everything else: AI, automation, and real-time decision support in healthcare only work as well as the data fabric they draw from. Fragmented records produce fragmented results.

Progress on Paper, Friction in Practice

Healthcare has made real headway on the formal side of interoperability. According to research from the Assistant Secretary for Technology Policy at HHS, routine hospital engagement in all four core interoperability domains, namely sending, receiving, finding, and integrating patient health information, grew by more than half between 2018 and 2023. That is not a trivial improvement.

But the same research also documents a stubborn gap between access and actual use. Roughly seven in ten hospitals can routinely access clinical information from outside providers. Less than half of clinicians routinely use that information at the point of care. Data is technically available. It is not reliably reaching the decisions that matter most.

The gap between access and use points to something the standards discussion tends to miss. Interoperability is not one problem. It is three overlapping problems at different layers of the healthcare system. Each layer has its own root cause and its own fix. Addressing the technical layer without the organizational and regulatory layers beneath it explains why so many well-funded interoperability programs still leave clinicians entering the same information in two places.

Layer One: Standards Fragmentation and API Immaturity

The technical layer is the most visible. Healthcare data is generated and stored across a wide range of systems: electronic health records, laboratory systems, imaging platforms, pharmacy networks, payer claim systems, and an expanding category of patient-generated data from devices and apps. These systems were built at different times, by different vendors, using different data models.

HL7 version 2 messages and Clinical Document Architecture formats remain the dominant exchange standards across most health information exchanges because they have decades of installed infrastructure behind them. FHIR APIs, which enable more granular, query-based data access and better interoperability with modern applications, are still the minority path for most data flows. ONC data on hospital API use shows that while patient-facing FHIR API access has grown significantly, most third-party clinical data integrations still rely on non-standards-based approaches.

The practical fix at this layer is incremental modernization of the data exchange path. Wrapper APIs that expose legacy system data in FHIR format without requiring full EHR replacement. Canonical data models that normalize the most clinically critical fields before they move between systems. Event-driven integration patterns for real-time exchange where latency matters, and batch patterns where it does not. Each of these moves reduces the standards fragmentation without requiring every system to change at once.

Layer Two: Organizational Silos and Incentive Misalignment

The organizational layer is less visible and harder to fix with architecture alone. Healthcare organizations share data according to their incentives, their governance structures, and the clarity of their data ownership rules. Where those incentives push against sharing, technical standards do not override them.

A few patterns repeat across organizations. Different departments treat patient records as locally owned assets rather than shared clinical resources. Staff are trained on department-level workflows, not on cross-system data retrieval. Data quality accountability is unclear, which means inconsistent records circulate and clinicians learn to distrust data from outside their own system. Integration projects are initiated channel by channel, leaving a different data picture in each downstream system.

The fix at this layer requires governance before architecture. A data stewardship model that assigns clear ownership and quality accountability for each data domain. Patient identity management that resolves the same person across multiple systems reliably. Cross-functional teams that include clinical informatics, IT, compliance, and frontline users in integration decisions, not just after deployment. And metrics tied to actual use at the point of care rather than to system-level availability, which is what most interoperability programs currently measure.

Ciklum's analysis on AI working across the healthcare workflow makes the underlying dependency clear: comprehensive data cleansing and governance is a prerequisite for AI to produce reliable results in healthcare settings. The same principle applies to interoperability generally. Clean, consistently governed data that travels with a reliable patient identity is the foundation. Everything else is built on top of it.

Layer Three: Information Blocking and Regulatory Friction

The regulatory layer adds a third dimension that pure engineering cannot address. The 21st Century Cures Act established a legal framework that treats information sharing as the expected default and information blocking as a prohibited practice subject to significant penalties. The ONC information blocking framework defines blocking broadly: any practice by a covered actor that interferes with the access, exchange, or use of electronic health information, unless a defined exception applies.

The framework matters because some of the barriers to interoperability are not technical or organizational. They are deliberate. Proprietary data formats that make migration difficult, contractual restrictions on data portability, and fee structures that effectively price out smaller health information networks all fall within the scope of what the law now targets.

For healthcare technology and compliance teams, the practical work at this layer involves three things. First, auditing current data-sharing practices against the information blocking exceptions to understand which restrictions are legally protected and which are not. Second, participating in the Trusted Exchange Framework and Common Agreement, which ONC established to create a common floor of trust and interoperability across networks. Third, building legal and compliance teams into the interoperability roadmap from the start rather than treating them as reviewers after the fact.

What This Looks Like in Practice

Both layers of the problem, technical and organizational, show up in concrete engineering work.

One of the world's largest medical device companies, a global medtech organization operating in more than 150 countries, faced a version of the organizational layer problem at scale. The absence of a centralized, integrated platform limited order efficiency, tracking, and engagement across healthcare providers and partners. Working with Ciklum, the company built Salesforce-based commerce portals integrated with ERP and payment systems, creating a unified data flow across ordering, fulfillment, and real-time tracking. The interoperability challenge here was not clinical record exchange. It was the same structural problem: data fragmented across systems, no shared identity for the interaction, and no connective layer that let the right information reach the right person at the right time.

A major UK pharmaceutical company showed the same dependency at the data layer. Legacy audit analytics relied on manually assigned event categories, which introduced errors that undermined leadership decisions. Ciklum built a machine learning pipeline that analyzed more than 400,000 audit findings, using unsupervised learning to assign accurate, context-driven category tags. The value of the AI model depended entirely on data that was structured, consistently labeled, and traceable. Without that foundation, no amount of modeling sophistication would have produced reliable results. It is the same logic that applies to clinical interoperability: the insight layer only works as well as the data layer it sits on.

Ciklum's analysis on intelligent process automation in healthcare points to where automation compounds the interoperability dividend. When data flows reliably between systems, automation can take over the repetitive data entry, reconciliation, and reporting tasks that currently absorb clinical staff time. Without consistent data exchange, automation creates efficiency in one system while leaving the problem of reconciliation to human effort at the boundary.

In Summary

Healthcare interoperability fails most often not because the standards are wrong or the APIs are missing. It fails because the three layers of the problem are addressed out of sequence or in isolation. The technical layer, standards fragmentation and API immaturity, is the most tractable but the least sufficient. The organizational layer, data governance, patient identity, and incentive misalignment, is where most programs quietly stall. The regulatory layer, information blocking practices, TEFCA participation, and compliance clarity, is the least visible but increasingly the most consequential.

Progress requires all three addressed together, with governance established before integration, and clinical use rather than technical availability used as the measure of success. That sequencing matters because each layer depends on the one beneath it. Connecting systems through modern APIs without resolving patient identity produces fast exchange of unreliable records. Resolving identity without governing data quality shifts the bottleneck from connection to trust. And governing data well without aligning on information blocking and regulatory obligations creates legal exposure that slows the program down later.

The organizations that move fastest on interoperability tend to treat it as a continuous operating discipline rather than a project with a go-live date. They track whether data is actually being used at the point of care, not just whether it is technically available. They resurface governance and identity questions each time a new system is integrated. And they involve compliance, clinical informatics, and engineering in the same decision forum rather than routing their work sequentially. None of this is architecturally complex. Most of it is disciplinary.

Frequently Asked Questions

1. What is the biggest barrier to healthcare interoperability in practice?

For most organizations, it is the organizational layer rather than the technical one. Data is technically available to exchange in many systems. The barriers are inconsistent patient identity resolution across systems, unclear data quality ownership, clinical staff trained on departmental rather than cross-system workflows, and metrics that measure API availability rather than clinician use at the point of care.

2. Is FHIR the answer to interoperability?

FHIR is a significant improvement over earlier standards because it enables more granular, query-based data access and aligns better with modern API conventions. But standards adoption alone does not produce interoperability. The same data fragmentation, identity inconsistency, and governance gaps that exist in HL7 v2 environments can exist in FHIR environments if the organizational layer is not addressed.

3. What does the 21st Century Cures Act require healthcare organizations to do?

The Act and ONC's information blocking rule establish that sharing electronic health information is the legal default. Covered actors, including healthcare providers, certified health IT developers, and health information networks, are prohibited from interfering with access, exchange, or use of electronic health information except under defined exceptions. Organizations need to audit their current practices against those exceptions to understand which data restrictions are permitted and which are not.

4. When does AI add value in healthcare interoperability?

AI adds value when the data layer is clean and consistently governed. Models that read from fragmented, inconsistently labeled, or identity-unresolved records produce unreliable outputs that clinicians learn to distrust. Fixing the interoperability foundation first is not a prerequisite that delays AI adoption. It is what makes AI adoption produce durable results rather than well-funded pilots.