Trigger Event

An Event which, when recorded or recognized by an application, indicates the need for an information flow to zero or more other applications, resulting in one or more Interactions.

A trigger event is an explicit set of conditions that initiate the transfer of information between system components (Application Roles). The trigger event represents the “real-world” event such as the placing of a laboratory order or drug order. The trigger event must be systematically recognizable by an automated system.

The Trigger Event may be caused by one of the following reasons:

• User Request Based (in this document also referred to as Environmental) - For example, the trigger event that prompts a system to send all accumulated data to a tracking system every 12 hours is considered Environmental. Similarly a user pressing a button in a user-interface would be considered environmental
• State Transition - resulting from a state transition as depicted in the State Transition Model for a particular message interaction. The trigger for canceling a document, for example, may be considered a State Transition Based trigger event
• Interaction Based - based on the receipt of another interaction. For example, the response to a query (which is an interaction) is an Interaction Based trigger event.

See below for a discussion of the impact of trigger events on a message receiver.

State Transition Trigger Events

Most trigger events are State-Transition based and will be encountered when reading the dynamic message model information defined to support a particular message interaction. Some trigger events may be based on more than one state transition (e.g. of the Focal Class -state changes to active- as well as of the act it replaces -state changes to aborted-) , which are assumed to occur simultaneously.

A trigger event may be defined for one specific type of order (e.g. a laboratory order) or at a "higher-level" (e.g. for any order). When a specific type of order is created, both the specific trigger and the more generic trigger would fire simultaneously. Example: You can have triggers that fire on the creation of an observation and triggers that fire on the creation of a public health case. If a public health case is created, you'd expect the triggers associated with both public health-cases as well as generic observations to fire. Similarly, if you had triggers that fire on the creation of an Intent, then they should also fire on the creation of an Order.

Trigger events which are either invoked by a state transition or which are associated with a state transition (as a request, fulfillment request or refusal) should include a link to the D-MIM definition of the class to be transitioned as well as the transition to occur (or which has occurred or was refused) for each associated transition.

The act which has undergone the state transition need not be communicated in the interaction(s) that were trigger by the state transisition: it could well be that an "Admission" (focal class = encounter) might cause other information to be passed around (such as patient demographics, allergies, etc.) Note: on the assumption the encounter interaction and an allergies notification are two different interactions: if the domain committee has defined that "fire the trigger event on activation of an encounter provided that allergies are present", then that's a state-transition based trigger with a guard condition which triggers two distinct interactions. If such a trigger event has not been defined, and the user causes an allergy interaction to be sent as a result of a manual or automated process, then the trigger event of the allergy interaction would be Environmental in nature.

Managed Participations

Suppose I want to send "a request for a transfer of a location". Location is a participation to an encounter. For the request I'd however need to have an Act in RQO mood. How would one model such a request?

• The trigger event would be represented as a CACT(EVN). At the moment we use that form whether the controlAct is requesting something (e.g. "please suspend X") or reporting something (e.g. "X has been suspended"). The subject of the ControlAct would be the encounter (presumably also in event mood) and the two locations as you've identified. You're actually undergoing two simultaneous state transitions (one for the old location and one for the new), which is similar to what happens when we do a supersede (with one act going to obsolete and the second act going to normal).

Receiver behaviour

A Trigger Event (within a sending application) represents an event which happened at the sender's side of the communication link. As specified in the Dynamic Model the behaviour of a receiving application (in terms of the response/resulting interactions it sends) is exclusively linked to the interaction (in the form of its Receiver Responsibilities). For example: the Trigger Event "creation of a new Prescription" may result in a "fulfillment request interaction" as well as a "notification of the creation of a request interaction". The trigger event doesn't distinguish between the notification or the fulfillment request; this is accomplished at the interaction level.

For a receiving application the Trigger Event may determine the way in which the message contents are processed. For example: the focal Act of a has the status "completed". If the Trigger Event indicates a state transition from active-to-completed, then this may cause a different way of processing the message contents than if the trigger event indicates a completed-to-completed (a correction) state transition. For this reason all HL7 messages must contain (in an implicit or explicit fashion) the identification of the trigger event.

Notes

1. When defining a Trigger Event, it can't be used to negate or otherwise significantly alter the semantics of the static model being communicated. Example: if the focal act of the Domain Payload is in EVN mood, the Trigger Event (when used as a Receiver Responsibility) can't redefine the message to be an Order.
2. An Environmental trigger event at the sender's side may be associated with a state transition at the receiver end. For example, a request to 'suspend' an Act would be triggered by an environmental trigger (e.g. a user clicking a button saying 'suspend').
3. A trigger event (when defined as a receiver responsibility option) may result in zero interactions, either because the receiver supports no interactions that are fired by that trigger event, or because the application configuration is such that no potential receivers have been registered as interested in receiving such interactions, then nothing happens.

Discussion

On 20070110 Mark Tucker expressed concern about trigger events.

• Desire to separate between "real world trigger events" (e.g. patient admitted) and the method being called (e.g. Make Bed). The original trigger mostly is of no interest whatsoever to the receiver.
• Desire to have "methodName" as the main label for an interaction (instead of interactionID). By not precoodinating this with a trigger event (e.g. one partcular state change) the method could be used for a wider scope of things
• Rene notes that there is a difference in use-cases (needs more analysis):
  • If one receives a patient admit interaction (which carries a patient admit), and one sends interactions as a result of that one wouldn't reference/use the original event in those interactions
  • If the patient admit occurs within one's own system, then current methodology states that one does reference the original event