ISO/HL7 21731:2006

INTERNATIONAL ISO/HL7
STANDARD 21731
First edition
2006-08-01
Health informatics — HL7 version 3 —
Reference information model —
Release 1
Informatique de santé — HL7 version 3 — Modèle d'information de
référence — Version 1
Reference number
©
ISO/HL7 2006
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO and HL7 2006
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO or IDF at the respective
address below.
ISO copyright office Health Level Seven, Inc.
Case postale 56 • CH-1211 Geneva 20 • Switzerland Standards Publishing Department
Tel. + 41 22 749 01 11 3300 Washtenaw Avenue, Suite 227
Fax + 41 22 749 09 47 Ann Arbor, MI 48104 • USA
E-mail copyright@iso.org E-mail hq@hl7.org
Web www.iso.org Web www.hl7.org
Published in Switzerland
ii © ISO/HL7 2006 – All rights reserved

ISO 21731:2006(E) & ANSI/HL7 RIM R1-2003
HEALTH LEVEL SEVEN
REFERENCE INFORMATION MODEL,
RELEASE 1
Modeling & Methodology George Beeler, Jr., PhD.
Co-Chair Beeler Consulting LLC
Editor James Case, DVM, PhD.
University of California, Davis
Modeling & Methodology Jane Curry
Co-Chair Sierra Systems & CIHI - HL7 Canada
Modeling & Methodology Ann Hueber
Co-Chair Pathology Associates Medical Laboratories
Editor Lloyd Mckenzie
IBM Canada & CIHI - HL7 Canada & Alberta Wellnet
Editor Gunther Schadow, M.D., PhD.
Regenstrief Institute for Health Care
Modeling & Methodology Abdul-Malik Shakir
Co-Chair Shakir Consulting LLC
Health Level Seven and HL7 are registered trademarks of Health Level Seven, Inc.
Health Level Seven, 3300 Washtenaw Avenue, Suite 227, Ann Arbor, MI 48104-4261. Phone: 734-677-7777
Fax: 734-677-6622, Email: HQ@HL7.org; Internet: http://www.HL7.org
© ISO/HL7 2006 - All rights reserved iii

ISO 21731:2006(E) & ANSI/HL7 RIM R1-2003
CONTENTS PAGE
Foreword . vi
0 Introduction . vi
0.1 Uses of a Reference Information Model (RIM) in Health Informatics . vi
0.2 Further information . vii
1 Scope . 1
2 Conformance . 1
3 Normative references . 1
4 Terms and definitions . 1
5 Interpretation of the Specification . 7
5.1 Specification contents . 7
5.2 Understanding the RIM . 8
5.3 Graphic Diagrams of the RIM . 9
6 Subject areas . 15
6.1 FoundationClasses . 15
6.1.1 Acts . 15
6.1.2 Entities . 16
6.1.3 Roles . 16
7 Classes . 16
7.1 Classes in subject area Acts . 16
7.2 Classes in subject area Entities . 61
7.3 Classes in subject area Roles . 77
8 Associations . 85
8.1 (0.*)ActRelationship :: source :: (1.1)Act :: outboundRelationship . 85
8.2 (0.*)ActRelationship :: target :: (1.1)Act :: inboundRelationship . 85
8.3 (1.1)Entity :: languageCommunication :: (0.*)LanguageCommunication :: entity . 85
8.4 (0.*)Participation :: act :: (1.1)Act :: participation . 85
8.5 (0.*)Participation :: role :: (1.1)Role :: participation . 85
8.6 (0.*)Role :: player :: (0.1)Entity :: playedRole . 85
8.7 (0.*)Role :: scoper :: (0.1)Entity :: scopedRole . 85
8.8 (0.*)RoleLink :: source :: (1.1)Role :: outboundLink . 85
8.9 (0.*)RoleLink :: target :: (1.1)Role :: inboundLink . 85
9 Normative Vocabulary Contents . 86
9.1 RIM Structural Vocabulary . 86
9.2 ActClass . 87
9.3 ActMood . 97
9.4 ActRelationshipCheckpoint . 99
9.5 ActRelationshipJoin . 99
9.6 ActRelationshipSplit . 100
9.7 ActRelationshipType . 100
9.8 ActStatus . 107
iv © ISO/HL7 2006 - All rights reserved

ISO 21731:2006(E) & ANSI/HL7 RIM R1-2003
9.9 ContextControl . 108
9.10 EntityClass . 110
9.11 EntityDeterminer . 112
9.12 EntityStatus . 113
9.13 ManagedParticipationStatus . 113
9.14 ParticipationType . 113
9.15 RelationshipConjunction . 118
9.16 RoleClass . 118
9.17 RoleLinkType . 125
9.18 RoleStatus . 125
Annex A (informative) Background of RIM Development . 126
A.1 History of the RIM . 126
A.2 Implications of Balloting the RIM . 126
Annex B (informative) Overview of RIM Design Principles . 128
B.1 Purpose . 128
B.2 Overview . 128
B.3 The Rationale Behind the RIM's Design . 128
B.4 Linking Acts Together: The Semantics of ActRelationship . 130
B.5 Definitions of the Six Core Rim Classes . 131
B.6 Data Type and Vocabulary Specifications . 132
B.7 HL7 Version 3 Methodology and the RIM . 133
Annex C (informative) Summary of Version 3 Data Types . 134
C.1 Overview of Data Types . 134
© ISO/HL7 2006 - All rights reserved v

ISO 21731:2006(E) & ANSI/HL7 RIM R1-2003
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee has
been established has the right to be represented on that committee. International organizations, governmental
and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
A pilot project between ISO and Health Level Seven Inc. (HL7) has been formed to develop and maintain
a group of ISO/HL7 standards in the field of medical devices as approved by Council resolution 7/2002.
Under this pilot project, HL7 is responsible for the development and maintenance of these standards with
participation and input from ISO member bodies.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/HL7 21731 was prepared by HL7 and Technical Committee ISO/TC 215, Health informatics.
0 Introduction
This introduction is confined to discussion of the requirement for a Reference Information Model in
standardization. Further information on the development of this model and the rational for advancing it as
a standard can be found in Annex A.
0.1 Uses of a Reference Information Model (RIM) in Health Informatics
0.1.1 Use of the RIM in ISO TC215
ISO TC215 – Health Informatics has previously advanced ISO 17113, a specification for a framweork for
developing health data interchange standards. This framework specification calls for messaging standards
to be based on a single, comprehensive model of health information. The RIM presented in the current
specification provides one such model. Further, the RIM may provide a reference document that can facilitate
the harmonization of the health informatics standards and relaterd specifications within ISO TC 215.
0.1.2 Use of the RIM by HL7
The HL7 RIM is a critical component of the V3 development process. It is the root of all information models
and structures developed as part of the V3 development process.
The HL7 V3 standard development process is a model-driven methodology in which a network of inter-related
models are developed that depict the static and behavioral aspects of the requirements and design of HL7
standards, as well as the underlying semantics and business rules that govern them.
vi © ISO/HL7 2006 - All rights reserved

TThe
l committees are circulated to the member bodies for
ISO 21731:2006(E) & ANSI/HL7 RIM R1-2003
0 INTRODUCTION
The RIM provides a static view of the information needs of HL7 V3 standards. It includes class and
state-machine diagrams and is accompanied by use case models, interaction models, data type models,
terminology models, and other types of models to provide a complete view of the requirements and design
of HL7 standards. The classes, attributes, state-machines, and relationships in the RIM are used to derive
domain-specific information models that are then transformed through a series of constraining refinement
processes to eventually yield a static model of the information content of an HL7 standard.
The HL7 V3 standard development process defines the rules governing the derivation of domain information
models from the RIM and the refinement of those models into HL7 standard specifications. The rules require
that all information structures in derived models be traceable back to the RIM and that their semantic and
related business rules not conflict with those specified in the RIM. The RIM therefore is the ultimate source
for all information content in HL7 V3 standards.
The RIM is used by HL7 international affiliates to extend HL7 V3 standards to meet local needs. Through
a process known as localization, V3 standard specifications are extended using the RIM as the source for
new information content. This new information is derived from the RIM and refined in the same manner used
to create the original specification.
0.1.3 Uses of the RIM Outside of HL7
The RIM is primarily for use by HL7 and its international affiliates. However, others outside of HL7 have also
found the RIM useful. Although HL7 maintains a copyright on the expression of this standard, HL7 does not
seek to license or otherwise control the use of information structures or programs that implement this
specification. Early adopters of the V3 standards development process have used the RIM to develop
HL7-like message specifications in their own environments. These early adopters include vendors, large
integrated delivery networks, and government agencies within the United States and internationally. These
same early adopters are extremely active in HL7 and provide practical input to the RIM and other aspects
of V3 the development process.
Some HL7 member organizations have reported using the RIM as a source of input to their enterprise
information architectures or as a starting place for systems analysis and design. The RIM may indeed be
useful for such purposes; however, HL7 provides no assurance that the RIM is useful for anything other
than as a reference model for HL7 standards development.
The RIM is only one model of healthcare information needs. The abstract style of the RIM and the ability to
extend the RIM through vocabulary specifications make the RIM applicable to any conceivable healthcare
system information interchange scenario. In fact, it is conceptually applicable to any information domain
involving entities playing roles and participating in acts.
The universal applicability of the RIM makes it particularly useful for an organization like HL7 that has to
consider the needs of a large and diverse membership. The style of the RIM makes it extremely stable,
which is another important characteristic for HL7. The HL7 standards development process calls for the
creation of domain specific models derived from the RIM and the incremental refinement of those models
into design models that are specific to the problem area. These problem area specific design models narrow
the abstractness of the RIM and include constraints on attribute values and class relationships that are use
case specific. External organizations considering using the HL7 RIM are advised to adopt a similar process
of deriving design models as a transformation of the RIM.
0.2 Further information
Questions or comments about the content of the standard may be addressed to HL7 at (www.hl7.org), to
one of the HL7 International Affiliate organizations, or to the Secretariat of ISO TC215 – Health Informatics.
© ISO/HL7 2006 - All rights reserved vii

INTERNATIONAL STANDARD ISO 21731:2006(E) & ANSI/HL7 RIM R1-2003
Health informatics — HL7 version 3 — Reference information
model — Release 1
1 Scope
The Health Level Seven (HL7) Reference Information Model (RIM) is a static model of health and health
care information as viewed within the scope of HL7 standards development activities. It is the combined
consensus view of information from the perspective of the HL7 working group and the HL7 international
affiliates. The RIM is the ultimate source from which all HL7 version 3.0 protocol specification standards
draw their information-related content. In the context of ISO TC215 – Health Informatics, the RIM provides
a reference model that may be used in developing further health informatics specifications.
2 Conformance
An information model such as the RIM specified in this standard may serve as the basis for other information
models that are directly derived from it, and may provide a foundation to support the design of data bases
and other information structures. Nevertheless, neither ISO TC 215 nor HL7 believe that it is reasonable to
define tests of whether a particular implementation may conform to this standard. Therefore users of this
standard shall not claim conformance to this standard. Further, ISO TC215 and HL7, as developers of this
standard request that users inform them of particular requirements which caused the users to deviate from
this stanard or to extend it. This will allow subsequent releases of the standard to meet a broader range of
requirements.
3 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 17113, Health informatics — Exchange of information between healthcare information systems —
Method for development of messages
ISO/IEC 19501, Information technology — Open Distributed Processing — Unified Modeling Language
(UML) Version 1.4.2
ANSI/HL7 V3 DT, R1-2004, HL7 Version 3 Standard: Data Types — Abstract Specification, Release 1

4 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
4.1
ANSI
American National Standards Institute
© ISO/HL7 2006 - All rights reserved 1

ISO 21731:2006(E) & ANSI/HL7 RIM R1-2003 4 TERMS AND DEFINITIONS
4.2
association
A reference from one class to another class or to itself, or a connection between two objects (instances of
classes).
4.3
association role name
A name for each end of an association. The name is a short verb phrase depicting the role of the class at
the opposite end of the association from the perspective of the class adjacent to the role.
4.4
attribute
An abstraction of a particular aspect of a class. Attributes become the data values that are passed in HL7
messages.
4.5
bag
A form of collection whose members are unordered, and need not be unique.
4.6
cardinality
Property of a data element (the number of times a data element may repeat within an individual occurrence
of an object view).
4.7
class
An abstraction of a thing or concept in a particular application domain.
4.8
classifier attribute
An attribute used in generalization hierarchies to indicate which of the specializations is the focus of the
class .
4.9
coded attribute
An attribute in the Reference Information Model (RIM) with a base data type of CD, CE, CS, or CV.
4.10
coding strength
An extensibility qualifier that specifies whether or not a code set can be expanded to meet local implementation
needs.
4.11
coding system
A scheme for representing concepts using (usually) short concept identifiers to denote the concepts that
are members of the system; defines a set of unique concept codes. Examples of coding systems are ICD-9,
LOINC and SNOMED.
4.12
collection
An aggregation of similar objects. The forms of collection used by HL7 are set , bag, and list. Objects which
may be found in collections include data types.
2 © ISO/HL7 2006 - All rights reserved

4 TERMS AND DEFINITIONS ISO 21731:2006(E) & ANSI/HL7 RIM R1-2003
4.13
connection
In an information model, a specified relationship between two classes .
4.14
data type
The structural format of the data carried in an attribute. It may constrain the set of values an attribute may
assume.
4.15
distal class
From the perspective of a class in an information model, it is the class at the opposite end of an association
between the two.
4.16
domain
1. A particular area of interest. For example, the domain for HL7 is healthcare.
2. The set of possible values of a data type , attribute, or data type component. See also vocabulary domain.
4.17
event
1. A stimulus that causes a noteworthy change in the state of an object, or a signal that invokes the behavior
of an object.
2. A vocabulary domain value for Mood.
4.18
extensibility qualifier
A vocabulary domain qualifier used in a domain specification, which indicates whether or not the existing
vocabulary domain can be extended with additional values. There are two possible values: CNE (coded, no
extension) and CWE (coded with extension).
4.19
generalization
An association between two classes, referred to as superclass and subclass, in which the subclass is derived
from the superclass. The subclass inherits all properties from the superclass, including attributes,
relationships, and states, but also adds new ones to extend the capabilities of the parent class. Essentially,
a specialization from the point-of-view of the subclass.
4.20
generalization hierarchy
All superclasses and subclasses with a common root superclass.
4.21
graphical expression
A visual representation of a model that uses graphic symbols to represent the components of the model
and the relationships that exist between those components.
© ISO/HL7 2006 - All rights reserved 3

ISO 21731:2006(E) & ANSI/HL7 RIM R1-2003 4 TERMS AND DEFINITIONS
4.22
Health Level Seven
HL7
A standards developing organization based in the United States of America.
4.23
identifier attribute
An attribute used to identify an instance of a class.
4.24
information model
A structured specification, expressed graphically and/or narratively, of the information requirements of a
domain. An information model describes the classes of information required and the properties of those
classes, including attributes, relationships, and states. Examples in HL7 are the Domain Reference Information
Model, Reference Information Model, and Refined Message Information Model.
4.25
inheritance
In a generalization relationship, the subclass inherits all properties from the superclass, including attributes,
relationships, and states, unless otherwise specified.
4.26
instance
A case or an occurrence. For example, an instance of a class is an object.
4.27
list
A form of collection whose members are ordered, and need not be unique.
4.28
literary expression
A representation of a model in text. The literary expression seeks to balance the need for a rigorous,
unambiguous description of the model with the need for a rendition that can be easily read and interpreted
by individuals who understand the general concepts underlying object-oriented models, but who may not
be schooled in formal model definition languages.
4.29
mandatory
If an attribute is designated as mandatory, all message elements which make use of this attribute must
contain a non-null value or they must have a default that is not null.
4.30
mandatory association
An association with a multiplicity minimum greater than zero on one end. A fully mandatory association is
one with a multiplicity minimum greater than zero on both ends.
4.31
methodology
Methods or rules followed in a particular discipline.
4 © ISO/HL7 2006 - All rights reserved

4 TERMS AND DEFINITIONS ISO 21731:2005(E) & ANSI/HL7 RIM R1-2003
4.32
model
A representation of a domain that uses abstraction to express the relevant concepts.
4.33
multiplicity
In the information model, multiplicity is a specification of the minimum and maximum number of objects from
each class that can participate in an association. Multiplicity is specified for each end of the association.
4.34
namespace
A namespace is a part of the model in which names are defined and used, where each name has a unique
meaning.
4.35
object
An instance of a class. A part of an information system containing a collection of related data (in the form
of attributes) and procedures (methods) for operating on that data.
4.36
object identity
The feature that the existence of an object is independent of any values associated with the object.
4.37
object-based
Any method, language, or system that supports object identity, classification, and encapsulation. An
object-based system does not support specialization . Ada is an example of an object-based implementation
language.
4.38
property
Any attribute, association, method, or state model defined for a class or object.
4.39
Reference Information Model
RIM
The HL7 information model from which all other information models (e.g., R-MIMs) and messages are
derived.
4.40
role
1. A function or position.
2. A Reference Information Model class that defines the competency of an Entity class. Each role is played
by one Entity (the Entity that is in the role) and is usually scoped by another.
3. In UML, each end of an association is designated as a role to reflect the function that class plays in the
association.
4.41
role name
See association role name.
© ISO/HL7 2005 - All rights reserved 5

ISO 21731:2006(E) & ANSI/HL7 RIM R1-2003 4 TERMS AND DEFINITIONS
4.42
set
A form of collection which contains an unordered list of unique elements of a single type.
4.43
specialization
An association between two classes (designated superclass and subclass), in which the subclass is derived
from the superclass. The subclass inherits all properties from the superclass, including attributes, relationships,
and states, but also adds new ones to extend the capabilities of the superclass.
4.44
state
A named condition of a class instance ( object) that can be tested by examination of the instance's attributes
and associations.
4.45
state attribute
An attribute describing the current state of an object.
4.46
state diagram
A graphical representation of a state transition model showing states as vertices (nodes) and state transitions
as directed arcs (arrows) between the nodes.
4.47
state machine
A description of the life cycle for instances of a class, defined by a state transition model.
4.48
state transition
A change in the state of an object, as a result of a change in its attributes or associations.
4.49
state transition model
A graphical representation of the life cycle of a class. The model depicts all of the relevant states of a class,
and the valid transitions from state to state.
4.50
subclass
A class that is the specialization of another class (superclass).
4.51
subject area
A convenient aggregation of model classes used to partition large models into manageable subsets.
4.52
sub-state
An identifiable state of a class that has a more specific definition than, and is entirely encompassed within
the scope of, its super-state.
6 © ISO/HL7 2006 - All rights reserved

5 INTERPRETATION OF THE SPECIFICATION ISO 21731:2006(E) & ANSI/HL7 RIM R1-2003
4.53
superclass
A class that is the generalization of one or more other classes (subclasses).
4.54
super-state
A state of a class that encompasses two or more independent sub-states.
4.55
Unified Modeling Language (UML)
A language for the creation of domain models. UML was created in order to unify several well-known
object-oriented modeling methodologies, including those of Booch, Rumbaugh, Jacobson, and others.
4.56
vocabulary
The set of valid values for a coded attribute or field.
4.57
vocabulary domain
The set of all concepts that can be taken as valid values in an instance of a coded attribute or field; a
constraint applicable to code values.
4.58
vocabulary domain qualifier
Part of a vocabulary domain specification. The two existing qualifiers are extensibility and realm.
4.59
W3C
The World Wide Web Consortium, an international industry consortium
5 Interpretation of the Specification
5.1 Specification contents
The RIM consists of classes assigned to one or more subject area packages. Attributes, Relationships, and
State Machines are associated with classes.
Each class within the RIM represents information about a concept that must be documented and
communicated within the health care environment. The names that are assigned to these classes are drawn
from normal language, but the use of these names is necessarily constrained to the "namespace" of the
RIM. The meaning of these classes is entirely embodied in the definition of the class, and the definitions of
the properties (attributes and associations) assigned to that class. Thus, for example, the meaning of the
"Role" class can only be understood by studying the definition provided and the properties assigned.
Definitions from another context or dictionary definitions for the name are not relevant within the context of
the RIM namespace.
The RIM is expressed using the Unified Modeling Language (UML) with HL7 specific tags as extensions to
the UML model element metadata. All standard UML model element metadata values are normative but
only the following HL7 extensions are also normative:
• Class.stateAttribute
• Class.classCode
© ISO/HL7 2006 - All rights reserved 7

ISO 21731:2006(E) & ANSI/HL7 RIM R1-2003 5 INTERPRETATION OF THE SPECIFICATION
• Attribute.mandatoryInclusion
• Attribute.cardinality
• Attribute.vocabDomain
• Attribute.vocabStrength
5.2 Understanding the RIM
The RIM uses a very abstract modeling style. The back-bone classes of the RIM and their structural attributes
are its core. An understanding of these classes and attributes is essential to understanding the RIM. This
section describes how the abstractions are represented in UML and controlled through the application of
controlling vocabulary that is part of this specification. An "executive overview" or high-level tutorial that
provides examples of how these abstractions can be used to represent more detailed health information is
contained in Annex B.
5.2.1 RIM as an abstract model
The RIM is comprised of six "back-bone" classes:
• Act which represents the actions that are executed and must be documented as health care is managed
and provided;
• Participation which expresses the context for an act in terms such as who performed it, for whom it was
done, where it was done, etc.;
• Entity which represents the physical things and beings that are of interest to, and take part in health
care;
• Role which establishes the roles that entities play as they participate in health care acts;
• ActRelationship which represents the binding of one act to another, such as the relationship between
an order for an observation and the observation event as it occurs; and
• RoleLink which represents relationships between individual roles.
Three of these classes -- Act, Entity and Role -- are further represented by a set of specialized classes, or
sub-types. In the HL7 representation, a sub-type is only added to the RIM if it requires one or more attributes
or associations that are not inherited from its parents. Classes that represent distinct concepts, but which
need no further attributes or associations are represented solely as a unique code in the controlling vocabulary.
Therefore, these three classes include the following coded attributes, which serve to further define the
concept being modeled:
• classCode (in Act, Entity and Role) represents the exact class or concept intended, whether or not that
class is represented as a class in the RIM hierarchy;
• moodCode (in Act) and determinerCode (in Entity) an attribute that distinguishes whether the class
represents an instance or a kind of Act or Entity. If the class is a specialization of Act then moodCode
further delineates the instance as an occurrence or an intent;
• code (in Act, Entity and Role) provides for further classification within a particular classCode value,
such as a particular type of observation within the Observation class.
The other three RIM back-bone classes -- Participation, ActRelationship and RoleLink -- are not represented
by generalization-specialization hierarchies. Nevertheless, these classes represent a variety of concepts,
such as different forms of participation or different kinds of relationships between acts. These distinctions
are represented by a typeCode attribute that is asserted for each of these classes.
8 © ISO/HL7 2006 - All rights reserved

5 INTERPRETATION OF THE SPECIFICATION ISO 21731:2006(E) & ANSI/HL7 RIM R1-2003
5.2.2 Representation of RIM class structure
As noted previously, the RIM is modeled using a subset of the semantics embodied in UML. The RIM is a
set of UML classes, each containing one or more attributes, which are assigned a data type based on an
independent specification of data types. The classes are linked either by a set of association relationships,
identified by unique role names, or by generalization relationships.
Each of these elements includes a textual definition. The appearance of attributes and associations is
controlled by cardinality and related constraints applied to the attributes and to the roles that link the
associations to the classes.
5.2.3 Representation of controlling vocabulary
Several of the attributes in the RIM are coded with the CS data type, which means that the value set to be
used for those attributes must be drawn from the set of codes that have been defined by HL7. The classCode
and typeCode attributes mentioned above are examples of attributes with a CS data type.
All of the code sets for these attributes are included as part of this ballot and are subject to the same voting
principles as the classes in the RIM. Each code set is represented as a vocabulary domain -- the set of all
concepts that can be taken as valid values in an instance of a coded field or attribute. It is important to note
that a vocabulary domain consists of a set of concepts, not a set of words or codes.
5.2.4 Related specifications
As noted above, each attribute in the RIM is assigned a data type. The formal specification for these data
types differs depending upon whether this model is being used within the context of HL7 or the context of
ISO TC215. For use in HL7, the normative specification for the datatypes is the "HL7 Data Types Abstract
Specification ((need current name)). Within the ISO TC215 framework, work-items to specify a relevant data
type specification are being advanced as ISO 22??xx??. In either case, an informative summary of the
relevant data type properties is included as Annex C.
5.3 Graphic Diagrams of the RIM
The classes in the Normative content of the RIM are represented in the following diagrams:
© ISO/HL7 2006 - All rights reserved 9

ISO 21731:2006(E) & ANSI/HL7 RIM R1-2003 5 INTERPRETATION OF THE SPECIFICATION
Figure 1: UML diagram of the classes in all subject areas.
10 © ISO/HL7 2006 - All rights reserved

5 INTERPRETATION OF THE SPECIFICATION ISO 21731:2006(E) & ANSI/HL7 RIM R1-2003
Figure 2: UML diagram of the classes in the Acts subject area.
© ISO/HL7 2006 - All rights reserved 11

ISO 21731:2006(E) & ANSI/HL7 RIM R1-2003 5 INTERPRETATION OF THE SPECIFICATION
Figure 3: UML diagram of the classes in the Entities subject area.
12 © ISO/HL7 2006 - All rights reserved

5 INTERPRETATION OF THE SPECIFICATION ISO 21731:2006(E) & ANSI/HL7 RIM R1-2003
Figure 4: UML diagram of the classes in the Roles subject area.
Figure 5: State-machine diagram for Act class.
© ISO/HL7 2006 - All rights reserved 13

ISO 21731:2006(E) & ANSI/HL7 RIM R1-2003 5 INTERPRETATION OF THE SPECIFICATION
Figure 6: State-machine diagram for Entity class.
Figure 7: State-machine diagram for ManagedParticipation class.
14 © ISO/HL7 2006 - All rights reserved

6 SUBJECT AREAS ISO 21731:2006(E) & ANSI/HL7 RIM R1-2003
Figure 8: State-machine diagram for Role class.
6 SUBJECT AREAS IN: HEALTH LEVEL SEVEN REFERENCE INFORMATION MODEL,
RELEASE 1
FoundationClasses
6.1 FoundationClasses (in base model)
This collection of classes and their associations represent the "normative" content of the HL7 RIM. The
content of this subject area has been balloted within HL7 as a normative document.
Link to a class diagram of this subject area.
• FoundationClasses contains subject areas:
Acts Entities Roles
6.1.1 Acts (in FoundationClasses)
A collection of classes including the Act class and its specializations. These relate to the actions and events
that constitute health care services.
© ISO/HL7 2006 - All rights reserved 15

ISO 21731:2006(E) & ANSI/HL7 RIM R1-2003 7 CLASSES
Link to a class diagram of this subject area.
• Acts contains classes:
Account FinancialContract PatientEncounter
Act FinancialTransaction Procedure
ActRelationship InvoiceElement PublicHealthCase
DeviceTask ManagedParticipation SubstanceAdministration
DiagnosticImage Observation Supply
Diet Participation WorkingList
6.1.2 Entities (in FoundationClasses)
A collection of classes related to the Entity class, its specializations and related qualifying classes. The
classes represent health care stakeholders and other things of interest to health care.
Link to a class diagram of this subject area.
• Entities contains classes:
Container LivingSubject Organization
Device ManufacturedMaterial Person
Entity Material Place
LanguageCommunication NonPersonLivingSubject
6.1.3 Roles (in FoundationClasses)
A collection of classes related to the Role class and its specializations. These classes focus on the roles
participants may play in health care.
Link to a class diagram of this subject area.
• Roles contains classes:
Access LicensedEntity Role
Employee Patient RoleLink
7 Classes in: Health Level Seven Reference Information Model, Release 1
Each of the classes is listed below. The sort order is based on the following three criteria:
Normative Content first
1.
Primary subject area name, alphabetically
2.
Class name, alphabetically
3.
7.1 Classes in subject area Acts
7.1.1 Class: Act (in Acts)
• Class code: ACT
• Attributes of Act:
classCode :: CS statusCode :: SET interruptibleInd :: BL
moodCode :: CS effectiveTime :: GTS levelCode :: CE
id :: SET activityTime :: GTS independentInd :: BL
code :: CD availabilityTime :: TS uncertaintyCode :: CE
16 © ISO/HL7 2006 - All rights reserved

7 CLASSES ISO 21731:2006(E) & ANSI/HL7 RIM R1-2003
negationInd :: BL priorityCode :: SET reasonCode :: SET
derivationExpr :: ST confidentialityCode :: SET languageCode :: CE
text :: ED repeatNumber :: IVL
• Associations of Act:
outboundRelationship :: (0.*) ActRelationship :: source :: (1.1)
inboundRelationship :: (0.*) ActRelationship :: target :: (1.1)
participation :: (0.*) Participation :: act :: (1.1)
• Act generalizes:
Account InvoiceElement SubstanceAdministration
DeviceTask Observation Supply
FinancialContract PatientEncounter WorkingList
FinancialTransaction Procedure
Description of Act:
A record of something that is being done, has been done, can be done, or is intended or requested to be
done.
Examples: The kinds of acts that are common in health care are (1) a clinical observation, (2) an assessment
of health condition (such as problems and diagnoses), (3) healthcare goals, (4) treatment services (such
as medication, surgery, physical and psychological therapy), (5) assisting, monitoring or attending, (6)
training and education services to patients and their next of kin, (7) and notary services (such as advanced
directives or living will), (8) editing and maintaining documents, and many others.
Discussion and Rationale: Acts are the pivot of the RIM; all domain information and processes are
represented primarily in Acts. Any profession or business, including healthcare, is primarily constituted of
intentional actions, performed and recorded by responsible actors. An Act-instance is a record of such an
intentional action. Intentional actions are distinguished from something that happens by forces of nature
(natural events). Such natural events are not Acts by themselves, but may be recorded as observed
(Observation).
Acts connect to Entities in their Roles through Participations and connect to other Acts through
ActRelationships. Participations are the authors, performers and other responsible parties as well as subjects
and beneficiaries (which includes tools and material used in the performance of the act, which are also
subjects). The moodCode distinguishes between Acts that ar
...