HL7 Profile V2r2 Final
Content
Health Level Seven
Version 2.x
Message Profiling Specification
Version 2.2
November 30, 2000
Copyright
2000, by Health Level Seven, Inc.
Table of Contents
1
INTRODUCTION..................................................................................................................................2
2
HL7 V2.X MESSAGE PROFILING....................................................................................................3
2.1
OVERVIEW.................................................................................................................................. 3
2.2
WHAT IS AN HL7 V2.X MESSAGE PROFILE?................................................................................4
2.3
HL7 V2.X MESSAGE PROFILE COMPONENTS...............................................................................5
2.3.1
Use Case Model.......................................................................................................................5
2.3.2
Static Definition of an HL7 V2.x Message Profile..................................................................7
2.3.2.1
2.3.2.2
2.3.2.3
2.3.3
2.3.3.1
2.3.3.2
3
Message Level Profile.......................................................................................................................8
Segment Level Profile.......................................................................................................................9
Field Level Profile...........................................................................................................................12
Dynamic Definition of an HL7 V2.x Message Profile...........................................................14
Interaction Model.............................................................................................................................14
Dynamic Profiles.............................................................................................................................15
IDENTIFICATION OF HL7 MESSAGE PROFILES USING ASN.1............................................16
3.1
STATIC PROFILE IDENTIFIER...................................................................................................... 16
3.2
DYNAMIC PROFILE IDENTIFIER.................................................................................................. 17
Figure 2.11.............................................................................................................................................18
4
OPEN ISSUES......................................................................................................................................20
Copyright
2000, by Health Level Seven, Inc.
1 Introduction
Document
History
This document is the result of a project begun in 1997 by the Health Level Seven
(HL7) Conformance Special Interest Group (SIG). The HL7 Conformance SIG,
in conjunction with the Andover Working Group (AWG), prepared this
specification based on the experience of vendors and healthcare providers who
have defined and implemented message profiles.
Scope
In its current form, this document is only a recommendation and should not be
considered an HL7 standard.
Purpose
This document is intended to:
Describe the HL7 V2.x Message Profile concept
Recommend a specification for defining specific message profiles of HL7
V2.x messages
Facilitate HL7 V2.x interpretation by users familiar with the HL7
standard, reducing interface analysis time and dissatisfaction with the
HL7 V2.x standard.
Reader
Prerequisites
The reader should be familiar with the HL7 V2.x Standard and the HL7 V3.0
Message Development Framework (MDF).
Acknowledgements
The HL7 Conformance SIG would like to thank those involved in the creation of
this specification, especially the healthcare providers and vendors who have
implemented HL7 V2.x message profiles. Such experience has been vital in
creating a quality specification that provides the structure and flexibility to work
in our complex subject area.
NOTE
For updates to this document and related information, visit the HL7 Web Site at
http://www.hl7.org. The work of the Conformance Special Interest Group is located
under Committees.
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
2 HL7 V2.x Message Profiling
2.1
Overview
HL7
Compliance
HL7 V2.x is the most widely implemented health-related standard, domestically
and internationally.
It is impossible to measure the compliance of HL7 V2.x interfaces relying only on
the HL7 2.x base standard. Often vendors claim compliance to HL7 without
providing supporting documentation. HL7 V2.x provides little more than a starting
point for vendor negotiation, and terms like HL7-like or HL7-ish are frequently
used to describe HL7 interfaces. As a result, interfacing continues to be slow,
painful, and costly.
Message
Profiling
HL7 V2.x Message Profiling provides a guideline for documenting particular uses
of HL7 messages. A defined V2.x message profile will be registered with HL7 and
may be reused by other HL7 users, moving the HL7 V2.x standard closer to “plug
and play” interfaces.
With consistent and complete V2.x Message Profile documentation, HL7 V2.x
interface partners explicitly understand:
NOTE
03/09/2000
What data will be passed
The format in which the data will be passed
The acknowledgement responsibilities of the sender and receiver.
Illustrations in this document are included only as examples and are not intended
to indicate all possible aspects of an HL7 Message Profile specification.
Copyright
2000, by Health Level Seven, Inc.
Page
2.2
What is an HL7 V2.x Message Profile?
Definition
An HL7 V2.x Message Profile is a precise and unambiguous specification of a
standard HL7 message that has been analyzed for use within a particular set of
requirements. It is a particular style or usage of a standard HL7 message, driven
by use case analysis and interaction modeling.
An HL7 V2.x Message Profile defines both the static structure and content of the
message and the dynamic interaction, which involves the communication of the
message from the sending application to one or more receiving applications.
Components
HL7 V2.x Message Profiles must consist of the following components:
Use Case Model - this may be a use case diagram supported with text or
just a textual description
Static Definition – consisting of Message Level Profile, Segment Level
Profile, and Field Level Profile
Dynamic Definition – consisting of an Interaction Model and Dynamic
Profile
HL7
Compliance
An HL7 V2.x Message Profile is compliant, in all aspects, with the HL7 defined
message it profiles, although it may specify constraints on the standard HL7
message definition.
Message Profile
Representation
An HL7 V2.x Message Profile should be expressed in tabular format. If XML is
used, profile creators must follow the informative XML document put forth by the
HL7 XML Special Interest Group.
In the Static Definition, for example, an HL7 V2.x Message Profile may limit the
cardinality of segments within the message, limit the cardinality of fields within
segments, or specify a set of user-defined table values.
Examples
In the Dynamic Definition, for example, the Message Profile may define whether
the message requires an accept acknowledgment or an application
acknowledgment.
NOTE
03/09/2000
HL7 V2.x Message Profile creators should follow the use case and interaction
model guidelines documented in the HL7 V3.0 Message Development
Framework (MDF).
Copyright
2000, by Health Level Seven, Inc.
Page
2.3
HL7 V2.x Message Profile Components
2.3.1 Use Case Model
Definition
A Use Case Model (Figure 2.1) documents the scope and requirements for an HL7
V2.x Message Profile or set of Message Profiles. The model includes a diagram
and detailed text.
Requirements
The Use Case Model must:
Tool
Reference
Figure 2.1
03/09/2000
Provide a name that clearly and concisely defines the exchange
Define the actors, including the sending and receiving applications
Define the responsibilities of these actors
Document the situations in which the exchange of a particular HL7
Message Profile is required
Document the purpose for each message exchange.
HL7 does not require the use of a Computer Assisted Software Engineering
(CASE) tool to develop Use Case Model. If you have a CASE tool, by all means
use it! If not, provide a textual description of the use case model in support of
your profile.
Refer to the HL7 V3.0 Message Development Framework (MDF) for further
information on use case models and their uses within HL7.
Use Case Model Example (next page)
Copyright
2000, by Health Level Seven, Inc.
Page
Admit/Visit Notification
Physician
is subject of
Patient
sends notification
authorizes
triggers
Admit/Visit Notification
Registrar
receives notification
ADT Notification
Recipient
ADT System
Description: A patient is admitted to the healthcare facility.
Actors:
1. Patient – is the recipient of healthcare services and is the subject of the admission to a healthcare
facility.
2. Physician – is legally responsible for admitting a patient to a healthcare facility.
3. Registrar – is responsible for processing an admission request.
4. ADT System – is responsible for sending a notification to interested subscribers when a patient is
admitted to a healthcare facility.
5. ADT Notification Recipient – is responsible for receiving notification of patient admissions.
Preconditions:
1. A Patient is presented to the healthcare facility.
2. ADT Notification Recipients have subscribed for patient admission/visit event notifications.
3. The Physician authorizes the Patient for admission to the healthcare facility.
4. The Registrar processes the admission request.
Flow of Events:
1. The ADT System sends notification of the patient admission to all subscribers of this event.
2. Upon receipt of a patient admit/visit notification, the ADT Notification Recipient acknowledges that
the event notification was received.
3. The ADT System receives the acknowledgement. If no acknowledgement is received or the
acknowledgement indicates that the notification was not received, then the ADT System logs an error.
Post Conditions:
1. All ADT Notification Recipients are aware that the Patient has been admitted.
Derives Events:
1. ADT^A01 {joint-iso-ccitt(2) country(16) US(840) organization (1) hl7(1) v2-3(5) static-profile(1)
adt(3) a01(1) null(0) null(0) v1(1)}
2. ACK^A01 {{joint-iso-ccitt(2) country(16) US(840) organization (1) hl7(1) v2-3(5) static-profile(1)}
Figure 2.1
Use Case Model Example
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
2.3.2 Static Definition of an HL7 V2.x Message Profile
The static definition of an HL7 V2.x Message Profile is directly associated with
its corresponding message in HL7 V2.x Standard. A complete HL7 V2.x Message
Profile shall be defined at the message, segment, and field levels.
Definition
Once again, an HL7 V2.x Message Profile is compliant in all aspects with the
HL7-defined message it profiles. However, the HL7 V2.x Message Profile may
define additional constraints on the standard HL7 message.
Constraints on
HL7 Messages
A static profile identifies only those specific elements of a standard HL7 message
that are used in the exchange.
A static profile removes all instances of optionality, defining explicitly:
Segments, segment groups, fields and components
Cardinalities
Value sets and coding systems.
Static Message Profile Example – ADT^A01
Figure 2.2
ADT^A01
HL7 Message Profile
HL7 Message Structure
MSH
MSH
EVN
EVN
PID
PID
Segments/Segment Groups:
- Cardinality (min, max)
NK1
NK1
NK1
NK1
NK1
NK1
NK1
...
PV1
NK1
NK1
NK1
...
PV1
...
...
PV2
PV2
OBX
OBX
AL1
AL1
...
...
Fields/Components:
- Field Usage (Optionality)
(R, RE, C, CE, X)
- Cardinality (max repeats)
- Value Sets/Coding system
- Descriptions
Figure 2.2
Static Message Profile Example – ADT^A01
As Figure 2.2 depicts, think of the HL7 Message Profile as an overlay of the HL7 Message Structure that
is further constrained. For example, where the HL7 Message Structure shows unlimited number of NK1
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
Segments, the HL7 Message Profile allows for only three repetitions. Additionally, fields that are optional
in the HL7 Message Structure may be required within the HL7 Message Profile.
2.3.2.1
Message Level Profile
Segment
Definitions
The set of segments included within the message of an HL7 V2.x Message Profile
shall be defined.
Any segments that are required by HL7 shall be included.
Segment
Cardinality
Some segments within HL7 Standard Messages are allowed to repeat. The
cardinality of all the segments within the message shall be defined.
The minimum cardinality shall be specified.
Where known, the maximum cardinality shall also be specified, or
specified as unlimited by using the asterisk symbol (*).
Allowable Values:
[0..0] - Segment not Used
[0..1] - Segment is Optional, but can only be have one Occurrence
[1..1] - Segment is Required, only one Occurrence
[0..n] - Segment is Optional, or may repeat n times.
[1..n] - Segment is Required, and may repeat up to n times
[0..*] - Segment is Optional, or may repeat unlimited number of times
[1..*] - Segment is Required, and may repeat unlimited number of times
Syntax
The message level profile shall be documented using the HL7 abstract message
syntax, with the addition of specifying cardinality for each of the segments
contained within the message structure.
Figure 2.3
Message Level Profile Example – Standard ADT^A01 Message Definition
(next page)
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
ADT
ADT Message
MSH
EVN
PID
[ { NK1
PV1
PV2
[ { OBX
[ { AL1
[ { DG1
[ { PR1
[ { GT1
[
{ IN1
[ IN2
[ IN3
}
]
[ ACC ]
[ UB1 ]
[ UB2 ]
} ]
}
}
}
}
}
]
]
]
]
]
]
]
[1,1]
[1,1]
[1,1]
[0,3]
[0,1]
[0,1]
[0,0]
[0,*]
[0,0]
.[0,0]
[0,0]
[0,0]
[0,0]
[0,0]
[0,0]
-----[0,0]
[0,0]
[0,0]
Chapter
Message Header
Event Type
Patient Identification
Next of Kin
Visit Info
Visit - additional info
Observation/Result
Allergy Information
Diagnosis Information
Procedures
Guarantor Information
2
3
3
3
3
3
7
3
6
6
6
Insurance Information
Insurance Information - Addit. Info.
Insurance Information - Cert.
6
6
6
Accident Information
Universal Bill Information
Universal Bill 92 Information
6
6
6
Figure 2.3
Message Level Profile Example –
Standard ADT^A01 Message Definition
2.3.2.2 Segment Level Profile
Segment
Profiles
The set of fields of each instance of an HL7-defined segment within the HL7 V2.x
Message Profile shall be specified.
The result of this definition is a segment profile (Figure 2.4). If a segment occurs
multiple times within a message profile, it may be represented by different segment
profiles. This shall be explicitly defined within the Message Profile specification.
Segment Profile
Format
The segment level profile shall be documented using the tabular format employed
for the HL7 segment definitions.
03/09/2000
The length column shall be updated to accurately reflect the maximum
allowed length for the field within this profile.
The R/O column shall be updated to reflect the usage of the field within
the particular segment of the message profile (see the following
paragraph, Field Usage).
The RP/# column shall accurately reflect the maximum number of
repetitions of the field allowed for this segment within this message
profile.
Copyright
2000, by Health Level Seven, Inc.
Page
Field Usage
The usage of the field shall be defined using one of the following allowed values:
R
Required.
A conforming sending application shall provide a valid value for all “R”
fields. The value shall be of the specified type and within the range
specified for the field.
For complete compatibility with HL7, any field designated as “Required”
in a standard HL7 message definition shall also be required in all HL7
Message Profiles of that standard message.
RE
Required but may be empty.
A conforming sending application shall be capable of providing a valid
value for all “RE” fields. If the conforming sending application knows the
value for this field, then a field value shall be provided of the specified
type and within the range specified for the field. If the conforming
sending application does not know the value for this field, then the field
value shall be specified as empty. For this usage, empty is a distinguished
value.
C
Conditional.
There is a predicate associated with this field that identifies the conditions
under which the value of the field shall be specified. The predicate must
be based on other field values within this message. This predicate may be
expressed as a mathematical expression or in text and may utilize
operators such as equivalence, logical AND, and logical OR. The
conforming sending application shall evaluate the predicate. If the
predicate is satisfied, then the conforming sending application shall
provide a value of the specified type and within the range specified for the
field. If the predicate is not satisfied, then the field value shall be
specified as empty.
CE
Conditional but may be empty.
There is a predicate associated with this field which identifies the
conditions under which the value of the field shall be specified. The
predicate must be based on other field values within this message. This
predicate may be expressed as a mathematical expression or in text and
may utilize operators such as equivalence, logical AND, and logical OR.
The conforming sending application shall evaluate the predicate.
If the predicate is satisfied and the conforming sending application knows
the value for the field, then the conforming sending application shall
provide a value of the specified type and within the range specified for the
field. If the predicate is satisfied but the conforming sending application
does not know the value for this field, then the field value shall be
specified as empty. If the predicate is not satisfied, then the field value
shall be specified as empty.
X
03/09/2000
Not supported.
These fields will not be supported. A conforming sending application will
not create a message with a value for these fields. A conforming receiving
Copyright
2000, by Health Level Seven, Inc.
Page
application will not obtain the value of this field contained within the
message. In the case of HL7 V2.x Encoding Rules, these fields are
expected to be empty.
Segment Level Profile Example – PID (Patient Identification) Segment
Figure 2.4
SEQ
LEN
DT
OPT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
4
20
20
20
48
48
26
1
48
80
106
4
40
40
60
80
80
20
16
25
20
80
60
1
2
80
60
80
26
1
SI
CX
CX
CX
XPN
XPN
TS
IS
XPN
CE
XAD
IS
XTN
XTN
CE
CE
CE
CX
ST
DLN
CX
CE
ST
ID
NM
CE
CE
CE
TS
ID
X
RE
R
X
R
RE
RE
RE
X
X
RE
X
X
X
X
X
X
X
RE
X
X
X
RE
X
X
X
X
X
X
X
RP/#
TBL#
Y
Y
Y
Y
0001
Y
Y
Y/3
0005
0289
Y/3
Y/3
0296
0002
0006
Y
Y
0189
0136
Y
0171
0172
0212
0136
ITEM#
ELEMENT NAME
00104
00105
00106
00107
00108
00109
00110
00111
00112
00113
00114
00115
00116
00117
00118
00119
00120
00121
00122
00123
00124
00125
00126
00127
00128
00129
00130
00739
00740
00741
Set ID - PID
Patient ID
Patient Identifier List
Alternate Patient ID - PID
Patient Name
Mother’s Maiden Name
Date/Time of Birth
Sex
Patient Alias
Race
Patient Address
County Code
Phone Number - Home
Phone Number - Business
Primary Language
Marital Status
Religion
Patient Account Number
SSN Number - Patient
Driver's License Number - Patient
Mother's Identifier
Ethnic Group
Birth Place
Multiple Birth Indicator
Birth Order
Citizenship
Veterans Military Status
Nationality
Patient Death Date and Time
Patient Death Indicator
Figure 2.4
Segment Level Profile Example (PID Segment)
2.3.2.3 Field Level Profile
Field
Definitions
Each individual field within a segment shall be completely defined to eliminate any
possible ambiguity.
In cases where HL7 2.x field descriptions are unclear or ambiguous, a more
precise semantic definition shall be specified.
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
User-Defined
and Suggested
Field Values
The allowed value set for many fields within the HL7 V2.x Standard is specified
as user-defined or containing only HL7 suggested values.
In these cases, the exact allowed value set shall be specified. These values shall
be defined by agreement between the sending and receiving application vendors.
Coded Entry (CE) type fields are specified as being populated based on coding
systems. For each of these fields, the specific coding system used shall be
identified. (See Figure 2.6 for an example of a CE type field.)
Many fields in HL7 V2.x are defined to be Composite Data (CM) types. Each
component within these composite fields shall be profiled. This requires defining
the usage, length, data type, and cardinality of each of the components. Where
there are sub-components of a component, each of the sub-components shall also
be profiled using the same criteria.
Figure 2.5
Field Description Example – OBX-8 Field (next page)
Figure 2.6
CE Data Type Example – OBX-5 Field (next page)
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
OBX- 8 Abnormal flags (ID) 00576
Definition: This field is used to indicate the normalcy status of the result.
This field shall be specified with a repeat count of three (3). The first repetition shall specify the
abnormal flag. The second repetition shall specify the delta flag. The third repetition shall specify
the microbial susceptibilities.
Values that may be specified for each repetition of this field are:
abnormal flags
alpha {N,A,AA,CNM}
numeric {L,H,LL,HH,CNM,<,>}
delta flags
alpha {B,W}
numeric {U,D}
microbial susceptibility flags {S,R,I,MS,VS}
Only the most extreme flag for each repetition of the field shall be specified.
Note that the value “CNM” (Could Not Measure) has been added to HL7 table #0078.
Figure 2.5
Field Description Example – OBX-8 Field
The following is a profile of the CE data type, used in the OBX-5 field for including the value for
an observation.
In this HL7 Message Profile, codes will not always apply. In these situations, only the “text”
component is required. If the sending application does not know the identifier, then the identifier
component may be left empty. If the identifier component is specified, the “name of coding
system” component must be specified.
SEQ
LEN
1
2
3
4
5
6
12
80
25
12
80
25
DT
ID
TX
ST
ID
TX
ST
R/O
RP/#
RE
R
C
RE
RE
RE
TBL#
Item #
Component Name
identifier
text
name of coding system
alternate identifier
alternate text
name of alternate coding system
Figure 2.6
CE Data Type Example – OBX-5 Field
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
2.3.3 Dynamic Definition of an HL7 V2.x Message Profile
Definition
The dynamic definition of an HL7 V2.x Message Profile identifies the
acknowledgment mode supported for the interaction between the sending
application and the receiving application(s).
2.3.3.1 Interaction Model
Definition
An Interaction Model (Figure 2.7) shall be included with the HL7 V2.x Message
Profile dynamic specification. This model defines specific interactions between the
applications that support message profile communication requirements.
The Interaction Model includes interaction diagrams that illustrate the sequence
of trigger event and resulting message flows between the sending and receiving
applications.
Reference
Refer to HL7 V3.0 Message Development Framework (MDF) for further
information regarding interaction models and their uses within HL7.
Figure 2.7
Interaction Model Example – ADT^A01/ACK^A01
: ADT System
: Clinical
Information System
ADT^A01( )
ACK^A01
Figure 2.7
Interaction Model Example – ADT^A01
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
2.3.3.2 Dynamic Profiles
Acknowledgements
The specific HL7 acknowledgments required and/or allowed for use with the
specified static definition of the HL7 V2.x Message Profile shall be defined.
Specifically, the dynamic profile shall identify whether an accept and/or
application level acknowledgment is allowed or required.
For any one static message profile there may be one or more dynamic message
profiles.
Conditions
The dynamic profile shall define the conditions under which an accept and/or
application level acknowledgments is expected.
Allowed conditions include:
Always
Never
Only on success
Only on error.
The specific success or error conditions must be specified.
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
3 Identification of HL7 Message Profiles Using ASN.1
Profile
Identifiers
HL7 Message Profiles shall be uniquely identified with static and dynamic profile
identifiers.
The sending application uses the profile identifiers to determine the specific HL7
Message Profile to send.
The receiving application uses the profile identifiers to determine:
3.1
Which HL7 Message Profile it has received
What data to expect from the sending application
Its responsibility as a receiver.
Static Profile Identifier
Definition
The static profile identifier is a means to uniquely identify a message profile. The
static profile identifier is expressed as an ASN.1 Object Identifier (OID).
Figure 2.8
Static Profile Identifier Example (next page)
Figure 2.9
Registration Tree for ADT, ORM, and ORU Messages (next page)
NOTE: The registration authority represents the branch from ISO to HL7 and is
specified as joint-iso-ccitt(2) country(16) US(840) organization(1) hl7(113883).
{ joint-iso-ccitt(2) country(16) US(840) organization(1) hl7(113883) v2-3(5) staticprofile(1) adt(3) a01(1) null(0) null(0) v1(1) }
For efficient communication, the identifier may be specified using the integer form:
{2 16 840 1 113883 5 1 3 1 0 0 1}
Figure 2.8
Static Profile Identifier Example
Note: The tree structure below is not a representation of the Figure 2.8 example.
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
Figure 2.9
Registration Tree for ADT, ORM, and ORU Messages
Note: This tree structure is provided to depict how the identifier changes based on the HL7 message that
is exchanged. This structure does not show all the administrative levels as defined in Figure 2.8.
3.2
Dynamic Profile Identifier
Definition
The dynamic profile identifier is a means to uniquely identify the dynamic aspects
of a message profile. The dynamic profile identifier is expressed as an ASN.1
Object Identifier (OID).
Figure 2.10
Dynamic Profile Identifier Example (next page)
Figure 2.11
Dynamic Profile Registration Tree Example (next page)
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
{ joint-iso-ccitt(2) country(16) US(840) organization(1) hl7(113883) v2-3(5) dynamicprofile(2) AccNE_AppNE(6) }
For efficient communication, the identifier may be specified using the integer form:
{2 16 840 1 113883 5 2 6}
Figure 2.10
Dynamic Profile Identifier Example
The identifier values for the possible combinations are given in the table below.
Acknowledge-ment Application
Accept Acknowledgement
AL
NE
SU
ER
AL
1
5
9
13
NE
2
6
10
14
SU
3
7
11
15
ER
4
8
12
16
Figure 2.11
Dynamic Profile Registration Tree Example
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
Physician
is subject of
Patient
authorizes
triggers
Registrar
Message Profile Example
sends notification
ADT System
Patient
receives notification
Physician
Admit/Visit Notification
is subject of
sends notification
authorizes ADT Notification
triggers
Recipient
Registrar
receives notification
Admit/Visit Notification
Use Case Model
ADT System
ADT Notification
Recipient
: ADT System
USE CASE MODEL...................................................................................................
USE CASE: ADMIT/VISIT NOTIFICATION.........................................................
DYNAMIC INTERACTION MODEL.....................................................................
STATIC PROFILE: ADT/ACK (EVENT A01).........................................................
ADT^A01
3.1
3.2
ADT^A01............................................................................................................................
ACK^A01............................................................................................................................
ACK^A01
4.
DYNAMIC PROFILE: ADT/ACK (EVENT A01)....................................................
4.1
4.2
ADT^A01............................................................................................................................
ACK^A01............................................................................................................................
5.
SEGMENT PROFILES..............................................................................................
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
MSH – MESSAGE HEADER SEGMENT DEFINITION...........................................................
EVN - EVENT TYPE SEGMENT DEFINITION.......................................................................
PID (Y) - PATIENT DEMOGRAPHICS SEGMENT DEFINITION.............................................
PD1 – PATIENT ADDITIONAL DEMOGRAPHIC SEGMENT DEFINITION..............................
NK1 - NEXT OF KIN SEGMENT DEFINITION.......................................................................
PV1 (2) - ADMIT VISIT INFO SEGMENT DEFINITION.........................................................
AL1 - ALLERGY SEGMENT DEFINITION.............................................................................
MSA - MESSAGE ACKNOWLEDGMENT SEGMENT DEFINITION.........................................
ERR - ERROR SEGMENT DEFINITION.................................................................................
6.
TABLES.......................................................................................................................
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
6.12
6.13
6.14
6.15
6.16
TABLE 0001 – SEX..............................................................................................................
TABLE 0002 – MARITAL STATUS........................................................................................
TABLE 0003 – EVENT TYPE CODE....................................................................................
TABLE 0004 – PATIENT CLASS...........................................................................................
TABLE 0005 – RACE...........................................................................................................
TABLE 006 – RELIGION......................................................................................................
TABLE 0007 – ADMISSION TYPE........................................................................................
TABLE 0008 – ACKNOWLEDGEMENT CODE......................................................................
TABLE 0009 – AMBULATORY STATUS................................................................................
TABLE 0010 – ADMITTING/ATTENDING/REFERRING/CONSULTING DOCTOR..................
TABLE 0018 – PATIENT TYPE.............................................................................................
TABLE 0023 – ADMIT SOURCE..........................................................................................
TABLE 0062 – EVENT REASON CODE...............................................................................
TABLE 0063 – RELATIONSHIP............................................................................................
TABLE 0069 – HOSPITAL SERVICE.....................................................................................
TABLE 0087 – PREADMIT TEST INDICATOR......................................................................
6.17TABLE 0092 – READMISSION INDICATOR.........................................
Static Profile
Interaction Model
Dynamic Profile
Segment Profiles
Tables
03/09/2000
: ADT Notification
Recipient
1.
1.1
2.
3.
Copyright
2000, by Health Level Seven, Inc.
Page 19
4 OPEN Issues
Conformancebased Queries
Tool related
Information
Since the origin of this document, HL7 has published HL7 V2.4 Chapter 5 Conformance-based Queries. The Conformance Special Interest Group and the
Control/Query Technical Committee have assigned a work group to work on
aligning the two standards.
A proposal has been written and the groups will review at the January 2001 HL7
Working Group Meeting.
We are currently working on a tool to facilitate the creation and browsing of a
profile tool. As the tool becomes available, this documentation will be updated to
reflect its usage.
HL7 Profile
Registration
The Conformance SIG is currently working with HL7 Headquarters to provide the
profile registration utility on the HL7 Web Site. As this utility becomes a reality,
this document will be updated.
Registration
Authority
The registration authority represents the branch from ISO to HL7 and is
specified as joint-iso-ccitt(2) country(16) US(840) organization(1) hl7(113883).
***has this registration been done by HL7? if so, who does it... if not is it the
intent of this sig to do it? where are the registration OID numbers kept (?HL7
website?), etc. etc. same question for dynamic profile identifier....
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page 20
Version 2.x
Message Profiling Specification
Version 2.2
November 30, 2000
Copyright
2000, by Health Level Seven, Inc.
Table of Contents
1
INTRODUCTION..................................................................................................................................2
2
HL7 V2.X MESSAGE PROFILING....................................................................................................3
2.1
OVERVIEW.................................................................................................................................. 3
2.2
WHAT IS AN HL7 V2.X MESSAGE PROFILE?................................................................................4
2.3
HL7 V2.X MESSAGE PROFILE COMPONENTS...............................................................................5
2.3.1
Use Case Model.......................................................................................................................5
2.3.2
Static Definition of an HL7 V2.x Message Profile..................................................................7
2.3.2.1
2.3.2.2
2.3.2.3
2.3.3
2.3.3.1
2.3.3.2
3
Message Level Profile.......................................................................................................................8
Segment Level Profile.......................................................................................................................9
Field Level Profile...........................................................................................................................12
Dynamic Definition of an HL7 V2.x Message Profile...........................................................14
Interaction Model.............................................................................................................................14
Dynamic Profiles.............................................................................................................................15
IDENTIFICATION OF HL7 MESSAGE PROFILES USING ASN.1............................................16
3.1
STATIC PROFILE IDENTIFIER...................................................................................................... 16
3.2
DYNAMIC PROFILE IDENTIFIER.................................................................................................. 17
Figure 2.11.............................................................................................................................................18
4
OPEN ISSUES......................................................................................................................................20
Copyright
2000, by Health Level Seven, Inc.
1 Introduction
Document
History
This document is the result of a project begun in 1997 by the Health Level Seven
(HL7) Conformance Special Interest Group (SIG). The HL7 Conformance SIG,
in conjunction with the Andover Working Group (AWG), prepared this
specification based on the experience of vendors and healthcare providers who
have defined and implemented message profiles.
Scope
In its current form, this document is only a recommendation and should not be
considered an HL7 standard.
Purpose
This document is intended to:
Describe the HL7 V2.x Message Profile concept
Recommend a specification for defining specific message profiles of HL7
V2.x messages
Facilitate HL7 V2.x interpretation by users familiar with the HL7
standard, reducing interface analysis time and dissatisfaction with the
HL7 V2.x standard.
Reader
Prerequisites
The reader should be familiar with the HL7 V2.x Standard and the HL7 V3.0
Message Development Framework (MDF).
Acknowledgements
The HL7 Conformance SIG would like to thank those involved in the creation of
this specification, especially the healthcare providers and vendors who have
implemented HL7 V2.x message profiles. Such experience has been vital in
creating a quality specification that provides the structure and flexibility to work
in our complex subject area.
NOTE
For updates to this document and related information, visit the HL7 Web Site at
http://www.hl7.org. The work of the Conformance Special Interest Group is located
under Committees.
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
2 HL7 V2.x Message Profiling
2.1
Overview
HL7
Compliance
HL7 V2.x is the most widely implemented health-related standard, domestically
and internationally.
It is impossible to measure the compliance of HL7 V2.x interfaces relying only on
the HL7 2.x base standard. Often vendors claim compliance to HL7 without
providing supporting documentation. HL7 V2.x provides little more than a starting
point for vendor negotiation, and terms like HL7-like or HL7-ish are frequently
used to describe HL7 interfaces. As a result, interfacing continues to be slow,
painful, and costly.
Message
Profiling
HL7 V2.x Message Profiling provides a guideline for documenting particular uses
of HL7 messages. A defined V2.x message profile will be registered with HL7 and
may be reused by other HL7 users, moving the HL7 V2.x standard closer to “plug
and play” interfaces.
With consistent and complete V2.x Message Profile documentation, HL7 V2.x
interface partners explicitly understand:
NOTE
03/09/2000
What data will be passed
The format in which the data will be passed
The acknowledgement responsibilities of the sender and receiver.
Illustrations in this document are included only as examples and are not intended
to indicate all possible aspects of an HL7 Message Profile specification.
Copyright
2000, by Health Level Seven, Inc.
Page
2.2
What is an HL7 V2.x Message Profile?
Definition
An HL7 V2.x Message Profile is a precise and unambiguous specification of a
standard HL7 message that has been analyzed for use within a particular set of
requirements. It is a particular style or usage of a standard HL7 message, driven
by use case analysis and interaction modeling.
An HL7 V2.x Message Profile defines both the static structure and content of the
message and the dynamic interaction, which involves the communication of the
message from the sending application to one or more receiving applications.
Components
HL7 V2.x Message Profiles must consist of the following components:
Use Case Model - this may be a use case diagram supported with text or
just a textual description
Static Definition – consisting of Message Level Profile, Segment Level
Profile, and Field Level Profile
Dynamic Definition – consisting of an Interaction Model and Dynamic
Profile
HL7
Compliance
An HL7 V2.x Message Profile is compliant, in all aspects, with the HL7 defined
message it profiles, although it may specify constraints on the standard HL7
message definition.
Message Profile
Representation
An HL7 V2.x Message Profile should be expressed in tabular format. If XML is
used, profile creators must follow the informative XML document put forth by the
HL7 XML Special Interest Group.
In the Static Definition, for example, an HL7 V2.x Message Profile may limit the
cardinality of segments within the message, limit the cardinality of fields within
segments, or specify a set of user-defined table values.
Examples
In the Dynamic Definition, for example, the Message Profile may define whether
the message requires an accept acknowledgment or an application
acknowledgment.
NOTE
03/09/2000
HL7 V2.x Message Profile creators should follow the use case and interaction
model guidelines documented in the HL7 V3.0 Message Development
Framework (MDF).
Copyright
2000, by Health Level Seven, Inc.
Page
2.3
HL7 V2.x Message Profile Components
2.3.1 Use Case Model
Definition
A Use Case Model (Figure 2.1) documents the scope and requirements for an HL7
V2.x Message Profile or set of Message Profiles. The model includes a diagram
and detailed text.
Requirements
The Use Case Model must:
Tool
Reference
Figure 2.1
03/09/2000
Provide a name that clearly and concisely defines the exchange
Define the actors, including the sending and receiving applications
Define the responsibilities of these actors
Document the situations in which the exchange of a particular HL7
Message Profile is required
Document the purpose for each message exchange.
HL7 does not require the use of a Computer Assisted Software Engineering
(CASE) tool to develop Use Case Model. If you have a CASE tool, by all means
use it! If not, provide a textual description of the use case model in support of
your profile.
Refer to the HL7 V3.0 Message Development Framework (MDF) for further
information on use case models and their uses within HL7.
Use Case Model Example (next page)
Copyright
2000, by Health Level Seven, Inc.
Page
Admit/Visit Notification
Physician
is subject of
Patient
sends notification
authorizes
triggers
Admit/Visit Notification
Registrar
receives notification
ADT Notification
Recipient
ADT System
Description: A patient is admitted to the healthcare facility.
Actors:
1. Patient – is the recipient of healthcare services and is the subject of the admission to a healthcare
facility.
2. Physician – is legally responsible for admitting a patient to a healthcare facility.
3. Registrar – is responsible for processing an admission request.
4. ADT System – is responsible for sending a notification to interested subscribers when a patient is
admitted to a healthcare facility.
5. ADT Notification Recipient – is responsible for receiving notification of patient admissions.
Preconditions:
1. A Patient is presented to the healthcare facility.
2. ADT Notification Recipients have subscribed for patient admission/visit event notifications.
3. The Physician authorizes the Patient for admission to the healthcare facility.
4. The Registrar processes the admission request.
Flow of Events:
1. The ADT System sends notification of the patient admission to all subscribers of this event.
2. Upon receipt of a patient admit/visit notification, the ADT Notification Recipient acknowledges that
the event notification was received.
3. The ADT System receives the acknowledgement. If no acknowledgement is received or the
acknowledgement indicates that the notification was not received, then the ADT System logs an error.
Post Conditions:
1. All ADT Notification Recipients are aware that the Patient has been admitted.
Derives Events:
1. ADT^A01 {joint-iso-ccitt(2) country(16) US(840) organization (1) hl7(1) v2-3(5) static-profile(1)
adt(3) a01(1) null(0) null(0) v1(1)}
2. ACK^A01 {{joint-iso-ccitt(2) country(16) US(840) organization (1) hl7(1) v2-3(5) static-profile(1)}
Figure 2.1
Use Case Model Example
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
2.3.2 Static Definition of an HL7 V2.x Message Profile
The static definition of an HL7 V2.x Message Profile is directly associated with
its corresponding message in HL7 V2.x Standard. A complete HL7 V2.x Message
Profile shall be defined at the message, segment, and field levels.
Definition
Once again, an HL7 V2.x Message Profile is compliant in all aspects with the
HL7-defined message it profiles. However, the HL7 V2.x Message Profile may
define additional constraints on the standard HL7 message.
Constraints on
HL7 Messages
A static profile identifies only those specific elements of a standard HL7 message
that are used in the exchange.
A static profile removes all instances of optionality, defining explicitly:
Segments, segment groups, fields and components
Cardinalities
Value sets and coding systems.
Static Message Profile Example – ADT^A01
Figure 2.2
ADT^A01
HL7 Message Profile
HL7 Message Structure
MSH
MSH
EVN
EVN
PID
PID
Segments/Segment Groups:
- Cardinality (min, max)
NK1
NK1
NK1
NK1
NK1
NK1
NK1
...
PV1
NK1
NK1
NK1
...
PV1
...
...
PV2
PV2
OBX
OBX
AL1
AL1
...
...
Fields/Components:
- Field Usage (Optionality)
(R, RE, C, CE, X)
- Cardinality (max repeats)
- Value Sets/Coding system
- Descriptions
Figure 2.2
Static Message Profile Example – ADT^A01
As Figure 2.2 depicts, think of the HL7 Message Profile as an overlay of the HL7 Message Structure that
is further constrained. For example, where the HL7 Message Structure shows unlimited number of NK1
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
Segments, the HL7 Message Profile allows for only three repetitions. Additionally, fields that are optional
in the HL7 Message Structure may be required within the HL7 Message Profile.
2.3.2.1
Message Level Profile
Segment
Definitions
The set of segments included within the message of an HL7 V2.x Message Profile
shall be defined.
Any segments that are required by HL7 shall be included.
Segment
Cardinality
Some segments within HL7 Standard Messages are allowed to repeat. The
cardinality of all the segments within the message shall be defined.
The minimum cardinality shall be specified.
Where known, the maximum cardinality shall also be specified, or
specified as unlimited by using the asterisk symbol (*).
Allowable Values:
[0..0] - Segment not Used
[0..1] - Segment is Optional, but can only be have one Occurrence
[1..1] - Segment is Required, only one Occurrence
[0..n] - Segment is Optional, or may repeat n times.
[1..n] - Segment is Required, and may repeat up to n times
[0..*] - Segment is Optional, or may repeat unlimited number of times
[1..*] - Segment is Required, and may repeat unlimited number of times
Syntax
The message level profile shall be documented using the HL7 abstract message
syntax, with the addition of specifying cardinality for each of the segments
contained within the message structure.
Figure 2.3
Message Level Profile Example – Standard ADT^A01 Message Definition
(next page)
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
ADT
ADT Message
MSH
EVN
PID
[ { NK1
PV1
PV2
[ { OBX
[ { AL1
[ { DG1
[ { PR1
[ { GT1
[
{ IN1
[ IN2
[ IN3
}
]
[ ACC ]
[ UB1 ]
[ UB2 ]
} ]
}
}
}
}
}
]
]
]
]
]
]
]
[1,1]
[1,1]
[1,1]
[0,3]
[0,1]
[0,1]
[0,0]
[0,*]
[0,0]
.[0,0]
[0,0]
[0,0]
[0,0]
[0,0]
[0,0]
-----[0,0]
[0,0]
[0,0]
Chapter
Message Header
Event Type
Patient Identification
Next of Kin
Visit Info
Visit - additional info
Observation/Result
Allergy Information
Diagnosis Information
Procedures
Guarantor Information
2
3
3
3
3
3
7
3
6
6
6
Insurance Information
Insurance Information - Addit. Info.
Insurance Information - Cert.
6
6
6
Accident Information
Universal Bill Information
Universal Bill 92 Information
6
6
6
Figure 2.3
Message Level Profile Example –
Standard ADT^A01 Message Definition
2.3.2.2 Segment Level Profile
Segment
Profiles
The set of fields of each instance of an HL7-defined segment within the HL7 V2.x
Message Profile shall be specified.
The result of this definition is a segment profile (Figure 2.4). If a segment occurs
multiple times within a message profile, it may be represented by different segment
profiles. This shall be explicitly defined within the Message Profile specification.
Segment Profile
Format
The segment level profile shall be documented using the tabular format employed
for the HL7 segment definitions.
03/09/2000
The length column shall be updated to accurately reflect the maximum
allowed length for the field within this profile.
The R/O column shall be updated to reflect the usage of the field within
the particular segment of the message profile (see the following
paragraph, Field Usage).
The RP/# column shall accurately reflect the maximum number of
repetitions of the field allowed for this segment within this message
profile.
Copyright
2000, by Health Level Seven, Inc.
Page
Field Usage
The usage of the field shall be defined using one of the following allowed values:
R
Required.
A conforming sending application shall provide a valid value for all “R”
fields. The value shall be of the specified type and within the range
specified for the field.
For complete compatibility with HL7, any field designated as “Required”
in a standard HL7 message definition shall also be required in all HL7
Message Profiles of that standard message.
RE
Required but may be empty.
A conforming sending application shall be capable of providing a valid
value for all “RE” fields. If the conforming sending application knows the
value for this field, then a field value shall be provided of the specified
type and within the range specified for the field. If the conforming
sending application does not know the value for this field, then the field
value shall be specified as empty. For this usage, empty is a distinguished
value.
C
Conditional.
There is a predicate associated with this field that identifies the conditions
under which the value of the field shall be specified. The predicate must
be based on other field values within this message. This predicate may be
expressed as a mathematical expression or in text and may utilize
operators such as equivalence, logical AND, and logical OR. The
conforming sending application shall evaluate the predicate. If the
predicate is satisfied, then the conforming sending application shall
provide a value of the specified type and within the range specified for the
field. If the predicate is not satisfied, then the field value shall be
specified as empty.
CE
Conditional but may be empty.
There is a predicate associated with this field which identifies the
conditions under which the value of the field shall be specified. The
predicate must be based on other field values within this message. This
predicate may be expressed as a mathematical expression or in text and
may utilize operators such as equivalence, logical AND, and logical OR.
The conforming sending application shall evaluate the predicate.
If the predicate is satisfied and the conforming sending application knows
the value for the field, then the conforming sending application shall
provide a value of the specified type and within the range specified for the
field. If the predicate is satisfied but the conforming sending application
does not know the value for this field, then the field value shall be
specified as empty. If the predicate is not satisfied, then the field value
shall be specified as empty.
X
03/09/2000
Not supported.
These fields will not be supported. A conforming sending application will
not create a message with a value for these fields. A conforming receiving
Copyright
2000, by Health Level Seven, Inc.
Page
application will not obtain the value of this field contained within the
message. In the case of HL7 V2.x Encoding Rules, these fields are
expected to be empty.
Segment Level Profile Example – PID (Patient Identification) Segment
Figure 2.4
SEQ
LEN
DT
OPT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
4
20
20
20
48
48
26
1
48
80
106
4
40
40
60
80
80
20
16
25
20
80
60
1
2
80
60
80
26
1
SI
CX
CX
CX
XPN
XPN
TS
IS
XPN
CE
XAD
IS
XTN
XTN
CE
CE
CE
CX
ST
DLN
CX
CE
ST
ID
NM
CE
CE
CE
TS
ID
X
RE
R
X
R
RE
RE
RE
X
X
RE
X
X
X
X
X
X
X
RE
X
X
X
RE
X
X
X
X
X
X
X
RP/#
TBL#
Y
Y
Y
Y
0001
Y
Y
Y/3
0005
0289
Y/3
Y/3
0296
0002
0006
Y
Y
0189
0136
Y
0171
0172
0212
0136
ITEM#
ELEMENT NAME
00104
00105
00106
00107
00108
00109
00110
00111
00112
00113
00114
00115
00116
00117
00118
00119
00120
00121
00122
00123
00124
00125
00126
00127
00128
00129
00130
00739
00740
00741
Set ID - PID
Patient ID
Patient Identifier List
Alternate Patient ID - PID
Patient Name
Mother’s Maiden Name
Date/Time of Birth
Sex
Patient Alias
Race
Patient Address
County Code
Phone Number - Home
Phone Number - Business
Primary Language
Marital Status
Religion
Patient Account Number
SSN Number - Patient
Driver's License Number - Patient
Mother's Identifier
Ethnic Group
Birth Place
Multiple Birth Indicator
Birth Order
Citizenship
Veterans Military Status
Nationality
Patient Death Date and Time
Patient Death Indicator
Figure 2.4
Segment Level Profile Example (PID Segment)
2.3.2.3 Field Level Profile
Field
Definitions
Each individual field within a segment shall be completely defined to eliminate any
possible ambiguity.
In cases where HL7 2.x field descriptions are unclear or ambiguous, a more
precise semantic definition shall be specified.
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
User-Defined
and Suggested
Field Values
The allowed value set for many fields within the HL7 V2.x Standard is specified
as user-defined or containing only HL7 suggested values.
In these cases, the exact allowed value set shall be specified. These values shall
be defined by agreement between the sending and receiving application vendors.
Coded Entry (CE) type fields are specified as being populated based on coding
systems. For each of these fields, the specific coding system used shall be
identified. (See Figure 2.6 for an example of a CE type field.)
Many fields in HL7 V2.x are defined to be Composite Data (CM) types. Each
component within these composite fields shall be profiled. This requires defining
the usage, length, data type, and cardinality of each of the components. Where
there are sub-components of a component, each of the sub-components shall also
be profiled using the same criteria.
Figure 2.5
Field Description Example – OBX-8 Field (next page)
Figure 2.6
CE Data Type Example – OBX-5 Field (next page)
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
OBX- 8 Abnormal flags (ID) 00576
Definition: This field is used to indicate the normalcy status of the result.
This field shall be specified with a repeat count of three (3). The first repetition shall specify the
abnormal flag. The second repetition shall specify the delta flag. The third repetition shall specify
the microbial susceptibilities.
Values that may be specified for each repetition of this field are:
abnormal flags
alpha {N,A,AA,CNM}
numeric {L,H,LL,HH,CNM,<,>}
delta flags
alpha {B,W}
numeric {U,D}
microbial susceptibility flags {S,R,I,MS,VS}
Only the most extreme flag for each repetition of the field shall be specified.
Note that the value “CNM” (Could Not Measure) has been added to HL7 table #0078.
Figure 2.5
Field Description Example – OBX-8 Field
The following is a profile of the CE data type, used in the OBX-5 field for including the value for
an observation.
In this HL7 Message Profile, codes will not always apply. In these situations, only the “text”
component is required. If the sending application does not know the identifier, then the identifier
component may be left empty. If the identifier component is specified, the “name of coding
system” component must be specified.
SEQ
LEN
1
2
3
4
5
6
12
80
25
12
80
25
DT
ID
TX
ST
ID
TX
ST
R/O
RP/#
RE
R
C
RE
RE
RE
TBL#
Item #
Component Name
identifier
text
name of coding system
alternate identifier
alternate text
name of alternate coding system
Figure 2.6
CE Data Type Example – OBX-5 Field
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
2.3.3 Dynamic Definition of an HL7 V2.x Message Profile
Definition
The dynamic definition of an HL7 V2.x Message Profile identifies the
acknowledgment mode supported for the interaction between the sending
application and the receiving application(s).
2.3.3.1 Interaction Model
Definition
An Interaction Model (Figure 2.7) shall be included with the HL7 V2.x Message
Profile dynamic specification. This model defines specific interactions between the
applications that support message profile communication requirements.
The Interaction Model includes interaction diagrams that illustrate the sequence
of trigger event and resulting message flows between the sending and receiving
applications.
Reference
Refer to HL7 V3.0 Message Development Framework (MDF) for further
information regarding interaction models and their uses within HL7.
Figure 2.7
Interaction Model Example – ADT^A01/ACK^A01
: ADT System
: Clinical
Information System
ADT^A01( )
ACK^A01
Figure 2.7
Interaction Model Example – ADT^A01
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
2.3.3.2 Dynamic Profiles
Acknowledgements
The specific HL7 acknowledgments required and/or allowed for use with the
specified static definition of the HL7 V2.x Message Profile shall be defined.
Specifically, the dynamic profile shall identify whether an accept and/or
application level acknowledgment is allowed or required.
For any one static message profile there may be one or more dynamic message
profiles.
Conditions
The dynamic profile shall define the conditions under which an accept and/or
application level acknowledgments is expected.
Allowed conditions include:
Always
Never
Only on success
Only on error.
The specific success or error conditions must be specified.
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
3 Identification of HL7 Message Profiles Using ASN.1
Profile
Identifiers
HL7 Message Profiles shall be uniquely identified with static and dynamic profile
identifiers.
The sending application uses the profile identifiers to determine the specific HL7
Message Profile to send.
The receiving application uses the profile identifiers to determine:
3.1
Which HL7 Message Profile it has received
What data to expect from the sending application
Its responsibility as a receiver.
Static Profile Identifier
Definition
The static profile identifier is a means to uniquely identify a message profile. The
static profile identifier is expressed as an ASN.1 Object Identifier (OID).
Figure 2.8
Static Profile Identifier Example (next page)
Figure 2.9
Registration Tree for ADT, ORM, and ORU Messages (next page)
NOTE: The registration authority represents the branch from ISO to HL7 and is
specified as joint-iso-ccitt(2) country(16) US(840) organization(1) hl7(113883).
{ joint-iso-ccitt(2) country(16) US(840) organization(1) hl7(113883) v2-3(5) staticprofile(1) adt(3) a01(1) null(0) null(0) v1(1) }
For efficient communication, the identifier may be specified using the integer form:
{2 16 840 1 113883 5 1 3 1 0 0 1}
Figure 2.8
Static Profile Identifier Example
Note: The tree structure below is not a representation of the Figure 2.8 example.
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
Figure 2.9
Registration Tree for ADT, ORM, and ORU Messages
Note: This tree structure is provided to depict how the identifier changes based on the HL7 message that
is exchanged. This structure does not show all the administrative levels as defined in Figure 2.8.
3.2
Dynamic Profile Identifier
Definition
The dynamic profile identifier is a means to uniquely identify the dynamic aspects
of a message profile. The dynamic profile identifier is expressed as an ASN.1
Object Identifier (OID).
Figure 2.10
Dynamic Profile Identifier Example (next page)
Figure 2.11
Dynamic Profile Registration Tree Example (next page)
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
{ joint-iso-ccitt(2) country(16) US(840) organization(1) hl7(113883) v2-3(5) dynamicprofile(2) AccNE_AppNE(6) }
For efficient communication, the identifier may be specified using the integer form:
{2 16 840 1 113883 5 2 6}
Figure 2.10
Dynamic Profile Identifier Example
The identifier values for the possible combinations are given in the table below.
Acknowledge-ment Application
Accept Acknowledgement
AL
NE
SU
ER
AL
1
5
9
13
NE
2
6
10
14
SU
3
7
11
15
ER
4
8
12
16
Figure 2.11
Dynamic Profile Registration Tree Example
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page
Physician
is subject of
Patient
authorizes
triggers
Registrar
Message Profile Example
sends notification
ADT System
Patient
receives notification
Physician
Admit/Visit Notification
is subject of
sends notification
authorizes ADT Notification
triggers
Recipient
Registrar
receives notification
Admit/Visit Notification
Use Case Model
ADT System
ADT Notification
Recipient
: ADT System
USE CASE MODEL...................................................................................................
USE CASE: ADMIT/VISIT NOTIFICATION.........................................................
DYNAMIC INTERACTION MODEL.....................................................................
STATIC PROFILE: ADT/ACK (EVENT A01).........................................................
ADT^A01
3.1
3.2
ADT^A01............................................................................................................................
ACK^A01............................................................................................................................
ACK^A01
4.
DYNAMIC PROFILE: ADT/ACK (EVENT A01)....................................................
4.1
4.2
ADT^A01............................................................................................................................
ACK^A01............................................................................................................................
5.
SEGMENT PROFILES..............................................................................................
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
MSH – MESSAGE HEADER SEGMENT DEFINITION...........................................................
EVN - EVENT TYPE SEGMENT DEFINITION.......................................................................
PID (Y) - PATIENT DEMOGRAPHICS SEGMENT DEFINITION.............................................
PD1 – PATIENT ADDITIONAL DEMOGRAPHIC SEGMENT DEFINITION..............................
NK1 - NEXT OF KIN SEGMENT DEFINITION.......................................................................
PV1 (2) - ADMIT VISIT INFO SEGMENT DEFINITION.........................................................
AL1 - ALLERGY SEGMENT DEFINITION.............................................................................
MSA - MESSAGE ACKNOWLEDGMENT SEGMENT DEFINITION.........................................
ERR - ERROR SEGMENT DEFINITION.................................................................................
6.
TABLES.......................................................................................................................
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
6.12
6.13
6.14
6.15
6.16
TABLE 0001 – SEX..............................................................................................................
TABLE 0002 – MARITAL STATUS........................................................................................
TABLE 0003 – EVENT TYPE CODE....................................................................................
TABLE 0004 – PATIENT CLASS...........................................................................................
TABLE 0005 – RACE...........................................................................................................
TABLE 006 – RELIGION......................................................................................................
TABLE 0007 – ADMISSION TYPE........................................................................................
TABLE 0008 – ACKNOWLEDGEMENT CODE......................................................................
TABLE 0009 – AMBULATORY STATUS................................................................................
TABLE 0010 – ADMITTING/ATTENDING/REFERRING/CONSULTING DOCTOR..................
TABLE 0018 – PATIENT TYPE.............................................................................................
TABLE 0023 – ADMIT SOURCE..........................................................................................
TABLE 0062 – EVENT REASON CODE...............................................................................
TABLE 0063 – RELATIONSHIP............................................................................................
TABLE 0069 – HOSPITAL SERVICE.....................................................................................
TABLE 0087 – PREADMIT TEST INDICATOR......................................................................
6.17TABLE 0092 – READMISSION INDICATOR.........................................
Static Profile
Interaction Model
Dynamic Profile
Segment Profiles
Tables
03/09/2000
: ADT Notification
Recipient
1.
1.1
2.
3.
Copyright
2000, by Health Level Seven, Inc.
Page 19
4 OPEN Issues
Conformancebased Queries
Tool related
Information
Since the origin of this document, HL7 has published HL7 V2.4 Chapter 5 Conformance-based Queries. The Conformance Special Interest Group and the
Control/Query Technical Committee have assigned a work group to work on
aligning the two standards.
A proposal has been written and the groups will review at the January 2001 HL7
Working Group Meeting.
We are currently working on a tool to facilitate the creation and browsing of a
profile tool. As the tool becomes available, this documentation will be updated to
reflect its usage.
HL7 Profile
Registration
The Conformance SIG is currently working with HL7 Headquarters to provide the
profile registration utility on the HL7 Web Site. As this utility becomes a reality,
this document will be updated.
Registration
Authority
The registration authority represents the branch from ISO to HL7 and is
specified as joint-iso-ccitt(2) country(16) US(840) organization(1) hl7(113883).
***has this registration been done by HL7? if so, who does it... if not is it the
intent of this sig to do it? where are the registration OID numbers kept (?HL7
website?), etc. etc. same question for dynamic profile identifier....
03/09/2000
Copyright
2000, by Health Level Seven, Inc.
Page 20
