Domain: Message Control Act Infrastructure


ANSI/HL7 V3 IM, R1-2004
HL7 Version 3 Standard: Infrastructure Management - Control Act Infrastructure, Release 1
10/20/2004
Control Query Co-Chair[CAM1] / Graham Grieve
Kestral Computing Pty Ltd.
Control Query Co-Chair / Mike Henderson
Eastern Informatics
Control Query Co-Chair / Joann Larson
Kaiser Permanente
Primary Contributor / Dale Nelson
Zed-Logic Informatics, LLC
Control Query Co-Chair / Jennifer Puyenbroek
McKesson Information Solutions
Primary Contributor / Larry Reis
LR Consulting
Primary Contributor / Mark Shafarman
Oracle Corporation
Control Query Co-Chair / Rene Spronk
Ringholm GmbH
Primary Contributor / Mark Tucker
Regenstrief Institute for Health Care

Last Published:03/21/200711:11AM

Content Last Edited:6/20/2005 6:46:43 PM

HL7® Version 3 Standard, © 2006 Health Level Seven®, Inc. All Rights Reserved.

HL7 and Health Level Seven are registered trademarks of Health Level Seven, Inc. Reg. U.S. Pat & TM Off

Table of Contents

View Revision MarksHide Revision Marks

Preface
i Notes to Readers
ii Message Design Element Navigation
1 Overview
1.1 Introduction & Scope
1.2Domain Message Information Models
2.Trigger Event Control Act Topic
2.1Application Roles
2.2Trigger Events
2.3Refined Message Information Models
2.4Hierarchical Message Descriptions
2.5Interactions
3.Common Message Elements Annex
3.1CMETs Used In This Domain
4.Interaction Annex
4.1By Application Role
4.2By Trigger Event
4.3By Message Type
5.Glossary

Preface

i Notes to Readers

This is the normative material for Version 3, Release 1.

ii Message Design Element Navigation

▼Trigger Event Control ActMCAI_RM700200UV01
▼Trigger Event Control ActMCAI_HD700200UV01
/ Trigger Event Control ActMCAI_MT700201UV01
/ Trigger Event Control Act - PRSCMCAI_MT705201UV01
▼Trigger Event Control Act Detected Issue CMETMCAI_RM900000UV01
▼Trigger Event Control Act Detected Issue CMETMCAI_HD900000UV01
/ Trigger Event Control Act Detected Issue CMETMCAI_MT900001UV01

1 Overview

1.1 Introduction & Scope

Scope

The Message Control Act Infrastructure covers the alternate structures of the message Trigger Event Control Acts in the HL7 Composite Message. Refer to Transmission Infrastructure for details relating to the HL7 Composite Message.

Introduction

As discussed in Transmission Infrastructure Introduction, the "Trigger Event Control Act" contains administrative information related to the "controlled act" which is being communicated as a messaging interaction. A Trigger Event Control Act describes the 'action' that is happening to the subject of the message (the payload). The Trigger Event Control Act contains details about the trigger event for the message such as who, when, where and why.

Trigger Event Control Acts may be grouped to allow for a set of similar acts to be conveyed consistently, and to be treated as a single act for the purposes of acknowledgement.

Trigger Event Control Acts may be associated with a conversation. A conversation code may be provided which identifies the dynamic model specification that the Trigger Event Control Act is a part of. This may, for example, be a query-response conversation, or a clinical pathway definition. There may also be a conversation id provided, which would tie this Trigger Event Control Act to a particular instance of a conversation. For example a instance of the retinal screening pathway for Jim Jones.

In general, the Trigger Event Control Act Infrastructure is intended to promote the reuse of similar structures that are used for the same type of interactions across the domains that contribute content to the HL7 Version 3 messaging standard. This chapter will discuss the alternate forms of the Trigger Event Control Act and an overview of their intended use.

Trigger Event Control Act Categories

The Trigger Event Control Act includes general administrative information related to a controlled act that is being communicated as a messaging interaction. The Trigger Event Control Act varies in structure depending upon the type of message interaction. The categories of message interaction currently recognized are:

  1. Action, Information, or State Transition Control messages
  2. Query and Query Response messages
  3. Master File / Registry Act messages

Accept-level acknowledgements [CAM2]are a message control function that do not require or allow a Control Act.

ApplicationCommit-level acknowledgement [CAM3](functional response) message interactions require the Trigger Event Control Act and, in most cases, include a domain specific application response. Certain interactions will employ the use of Shared Messages as the functional response. Although the application acknowledgement (functional response) is normal, an application response message is also allowed to exist with only the Control Act that carries no additional domain content. If the response is not defined by a domain interaction, the use of a Transmission Infrastructure Interaction would be appropriate[CAM4].

What follows is a brief discussion of each of the above message interaction categories.

Action, Information, and State Transition Control Interactions

These include all messages which convey application content with the exception of Query and Master File / Registry (see below). Messaging interactions occur between an originating application[CAM5] and a receiving application[CAM6]. For reliable messaging interactions[CAM7], there is a sequence of at least two messaging events that form part of an HL7 conversation[CAM8]. Refer to Transmission Infrastructure for the modes of messaging. The initial message interaction generally passes application content that is the purpose for the HL7 conversation (messaging interaction sequence).

Depending on the receiver responsibilities of the initial message interaction, there might be a second message interaction that is some level of acknowledgement response. The acknowledgement could be by the receiving application or could be a surrogate for the receiving application that may only guarantee delivery of the content to the intended application. The receiver responsibilities may be defined in the specification for the interaction, or may be defined in an HL7 Conversation Definition.

Upon receipt of a positive application acknowledgment (response), the payload will indicate what was done (the promise, event, modified object, etc.). A negative application acknowledgement (rejection) won't contain any of those. The message interaction id and trigger event id indicate that this is a rejection.

The "semantic content" of a message is the combination of the ControlAct and the payload. To fully understand the trigger event you need both. The Control Act just says "Please 'do something' with 'this thing'". The payload is needed to indicate what 'this thing' is. However, the bulk of the trigger event information is attached to the Control Act:

Because this information tends to be reasonably consistent, irrespective of domain, the ControlAct has been defined as a reusable message type and will be referenced in the domain interaction. This saves committees the trouble of defining the content, simplifies their message types, and ensures consistency. However, the combination is needed to understand what is really happening.

Query Specification/Query Response Interactions

Query Specification and Query Response interactions have a form of the Control Act that contains elements that are needed to establish and control a logical query session between two applications. A more complete discussion of the use of the query support provided in this ballot is discussed in the Query Control, Query Infrastructure (QUQI) domain chapter.

Master File / Registry Act Interactions

Master File / Registry Act messaging interactions are the third and last category of message interaction types that require a unique Control Act structure in the current HL7 Version 3 Composite Message Payload Specification. This infrastructure is presented in detail in the Master File / Registry Infrastructure (MFMI) domain chapter.

Customization and Refinement of Trigger Event Control Acts

The message types defined in the Message Control Act Infrastructure section of the ballot are highly generic and inclusive. In order to permit expressivity where needed by implementers, most of the attributes and relationships are defined to be optional. The use cases for the general messages are so abstract that most useful constraints are impossible to specify at this level.

For example, in some cases, it is desirable to indicate a performer as well as an author, for an act. The performer is the party who actually performs the act; in this case, a notification. One can presume that there is an author for a control act, however it is not required to record information about the author. At the same time, while it is generally assumed that only a single author is allowed, many performers can be specified.

Note to implementers: Message designers and implementers may further refine and constrain Trigger Event Control Acts. Refer to Refinement, Constraint, and Localization section for details for rules and principles regarding customization and refinement.

Note to Technical Committees: Technical committees are encouraged to create refined versions of Trigger Event Control Acts that tighten the cardinalities of attributes and relationships as they see fit for their specific use cases. Unlike normal refinement, committee level Trigger Event Control Act R-MIM may not omit mention of attributes and relationships nor mark them as Not Permitted (NP). To do so would prohibit the use of these attributes in site-specific implementations. Refer to Refinement, Constraint, and Localization section for details for rules and principles regarding customization and refinement.

1.2Domain Message Information Models

Trigger Event Control Act Infrastructure D-MIM (MCAI_DM700200UV02)

Diagram


Click thumbnail above to open larger graphic in a new window

Description

This D-MIM (which is a duplicate of the R-MIM for this domain) specifies the Trigger Event Control Act structure in the HL7 version 3 composite message payload specification that is used for action, information, and state transition message interactions. This structure specifies the superset of associations and ActRelationshipTypes that domain committees may want to specify for administrative information content that is to accompany a given message interaction. Provisions for constraining the accompanying information will be made first by committees concerning functional needs for a specific message interaction. Further constraints will be provided by the enforcement of a conformance profile at the time of specifying the implementation of the message interaction.

Design Walk-through

The Trigger Event Control Act plays a central role in the semantics of HL7 communication. Information in the transmission wrapper helps with message delivery. The Trigger Event Control Act specifies precisely the nature of the event notification, or the command that is given. The central construct in the trigger Event Control Act is the ControlActProcess class.

The ControlActProcess class may be transmitted within a ControlActGroup class. This is a way to provide shared context for many control acts. For example a set of patient demographic update notifications may be conveyed as a set of separate control acts within a control act grouper. This is particularly useful if there is a requirement to be able to accept or reject each update independently.

The ControlActProcess class can be seen as a generalization of the HL7 Version 2 "EVN" (event) segment. The EVN segment specifies the name of the event as well as the time of the event, the person responsible for the event, etc. These tend to be "facts about the event", rather than "facts of the event[CAM9]".

There is inherent tension between the two different ways of representing information about the event. Data about the event can be carried by the ControlActProcess class, or by specific HL7 domain payload.

Consider a new order for service. In this case, there is a natural HL7 domain content payload (the "Order") which represents the order, and who ordered it and when, etc. For these messages, there will be a certain level of duplication between the ControlActProcess associations and the domain content.

It is an HL7 design philosophy *not* to duplicate information in ControlActProcess associations that is reasonably found within the carried Domain payload. Some duplication may however be unavoidable. HL7 message senders should not need to "pluck out" data from the domain content in order to populate the ControlActProcess associations. The full richness of the ControlActProcess is available as a standard design for use by messages that may need to convey this data. Using the pre-defined associations and attributes of the ControlActProcess will contribute to HL7's uniformity and consistency.

The control act process class is the central construct for the transmission control act wrapper RMIM. It captures information related to the specific act - the trigger event - that is central to the message.

The following attributes are central to using the control act:

  • classCode: Mandatory, constrained to CACT, a control act.
  • moodCode: The x_ActMoodIntentEvent domain has been defined for this attribute to specify actual and intended events.
  • id: The identifier that has been designated for the control act or notification.
  • code: The code indicates the Trigger Event of the act or the notification that has been sent. The values are derived from the MDF, examples include "COMT_TE200200" or "QURX_TE100001". The codeSystem identifies the HL7 organization. The domain HL7TriggerEventCode has been defined to represent these codes.
  • text: The text attribute can be used to convey a textual or multimedia description of the Act.
  • effectiveTime: The date and time on which the control act or notification was composed and authorized for transmission, i.e. the date and time the event occurred that triggered the interaction. This date and time will normally differ from the data and time contained in the transmission wrapper.

Example: Suspension of a prescription. A doctor wants to suspend a prescription effective at noon the following day. The effective time would be noon the following day Numerous interactions might be triggered (order-entry system to pharmacy, pharmacy to nursing system). The time associated with each of the messages associated with those interactions would be the message time.

  • priorityCode: A code, or a set of codes, that identifies the circumstances in which the event happened, shall happen, is planned to happen, or requested to happen. The default value is R for routine.
  • reasonCode: A code specifying the motivation, cause, or rationale of the Act. The reasonCode should only be used for common reasons that are not related to a prior Act or any other condition expressed in Acts. Example reasons that might qualify for being coded in this field might be: "routine requirement", "infectious disease reporting requirement", "on patient request", or "required by law". The reasonCode attribute identifies types of reasons, or broad categories of reasons. It is not to be used for the identification of fine-grained reasons for the Act. The value of this attribute shall not be interpreted as a refinement of the trigger event identified in the code attribute; it's value is "for information" only.

This attribute shall not be valued if a (detailed) reason for the Act is specified by means of the DetectedIssueEvent class. See below for a discussion of the reason act relationship and the reporting of detected issues in the DetectedIssueEvent class, the reasonCode attribute and the Transmission Wrapper.

  • languageCode: The primary language in which this Act statement is specified, particularly the language of the text attribute.

The following control act participations are defined for the control act. Note that where the model permits more than one instance of (or requires) a participation or act relationship, cardinality should be constrained as fully as possible in the domain-defined message type. Note that the location for any of the participants, if provided, will be defined in the R_AssignedPerson CMET.

  • authorOrPerformer There are zero to many parties recorded as author or performer for a control act.

The author of an act is the person who takes responsibility for its creation. This could be the doctor who orders a test or the public health professional who decides to notify a local, state, or national public health entity.

The performer of an act is the person who actually and principally carries out the "controlled act". The performer is rarely used.

The actual party involved is either a device or a person, and the particular information involved is specified in the Assigned Person, and the Assigned Device CMET. The reader should note that, in many cases, it is the organization responsible for authoring or performing an act that is recorded as opposed to the person. In this case, the Assigned Person CMET is still used. However, the organization that scopes the performer role is recorded.

  • overseer: There are zero to many overseers for a control act. In some cases but by no means all, it is relevant to record information about a person who oversees the work of the acts' author or performer. This is particularly relevant in instructional situations. It is possible, but unlikely for there to be many parties acting as overseer.
  • dataEnterer: If relevant, the party who enters data associated with the control act may be recorded. It is possible for multiple parties to provide data entry.
  • informationRecipient: There are zero to many designated information recipients for a control act. These are the parties who are intended to receive the information that is included in the message. Information recipients are differentiated from message receivers (as shown in the Transmission Wrapper) because the information recipients do not have a role in the actual message management and transmission.

To convey an organization instead of person, leave the player empty and use the scoper.

  • subject: The control act has zero to many subject acts. Note that multiple subject acts should be of the same type (for easy and reasonable binding in the XML ITS). This class provides an entry point into the data structure that is conveyed in the body of the message. Note that the contextConductionIndicator is always "false", i.e. none of the participations described above are conducted to (inherited by) the domain payload. Any participations that are required within the domain information model need to be included there. Note: Refer to the (The user identified specification IMMCAI is not available) and (The user identified specification IMMCAI is not available) regarding Refinement, Constraint, and Localization.

Reporting Errors and Issues

An application which processes a message may detect various errors and issues related to the structure or the content of a message.