Communication Process Model

Interaction and Transmission Patterns

Glossary definition: An Interaction Pattern is a sequence of interactions that are related because they belong to one and the same business process.

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.

Duscussion May2006

Runtime path group id = the set of paths that I will accept for this particular instance

Linkage of interactions within a “path instance” is handled by the identifiers within the payload

The path group can be expressed through an activity diagram

Ramifications:

• Implementers will declare:
  • I support application role X, with patterns A & D, and application role Y with patterns A & B
  • They may choose to restrict a pattern by indicating that certain ‘decision points’ will have a more limited number of outcomes. This would be considered “interoperable, but not strictly conformant.”
  • If there is need for a different pattern (because they want to market a different set of constraints a ‘conformant’), they need to convince the committee that it is a useful pattern.
• Committees will:
  • Define each ‘pattern’ as a distinct artifact
  • Attempt to re-use application role labels across patterns where general business responsibility is consistent
• From acknowledgement perspective:
  • Dump the concept of “application acknowledgements.”
  • Immediate mode responses can link request and response at the transmission level, if appropriate for the transmission protocol.
• Other rules:
  • Once a pattern has been invoked, the pattern cannot be changed throughout the duration of the conversation.
• On the wire, Must send:
  • transmission
    • interaction id
  • control act layer – needs to be persisted/retained
    • target application role id
    • target pattern id
    • (Note: these will still affect “can I support this interaction,” so this information will need to be processed when constructing accept acks.)

Motion: (May2006) MnM supports replacing the existing methodology of receiver responsibilities and application roles with the activity-diagram-based approach described above, and will seek endorsement of the committees at the Facilitators’ Roundtable meeting Thursday. If endorsed, this will be documented in a whitepaper to be incorporated in the HDF (and V3 Guide, etc.) and referred to Tooling and Publishing committees for implementation. (Austin, Patrick – 9:0:1) motion passes.

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:

1. Transmission.id - uniquely identifies a point-to-point hop. This is pretty useless at the business level.
2. ControlAct.id - uniquely identifies a particular action, which may be a step in a sequence
3. Transaction.id (does not yet exist) - uniquely identifies a particular sequence of actions (the Interaction Pattern type, the ID of the class)
4. 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?