Communication Process Model
Glossary definition: An Interaction Pattern is a sequence of interactions that are related because they belong to one and the same business process.
Contents
Details
Note: the use of Interaction Patterns has not been formally accepted as methodology. At this point in time this page tries to explore the concept.
An Interaction Pattern consists of 1 or more Transmission Patterns. The interactions may be linked by business process identifiers such as "Placer Order ID", "queryId", "PrescriptionID"", or by a new attribute (probably on the controlAct) which acts as a link between all Transmissions contained in an Interaction Pattern instance..
At this level of abstraction the delivery method of the interactions is of no relevance whatsoever.
- The use of some Interactions (e.g. Accept Level Acknowledgement,
Polling Interaction, Query Continuation/Abort Interaction and Batch Based Interactions) is not relevant for an Interaction Pattern, this is relevant at the Transmission level only.
- Most Storyboard Diagrams in the HL7 v3 standard describe (part of) an
Interaction Pattern.
- Interaction Patterns can exist as a definition (a class) as well as a partcular instance of that pattern.
Examples
A Laboratory Order, followed by a Promise, a modification of the Order by the Laboratory, and a final labresult constitutes an interaction. The interaction pattern consists of 3 Transmission Patterns. The initiating interaction of each Transmission Pattern results in messages linked to it by means of the Transmission Wrapper.
Notes
How should we identify a business process, when the identifier remains the same across several business processes, and may not even exist at all times through-out the process? Basically we have the following:
- Transmission.id - uniquely identifies a point-to-point hop. This is pretty useless at the business level.
- ControlAct.id - uniquely identifies a particular action, which may be a step in a sequence
- Transaction.id (does not yet exist) - uniquely identifies a particular sequence of actions (the Interaction Pattern type, the ID of the class)
- Payload.id - uniquely identifies a business object which may be manipulated by 0..* transactions. This is pretty useless at the business level, for it may not be the same object that is being manipulated by all Interactions in an interaction pattern. Use of the Payload.id doesn't make sense since this should be fully use case and content oriented.
Impact on MCCI Artefacts
If the use of Interaction Patterns is accepted as part of the methodology then this will have a number of consequences for the MCCI materials.
- One and the same composite message type will be used for both state based triggers as well as Application Responses.
- This means that both a notification as well asn an Application response use one and the same Transmission Wrapper. This leads to the question what the role of the Acknowledgement class is in this new dynamic model.
- It also means we’ll have only 1 Transmission Wrapper model which is used by all interactions, irrespective of whether they’re used in notification interactions or responses.
- An attribute will have to be added to interaction instances to specify to what “Interaction Pattern type” they belong to.
- The identification of the “Interaction pattern Instance” the interaction instance belongs to (effectively a conversation ID) probably requires an identification as well.
- InteractionId is currently defined as the triplet (Trigger event, composite message type, receiver responsibilities).
- Receiver Responsibilities will be removed from this definition. The initial interaction which starts an interaction pattern will identify the appropriate “Interaction Pattern type” somewhere in the composite message type, it wont be precoordinated within the IN identifier.
- The current methodology states that each interaction has 1 Trigger Event associated with it. Either we have to change the statement to say that a interaction may be caused by one out of a defined set of TEs (and this set of TEs is then associated with the IN), or we should remove the TE from the triplet which defines an IN. If TE is dropped as part of the definition of an IN, the interaction identifier will solely identify the elements the composite message is being made up of.
- All of this weakens the role of the TE identifier, unless Interaction Patterns still use TEs to determine dynamic behaviour.
Business-Level Receiver Resonsibilities
The question pharmacy and lab were faced with (and which ahs been extensively discussed) seems to boil down to this example use-case: how do I send (1) "here's an order, please perfom" v. (2) "FYI: here's an order, please keep on record, do not perform".
- Let's assume that both interactions (1) and (2) are notifications that DO NOT have receiver responsabilities. (i.e. no application-level accepts or rejects)
- In that case interaction (1) has the same structure, trigger event, and (communication-level) receiver responsabilities as interaction (2). So currently in v3 modeling terms they are exactly the same.
- So we have a use-case for wishing to explicitely include some of the "business level receiver responsabilities" of the receiver into the interaction, e.g. "this is an order I want you to act upon" v. "FYI, do nothing".
Duplication
Note also that this also might have repercussions for the "duplication" item at MCCI item lists. Is there a difference if the message is "duplicated" at the Transmission.id or at the ControlAct.id/Transaction.id level?
