Ringholm-Logo Ringholm
 Whitepaper
Ringholm page header
Training    Services   |   Whitepapers    Blog    Events    Links   |   About us    Partners    Clients    Contact

HL7 v3 RIM Act Essentials: moodCode

The contents of this whitepaper are published under the Creative Commons Attribution-Share Alike license.
See http://www.ringholm.com/docs/04400_en_HL7_v3_RIM_moodCode.htm for the latest version of this document.
Author: René Spronk - Sr.Consultant, Ringholm bv
Document status: Draft, version 0.9 (2010-05-14)   
Please sent questions and comments to Rene.Spronk@Ringholm.com


Summary

The semantic interpretation of the Act class in the HL7 version 3 RIM heaviliy relies on one of its properties: its mood. This whitepaper attempts to explain the concept of mood - a lot of examples are provided in the process. Related concepts such as the ActClass, ActStatus and the impact of the NegationIndicator are also covered.

1. Introduction

HL7 (and any complex information system) is about information, communicated between agents (human people, machines, etc.). In order to correctly interpret the semantics of a HL7 v3 Act one has to have an understanding of some of its core attributes.

When introduced to the RIM most people have a hard time understanding the concept of “the mood of an Act”. This whitepaper aims to clarify the concept of mood – using ample examples in the process. The word mood is from the Latin modus, meaning manner, way, method.

The semantic interpretation of an Act is defined by two of its properties/attributes: classCode and moodCode. The classCode identifies the meaning of an Act, the moodCode its usage. These two characteristics describe different dimensions of the Act.

Example: the classCode of the “room cleaning” activity distinguishishes the semantics of the activity from other activities such as “doing the dishes”. The moodCode can be used to denote the context of the activity: “clean your room!” (a request), or “I’ve cleaned my room” (an actual event).

2. classCode

classCode is defined in the RIM as: (definition, RIM v. 0230) the major class of Acts to which an Act-instance belongs. The classCode attribute provides a tightly controlled vocabulary of Act class "types” that have a unique meaning.

Example:the ActClass coding system is hierarchical in nature. The PROC (generic procedure) Act class type is a parent concept of the SBADM (substance administration, introducing a substance to the patient) and SBEXT (substance extraction, removing something from a patient) Act class types. SBEXT is a parent concept of SPECCOLLECT (specimen collection).

Each and every concept code in the ActClass value set identifies an Act class type which has a meaning which is distinct from any other Act class type. Each and every instance of an Act has one Act class type associated with it.

The code attribute defines a specific sub-type of this Act type, and is intended to allow use of rich terminologies such as LOINC and SNOMED to represent these sub-types. If present, Code has to be a specialization of the classCode; code cannot alter the meaning of classCode.

Example:for the “room cleaning” activity the code attribute identifies the “type of room cleaning”. Code could for instance be ‘superficial’ or ‘thorough’ .
Example: For an Act with class type PROC (procedure) the code attribute identifies the “kind of procedure”. Code could be 174036004 (a SNOMED code) to identify that the procedure is of the type “Emergency Appendicectomy”.

Each Act type is represented by a physical class in the RIM. Each physical class in the RIM may be related to multiple Act types if those Act types have a unique meaning, but did not require unique attributes or unique patterns of associations.

Relationship between the physical RIM acts and the Act Type hierarchy

Example: the RIM (as a definition of a set of physical classes) defines Act, Procedure (as a specialization of Act) and SubstanceAdministration (as a specialization of Procedure). The Act type PROC is represented by Procedure (as a physical RIM class); SBADM is represented by SubstanceAdministration; and both SBEXT and SPECCOLLECT are represented by Procedure.

Each physical RIM class may be used to represent zero or more Act class types; each Act class type is represented by one physical RIM class.


3. moodCode

MoodCode is defined in the RIM as: (definition, Rim v. 0230) the intended use of the Act statement: as a report of fact, a command, a possibility, a goal, etc. In other words: moodCode specifies how the act is used. This should be determinable by the context of the Act , but it is explicit in the act to reduce processing requirements. The moodCode attribute provides a tightly controlled vocabulary of the intented use (each linked to a phase in a series of business activities) that have a unique meaning. The mood assignment does not change throughout the lifetime of the act object. The Act.moodCode modifies the meaning of the Act class in a controlled way, just as in natural language, grammatical form of a verb modifies the meaning of a sentence in defined ways. For example, if the mood is factual (event), then the entire act object represents a known fact. If the mood expresses a plan (intent), the entire act object represents the expectation of what should be done.

Example: In RequestOrder mood, the Act class type “room cleaning” should be interpreted as "please clean your room." In Event mood, the Act class type should be interpreted as "room cleaning is being done or has been done."
Example: In RequestOrder mood, the Act class type OBS (Observation) with Act.code set to “blood glucose” should be interpreted as "please measure blood glucose." In Event mood, the Act class type should be interpreted as "blood glucose was measured or is being measured."

As the meaning of an Act-instance is factored in the mood code, the mood code affects the interpretation of the entire Act object and with it every property (attributes and associations). Note that the mood code affects the interpretation of the act object, and the meaning of the act object in turn determines the meaning of the attributes. However, the mood code does not arbitrarily change the meaning of individual attributes.

3.1 Inert vs descriptive properties

Acts have two kinds of act properties, inert and descriptive.
  1. Inert properties are not affected by the mood. They can be interpreted regardless of the mood. For example, there is an identifier attribute Act.id, which gives a unique identification to an act object. Being a unique identifier for the object is in no way dependent on the mood of the act object. Therefore, the "interpretation" of the Act.id attribute is inert with respect to the act object's mood.
  2. Descriptive properties follow the mood of the object. Most of the Act class attributes describe what the Act statement expresses. Descriptive properties of the Act class answer the questions who, whom, where, with what, how and when the action is done. The questions who, whom, with what, and where are answered by Participations, while how and when are answered by descriptive attributes and ActRelationships. The interpretation of a descriptive attribute is aligned with the interpretation of the entire act object, and controlled by the mood.

Example: To illustrate the effect of mood code, consider the act of “room cleaning”. Mrs Smith requests that her son John clean his room; subsequently John cleans his room.
  • In RequestOrder mood, the Act class type should be interpreted as "please clean room." The Participations identify the people actually and supposedly involved in the act, especially the order placer (the Author participation, Mrs Smith) and the designated filler (the Performer participation, John), and the objects actually or supposedly involved in the act (e.g., the room which is the subject of the cleaning, Johns room). The Performer (as an example of a descriptive property) is the role (played by John) that is requested to perform the requested act. The effectiveTime property of the Act (a descriptive property) identifies the time interval during which the requested act should be performed ("clean your room within the next 30 minutes!").
  • In Event mood, the Act class type should be interpreted as "the room was cleaned or is being cleaned." Participations indicate the people actually involved in the act (e.g. Author and Performer participations – John is playing both roles), and the objects actually involved (e.g., Johns room). The Performer (as an example of a descriptive property) is the role (played by John) that is has performed or is still performing the requested act. The effectiveTime property of the Act (a descriptive property) identifies the time interval during which the activity was/is performed ("I finished cleaning 10 minutes ago; it took me only 15 minutes").
  • Other moods include: The Definition mood which specifies the Act of “room cleaning” (as defined by Mrs Smith: making the bed, sweeping the floor, and putting belongings away).

Relationship between room cleaning acts in different moods.

Example:To illustrate the effect of mood code, consider a "blood glucose" observation.
  • In RequestOrder mood, the Act class type should be interpreted as "please measure blood glucose." The Participations identify the people actually and supposedly involved in the act, especially the order placer (the Author participation) and the designated filler (the Performer participation), and the objects actually or supposedly involved in the act (e.g., specimen sent, equipment requirements, etc.). The Act.id (as an example of an inert property) identifies the order activity (the placer order number). The Performer (as an example of a descriptive property) is the role that is requested to perform the requested act.
  • In Promise mood, the Act class type should be interpreted as "a promise to measure blood glucose." The Participations identify the people actually and supposedly involved in the act, especially the order filler (the Author participation). The Act.id (as an example of an inert property) identifies the promise activity (the filler order number). The Author (as an example of a descriptive property) is the role that is promising to perform the requested act.
  • In Event mood, the Act class type should be interpreted as "blood glucose was measured or is being measured." Participations indicate the people actually involved in the act (e.g. Author and Performer participations), and the objects actually involved (e.g., specimen, facilities, equipment). The Observation.value is the value actually obtained (e.g., 80 mg/dL, or <15 mg/dL). The Act.id (as an example of an inert property) identifies the observation activity. The Performer (as an example of a descriptive property) is the role that is has performed or is still performing the requested act.
  • Other moods include: The Definition mood which specifies the Act of "obtaining blood glucose." In Goal mood (a kind of criterion), the author states that "our goal is for blood glucose values to be within the given range."

Relationship between blood glucose observation acts in different moods.

3.2 Negation of an Act

Act.actionNegationInd is defined in the RIM as: (definition, Rim v. 0230) An indicator specifying that the Act statement is a negation of the Act in Event mood as described by the descriptive attributes. This attributes negates all the descriptive properties of the Act, but has no effect on its inert properties. In effect, if you would view the Act as a statement, and would combine all its descriptive properties as an AND statement, using act negation would be like putting logical NOT in front of that statement. Depending on the semantics one wishes to express actNegationInd may be set to true or false upon instantiation of an act object. The value of this attribute doesn't change during the lifecycle of the object.

The actionNegationInd works as a negative existence quantifier on the actual, intended or described Act event. In Event mood, it indicates the defined act did not occur. In Intent mood, it indicates the defined act is not intended/desired to occur. In Criterion mood, it indicates that the condition is based on the non-occurrence of the event. It is nonsensical to have a negationInd of true for acts with a mood of definition.

Example: consider the act of “room cleaning”. Mrs Smith requests that her son John clean his room; subsequently John cleans his room.
  • In RequestOrder mood the Act class type should be interpreted as "a request to do roomcleaning." The actionNegationInd indicates that the request has NOT been made – the act of requesting did not happen. The Participations identify the people actually and supposedly involved in the act, especially the order placer (the Author participation, Mrs Smith) and the designated filler (the Performer participation, John), and the objects actually or supposedly involved in the act (e.g., the room which is the subject of the cleaning, Johns room). The Performer (as an example of a descriptive property) is the role (played by John) that is requested to perform the requested act.
  • In Event mood the Act class type should be interpreted as "the room was cleaned or is being cleaned." The actionNegationInd indicates that the room was NOT cleaned –the act of cleaning did not happen. If effectiveTime is populated, it indicates the timeframe during which the room wasn’t being cleaned. Participations indicate the people actually involved in the act (e.g. Author and Performer participations – John is playing both roles), and the objects actually involved (e.g., Johns room). The Performer (as an example of a descriptive property) is the role (played by John) that is has performed or is still performing the requested act.
The actionNegationInd negates the Act as described by the descriptive properties (including Act.code, Act.effectiveTime, Observation.value, Act.doseQty, etc.) and any of its components. The document characteristic properties such as Act.id, Act.moodCode, Act.confidentialityCode, and particularly the Author-Participation are not negated. These document characteristic properties always have the same meaning: i.e., the author remains to be the author of the negative observation. Also, most ActRelationships (except for components) are not included in the negation.

3.3 Mood versus Status

The status of an Act is an inert property. Act.statusCode is defined in the RIM as: (definition, Rim v. 0230) The state of the Act. The status reflects the state of the activity. I.e. the state of the activity in its life-cycle/business-cycle.

When the Act class is instantiated it will have one single (fixed) mood. The status of the act may change during its lifecycle, e.g. from new, to active, and finally to completed.

Example:To illustrate the fact that status is an inert property consider the "blood glucose" observation example:
  • In RequestOrder mood, the Act class type should be interpreted as "please measure blood glucose." The act status may be active, completed, aborted, nullified etc. - the status of the request to perform the act.
  • In Promise mood, the Act class type should be interpreted as "a promise to measure blood glucose." The act status may be active, completed, aborted, nullified etc. - the status of the promise to perform the act.
  • In Event mood, the Act class type should be interpreted as "blood glucose was measured or is being measured." The act status may be active, completed, aborted, nullified etc. - the status of performing the act.
Note: quite often mood is interpreted as a status of an activity; whereby the mood of e.g. an observation activity changes from RequestOrder to Event during its life-cycle. These are actually two entirely different objects: the object in requestOrder mood is created by the Order Placer Application (it has a fixed mood; and may undergo various status changes during its lifecycle); the object in Event mood is created by the Order Filler Application (it has a fixed mood; and may undergo various status changes during its lifecycle). The mood of an object never changes (it isn't allowed to change) during its lifecycle. The status of an object may change over time to reflect its state in its lifecycle.

References


About Ringholm bv

Ringholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards.
See http://www.ringholm.com or call +31 33 7 630 636 for additional information.