HL7 Reference Information Model

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

HL7 Version 3 Standard, Copyright Health Level Seven, Inc.© 2002. All Rights Reserved.

Table of contents

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

This document is meant to serve as an "Executive Summary" of the basic concepts and rationale behind the design and development of the HL7 Reference Information Model (RIM). It is not meant to be an "application guide" on RIM usage although several partial examples of usage are presented when they are deemed helpful in explaining the fundamental design and development concepts of the RIM.

A Reference Information Model (RIM) is constructed to facilitate consistent sharing and usage of data across multiple "local" contexts. In general, the broader the scope of interest, the more important it is to make explicit all assumptions about a topic or domain-of-interest. The HL7 Version 3 RIM is designed to provide a unified framework for, and to serve as a comprehensive source of, all information used by an HL7 Specification . The RIM specifically and unambiguously articulates both the explicit definitions of healthcare concepts - the "things of interest" to the world of healthcare information systems - and the relationships (aka "associations") between these concepts-of-interest.

HL7 V3 Specifications (e.g. HL7 V3 messages, structured documents, etc.) permit loosely-coupled information systems to interoperate (i.e. exchange data) in a variety of healthcare delivery contexts including those found in disparate provider organizations, perspectives, and jurisdictions. The scope of the HL7 RIM therefore includes all of the information that is required to be sent between, and processed by, participating healthcare information systems. In addition, it should be noted that the RIM does not model (nor need to model) information stored by a given healthcare information system but never transmitted to another system.

The RIM is expressed using a visual modeling syntax based on the Unified Modeling Language (UML). (Specific variances between "standard UML" and "HL7 UML" as manifest in the RIM, such as the placement of association names, are currently under review by the HL7 Modeling and Methodology Technical Committee with the goal of moving to a maximum alignment between the two syntaxes.) HL7 also maintains a database ("RIM repository") containing the details of each RIM concept, attribute, and association including the item's rationale, definition, constraints, and edit/change history. At some point in the future, any or all of this information may be formally published in an HL7-specific UML profile.

It is important to note that the RIM is not intended to be a logical or physical model of a database, a design for a particular vendor's information system, or a perspective focused on a particular healthcare organization or enterprise. In fact, the RIM is not intended to represent a particular set of HL7 messages, but rather the collective universe of data and relationships from which any relevant HL7 message could be constructed. Specific users of the RIM are expected to utilize relevant portions of the RIM as needed, adopting its content to their own information modeling needs and notations.

The overarching structure of the RIM is based on six "core" classes: Act, Entity, Role, Participation, 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.

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

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

An Act is an action of interest that has happened, can happen, is happening, is intended to happen, or is requested/demanded to happen. An act is an intentional action in the business domain of HL7. Healthcare (and any profession or business) is constituted of intentional actions. An Act instance is a record of such an intentional action.

An Entity is a class or specific instance of a physical thing or an organization/group of physical things capable of participating in Acts; an artifact. This includes living subjects, organizations, material, and places. The Entity hierarchy encompasses human beings, organizations, living organisms, devices, pharmaceutical substances, etc. It does not include events/acts/actions, the definition of things, or the roles that things can play (e.g. patient, provider).

A Role is a categorization of competency of the Entity that plays the Role as defined by the Entity that scopes the Role.

An Entity, in a particular Role, can participate in an Act. Note that a particular entity in a particular role can participate in an act in many ways. Thus, a Person in the role of a practitioner can participate in a patient encounter as a rounding physician or as an attending physician. The Role defines the competency of the Entity irrespective of any Act, as opposed to Participation, which is limited to the scope of an Act.

Each role is 'played' by one Entity (the Entity that is in the role) and is usually 'scoped' by another. Thus the Role of 'patient' is played by (usually) a person and scoped by the provider from whom the patient will receive services. Similarly, the employer scopes an Employee role.

A Participation is an association between a Role and an Act. The Participation represents the involvement of the Entity playing the Role with regard to the associated Act. A single Role may participate in multiple Acts and a single Act may have multiple participating Roles. A single Participation is always an association between a particular Role and a particular Act. Participation is limited to the scope of the Act, as opposed to Role, which defines the competency of an Entity irrespective of any Act.

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

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

Entity, Act and Role are "high-level" classes, although they are not "abstract" classes in the formal sense (i.e. meaningful instances of both classes are quite common). As a result, it has been necessary to define a number of more specialized subclasses of these three classes to specify the additional data (class attributes) required in more specific contexts (e.g. the Observation subclass of Act and the Living Subject and Material subclasses of Entity). . Attributes of a subclass must be both useful and unique to that subclass. Subclasses inherit all of the attributes of their parent superclass.

There are meaningful subclasses in each of these hierarchies that do not require additional attributes, and therefore are not represented as classes in the RIM. The "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.

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.

The RIM class, attribute and association definitions provide detail about logical meaning, but a full specification requires data types and domains. Data Types define the allowable values of attributes and what these values "mean." Data types are therefore the fundamental building blocks that shape (and constrain) all the semantics that can ultimately expressed in the RIM. Data types are represented in the RIM repository rendered in a style similar to that of the RIM. (It should be noted that this visual representation of the RIM Data Types is not the normative form and is not entirely correct. The normative form can be found in the Data Types Specification Part II).

Vocabulary Domains are also explicitly defined in the RIM repository. They document cross-reference and alternative representations among coding systems, while keeping track of the logical concepts being expressed by each code. Each attribute of each class may only be expressed using specific Data Types and Vocabulary Domains.

In summary, the primary motivation for the development of the RIM was the desire to clearly define the various data elements and relationships that comprise the healthcare information space. A direct outgrowth of this knowledge explication exercise is the ability to reuse the same concept in multiple healthcare messages. The complete process of defining a message is defined and discussed in the V3 Guide and accompanying HL7 Message Definition Framework (MDF). The basic steps include definition and documentation of the data interchange needs (e.g. a set of messages to support a particular clinical or administrative process) via a Storyboard, the selection/restriction of the RIM to those classes and attributes needed to populate the given message, and the subsequent application of additional constraints on number and possible values of each attribute.

Refer to the HL7 Version 3 Guide and MDF for further information.

The representations available for the RIM include a diagram for each of the high level subject areas, and a reference to the full RIM "billboard" in a PDF file where 'zooming' is more readily supported. The available graphics follow:

• The RIM billboard as a PDF file.

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.

• Acts contains classes:

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

• CommunicationInfrastructure contains subject areas:

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

• MessageControl contains classes:

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

• StructuredDocuments contains classes:

A collection of classes related to the Entity class, its specializations and related qualifying classes. The classes represent health care stakeholders and other things of interest to health care.

• Entities contains classes:

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

• Roles contains classes:

• Attributes of Access:

• Access is a specialization of: Role

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.

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.

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.

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.

• Attributes of Account:

• Account is a specialization of: FinancialAct

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.

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

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

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

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

• Attributes of Act:

• Associations of Act:
• outboundRelationship :: (0..*)ActRelationship :: source :: (1..1)
• inboundRelationship :: (0..*)ActRelationship :: target :: (1..1)
• participation :: (0..*)Participation :: act :: (1..1)

• Act generalizes:

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.

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.

| PV1^2^00132^Patient Class |

| FT1^6^00360^Transaction Type |

| FT1^7^00361^Transaction Code |

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

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

A unique identifier for the Act.

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

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.

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

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.

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.

| FT1^8^00362^Transaction Description |

A code specifying the state of the Act.

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

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

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

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.

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

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.

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.

| PV1^4^00134^Admission Type |

| PV2^25^00726^Visit Priority Code |

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.

| IN1^27^00452^Release Information Code |

| PV2^21^00722^Visit Publicity Code |

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.

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

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

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.

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.

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.

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

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

| PV1^34^00164^Delete Account Indicator |

| PV2^4^00184^Transfer Reason |

| IN3^17^00518^Appeal Reason |

The language used in documenting the Act.

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

• ActHeir is a specialization of: Act

Rationale: It has been discovered that one cannot create an HMD choice structure for a set of classes, all of which are sub-types of Act, Role or Entity, but for which there is not a defined physical class. These are the classes that would have been in the RIM as direct descendants (heirs) of Act, Role and Entity, except for the fact that they carried no unique attributes or associations.

The addition of this single empty class in each hierarchy will permit messages with the appropriate and necessary choice structures to be built. Subsequent evolution of the methodology and tooling may permit the elimination of these classes in favor of an equivalent abstraction in the methodology.

• Attributes of ActRelationship:

• Associations of ActRelationship:
• target :: (1..1)Act :: inboundRelationship :: (0..*)
• source :: (1..1)Act :: outboundRelationship :: (0..*)

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.

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.

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

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.

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.

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.

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.

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.

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

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

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.

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.

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

• Attributes of AssignedEntity:

• AssignedEntity is a specialization of: Role

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.

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

• Attributes of Container:

• Container is a specialization of: ManufacturedMaterial

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.

The capacity of the container in the units specified.

The height of the container in units specified.

The outside diameter of the container in units specified.

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

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.

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.

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.

• Attributes of Device:

• Device generalizes:

• Device is a specialization of: ManufacturedMaterial

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.

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

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

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

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

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.

• Attributes of DeviceTask:

• DeviceTask is a specialization of: Act

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.

The parameters of the task submitted to the device upon issuing of a command (or configuring the schedule of spontaneously executed tasks.) Parameters are only specified here if they are not included in separate HL7 defined structure. The parameters are a list of any data values interpreted by the device. The parameters should be typed with an appropriate HL7 data type (e.g., codes for nominal settings, such as flags, REAL and INT for numbers, TS for points in time, PQ for dimensioned quantities, etc.) However, besides this HL7 data typing, the functioning of the parameters is opaque to the HL7 standardization.

Rationale: Some parameters for tasks are uniquely defined by a specific model of equipment. Most critical arguments of a task (e.g., container to operate on, positioning, timing, etc.) are specified in an HL7 standardized structure, and the parameter list would not be used for those. The parameter list is used only for those parameters that cannot be standardized because they are uniquely defined for a specific model of equipment.

• Attributes of DiagnosticImage:

• DiagnosticImage is a specialization of: Observation

Class for holding attributes unique to diagnostic images.

Patient direction of the rows and columns of the image.

• Attributes of Diet:

• Diet is a specialization of: Supply

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.

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

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

• Attributes of Employee:

• Employee is a specialization of: Role

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)

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)

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

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

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

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.

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

A code categorizing the calculation method used by the employer to compute the employee's salary. For example, hourly, annual, commission.

The salary amount paid by the employer to the employee.

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

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

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

• Attributes of Entity:

• Associations of Entity:
• communicationFunction :: (0..*)CommunicationFunction :: entity :: (1..*)
• languageCommunication :: (0..*)LanguageCommunication :: entity :: (1..1)
• playedRole :: (0..*)Role :: player :: (0..1)
• scopedRole :: (0..*)Role :: scoper :: (0..1)

• Entity generalizes:

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

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.

| GT1^10^00414^Guarantor Type |

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

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

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.

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.

| IN2^14^00485^Champus Service |

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

A name for the Entity instance.

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.

| PV2^5^00185^Patient Valuables |

| PV2^6^00186^Patient Valuables Location |

A code specifying the state of Entity.

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

A telecommunication address for the Entity.

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

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

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.

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?

• EntityHeir is a specialization of: Entity

Rationale: It has been discovered that one cannot create an HMD choice structure for a set of classes, all of which are sub-types of Act, Role or Entity, but for which there is not a defined physical class. These are the classes that would have been in the RIM as direct descendants (heirs) of Act, Role and Entity, except for the fact that they carried no unique attributes or associations.

The addition of this single empty class in each hierarchy will permit messages with the appropriate and necessary choice structures to be built. Subsequent evolution of the methodology and tooling may permit the elimination of these classes in favor of an equivalent abstraction in the methodology.

• Attributes of FinancialAct:

• FinancialAct generalizes:

• FinancialAct is a specialization of: Act

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

The monetary value of a financial act after any applicable discounts and adjustments have been applied.

This attribute can be used to represent concepts that include the balance of a financial account, the value of a financial transaction, and the value of an invoice line item or adjustment.

• Attributes of FinancialContract:

• FinancialContract is a specialization of: Act

A contract whose value is measured in monetary terms.

Establishes the payment terms for a contractual agreement or obligation. Examples are "net 30", "on receipt of invoice", "upon completion of service", etc.

• Attributes of FinancialTransaction:

• FinancialTransaction is a specialization of: FinancialAct

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.

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.

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.

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.

• Attributes of Guarantor:

• Guarantor is a specialization of: Role

The double role-based association between a party in the role of guarantor and an organization in the role of healthcare provider .

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

| PV1^23^00153^Credit Rating |

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

• Attributes of ImagingModality:

• ImagingModality is a specialization of: Device

Class to contain unique attributes of diagnostic imaging equipment.

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

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.

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

• Attributes of InvoiceElement:

• InvoiceElement is a specialization of: FinancialAct

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.

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.

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.

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.

| FT1^10^00364^Transaction Quantity |

| FT1^22^00374^Unit Cost |

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

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

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

| IN2^27^00498^Eligibility Source |

A flag indicating whether the details of the invoice processing results (usually an authorization or an adjustment) should be communicated directly to the covered party involved.

• Attributes of LanguageCommunication:

• Associations of LanguageCommunication:
• entity :: (1..1)Entity :: languageCommunication :: (0..*)

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.

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

| GT1^36^00118^Primary Language |

| IN2^34^00118^Primary Language |

| NK1^20^00118^Primary Language |

| PID^15^00118^Primary Language |

A code depicting the method of expression of the language (e.g. expressed spoken, expressed written, expressed signed, received spoken, received written, received sign)

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

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

• Attributes of LicensedEntity:

• LicensedEntity is a specialization of: Role

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.

The date recertification is required.

• Attributes of LivingSubject:

• LivingSubject generalizes:

• LivingSubject is a specialization of: Entity

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.

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.

| NK1^15^00111^Sex |

| PID^8^00111^Sex |

| STF^5^00111^Sex |

| GT1^9^00413^Guarantor Sex |

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

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

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

An indication that the subject is dead.

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

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

| PID^24^00127^Multiple Birth Indicator |

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

| PID^25^00128^Birth Order |

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

| PD1^8^00760^Organ Donor |

• Attributes of ManagedParticipation:

• ManagedParticipation is a specialization of: Participation

A "stateful" participation. The primary example would be attending practitioner for an inpatient encounter.

Rationale: The state attribute is being added to support attending physician participation on Encounters.

A unique identifier for a participation.

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

• Attributes of ManufacturedMaterial:

• ManufacturedMaterial generalizes:

• ManufacturedMaterial is a specialization of: Material

Things or combination of things transformed for a particular purpose by a non-natural or manufacturing process. This class encompasses containers, devices, software modules and facilities.

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.

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

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.

• Attributes of Material:

• Material generalizes:

• Material is a specialization of: Entity

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.

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.

• Attributes of NonPersonLivingSubject:

• NonPersonLivingSubject is a specialization of: LivingSubject

A non-human living subject..

A code representing the taxonomy of the living subject.

A code representing the breed of the living subject.

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

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

An indication that the living subject was euthanized.

• Attributes of Observation:

• Observation generalizes:

• Observation is a specialization of: Act

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.

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.

| GT1^34^00145^Ambulatory Status |

| IN2^32^00145^Ambulatory Status |

| NK1^18^00145^Ambulatory Status |

| PV1^15^00145^Ambulatory Status |

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

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.

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.

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.

• Attributes of Organization:

• Organization is a specialization of: Entity

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.

The postal and residential addresses of an organization.

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

The standard industry class code of the organization.

• Attributes of Participation:

• Associations of Participation:
• act :: (1..1)Act :: participation :: (0..*)
• role :: (1..1)Role :: participation :: (0..*)

• Participation generalizes:

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.

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.

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

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.

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

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.

A textual or multimedia depiction of commentary related to Participation.

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

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.

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.

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.

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.

• Attributes of Patient:

• Patient is a specialization of: Role

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.

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

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

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

| PV1^16^00146^VIP Indicator |

• Attributes of PatientEncounter:

• PatientEncounter is a specialization of: Act

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

The source of the referral for a patient encounter.

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

| PV1^14^00144^Admit Source |

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?

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

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

| PV1^36^00166^Discharge Disposition |

A indication that the LivingSubject was born during this PatientEncounter.

| PV2^36^00737^Newborn Baby Indicator |

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.

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

| PV1^12^00142^Preadmit Test Indicator |

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

| PV1^22^00152^Courtesy Code |

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.

• Attributes of Person:

• Person is a specialization of: LivingSubject

An individual human being.

The address(es) of a Person.

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

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.

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

The amount of education a person achieved.

OpenIssue: Need example values.

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

OpenIssue: Need example values.

| GT1^52^00753^Handicap |

| IN1^48^00753^Handicap |

| NK1^36^00753^Handicap |

| PD1^6^00753^Handicap |

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.

| GT1^37^00742^Living Arrangement |

| IN2^35^00742^Living Arrangement |

| NK1^21^00742^Living Arrangement |

| PD1^2^00742^Living Arrangement |

A person's religious preference.

OpenIssue: Need example values.

| GT1^41^00120^Religion |

| IN2^39^00120^Religion |

| NK1^25^00120^Religion |

| PID^17^00120^Religion |

A code depicting the race of a person.

| IN2^71^00113^Race |

| NK1^35^00113^Race |

| PID^10^00113^Race |

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.

| GT1^44^00125^Ethnic Group |

| IN2^42^00125^Ethnic Group |

| NK1^28^00125^Ethnic Group |

| PID^22^00125^Ethnic Group |

• Attributes of Place:

• Place is a specialization of: Entity

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

Indicates whether the facility is considered mobile.

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

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

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

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

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.

• Attributes of Procedure:

• Procedure is a specialization of: Act

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.

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.

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.

The anatomical site or system that is the focus of the procedure. For example, a Nephrectomy's target site is the right or left kidney; an arteria pulmonalis catheter targets a pulmonary artery. For non-invasive procedures, e.g., acupuncture, the target site is the organ/system that is sought to be influenced (e.g., "the liver".)

If the subject of the Act is something other than a human patient or animal, the attribute is used analogously to specify a structural landmark of the thing where the act focuses.

Some target sites can also be "pre-coordinated" in the Act definition, so that there is never an option to select different body sites. The same information structure can handle both the pre-coordinated and the post-coordinated approach.

• Attributes of PublicHealthCase:

• PublicHealthCase is a specialization of: Observation

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.

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.

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.

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.

• Attributes of Referral:

• Referral is a specialization of: Act

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.

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.

• Attributes of Role:

• Associations of Role:
• player :: (0..1)Entity :: playedRole :: (0..*)
• scoper :: (0..1)Entity :: scopedRole :: (0..*)
• participation :: (0..*)Participation :: role :: (1..1)
• outboundLink :: (0..*)RoleLink :: source :: (1..1)
• inboundLink :: (0..*)RoleLink :: target :: (1..1)

• Role generalizes:

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

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.

A unique identifier for the Role.

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

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

An address specification applicable the Entity while in the Role.

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

A telecommunication address for the Role.

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

A code specifying the state of Role.

| PID^27^00130^Veterans Military Status |

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

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.

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

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.

• RoleHeir is a specialization of: Role

Rationale: It has been discovered that one cannot create an HMD choice structure for a set of classes, all of which are sub-types of Act, Role or Entity, but for which there is not a defined physical class. These are the classes that would have been in the RIM as direct descendants (heirs) of Act, Role and Entity, except for the fact that they carried no unique attributes or associations.

The addition of this single empty class in each hierarchy will permit messages with the appropriate and necessary choice structures to be built. Subsequent evolution of the methodology and tooling may permit the elimination of these classes in favor of an equivalent abstraction in the methodology.

• Attributes of RoleLink:

• Associations of RoleLink:
• target :: (1..1)Role :: inboundLink :: (0..*)
• source :: (1..1)Role :: outboundLink :: (0..*)

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)

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

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

• Attributes of SchedulableResource:

• SchedulableResource is a specialization of: Role

A Role of an Entity that can be scheduled.

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

OpenIssue: Not sure what this means.

• Attributes of SubstanceAdministration:

• SubstanceAdministration is a specialization of: Act

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.

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.

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.

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.

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.

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

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

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

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.

• Attributes of Supply:

• Supply generalizes:

• Supply is a specialization of: Act

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.

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

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.

• Attributes of WorkingList:

• WorkingList is a specialization of: Act

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.

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.

• Attributes of Acknowledgement:

• Associations of Acknowledgement:
• acknowledgedMessage :: (1..1)Message :: acknowledgement :: (1..*)
• acknowledgingMessage :: (1..1)Message :: payload :: (1..1)

The Acknowledgement class contains information sent when acknowledging another message.

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

| MSA^1^00018^Acknowledgement Code |

This attribute allows for a coded error type.

| MSA^6^00023^Error Condition |

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

| MSA^3^00020^Text Message |

This attribute is used in the sequence number protocol.

| MSA^4^00021^Expected Sequence Number |

• Attributes of AttentionLine:

• Associations of AttentionLine:
• transmission :: (1..1)Transmission :: attentionLine :: (0..*)

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

A parameter defining word.

A parameter value.

• Attributes of Batch:

• Associations of Batch:
• transmission :: (0..*)Transmission :: batch :: (0..1)

• Batch is a specialization of: Transmission

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.

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

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

This attribute is used by the application processing the batch.

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

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

| BHS^10^00090^Batch Comment |

| BTS^2^00090^Batch Comment |

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

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

| BTS^3^00095^Batch Totals |

• Attributes of ClinicalDocument:

• ClinicalDocument is a specialization of: ContextStructure

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

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.

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.