Message flow

In a healthcare environment, HL7v2 messages follow a typical flow that allows clinical and administrative information to move between systems. The flow involves the generation, transmission, reception, and processing of messages — and the acknowledgments that close the loop.

When a patient is admitted to a hospital, for example, the admission triggers an information exchange between the hospital's admission system (typically the Electronic Health Record) and the laboratory information system (LIS). The admission system sends a message to the laboratory to request the necessary tests. The laboratory must then receive the message through an interface, process it, and send a message back to confirm the test order and, eventually, return the results.

Like any process, an HL7v2 flow involves a set of actors and a sequence of steps. This page covers both: the typical flow of messages between systems, and the two roles involved in the exchange.

Source and destination roles

In HL7v2 messaging, the concepts of message sending (source system) and message receiving (destination system) describe the roles and responsibilities of the systems involved in the exchange.

Message sending (source system)

The source system initiates and sends an HL7v2 message. It generates the message in response to a specific event or action. The source is responsible for constructing the message according to the appropriate message type, populating the segments and fields with relevant data, and initiating transmission to the intended destination.

A source system typically:

• Identifies the event that triggers the need for information exchange.
• Gathers the data and information related to the event.
• Constructs the HL7 message using the appropriate message type, trigger event, and predefined segment structure.
• Encodes the message using the agreed delimiters and encoding characters.
• Initiates transmission to the destination system.

Message receiving (destination system)

The destination system receives and processes the HL7 message transmitted by the source. It interprets, validates, and uses the information contained within the message.

A destination system typically:

• Receives the HL7 message from the source system through the designated communication channel.
• Validates the message structure, syntax, and adherence to the HL7v2 standard.
• Parses and interprets the content, extracting data from segments and fields.
• Performs any data transformations or mappings needed to align with its own data model.
• Processes the information — updating patient records, triggering workflows, generating reports, or whatever the message's purpose requires.
• Generates an acknowledgment to provide feedback on the processing status.

Steps

The typical flow of an HL7v2 message exchange — from the originating event to the final acknowledgment — looks like this.

1. Event occurrence

The flow begins with an event in the healthcare system. The event can be any activity that triggers information exchange between two or more applications — a patient admission, a laboratory test order, an observation result becoming available, a discharge. In the diagram above, a doctor-appointment request has been triggered by a care provider in the hospital's EHR. This event triggers an exchange between the EHR (the source system) and the hospital's scheduling system (the destination system).

2. Message generation

Once an event occurs, the source system creates an HL7v2 message. The choice of programming language or framework does not matter, provided the resulting message complies with the HL7v2 standard. The generated message contains structured data representing the event. It is constructed according to the appropriate message type and trigger event for the exchange.

In the example, the EHR generates an HL7v2 message to request a doctor appointment. The message uses the SIU^S12 type, which requests a service (in this case, an appointment) from a scheduling system. The message contains information about the patient, the requested service, and any other relevant data.

MSH|^~\&|SendingApp|SendingFacility|ReceivingApp|ReceivingFacility|20230630120000||SIU^S12^SIU_S12|MSG000002|P|2.8|
SCH|1|12345|||20230701^20230702||1^60^Mins||||^^^Hospital^Bed^100||||||||12345678|John Doe|
PID|1||1234567890^^^MRN^MRN~9876543210^^^SSN^SSN||Doe^John^M^^^||19700101|M|||123 Main St^Anytown^CA^12345||555-123-4567|||S|||||||||||||||||||12345678|
RGS|1|
AIS|1|^^^Appointment^Appointment||202307011000^202307011100^R||||||12345^Smith^Jane^^Dr.||||||||||||||||
AIL|1|1|^^^Appointment Location^Appointment Location||||Hospital^100 Main St^Anytown^CA^12345|

3. Message transmission

After the message is generated, it must be transmitted from the source system to the destination. Transmission can occur over various communication channels — dedicated HL7 interfaces, health information exchanges (HIEs), or secure network connections like HL7 over TCP/IP.

In the example, the EHR transmits the message to the scheduling system through a dedicated HL7 interface. The interface handles the transmission and delivers the message to the intended destination. We cover transmission protocols in the MLLP Protocol.

4. Message reception

The destination system receives the HL7v2 message through the agreed communication channel. It then performs whatever it needs to interpret, validate, and use the information. Depending on the use case and the implementation, this step may include validating the message structure, checking adherence to the HL7v2 standard, and performing data transformations to align with the destination's internal data model.

In the example, the scheduling system receives the message transmitted by the EHR. It validates structure and syntax, parses the content, extracts data from segments and fields, and maps it into its own format.

At this stage, the source system does not yet know whether the message was received, or processed successfully. This is why HL7v2 defines the concept of acknowledgment messages — to provide feedback on the processing status of the received message.

5. Data processing

Once the message is received, the destination performs whatever actions the message asks for: updating patient records, triggering workflows or alerts, generating reports, or any other process appropriate to the message's purpose.

6. Message acknowledgment

After processing, the destination generates an acknowledgment message to provide feedback on the processing status. The acknowledgment indicates whether the original message was processed successfully, encountered errors, or required specific actions. Without an acknowledgment, the source has no way to know whether its message arrived and was processed — leading to a lack of visibility, lost data, and inconsistencies between systems.

In the example, the scheduling system generates an acknowledgment message. The acknowledgment uses the ACK message type, which is used to confirm receipt and processing status. The message contains an acknowledgment code that indicates the outcome.

MSH|^~\&|ReceivingApp|ReceivingFacility|SendingApp|SendingFacility|20230630121000||ACK^S12^ACK_S12|MSG000002|P|2.8|
MSA|AA|MSG000002|Appointment scheduled successfully|

See Acknowledgments for the details.

Summary

The typical flow of HL7v2 messages — event, generation, transmission, reception, processing, acknowledgment — is what allows healthcare systems to exchange clinical and administrative data with consistent meaning. The standardized message format, defined message types, and predefined trigger events let systems built by different vendors at different times communicate in a way both ends can rely on.

The ability of systems to communicate events and exchange information about a patient's journey is critical to any healthcare deployment. The versatility of HL7v2 — and the standardization that underlies it — is what has kept the standard relevant for nearly four decades.