HL7 (Health Level Seven) plays an extensive role in healthcare interoperability. It is a free set of international standards that outlines the format used to transfer healthcare data between disparate systems. Healthcare information that needs to be exchanged between systems is transmitted as one or more messages.
These messages are comprised of different segments in a definitive sequence according to the messaging standards of HL7. Customized healthcare information that falls outside HL7 standards can be transferred between systems by creating a z-segment (custom segment). HL7 messages are usually transmitted by the TCP/IP protocol over a local area network (LAN) via interconnected devices, for example, the hospital or healthcare organization building.
What Are HL7 Messages?
Whenever healthcare data or information needs to be transferred between different healthcare organizations or systems, HL7 messages are used. These messages are sent in reply to trigger events linked to the patient, for example, when a patient is being discharged, admitted to a hospital, or visiting a medical professional. Some examples of HL7 messages include billing information, laboratory records, patient records, x-ray, MRI, or CT scan data.
HL7 Message Structure
Each HL7 message comprises one or more different sets of segments in a specific sequence in human-readable (ASCII) format. A message syntax table can characterize HL7 messages. Messages consist of three components, segments, composites (components), and sub-fields (sub-components).
Each HL7 message type is characterized by a three-character code, such as ADT, with ADT (Admission, discharge, and transfer) defining the HL7 message type. A segment three-character code A01 is the trigger event; thus, when ADT-A01 is entered into the system, the character code explains why the message is sent and the trigger event. The character code ADT-A01 translates to “patient admit.”
The most common HL7 message types are:
- ADT: Admission, discharge, and transfer
- ACK: General acknowledgment
- ORU: Observation message (unsolicited)
- ORM: Pharmacy/treatment order message
- SIU: Schedule information (Unsolicited)
- BAR: Add/change billing account
- MDM: Medical document management
- MFN: Master files notification
- DFT: Detailed financial transactions
- RGV: Pharmacy/treatment give message
- RDE: Pharmacy/treatment encoded order message
- QRY: Query
HL7 Segments
HL7 messages can consist of one or more segments containing one category of specific data, such as patient demographics, patient admission date, or Patient next of kin. Each segment is separated by a carriage return character (/r), with segment components or fields separated by the pipe “|”. If sub-fields (sub-components) are present, they are separated by the character “^”.
Segment IDs are unique three-character codes that identify each segment of the message. There are roughly 120 segment codes present for HL7, with the most used segments:
- DG1: Diagnosis
- MSH: Message header
- PID: Patient identification
- PV1: Patient visit
- NTE: Notes and comments
- NK1: Next of kin
- IN1: Insurance
- EVN: Event type
- OBR: Observation request
- OBX: Observation result
- ORC: Common order
What Are Custom HL7 Z Segments?
A Z-segment in HL7 is a message segment containing patient or clinical data that is not part of the original HL7 standard and is expressed locally. Z-segments are the main reason why the HL7 standard is referred to as flexible. Z-segments can be used to create custom messages so that applications can receive or send data that is defined outside of the HL7 standard. When adding z-segments to the HL7 messaging standard, new fields may need to be created to support the z-segment requirements.
All Z-segments start with “Z,” for example, ZEK, ZPM, and ZAL, and can be inserted in any place in the HL7 message. It is prevalent to place/insert the z-segment within a set of segments that have similar information as the z-segment—for example, adding a z-segment containing additional patient information to segments that have the PID (patient identification) code. Z- segments are also planted at the end of the message, which prevents systems that are configured to interpret standard HL7 format from requesting any configuration modifications before the message is processed and transmitted.
The application will then be able to easily read the segments in the order that it predicts and interpret the information from the z-segment at the end of the message via defined system configurations. The placement of Z-segments after the HL7 standard is beneficial if some applications are configured to ignore z-segments that they are not programmed to utilize.
When developing and adding z-segments to HL7 messages, it is essential to ensure that the data subject matter is similar (i.e., patient details, additional patient information, or patient visits) and unchanged to ensure that the trigger event remains the same.
Working with unexpected Z Segments
Unexpected Z-segments in HL7 may be sent by systems, regardless of if these segments are part of the original specifications. Depending on its location in the messaging system, the z-segment is located; even if you are not interested in the data, the segment will need to be considered during the development and testing period of the interface engine. Unexpected Z-segments are observed when some vendors use Z-segments in messaging instead of HL7 standards.
Examples Of Z Segments
When characterizing a z-segment (locally-defined information), reusing predefined fields or custom fields to accommodate or add additional information not included in the HL7 standard may be needed.
Examples of Z-segments in HL7 include:
- ZPD segment: Created to contain customized patient demographics information, e.g., ZPD_Allergies.
- ZLR segment: Typically utilized to add additional information for legacy laboratory-based reporting. When adding a Z-segment to an HL7 2.3 ORU message, only one ZLR per OBR (Observation request) can be inserted as the ZLR segment needs to follow after each OBR segment.
- ZPP: Patient preference, i.e., patient choice of a surgeon or medical professional (PR1_Surgeon) or patient diet preferences (PV1_Diet_Type).
Conclusion
Z-segments in HL7 can be extremely helpful for healthcare organizations looking to add additional customized healthcare (patient data or system information) data that falls outside of the HL7 standards to improve interoperability further. When inserting custom z-segments into HL7 standard segments, it is essential to know if the system is programmed to ignore z-segments or z-segments that have been inserted instead of HL7 standards.
