HL7 interfaces, in plain English
What an HL7 interface really is, why the integration engine matters more, and the four questions to ask before any healthcare integration project.
If you run a clinic, a health-tech product, or the IT shop between them, you have probably had this meeting: two systems need to talk, someone says “we’ll build an HL7 interface,” everyone nods, and six months later the project is somehow both over budget and not done. This essay is the plain-English version of what is actually going on.
What an HL7 interface really is
HL7 is not an app or a product. It is a family of message formats — ADT for admissions and demographics, ORM for orders, ORU for results, SIU for scheduling — that healthcare systems use to tell each other what just happened. An “interface” is the pipe that carries those messages from one system to another, plus all the translation that happens in the middle.
The translation is the whole job. Both systems speak HL7 the way two people can both speak English and still misunderstand each other. One system puts the patient’s insurance in a field the other system uses for something else. One sends a cancellation as a new message; the other expects a status change. The standard is a starting point, not a guarantee.
Why the integration engine matters more than the interface
You can wire system A directly to system B. It works — once. The third time you do it, you have six pipes, each with its own translation logic, each documented in one person’s head. This is how health systems end up afraid of their own plumbing.
An integration engine — Mirth Connect, Rhapsody, Cloverleaf, and their successors — sits in the middle. Every system connects to the engine once; the engine handles routing, translation, queuing when a system goes down, and a log of every message that ever passed through. When an interface breaks at 2 a.m., the engine is the difference between “replay the queue” and “call the vendor and pray.”
The questions to ask before any integration project
Which messages, exactly? “Connect the EHR to the billing system” is not a scope. “ADT A01/A04/A08 and DFT P03, one direction, with these twelve fields mapped” is a scope.
What happens when a message fails? Every interface drops messages eventually. The design question is whether anyone finds out, and whether the fix is a replay or a data-entry weekend.
Who owns the mapping document? The single most valuable artifact in any integration is the field-by-field mapping with its edge cases written down. If it lives in a contractor’s head, you are renting your own interface.
Does patient data stay safe in transit and at rest? The compliance part is not optional and it is not paperwork — it shapes the architecture.
Where I fit
I have spent years on healthcare data plumbing — HL7 interfaces, integration engines, and the unglamorous work of making clinical data agree with itself. The way I engage is deliberately small at first: an integration assessment that maps your systems, your message flows, and the two or three risks that will actually bite, before anyone commits to a build.
If you are staring at one of these projects: here is how I run healthcare technology work, and here is a free half hour to talk through the specific mess. No deck, no pitch — bring the diagram, or the napkin, or nothing.