Transport and interface engines

So far we have read messages. But how do they actually travel from one system to another? In the HL7 v2 world, the answer comes down to one acronym, MLLP, and one middleman, theinterface engine.

The problem: TCP does not know about messages

Messages travel over the network using TCP/IP. But TCP carries a continuous stream of bytes, with no idea where one message ends and the next begins. So we need a convention toframe each message.

MLLP: three framing bytes

The Minimal Lower Layer Protocol wraps each message between control bytes: one start byte, then the message, then two end bytes.

• ⟨0B⟩: the start byte (the VT control character).
• ⟨1C⟩⟨0D⟩: the two end bytes (FS then carriage return).

Thanks to this framing, the receiver knows exactly where each message starts and ends, even if ten messages arrive back to back on the same connection.

The acknowledgement, the safety net

Once the message is received, the destination sends back an ACK message, framed the same way, to confirm "received and understood". If the sender does not get its ACK, it knows something failed and can resend. This back-and-forth is what makes the exchange reliable.

The interface engine, the universal translator

In practice, two systems rarely connect directly. In the middle sits aninterface engine: software that receives messages, transformsthem (rename a field, reformat a date, translate a code) and routes them to the right destination. It is the hospital's universal translator.

The best known are Mirth Connect, Cloverleaf, Iguana, Corepoint. Mirth Connect is free and open source: the ideal entry point to practice on a small personal project, receiving and sending real messages.