Health Level 7 (HL7)

2.x Introduction

Presented by
Jim Forbes &
Sisamone Phanthasomchit
2005
1
Session Overview

• Introduction
• Need for a Standard
• 2.X Conceptual Overview
• break
• Practice Exercise
• HL7 Tips

2
Session Overview - Objectives

• Attain basic understanding of the HL7

Organization
• Attain basic understanding of HL7 2.X messaging
• Provide some Pointers for use of the standard

3
Introduction – What is HL7?

What is HL7
• HL7 is an ANSI accredited data exchange Standard
for Healthcare ;
– An ANSI accredited Standards Development Organization

Purpose:
• To facilitate communications of electronic Information
within a Healthcare setting

Primary Goal:
• To provide standards for the exchange of data among
Healthcare computer applications that eliminate or
substantially reduce custom interface programming
and software maintenance that otherwise may be
required

4
Introduction – Why the name?

• Conceptually operates at the 7th level of the International

Organization for Standardization (ISO) model for Open
System Interconnect (OSI)
• Primarily concerned with the data content and
interrelationship of messages with limited support for
application-level error conditions
• The communications environment, including its architecture,
design and implementation, is outside the scope of HL7
• The HL7 Standard assumes that the communications
environment will provide:

Character conversion

Variable length message support

Error free transmission

5
Introduction - The ISO OSI Stack
Level Name Short Description Examples

7 Application Interfaces directly to and performs HTTP,SMTP, FTP, Telnet, AppleTalk, LDAP etc
common application services for the
application processes

6 Presentation Responsible for the delivery and HTTP/HTML, XML, FTP, Telnet, Apple Filing
formatting of information to the Protocol
application layer for further
processing or delay (i.e. conversion of
data from EBCDIC to ASCII)

5 Session Provides full or half duplex operations Appletalk Session Protocol (ASP)
and establishes checkpoint, DataLink Control (DLC)
adjournment, termination and restart NBT
procedures. NetBios

4 Transport Tracks packets and retransmits those TCP

that fail. Controls the reliability of a Appletalk Transaction Protocol(ATP)
link
3 Network Network routing, flow control, IP
segmentation/de-segmentation and IPX
error control NWLink
Routers operate at this layer

2 Data Link Error handling, Addressing, bit Ethernet

organization Token Ring
Point-to-point Protocol(PPP)
Fibre Distribution Data Interface(FDDI)

1 Physical Specification of Electrical and RS-232

mechanical requirements 10BASE-T
100BASE-T
electricity 6
radio
Need for a Standard…In The Beginning

7
Need for a Standard…In The Beginning

$ = {a,b,c}

$=
$= {b,a ,f }
,c} d
e,

$ = {f,e,d}
$ = {c,b

{c {
,a , =
b} $
,a}

d ,e,f}
{
$=

8
Need for a Standard…What HL7 Gives Us

{a,b,c}

{a,b
{a ,c}
,b , }
{a,b,c}

c} e, ,f
{d

{d,e,f}
e,f}
{d ,

9
Need for a Standard…Getting the Most out of HL7

7 :F IN}
{ HL
{HL7:ADT}
: ADT}
7
{HL
{H
Server

{H L7

{HL7:FIN}
{HL7:ADT}
D T} L7
:A
:FI
N}
L7: A DT
}
{H I N}
7: F
L
{H

10
Need for a Standard…HL7 the Early Years

March 1987-June 1990 December 1994 Version

Version 2.1 Version 2.2
Chapter Description Chapter Description

2 Control 2 Control

3 Patient Administration 3 Patient Administration

4 Order Entry 4 Order Entry

5 Query 5 Query

6 Patient Accounting 6 Patient Accounting

7 Ancillary Data Reporting 7 Ancillary Data Reporting

Membership: 12
8 Master files
Participation aprox. 75

Membership: 1300
Participation: 250-300
June 1994: HL7 becomes an V2.2 = ANSI Accredited Standard 1996
ANSI Accredited Standards
Developing Organization 11
Need for a Standard…HL7 the Early Years

December 1994 Version May 1997 V 2.3

2.2 Chapter Description
Chapter Description 2 Control
3 Patient Administration
2 Control
4 Order Entry

3 Patient Administration 5 Query

6 Patient Accounting
4 Order Entry 7 Ancillary Data Reporting
8 Master files
5 Query
9 Medical Records Info. Management
6 Patient Accounting
10 Scheduling
7 Ancillary Data Reporting 11 Patient Referral
12 Patient Care
8 Master files
Appendices

Membership: 1300 A Data Definition Table

Participation: 250-300 B Lower Layer Protocols
C Network Management
D Version 2.2 BNF Message Descriptions

May 1997: Version 2.3 received E Glossary

ANSI approval Membership: 1700: Participation 350-400
12
Need for a Standard…Recent

July 2003 Version 2.5

Chapter Description
2 Control
3 Patient Administration
4 Order Entry
5 Query
6 Patient Accounting
7 Ancillary Data Reporting
8 Master files
9 Medical Records Information Management
10 Scheduling
11 Patient Referral
12 Patient Care
13 Clinical Laboratory Automation
14 Application Management (formerly Appendix C Network Management)

15 Personnel Management
Appendices
A Data Definition Table
B Lower Layer Protocols
C BNF Message Descriptions
D Glossary
Membership: 2000+ Participation: 400-500 13
Need for a Standard…Recent

•New with Version 2.5:

–Improves how data types are documented

–Data types are detailed in tables
–Allows exact definition of properties
–Includes maximum component lengths
–Includes reference tables
–Adds OVR (Override) and SFT (Software)
segments

14
Need for a Standard…Historical Timelines

2.1 2.2 2.3 2.3.1 2.4 2.5 2.6

Australia + Canada
+ China
Germany Finland
Japan India
The Netherlands Korea
New Zealand Southern Africa
Taiwan
United Kingdom
v3

P
1 1 1 1 1 2 2 R
9 9 9 9 9 0 0 E
8 9 S
9 9 9 0 0 E
7 0 4 7 9 0 3 N 15
T
Need for a Standard – Additional Background

Each subsequent release in the 2.X series:

• maintains backward compatibility with previous

versions.
• corrects errors found in the previous version
• extends the format within the format and context of
HL7 2.X

16
2.x Conceptual Overview

Important Concepts and Terminology

Trigger Events: HL7 is written from the assumption that an

event in the real world of healthcare creates the need for the
exchange of data between systems

A message is the atomic unit of data transferred between

systems. It is comprised of a group of segments in a defined
sequence. Each message has a message type that defines its
purpose. (HL7 v2.5 section 2.5.1)

A segment is a logical group of fields in a defined sequence

A field is a string of characters.

Delimiters are special characters used to indicate segment

termination, field, component, sub-component and repetition
separation and escape character.
17
2.x Conceptual Overview – Trigger Events

• Trigger events are identified by a unique 3 character

code. This code is known as an event type
• ‘Z’ trigger codes are reserved for locally-defined trigger
event
• A trigger event generates a message

18
2.x Conceptual Overview – Trigger Events
Example: Trigger Events (for more info see 2.17.2 of 2.5 TABLE 003)
Message Description
A01 ADT/ACK – Admit/visit notification
A02 ADT/ACK – Transfer a patient
A03 ADT/ACK – Discharge a patient
O01 ORM – Order Message (also RDE, RDS, RGV, RAS)
O02 ORR – Order Response (also RRE, RRD, RRG, RRA)
O03 OMD – Diet order
R01 ORU/ACK – Unsolicited transmission of an observation message
… Etc…

19
2.x Conceptual Overview – Messages

A message is the atomic unit of data transferred

between systems. It is comprised of a group of
segments in a defined sequence. Each message
has a message type that defines its purpose. (HL7
v2.5 section 2.5.1)

HL7 provides an HL7 Message Structure for each

message

20
2.x Conceptual Overview – Messages (cont)
Example: Message Type (for more info see 2.17.1 of 2.5 TABLE 0076)
Message Description Chapter
ACK General acknowledgement message 2
ADR ADT response 3
ADT ADT message 3
BAR Add/change billing account 6
CRM Clinical study registration message 7
CSU Unsolicited study data message 7
DFT Detailed financial transaction 6
DOC Document response 9
DSR Display response 5
EAC Automated equipment command message 13
EAN Automated equipment notification message 13
ORM Pharmacy/treatment order message 4
ORU Unsolicited transmission of an observation message 7
… Etc…

21
2. x Conceptual Overview – Messages (cont)
Message Type

Trigger Code
ADT - A01

MSH
EVN
PID
NK1
Segments
PV1

OBX
AL1

IN1 22
...
2.x Conceptual Overview – Messages (cont)

HL7 abstract message syntax

• Each message is defined in special notation
that lists the segment IDs in the order they
would appear in the message.
• Braces, {…}, indicate one or more repetitions of
the enclosed group of segments.
• Brackets, […], show that the enclosed group of
segments is optional.
• If a group of segments is optional and may
repeat it should be enclosed in brackets and
braces, [{…}],

23
2.x Conceptual Overview – Messages (cont)
ADT^A01 ADT Message Status Chapter
MSH Message Header 2
{{SFT}] Software Segment Required Segments 2
EVN Event Type 3
PID Patient Identification 3
[ PD1 ] Additional Demographics 3
[{ROL}] Role Optional Segments 15
[{NK1}] Next of Kin / Associated Parties 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit – Additional Info 3
[{ROL}] Role Optional & 15
[{DB1}] Disability Information Repeating 3
[{OBX}] Observation/Result Segments 7
[{AL1 }] Allergy Information 3
[{DG1}] Diagnosis Information 6
[{DRG}] Diagnosis Related Group 6
… continued on next slide …

24
2.x Conceptual Overview – Messages (cont)
ADT^A01 ADT Message Status Chapter
[{ --- Procedure begin Segment Group
PR1 Procedures 6
[{ROL}] Role 15
}] --- Procedure end
[{GT1}] Guarantor 6
[{ 15 --- Insurance begin Segment Group
IN1 Insurance 6
[ IN2 ] Insurance Additional Info. 6
[{ IN3}] Insurance Additional Info – Cert. 6
[{ROL}] Role 15
}] --- Insurance end
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6
[ PDA ] Patient Death and Autopsy 3
continued from previous slide

25
2.x Conceptual Overview – Messages (cont)

A named segment ‘X’ may occur more than once in an

abstract message syntax. This differs from repetition
described earlier. When this occurs, the following rules
must be adhered to:
If segment ‘X’ appears in two individual or group locations,
and
a) Either appearance is optional or repeating in an
individual location;
b) Or, either appearance is optional or repeating, in a
group location
Then, the occurrences of segment ‘X’ must be separated by
at least one required segment of a different name
This helps ensure that no ambiguity can exist as to the
individual or group location of any occurrence of a segment
in a message instance
26
2.x Conceptual Overview – Messages (cont)
Examples of Un-parsable Segment Grouping
Example 1 Example 2 Example 3
{SEG1} [ SEG1] {SEG1}
[SEG1] { [SEG2
[SEG2] SEG3]
SEG1 SEG1
}

Examples of Proper Segment Grouping

Example 1 Example 2 Example 3
{SEG1} [ SEG1] SEG1
SEG2 { [SEG2]
[SEG1]
SEG2 SEG3
[SEG1] {SEG1}
}
27
2.x Conceptual Overview – Segments

• A segment is a logical grouping of data fields

• Segments may be required or optional

• Segments may repeat

• Each segment is given a name known as Segment ID, for

example, MSH, EVN, PID, PV1 etc.

• Z segments are reserved for locally-defined segments

• Segments may be grouped. This is called a segment

group.

28
2.x Conceptual Overview – Segments (cont)
A segment is a logical group of fields in a defined
sequence
ADT
MSH
EVN
PID

Fields

NK1
PV1
PV2
AL1 29
...
2.x Conceptual Overview – Segments (cont)
HL7 Attribute Table - PID
SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAM E
1 4 SI O 00104 Set ID - PID
2 20 CX B 00105 Patient ID
3 250 CX R Y 00106 Patient Identifier List
4 20 CX B Y 00107 Alternate Patient ID - PID
5 250 XPN R Y 00108 Patient Nam e
6 250 XPN O Y 00109 Mother’s Maiden Nam e
7 26 TS O 00110 Date/Tim e of Birth
8 1 IS O 0001 00111 Adm inistrative Sex
9 250 XPN B Y 00112 Patient Alias
10 250 CE O Y 0005 00113 Race
11 250 XAD O Y 00114 Patient Address
12 4 IS B 0289 00115 County Code
13 250 XTN O Y 00116 Phone Num ber - Hom e
14 250 XTN O Y 00117 Phone Num ber - Business
15 250 CE O 0296 00118 Prim ary Language
16 250 CE O 0002 00119 Marital Status
17 250 CE O 0006 00120 Religion
18 250 CX O 00121 Patient Account Num ber
19 16 ST B 00122 SSN Number - Patient
20 25 DLN O 00123 Driver's License Number - Patient

30
2.x Conceptual Overview – Fields
(Attributes)

Attributes are defined for each field including:

Sequence Number
Ordinal position of the data field within the segment..

Maximum length
Maximum number of characters that one occurrence of
the data field may occupy

Data Type
The Basic building block used to construct or restrict the
contents of a data field.

31
2.x Conceptual Overview – Fields
(Attributes)

Attributes Continued:

Optionality
O = Optional
R = Required
C = Conditionally required
B = left in for backward compatibility
X = Not used with this trigger event
W = Withdrawn
Repetition
Whether the field may repeat
Table
Specifies the Hl7 identifier for a set of coded values
ID Number
Unique identifier the data item throughout the Standard
Name
Descriptive name of the data item
32
2.x Conceptual Overview – Fields
(Attributes – Data Types)
Example: Data Types (for more info see 2.16. of 2.5 TABLE
0440)
Data Data Type Name LEN Category Comment
type
AD Address 415 Demographic Replaced by XAD as of v
s 2,3
CN Composite ID number Code Values Withdrawn. Replaced by
and name XCN as of v 2.3
DTM Date/time 24
ST String 199 Alphanumeric
TS Time stamp 26 Date/time
TX Text Data 65536 Alphanumeric
XAD External address 631 Demographic Replaces AD as of v 2.3
s
XCN Extended composite ID 3002 Code Values Replaces CN as of v 2.3
number and name
XPN Extended person name 1103 Demographic Replaces PN as of v 2.3
s
… Etc…
33
2.x Conceptual Overview – Fields
(Attributes – Data Types - XAD)

XAD = Extended Address (Section 2.9.51)

|<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)>|

Sub-components of Street Address Data Type

(SAD)
<street or mailing address (ST)> & <street name (ST)> &<dwelling number
(ST)>

|343 Spruce Street&Spruce Street&343^Spruce

Street Retirement Home^Toronto^ON ^M5A
2K9^CA^H|
or
|343 Spruce Street^Spruce Street Retirement
Home^Toronto^ON ^M5A 2K9^CA^H| 34
2.x Conceptual Overview – Fields
(Attributes – Data Types - XPN)

Example Data Type: XPN = Extended Person Name (Section 2.9.54)

|<family name (FN)> ^ <given name (ST)> ^ <second and further given names or
initials thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)>
^<degree (e.g., MD) (IS)> ^ <name type code (ID)> ^ <name representation
code (ID)> ^ <name content (CE)> ^ <name validity range (DR)> ^ <name
assembly order (ID)>|

|Forbes^James^H^III^DR^PHD^L|

Sub-components of family name (FN):

<surname (ST)>&<own surname prefix (ST)> &<own surname

(ST)>&<surname prefix from partner/spouse (ST)>&<name of alternate
coding system (IS)>

35
2.x Conceptual Overview – Fields
(Attributes – Data Types - Other)

HL7 Defined Table User/Site Defined Table

ID Data Type IS Data Type
‘are part of the HL7 • Values will vary from institution to
standard because they institution
affect the interpretation of
the messages that contain • Tables are not defined in the
them. They are limited to the standard
values established by the
HL7 Standard’ • May be assigned ‘suggested
values’
• May add/remove/change
Table 4000 – Name representation suggested values
V alue D escription
Table 0128 – Allergy Severity
I Ideographic V a lu e D e s c r ip tio n
A A lphabetic S V S e v e re
P P honetic M O M o d e ra te
M I M ild
36
2.x Conceptual Overview – Fields
(Attributes – Data Types - continued)

• A data field is a string of characters

• Fields are identified by it’s position in the segment
(e.g. PID-5 = Patient Name)
• Blank – means field has no data.
• “” – means field has null value.

Null = |””| Blank = ||

Recipient should Recipient should not
remove any data from update this field, any
this field existing data should
remain
HL7 does not care how systems actually store data
within an application.
(v.2.5 section 2.5.3) 37
2.x Conceptual Overview – Delimiters

Applications will use the agreed upon delimiters, as

they appear on the message header segment
(MSH), to parse the message.
Delimiter Sugg. Usage
Value
Segment Terminator <cr> Terminates a segment message.
Field Separator | Separates two adjacent data fields
within a segment.
Component Separator ^ Separates adjacent components of data
fields where allowed.
Subcomponent Separator & Separates adjacent subcomponents of
data fields where allowed.
Repetition Separator ~ Separates multiple occurrences of a
field where allowed
Escape Character \ For use with any field represented by
ST, TX or FT data type, or for use with
the data (fourth) component of the ED
data type.
38
2.x Conceptual Overview – Delimiters (cont)

• Delimiters are defined in MSH:1

• There is no message terminator
• Delimiter sequence is critical:

Field
Field
MSH|^~\&|…
123456789…
Sub-
Component
component
Repeat Escape
39
2.x Conceptual Overview – Example (Fields
and Delimiters)

MSH|^~\&|REG|TGH|LAB|TML|200502151126||ADT^A01|M12345|
P|2.5|<cr>
EVN|A01|200502151126|<cr>
PID|1||PATID1234^5^M11||FORBES^JAMES^H||19670329|M||C|
1200 ELM STREET^^TORONTO^ON^M5G1Z6|GL| (416)555-
1212|(416)555-3434||S||X45 ^2^M10|123456789|987654^ON|<cr>
NK1|1|FORBES^SADIE^K|WIFE||||CP^Contact person|<cr>
PV1|1|I|0^2012^01|E||||004777^LEBAUER^SARA^J.||TRMA||||A
DM|A0|<cr>

PID-5 Patient Name (XPN)

PID|1||PATID1234^5^M11||FORBES^JAMES^H||19670329|M

3 5
12 4 40
2.x Conceptual Overview – Example (Fields
and Delimiters)

PID|1||PATID1234^5^M11||FORBES^JAMES^H||19670329|M

PID-5 Patient Name (XPN)

| FORBES^JAMES^H|

1 2 3

PID-5.1 Family Name (FN)

In certain component or subcomponent square
brackets are used, “[“ and “]”.
For example, PID-5[1]
41
2.x Conceptual Overview – HL7 Message
Profiling
Definition:
- An HL7 message profile is an unambiguous
specification of one or more standard HL7
messages that have been analyzed for a
particular use case.
- A message profile fully describes a
conversation between two or more systems
through the combination of the following:
A) One use case analysis
B) One or more dynamic definitions, and
C) One or more static definitions

42
2.x Conceptual Overview – HL7 Message
Profiling (Components of a Message Profile)

1) Use Case Model

2) Interaction Model
3) Dynamic Definition
4) Static Definition – Message Level
5) Static Definition – Segment Level
6) Static Definition – Field Level

43
2.x Conceptual Overview – HL7 Message
Profiling (What is a use case?)
A use case model documents the scope and requirements
for an HL7 message profile or set of message profiles
Example A01 (Admit)

Register IP visit type Assign patient bed

on HIS for patient to Nursing Unit
Clerk or Nurse

Accept/Save

HIS broadcasts
A01 Trigger
Message
44
2.x Conceptual Overview – HL7 Message
Profiling (Use case example)

2.0 Use Case Assign Patient a Bed

2.1 Actors Clerk or Nurse

2.2 Purpose To assign patient a bed on nursing unit

2.3 Overview Clerk or Nurse assigns patient a bed on a nursing unit. This is
part of the visit or appointment registration process.
2.4 Preconditions Visit or appointment registration is available on HIS. Bed is
unoccupied by another patient.
2.5 Main Flow Actor Action:
1. Clerk or Nurse starts visit or appointment registration on
HIS.
2. Clerk or Nurse searches for available bed on Nursing Unit
on HIS.
System response to (2):
Returns all available bed on Nursing Unit.
3. Clerk or Nurse assign patient a bed on Nursing Unit.
System response to (3):
Shows patient is in bed assigned.
45
2.x Conceptual Overview – HL7 Message
Profiling (Dynamic Definition)

• Dynamic definition is an interaction specification

for a conversation between 2 or more systems
• It may reference one to many static definitions
• The dynamic definition may include interaction
model
• Shall define the conditions under which an accept
and or application acknowledgment is expected

46
2.x Conceptual Overview – HL7 Message
Profiling (Interaction Model)

• Interaction Model illustrates the sequence of trigger

events and resulting message flows between 2 or
more systems
• It may be in literal or graphical form
• Graphical form should be a UML activity diagram

47
2.x Conceptual Overview – HL7 Message
Profiling (Interaction Model)
Sending Application
(Patient Administration) Receiving System (Departmental Application, 1..n)

Patient Admitted

Broadcast
Send ADT^A01 Receive ADT^A01

ACK Code ‘AE’: Invalid Syntax/Semantics ACK Code ‘AA’: Application Accept

ACK Code ‘AR’: DB Not Available

Persist Message

Process Message
Receive ACK Send ACK with ACK Code

48
2.x Conceptual Overview – HL7 Message
Profiling (Static Definition)

• Static definition is a specification for a single

message
• A complete static definition shall be defined at the
message, segment, and field levels
• The static definition explicitly defines:
A) Segments, segment groups, fields and
components usage rules
B) Cardinalities
C) Value sets and coding systems

49
 Sample Static Definition – Message Level
Segment ADT Message Usage Cardinality Chapter
MSH Message Header R [1..1] 2
EVN Event Type R [1..1] 3
PID Patient Identification R [1..1] 3
[PD1] Additional Demographics X [0..0] 3
[{ROL}] Role X [0..0] 12
[{NK1}] Next of Kin/Associated Parties RE [0..3] 3
PV1 Patient Visit C [0..1] 3
[PV2] Patient Visit – Additional Info. RE [0..1] 3
[{ROL}] Role X [0..0] 13
[{DB1}] Disability Information X [0..0] 3
[{OBX}] Observation/Result X [0..0] 7
[{AL1}] Allergy Information RE [0..0] 3
[{DG1}] Diagnosis Information X [0..0] 6
[DRG] Diagnosis Related Group X [0..0] 6
[{
PR1 Procedures X [0..0] 6
[{ROL}] Role X [0..0] 12
50
…..
 Sample Segment Level Definition – PID (Patient Identification) Segment
SEQ LEN DT Usage Cardinality TBL# Item# Element Name
1 4 SI X 00104 Set ID – PID
2 20 CX RE [0..1] 00105 Patient ID
3 20 CX R [0..*] 00106 Patient Identifier List
4 20 CX X 00107 Alternate Patient ID - PID
5 48 XPN R [1..*] 00108 Patient Name
6 48 XPN RE [0..*] 00109 Mother’s Maiden Name
7 26 TS RE [0..1] 00110 Date/Time of Birth
8 1 IS RE [0..1] 0001 00111 Sex
9 48 XPN X 00112 Patient Alias
10 80 CE X 0005 00113 Race
11 106 XAD RE [0..3] 00114 Patient Address
12 4 IS X 0289 00115 County Code
13 40 XTN RE [0..3] 00116 Phone Number-Home
14 40 XTN RE [0..3] 00117 Phone Number-Business
15 60 CE X 0296 00118 Primary Language

51
2.x Conceptual Overview – HL7 Message
Profiling (Static Definition – Field Level)

Each individual field within a segment shall be

completely defined to eliminate any ambiguity

Provides:

•Field Definition
•User-defined and suggested field values
•Constant Values
•Example Data Values
•Components and Subcomponents

52
2.x Conceptual Overview – HL7 Message
Profiling (Profile Types)

There are three basic profile types used in

documenting standard conformance

1) Vendor constrainable profiles

2) Realm constrainable profiles
3) Implementation profiles

53
2.x Conceptual Overview – HL7 Message
Profiling (Profile Types – Vendor Constrainable)

A vendor might develop a message profile to which

all their software products must comply but, in itself,
is not an implementation profile.

The vendor profile constraints the HL7 standard by:

1) Defining agreed-to vocabularies

2) Conditionality rules
3) Supported items
4) Local extensions

54
2.x Conceptual Overview – HL7 Message
Profiling (Profile Types – Realm Constrainable)

Realms, national and regional, profiles represent

localization and restrictions placed on the
appropriate standard, while providing enough
optionality for basing the more specific
implementation profiles.

55
2.x Conceptual Overview – HL7 Message
Profiling (Profile Types – Implementation)
Implementation profiles represent the lowest level of
specification required for unambiguous
implementation.

56
2.x Conceptual Overview – HL7 Message
Profiling (Profile Types)
ADT^A01 ADT^A01

MSH MSH Segments/Segment Groups:

EVN EVN -Segment usage
-Cardinality (min/max)
PID PID

NK1 NK1 NK1 NK1 NK1 NK1 NK1 NK1 NK1 NK1

PV1 PV1

Fields/Components:
PV2 PV2
-Field usage (optionality)
OBX OBX
-Cardinality (min, max)
AL1 AL1 -Value Sets/Coding System
-Descriptions
57
Practice Exercise 1– Identify Field Component

PID|1||PATID1234^5^M11||FORBES^JAMES^H||1
9670329|M||C|1200 ELM
STREET^^TORONTO^ON^M5G1Z6^CAN|GL|
(416)555-1212|(416)555-3434||S||X45
^2^M10|123456789|987654^ON|<cr>

What value is in PID-1?

What value is in PID-3[1]?

What value is in PID-5[2]?

What value is in PID-7?

What value is in PID-11[3]?

58
Practice Exercise 2
ADT^A01 ADT Message Status Chapter
MSH Message Header 2
{{SFT}] Software Segment 2
EVN Event Type 3
PID Patient Identification 3
[ PD1 ] Additional Demographics 3
[{ROL}] Role 15
[{NK1}] Next of Kin / Associated Parties 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit – Additional Info 3
[{ROL}] Role 15
[{DB1}] Disability Information 3
[{OBX}] Observation/Result 7
[{AL1 }] Allergy Information 3
[{DG1}] Diagnosis Information 6
[{DRG}] Diagnosis Related Group 6
… …

59
Practice Exercise 3 – Identify Syntax Errors

The following A01 message includes errors.
Identify the errors.

MSH|^~\&|REG|TGH|LAB|TML|200502151126||ADT-
A01|M12345|P|2.5|<cr>
EVN|A03|200502151126!
PID]1||PATID1234^5^M11||FORBES^JAMES^H||196
70329|M||C|1200 ELM
STREET^^TORONTO^ON^M5G1Z6^CAN|GL|
(416)555-1212|(416)555-3434||S||X45
^2^M10|123456789|987654^ON|<cr>
NK1|1|FORBES^SADIE^K|SPO||||CP*Contact
person|<cr>
PV11|1|I|0^2012^01|E||||004777^LEBAUER^SARA^J.|
|TRMA||||ADM|A0|||I|<cr>
60
Practice Exercise 3 - Answers

MSH|^~\&|REG|TGH|LAB|TML|200502151126||ADT-
A01|M12345|P|2.5|<cr>
EVN|A03|200502151126!
PID]1||PATID1234^5^M11||FORBES^JAMES^H||196
70329|M||C|1200 ELM
STREET^^TORONTO^ON^M5G1Z6^CAN|GL|
(416)555-1212|(416)555-3434||S||X45
^2^M10|123456789|987654^ON|<cr>
NK1|1|FORBES^SADIE^K|SPO||||CP*Contact
person|<cr>
PV11|1|I|0^2012^01|E||||004777^LEBAUER^SARA^J.|
|TRMA||||ADM|A0|||I|<cr>
61
HL7 Tips

1. Know what your looking for before you buy

• complete User requirements and use cases

2. Maintain a complete documentation library

3. Develop and maintain test scripts according to functional

Features and trigger events

4. Encourage vendors to provide latest versions of HL7

Messaging (i.e. 2.5 or greater)

5. Participate in HL7 Canada/HL7 inc.

6. Interface Engine Technology provides an advantage

62
Questions?

63
 Thank you

Allie Grassie
Guy Patterson
Sudhir Oak
Helen Stevens

64
Contact Info
Presenters:
Contact Info:
Allie Grassie CIHI
HL7 Canada Secretariat
416 – 481 – 2002 x 3583
agrassie@cihi.ca

Jim Forbes University Health Network

HL7 Canada Board Member
416 – 340 – 4800 x 6021
jim.forbes@uhn.on.ca

Sis Phanthasomchit University Health Network

Interface Specialist
416 – 340 – 4800 x 6847
sisamone.phanthasomchit@uhn.on.ca

65