HL7 Reference Information Model

Version: V 01-18 (10/10/2002)
ModelID: RIM_0118

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 ActRelationship
    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 Acts
    2.2 CommunicationInfrastructure
        2.2.1 MessageControl
        2.2.2 StructuredDocuments
    2.3 Entities
    2.4 Roles
3 Classes
    3.1 Access
    3.2 Account
    3.3 Act
    3.4 ActHeir
    3.5 ActRelationship
    3.6 AssignedEntity
    3.7 Container
    3.8 Device
    3.9 DeviceTask
    3.10 DiagnosticImage
    3.11 Diet
    3.12 Employee
    3.13 Entity
    3.14 EntityHeir
    3.15 FinancialAct
    3.16 FinancialContract
    3.17 FinancialTransaction
    3.18 Guarantor
    3.19 ImagingModality
    3.20 InvoiceElement
    3.21 LanguageCommunication
    3.22 LicensedEntity
    3.23 LivingSubject
    3.24 ManagedParticipation
    3.25 ManufacturedMaterial
    3.26 Material
    3.27 NonPersonLivingSubject
    3.28 Observation
    3.29 Organization
    3.30 Participation
    3.31 Patient
    3.32 PatientEncounter
    3.33 Person
    3.34 Place
    3.35 Procedure
    3.36 PublicHealthCase
    3.37 Referral
    3.38 Role
    3.39 RoleHeir
    3.40 RoleLink
    3.41 SchedulableResource
    3.42 SubstanceAdministration
    3.43 Supply
    3.44 WorkingList
    3.45 Acknowledgement
    3.46 AttentionLine
    3.47 Batch
    3.48 ClinicalDocument
    3.49 CommunicationFunction
    3.50 ContextStructure
    3.51 ControlAct
    3.52 LinkHtml
    3.53 LocalAttr
    3.54 LocalMarkup
    3.55 LogicalExpression
    3.56 Message
    3.57 Parameter
    3.58 ParameterItem
    3.59 ParameterList
    3.60 QueryAck
    3.61 QueryByParameter
    3.62 QueryBySelection
    3.63 QueryContinuation
    3.64 QueryEvent
    3.65 QuerySpec
    3.66 RelationalExpression
    3.67 SelectionExpression
    3.68 SortControl
    3.69 Table
    3.70 TableCell
    3.71 TableColumnStructure
    3.72 TableStructure
    3.73 Transmission
4 Associations
    4.1 (1..*)Acknowledgement :: acknowledgedMessage :: (1..1)Message :: acknowledgement
    4.2 (1..1)Acknowledgement :: acknowledgingMessage :: (1..1)Message :: payload
    4.3 (0..*)ActRelationship :: source :: (1..1)Act :: outboundRelationship
    4.4 (0..*)ActRelationship :: target :: (1..1)Act :: inboundRelationship
    4.5 (0..*)AttentionLine :: transmission :: (1..1)Transmission :: attentionLine
    4.6 (0..1)Batch :: transmission :: (0..*)Transmission :: batch
    4.7 (0..1)ControlAct :: payload :: (0..*)Message :: controlAct
    4.8 (1..*)Entity :: communicationFunction :: (0..*)CommunicationFunction :: entity
    4.9 (1..1)Entity :: languageCommunication :: (0..*)LanguageCommunication :: entity
    4.10 (0..*)Parameter :: queryByParameter :: (0..1)QueryByParameter :: parameter
    4.11 (0..1)ParameterList :: parameter :: (0..*)Parameter :: parameterList
    4.12 (0..*)Participation :: act :: (1..1)Act :: participation
    4.13 (0..*)Participation :: role :: (1..1)Role :: participation
    4.14 (0..1)QueryEvent :: controlAct :: (1..1)ControlAct :: queryEvent
    4.15 (0..*)Role :: player :: (0..1)Entity :: playedRole
    4.16 (0..*)Role :: scoper :: (0..1)Entity :: scopedRole
    4.17 (0..*)RoleLink :: source :: (1..1)Role :: outboundLink
    4.18 (0..*)RoleLink :: target :: (1..1)Role :: inboundLink
    4.19 (0..*)SelectionExpression :: leftSide :: (0..1)LogicalExpression :: userAsLeft
    4.20 (0..*)SelectionExpression :: queryBySelection :: (1..1)QueryBySelection :: selectionExpression
    4.21 (0..*)SelectionExpression :: rightSide :: (0..1)LogicalExpression :: userAsRight
    4.22 (0..*)SortControl :: querySpec :: (1..1)QuerySpec :: sortControl
    4.23 (1..*)Transmission :: communicationFunction :: (0..*)CommunicationFunction :: transmission

1

Introduction

1.1

Release notes

This version of the RIM reflects changes that have not yet been harmonized, but which will be formally presented for approval at the November 2002 RIM Harmonization meeting. The changes included here are limited to two technical corrections plus the conformance to new naming-style changes for classes, subject areas and vocabulary domains. The style changes were reviewed during the Fall Meeting and on M&M Conference calls. The RIM is being released in advance of final approval of these changes in order to facilitate preparation of HL7 V3 and RIM ballot materials.

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, ActRelationship, and RoleLink. 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 (scoper, player) 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 - ActRelationship and RoleLink - are used to "associate" or "link" instances of the class with which it is associated. The class RoleLink 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 ActRelationship are explained below.

1.5

Linking Acts Together: The Semantics of ActRelationship

An understanding of the semantics and application of ActRelationship 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 ActRelationship: 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 ActRelationship 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 ActRelationship 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 ActRelationship instances of type: has-component.  The sequenceNumber 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 ActRelationship instances of type: has-component. The sequenceNumber attribute orders the relationships into a sequence. Each act can in turn be decomposed into plan-components.

In summary, the classes Act and ActRelationship 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 ActRelationship can (and will) be expected to be used to collectively capture the complex semantics of clinical reasoning, e.g. an instance of ActRelationship (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

ActRelationship

An ActRelationship 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 ActRelationship (the "source act".)

1.6.6

RoleLink

A RoleLink 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 "classCode" attribute in each of these hierarchies specifies which class is represented. The code set that can be used with the "classCode" attributes are tightly controlled by HL7. A second attribute in each hierarchy, the "code" 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.moodCode 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 ActRelationship 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

Model of message control classes.

Figure 5: Model of message control classes.

Model of structured documents classes..

Figure 6: Model of structured documents classes..

The state-machine diagram for the Act class.

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

The state-machine diagram for the Entity class.

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

The state-machine diagram for the ManagedParticipation class.

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

The state-machine diagram for the Role class.

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

The state-machine diagram for the QueryEvent class.

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

2

Subject areas in HL7 Reference Information Model

Acts
CommunicationInfrastructure
Entities
Roles

2.1

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.

Account
Act
ActHeir
ActRelationship
DeviceTask
DiagnosticImage
Diet
FinancialAct
FinancialContract
FinancialTransaction
InvoiceElement
ManagedParticipation
Observation
Participation
PatientEncounter
Procedure
PublicHealthCase
Referral
Role
SubstanceAdministration
Supply
WorkingList

2.2

CommunicationInfrastructure (in base model)

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

MessageControl
StructuredDocuments

2.2.1

MessageControl (in CommunicationInfrastructure)

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

Acknowledgement
AttentionLine
Batch
CommunicationFunction
ControlAct
LogicalExpression
Message
Parameter
ParameterItem
ParameterList
QueryAck
QueryByParameter
QueryBySelection
QueryContinuation
QueryEvent
QuerySpec
RelationalExpression
SelectionExpression
SortControl
Transmission

2.2.2

StructuredDocuments (in CommunicationInfrastructure)

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

ClinicalDocument
ContextStructure
LinkHtml
LocalAttr
LocalMarkup
Table
TableCell
TableColumnStructure
TableStructure

2.3

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
EntityHeir
ImagingModality
LanguageCommunication
LivingSubject
ManufacturedMaterial
Material
NonPersonLivingSubject
Organization
Person
Place
Role

2.4

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
AssignedEntity
Employee
Entity
Guarantor
LicensedEntity
Participation
Patient
Role
RoleHeir
RoleLink
SchedulableResource

3

Classes in HL7 Reference Information Model

3.1

Class: Access (in Roles)

approachSiteCode :: CD
targetSiteCode :: CD
gaugeQuantity :: 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 approachSiteCode. The body compartment into which material is administered or from which it is drained is designated by the targetSiteCode.

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.

OpenIssue: Issue relates to the restriction of access device to persons or animals as patients. In the case where the material desired does not originate from a "living subject" such as in environmental monitoring, then the access device definition needs to reflect that change. For example, an order for a sample to be taken from the clean-out port of a food processing device for a public health investigation.

Attributes of Access:

3.1.1

Access.approachSiteCode :: CD (0..1)

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_code., indeed the Access.approachSiteCode has been copied from the Procedure class into the Access role class. The value of the Access.approachSiteCode should be identical to the value of the Procedure.approachSiteCode 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.targetSiteCode :: CD (0..1)

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.targetSiteCode; indeed the Access.targetSiteCode has been copied from the Procedure class into the Access role class. The value of the Access.targetSiteCode should be identical to the value of the Procedure.targetSiteCode 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.)

OpenIssue: This is another area where the definition could be generalized to Entities other than LivingSubjects. The target site for environmental sampling may be a particular part of a machine, sewage system, distribution system, etc.


3.1.3

Access.gaugeQuantity :: PQ (0..1)

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

name :: ST
currencyCode :: CE
interestRateQuantity :: RTO<MO,PQ>
allowedBalanceQuantity :: 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.name :: ST (0..1)

Attribute description:

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


3.2.2

Account.currencyCode :: CE (0..1)

Vocabulary domain: Currency (CWE)

Attribute description:

Indicates the currency that the account is managed in. Specific amounts might be reported in another currency however this represents the default currency for activity in this account.

ExtRef: ISO:4217


3.2.3

Account.interestRateQuantity :: RTO<MO,PQ> (0..1)

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.allowedBalanceQuantity :: IVL<MO> (0..1)

Attribute description:

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


3.3

Class: Act (in Acts)

classCode :: CS
moodCode :: CS
id :: SET<II>
code :: CD
negationInd :: BL
text :: ED
statusCode :: SET<CS>
effectiveTime :: GTS
activityTime :: GTS
availabilityTime :: TS
priorityCode :: SET<CE>
confidentialityCode :: SET<CE>
repeatNumber :: IVL<INT>
interruptibleInd :: BL
contextLockInd :: BL
levelCode :: CE
independentInd :: BL
uncertaintyCode :: CE
reasonCode :: SET<CE>
languageCode :: CE
substitutionConditionCode :: CE

ActHeir
ContextStructure
ControlAct
DeviceTask
FinancialAct
FinancialContract
Observation
PatientEncounter
Procedure
Referral
SubstanceAdministration
Supply
WorkingList

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 ActRelationship 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 "typeCode" 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.classCode :: CS (1..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.

Version 2.x reference:

| PV1^2^00132^Patient Class |

| FT1^6^00360^Transaction Type |

| FT1^7^00361^Transaction Code |

| FT1^9^00363^Transaction Description - Alt |


3.3.2

Act.moodCode :: CS (1..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..*)

Attribute description:

A unique identifier for the Act.

Version 2.x reference:

| PID^18^00121^Patient Account Number |

| MRG^3^00213^Prior Patient Account Number |

| BLG^3^00236^Account ID |

| FT1^2^00356^Transaction ID |

| FT1^14^00368^Insurance Plan ID |

| IN1^2^00368^Insurance Plan ID |

| DG1^8^00382^Diagnostic Related Group |

| DRG^1^00382^Diagnostic Related Group |

| IN1^14^00439^Authorization Information |

| IN1^35^00460^Company Plan Code |

| IN1^46^00471^Prior Insurance Plan ID |

| IN3^2^00503^Certification Number |

| UB2^12^00564^Document Control Number |


3.3.4

Act.code :: CD (0..1)

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.

Version 2.x reference:

| FT1^18^00148^Patient Type |

| PV1^18^00148^Patient Type |

| IN1^15^00440^Plan Type |

| IN1^31^00456^Type of Agreement Code |

| IN2^21^00492^Blood Deductible |

| IN2^28^00499^Room Coverage Type/Amount |

| IN2^29^00500^Policy Type/Amount |

| IN2^30^00501^Daily Deductible |

| IN3^12^00513^Non-Concur Code/Description |

| DRG^8^00770^DRG Payor |

| IN1^47^01227^Coverage Type |

| LRL^4^01227^Coverage Type |


3.3.5

Act.negationInd :: BL (0..1)

Attribute description:

An indicator specifying that the Act is a negation of the Act event specified by Act.classCode and Act.code.

OpenIssue: Scope of negotation indicator is not clear and needs to be fixed.


3.3.6

Act.text :: ED (0..1)

Attribute description:

A textual or multimedia description of the Act.

There is no restriction on length or content imposed on the Act.text 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.text attribute is subject to the Act.moodCode. 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.

Version 2.x reference:

| FT1^8^00362^Transaction Description |


3.3.7

Act.statusCode :: SET<CS> (0..*)

Vocabulary domain: ActStatus (CNE)

Attribute description:

A code specifying the state of the Act.

Version 2.x reference:

| IN1^32^00457^Billing Status |

| IN2^16^00487^Champus Status |

| IN3^23^00524^Second Opinion Status |

| IN3^24^00525^Second Opinion Documentation Received |

| PV2^16^00717^Purge Status Code |

| PV2^24^00725^Patient Status Code |


3.3.8

Act.effectiveTime :: GTS (0..1)

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

ExtRef: UB92 FL 17, UB91 FL 18

Version 2.x reference:

| PV1^25^00155^Contract Effective Date |

| PV1^30^00160^Transfer to Bad Debt Date |

| PV1^35^00165^Delete Account Date |

| PV1^41^00171^Account Status |

| PV1^44^00174^Admit Date/Time |

| PV1^45^00175^Discharge Date/Time |

| FT1^5^00359^Transaction Posting Date |

| GT1^13^00417^Guarantor Date - Begin |

| IN3^6^00507^Certification Date/Time |

| IN3^9^00510^Certification Begin Date |

| IN3^13^00514^Non-Concur Effective Date/Time |

| IN3^22^00523^Second Opinion Date |

| PV2^17^00718^Purge Status Date |


3.3.9

Act.activityTime :: GTS (0..1)

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.

Version 2.x reference:

| FT1^4^00358^Transaction Date |

| IN1^29^00454^Verification Date/Time |

| IN3^7^00508^Certification Modify Date/Time |

| DRG^2^00769^DRG Assigned Date/Time |


3.3.10

Act.availabilityTime :: TS (0..1)

Attribute description:

A time expression specifying the point in time at which information about Act first became available.

For HL7 messaging, the Act.availabilityTime will be set according to the sender system.

The Act.availabilityTime 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.priorityCode :: SET<CE> (0..*)

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.

Version 2.x reference:

| PV1^4^00134^Admission Type |

| PV2^25^00726^Visit Priority Code |


3.3.12

Act.confidentialityCode :: SET<CE> (0..*)

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.

Version 2.x reference:

| IN1^27^00452^Release Information Code |

| PV2^21^00722^Visit Publicity Code |


3.3.13

Act.repeatNumber :: IVL<INT> (0..1)

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.effectiveTime, whichever comes first.


3.3.14

Act.interruptibleInd :: BL (0..1)

Attribute description:

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


3.3.15

Act.contextLockInd :: BL (0..1)

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.levelCode :: CE (0..1)

Vocabulary domain: ActContextLevel (CWE)

Attribute description:

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

OpenIssue: The values of this attribute need to be carefully considered to address the open issues relating to inheritance.


3.3.17

Act.independentInd :: BL (0..1)

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

Act.uncertaintyCode :: CE (0..1)

Vocabulary domain: ActUncertainty (CNE)

Attribute description:

A code indicating whether the Act statement has been asserted to be uncertain in any way. Uncertainty asserted using this attribute applies to the combined meaning of the Act statement established by all descriptive attributes (e.g., Act.code, Act.effectiveTime, Observation.value, SubstanceAdministration.doseQuantity, etc.), and the meanings of any contextually dependent associated classes (i.e., "components", "reasons" or other outbound ActRelationships share in the uncertainty.)

This is not intended for use to replace or compete with uncertainty associated with a Observation.values alone or other individual attributes of the class. Such pointed indications of uncertainty should be specified by applying the PPD, UVP or UVN data type extensions to the specific attribute. Particualrly if the uncertainty is uncertainty of a quantitative measurement value, this must still be represented by a PPD<PQ> in the value and NOT using the uncertaintyCode. Also, when differential diagnoses are enumerated or even weighed for probability, the UVP<CD> or UVN<CD> must be used, not the uncertaintyCode. The use of the uncertaintyCode is appropriate only if the entirety of the Act and its dependent Acts is questioned.

Examples are: patient might have had a cholecystectomy procedure in the past (but isn't sure).

OpenIssue: The vocabulary domain needs to be defined, and once defined, the vocabulary domain may cause us to re-visit negationInd.


3.3.19

Act.reasonCode :: SET<CE> (0..*)

Vocabulary domain: ActReason (CWE)

Attribute description:

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

Version 2.x reference:

| PV1^29^00159^Transfer to Bad Debt Code |

| PV1^34^00164^Delete Account Indicator |

| PV2^4^00184^Transfer Reason |

| IN3^17^00518^Appeal Reason |


3.3.20

Act.languageCode :: CE (0..1)

Vocabulary domain: HumanLanguage (CWE)

Attribute description:

The language used in documenting the Act.


3.3.21

Act.substitutionConditionCode :: CE (0..1)

Vocabulary domain: SubstitutionCondition (CWE)

Attribute description:

Indicates the conditions under which an ordered or intended item may be substituted with a different one.


3.4

Class: ActHeir (in Acts)

Description of ActHeir:

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

Class: ActRelationship (in Acts)

typeCode :: CS
inversionInd :: BL
contextControlCode :: CS
sequenceNumber :: INT
priorityNumber :: INT
pauseQuantity :: PQ
checkpointCode :: CS
splitCode :: CS
joinCode :: CS
negationInd :: BL
conjunctionCode :: CS

Description of ActRelationship:

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 ActRelationship 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 ActRelationship (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 ActRelationship 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 ActRelationship link.

The ActRelationship.typeCode identifies the meaning and purpose of every ActRelationship instance.

Attributes of ActRelationship:

3.5.1

ActRelationship.typeCode :: CS (1..1) Mandatory

Vocabulary domain: ActRelationshipType (CNE)

Attribute description:

A code specifying the meaning and purpose of every ActRelationship instance. Each of its values implies specific constraints to what kinds of Act objects can be related and in which way.

Version 2.x reference:

| FT1^3^00357^Transaction Batch ID |

| FT1^15^00369^Insurance Amount |

| FT1^17^00370^Fee Schedule |

| IN1^25^00450^Rpt of Eligibility Flag |

| IN1^33^00458^Lifetime Reserve Days |

| IN1^34^00459^Delay Before L. R. Day |

| IN1^37^00462^Policy Deductible |

| IN1^39^00464^Policy Limit - Days |

| IN2^19^00490^Baby Coverage |

| IN2^20^00491^Combine Baby Bill |

| IN2^21^00492^Blood Deductible |

| IN2^24^00495^Non-Covered Insurance Code |

| IN2^28^00499^Room Coverage Type/Amount |

| IN2^29^00500^Policy Type/Amount |

| IN2^30^00501^Daily Deductible |

| IN3^5^00506^Penalty |

| IN3^20^00521^Pre-Certification Req/Window |

| IN2^67^00807^Copay Limit Flag |


3.5.2

ActRelationship.inversionInd :: BL (0..1)

Attribute description:

An indicator specifying that the Act_Relationship.typeCode should be interpreted as if the roles of the source and target Acts were reversed.

The inversion indicator is used when the meaning of ActRelationship_typeCode 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 inversionInd 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 inversionInd value is.


3.5.3

ActRelationship.contextControlCode :: CS (0..1)

Vocabulary domain: ContextControlActRelationship (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.5.4

ActRelationship.sequenceNumber :: INT (0..1)

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

ActRelationship.priorityNumber :: INT (0..1)

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

ActRelationship.pauseQuantity :: PQ (0..1)

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

ActRelationship.checkpointCode :: CS (0..1)

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

ActRelationship.splitCode :: CS (0..1)

Vocabulary domain: ActRelationshipSplit (CNE)

Attribute description:

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


3.5.9

ActRelationship.joinCode :: CS (0..1)

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

ActRelationship.negationInd :: BL (0..1)

Attribute description:

An indicator used in ActRelationships 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 negationInd is part of the condition so that the Boolean outcome of the condition XOR-ed with the negationInd of the condition link must be true. Thus, if the negationInd is "true", we say the "condition is true", even if the test was negative.


3.5.11

ActRelationship.conjunctionCode :: CS (0..1)

Vocabulary domain: RelationshipConjunction (CNE)

Attribute description:

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


3.6

Class: AssignedEntity (in Roles)

positionCode :: CE
primaryCareInd :: BL

Description of AssignedEntity:

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 AssignedEntity:

3.6.1

AssignedEntity.positionCode :: CE (0..1)

Vocabulary domain: PractitionerPosition (CWE)


3.6.2

AssignedEntity.primaryCareInd :: BL (0..1)

Attribute description:

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


3.7

Class: Container (in Entities)

capacityQuantity :: PQ
heightQuantity :: PQ
diameterQuantity :: PQ
capTypeCode :: CE
separatorTypeCode :: CE
barrierDeltaQuantity :: PQ
bottomDeltaQuantity :: 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.typeCode = "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.7.1

Container.capacityQuantity :: PQ (0..1)

Attribute description:

The capacity of the container in the units specified.


3.7.2

Container.heightQuantity :: PQ (0..1)

Attribute description:

The height of the container in units specified.


3.7.3

Container.diameterQuantity :: PQ (0..1)

Attribute description:

The outside diameter of the container in units specified.


3.7.4

Container.capTypeCode :: CE (0..1)

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

Container.separatorTypeCode :: CE (0..1)

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

Container.barrierDeltaQuantity :: PQ (0..1)

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

Container.bottomDeltaQuantity :: PQ (0..1)

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

Class: Device (in Entities)

manufacturerModelName :: ST
softwareName :: ST
localRemoteControlStateCode :: CE
alertLevelCode :: CE
lastCalibrationTime :: TS

ImagingModality

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

Attributes of Device:

3.8.1

Device.manufacturerModelName :: ST (0..1)

Attribute description:

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


3.8.2

Device.softwareName :: ST (0..1)

Attribute description:

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


3.8.3

Device.localRemoteControlStateCode :: CE (0..1)

Vocabulary domain: LocalRemoteControlState (CWE)

Attribute description:

The current state of control associated with the equipment. An equipment can either work autonomously (localRemoteControlStateCode="Local") or it can be controlled by another system (localRemoteControlStateCode="Remote").


3.8.4

Device.alertLevelCode :: CE (0..1)

Vocabulary domain: DeviceAlertLevel (CWE)

Attribute description:

This field identifies the current functional activity of the automated device. The value of alertLevelCode is determined by the machine itself.


3.8.5

Device.lastCalibrationTime :: TS (0..1)

Attribute description:

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

OpenIssue: Is this linked somehow with the 'maintainer'?

OpenIssue: Given the definition of the class, this attribute would be moved up to ManufacturedMaterial.


3.9

Class: DeviceTask (in Acts)

parameterValue :: LIST<ANY>

Description of DeviceTask:

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 moodCode <= ORD; an executed task (including a task in progress) has moodCode <= EVN, an automatic task on the schedule has moodCode <= INT.

Attributes of DeviceTask:

3.9.1

DeviceTask.parameterValue :: LIST<ANY> (0..*)

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

Class: DiagnosticImage (in Acts)

subjectOrientationCode :: CE

Description of DiagnosticImage:

Class for holding attributes unique to diagnostic images.

Attributes of DiagnosticImage:

3.10.1

DiagnosticImage.subjectOrientationCode :: CE (0..1)

Vocabulary domain: ImagingSubjectOrientation (CWE)

Attribute description:

Patient direction of the rows and columns of the image.


3.11

Class: Diet (in Acts)

energyQuantity :: PQ
carbohydrateQuantity :: PQ

Description of Diet:

Diet acts are supply acts, with some aspects resembling SubstanceAdministration acts: the detail of the diet is given as a description of the Material associated via Participation.typeCode="product". Medically relevant diet types may be communicated in the Entity.code, however, the detail of the food supplied and the various combinations of dishes should be communicated as Material instances.

Attributes of Diet:

3.11.1

Diet.energyQuantity :: PQ (0..1)

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

Diet.carbohydrateQuantity :: PQ (0..1)

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

OpenIssue: Unclear whether the same should not be expressed as associated observations in goal mood (observation.typeCode = carbohydrate intake.)


3.12

Class: Employee (in Roles)

jobCode :: CE
jobTitleName :: ST
jobClassCode :: CE
salaryTypeCode :: CE
salaryQuantity :: MO
hazardExposureText :: ED
protectiveEquipmentText :: 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 AssignedEntity)

Attributes of Employee:

3.12.1

Employee.jobCode :: CE (0..1)

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)

Version 2.x reference:

| NK1^11^00200^Next of Kin/Associated Parties Job Code/Class |

| GT1^50^00786^Job Code/Class |

| IN2^47^00786^Job Code/Class |

| STF^19^00786^Job Code/Class |


3.12.2

Employee.jobTitleName :: ST (0..1)

Attribute description:

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

Version 2.x reference:

| NK1^10^00199^Next of Kin/Associated Parties Job Title |

| IN2^23^00494^Special Coverage Approval Title |

| GT1^49^00785^Job Title |

| IN2^46^00785^Job Title |

| STF^18^00785^Job Title |


3.12.3

Employee.jobClassCode :: CE (0..1)

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

Version 2.x reference:

| NK1^11^00200^Next of Kin/Associated Parties Job Code/Class |

| GT1^50^00786^Job Code/Class |

| IN2^47^00786^Job Code/Class |

| STF^19^00786^Job Code/Class |


3.12.4

Employee.salaryTypeCode :: CE (0..1)

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

Employee.salaryQuantity :: MO (0..1)

Attribute description:

The salary amount paid by the employer to the employee.

OpenIssue: Is this the amount paid per the value specified in salaryTypeCode?


3.12.6

Employee.hazardExposureText :: ED (0..1)

Attribute description:

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


3.12.7

Employee.protectiveEquipmentText :: ED (0..1)

Attribute description:

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


3.13

Class: Entity (in Entities)

classCode :: CS
determinerCode :: CS
id :: SET<II>
code :: CE
quantity :: SET<PQ>
name :: BAG<EN>
desc :: ED
statusCode :: SET<CS>
existenceTime :: IVL<TS>
telecom :: BAG<TEL>
riskCode :: CE
handlingCode :: CE
importanceStatusText :: ED

EntityHeir
LivingSubject
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.13.1

Entity.classCode :: CS (1..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.

Version 2.x reference:

| GT1^10^00414^Guarantor Type |

| LOC^3^00945^Location Type-LOC |


3.13.2

Entity.determinerCode :: CS (1..1) Mandatory

Vocabulary domain: EntityDeterminer (CNE)

Attribute description:

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


3.13.3

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

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

Entity.code :: CE (0..1)

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

Version 2.x reference:

| IN2^14^00485^Champus Service |


3.13.5

Entity.quantity :: SET<PQ> (0..*)

Attribute description:

Specifies the quantity of the given entity, as interpreted in coordination with the determinerCode. For individual instances of Entities, the quantity is 1. For a group of individual members, the quantity is the number of individual members in the group.

When the Entity instance is a portion of a substance, the quantity specifies the amount of that substance comprised by that portion. For an undetermined substance (kind) the quantity 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 quantity 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 quantity 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(quantity = 100) has-part Person(quantity = 60; sex = female). Amoxicillin 500 mg per tablet is Material(Tablet, quantity = 1) has-ingredient Material(Amoxicillin, quantity = 500 mg). Glucose 50% (D5W) is Material(D5W, quantity = 1 kg) has-ingredient Material(Glucose, quantity = 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 quantity 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.13.6

Entity.name :: BAG<EN> (0..*)

Attribute description:

A name for the Entity instance.


3.13.7

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

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.

Version 2.x reference:

| PV2^5^00185^Patient Valuables |

| PV2^6^00186^Patient Valuables Location |


3.13.8

Entity.statusCode :: SET<CS> (0..*)

Vocabulary domain: EntityStatus (CNE)

Attribute description:

A code specifying the state of Entity.


3.13.9

Entity.existenceTime :: IVL<TS> (0..1)

Attribute description:

An interval of time specifying the period during which the artifact represented by Entity has, had, or will have physical existence.


3.13.10

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

Attribute description:

A telecommunication address for the Entity.

Version 2.x reference:

| PID^13^00116^Phone Number - Home |

| NK1^6^00195^Business Phone Number |

| GT1^6^00410^Guarantor Ph Num- Home |

| GT1^7^00411^Guarantor Ph Num-Business |

| GT1^18^00422^Guarantor Employer Phone Number |

| IN1^7^00432^Insurance Co Phone Number |

| IN3^16^00517^Certification Contact Phone Number |

| IN3^19^00520^Certification Agency Phone Number |

| OM1^17^00602^Telephone Number of Section |

| OM1^29^00614^Phone Number of Outside Site |

| GT1^46^00749^Contact Person's Telephone Number |

| NK1^31^00749^Contact Person's Telephone Number |

| IN2^50^00790^Employer Contact Person Phone Number |

| IN2^53^00793^Insured's Contact Person Telephone Number |

| IN2^58^00798^Insurance Co Contact Phone Number |

| IN2^63^00803^Insured's Telephone Number - Home |

| IN2^64^00804^Insured's Employer Telephone Number |


3.13.11

Entity.riskCode :: CE (0..1)

Vocabulary domain: EntityRisk (CWE)

Attribute description:

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


3.13.12

Entity.handlingCode :: CE (0..1)

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

Entity.importanceStatusText :: ED (0..1)

Attribute description:

A textual description or multimedia depiction of the relative importance the artifact represented by Entity has to the owner of the Entity.

OpenIssue: There is a problem with this attribute. Shouldn't it be coded? Does it belong here at all?


3.14

Class: EntityHeir (in Entities)

Description of EntityHeir:

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

Class: FinancialAct (in Acts)

netAmt :: MO

Account
FinancialTransaction
InvoiceElement

Description of FinancialAct:

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

Attributes of FinancialAct:

3.15.1

FinancialAct.netAmt :: MO (0..1)

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

Class: FinancialContract (in Acts)

paymentTermsCode :: CE

Description of FinancialContract:

A contract whose value is measured in monetary terms.

Attributes of FinancialContract:

3.16.1

FinancialContract.paymentTermsCode :: CE (0..1)

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

Class: FinancialTransaction (in Acts)

creditExchangeRateQuantity :: REAL
debitExchangeRateQuantity :: REAL
interestRateQuantity :: RTO

Description of FinancialTransaction:

A sub-class of Act representing any transaction between two accounts whose value is measured in monetary terms. Financial transactions always reference two accounts (debit and credit), but there may be circumstances where one or both accounts are implied or inherited from another context in a specific message.

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 FinancialTransaction:

3.17.1

FinancialTransaction.creditExchangeRateQuantity :: REAL (0..1)

Attribute description:

A decimal number indicating the rate of exchange in effect between the currency of the account being credited, and the currency of the transaction value.

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 real number "r" such that "y (USD) * r = x (CAD)".

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

FinancialTransaction.debitExchangeRateQuantity :: REAL (0..1)

Attribute description:

A decimal number indicating the rate of exchange in effect between the currency of the account being debited, and the currency of the transaction value.

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 real number "r" such that "y (USD) * r = x (MXP)".

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

FinancialTransaction.interestRateQuantity :: RTO (0..1)

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

Class: Guarantor (in Roles)

creditRatingCode :: 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.18.1

Guarantor.creditRatingCode :: CE (0..1)

Vocabulary domain: CreditRating (CWE)

Attribute description:

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

Version 2.x reference:

| PV1^23^00153^Credit Rating |

| GT1^23^00774^Guarantor Credit Rating Code |


3.19

Class: ImagingModality (in Entities)

pixelIntensityRelationshipCode :: CE
spacialResolutionQuantity :: PQ
pixelPaddingQuantity :: PQ

Description of ImagingModality:

Class to contain unique attributes of diagnostic imaging equipment.

Attributes of ImagingModality:

3.19.1

ImagingModality.pixelIntensityRelationshipCode :: CE (0..1)

Vocabulary domain: PixelIntensityRelationship (CWE)

Attribute description:

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


3.19.2

ImagingModality.spacialResolutionQuantity :: PQ (0..1)

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

ImagingModality.pixelPaddingQuantity :: PQ (0..1)

Attribute description:

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


3.20

Class: InvoiceElement (in Acts)

modifierCode :: SET<CE>
unitQuantity :: RTO<PQ,PQ>
unitPriceAmt :: RTO<MO,PQ>
factorNumber :: REAL
pointsNumber :: REAL
coverageSourceCode :: CE
notifySubjectInd :: BL

Description of InvoiceElement:

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 classCode and code 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 ParticipationTarget.

Attributes of InvoiceElement:

3.20.1

InvoiceElement.modifierCode :: SET<CE> (0..*)

Vocabulary domain: InvoiceElementModifier (CWE)

Attribute description:

Designates a modifier to the code 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 code attribute for additional information, clarification, etc.


3.20.2

InvoiceElement.unitQuantity :: RTO<PQ,PQ> (0..1)

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, and 15 each of a container of 1000 each, etc.

Each invoice_element that is being charged or billed is identified by a charge or bill code (InvoiceElement.code). In some situations, this code is a pre-coordinated code set and represents a container (e.g. UPC code for a container of 1000 pills and another UPC code for a container of the same pills butin a container of 100). The UPC code is used in invoicing, but ratios are required to specify that only a portion of the container (e.g. bottle) are being billed or charged. If the InvoiceElement does not reference a container, then the denominator is not specified.

For example, 15 pills in a container size of 1000 pills. In this case, the numerator can be expressed as "15 {pill}" or simply "15" and the denominator can be expressed as "1000 {bottle}" or simply "1000" (see discussion following for rational of using descriptive text for countable units).

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, pills and containers 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.code. That is, a specific InvoiceElement.code would indicate that the item referenced by the act represents a box of 20 items. There would be a different InvoiceElement.code for a box of 40 items, and so on.

For example, if the InvoiceElement.code represents a box of 20 items, and the InvoiceElement.unitQuantity = 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 (typeCode = "PRD"), and a combination of role and entity classes to describe the details of the packaging.


3.20.3

InvoiceElement.unitPriceAmt :: RTO<MO,PQ> (0..1)

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 unitQuantity attribute.

Version 2.x reference:

| FT1^10^00364^Transaction Quantity |

| FT1^22^00374^Unit Cost |


3.20.4

InvoiceElement.factorNumber :: REAL (0..1)

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

InvoiceElement.pointsNumber :: REAL (0..1)

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

InvoiceElement.coverageSourceCode :: CE (0..1)

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

Version 2.x reference:

| IN2^27^00498^Eligibility Source |


3.20.7

InvoiceElement.notifySubjectInd :: BL (0..1)

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

Class: LanguageCommunication (in Entities)

languageCode :: CE
modeCode :: CE
proficiencyLevelCode :: CE
preferenceInd :: BL

Description of LanguageCommunication:

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 LanguageCommunication:

3.21.1

LanguageCommunication.languageCode :: CE (0..1)

Vocabulary domain: HumanLanguage (CWE)

Attribute description:

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

Version 2.x reference:

| GT1^36^00118^Primary Language |

| IN2^34^00118^Primary Language |

| NK1^20^00118^Primary Language |

| PID^15^00118^Primary Language |


3.21.2

LanguageCommunication.modeCode :: CE (0..1)

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

LanguageCommunication.proficiencyLevelCode :: CE (0..1)

Vocabulary domain: LanguageAbilityProficiency (CWE)

Attribute description:

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


3.21.4

LanguageCommunication.preferenceInd :: BL (0..1)

Attribute description:

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


3.22

Class: LicensedEntity (in Roles)

recertificationTime :: TS

Description of LicensedEntity:

A relationship in which the scoper licenses the player to perform specific functions. Examples include the certification of equipment, as well as the granting of license to organizations or professionals.

Attributes of LicensedEntity:

3.22.1

LicensedEntity.recertificationTime :: TS (0..1)

Attribute description:

The date recertification is required.


3.23

Class: LivingSubject (in Entities)

administrativeGenderCode :: CE
birthTime :: TS
deceasedInd :: BL
deceasedTime :: TS
multipleBirthInd :: BL
birthOrderNumber :: INT
organDonorInd :: BL

NonPersonLivingSubject
Person

Description of LivingSubject:

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 LivingSubject:

3.23.1

LivingSubject.administrativeGenderCode :: CE (0..1)

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.

ExtRef: This information is reported on UB FL 15.

Version 2.x reference:

| NK1^15^00111^Sex |

| PID^8^00111^Sex |

| STF^5^00111^Sex |

| GT1^9^00413^Guarantor Sex |

| IN1^43^00468^Insured's Sex |


3.23.2

LivingSubject.birthTime :: TS (0..1)

Attribute description:

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

Version 2.x reference:

| NK1^16^00110^Date/Time of Birth |

| PID^7^00110^Date/Time of Birth |

| STF^6^00110^Date/Time of Birth |

| GT1^8^00412^Guarantor Date/Time of Birth |

| IN1^18^00443^Insured's Date of Birth |


3.23.3

LivingSubject.deceasedInd :: BL (0..1)

Attribute description:

An indication that the subject is dead.


3.23.4

LivingSubject.deceasedTime :: TS (0..1)

Attribute description:

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


3.23.5

LivingSubject.multipleBirthInd :: BL (0..1)

Attribute description:

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

Version 2.x reference:

| PID^24^00127^Multiple Birth Indicator |


3.23.6

LivingSubject.birthOrderNumber :: INT (0..1)

Attribute description:

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

Version 2.x reference:

| PID^25^00128^Birth Order |


3.23.7

LivingSubject.organDonorInd :: BL (0..1)

Attribute description:

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

Version 2.x reference:

| PD1^8^00760^Organ Donor |


3.24

Class: ManagedParticipation (in Acts)

id :: SET<II>
statusCode :: SET<CS>

Description of ManagedParticipation:

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 ManagedParticipation:

3.24.1

ManagedParticipation.id :: SET<II> (0..*)

Attribute description:

A unique identifier for a participation.


3.24.2

ManagedParticipation.statusCode :: SET<CS> (0..*)

Vocabulary domain: ManagedParticipationStatus (CNE)

Attribute description:

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


3.25

Class: ManufacturedMaterial (in Entities)

lotName :: ST
expirationTime :: TS
stabilityTime :: IVL<TS>

Container
Device

Description of ManufacturedMaterial:

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 ManufacturedMaterial:

3.25.1

ManufacturedMaterial.lotName :: ST (0..1)

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

ManufacturedMaterial.expirationTime :: TS (0..1)

Attribute description:

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


3.25.3

ManufacturedMaterial.stabilityTime :: IVL<TS> (0..1)

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 (determinerCode = 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 stabilityTime.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 stabilityTime.high TS beyond which the reagent is no longer considered useable for its normal testing purpose.


3.26

Class: Material (in Entities)

formCode :: CE

ManufacturedMaterial

Description of Material:

A Material is an Entity that excludes LivingSubjects 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 LivingSubject 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.26.1

Material.formCode :: CE (0..1)

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.

OpenIssue: Vocabulary domain should include, but is broader than, the DoseForm domain.


3.27

Class: NonPersonLivingSubject (in Entities)

taxonomicClassificationCode :: CE
breedCode :: CE
strainText :: ED
genderStatusCode :: CE
euthanasiaInd :: BL

Description of NonPersonLivingSubject:

A non-human living subject..

Attributes of NonPersonLivingSubject:

3.27.1

NonPersonLivingSubject.taxonomicClassificationCode :: CE (0..1)

Vocabulary domain: NonPersonLivingSubjectTaxonomicClassification (CWE)

Attribute description:

A code representing the taxonomy of the living subject.


3.27.2

NonPersonLivingSubject.breedCode :: CE (0..1)

Vocabulary domain: NonPersonLivingSubjectBreed (CWE)

Attribute description:

A code representing the breed of the living subject.


3.27.3

NonPersonLivingSubject.strainText :: ED (0..1)

Attribute description:

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


3.27.4

NonPersonLivingSubject.genderStatusCode :: CE (0..1)

Vocabulary domain: GenderStatus (CWE)

Attribute description:

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


3.27.5

NonPersonLivingSubject.euthanasiaInd :: BL (0..1)

Attribute description:

An indication that the living subject was euthanized.


3.28

Class: Observation (in Acts)

value :: ANY
interpretationCode :: SET<CE>
methodCode :: SET<CE>
targetSiteCode :: SET<CD>
derivationExpr :: ST

DiagnosticImage
PublicHealthCase

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

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

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.

OpenIssue: We should revisit the proper attribute to be used to transmit clinical documents.

Version 2.x reference:

| GT1^34^00145^Ambulatory Status |

| IN2^32^00145^Ambulatory Status |

| NK1^18^00145^Ambulatory Status |

| PV1^15^00145^Ambulatory Status |


3.28.2

Observation.interpretationCode :: SET<CE> (0..*)

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

Observation.methodCode :: SET<CE> (0..*)

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.typeCode and therefore does not need to be specified in Observation.methodCode.


3.28.4

Observation.targetSiteCode :: SET<CD> (0..*)

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

Observation.derivationExpr :: ST (0..1)

Attribute description:

Derived observations can be defined through association with other observations using relationships of derivation type (ActRelationship.typeCode = derivation.) For example, to define a derived observation for Mean Corpuscular Hemoglobin (MCH) one will associate the MCH observation with a Hemoglobin (HGB) observation (ActRelationship.sequence_nmb = 1) and a Red Blood cell Count (RBC) observation (ActRelationship.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 ActRelationship.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.29

Class: Organization (in Entities)

addr :: BAG<AD>
standardIndustryClassCode :: 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.29.1

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

Attribute description:

The postal and residential addresses of an organization.

Version 2.x reference:

| PID^11^00114^Patient Address |

| PID^12^00115^County Code |

| NK1^4^00193^Address |

| GT1^5^00409^Guarantor Address |

| GT1^17^00421^Guarantor Employer Address |

| IN1^5^00430^Insurance Company Address |

| IN1^19^00444^Insured's Address |

| IN1^44^00469^Insured's Employer Address |

| OM1^28^00613^Address of Outside Site(s) |


3.29.2

Organization.standardIndustryClassCode :: CE (0..1)

Vocabulary domain: OrganizationIndustryClass (CWE)

Attribute description:

The standard industry class code of the organization.


3.30

Class: Participation (in Acts)

typeCode :: CS
functionCode :: CD
contextControlCode :: CS
sequenceNumber :: INT
noteText :: ED
time :: IVL<TS>
modeCode :: CE
awarenessCode :: CE
signatureCode :: CS
signatureText :: ED

ManagedParticipation

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

Participation.typeCode :: CS (1..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.typeCode 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.functionCode is a mostly locally defined descriptor for the kind of professional activity carried out by the participant.

Version 2.x reference:

| IN1^20^00445^Assignment of Benefits |

| IN1^21^00446^Coordination of Benefits |

| IN1^22^00447^Coord of Ben. Priority |

| IN2^5^00476^Mail Claim Party |

| IN2^19^00490^Baby Coverage |

| IN2^59^00799^Policy Scope |


3.30.2

Participation.functionCode :: CD (0..1)

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

Participation.contextControlCode :: CS (0..1)

Vocabulary domain: ContextControlParticipation (CNE)

Attribute description:

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


3.30.4

Participation.sequenceNumber :: INT (0..1)

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

Participation.noteText :: ED (0..1)

Attribute description:

A textual or multimedia depiction of commentary related to Participation.


3.30.6

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

Attribute description:

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


3.30.7

Participation.modeCode :: CE (0..1)

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

Participation.awarenessCode :: CE (0..1)

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

Participation.signatureCode :: CS (0..1)

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


3.30.10

Participation.signatureText :: ED (0..1)

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.typeCode; 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.31

Class: Patient (in Roles)

confidentialityCode :: CE
veryImportantPersonCode :: CE

Description of Patient:

A relationship between a LivingSubject 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.31.1

Patient.confidentialityCode :: CE (0..1)

Vocabulary domain: Confidentiality (CWE)

Attribute description:

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

Version 2.x reference:

| GT1^38^00743^Publicity Indicator |

| IN2^36^00743^Publicity Indicator |

| NK1^22^00743^Publicity Indicator |

| PD1^11^00743^Publicity Indicator |

| GT1^39^00744^Protection Indicator |

| IN2^37^00744^Protection Indicator |

| NK1^23^00744^Protection Indicator |

| PD1^12^00744^Protection Indicator |


3.31.2

Patient.veryImportantPersonCode :: CE (0..1)

Vocabulary domain: PatientImportance (CWE)

Attribute description:

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

Version 2.x reference:

| PV1^16^00146^VIP Indicator |


3.32

Class: PatientEncounter (in Acts)

admissionSourceCode :: CE
referralSourceCode :: CE
lengthOfStayQuantity :: PQ
dischargeDispositionCode :: CE
birthEncounterInd :: BL
acuityLevelCode :: CE
urgencyCode :: CE
preAdmitTestInd :: BL
specialCourtesiesCode :: SET<CE>
specialAccommodationCode :: SET<CE>

Description of PatientEncounter:

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.

OpenIssue: States of patient encounter (#234).

Attributes of PatientEncounter:

3.32.1

PatientEncounter.admissionSourceCode :: CE (0..1)

Vocabulary domain: EncounterAdmissionSource (CWE)

Attribute description:

The source of the referral for a patient encounter.


3.32.2

PatientEncounter.referralSourceCode :: CE (0..1)

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

Version 2.x reference:

| PV1^14^00144^Admit Source |


3.32.3

PatientEncounter.lengthOfStayQuantity :: PQ (0..1)

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.

OpenIssue: Should there be a Boolean indicator to specify "estimated" vs. "actual" rather than having this attribute mean two things?

Version 2.x reference:

| PV2^11^00712^Actual Length of Inpatient Stay |


3.32.4

PatientEncounter.dischargeDispositionCode :: CE (0..1)

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

Version 2.x reference:

| PV1^36^00166^Discharge Disposition |


3.32.5

PatientEncounter.birthEncounterInd :: BL (0..1)

Attribute description:

A indication that the LivingSubject was born during this PatientEncounter.

Version 2.x reference:

| PV2^36^00737^Newborn Baby Indicator |


3.32.6

PatientEncounter.acuityLevelCode :: CE (0..1)

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

PatientEncounter.urgencyCode :: CE (0..1)

Vocabulary domain: EncounterAdmissionUrgency (CWE)


3.32.8

PatientEncounter.preAdmitTestInd :: BL (0..1)

Attribute description:

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

Version 2.x reference:

| PV1^12^00142^Preadmit Test Indicator |


3.32.9

PatientEncounter.specialCourtesiesCode :: SET<CE> (0..*)

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.

Version 2.x reference:

| PV1^22^00152^Courtesy Code |


3.32.10

PatientEncounter.specialAccommodationCode :: SET<CE> (0..*)

Vocabulary domain: SpecialAccommodation (CWE)

Attribute description:

A code indicating the type of special accommodations provided for a patient encounter (e.g., wheelchair, stretcher, interpreter, attendant, seeing eye dog). For encounters in intention moods, this information can be used to identify special arrangements that will need to be made for the incoming patient.


3.33

Class: Person (in Entities)

addr :: BAG<AD>
maritalStatusCode :: CE
educationLevelCode :: CE
disabilityCode :: CE
livingArrangementCode :: CE
religiousAffiliationCode :: CE
raceCode :: SET<CE>
ethnicGroupCode :: SET<CE>

Description of Person:

An individual human being.

Attributes of Person:

3.33.1

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

Attribute description:

The address(es) of a Person.

Version 2.x reference:

| PID^11^00114^Patient Address |

| PID^12^00115^County Code |

| NK1^4^00193^Address |

| GT1^5^00409^Guarantor Address |

| GT1^17^00421^Guarantor Employer Address |

| IN1^5^00430^Insurance Company Address |

| IN1^19^00444^Insured's Address |

| IN1^44^00469^Insured's Employer Address |

| OM1^28^00613^Address of Outside Site(s) |


3.33.2

Person.maritalStatusCode :: CE (0..1)

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

OpenIssue: It is not clear what the temporal values are and whether or not items such as divorced/married are mutually exclusive.

OpenIssue: Probably competing existing code schemes.

Version 2.x reference:

| IN2^43^00119^Marital Status |

| NK1^14^00119^Marital Status |

| PID^16^00119^Marital Status |

| STF^17^00119^Marital Status |

| GT1^30^00781^Guarantor Marital Status Code |


3.33.3

Person.educationLevelCode :: CE (0..1)

Vocabulary domain: EducationLevel (CWE)

Attribute description:

The amount of education a person achieved.

OpenIssue: Need example values.


3.33.4

Person.disabilityCode :: CE (0..1)

Vocabulary domain: PersonDisabilityType (CWE)

Attribute description:

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

OpenIssue: Need example values.

Version 2.x reference:

| GT1^52^00753^Handicap |

| IN1^48^00753^Handicap |

| NK1^36^00753^Handicap |

| PD1^6^00753^Handicap |


3.33.5

Person.livingArrangementCode :: CE (0..1)

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.

Version 2.x reference:

| GT1^37^00742^Living Arrangement |

| IN2^35^00742^Living Arrangement |

| NK1^21^00742^Living Arrangement |

| PD1^2^00742^Living Arrangement |


3.33.6

Person.religiousAffiliationCode :: CE (0..1)

Vocabulary domain: ReligiousAffiliation (CWE)

Attribute description:

A person's religious preference.

OpenIssue: Need example values.

Version 2.x reference:

| GT1^41^00120^Religion |

| IN2^39^00120^Religion |

| NK1^25^00120^Religion |

| PID^17^00120^Religion |


3.33.7

Person.raceCode :: SET<CE> (0..*)

Vocabulary domain: Race (CWE)

Attribute description:

A code depicting the race of a person.

Version 2.x reference:

| IN2^71^00113^Race |

| NK1^35^00113^Race |

| PID^10^00113^Race |


3.33.8

Person.ethnicGroupCode :: SET<CE> (0..*)

Vocabulary domain: Ethnicity (CWE)

Attribute description:

The ethnic group of the person.

OpenIssue: Knowing that this repeats, it may be required that a 'primary' in the list is required as well. There is currently no mechanism to identify the primary in the set in the HMD.

OpenIssue: Need example values.

Version 2.x reference:

| GT1^44^00125^Ethnic Group |

| IN2^42^00125^Ethnic Group |

| NK1^28^00125^Ethnic Group |

| PID^22^00125^Ethnic Group |


3.34

Class: Place (in Entities)

mobileInd :: BL
addr :: AD
directionsText :: ED
positionText :: ED
gpsText :: 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.34.1

Place.mobileInd :: BL (0..1)

Attribute description:

Indicates whether the facility is considered mobile.


3.34.2

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

Attribute description:

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

Version 2.x reference:

| RXD^13^00299^Deliver-to Location |

| RXE^8^00299^Deliver-to Location |

| RXG^11^00299^Deliver-to Location |

| RXO^8^00299^Deliver-to Location |

| RXA^11^00353^Administered-at Location |

| LOC^5^00948^Location Address |

| RXD^13^01303^Dispense-to Location |

| RXG^11^01303^Dispense-to Location |


3.34.3

Place.directionsText :: ED (0..1)

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

ExtRef: PHCDM-02.01.04.01


3.34.4

Place.positionText :: ED (0..1)

Attribute description:

A set of codes that locates the site within a mapping scheme. For example, map coordinates for US Geological Survey maps.


3.34.5

Place.gpsText :: ST (0..1)

Attribute description:

GPS coordinates of the place.

OpenIssue: This is really the GPS coordinates, and needs a different data type to capture the integers. Also, it needs a description.


3.35

Class: Procedure (in Acts)

methodCode :: SET<CE>
approachSiteCode :: SET<CD>
targetSiteCode :: 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.35.1

Procedure.methodCode :: SET<CE> (0..*)

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.moodCode = DEF) the methodCode attribute is a set of all available method codes that a user may select while ordering, or expect while receiving results.


3.35.2

Procedure.approachSiteCode :: SET<CD> (0..*)

Vocabulary domain: ActSite (CWE)

Attribute description:

The anatomical site or system through which the procedure reaches its target (see targetSiteCode.) 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.35.3

Procedure.targetSiteCode :: SET<CD> (0..*)

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

Class: PublicHealthCase (in Acts)

detectionMethodCode :: CE
transmissionModeCode :: CE
diseaseImportedCode :: CE

Description of PublicHealthCase:

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

OpenIssue: Need to work to broaden the concept, the name and the description.

Attributes of PublicHealthCase:

3.36.1

PublicHealthCase.detectionMethodCode :: CE (0..1)

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

PublicHealthCase.transmissionModeCode :: CE (0..1)

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.

OpenIssue: Consider moving this attribute to Observation.


3.36.3

PublicHealthCase.diseaseImportedCode :: CE (0..1)

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

Class: Referral (in Acts)

authorizedVisitsQuantity :: 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.

OpenIssue: What is the distinction between the reason_text and the desc attributes? Their descriptions do not reveal the difference, nor does the class description.

Attributes of Referral:

3.37.1

Referral.authorizedVisitsQuantity :: REAL (0..1)

Attribute description:

The number of authorized referral visits.

OpenIssue: Unclear what this attribute does, how it is used, and whether it belongs here. Authorized_visits_quantity sounds more like a property of a health coverage.


3.38

Class: Role (in Roles)

classCode :: CS
id :: SET<II>
code :: CE
negationInd :: BL
addr :: BAG<AD>
telecom :: BAG<TEL>
statusCode :: SET<CS>
effectiveTime :: IVL<TS>
certificateText :: ED
quantity :: RTO
positionNumber :: LIST<INT>

Access
AssignedEntity
Employee
Guarantor
LicensedEntity
Patient
RoleHeir
SchedulableResource

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

Role.classCode :: CS (1..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.38.2

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

Attribute description:

A unique identifier for the Role.


3.38.3

Role.code :: CE (0..1)

Vocabulary domain: RoleCode (CWE)

Attribute description:

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


3.38.4

Role.negationInd :: BL (0..1)

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

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

Attribute description:

An address specification applicable the Entity while in the Role.

Version 2.x reference:

| PID^11^00114^Patient Address |

| PID^12^00115^County Code |

| NK1^4^00193^Address |

| GT1^5^00409^Guarantor Address |

| GT1^17^00421^Guarantor Employer Address |

| IN1^5^00430^Insurance Company Address |

| IN1^19^00444^Insured's Address |

| IN1^44^00469^Insured's Employer Address |

| OM1^28^00613^Address of Outside Site(s) |


3.38.6

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

Attribute description:

A telecommunication address for the Role.

Version 2.x reference:

| PID^13^00116^Phone Number - Home |

| NK1^6^00195^Business Phone Number |

| GT1^6^00410^Guarantor Ph Num- Home |

| GT1^7^00411^Guarantor Ph Num-Business |

| GT1^18^00422^Guarantor Employer Phone Number |

| IN1^7^00432^Insurance Co Phone Number |

| IN3^16^00517^Certification Contact Phone Number |

| IN3^19^00520^Certification Agency Phone Number |

| OM1^17^00602^Telephone Number of Section |

| OM1^29^00614^Phone Number of Outside Site |

| GT1^46^00749^Contact Person's Telephone Number |

| NK1^31^00749^Contact Person's Telephone Number |

| IN2^50^00790^Employer Contact Person Phone Number |

| IN2^53^00793^Insured's Contact Person Telephone Number |

| IN2^58^00798^Insurance Co Contact Phone Number |

| IN2^63^00803^Insured's Telephone Number - Home |

| IN2^64^00804^Insured's Employer Telephone Number |


3.38.7

Role.statusCode :: SET<CS> (0..*)

Vocabulary domain: RoleStatus (CNE)

Attribute description:

A code specifying the state of Role.

Version 2.x reference:

| PID^27^00130^Veterans Military Status |


3.38.8

Role.effectiveTime :: IVL<TS> (0..1)

Attribute description:

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


3.38.9

Role.certificateText :: ED (0..1)

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

Role.quantity :: RTO (0..1)

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 quantity is 75 mg : 0.6 mL. Both numerator and denominator must be amount quantities (refer to the Entity.quantity definition).


3.38.11

Role.positionNumber :: LIST<INT> (0..*)

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

Class: RoleHeir (in Roles)

Description of RoleHeir:

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

Class: RoleLink (in Roles)

typeCode :: CS
effectiveTime :: IVL<TS>

Description of RoleLink:

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

RoleLink 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 RoleLink:

3.40.1

RoleLink.typeCode :: CS (1..1) Mandatory

Vocabulary domain: RoleLinkType (CNE)

Attribute description:

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


3.40.2

RoleLink.effectiveTime :: IVL<TS> (0..1)

Attribute description:

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


3.41

Class: SchedulableResource (in Roles)

slotSizeIncrementQuantity :: PQ

Description of SchedulableResource:

A Role of an Entity that can be scheduled.

Attributes of SchedulableResource:

3.41.1

SchedulableResource.slotSizeIncrementQuantity :: PQ (0..1)

Attribute description:

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

OpenIssue: Not sure what this means.


3.42

Class: SubstanceAdministration (in Acts)

routeCode :: CE
approachSiteCode :: SET<CD>
doseQuantity :: IVL<PQ>
rateQuantity :: IVL<PQ>
doseCheckQuantity :: SET<RTO>
maxDoseQuantity :: SET<RTO>
potencyQuantity :: PQ
substitutionCode :: CE

Description of SubstanceAdministration:

SubstanceAdministration 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 SubstanceAdministration:

3.42.1

SubstanceAdministration.routeCode :: CE (0..1)

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

OpenIssue: should a specialized routeCode be replaced by a general anatomic site code.


3.42.2

SubstanceAdministration.approachSiteCode :: SET<CD> (0..*)

Vocabulary domain: ActSite (CWE)

Attribute description:

The detailed anatomical site where the medication is routed. Note, this attribute is only needed if the routeCode requires further specification. For example, if the routeCode is "by mouth", no further specification of approach site is needed. If, however, routeCode is intravenous or intra-muscular, the precise site may be specified in this attribute (e.g., right forearm or left deltoid muscle respectively.)

OpenIssue: There is some overlap with routeCode. Will have to determine if body site is better to be included with route or if it is better to try to split route and body site (so that for instance "SQ" is a route, while "left forearm" is the body site.


3.42.3

SubstanceAdministration.doseQuantity :: IVL<PQ> (0..1)

Attribute description:

The doseQuantity 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_quantity attribute, the use of attributes such as doseQuantity and doseCheckQuantity 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, doseQuantity 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.42.4

SubstanceAdministration.rateQuantity :: IVL<PQ> (0..1)

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.rateQuantity is specified as a physical quantity in time (a duration.) Hence, the rateQuantity is really the denominator of the dose rate (the doseQuantity is the numerator). For example, if a Ringer's solution is to be given at 100 mL/hour i.v., the doseQuantity would be 100 mL and the rateQuantity would be 1 h. Note that there is no difference in the actual values of doseQuantity and rateQuantity as long as the quotient of both has the same value. In this example, we could just as well specify doseQuantity as 50 mL and rateQuantity 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 doseQuantity attribute specifying the rate right in that one attribute (e.g., doseQuantity = 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 doseQuantity 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_doseQuantity = doseQuantity x strength_quantity / rateQuantity.


3.42.5

SubstanceAdministration.doseCheckQuantity :: SET<RTO> (0..*)

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 doseCheckQuantity attribute of the Ratio (RTO) data type. The numerator must be comparable to the doseQuantity 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 "doseCheckQuantity = doseQuantity (1) * strength_quantity (250 mg) * activity_dttm (3 /d) = 750 mg/d."

For an intravenous example, this term would be "doseCheckQuantity = doseQuantity (100 ml) * strength_quantity (1) / rateQuantity (1 h) = 100 mL/h" which can be calculated on a daily basis as "doseCheckQuantity = 100 mL/h * 24 h/d = 2400 mL/d = 2.4 L/d."

Rationale: This attribute incurs a constraint: invariant(SubstanceAdministration med, RTO max) where med.max_doseQuantity.contains(max) { max.numerator.compares(med.doseQuantity); max.denominator.compares(1 s);}


3.42.6

SubstanceAdministration.maxDoseQuantity :: SET<RTO> (0..*)

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 quantity as numerator and a time duration as denominator, e.g. 500 mg/day; 1200mg/week.

Rationale: This attribute requires a constraint: invariant(SubstanceAdministration med, RTO max) where med.max_doseQuantity.contains(max) { max.numerator.compares(med.doseQuantity); max.denominator.compares(1 s);}


3.42.7

SubstanceAdministration.potencyQuantity :: PQ (0..1)

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

SubstanceAdministration.substitutionCode :: CE (0..1)

Vocabulary domain: SubstanceAdminSubstitution (CWE)

Attribute description:

Indicates whether an ordered or intended SubstanceAdministration may be or has been substituted for a different SubstanceAdministration. 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 SubstanceAdministration.substitutionCode 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.43

Class: Supply (in Acts)

quantity :: PQ
expectedUseTime :: 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.typeCode="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 SubstanceAdministration Act. The SubstanceAdministration class represents the administration of medication, while dispensing is supply.

Attributes of Supply:

3.43.1

Supply.quantity :: PQ (0..1)

Attribute description:

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


3.43.2

Supply.expectedUseTime :: IVL<TS> (0..1)

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.quantity 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.quantity, as this tends to be more precise. Supply.expectedUseTime will always be an estimate that can be influenced by external factors.


3.44

Class: WorkingList (in Acts)

ownershipLevelCode :: CE

Description of WorkingList:

WorkingList collects a dynamic list of individual instances of Act via ActRelationship 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.

OpenIssue: The name is too generic. This needs to be harmonized with Scheduling.

Attributes of WorkingList:

3.44.1

WorkingList.ownershipLevelCode :: CE (0..1)

Vocabulary domain: ListOwnershipLevel (CWE)

Attribute description:

Ownership_levelCode 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.45

Class: Acknowledgement (in MessageControl)

typeCode :: CS
errorDetailCode :: CE
noteText :: ED
expectedSequenceNumber :: INT

Description of Acknowledgement:

The Acknowledgement class contains information sent when acknowledging another message.

Attributes of Acknowledgement:

3.45.1

Acknowledgement.typeCode :: CS (0..1)

Vocabulary domain: AcknowledgementType (CNE)

Attribute description:

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

Version 2.x reference:

| MSA^1^00018^Acknowledgement Code |


3.45.2

Acknowledgement.errorDetailCode :: CE (0..1)

Vocabulary domain: MessageCondition (CWE)

Attribute description:

This attribute allows for a coded error type.

Version 2.x reference:

| MSA^6^00023^Error Condition |


3.45.3

Acknowledgement.noteText :: ED (0..1)

Attribute description:

This attribute further describes an error condition. This text may be printed in error logs or presented to an end user.

Version 2.x reference:

| MSA^3^00020^Text Message |


3.45.4

Acknowledgement.expectedSequenceNumber :: INT (0..1)

Attribute description:

This attribute is used in the sequence number protocol.

Version 2.x reference:

| MSA^4^00021^Expected Sequence Number |


3.46

Class: AttentionLine (in MessageControl)

keyWordText :: ST
value :: ST

Description of AttentionLine:

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

Attributes of AttentionLine:

3.46.1

AttentionLine.keyWordText :: ST (0..1)

Attribute description:

A parameter defining word.


3.46.2

AttentionLine.value :: ST (0..1)

Attribute description:

A parameter value.


3.47

Class: Batch (in MessageControl)

referenceControlId :: II
name :: ST
batchComment :: SET<ST>
transmissionQuantity :: INT
batchTotalNumber :: 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.

OpenIssue: To be resolved when future work completed.

Attributes of Batch:

3.47.1

Batch.referenceControlId :: II (0..1)

Attribute description:

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

Version 2.x reference:

| BHS^12^00092^Reference Batch Control ID |


3.47.2

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

Attribute description:

This attribute is used by the application processing the batch.

Version 2.x reference:

| BHS^9^00089^Batch Name/ID/Type |


3.47.3

Batch.batchComment :: SET<ST> (0..*)

Attribute description:

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

Version 2.x reference:

| BHS^10^00090^Batch Comment |

| BTS^2^00090^Batch Comment |


3.47.4

Batch.transmissionQuantity :: INT (0..1)

Attribute description:

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


3.47.5

Batch.batchTotalNumber :: SET<INT> (0..*)

Attribute description:

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

Version 2.x reference:

| BTS^3^00095^Batch Totals |


3.48

Class: ClinicalDocument (in StructuredDocuments)

setId :: II
versionNumber :: INT
completionCode :: CE
storageCode :: CE
copyTime :: TS

Description of ClinicalDocument:

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

Attributes of ClinicalDocument:

3.48.1

ClinicalDocument.setId :: II (0..1)

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.setId, and has the value of document_service.versionNumber 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.typeCode 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.setId as the parent report being replaced, and increments the value of document_serivce.versionNumber 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.48.2

ClinicalDocument.versionNumber :: INT (0..1)

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

ClinicalDocument.completionCode :: CE (0..1)

Vocabulary domain: DocumentCompletion (CWE)

Attribute description:

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


3.48.4

ClinicalDocument.storageCode :: CE (0..1)

Vocabulary domain: DocumentStorage (CWE)

Attribute description:

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


3.48.5

ClinicalDocument.copyTime :: TS (0..1)

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

Class: CommunicationFunction (in MessageControl)

typeCode :: CS
telecom :: TEL

Description of CommunicationFunction:

Relationship class binds the various entities which function in the transmission (sender, receiver, respond-to) to be linked to the transmission.

Attributes of CommunicationFunction:

3.49.1

CommunicationFunction.typeCode :: CS (0..1)

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

CommunicationFunction.telecom :: TEL (0..1)

Attribute description:

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


3.50

Class: ContextStructure (in StructuredDocuments)

localId :: ST

ClinicalDocument
LinkHtml
LocalAttr
LocalMarkup
Table
TableStructure

Description of ContextStructure:

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 ContextStructure:

3.50.1

ContextStructure.localId :: ST (0..1)

Attribute description:

An optional identifier which must be unique within the document.


3.51

Class: ControlAct (in MessageControl)

structureTypeId :: II
responseCode :: CS

Description of ControlAct:

An act representing a system action such as the change of state of another act or the initiation of a query. All control acts represent trigger events in the HL7 context. ControlActs may occur in different moods.

OpenIssue: Look at the symmetry between how messages and documents are structured. This is work that is yet to be completed.

Attributes of ControlAct:

3.51.1

ControlAct.structureTypeId :: II (0..1)

Attribute description:

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


3.51.2

ControlAct.responseCode :: CS (0..1)

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

Class: LinkHtml (in StructuredDocuments)

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

Description of LinkHtml:

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

Attributes of LinkHtml:

3.52.1

LinkHtml.href :: ED (0..1)

Attribute description:

This attribute is part of the HTML anchor tag.


3.52.2

LinkHtml.name :: ST (0..1)

Attribute description:

This attribute is part of the HTML anchor tag.


3.52.3

LinkHtml.rel :: SET<CE> (0..*)

Vocabulary domain: HtmlLinkType ()

Attribute description:

This attribute is part of the HTML anchor tag.


3.52.4

LinkHtml.rev :: SET<CE> (0..*)

Vocabulary domain: HtmlLinkType ()

Attribute description:

This attribute is part of the HTML anchor tag.


3.52.5

LinkHtml.title :: ST (0..1)

Attribute description:

This attribute is part of the HTML anchor tag.


3.53

Class: LocalAttr (in StructuredDocuments)

name :: ST
value :: ST

Description of LocalAttr:

A component used to map local semantics into the exchange standard when local semantics have not yet been standardized.

Attributes of LocalAttr:

3.53.1

LocalAttr.name :: ST (0..1)

Attribute description:

The name of the local attribute.


3.53.2

LocalAttr.value :: ST (0..1)

Attribute description:

The value of the local attribute.


3.54

Class: LocalMarkup (in StructuredDocuments)

descriptor :: ST
render :: ST
ignoreCode :: CS

Description of LocalMarkup:

A component used to map local semantics into the exchange standard when local semantics have not yet been standardized.

Attributes of LocalMarkup:

3.54.1

LocalMarkup.descriptor :: ST (0..1)

Attribute description:

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


3.54.2

LocalMarkup.render :: ST (0..1)

Attribute description:

The render attribute indicates how the sender would render the contents. The value can be drawn from a local vocabulary domain.


3.54.3

LocalMarkup.ignoreCode :: CS (0..1)

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

Class: LogicalExpression (in MessageControl)

relationalConjunctionCode :: CS

Attributes of LogicalExpression:

3.55.1

LogicalExpression.relationalConjunctionCode :: CS (0..1)

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.

Version 2.x reference:

| VTQ^5^00700^Selection Criteria |


3.56

Class: Message (in MessageControl)

versionId :: ST
interactionId :: II
profileId :: SET<II>
processingCode :: CS
processingModeCode :: CS
acceptAckCode :: CS
applicationAckCode :: CS
sequenceNumber :: INT
attachmentText :: SET<ED>

Description of Message:

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

Attributes of Message:

3.56.1

Message.versionId :: ST (0..1)

Attribute description:

This attribute is matched by the receiving system to its own version to be sure the message will be interpreted correctly.

Version 2.x reference:

| MSH^12^00012^Version ID |


3.56.2

Message.interactionId :: II (0..1)

Attribute description:

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

Version 2.x reference:

| MSH^9^00009^Message Type |


3.56.3

Message.profileId :: SET<II> (0..*)

Attribute description:

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


3.56.4

Message.processingCode :: CS (0..1)

Vocabulary domain: ProcessingID (CNE)

Attribute description:

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

Version 2.x reference:

| MSH^11^00011^Processing ID |


3.56.5

Message.processingModeCode :: CS (0..1)

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.

Version 2.x reference:

| MSH^11^00011^Processing ID |


3.56.6

Message.acceptAckCode :: CS (0..1)

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.

Version 2.x reference:

| MSH^15^00015^Accept Acknowledgement Type |


3.56.7

Message.applicationAckCode :: CS (0..1)

Vocabulary domain: AcknowledgmentCondition (CNE)

Attribute description:

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

Version 2.x reference:

| MSH^16^00016^Application Acknowledgement Type |


3.56.8

Message.sequenceNumber :: INT (0..1)

Attribute description:

This attribute is provided for implementing the sequence number protocol. This field is incremented by one for each subsequent value assignment.

Version 2.x reference:

| MSH^13^00013^Sequence Number |


3.56.9

Message.attachmentText :: SET<ED> (0..*)

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.

OpenIssue: Constrain the use of the ED data type in the attachment message type. Additionally, the appropriateness of this attribute in the Message class is in question. An alternative to consider would be the placement of this attribute in a new class maintaining a 0 to many relationship with the Message class.


3.57

Class: Parameter (in MessageControl)

id :: II
name :: ST

ParameterItem
ParameterList

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

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

Attribute description:

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


3.57.2

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

Attribute description:

In a ParameterList, 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.58

Class: ParameterItem (in MessageControl)

value :: ANY
semanticsText :: ST

Description of ParameterItem:

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

Attributes of ParameterItem:

3.58.1

ParameterItem.value :: ANY (0..1)

Attribute description:

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


3.58.2

ParameterItem.semanticsText :: ST (0..1)

Vocabulary domain: String (CWE)

Attribute description:

The ParameterItem.typeCode attribute provides a unique identification to an element within a specified query response structure.


3.59

Class: ParameterList (in MessageControl)

Description of ParameterList:

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

3.60

Class: QueryAck (in MessageControl)

messageQueryCode :: CE
queryResponseCode :: CS
resultTotalQuantity :: INT
resultCurrentQuantity :: INT
resultRemainingQuantity :: INT

Description of QueryAck:

This class carries information sent with responses to a query.

Attributes of QueryAck:

3.60.1

QueryAck.messageQueryCode :: CE (0..1)

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.

OpenIssue: Should this attribute be represented by an Instance Identifier (OID+ extension) or a code value within an HL7 vocabulary domain that can be extended by implementers of the standard?


3.60.2

QueryAck.queryResponseCode :: CS (0..1)

Vocabulary domain: QueryStatus (CNE)

Attribute description:

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

Version 2.x reference:

| QAK^2^00708^Query Response Status |


3.60.3

QueryAck.resultTotalQuantity :: INT (0..1)

Attribute description:

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


3.60.4

QueryAck.resultCurrentQuantity :: INT (0..1)

Attribute description:

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


3.60.5

QueryAck.resultRemainingQuantity :: INT (0..1)

Attribute description:

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


3.61

Class: QueryByParameter (in MessageControl)

Description of QueryByParameter:

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

Class: QueryBySelection (in MessageControl)

Description of QueryBySelection:

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

Class: QueryContinuation (in MessageControl)

startResultNumber :: INT
continuationQuantity :: INT

Description of QueryContinuation:

This class maintains the state information required at the application level to control the logical continuation of a query response.

Attributes of QueryContinuation:

3.63.1

QueryContinuation.startResultNumber :: INT (0..1)

Attribute description:

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


3.63.2

QueryContinuation.continuationQuantity :: INT (0..1)

Attribute description:

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


3.64

Class: QueryEvent (in MessageControl)

queryId :: II
statusCode :: CS

QueryAck
QueryContinuation
QuerySpec

Description of QueryEvent:

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.

OpenIssue: State names need to be re-visited.

Attributes of QueryEvent:

3.64.1

QueryEvent.queryId :: II (0..1)

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. QueryEvent.queryId may remain the same across multiple interactions when performing continuations of a previous query.


3.64.2

QueryEvent.statusCode :: CS (0..1) Mandatory

Vocabulary domain: QueryEventStatus ()


3.65

Class: QuerySpec (in MessageControl)

messageQueryCode :: CE
modifyCode :: CS
responseElementGroupId :: SET<II>
responseModalityCode :: CS
responsePriorityCode :: CS
initialQuantity :: INT
initialQuantityCode :: CE
executionAndDeliveryTime :: TS

QueryByParameter
QueryBySelection

Description of QuerySpec:

This class contains the specification of all HL7 Version 3 queries. Attributes common to all queries appear in this class specification.

Attributes of QuerySpec:

3.65.1

QuerySpec.messageQueryCode :: CE (0..1)

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.

OpenIssue: Should this attribute be represented by an Instance Identifier (OID + extension) or a code value within an HL7 vocabulary domain that can be extended by implementers of the standard?

OpenIssue: Can the "Message.profileId" attribute provide a means of supporting the need to have a mechanism for local implementations to specify query response pairs as local business requirements dictate.

OpenIssue: In Version 3, must we have an explicity interaction set defined for any ad hoc query request/query response pair that may want to be implemented? If it is reasonable to support local implementations of query request/query response interaction pairs with (1) a generic query mechanism that allows specific query interaction pairs to be exchanged using a set of standard query interactions and (2) a protocol for passing parameters which can allow applications to customize for local business requirements?


3.65.2

QuerySpec.modifyCode :: CS (0..1)

Vocabulary domain: ModifyIndicator (CNE)

Attribute description:

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


3.65.3

QuerySpec.responseElementGroupId :: SET<II> (0..*)

Attribute description:

The responseElementGroupId 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.65.4

QuerySpec.responseModalityCode :: CS (0..1)

Vocabulary domain: ResponseModality (CNE)

Attribute description:

Defines the timing and grouping of the response instances.


3.65.5

QuerySpec.responsePriorityCode :: CS (0..1)

Vocabulary domain: QueryPriority (CNE)

Attribute description:

Identifies the time frame in which the response is expected.

Version 2.x reference:

| QRD^3^00027^Query Priority |


3.65.6

QuerySpec.initialQuantity :: INT (0..1)

Attribute description:

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

Version 2.x reference:

| QRD^7^00031^Quantity Limited Request |


3.65.7

QuerySpec.initialQuantityCode :: CE (0..1)

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

QuerySpec.executionAndDeliveryTime :: TS (0..1)

Attribute description:

Specifies the time the response is to be returned.


3.66

Class: RelationalExpression (in MessageControl)

elementName :: ST
relationalOperatorCode :: CS
value :: ST

Attributes of RelationalExpression:

3.66.1

RelationalExpression.elementName :: ST (0..1)

Attribute description:

Identifies RIM element as subject of selection criteria evaluation.


3.66.2

RelationalExpression.relationalOperatorCode :: CS (0..1)

Vocabulary domain: RelationalOperator (CNE)

Attribute description:

Identifies common relational operators used in selection criteria.

Version 2.x reference:

| VTQ^5^00700^Selection Criteria |


3.66.3

RelationalExpression.value :: ST (0..1)

Attribute description:

Value supplied for comparison using criteria.

Version 2.x reference:

| VTQ^5^00700^Selection Criteria |


3.67

Class: SelectionExpression (in MessageControl)

LogicalExpression
RelationalExpression

3.68

Class: SortControl (in MessageControl)

sequenceNumber :: INT
elementName :: ST
directionCode :: CS

Description of SortControl:

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

Attributes of SortControl:

3.68.1

SortControl.sequenceNumber :: INT (0..1)


3.68.2

SortControl.elementName :: ST (0..1)

Attribute description:

Identifies a RIM element in a query response.


3.68.3

SortControl.directionCode :: CS (0..1)

Vocabulary domain: Sequencing (CNE)

Attribute description:

Specifies sequence of sort order.


3.69

Class: Table (in StructuredDocuments)

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

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

Attribute description:

This attribute is part of the XHTML table model.


3.69.2

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

Attribute description:

This attribute is part of the XHTML table model.


3.69.3

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

Vocabulary domain: TableRules (CNE)

Attribute description:

This attribute is part of the XHTML table model.


3.69.4

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

Attribute description:

This attribute is part of the XHTML table model.


3.69.5

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

Attribute description:

This attribute is part of the XHTML table model.


3.69.6

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

Attribute description:

This attribute is part of the XHTML table model.


3.69.7

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

Vocabulary domain: TableFrame (CNE)

Attribute description:

This attribute is part of the XHTML table model.


3.70

Class: TableCell (in StructuredDocuments)

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

Description of TableCell:

A cell in a table.

Attributes of TableCell:

3.70.1

TableCell.scope :: CS (0..1)

Vocabulary domain: TableCellScope (CNE)

Attribute description:

This attribute is part of the XHTML table model.


3.70.2

TableCell.abbr :: ST (0..1)

Attribute description:

This attribute is part of the XHTML table model.


3.70.3

TableCell.axis :: ST (0..1)

Attribute description:

This attribute is part of the XHTML table model.


3.70.4

TableCell.colspan :: INT (0..1)

Attribute description:

This attribute is part of the XHTML model.


3.70.5

TableCell.headers :: SET<ED> (0..*)

Attribute description:

This attribute is part of the XHTML table model.


3.70.6

TableCell.rowspan :: INT (0..1)

Attribute description:

This attribute is part of the XHTML model.


3.71

Class: TableColumnStructure (in StructuredDocuments)

span :: INT
width :: ST

Description of TableColumnStructure:

A table column or column group.

Attributes of TableColumnStructure:

3.71.1

TableColumnStructure.span :: INT (0..1)

Attribute description:

This attribute is part of the XHTML table model.


3.71.2

TableColumnStructure.width :: ST (0..1)

Attribute description:

This attribute is part of the XHTML table model.


3.72

Class: TableStructure (in StructuredDocuments)

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

TableCell
TableColumnStructure

Description of TableStructure:

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

Attributes of TableStructure:

3.72.1

TableStructure.char :: ST (0..1)

Attribute description:

This attribute is part of the XHTML table model.


3.72.2

TableStructure.charoff :: ST (0..1)

Attribute description:

This attribute is part of the XHTML table model.


3.72.3

TableStructure.halign :: CS (0..1)

Vocabulary domain: TableCellHorizontalAlign (CNE)

Attribute description:

This attribute is part of the XHTML table model.


3.72.4

TableStructure.valign :: CS (0..1)

Vocabulary domain: TableCellVerticalAlign (CNE)

Attribute description:

This attribute is part of the XHTML table model.


3.73

Class: Transmission (in MessageControl)

id :: II
creationTime :: TS
securityText :: ST

Batch
Message

Description of Transmission:

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

Attributes of Transmission:

3.73.1

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

Attribute description:

Unique identifier of the transmission

Version 2.x reference:

| MSA^2^00010^Message Control ID |

| MSH^10^00010^Message Control ID |

| FHS^11^00077^File Control ID |

| BHS^11^00091^Batch Control ID |


3.73.2

Transmission.creationTime :: TS (0..1)

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.

Version 2.x reference:

| MSH^7^00007^Date/Time of Message |

| FHS^7^00073^File Creation Date/Time |

| BHS^7^00087^Batch Creation Date/Time |


3.73.3

Transmission.securityText :: ST (0..1)

Attribute description:

This attribute is specified for applications to implement security features for a transmission. Its uses is not further specified at this time.

Version 2.x reference:

| FHS^8^00074^File Security |

| BHS^8^00088^Batch Security |


4

Associations in HL7 Reference Information Model

4.1

(1..*)   Acknowledgement :: acknowledgedMessage :: (1..1) Message :: acknowledgement

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

4.2

(1..1)   Acknowledgement :: acknowledgingMessage :: (1..1) Message :: payload

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

4.3

(0..*)   ActRelationship :: source :: (1..1) Act :: outboundRelationship

4.4

(0..*)   ActRelationship :: target :: (1..1) Act :: inboundRelationship

4.5

(0..*)   AttentionLine :: transmission :: (1..1) Transmission :: attentionLine

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

4.6

(0..1)   Batch :: transmission :: (0..*) Transmission :: batch

4.7

(0..1)   ControlAct :: payload :: (0..*) Message :: controlAct

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

OpenIssue: Examine the symmetry between the way messages and documents relate to the RIM including the way messages.

4.8

(1..*)   Entity :: communicationFunction :: (0..*) CommunicationFunction :: entity

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

4.9

(1..1)   Entity :: languageCommunication :: (0..*) LanguageCommunication :: entity

4.10

(0..*)   Parameter :: queryByParameter :: (0..1) QueryByParameter :: parameter

4.11

(0..1)   ParameterList :: parameter :: (0..*) Parameter :: parameterList

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

4.12

(0..*)   Participation :: act :: (1..1) Act :: participation

4.13

(0..*)   Participation :: role :: (1..1) Role :: participation

4.14

(0..1)   QueryEvent :: controlAct :: (1..1) ControlAct :: queryEvent

4.15

(0..*)   Role :: player :: (0..1) Entity :: playedRole

The following constraint applies to this association:

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

4.16

(0..*)   Role :: scoper :: (0..1) Entity :: scopedRole

The following constraint applies to this association:

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

4.17

(0..*)   RoleLink :: source :: (1..1) Role :: outboundLink

4.18

(0..*)   RoleLink :: target :: (1..1) Role :: inboundLink

4.19

(0..*)   SelectionExpression :: leftSide :: (0..1) LogicalExpression :: userAsLeft

4.20

(0..*)   SelectionExpression :: queryBySelection :: (1..1) QueryBySelection :: selectionExpression

4.21

(0..*)   SelectionExpression :: rightSide :: (0..1) LogicalExpression :: userAsRight

4.22

(0..*)   SortControl :: querySpec :: (1..1) QuerySpec :: sortControl

4.23

(1..*)   Transmission :: communicationFunction :: (0..*) CommunicationFunction :: transmission

This relation links a transmission to its sender, receiver, call-back party, etc.