Professional Documents
Culture Documents
HL7 Profile V2r2 Final
HL7 Profile V2r2 Final
HL7 Profile V2r2 Final
Version 2.x
1 INTRODUCTION..................................................................................................................................2
Document This document is the result of a project begun in 1997 by the Health Level Seven
History (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.
Reader The reader should be familiar with the HL7 V2.x Standard and the HL7 V3.0
Prerequisites Message Development Framework (MDF).
Acknowledge- The HL7 Conformance SIG would like to thank those involved in the creation of
ments 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.
2.1 Overview
HL7 HL7 V2.x is the most widely implemented health-related standard, domestically
Compliance and internationally.
Message HL7 V2.x Message Profiling provides a guideline for documenting particular uses
Profiling 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 Illustrations in this document are included only as examples and are not intended
to indicate all possible aspects of an HL7 Message Profile specification.
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 An HL7 V2.x Message Profile is compliant, in all aspects, with the HL7 defined
Compliance message it profiles, although it may specify constraints on the standard HL7
message definition.
Message Profile An HL7 V2.x Message Profile should be expressed in tabular format. If XML is
Representation 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).
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.
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.
authorizes Registrar
Patient is subject of triggers
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
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 A static profile identifies only those specific elements of a standard HL7 message
HL7 Messages that are used in the exchange.
ADT^A01
MSH MSH
EVN EVN Segments/Segment Groups:
PID PID - Cardinality (min, max)
NK1 NK1 NK1 NK1 NK1 ... NK1 NK1 NK1 NK1 NK1 ...
PV1 PV1
... ...
Fields/Components:
- Field Usage (Optionality)
PV2 PV2 (R, RE, C, CE, X)
- Cardinality (max repeats)
OBX OBX - Value Sets/Coding system
AL1 AL1 - 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
Segment The set of segments included within the message of an HL7 V2.x Message Profile
Definitions shall be defined.
Segment Some segments within HL7 Standard Messages are allowed to repeat. The
Cardinality cardinality of all the segments within the message shall be defined.
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)
Figure 2.3
Message Level Profile Example
Standard ADT^A01 Message Definition
Segment The set of fields of each instance of an HL7-defined segment within the HL7 V2.x
Profiles 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 The segment level profile shall be documented using the tabular format employed
Format for the HL7 segment definitions.
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.
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.
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
Figure 2.4 Segment Level Profile Example PID (Patient Identification) Segment
Figure 2.4
Segment Level Profile Example (PID Segment)
Field Each individual field within a segment shall be completely defined to eliminate any
Definitions possible ambiguity.
In cases where HL7 2.x field descriptions are unclear or ambiguous, a more
precise semantic definition shall be specified.
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.
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.
Figure 2.6
CE Data Type Example OBX-5 Field
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).
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.
ADT^A01( )
ACK^A01
Figure 2.7
Interaction Model Example ADT^A01
Acknowledge- The specific HL7 acknowledgments required and/or allowed for use with the
ments 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.
Always
Never
Only on success
Only on error.
Profile HL7 Message Profiles shall be uniquely identified with static and dynamic profile
Identifiers identifiers.
The sending application uses the profile identifiers to determine the specific HL7
Message Profile to send.
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.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).
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.
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).
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.
Accept Acknowledgement
AL NE SU ER
Acknowledge-ment Application
AL 1 2 3 4
NE 5 6 7 8
SU 9 10 11 12
ER 13 14 15 16
Figure 2.11
Dynamic Profile Registration Tree Example
authorizes Registrar
Patient is subject of triggers
Tables
Conformance- Since the origin of this document, HL7 has published HL7 V2.4 Chapter 5 -
based Queries 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.
Tool related We are currently working on a tool to facilitate the creation and browsing of a
Information profile tool. As the tool becomes available, this documentation will be updated to
reflect its usage.
HL7 Profile The Conformance SIG is currently working with HL7 Headquarters to provide the
Registration profile registration utility on the HL7 Web Site. As this utility becomes a reality,
this document will be updated.
Registration The registration authority represents the branch from ISO to HL7 and is
Authority 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....