This lesson will introduce you to the HL7v2 standard, which is used to exchange data between healthcare IT systems. After you have completed this lesson, you will be familiar with a few core concepts. You will also know where to look for more information.
Read through sections 1.3, 1.4, 1.5, and 1.8 of chapter 1 of the HL7 v2.9 standard. We have a copy in the HL7 directory in the Innolitics Library. You can also download a copy on the HL7 website after creating a free account.
Watch this short video about the HL7 message format.
Browse through sections 2.2, 2.3, and 2.4 of chapter 2 of the HL7 v2.9 standard. Chapter 2 describes the message format from the previous video in a good deal more detail.
Glance through chapters 2A (Data Types) and 2C (Code Tables).
Glance through the table of contents of the Caristix “HL7 Survival Guide” in the root of the Innolitics Library. You can also download this from the Caristix website here.
To learn as much as possible from these exercises, we recommend that you write your response before revealing the provided answers.
Define, in your own words, the following HL7 terms: “Trigger event”, “message”, “segment”, “field”, “data-type”, “component”, and “sub-component”.
Here are the definitinos from chapter 2 of the standard:
The standard is written from the assumption that an event in the real world of healthcare creates the need for data to flow among systems. The real-world event is called the trigger event. For example, the trigger event a patient is admitted may cause the need for data about that patient to be sent to a number of other systems. The trigger event, an observation (e.g., a CBC result) for a patient is available, may cause the need for that observation to be sent to a number of other systems. When the transfer of information is initiated by the application system that deals with the triggering event, the exchange is termed an unsolicited update.
A message is the atomic unit of data transferred between systems. It is comprised of a group of segments in a defined sequence. Each message has a message type that defines its purpose. For example the ADT Message type is used to transmit portions of a patient’s Patient Administration (ADT) data from one system to another. A three-character code contained within each message identifies its type.
A segment is a logical grouping of data fields. Segments of a message may be required or optional. They may occur only once in a message or they may be allowed to repeat. Each segment is given a name. For example, the ADT message may contain the following segments: Message Header (MSH), Event Type (EVN), Patient ID (PID), and Patient Visit (PV1). Each segment is identified by a unique three-character code known as the Segment ID.
A field is a string of characters.
Fields occur in a fixed position in a given segment.
Data types may be either primitive or composite. Primitive data types consist of a series of characters as specified by the data type. Composite data types are made up of a series of components that are themselves assigned to a data type, which may again be either primitive or composite data types. In the case of composite data types, the components of a component are called sub-components, and they shall only be assigned primitive data types.
Consider this HL7 message.
MSH|^~\&|SWSIMAGESRVR|INNOLITICS_ENG|MIRTH|INNOLITICS_ENG|20100719171917.926|| ORU^R01^ORU_R01|1279585157566|P|2.6||||||UNICODE UTF-8 PID|1||SWS-F4263E6F||EXAMPLE^JOSEPHINE^DEVA||19641102|F OBR|1|899911-333^fred|00112781^SWS_FILLERUP|077777-TCD^077777-TCD^DEFAULT_RSCSN||| 20090923155556|||||||||^KENOBI|||||||||F|||||||&DaRavino&Alfonse&&&&C.A. OBX|1|ED|EncapsulatedReport^1.2.840.114340.3.8251016058117.2.20090923.155556.44|| fred^application^application/pdf^Base64^<Base64 Encoded PDF>||||||F
NOTE: The lines were hardwrapped to avoid the need for horizontal-scrolling. Ordinarily there is one HL7 segment per line.
What is the message type? What do the components of the message type field mean?
Watch the short video about about the HL7 message format linked in the reading material. Also, take a look at section 2.14.9 of the standard, and use chapter 2A to dig into the meaning of the components of the message type field.
Section 2.14.9 of the standard shows the fields that are present in the MSH segment. The 9th field, also called MSH.9, is the “Message Type”. Notice that this field is required (the “R” in the “OPT” column) and has a data type of “MSG” (the “MSG” in the “DT” column).
Details about the “MSG” data type can be found in chapter 2A of the standard. If you look in the table of contents of this chapter, you can find details about “MSG” in section 2A.3.44.
This field has three components. The first two have length 3, and the third has a length between 3 and 7. In this example, the “Message Code” component is
ORU, the “Trigger Event” is
R01, and the “Message Structure” is
ORU_R01. Note that the components are separated by
^, which is the component-separator for this message, as specified in MSH.2.
Notice that the data type of all three components is “ID”. Also note that each of the components has a table of allowable values, as specified in the “TBL#” column of section 2A.3.44. You can look up these tables in chapter 2C. For example, if you look in Table 0076 you will see a list of all the allowable message types.
This process of looking at the Segment to determine the field, then looking at the data type, then looking at the data type’s table of possible values, is a common pattern when working with HL7.
The value of
ORU means the message is an “Unsolicited transmission of an observation”. In chapter 7, you could read more about this. It says:
The ORU message is for transmitting observational results, including lab, clinical or other observations, to other systems.
Select another field from the HL7 message in Exercise 2 and track down what it means.
Using the Caristix HL7 browser (in many ways analogous to our DICOM Standard Browser, but for HL7), look up the MSH segment for HL7v2.6. Then look up the Message Type field. Then look up the possible values for the Message Code component.
Click on the “HL7 Messaging” tab on the left side of the Caristix HL7 tool. Create an account. Then upload the sample message from Exercise 2. Be sure the select the right version of the standard from the dropdown. Look up the same field you investigated in Exercise 3 using this tool.
Open the lesson page in the GitHub editor.
Remove any exercises or learning material that are not useful to the intended audience. Find ways to shorten and clarify the writing. Add generally useful exercises, responses, or learning material. Your improvements will make our training program great!
Create a new branch and pull request and assign it to your lesson mentor. The available lesson mentors are included in the YAML front matter of the lesson. They will set up a time to review your suggested changes and to talk through your exercises for the lesson.
After the review add your self to the "completed" property in the lesson's YAML front matter and merge in your changes!