A hospital running an EHR, a lab system, a pharmacy system, a scheduling tool, and a handful of specialty applications does not wire them to each other directly, not for long. Five systems connected point to point is ten interfaces to build and keep working. Add a sixth and it is fifteen. Every new system multiplies the connections faster than any team can maintain them by hand.
An integration engine exists for the exact moment that stops working: one point every message passes through, where rules decide what to transform and where to send it next. If a destination cannot take a message right now, the engine holds it and tries again. Direct system-to-system interfaces are simpler to picture, and they stop scaling the moment a hospital runs more than a handful of systems that all need to hear from each other.
What an Integration Engine Does to Every Message
IHE’s own vocabulary for this layer is not perfectly consistent, and the inconsistency is worth untangling rather than smoothing over. Its Radiology User’s Handbook defines a broker as a device that translates between a system’s own format and what everything else expects. Its glossary treats the two terms as one, with an entry that simply reads “Interface engine: See Broker”.
Its own deployment guidance draws a sharper line a few chapters later, separating a narrow adapter built for one system pair from something broader. It calls that broader layer a “general, multipurpose, high-throughput message adaptation system”: an interface engine run as a central service reaching many systems at once rather than one dedicated pair.
The narrow broker that sits in front of a RIS to expose a Modality Worklist service is the first kind. The enterprise-wide layer an admission feed and a lab order pass through, long before either one reaches radiology, is the second, and it is the subject of the rest of this piece.
Whatever it is called, the layer does the same handful of jobs on every message that crosses it, regardless of which two systems are talking.
| Function | What it means |
|---|---|
| Receive | Accept an inbound message from a sending system over its own connection, independent of what any other sender is doing |
| Parse | Break the message into its segments and fields so the content can be read and acted on programmatically |
| Transform | Rewrite fields, codes, or structure so the message matches what the receiving system expects, not what the sender happened to send |
| Route | Decide which downstream system or systems should receive this message, based on rules built on the message’s own content |
| Acknowledge | Return a response telling the sender whether the message was accepted, and at what level |
| Queue | Hold a message the engine has accepted but has not yet delivered, so a slow or unavailable destination does not block anything upstream |
| Retry | Attempt delivery again on a schedule when a destination does not respond, without asking the sender to resend anything |
| Log | Record what happened to every message, so a gap can be found by checking a record instead of guessing |
This is not a new shape of problem. DICOM routing solves the identical one a layer down, for imaging studies instead of clinical messages, and the two layers fail in the same way when nobody is watching. Two of the jobs above carry most of the actual engineering risk: transform and queue. The rest are largely mechanical once the engine is configured correctly.
Message Transformation: Where the Work and the Risk Concentrate
HL7 version 2 messages look standardized until two real systems try to exchange one. The standard defines segments, fields, and trigger events, but it leaves wide optionality inside that structure. Which fields a system populates varies by vendor. So does which local code table it uses for something like patient sex or marital status, and whether it adds its own locally defined segments carrying data that means nothing to anyone downstream.
HL7 itself expects the standard to carry both shapes of deployment at once. Its own product brief for the Version 2 messaging standard puts it plainly: the standard “is designed to support a central patient care system as well as a more distributed environment where data resides in departmental systems.” Departmental systems are where most of that local variation originates.
An admission feed out of a major EHR platform such as Epic or Cerner rarely matches what a lab system, a bed management tool, or a department’s own scheduling application expects field for field. Every one of those systems calls itself HL7 compliant regardless.
An integration engine’s job is to close that gap without asking either system to change. IHE’s own guidance on legacy healthcare integration describes exactly this function: “Typically, there is an interface engine between a HIS and a RIS, which can be used to transform any of these messages.” That can mean minor field-level changes to a shared HL7 feed, or converting a system’s proprietary format to HL7 and back.
That transformation logic gets built as reusable mapping rules rather than one-off code written for each connection, and who is able to author those rules decides what the engine costs to maintain. A 2011 paper on interface engine design took that as its starting problem: needing a programmer every time a rule changes is the bottleneck. It put the “information exchange rules (called the mapping data)” behind a graphical editor and stored them for reuse.
The risk sits in exactly the same place as the convenience. A rule that maps one system’s code for marital status to another’s wrong equivalent succeeds silently. Nothing downstream can tell a correct transformation from a mistaken one dressed up as a valid message, because both produce output that parses cleanly. The failure is not a rejected message, it is a confidently wrong one, and it surfaces only when someone notices a patient’s record disagrees with itself across two systems.
Guaranteed Delivery: What “Acknowledged” Actually Means
Delivered and acknowledged are not the same claim, and an engine that treats them as interchangeable can report a clean send for a message the receiving application never actually processed. HL7 v2 defines this distinction directly, in the code set a receiving system returns in a message’s MSA segment. The standard’s own acknowledgment code table is “used in HL7 Version 2.x messaging in the MSA segment.” It separates two different handshakes rather than one.
Original mode carries a single application-level code: AA for accepted, AE for an application error, AR for an application reject. Enhanced mode splits the same handshake into two steps instead. An earlier commit acknowledgment confirms the message reached the receiving system at all. A later application acknowledgment confirms what the receiving application did with it once it tried to process the content.
An engine that stops watching after the commit response is watching the wrong half of the handshake. The message arrived. Whether the receiving application accepted it as valid, rejected it, or errored out trying to act on it is a separate question, answered later. That is the one that decides whether anything downstream can trust what just happened.
What Happens When a Downstream System Is Down
A downstream system going quiet is the normal case an integration engine has to handle, not the exceptional one. A maintenance window, a crashed service, a network segment that drops mid-shift: all of it happens to systems that are otherwise reliable, and none of it is a reason the sender’s own message should fail.
Because the engine already separates accepting a message from delivering it, an unavailable destination is a solvable problem rather than a lost one. The message sits in the engine’s own queue and gets retried on a schedule until the destination answers or someone intervenes. This is the same mechanism DICOM routing calls store-and-forward: decoupling acceptance from delivery is what makes retry possible at all, one layer up or one layer down.
What differs between the two layers is what ordering means once something is held and retried. An imaging study is largely self-contained and does not depend on the order it arrives in relative to other studies. An admission feed does.
A discharge message can arrive before the admission it discharges, when the engine retries the admission after a longer outage. That can leave a downstream system’s picture of the encounter in a state its own logic never expected. Retrying strictly in the order received, within a single channel, handles this by construction. It does not extend across separate channels feeding the same destination.
The expensive failure is the same one at either layer. A queue has been growing for hours because a destination has been down since a change nobody rolled back, and no one has been watching the count. Every message in it is recoverable once the destination returns. Recoverable later is not the same as available now, for a downstream system that has been running on stale or missing data the whole time.
Judging an Integration Engine
The questions worth asking a vendor, or asking about a hospital’s existing environment, follow from everything above.
| Criterion | The question to ask |
|---|---|
| Throughput | What message volume and burst size has this engine actually run in production, not the figure on a spec sheet |
| Transformation model | Are mapping rules configuration a non-programmer can read and version, or code in a proprietary scripting layer only the original integrator can touch |
| Testability | Can a new interface be tested against realistic message volume and edge cases before it touches a live system, or does testing mean waiting for the first production message to break something |
| Monitoring and alerting | Does the engine surface a stuck or growing queue on its own, or does someone have to notice a downstream system has gone quiet |
| Interface ownership | Once an interface is built, whose job is it when the sending system changes a field, or a receiving system’s vendor pushes an update that quietly breaks a mapping |
Testability and interface ownership are the two a product team most often skips, and they are the two that determine whether a transformation error gets caught before go-live or six months into production. An interface engine outlives the project that built it more often than not. Whether it stays trustworthy has less to do with whether it worked on day one than with whether anyone still owns it on day one thousand.
Which Rules, Who Tests Them, Who Gets Paged
Named plainly, the layer does four things: receive, transform, route, and hold a message safely when nobody downstream is ready for it yet. What makes it worth designing around deliberately is that a wrong transformation or a silently stuck queue produces no error any system can act on. It just produces the wrong picture of a patient, quietly, until someone reconciles it against something else.
For a team scoping a connection into a hospital’s environment, the integration engine question is rarely whether one exists. It usually does. The real questions sit upstream of that: which mapping rules this specific interface needs, who tests them before go-live, and who gets paged when a queue starts growing.
An integration engine is not part of what EBM offers in this market today. It typically sits among the HIS, the EHR, and a hospital’s other departmental systems, reconciling and routing HL7 traffic long before an order ever reaches radiology. EBM mAIn PACS® picks up from there, on the DICOM side: native C-STORE, Query/Retrieve, Modality Worklist, and Storage Commitment. Those are the services a deployment’s existing systems meet it on, and the messaging layer upstream stays with the engine that got the order there in the first place.
The engine’s job ends where the reconciled order reaches radiology. PACS Integration: Connecting Modalities, RIS, and the EHR covers what happens from there, across all three of its integration surfaces. Where the result travels back as structured data rather than a legacy feed, FHIR in Plain Terms covers the newer resource model carrying it.
A partner assembling an imaging product rarely wants to own both layers. The imaging tier is where EBM Fabric™ does the work, on native DICOM services that a partner ships under their own brand. The messaging tier is a known engineering problem with mature tools, and the question there is usually only which of them a given hospital already runs.