1. Care Coordination and Interoperable Health IT Systems
Unit 5: Standards for Interoperable Health IT
Lecture c – Introduction to HL7 V2®
Welcome to Care Coordination and Interoperable Health IT Systems, Standards for Interoperable Health IT, Lecture c.
This material (Comp 22 Unit 5) was developed by Columbia University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number 90WT0004.
This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. To view a copy of this license, visit

2. Standards for Interoperable Health IT Learning Objectives
Objective 1: Explain why standards are required, how they are developed, and how adoption is encouraged (Lecture a)
Objective 2: Name and describe the types of interoperability standards available (Lecture b)
Objective 3: Summarize functionality of HL7 V2®, CDA®/CCDA, and FHIR® (Lectures c, d, and e)
Objective 4: Recognize HL7 V2® messages, CDA® documents, and FHIR® resources (Lectures c, d, and e)
This unit will cover the following learning objectives: 1) explain why standards are required, how they are developed, and how adoption is encouraged; 2) name and describe the types of interoperability standards available; 3) summarize functionality of HL7 V2®, CDA®/CCDA, and FHIR®; and 4) recognize HL7 V2® messages, CDA® documents, and FHIR® resources. This lecture will focus on the functionality and messages of HL7.

3. HL7 Version 2® (V2)
Originally created in the 1980s as a standard to communicate health care information between systems in hospitals
As of 2016, HL7 has published V2.8 and is working on V2.9
Achieved widespread adoption as a general health care interoperability standard both within and between a variety of organizations
Defines standard message layouts and defines how they are exchanged
HL7 version 2® was originally created in the 1980s as a standard to communicate health care information between systems and hospitals. As of 2016, HL7 has already published HL7 version 2.8 and is working on version HL7 version 2® has achieved widespread global adoption as a general health care interoperability standard, both within and between varieties of organizations. HL7 version 2® defines standard message layouts and the rules on how they are exchanged.
Health IT Workforce Curriculum Version 4.0

4. HL7 V2® message types
The most common message types implemented within an organization are:
ADT (Admission / Discharge / Transfer) or patient administration
Orders
Results
Clinical Reports
Charges
Scheduling
Pharmacy administration and dispensing
The most common message types implemented within an organization using HL7 version 2® are ADT messages, which are also referred to as admit discharge transfer messages. Other common message types are orders messages, results messages, clinical reports messages or medical records messages, charges, scheduling, medication administration, and medication dispensing.
Health IT Workforce Curriculum Version 4.0

5. Uses of HL7 V2® Most common uses between organizations:
Public health communications
Reportable results, syndromic surveillance, immunizations
Communication with labs
Orders, results
Patient Identification
Using the IHE PIX / PDQ HL7 V2® profiles
Communication from providers to health information exchanges
ADT, allergies, medications, results, other clinical data
The most common uses of HL7 Version 2® between organizations are messages for public health communications, such as reportable results, syndromic surveillance, and immunizations. Another common use is for order and result communication between doctors and commercial labs. A third common use of HL7 messages is for identifying an matching patients in a health information exchange. HL7 version 2® is also a common vehicle providers use to share health information about patient visits to a health information exchange.
Health IT Workforce Curriculum Version 4.0

6. A typical HL7 V2® messaging scenario
Imagine a typical HL7 version 2® messaging scenario, where a patient is admitted to the hospital. In HL7 version 2® terms, this event is referred to as a “trigger event”. The trigger event then leads to the patient admission being recorded in the registration system and a message is generated and sent to the receiving systems. The message will be sent to the hospital EHR and the hospital laboratory. It might also be sent to the hospital pharmacy, the public health authority for syndromic surveillance purposes, or a health information exchange. The health information exchange might then notify the patient’s primary doctor that the patient has been admitted to the hospital. Each system that receives the admission message would process it based on their application logic – in many cases a new visit record would be created on the receiving system.
5.7 (Lorenzi, V., 2016).
Health IT Workforce Curriculum Version 4.0

7. How HL7 Version 2® messaging works
A real world event happens, such as the admission of a patient. We call that a trigger event. The event is recorded on the sending system. The sending system then creates a message based on the HL7 standard and sends it to the receiving system. For example, the admission might be recorded on the patient registration system and then the message notifying about the admission would be sent to the laboratory information system. The receiving system receives the message and either fully processes it or at least saves it to a recoverable resource. If it can receive the message successfully, it sends back a positive acknowledgement message. Otherwise, it sends back a negative acknowledgement message.
5.8 (Lorenzi, V., 2016).
Health IT Workforce Curriculum Version 4.0

8. An example HL7 Admit Message
This example message is communicating information about the hospital admission of Adam Everyman. It consists of header information about the message followed by information about the trigger event followed by information about the patient followed by information about the patient’s visit at the hospital. MSH, EVN, PID, and PV1 are all known as segments. Lets look more closely at the message and its segments.
5.9 Figure (HL7 Version 2.7 Standard Copyright©, 2011). Used with permission.
Health IT Workforce Curriculum Version 4.0

9. Breaking down an HL7 V2 Message
Each message is made up of segments
A segment is a group of related fields
Each segment begins with a three segment identifier and ends with a carriage return
The very first segment of every message is the Message Header Segment (MSH)
The ordering of segments in a message are defined in the HL7 Message Definition for that Message Type
Each message is made up of segments. A segment is a group of related fields. Each segment begins with a three segment identifier and ends with a carriage return. The very first segment of every message is the Message Header Segment whose segment ID is MSH. The ordering of segments in a message matters and are defined in the HL7 Message Definition for that Message Type. Let’s look at an example message definition.
Health IT Workforce Curriculum Version 4.0

10. Example of a message definition
Each type of HL7 V2 message is defined in the standard with a Message Definition. The Message Definition shows what segments can appear in a message, how often, and in what order. It gives the segment IDs, short descriptions, and provides the chapter in the HL7 Version 2 specification where the segment is defined so that the reader can go and get additional information. If a segment is optional, it is surrounded with square brackets. If the segment can repeat, it is surrounded with curly braces. The message definition shown here is for a patient admission message. It requires the MSH, EVN, PID, and PV1 segment. All the other segments are optional. The SFT, ARV, ROL, and NK1 segments can repeat. For example, a patient admission can have zero to any number of Next of Kin or Associated Parties because the NK1 segment is optional and repeats.
5.10 Figure (Lorenzi, V., 2016). Adapted from HL7 Version 2.7 Patient Admission Message Definition.
Health IT Workforce Curriculum Version 4.0

11. Examining an HL7 message
Trigger event code
E.g. patient admission = A01, patient transfer = A02, patient discharge = A03, etc.
Sample patient registration message has four segments:
Message header (MSH)
Event (EVN)
Patient identification (PID)
Patient visits (PV1)
In our example message, the trigger event was Patient Admission. All trigger events are represented by three character codes. The trigger event for Patient Admission is A01. Examples of other trigger event codes include A02 for patient transfer and A03 for patient discharge. In the example message, there are four segments – MSH, EVN, PID, and PV1. Note that there were none of the optional segments that were specified in the message definition. The first segment is MSH, which is the message header. The MSH segment tells the receiver about the message itself – the time and date it was created, the trigger event, the message type, and what version of HL7 was used. The second segment is the event segment, or EVN, which says more about the trigger event and when the actual event happened. The third segment is the patient identification segment, or PID, which gives the patient’s demographics. The fourth segment is the patient visit segment, or PV1, which gives information about the patient’s hospital visit such as the location of the admission, the attending doctor, and the admitting service.
Health IT Workforce Curriculum Version 4.0

12. Each segment has a segment definition
HL7 Implementation
Each segment has a segment definition
Each segment has a segment definition. This is the segment definition for the patient identification segment of PID. A segment definition includes a sequence number, which is just a logical sequence of the field within the segment; a suggested maximum length for the field; and a data type for the field. The data type can be simple or complex, and if it is complex, then it is further broken up into components and sub-components.
5.11 Figure (HL7 Version Standard). Used with permission.

13. Special characters are used to “encode” or “delimit” HL7 messages
Segment Terminator
<CR>
Ends every segment
Cannot be changed
Field Separator |
Separates adjacent fields
E.g. ORC|NW|12345….
Repetition Separator ~
Separates repetitions of a field
E.g. Winken~Blinken~Nod
Component ^
Separates components of a field
15545^GLUCOSE
Subcomponent
&
Separates subcomponents of a component
Trapp&Von^Maria
Escape \
Used to include delimiters as data
Special characters are used to encode or decode HL7 messages. The segment terminator ends every segment and cannot be changed. The field separator separates adjacent fields. The repetition separator separates repetitions of a field and the component separator separates components of the field and the sub-component separator separates sub-components of a component.
Health IT Workforce Curriculum Version 4.0

14. Encoding fields, components, subcomponents, and repetitions (F/C/S/R)
Precede each F/C/S/R with the appropriate separator
Put each F/C/S/R in order based on the Segment Definition
If a F/C/S/R is not present, continue with the next F/C/S/R
If F/C/S/R present but null, put “”
E.g. if Date of Birth is null on the sending system, send |“”|.
If no more F/C/S/R required, separators are not required
HL7 has special encoding rules which the sender follows to encode a message in the HL7 V2 message format for transmission. The sending system follows the format of the Message Definition as it creates the message. For each segment, it follows the order of fields in the corresponding segment definition. The sending system puts each field component, sub-component, and repetition in order based on the segment definition. If it finds that a field, component, sub-component, or repetition is not present, it skips it and continues with the next field component, sub-component and repetition. So then that would mean that if there is not present for a particular field, you get it with two vertical bars next to each to other and nothing in between. However, if the field component, sub-component, and repetition has the null value, meaning that it is an empty field on the sending system or it is deleted, the sending system would put double quotes to show that it has been deleted or it is null. For example, if the birthdate is empty on the sending system, the sending system would put double quotes in between the vertical bars. If there are no more fields, components, sub-components, or repetitions required and no data left to send, then separators are not required at the end and a carriage return is added to end the segment.
Health IT Workforce Curriculum Version 4.0

15. Encoding a PID segment 5.12 (Lorenzi, V., 2016)
Let’s look at encoding a PID segment. In this case, we have a patient named John J. Jones with the medical record number That medical record number was assigned by the assigning authority Good Clinic. If you look at the PID segment, you will figure out that PID five is the field that would contain patient name and PID three is the field that would contain the patient identifier. To build the segment, first you would put the segment ID, which is PID. Then you would proceed to the first field with the vertical bar and since you have no value for field one or field two, which are set ID and external patient ID, respectively, you would just put more vertical bars. You do have values for field three, which is internal patient ID and is broken up into components. The first component is the medical record number. Then you do not have anything for the 3.2 and 3.3. components. However, you have the assigning authority value, which is Good Clinic. Moving on to field four, which is alternate ID, you do not have any value, so you put nothing. For field five, which is patient’s name, you put the last name in 5.1 component, the first name in 5.2 component, and the middle name or initial in 5.3 component. If any of those fields had nulls because it was deleted or nothing existed, then you would see double quotes. Note that we ended the segment after the fifth field, or PID-5, because there is no more data and it is that last required field in the segment definition. The segment can send right after the name field since the sender has no more PID information about the patient to communicate and no fields after field 5 are required in the segment definition.
5.12 (Lorenzi, V., 2016)
Health IT Workforce Curriculum Version 4.0

16. Summary: Anatomy of an HL7 message
In summary, an HL7 Message is made up of segments. A segment is a group of related fields. Each segment begins with a three-character segment that ends with a carriage return. The very first segment of every message is the MSH segment. The fields in a segment can sometimes be further broken down into components and sub-components. Field components and sub-components are stringed together in a linear fashion with delimiters, such as a vertical bar, tilde, circumflex, and ampersand. These delimiters separate the fields of the components, sub-components, or repetitions., which is for the message header.
5.13 (Lorenzi, V., 2016)
Health IT Workforce Curriculum Version 4.0

17. HL7 V2 is used for most interfaces with laboratory information systems
We have been looking at a patient administration message, so now let’s look at a laboratory message as an example. This particular picture is from an implementation guide and shows how the lab results flow might work. Implementation guides constrain standards and give more information. This picture demonstrates a use case and the constraints within this specification. One constraint is that it is only for laboratory messages. Another constraint is that it requires that all lab tests be encoded using the LOINC standard terminology. In this particular scenario, the doctor sends an order to the lab results interface. The lab result interface in sends the order to the downstream system, which is in this case the lab. The lab receives the order and specimen, sends preliminary results, and sends final results later. The provider could provide corrections to the result. So, there is actually a bi-directional workflow that is happening here.
5.14 (HL7 Version Implementation Guide: S&I Framework Lab Results Interface, Release 1- US Realm). Used with permission.
Health IT Workforce Curriculum Version 4.0

18. Structure of a Results Message
Now that we discussed the workflow of a laboratory message, let’s look at the structure of the laboratory results message. This HL7 V2.4 Message definition has been abbreviated for teaching purposes. Like the patient administration message, the results message also has a required message header segment, or MSH. The PID and OBR segments are also required. The OBR Observations Report segment contains fields related to the execution of the lab order by the lab. For example, it contains the time the test was resulted. The actual test result is recorded using one on more OBX or Observation segments. For example, an electrolytes test would have several observations represented as OBX segments. It would have one for every electrolyte such as one for Potassium and one for Sodium.
5.15 Figure (Lorenzi, V., 2016). Adapted from HL7 Version 2.4.
Health IT Workforce Curriculum Version 4.0

19. Sample HL7 result message
Let’s look closer at a sample results message. You will see the MSH segment, the PID segment, the OBR segment while tells us the test is a Glucose reading, and the OBX segment, which contains the value of the result.
5.16 Figure (HL7 Version Edition, V3 Guide, V2 Example). Used with permission.
Health IT Workforce Curriculum Version 4.0

20. OBX: Observation / results detail segment
Here are the fields for the OBX, the observation details segment. The common fields include: identifier, units, references range, abnormal flags, responsible observer, and observation method.
5.17 Figure (HL7 V2®). Used with permission.
Health IT Workforce Curriculum Version 4.0

21. Limitations in HL7 Version 2
Too much optionality and ambiguity
Generic, not constrained to specific use cases
Interoperability standards and terminology standards are not integrated
Gaps and overlaps in standards
Conformance is often not specified
Typical HL7 legacy V2 interface installation requires site-specific analysis, specification, and coding
Implementation guides / profiles give detailed guidance and constraints and would reduce implementation cost
HL7 Version 2 has limitations. There are too many options and ambiguity in the specifications. It is too generic intended to work with a wide variety of use cases instead of being fully constrained to work for specific use cases. Its not well-integrated with terminology standards. There are gaps in functionality as well as overlaps with the functionality of other standards. Conformance is not often well specified. As a result, to make two systems inter-operable when both use HL7 Version 2 requires site-specific analysis, specification, and coding. When implementing HL7 Version 2, the implementor will ideally implement an HL7 V2 implementation guide or profile which gives detailed guidance and constraints and would reduce implementation variance and cost.
Health IT Workforce Curriculum Version 4.0

22. HL7 V2 Implementation Guides required for ONC 2014 and 2015 certifications for public health
HL Implementation Guide for Immunization Messaging, Release 1.5.
PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient and Ambulatory Settings, Release 2.0, April 21, 2015.
HL7 Version 2.5.1: HL7 Version Implementation Guide: Electronic Laboratory Reporting to Public Health, DSTU, Release 2 (US Realm), 2013
HL7 Version 2.4, HL7 Version 2.7, HL7 V Edition, S&I Framework Laboratory Results Interface
Speaking of implementation guides, here are some HL7 version 2 implementation guides that are required for ONC 2014 and 2015 certifications for public health. The examples here are for immunization messaging, syndromic surveillance, and laboratory reporting.
Health IT Workforce Curriculum Version 4.0

23. Unit 5: Standards for Interoperable Health IT, Summary – Lecture c, Introduction to HL7 V2®
Health Level 7, or HL7 Version 2®, is a widely adopted general health care interoperability standard
HL7 Version 2® defines standard trigger events and message types and defines how the messages are exchanged
Two common message types are the patient admission message and the laboratory result message
A HL7 message is comprised of strings of fields grouped into segments and separated by encoding characters
Although HL7 Version 2® is widely adopted, there are a lot of variances between implementations
Implementation guides are encouraged to resolve variances
This concludes Lecture c of Standards for Interoperable Health IT. To summarize, Health Level 7, or HL7 Version 2, is a widely adopted general health care interoperability standard. HL7 version 2 defines standard trigger events and message types and defines how the messages are exchanged. Two common message types are the patient admission message and the laboratory result message. A HL7 message is comprised of strings of fields grouped into segments and separated by encoding characters. Although HL7 version 2 is widely adopted, there is a lot of variances between implementations. To help resolve this, implementation guides are encouraged.

24. Standards for Interoperable Health IT References – Lecture c
HL7 Standard Version 2.4 Copyright 2000
HL7 Version Implementation Guide: S&I Framework Lab Results Interface, Release 1- US Realm
Charts, Figures, and Tables
5.7 Figure: Lorenzi, V A typical HL7 V2® messaging scenario.
5.8 Figure: Lorenzi, V How HL7 Version 2® messaging works.
5.9 Figure: HL7 Version 2.7 Standard Copyright©, An example admit message.
5.10 Figure: Lorenzi, V Adapted from HL7 Version 2.7 Patient Admission Message Definition. Example of a message definition.
5.11 Figure: HL7 Version Standard. Segment definition.
5.12 Figure: Lorenzi, V Encoding a PID segment.
5.13 Figure: Lorenzi, V Anatomy of an HL7 message.
No audio.

25. Standards for Interoperable Health IT References – Lecture c (Cont’d)
Charts, Figures, and Tables
5.14 Figure: HL7 Version Implementation Guide: S&I Framework Lab Results Interface, Release 1- US Realm. HL7 V2 interface with laboratory information systems.
5.15 Figure: Lorenzi, V Adapted from HL7 Version Structure of a results message.
5.16 Figure: HL7 Version Edition, V3 Guide, V2 Example. Sample HL7 results message.
5.17 Figure: HL7 V2®. Observation / results detail segment.
No audio.

26. Unit 5: Standards for Interoperable Health IT, Lecture c – Introduction to HL7 V2®
This material was developed by Columbia University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number 90WT0004.
No audio.