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

Table of contents

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

1

Introduction

1.1

Release notes

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

1.2

Purpose

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.

1.3

Overview

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.

1.4

The Rationale Behind the RIM's Design

The overarching structure of the RIM is based on six "core" classes: Act, Entity, Role, Participation, Act_relationship, and Role_link. Each class is defined in Section 1.4. Following is a discussion of the fundamental thinking behind, and basic usage guidelines for, the six classes and their inter-relationships.

The HL7 RIM identifies two major "high-level" concepts that are fundamental to understanding the world of healthcare information: intentional "actions" or "services" (Acts), and "people, places and things" that are of interest in the world of healthcare (Entities).

The concept "Act" (and its subclasses) represents all of the intentional actions documented by a healthcare professional in either a clinical or administrative context. The presence of the Act class as one of the core RIM classes is a reflection of HL7's view that "from a messaging/system communication perspective, healthcare consists of a series of attributed, intentional actions."" Thus, instances of the class/concept Act include both clinical observations (e.g. patient temperature) and interventions (e.g. administer medication), and administrative actions (e.g. admit patient). Note that in this "act-centered" view of healthcare, the act of an observation takes on two seemingly contradictory meanings: "the act of recognizing and documenting a particular fact," and "the description of the thing observed." In other words, an instance of an Observation Act represents both the attributed act of observing and the results of the observation. Both aspects of this expanded definition of an Observation Act are captured by specific attributes of the class Act or its 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.

1.5

Linking Acts Together: The Semantics of Act_relationship

An understanding of the semantics and application of Act_relationship begins with, an understanding of the "fractal" or "robotic arm" nature of a set of Acts. This perspective is, in turn, best viewed from the overarching framework of the categorization of three types of "collecting relationships" represented by instances of Act_relationship: whole/part (e.g. lab or test batteries (see the discussion of the "robotic arm" below); rule-based (e.g. care plans, protocols, etc.); and cognitive actions (e.g. judgment, renaming, replacement, subsumption, supported by/reason for, etc.).

Regarding the "fractal" or "robotic arm" discussion, As mentioned above, instances of Act_relationship can be used to model the "fractal" or "robotic arm" notion behind a "whole/part" relationship. Consider a surgical procedure such as a laparoscopic cholecystectomy. The procedure may be represented as a single instance of Act, or, alternatively, as a "collection" of (partially ordered) instances of Act each of which is a finer granularity than the entire procedure, e.g. obtain consent, administer pre-op medication, administer anesthesia (throughout the surgical procedure), make the incision, etc. In turn, for any of the more finely granulated actions just mentioned, further granulation/decomposition may occur. The degree of granularity is clearly dependent on the context of the action(s) and the interest level/perspective of the party performing (or not performing) the decomposition. Figure 1 shows a "surgeon's-eye view" of some of the instances of Act and Act_relationship for the exemplar cholecystectomy..

Example of sequential plan construction for laparoscopic cholecystectomy.  Edged boxes are Act instances (all in definition, or 'master' mood.)  Rounded boxes are Act_relationship instances of type: has-component.  The sequence_nbr attribute orders the relationships into a sequence.  Each act can in turn be decomposed into plan-components.

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).

1.6

Definitions of the Six Core Rim Classes

1.6.1

Act

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.

1.6.2

Entity

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).

1.6.3

Role

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.

1.6.4

Participation

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.

1.6.5

Act_relationship

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".)

1.6.6

Role_link

A Role_link is a connection between two roles expressing a dependency between those roles.

1.6.7

Sub Classes of Act, Entity and Role

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.

1.6.8

The Concept of Mood

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.

1.7

Data Types and Vocabulary Domains

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.

1.8

HL7 Version 3 Methodology and the RIM

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.

1.9

Graphic Diagrams of the RIM

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:

Entity class hierarchy in HL7 RIM.

Figure 2: Entity class hierarchy in HL7 RIM.

Role class hierarchy in HL7 RIM.

Figure 3: Role class hierarchy in HL7 RIM.

Complete Act class hierarchy in HL7 RIM

Figure 4: Complete Act class hierarchy in HL7 RIM

Clinical Act class hierarchy in HL7 RIM

Figure 5: Clinical Act class hierarchy in HL7 RIM

Financial Act class hierarchy in HL7 RIM

Figure 6: Financial Act class hierarchy in HL7 RIM

Model of message control classes.

Figure 7: Model of message control classes.

Model of structured documents classes..

Figure 8: Model of structured documents classes..

The state-machine diagram for the Act class.

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

The state-machine diagram for the Entity class.

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

The state-machine diagram for the Managed_participation class.

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

The state-machine diagram for the Role class.

Figure 12: The state-machine diagram for the Role class.

2

Subject areas in HL7 Reference Information Model

RIM_Acts
RIM_Communication_infrastructure
RIM_Entities
RIM_Roles
RIM_unassigned

2.1

RIM_Acts (in base model)

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_Clinical_acts
RIM_Financial_acts

2.1.1

RIM_Clinical_acts (in RIM_Acts)

A collection of classes related to the Act class and its specializations. These relate to the actions and events that constitute clinical care services.

Act
Act_context
Act_heir
Act_relationship
Device_task
Diagnostic_image
Diet
Managed_participation
Observation
Participation
Patient_encounter
Procedure
Public_health_case
Referral
Role
Substance_administration
Supply
Working_list

2.1.2

RIM_Financial_acts (in RIM_Acts)

A collection of classes related to the Act class and its specializations. These classes focus on the administrative and financial activities in health care.

Account
Act
Act_relationship
Financial_act
Financial_contract
Financial_transaction
Invoice_element
Participation
Role

2.2

RIM_Communication_infrastructure (in base model)

A collection of subject areas that define the technical infrastructure of HL7, including messaging, structured documents and components.

RIM_Message_control
RIM_Structured_documents

2.2.1

RIM_Message_control (in RIM_Communication_infrastructure)

A collection of classes related to the technical definition and control of message-based communication in HL7.

Acknowledgement
Attention_line
Batch
Communication_function
Control_event
Logical_expression
Message
Parameter
Parameter_item
Parameter_list
Query_ack
Query_by_parameter
Query_by_selection
Query_continuation
Query_event
Query_spec
Relational_expression
Selection_expression
Sort_control
Transmission

2.2.2

RIM_Structured_documents (in RIM_Communication_infrastructure)

A collection of classes related to the definition of document-based communication in HL7, as represented by the Clinical Document Architecture standards.

Character_data
Clinical_document
Context_structure
Entry
Link
Link_html
Local_attr
Local_markup
Table
Table_cell
Table_column_structure
Table_structure

2.3

RIM_Entities (in base model)

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.

Container
Device
Entity
Entity_heir
Imaging_modality
Language_communication
Living_subject
Manufactured_material
Material
Non_Person_living_subject
Organization
Person
Place
Role

2.4

RIM_Roles (in base model)

A collection of classes related to the Role class and its specializations. These classes focus on the roles participants may play in health care.

Access
Assigned_entity
Certified_entity
Employee
Entity
Guarantor
Participation
Patient
Relationship_link
Role
Role_heir
Schedulable_resource

2.5

RIM_unassigned (in base model)

3

Classes in HL7 Reference Information Model

3.1

Class: Access (in RIM_Roles)

approach_site_cd :: CD
target_site_cd :: CD
gauge_qty :: PQ

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:

3.1.1

Access.approach_site_cd :: CD (0..1) Mandatory

Vocabulary domain: ActSite (CWE)

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.


3.1.2

Access.target_site_cd :: CD (0..1) Mandatory

Vocabulary domain: ActSite (CWE)

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.)


3.1.3

Access.gauge_qty :: PQ (0..1) Mandatory

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.


3.2

Class: Account (in RIM_Financial_acts)

nm :: ST
currency_cd :: CE
interest_rate_qty ::
allowed_balance_qty :: IVL<MO>

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:

3.2.1

Account.nm :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

The descriptive name of the account as carried in the ledger of which the account is a part.


3.2.2

Account.currency_cd :: CE (0..1) Mandatory

Vocabulary domain: Currency (CWE)

Attribute description:

Indicates the currency that the account is managed in.


3.2.3

Account.interest_rate_qty :: (0..1) Mandatory

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.)


3.2.4

Account.allowed_balance_qty :: IVL<MO> (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

An interval describing the minimum and maximum allowed balances for an account.


3.3

Class: Act (in RIM_Clinical_acts)

class_cd :: CS
mood_cd :: CS
id :: SET<II>
cd :: CD
negation_ind :: BL
txt :: ED
status_cd :: SET<CS>
effective_time :: GTS
activity_time :: GTS
availability_time :: TS
priority_cd :: SET<CE>
confidentiality_cd :: SET<CE>
repeat_nbr :: IVL<INT>
interruptible_ind :: BL
context_lock_ind :: BL
independent_ind :: BL
reason_cd :: SET<CE>
language_cd :: CE

Act_context
Act_heir
Context_structure
Control_event
Device_task
Financial_act
Financial_contract
Observation
Patient_encounter
Procedure
Referral
Substance_administration
Supply
Working_list

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:

3.3.1

Act.class_cd :: CS (0..1) Mandatory

Vocabulary domain: ActClass (CNE)

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.


3.3.2

Act.mood_cd :: CS (0..1) Mandatory

Vocabulary domain: ActMood (CNE)

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).


3.3.3

Act.id :: SET<II> (0..*) Mandatory

Vocabulary domain: ()

Attribute description:

A unique identifier for the Act.


3.3.4

Act.cd :: CD (0..1) Mandatory

Vocabulary domain: ActCode (CWE)

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.


3.3.5

Act.negation_ind :: BL (0..1) Mandatory

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."


3.3.6

Act.txt :: ED (0..1) Mandatory

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.


3.3.7

Act.status_cd :: SET<CS> (0..*) Mandatory

Vocabulary domain: ActStatus (CNE)

Attribute description:

A code specifying the state of the Act.


3.3.8

Act.effective_time :: GTS (0..1) Mandatory

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.)


3.3.9

Act.activity_time :: GTS (0..1) Mandatory

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.


3.3.10

Act.availability_time :: TS (0..1) Mandatory

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.


3.3.11

Act.priority_cd :: SET<CE> (0..*) Mandatory

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.


3.3.12

Act.confidentiality_cd :: SET<CE> (0..*) Mandatory

Vocabulary domain: Confidentiality (CWE)

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.


3.3.13

Act.repeat_nbr :: IVL<INT> (0..1) Mandatory

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.


3.3.14

Act.interruptible_ind :: BL (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

An indicator specifying whether Act is interruptible by other, asynchronous Acts


3.3.15

Act.context_lock_ind :: BL (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Indicates that all acts connected through context-conductive links should not be independently removed from the context of this act.


3.3.16

Act.independent_ind :: BL (0..1) Mandatory

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.


3.3.17

Act.reason_cd :: SET<CE> (0..*) Mandatory

Vocabulary domain: ActReason (CWE)

Attribute description:

A code specifying the motivation, cause, or rationale for non-clinical actions represented by Act.


3.3.18

Act.language_cd :: CE (0..1) Mandatory

Vocabulary domain: HumanLanguage (CWE)

Attribute description:

The language used in documenting the Act.


3.4

Class: Act_context (in RIM_Clinical_acts)

level_cd :: CE

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:

3.4.1

Act_context.level_cd :: CE (0..1) Mandatory

Vocabulary domain: ActContextLevel (CWE)

Attribute description:

The nature or level of the contextual containment that this Act_context provides for the Acts it contains.


3.5

Class: Act_heir (in RIM_Clinical_acts)

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.

3.6

Class: Act_relationship (in RIM_Clinical_acts)

type_cd :: CS
inversion_ind :: BL
context_control_cd :: CS
sequence_nbr :: INT
priority_nbr :: INT
pause_qty :: PQ
checkpoint_cd :: CS
split_cd :: CS
join_cd :: CS
negation_ind :: BL
conjunction_cd :: CS

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:

3.6.1

Act_relationship.type_cd :: CS (0..1) Mandatory

Vocabulary domain: ActRelationship (CNE)

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.


3.6.2

Act_relationship.inversion_ind :: BL (0..1) Mandatory

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.


3.6.3

Act_relationship.context_control_cd :: CS (0..1) Mandatory

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.


3.6.4

Act_relationship.sequence_nbr :: INT (0..1) Mandatory

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.


3.6.5

Act_relationship.priority_nbr :: INT (0..1) Mandatory

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.


3.6.6

Act_relationship.pause_qty :: PQ (0..1) Mandatory

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.


3.6.7

Act_relationship.checkpoint_cd :: CS (0..1) Mandatory

Vocabulary domain: ActRelationshipCheckpoint (CNE)

Attribute description:

A code specifying when in the course of an Act a guard condition or pre-condition for the Act is evaluated.


3.6.8

Act_relationship.split_cd :: CS (0..1) Mandatory

Vocabulary domain: ActRelationshipSplit (CNE)

Attribute description:

A code specifying how branches are selected for execution when an activity plan has a branch.


3.6.9

Act_relationship.join_cd :: CS (0..1) Mandatory

Vocabulary domain: ActRelationshipJoin (CNE)

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.


3.6.10

Act_relationship.negation_ind :: BL (0..1) Mandatory

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.


3.6.11

Act_relationship.conjunction_cd :: CS (0..1) Mandatory

Vocabulary domain: RelationshipConjunction (CNE)

Attribute description:

A code specifying the logical conjunction of the criteria in a pair of precondition or outcome Acts.


3.7

Class: Assigned_entity (in RIM_Roles)

position_cd :: CE
primary_care_ind :: BL

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:

3.7.1

Assigned_entity.position_cd :: CE (0..1) Mandatory

Vocabulary domain: PractitionerPosition (CWE)


3.7.2

Assigned_entity.primary_care_ind :: BL (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

An indication that the healthcare practitioner is a primary care provider.


3.8

Class: Certified_entity (in RIM_Roles)

recertification_time :: TS

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:

3.8.1

Certified_entity.recertification_time :: TS (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

The date recertification is required.


3.9

Class: Clinical_document (in RIM_Clinical_acts)

set_id :: II
version_nbr :: INT
completion_cd :: CE
storage_cd :: CE
copy_time :: TS

Description of Clinical_document:

Specialization of Act to add the characteristics unique to document management services.

Attributes of Clinical_document:

3.9.1

Clinical_document.set_id :: II (0..1) Mandatory

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.


3.9.2

Clinical_document.version_nbr :: INT (0..1) Mandatory

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.


3.9.3

Clinical_document.completion_cd :: CE (0..1) Mandatory

Vocabulary domain: DocumentCompletion (CWE)

Attribute description:

A code depicting the completion status of a report (e.g., incomplete, authenticated, legally authenticated).


3.9.4

Clinical_document.storage_cd :: CE (0..1) Mandatory

Vocabulary domain: DocumentStorage (CWE)

Attribute description:

A code depicting the storage status (e.g., active, archived, purged) of a report.


3.9.5

Clinical_document.copy_time :: TS (0..1) Mandatory

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.


3.10

Class: Container (in RIM_Entities)

capacity_qty :: PQ
height_qty :: PQ
diameter_qty :: PQ
cap_type_cd :: CE
separator_type_cd :: CE
barrier_delta_qty :: PQ
bottom_delta_qty :: PQ

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:

3.10.1

Container.capacity_qty :: PQ (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

The capacity of the container in the units specified.


3.10.2

Container.height_qty :: PQ (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

The height of the container in units specified.


3.10.3

Container.diameter_qty :: PQ (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

The outside diameter of the container in units specified.


3.10.4

Container.cap_type_cd :: CE (0..1) Mandatory

Vocabulary domain: ContainerCap (CWE)

Attribute description:

The type of cap that is to be used with the container for decapping, piercing or other mechanisms.


3.10.5

Container.separator_type_cd :: CE (0..1) Mandatory

Vocabulary domain: ContainerSeparator (CWE)

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.


3.10.6

Container.barrier_delta_qty :: PQ (0..1) Mandatory

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.


3.10.7

Container.bottom_delta_qty :: PQ (0..1) Mandatory

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.


3.11

Class: Device (in RIM_Entities)

manufacturer_model_nm :: ST
software_nm :: ST
local_remote_control_state_cd :: CE
alert_level_cd :: CE
last_calibration_time :: TS

Imaging_modality

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:

3.11.1

Device.manufacturer_model_nm :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Name of the version of this device as designated by the manufacturer.


3.11.2

Device.software_nm :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Name, version and release of the software that operates the device.


3.11.3

Device.local_remote_control_state_cd :: CE (0..1) Mandatory

Vocabulary domain: LocalRemoteControlState (CWE)

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").


3.11.4

Device.alert_level_cd :: CE (0..1) Mandatory

Vocabulary domain: DeviceAlertLevel (CWE)

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.


3.11.5

Device.last_calibration_time :: TS (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Date of last calibration and/or inspection of the device.


3.12

Class: Device_task (in RIM_Clinical_acts)

parameter_value :: LIST<ANY>

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:

3.12.1

Device_task.parameter_value :: LIST<ANY> (0..*) Mandatory

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.


3.13

Class: Diagnostic_image (in RIM_Clinical_acts)

subject_orientation_cd :: CE

Description of Diagnostic_image:

Class for holding attributes unique to diagnostic images.

Attributes of Diagnostic_image:

3.13.1

Diagnostic_image.subject_orientation_cd :: CE (0..1) Mandatory

Vocabulary domain: ImagingSubjectOrientation (CWE)

Attribute description:

Patient direction of the rows and columns of the image.


3.14

Class: Diet (in RIM_Clinical_acts)

energy_qty :: PQ
carbohydrate_qty :: PQ

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:

3.14.1

Diet.energy_qty :: PQ (0..1) Mandatory

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".


3.14.2

Diet.carbohydrate_qty :: PQ (0..1) Mandatory

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.


3.15

Class: Employee (in RIM_Roles)

job_cd :: CE
job_title_nm :: ST
job_class_cd :: CE
salary_type_cd :: CE
salary_qty :: MO
hazard_exposure_txt :: ED
protective_equipment_txt :: ED

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:

3.15.1

Employee.job_cd :: CE (0..1) Mandatory

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)


3.15.2

Employee.job_title_nm :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

The title of the job held, for example, Vice President, Senior Technical Analyst.


3.15.3

Employee.job_class_cd :: CE (0..1) Mandatory

Vocabulary domain: EmployeeJobClass (CWE)

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.


3.15.4

Employee.salary_type_cd :: CE (0..1) Mandatory

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.


3.15.5

Employee.salary_qty :: MO (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

The salary amount paid by the employer to the employee.


3.15.6

Employee.hazard_exposure_txt :: ED (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

The type of hazards associated with the work performed by the employee for the employer. For example, asbestos, infectious agents.


3.15.7

Employee.protective_equipment_txt :: ED (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Protective equipment needed for the job performed by the employee for the employer. For example, safety glasses, hard hat.


3.16

Class: Entity (in RIM_Entities)

class_cd :: CS
determiner_cd :: CS
id :: SET<II>
cd :: CE
qty :: SET<PQ>
nm :: BAG<EN>
desc :: ED
status_cd :: SET<CS>
existence_time :: IVL<TS>
telecom :: BAG<TEL>
risk_cd :: CE
handling_cd :: CE
importance_status_txt :: ED

Entity_heir
Living_subject
Material
Organization
Place

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:

3.16.1

Entity.class_cd :: CS (0..1) Mandatory

Vocabulary domain: EntityClass (CNE)

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.


3.16.2

Entity.determiner_cd :: CS (0..1) Mandatory

Vocabulary domain: Determiner (CNE)

Attribute description:

A code specifying whether Entity represents a class of artifacts or a specific instance of an artifact.


3.16.3

Entity.id :: SET<II> (0..*) Mandatory

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.


3.16.4

Entity.cd :: CE (0..1) Mandatory

Vocabulary domain: EntityCode (CWE)

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.


3.16.5

Entity.qty :: SET<PQ> (0..*) Mandatory

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).


3.16.6

Entity.nm :: BAG<EN> (0..*) Mandatory

Vocabulary domain: ()

Attribute description:

A name for the Entity instance.


3.16.7

Entity.desc :: ED (0..1) Mandatory

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.


3.16.8

Entity.status_cd :: SET<CS> (0..*) Mandatory

Vocabulary domain: EntityStatus (CNE)

Attribute description:

A code specifying the state of Entity.


3.16.9

Entity.existence_time :: IVL<TS> (0..1) Mandatory

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.


3.16.10

Entity.telecom :: BAG<TEL> (0..*) Mandatory

Vocabulary domain: ()

Attribute description:

A telecommunication address for the Entity.


3.16.11

Entity.risk_cd :: CE (0..1) Mandatory

Vocabulary domain: EntityRisk (CWE)

Attribute description:

A code specifying the threat or hazard associated with the Entity.


3.16.12

Entity.handling_cd :: CE (0..1) Mandatory

Vocabulary domain: EntityHandling (CWE)

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.


3.16.13

Entity.importance_status_txt :: ED (0..1) Mandatory

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.


3.17

Class: Entity_heir (in RIM_Entities)

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.

3.18

Class: Financial_act (in RIM_Financial_acts)

net_amt :: MO

Account
Financial_transaction
Invoice_element

Description of Financial_act:

An act utilized primarily for administrative (versus clinical) purposes.

Attributes of Financial_act:

3.18.1

Financial_act.net_amt :: MO (0..1) Mandatory

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.


3.19

Class: Financial_contract (in RIM_Financial_acts)

payment_terms_cd :: CE

Description of Financial_contract:

A contract whose value is measured in monetary terms.

Attributes of Financial_contract:

3.19.1

Financial_contract.payment_terms_cd :: CE (0..1) Mandatory

Vocabulary domain: PaymentTerms (CWE)

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.


3.20

Class: Financial_transaction (in RIM_Financial_acts)

credit_exchange_rate_qty :: RTO
debit_exchange_rate_qty :: RTO
interest_rate_qty :: RTO

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:

3.20.1

Financial_transaction.credit_exchange_rate_qty :: RTO (0..1) Mandatory

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.


3.20.2

Financial_transaction.debit_exchange_rate_qty :: RTO (0..1) Mandatory

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.


3.20.3

Financial_transaction.interest_rate_qty :: RTO (0..1) Mandatory

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.


3.21

Class: Guarantor (in RIM_Roles)

credit_rating_cd :: CE

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:

3.21.1

Guarantor.credit_rating_cd :: CE (0..1) Mandatory

Vocabulary domain: CreditRating (CWE)

Attribute description:

A code depicting the credit rating (e.g., excellent, good, fair, questionable, poor).


3.22

Class: Imaging_modality (in RIM_Entities)

pixel_intensity_relationship_cd :: CE
spacial_resolution_qty :: PQ
pixel_padding_qty :: PQ

Description of Imaging_modality:

Class to contain unique attributes of diagnostic imaging equipment.

Attributes of Imaging_modality:

3.22.1

Imaging_modality.pixel_intensity_relationship_cd :: CE (0..1) Mandatory

Vocabulary domain: PixelIntensityRelationship (CWE)

Attribute description:

The relationship between the Pixel sample values and the X-Ray beam intensity.


3.22.2

Imaging_modality.spacial_resolution_qty :: PQ (0..1) Mandatory

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.


3.22.3

Imaging_modality.pixel_padding_qty :: PQ (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Value of pixels added to non-rectangular image to pad to rectangular format.


3.23

Class: Invoice_element (in RIM_Financial_acts)

modifier_cd :: CE
unit_qty :: PQ
unit_price :: RTO
factor_nbr :: REAL
points_nbr :: REAL
coverage_source_cd :: CE
notify_subject_ind :: BL

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:

3.23.1

Invoice_element.modifier_cd :: CE (0..1) Mandatory

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.


3.23.2

Invoice_element.unit_qty :: PQ (0..1) Mandatory

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.


3.23.3

Invoice_element.unit_price :: RTO (0..1) Mandatory

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.


3.23.4

Invoice_element.factor_nbr :: REAL (0..1) Mandatory

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


3.23.5

Invoice_element.points_nbr :: REAL (0..1) Mandatory

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


3.23.6

Invoice_element.coverage_source_cd :: CE (0..1) Mandatory

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, . . .).


3.23.7

Invoice_element.notify_subject_ind :: BL (0..1) Mandatory

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.


3.24

Class: Language_communication (in RIM_Entities)

language_cd :: CE
mode_cd :: CE
proficiency_level_cd :: CE
preference_ind :: BL

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:

3.24.1

Language_communication.language_cd :: CE (0..1) Mandatory

Vocabulary domain: HumanLanguage (CWE)

Attribute description:

A code indicating the language being communicated by the Entity (e.g. Spanish, Italian, German).


3.24.2

Language_communication.mode_cd :: CE (0..1) Mandatory

Vocabulary domain: LanguageAbilityMode (CWE)

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)


3.24.3

Language_communication.proficiency_level_cd :: CE (0..1) Mandatory

Vocabulary domain: LanguageAbilityProficiency (CWE)

Attribute description:

A code classifying the level of proficiency in the language (e.g. excellent, good, fair, poor)


3.24.4

Language_communication.preference_ind :: BL (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

An indication of whether or not the language is the one preferred by the entity for the indicated mode.


3.25

Class: Living_subject (in RIM_Entities)

administrative_gender_cd :: CE
birth_time :: TS
deceased_ind :: BL
deceased_time :: TS
multiple_birth_ind :: BL
birth_order_nbr :: INT
organ_donor_ind :: BL

Non_Person_living_subject
Person

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:

3.25.1

Living_subject.administrative_gender_cd :: CE (0..1) Mandatory

Vocabulary domain: AdministrativeGender (CWE)

Attribute description:

A code depicting the gender (sex) of a person (e.g., female, male). This code is used for administrative purposes.


3.25.2

Living_subject.birth_time :: TS (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

The date and time of a living subject's birth or hatching.


3.25.3

Living_subject.deceased_ind :: BL (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

An indication that the subject is dead.


3.25.4

Living_subject.deceased_time :: TS (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

The date and time that a living subject's death occurred.


3.25.5

Living_subject.multiple_birth_ind :: BL (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

A indication as to whether the living subject is part of a multiple birth.


3.25.6

Living_subject.birth_order_nbr :: INT (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

For newborn living subjects in a multiple birth, the order in which this living subject was born.


3.25.7

Living_subject.organ_donor_ind :: BL (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

An indication that the living subject is (as in "has donated" or "is willing to donate") an organ donor.


3.26

Class: Managed_participation (in RIM_Clinical_acts)

id :: SET<II>
status_cd :: SET<CS>

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:

3.26.1

Managed_participation.id :: SET<II> (0..*) Mandatory

Vocabulary domain: ()

Attribute description:

A unique identifier for a participation.


3.26.2

Managed_participation.status_cd :: SET<CS> (0..*) Mandatory

Vocabulary domain: ParticipationStatus (CNE)

Attribute description:

A code depicting the state of the participation (e.g., pending, active, complete, cancelled).


3.27

Class: Manufactured_material (in RIM_Entities)

lot_nm :: ST
expiration_time :: TS
stability_time :: IVL<TS>

Container
Device

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:

3.27.1

Manufactured_material.lot_nm :: ST (0..1) Mandatory

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.


3.27.2

Manufactured_material.expiration_time :: TS (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

The date and time the manufacturer stops ensuring the safety, quality, and/or proper functioning of the material.


3.27.3

Manufactured_material.stability_time :: IVL<TS> (0..1) Mandatory

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.


3.28

Class: Material (in RIM_Entities)

form_cd :: CE

Manufactured_material

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:

3.28.1

Material.form_cd :: CE (0..1) Mandatory

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.


3.29

Class: Non_Person_living_subject (in RIM_Entities)

taxonomic_classification_cd :: CE
breed_cd :: CE
strain_txt :: ED
gender_status_cd :: CE
euthanasia_ind :: BL

Description of Non_Person_living_subject:

A non-human living subject..

Attributes of Non_Person_living_subject:

3.29.1

Non_Person_living_subject.taxonomic_classification_cd :: CE (0..1) Mandatory

Vocabulary domain: NonPersonLivingSubjectTaxonomicClassification (CWE)

Attribute description:

A code representing the taxonomy of the living subject.


3.29.2

Non_Person_living_subject.breed_cd :: CE (0..1) Mandatory

Vocabulary domain: NonPersonLivingSubjectBreed (CWE)

Attribute description:

A code representing the breed of the living subject.


3.29.3

Non_Person_living_subject.strain_txt :: ED (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

A text string representing the genotypic or phenotypic strain of the living subject.


3.29.4

Non_Person_living_subject.gender_status_cd :: CE (0..1) Mandatory

Vocabulary domain: GenderStatus (CWE)

Attribute description:

A code indicating whether the reproductive organs of Non_person_living_subject have been surgically removed.


3.29.5

Non_Person_living_subject.euthanasia_ind :: BL (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

An indication that the living subject was euthanized.


3.30

Class: Observation (in RIM_Clinical_acts)

value :: ANY
interpretation_cd :: SET<CE>
method_cd :: SET<CE>
target_site_cd :: SET<CD>
derivation_expr :: ST

Diagnostic_image
Public_health_case

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:

3.30.1

Observation.value :: ANY (0..1) Mandatory

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.


3.30.2

Observation.interpretation_cd :: SET<CE> (0..*) Mandatory

Vocabulary domain: ObservationInterpretation (CWE)

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."


3.30.3

Observation.method_cd :: SET<CE> (0..*) Mandatory

Vocabulary domain: ObservationMethod (CWE)

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.


3.30.4

Observation.target_site_cd :: SET<CD> (0..*) Mandatory

Vocabulary domain: ActSite (CWE)

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.


3.30.5

Observation.derivation_expr :: ST (0..1) Mandatory

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.


3.31

Class: Organization (in RIM_Entities)

addr :: BAG<AD>
standard_industry_class_cd :: CE

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:

3.31.1

Organization.addr :: BAG<AD> (0..*) Mandatory

Vocabulary domain: ()

Attribute description:

The postal and residential addresses of an organization.


3.31.2

Organization.standard_industry_class_cd :: CE (0..1) Mandatory

Vocabulary domain: OrganizationIndustryClass (CWE)

Attribute description:

The standard industry class code of the organization.


3.32

Class: Participation (in RIM_Clinical_acts)

type_cd :: CS
function_cd :: CD
context_control_cd :: CS
sequence_nbr :: INT
note_txt :: ED
time :: IVL<TS>
mode_cd :: CE
awareness_cd :: CE
signature_cd :: CS
signature_txt :: ED

Managed_participation

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:

3.32.1

Participation.type_cd :: CS (0..1) Mandatory

Vocabulary domain: ParticipationType (CNE)

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.


3.32.2

Participation.function_cd :: CD (0..1) Mandatory

Vocabulary domain: ParticipationFunction (CWE)

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.


3.32.3

Participation.context_control_cd :: CS (0..1) Mandatory

Vocabulary domain: ParticipationContextControl (CNE)

Attribute description:

Specifies if this participation can be inherited along conductive act-relationships.


3.32.4

Participation.sequence_nbr :: INT (0..1) Mandatory

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.


3.32.5

Participation.note_txt :: ED (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

A textual or multimedia depiction of commentary related to Participation.


3.32.6

Participation.time :: IVL<TS> (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

An interval of time specifying the effective period of the Participation.


3.32.7

Participation.mode_cd :: CE (0..1) Mandatory

Vocabulary domain: ParticipationMode (CWE)

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.


3.32.8

Participation.awareness_cd :: CE (0..1) Mandatory

Vocabulary domain: TargetAwareness (CWE)

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.


3.32.9

Participation.signature_cd :: CS (0..1) Mandatory

Vocabulary domain: ParticipationSignature (CNE)

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.


3.32.10

Participation.signature_txt :: ED (0..1) Mandatory

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.


3.33

Class: Patient (in RIM_Roles)

confidentiality_cd :: CE
very_important_person_cd :: CE

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:

3.33.1

Patient.confidentiality_cd :: CE (0..1) Mandatory

Vocabulary domain: Confidentiality (CWE)

Attribute description:

A code depicting the nature of publicity protections in place for this patient.


3.33.2

Patient.very_important_person_cd :: CE (0..1) Mandatory

Vocabulary domain: PatientImportance (CWE)

Attribute description:

An indication of the person's VIP type, for example, board member, diplomat, etc..


3.34

Class: Patient_encounter (in RIM_Clinical_acts)

admission_source_cd :: CE
referral_source_cd :: CE
length_of_stay_qty :: PQ
discharge_disposition_cd :: CE
accident_cd :: CE
birth_encounter_ind :: BL
acuity_level_cd :: CE
urgency_cd :: CE
pre_admit_test_ind :: BL
special_courtesies_cd :: SET<CE>
valuables_desc :: ED
valuables_location_desc :: ED

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:

3.34.1

Patient_encounter.admission_source_cd :: CE (0..1) Mandatory

Vocabulary domain: EncounterAdmissionSource (CWE)

Attribute description:

The source of the referral for a patient encounter.


3.34.2

Patient_encounter.referral_source_cd :: CE (0..1) Mandatory

Vocabulary domain: EncounterReferralSource (CWE)

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).


3.34.3

Patient_encounter.length_of_stay_qty :: PQ (0..1) Mandatory

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.


3.34.4

Patient_encounter.discharge_disposition_cd :: CE (0..1) Mandatory

Vocabulary domain: EncounterDischargeDisposition (CWE)

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


3.34.5

Patient_encounter.accident_cd :: CE (0..1) Mandatory

Vocabulary domain: EncounterAccident (CWE)


3.34.6

Patient_encounter.birth_encounter_ind :: BL (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

A indication that the Living_subject was born during this Patient_encounter.


3.34.7

Patient_encounter.acuity_level_cd :: CE (0..1) Mandatory

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.


3.34.8

Patient_encounter.urgency_cd :: CE (0..1) Mandatory

Vocabulary domain: EncounterAdmissionUrgency (CWE)


3.34.9

Patient_encounter.pre_admit_test_ind :: BL (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

An indication that pre-admission tests are required for this patient encounter.


3.34.10

Patient_encounter.special_courtesies_cd :: SET<CE> (0..*) Mandatory

Vocabulary domain: EncounterSpecialCourtesy (CWE)

Attribute description:

A code identifying special courtesies extended to the patient. For example, no courtesies, extended courtesies, professional courtesy, VIP courtesies.


3.34.11

Patient_encounter.valuables_desc :: ED (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Descriptive text identifying where the patient's valuables are located.


3.34.12

Patient_encounter.valuables_location_desc :: ED (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Descriptive text identifying where valuables of patient is located.


3.35

Class: Person (in RIM_Entities)

addr :: BAG<AD>
marital_status_cd :: CE
education_level_cd :: CE
ambulatory_status_cd :: CE
disability_cd :: CE
living_arrangement_cd :: CE
religious_affiliation_cd :: CE
special_accommodation_cd :: SET<CE>
race_cd :: SET<CE>
ethnic_group_cd :: SET<CE>

Description of Person:

An individual human being.

Attributes of Person:

3.35.1

Person.addr :: BAG<AD> (0..*) Mandatory

Vocabulary domain: ()

Attribute description:

The address(es) of a Person.


3.35.2

Person.marital_status_cd :: CE (0..1) Mandatory

Vocabulary domain: MaritalStatus (CWE)

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


3.35.3

Person.education_level_cd :: CE (0..1) Mandatory

Vocabulary domain: EducationLevel (CWE)

Attribute description:

The amount of education a person achieved.


3.35.4

Person.ambulatory_status_cd :: CE (0..1) Mandatory

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.


3.35.5

Person.disability_cd :: CE (0..1) Mandatory

Vocabulary domain: PersonDisabilityType (CWE)

Attribute description:

A code identifying a person's disability, e.g., vision impaired, hearing impaired.


3.35.6

Person.living_arrangement_cd :: CE (0..1) Mandatory

Vocabulary domain: LivingArrangement (CWE)

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.


3.35.7

Person.religious_affiliation_cd :: CE (0..1) Mandatory

Vocabulary domain: ReligiousAffiliation (CWE)

Attribute description:

A person's religious preference.


3.35.8

Person.special_accommodation_cd :: SET<CE> (0..*) Mandatory

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.


3.35.9

Person.race_cd :: SET<CE> (0..*) Mandatory

Vocabulary domain: Race (CWE)

Attribute description:

A code depicting the race of a person.


3.35.10

Person.ethnic_group_cd :: SET<CE> (0..*) Mandatory

Vocabulary domain: Ethnicity (CWE)

Attribute description:

The ethnic group of the person.


3.36

Class: Place (in RIM_Entities)

mobile_ind :: BL
addr :: AD
directions_txt :: ED
position_txt :: ED
gps_txt :: ST

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:

3.36.1

Place.mobile_ind :: BL (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Indicates whether the facility is considered mobile.


3.36.2

Place.addr :: AD (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

The physical address of this place. (ADDR.use must be PHYS)


3.36.3

Place.directions_txt :: ED (0..1) Mandatory

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".


3.36.4

Place.position_txt :: ED (0..1) Mandatory

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.


3.36.5

Place.gps_txt :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

GPS coordinates of the place.


3.37

Class: Procedure (in RIM_Clinical_acts)

method_cd :: SET<CE>
approach_site_cd :: SET<CD>
target_site_cd :: SET<CD>

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:

3.37.1

Procedure.method_cd :: SET<CE> (0..*) Mandatory

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.


3.37.2

Procedure.approach_site_cd :: SET<CD> (0..*) Mandatory

Vocabulary domain: ActSite (CWE)

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.


3.37.3

Procedure.target_site_cd :: SET<CD> (0..*) Mandatory

Vocabulary domain: ActSite (CWE)

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.


3.38

Class: Public_health_case (in RIM_Clinical_acts)

detection_method_cd :: CE
transmission_mode_cd :: CE
disease_imported_cd :: CE

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:

3.38.1

Public_health_case.detection_method_cd :: CE (0..1) Mandatory

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.


3.38.2

Public_health_case.transmission_mode_cd :: CE (0..1) Mandatory

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.


3.38.3

Public_health_case.disease_imported_cd :: CE (0..1) Mandatory

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.


3.39

Class: Referral (in RIM_Clinical_acts)

authorized_visits_qty :: REAL

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:

3.39.1

Referral.authorized_visits_qty :: REAL (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

The number of authorized referral visits.


3.40

Class: Relationship_link (in RIM_Roles)

type_cd :: CS
effective_time :: IVL<TS>

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:

3.40.1

Relationship_link.type_cd :: CS (1..1) Mandatory

Vocabulary domain: RelationshipLinkType (CNE)

Attribute description:

A code specifying the kind of associative connection represented by the Relationship_Link.


3.40.2

Relationship_link.effective_time :: IVL<TS> (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

An interval of time specifying the period during which the connection between Roles is applicable.


3.41

Class: Role (in RIM_Roles)

class_cd :: CS
id :: SET<II>
cd :: CE
negation_ind :: BL
addr :: BAG<AD>
telecom :: BAG<TEL>
status_cd :: SET<CS>
effective_time :: IVL<TS>
certificate_txt :: ED
qty :: RTO
position_nbr :: LIST<INT>

Access
Assigned_entity
Certified_entity
Employee
Guarantor
Patient
Role_heir
Schedulable_resource

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:

3.41.1

Role.class_cd :: CS (0..1) Mandatory

Vocabulary domain: RoleClass (CNE)

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.


3.41.2

Role.id :: SET<II> (0..*) Mandatory

Vocabulary domain: ()

Attribute description:

A unique identifier for the Role.


3.41.3

Role.cd :: CE (0..1) Mandatory

Vocabulary domain: RoleCode (CWE)

Attribute description:

A code specifying a further classification of Role, qualified by the value of the class_cd


3.41.4

Role.negation_ind :: BL (0..1) Mandatory

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.)


3.41.5

Role.addr :: BAG<AD> (0..*) Mandatory

Vocabulary domain: ()

Attribute description:

An address specification applicable the Entity while in the Role.


3.41.6

Role.telecom :: BAG<TEL> (0..*) Mandatory

Vocabulary domain: ()

Attribute description:

A telecommunication address for the Role.


3.41.7

Role.status_cd :: SET<CS> (0..*) Mandatory

Vocabulary domain: RoleStatus (CNE)

Attribute description:

A code specifying the state of Role.


3.41.8

Role.effective_time :: IVL<TS> (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

An interval of time specifying the period during which the Role is applicable.


3.41.9

Role.certificate_txt :: ED (0..1) Mandatory

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.


3.41.10

Role.qty :: RTO (0..1) Mandatory

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).


3.41.11

Role.position_nbr :: LIST<INT> (0..*) Mandatory

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.


3.42

Class: Role_heir (in RIM_Roles)

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.

3.43

Class: Schedulable_resource (in RIM_Roles)

slot_size_increment_qty :: PQ

Description of Schedulable_resource:

A Role of an Entity that can be scheduled.

Attributes of Schedulable_resource:

3.43.1

Schedulable_resource.slot_size_increment_qty :: PQ (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Duration for a single schedulable unit in a schedule for a resource.


3.44

Class: Substance_administration (in RIM_Clinical_acts)

route_cd :: CE
approach_site_cd :: SET<CD>
dose_qty :: IVL<PQ>
rate_qty :: IVL<PQ>
dose_check_qty :: SET<RTO>
max_dose_qty :: SET<RTO>
potency_qty :: PQ
substitution_cd :: CE

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:

3.44.1

Substance_administration.route_cd :: CE (0..1) Mandatory

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".


3.44.2

Substance_administration.approach_site_cd :: SET<CD> (0..*) Mandatory

Vocabulary domain: ActSite (CWE)

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.)


3.44.3

Substance_administration.dose_qty :: IVL<PQ> (0..1) Mandatory

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.


3.44.4

Substance_administration.rate_qty :: IVL<PQ> (0..1) Mandatory

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.


3.44.5

Substance_administration.dose_check_qty :: SET<RTO> (0..*) Mandatory

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);}


3.44.6

Substance_administration.max_dose_qty :: SET<RTO> (0..*) Mandatory

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);}


3.44.7

Substance_administration.potency_qty :: PQ (0..1) Mandatory

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).


3.44.8

Substance_administration.substitution_cd :: CE (0..1) Mandatory

Vocabulary domain: SubstanceAdminSubstitution (CWE)

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.


3.45

Class: Supply (in RIM_Clinical_acts)

qty :: PQ
expected_use_time :: IVL<TS>

Diet

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:

3.45.1

Supply.qty :: PQ (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Specifies the quantity ordered or supplied (depending on the mood_cd.)


3.45.2

Supply.expected_use_time :: IVL<TS> (0..1) Mandatory

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.


3.46

Class: Working_list (in RIM_Clinical_acts)

ownership_level_cd :: CE

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:

3.46.1

Working_list.ownership_level_cd :: CE (0..1) Mandatory

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.


3.47

Class: Acknowledgement (in RIM_Message_control)

type_cd :: CS
error_detail_cd :: CE
note_txt :: ED
expected_sequence_nbr :: INT

Description of Acknowledgement:

The Acknowledgement class contains information sent when acknowledging another message.

Attributes of Acknowledgement:

3.47.1

Acknowledgement.type_cd :: CS (0..1) Mandatory

Vocabulary domain: AcknowledgementType (CNE)

Attribute description:

This attribute contains an acknowledgement code as described in the HL7 message processing rules.


3.47.2

Acknowledgement.error_detail_cd :: CE (0..1) Mandatory

Vocabulary domain: MessageCondition (CWE)

Attribute description:

This attribute allows for a coded error type.


3.47.3

Acknowledgement.note_txt :: ED (0..1) Mandatory

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.


3.47.4

Acknowledgement.expected_sequence_nbr :: INT (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute is used in the sequence number protocol.


3.48

Class: Attention_line (in RIM_Message_control)

key_word_txt :: ST
value :: ST

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:

3.48.1

Attention_line.key_word_txt :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

A parameter defining word.


3.48.2

Attention_line.value :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

A parameter value.


3.49

Class: Batch (in RIM_Message_control)

reference_control_id :: II
name :: ST
batch_comment :: SET<ST>
transmission_count :: INT
batch_totals :: SET<INT>

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:

3.49.1

Batch.reference_control_id :: II (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute indicates the control identifier of the batch when it was originally transmitted.


3.49.2

Batch.name :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute is used by the application processing the batch.


3.49.3

Batch.batch_comment :: SET<ST> (0..*) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute is available to capture comments related to the batch.


3.49.4

Batch.transmission_count :: INT (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute contains the count of individual transmissions contained within the batch.


3.49.5

Batch.batch_totals :: SET<INT> (0..*) Mandatory

Vocabulary domain: ()

Attribute description:

The batch total. It is possible that more than a single batch total exists.


3.50

Class: Character_data (in RIM_Structured_documents)

value :: ST

Description of Character_data:

Plain character data.

Attributes of Character_data:

3.50.1

Character_data.value :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Plain character data.


3.51

Class: Communication_function (in RIM_Message_control)

type_cd :: CS
telcom :: TEL

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:

3.51.1

Communication_function.type_cd :: CS (0..1) Mandatory

Vocabulary domain: CommunicationFunctionType (CNE)

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.


3.51.2

Communication_function.telcom :: TEL (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

The telecomm address that can be used to reach the entity that is serving this function.


3.52

Class: Context_structure (in RIM_Structured_documents)

local_id :: ST

Clinical_document
Table
Table_structure

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:

3.52.1

Context_structure.local_id :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

An optional identifier which must be unique within the document.


3.53

Class: Control_event (in RIM_Message_control)

structure_type_id :: II
response_cd :: CS

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:

3.53.1

Control_event.structure_type_id :: II (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Attribute identifying the structure of the payload portion of the message specified for this interaction.


3.53.2

Control_event.response_cd :: CS (0..1) Mandatory

Vocabulary domain: ResponseLevel (CNE)

Attribute description:

Specifies whether a response is expected from the addressee of this interaction and what level of detail that response should include.


3.54

Class: Entry (in RIM_Structured_documents)

local_id :: ST

Character_data
Link
Link_html
Local_attr
Local_markup

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:

3.54.1

Entry.local_id :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

An optional identifier which must be unique within the document.


3.55

Class: Link (in RIM_Structured_documents)

Description of Link:

A link is a generic referencing mechanism.

3.56

Class: Link_html (in RIM_Structured_documents)

href :: ED
name :: ST
rel :: SET<CE>
rev :: SET<CE>
title :: ST

Description of Link_html:

Link_html is based on the HTML anchor tag, and enables HTML-style hyperlinking semantics.

Attributes of Link_html:

3.56.1

Link_html.href :: ED (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute is part of the HTML anchor tag.


3.56.2

Link_html.name :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute is part of the HTML anchor tag.


3.56.3

Link_html.rel :: SET<CE> (0..*) Mandatory

Vocabulary domain: HtmlLinkType ()

Attribute description:

This attribute is part of the HTML anchor tag.


3.56.4

Link_html.rev :: SET<CE> (0..*) Mandatory

Vocabulary domain: HtmlLinkType ()

Attribute description:

This attribute is part of the HTML anchor tag.


3.56.5

Link_html.title :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute is part of the HTML anchor tag.


3.57

Class: Local_attr (in RIM_Structured_documents)

name :: ST
value :: ST

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:

3.57.1

Local_attr.name :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

The name of the local attribute.


3.57.2

Local_attr.value :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

The value of the local attribute.


3.58

Class: Local_markup (in RIM_Structured_documents)

descriptor :: ST
render :: ST
ignore_cd :: CS

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:

3.58.1

Local_markup.descriptor :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

The descriptor attribute describes the element, and the value can be drawn from a local vocabulary domain.


3.58.2

Local_markup.render :: ST (0..1) Mandatory

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.


3.58.3

Local_markup.ignore_cd :: CS (0..1) Mandatory

Vocabulary domain: LocalMarkupIgnore (CNE)

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").


3.59

Class: Logical_expression (in RIM_Message_control)

relational_conjunction_cd :: CS

Attributes of Logical_expression:

3.59.1

Logical_expression.relational_conjunction_cd :: CS (0..1) Mandatory

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.


3.60

Class: Message (in RIM_Message_control)

version_id :: ST
interaction_id :: II
profile_id :: SET<II>
processing_cd :: CS
processing_mode_cd :: CS
accept_ack_cd :: CS
application_ack_cd :: CS
sequence_nbr :: INT
attachment_txt :: ED

Description of Message:

The Message class is the parent class of all HL7 Version 3 messages.

Attributes of Message:

3.60.1

Message.version_id :: ST (0..1) Mandatory

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.


3.60.2

Message.interaction_id :: II (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

The interaction identifier is a reference to the unique information interchange derived from the V3 MDF for specifying a message.


3.60.3

Message.profile_id :: SET<II> (0..*) Mandatory

Vocabulary domain: ()

Attribute description:

The message profile identifier allows a given implementation to explicitly state how it varies from the standard message definition.


3.60.4

Message.processing_cd :: CS (0..1) Mandatory

Vocabulary domain: ProcessingID (CNE)

Attribute description:

This attribute defines whether the message is part of a production, training, or debugging system.


3.60.5

Message.processing_mode_cd :: CS (0..1) Mandatory

Vocabulary domain: ProcessingMode (CNE)

Attribute description:

This attribute defines whether the message is being sent in current processing, archive mode, initial load mode, restore from archive mode, etc.


3.60.6

Message.accept_ack_cd :: CS (0..1) Mandatory

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.


3.60.7

Message.application_ack_cd :: CS (0..1) Mandatory

Vocabulary domain: AcknowledgmentCondition (CNE)

Attribute description:

This attribute contains conditions under which application level acknowledgements are to be returned in response to this message.


3.60.8

Message.sequence_nbr :: INT (0..1) Mandatory

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.


3.60.9

Message.attachment_txt :: ED (0..1) Mandatory

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.


3.61

Class: Parameter (in RIM_Message_control)

id :: II
name :: ST

Parameter_item
Parameter_list

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:

3.61.1

Parameter.id :: II (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

The Parameter.id can assist in tracing problems with implementing the query-by-parameter mechanism.


3.61.2

Parameter.name :: ST (0..1) Mandatory

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.


3.62

Class: Parameter_item (in RIM_Message_control)

value :: ANY
semantics_txt :: ST

Description of Parameter_item:

Represents a valued element structure for the element specified in the query response.

Attributes of Parameter_item:

3.62.1

Parameter_item.value :: ANY (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Represents a valued element structure for the element specified in the query response.


3.62.2

Parameter_item.semantics_txt :: ST (0..1) Mandatory

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.


3.63

Class: Parameter_list (in RIM_Message_control)

Description of Parameter_list:

Specifies a named list of parameters (name/value pairs) that is referenced in a query conformance statement.

3.64

Class: Query_ack (in RIM_Message_control)

message_query_cd :: CE
query_response_cd :: CS
result_count_total :: INT
result_count_current :: INT
result_count_remaining :: INT

Description of Query_ack:

This class carries information sent with responses to a query.

Attributes of Query_ack:

3.64.1

Query_ack.message_query_cd :: CE (0..1) Mandatory

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.


3.64.2

Query_ack.query_response_cd :: CS (0..1) Mandatory

Vocabulary domain: QueryStatus (CNE)

Attribute description:

This attribute allows the responding system to return a precise response status.


3.64.3

Query_ack.result_count_total :: INT (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Specifies total number of instance matches for query specification associated with this query response instance.


3.64.4

Query_ack.result_count_current :: INT (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Specifies number of matches for processed query specification that occur in current bundle of matches.


3.64.5

Query_ack.result_count_remaining :: INT (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Specifies number of matches for processed query specification that have yet to be sent to receiver.


3.65

Class: Query_by_parameter (in RIM_Message_control)

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.

3.66

Class: Query_by_selection (in RIM_Message_control)

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.

3.67

Class: Query_continuation (in RIM_Message_control)

start_result_nbr :: INT
quantity :: INT

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:

3.67.1

Query_continuation.start_result_nbr :: INT (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Specifies the instance number in the original query result set to start return in next query response message.


3.67.2

Query_continuation.quantity :: INT (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Specifies the number of instance matches to return in the next query response message.


3.68

Class: Query_event (in RIM_Message_control)

query_id :: II

Query_ack
Query_continuation
Query_spec

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:

3.68.1

Query_event.query_id :: II (0..1) Mandatory

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.


3.69

Class: Query_spec (in RIM_Message_control)

message_query_cd :: CE
modify_cd :: CS
response_element_group_id :: SET<II>
response_modality_cd :: CS
response_priority_cd :: CS
initial_qty :: INT
initial_qty_cd :: CE
execution_and_delivery_time :: TS

Query_by_parameter
Query_by_selection

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:

3.69.1

Query_spec.message_query_cd :: CE (0..1) Mandatory

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.


3.69.2

Query_spec.modify_cd :: CS (0..1) Mandatory

Vocabulary domain: ModifyIndicator (CNE)

Attribute description:

Indicates whether the subscription to a query is new or is being modified.


3.69.3

Query_spec.response_element_group_id :: SET<II> (0..*) Mandatory

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.


3.69.4

Query_spec.response_modality_cd :: CS (0..1) Mandatory

Vocabulary domain: ResponseModality (CNE)

Attribute description:

Defines the timing and grouping of the response instances.


3.69.5

Query_spec.response_priority_cd :: CS (0..1) Mandatory

Vocabulary domain: QueryPriority (CNE)

Attribute description:

Identifies the time frame in which the response is expected.


3.69.6

Query_spec.initial_qty :: INT (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Defines the maximum size of the response that can be accepted by the requesting application.


3.69.7

Query_spec.initial_qty_cd :: CE (0..1) Mandatory

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


3.69.8

Query_spec.execution_and_delivery_time :: TS (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Specifies the time the response is to be returned.


3.70

Class: Relational_expression (in RIM_Message_control)

element_name :: ST
relational_operator_cd :: CS
value :: ST

Attributes of Relational_expression:

3.70.1

Relational_expression.element_name :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Identifies RIM element as subject of selection criteria evaluation.


3.70.2

Relational_expression.relational_operator_cd :: CS (0..1) Mandatory

Vocabulary domain: RelationalOperator (CNE)

Attribute description:

Identifies common relational operators used in selection criteria.


3.70.3

Relational_expression.value :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Value supplied for comparison using criteria.


3.71

Class: Selection_expression (in RIM_Message_control)

Logical_expression
Relational_expression

3.72

Class: Sort_control (in RIM_Message_control)

sequence_nbr :: INT
element_name :: ST
direction_cd :: CS

Description of Sort_control:

Holds specification of sort order for instance matches to a query.

Attributes of Sort_control:

3.72.1

Sort_control.sequence_nbr :: INT (0..1) Mandatory

Vocabulary domain: ()


3.72.2

Sort_control.element_name :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Identifies a RIM element in a query response.


3.72.3

Sort_control.direction_cd :: CS (0..1) Mandatory

Vocabulary domain: Sequencing (CNE)

Attribute description:

Specifies sequence of sort order.


3.73

Class: Table (in RIM_Structured_documents)

summary :: ST
width :: ST
rules :: CS
cellspacing :: ST
cellpadding :: ST
border :: INT
frame :: CS

Description of Table:

A container consisting of multiple cells arranged in rows and columns.

Attributes of Table:

3.73.1

Table.summary :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute is part of the XHTML table model.


3.73.2

Table.width :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute is part of the XHTML table model.


3.73.3

Table.rules :: CS (0..1) Mandatory

Vocabulary domain: TableRules (CNE)

Attribute description:

This attribute is part of the XHTML table model.


3.73.4

Table.cellspacing :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute is part of the XHTML table model.


3.73.5

Table.cellpadding :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute is part of the XHTML table model.


3.73.6

Table.border :: INT (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute is part of the XHTML table model.


3.73.7

Table.frame :: CS (0..1) Mandatory

Vocabulary domain: TableFrame (CNE)

Attribute description:

This attribute is part of the XHTML table model.


3.74

Class: Table_cell (in RIM_Structured_documents)

scope :: CS
abbr :: ST
axis :: ST
colspan :: INT
headers :: SET<ED>
rowspan :: INT

Description of Table_cell:

A cell in a table.

Attributes of Table_cell:

3.74.1

Table_cell.scope :: CS (0..1) Mandatory

Vocabulary domain: TableCellScope (CNE)

Attribute description:

This attribute is part of the XHTML table model.


3.74.2

Table_cell.abbr :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute is part of the XHTML table model.


3.74.3

Table_cell.axis :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute is part of the XHTML table model.


3.74.4

Table_cell.colspan :: INT (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute is part of the XHTML model.


3.74.5

Table_cell.headers :: SET<ED> (0..*) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute is part of the XHTML table model.


3.74.6

Table_cell.rowspan :: INT (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute is part of the XHTML model.


3.75

Class: Table_column_structure (in RIM_Structured_documents)

span :: INT
width :: ST

Description of Table_column_structure:

A table column or column group.

Attributes of Table_column_structure:

3.75.1

Table_column_structure.span :: INT (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute is part of the XHTML table model.


3.75.2

Table_column_structure.width :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute is part of the XHTML table model.


3.76

Class: Table_structure (in RIM_Structured_documents)

char :: ST
charoff :: ST
halign :: CS
local_id :: ST
valign :: CS

Table_cell
Table_column_structure

Description of Table_structure:

A table structure is either a column structure, a row structure, or a table cell.

Attributes of Table_structure:

3.76.1

Table_structure.char :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute is part of the XHTML table model.


3.76.2

Table_structure.charoff :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

This attribute is part of the XHTML table model.


3.76.3

Table_structure.halign :: CS (0..1) Mandatory

Vocabulary domain: TableCellHorizontalAlign (CNE)

Attribute description:

This attribute is part of the XHTML table model.


3.76.4

Table_structure.local_id :: ST (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

An optional identifier which must be unique within the document.


3.76.5

Table_structure.valign :: CS (0..1) Mandatory

Vocabulary domain: TableCellVerticalAlign (CNE)

Attribute description:

This attribute is part of the XHTML table model.


3.77

Class: Transmission (in RIM_Message_control)

id :: II
creation_time :: TS
security :: ST

Batch
Message

Description of Transmission:

Represents information about a specific transmission of information from one application to another.

Attributes of Transmission:

3.77.1

Transmission.id :: II (0..1) Mandatory

Vocabulary domain: ()

Attribute description:

Unique identifier of the transmission


3.77.2

Transmission.creation_time :: TS (0..1) Mandatory

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.


3.77.3

Transmission.security :: ST (0..1) Mandatory

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.


4

Associations in HL7 Reference Information Model

4.1

(0..*)   Acknowledgement :: acknowledges :: (1..1) Message :: is_acknowledged_by

This connection shows the relationship of the acknowledgement to a specific HL7 V3 message

4.2

(0..1)   Acknowledgement :: occurs_with :: (1..1) Message :: has

This relationship indicates the association of the Acknowledgement class in an HL7 V3 acknowledgement message.

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

This relationship allows parameters for a technology specific transport to be represented in the V3 transmission. outer wrapper.

4.7

(0..1)   Batch :: contains :: (0..*) Transmission :: is_contained_by

4.8

(0..1)   Control_event :: is_communicated_as :: (0..*) Message :: has_payload

Message_interactions are the payloads of Messages. This is navigable in one direction only from Message to Message_interaction.

4.9

(1..1)   Entity :: communicates_with :: (0..*) Language_communication :: used_by

4.10

(1..*)   Entity :: serves :: (0..*) Communication_function :: served_by

This relationship allows the entities playing the various communication functions to be identified.

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

Specifies the relationship between a parameter list and the parameters which are its content.

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

The following constraint applies to this association:

Invariant (Role x) { not(x.played_by.equals(null)) or not(x.scoped_by.equals(null)) }

4.21

(0..*)   Role :: is_scoped_by :: (0..1) Entity :: scopes

The following constraint applies to this association:

Invariant (Role x) { not(x.played_by.equals(null)) or not(x.scoped_by.equals(null)) }

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 relation links a transmission to its sender, receiver, call-back party, etc.