Message Control Act Infrastructure
 ANSI/HL7 V3 IM, R1-2004 HL7 Version 3 Standard: Infrastructure Management: Message Control Act Infrastructure 10/20/2004 |
| Responsible Group | Infrastructure and Messaging Work Group HL7 |
| Control Query Co-Chair | 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 |
HTML Generated: 2012-08-31T12:04:28
Content Last Edited: 2011-07-13T15:38:54
HL7® Version 3 Standard, © 2004 Health Level Seven® International All Rights Reserved.
HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
Use of these materials is governed by HL7 International's IP Compliance Policy.
Table of Contents
Preface
i Notes to Readers
ii Message Design Element Navigation
1 Overview
1.1 Introduction & Scope
1.2 Domain Information Models
2 Trigger Event Control Act Topic
2.1 Introduction
2.2 Application Roles
2.3 Trigger Events
2.4 Refined Message Information Models
2.5 Hierarchical Message Descriptions
2.6 Interactions
3 Quality Analysis Report Topic
4 CMETs Used by this Domain
5 Interactions Annex
5.1 By Application Role
5.2 By Trigger Event
5.3 By Message Type
6 Glossary
This is the normative material for Version 3, Release 1.
|
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.
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:
- Action, Information, or State Transition Control messages
- Query and Query Response messages
- Master File / Registry Act messages
Accept-level acknowledgements are a message control function that do not require or allow a Control Act.
Application-level acknowledgement (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.
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 and a receiving application. For reliable messaging interactions, there is a sequence of at least two messaging events. Refer to Transmission Infrastructure for the modes of messaging. The initial message interaction generally passes application content that is the purpose for the 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.
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.
Diagram
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.
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 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".
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 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 Note to Implementors and Note to Technical Committees 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.
- If the errors are related to the secure delivery of the message or its structure then the errors are identified in the Transmission Wrapper. Examples include "Couldn't parse", "Receiver doesn't exist", "Conformance profile unknown".
- If the issues (errors) are related to the information as conveyed by the message, evaluated in context by the processing application, then the issues are identified by means of the reason act association. The detected issues are related to "business-rule" or "process" problems. Examples include: "drug-drug interaction", "invoice too late".
The reason act relationship is used to convey detected issues. Following is a list of reason's attributes:
- typeCode: constrained to the value RSON
- contextConductionIndicator: If true, associations in the control act are conducted across the reason to the DetectedIssueEvent
Refer to the Detected Issue Event R-MIM Walkthrough for details regarding the DetectedIssueEvent that can be used to convey observations made by a system as part of it's processing of a message.
| Return to top of page |