This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Interaction"

From HL7Wiki
Jump to navigation Jump to search
(new page)
Line 3: Line 3:
 
*[[Trigger Event]] - each interaction will be associated with a single trigger event.  The trigger event represents the “real-world” occurrence that creates a need to exchange information.  Note that a given trigger event may fire multiple interactions.  
 
*[[Trigger Event]] - each interaction will be associated with a single trigger event.  The trigger event represents the “real-world” occurrence that creates a need to exchange information.  Note that a given trigger event may fire multiple interactions.  
 
:Note that the semantic context of an interaction has to be defined by a domain.
 
:Note that the semantic context of an interaction has to be defined by a domain.
: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.
 
  
 
*[[Composite Message Type]] – The set of static model definitions (wrappers and message types) that define the structures of the data that is transmitted by the interaction.  Committees will explicitly identify all message types (transmission wrapper, control act wrapper and payload) associated with a particular interaction.
 
*[[Composite Message Type]] – The set of static model definitions (wrappers and message types) that define the structures of the data that is transmitted by the interaction.  Committees will explicitly identify all message types (transmission wrapper, control act wrapper and payload) associated with a particular interaction.

Revision as of 04:56, 30 November 2005

Interactions are defined as a triplet involving the following elements:

  • Trigger Event - each interaction will be associated with a single trigger event. The trigger event represents the “real-world” occurrence that creates a need to exchange information. Note that a given trigger event may fire multiple interactions.
Note that the semantic context of an interaction has to be defined by a domain.
  • Composite Message Type – The set of static model definitions (wrappers and message types) that define the structures of the data that is transmitted by the interaction. Committees will explicitly identify all message types (transmission wrapper, control act wrapper and payload) associated with a particular interaction.
In terms of structure an Interaction can be either a Message-based Interaction or a Batch-based Interaction. Interactions consist of:
1. a Batch Wrapper (conditional upon it being a Batch)
2. a Transmission Wrapper
3. a Trigger Event Control Act Wrapper (conditional)
4. Domain Content (optional)


  • Receiver Responsibilities - will be defined for the target receiver of the message. The receiver responsibilities will be cast in terms of one of several interactions to be sent as a result of receiving the message and/or as one trigger event out of a set of trigger events the receiver will fire after receipt of the message. Implementers will need to take care that applications that can send an interaction are capable of receiving the ‘receiver responsibility’ interactions, and vice versa.
Receiver Responsibilities are a set of mutually exclusive responsibility options that are triggered by the receipt of an interaction. Each responsibility option includes a description that describes the circumstances under which that option should be fired. These circumstances are all mutually exclusive, such that one and only one responsibility option fires in response to a given interaction.
A responsibility option consists of:
A) An optional trigger event the receiver should fire
B) An optional interaction the receiver should return. (This is what's sent as an 'application acknowledgment')
It is possible that the responsibility option interaction will itself have receiver responsibilities, resulting in a prolonged conversation between sender and receiver.