Published on InterSystems Developer Community (https://community.intersystems.com)

Home > Requesting and receiving test results (messages OML, ORL and ORU of HL7v2)

Article
Iryna Mykhailova · Dec 12, 2022 12m read

Requesting and receiving test results (messages OML, ORL and ORU of HL7v2)

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.

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. Let's better have a look at the order segments that are the main point of this message.

 
Spoiler
Segment Description
{Order}  
  ORC Common order. This segment is used to transmit fields that are common to all orders (all types of services that are requested). It is required.
  [{PRT}] Participation Information. This segment contains the data necessary to add, update, correct, and delete from the record persons, organizations, or locations (participants) participating in the activity being transmitted. It is optional.
  [{Timing}]  
    TQ1 Timing/quantity. This segment is used to specify the complex timing of events and actions such as those that occur in order management and scheduling systems. This segment determines the quantity, frequency, priority and timing of a service. By allowing the segment to repeat, it is possible to have service requests that vary the quantity, frequency and priority of a service request over time. It is required.
    [{TQ2}] Timing/quantity Relationship. This segment is used to form a relationship between the service request the TQ1/TQ2 segments are associated with, and other service requests. It will link the current service request with one or more other service requests. It is optional.
  [Observation Request]  
    OBR Observation Request. This segment is used to transmit information specific to an order for a diagnostic study or observation, physical exam, or assessment. It is required.
    [TCD] Test Code Detail. This segment contains the data necessary to perform operations or calculations, or execute decisions by the laboratory automation system, and which are not supported by the original HL7 segments related to orders (ORC, OBR). It is optional.
    [{NTE}] Notes And Comments. This optional segment is commonly used for sending notes and comments. It is optional.
    [{PRT}] Participation Information
    [CTD] Contact Data. This segment may identify any contact personnel associated with a patient referral message and its related transactions. It is optional.
    [{DG1}] Diagnosis. This segment contains patient diagnosis information of various types, for example, admitting, primary, etc. The DG1 segment is used to send multiple diagnoses (for example, for medical records encoding). It is optional.
    [{Observation}]  
      OBX Observation/result. This segment is used to transmit a single observation or observation fragment. It represents the smallest indivisible unit of a report. The OBX segment can also contain encapsulated data, e.g., a CDA document or a DICOM image. It is required.
      [{PRT}] Participation Information
      [TCD] Test Code Detail
      [{NTE}] Notes And Comments
    [{Specimen}]  
      SPM

Specimen. The intent of this segment is to describe the characteristics of a specimen. It differs from the intent of the OBR in that the OBR addresses order-specific information. It differs from the SAC segment in that the SAC addresses specimen container attributes. An advantage afforded by a separate specimen segment is that it generalizes the multiple relationships among order(s), results, specimen(s) and specimen container(s).

A specimen is defined as "A physical entity that is an individual, a group, an item, or a part representative of a larger group, class or whole that is the target of an observation or analysis for the purpose of drawing conclusions about the group, class, or whole." Note that any physical entity in the universe has the potential to become a specimen. A specimen is collected or obtained from a source and may be representative of the source, or may represent a deviation within the source. A specimen may be wholly or partially consumed during an observation and any remaining portion of the specimen is persistent and can be stored.

This segment may also be used in limited cases to describe a "virtual" specimen. In particular, to identify the characteristics required for a specimen in the context of a specific observation or test. In summary, SPM represents the attributes specific and unique to a specimen.

      [{Specimen Observation}]  
        OBX Observation/result
        [{PRT}] Participation Information
      [{Container}]  
        SAC Specimen Container Detail. The container detail segment is the data necessary to maintain the containers that are being used throughout the Laboratory Automation System. The specimens in many laboratories are transported and processed in containers (e.g., sample tubes). When SPM and SAC are used in the same message, then the conceptually duplicate attributes will be valued only in the SPM.
        [{Container Observation}]  
          OBX Observation/result
          [{PRT}] Participation Information
    [{Prior Result}]  
      [Patient Prior]  
        PID Patient Identification. This segment is used by all applications as the primary means of communicating patient identification information. This segment contains permanent patient identifying and demographic information that, for the most part, is not likely to change frequently. It should be noted that from V2.4 onwards the demographics of animals can also be sent in the PID segment.
        [PD1] Patient Additional Demographic. The patient additional demographic segment contains demographic information that is likely to change about the patient.
        [{PRT}] Participation Information
        [{ARV}] Access Restriction. This segment is used to communicate the requested/required type of access restrictions from system to system, at both the person/patient and the encounter/visit level.
      [Patient Visit Prior]  
        PV1 Patient Visit. This segment is used by Registration/Patient Administration applications to communicate information on an account or visit-specific basis.
        [PV2] Patient Visit - Additional Information. This segment is a continuation of information contained on the PV1 segment.
        [{PRT}] Participation Information
      [{AL1}] Patient Allergy Information. This segment contains patient allergy information of various types. Each AL1 segment describes a single patient allergy.
      {Order Prior}  
        ORC Common Order
        [{PRT}] Participation Information
        OBR Observation Request
        [{NTE}] Notes And Comments
        [{PRT}] Participation Information
        [{Timing Prior}]  
          TQ1 Timing/quantity
          [{TQ2}] Timing/quantity Relationship
        {Observation Prior}  
          OBX Observation/result
          [{PRT}] Participation Information
          [{NTE}] Notes And Comments
    [{FT1}] Financial Transaction. This segment contains the detail data necessary to post charges, payments, adjustments, etc., to patient accounting records.
    [{CTI}] Clinical Trial Identification. This segment is an optional segment that contains information to identify the clinical trial, phase and time point with which an order or result is associated.
    [BLG] Billing. This segment is used to provide billing information, on the ordered service, to the filling application.

 [ ] = optional, {} = repeatable

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.

Any comments/suggestions are welcome in the comments section.

#HL7 #HealthShare #InterSystems IRIS for Health

Source URL:https://community.intersystems.com/post/requesting-and-receiving-test-results-messages-oml-orl-and-oru-hl7v2