Healthcare organisations run on data. A patient's journey through a hospital involves laboratory results flowing from the LIS to the EHR, medication orders moving from the prescribing system to pharmacy, images acquired by radiology equipment and routed to PACS for reading, and demographic updates propagating across every system that holds a record. When these data flows work reliably, clinical care is supported. When they break, the consequences range from inefficiency (manual re-entry of data) to genuine clinical risk (delayed results, missing allergy information, incorrect patient matching).
Integration is not a project — it is an ongoing engineering discipline. This guide covers the core concepts, patterns, and technologies that underpin reliable healthcare system integration.
Why Healthcare Systems Need Integration
Healthcare IT environments are inherently heterogeneous. No single vendor provides every system a healthcare organisation needs. The EHR, the laboratory information system, the radiology PACS, the pharmacy system, the patient administration system, the billing platform, and the medical devices on the ward floor are typically from different vendors, running on different technology stacks, and designed to different standards.
Without integration, data lives in silos. A clinician reviewing a patient in the EHR cannot see laboratory results that have not been manually entered. A pharmacist does not receive electronic orders. A discharge summary cannot be generated from structured clinical data because it does not exist in one place. Multiply this across hundreds of patients and dozens of care settings, and the operational and clinical cost of fragmented data is enormous.
Integration Patterns
Three architectural patterns are used in healthcare integration:
Point-to-Point Integration
In point-to-point integration, each system connects directly to every other system it needs to exchange data with. For an environment with five systems, this means up to ten connections. For twenty systems, potentially hundreds.
Point-to-point integration is simple to implement for a single connection but does not scale. Each connection is unique, requires its own maintenance, and is affected when either endpoint changes. Healthcare organisations that have grown organically over many years frequently have a tangle of undocumented point-to-point connections that nobody fully understands. When a system is upgraded, it is impossible to predict which connections will break.
Hub-and-Spoke with an Integration Engine
An integration engine (also called an interface engine or middleware) sits at the centre of the integration architecture. Each system connects to the integration engine, not directly to other systems. The integration engine receives messages, transforms them as required, routes them to the correct destination systems, and provides monitoring and error handling for all message flows.
This pattern dramatically reduces connection complexity, centralises monitoring, and makes it possible to add or remove systems without rebuilding every connection. When a new laboratory system is installed, only the integration to the engine needs to be built — not a new connection to every downstream system.
Widely used integration engines in healthcare include Mirth Connect (open-source, widely deployed globally), Rhapsody (Orion Health), Microsoft BizTalk (older enterprise environments), and Azure Integration Services (for cloud-native or hybrid architectures). The choice of engine depends on the organisation's technical environment, internal capability, and budget.
API-First Integration
Modern healthcare systems increasingly expose APIs — typically RESTful HTTP APIs aligned to HL7 FHIR standards — that allow other systems to query or post data programmatically. API-first integration is the direction of travel for the industry, driven by regulatory mandates (CMS Interoperability Rule in the US), clinical data sharing requirements, and the growth of patient-facing digital health applications.
API-first integration coexists with integration engine-based messaging rather than replacing it. Legacy systems that communicate via HL7 v2 messages will not be replaced overnight. Effective integration architectures in healthcare typically combine an integration engine for HL7 v2 and traditional messaging workloads with FHIR API endpoints for modern interoperability use cases.
HL7 FHIR
FHIR (Fast Healthcare Interoperability Resources), developed by HL7 International, is the current generation interoperability standard for healthcare data exchange. FHIR R4 is the stable release in widest deployment.
FHIR represents clinical concepts as resources: Patient, Observation, Encounter, DiagnosticReport, MedicationRequest, Condition, Procedure, and so on. Each resource has a defined structure (JSON or XML) and can be created, read, updated, or deleted via standard RESTful HTTP operations.
FHIR APIs have become the standard interface for patient-facing applications, care coordination platforms, and clinical data exchange networks. The US 21st Century Cures Act mandates that EHRs expose FHIR R4 APIs for patient data access. Internationally, adoption is growing rapidly, with national programmes in Australia, the UK, Canada, and others building on FHIR foundations.
Common Healthcare Integration Use Cases
ADT (Admit-Discharge-Transfer) events: Patient registration, admission, discharge, and transfer events generated by the Patient Administration System (PAS) need to flow to all systems that maintain a patient record. A patient who is admitted should appear in the EHR, the pharmacy system, and the laboratory system simultaneously. Missed ADT messages cause patient registration errors, result routing failures, and billing problems.
Laboratory results: Results generated in the Laboratory Information System (LIS) must be delivered to the ordering clinician's system promptly and matched accurately to the correct patient and order. HL7 ORU (Observation Result Unsolicited) messages carry results in traditional v2 messaging. FHIR DiagnosticReport and Observation resources carry results in FHIR-based exchanges.
Medication orders: Electronic prescribing generates orders that must be routed to pharmacy for dispensing. HL7 RXO and RXE message types are used in v2 environments; FHIR MedicationRequest resources in FHIR environments.
Radiology orders and results: Orders sent from clinical systems to radiology worklists (typically via DICOM Modality Worklist) and completed reports returned to clinical systems (HL7 ORU or FHIR DiagnosticReport).
Data Mapping and Transformation
Healthcare data exchange rarely involves simply passing data from one system to another unchanged. Systems use different code sets for the same concepts — one system may represent blood groups as "A+", another as "A POS". Patient identifier types differ. Date formats differ. Integration engines apply transformation logic to convert data from the format produced by the source system to the format expected by the destination system.
Data mapping should be documented carefully. Undocumented transformation logic is a significant operational risk: when a source system changes its data format, the transformation breaks and the impact may not be immediately apparent if monitoring is inadequate.
Error Handling and Monitoring
Every integration must have error handling and monitoring. Messages fail: a destination system is offline, a message fails validation, a transformation produces unexpected output. Without error handling, messages can be silently lost. A laboratory result that never reaches the EHR because an integration broke silently is a clinical risk.
Integration engines should be configured to:
- Queue messages when destination systems are unavailable and deliver them when connectivity is restored
- Alert operations staff when error rates exceed normal thresholds
- Provide a reprocessing mechanism for messages that failed due to transient errors
- Log all message transactions for audit and troubleshooting
Testing Integration Builds
Integration builds should be tested rigorously before go-live. Testing should include:
- Functional testing: Does each message type produce the correct result at the destination?
- Negative testing: What happens when a message is malformed, when a patient is not found in the destination system, or when the destination system is unavailable?
- Volume testing: Does performance degrade under realistic message volumes during peak periods?
- End-to-end workflow testing: Do complete clinical workflows (admit a patient, order a test, receive a result) work correctly across all integrated systems?
Integration testing is best performed in a dedicated test environment that mirrors production. Testing integration changes in production is not acceptable practice in a clinical environment.
Well-designed integration is invisible to clinical staff — data is where it needs to be, when it needs to be there, without manual intervention. Poorly designed integration is felt through delays, errors, and workarounds that consume clinical time and introduce risk.
FZ Consulting LLP provides healthcare integration design and advisory services. Contact us to discuss your integration architecture or a specific integration challenge.