HL7

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
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
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.
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.
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:
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.
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.
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
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
10
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.
11
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Â01ÂDT_A01|NSI1|P|2.6<cr>
EVN|A01|20090627120759<cr>
PID|1|||444-22-2222^^^HC^MR|EVERYWOMANÊVEÊ||19780113000000|F|||2222
HOME STREET^ÂNN ARBOR^^99999<cr>
NK1|1|EVERYMANÂDAM|SPO|2222 HOME STREET|555-555-2004<cr>
PV1|1|I|301|R|||1436^PRIMARY^PATRICIA^P|1026ÂDMITÂLAN|998ÂTTENDÂA
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.
12
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
13
[{ 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).
14
Figure 3 shows an example of transactions between two systems using Chapter 3

messages and trigger events.
ADTÂ01
System
A
Trigger
Event A01
System
B
Accept ACK
ADTÂ02
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.
15
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
0021
16
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
17
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.
18
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.
19
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.
20
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.|
21
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ÛSD|
22
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)
23
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
24
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.
25
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
26
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
27
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
28
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Î9^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) âlternate 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
29
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|
30
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^ÂNN ARBOR^MICHIGAN^
99999ÛSA|
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.
31
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îmage^GIF|
We have seen the most commonly used HL7 data types, including several examples.
Numerous other examples will be provided throughout the course.
32
Lets examine a few more important concepts before we conclude this introduction
to HL7 Version 2.x.
33
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>
34
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.
35
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.
36
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.
37

HL7

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

HL7

Enviado por

Direitos autorais:

Formatos disponíveis

E-LEARNING COURSE

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

HL7 E-LEARNING COURSE

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

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

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

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

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

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

HEALTH LEVEL 7 (HL7)

HL7 Mission (as an organization)

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,

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

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

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

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

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

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

How is the HL7 V2.x standard organized?

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

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

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

Control (Structure of the messages/Conformance)

Patient Administration (admission , discharge, transfer)

Order Entry (laboratory, pharmacy, etc.)

Financial Management (Billing / Patient Accounts)

Observation Reporting (results sent as identifiable elements - laboratory,

Medical Records/Information Management (document management

Clinical Laboratory Automation

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

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

Claims & Reimbursement

How do we read the HL7 V2.x standard?

Figure 1 shows a basic model of an HL7 transaction.

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

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

Figure 1 - Basic model of transaction

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

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

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

Each message contains:

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

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

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

Patient Identifiers and Demographic Data

Additional Demographic Data

Patient Visit/Encounter Information

Patient Visit Additional Information

Diagnosis Related Group

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

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

Insurance Additional Information

Insurance Additional Information cert.

PLEASE REMEMBER THESE RULES

then the segment may

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

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

Figure 3 V2.x Chapter 3 Transactions

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

Asociacin HL7 Argentina HL7 Inc. - All rights reserved

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