You are on page 1of 37

E-LEARNING COURSE

HL7 2X
INTRODUCTION TO HL7 VERSION
2.X, DATA TYPES, ACK

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

HL7 E-LEARNING COURSE


MODULE I - INTRODUCTION
UNIT I.1
INTRODUCTION TO HEALTHCARE INTEROPERABILITY
UNIT I.2
INTRODUCTION TO VOCABULARIES IN HEALTHCARE
UNIT I.3
INTRODUCTION TO UNIFIED MODELING LANGUAGE (UML)
UNIT I.4
INTRODUCTION TO EXTENSIBLE MARKUP LANGUAGE (XML)
MODULE V HL7 V2.x
UNIT V.1
INTRODUCTION TO HL7 VERSION 2.X, DATA TYPES, ACK
UNIT V.2
HL7 V2.X: PATIENT ADMINISTRATION, ORDERS AND RESULTS
UNIT V.3
HL7 V2.X: Z-SEGMENTS / IMPLEMENTATION / PROFILES
UNIT V.4
HL7 V2X.XML: XML IMPLEMENTATION OF V2.X MESSAGING
MODULE T HL7 V3
UNIT T.1
INTRODUCTION TO HL7 V3
UNIT T.2
REFERENCE INFORMATION MODEL RIM / DERIVED MODELS
UNIT T.3
HL7 V3 DATA TYPES AND THEIR XML REPRESENTATION
UNIT T.4
HL7 V3: FROM THE MODEL TO THE MESSAGE
MODULE C HL7 CDA R2
UNIT C.1
INTRODUCTION TO HL7 CDA R2
UNIT C.2
CDA R2 ARCHITECTURE: HEADER, BODY AND ENTRIES
UNIT C.3
CDA R2 IMPLEMENTATION GUIDES
UNIT C.4
CDA R2 ENTRIES: CLINICAL STATEMENT
Language: EN (ENGLISH)

HL7ELC_V_EN_U01_V01.2

Version: 1.2

Year: 2009

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

Table of Contents
Introduction to HL7 v2 ...................................................................................................4
Health Level 7 (HL7) .......................................................................................................5
HL7 Mission (as an organization)..............................................................................5
HL7 version 2 ...................................................................................................................8
What is HL7 V2.x?........................................................................................................8
How is the HL7 V2.x standard organized? ..............................................................8
How do we read the HL7 V2.x standard? ............................................................10
Communication environment ...................................................................................12
Message ........................................................................................................................12
Segments ...................................................................................................................13
Fields...........................................................................................................................17
Components .............................................................................................................17
Subcomponents .......................................................................................................18
Message delimiters...................................................................................................18
Summary....................................................................................................................19
Summary....................................................................................................................19
Data types.....................................................................................................................20
Categories.................................................................................................................20
Alphanumeric Data Types ..................................................................................21
Data Types for Numbers and Quantities...........................................................22
Data Types for Times and Dates.........................................................................24
Data Types for Identifiers .....................................................................................25
Data Types for Coded Values ............................................................................29
Data types for Addresses, Persons, Organizations, and Phone Numbers ...31
Data Types for Multimedia Objects ...................................................................32
Message Processing Rules ..........................................................................................34
Sending Rules ............................................................................................................34
THE TEN OUTBOUND HL7 COMMANDMENTS ........................................................34
Receiving Rules.........................................................................................................35
THE TWO INBOUND HL7 COMMANDMENTS ..........................................................35
Acknowledgement of Message Reception (ACK).............................................35
Original mode .......................................................................................................35
Enhanced mode ..................................................................................................36

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

INTRODUCTION TO HL7 V2
Goals of this unit:
Understand the mechanics of message exchange.
Write a simple V2.x message header (and some other message fragments).
Read and understand an HL7 v2.x message.
To help define the scope of HL7 V2.x were going to review some basic information;
much of which you may be familiar with. Please take a moment to review this
information so we can avioid any misconceptions.

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

HEALTH LEVEL 7 (HL7)


Founded in 1987, HL7 is the only standards development organization (SDO)
committed solely to the helthcare domain.
HL7 V2.x is an implementation of healthcare information exchange at layer 7 of the
OSI (Open Systems Interconnection) network model, hence its name: Health
[Information at] Level 7 [of the OSI model].
For more information on the ISO/OSI network model, we recommend:
http://en.wikipedia.org/wiki/OSI_model

Function

Communication

Application

Presentation

5
4

Session
Transport

Network
Data Link
Physical

2
1

HL7

HL7 Mission (as an organization)


HL7 defines its mission as providing standards for interoperability that improve care
delivery, optimize workflow, reduce ambiguity and enhance knowledge transfer
among all of our stakeholders, including healthcare providers, government agencies,
the vendor community, fellow SDOs and patients. [http://www.hl7.org/about]
HL7 standards define messages and message exchange protocols that support
clinical practice and management. Remember that in the first part of UNIT 1, you saw
that clinical management is a broad concept that tries to analyze the cost and
effectiveness of medical acts in order to define healthcare policies that will achieve
and maintain high quality outcomes.
Data exchange between health care
applications is essential to achieving that goal.

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

HL7 has accepted responsibility for creating flexible, cost-effective standards,


guidelines and methodologies that provide interoperability between healthcare
systems and the exchange of meaningful electronic health information.
Since 1994 the organization has been accredited by the American National
Standards Institute (ANSI) as a Standards Developing Organization (SDO). As an SDO,
HL7 has adopted a structure and formal procedures to achieve consensus and a
balance of interest among its various stakeholders: systems and application vendors,
health insurance companies, governmental jurisdictions, universities, hospitals, health
care providers, consultants, etc.

The use of HL7 standards worldwide has been made possible in large part by the
more than 500 companies that have organizational membership, representing more
than 2000 members, and more than 30 international affiliate organizations. About a
quarter of the worldwide membership meets periodically in Working Group Meetings.
Table 1 lists some of the nations represented by HL7 Affiliate organizaitons.
Table 1 - International affiliates
Argentina

Australia

Brazil

Canada

China

Croatia

Czech Rep.

Denmark

Finland

Germany

Greece

India

Ireland

Italy

Japan

Korea

Lithuania

Mexico

New Zealand

Poland

Spain

South Africa

Switzerland

Taiwan

Netherlands

United Kingdom

Uruguay

Recently, affiliates representing Chile, Colombia, and Singapore joined HL7, as the
organization continues its trend of steady growth. All these countries have their own
independent affiliate organizations and are represented on an Affiliate Council for
international harmonization and adapting standards in different parts of the world.
The first HL7 messaging standards, Version 1.0 and Version 2.0, were approved in 1987
and 1988 respectively. Since then various release updates of V2 have been
published:

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

1990

1994

1997

1999

2000

2003

2007

2008

2.1

2.2

2.3

2.3.1

2.4

2.5

2.5.1

2.6

This course is ased on v2.6, which is widely supported by existing applications. Usually
applications encode HL7 messages using pure ASCII text with a flat file format.
HL7 V2.x has fewer semantic restrictions that is to say, it does not specify the
underlying model and the vocabulary as strictly as HL7 Version 3. Efforts have been
initiated to align the HL7 V2.x standards with the Version 3 Reference Information
Model (RIM)
HL7 has also developed a specification for encoding V2.x messages in XML (V2.XML).
Our initial focus will be on HL7 V2.x, a messaging standard for the exchange of
administrative, financial or clinical data, HL7 also provides other standards including
the following:

HL7 Clinical Document Architecture (CDA) is a very important initiative within


HL7, defining a standard for the exchange of clinical documents, such as
discharge or consultation notes and summaries, imaging and laboratory
reports, etc. This model is typically encoded in XML. CDA Release 2.0 is closely
aligned with the Version 3 Reference Information Model and uses V3 data
types. The CDA specifications are flexible and allow for the use of templates
according to different scenarios and settings. In a later unit, we shall discuss
CDA and examine several examples of CDA implementations.
Arden Syntax is a grammar for expressing and sharing rules of clinical
knowledge, which generally are well developed in clinical practice guidelines.
For example, a rule can be formulated in Arden Syntax such that if a patient is
to be administered digoxin but his potassium is less than 3 mEq/L, an alarm
may be generated to suspend the medication.
CCOW (a standard developed by the Clinical Context Object Workgroup) is a
framework for sharing context (user, patient, study) between applications and
allowing single sign-on and desktop sharing among applications.

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

HL7 VERSION 2
What is HL7 V2.x?

Development of incremental releases of HL7 V2, which have come to be referred to


collectively as HL7 V2.x, began in 1988. HL7 V2.x is a protocol for the exchange of
clinical data through messages.
What HL7 V2.x is not includes the following:

It is not an application
It is not a data structure or a database specification.
It is not an architecture to design applications for hospitals.
It is not a specification for a message router.

Typically, HL7 V2.x messages are encoded as ASCII text strings with delimiters. HL7
V2.x has few inherent semantic restrictions; the vocabulary to include in the codified
elements of the messages is usually subject to negotiation between the parties.
HL7 V2.x defines the context of each field for example, diagnosis - but
may leave the decision of whether field contents should be free text or
use a standard terminology up to the implementers. That decision is
typically agreed upon between the issuer and the recipient of the
message.

The standard does not define how the messages are sent (directly over TCP/IP,
through file transfers, via a serial port, through a Web service, etc.) These are called
`low level' or `transport' protocols; while HL7 V2.x sometimes offers guidance in this
regard, none of these lower-level protocols is mandatory or normative in the HL7
standard.

How is the HL7 V2.x standard organized?


HL7 v2.x is organized into chapters, each of which has a specific purpose or domain.

Chapter 2 defines how to encode and decode messages, whereas the rest of the
chapters concentrate on an area or domain of healthcare information addressed by
a specific Work Group. The combined output of these Work Groups must be
approved by a consensus group with broad representation of the HL7 membership
before a version of the standard may be published.

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

Membership in a Work Gorup is open to any HL7 member or other party interested in
that specific area. Work Groups are responsible for incorporating additions or
changes to their respective areas of the Standard.

The final product of the Working Group is a version of the HL7 V2.x standard, of which
the most recent version as of this writing is V2.6. Each chapter contains the necessary
information to create messages relevant to that chapters domain, as well as
appropriate references to the content (such as element definitions) of other chapters.
For example, Chapter 10, Scheduling, makes reference to the PID
segment, which conveys information about the patient. The PID segment
is not defined in Chapter 10; instead the reader is referred to Chapter 3
which defines the PID segment.

Table 2 describes the chapters that make up HL7 V2.6


Table 2 - Chapters of Version 2.6
CAP.

SCOPE / DOMAIN

01

Introduction

02

Control (Structure of the messages/Conformance)

03

Patient Administration (admission , discharge, transfer)

04

Order Entry (laboratory, pharmacy, etc.)

05

Query

06

Financial Management (Billing / Patient Accounts)

07

Observation Reporting (results sent as identifiable elements - laboratory,


imaging, etc.)

08

Master Files

09

Medical Records/Information Management (document management

10

Scheduling

11

Patient Referral

12

Patient Care

13

Clinical Laboratory Automation

14

Application Management

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

15

Personnel Management

16

Claims & Reimbursement

17

Materials Management

How do we read the HL7 V2.x standard?


In order to be able to use the standard it is essential to know Chapter 2, Control.
Mastery of this chapter will enable you to apply the rest of the standard, which is why
a Control Specialist Certification program has been developed for HL7 V2.x.
As mentioned in previous paragraphs, the chapters following Chapter 2 define the
elements (message types, trigger events, segments, and fields) required to build
messages appropriate to a specific domain of the information system.
Each of these domain chapters typically includes the following parts:
introduction/scope
trigger events
message definition
examples
outstanding issues

Figure 1 shows a basic model of an HL7 transaction.

System B

RECEIVE A
MESSAGE
SEND AN
ANSWER

Trigger event

SEND A
MESSAGE
RECEIVE AN
ANSWER

NETWORK

System A

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

10

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

Figure 1 - Basic model of transaction

The model is quite basic: a trigger event (something that ocurred in the real world)
causes System A to send a message. This message is received by System B, which
sends a response back to System A.

As a real-life example; when a patient is admitted into the hospital, the


patient registration system sends a message to the billing system to inform
it of the new patient and request than an account be opened for this
episode. This message is received by the billing system, which sends a
response message to the patient registration system confirming that the
original message has been processed.

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

11

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

COMMUNICATION ENVIRONMENT
The HL7 Standard assumes that the communication environment will provide the
following capabilities:
Error-free transmission. Applications can assume that they will correctly receive
all of the transmitted bytes in the order in which they were sent. This implies that
error checking is done at a lower level.
Character conversion. In a case where different machines use different
representations (e.g., ASCII-EBCDIC) the communication environment will be
expected to convert the data from one representation to the other.
Message Length. HL7 sets no limits on the length of a message. The standard
assumes that the communication environment can transport messages of any
length necessary.

MESSAGE
A message is the atomic unit of data transferred between systems. Figure 2 shows a
typical HL7 message.
MSH|^~\&|NSI||LAB||20090627120759||ADT^A01^ADT_A01|NSI1|P|2.6<cr>
EVN|A01|20090627120759<cr>
PID|1|||444-22-2222^^^HC^MR|EVERYWOMAN^EVE^E||19780113000000|F|||2222
HOME STREET^^ANN ARBOR^^99999<cr>
NK1|1|EVERYMAN^ADAM|SPO|2222 HOME STREET|555-555-2004<cr>
PV1|1|I|301|R|||1436^PRIMARY^PATRICIA^P|1026^ADMIT^ALAN|998^ATTEND^AA
RON|M|||A|4|A0|N|1026^SENDER^SAM|OB|H0100240|||||||||||||||||ALV|
|||||||20080123095130|20080123102455<cr>
IN1|1|INT|HCPAYOR|HC PAYOR INC<cr>
Figure 2 - A01 Sample Message

Each message contains:


1. segments
2. fields
3. delimiter characters
4. components

Lets look at these elements of the message in a little more detail.

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

12

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

Segments
A HL7 segment is a logical grouping of data fields. Segments of a message may be
required or optional. They may occur only once or they may be allowed to
repeat. Each segment is identified by a three character code, known as the
Segment ID, and a name. For example, the ADT message may contain,
among others, the following segments: Message Header (MSH), Event Type
(EVN), Patient ID (PID), and Patient Visit (PV1).

Segment ID codes beginning with the letter Z are reserved for locally
defined segments. Such constructs are useful for the exchange of
information not defined by the standard. However, caution must be
exercised when using Z segments and other locally defined structures.
Well see more about that later.
The following table shows the segments that might be transmitted in a typical patient
registration message (message type ADT). This is commonly referred to as an abstrat
message syntax.

MSH

Message Header

EVN

Event Information

PID

Patient Identifiers and Demographic Data

[PD1]
[{ NK1 }]

Additional Demographic Data


Patient Next of Kin/Associated Parties

PV1

Patient Visit/Encounter Information

[PV2]

Patient Visit Additional Information

[{ DB1 }]

Disability Information

[{ AL1 }]

Allergy Information

[{ DG1 }]

Diagnosis Information

[DRG]

Diagnosis Related Group

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

13

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

[{ PR1}]

Procedures

[{ROL}]

Role

[{ GT1 }]

Guarantor

[{IN1}]

Insurance

[IN2]

Insurance Additional Information

[IN3]

Insurance Additional Information cert.

[ACC]

Accident Information

PLEASE REMEMBER THESE RULES


a) If the segment ID appears between square brackets [...] then the segment is
optional.
b) If the segment ID appears between curly braces {}
repeat.

then the segment may

c) If the segment ID appears between both curly braces and square brackets [{}]
then it is both optional and repeating.
Each segment is composed of a number of fields which well discuss later in this unit.
The first segment (MSH) identifies the type of message and the trigger event that
caused the message to be sent. A real-world event that triggers a message
exchange is called a trigger event.

The message types are logical aggregators that assign the same category to a group
of events. For example, messages of type ADT will be used to transmit information
about all patient registrations and updates. Within the ADT message type we find
over 60 different trigger events, such as the admission of the patient, a change in
location of the patient, or discharge of a patient. Thus, a message for trigger event
A01 indicates that a new patient has been admitted. The A02 trigger event indicates
that the patient has changed location, while trigger event A03 indicates that the
patient was discharged.

The relationship between message type and trigger event is one to many.
Each message type may be associated with more than one trigger event.
However, each trigger event is associated with one and only one
message type (and its associated application acknowledgment).

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

14

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

Figure 3 shows an example of transactions between two systems using Chapter 3


messages and trigger events.

ADT^A01

System
A
Trigger
Event A01

System
B

Accept ACK

ADT^A02

Trigger
Event A02
Accept ACK

Figure 3 V2.x Chapter 3 Transactions

When a patient admission is recorded, a message of type ADT event A01 is sent.
Likewise, to report a change of patient location, a message of type ADT event A02 is
sent.
In both cases the receiving system returns a message of type ACK (general
acknowledgment).
Usually the information in an ADT message type has been entered into the patient
administration system and is then transmitted to other systems throughout the
organization.

For example, an A01 event can be used to notify the laboratory system
that a patient has been admitted and that studies can be requested for
the patient. It also contains the patients location, sex, and age.

If the patient is subsequently transferred to a new permanent location, an A02 trigger


event is used to notify the laboratory of the new location, so the lab will be able to
locate the patient when needing to perform a phlebotomy.

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

15

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

An abstract message syntax, such as that shown for the ADT message above, defines
which segments make up the message, as well as their order, grouping, and
optionality. However, the abstract message syntax does not describe the segment
content.
Two or more segments may be organized as a logical unit called a segment group.
As with individual segments, a segment group may be required or optional. A
segment group is assigned a name that represents a permanent identifier that may
not be changed; unlike an individual segment ID, the name of a segment group
generally does not appear in the HL7 message.
Table 4 shows the attributes of the first 18 fields of the PV1 segment, as defined in V2.6:
SEQ

LEN

DT

OPT

SI

RP/#

TBL#

0004

ITEM#

ELEMENT NAME

00131

Set ID - PV1

00132

Patient Class

00133

Assigned Patient Location

00134

Admission Type

IS

80

PL

IS

250

CX

00135

Preadmit Number

80

PL

00136

Prior Patient Location

250

XCN

0010

00137

Attending Doctor

250

XCN

0010

00138

Referring Doctor

250

XCN

0010

00139

Consulting Doctor

0069

00140

Hospital Service

00141

Temporary Location

0007

10

IS

11

80

PL

12

IS

0087

00142

Preadmit Test Indicator

13

IS

0092

00143

Re-admission Indicator

14

IS

0023

00144

Admit Source

15

IS

0009

00145

Ambulatory Status

16

IS

0099

00146

VIP Indicator

17

250

XCN

0010

00147

Admitting Doctor

18

IS

19

250

CX

20

50

FC

21

IS

22

23

0018

00148

Patient Type

00149

Visit Number

0064

00150

Financial Class

0032

00151

Charge Price Indicator

IS

0045

00152

Courtesy Code

IS

0046

00153

Credit Rating

24

IS

0044

00154

Contract Code

25

DT

00155

Contract Effective Date

26

12

NM

00156

Contract Amount

27

NM

00157

Contract Period

28

IS

0073

00158

Interest Code

29

IS

0110

00159

Transfer to Bad Debt Code

30

DT

00160

Transfer to Bad Debt Date

31

10

IS

00161

Bad Debt Agency Code

32

12

NM

00162

Bad Debt Transfer Amount

HL7ELC_V_EN_U01_V01.2

0021

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

16

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

33

12

NM

00163

Bad Debt Recovery Amount

34

IS

00164

Delete Account Indicator

35

DT

00165

Delete Account Date

36

IS

0112

00166

Discharge Disposition

37

47

DLD

0113

00167

Discharged to Location

38

705

CWE

0114

00168

Diet Type

39

IS

0115

00169

Servicing Facility

40

IS

0116

00170

Bed Status

41

IS

0117

00171

Account Status

42

80

PL

00172

Pending Location

43

80

PL

00173

Prior Temporary Location

44

24

DTM

00174

Admit Date/Time

45

24

DTM

00175

Discharge Date/Time

46

12

NM

00176

Current Patient Balance

47

12

NM

00177

Total Charges

48

12

NM

00178

Total Adjustments

49

12

NM

00179

Total Payments

50

250

CX

0203

00180

Alternate Visit ID

51

IS

0326

01226

Visit Indicator

52

250

XCN

0010

01274

Other Healthcare Provider

0111

Table 4 PV1 segment definition

Each column in the table defines a specific attribute of the segment:


SEQ: Ordinal position of the field within the segment.
LEN: Maximum number of characters that the field may contain.
DT: Data type defined by HL7.
OPT: Field Optionality (R-required, O-optional, C-conditional, X-discontinued, Bmaintained for backward compatibility with previous versions)
RP #: Repetition, maximum number of occurrences allowed
TBL #:Domain of possible values
ITEM: an integer number that uniquely identifies the field
ELEMENT NAME: the field name

Fields
A field is a string of characters defined by an HL7 data type. Appendix A of the HL7
V2.x standard provides an alphabetical list of all fields.

Components
Depending on its data type, a field can have one or more components. A model of
the components of each field in a segment is contained in the chapter of the HL7
HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

17

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

standard in which the segment is defined. Figure 4 below, shows the eight
components of patient name (data type XPN) as defined in HL7 V2.3.1.

Figure 4

3.3.2.5 Patient name (XPN) 00108


Components: <family name (ST)> ^ <given
name (ST)> ^ <middle initial or name
(ST)> ^ <suffix (e.g., JR or III) (ST)>
^ <prefix (e.g., DR) (ST)> ^ <degree
(e.g., MD)(ST)> ^ <name type code (ID)>
^ <name representation code (ID)>
Subcomponents
Note that when a field (as defined by its data type) is made up of multiple
components, each component itself is assigned a data type. When the data type
specifying a component is itself made up of multiple components, each of its parts is
called a subcomponent.
In the example above none of the components contains subcomponents.

Message delimiters
In constructing a message, certain special characters are used. The recommended
delimiters are:

Segment Terminator

<CR> (ASCII 13)

Field separator

(ASCII 124)

Component Separator

(ASCII 94)

Subcomponent Separator

&

(ASCII 38)

Repetition Separator

(ASCII 126)

Escape Character

(ASCII 92)

With the exception of the Segment Terminator <CR> any of these delimiters can be
modified by negotiation during the implementation.

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

18

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

Summary
A message consists of segments separated from each other by the segment
terminator (always <CR>). Each segment consists of fields separated by the field
separator (usually |). Each field is composed of one or more components separated
by the component separator (usually ^) and each component corresponds to a
specific data type. Depending on its data type, a component can contain one or
more subcomponents separated by the subcomponent separator (usually &).

MESSAGE
SEGMENTS
FIELDS
DATA TYPES
COMPONENTS

The next section will address the data types that define components and
subcomponents within fields.

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

19

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

DATA TYPES

Each HL7 element is defined as having a data type; the HL7 V2.x standard defines
over 80 different data types.
A data type may have a single component or may be defined as a set of
components. The purpose of a data type is to constrain the contents of a field.
Starting in HL7 Version 2.5, each data type has a defined maximum length.
In the segment attribute table (table 4 of part 1) the data type defining the structure
of each field is indicated in the DT column.

Categories
Data types tend to fall into logical categories:
Alphanumeric (ST TX FT SRT)
Numerical (CQ MO NM SI SN)
Identifiers (ID IS HD EI RP PL PT VID)
Date / Time (DT TM TS)
Coded values (CE CF CK CX XCN CNE CWE)
Generic (CM)
Demographic (AD PN TN XAD XPN XON XTN SAD FN)
Waveforms (CD MA NA ED)
Price (CP)
Finance (FC)
Master File tables (DLN JCC VH)
Medical records(PPN)
Temporary series (DR RI SCV TQ)
We wont review all V2.x data types in this unit, only some of the more common ones.

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

20

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

Alphanumeric Data Types


Alphanumeric data types may contain any ASCII printable character. Table 5 shows
these data types and their characteristics.
Table 5 - Alphanumeric data types
Data type

Characteristic

ST - String

Left justified, trailing spaces optional. Used for short


strings of <200 characters, intended for machine
consumption.
Strings longer than 200 characters, or intended for user
display, will usually be of data type TX or FT

TX - Text

Intended to be shown to the user through a terminal or


a printer. This data type allows leading spaces to
improve presentation. It can be long (up to 64 K)

FT - Formatted Text

Derivative of the ST but allowing the use of formatting


codes enclosed in escape characters, as shown in the
following table.

Text formatting codes used for the FT data type include the following:

Code

Meaning

.sp #

Ends the present line and skips the number # of lines

.br

Begin new line

.fi

Begin word wrap

.nf

Ends word wrap

.in #

Indent # of spaces

.ti #

Temporary indent # of spaces

.ce

End the present line and center the following line

Example of formatting codes:

|Observation:\.sp\\.in+4\\.ti-4\1. The cardio mediastinal silhouette is now within normal


limits.\.sp\\.ti-4\2. Lung fields show minimal ground glass appearance.|

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

21

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

The output displayed by the receiving system would look something like this:

Observation:
1. The cardio mediastinal
silhouette is now within
normal limits.
2. Lung fields show minimal
ground glass appearance.
Data Types for Numbers and Quantities
The data types in the following table are used to express numbers and quantities.
Table 6 - Numeric and quantity data types
Data type

Characteristic

CQ Composite
Quantity with
units

This data type has two components, the first for the amount and
the second for the units of measure.

MO - Money
(Money)

This data type is specifically for fields expressing currency


amounts and has two components. The first one is the amount
and the second is the denomination of currency.

<QUANTITY (NM)>^<UNITS (CE)>


For example, to express that a person weighs 123.7 Kilograms:
|123.7^kg|

<QUANTITY (NM)>^<DENOMINATION (ID)>


For example, to specify that a medicine cost is $ 99,50 ($=U.S.
dollars) : |99.50^USD|

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

22

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

Data type

Description

SI - Sequence
Identifier

This data type is a positive whole number. It is used to identify


the ordinal position of a repeating segment within a message.

SN - Structured
Numeric

This data type is used to express clinical results with some type of
qualifier. Sets of values are indicated with a comparator and a
separator/suffix (Comparators can be =, >, <, >=, <= or
<>; separators can be - , +, /, . , or : )
The structure is as follows:
<comparator (ST)>^<num1 (NM)>^<separator/suffix (ST)>^<num2
(NM)>
Ex |>^10000| (greater than 10000)
Ex |^128^-^256| (equal to a range between 128 and 256)
Ex |^1^:^256| (titration of 1:256 - serology)
Ex |^3^+| (occult blood positivity)

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

23

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

Data Types for Times and Dates


Data type

Description

DT (Date)

This data type is specifically for expressing dates. The format is


YYYY[MM[DD]].
The portions in square brackets are optional. Thus, the group
month-day is optional and the day is optional if the month is
specified. For example, to express October15, 2006: 20061015; to
express May 2007: 200705.

TM (Time)

This data type is used to express time, without date, in the


following format:
HH[MM[SS[.S[S[S[S]]]]]][+/-ZZZZ]
The digits symbolized by HH indicate hours, MM indicate minutes
and SS.SSSS indicate seconds and optional fractions of seconds.
+ZZZZ or ZZZZ optionally designates the time zone offset from UTC
(formerly Greenwich Mean Time).
Lets see some examples:
|235959+1100| 1 second before midnight in the time zone
located at GMT+11 hours.
|0800| eight AM, local time.
|093544.2312| 44.2312 seconds after 9:35 AM, local time.
|13| 1 PM, local time.

TS - Time Stamp This data type combines date and time. Its structure is as follows:
(Time/date)
YYYY[MM[HH[MM[SS[.S[S[S[S]]]]]][+/-ZZZZ]]^<degree of
precision>
Example:
|19760704010159| indicates 1:01: 59 A.M. on July 4, 1976

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

24

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

Data Types for Identifiers


Data type

Description

ID - value from
HL7 defined
table

This data type indicates that the value is from a HL7 defined
table. When we encounter a field with this data type we must
defer to the specified table (TBL#) for allowable values and their
definition. For example, there is a table with the values: Yes or
No.
These values are specified in the table 0136 yes/no and the
possible values include Y (YES) and N (NO).
The table may be extended, but the values published by HL7 are
normative and may not be redefined. They are expected to be
recognized by communicating systems.

IS - value from
user defined
tables

This data type indicates that the value is from a USER defined
table. For example, Sex table
VALUE Description
F Female
M Male
O Other
U Unknown
These tables are defined in each implementation. HL7 may
suggest values, but communicating systems may use any set of
values they deem appropriate.

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

25

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

Data type

Description

HD - Hierarchic
Designator

This type of identifier is usually for applications and assigning


authorities. Its structure is:
<namespace ID (IS)>^<universal ID (ST)>^<universal ID type (ID)>
It consists of three components where the first is an entry from a
user-defined table, and the second is a string formatted
according to the rules of the ID type indicated in the third
component.
If the designated entity is a locally defined organization, only
<namespace ID> will be included. Example GHH_CLINIC.
If the organization identifier is public, the last two components
are used.
Universal ID type (ID) is the type of domain Identifier for the
universal ID. Examples of Universal ID type are: DNS, GUID, etc.
Example: ^HL7.org^DNS
Universal ID (ST) is an identifier that is unique within the domain of
the Universal ID Type.

EI - Entity
Identifier

This data type expresses identifiers assigned by an application. It


consists of 4 components; the first one is the identifier for the
entity, and the remaining components identify the authority
assigning the identifier.
Here is its structure:
<entity identifier (ST)>^<namespace ID (IS)>^
<universal ID (ST)>^<universal ID type (ID)>
Examples:
Accession Number (lab), Order Number, Inpatient Encounter
Number, Authorization Number, Facility Identifier, etc.
Example: |125658^HIS_HIBA| designates ID 125658 assigned by
the hospital information system of the Italian Hospital of Buenos
Aires

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

26

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

Data type

Description

PL - Patient
Location

This data type is used to specify the location of a patient within


an institution. It can also have other uses; for example, the
location of a doctor's office or a nursing station.
The components, as of HL7 V2.3.1, are as follows:
<point of care (IS)>^<room (IS)>^<bed (IS)>^<facility
(HD)>^<location status (IS)>^<person location type
(IS)>^<building (IS)>^<floor (IS)>^<location description (ST)>
Note that this data type does not present the information in the
logical order one might expect (from the most generic to the
most specific component) which would be: person location
type, facility, building, floor, point of care, room, bed. This is due
to the HL7 rules for extending data types. Over time additional
components were added this data type; based on the rules
each addition occurred to the end of the data type.
Person location type and location description are intended to
describe the kind of location.
Location status can be used to express the state of a bed or
room for example in a room census (occupied, reserved, free).
Example: |2101 IM^210^2101^GHH^^^GHH^2^GHH BEDBUILDING 10|
This indicates that the patient is in the department of Internal
Medicine (IM) in room 210, bed 2101 of the second floor of
Building 10 of Good Health Hospital

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

27

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

Data type

Description

PT - Processing
Type

Indicates if the message is to be processed in debugging,


production, or training mode and whether regular processing or
special processing (restoring from archive, initial load, etc.) is
being used
This data type is used in MSH-11-Processing ID. Its structure is:
<processing ID (ID)>^<processing mode (ID)>
The first component has three possible values - D: Debugging, P:
Production, T: Training. The second component has four possible
values - A: Archive; R: Restore from archive; I: Initial load; not
present/blank: default, regular processing)
Example
|P| indicates that the sending interface is in production mode
and that the data is intended to be processed normally

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

28

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

Data Types for Coded Values


HL7 establishes these data types for those elements that need to be codified. Among
them we find:

Data type

Description

CE - coded
element

This data type transmits codes with a text or description


associated to the code. Contains 6 components. The first three
components specify the concept in one coding system. The
second three components allow the same concept to be
expressed using an alternate coding system.
Its structure is:<identifier (ST)>^<text (ST)>^<name of coding
system (ID)>^<alternate identifier (ST)>^<alternate text
(ST)>^<name of alternate coding system (ID)>
Within the first triplet, the first component contains the code, the
second component contains a description of that code and the
last component identifies the coding system. The structure of the
second triplet is the same. Example:
|F-11380^CREATININE^I9^2148-^CREATININE^LN|
RECOMMENDATION: USE CNE or CWE data type. CE is retained
for backward compatibility

CNE - coded
with no
exceptions

This data type indicates that the values in this field must be
selected from the coding system designated in the HL7 element
definition without exception. The designated coding system may
not be locally extended and its codes may not be redefined.
Similar to CE but with versioning and original text (original text is
meant for including the text that the physician actually entered
into the system).
Its structure is:
<identifier (ST)>^<text (ST)>^<name of coding system
(ID)>^<alternate identifier (ST)>^<alternate text (ST)>^<name of
alternate coding system (ID)>^<version ID (ST) ^alternate coding
system version ID (ST) ^<original text (ST)>
Example showing the use of LOINC Version 1.0:
|718-7^Hemoglobin^LN^^^^1.0|

CWE - coded
The concept is similar to the CNE, but allowing exceptions: you
with exceptions can send only the alternate coding sequence, or include NULL
FLAVORS (explaining why you are not sending a value in the
coded system: not asked, not known, not found within the
domain, etc.) The designated coding system may be locally
extended; although no codes may be redefined. Same structure
as CNE.
CX extended
composite ID

This data type supports an identifier with associated


administrative data, such as a medical record number for a

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

29

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

with check digit patient or a person identifier. It has the following format:
<ID (ST)> ^ <check digit (ST)> ^ <check digit scheme (ST)> ^
<assigning authority (HD)> ^ <identifier type code (ID)> ^
<assigning facility (HD)> ^ <effective date (DT)> ^ <assigning
jurisdiction (CWE)> ^ <assigning agency or department (CWE)>
For example, the patient with medical record number W1234
assigned by Good Health Hospital would have the following
information in field PID-3, which is of data type CX:
|W1234^^^GHH^MR|

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

30

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

Data types for Addresses, Persons, Organizations, and Phone


Numbers
Data type

Description

XAD - extended This data types is used to express addresses; its structure is as
address
follows:
<street address (SAD)>^< other designation (ST)>^<city (ST)> ^
<state or province (ST)>^<zip or postal code (ST)>^<country (ID)>
^<address type (ID)>^<other geographic designation (ST)>^
<county/parish code (IS)>^<census tract (IS)>^
<address representation code (ID)>^<address validity range
DR)>^<effective date (TS)> ^ <expiration date (TS)>
For example to indicate building number 1058 on Healthcare
Drive in Ann Arbor, Michigan, USA, with zip code 99999:
|1058 Healthcare Drive^^ANN ARBOR^MICHIGAN^
99999^USA|
XPN - extended This data type is used to identify patients and persons.
person name
The format is:
<family name (FN)>^<given name (ST)>^
<middle initial or name (ST)>^<suffix (ST)>^<prefix (ST)>^
<degree (IS)>^<name type code (ID) >^
<name representation code (ID)>^<name context (CE) >^
<name validity range (DR)>^<name assembly order (ID)>^
<effective date (TS)>^<expiration date (TS)>^
<professional suffix (ST)>
The following example refers to Charlie C. Chopper, MD:
|Chopper^Charlie^C^^MD|
XON extended
composite
name and ID for
organizations

This data type is used to identify an organization and its


associated ID. Its format is:
<organization name (ST)> ^ <organization name type code (IS)>
^ <ID number (NM)> ^ <check digit (NM)> ^ <code identifying
check digit scheme (ID)>^ <assigning authority (HD)> ^
<identifier type code (IS)> ^ <assigning facility ID (HD)> ^ <name
representation code (ID)>^ <organization identifier (ST)>
This data type is similar to XCN but for organizations. Note that it
includes an ID number in the third component. See also data
type XCN, used for staff and practitioners.

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

31

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

XTN - extended This data type is used to express contact information such as
telephone
telephone numbers; its format is:
number

[NN] [(999)]999-9999[X99999][B99999][C any text] (ST) ^


<telecommunication use code (ID)> ^ <telecommunication
equipment type (ID)> ^ <email address (ST)> ^ <country
code (NM)> ^ <area/city code (NM)> ^ <phone number
(NM)> ^ <extension (NM)> ^ <any text (ST)> ^ <extension
prefix (ST)> ^ <speed dial code (ST)> ^ <unformatted
telephone number (ST)>

Data Types for Multimedia Objects


Data type

Description

ED encapsulated
dates

This data type is used to transmit encapsulated data. Instead of


sending a pointer to the data, you can send the actual data
encoded as MIME (BASE 64).
Format:
<source application (HD)>^<type of data (ID)>^
<data subtype (ID))>^<encoding (ID)>^<data (TX)>

RP - Reference
Pointer

This data type is used to transmit information on multimedia


objects stored in another systems repositories. Its structure is:
<POINTER (ST)>^<APPLICATION ID (HD)>^
<TYPE OF DATA (ID)>^<SUBTYPE (ID)>
The first component indicates the resource location.
The second identifies the application responsible for the
information. The third and fourth components define the type of
information (type and subtype). For example: Image / JPEG
Uses: To let the receiving applications know the address for
accessing objects stored by the sender application: DICOM
objects, PDF, JPG, HTML, etc.
| http://www.hl7.org/image/about2.gif ^HL7^image^GIF|

We have seen the most commonly used HL7 data types, including several examples.
Numerous other examples will be provided throughout the course.

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

32

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

Lets examine a few more important concepts before we conclude this introduction
to HL7 Version 2.x.

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

33

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

MESSAGE PROCESSING RULES


Sending Rules
THE TEN OUTBOUND HL7 COMMANDMENTS
1. Encode each segment in the order specified in the abstract message
format
2. The segment ID is required to identify EACH segment
3. Precede each data field with the field separator
4. Encode the data fields in the order specified in the segment definition table
5. Data fields not present require no characters.
6. Data fields present but null are encoded with (double quotes)
7. If components, subcomponents, or repetitions at the end of a data field are
not present, their separators may be omitted
8. If no more fields are present in a segment, the data field separators may be
omitted
9. Padding doesnt violate the rules, but its not good practice and leads to
unnecessary processing and message length.
10. End each segment with the REQUIRED segment terminator
(1) Abstract Message Format

(4) Segment Definition Table

(5)
- (6)
PID|||222-6667777||CHOPPER^CHARLIE^C||...

(7)
Nightingale^Nancy^^^^^
Nightingale^Nancy

(8)
PID|||222-666-7777||CHOPPER||||| =
PID|||222-666-7777||CHOPPER

(10)
MSH<CR>
PID<CR>

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

34

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

Receiving Rules
THE TWO INBOUND HL7 COMMANDMENTS
1. IGNORE THE UNEXPECTED: segments, fields, components, subcomponents, and

repetitions of a field that are present but not expected. THEY ARE NOT YOUR PROBLEM
2. IF ITS NOT THERE, ASSUME ITS NOT PRESENT: Treat segments, fields, components,
subcomponents, and repetitions that are expected but not sent as not present take no
action.

If the message contains something you werent expecting: ignore it.


If something is not there and you were expecting it: assume its not present, and
respond accordingly.
Required fields (fields required and not present) should be identified in the ERR
segment of an acknowledgment message. Acknowledgment messages are
discussed briefly below.

Acknowledgement of Message Reception (ACK)


In figure 1 we saw that in a basic HL7 transaction, a trigger event causes System A to
send a message. This message is received by System B, which sends a response to
System A.
The response from System B is an acknowledgment message.
One of two modes of acknowledgment may be in use:

1. Original processing mode


2. Enhanced processing mode

Original mode
In the Original processing mode, the reception, storage, and processing of messages
are all acknowledged by a single acknowledgment message at the application
level.
The rationale is that it is not enough to know that the underlying communications
system guaranteed delivery of the message. It is also necessary to know that the
receiving application processed the data successfully.

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

35

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

The acknowledgment may contain data that are of interest to the system that
initiated the exchange.
For example, if a patient care provider wants to order a lab test, it may send a
message of type ORM to a lab application identifying the patient, the test ordered,
and other information about the order.
The lab application will acknowledge the order when it has processed it successfully.
It will do so by means of an application acknowledgment message of type ORR that
includes an order status and filler order number in the ORC segment.
The receiving system may also acknowledge the order after placing it in an input
queue, expecting to fully process the order into its database at a future time. The only
assumption is that the input queue is maintained at the same level of the integrity as
the database.

Enhanced mode
In Version 2.2 HL7 extended the standard to include Enhanced Mode
acknowledgment. Here a distinction is made between accept and application
acknowledgment, as well the conditions under which each is required.
With a positive accept acknowledgment, the receiving system commits the message
to safe storage in a manner that releases the sending system from the need to resend
the message.

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

36

HL7 E-LEARNING COURSE MODULE V.1 - HL7 V2.X INTRO: CONTROL

After the message has been processed by the receiving system at the application
level, an application acknowledgment may be used to return the new status to the
sending system. This ACK may be of three types:

1. OK Answer: (AA): the message was processed successfully


2. Reject ANSWER : failed to process (REJECT) the message for reasons unrelated
to its content or format (AR)

3. ERROR Message: Message of error (AE).


You are now ready to perform the practice exercises.

HL7ELC_V_EN_U01_V01.2

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

37