Health Level Seven

Version 2.x

Message Profiling Specification

Version 2.2

November 30, 2000

08/14/97

Table of Contents

1Introduction......

2HL7 V2.x Message Profiling......

2.1Overview......

2.2What is an HL7 V2.x Message Profile?......

2.3HL7 V2.x Message Profile Components......

2.3.1Use Case Model......

2.3.2Static Definition of an HL7 V2.x Message Profile......

2.3.2.1Message Level Profile......

2.3.2.2Segment Level Profile......

2.3.2.3Field Level Profile......

2.3.3Dynamic Definition of an HL7 V2.x Message Profile......

2.3.3.1Interaction Model......

2.3.3.2Dynamic Profiles......

3Identification of HL7 Message Profiles Using ASN.1......

3.1Static Profile Identifier......

3.2Dynamic Profile Identifier......

Figure 2.11......

4OPEN Issues......

08/14/97

1Introduction

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).
Acknowledge-ments / 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 The work of the Conformance Special Interest Group is located under Committees.

2HL7 V2.x Message Profiling

2.1Overview

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:
  • What data will be passed
  • The format in which the data will be passed
  • The acknowledgement responsibilities of the sender and receiver.

NOTE / Illustrations in this document are included only as examples and are not intended to indicate all possible aspects of an HL7 Message Profile specification.

2.2What 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.
Examples / 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.
In the Dynamic Definition, for example, the Message Profile may define whether the message requires an accept acknowledgment or an application acknowledgment.
NOTE / 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).

2.3HL7 V2.x Message Profile Components

2.3.1Use 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:
  • 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.

Tool / 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.
Reference / Refer to the HL7 V3.0 Message Development Framework (MDF) for further information on use case models and their uses within HL7.
Figure 2.1 / Use Case Model Example (next page)


Admit/Visit Notification

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

2.3.2Static Definition of an HL7 V2.x Message Profile

Definition / 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.
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.

Figure 2.2 / Static Message Profile Example– ADT^A01

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 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.1Message 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)

ADTADT MessageChapter

MSH[1,1]Message Header2

EVN[1,1]Event Type3

PID [1,1]Patient Identification3

[ { NK1 } ][0,3]Next of Kin3

PV1[0,1]Visit Info3

PV2 [0,1]Visit - additional info3

[ { OBX } ][0,0]Observation/Result7

[ { AL1 } ][0,*]Allergy Information3

[ { DG1 } ][0,0]Diagnosis Information6

[ { PR1 } ].[0,0]Procedures6

[ { GT1 } ][0,0]Guarantor Information6

[ [0,0]

{ IN1[0,0]Insurance Information6

[ IN2 ][0,0]Insurance Information - Addit. Info.6

[ IN3 ] [0,0]Insurance Information - Cert.6

} ------

]

[ ACC ][0,0]Accident Information 6

[ UB1 ][0,0]Universal Bill Information6

[ UB2 ][0,0]Universal Bill 92 Information6

Figure 2.3

Message Level Profile Example –
Standard ADT^A01 Message Definition

2.3.2.2Segment 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.
  • Thelength 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.

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 / 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 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.
Figure 2.4 / Segment Level Profile Example– PID (Patient Identification) Segment
SEQ / LEN / DT / OPT / RP/# / TBL# / ITEM# / ELEMENT NAME
1 / 4 / SI / X / 00104 / Set ID - PID
2 / 20 / CX / RE / 00105 / Patient ID
3 / 20 / CX / R / Y / 00106 / Patient Identifier List
4 / 20 / CX / X / Y / 00107 / Alternate Patient ID - PID
5 / 48 / XPN / R / Y / 00108 / Patient Name
6 / 48 / XPN / RE / Y / 00109 / Mother’s Maiden Name
7 / 26 / TS / RE / 00110 / Date/Time of Birth
8 / 1 / IS / RE / 0001 / 00111 / Sex
9 / 48 / XPN / X / Y / 00112 / Patient Alias
10 / 80 / CE / X / Y / 0005 / 00113 / Race
11 / 106 / XAD / RE / Y/3 / 00114 / Patient Address
12 / 4 / IS / X / 0289 / 00115 / County Code
13 / 40 / XTN / X / Y/3 / 00116 / Phone Number - Home
14 / 40 / XTN / X / Y/3 / 00117 / Phone Number - Business
15 / 60 / CE / X / 0296 / 00118 / Primary Language
16 / 80 / CE / X / 0002 / 00119 / Marital Status
17 / 80 / CE / X / 0006 / 00120 / Religion
18 / 20 / CX / X / 00121 / Patient Account Number
19 / 16 / ST / RE / 00122 / SSN Number - Patient
20 / 25 / DLN / X / 00123 / Driver's License Number - Patient
21 / 20 / CX / X / Y / 00124 / Mother's Identifier
22 / 80 / CE / X / Y / 0189 / 00125 / Ethnic Group
23 / 60 / ST / RE / 00126 / Birth Place
24 / 1 / ID / X / 0136 / 00127 / Multiple Birth Indicator
25 / 2 / NM / X / 00128 / Birth Order
26 / 80 / CE / X / Y / 0171 / 00129 / Citizenship
27 / 60 / CE / X / 0172 / 00130 / Veterans Military Status
28 / 80 / CE / X / 0212 / 00739 / Nationality
29 / 26 / TS / X / 00740 / Patient Death Date and Time
30 / 1 / ID / X / 0136 / 00741 / Patient Death Indicator

Figure 2.4

Segment Level Profile Example (PID Segment)

2.3.2.3Field 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.
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)


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 / DT / R/O / RP/# / TBL# / Item # / Component Name
1 / 12 / ID / RE / identifier
2 / 80 / TX / R / text
3 / 25 / ST / C / name of coding system
4 / 12 / ID / RE / alternate identifier
5 / 80 / TX / RE / alternate text
6 / 25 / ST / RE / name of alternate coding system

Figure 2.6

CE Data Type Example – OBX-5 Field

2.3.3Dynamic 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.1Interaction 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