HL7 Reference Information Model
Version: V 01-14 (3/9/2002)
ModelID: RIM_0114
Modeling & Methodology Co-Chair |
George Beeler Jr PhD. Beeler Consulting LLC
|
Modeling & Methodology Co-Chair |
Jane Curry Sierra Systems & CIHI - HL7 Canada
|
Modeling & Methodology Co-Chair |
Abdul-Malik Shakir Shakir Consulting LLC
|
HL7 Version 3 Standard, Copyright Health Level Seven, Inc.© 2002. All Rights Reserved.
1 Introduction
1.1 Release notes
1.2 Purpose
1.3 Overview
1.4 The Rationale Behind the RIM's Design
1.5 Linking Acts Together: The Semantics of Act_relationship
1.6 Definitions of the Six Core Rim Classes
1.7 Data Types and Vocabulary Domains
1.8 HL7 Version 3 Methodology and the RIM
1.9 Graphic Diagrams of the RIM
2 Subject areas
2.1 RIM_Acts
2.1.1 RIM_Clinical_acts
2.1.2 RIM_Financial_acts
2.2 RIM_Communication_infrastructure
2.2.1 RIM_Message_control
2.2.2 RIM_Structured_documents
2.3 RIM_Entities
2.4 RIM_Roles
2.5 RIM_unassigned
3 Classes
3.1 Access
3.2 Account
3.3 Act
3.4 Act_context
3.5 Act_heir
3.6 Act_relationship
3.7 Assigned_entity
3.8 Certified_entity
3.9 Clinical_document
3.10 Container
3.11 Device
3.12 Device_task
3.13 Diagnostic_image
3.14 Diet
3.15 Employee
3.16 Entity
3.17 Entity_heir
3.18 Financial_act
3.19 Financial_contract
3.20 Financial_transaction
3.21 Guarantor
3.22 Imaging_modality
3.23 Invoice_element
3.24 Language_communication
3.25 Living_subject
3.26 Managed_participation
3.27 Manufactured_material
3.28 Material
3.29 Non_Person_living_subject
3.30 Observation
3.31 Organization
3.32 Participation
3.33 Patient
3.34 Patient_encounter
3.35 Person
3.36 Place
3.37 Procedure
3.38 Public_health_case
3.39 Referral
3.40 Relationship_link
3.41 Role
3.42 Role_heir
3.43 Schedulable_resource
3.44 Substance_administration
3.45 Supply
3.46 Working_list
3.47 Acknowledgement
3.48 Attention_line
3.49 Batch
3.50 Character_data
3.51 Communication_function
3.52 Context_structure
3.53 Control_event
3.54 Entry
3.55 Link
3.56 Link_html
3.57 Local_attr
3.58 Local_markup
3.59 Logical_expression
3.60 Message
3.61 Parameter
3.62 Parameter_item
3.63 Parameter_list
3.64 Query_ack
3.65 Query_by_parameter
3.66 Query_by_selection
3.67 Query_continuation
3.68 Query_event
3.69 Query_spec
3.70 Relational_expression
3.71 Selection_expression
3.72 Sort_control
3.73 Table
3.74 Table_cell
3.75 Table_column_structure
3.76 Table_structure
3.77 Transmission
4 Associations
4.1 (0..*)Acknowledgement :: acknowledges :: (1..1)Message :: is_acknowledged_by
4.2 (0..1)Acknowledgement :: occurs_with :: (1..1)Message :: has
4.3 (0..*)Act_context :: provides_context_for :: (1..*)Act :: originates_in_context_of
4.4 (0..*)Act_relationship :: has_source :: (1..1)Act :: is_source_for
4.5 (0..*)Act_relationship :: has_target :: (1..1)Act :: is_target_for
4.6 (0..*)Attention_line :: can_accompany :: (1..1)Transmission :: can_include
4.7 (0..1)Batch :: contains :: (0..*)Transmission :: is_contained_by
4.8 (0..1)Control_event :: is_communicated_as :: (0..*)Message :: has_payload
4.9 (1..1)Entity :: communicates_with :: (0..*)Language_communication :: used_by
4.10 (1..*)Entity :: serves :: (0..*)Communication_function :: served_by
4.11 (0..1)Entry :: contains :: (0..*)Entry :: is_contained_in
4.12 (0..*)Entry :: is_contained_in :: (0..1)Context_structure :: contains
4.13 (0..*)Parameter :: is_parameter_of :: (0..1)Query_by_parameter :: has
4.14 (0..1)Parameter_list :: may_contain :: (0..*)Parameter :: is_part_of
4.15 (0..*)Participation :: for :: (1..1)Act :: has
4.16 (0..*)Participation :: has_as_participant :: (1..1)Role :: participates_in
4.17 (0..1)Query_event :: occurs_with :: (1..1)Control_event :: may_have
4.18 (0..*)Relationship_link :: has_source :: (1..1)Role :: is_source_for
4.19 (0..*)Relationship_link :: has_target :: (1..1)Role :: is_target_for
4.20 (0..*)Role :: is_played_by :: (0..1)Entity :: plays
4.21 (0..*)Role :: is_scoped_by :: (0..1)Entity :: scopes
4.22 (1..1)Selection_expression :: has_left_side :: (0..*)Logical_expression :: is_lhs_for
4.23 (1..1)Selection_expression :: has_right_side :: (0..*)Logical_expression :: is_rhs_for
4.24 (0..*)Selection_expression :: is_for :: (1..1)Query_by_selection :: has_expression
4.25 (0..*)Sort_control :: is_for :: (1..1)Query_spec :: has
4.26 (1..*)Transmission :: executed_by :: (0..*)Communication_function :: executes
This version of the RIM reflects changes to the RIM approved during the March 2002 RIM Harmonization Meeting in Alpharetta,
GA. This version will be published as part of the second committee-level ballot of Version 3, and is the basis for the designs
therein.
Question should be addressed to the co-chairs of the Methodology and Modeling Committee and/or sent to the M&M e-mail list
at mnm@lists.hl7.org
This document is meant to serve as an "Executive Summary" of the basic concepts and rationale behind the design and development
of the HL7 Reference Information Model (RIM). It is not meant to be an "application guide" on RIM usage although several
partial examples of usage are presented when they are deemed helpful in explaining the fundamental design and development
concepts of the RIM.
A Reference Information Model (RIM) is constructed to facilitate consistent sharing and usage of data across multiple "local"
contexts. In general, the broader the scope of interest, the more important it is to make explicit all assumptions about a
topic or domain-of-interest. The HL7 Version 3 RIM is designed to provide a unified framework for, and to serve as a comprehensive
source of, all information used by an HL7 Specification . The RIM specifically and unambiguously articulates both the explicit
definitions of healthcare concepts - the "things of interest" to the world of healthcare information systems - and the relationships
(aka "associations") between these concepts-of-interest.
HL7 V3 Specifications (e.g. HL7 V3 messages, structured documents, etc.) permit loosely-coupled information systems to interoperate
(i.e. exchange data) in a variety of healthcare delivery contexts including those found in disparate provider organizations,
perspectives, and jurisdictions. The scope of the HL7 RIM therefore includes all of the information that is required to be
sent between, and processed by, participating healthcare information systems. In addition, it should be noted that the RIM
does not model (nor need to model) information stored by a given healthcare information system but never transmitted to another
system.
The RIM is expressed using a visual modeling syntax based on the Unified Modeling Language (UML). (Specific variances between
"standard UML" and "HL7 UML" as manifest in the RIM, such as the placement of association names, are currently under review
by the HL7 Modeling and Methodology Technical Committee with the goal of moving to a maximum alignment between the two syntaxes.)
HL7 also maintains a database ("RIM repository") containing the details of each RIM concept, attribute, and association
including the item's rationale, definition, constraints, and edit/change history. At some point in the future, any or all
of this information may be formally published in an HL7-specific UML profile.
It is important to note that the RIM is not intended to be a logical or physical model of a database, a design for a particular
vendor's information system, or a perspective focused on a particular healthcare organization or enterprise. In fact, the
RIM is not intended to represent a particular set of HL7 messages, but rather the collective universe of data and relationships
from which any relevant HL7 message could be constructed. Specific users of the RIM are expected to utilize relevant portions
of the RIM as needed, adopting its content to their own information modeling needs and notations.
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 subclass Observation.
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 Acts.
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.
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..

Figure
1: 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 plan-components.
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).
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 action.
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 Employee role.
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.
Entity, Act and Role are "high-level" classes, although they are not "abstract" classes in the formal sense (i.e. meaningful
instances of both classes are quite common). As a result, it has been necessary to define a number of more specialized subclasses
of these three classes to specify the additional data (class attributes) required in more specific contexts (e.g. the Observation
subclass of Act and the Living Subject and Material subclasses of Entity). . Attributes of a subclass must be both useful
and unique to that subclass. Subclasses inherit all of the attributes of their parent superclass.
There are meaningful subclasses in each of these hierarchies that do not require additional attributes, and therefore are
not represented as classes in the RIM. The "class_cd" attribute in each of these hierarchies specifies which class is represented.
The code set that can be used with the "class_cd" attributes are tightly controlled by HL7. A second attribute in each hierarchy,
the "cd" attribute provides a further classification of subtypes of each subclass.
The Act class represents intentional actions. These actions can exist in different "moods". Moods describe activities as
they progress in the business cycle, from defined, through planned and ordered to complete. The mood of an Act is specified
by the value of the Act.mood_cd attribute.
Any instance of an Act assumes one and only one mood and will not change its mood along its life cycle. The moods - definition,
intent, order, event - seem to specify a life cycle of an activity. However, the participants in the activity in these different
moods are different, as is the data. Therefore, the mood of an Act instance is static. The progression actualization (i.e.,
the progression from defined, through planned and ordered, to being performed) is called the "business cycle" to distinguish
it from the "life cycle" of a single act instance. Related Act instances that form such a "business cycle" are linked through
the Act_relationship class.
The RIM class, attribute and association definitions provide detail about logical meaning, but a full specification requires
data types and domains. Data Types define the allowable values of attributes and what these values "mean." Data types are therefore the fundamental building
blocks that shape (and constrain) all the semantics that can ultimately expressed in the RIM. Data types are represented
in the RIM repository rendered in a style similar to that of the RIM. (It should be noted that this visual representation
of the RIM Data Types is not the normative form and is not entirely correct. The normative form can be found in the Data
Types Specification Part II).
Vocabulary Domains are also explicitly defined in the RIM repository. They document cross-reference and alternative representations among coding
systems, while keeping track of the logical concepts being expressed by each code. Each attribute of each class may only be
expressed using specific Data Types and Vocabulary Domains.
In summary, the primary motivation for the development of the RIM was the desire to clearly define the various data elements
and relationships that comprise the healthcare information space. A direct outgrowth of this knowledge explication exercise
is the ability to reuse the same concept in multiple healthcare messages. The complete process of defining a message is defined
and discussed in the V3 Guide and accompanying HL7 Message Definition Framework (MDF). The basic steps include definition
and documentation of the data interchange needs (e.g. a set of messages to support a particular clinical or administrative
process) via a Storyboard, the selection/restriction of the RIM to those classes and attributes needed to populate the given
message, and the subsequent application of additional constraints on number and possible values of each attribute.
Refer to the HL7 Version 3 Guide and MDF for further information.
The representations available for the RIM include a diagram for each of the high level subject areas, and a reference to the
full RIM "billboard" in a PDF file where 'zooming' is more readily supported. The available graphics follow:

Figure
2: Entity class hierarchy in HL7 RIM.

Figure
3: Role class hierarchy in HL7 RIM.

Figure
4: Complete Act class hierarchy in HL7 RIM

Figure
5: Clinical Act class hierarchy in HL7 RIM

Figure
6: Financial Act class hierarchy in HL7 RIM

Figure
7: Model of message control classes.

Figure
8: Model of structured documents classes..

Figure
9: The state-machine diagram for the Act class.

Figure
10: The state-machine diagram for the Entity class.

Figure
11: The state-machine diagram for the Managed_participation class.

Figure
12: The state-machine diagram for the Role class.
A collection of subject areas related to the Act class and its specializations. These relate to the actions and events that
constitute health care services.
- RIM_Acts contains subject areas:
A collection of classes related to the Act class and its specializations. These relate to the actions and events that constitute
clinical care services.
- RIM_Clinical_acts contains classes:
A collection of classes related to the Act class and its specializations. These classes focus on the administrative and financial
activities in health care.
- RIM_Financial_acts contains classes:
A collection of subject areas that define the technical infrastructure of HL7, including messaging, structured documents and
components.
- RIM_Communication_infrastructure contains subject areas:
A collection of classes related to the technical definition and control of message-based communication in HL7.
- RIM_Message_control contains classes:
A collection of classes related to the definition of document-based communication in HL7, as represented by the Clinical Document
Architecture standards.
- RIM_Structured_documents contains classes:
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.
- RIM_Entities contains classes:
A collection of classes related to the Role class and its specializations. These classes focus on the roles participants may
play in health care.
- RIM_Roles contains classes:
- RIM_unassigned contains no classes
- Access
is a specialization of:
Role
Description of Access:
A role played by a device when the device is used to administer therapeutic agents (medication and vital elements) into the
body, or to drain material (e.g., exudates, pus, urine, air, blood) out of the body. For the most part, anything that would
be used for access would be a device (something specifically manufactured or created to serve that purpose). Typically the
device is a catheter or cannula inserted into a compartment of the body.
A device enters the body from an anatomic site designated by the approach_site_cd. The body compartment into which material
is administered or from which it is drained is designated by the target_site_cd.
Note that the Access role primarily exists in order to describe material actually deployed as an access, and not so much
the fresh material as it comes from the manufacturer. For example, in supply ordering a box of catheters from a distributor,
it is not necessary to use the Access role class, since the material attributes will usually suffice to describe and identify
the product for the order. But the Access role is used to communicate about the maintenance, intake/outflow, and due replacement
of tubes and drains.
Devices in the role of an Access are typically used in intake/outflow observations, and in medication routing instructions.
Microbiologic observations on the material itself or on fluids coming out of a drain, are also common.
Attributes of Access:
Attribute description:
Specifies the anatomic site where the line or drain first enters the body. For example in a arteria pulmonalis catheter
targets a pulmonary artery but the access approach site is typically the vena carotis interna at the neck, or the vena subclavia
at the fossa subclavia.
The coding system is the same as for Procedure.access_site_cd., indeed the Access.approach_site_cd has been copied from the
Procedure class into the Access role class. The value of the Access.approach_site_cd should be identical to the value of the
Procedure.approach_site_cd of an associated access placement procedure. This attribute is used if such an associated access
placement procedure is not communicated. Since accesses are typically placed for a considerable period of time and since
the access is used as a resource of many acts, the access approach site becomes an important identifying attribute of the
access itself.
Attribute description:
This is the target site of the access, i.e., the compartment into which material is administered or from which it is collected.
For example, a pulmonary artery catheter will have the target site arteria pulmonalis with or without a known laterality.
For environmental testing this could be the incubation chamber or the cooling tower or the overflow reservoir, etc.
The coding system is the same as for Procedure.target_site_cd; indeed the Access.target_site_cd has been copied from the Procedure
class into the Access role class. The value of the Access.target_site_cd should be identical to the value of the Procedure.target_site_cd
of an associated access placement procedure. This attribute is used if such an associated access placement procedure is not
communicated. Since accesses are typically placed for a considerable period of time and since the access is used as a resource
of many acts, the target site becomes an important identifying attribute of the access itself. The target site is an important
information that determines what kinds of substances may or may not administered (e.g., special care to avoid medication injections
into an arterial access.)
Vocabulary domain:
()
Attribute description:
The gauge of an access is a measure for the inner diameter of the tube (the lumen.) Typically catheter gauge is measured
in terms of units not seen elsewhere. Those units are defined in the Unified Code for Units of Measure.
Description of Account:
A sub-class of Act representing a financial account established to track the net result of financial acts. Can be used to
represent the accumulated total of billable amounts for goods or services received, payments made for goods or services, and
debit and credit accounts between which financial transactions flow.
Attributes of Account:
Vocabulary domain:
()
Attribute description:
The descriptive name of the account as carried in the ledger of which the account is a part.
Vocabulary domain:
Currency
(CWE)
Attribute description:
Indicates the currency that the account is managed in.
Vocabulary domain:
()
Attribute description:
A ratio that indicates the rate of interest that the account balance is subject to, and the term over which the interest rate
compounds.
Constraint: Unit of the denominator PQ datatype must be comparable to seconds. (I.e. the denominator must be measured in
time.)
Vocabulary domain:
()
Attribute description:
An interval describing the minimum and maximum allowed balances for an account.
- Act
is a specialization of:
Description of Act:
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 action.
Any intentional action can exist in different "moods". Moods describe activities as they progress in the business cycle,
from defined, through planned and ordered to complete.
Any instance of an Act assumes one and only one mood and will not change its mood along its life cycle. The moods - definition,
intent, order, event - seem to specify a life cycle of an activity. However, the participants in the activity in these different
moods are different, as is the data. Therefore, the mood of an Act instance is static. The progression actualization (i.e.,
the progression from defined, through planned and ordered, to being performed) is called the "business cycle" to distinguish
it from the "life cycle" of a single act instance. Related Act instances that form such a "business cycle" are linked through
the Act_relationship class.
Examples for acts in health care are: a clinical test, an assessment of health condition (such as problems and diagnoses),
the setting of healthcare goals, the performance of treatment services (such as medication, surgery, physical and psychological
therapy), assisting, monitoring or attending, training and education services to patients and their next of kin, and notary
services (such as advanced directives or living will).
Acts have participants, which can be actors or targets. Examples of actors are nurses, doctors, family members, notary publics,
and service organizations -- every person or organization that is capable of independent decisions and can thus is responsible
(and liable) for the actions performed.
Target participants in an act may include the patient, the patient's spouse, family, or community, a specimen drawn from the
patient or from any object of interest. As patients do play active roles in their own healthcare, the patient can be both
an active participant and a target participant at the same time (self-administered or reflexive services.)
An act can have multiple active participants and multiple target participants, their specific role being distinguished in
the "type_cd" of the respective instance of the Participation class. In particular, an act involving coordination of care
may involve two or more active participants -- playing different roles -- who interact on behalf of a patient, family, or
aggregate in the role of target participant. For example, a nurse (active participant) calls Meals on Wheels (active participant)
on behalf of the patient (target participant).
An act includes the "results", "answers" or informational "procedure products" gained during the act. In this model, "results"
do not exist without an act, and every clinical result, including those results gained accidentally, is gleaned via an act.
In other moods, such as "definition " or "intent", the results are the possible results, the expected or aimed-for results,
or the tested-for results.
Attributes of Act:
Attribute description:
A code specifying the class or category of Acts that the specific Act represents. The code indicates which class in the Act
hierarchy is represented by any instance of Act.
Attribute description:
A code specifying whether the Act is an activity that has happened, can happen, is happening, is intended to happen, or is
requested/demanded to happen.
Webster's dictionary defines mood of a verb as a "distinction of form ... of a verb to express whether the action or state
it denotes is conceived as fact or in some other manner (as command, possibility, or wish)". This definition of mood is applied
directly activities in health care where the action may be conceived as an event that happened (fact), an ordered act (command),
a possible act (master file), or a goal (wish).
Vocabulary domain:
()
Attribute description:
A unique identifier for the Act.
Attribute description:
A code specifying which particular kind of Act that the Act represents within its class.
The kind of Act (e.g. physical examination, serum potassium, patient encounter, financial transaction, etc.)is specified with
a code from one of several, typically external, coding systems. The coding system will depend on the class of Act, such as
LOINC for observations, perhaps SNOMED for procedures, etc.
Vocabulary domain:
()
Attribute description:
An indicator specifying that the Act is a negation of the Act event specified by Act.class_cd and Act.cd.
For example when used with Act.class_cd "Observation" it allows one to say "patient has no chest pain". In criterion mood
it negates the criterion analogously, e.g., "if systolic blood pressure is not within 90-100 mmHg then alert me."
Vocabulary domain:
()
Attribute description:
A textual or multimedia description of the Act.
There is no restriction on length or content imposed on the Act.txt attribute. The content of the description is not considered
part of the functional information communicated between systems. Free text descriptions are used to help an individual interpret
the content and context of the act. All information relevant for automated functions must be communicated using the proper
attributes and associated objects.
As with any attribute of the Act class, the meaning of the Act.txt attribute is subject to the Act.mood_cd. For act definitions,
the description can contain textbook-like information about that act. For act orders, the description will contain particular
instructions pertaining only to that order. Filler order systems must show the description field to a performing provider.
Attribute description:
A code specifying the state of the Act.
Vocabulary domain:
()
Attribute description:
A time expression specifying the focal or operative time of the Act
This is the time at which the action focuses. It is also known as the "primary" time (Arden Syntax) or the "biologically relevant
time" (HL7 v2.x). This attribute is distinguished from activity time. For observations, the time of the observation activity
may be much later than the time of the observed feature. For instance, in a Blood Gas Analysis (BGA), a result will always
come up several minutes after the specimen was taken, meanwhile the patient's physiological state may have changed significantly.
For surgical procedures the time between first cut and last suture is taken as the effective time of the procedure. For transport
and supply acts the effective time is the time en route or time of delivery respectively (discounting the travel time to the
pick-up location and from the drop-off location.) For administrative acts, such as patient encounters, this is the "administrative"
time, i.e., the encounter start and end date required to be chosen by business rules, as opposed to the actual time the healthcare
encounter related work is performed (which would be the activity_time.)
Vocabulary domain:
()
Attribute description:
A time expression specifying the occasion time or time of happening for the Act.
This is the time when the action happened, is ordered or scheduled to happen, or when it can possibly happen (depending on
the mood of the Act).
When used with procedures and other events, this is the total time of activity including preparation and clean-up actions.
Thus it may be longer than the effective time of the same act, which is the period during which the procedure actually takes
place.
Vocabulary domain:
()
Attribute description:
A time expression specifying the point in time at which information about Act first became available.
For HL7 messaging, the Act.availability_time will be set according to the sender system.
The Act.availability_time is an inert attribute with respect to the mood code. This means, it is the recording time of the
act object regardless of its mood.
Rationale: A database that records a separate time stamp for both valid time and transaction time is called a bi-temporal
database. Bi-temporal databases allow reconstructing at any time what users of the database actually could have known, versus
what the state of the world was at that time. For example, one might record that a patient had a right-ventricular myocardial
infarction effective three hours ago, but we may only know about this unusual condition a few minutes ago. Thus, any interventions
from three hours ago until a few minutes ago may have assumed a usual left-ventricular infarction, which can explain why these
interventions may not have been appropriate in light of the more recent knowledge about the prior state. However, the transaction
time (or recording time) may vary from system to system.
Vocabulary domain:
ActPriority
(CWE)
Attribute description:
A code or set of codes specifying the urgency under which the Act happened, can happen, is happening, is intended to happen,
or is requested/demanded to happen.
This attribute is used in orders to indicate the ordered priority, and in event documentation it indicates the actual priority
used to perform the act. In definition mood it indicates the available priorities.
Attribute description:
A code specifying limits regarding the disclosure of information about Act.
It is important to note that good confidentiality of the medical record cannot be achieved solely through confidentiality
codes to mask individual record items from certain types of users.
Aggregations of data should assume the privacy level of the most private action in the aggregation.
Vocabulary domain:
()
Attribute description:
An interval of integer numbers stating the minimal and maximal number of repetitions of the Act.
The number of repeats is additionally constrained by time. The act will repeat at least the minimal number times and at most,
the maximal number of times. Repetitions will also terminate when the time exceeds the maximal Act.effective_time, whichever
comes first.
Vocabulary domain:
()
Attribute description:
An indicator specifying whether Act is interruptible by other, asynchronous Acts
Vocabulary domain:
()
Attribute description:
Indicates that all acts connected through context-conductive links should not be independently removed from the context of
this act.
Vocabulary domain:
()
Attribute description:
An indicator specifying whether the Act can occur independently of other Acts.
Some acts can only be manipulated as subordinate to a composite act. Others are abstractions of acts or inseparable act groups
that should only be manipulated together. This attribute is true by default.
Attribute description:
A code specifying the motivation, cause, or rationale for non-clinical actions represented by Act.
Attribute description:
The language used in documenting the Act.
-
Attributes of Act_context:
- Act_context
is a specialization of:
Act
Description of Act_context:
The Act_context is a specialization of an Act that explicitly contains a set of other Acts that share the same context. The
"context" of an act is defined as the attribution ascribed to its containing Act_context.
Attributes of Act_context:
Vocabulary domain:
ActContextLevel
(CWE)
Attribute description:
The nature or level of the contextual containment that this Act_context provides for the Acts it contains.
- Act_heir
is a specialization of:
Act
Description of Act_heir:
Rationale: It has been discovered that one cannot create an HMD choice structure for a set of classes, all of which are sub-types
of Act, Role or Entity, but for which there is not a defined physical class. These are the classes that would have been in
the RIM as direct descendants (heirs) of Act, Role and Entity, except for the fact that they carried no unique attributes
or associations.
The addition of this single empty class in each hierarchy will permit messages with the appropriate and necessary choice structures
to be built. Subsequent evolution of the methodology and tooling may permit the elimination of these classes in favor of
an equivalent abstraction in the methodology.
-
Attributes of Act_relationship:
- Act_relationship
is a specialization of:
Description of Act_relationship:
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". Consider every Act_relationship
instance an arrow with a point (headed to the target) and a butt (coming from the source.) For each relationship type, the
functions (or roles) of source and target Act are different. In principle the assignment of functions (roles) to each side
of the relationship "arrow" is completely arbitrary. 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".)
With this recursive act relationship one can group actions into "batteries," e.g., LYTES, CHEM12, or CBC, where multiple routine
laboratory tests are ordered as a group. Some groupings, such as CHEM12, appear more arbitrary; others, such as blood pressure,
seem to naturally consist of systolic and diastolic pressure.
Acts may also be grouped longitudinally, in a sequence of sub-actions to form temporal and conditional (non-temporal) action
paths (e.g., care plan, critical path, clinical trials, drug treatment protocols).
Acts may be explicitly timed, and may be conditioned on the status or outcome of previous actions. Concurrent collections
of acts allow expressing logical branches as well as parallel tasks (tasks carried out at the same time.) These constructs
can be organized in multiple layers of nesting, to fully support workflow management.
The Act_relationship class is not only used to construct action plans but also to represent clinical reasoning or judgments
about action relationships. Prior actions can be linked as the reasons for more recent actions. Supporting evidence can be
linked with current clinical hypotheses. Problem lists and other networks of related judgments about clinical events are represented
by the Act_relationship link.
The Act_relationship.type_cd identifies the meaning and purpose of every Act_relationship instance.
Attributes of Act_relationship:
Attribute description:
A code specifying the meaning and purpose of every Act_relationship instance. Each of its values implies specific constraints
to what kinds of Act objects can be related and in which way.
Vocabulary domain:
()
Attribute description:
An indicator specifying that the Act_Relationship.type_cd should be interpreted as if the roles of the source and target Acts
were reversed.
The inversion indicator is used when the meaning of Act_relationship_type_cd must be reversed. For example, we define a relationship
type reason to express the reason for an action as in:
a) "A cholecystectomy was performed because of symptomatic cholelithiasis without signs for cholecystitis." (cholecystectomy
has-reason cholelithiasis)
This statement of rationale is attributed to the responsible performer of the cholecystectomy. Now consider the following
statement:
b) "The finding of symptomatic gall stones (cholelithiasis) with no signs of acute cholecystitis suggests a cholecystectomy."
While sentence a) declares a reason for an action, sentence b) suggests an action. Reason and suggestion links are reciprocal,
i.e., if X has-reason Y, then Y suggests X. The second statement would have been made by the originator of the cholelithiasis
finding.
In the "network" of interrelated acts, we need to make sure that we do not lose proper attribution of statements to originators
("who said what?") Since attribution is so important, we adopt a very simple rule for it: an act relationship is always attributed
to the originator of the source Act. No exceptions to this rule are permitted whatsoever. If attribution needs to be different
one can invert the relationship type by setting the inversion_ind attribute to "true".
If the inversion indicator is "true", source and target act swap their roles; that is, the reason and the suggested action
swap their roles, so that cholecystectomy can be the source and cholelithiasis can be the target. Note that the attribution
rule is always unchanged; i.e., the act relationship is always attributed to the responsible author of the source act, no
matter what the inversion_ind value is.
Vocabulary domain:
ActRelationshipContextControl
(CNE)
Attribute description:
A code that specifies if this act relationship is conductive to inherited participations and relationships or if it can itself
be inherited.
Act relationships and participations that are marked inheritable can be inherited along act-relationships that are marked
conductive. Conductance of inheritable objects is transitive and unidirectional from source to target. The total of all inheritable
objects along an uninterrupted chain of conductive links leading back from a target act towards the source of act relationships
is called the inherited context of that act. All inherited context is lost at an act relationship marked non-conductive. Context
inheritance can be additive (I) or overriding (IOS). Additive inheritance adds new objects into the inherited context while
overriding inheritance replaces inherited objects of the same or more specific type/class with this inherited object.
Example 1: An observation event has a patient participation marked inheritable and has component observation events linked
through act relationships that are marked conductive. This means that the patient participation is a patient participation
of those component observation events.
Example 2: A composite order has a patient participation, an author participation, and a reason relationship to a diagnosis,
all marked as inheritable. The order further has several detail orders as components, with the components marked as conductive.
The patient, author, and reason of the component orders are the same as for the composite order.
Vocabulary domain:
()
Attribute description:
An integer specifying the relative order of the Act_Relationship in relation to other Act_Relationships having the same associated
source Act.
It is used to represent sequences of actions in execution plans. The ordering may be total, if each sequence number in a set
is unique, or partial, if specific sequence numbers are repeated.
Vocabulary domain:
()
Attribute description:
An integer specifying the relative primacy of the Act_Relationship to other Act_Relationships having the same associated source
Act.
It is used to represent the priority ordering of conditional branches in act execution plans, or priority ranking in pre-condition,
outcome or support links, and preferences among options. The ordering may be total in which all priority numbers are unique,
or partial if specific priority values repeat.
Vocabulary domain:
()
Attribute description:
A specification of a quantity of time that should elapse between the clearance for execution of an Act and the actual beginning
of execution.
Any entering pre-conditions are tested before the slot is entered, so the pause specifies a minimal waiting time before the
act is executed after its pre-conditions become true.
Attribute description:
A code specifying when in the course of an Act a guard condition or pre-condition for the Act is evaluated.
Attribute description:
A code specifying how branches are selected for execution when an activity plan has a branch.
Attribute description:
A code specifying how concurrent Acts are resynchronized in a parallel branch construct.
This attribute has its principle use in specifying care plans. A kill branch will only be executed if there is at least one
active wait (or exclusive wait) branch. If there is no other wait branch active, a kill branch is not started at all (rather
than being discontinued shortly after it is started.) A detached branch will be unrelated to all other branches, thus a kill
branch will be discontinued no matter whether there are detached branches still running.
Vocabulary domain:
()
Attribute description:
An indicator used in Act_relationships that are condition or criterion links. The indicator asserts that the meaning of the
link is negated.
For conditions and criteria links, indicates whether the meaning is negative (condition must not be true.) Normally all conditions
are interpreted as affirmative, i.e., the condition must be true. The negation_ind is part of the condition so that the Boolean
outcome of the condition XOR-ed with the negation_ind of the condition link must be true. Thus, if the negation_ind is "true",
we say the "condition is true", even if the test was negative.
Attribute description:
A code specifying the logical conjunction of the criteria in a pair of precondition or outcome Acts.
-
Attributes of Assigned_entity:
- Assigned_entity
is a specialization of:
Role
Description of Assigned_entity:
An agent role in which the agent is an Entity acting in the employ of an organization. The focus is on functional role on
behalf of the organization, unlike the Employee role where the focus is on the 'Human Resources' relationship between the
employee and the organization.
Attributes of Assigned_entity:
Vocabulary domain:
PractitionerPosition
(CWE)
Vocabulary domain:
()
Attribute description:
An indication that the healthcare practitioner is a primary care provider.
-
Attributes of Certified_entity:
- Certified_entity
is a specialization of:
Role
Description of Certified_entity:
A relationship in which the scoper certifies the players ability to perform a specific task. The certification may imply
legal capacity, or an evaluated capability for the performance of that task. Examples include the certification of equipment,
as well as the granting of license or certificates to organizations or professionals.
Attributes of Certified_entity:
Vocabulary domain:
()
Attribute description:
The date recertification is required.
-
Attributes of Clinical_document:
Description of Clinical_document:
Specialization of Act to add the characteristics unique to document management services.
Attributes of Clinical_document:
Vocabulary domain:
()
Attribute description:
A report identifier that remains constant across all document revisions that derive from a common original document. An original
report is the first version of a report. It gets a new unique value for document_service.set_id, and has the value of document_service.version_nbr
set to equal "1". An addendum is an appendage to an existing report that contains supplemental information The appendage is
itself an original report. The parent report being appended is referenced via an act_relationsip, with act_relationship.type_cd
set to equal "APND" (for "appends"). The parent report being appended remains in place and its content and status are unaltered.
A replacemnt report replaces an existing report. The replacement report uses the same value for document_service.set_id as
the parent report being replaced, and increments the value of document_serivce.version_nbr by 1. The state of the parent report
being replaced should become "superceded" explicitly by another message, but is still retained in the system for historical
reference.
Vocabulary domain:
()
Attribute description:
Version number is an integer starting at '1' and incrementing by 1. The first instance or original report should always be
valued as '1'. The version number value must be incremented by one when a report is replaced, but can also be incremented
more often to meet local requirements.
Attribute description:
A code depicting the completion status of a report (e.g., incomplete, authenticated, legally authenticated).
Attribute description:
A code depicting the storage status (e.g., active, archived, purged) of a report.
Vocabulary domain:
()
Attribute description:
Time a document is released (i.e., copied or sent to a display device) from a document management system that maintains revision
control over the document. Once valued, cannot be changed. Intent of this attribute is to give the viewer of the document
some notion as to how long the document has been out of the safe context of its document management system.
Description of Container:
A container is a manufactured material used to hold other things for purposes such as transportation or protection of contents
from loss or damage. With amorphic substances (liquids, gases) a container is required. However, the content of a container
is always distinguishable and relatively easily separable from the container, unlike the content (ingredient) of a mixture.
A container is related to a content material through Role_relationship.type_cd = "has content".
Rationale: The specifications for this class arose from the collaboration between HL7 and the NCCLS. Many of the attribute
definitions are drawn from or reference the NCCLS standard.
Attributes of Container:
Vocabulary domain:
()
Attribute description:
The capacity of the container in the units specified.
Vocabulary domain:
()
Attribute description:
The height of the container in units specified.
Vocabulary domain:
()
Attribute description:
The outside diameter of the container in units specified.
Attribute description:
The type of cap that is to be used with the container for decapping, piercing or other mechanisms.
Attribute description:
A material such as a gel that is contained in blood collection tubes to facilitate separation of blood cells from blood serum
by creating a physical "barrier" between them.
Vocabulary domain:
()
Attribute description:
The distance from the Point of Reference to the separator material (barrier) within the container. This distance may be provided
by the LAS to the instrument and/or specimen processing/handling device to facilitate the insertion of a sampling probe into
the specimen without touching the separator. See the Point of Reference definition or in NCCLS standard AUTO5 Laboratory Automation:
Electromechanical Interfaces.
Vocabulary domain:
()
Attribute description:
The distance from the Point of Reference to the outside bottom of the container in units specified below. Refer to Point of
Reference definition in section Glossary or in NCCLS standard AUTO5 Laboratory Automation: Electromechanical Interfaces.
Description of Device:
A device is anything used in an activity without being substantially changed through that activity. This includes durable
(reusable) medical equipment as well as disposable equipment. The kind of device is identified by the Entity.cd.
Attributes of Device:
Vocabulary domain:
()
Attribute description:
Name of the version of this device as designated by the manufacturer.
Vocabulary domain:
()
Attribute description:
Name, version and release of the software that operates the device.
Attribute description:
The current state of control associated with the equipment. An equipment can either work autonomously (local_remote_control_state_cd="Local")
or it can be controlled by another system (local_remote_control_state_cd="Remote").
Attribute description:
This field identifies the current functional activity of the automated device. The value of alert_level_cd is determined by
the machine itself.
Vocabulary domain:
()
Attribute description:
Date of last calibration and/or inspection of the device.
-
Attributes of Device_task:
- Device_task
is a specialization of:
Act
Description of Device_task:
An activity of an automated system. Such activities are invoked either by an outside command or are scheduled and executed
spontaneously by the device (e.g., regular calibration or flushing.) The command to execute the task has mood_cd <= ORD; an
executed task (including a task in progress) has mood_cd <= EVN, an automatic task on the schedule has mood_cd <= INT.
Attributes of Device_task:
Vocabulary domain:
()
Attribute description:
The parameters of the task submitted to the device upon issuing of a command (or configuring the schedule of spontaneously
executed tasks.) Parameters are only specified here if they are not included in separate HL7 defined structure. The parameters
are a list of any data values interpreted by the device. The parameters should be typed with an appropriate HL7 data type
(e.g., codes for nominal settings, such as flags, REAL and INT for numbers, TS for points in time, PQ for dimensioned quantities,
etc.) However, besides this HL7 data typing, the functioning of the parameters is opaque to the HL7 standardization.
Rationale: Some parameters for tasks are uniquely defined by a specific model of equipment. Most critical arguments of a
task (e.g., container to operate on, positioning, timing, etc.) are specified in an HL7 standardized structure, and the parameter
list would not be used for those. The parameter list is used only for those parameters that cannot be standardized because
they are uniquely defined for a specific model of equipment.
-
Attributes of Diagnostic_image:
Description of Diagnostic_image:
Class for holding attributes unique to diagnostic images.
Attributes of Diagnostic_image:
Vocabulary domain:
ImagingSubjectOrientation
(CWE)
Attribute description:
Patient direction of the rows and columns of the image.
- Diet
is a specialization of:
Supply
Description of Diet:
Diet acts are supply acts, with some aspects resembling Substance_administration acts: the detail of the diet is given as
a description of the Material associated via Participation.type_cd="product". Medically relevant diet types may be communicated
in the Entity.cd, however, the detail of the food supplied and the various combinations of dishes should be communicated as
Material instances.
Attributes of Diet:
Vocabulary domain:
()
Attribute description:
This value indicates the supplied biologic energy (Calories) per day. This physical quantity should be convertible to 1 kcal/d
(or 1 kJ/d.) Note, that there is a lot of confusion about what is a "calorie." There is a "large Calorie" and a "small calorie."
On "nutrition facts" labels, the large "Calories" is used. More appropriately, however, one should use the small calorie,
which is 1/1000 of a large Calorie. In the Unified Code for Units of Measure, the proper unit symbol for the large calorie
is "[Cal]" and for the small calorie it is "cal", or, more commonly used as a kilo-calorie "kcal".
Vocabulary domain:
()
Attribute description:
For diabetes diet one typically restricts the amount of metabolized carbohydrates to a certain amount per day (e.g., 240 g/d).
This restriction can be communicated in the carbohydrate_qty.
- Employee
is a specialization of:
Role
Description of Employee:
A relationship between a person or organization and a person or organization formed for the purpose of exchanging work for
compensation. The purpose of the role is to identify the type of relationship the employee has to the employer, rather than
the nature of the work actually performed. (Contrast with Assigned_entity)
Attributes of Employee:
Vocabulary domain:
EmployeeJob
(CWE)
Attribute description:
A code describing the job performed by the employee for the employer. For example, accountant, programmer, banker.
Rationale: Represents the first component of the JCC data type (job Code)
Vocabulary domain:
()
Attribute description:
The title of the job held, for example, Vice President, Senior Technical Analyst.
Attribute description:
A code depicting the time-relative nature of the work performed by the employee for the employer. For example, full-time,
part time.
Rationale: The job class in v2.3 (second component of JCC data type) references Employee Classification table. The first
component of the JCC data type (job code) is represented in Person_employment.job_cd.
Vocabulary domain:
EmployeeSalaryType
(CWE)
Attribute description:
A code categorizing the calculation method used by the employer to compute the employee's salary. For example, hourly, annual,
commission.
Vocabulary domain:
()
Attribute description:
The salary amount paid by the employer to the employee.
Vocabulary domain:
()
Attribute description:
The type of hazards associated with the work performed by the employee for the employer. For example, asbestos, infectious
agents.
Vocabulary domain:
()
Attribute description:
Protective equipment needed for the job performed by the employee for the employer. For example, safety glasses, hard hat.
- Entity
is a specialization of:
Description of Entity:
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, or the roles that things can play (e.g. patient, provider).
Attributes of Entity:
Attribute description:
A code specifying the class or category of Entities that the specific Entity represents. The code indicates which class in
the Entity hierarchy is represented by any instance of Entity.
Attribute description:
A code specifying whether Entity represents a class of artifacts or a specific instance of an artifact.
Vocabulary domain:
()
Attribute description:
A unique identifier for the Entity.
Communication only requires that each entity might have a single identifier assigned to it. Nevertheless, , since different
systems will maintain different data bases, there may be different instance identifiers assigned by different systems. Note
that an instance identifier is a pure identifier and not a classifier. For Material, serial numbers assigned by specific
manufacturers, catalog numbers of specific distributors, or inventory numbers issued by owners, may also be represented by
the Role.id, which allows a more clear expression of the fact that such a code is assigned by a specific party associated
with that material.
Attribute description:
A code specifying which particular kind of Entity the Entity represents within its class
The values for this attribute are drawn from one of several coding systems depending on the class of entities, such as living
subjects (typed by animal and plant taxonomies), chemical substance (e.g., IUPAC code), organizations, insurance company,
government agency, hospital, park, lake, syringe, etc. Note that Entity.cd may be so fine grained that some types may only
have one known instance. Types with an extension of one instance are very similar to names. An example is the CDC vaccine
manufacturer code, which is modeled as a concept vocabulary, when in fact each concept refers to only one instance.
Vocabulary domain:
()
Attribute description:
Specifies the quantity of the given entity, as interpreted in coordination with the determiner_cd. For individual instances
of Entities, the qty is 1. For a group of individual members, the qty is the number of individual members in the group.
When the Entity instance is a portion of a substance, the qty specifies the amount of that substance comprised by that portion.
For an undetermined substance (kind) the qty servers two purposes at the same time: (a) it provides a means of relations between
quantities specific for that substance, and (b) it is a reference quantity for the specification of ingredients or components.
In all cases, the qty is an extensive "amount" kind of quantity (e.g., number, length, volume, mass, surface are, energy,
etc.) Note that most relative or fractional quantities are not amounts, in particular, mass fraction, substance concentration,
mass ratios, percentages, etc. are not extensive quantities and are prohibited values for this attribute.
With undetermined kinds, the qty is but a reference quantity for the specification of the proportion of ingredients or components
(e.g. through a has-part, has-ingredient, or has-content Role.) For example, a kind of group with 60% females is Person(qty
= 100) has-part Person(qty = 60; sex = female). Amoxicillin 500 mg per tablet is Material(Tablet, qty = 1) has-ingredient
Material(Amoxicillin, qty = 500 mg). Glucose 50% (D5W) is Material(D5W, qty = 1 kg) has-ingredient Material(Glucose, qty =
50 g).
Material-specific quantity relations are expressed using the fact that the data type of this attribute is a set of physical
quantity (SET<PQ>). If more than one qty value are specified in this set, each element in this set is considered to specify
the same amount of the material. For example, for one liter of water one could use the set 1 L, 1 kg, 55.56 mol to specify
the volume, mass, and amount of substance for the same amount of water, this is equivalent with specifying the mass density
(volumic mass 1 kg/L) and the molar mass (18 g/mol). For Glucose one could specify 180 g, 1 mol according to the molar mass
(180 g/mol).
Vocabulary domain:
()
Attribute description:
A name for the Entity instance.
Vocabulary domain:
()
Attribute description:
A textual or multimedia depiction of the Entity.
The content of the description is not considered part of the functional information communicated between systems. Descriptions
are meant to be shown to interested human individuals. All information relevant for automated functions must be communicated
using the proper attributes and associated objects.
Attribute description:
A code specifying the state of Entity.
Vocabulary domain:
()
Attribute description:
An interval of time specifying the period during which the artifact represented by Entity has, had, or will have physical
existence.
Vocabulary domain:
()
Attribute description:
A telecommunication address for the Entity.
Attribute description:
A code specifying the threat or hazard associated with the Entity.
Attribute description:
A code specifying special handling requirements for the artifact represented by Entity.
A code to describe how the Entity needs to be handled to avoid damage to it or other entities. Examples include: Keep at room
temperature; Keep frozen below 0 C; Keep in a dry environment; Keep upright, do not turn upside down.
Vocabulary domain:
()
Attribute description:
A textual description or multimedia depiction of the relative importance the artifact represented by Entity has to the owner
of the Entity.
- Entity_heir
is a specialization of:
Entity
Description of Entity_heir:
Rationale: It has been discovered that one cannot create an HMD choice structure for a set of classes, all of which are sub-types
of Act, Role or Entity, but for which there is not a defined physical class. These are the classes that would have been in
the RIM as direct descendants (heirs) of Act, Role and Entity, except for the fact that they carried no unique attributes
or associations.
The addition of this single empty class in each hierarchy will permit messages with the appropriate and necessary choice structures
to be built. Subsequent evolution of the methodology and tooling may permit the elimination of these classes in favor of
an equivalent abstraction in the methodology.
-
Attributes of Financial_act:
- Financial_act generalizes:
- Financial_act
is a specialization of:
Act
Description of Financial_act:
An act utilized primarily for administrative (versus clinical) purposes.
Attributes of Financial_act:
Vocabulary domain:
()
Attribute description:
The monetary value of a financial act after any applicable discounts and adjustments have been applied.
This attribute can be used to represent concepts that include the balance of a financial account, the value of a financial
transaction, and the value of an invoice line item or adjustment.
-
Attributes of Financial_contract:
- Financial_contract
is a specialization of:
Act
Description of Financial_contract:
A contract whose value is measured in monetary terms.
Attributes of Financial_contract:
Attribute description:
Establishes the payment terms for a contractual agreement or obligation. Examples are "net 30", "on receipt of invoice",
"upon completion of service", etc.
-
Attributes of Financial_transaction:
Description of Financial_transaction:
A sub-class of Act representing any transaction between two accounts whose value is measured in monetary terms.
In the "intent" mood, communicates a request for a transaction to be initiated, or communicates a transfer of value between
two accounts.
In the "event" mood, communicates the posting of a transaction to an account.
Attributes of Financial_transaction:
Vocabulary domain:
()
Attribute description:
A ratio indicating the rate of exchange in effect between the currency of the account being credited, and the currency of
the transaction value.
The numerator should be expressed as a quantity in the currency of the credit account, and the denominator should be expressed
as a quantity in the currency that the transaction is being reported in.
For example, for the purchase of services valued in Mexican pesos using U.S. dollars paid from a Canadian dollar account,
the credit exchange ratio would be communicated as the ratio (n CAD / n USD).
Rationale: this approach ensures that a common reporting mechanism is used, from the perspective of the value of the transaction,
which is used to communicate the value of the act.
Vocabulary domain:
()
Attribute description:
A ratio indicating the rate of exchange in effect between the currency of the account being debited, and the currency of the
transaction value.
The numerator should be expressed as a quantity in the currency of the debit account, and the denominator should be expressed
as a quantity in the currency that the transaction is being reported in.
For example, for the purchase of services valued in Mexican pesos using U.S. dollars paid from a Canadian dollar account,
the debit exchange ratio would be communicated as the ratio (n MXP / n USD).
Rationale: this approach ensures that a common reporting mechanism is used, from the perspective of the value of the transaction,
which is used to communicate the value of the act.
Vocabulary domain:
()
Attribute description:
A ratio that indicates the rate of interest that the transaction value is subject to and the term over which the interest
rate compounds.
The numerator is the interest rate and the denominator is the compounding term.
- Guarantor
is a specialization of:
Role
Description of Guarantor:
The double role-based association between a party in the role of guarantor and an organization in the role of healthcare provider
.
Attributes of Guarantor:
Vocabulary domain:
CreditRating
(CWE)
Attribute description:
A code depicting the credit rating (e.g., excellent, good, fair, questionable, poor).
-
Attributes of Imaging_modality:
- Imaging_modality
is a specialization of:
Device
Description of Imaging_modality:
Class to contain unique attributes of diagnostic imaging equipment.
Attributes of Imaging_modality:
Vocabulary domain:
PixelIntensityRelationship
(CWE)
Attribute description:
The relationship between the Pixel sample values and the X-Ray beam intensity.
Vocabulary domain:
()
Attribute description:
The inherent limiting resolution in mm of the equipment for high contrast objects for the data gathering and reconstruction
technique chosen. If variable across the images of the series, the value at the image center.
Vocabulary domain:
()
Attribute description:
Value of pixels added to non-rectangular image to pad to rectangular format.
-
Attributes of Invoice_element:
Description of Invoice_element:
A sub-type of Act that provides support for the full range of information requirements for invoice processing in healthcare.
The class will be used in at least three moods - definition, order and event - and with a variety of both class_cd and cd
values to distinguish them.
In the "definition" mood, this class provides for the specification of component items covered by health insurance plans and
policies. These items may in turn be linked to one or more billable acts in definition mood to specify the coverages.
In the "order" mood, this class becomes an "invoice" (or claim) containing a set of items (also instances of this class),
associated to the billable acts covered by the items and the policies under which the invoice is asserted, etc. When instances
of this class exist in relationship with instances of authorization or eligibility, are used to communicate the details of
requests for authorization or eligibility inquiries.
In the "event" mood, this class represents the action (result) undertaken in response to the claim. This includes a set of
processing results and adjustments instantiated from this class that reflect the specific coverage decisions related to each
of the items in the ordered invoice.
The context for this class is established, as usual, by a combination of act relationships, participations and roles which
undertake the participations.
Act relationships provide for: compositional relations between plans, policies and sub-policies; compositional relations between
invoices, invoice item groups and invoice items; compositional relations between processing results and adjustments within
a single result; and reference relationships between one invoice item and another or from a processing result (event) to the
invoice item (order) to which it responds.
Participation types used by this class include: "beneficiary," which reflects a "covered party" (role) as the target of a
coverage policy or item, and which provides for coordination-of-benefits sequencing among a set of covered parties; and "policy
holder" which is in the domain ServiceTargetType.
Attributes of Invoice_element:
Vocabulary domain:
InvoiceElementModifier
(CWE)
Attribute description:
Designates a modifier to the cd attribute to provide additional information about the invoice element.
In the "intent" mood, communicates processing consideration information.
In the "event" mood, communicates information about sub-trees of the coding system utilized in the cd attribute for additional
information, clarification, etc.
Vocabulary domain:
()
Attribute description:
A description of the number of instances of a product or service that is being billed or charged for.This attribute represents
such concepts as 4 hours, 4 mg, 4 boxes, etc.
The unit of measure is restricted to a measurable unit such as liters, milligrams and hours. Non-measurable, but countable
units such as boxes, packages, visits must not be specified using the unit component of the PQ data type, except as an annotation,
marked by {xxx}.Refer to Data Types Part II Unabridged Specification, Appendix A :Unified Code for Units of Measure.
Specification of countable units can be handled with the following techniques:
(1) specify the countable unit in the invoice_element.cd.That is, a specific Invoice_element.cd would indicate that the item
referenced by the act represents a box of 20 items.There would be a different Invoice_element.cd for a box of 40 items, and
so on.
For example, if the Invoice_element.cd represents a box of 20 items, and the Invoice_element.unit_qty = 2 (no units), then
this represents 2 boxes of 20 items for a total of 40 items.
(2) if more detail is required (e.g. to describe the composition, packaging, manufacturer of a product), then use a participation
(type_cd = "PRD"), and a combination of role and entity classes to describe the details.
Vocabulary domain:
()
Attribute description:
The monetary cost per unit being accounted. In constructing the ratio, the numerator must of data type MO, and the denominator
must be a PQ, specified in the same manner as the unit_qty attribute.
Vocabulary domain:
()
Attribute description:
Used in financial calculations to derive amounts from quantities of services delivered and/or goods received.
The simplest formula for deriving gross amounts is: Units (Quantity) * Cost/Unit = Amount
The concept of a Factor allows for a discount or surcharge multiplier to be applied to a monetary amount. For example, the
formula, with a factor would be: Units (Quantity) * Cost/Point * Factor = Amount
For example, this could be 10 (Number of Treatments as Units) * $3.00 (Cost per Unit) * 1.5 (Factor) = $45.00 (Amount).
See related note on Points. Formula, with Points and Factors becomes: Units * Cost/Unit * Points * Factor = Amount
Vocabulary domain:
()
Attribute description:
Used in financial calculations to derive amounts from quantities of services delivered and/or goods received.
The simplest formula for deriving amounts is: Units (Quantity) * Cost/Unit = Amount
The concept of Points allows for assignment of point values for services and/or goods, such that a dollar amount can be assigned
to each point. For example, the formula, with points would be: Units (Quantity) * Points * Cost/Point = Amount
For example, this could be 5 (Number of Treatments as Units) * 3 (Number of Points per treatment as Points)* $20.00 (Cost
per Point) = $300.00 (Amount).
See related note on Factor. Formula, with Points and Factors becomes: Units * Cost/Unit * Points * Factor = Amount
Vocabulary domain:
CoverageSource
(CWE)
Attribute description:
A code depicting the source of information about the coverage (e.g., insurance company, employer, insured presented policy,
insured presented card, signed statement on file, verbal information, none, . . .).
Vocabulary domain:
()
Attribute description:
A flag indicating whether the details of the invoice processing results (usually an authorization or an adjustment) should
be communicated directly to the covered party involved.
-
Attributes of Language_communication:
- Language_communication
is a specialization of:
Description of Language_communication:
Class reflects the language communication capabilities for an Entity, showing the languages with which the entity can communicate,
the mode of communication (speak, read, write), the proficiency of that communication, and the Entity's preference.
Attributes of Language_communication:
Attribute description:
A code indicating the language being communicated by the Entity (e.g. Spanish, Italian, German).
Attribute description:
A code depicting the method of expression of the language (e.g. expressed spoken, expressed written, expressed signed, received
spoken, received written, received sign)
Attribute description:
A code classifying the level of proficiency in the language (e.g. excellent, good, fair, poor)
Vocabulary domain:
()
Attribute description:
An indication of whether or not the language is the one preferred by the entity for the indicated mode.
-
Attributes of Living_subject:
- Living_subject generalizes:
- Living_subject
is a specialization of:
Entity
Description of Living_subject:
An organism or complex animal, alive or not. Instances of this class encompass mammals, birds, fishes, bacteria, parasites,
fungi and viruses. Person is a specialization of this class.
Attributes of Living_subject:
Attribute description:
A code depicting the gender (sex) of a person (e.g., female, male). This code is used for administrative purposes.
Vocabulary domain:
()
Attribute description:
The date and time of a living subject's birth or hatching.
Vocabulary domain:
()
Attribute description:
An indication that the subject is dead.
Vocabulary domain:
()
Attribute description:
The date and time that a living subject's death occurred.
Vocabulary domain:
()
Attribute description:
A indication as to whether the living subject is part of a multiple birth.
Vocabulary domain:
()
Attribute description:
For newborn living subjects in a multiple birth, the order in which this living subject was born.
Vocabulary domain:
()
Attribute description:
An indication that the living subject is (as in "has donated" or "is willing to donate") an organ donor.
-
Attributes of Managed_participation:
Description of Managed_participation:
A "stateful" participation. The primary example would be attending practitioner for an inpatient encounter.
Rationale: The state attribute is being added to support attending physician participation on Encounters.
Attributes of Managed_participation:
Vocabulary domain:
()
Attribute description:
A unique identifier for a participation.
Attribute description:
A code depicting the state of the participation (e.g., pending, active, complete, cancelled).
-
Attributes of Manufactured_material:
- Manufactured_material generalizes:
- Manufactured_material
is a specialization of:
Material
Description of Manufactured_material:
Things or combination of things transformed for a particular purpose by a non-natural or manufacturing process. This class
encompasses containers, devices, software modules and facilities.
Attributes of Manufactured_material:
Vocabulary domain:
()
Attribute description:
The lot number is a number used to identify a particular batch of manufactured material. It is usually printed on the label
attached to the container holding the substance and on the packaging which houses the containerNote that a lot number is not
meant to be a unique identifier, but is meaningful only when the product kind and manufacturer are also identified.
Vocabulary domain:
()
Attribute description:
The date and time the manufacturer stops ensuring the safety, quality, and/or proper functioning of the material.
Vocabulary domain:
()
Attribute description:
Specifies the time at which the material is considered useable after it is activated (for instance through opening the bottle
of a liquid.) If a kind of material is described (determiner_cd = KIND) only the width of that interval can be known, i.e.,
the duration after opening the reagent container at which the reagent substance is considered useable for its normal testing
purpose. For an actual instance of the reagent (e.g., a specific bottle), the stability_time.low TS marks the time at which
the reagent bottle has been opened (or the reagent was otherwise activated.) Together with the typical stability duration,
this determines the stability_time.high TS beyond which the reagent is no longer considered useable for its normal testing
purpose.
- Material
is a specialization of:
Entity
Description of Material:
A Material is an Entity that excludes Living_subjects and places. Manufactured or processed products are considered material,
even if they originate in living matter. Parts (e.g. organs) derived from living subjects are Material that may need to be
tracked through associations with the individual Living_subject from which they were obtained. Examples of Material are pharmaceutical
substances (including active vaccines containing retarded virus), disposable supplies, durable equipment, implantable devices,
food items (including meat or plant products), waste, traded goods, etc.
Attributes of Material:
Vocabulary domain:
MaterialForm
(CWE)
Attribute description:
This is a classifier describing the form of the material. This includes the typical state of matter (solid, liquid, gas)
and, for therapeutic substances, the dose form.
-
Attributes of Non_Person_living_subject:
Description of Non_Person_living_subject:
A non-human living subject..
Attributes of Non_Person_living_subject:
Vocabulary domain:
NonPersonLivingSubjectTaxonomicClassification
(CWE)
Attribute description:
A code representing the taxonomy of the living subject.
Vocabulary domain:
NonPersonLivingSubjectBreed
(CWE)
Attribute description:
A code representing the breed of the living subject.
Vocabulary domain:
()
Attribute description:
A text string representing the genotypic or phenotypic strain of the living subject.
Attribute description:
A code indicating whether the reproductive organs of Non_person_living_subject have been surgically removed.
Vocabulary domain:
()
Attribute description:
An indication that the living subject was euthanized.
-
Attributes of Observation:
- Observation
is a specialization of:
Act
Description of Observation:
Observations are actions performed in order to determine an answer or result value. Observation result values (Observation.value)
include specific information about the observed object. The type and constraints of result values depend on the kind of action
performed.
Clinical documents commonly have 'Subjective' and 'Objective' findings, both of which are kinds of Observations. In addition,
clinical documents commonly contain 'Assessments', which are also kinds of Observations. Thus, the establishment of a diagnosis
is an Observation.
Attributes of Observation:
Vocabulary domain:
()
Attribute description:
The result value of an observation action. As was true with HL7 v2, this value can be of any data type. However, there are
clearly more or less reasonable choices of data types as indicated below.
Kind of observation :: Data type ::Notes
(1) Quantitative measurements :: PQ ::Physical quantity (real number with unit.) This is the most usual choice. Note that
numeric values must not be communicated as a simple character string (ST.)
(2) Titer (e.g., 1:64) and other ratios (e.g. 1 out of 1000) :: RTO :: A ratio of two integer numbers (e.g., 1:128.) Sometimes
by local conventions titers are reported as just the denominator (e.g., 32 instead of 1/32) Such conventions are confusing
and should not be followed in HL7 messages.
(3) Index (number without unit) :: REAL :: When a quantity does not have a proper unit, one can just send the number as a
real number. Alternatively one can use a PQ with a dimensionless unit (e.g., 1 or %). An integer number should only be sent
when the measurement is by definition an integer, which is an extremely rare case and then is most likely an ordinal (see
below.)
(4) Ranges (e.g., < 3; 12-20) :: IVL<PQ> :: Interval of physical quantity. Note that sometimes such intervals are used to
report the uncertainty of measurement value. For uncertainty there are dedicated data type extensions available.
(5) Ordinals (e.g., stage "IIa") :: CV, INT :: At this point, ordinals should be reported either as code values, (e.g., +,
++, +++; or I, IIa, IIb, III, IV) or as integers. In the future ordinals may be addressed by a separate data type.
(6) Nominal results, "taxons" (e.g. organism type.) :: CD :: The Concept Descriptor (CD) is the most common data type to use
for categorical results (e.g., diagnosis, complaint, color.) Such qualitative results are rarely simple Code Values (CV) if
there is a tightly defined code system which everyone uses.
(7) Image (still, movie) :: ED :: The encapsulated data type allows one to send an image (e.g., chest X-ray) or a movie (e.g.,
coronary angiography, cardiac echo.)
(8) Waveform :: Waveforms can be sent using the waveform template developed by the Automated Data SIG for version 2.3. A mapping
onto version 3 is shown farther below. In addition one can use the Encapsulated Data (ED) data type to send waveforms in other
formats.
(9) Formalized expressions :: ST :: The character string data type may exceptionally be used to convey formalized expressions
that do not fit in any of the existing data types. However, use of the string data type is not allowed if the meaning can
be represented by one of the existing data types. Note that many of the data types do have character string literal expressions
too, so the field in the message can be formatted using character string literals and still have a distinct data type.
Attribute description:
This attribute allows for a very rough interpretation of the course or outcome of a service action. This is sometimes called
"abnormal flags", however, the judgment of normalcy is just one of the common rough interpretations, and is often not relevant.
For example, for the observation of a pathologic condition, it doesn't make sense to state the normalcy, since pathologic
conditions are never considered "normal."
Attribute description:
The method by which the result was achieved. This may be important to know when interpreting a report more thoroughly (e.g.,
blood pressure method: arterial puncture vs. Riva-Rocci, sitting vs. supine position, etc.) It should be noted that in some
cases the method will already be specified by the Observation.type_cd and therefore does not need to be specified in Observation.method_cd.
Attribute description:
The anatomical site or system that is the focus of the observation, if applicable. Most observation target sites are implied
by the observation code and definition. For example, "heart murmur" always has the heart as target. This attribute is used
when the observation target site needs to be refined, to distinguish right and left etc.
If the subject of the Observation is something other than a human patient or animal, the attribute is used analogously to
specify a structural landmark of the thing where the act focuses. For example, if the subject is a lake, the site could be
inflow and outflow, etc. If the subject is a lymphatic node, "hilus," "periphery," etc. would still be valid target sites.
Vocabulary domain:
()
Attribute description:
Derived observations can be defined through association with other observations using relationships of derivation type (Act_relationship.type_cd
= derivation.) For example, to define a derived observation for Mean Corpuscular Hemoglobin (MCH) one will associate the MCH
observation with a Hemoglobin (HGB) observation (Act_relationship.sequence_nmb = 1) and a Red Blood cell Count (RBC) observation
(Act_relationship.sequence_nmb = 2) Since MCH = HGB / RBC, the value of the derivation expression would be "$1 / $2".
The derivation expression is a character string with a simple syntax similar to that of the UNIX "expr" utility, or the expression
subset of the PERL or TCL language. All observations that are cited in the formula must be associated with the derived observation
through links of type derivation with a unique Act_relationship.sequence_nmb. Such observation values are referred to by that
sequence number preceded by a dollar sign ($).
Defined operators are addition (+), subtraction (?), multiplication (*) and division (/). Parentheses can be used to overcome
the usual precedence (left to right, multiplication before addition.) In addition to the basic arithmetic operations the usual
mathematical functions are defined.
-
Attributes of Organization:
- Organization
is a specialization of:
Entity
Description of Organization:
A formalized group of people with a common purpose (e.g. administrative, legal, political) and the infrastructure to carry
out that purpose. Examples include companies and institutions, a government department, an incorporated body that is responsible
for administering a facility, an insurance company.
Attributes of Organization:
Vocabulary domain:
()
Attribute description:
The postal and residential addresses of an organization.
Vocabulary domain:
OrganizationIndustryClass
(CWE)
Attribute description:
The standard industry class code of the organization.
-
Attributes of Participation:
- Participation generalizes:
- Participation
is a specialization of:
Description of Participation:
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.
Participations are generally grouped into actors and targets. Examples of actors are nurses, doctors, family members, notary
publics, and service organizations -- every person or organization that is capable of independent decisions and can thus be
responsible (and liable) for the actions performed. Target participants in an act may include the patient, the patient's spouse,
family, or community, a specimen drawn from the patient or from any object of interest.
Actors can participate in an action in different ways. For example, primary surgeon, assistant surgeon, sterile nurse, and
nurse assistant are all actors in a surgical procedure, who are more or less immediately involved in the action. However,
payers, supervisors, provider organizations (e.g., "MicroLab") and their delegates may be actors too, even though they might
not be individual persons who have their "hands on" the action.
The notion of multiple actors with specific functions touches and partially overlaps on two "sides" with related concepts
of the RIM, and understanding the distinctions is important to use the RIM constructs correctly. On the one "side" actor functions
look similar to Roles (e.g., healthcare practitioner, guarantor, contact-person,) and capability and certification (e.g.,
certified surgeon vs. resident, certified nurse midwife vs. other midwife practitioner, registered nurse vs. other nurse practitioner.)
The professional credentials of a person may be quite different from what a person actually does. The most common example
is interns and residents performing anesthesia or surgeries under (more or less) supervision of attending specialists. The
opposite example is people who are both medical doctors and registered nurses and who perform the function of a nurse. Thus,
Roles and certification refer to the static capabilities of a person (person-related) while participating actors refer to
the particular function an actor played in the activity.
On the other "side" the actor concept interferes with sub-activities. Whenever multiple actors are involved in an act, each
actor performs a different task (with the extremely rare exception of such symmetrical activities as two people pulling a
rope from either end.) Thus, the presence of multiple actors could be equally well modeled as an act consisting of sub-acts
where each act would have only one performing actor
For example, a record of a surgical service may include the actors of type: (a) consenter, (b) primary surgeon, and (c) anesthetist.
These three actors really perform different tasks, which can be represented as three related acts: (a) the consent, (b) the
surgery proper, and (c) the anesthesia act in parallel to the surgery. If we used the sub-acts, the consenter, surgeon and
anesthetist could simply be of actor type "performer." Thus the more sub-acts we use, the fewer different actor types need
to be distinguished, and the fewer sub-acts we use, the more distinct actor types we need.
Note that the perception of a task as "atomic" or "composite" (of sub-tasks) depends on local business rules and may differ
from department to department. In principle, every task can be thought of as being a composite of sub-tasks. We thus say that
actions are "fractal." The paradigmatic example of the fractal nature of activities is a "robotic arm" doing some simple action
as reaching for a tool in front of it. The seemingly simple activity of the robotic arm decomposes into complex control and
coordination procedures and movements, action of separate motors and switches, etc. (We sometimes use the key-phrase "robotic
arm discussion" to recall the fractal nature of actions, since this example has been brought up over and over again, independently
by different people.)
As a rule of thumb, sub-tasks should be considered instead of multiple actors when each sub-task requires special scheduling,
or billing, or if overall responsibilities for the sub-tasks are different. In most cases, however, human resources are scheduled
by teams (instead of individuals,) billing tends to lump many sub-tasks together into one position, and overall responsibility
often rests with one attending physician, chief nurse, or head of department. This model allows both the multi-actor and the
muli-act approach to represent the business reality, with a slight bias towards "lumping" minor sub-activities into the overall
act.
Attributes of Participation:
Attribute description:
A code depicting the kind of Participation or involvement the Entity playing the Role associated with the Participation has
with regard to the associated Act.
The number and kinds of involved participants also depend on the special kind of act. The "ParticipationType" vocabulary domain
defines a few orthogonal axes along which Participation types can be defined more regularly. For example, one axis represents
the physical performance of the action; another axis represents the responsibility for the action, yet another represents
authoring the information in the Act object. A Participant can have one or more of these types to a certain degree. However,
the business semantics of these types is too variant to be mathematically analyzed. For this reason, we split the coding of
the kind of Participant's involvement into two attributes. The Participant.type_cd contains only categories that have crisp
semantic relevance in the scope of HL7. It is a coded attribute without exceptions and no alternative coding systems allowed.
Conversely, the Participation.function_cd is a mostly locally defined descriptor for the kind of professional activity carried
out by the participant.
Attribute description:
A code specifying the function played by the Participation in the Act.
The code can accommodate the huge variety and nuances of functions that Participants may perform in the act. The number and
kinds of functions applicable depends on the special kind of act. E.g., each operation and method may require a different
number of assistant surgeons or nurses.
Vocabulary domain:
ParticipationContextControl
(CNE)
Attribute description:
Specifies if this participation can be inherited along conductive act-relationships.
Vocabulary domain:
()
Attribute description:
An integer specifying the relative order of the Participation in relation to other Participations having the same associated
Act.
The sequencing might be undertaken for functional reasons or to establish a priority between participations. One example is
the sequencing of covered party participations to establish a coordination of benefits sequence in insurance claims.
Vocabulary domain:
()
Attribute description:
A textual or multimedia depiction of commentary related to Participation.
Vocabulary domain:
()
Attribute description:
An interval of time specifying the effective period of the Participation.
Attribute description:
A code specifying the modality by which the Entity playing the Role is participating in the Act.
Examples include physically present, over the telephone, or in written communication. Particularly for author (originator)
participants this is used to specify whether the information represented by the act was initially provided verbally, (hand)written,
or electronically.
Attribute description:
A code specifying the extent to which the Entity playing the participating Role, usually as a target Participation, is aware
of the associated Act, and especially of the observation made.
For example, a patient (or his next family members) may not be aware of a malignancy diagnosis, the patient and family may
be aware at different times, and some patients may go through a phase of denial.
Attribute description:
A code specifying circumstances related to the requirements for and the existence of a signature of the Entity playing the
Role associated with the Participation.
For example, a surgical Procedure act object (representing a procedure report) requires a signature of the performing and
responsible surgeon, and possibly other participants. See also: Participation.signature_txt.
Vocabulary domain:
()
Attribute description:
A textual or multimedia depiction of the signature by which the Entity playing the Role associated with the Participation
endorses that its participation in the Act is as stated in the Participation.type_cd; indicating that it assumes the associated
accountability for the Act.
For example, an AUTHOR assumes accountability for the truth of the Act statement to the best of his knowledge, whereas an
information RECIPIENT would only sign the fact that he has received the information.
The signature can be represented in many different ways either inline or by reference according to the ED data type. Typical
cases are:
1) Paper-based signatures: the ED data type may refer to some document or file that can be retrieved through an electronic
interface to a hardcopy archive.
2) Electronic signature: this attribute can represent virtually any electronic signature scheme.
3) Digital signature: in particular, this attribute can represent digital signatures, for example, by reference to a signature
data block that is constructed in accordance to a digital signature standard, such as XML-DSIG, PKCS#7, PGP, etc.
- Patient
is a specialization of:
Role
Description of Patient:
A relationship between a Living_subject in the Role of patient and a healthcare provider, typically established for the provision
of healthcare services to the patient by the provider. The role is scoped by the provider.
Attributes of Patient:
Attribute description:
A code depicting the nature of publicity protections in place for this patient.
Vocabulary domain:
PatientImportance
(CWE)
Attribute description:
An indication of the person's VIP type, for example, board member, diplomat, etc..
-
Attributes of Patient_encounter:
- Patient_encounter
is a specialization of:
Act
Description of Patient_encounter:
An interaction between a patient and healthcare participant(s) for the purpose of providing patient service(s) or assessing
the health status of a patient. For example, outpatient visit to multiple departments, home health support (including physical
therapy), inpatient hospital stay, emergency room visit, field visit (e.g., traffic accident), office visit, occupational
therapy, telephone call.
Attributes of Patient_encounter:
Attribute description:
The source of the referral for a patient encounter.
Attribute description:
A code categorizing the source of this patient encounter for reimbursement purposes (e.g., physician referral, transfer from
another health care facility, court/law enforcement agency).
Vocabulary domain:
()
Attribute description:
Length of stay when evaluated on discharge from hospital. The actual days quantity can not be simply calculated from the
admission and discharge dates because of possible leaves of absence.
Attribute description:
A code depicting the actual disposition of the patient at the time of discharge (e.g., discharged to home, expired, against
medical advice, etc.).
Rationale: Clarification of definition
Vocabulary domain:
EncounterAccident
(CWE)
Vocabulary domain:
()
Attribute description:
A indication that the Living_subject was born during this Patient_encounter.
Vocabulary domain:
EncounterAcuity
(CWE)
Attribute description:
A code depicting the acuity (complexity of patient care, resource intensiveness of the patient care) of a patient's medical
condition upon arrival. Values may be derived from formal acuity coding schemes such as RBS.
Vocabulary domain:
()
Attribute description:
An indication that pre-admission tests are required for this patient encounter.
Attribute description:
A code identifying special courtesies extended to the patient. For example, no courtesies, extended courtesies, professional
courtesy, VIP courtesies.
Vocabulary domain:
()
Attribute description:
Descriptive text identifying where the patient's valuables are located.
Vocabulary domain:
()
Attribute description:
Descriptive text identifying where valuables of patient is located.
Description of Person:
An individual human being.
Attributes of Person:
Vocabulary domain:
()
Attribute description:
The address(es) of a Person.
Attribute description:
A code indicating the married or similar partnership status of a person, e.g., married, separated, divorced, widowed, common-law
marriage.
This information is reported on UB FL 16
Vocabulary domain:
EducationLevel
(CWE)
Attribute description:
The amount of education a person achieved.
Vocabulary domain:
AmbulatoryStatus
(CWE)
Attribute description:
Identifies the person's transient state of mobility or factors which impact their state of mobility, e.g., ambulates with
assistive devices, wheelchair-bound, bed-bound, etc.
Attribute description:
A code identifying a person's disability, e.g., vision impaired, hearing impaired.
Attribute description:
A code depicting the living arrangements of a person (e.g., independent household, institution, nursing home, extended care
facility, retirement community, etc.). Used for discharge planning, social service assessment, psychosocial evaluation.
Vocabulary domain:
ReligiousAffiliation
(CWE)
Attribute description:
A person's religious preference.
Vocabulary domain:
SpecialAccomodation
(CWE)
Attribute description:
A code indicating the type of special accommodations for a person (e.g., wheelchair, stretcher, interpreter, attendant, seeing
eye dog). This attribute can be used when planning for a patient encounter and also when the source of the information is
irrelevant, not known, etc.
Vocabulary domain:
Race
(CWE)
Attribute description:
A code depicting the race of a person.
Attribute description:
The ethnic group of the person.
- Place
is a specialization of:
Entity
Description of Place:
A physical place or site with its contained structures, if any. Place may be natural or man-made. The geographic position
of a place may or may not be constant. Examples include a field, lake, city, county, state, country, lot (land), building,
pipeline, power line, playground, ship, truck. Places may be work facilities (where relevant acts occur), homes (where people
live) or offices (where people work.) Places may contain sub-places (floor, room, booth, bed.) Places may also be sites that
are investigated in the context of health care, social work, public health administration (e.g., buildings, picnic grounds,
day care centers, prisons, counties, states, and other focuses of epidemiological events.)
Attributes of Place:
Vocabulary domain:
()
Attribute description:
Indicates whether the facility is considered mobile.
Vocabulary domain:
()
Attribute description:
The physical address of this place. (ADDR.use must be PHYS)
Vocabulary domain:
()
Attribute description:
A free text note that carries information related to a site that is useful for entities accessing that site. It could include
directions for finding the site when address information is inadequate, GPS information is not available, and/or the entity
accessing the site cannot make direct use of the GPS information. It could also include information useful to people visiting
the location. E.g., "Last house on the right", "If owner not present, check whereabouts with neighbor down the road".
Vocabulary domain:
()
Attribute description:
A set of codes that locates the site within a mapping scheme. For example, map coordinates for US Geological Survey maps.
Vocabulary domain:
()
Attribute description:
GPS coordinates of the place.
- Procedure
is a specialization of:
Act
Description of Procedure:
The term "procedure" is also commonly known as a "surgical procedure" or an "operative procedure". Typically, a surgical procedure
involves planned alteration of the structure of the body, ordinarily requiring the disruption of some body surface, usually
through an incision.
Attributes of Procedure:
Vocabulary domain:
ProcedureMethod
(CWE)
Attribute description:
For any Procedure there may be several different methods to achieve by and large the same result, but may be important to
know when interpreting a report more thoroughly (e.g., cholecystectomy: open vs. laparoscopic) Method concepts can be "pre-coordinated"
in the Act definition. There are many possible methods, which all depend heavily on the particular kind of Procedure, so that
defining a vocabulary domain of all methods is difficult. However, a code system might be designed such that it specifies
a set of available methods for each defined Procedure concept. Thus, a user ordering a Procedure could select one of several
variances of the act by means of the method code. Available method variances may also be defined in a master service catalog
for each defined Procedure. In act definition records (Act.mood_cd = DEF) the method_cd attribute is a set of all available
method codes that a user may select while ordering, or expect while receiving results.
Attribute description:
The anatomical site or system through which the procedure reaches its target (see target_site_cd.) For example, a Nephrectomy
can have a trans-abdominal or a primarily retroperitoneal approach; an arteria pulmonalis catheter targets a pulmonary artery
but the approach site is typically the vena carotis interna or the vena subclavia, at the neck or the fossa subclavia respectively.
For non-invasive procedures, e.g., acupuncture, the approach site is the punctured area of the skin.
If the subject of the Act is something other than a human patient or animal, the attribute is used analogously to specify
a structural landmark of the thing where the act focuses.
Some approach sites can also be "pre-coordinated" in the Act definition, so that there is never an option to select different
body sites. The same information structure can handle both the pre-coordinated and the post-coordinated approach.
Attribute description:
The anatomical site or system that is the focus of the procedure. For example, a Nephrectomy's target site is the right or
left kidney; an arteria pulmonalis catheter targets a pulmonary artery. For non-invasive procedures, e.g., acupuncture, the
target site is the organ/system that is sought to be influenced (e.g., "the liver".)
If the subject of the Act is something other than a human patient or animal, the attribute is used analogously to specify
a structural landmark of the thing where the act focuses.
Some target sites can also be "pre-coordinated" in the Act definition, so that there is never an option to select different
body sites. The same information structure can handle both the pre-coordinated and the post-coordinated approach.
-
Attributes of Public_health_case:
Description of Public_health_case:
A public health case is an Observation representing a condition or event that has a specific significance for public health.
Typically it involves an instance or instances of a reportable infectious disease or other condition. The public health case
can include a health-related event concerning a single individual or it may refer to multiple health-related events that are
occurrences of the same disease or condition of interest to public health. An outbreak involving multiple individuals may
be considered as a type of public health case. A public health case definition (Act.mood_cd = "definition") includes the description
of the clinical, laboratory, and epidemiologic indicators associated with a disease or condition of interest to public health.
There are case definitions for conditions that are reportable, as well as for those that are not. There are also case definitions
for outbreaks. A public health case definition is a construct used by public health for the purpose of counting cases, and
should not be used as clinical indications for treatment. Examples include AIDS, toxic-shock syndrome, and salmonellosis and
their associated indicators that are used to define a case.
Attributes of Public_health_case:
Vocabulary domain:
CaseDetectionMethod
(CWE)
Attribute description:
Code for the method by which the public health department was made aware of the case. Includes provider report, patient self-referral,
laboratory report, case or outbreak investigation, contact investigation, active surveillance, routine physical, prenatal
testing, perinatal testing, prison entry screening, occupational disease surveillance, medical record review, etc.
Vocabulary domain:
CaseTransmissionMode
(CWE)
Attribute description:
Code for the mechanism by which disease was acquired by the living subject involved in the public health case. Includes sexually
transmitted, airborne, bloodborne, vectorborne, foodborne, zoonotic, nosocomial, mechanical, dermal, congenital, environmental
exposure, indeterminate.
Vocabulary domain:
CaseDiseaseImported
(CWE)
Attribute description:
Code that indicates whether the disease was likely acquired outside the jurisdiction of observation, and if so, the nature
of the inter-jurisdictional relationship. Possible values include not imported, imported from another country, imported from
another state, imported from another jurisdiction, and insufficient information to determine.
- Referral
is a specialization of:
Act
Description of Referral:
An introduction of a patient from a source caregiver to a target caregiver or provider institution, typically for the purpose
of obtaining the target caregiver's assessment and treatment recommendations. A referral may authorize a specified quantity
of a particular kind or level of service. A referral may also simply be a recommendation or introduction.
Attributes of Referral:
Vocabulary domain:
()
Attribute description:
The number of authorized referral visits.
-
Attributes of Relationship_link:
- Relationship_link
is a specialization of:
Description of Relationship_link:
A connection between two roles expressing a dependency between those roles.
For example: A role of assignment or agency depends on another role of employment, such that when the employment role is terminated,
the assignments would be terminated as well. This is the dependency of the assignment role with the employment role, or in
other words, the assignment is "part of" the employment. Another use case is to reflect authority of one role over another
(in organizational relationships.) For example, an employee of type "manager" may have authority over employees of type "analyst"
which would be indicated by a role link for "direct authority".
Relationship_link specifies the relationships between roles, not between people (or other entities.) People (or other Entities)
are primarily related by their direct player/scoper relationships around the player's Role and more generally through their
interactions (i.e. their participations in acts)
Attributes of Relationship_link:
Attribute description:
A code specifying the kind of associative connection represented by the Relationship_Link.
Vocabulary domain:
()
Attribute description:
An interval of time specifying the period during which the connection between Roles is applicable.
- Role
is a specialization of:
Description of Role:
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 Employee role.
The identifier of the Role identifies the Entity playing the role. This identifier is formally either issued by the scoping
Entity or, at least, formally recognized by the scoping Entity as an identifier of the Role.
Attributes of Role are those that are particular to the playing entity while in the particular role.
Rationale: Requires further constraint: invariant (Role x) where x.nonNull x.played_by.nonNull.or(x.scoped_by.nonNull);
Attributes of Role:
Attribute description:
A code specifying the class or category of Roles that the specific Role represents. The code indicates which class in the
Role hierarchy is represented by any instance of Role.
Vocabulary domain:
()
Attribute description:
A unique identifier for the Role.
Attribute description:
A code specifying a further classification of Role, qualified by the value of the class_cd
Vocabulary domain:
()
Attribute description:
An indicator specifying that the Role is a competency that is not attributed to the Entity playing the Role.
For example, when the Role involves containment, this attribute allows for explicit exclusions. Normally all roles are considered
to be affirmative. (This attribute defaults to FALSE.)
Vocabulary domain:
()
Attribute description:
An address specification applicable the Entity while in the Role.
Vocabulary domain:
()
Attribute description:
A telecommunication address for the Role.
Attribute description:
A code specifying the state of Role.
Vocabulary domain:
()
Attribute description:
An interval of time specifying the period during which the Role is applicable.
Vocabulary domain:
()
Attribute description:
A textual or multimedia depiction of a certification issued by the scoping Entity of a Role certifying the competency of the
Entity playing the Role.
A certificate for the Role. The certificate subject is the Entity that plays the Role. The certificate issuer is the Entity
that scopes the Role.
The certificate can be represented in many different ways, either inline or by reference, according to the ED data type. Typical
cases are:
1) Paper-based certificate: the ED data type may refer to some document or file that can be retrieved through an electronic
interface to a hardcopy archive.
2) Electronic certificate: this attribute can represent virtually any electronic certification scheme, such as, an electronically
(incl. digitally) signed electronic text document.
3) Digital certificate (public key certificate): in particular, this attribute can represent digital certificates, as an inline
data block or by reference to such data. The certificate data block would be constructed in accordance to a digital certificate
standard, such as X509, SPKI, PGP, etc.
Vocabulary domain:
()
Attribute description:
This attribute is used for Roles that represent composition relationships between the scoping and playing Entities. It is
a ratio specifying the relative quantities of the Entity playing the Role and the Entity scoping the Role.
In composition-relationships (e.g., has-parts, has-ingredient, has-content) it specifies that a numerator amount of the target
entity is comprised by a denominator amount of the source entity of such composition-relationship. For example, if a box (source)
has-content 10 eggs (target), the relationship quantity is 10:1; if 0.6 mL contain 75 mg of FeSO4 the ingredient relationship
qty is 75 mg : 0.6 mL. Both numerator and denominator must be amount quantities (refer to the Entity.qty definition).
Vocabulary domain:
()
Attribute description:
An integer specifying the position of the Entity playing the Role with respect to the Entity that scopes the Role.
This attribute is primarily used with respect to containment roles. For example, some containers have discrete positions
in which content may be located. Depending on the geometry of the container, the position may be referenced as a scalar ordinal
number, or as a vector of ordinal numbers (coordinates.) Coordinates always begin counting at 1.
Some containers may have customary ways of referring to the positions or no way at all. In absence of any specific regulation
for a specific container type, the rule of thumb is that the coordinate that is changed earlier is positioned first. For an
automated blood chemistry analyzer with a square shaped tray, this means that the first coordinate is the one in which direction
the tray moves at each step and the second coordinate is the one in which the tray moves only every 10 (or so) steps.
- Role_heir
is a specialization of:
Role
Description of Role_heir:
Rationale: It has been discovered that one cannot create an HMD choice structure for a set of classes, all of which are sub-types
of Act, Role or Entity, but for which there is not a defined physical class. These are the classes that would have been in
the RIM as direct descendants (heirs) of Act, Role and Entity, except for the fact that they carried no unique attributes
or associations.
The addition of this single empty class in each hierarchy will permit messages with the appropriate and necessary choice structures
to be built. Subsequent evolution of the methodology and tooling may permit the elimination of these classes in favor of
an equivalent abstraction in the methodology.
-
Attributes of Schedulable_resource:
- Schedulable_resource
is a specialization of:
Role
Description of Schedulable_resource:
A Role of an Entity that can be scheduled.
Attributes of Schedulable_resource:
Vocabulary domain:
()
Attribute description:
Duration for a single schedulable unit in a schedule for a resource.
-
Attributes of Substance_administration:
- Substance_administration
is a specialization of:
Act
Description of Substance_administration:
Substance_administration is an Act using a Material as a therapeutic agent. The effect of the therapeutic substance is typically
established on a biochemical basis, however, that is not a requirement. For example, radiotherapy can largely be described
in the same way, especially if it is a systemic therapy such as radio-iodine.
Attributes of Substance_administration:
Vocabulary domain:
MedAdministrationRoute
(CWE)
Attribute description:
The route by which the medication is administered. Medication route - when the medication is delivered to a living patient
- is similar to an anatomic body site through which the therapeutic agent is incorporated or otherwise applied to the body
(body_site_cd). The typical routes are per os (PO), sublingual (SL), rectal (PR), per inhalationem (IH), ophtalmic (OP),
nasal (NS), otic (OT), vaginal (VG), intra-dermal (ID), subcutaneous (SC), intra-venous (IV), and intra-cardial (IC). However,
there are other routes and there are many variations as to how to access a specific route. For instance, an oral administration
with the patient swallowing will usually have the same effect as if the same substance is given through a gastric tube. A
more systematic approach to break down the route into components such as site of primary entry (e.g. oral, nasal), site/system
of substance uptake (e.g. gastrointestinal, bronchial, nasal mucosa), method (e.g., swallow, inhale), and device (e.g., gastric
tube, tracheal tube) should be considered. When the medication is delivered to an environmental site, or a location, the route
code indicates a site on its "body".
Attribute description:
The detailed anatomical site where the medication is routed. Note, this attribute is only needed if the route_cd requires
further specification. For example, if the route_cd is "by mouth", no further specification of approach site is needed. If,
however, route_cd is intravenous or intra-muscular, the precise site may be specified in this attribute (e.g., right forearm
or left deltoid muscle respectively.)
Vocabulary domain:
()
Attribute description:
The dose_qty is the amount of the therapeutic agent or other substance given at one administration event. If specified as
an interval, the dose is a value in the specified range. This attribute can be used alone or in combination with a strength.
In theory, for medications provided to patients, a physician's prescription could suffice with just the dose specification.
For example, if Azythromycin is to be given at 80 mg once a day for three days, there is no need to specify a strength. The
pharmacist can figure out the right preparation given what is available in stock or on the marketplace. When the pharmacist
dispenses a particular preparation with a particular strength and packet size from a particular manufacturer, etc., this detail
should be communicated using the Material class.
Open Issue: with the deletion of the strength_qty attribute, the use of attributes such as dose_qty and dose_check_qty has
changed slightly. It is now no longer clear how doses such as 250 mg Amoxicillin 3/d are represented. With strength being
in the Material class, dose_qty would have to be only 1. However, the administered object (e.g., capsule) is different from
the amount of the leading ingredient that one would expect in a "dose quantity" attribute.
Vocabulary domain:
()
Attribute description:
With continuously divisible dose forms (e.g., liquids, gases) a dose rate can be specified. If specified as an interval,
the rate should be anywhere in the specified range. The Pharmacotherapy.rate_qty is specified as a physical quantity in time
(a duration.) Hence, the rate_qty is really the denominator of the dose rate (the dose_qty is the numerator). For example,
if a Ringer's solution is to be given at 100 mL/hour i.v., the dose_qty would be 100 mL and the rate_qty would be 1 h. Note
that there is no difference in the actual values of dose_qty and rate_qty as long as the quotient of both has the same value.
In this example, we could just as well specify dose_qty as 50 mL and rate_qty as 30 min, or 200 mL and 2 h or any other combination
where the quotient equals 100 mL/h.
Note that in principle one could again suffice with just the dose_qty attribute specifying the rate right in that one attribute
(e.g., dose_qty = 100 mL/h.) However this practice is not allowed. Systems that implement the semantics of units according
to the Unified Code for Units of Measure would have no problem noting the fact that a dose_qty is really a rate. Other system
however will have difficulties to tell an at-once dose from a dose rate from just looking at the units. If a system wishes
to deal only with a single quantity describing the dosage, it can always calculate such a quantity as real_dose_qty = dose_qty
x strength_qty / rate_qty.
Vocabulary domain:
()
Attribute description:
This attribute should not generally be used; it is only provided for a special purpose. In some countries, especially Japan,
there is a regulatory requirement to note the total daily dose on the prescription and associated documentation. The purpose
of this requirement obviously is to encourage and facilitate reviewing the total dose prescribed to avoid over- (or under-)
dosage. Rather than to define a "total daily dose" attribute as HL7 v2.3 did, we define this general purpose dose_check_qty
attribute of the Ratio (RTO) data type. The numerator must be comparable to the dose_qty and the denominator must be an quantity
of elapsed time. For example, with Erythromycin 250 mg 1 tablet 3 times a day one can calculate the total daily dose as "dose_check_qty
= dose_qty (1) * strength_qty (250 mg) * activity_dttm (3 /d) = 750 mg/d."
For an intravenous example, this term would be "dose_check_qty = dose_qty (100 ml) * strength_qty (1) / rate_qty (1 h) = 100
mL/h" which can be calculated on a daily basis as "dose_check_qty = 100 mL/h * 24 h/d = 2400 mL/d = 2.4 L/d."
Rationale: This attribute incurs a constraint: invariant(Substance_administration med, RTO max) where med.max_dose_qty.contains(max)
{ max.numerator.compares(med.dose_qty); max.denominator.compares(1 s);}
Vocabulary domain:
()
Attribute description:
Identifies the maximum total quantity of a therapeutic substance that may be administered to a subject over the period of
time. The data type is a ratio (RTO) with the a value comparable to dose qty as numerator and a time duration as denominator,
e.g. 500 mg/day; 1200mg/week.
Rationale: This attribute requires a constraint: invariant(Substance_administration med, RTO max) where med.max_dose_qty.contains(max)
{ max.numerator.compares(med.dose_qty); max.denominator.compares(1 s);}
Vocabulary domain:
()
Attribute description:
Identifies the relative 'effectiveness' of the substance being administered. Intended to express concepts for homeopathic
'strength', and similar concepts.
Rationale: Note: This should NOT be used to represent standard ingredient strengths (measured in milligrams). This should
be represented using the Composition relationship between a product and its active ingredient(s).
Attribute description:
Indicates whether an ordered or intended Substance_administration may be or has been substituted for a different Substance_administration.
The fact that the actual act differs from the planned or ordered act, and the details of the variance can be seen by comparing
the act as planned or ordered from the act as performed. Both act records should be sent in a message where this difference
is important. The Substance_administration.substitution_cd attribute is mainly used in an order, to specify whether an ordered
act may be substituted and in what way it may be substituted.
- Supply
is a specialization of:
Act
Description of Supply:
Supply orders and deliveries are simple Acts that focus on the delivered product. The product is associated with the Supply
Act via Participation.type_cd="product". With general Supply Acts, the precise identification of the Material (manufacturer,
serial numbers, etc.) is important. Most of the detailed information about the Supply should be represented using the Material
class. If delivery needs to be scheduled, tracked, and billed separately, one can associate a Transportation Act with the
Supply Act. Pharmacy dispense services are represented as Supply Acts, associated with a Substance_administration Act. The
Substance_administration class represents the administration of medication, while dispensing is supply.
Attributes of Supply:
Vocabulary domain:
()
Attribute description:
Specifies the quantity ordered or supplied (depending on the mood_cd.)
Vocabulary domain:
()
Attribute description:
Identifies the period time over which the supplied product is expected to be used, or the length of time the supply is expected
to last. In some situations, this attribute may be used instead of Supply.qty to identify the amount supplied by how long
it is expected to last, rather than the physical quantity issued. E.g. 90 days supply of medication (based on an ordered
dosage), 10 hours of jet fuel, etc. NOTE: When possible, it is always better to specify Supply.qty, as this tends to be more
precise. Supply.expected_use_time will always be an estimate that can be influenced by external factors.
-
Attributes of Working_list:
- Working_list
is a specialization of:
Act
Description of Working_list:
Working_list collects a dynamic list of individual instances of Act via Act_relationship which reflects the need of an individual
worker, team of workers, or an organization to manage lists of acts for many different clinical and administrative reasons.
Examples of working lists include problem lists, goal lists, allergy lists, and to-do lists.
Attributes of Working_list:
Vocabulary domain:
ListOwnershipLevel
(CWE)
Attribute description:
Ownership_level_cd indicates the category of representation for the personnel managing the list, whether person, team or organization.
Other values may be added as needed by an organization.
-
Attributes of Acknowledgement:
- Acknowledgement
is a specialization of:
Description of Acknowledgement:
The Acknowledgement class contains information sent when acknowledging another message.
Attributes of Acknowledgement:
Attribute description:
This attribute contains an acknowledgement code as described in the HL7 message processing rules.
Attribute description:
This attribute allows for a coded error type.
Vocabulary domain:
()
Attribute description:
This attribute further describes an error condition. This text may be printed in error logs or presented to an end user.
Vocabulary domain:
()
Attribute description:
This attribute is used in the sequence number protocol.
-
Attributes of Attention_line:
- Attention_line
is a specialization of:
Description of Attention_line:
This class allows parameters for a technology specific transport to be represented in the V3 message outer wrapper.
Attributes of Attention_line:
Vocabulary domain:
()
Attribute description:
A parameter defining word.
Vocabulary domain:
()
Attribute description:
A parameter value.
Description of Batch:
The Batch class is to specify a message which is a collection of HL7 V3 messages. This class is a placeholder for future
specification work by the Control/Query TC.
Attributes of Batch:
Vocabulary domain:
()
Attribute description:
This attribute indicates the control identifier of the batch when it was originally transmitted.
Vocabulary domain:
()
Attribute description:
This attribute is used by the application processing the batch.
Vocabulary domain:
()
Attribute description:
This attribute is available to capture comments related to the batch.
Vocabulary domain:
()
Attribute description:
This attribute contains the count of individual transmissions contained within the batch.
Vocabulary domain:
()
Attribute description:
The batch total. It is possible that more than a single batch total exists.
-
Attributes of Character_data:
- Character_data
is a specialization of:
Entry
Description of Character_data:
Plain character data.
Attributes of Character_data:
Vocabulary domain:
()
Attribute description:
Plain character data.
-
Attributes of Communication_function:
- Communication_function
is a specialization of:
Description of Communication_function:
Relationship class binds the various entities which function in the transmission (sender, receiver, respond-to) to be linked
to the transmission.
Attributes of Communication_function:
Attribute description:
The type of communication function being served by the entity with respect to the transmission, such as sender, receiver,
respond-to party, etc.
Vocabulary domain:
()
Attribute description:
The telecomm address that can be used to reach the entity that is serving this function.
-
Attributes of Context_structure:
- Context_structure generalizes:
- Context_structure
is a specialization of:
Act
Description of Context_structure:
A structure is a container within a document. Structures have captions which can be coded. Structures can nest, and structures
can contain entries.
Attributes of Context_structure:
Vocabulary domain:
()
Attribute description:
An optional identifier which must be unique within the document.
-
Attributes of Control_event:
- Control_event
is a specialization of:
Act
Description of Control_event:
The Event is the focal point of information assembled in response to the occurrence of a "controlled event." "Participations"
and "Acts" related to a "controlled event" ard assembled in a package with the RIM content that a domain technical committee
specifies as the main payload of information to be communicated to document the event. This package can be placed in a message
envelope, directed to an application managing documents or any application with component interfaces to this package of structured
information content.
Attributes of Control_event:
Vocabulary domain:
()
Attribute description:
Attribute identifying the structure of the payload portion of the message specified for this interaction.
Attribute description:
Specifies whether a response is expected from the addressee of this interaction and what level of detail that response should
include.
- Entry
is a specialization of:
Description of Entry:
Entries are contained within structures. Some entries (e.g. Local_markup) can contain nested entries (e.g. Local_attr). Entries
also occur in table cells and captions.
Attributes of Entry:
Vocabulary domain:
()
Attribute description:
An optional identifier which must be unique within the document.
- Link
is a specialization of:
Entry
Description of Link:
A link is a generic referencing mechanism.
- Link_html
is a specialization of:
Entry
Description of Link_html:
Link_html is based on the HTML anchor tag, and enables HTML-style hyperlinking semantics.
Attributes of Link_html:
Vocabulary domain:
()
Attribute description:
This attribute is part of the HTML anchor tag.
Vocabulary domain:
()
Attribute description:
This attribute is part of the HTML anchor tag.
Attribute description:
This attribute is part of the HTML anchor tag.
Attribute description:
This attribute is part of the HTML anchor tag.
Vocabulary domain:
()
Attribute description:
This attribute is part of the HTML anchor tag.
-
Attributes of Local_attr:
- Local_attr
is a specialization of:
Entry
Description of Local_attr:
A component used to map local semantics into the exchange standard when local semantics have not yet been standardized.
Attributes of Local_attr:
Vocabulary domain:
()
Attribute description:
The name of the local attribute.
Vocabulary domain:
()
Attribute description:
The value of the local attribute.
-
Attributes of Local_markup:
- Local_markup
is a specialization of:
Entry
Description of Local_markup:
A component used to map local semantics into the exchange standard when local semantics have not yet been standardized.
Attributes of Local_markup:
Vocabulary domain:
()
Attribute description:
The descriptor attribute describes the element, and the value can be drawn from a local vocabulary domain.
Vocabulary domain:
()
Attribute description:
The render attribute indicates how the sender would render the contents. The value can be drawn from a local vocabulary domain.
Attribute description:
The ignore attribute tells the receiver to ignore just the <local_markup> tag (ignore="markup"), or to ignore the <local_markup>
tag and all contained content (ignore="all").
-
Attributes of Logical_expression:
Attributes of Logical_expression:
Vocabulary domain:
SQLConjunction
(CNE)
Attribute description:
When more than one criteria is to be applied in the evaluation of candidate instances, a conjunction is supplied to identify
how to relate an additional criteria.
Description of Message:
The Message class is the parent class of all HL7 Version 3 messages.
Attributes of Message:
Vocabulary domain:
()
Attribute description:
This attribute is matched by the receiving system to its own version to be sure the message will be interpreted correctly.
Vocabulary domain:
()
Attribute description:
The interaction identifier is a reference to the unique information interchange derived from the V3 MDF for specifying a message.
Vocabulary domain:
()
Attribute description:
The message profile identifier allows a given implementation to explicitly state how it varies from the standard message definition.
Attribute description:
This attribute defines whether the message is part of a production, training, or debugging system.
Attribute description:
This attribute defines whether the message is being sent in current processing, archive mode, initial load mode, restore from
archive mode, etc.
Vocabulary domain:
AcknowledgmentCondition
(CNE)
Attribute description:
The attribute identifies the conditions under which accept acknowledgements are required to be returned in response to this
message.
Vocabulary domain:
AcknowledgmentCondition
(CNE)
Attribute description:
This attribute contains conditions under which application level acknowledgements are to be returned in response to this message.
Vocabulary domain:
()
Attribute description:
This attribute is provided for implementing the sequence number protocol. This field is incremented by one for each subsequent
value assignment.
Vocabulary domain:
()
Attribute description:
Contains arbitrary attachments of data blocks to which can be referred to from the interior of the message. Any ITS is advised
to represent the attachments behind the main message body. Attachments are referred to from the message body using the reference
functionality of the ED data type.
- Parameter
is a specialization of:
Description of Parameter:
The Parmeter class is an implementation class that represents the structure of parameters that may be specified with the Query-by-parameter
mechanisms of the V3 query framework. Parameters may be set of name/value pairs, a named parameter list with a set of name/value
pairs or any combination the previous two options.
Attributes of Parameter:
Vocabulary domain:
()
Attribute description:
The Parameter.id can assist in tracing problems with implementing the query-by-parameter mechanism.
Vocabulary domain:
()
Attribute description:
In a Parameter_list, specifies a named list of parameters (name/value pairs) that is referenced in a query conformance statement.
In A_parameter, identifies the name of the element field in an HMD specified for query response.
-
Attributes of Parameter_item:
- Parameter_item
is a specialization of:
Parameter
Description of Parameter_item:
Represents a valued element structure for the element specified in the query response.
Attributes of Parameter_item:
Vocabulary domain:
()
Attribute description:
Represents a valued element structure for the element specified in the query response.
Vocabulary domain:
String
(CWE)
Attribute description:
The Parameter_item.type_cd attribute provides a unique identification to an element within a specified query response structure.
- Parameter_list
is a specialization of:
Parameter
Description of Parameter_list:
Specifies a named list of parameters (name/value pairs) that is referenced in a query conformance statement.
Description of Query_ack:
This class carries information sent with responses to a query.
Attributes of Query_ack:
Vocabulary domain:
<<unassigned>>
(CWE)
Attribute description:
This attribute is the name of the query as defined by the function-specific chapters of this specification or by an implementation
specific agreement. There is a one to one correspondence with a conformance statement for this query name. The query name
is an identifier for this conformancd statement. The HL7 standard will maintain a table of the standard queries as specified
by an HL7 technical committee. Implementation specific queries will extend this table.
Vocabulary domain:
QueryStatus
(CNE)
Attribute description:
This attribute allows the responding system to return a precise response status.
Vocabulary domain:
()
Attribute description:
Specifies total number of instance matches for query specification associated with this query response instance.
Vocabulary domain:
()
Attribute description:
Specifies number of matches for processed query specification that occur in current bundle of matches.
Vocabulary domain:
()
Attribute description:
Specifies number of matches for processed query specification that have yet to be sent to receiver.
- Query_by_parameter
is a specialization of:
Query_spec
Description of Query_by_parameter:
This class contains the definition of a Query by Parameter, an HL7 query format proposed to replace the QRD/QRF query format.
The query format is considered a closed query because a data server specifies a fixed list of parameters published in a query
conformance statement.
- Query_by_selection
is a specialization of:
Query_spec
Description of Query_by_selection:
This class contains the definition of a Query by Selection. This is an HL7 query in which a request can specify any or all
of the variables offered by a data server and may additionally specify any permissible operators and values for each variable
as published in a query conformance statement. This query format is considered an open query because it allows a selection
specification against a published data base schema.
-
Attributes of Query_continuation:
Description of Query_continuation:
This class maintains the state information required at the application level to control the logical continuation of a query
response.
Attributes of Query_continuation:
Vocabulary domain:
()
Attribute description:
Specifies the instance number in the original query result set to start return in next query response message.
Vocabulary domain:
()
Attribute description:
Specifies the number of instance matches to return in the next query response message.
-
Attributes of Query_event:
- Query_event
is a specialization of:
Description of Query_event:
This abstract class is used to gather the parts of a message interaction that are specific to a query message interaction.
Rationale: A message element type is defined by a TC to meet a messaging requirement for a query response (like the response
message element type for a demographics query). An instance of such a message element type would be represented as a query
message interaction in this revised view of the V3 query/response model. The "return_element_group" would identify the RIM
view that would be similar in form to the RIM view specified in a declarative or imperative application message interaction.
Attributes of Query_event:
Vocabulary domain:
()
Attribute description:
This attribute may be valued by the initiating application to identify the query. It is intended to be used to match response
messages to the originating query. Query_event.query_id may remain the same across multiple interactions when performing
continuations of a previous query.
-
Attributes of Query_spec:
Description of Query_spec:
This class contains the specification of all HL7 Version 3 queries. Attributes common to all queries appear in this class
specification.
Attributes of Query_spec:
Vocabulary domain:
<<unassigned>>
(CWE)
Attribute description:
This attribute is the name of the query as defined by the function-specific chapters of this specification or by an implementation
specific agreement. There is a one to one correspondence with a conformance statement for this query name. The query name
is an identifier for this conformance statement. The HL7 standard will maintain a table of the standard queries as specified
by an HL7 technical committee. Implementation specific queries will extend this table.
Attribute description:
Indicates whether the subscription to a query is new or is being modified.
Vocabulary domain:
()
Attribute description:
The response_element_group_id identifies the specific message_type to be returned in the query response. This message_type
must be chosed from the set of message types supported by the receiver responsibilities associated with the query interaction.
Attribute description:
Defines the timing and grouping of the response instances.
Attribute description:
Identifies the time frame in which the response is expected.
Vocabulary domain:
()
Attribute description:
Defines the maximum size of the response that can be accepted by the requesting application.
Vocabulary domain:
QueryRequestLimit
(CWE)
Attribute description:
Defines the units associated with the magnitude of the maximum size limit of a query response that can be accepted by the
requesting application
Vocabulary domain:
()
Attribute description:
Specifies the time the response is to be returned.
-
Attributes of Relational_expression:
Attributes of Relational_expression:
Vocabulary domain:
()
Attribute description:
Identifies RIM element as subject of selection criteria evaluation.
Attribute description:
Identifies common relational operators used in selection criteria.
Vocabulary domain:
()
Attribute description:
Value supplied for comparison using criteria.
- Selection_expression generalizes:
- Selection_expression
is a specialization of:
-
Attributes of Sort_control:
- Sort_control
is a specialization of:
Description of Sort_control:
Holds specification of sort order for instance matches to a query.
Attributes of Sort_control:
Vocabulary domain:
()
Vocabulary domain:
()
Attribute description:
Identifies a RIM element in a query response.
Attribute description:
Specifies sequence of sort order.
Description of Table:
A container consisting of multiple cells arranged in rows and columns.
Attributes of Table:
Vocabulary domain:
()
Attribute description:
This attribute is part of the XHTML table model.
Vocabulary domain:
()
Attribute description:
This attribute is part of the XHTML table model.
Attribute description:
This attribute is part of the XHTML table model.
Vocabulary domain:
()
Attribute description:
This attribute is part of the XHTML table model.
Vocabulary domain:
()
Attribute description:
This attribute is part of the XHTML table model.
Vocabulary domain:
()
Attribute description:
This attribute is part of the XHTML table model.
Attribute description:
This attribute is part of the XHTML table model.
-
Attributes of Table_cell:
Description of Table_cell:
A cell in a table.
Attributes of Table_cell:
Attribute description:
This attribute is part of the XHTML table model.
Vocabulary domain:
()
Attribute description:
This attribute is part of the XHTML table model.
Vocabulary domain:
()
Attribute description:
This attribute is part of the XHTML table model.
Vocabulary domain:
()
Attribute description:
This attribute is part of the XHTML model.
Vocabulary domain:
()
Attribute description:
This attribute is part of the XHTML table model.
Vocabulary domain:
()
Attribute description:
This attribute is part of the XHTML model.
-
Attributes of Table_column_structure:
Description of Table_column_structure:
A table column or column group.
Attributes of Table_column_structure:
Vocabulary domain:
()
Attribute description:
This attribute is part of the XHTML table model.
Vocabulary domain:
()
Attribute description:
This attribute is part of the XHTML table model.
-
Attributes of Table_structure:
- Table_structure generalizes:
Description of Table_structure:
A table structure is either a column structure, a row structure, or a table cell.
Attributes of Table_structure:
Vocabulary domain:
()
Attribute description:
This attribute is part of the XHTML table model.
Vocabulary domain:
()
Attribute description:
This attribute is part of the XHTML table model.
Attribute description:
This attribute is part of the XHTML table model.
Vocabulary domain:
()
Attribute description:
An optional identifier which must be unique within the document.
Attribute description:
This attribute is part of the XHTML table model.
-
Attributes of Transmission:
- Transmission generalizes:
- Transmission
is a specialization of:
Description of Transmission:
Represents information about a specific transmission of information from one application to another.
Attributes of Transmission:
Vocabulary domain:
()
Attribute description:
Unique identifier of the transmission
Vocabulary domain:
()
Attribute description:
The date/time that the sending system created the transmission. If the time zone is specified, it will be used throughout
the transmission as the default time zone.
Vocabulary domain:
()
Attribute description:
This attribute is specified for applications to implement security features for a transmission. Its uses is not further specified
at this time.
This connection shows the relationship of the acknowledgement to a specific HL7 V3 message
This relationship indicates the association of the Acknowledgement class in an HL7 V3 acknowledgement message.
This relationship allows parameters for a technology specific transport to be represented in the V3 transmission. outer wrapper.
Message_interactions are the payloads of Messages. This is navigable in one direction only from Message to Message_interaction.
This relationship allows the entities playing the various communication functions to be identified.
Specifies the relationship between a parameter list and the parameters which are its content.
The following constraint applies to this association:
Invariant (Role x) { not(x.played_by.equals(null)) or not(x.scoped_by.equals(null)) }
The following constraint applies to this association:
Invariant (Role x) { not(x.played_by.equals(null)) or not(x.scoped_by.equals(null)) }
This relation links a transmission to its sender, receiver, call-back party, etc.