Most healthcare organizations already have dozens of systems that hold patient data. EHRs, lab information systems, imaging archives, pharmacy platforms, payer portals, remote monitoring devices, CRMs, care management tools. The problem is not a lack of data. The problem is that these systems do not talk to each other in ways that clinicians and operations teams can actually use. Interoperability in healthcare is not a single API project. It is a data, workflow, standards, governance, and rollout problem. Getting it right requires understanding what the standards actually do, where projects typically break down, and how to structure an implementation that survives contact with real clinical environments.
What interoperability in healthcare actually means
Interoperability is the ability of different health IT systems to exchange, interpret, and use clinical data reliably. That definition sounds simple, but it contains three distinct requirements that are often confused.
Exchange means data moves from system A to system B. This is the part most people think about first: the API call, the HL7 message, the file transfer.
Interpretation means system B can parse the data, match it to the right patient, and understand what the fields mean. A lab result that arrives as a free-text blob inside a generic note field is exchanged but not interpreted.
Use means a clinician, care coordinator, billing analyst, or automated workflow can act on the data without leaving their normal process. If a nurse has to log into a separate portal, copy values into the EHR manually, and then document the source, the organization has exchange but not usability.
According to ONC data from 2023, 70% of non-federal acute care hospitals engaged in all four domains of interoperable exchange: sending, receiving, finding, and integrating electronic health information. But less than half (43%) routinely engaged in all four. And while 71% of hospitals routinely had access to necessary outside clinical information at the point of care, only 42% reported that clinicians often used it when treating patients.
That gap between "data is technically available" and "clinicians actually use it" is where most interoperability investments either pay off or waste money.
The systems involved are broad. Common integration targets include:
- Electronic health records (Epic, Cerner/Oracle Health, MEDITECH, athenahealth, and others)
- Laboratory information systems
- Radiology and imaging (PACS, RIS)
- Pharmacy and medication management
- Payer and claims platforms
- Patient portals and mobile apps
- Remote patient monitoring and wearable devices
- Care management and population health tools
- Revenue cycle and billing systems
- CRM and patient engagement platforms
If data arrives late, unstructured, unmapped, or outside the clinician workflow, the organization is still not meaningfully interoperable.
FHIR, HL7, USCDI, and APIs: how the standards fit together
Healthcare standards are confusing because the same organization, HL7 International, is responsible for several generations of standards that still run in production today.
HL7 v2 is the workhorse of hospital integration. It has been in use since the late 1980s and remains the most widely deployed messaging standard in acute care. HL7 v2 messages handle event-driven workflows: ADT (admit, discharge, transfer), ORM/OML (orders), ORU (results), SIU (scheduling), and others. Most integration engines in hospitals process thousands of v2 messages per day. The format is pipe-delimited, segment-based, and highly customizable, which is both its strength and its weakness. Two hospitals running "HL7 v2 ADT feeds" may have very different segment structures, field mappings, and local extensions.
CDA (Clinical Document Architecture) is a document-oriented XML standard. It appears most often in Continuity of Care Documents (CCDs) and in legacy health information exchange. CDA is structured but heavy, and adoption has been uneven.
FHIR (Fast Healthcare Interoperability Resources) is the modern standard. FHIR models clinical data as discrete resources (Patient, Observation, Medication, Condition, Encounter, AllergyIntolerance, and many others) and exposes them through RESTful APIs using JSON or XML. FHIR is designed for web and mobile developers, supports granular data access, and has a growing ecosystem of implementation guides.
USCDI (United States Core Data for Interoperability) defines the common data classes and elements that certified health IT must support in the U.S. It includes demographics, problems, medications, allergies, lab results, vital signs, clinical notes, and other categories. USCDI is updated periodically to expand the required data set.
US Core Implementation Guide translates many USCDI requirements into FHIR. According to HL7's US Core IG documentation, US Core is based on FHIR R4, defines minimum constraints on FHIR resources to create US Core Profiles, and documents minimum FHIR RESTful interactions for accessing patient data. It acts as a floor for U.S. FHIR interoperability while allowing specific use-case guides to build on top.
Regulatory pressure is real. The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) requires impacted payers to implement and maintain HL7 FHIR APIs, including Patient Access API updates, Provider Access API, Payer-to-Payer API, and Prior Authorization API. Required standards include USCDI, FHIR R4.0.1, US Core IG STU 3.1.1, SMART App Launch, Bulk Data Access, and OpenID Connect. API compliance dates generally begin January 1, 2027, with operational prior authorization requirements starting January 1, 2026.
It is worth being direct about FHIR's limitations. FHIR provides a standard resource model and API pattern, but it does not solve patient matching, terminology mapping, consent management, data quality, security architecture, or operational monitoring. Those problems exist regardless of which standard you use.
Where interoperability projects usually fail
After working on healthcare software development projects across different system environments, the failure patterns become predictable.
Starting with the integration engine before defining the clinical workflow. Teams buy or configure an interface engine, connect two systems, and declare success. Then they discover that the data lands in a tab clinicians never open, or that the workflow requires a round-trip confirmation that was never built. The integration works. The workflow does not.
Assuming vendor APIs mean the needed fields are available in the right format. EHR vendors publish API documentation, but the data available through those APIs depends on how the organization has configured the system, what modules are licensed, and what data clinicians actually enter. A FHIR Observation endpoint exists, but the specific LOINC-coded lab results your workflow needs may not be populated.
Treating patient matching as a minor detail. Without a reliable way to match patients across systems, every integration becomes a source of mismatched records, duplicate charts, and clinical risk. Patient matching is hard because names change, identifiers differ across systems, demographics contain errors, and there is no universal patient ID in the U.S.
Ignoring terminology mapping. System A uses local lab codes. System B expects LOINC. The problem list uses ICD-10 in one system and SNOMED CT in another. Medications reference NDC codes in pharmacy but RxNorm in the EHR. Without a deliberate terminology mapping strategy, data arrives but cannot be interpreted.
Building one-way exchange where clinicians cannot act on the data. Sending a referral notification is not the same as closing the referral loop. Pushing lab results is not useful if the ordering provider cannot review, acknowledge, and act on them within their workflow.
No ownership for failed messages, queue backlogs, stale data, consent exceptions, and audit evidence. Integration is an ongoing operational responsibility. Messages fail. Queues back up. Source systems change field formats without warning. Someone needs to own monitoring, alerting, exception handling, and resolution.
Security and compliance added late. HIPAA, state privacy laws, consent requirements, minimum necessary data rules, and audit logging need to be designed into the integration from the start. Retrofitting access controls and encryption onto a working integration is expensive and error-prone. If you are building in a regulated environment, HIPAA compliance should be part of the architecture, not a review checkpoint at the end.
How to implement interoperability in healthcare
A practical implementation follows a phased approach. Skipping phases is the most common source of rework.
Phase 1: Choose the use case and workflow first
Do not start with "we need interoperability." Start with a specific clinical or operational workflow that is broken or manual today. Examples:
- Referral loop closure between primary care and specialists
- Lab results flowing into the EHR with structured review and acknowledgment
- Remote patient monitoring data reaching care management teams with alerts
- Payer prior authorization with electronic status updates
- Patient portal access to visit summaries, lab results, and medication lists
- Hospital inventory and supply chain connected to clinical operations
Define who does what, when, and in which system. Document the current state and the target state.
Phase 2: Inventory systems, data owners, and constraints
For every system involved, document:
- System name, version, and vendor
- Available integration methods (HL7 v2 feeds, FHIR APIs, proprietary APIs, database access, flat files)
- Data elements available and their format
- Data owners and governance contacts
- Vendor limitations, licensing requirements, and support responsiveness
- Consent and authorization requirements
- BAA status and security posture
- Uptime requirements and maintenance windows
This inventory often reveals surprises. A system you assumed had a modern API may only support batch file exports. A vendor may require a paid integration module. A data owner may not have authority to share certain fields.
Phase 3: Define the canonical data model and terminology plan
Decide which data elements matter for your workflow. Map local fields from each source system to a common model. Choose your terminology standards (LOINC for labs, SNOMED CT for problems, ICD-10 for diagnoses, RxNorm for medications, CPT for procedures). Document every transformation, including edge cases and defaults for missing data.
This is tedious work. It is also where data quality is won or lost.
Phase 4: Select integration architecture
The right architecture depends on the use case, scale, and long-term roadmap.
- Point-to-point APIs work for narrow, well-defined connections between two systems. They are simple but do not scale.
- Integration engine / interface engine (Mirth Connect, Rhapsody, InterSystems HealthShare, and others) handles HL7 v2 message routing, transformation, and monitoring. This is the standard approach for hospital ADT, orders, and results.
- FHIR server / API layer provides reusable, standards-based data access for multiple consumers. This is the right choice when you need to serve data to apps, portals, payer APIs, and analytics.
- Event-driven architecture (message queues, pub/sub) works well for real-time notifications and decoupled systems.
- Data warehouse / data lake supports analytics, reporting, and population health. Be clear: analytics pipelines do not replace operational interoperability. A data warehouse that refreshes nightly cannot support a real-time clinical workflow.
Many organizations need a combination. A hospital might use an interface engine for HL7 v2 ADT and results, a FHIR API layer for patient portal and app access, and a data warehouse for quality reporting.
Phase 5: Build security and compliance into the flow
- Implement OAuth 2.0 and SMART on FHIR for app authorization where applicable
- Enforce role-based and attribute-based access control
- Encrypt data in transit (TLS) and at rest
- Log every data access and exchange event for audit
- Handle patient consent programmatically, especially for sensitive categories (behavioral health, substance use, reproductive health)
- Apply minimum necessary data principles: do not send entire patient records when the workflow needs three fields
- Build retry logic, dead-letter queues, and alerting for failed exchanges
- Plan for backup and disaster recovery of integration infrastructure
Phase 6: Pilot with one workflow
Deploy the integration for a single site, department, or provider group. Measure:
- Data completeness and accuracy
- Latency (time from source event to data availability in the target system)
- Exception and error rates
- Clinician adoption (are they actually using the data?)
- Operational support burden (how many tickets, manual fixes, and escalations?)
Adjust mapping, error handling, and workflow design based on what you learn.
Phase 7: Scale only after support processes exist
Before expanding to additional sites, workflows, or systems, confirm that you have:
- Monitoring dashboards and alerting
- On-call support for integration failures
- Documented runbooks for common error scenarios
- A change management process for source system upgrades and configuration changes
- Governance for adding new data elements or connections
This phased approach applies whether you are connecting two systems or building a platform that serves dozens of downstream consumers. The RAE Health project is a useful example. It connected mobile patient data (event detection, calendar, breathing exercises), wearable signals, caregiver and provider visibility through RAE Connect, and a web clinical portal with analytics-oriented workflows, all on an AWS backend over a 24-month-plus engagement. The reason that kind of system holds together is that the integration design follows the clinical and caregiver workflows instead of treating data feeds as the whole job. That distinction matters more than the choice of any particular standard or tool.
Build, buy, or customize: choosing the right path
Off-the-shelf connectors fit standard EHR/payer/lab use cases when the workflow is common and vendor support is mature. If you need Epic-to-lab results using a well-documented interface, a pre-built connector with configuration may be the fastest path. Expect weeks for setup and testing.
Customize when your workflow, data mapping, patient identity logic, or operational rules differ from what the default connector assumes. Most real-world projects land here. The connector handles transport and basic parsing; your team handles mapping, error handling, consent logic, and workflow integration. Timeline: one to three months for a single workflow, depending on complexity.
Build a custom integration or API layer when interoperability is central to your product, when multiple downstream systems depend on it, or when you need full control over data quality, audit, resilience, and roadmap. This is common for custom software development in health tech products, multi-facility health systems with non-standard workflows, and organizations building platforms that serve external partners. Timeline: several months for initial build, with ongoing maintenance as a permanent operational cost.
Regardless of the path, budget for ongoing maintenance. Source systems change. Standards evolve. Vendor APIs get versioned. Regulations add new requirements. Interoperability is not a project with a fixed end date.
A practical implementation checklist
Before starting or evaluating an interoperability initiative, confirm that you have clear answers for each of these:
- Workflow definition: Which clinical or operational workflow are you enabling? Who are the users? What do they need to see, do, and confirm?
- System inventory: What systems are involved? What integration methods do they support? What are the vendor constraints?
- Data model: What data elements does the workflow require? How are they represented in each source system? What is the canonical model?
- Standards: Which standards apply (HL7 v2, FHIR, CDA, USCDI, US Core)? Are there regulatory requirements driving standard selection?
- Terminology: How will you map between local codes and standard terminologies (LOINC, SNOMED CT, ICD-10, RxNorm)?
- Patient matching: How will you match patients across systems? What is the fallback when automated matching fails?
- Security and compliance: How are authentication, authorization, encryption, audit logging, and consent handled?
- Testing: How will you validate data accuracy, completeness, and latency? Do you have test environments for each connected system?
- Monitoring and alerting: How will you detect failed messages, queue backlogs, and data quality issues in production?
- Support and operations: Who owns the integration in production? What are the escalation paths? What are the SLAs?
- Governance: Who approves changes to mappings, data elements, or connected systems? How are new integration requests prioritized?
If any of these are blank, address them before writing code. The cost of fixing a workflow mismatch or a missing terminology map after go-live is significantly higher than getting it right during planning. For teams looking to streamline clinical processes alongside their integration work, healthcare workflow automation is a related topic worth reviewing.
