Short answer: a hospital runs dozens of systems, and integration is the work of making them agree about one patient. At the centre sits the HIS (hospital information system) or EHR, which owns the patient's identity, admissions and the clinical record. Around it: the laboratory system (LIS), radiology (RIS and PACS), pharmacy, theatre, emergency, billing, devices (monitors, infusion pumps), and increasingly patient apps, wearables and telemedicine. An interface engine in the middle receives, transforms and routes messages, so that each system is connected once rather than to every other. The traffic is mostly HL7 v2 messages over MLLP for events (admissions, orders, results), DICOM for images, CDA or PDF for documents, and FHIR over REST for anything new, patient-facing or external.
The systems and what they exchange
A hospital's integration landscape is made of the HIS or EHR, which owns patient identity, encounters and the clinical record, plus the laboratory system, radiology (RIS and PACS), pharmacy, devices, patient apps, telemedicine and regional systems. They exchange HL7 v2 messages such as ADT, orders and ORU results, DICOM images, CDA documents and FHIR resources.
| System | Owns | Sends | Receives |
|---|---|---|---|
| HIS / EHR | Patient identity, encounters, orders, the clinical record | ADT (admissions, transfers), ORM/OML orders, SIU scheduling | ORU results, MDM documents, DFT charges |
| LIS (laboratory) | Specimens, analyses, results, reference ranges | ORU^R01 results, ORR order responses | ORM/OML orders, ADT for demographics |
| RIS / PACS | Imaging orders, worklists, reports, images | ORU reports, DICOM to viewers, SIU | ORM/OMI orders, ADT; DICOM MWL to modalities |
| Pharmacy | Formulary, dispensing, stock | RDS dispense, RAS administration | OMP/RDE medication orders, ADT |
| Devices and monitors | Vital signs, waveforms, alarms | ORU^R01 observations (IHE PCD), proprietary | ADT for patient context |
| Patient portal / apps | Patient-entered data, access | FHIR Observations, questionnaires, messages | FHIR read of results, appointments, documents |
| Telemedicine | Video visits, remote monitoring | FHIR Encounter, Observation, DocumentReference | Appointment, Patient context, SMART launch |
| Regional and national systems | Shared records, registries, e-prescription | CDA documents (XDS), FHIR, national messages | Queries, notifications |
The interface engine
An interface engine is the hospital's messaging hub: it receives HL7 v2, FHIR, file and database traffic from each system, transforms and routes it to every other system that needs it, and keeps queues, retries, monitoring and audit. Without one, N systems need up to N×(N−1)/2 hand-built interfaces; with one, each system connects once.
The engine (Mirth Connect / NextGen Connect, Rhapsody, InterSystems HealthShare and IRIS for Health, Infor Cloverleaf, Qvera QIE, among others) provides listeners (MLLP, HTTP, file, database), transformations (map fields, fix codes, convert v2 to FHIR), routing (send an ADT to eight systems with eight filters), queuing and retries, monitoring and audit. It is also where patient identity is reconciled when systems disagree, and where a FHIR facade is often built over a legacy database. See Interface engines explained.
The flows that matter most
The hospital integration flows that matter most are ADT (admissions, discharges, transfers and demographic updates fanned out from the HIS), orders and results between the EHR and the laboratory or radiology, medication orders and dispensing, documents such as discharge letters, device data from monitors, and patient-facing exchange of results, appointments and home measurements over FHIR.
- ADT: every admission, discharge, transfer, registration and demographic update (A01, A03, A02, A04, A08, A40 merge) fans out from the HIS to everyone else. If ADT is late or wrong, every downstream system files data under the wrong patient or encounter. See HL7 v2 messages explained.
- Orders and results: ORM/OML out, ORU back, with placer and filler numbers tying them together; LOINC and UCUM in the results. See HL7 v2 order messages and Integrating a laboratory system with an EHR.
- Imaging: orders to the RIS, DICOM worklists to the scanners, images to the PACS, reports back as ORU, viewers through DICOMweb. See PACS vs RIS vs VNA.
- Medication: orders to pharmacy, dispensing and administration back, with the closed loop (barcode at the bedside) as the safety goal.
- Documents: discharge letters, operative notes and scanned documents as MDM messages, CDA or PDFs into a document repository, published to regional registries.
- Devices: monitors feeding vital signs into the record through IHE PCD profiles or vendor gateways, with alarm management as a separate discipline.
- Patient-facing: results, appointments and documents to the portal and apps over FHIR; questionnaires, home measurements and wearable data back in, with provenance marking them as patient-reported. See Remote patient monitoring with FHIR.
Patterns that work
Hospital integration patterns that work are: one master system for patient identity, with everyone else subscribing to ADT; code mapping to LOINC, SNOMED CT and ATC once at the engine; acknowledgements, queues and retries for every message; idempotent results and documents; a FHIR layer for patient apps and external partners; and test environments with synthetic patients before go-live.
- One master for identity. The HIS (or a master patient index) owns identifiers; everyone else subscribes to ADT and never invents patients.
- Codes at the boundary. Map local codes to LOINC, SNOMED CT, ATC at the engine, once, and keep the local code alongside.
- Acknowledge, queue, retry. Every v2 message gets an ACK; the engine persists and replays; nobody loses a result because a system was rebooting.
- Idempotency. Results and documents carry identifiers; a replay updates rather than duplicates.
- A FHIR layer for everything new. Patient apps, telemedicine, research extracts and external partners talk FHIR to a facade or a dedicated FHIR server fed from the internal flows, rather than to the HIS directly.
- Test environments with synthetic patients, and a conformance step (IHE Connectathon profiles, national test suites) before anything touches production.
Failure modes seen everywhere
The failure modes seen in almost every hospital integration are duplicate patients from registration typos, results filed to the wrong encounter after a merge, unmapped local codes, time-zone and daylight-saving errors in timestamps, free-text units, interfaces that stop silently without monitoring, vendor Z-segments that break parsers, and temporary CSV feeds that never get retired.
Duplicate patients from registration typos; results filed to the wrong encounter after a merge; local test codes nobody mapped; time zones and daylight saving in message timestamps; free-text units; an interface that silently stopped and nobody monitored; vendor-specific Z-segments that break parsers; and the "temporary" CSV feed that is still running ten years later.
Where FHIR is changing the picture
FHIR is changing hospital integration at the edges rather than the core. Inside the building, HL7 v2 and DICOM remain because analysers, scanners and legacy modules speak them; FHIR takes over patient access, SMART on FHIR apps, CDS Hooks decision support, Subscriptions, regional and national exchange under the EHDS and TEFCA, and research extracts.
Internally, HL7 v2 and DICOM stay for years, because every analyser, scanner and legacy module speaks them. FHIR wins at the edges: patient access, apps launched inside the EHR (SMART on FHIR), decision support (CDS Hooks), subscriptions for event-driven integration, regional and national exchange under the EHDS and TEFCA, and research extracts. Many hospitals now run a FHIR server fed by the engine as their integration layer for everything outside the building; see Healthcare interoperability standards: the map.
In Anpheros
Anpheros Platform sits at the FHIR edge of hospital integration: a FHIR R4 record that a hospital or clinic can write to and read from with the patient's consent, fed by the hospital's own integration through the lab connector (HL7 v2 ORU, CSV or JSON), with webhooks and provenance per source. It does not replace the HIS or the engine.
Anpheros Platform sits at that edge: a FHIR R4 record a hospital or clinic can write to and read from with the patient's consent, fed by the hospital's own integration (the lab connector takes HL7 v2 ORU, CSV or JSON), with webhooks for change notification and provenance per source. It does not replace the HIS or the engine; it gives the patient a record that follows them out of the building.
Related pages
- Interface engines explained
- How to integrate a laboratory system with an EHR
- HL7 v2 messages explained: ADT and ORU
- PACS vs RIS vs VNA
- Remote patient monitoring with FHIR
- Healthcare interoperability standards: the map
- Integrate clinic systems with FHIR (developer site)
Sources
- HL7 Version 2 product suite
- IHE IT Infrastructure technical framework
- IHE Devices domain (Patient Care Device profiles)
- HL7 FHIR R4: Messaging and workflow
- HL7 v2-to-FHIR implementation guide
Frequently asked questions
Should a new hospital integrate everything with FHIR?
Not everything. Analysers, scanners and most departmental systems speak HL7 v2 and DICOM, and that will not change soon. Use FHIR for patient-facing, external and new integrations, and an engine to bridge.
What is the difference between an HIS and an EHR?
Usage varies by country. HIS often means the administrative and clinical hospital system together; EHR emphasises the clinical record. In integration terms both are the system that owns identity, encounters and the record.
How many interfaces does a mid-sized hospital have?
Typically between fifty and a few hundred message flows through the engine, counting each direction and each receiving system. The engine's monitoring screen is where integration teams live.
Who owns integration in a hospital?
The hospital's IT integration team, usually with the engine vendor's support, and each departmental vendor for its side. National programmes and IHE profiles reduce but do not remove the project work.
Try it free in the sandbox
Your first FHIR call in 5 minutes. An HL7 FHIR R4 API with the patient's consent built in: try it in the sandbox, then connect your own app or clinic system.
Free · 30 synthetic patients · no card
Anpheros builds a medical record that the patient controls and can share with any clinic, on an HL7 FHIR R4 platform, based in the EU. These guides help you understand and organise your health; they do not replace your doctor.
About Anpheros →
AnpherosThe more you log, the clearer your record
Your health history in one place, under your control.
Free · Works in your browser · No card
