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

Difference between revisions of "Communication Process Model"

From HL7Wiki
Jump to navigation Jump to search
Line 6: Line 6:
  
 
== Details ==
 
== 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 Pattern]]s. The
 
An Interaction Pattern consists of 1 or more [[Transmission Pattern]]s. The
 
interactions may be linked by business process identifiers such as
 
interactions may be linked by business process identifiers such as
−
"Placer Order ID", "queryId", "PrescriptionID".
+
"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.
 
At this level of abstraction the delivery method of the interactions is of no relevance whatsoever.
Line 17: Line 18:
 
[[Batch Based Interaction]]s) is not relevant for an Interaction
 
[[Batch Based Interaction]]s) is not relevant for an Interaction
 
Pattern, this is relevant at the Transmission level only.
 
Pattern, this is relevant at the Transmission level only.
−
*Most [[Storyboard Diagrams]] in the HL7 v3 standard describe an
+
*Most [[Storyboard Diagrams]] in the HL7 v3 standard describe (part of) an
 
Interaction Pattern.
 
Interaction Pattern.
 
*Interaction Patterns can exist as a definition (a class) as well as a partcular instance of that pattern.
 
*Interaction Patterns can exist as a definition (a class) as well as a partcular instance of that pattern.
Line 31: Line 32:
 
== Notes ==
 
== Notes ==
  
−
All interactions have to have a payload model, to ensure all interactions contain some form of business-process-identifier, which allows the linking of individual Transmissions within an Interaction Pattern.
+
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:
−
''20060113: MNM WGM: All app level interactions must have a defined payload model. for simple accept/refusal interactions the payload may be limited to a simple shared message MT referencing the request being accepted/refused. (Rene/Heath, 6-0-2)''
+
#Transmission.id - uniquely identifies a point-to-point hop. This is pretty useless at the business level.
−
Ongoing discussion: there are use-cases where a payload may not make sense.
 
−
 
 
−
Discussion: How can payload.id be a 'primary' identifier for 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
 
 
#ControlAct.id - uniquely identifies a particular action, which may be a step in a sequence
 
#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
+
#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.
+
#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. 
  
−
(LLoyd) I agree that #1 is pretty useless at the business level.  I'd love for us to use #2.  I can get talked into supporting #3.  I think #4 is as useless for the purposes you're describing as #1 is.
+
== Impact on MCCI Artefacts ==
  
−
(Miroslav) Just want to suppport Lloyd's suggestion. From the communication dynamics point of view, I don't think that business process id can be contained in Transmission Wrapper. Having it in the Payload also doesn't make sense since this should be fully use case and content oriented. Control Act Wrapper is the single logical place to have the business process identification managed.
+
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.
  
−
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 and ControlAct.id level?
+
*One and the same composite message type will be used for both state based triggers as well as [[Application Response]]s.
 +
**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 ==
 
== Business-Level Receiver Resonsibilities ==
  
−
The question pharmacy and lab are faced with 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".
+
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 the receiver responsabilities (from a pure communications standpoint) are the same, and that both interactions (1) and (2) are notifications that DO NOT have receiver responsabilities. (i.e. no application-level accepts or rejects)
+
*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.
 
*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".
 
*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".
  
−
(Tom de Jong): The example use-case states that the interactions do not have receiver responsibilities, but that's not entirely true. [[Receiver Responsibilities]] have two (potential) elements:
+
== Duplication ==
−
#the required response interactions (communication responsibilities) and/or
 
−
#the required resulting trigger events (processing responsibilities). Of course the trigger event and the interaction will often go hand in hand, but in this example we assumed there were no communication responsibilities.
 
−
 
 
−
So the first question is: can the difference between the two interactions be determined by the fact that one will result in a trigger at the receiver (the request for fulfilment) and the other will not (the notification)? So in this example, without a response interaction, what is the resulting trigger event (so, on the receiver side) for the fulfilment request?
 
−
 
 
−
(Rene) One of the problems when discussing this is that the definition of [[Receiver Responsibilities]] has never been formally agreed upon. There is a working definition, but it contains a definition of [[Trigger Event]] that is purely communication oriented, not business process oriented.
 
  
−
(Lloyd)We need to discuss within MnM whether introducing a level of standardization above the existing level of "receiver responsibilities" is desirable. Effectively what we'd be doing is defining part of the 'internal' state machine of the various application roles and showing how a complete flow might occur. This gets into the area of application behavior, which is an area where HL7 has traditionally tread very lightly. (Rene) This additional level is currently labeled [[Interaction Pattern]] on this Wiki.
+
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?
  
  
 
[[Category:INM Glossary]]
 
[[Category:INM Glossary]]

Revision as of 17:07, 13 May 2006

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.

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.

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:

  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?

Retrieved from "https://wiki.hl7.org/w/index.php?title=Communication_Process_Model&oldid=3855"