Short answer: an interface engine (integration engine) is middleware built for healthcare messaging. It listens on many protocols (MLLP for HL7 v2, HTTP for FHIR and SOAP, files, databases, queues), transforms messages (field mapping, code translation, format conversion such as HL7 v2 to FHIR), routes them to one or many destinations with filters, and keeps queues, retries, logs and dashboards so that a message is never lost and every failure is visible. Hospitals use one so that each system is connected to the engine once instead of to every other system. The well-known products are Mirth Connect (NextGen Connect, historically open source), Rhapsody, InterSystems HealthShare / IRIS for Health, Infor Cloverleaf, Qvera QIE, Orion and a long tail; cloud providers offer managed equivalents.
The building blocks
The building blocks of an interface engine are channels (one flow from a source to its destinations), source connectors or listeners such as MLLP and HTTP, filters that decide whether a message continues, transformers that map fields and codes, destination connectors, queues with retry, monitoring with alerting, and an audit trail of channel changes and message history.
Every engine, whatever the vocabulary, has the same parts:
- Channel (interface): one flow from a source to one or more destinations, with its own settings and statistics.
- Source connector / listener: MLLP (TCP with framing for HL7 v2), HTTP(S) endpoints, SFTP and file polling, database queries, JMS or other queues, DICOM in some products.
- Filter: a rule that decides whether a message continues (only ADT^A01 for this patient class).
- Transformer: scripts or mappings that change the message: rename fields, map local codes to LOINC through a lookup table, build a FHIR Observation from an OBX segment, add a Z-segment a legacy system expects.
- Destination connector: where the result goes, with its own protocol and error handling.
- Queue and retry: messages persist until acknowledged; failures retry with back-off; poison messages land in an error queue for humans.
- Monitoring and alerting: per-channel counters, latency, error rates, alerts when a channel goes quiet (the most useful alert in healthcare integration).
- Audit: who changed which channel, and the message history for troubleshooting, with retention and access controls because it is patient data.
Typical jobs
The typical jobs of a healthcare interface engine are ADT fan-out from the HIS to departments, routing laboratory results to several receivers, translating local codes to LOINC, ATC and UCUM, bridging HL7 v2, FHIR, CDA and CSV formats, exposing a FHIR facade over a legacy database, normalising device feeds, and adapting MLLP inside to HTTPS outside.
- ADT fan-out: receive admissions from the HIS, filter and translate per department, deliver to lab, radiology, pharmacy, bed management and the patient portal.
- Results routing: ORU from the LIS to the EHR, to the ordering GP's system, to the regional record, to the patient's FHIR record, each with a different subset and format.
- Code translation: local test codes to LOINC, local drug codes to ATC, free-text units to UCUM, through maintained lookup tables (mapping lab codes to LOINC).
- Format bridging: HL7 v2 to FHIR and back, CDA to FHIR, CSV from an old system to anything.
- A FHIR facade: the engine exposes FHIR endpoints and answers them by querying the legacy database or sending v2 queries, so apps see a FHIR server where none exists.
- Device integration: proprietary monitor feeds normalised to IHE PCD observations.
- Protocol adaptation: MLLP inside the building, HTTPS with OAuth to the outside.
Choosing one
Choosing an interface engine comes down to six criteria: message volume and how critical latency and outages are, the protocols and standards supported out of the box (HL7 v2, FHIR R4, DICOM, national formats), developer experience, operations such as clustering and failover, licensing terms, which changed for some products in 2025, and the skills available to maintain channels.
- Volume and criticality: messages per day, acceptable latency, and whether a two-minute outage matters (it does for ADT and results).
- Protocols and standards out of the box: HL7 v2 versions and parsers, FHIR R4 support with validation, DICOM, X12 in the US, national formats.
- Developer experience: scripting language (JavaScript in Mirth, proprietary in others), version control of channel definitions, test tooling, deployment to several environments.
- Operations: clustering, failover, monitoring integrations, upgrade path, support model.
- Licensing: open source or community editions, subscription per channel or per core, managed cloud offerings; licensing of some historically open products changed in 2025, so check the current terms.
- Skills available: the engine is only as good as the people who maintain the channels.
Running one safely
Running an interface engine safely means treating channel definitions as code under version control, testing with synthetic messages before production, governing code lookup tables with named owners, alerting when a channel goes silent, restricting and purging message history because it is patient data, documenting every channel's purpose, and never letting the engine become the system of record.
Treat channel definitions as code: in version control, reviewed, deployed through test and staging with synthetic messages. Keep lookup tables (code maps) under governance with owners. Set alerts on silence, not only on errors. Restrict access to message history, which is patient data, and purge it on a schedule. Document every channel's purpose and owner; the undocumented channel is the one that stops a department when its author leaves. And never let the engine become the system of record: it moves and transforms data, it does not own it.
When you do not need one
An interface engine is not needed when a greenfield system's partners all speak FHIR, in which case a FHIR server with Subscriptions and an API gateway cover routing and authentication, or when a single HL7 v2 interface can be handled by a library such as HAPI HL7v2 or hl7apy. The engine earns its place with many systems and formats.
A greenfield system whose partners all speak FHIR can use a FHIR server with Subscriptions and an API gateway for authentication, rate limiting and routing, with transformations in ordinary services. A single HL7 v2 interface can be handled by a small library (HAPI HL7v2 in Java, hl7apy or python-hl7 in Python) inside the application. The engine earns its place when there are many systems, many formats and the need for an operations console that non-developers can watch.
In Anpheros
Anpheros Platform is on the FHIR side of the engine: hospitals route the flows they want to share (results, documents, encounters) to it through their engine or through the lab connector, and read back through FHIR APIs and webhooks. The developer site shows the HL7 v2 to FHIR mapping the connector applies.
Related pages
- Hospital system integration explained
- How to integrate a laboratory system with an EHR
- HL7 v2 messages explained: ADT and ORU
- How to map local lab codes to LOINC
- FHIR Subscriptions explained
- HL7 v2 to FHIR mapping (developer site)
Sources
- NextGen Connect (Mirth Connect)
- Rhapsody Integration Engine
- InterSystems IRIS for Health
- Infor Cloverleaf
- HAPI HL7v2 library
- HL7 v2-to-FHIR implementation guide
Frequently asked questions
Is an interface engine the same as an ESB or an iPaaS?
Same family, specialised: an interface engine ships with HL7 v2, DICOM, CDA and FHIR support, MLLP, healthcare-specific monitoring and the vocabulary integration teams use. General ESBs and iPaaS products can do the job with more building.
Can the engine convert HL7 v2 to FHIR automatically?
Several engines include mappings based on the HL7 v2-to-FHIR guide, and they handle the common segments. Local conventions, Z-segments and code mapping always need project work.
Does the engine store patient data?
It persists messages in transit and keeps message history for troubleshooting, which is patient data and must be protected and purged. It should not be used as a long-term store or a system of record.
Open source or commercial?
Both are in production in large hospitals. The decision usually turns on support, skills, clustering needs and the current licensing terms, which have changed for some products; check before committing.
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
