Interoperability
What is an integration engine in a hospital?
An integration engine is the software in the middle of a hospital's systems. It receives messages and API calls from one system (often HL7 v2 from the patient administration system), checks them, transforms and routes them, and delivers them to the systems that need them, so each system doesn't need its own link to every other.
Why hospitals need one
NHS England points out that the NHS is hundreds of organisations whose staff enter information into systems with different information models, structures and coding. Even inside one hospital, the PAS, EPR, lab, radiology, pharmacy and theatre systems usually come from different suppliers. NHS England defines interoperability as people being able to complete a task across software and organisational boundaries, using products from different vendors that work together with little or no human intervention. An integration engine is one of the main ways a hospital gets there.
What an integration engine does
- Receives feeds: HL7 v2 messages, FHIR API calls, files and webhooks.
- Validates and acknowledges them, so the sender knows whether a message arrived.
- Transforms them: one supplier's version of an ADT or result message into the shape another system expects, or HL7 v2 into FHIR.
- Routes each message to the systems that should get it, and only those.
- Queues and retries when a receiving system is down, and holds messages it can't process.
- Logs and monitors traffic, so the team can see what arrived, what was sent and what failed.
Why the mapping lives in the middle
HL7 says v2 implementations vary so much that mappings generally have to be worked out site by site. Putting that knowledge in one place means a change of lab supplier is a change to one mapping, not to every system that receives results. NHS England makes a related point about APIs: what matters is the standard an API conforms to, not the API itself. The engine is where local feeds are brought into line with standards such as FHIR UK Core, SNOMED CT and the NHS Number.
Questions to ask about your integration layer
- What happens to a message that can't be mapped: is it rejected, dropped, or kept with the raw content so it can be replayed after a fix?
- Is a sender acknowledged before or after the message is safely stored?
- Can you replay a day's traffic into a new or repaired system?
- How are patient identifiers reconciled, and are local copies of demographics kept in step with the Personal Demographics Service, as NHS England's usage policy requires?
- Who owns the mappings, and how is a change reviewed? Integration software sits in the clinical risk picture too: DCB0129 has its own guidance document on middleware, and the DCB applicability guide counts a "data flow" as a digital product.
What it does not mean
- An integration engine doesn't fix data quality on its own. It moves and reshapes what systems send; wrong or missing data upstream stays wrong.
- Connected doesn't mean interoperable. NHS England's definition is about people completing tasks across systems, which also needs shared terminology, identifiers and agreed processes.
- It isn't outside clinical safety. A mapping error can put a result on the wrong patient or drop it altogether, so changes deserve the same care as other health IT changes.
Where Thalix fits
Thalix's first layer is an integration node. Drivers for HL7 v2, FHIR, DICOMweb, MQTT, webhooks, files and other nodes feed one pipeline (a CloudEvents envelope, identity linking, de-duplication and dead letters) into an ordered, replayable event log, with the raw message kept. Senders are acknowledged only after events are durably logged, an http-out driver delivers events onward at least once, and nodes can federate over NATS JetStream from edge to site to central. It can take the same HL7 v2 feeds an existing engine sends, so a pilot doesn't have to rewire the hospital.
Thalix is at pilot stage. Demos run on synthetic data, and a hospital deployment needs its own clinical safety case, information governance approval and security review. We don't claim any certification or assessment result the product doesn't have.
Questions people ask
Is an integration engine the same as an interface engine?
The two terms are used for the same kind of software: something in the middle that receives, transforms and routes messages between systems. What matters is what it does with messages it can't process, and how it is governed.
Do integration engines need clinical safety assessment?
Software that carries patient data between systems is part of the clinical risk picture. NHS England's DCB0129 page lists a guidance document on middleware, and the DCB applicability guide counts data flows as digital products. Your clinical safety officer decides how the standards apply locally.
Can an integration engine convert HL7 v2 to FHIR?
Many can, but HL7 says v2-to-FHIR mappings generally have to be done implementation by implementation. HL7's V2 to FHIR guide is a starting point, not a finished mapping for your hospital.
Sources
Each source below is an official page, read and checked in October 2026. Where a page and this guide differ, the official page wins.
- Interoperability NHS England · checked October 2026
- Comparison: HL7 v2 messaging (FHIR R5) HL7 · checked October 2026
- HL7 Version 2 to FHIR implementation guide HL7 · checked October 2026
- Personal Demographics Service NHS England Digital · checked October 2026
- DCB0129: Clinical risk management in the manufacture of health IT systems NHS England Digital · checked October 2026
- Applicability of DCB 0129 and DCB 0160: terms and definitions NHS England Digital · checked October 2026
General information only, written for hospital digital, IT, operations and clinical safety teams. It isn't legal, regulatory, information governance or clinical safety advice, and it doesn't replace your own organisation's processes or the official guidance linked above.