Why the words matter
In a procurement meeting, someone asks whether the new system "has an API". The supplier says yes. Six months later the integration team discovers the API is read only, covers a third of the data, and has no way to tell anyone when something changes. Nobody lied. The word just meant different things to different people.
Healthcare integration has more vocabulary than most fields, and much of it is used loosely. This glossary defines each term by what it does, keeps the definitions vendor neutral, and notes where terms are commonly confused.
The glossary
API (application programming interface)
A defined way for one piece of software to request data or actions from another. In healthcare it usually means a web API, often RESTful, sometimes using FHIR. An API is a door into one system. It says nothing about how data gets moved, checked or transformed between many systems. When a supplier says "we have an API", ask what it covers, whether it can write as well as read, and how you find out about changes.
Interface engine (integration engine)
Software that sits between systems and receives, routes, transforms and delivers messages. Classic interface engines grew up around HL7 v2 messaging in hospitals: an ADT message comes in from the PAS and is copied, reshaped and sent on to pathology, radiology and the EPR. The terms interface engine and integration engine are used interchangeably. The interface engine decommissioning checklist shows what one typically holds.
iPaaS (integration platform as a service)
An integration platform delivered and run as a cloud service, rather than installed and maintained on your own servers. It covers the same jobs as an interface engine (connecting, transforming, routing) and usually adds workflow orchestration, monitoring and managed connectors. The "as a service" part is about who runs it, not what it does. Some platforms offer the same product as a managed service or self hosted.
Middleware
The umbrella term for any software that sits between applications and helps them communicate. Interface engines, iPaaS products, message queues and ESBs are all middleware. Useful as a category, too vague for a requirement.
ESB (enterprise service bus)
An architecture pattern, and a class of product, where systems connect to a shared bus rather than to each other. Popular in large enterprises in the 2000s and 2010s. In healthcare the term mostly appears in older architecture documents and some legacy estates.
Point to point integration
A direct connection between two systems, built for that pair. Simple to start, hard to scale: every new system adds connections to every system it needs to talk to, and each one is maintained separately. Most "spaghetti" estates are collections of point to point interfaces.
Orchestration
Coordinating a sequence of steps across several systems as one process, with ordering, conditions, retries and error handling. Routing moves one message. Orchestration runs a workflow, such as "when a starter appears in ESR, create accounts, check training, then notify the manager". The anatomy of a healthcare integration workflow breaks one down step by step.
Transformation (mapping)
Changing data from the shape and codes one system uses into the shape and codes another expects. Structural transformation changes format, for example HL7 v2 to FHIR. Semantic mapping changes meaning, for example a local code to its SNOMED CT equivalent. Both are needed, and the second is usually harder.
HL7 v2
A long established messaging standard for exchanging clinical and administrative events between systems, built from pipe delimited segments. Still the workhorse inside most hospitals for admissions, orders and results. It is a standard for message content and structure, not a product.
FHIR (Fast Healthcare Interoperability Resources)
The current HL7 standard, which models healthcare data as resources (Patient, Observation, Encounter and so on) exchanged over web APIs. In England, national APIs increasingly use FHIR, profiled through UK Core. Like HL7 v2, it is a standard, not a product.
MESH (Message Exchange for Social Care and Health)
The NHS England national service for sending messages and files securely between organisations, using a mailbox model. Many national flows use MESH as the transport underneath. MESH moves the message. It does not check what is inside it.
Connector
A prebuilt component that handles connection to a specific system or standard: authentication, endpoints, paging, error codes. A connector saves building that plumbing yourself. It doesn't decide what data should flow or what should happen when it fails.
Terminology server
A service that holds code systems such as SNOMED CT, ICD-10 and LOINC, and answers questions about them: is this code valid, what does it mean, what does it map to. The terminology server vs lookup table explainer covers why that matters.
Webhook
A way for a system to notify another automatically when something happens, by calling a URL the receiver has registered. It is the opposite of polling, where the receiver keeps asking whether anything has changed.
How the terms fit together
Most confusion disappears once you separate four layers:
- Transport: how bytes get from A to B (web APIs, MESH, file transfer, webhooks).
- Format: the structure of the data (HL7 v2, FHIR, CSV).
- Meaning: what the codes inside mean (SNOMED CT, dm+d, local code lists).
- Orchestration: what happens, in what order, and what to do when a step fails (interface engines, iPaaS, workflow tools).
An API is mostly transport. FHIR is format. SNOMED CT is meaning. An interface engine or iPaaS is where orchestration lives, and where the other three are wired together. The levels of healthcare interoperability apply the same separation to maturity.
Next time a term appears in a requirement or a contract, ask which of the four layers it refers to. That one question removes most of the ambiguity.
