HL7 RIM (extract)
Workflow in Healthcare - Extract from HL7 RIM.
From: Version: V 01-14 (3/9/2002) ModelID: RIM_0114
HL7 Version 3 Standard, Copyright Health Level Seven, Inc.© 2002. All Rights Reserved.
1.4 The Rationale Behind the RIM's Design
The overarching structure of the RIM is based on six "core" classes:
Act, Entity, Role, Participation, Act_relationship, and Role_link. Each
class is defined in Section 1.4. Following is a discussion of the
fundamental thinking behind, and basic usage guidelines for, the six
classes and their inter-relationships.
The HL7 RIM identifies two major "high-level" concepts that are
fundamental to understanding the world of healthcare information:
intentional "actions" or "services" (Acts), and "people, places and
things" that are of interest in the world of healthcare (Entities).
The concept "Act" (and its subclasses) represents all of the
intentional actions documented by a healthcare professional in either a
clinical or administrative context. The presence of the Act class as
one of the core RIM classes is a reflection of HL7's view that "from a
messaging/system communication perspective, healthcare consists of a
series of attributed, intentional actions."" Thus, instances of the
class/concept Act include both clinical observations (e.g. patient
temperature) and interventions (e.g. administer medication), and
administrative actions (e.g. admit patient). Note that in this
"act-centered" view of healthcare, the act of an observation takes on
two seemingly contradictory meanings: "the act of recognizing and
documenting a particular fact," and "the description of the thing
observed." In other words, an instance of an Observation Act represents
both the attributed act of observing and the results of the
observation. Both aspects of this expanded definition of an Observation
Act are captured by specific attributes of the class Act or its
The concept "Entity" (and its subclasses) includes all living subjects
(e.g. persons, animals), organizations (e.g. formal and informal),
materials (e.g. durable and non-durable goods, food, tissue,
containers,), and places that may be of interest in a healthcare
messaging context. It should be noted that the concept of "collection
of information" (e.g. a medical record) is not a instance or subclass
of Entity, but is instead considered as a collection of attributed
The RIM places two additional classes - Role and Participation -
between Act and Entity. The Role class models several important
concepts that are prevalent in the healthcare delivery domain. First,
Role captures the fact that the various "static" entities may
"temporally" assume one or more "roles" (e.g. patient, primary care
physician, responsible party, Registered Nurse etc.) in a particular
healthcare context. Second, the concepts of "capability" (e.g. Advanced
Cardiac Life Support) and "certification" (e.g. Licensed Practical
Nurse) are also modeled using instances of the Role class. Finally,
careful examination of the multiplicity (0..1) and names (is_scoped_by,
is_played_by) of the two associations between Entity and Role reveals
that the Role class can be used to "group" instances of Entity.
It is important to distinguish the concept of Entity-in-a-Role from the
Act-specific concept of "the function-based role played by an
Entity-in-a-Role in the context of a specific Act." These semantics are
modeled using instances of the Participation class. For example, an
Anesthesia Resident (Entity-in-a-Role) administers anesthesia
(Participation as "provider" in the Act "administer anesthesia") to a
patient (Participation as a 'recipient" in the Act "administer
anesthesia." Note that the absence of a direct association between the
Participation and Entity classes is a manifestation of an underlying
HL7 RIM assumption that all instances of Entity involved in an Act are
participating in the Act in a particular Role.
In summary, both the Participation and the Role classes are necessary
to fully model the complex semantics that exist between instances of
Entity and Act, and a concise summary of the HL7 RIM's view of
healthcare can be stated as follows: At the highest level of
abstraction, healthcare consists of a series of intentional, attributed
Acts performed to, by, on behalf of, utilizing or in some way involving
one or more instances of a Participating ("as primary provider," etc.)
Entity-in-a-Role ("John Smith in the role of Patient").
The two remaining classes in the RIM - Act_relationship and Role_link -
are used to "associate" or "link" instances of the class with which it
is associated. The class Role_link is used to establish a
"dependency-based link" (e.g. accountability, chain-of-trust, etc.)
between two instances of an Entity-in-a-Role. The semantics of
Act_relationship are explained below.
1.5 Linking Acts Together: The Semantics of Act_relationship
An understanding of the semantics and application of Act_relationship
begins with, an understanding of the "fractal" or "robotic arm" nature
of a set of Acts. This perspective is, in turn, best viewed from the
overarching framework of the categorization of three types of
"collecting relationships" represented by instances of
Act_relationship: whole/part (e.g. lab or test batteries (see the
discussion of the "robotic arm" below); rule-based (e.g. care plans,
protocols, etc.); and cognitive actions (e.g. judgment, renaming,
replacement, subsumption, supported by/reason for, etc.).
Regarding the "fractal" or "robotic arm" discussion, As mentioned
above, instances of Act_relationship can be used to model the "fractal"
or "robotic arm" notion behind a "whole/part" relationship. Consider a
surgical procedure such as a laparoscopic cholecystectomy. The
procedure may be represented as a single instance of Act, or,
alternatively, as a "collection" of (partially ordered) instances of
Act each of which is a finer granularity than the entire procedure,
e.g. obtain consent, administer pre-op medication, administer
anesthesia (throughout the surgical procedure), make the incision, etc.
In turn, for any of the more finely granulated actions just mentioned,
further granulation/decomposition may occur. The degree of granularity
is clearly dependent on the context of the action(s) and the interest
level/perspective of the party performing (or not performing) the
decomposition. Figure 1 shows a "surgeon's-eye view" of some of the
instances of Act and Act_relationship for the exemplar
cholecystectomy.. [Example of sequential plan construction for
laparoscopic cholecystectomy. Edged boxes are Act instances (all in
definition, or 'master' mood.) Rounded boxes are Act_relationship
instances of type: has-component. The sequence_nbr attribute orders the
relationships into a sequence. Each act can in turn be decomposed into
In summary, the classes Act and Act_relationship have been designed to
allow for representing the rich semantics of each of three types of
collections mentioned above at whatever coarseness or fineness of
granularity is appropriate to the specific messaging context. In
addition, the various of types of collections and levels of granularity
represented by instances of Act_relationship can (and will) be expected
to be used to collectively capture the complex semantics of clinical
reasoning, e.g. an instance of Act_relationship (e.g. "supported by")
could be used to form a link from an instance of an observation Act
representing a specific lab test (e.g. sedimentation rate = 48 to an
instance of an observation Act representing a particular diagnosis
(e.g. DX = Systemic Lupus Erythematosus).
1.6 Definitions of the Six Core Rim Classes
An Act is an action of interest that has happened, can happen, is
happening, is intended to happen, or is requested/demanded to happen.
An act is an intentional action in the business domain of HL7.
Healthcare (and any profession or business) is constituted of
intentional actions. An Act instance is a record of such an intentional
An Entity is a class or specific instance of a physical thing or an
organization/group of physical things capable of participating in Acts;
an artifact. This includes living subjects, organizations, material,
and places. The Entity hierarchy encompasses human beings,
organizations, living organisms, devices, pharmaceutical substances,
etc. It does not include events/acts/actions, the definition of things,
or the roles that things can play (e.g. patient, provider).
A Role is a categorization of competency of the Entity that plays the
Role as defined by the Entity that scopes the Role.
An Entity, in a particular Role, can participate in an Act. Note that a
particular entity in a particular role can participate in an act in
many ways. Thus, a Person in the role of a practitioner can participate
in a patient encounter as a rounding physician or as an attending
physician. The Role defines the competency of the Entity irrespective
of any Act, as opposed to Participation, which is limited to the scope
of an Act.
Each role is 'played' by one Entity (the Entity that is in the role)
and is usually 'scoped' by another. Thus the Role of 'patient' is
played by (usually) a person and scoped by the provider from whom the
patient will receive services. Similarly, the employer scopes an
A Participation is an association between a Role and an Act. The
Participation represents the involvement of the Entity playing the Role
with regard to the associated Act. A single Role may participate in
multiple Acts and a single Act may have multiple participating Roles. A
single Participation is always an association between a particular Role
and a particular Act. Participation is limited to the scope of the Act,
as opposed to Role, which defines the competency of an Entity
irrespective of any Act.
An Act_relationship is an association between a pair of Acts. This
includes Act to Act associations such as collector/component,
predecessor/successor, and cause/outcome.
The class has two associations to the Act class, one named "source" the
other named "target". .... Since the relationships associated with an
Act are considered properties of the source act object. That means that
the originator of the information reported in an act object is not only
responsible for the attribute values of that object, but also for all
its outgoing relationships.
The rule of attribution is that all act relationships are attributed to
the responsible actor of the Act at the source of the Act_relationship
(the "source act".)
A Role_link is a connection between two roles expressing a dependency
between those roles.
Extract from: Version: V 01-14 (3/9/2002) ModelID: RIM_0114
This site is currently hosted and kindly sponsored by
Montage Systems Pty. Ltd.