Trigger Event

An Event which, when recorded or recognized by an application, indicates the need for an information flow to one 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:

• User Request - For example, the trigger event that prompts a system to send all accumulated data to a tracking system every 12 hours is considered User Based.
• 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 another interaction. For example, the response to a query (which is an interaction) is an Interaction Based trigger event.

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, which are assumed to occur simultaneously.

Discussion

A pharmacy can request for a physician order to be aborted (1) , but can't cancel it themselves. A physician can abort the order (2) and request the pharmacy to fulfill that. When they do so, they're not saying "abort your promise" or "abort your event". They're saying "Do what ever you need to do to deal with the fact that this order is cancelled". That may involve contacting a delegated pharmacy, or many other things the physician system doesn't know about or care about. The state-transition of (1) and (2) is the same. The payload is the same. The semantics of the request are distinct. The pharmacy domain has to define 2 different trigger events (“Please suspend this order” and “Please Deal With the Fact that I suspended this Order”). (Dick) In V2 we used to say the Trigger Events were real-world events such as "a patient is admitted" a lab test is ordered. (Rene) And that's the way it should stay IMO. If we look at activity diagrams, then these define the circumstances and the reasons for cummication.

Adding the Notification or Fullfillment request suffixes amounts to assigning "receiver behaviour" aspects to a trigger event. We don't want this to be dealt with at that level; receiver behaviour is linked to the interaction (in the form of receiver responsibilities) or to atribute values within the message itself.