HL7 V3 Guide
Committee Ballot # 2
HL7 Version 3 Standard, Copyright © 2002. All Rights Reserved.
Table of contents
1 HL7 FOUNDATION COMPONENTS
1.1 INFORMATION MODEL
1.1.1 Information Model Components
1.1.2 Types of Information Models
1.1.3 Static Structure: Classes and Relationships
1.1.4 Information Content: Attributes, Values, and Constraints
1.1.5 Dynamic Behavior: States and Transitions
1.2 VOCABULARY
1.2.1 HL7 Vocabulary Domains
1.2.2 Use of Vocabulary Domains to Build V3 Messages
1.2.3 Use of External Terminologies
1.2.4 Use of Local Vocabularies
1.2.5 HL7 Vocabulary and the UMLS Metathesaurus
1.2.6 Good Vocabulary Practices
2 HL7 MESSAGING COMPONENTS
2.1 INTRODUCTION
2.1.1 Document Scope
2.1.2 Overview of the V3 Publication
2.1.3 Methodology Preview
2.2 STORYBOARD AND STORYBOARD NARRATIVE
2.2.1 Overview
2.2.2 Storyboard Format
2.3 Application Roles
2.4 CONFORMANCE CLAIMS AND ORGANIZATIONAL
PRACTICES
2.4.1 Introduction
2.4.2 Conformance Claim Work Products
2.5 Trigger Events
2.6 REFINED MESSAGE INFORMATION MODELS
2.7 UNDERSTANDING HIERARCHICAL MESSAGE
DEFINITIONS
2.7.1 Overview
2.7.2 Hierarchial Message Descriptor (HMD) Column
Descriptions
2.8 Message Types
2.9 INTERACTIONS
2.9.1 Overview
2.9.2 Message Types
2.9.3 Receiver Responsibilities
2.9.4 Interaction Models
Appendices
A References
B Appendix A: Act Properties and Moods
1
HL7 FOUNDATION COMPONENTS
1.1
INFORMATION MODEL
The information model defines all the information from which the
data content of HL7 messages are drawn. It follows object-oriented
modeling techniques, where the information is organized into classes
that have attributes and that maintain associations with other
classes. The information model forms a shared view of the
information domain used across all HL7 messages independent of
message structure. Thus, the information model provides a means
for discovering and reconciling differences in data definition.
1.1.1
Information Model Components
The information model consists of the following components:



classes, their attributes, and relationships between the
classes;
state transition models for some classes;
data types and constraints.
Large portions of the information model have graphical
representations in the Unified Modeling Language (UML). This
includes the class diagram, the state transition diagram, and the data
type diagram. Those graphical representations are views into the
respective information model component. Some of the information
model is specified informally in descriptive text and accompanying
documents.
The information model notation is based largely on the Unified
Modeling Language (UML), a modeling language that unifies the
object-oriented modeling methods of Grady Booch, Jim Rumbaugh,
Ivar Jacobson, and others. The UML is a rich, mainly graphical,
means of expressing object-oriented concepts. To obtain more
information about UML see http://www.rational.com/uml/ or the book
UML Distilled by Martin Fowler (ISBN 0-201-32563-2).
1.1.2
Types of Information Models
The HL7 information modeling process recognizes three different
types of information models. Each of the model types uses the same
notation and has the same underlying meta-model. The models differ
from each other based on their information content, scope, and
intended use. The three types of information models are:



Reference Information Model (RIM): The RIM is used to
express the information content for the collective work of the
HL7 Working Group. The RIM is a coherent, shared
information model that is the source for the data content of all
HL7 messages. The RIM is maintained by a collaborative,
consensus building process involving all Technical
Committees and Special Interest Groups. Through a process
known as model harmonization, information content submitted
as RIM change proposals is debated, enhanced, and
reconciled by Technical Committee representatives and
applied to the RIM.
Domain Message Information Model (D-MIM): The D-MIM is a
derivative of the RIM that includes a fully expanded set of
class clones, attributes and relationships that are used to
create messages for any particular domain. Generalization
hierarchies in the RIM may be collapsed in the R-MIM. The DMIM is used as a common base upon which all R-MIMs within
a domain are built.
Refined Message Information Model (R-MIM): The R-MIM is
used to express the information content for a message or set
of messages with annotations and refinements that are
message specific. The content of the R-MIM is drawn from the
D-MIM for the specific subject domain. The R-MIM may
include clones of selected classes with alias names specific to
the perspective of the message(s) to be derived. The R-MIM
is used to create a certain message-specific projection of the
D-MIM for the purpose of being context specific while
maintaining the semantic link to the more generic RIM.
1.1.3
1.1.3.1
Static Structure: Classes and Relationships
Classes
A class is an abstraction of things or concepts that are subjects of
interest in a given application domain. All things or concepts
subsumed under a class have the same properties and are subject
to and conform to the same rules. Classes are the people, places,
roles, things, and events about which information is kept. Classes
have a name, description, and sets of attributes, relationships, and
states.
The instances of classes are called objects. Where classes
represent categories of concepts, people and things, objects
represent the individual things themselves. There is still a difference
between objects and the things they represent. Objects capture all
relevant data about things, which are known to the information
system, but are not the things themselves. For instance, a particular
human being, named John Doe, may be represented through an
object in an information system. That object contains John Doe's
demographic or medical data, but the object is still different from
John Doe himself.
1.1.3.2
Relationships
Classes relate with classes in various ways. Such relationships can
be of three types:



Generalization
Association
Composite Aggregation
1.1.3.2.1
Generalizations
A generalization relationship is a connection between classes (as
opposed to instances). The generalization relationship expresses
that one class (called the superclass) is a generalization of another
class (called the subclass). Conversely, the subclass is a
specialization of the superclass. Instances of a subclass are also
instances of the superclass. Conceptually, the superclass does not
have a separate related instance to the instance of the subclass,
although implementation-wise this may be different. Conceptually,
generalization relationships are associations between classes, not
between instances.
In a generalization relationship the subclass inherits all properties
from the superclass, including attributes, relationships, and states. In
addition, the subclass has other properties that are special for the
subclass.
Each subclass may in turn have subclasses of its own. Thus,
superclass/subclass and generalization/specialization are relative
concepts. A class can be both a subclass of its superclass and a
superclass of its subclasses. The entirety of superclasses and
subclasses with a common root superclass is called a generalization
hierarchy.
A generalization usually has multiple specializations. However, not
all of the conceptual specializations need to be represented in the
model. Only those concepts that warrant special properties (e.g.,
attributes, relationships, states) are modeled as distinguished
classes. If all specializations of a class are fully enumerated as
subclasses in the model, the superclass could be "abstract." An
abstract class is never instantiated directly, but only through one of
its specializations.
1.1.3.2.2
Associations
An association defines a connection between objects. The objects
may be instances of two different classes or of the same class
(reflexive association). Just as classes have instances, associations
have instances too. An association instance is a connection between
objects and is defined by an association that connects classes.
Figure 1: One association defined in the information model can have
multiple instances. Each instance of an association connects two
objects. The number of instances of an association connecting to
one object is regulated by the multiplicities.
Associations in the HL7 Methodology have at least two ends. Each
end of the association instance connects with one and only one
object. However, one object may be associated with more than one
object of the same class by the same association. In this case,
multiple association instances exist, each connecting exactly two
objects. The number of instances of an association that can connect
to one object is regulated by the multiplicities of the association.
An association multiplicity specifies the minimum and maximum
number of objects of each class participating in the association. The
multiplicity is documented as a pair of cardinal numbers (i.e., nonnegative integers) min..max. The lower bound min is a non-negative
integer, usually zero or one. The upper bound max is an integer
greater or equal to min, usually one, or unlimited, indicated by an
asterisk ("*").1 Valid multiplicities are listed in the following table:
Multiplicity
Meaning
0..1
minimum zero, maximum one
0..n
minimum zero, maximum the integer n, where n > 1
0..*
minimum zero, maximum unlimited
1
short for "1..1" minimum one, maximum one
1..n
minimum one, maximum the integer n, where n > 1
1..*
minimum one, maximum unlimited
n1..n2
minimum the integer n1, maximum the integer n2, where
n1 > 1 and n2 >n1
n..*
minimum the integer n, maximum unlimited, where n > 1
1.1.3.2.3
Composite Aggregations
A composite aggregation is a special flavor of an association
between objects. Composite aggregations indicate that objects relate
to each other as part and whole. Unlike common associations, a
composite aggregation relationship is directed, one end being the
whole and the other end being the part. The part is conceptually
strongly dependent on the whole class, so that the part cannot exist
without the whole.
1.1.3.2.4
Classes Expressing Complex or Dynamic Associations
Many associations between business objects are of a more complex
nature than could be expressed by a common association. For
example, an association between two objects might only be valid in a
certain time interval. Other associations need to be qualified or
classified. This can be expressed with modeling patterns (design
patterns). Modeling patterns are building blocks that can be reused
in many circumstances. Four of those patterns are defined in the
following sub-sections.
When a model contains associations with multiplicities "0..*" on both
ends, this is an indication for a complex relationship that is likely to
require more information. For example, the relationship between
Patient and Physician would be a many-to-many association. In
database design, many-to-many relationships were commonly
resolved because there was no other way to technically implement
them. In conceptual information modeling, resolving of such
relationships is common because it is unlikely that many-to-many
associations exist without further qualifications.
Note that the UML concept of an "association class" differs from the
"associative class." An association class does not generally allow
resolution of many-to-many classes, because multiple associations
between the same pair of objects are not distinguished as individual
associations with an association class. Associative classes are more
powerful than association classes. The disadvantage of associative
classes is that simple association names are turned into abstract and
awkward association names. For instance, where a Physician sees a
Patient with a many-to-many association, a physician is_involved_in
many Patient-Physician-Associations, that in turn has_as_patient a
Patient.
Figure 2: Resolving a many-to-many association (a) through an
associative intermediary class (b).
1.1.4
1.1.4.1
Information Content: Attributes, Values, and Constraints
Attributes
Class attributes are the core components of the information model.
The attributes are the source for all the information content of HL7.
The majority of attributes are descriptive attributes that depict
aspects of classes that are important for communication between
healthcare systems. Besides the descriptive attributes there are
three special kinds of attributes in the information model:



identifier attributes
classifier attributes
state attributes
1.1.4.1.1
Identifier Attributes
Identifier attributes can be used to identify an instance of a class.
Sometimes more than one attribute may be needed to identify an
instance of a class. The identifier attributes always have a value. The
values of identifier attributes are unique among all instances of the
class. Since identity is static, values of identifier attributes never
change. Identifier attributes are assigned the Instance Identifier (II)
data type and are generally have a name ending in "-ID".
Examples of Identifier Attributes from the RIM include Entity.ID and
Act.ID. These identifier attributes have an II datatype and uniquely
identify a particular Entity or Act respectively. In each case the
identifier attributes are a set of instance identifiers. This indicated
that there may be multiple unique identifiers for an Entity or Act.
Entity identifiers might include medical record numbers, social
security numbers, driver license number, and others. Act identifiers
might include placer accession numbers, filler accession numbers,
and others.
1.1.4.1.2
Classifier Attributes
Classifier attributes are used in generalization hierarchies to indicate
which of the specializations is the focus of the class. The classifier
attribute is placed in the superclass and contains a code value
declaring the subclass type. There may be multiple classifier
attributes in a superclass, indicating multiple independent
generalization hierarchies. In a fully enumerated specialization
hierarchy, classifier attributes are needed in order to specify the
specialization class in a message.
The classifier attributes are a critical aspect of the classes forming
the backbone of the RIM (Entity, Role, and Act). The classifier
attributes are named "Class-CD". The classifier attributes provides a
great amount of flexibility and extensibility in the information model.
The vocabulary domains for classifier attributes include an entry for
each specialization of the backbone class. For example the
vocabulary domain specified for Entity.Class_CD includes Living
subject, Organization, Place and Material. The vocabulary domain
may also include entries that are not explicitly expressed as classes
in the model. For example, Group is a valid Entity class code (or
specialization of entity) but does not appear in the model as a class.
This provides the flexibility and extensibility capability.
1.1.4.1.3
State Attributes
A state attribute is used in subject classes. It contains a value that
concisely indicates the current state of the class. A subject class
must have only one state attribute. The state attribute must be
assigned the data type "set of code value" that allows multiple state
flags to be specified. State attributes as named Status-CD and are
associated with vocabulary domains defined by HL7 that correspond
to the state machine defined for the subject class. For example the
Act.Status_CD has the domain values of active, suspended,
cancelled, completed, and aborted.
1.1.4.2
Data Types
Data types are the basic building blocks of attributes. They define the
structural format of the data carried in the attribute and influence the
set of allowable values an attribute may assume. Data types have
very little intrinsic semantic content. The semantic context for a data
type is carried by its corresponding attribute. Every attribute in the
RIM is associated with one and only one data type, and each data
type is associated with zero or many attributes.
1.1.4.3
Constraints
Constraints narrow down the set of possible values that an attribute
can take on. Constraints include vocabulary domain constraints (e.g.,
this attribute must be a LOINC code), range constraints (e.g., this
attribute must be a floating point number between 0 and 1) and
more. While the term "constraint" has the connotation of restricting
and limiting, the objective in defining constraints is more to provide
guidance in the proper use of a class or attribute. The important point
about constraints is to suggest legal values rather than to penalize
illegal values.
A vocabulary domain is a constraint applicable to code values.
Vocabulary domains define the set of possible values for a code
value. Hence, vocabulary domain constraints are largely defined in
terms of sets and subsets rather than using predicates. The data
types code value and concept descriptor, without a domain
specification, have an infinite domain that includes all concepts that
man can ever conceive of. In other words, code values are useless
without some guidance provided by constraints to their value set.
Constraints may be specified in the RIM, MIM, R-MIM or HMD. If
specified in the RIM, the constraint is relevant for an attribute in all
messages containing the attribute. If specified in the MIM or R-MIM,
the constraint is specific to all of the messages derived from that MIM
or R-MIM. Constraints may also be specified within the HMD where
they can be made specific to a particular set of message structures.
Constraints specified in a higher level (e.g., the RIM) may be further
constrained in a lower level (e.g., MIM or HMD). However, the
subordinate constraint must conform to the constraint on the higher
level. Higher level constraints cannot be undone on a lower level.
Figure 3: A simple state transition model representing the life cycle of
an activity.
1.1.5
Dynamic Behavior: States and Transitions
An aspect of the behavioral aspect of a class is defined in a state
diagram associated with a class in an information model. State
diagrams are developed for classes that are the central subject of an
interaction. These classes are called subject classes. Interactions
are sometimes motivated by changes in the status of a subject class.
For example Act may be identified as a subject class. The
vocabulary domain for the Act.Status_CD declares the defined states
for the Act. Those states include Active, Suspended, Cancelled,
Complete, and Aborted. A state diagram depicts the allowable class
states with a box labeled with the name of the state. Changes in
state are called state transitions and are depicted in the diagram by a
line with a arrowhead showing the direction of the transition. An
example of a state transition might be the change in the state of an
Act from Active to Complete. The change in state (state transition) is
associated with a trigger event that causes the transition. The trigger
event in this example might be the fulfillment of an order. An order is
a special type of Act. The transition from an Active order to a
Completed order is triggered by the fulfillment of the Order. The state
diagram depicts the states, trigger event, and state transitions of
interest.
Analysis of the state diagram can be useful for discovering trigger
events that might lead to the need for interactions.
1.2
VOCABULARY
1.2.1
HL7 Vocabulary Domains
Within the HL7, a vocabulary domain is the set of all concepts that
can be taken as valid values in an instance of a coded field or
attribute. For example, in the RIM, the Living_subject class has a
coded attribute administrative_gender_cd. If the
administrative_gender_cd attribute becomes part of a hierarchical
message definition (HMD), and a message instance is subsequently
created as part of an implemented interface, the
administrative_gender_cd field contains the concepts male and
female.
It is important to note that a value domain consists of a set of
concepts, not a set of words or codes. In different implementations of
an interface, the same concept could be represented using different
coding systems. Thus, each concept in a vocabulary domain has a
one-to-many relationship to codes that might be used as
representations for the concept in a message instance.
The general meaning of code system is a scheme for representing
concepts using (usually) short concept identifiers to denote the
concepts that are members of the system. A coding scheme defines
a set of unique concept codes.
1.2.1.1
Vocabulary Domains and RIM Attributes
Each coded attribute in the RIM (i.e., with a data type of CC, CD, CE,
CS, CV, SET_CD, SET_CE, SET_CS, or SET_CV) will be
associated with one and only one vocabulary domain. For example
the vocabulary domain for Administrative_gender_cd is
AdmistrativeGender. Some vocabulary domains are associated with
more that one RIM attribute. For example the Vocabulary domain
PhysicalQuantity is associated with both diet_carbohydrate_qty and
Diet_energy_qty. The vocabulary domain table may be an HL7defined table, an HL7-recognized external coding scheme (e.g.,
LOINC, SNOMED, HIPAA) or some combination of those, or may
contain locally defined codes.
The HL7-defined vocabulary domain tables that have been
developed for coded class attributes are stored in the HL7 repository.
A number of printable views have been extracted to produce the HL7
Vocabulary Domain Listings for the RIM The views are presented in
table format and include the HL7 Vocabulary Domain Values list and
the HL7 Domain Tables and Coded Attributes list. HL7-recognized
external vocabulary domains are described in the External Domains
list. Links are provided between these tables and attributes in the
RIM.



The HL7 Vocabulary Domain Values table includes a
mnemonic code, concept identifier, print name, and
definition/description for each value. This table also shows
any hierarchical relationship that exists between values in
each domain table.
The HL7 Domain Tables and the Coded Attributes table name
the coded attribute(s) in the RIM that are supported by that
vocabulary domain.
The External Domains table includes concept identifier,
defining Express, code system abbreviation, description, and
a link to the source for each table.
1.2.1.2
Vocabulary Domain Qualifiers
Coded fields contain two pieces of information relative to Vocabulary:
The vocabulary domain and the extensibility qualifier. The
Extensibility qualifier has two possible values: CNE (coded no
exceptions), and CWE (coded with exceptions). There are presently
only two vocabulary domain qualifiers: Extensibility and Realm.
Currently, the Extensibility qualifier is the only qualifier that can be
used in domain specifications. Both the Realm and Extensibility
qualifiers can be used in domain constraints.
The vocabulary domain name and the associated Extensibility
qualifier for each coded attribute in the RIM are specified in the RIM
narrative. This specification occurs as the first line of the description
for a coded RIM class attribute. The information is formatted as
shown in the example below from Entity_class_cd:
Domain: "EntityClass" (CNE)
There is a hyperlink between the vocabulary domain name
(EntityClass) and its entry in the HL7 Vocabulary Domain Values
table. For those domains that are not yet developed, a domain name
has been assigned but the table contains no values.
The CWE value for the Extensibility qualifier means that the code set
can be expanded to meet local implementation needs. When a
coded attribute is sent in a message, local concepts or free text may
be sent in place of a standard code if the desired concept is not
represented in the standard vocabulary domain.
The CNE value for the Extensibility qualifier means that the code set
is fixed and cannot be extended. A concept from the specified
domain must be sent as the value of the coded field in a message. If
the field cannot be valued from the concepts that exist in the
specified domain, the field cannot be placed in the message. If a
CNE field is required in a message, but the field cannot be valued
from the concepts that exist in the specified domain, then no valid
message can be created.
The Realm qualifier allows the domain of a coded attribute to be
specialized according to the geographical, organizational, or political
environment where the HL7 standard is being used. For example,
the Realm qualifier would allow the Gender domain to hold a
somewhat different value set for HL7 messages when used in Japan
versus when the Gender domain is used in HL7 messages in the
United States.
All domain qualifiers are values in the VocabularyDomainQualifier
domain.
1.2.2
Use of Vocabulary Domains to Build V3 Messages
Constraints are applied to RIM classes and their coded RIM
attributes by selecting appropriate values from the vocabulary
domains for those attributes.
1.2.2.1
Vocabulary Domain Constraints
The vocabulary domain specifications stated in the RIM always refer
to a complete vocabulary domain. That is, at the RIM level there is
no specialization based on realm of use or on the context and needs
of a specific message. As RIM attributes are specialized to suit a
specific message context, the domain of the attribute can be reduced
(constrained) to reflect the specialization.
A domain that has been constrained to a particular realm and coding
system is called a value set. A vocabulary domain constraint can be
applied to any level below the RIM, and is an expression that states
how the sub-domain (value set) was derived from the domain
specified in the RIM. A vocabulary domain constraint in R-MIM, DMIM, etc contain the name of the value set and its list of domain
qualifiers. Domain constraint expressions are only contained in the
Value Set Definition Table.
The general rule for creating vocabulary domain constraints is that a
domain can be reduced in scope as it is specialized for a particular
use, but its semantic scope can never be expanded. The application
of the general rule results in the following specific rules.


1.2.3
The vocabulary domain of a coded element or attribute used
at any level of specialization below the RIM must be a subset
of the vocabulary domain specified for the attribute in the RIM.
Note that for attributes that are qualified with an extensibility of
CWE, local codes are an allowed extension to the domain, but
this is not intended as an increase in the semantic scope of
the attribute.
Once the Extensibility qualifier value CNE has been invoked
at any level of attribute domain specification (RIM, R-MIM,
CMET, HMD, etc), the CNE qualifier must be retained in any
subsequent domain constraints. For example, if a coded
attribute has a CNE qualifier in the RIM, any R-MIM, CMET,
HMD, etc must also have a CNE qualifier associated with the
domain of that attribute. If a vocabulary domain in the RIM has
the Extensibility qualifier value of CWE (coded with
exceptions), a subsequent constraint of that attribute's domain
can have either the CNE or CWE qualifier.
Use of External Terminologies
HL7-recognized external terminologies are listed in the External
Domains table.
The Vocabulary Technical Committee is working on strategies for
use of external vocabularies in HL7 domain specifications and
messages. The following principles summarize HL7's general
approach:


HL7 is committed to using existing terminologies as values for
coded fields in HL7 messages, where possible, rather than
creating a new terminology.
HL7 is seeking a solution that allows the use of proprietary
vocabularies (SNOMED, Read, MEDCIN, etc.) in a manner
that is equitable to all vocabulary creation/maintenance
organizations.
Given these goals, the HL7 Vocabulary Technical Committee has
concluded that:







1.2.4
HL7 should not choose a single proprietary coding scheme.
The presumption is that a "market model" will assure
responsive maintenance of proprietary terminologies.
HL7 will properly license any terminologies it uses.
The primary code in coded fields can be a UMLS CUI (Unified
Medical Language System, Concept Unique Identifier) or a
proprietary code when properly licensed.
Coding schemes used by HL7 must be registered with HL7.
See more details below. HL7-registered vocabularies are
listed in the External Domains table.
To be used for a given domain, a terminology must cover all of
the concepts defined in the domain specification for that
domain.
To enable interoperability, proprietary codes used in
messages must be mapped to a publicly available reference
model that supports the desired degree of interoperability.
Use of Local Vocabularies
It is legal to use locally defined concepts and codes in HL7
messages when the standard value set does not contain the needed
concept, and when the vocabulary domain has an Extensibility
qualifier of CWE (coded with exceptions).
There are a few rules that govern the use of local codes:



1.2.5
A local code cannot be sent for a concept that is already
represented in the standard domain.
Locally defined code systems will be assigned OIDs (object
identifiers) so that they can be distinguished from any other
HL7-registered proprietary or external terminology.
Users are encouraged to submit local codes to the HL7
Vocabulary Technical Committee so that they can be
incorporated into the HL7 vocabulary domain, thereby
increasing the interoperability of the communicating systems.
HL7 Vocabulary and the UMLS Metathesaurus
HL7 has an informal agreement with the United States National
Library of Medicine (NLM) that HL7-maintained vocabulary tables will
be incorporated into the UMLS Metathesaurus. In fact, many of the
characteristics of the HL7 domain specification database are based
on the design principles of the Metathesaurus tables.
The main reasons for wanting the HL7 tables in the Metathesaurus
are:



It is a neutral environment where cross mapping of various
terminologies can occur.
The Metathesaurus has proved to be a stable and readily
accessible archive of concepts and their representations.
Linking HL7 content to the Metathesaurus content allows HL7
users to take advantage of the richness of the UMLS
Knowledge Sources, including links to bibliographic
references and the semantic network.
Placing HL7 terms and codes in the Metathesaurus will allow easy
cross-referencing between HL7 terms and existing vocabularies, like
SNOMED International and LOINC. It also creates linkages to other
aspects of the UMLS Knowledge Sources such as bibliographic
references, the Semantic Network, the Specialist Lexicon,
definitions, and co-occurrence data. These linkages have the
potential to make data in HL7 messages much more useful to the
parties that send and receive clinical messages. Having all of the
codes in a common database will allow comparisons that can lead to
greater consistency and interoperability among the various message
developers.
1.2.6
Good Vocabulary Practices
The Vocabulary Technical Committee develops and maintains the
document containing good vocabulary practices guidelines to be
followed in definition and maintenance of vocabulary domains.
Contact the Vocabulary Technical co-chairs to abtain a copy of the
Good Vocabulary Practices Guidelines document.
2
HL7 MESSAGING COMPONENTS
2.1
INTRODUCTION
This HL7 V3 Guide was created for use by members of the Health
Level Seven (HL7) Working Group as a companion to the V3
Standard. The information contained in this document is based on
and was drawn from the Message Development Framework (MDF).
In fact, the V3 Guide can be considered a "condensed" version of the
MDF in that it contains only the methodological information an HL7
member needs to understand the V3 publication. Most of the
theoretical and technical discussions provided in the MDF are not
included in the V3 Guide.
2.1.1
Document Scope
This document defines and describes the elements such as
Storyboards, the Information Model, and vocabulary that comprise
the piece of the V3 publication. HL7 members should use this
document as a tool for gaining general understanding of the V3
publication.
2.1.2
Overview of the V3 Publication
As indicated in the Backbone document, there are several
documents within the V3 publication. However, the V3 Guide is
primarily concerned with the following four documents:




HL7 Version 3 Standard: Administrative Management
HL7 Version 3 Standard: Infrastructure Management
HL7 Version 3 Standard: Health and Clinical Management
HL7 Version 3 Standard: Vocabulary
The first three documents noted above are divided into Sub-sections
and domains as outlined below.
HM Section: Health and Clinical Management
PO Sub-Section: Practice and Operations
LB
Domain: Laboratory
RX Domain: Pharmacy
RC Sub-Section: Records
PC Domain: Medical Records
AM Section: Administrative Management
PR Sub-Section: Practice
PA
Domain: Patient Administration
SC Domain: Scheduling
FI Sub-Section: Financial
FM Domain: Financial Management
CR Domain: Claims & Reimbursements
AB
IM
Domain: Accounting & Billing
Section: Infrastructure Management
CO Sub-Section: Control
MC Domain: Message Control
MF Domain: Master Files
QU Sub-Section: Query
QD Domain: Query
Additional Sections and Sub-sections exist in HL7; however, they
have not yet included submissions for the V3 Release.
Each of the domains documents contain the following:










Storyboard (ST)
Storyboard Narrative (SN)
Application Roles (AR)
Trigger Event (TE)
Domain Message Information Model (DM)
Refined Message Information Model (RM)
Hierarchical Message Definition (HD)
Message Type (MT)
Example (EX)
Interactions (IN)
Each of the bullets above represents an artifact. Each artifact is
submitted by a Technical Committee and given a unique identifier
that is assigned by concatenating the Sub-Section, Domain and
Artifact code (the artifact codes are in parentheses in the bulleted list
above), a 5-digit, non-meaningful number, two digit realm and 2 digit
version. For example, an application role submitted by the Patient
Administration domain may have the following unique artifact
identifier:
PRPA_AR00001UV00
Where:
PR = Subsection: Practice
PA = Domain: Patient Administration
AR = Artifact: Application Role
00001 = 5 digit non-meaningful number
UV = realm (the only current value is UV for universal)
00 = Current version number
As you browse through the ballot documents, you will notice that
most artifact identifiers are hyperlinks that take you to the particular
artifact in question.
The chapters of the Messaging Components Section of the V3 Guide
explain each of these artifacts.
2.1.3







Methodology Preview
STORYBOARD AND STORYBOARD NARRATIVE (§2.2 )
contains a describes the elemets of storyboards and
storyboard narratives.
INSERT ENTRY FOR APPLICATION ROLES
INSERT ENTRY FOR TRIGGER EVENTS
INSERT ENTRY FOR D-MIM
INSERT ENTRY FOR R-MIM
UNDERSTANDING HIERARCHICAL MESSAGE
DEFINITIONS (§2.7 ) describes Hierarchical Message
Definitions (HMDs) and their structure.
INSERT ENTRY FOR MESSAGE TYPES

INTERACTIONS (§2.9 ) discusses interactions (or
communication needs) for an HL7 message.
2.2
STORYBOARD AND STORYBOARD NARRATIVE
2.2.1
Overview
The storyboard concept is borrowed from the movie and animation
industry, and is useful to the development of HL7 messages for the
same reasons proven in that industry:




A storyboard depicts a story using a series of "snapshots" or
events in chronological sequence;
Each snapshot represents a recognizable, meaningful
moment in the sequence of events that the reader must know
about to understand the overall sequence and result;
Each snapshot illustrates the key participants in the
storyboard and their interaction with other players;
The whole series of snapshots provides a coherent
description of a complete process or activity.
Storyboarding is helpful as part of the message development
methodology because:



Each storyboard is comprised of a sequence of interactions.
Storyboarding provides context for the other normative
documents produced during the message development
process and provide the supporting narrative for collaboration
diagrams.
Storyboards are helpful in grouping interactions that may
constitute an application role.
A Storyboard consists of a short description of its purpose and an
interaction diagram that shows the progression of interactions
between the application roles. A storyboard narrative is a description
of a real-life event that provides the necessary context for the
development of a specific interaction described in the storyboard.
The process of storyboarding lays the foundation for describing HL7
messages and their content.
2.2.2
Storyboard Format
The V3 Storyboards are comprised of five sections: a Name, an ID, a
Purpose, Annotations, Interaction Diagram and List. The name is
simply a short, descriptive phrase. The ID is a 16-character code and
ST appearing as the ninth and tenth characters identifies the artifact
as a Storyboard. The purpose is a short phrase which gives the
purpose for which the storyboard was created. Frequently it
describes the generic set of actions that the storyboard represents.
Annotations are of two types, either Developments Notes (DN) or
Walk Throughs (WT). Developer notes describe how and why the
storyboard was developed. A walkthroughs is a narrative that
describes how one moves through the Interaction Diagram. The
Interaction Diagram shows the interactions between the application
roles and list of Interactions with hyperlinks to the complete
description of the Interaction.The interaction diagram is required and
can be depicted using a sequence diagram.
2.2.2.1
Storyboard Narrative Format
The V3 Storyboard Narratives are comprised of a Name, an ID, a
narrative, the applicable status field and identifier field values. The ID
is a 16-character code and SN appearing as the ninth and tenth
characters identifies the artifact as a Storyboard Narrative. The
narrative qualifies the possible ways in which the story could
transpire.
A sample Storyboard and Storyboard Narrative from Medical
Records is provided below:
Story: Original Document Notification (RCMR_ST00001UV00)
Purpose
Describe various ways documents are originated, edited, revised,
apprended, and removed from patient care.
Annotations
Type Realm Note
DN UV Universal development note
WT UV Universal walkthrough note
NEEDS FORMATTING
A sample Storyboard Diagram from the Medical Records Sub-section
is provided below
1 RCMR_IN00001 Original Document Notification
2 RCMR_IN00002 Original Document Notification and Content
3 RCMR_IN00003 Document Status Change Notification
4 RCMR_IN00004 Document Status Change Notification and
Content
5 RCMR_IN00005 Document Addendum Notification
6 RCMR_IN00006 Document Addendum Notification and Content
7 RCMR_IN00007 Document Edit Notification
8 RCMR_IN00008 Document Edit Notification and Content
9 RCMR_IN00009 Document Replacement Notification
10 RCMR_IN00010 Document Replacement Notification and
Content
11 RCMR_IN00011 Document Cancel Notification
ADD TO ABOVE NAMED GRAPHIC
Narrative: Original Document Notification (RCMR_SN00001UV00)
A pathology resident performs a gross dissection examination of the
tissue submitted from a surgical procedure to remove the gall
bladder of a 37 year old female patient. The pathologist assigns a
surgical case number to the study and dictates their observations
into a central dictation system. This narrative is exposed to a
transcriptionist who keys the text into a transcription management
system. This application generates a message from the Transcription
Management System to specialized case of a document
management system called a surgical pathology system.
Since a complete surgical pathology exam contains microscopic
findings and conclusiongs the the Document Completion Status is
marked as 'Incomplete'
Status field value contained in this message include:




Status_cd: 'draft'
Completion_cd: 'incomplete'
Confidentiality_cd: 'usual control'
Availability_dttm: not present

Storage_cd: 'active'
Identifier fields include:



id: 'a123'
set_id: 'BB35'
version_nbr: '1'
NEEDS FORMATTING
2.3
Application Roles
Application roles describe the type of system component that sends
and receives the message. An application role has a name, a
description and a unique identifier.
Role: Transcription Manager (RCMR_AR00001)
Description
Long Name: Transcription Manager
This role manages the transcription of documents and the
transmission of documents and document status changes to other
applications.
There are no specifications about how the system component carries
out these responsibilities. The same system component can be
described by more than one application role. Application roles are
not necessarily mutually exclusive, but can be nested or overlapped.
An example would be an order entry system that can send laboratory
orders or pharmacy orders. Three application roles are defined: a
Laboratory Order Placer, a Pharmacy Order Placer and a Laboratory
and Pharmacy Order Placer which includes the other two. There may
be no interactions that include application roles actually named
Laboratory and Pharmacy Order Placer, but a system component
could claim this application role and undertake to send interactions
with both Laboratory Order Placer application roles and Pharmacy
Order Placer application roles. This allows application roles to
explicitly describe niche players as well as more generalized
systems.
Application Roles are sometimes identified as being "loosely
coupled" versus "tightly coupled." This distinction refers to whether or
not additional information about the subject classes participating in a
message may be commonly available to system components outside
of the specific message. Loosely coupled application roles do not
assume common information is available, while tightly coupled
application roles do assume information is available. Information may
be common because both system components have access to a
common data store or repository or there may be separate, but
synchronized, data stored within each system. An example may be a
loosely coupled system which requires the particulars about a patient
sent with each message, versus a tightly coupled system which can
act on a message sent with only the patient identifier to distinguish
which patient.
2.4
CONFORMANCE CLAIMS AND ORGANIZATIONAL
PRACTICES
2.4.1
Introduction
HL7 V3 messages were designed to be specific enough to permit
strong conformance claims to be asserted and verified. Release 1 of
V3 has all the features that will be required for conformance
statements, but a formal V3 conformance registry process is not yet
in place
This section describes how conformance criteria are stated and used
in V3.
Most conformance criteria are stated in terms of the performance of
a healthcare information system with respect to its interfaces. As
such the burden of conformance falls primarily on the developer or
installer of the information system. The goal with respect to these
conformance criteria is to provide a concrete definition of
conformance that can be the basis of contractual agreements and
conformance testing.
Figure 4: HL7 Conformance Claims
In other cases, HL7 states good organizational practices for using
the HL7 Standard. As there is no contractual relationship between
HL7 and user organizations, HL7 does not expect to be able to audit
or otherwise enforce compliance. Nonetheless, it is extremely
valuable to state these principles in a clear and concise way.
2.4.1.1
Conformance Claims
One of the primary benefits of V3 is that conformance criteria are
stated in terms that are sufficiently concrete to use in contracts and
test the conformance of a system.
The parties that need to communicate about conformance are the
sponsors and users. The sponsor of an information system is the
vendor, in-house developer, or provider of public domain software.
The user of a health care information system is the organization that
buys or leases the information system or employs an information
system for which the software was developed in-house or is in the
public domain.
The scope of HL7 is very broad; very few if any systems will conform
to all the application roles contemplated for V 3. For this reason, a
general statement such as "system X conforms to HL7" is imprecise.
A user wants to know "to what parts of HL7 does it conform"?
In order to be precise, the specifications created by the HL7
technical committees describe entities that constitute individual
statements of conformance criteria. The sponsor of a healthcare
information system combines them into a conformance claim set by
simply publishing the list of individual conformance statements that it
claims. This list is called a conformance claim set. The user relies on
the conformance claim set to know the HL7 capabilities of a
sponsor's system, and its ability to interact with other systems,
before making a commitment to purchase or otherwise employ the
system under consideration. The user can expect that the sponsor's
system fully conforms to each of the statements in its conformance
claim set. After a contract is signed, the conformance claim set
serves as a basis for resolution of differences in the expected and
actual implementation of HL7.
As certification methods are developed for V3, there will be explicit
tests to validate the conformance of a sponsor's systems to the
statements of conformance criteria.
2.4.2
Conformance Claim Work Products
As described in the Introduction, statements of conformance criteria
are designed to provide precise descriptions of the HL7 functions a
system must support with respect to a specific part of the HL7
specifications. Conformance criteria are defined by HL7 and given an
unambiguous identifier.
A conformance claim set is a list of the identifiers of specific HL7
statements of conformance criteria.
There are two kinds of statements of conformance criteria: functional
and technical. A functional statement of conformance criteria is a
commitment to fulfill the responsibilities of a V3 application role.
Functional statements of conformance criteria are completely
specified by functional technical committees as they define
interactions relating to an application role. In other words, they are
claims to:



send certain HL7 messages to systems that conform to
certain other application roles in response to certain trigger
events;
receive certain HL7 messages to systems that conform to
certain other application roles; and
upon receipt of certain messages, perform the receiver
responsibilities.
Furthermore, the sponsor must enumerate all optional conformance
message elements associated with a conformance claim, and
identify:


whether it can send or receive the conformance message
element;
if the conformance message element is of data type
multimedia-enabled free text, which of the media types it
supports.
A technical statement of conformance criteria is any other testable
claim. Today, this is the XML Implementable Technology
Specification. In general, the Control/Query Technical Committee
writes technical statements of conformance criteria.
2.4.2.1
Functional Statement of Conformance Criteria
Each application role defined in a release of HL7 V3 specifications is
a functional statement of conformance criteria. In claiming
conformance to an application role, the sponsor is asserting that it
fulfills the obligations of that application role. This specifically means
that it sends all of the interactions that are required to be sent, and
receives all the interactions that the application role is required to
receive, and performs the receiver responsibilities associated with
them.
It is important to notice that each interaction is associated with one
and only one application role. The same message type may be used
in response to the same trigger event in another application role, but
that interaction will have a different identifier. Likewise the same
message type may be used in response to a different trigger event in
the same application role, but that will also be a different interaction.

Sending Interactions The sponsor claims that its information
system will send an interaction in response to the HL7 trigger
event that initiates it. The sponsor also claims that the
message will be sent using the message type prescribed by
HL7 in the Hierarchical Message Description (HMD. The HMD
defines the sequence, grouping, repetition and abstract type
of message elements in the message. It does not, however,
define the elements' physical format or the manner in which
the message is sent. These characteristics will vary according
to the Implementable Technology Specifications (ITS) applied
to the HMD. The interpretation of the terms null, not present
and the possible inclusion values in the HMD are critical to
determining conformance. The term conformance message
element means any element of a message that is either a
component of the message type or a component of any
component of the message type, to the entire depth of the
tree that is represented in the HMD. Certain conformance
message elements have special treatment, because they
correspond to attributes of the Reference Information Model.
They are called RIM attribute elements. The statement of
conformance criteria is different for RIM attribute elements.
Inclusion refers to the conditions under which a message
element appears in a message. The term relates directly to
the determination of conformance. This section defines how it
is used when relating to interactions that are sent by a
sponsor's information system. The possible values for the
inclusion of a message element are:
o Mandatory. The message element must appear every
time the message description is used for an Interaction
(subject to the rules of multiplicity and conditionality.) In
addition, if the component represents a RIM attribute, it
must not have any null values.
o Optional. The element need not appear in every
message instance; if it appears, and it is a RIM attribute
it can have a null value.
Conformance refers to....
o
Required. The message element must appear every
time the message description is used for an Interaction
(subject to the rules of multiplicity and conditionality.)
All message elements that have an inclusion value of
mandatory must have a conformance value of required.
o
o
Not Required. The message element may be populated
or used by one system sponsor, but not by another.
Each system sponsor is required to state its ability to
accept or send the message element as part of its
conformance claim.
Not Permitted. This message element may never occur
when the message type is used for an interaction.
Since a single HMD is used to describe multiple
message types, this option is necessary.
In describing a sponsor's information system the term function
point is any system function, user transaction, or other
interaction or event which, when it occurs, may correspond to
an HL7 Trigger Event. It is difficult to be more specific
because of the variety of architectures and terminologies used
by various information systems. The relationship between
trigger events and function points is many-to-many. More than
one function point may represent the same trigger event. For
example, "discharge AMA" and "patient death" may be
handled on different screens although they both represent the
same trigger event. It is equally true that a single function
point may represent different trigger events. For example,
"discharge mother and baby" may represent two unique
discharge trigger events. A claim that an information system
corresponds to an application role implies the following
statements:
The mappings between data elements in the sender's
database and the message must conform to the
semantics of the message information model and its
specific relationships that are named in the HMD. (This
does not imply that the sender's database uses the
same names for the data elements or has the same
structure as the appropriate HL7 message information
model.)
o Whenever any function point occurs that corresponds
to any HL7 trigger event that initiates an interaction, the
system will send all the interactions specified for the
application role.
Receiving Interactions A sponsor claiming to conform to an
application role also has requirements when receiving
interactions. In general, the receiving system must map
appropriately all message elements of the interaction instance
to the corresponding data in the receiving information system.
If, however, the message element has a conformance value of
not required and the sponsor does not claim to support the
o


message element, then this requirement does not apply. The
data so mapped must appear correctly in screens, reports,
and other outputs of the system. Specifying the information
content of specific screens, reports, and other outputs is
beyond the scope of HL7. However, if a specific data element
does occur on a screen, report, or other output, and the
corresponding data field has been received in an HL7
message, the value in the last HL7 message should appear.
Of course, this flow may be overridden by subsequent actions
of the users of the information system. The mapping between
data fields in the message and the receiver's database must
conform to the semantics of the message information model
and its specific connections that are named in the HMD. (This
does not imply that the receiver's database uses the same
names for the data fields or has the same structure as the
appropriate HL7 message information model.) If the trigger
event for which the message is sent corresponds to one or
more function points in the receiver's system it should take the
actions that correspond to the function point. Suppose, for
example, that the function point that corresponds to canceling
an order creates consequential updates to the patient account
and work list portions of the database of the information
system. The receipt of an HL7 message that corresponds to
that function point should trigger the same updates.
Sometimes the receiving information system may choose to
recognize the receipt of an HL7 message instance as a
distinct function point from the local execution of the same
information. (For example, it may choose to defer the
transaction for verification.) It is not a failure to conform to
have a reasonable but different workflow for the recognition of
events through HL7 messages. Certain interactions include
responsibilities of the receiving information systems to initiate
other interactions. In claiming that its information system
corresponds to an application role, the sponsor is claiming
that it performs all receiver responsibilities.
Simultaneously Sending and Receiving Interactions In many
cases a sponsor's information system may conform to
application roles that make the information system both the
sender and receiver of the interaction. It may implement this
transfer of information in any manner at all, not necessarily
using the HL7 Standard. In certain cases a sponsor's
information system must send an interaction both to itself and
to another application role that is implemented in another
information system. In this case it need not use HL7
interactions for the information transfer to itself, but it must use
HL7 interactions for the transfer to the other information
system.
2.4.2.2
Technical Statement of Conformance Criteria
A technical statement of conformance criteria is a statement that an
information system corresponds to some aspect of the HL7 Standard
that is different from, and independent of, the functional statement of
conformance criteria that are asserted through application roles. The
statement is made as unambiguously as possible in natural language
text. In order to be a technical statement of conformance criterion it
must also be testable.
Examples of technical statement of conformance criteria include the
Implementable Technology Specifications and special HL7 protocols
such as batch or sequence number.

Technical Conformance Criteria with Respect to Vocabularies
The Vocabulary Technical Committee will write one or more of
the technical statements of conformance criteria. They will
include these principles:
o This system has the ability to produce a report of all
local codes in use in a specific implementation.
o This system has the ability to produce an HL7 message
containing a report of all local codes in use in a specific
implementation.
o This system has the ability to change the code in use
for a concept without invalidating system outputs,
including reports that include times before and after the
change.
o This system has the ability to replace the code in use
for a concept with several that represent subspecies of
the concept without invalidating system outputs,
including reports that include times before and after the
change.
2.4.2.3
Good Organizational Practices
Statements of good organizational practice will be written as a series
of statements about the policies of a generic user organization. To
the maximum extent practical it should be possible to objectively
determine the performance of an organization with respect to the
statements.

Good Organizational Practices for Vocabulary The Vocabulary
Technical Committee will write one or more statements of
good organizational practice that embody the following
principles:
o The organization will use standard codes if they exist. If
the concept to be sent exists in the domain
specification for the field, a code from the domain must
be sent. In other words, one cannot send a local code
for something that exists in the standard domain.
o The organization will not use a code from a standard
set and give it a new meaning.
o Where the organization uses a local code, it will use
one that is consistent with the semantic type of national
codes assigned to the same data field. In other words,
if the field is "Eye Color" with values of "blue," "hazel,"
and "brown, it would be inappropriate to send a code
meaning "Arm." (Note: A violation of this principle can
only be detected by human review.)
o Where the organization finds the necessity to use local
codes, it will submit them to HL7 for review and
addition. HL7 will share these proposed concept
additions with HL7 vocabulary source providers.
o An organization will promptly begin using new codes
when it upgrades its systems.
o When an organization has submitted a local code
requesting the creation of a standard code, and the
responsible standards organization denies the creation
of a new standard code, and the denial provides an
alternative method to meet the need, the organization
will adopt the alternative method.
2.5
Trigger Events
A trigger event is an explicit set of conditions that initiate the transfer
of information between system components. A trigger event is a realworld event, for example, a laboratory order is placed, or a drug is
dispensed. A trigger event is described by a unique identifier, a
name and the description of the condition that would cause
information to flow.
Trigger: Original Document Notification (RCMR_TE00001)
Description
Long Name: Original Document Notification
This is a notification of the creation of a document without the
accompanying content. Systems become aware of documents by
multiple approaches.
A set of conditions must be systematically recognizable by an
automated system. In many cases the successful completion of a
particular business transaction is also a trigger to send messages,
such as a particular point in time (e.g., at midnight send all queued
update transactions), or a relative interval of time (e.g., every 12
hours send accumulated information to a tracking system). A
message may also be sent as a result of an "alert" event that results
from monitoring a complex set of data elements for a particular
pattern of values.
More than one interaction can be initiated by the same trigger event,
but each interaction is triggered by only one trigger event. Trigger
events are often defined in state transitions for subject classes.
These trigger events cause messages to flow because the state of a
subject class is changing. Once a trigger event has occurred,
messages are sent to inform the participating system. These state
transitions can be part of an expected business cycle or may be
triggered because of exceptions in the normal business processes.
The full set of states and their transitions are documented in state
diagrams accompanying an information model at the Reference
Information Model (RIM) level, or one of information models (Domain
Information Model (D-MIM), Message Information Model-MIM or
Refined Message Information Model-R-MIM).
2.6
REFINED MESSAGE INFORMATION MODELS
Question 2 is answered by referring to a trigger event. A trigger
event is an explicit set of conditions that initiate the transfer of
information between system components. A trigger event is
described by a unique identifier, a name and the description of the
condition that would cause information to flow.
The set of conditions must be systematically recognizable by an
automated system. Trigger events can be as simple as manual
intervention, where a human user "invokes" a specific message
transfer. In many cases the successful completion of a particular
business transaction is also a trigger to send messages, such as a
particular point in time (e.g., at midnight send all queued update
transactions), or a relative interval of time (e.g., every 12 hours send
accumulated information to a tracking system). A message may also
be sent as a result of an "alert" event that results from monitoring a
complex set of data elements for a particular pattern of values.
More than one interaction can be initiated by the same trigger event,
but each interaction is triggered by only one trigger event. Trigger
events are often defined in state transitions for subject classes.
These trigger events cause messages to flow because the state of a
subject class is changing because a trigger event has occurred and
the messages are being sent to inform participating system
components. These state transitions can be part of an expected
business cycle or may be triggered because of exceptions in the
normal business processes. The full set of states and their
transitions are documented in state diagrams accompanying an
information model at the Reference Information Model (RIM) level, or
one of information models (Message Information Model-MIM or
Refined Message Information Model-R-MIM) defined during
message development.
2.7
UNDERSTANDING HIERARCHICAL MESSAGE
DEFINITIONS
2.7.1
Overview
This chapter describes how a message structure uses the
Hierarchical Message Definitions (HMD), a normative expression of
the standard.
Some questions that are frequently asked are: "Why do we need to
create an HMD? If we already know the sender, the receiver, the
trigger event and the classes, why not just send the data?" There are
several important answers to this question.


The information model contains a group of classes that
frequently are interconnected in more than one way. For
example, there may be associations that lead from Patient to
Person directly (this is the person who is the patient) and
indirectly (this is the person who is the next of kin or the
patient, or this is the person who is the primary physician of
the patient). The communicating systems must be able to
determine which of the objects derived from these classes
contain the data to be sent. Furthermore, they must be able to
navigate to the related objects through the associations that
are defined for the classes.
The same attributes may not be appropriate for different
objects. Although both the patient and the physician
associated with a clinical order are people, it is unlikely that
we will send the physician's religion, date of birth, or sex each
time we process an order for the patient. The communicating
systems must be aware which of the objects will be sent.

Finally, to send data over the wire, the computer must
organize it sequentially. There are many different ways to
organize the data from a group of objects interconnected by
their associations. If the sender and the receiver do not agree
exactly on that order, the communication is frustrated. If the
sender transmits information about the attending physician
before that of the primary care physician, and the receiver is
expecting the opposite order, there will be a problem. The
communicating systems must know the exact sequence in
which information will be sent.
The Hierarchical Message Definition specifies these choices. It
defines a single message structure that is used for an interaction
without reference to the implementation technology. The
Implementation Technology Specification describes how to combine
data with the message structure in order to create a message
instance. This means that a message sent in the format of one
implementation technology can be easily transliterated into the
format of another.
In simplest terms, an HMD is a tabular representation of the
sequence of elements (i.e., classes, attributes and associations) that
may be used to generate HL7 messages. The HMD is composed of
three sections. The leftmost section maps the elements (classes,
attributes and associations) to the RIM. The center section, called
the common message, is a generic template for the specific
instances described on the rightmost part of the HMD. The common
message will never be sent, and does not have a corresponding
trigger event. The specific instances of the message, called message
types, described on the rightmost part of the HMD may be
communicated in response to a trigger event.
A sample HMD is provided below:
Figure 5: Sample HMD.
2.7.2
Hierarchial Message Descriptor (HMD) Column Descriptions
No - Row number. Each row is sequentially numbered and identifies
the order in which the data within the message is sent.
Row - Identifies the type of element. Valid values are class, attr
(attribute), and assoc (association).
Property - The name of the class, attribute or association role name
as it appears in the RIM.
RIM Source - Identifies the class from which the attribute or
association originates.
Element Name - The name of the element as it appears in the RMIM. This may or may not be the same as the value in Property. This
value will be different when a class, association or role is cloned and
renamed in the process of creating the R-MIM.
Short Name - The name of the element in the XML ITS. Refer to the
HL7 Version 3 Standard: XML Implementation Technology
Specification for more details.
InMET - In Message Element Type. This column points to the parent
of the element within the current hierarchy.
OfMET - Of Message Element Type. Identifies the data type of
attributes or class name of associations.
S - Message Element Type Source. Valid values are D (data type), N
(new, being defined starting at this row), U (use, meaning that an
element, but not its value, from a previous row in the HMD is being
reused), C (CMET), I (Instance, refers to the reuse of a particular
element and its value as defined previously in the HMD), and R
(recursive, into itself).
Each group of the following columns appears in both the template
and the Message Types:
C - Cardinality. This specifies the minimum and maximum number of
occurrences of the message element.
D - Vocabulary Domain Specification. Clicking on this link will take
you to the Domain Specification for this element.
CS - Coding Strength. Valid values are CWE (coded with exceptions,
meaning that the code set can be expanded to meet local
implementation needs) and CNE (coded no exceptions, meaning that
the code set cannot be expanded).
M - Mandatory. Valid values are M (Mandatory) or Blank. An M in the
field requires that some data be sent for this element. If the data is
not known, a value of unknown, not given, etc. must be sent. An M in
this column (for Mandatory) differs from a 1 in the Cardinality column
in that an M indicates that the message cannot be validly parsed
without a value in this field or without defining a default. If no default
is provided, you either do not send a message or must send a value.
An M in this column also differs from an R in the Conformance
column (explained below).
N - Note. If one is provided, this is simply a free text note provided by
the committee.
D - Default. Default value provided by the committee. If null is sent,
the default should be substituted on receipt (i.e., if the default value
is 10 and a null is sent, the receiving system should substitute 10).
D - Default Update Mode. This is a heading for the allowable set of
values defined in the Update Mode Set column.
U - Update Mode Set. The allowable set of values for the mode
identified in the Default Update Mode column.
C - Conformance. Valid values are R (required), NP (not permitted),
and Blank (not required). A value of R (required) means that the
message elements must appear every time the message description
is used for an Interaction. If the data is available, the element must
carry the data. If the data is not available, a blank may be sent. NP
(not permitted) means that the message element is never sent for
this message type. Blank means that conformance for this element is
to be negotiated on a site-specific basis.
2.8
Message Types
A message type has an assigned unique identifier and a description
along with annotations. The specific message type is documented in
the Hierarchical Message Description (HMD) and is associated with
a specific D-MIM and R-MIM.
Message Type: Document Header (without contents)
(RCMR_MT00001)
Grid View
Table View
Schema
Example
Grid View
Table View
Schema
Example
Description
This message type is used to convey status information about a
document, without sending the document itself.
Annotations
Type
Realm
Note
DN
UV Universal development note
WT
UV Universal walkthrough note
The HMD specifies the order and constraints of particular set of
attributes and relationships drawn from the RIM classes of interest.
Each unique pattern of attributes and relationships is made explicit
as "cloned" classes. A single HMD can specify different patterns of
constraints for the same set of attributes as long as the constraints
are at least as strict as those prescribed in the common message for
the HMD. Constraints may be stricter (or "tighter") than the common
message. This allows a single HMD to satisfy the needs of a number
of related interactions. For example, an HMD may be defined to
satisfy the information needs for adding a person to a registry. One
of the message types defined for the HMD contains all relevant
attributes. Different constraints can be applied in a related message
type to update various person characteristics.
2.9
INTERACTIONS
2.9.1
Overview
Interactions are at the heart of messaging. The formal definition of an
interaction is:
A unique association between a specific message type (information
transfer), a particular trigger event that initiates or "triggers" the
transfer, and the application roles that send and receive the
message type. It is a unique, one-way transfer of information.
A single Interaction explicitly answers the questions:
1. Which type of system component sends a particular type of
message;
2. How a system knows when to send a particular type of
message;
3. What the particular message type is;
4. To what type of receiving system component the message
type is sent;
5. What the expectations are, if any, for the receiving system to
be able to send other associated interactions.
2.9.1.1
Application Roles
Application roles describe the type of system component that sends
and receives the message, answering questions 1 and 4. An
application role has a name, a description and a unique identifier.
The scope of responsibility for a particular application role is the
complete set of interactions in which the system component
participates, either as a sender or a receiver.
Application Roles are sometimes identified as being "loosely
coupled" versus "tightly coupled." This distinction refers to whether or
not additional information about the subject classes participating in a
message may be commonly available to system components outside
of the specific message. Loosely coupled application roles do not
assume common information is available, while tightly coupled
application roles do assume information is available.
2.9.1.2
Trigger Event
Question 2 of the Interaction definition is answered by referring to a
trigger event. A trigger event is an explicit set of conditions that
initiate the transfer of information between system components. A
trigger event is described by a unique identifier, a name and the
description of the condition that would cause information to flow. The
set of conditions must be systematically recognizable by an
automated system. Trigger events can be as simple as manual
intervention, where a human user "invokes" a specific message
transfer. In many cases the successful completion of a particular
business transaction is also a trigger to send messages, such as a
particular point in time (e.g., at midnight send all queued update
transactions), or a relative interval of time (e.g., every 12 hours send
accumulated information to a tracking system). A message may also
be sent as a result of an "alert" event that results from monitoring a
complex set of data elements for a particular pattern of values.
More than one interaction can be initiated by the same trigger event,
but each interaction is triggered by only one trigger event. Trigger
events are often defined in terms of state transitions for subject
classes. These trigger events cause messages to flow because the
state of a subject class is changing. These state transitions can be
part of an expected business cycle or may be triggered because of
exceptions in the normal business processes.
2.9.2
Message Types
Question 3 is answered by referring to a specific message type. A
message type has an assigned unique identifier and a description.
The specific message type is documented in the Hierarchical
Message Description (HMD) that is defined during the message
development processes and is associated with as specific R-MIM.
The HMD specifies the order and constraints of particular set of
attributes and relationships drawn from the RIM classes of interest
with each unique pattern of attributes and relationships made explicit
as "cloned" classes. A single HMD can specify different patterns of
constraints for the same set of attributes as long as the constraints
are at least as strict as those prescribed in the common message for
the HMD. Constraints may be stricter (or "tighter") than the common
message. This allows a single HMD to satisfy the needs of a number
of related interactions. For example, an HMD may be defined to
satisfy the information needs for adding a person to a registry. One
of the message types defined for the HMD contains all relevant
attributes. Different constraints can be applied in a related message
type to update various person characteristics.
2.9.3
Receiver Responsibilities
The definition of receiver responsibilities answers question 5.
Receiver responsibilities refer to additional interactions that the
receiving application role must initiate upon receiving the interaction
in question. Receiver responsibilities do not necessarily exist for
each interaction. Receiving a message may be considered a trigger
event that causes information to flow, or there may be additional
conditions that must be fulfilled prior to subsequent message(s)
being sent. The receiver responsibilities is expressed as a list of the
interactions the receiving application role must be able to send.
2.9.4
Interaction Models
The interdependencies between interactions may be expressed as
sequence diagrams. A sequence diagram expresses the same
information but is read from the top down to indicate the expected
sequence of related interactions. The purpose is usually described
through a storyboard, which may be illustrated with storyboard
examples.
Figure 6: Sequence Diagram.
A
References
Message Development Framework
HL7 Version 3 Standard: Message Development Framework, HL7
Version 3 Taskforce
HL7 Version 3 Standard: Administrative Management
HL7 Version 3 Standard: Administrative Management, HL7 Version 3
Taskforce
HL7 Version 3 Standard: Infrastructure Management
HL7 Version 3 Standard: Infrastructure Management, HL7 Version 3
Taskforce
HL7 Version 3 Standard: Health and Clinical Management
HL7 Version 3 Standard: Health and Clinical Management, HL7 Version
3 Taskforce
HL7 Version 3 Standard: Vocabulary
HL7 Version 3 Standard: Vocabulary, HL7 Version 3 Taskforce
HL7 Version 3 Statement of Principles
HL7 Version 3 Statement of Principles, HL7 Version 3 Taskforce
stofprin
Method for the Development of Healthcare Messages
Method for the Development of Healthcare Messages, CEN TC 251
Object Oriented Software Engineering
Object Oriented Software Engineering, Ivar Jacobson, et al.
Object Oriented Analysis
Object Oriented Analysis, Peter Coad & Ed Yourdon
Open EDI Reference Model
Open EDI Reference Model, ISO/IEC CD 14662
Unified Method, Version 0.8
Unified Method, Version 0.8, Grady Booch & James Rumbaugh
UML Distilled
UML Distilled, Martin Fowler with Kendall Scott
B
Appendix A: Act Properties and Moods
Table 1: Detailed behavior of Act properties with
Property
Definition
Intent (and ord
Act.id
object id
object id
Act.availability_time
time the object was
created
time the object w
created
Act.confidentiality_cd
applicable confidentiality
policies.
confidentiality
policy (at least a
strong as in
definition.)
name of defined action
name of intende
action, redundan
action is identifie
through a link to
act definition
Act.txt
textbook-like description
of the act
description of the
intended actions
instructions (not
just repeating wh
is said already in
the text of the ac
definition)
Act.activity_time
the time the act provider
carries out the action
(e.g., business hours)
the time(s) the
action is
(tentatively)
scheduled to
Act.cd
Table 1: Detailed behavior of Act properties with
Property
Definition
Intent (and ord
happen, most
intents will only u
effective time
leaving activity ti
open
Act.effective_time
not used
constrains the
effective time of
the event
Act.status_cd
state of the act definition
(see text describing the
attribute.)
state of the inten
(see text.)
procedure.method_cd
method(s) available for
the Act. No method code
is applicable if not listed
in the act definition
method selected
or method(s)
constrained,
subset of the
definition's meth
codes
Act.interpretation_cd
interpretation codes
applicable (reported) with
not used
Table 1: Detailed behavior of Act properties with
Property
Definition
Intent (and ord
this act
Act.repeat_nbr
minimum/maximum
number of a repeatable
minimum/maxim
Act. Most acts are
number of
repeatable and maximum repetitions order
is by default infinite
Act.interruptible_ind
specifies defined act (or
specifies step in
plan component) as being the care plan as
interruptible
being interruptib
Observation.value ordered scales
specifies the absolute
range of possible
observation values.
not used
nominal scales
specifies the domain of
the defined parameter
not used
Observation.derivation_expr
an expression for
same as in
calculating the value from
definition
linked input parameters
Substance_administration.doseform_cd
the set of doseforms
available for this
medication act, though
the ordered
usually
doseform(s),
Substance_administration usually just one
acts are defined one per
doseform
Table 1: Detailed behavior of Act properties with
Property
Definition
Intent (and ord
Substance_administration.route_cd
the set of routes
applicable for the
medication, however,
medication can be
administered over
unusual routes
the route(s)
ordered or
intended
Substance_administration.dose_qty
a range defining the
recommended dosage
an ordered
dosage, may be
crisp quantity or
constrained rang
Substance_administration.strength_qty
the strength
actually ordered,
may be empty
a set of strengths, though
since the order
medications are usually
does not need to
defined one per strength
concern itself wit
manufactured
drugs
Substance_administration.rate_qty
a range defining the
recommended rate
a range (or crisp
quantity) for the
intended rate
Substance_administration.substitution_cd
specifies allowable kinds
and reasons for
substitution (if any)
specifies allowab
kinds and reason
for substitution (i
any)
not used (although could
not used (althou
be used as in 0.5(1 g Q4Substance_administration.dose_check_qty
could be used as
6H but not more than 4
definition)
g/d)
Endnotes
1. [source] In other models, the lower case letters "n" or "m" are
sometimes used, indicating integer variables. This notation is
not defined in the UML Notation Guide. The problem with
using letters instead of the asterisk is that if the same letter is
used more than once, it may be misunderstood to represent
the same integer number everywhere. Furthermore, an "n"
indicates some boundary specified elsewhere, while the
asterisk ("*") indicates unbounded multiplicity, without the
notion of any dependency between such multiplicities.