1. Introduction to HL7
Bhushan Borole.
Date : 27-Sep-2012

2. Agenda
 What, Why, When HL7?
 Need of HL7
 HL7 in Healthcare Management Systems
 Message
 Message encoding schemes
 V2 and V3

3.  What, Why, When HL7?
 Need of HL7
 HL7 in Healthcare Management Systems
 Message
 Message encoding schemes
 V2 and V3

4. What? What is HL7 (Health Level Seven)?
• Protocol for data exchange between computer
systems in health care environments.
• Defines messages as they are exchanged and the
procedures used for exchanging them.
• Refers to the top layer (Level 7) of OSI/ISO layer
model (see next slide).
• ANSI standard since 1997 most widely used in
USA, Canada, Australia, New Zealand and Japan.

5. What is HL7 (Health Level Seven)?
HL7 contains message standards covering:
•Patient Administration
•Orders for Clinical Services and Observations,
Pharmacy, Nutrition and Supplies order entry
•Patient Accounting and Charges
•Observation Reporting
•Document Management Services
•Appointment Scheduling
•Laboratory Automation
•Personnel Management
•…

6. What is HL7 (Health Level Seven)?
Type of network communication
Application
(e-mail, telnet, FTP, HL7)
Presentation Data conversion, encryption
Controlling dialogues (sessions).
Session Establishing, terminating and
restarting connection.
Transport Routing, reliable data
TCP/IP transport between two
computers
Network
Network adapter: Ethernet, wireless
Data-Link
Ethernet
Physical Physical link: Ethernet cable, RS-232,
optical link

7.  What, Why, When HL7?
 Need of HL7
 HL7 in Healthcare Management Systems
 Message
 Message encoding schemes
 V2 and V3

8.  A Complete Solution
 Interoperability
 Open System

9. Interoperability…
 “Interoperability is the ability of two or
more systems or components to
exchange information and to use the
information that has been exchanged.
• ‘Functional’ interoperability is the capability
to reliably exchange information without
error.
• ‘Semantic’ interoperability is the ability to
interpret, and, therefore, to make effective use
of the information so exchanged.”
• ‘Process’ Interoperability makes system
Integral to (healthcare delivery) process,
work flow.

10. Interoperability Definition -
(U.S. Executive Order)
“’Interoperability’ means the ability to communicate
and exchange data accurately, effectively, securely,
and consistently with different information technology
systems, software applications, and networks in
various settings, and exchange data such that clinical
or operational purpose and meaning of the data are
preserved and unaltered.”
- President Bush, 22 August 2006

11. A Very Brief History of HL7
HL7 = Health Level 7
2.X
Founded in 1987-
2.0 was created in 1988 –
2.1 ->2.3 1990-1999
versions 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.5.1 and 2.6.
3.0

12. EHR Interoperability Model Objectives
1. Establish a common reference for EHR Record Interoperability -
Statement of requirements
2.Gain industry consensus via HL7’s (ANSI accredited) open, standards
development process
3.Establish current and forward benchmarks to achieve persistent legal
EHR Records
4.Establish testable conformance criteria for validation of EHR Records.
5.Specify EHR Record in context of its flow and lifecycle including
Preservation of semantic meaning.
6.Specify EHR Record in context as immediate record (documentation) of
Health(care) delivery process
7.Specify Common EHR Record Unit, sufficient to document all
healthcare Acts/Actions Establish as Complementary companion to EHR-
S Functional Model

13. Proprietary system model:
• Closed-system model is easier to design and
initially costs less to implement
• Greater reliability on single vendors
• More reliance on specific applications and
technologies

14. Adhering to a standard protocol is called "open system
architecture". Anybody can interface with an open system
using appropriate protocols, independent of its vendor. When
using HL7, the interface allows for numerous systems to be
added to a single HL7 feed.

15.  What, Why, When HL7?
 Need of HL7
 HL7 in Healthcare Management Systems
 Message
 Message encoding schemes
 V2 and V3

16. HL7 in Healthcare
Management System

17. Outbound Vs Inbound
Inbound – Data coming to the application
Outbound – Data being exported out of application.
So all data being passed from MaximEyes SQL
EHR to external application is called Outbound and
all data being passed into MaximEyes SQL EHR is
called Inbound.

18. ConnectEngine
HL7 Specification
Messages Tool (e.g., nHapi)
External • Profile based
• Structurally correct MaximEyes
Application • Validated
• Varied
• Descriptive
• Suitable basis for HL7Utility
SQL EHR
conformance testing
ConnectEngine
Utility
Inbound ...

19. ACK
Every time an application accepts a message and
processes the data it sends an Acknowledgement
back to the sending application. The important part
of an ACK is that it means the other systems has not
only received but processed the message that was
sent.
NACK is a negative ACK that contains an error in
that is sent back to the sending application.

20.  What, Why, When HL7?
 Need of HL7
 HL7 in Healthcare Management Systems
 Message
 Message encoding schemes
 V2 and V3

21. What’s the Message
Messages are the base format used for all HL7
communication
Data formatted with HL7 Encoding Rules and
Message Construction Rules.
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.
“Z”

22. Message Type
Type of message describes the content – What
part of Message
Defines the purpose for the message being sent
Ex. ADT Message type is used to transmit portions of a
patient's Patient Administration (ADT) data from one
system to another.
Refers HL7 Table 0076 - Message type
Position in Message - MSH field 9.1

23. Trigger Event
Type of message describes the content – Why part
of message
There is a one-to-many relationship between
message types and trigger event codes.
explicit set of conditions that initiate the transfer
of information
Refers HL7 Table 0003 - Event type
Position in Message - MSH field 9.2
A patient is registered(A04)
An appointment is booked (S12)

24. Message structure
ADT^A04 Register a patient
ADT^A08 Update patient information
ADT^A01 Admit/visit notification
ADT^A23 Delete a patient record
MFN^M02 Master file - staff practitioner
MFN^M05 Patient location master file
ORU^R01 Unsolicited transmission of an observation
message
VXU^V04Unsolicited vaccination record update

25. Delimiters
Special characters that separate one composite in a segment
from another, or separate one sub-composite from another.
Character Description
<CR> or 0x0D Segment
Delimiter/Terminator
| Field(Composite) delimiter
^ Sub-field (Component)
delimiter
& Sub-sub field
(subcomponent) delimiter
~ Repetition delimiter
ESCAPE Character

26. Character Escape Sequence
& T
^ S
| F
~ R
E
Hexadecimal character
Xxx..
xx

27. Segments
Each line in a message is referred to as a Segment.
Segments are units that comprise messages. Hence each Segment
has its own semantic purpose or function
There are over 120 types of Segments that can be used.
A segment is defined as a sequence of fields
Examples of HL7 message segments:
• MSH - Message Header
information about a message
• EVN - Event Type
event information
• PID - Patient Identification
information about a patient
• NK1 - Next of Kin
information about the patient's other related parties
• OBR - Observation Request
information about an order
• OBX - Observation Report
information about a result
“Z”

28. More on segments
•Segments and segment groups A segment is a logical
grouping of data fields.
•Segments of a message may be required or optional.
•Each Segment provides a specific type of data to be
sent.
•Some segments such as OBX, NTE, NK1, or AL1 can
be repeating.
•An example is the NK1 segment which consists of
“next of kin/associated parties" will repeat several
times if a person has several next of kin relationships

29. Message structure
HL7 Message Example

30. Fields (Composites)
A field is a string of characters.
Fields for use within HL7 segments are defined by HL7.
HL7 does not care how systems actually store data within
an application. When fields are transmitted, they are sent
as character strings.
Fields are the specific fields of a segment. The fields can
be either a primitive data type such as a string number,
alpha or alphanumeric or it can be made up of other
composites (components).
Null. Any existing value for the corresponding data base
element in the receiving application should be deleted.
This is symbolically communicated as two double-quotes
between the delimiters (i.e., |""|)

31. Fields (Continued..)
Have constraint for –
• Position - Ordinal position of the data field within the segment
• Data type - Basic building block used to construct or restrict the contents of a data.
• Optionality Whether the field is required, optional, or conditional in a segment.
Value Description
R Required
O Optional
C Conditional
X Not used with this trigger event
B Backward compatible

32.  Repetition - Whether the field may repeat.
 Maximum length - Max number of characters that
one occurrence of the data field may occupy.
 Fields are restricted for structure by HL7 defined
Datatypes.
 Count is 160+ for 2.5.1

34. Data Exchange
•No data exchange, messaging and communication
technologies are determined by HL7.
•Frequently used protocols in HL7 implementations:
 MLLP (Minimal Lower Layer Protocol)
 TCP/IP based
 SOAP (Simple Object Access Protocol) – XML
based
 Batch Files – messages in text files exchanged
by FTP and SMTP or offline via a tape or a
diskette

35.  What, Why, When HL7?
 Need of HL7
 HL7 in Healthcare Management Systems
 Message
 Message encoding schemes
 V2 and V3

36. Message encoding schemes
HL7 uses two encoding schemes:
• HL7 ER, also known as 'traditional' HL7 format;
 used for HL7 versions 2.x
• XML
 primary encoding scheme for HL7 v 3.0
 can be used for HL7 v 2.x in environments
where sender and receiver both understand XML

37. Message encoding schemes
HL7 ER
Sample message encoded in HL7 ER format

38. Message encoding schemes
XML
Sample message encoded using XML scheme
<!DOCTYPE ACK SYSTEM "hl7_v231.dtd">
<ACK>
<MSH>
<MSH.1>|</MSH.1>
<MSH.2>^~&amp;</MSH.2>
<MSH.3>
<HD.1>LAB</HD.1>
<HD.2>foo</HD.2>
<HD.3>bar</HD.3>
</MSH.3>
<MSH.4><HD.1>767543</HD.1></MSH.4>
<MSH.5><HD.1>ADT</HD.1></MSH.5>
<MSH.6><HD.1>767543</HD.1></MSH.6>
<MSH.7>19900314130405</MSH.7>
...
...
</MSH>

39. Message encoding schemes
HL7 is not Plug & Play
•Basic reasons – Missing Fields, Same Data in
Different Fields, Same Data in Different Formats,
Different Versions, Missing Values (including
mandatory fields), Invalid Segment Grammar
•Not all data types may be coded using standard HL7
format. For these types vendor specific messages and
fields must be used.
•When deploying system utilizing HL7 interface, it still
must be adapted to hospital-specific requirements.

40.  What, Why, When HL7?
 Need of HL7
 HL7 in Healthcare Management Systems
 Message
 Message encoding schemes
 V2 and V3

42. HL7 V2
• Not “Plug and Play” – it provides 80 percent of the
interface and a framework to negotiate the remaining 20
percent on an interface-by-interface basis
• Historically built in an ad hoc way because no
other standard existed at the time
• Generally provides compatibility between 2.X
versions
• Messaging-based standard built upon pipe and hat
encoding
• In the U.S., V2 is what most people think of when
people say “HL7?

43. HL7 V3
• Approaching “Plug and Play” – less of a
“framework for negotiation”
• Many decades of effort over ten year period
reflecting “best and brightest” thinking
• NOT backward compatible with V2
• Model-based standard built upon Reference
Information Model (RIM) provides consistency across
entire standard
• In the U.S., when Clinical Document
Architecture (CDA) is what most people in the U.S.
think of when people say “HL7 V3?

44. The difficulties with HL7 3.0 :
1.Despite the length of time it has been under development, the
3.0 standard has not yet been clearly defined.
2.Very few health-care facilities have migrated to version 3.0,
since this version is not compatible with version 2.X.
Applications that support version 3.0 would also need to support
version 2.X.
3.Creating an interface between version 2.X and version 3.0
would be difficult and expensive.
Because of these difficulties, version 2.X remains the standard
that is used by both healthcare facilities and vendors.

45. HL7 interface should not be contained on a mobile device
•HL7 interfaces need to be persistent
•Configuration and change management
•Licensing concerns
•Database and storage issues: