In the previous article, we've seen the structure of one of the most used types of HL7 message - ADT (Admit, Discharge, Transfer) and an example of ADT^A04 with the description of all its fields. Now let's look at another flow of data having to do with ordering and fulfilling the orders of tests. I'm talking about ORM (as of version 2.5 you should use specific messages to order tests, like OMG, OML, OMD, OMS, OMN, OMI, and OMP), ORL and ORU messages. In a very simplified case, the exchange of data may look like this. ![](/sites/default/files/inline/images/images/image(5043).png) Let's look at these messages in more detail. ## HL7 OML messages HL7 OML – Laboratory Order - may be used for the communication of laboratory and other order messages and must be used for lab automation messages. The trigger event for this message is any change to a laboratory order. Such changes include the submission of new orders, cancellations, updates, etc. OML messages can originate also with a placer, filler, or an interested third party. Depending on the number of specimens and containers one has to use different subtypes of this message.  There are 4 different subtypes of this type of message in version 2.8. | Subtype | Description | | ------- | -------------------------------------------------------------------------------- | | OML^O21 | Laboratory order  | | OML^O33 | Laboratory order for multiple orders related to a single specimen | | OML^O35 | Laboratory order for multiple orders related to a single container of a specimen | | OML^O39 | Specimen shipment centric laboratory order  | If we look at the general structure of this type of message they consist of the following segments. | Segment | Description | | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | MSH | Message Header. This segment contains information about the message sender and receiver, the date and time that the message was created. This segment is required. | | [SFT] | Software Information. This segment provides additional information about the software product(s) used as a Sending Application. The primary purpose of this segment is for diagnostic use. There may be additional uses per site-specific agreements. This segment is optional. | | [UAC] | User Authentication Credential. This optional segment provides user authentication credentials, a Kerberos Service Ticket or SAML assertion, to be used by the receiving system to obtain user identification data. It is to be used when the receiving application system requires the sending system to provide end-user identification for accountability or access control in interactive applications. Since user authentication implementations often limit the time period for validity of the session authentication credentials, this segment is not intended for use in non-interactive applications. | | [NTE] | Notes and Comments. This optional segment is commonly used for sending notes and comments. |  [ ] = optional Apart from these 4 segments, common for all the messages of this type, for OML^O21, for example, there are also segments related to the patient and order. Since patient information uses the same segments in different messages I won't go into details - an example of version 2.5 is described in the [previous article](https://community.intersystems.com/post/types-hl7-adt-message-and-example-adta04). Let's better have a look at the order segments that are the main point of this message.
 
Spoiler
## HL7 ORL messages HL7 ORL – Laboratory Order Response - is the application acknowledgment to an OML message. The function of this message is to respond to an OML message.   There are also 4 different subtypes of this type of message in version 2.8 that are sent back in response to a corresponding OML message. | Subtype | Description | | ------- | -------------------------------------------------------------------------------- | | ORL^O22 | General laboratory order response message to any OML | | ORL^O34 | Laboratory order response message to a multiple order related to single specimen | | ORL^O36 | Laboratory order response message to a single container of a specimen OML | | ORL^O40 | Specimen Shipment Centric Laboratory Order Acknowledgment Message | If we look at the general structure of this type of message they consist of the following segments. | Segment | Description | | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | MSH | Message Header. This segment contains information about the message sender and receiver, the date and time that the message was created. This segment is required. | | MSA | Message Acknowledgment. This segment contains information sent while acknowledging another message. This segment is required. | | [ERR] | Error. This segment is used to add error comments to acknowledgment messages. It is optional. | | [SFT] | Software Information. This segment provides additional information about the software product(s) used as a Sending Application. The primary purpose of this segment is for diagnostic use. There may be additional uses per site-specific agreements. This segment is optional. | | [UAC] | User Authentication Credential. This optional segment provides user authentication credentials, a Kerberos Service Ticket or SAML assertion, to be used by the receiving system to obtain user identification data. It is to be used when the receiving application system requires the sending system to provide end-user identification for accountability or access control in interactive applications. Since user authentication implementations often limit the time period for the validity of the session authentication credentials, this segment is not intended for use in non-interactive applications. | | [NTE] | Notes and Comments. This optional segment is commonly used for sending notes and comments. |  [ ] = optional Next comes a group of order response set of segments. The exact segments depend on the type of incoming message and repeat information from it. ## HL7 ORU messages HL7 ORU – Observation Result – contains information about a patient’s clinical observations and is used in response to an order generated in a clinical system (HL7 ORM message). ORU messages are most commonly used within the context of EKG studies, laboratory results, imaging studies, and medical interpretations. They have also been used to communicate order and results information for the purpose of clinical trials (e.g. drug development). It is important to note that ORU messages do not natively contain images, but use a combination of text, codes and numbers to communicate results. There are several subtypes of this message.  | Subtype | Description | | ------- | ------------------------------------------------------------------------------------- | | ORU^R01 | Unsolicited Observation Message | | ORU^R30 | Unsolicited Point-Of-Care Observation Message Without Existing Order - Place an Order | | ORU^R31 | Unsolicited New Point-Of-Care Observation Message - Search For An Order | | ORU^R32 | Unsolicited Pre-Ordered Point-Of-Care Observation | | ORU^R40 | Unsolicited Alert Observation Message | Let's look at segments of the ORU^R01 message that is used for transmitting laboratory results to other systems. | Segment | Description | | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | MSH | Message Header. This segment contains information about the message sender and receiver, the date and time that the message was created. This segment is required. | | [SFT] | Software Information. This segment provides additional information about the software product(s) used as a Sending Application. The primary purpose of this segment is for diagnostic use. There may be additional uses per site-specific agreements. This segment is optional. | | [UAC] | User Authentication Credential. This optional segment provides user authentication credentials, a Kerberos Service Ticket or SAML assertion, to be used by the receiving system to obtain user identification data. It is to be used when the receiving application system requires the sending system to provide end-user identification for accountability or access control in interactive applications. Since user authentication implementations often limit the time period for validity of the session authentication credentials, this segment is not intended for use in non-interactive applications. | | Patient Result | Contains information organized in almost the same segments as Observation Request and Patient Prior parts from respective OML message. | | [DSC] | Continuation Pointer. This segment is used in the continuation protocol. |  [ ] = optional This is it for now. Hope this made the whole exchanging messages process to request and receive the test results a bit clearer. Find out more about HL7v2 on the [official portal](http://www.hl7.org/implement/standards/product_section.cfm?section=13). Any comments/suggestions are welcome in the comments section.