Description 

This is an example application role for the receiver of a control act message.

Description 

This is an example application role for the sender of a control act message.

Description 

Type:

The trigger of the control act.

Parent:

Trigger Event Control Act Infrastructure (MCAI_DM700200UV)

This RMIM specifies the intermediate wrapper structure in the HL7 version 3 composite message payload specification that is used for notification and request for action type 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 to meet implementation requirements will be provided by the enforcement of a conformance profile at the time of specifying the implementation of the message interaction.

Contained Hierarchical Message Descriptions

Trigger Event Control Act

MCAI_HD700200UV01

Parent:

Trigger Event Control Act Infrastructure (MCAI_DM700200UV)

The DetectedIssueEvent can be used to convey observations made by a system as part of it's processing of a message. This is commonly used for identifying "business rule" or "process" problems that may result in a refusal to carry out a particular request to acknowledge the issue and/or by providing some form of mitigation factors. The Act or Acts that may cause the adverse outcome are the target of the subject ActRelationship. The DetectedIssueEvent can be either:

• detected by a receiver of the Act (and consequently reported back to the sender as an issue in an application acknowledgement)

• if already known (detected) by the originator of the act, it can be included by the originator.

The following list describes the attributes of DetectedIssueEvent:

• classCode: Required, mandatory, and constrained to the value ALRT

• moodCode: Required, mandatory, and constrained to the value EVN

• id: a unique identifier for this DetectedIssue (optional)

• code: indicates the type of problem being detected (e.g., drug-drug interaction) while the DetectedIssueEvent.value is used to represent a specific problem code (e.g., specific drug-drug interaction). The code attribute is defined with the domain ActDetectedIssueCode.

  Examples of types of issues include:

  • Detection of a drug-drug interaction

  • Identification of a late-submission for an invoice

  • Detection of a requested discharge for a patient which does not meet hospital-defined discharge criteria

  • Detection of insufficient authorization required when executing a query

• text: additional information

• value: the specific problem code (e.g. "Drug A causes death when combined with drug B")

Examples involving Prescriptions:

If the original message is about "Please suspend this Pharmacy Order", the Control Act would represent the "Please suspend", and the Pharmacy Order would be described (at least at a reference level) in the Payload.

The following is an explanation of how the ControlActProcess attributes and act relationships would be populated:

• code: What should be done (suspend something)

• author: Who asked for the suspension

• reasonCode: Why ask for the suspension

• reason act relationship: Why ask for the suspension

• effectiveTime: When should it be suspended

• performer: Who should suspend it

• If this request results in a rejection at the application level, the response has a ControlAct that says "Reject" pointing to a pharmacy order to say "I reject your request to suspend the pharmacy order."

The Payload of the Trigger Event Control Act would be the prescription.

Example of a rejection due to drug-drug interaction

This is a "business rule" problem. ControlActProcess.reasonCode would not be populated. DetectedIssueEvent.code = "DRG" representing the concept "Drug-drug interaction". DetectedIssueEvent.value = "Drug A causes death when combined with drug B". Also agree that there might be multiple DetectedIssueEvent classes, each having the appropriate code and value attributes regardless of how many problems there are.

Example of a rejection due medication not in stock:

ControlActProcess.reasonCode = "out of stock" (OS is the concept code, although it is only listed under the SubstanceAdminSubstitutionReason). That should be sufficient.

Example of a rejection due to multiple business rules:

If it breaks multiple business rules, e.g. a drug-drug interaction and an authorization issue and a financial issue. ControlActProcess.reasonCode would not be populated and then there would be three instances of DetectedIssueEvent to identify the three issues.

The management of the DetectedIssueEvent can be conveyed via the target DetectedIssueManagement Act class of the targetOf ActRelationship. The targetOf.typeCode is MITGT which will allow for removing or lessening the effect of the detected issue. The DetectedIssueManagement.code attribute is defined by the domain ActDetectedIssueManagementCode.

Examples of issue management types include:

• Compassionate Refill (e.g. if patient lost subscribed medication)

• Emergency Override (to allow data to be made available even if there is insufficient authorization to execute a query)

The DetectedIssueManagement class has the following attributes:

• moodCode: either DEF or EVN. The moodCode is EVN when the sender wishes to communicate an override request for the DetectedIssue, and DEF when a receiver (usually in an application level negative acknowledgement - NAK) wants to suggest possible override codes to the sender. Version 2 mapping: planned for v2.6.

• code: override type. Example: If a business rule states that a prescription on hold cannot be dispensed, an override type might be "Dispense Held Prescription" to allow the prescription to be dispensed in exception to the rule. Version 2 mapping: OVR-1, ERR-10

• text: override reason, override comments Example: A patient is given a prescription; however, before completing the prescription, the remaining pills are spoiled. The patient returns to their pharmacy and explains the situation to their pharmacist. The pharmacist decides to replace the spoiled drugs; however, when attempting to record the event, a message is returned indicating that the dispense would exceed the maximum amount prescribed. The pharmacist overrides the rule and specifies an Override Reason Code indicating a replacement of lost product. Version 2 mapping: OVR-2, ERR-11, OVR-3)

The ActOrderRequired class has the following attributes

• code: action to be taken. Example: After submitting a dispense transaction, a response is returned to the user indicating that the patient may be abusing drugs. Given the sensitivity of this warning, the error is returned with an indicator stating that the patient should not be informed of the error with the implication that steps should be taken to rule out or confirm the warning. Version 2 mapping: ERR-9.

The ActOrderRequired class has the following association:

• subject: identifies the party involved in the action identified by ActOrderRequired. Version 2 mapping: ERR-12

Contained Hierarchical Message Descriptions

Trigger Event Control Act Detected Issue CMET

MCAI_HD900000UV01

This HMD specifies the Trigger Event Control Act structure in the HL7 version 3 composite message specification that is used for action, information, and state transition control 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.

Examples:

• Sender asks addressee to do something depending on the focal Act of the payload. An example is "fulfill this order". Addressee has responsibilities to either reject the message (application response) or to act on it in an appropriate way (specified by the specific receiver responsibilities for the interaction).
• Sender sends payload to addressee as information. Addressee does not have responsibilities beyond serving addressee's own interest (i.e., read and memorize as it sees fit.) This is equivalent to an FYI on a memo.
• Sender transmits a status change pertaining to the focal act of the payload. This status of the focal act is the final state of the state transition. This can be either a request or a command, according to the mood of the control act.

Common Message Element Types Used

R_AssignedPerson	COCT_MT090100UV01
R_AssignedDevice	COCT_MT090300UV01
A_DetectedIssue	MCAI_MT900001UV01

Message Type List

Trigger Event Control Act	MCAI_MT700201UV01
Trigger Event Control Act - PRSC	MCAI_MT705201UV01

A local Common Message Element Type (CMET) used to refer to the detected issues in the trigger event control acts. It will not be utilized by itself, but as a reusable model artifact.

Message Type List

Trigger Event Control Act Detected Issue CMET

MCAI_MT900001UV01

Sender asks addressee to do something depending on the focal Act of the payload. An example is "fulfill this order". Addressee has responsibilities to either reject the message or to act on it in an appropriate way (specified by the specific receiver responsibilities for the interaction).

Trigger Event	Example, Control Act	MCAI_TE700201UV01
Transmission Wrapper	Send Message Payload	MCCI_MT000100UV01

Sending and Receiving Roles

Sender	Example, Control Act: Sender	MCAI_AR000001UV01
Receiver	Example, Control Act: Receiver	MCAI_AR000002UV01