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
 
(20 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
[[Image:Dynamic_patterns.gif|300px|right|thumb|Interaction and
+
{{MnM Closed Hot Topic}}
−
Transmission Patterns]]
+
{{INM Workitem}}
  
−
'''Glossary definition:''' An Interaction Pattern is a sequence of interactions that are related
+
'''Closed:''' May 2009 because it is being super ceded by new work on a dynamic model.
−
because they belong to one and the same business process.  
+
 
 +
'''Glossary definition:''' A Communication Process Model ([[CPM]]) is .... The model is part of the [[Dynamic Model]] and is documented using an [[Activity Diagram]].
 +
 
 +
'''NOTE: The concepts on this page have not been formally approved yet.''' Motion: (May2006) MnM supports replacing the existing methodology of receiver responsibilities and application roles with the activity-diagram-based approach described below, 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.
 +
 
 +
{{INM Motion|20070505 WGM: Strawvote (8-0-2): Explore the idea that CPMs be consider interaction patterns that can be bound to static model content within the scope allowed by committees at conformance time. We currently allow binding by committees only.}}
  
 
== Details ==
 
== Details ==
  
−
An Interaction Pattern consists of 1 or more [[Transmission Pattern]]s. The
+
[[Image:Cpm example diagram.gif|250px|right|thumb|CPM Example (beta draft)]]
−
interactions may be linked by business process identifiers such as
+
 
−
"Placer Order ID", "queryId", "PrescriptionID".
+
A CPM expresses our understanding of flows or patterns of behavior around the exchange of groups of [[Composite Message Type]]s. They describe under what circumstances a composite message type is transmitted.
 +
 
 +
Note: 2008/05/04 - Discussion deferred as the ARB is working on this as an action item.  They'll come back to MnM when they have something to discuss.
 +
 
 +
A CPM is documented using an [[Activity Diagram]]s (basically flowdiagrams with decision points), with "swimlanes" that represent application roles. They are much more expressive than sequence (interaction) diagrams. The modelling is limited to communication related activities, the aim is not to "model the whole world". Decision Points show choices, but don't specify how the choice should be made, as that is application/business rule behavior which is out of scope of HL7.
  
 
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.
  
−
*The use of some Interactions (e.g. [[Accept Level Acknowledgement]],
+
CPMs may exist at various levels, e.g.
−
[[Polling Interaction]], [[Query Continuation/Abort Interaction]] and
+
*higher level ''abstract CPMs'' (a.k.a. stereotype, non implementable) - e.g. a generic Order workflow
−
[[Batch Based Interaction]]s) is not relevant for an Interaction
+
*Domains may define 1, or a set of, CPMs. CPMs may follow archetypes/stereotypes (e.g. orders). Nuance differences, constrain/extend CPM in domain.
−
Pattern, this is relevant at the Transmission level only.
+
*CPMs can be profiled for conformance reasons. CPMs can be constrained by committees as well. Constraining a CPM may be done in the form of reducing the number of options by the removal of decision points from a CPM, constraining the circumstances where a trigger event is invoked.
−
*Most [[Storyboard Diagrams]] in the HL7 v3 standard describe an
+
*Extended CPMs. It has yet to be established how “extensions” are allowed (e.g. for realms). We may have to uspport “local extensions in a separate namespace” on dynamic models expressed by CPMs.
−
Interaction Pattern.
+
 
−
*Interaction Patterns can exist as a definition (a class) as well as a partcular instance of that pattern.
+
CPMs may have multipe entry points. CPMs form the basis for [[Conformance Statement]]s (e.g. "I am a Lab system and I support the following CPMs").
 +
 
 +
A [[Communication Process Instance]] ([[CPI]]) identifies one partular instance of a CPM. Activity Diagrams that show 1 specific CPI (which contains no more "open" decision points) is effectively a Sequence Diagram. Activity Diagrams are normative (and contain information we don't currently capture), [[Sequence Diagram]] are examplary. Sequence Diagrams will be used in combination with storyboards, because storyboards typically describe a CPI.
 +
 
 +
A CPM has an artefact ID (e.g. POLB_PM123456UV01), a CPI is identified by means of an II attribute. The CPI identifier is known in other environments as the ''business process identifier'' or ''conversation ID''. Examples of a similar concept (limited to query/response based CPMs) already present in v3 interactions is "queryId". Both identifiers are referenced in the contractual portion of the transmision wrapper.
 +
 
 +
== Requirements ==
  
−
=== Examples ===
+
CPMs have been introduced to cover the following requirements:
 +
*they need to define what [[Composite Message Type]] can be exchanged
 +
*they need to indicate types of systems ([[Application Roles]]) are capable of sending which composite message types
 +
*they identify under what circumstances a composite message type is transmitted
 +
*they need to be able to express our understanding of flows or patterns of behavior around the exchange of groups of composite messages
  
−
A Laboratory Order, followed by a Promise, a modification of the Order
+
Objectives:
−
by the Laboratory,  and a final labresult constitutes an interaction.
+
*set expectations for conformance (including from a dynamic perspective). Conformance Statement: "I am a Lab system and I support the following patterns".
−
The interaction pattern consists of 3 Transmission Patterns. The
+
*lower the number of interaction artefacts necessary to cover the various scenarios in a domain. For example avoids having to define all interactions twice in the Lab domain (with and without [[Receiver Responsibilities]]).
−
initiating interaction of each Transmission Pattern results in messages
 
−
linked to it by means of the Transmission Wrapper.
 
  
−
== Notes ==
+
Observations:
 +
*how to call artefact. [[HDF]] "dynamic view". Activity Diagram used to document CPM: Communication process Model, Communication Process Instance. This is part of the dynamic model.
 +
*transition: transform current receiver responsibilities into simple CPMs. Committees can define more complex ones.
 +
*Remove "receiver responsibility" from HL7 Interaction concept. Interaction = tuple ([[Trigger Event]], [[Composite Message Type]]).
  
−
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.
+
== Transition Issues ==
−
''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)''
 
−
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:
+
Transitioning from the old dynamic model (expressed in terms of [[Receiver Responsibilities]], with an Interaction ID being a tuple of ([[Trigger Event]], [[Composite Message Type]], [[Receiver Responsibilities]]) to a CPM based dynamic model calls for several changes to be made. The new CPM based ynamic model should be in place during the January 2007 WGM.
−
#Transmission.id - uniquely identifies a point-to-point hop
 
−
#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
 
−
#Payload.id - uniquely identifies a business object which may be manipulated by 0..* transactions.
 
  
−
(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.
 
  
−
(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.
+
*Transform to take existing dynamic model content (e.g. receiver responsibilities) in to CPMs. Create identifiers for these “old” CPMs, e.g. by using the existing interaction id for the ‘request’, with new “artifact” portion.
 +
*Need to have some starting-point patterns for committees
 +
*Remove [[Receiver Responsibilities]] from the concept of Interaction ID.
  
−
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?
+
The introduction of CPMs has a number of consequences for the MCCI materials.
  
−
== Business-Level Receiver Resonsibilities ==
+
*Interaction ID turns into a tuple consisting of [[Trigger Event]] and [[Composite Message Type]] (see [[Interaction (new dynamic model)]] for details). If an [[Application Response]] was generated based on an Interaction Based trigger event (e.g. a qyery response interaction) then such one interaction requires Acknowledgement/AcknowledgementDetail classes in its wrapper. If an [[Application Response]] was generated based on an State Based trigger event (e.g. a Promise interaction) then .. this leads to the question what the role of the Acknowledgement/AcknowledgementDetail classes are in this new dynamic model.
 +
**It could mean we’ll have only 1 [[Transmission Wrapper]] model which is used by all interactions, irrespective of whether they’re used in initial interactions or in responses.
 +
*An attribute will have to be added to interaction instances to specify to what CPM they conform to.
 +
**The identification of the CPI (effectively a conversation ID) needs to be added to the transmission(?) wrapper.
  
−
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".
+
== Notes ==
−
*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)
 
−
*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".
 
  
−
(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:
+
A Laboratory Order, followed by a Promise, an optional modification of the Order by the Laboratory, and a final labresult constitutes a CPM.
−
#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?
+
*The use of some Interactions (e.g. [[Accept Level Acknowledgement]],
 +
[[Polling Interaction]], [[Query Continuation/Abort Interaction]] and
 +
[[Batch Based Interaction]]s) is not relevant for an CPM, this is relevant at the Transmission level only.
 +
*Most [[Storyboard Diagrams]] in the HL7 v3 standard describe a CPI or (part of) a CPM.
  
−
(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.
+
Ramifications:
 +
*Implementers will declare:
 +
**I support application role X, with CPMs A & D, and application role Y with CPMs 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 CPM (because they want to market a different set of constraints a ‘conformant’), they need to convince the committee that it is a useful CPM.
  
−
(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.
+
*Committees will:
 +
**Define each CPM as a distinct artifact
 +
**Attempt to re-use application role labels across CPMs where general business responsibility is consistent
  
 +
*Other rules:
 +
**Once a CPM has been invoked, the CPM cannot be changed throughout the duration of the conversation.
  
−
[[Category:INM Glossary]]
+
Note from the INM out of cycle meeting: Even if a [[Transmission SLA]] is in place, we may still have run-time SLA options which have to be conveyed within an interaction instance that may have an influence on how & when an interaction is responded to.

Latest revision as of 05:31, 10 May 2009

ClosedHotTopic.GIF

This page documents a Closed, fully actioned MnM Hot Topic, i.e. a methodology issue requiring a resolution from Modeling and Methodology.

INM workitem.gif

This page documents an INM Workitem, i.e. an issue within scope of the INM Committee that either is still being discussed, or the resolution of which has not yet been included in an INM ballot.

Closed: May 2009 because it is being super ceded by new work on a dynamic model.

Glossary definition: A Communication Process Model (CPM) is .... The model is part of the Dynamic Model and is documented using an Activity Diagram.

NOTE: The concepts on this page have not been formally approved yet. Motion: (May2006) MnM supports replacing the existing methodology of receiver responsibilities and application roles with the activity-diagram-based approach described below, 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.

INM committee motion: 20070505 WGM: Strawvote (8-0-2): Explore the idea that CPMs be consider interaction patterns that can be bound to static model content within the scope allowed by committees at conformance time. We currently allow binding by committees only.

Details

CPM Example (beta draft)

A CPM expresses our understanding of flows or patterns of behavior around the exchange of groups of Composite Message Types. They describe under what circumstances a composite message type is transmitted.

Note: 2008/05/04 - Discussion deferred as the ARB is working on this as an action item. They'll come back to MnM when they have something to discuss.

A CPM is documented using an Activity Diagrams (basically flowdiagrams with decision points), with "swimlanes" that represent application roles. They are much more expressive than sequence (interaction) diagrams. The modelling is limited to communication related activities, the aim is not to "model the whole world". Decision Points show choices, but don't specify how the choice should be made, as that is application/business rule behavior which is out of scope of HL7.

At this level of abstraction the delivery method of the interactions is of no relevance whatsoever.

CPMs may exist at various levels, e.g.

  • higher level abstract CPMs (a.k.a. stereotype, non implementable) - e.g. a generic Order workflow
  • Domains may define 1, or a set of, CPMs. CPMs may follow archetypes/stereotypes (e.g. orders). Nuance differences, constrain/extend CPM in domain.
  • CPMs can be profiled for conformance reasons. CPMs can be constrained by committees as well. Constraining a CPM may be done in the form of reducing the number of options by the removal of decision points from a CPM, constraining the circumstances where a trigger event is invoked.
  • Extended CPMs. It has yet to be established how “extensions” are allowed (e.g. for realms). We may have to uspport “local extensions in a separate namespace” on dynamic models expressed by CPMs.

CPMs may have multipe entry points. CPMs form the basis for Conformance Statements (e.g. "I am a Lab system and I support the following CPMs").

A Communication Process Instance (CPI) identifies one partular instance of a CPM. Activity Diagrams that show 1 specific CPI (which contains no more "open" decision points) is effectively a Sequence Diagram. Activity Diagrams are normative (and contain information we don't currently capture), Sequence Diagram are examplary. Sequence Diagrams will be used in combination with storyboards, because storyboards typically describe a CPI.

A CPM has an artefact ID (e.g. POLB_PM123456UV01), a CPI is identified by means of an II attribute. The CPI identifier is known in other environments as the business process identifier or conversation ID. Examples of a similar concept (limited to query/response based CPMs) already present in v3 interactions is "queryId". Both identifiers are referenced in the contractual portion of the transmision wrapper.

Requirements

CPMs have been introduced to cover the following requirements:

  • they need to define what Composite Message Type can be exchanged
  • they need to indicate types of systems (Application Roles) are capable of sending which composite message types
  • they identify under what circumstances a composite message type is transmitted
  • they need to be able to express our understanding of flows or patterns of behavior around the exchange of groups of composite messages

Objectives:

  • set expectations for conformance (including from a dynamic perspective). Conformance Statement: "I am a Lab system and I support the following patterns".
  • lower the number of interaction artefacts necessary to cover the various scenarios in a domain. For example avoids having to define all interactions twice in the Lab domain (with and without Receiver Responsibilities).

Observations:

  • how to call artefact. HDF "dynamic view". Activity Diagram used to document CPM: Communication process Model, Communication Process Instance. This is part of the dynamic model.
  • transition: transform current receiver responsibilities into simple CPMs. Committees can define more complex ones.
  • Remove "receiver responsibility" from HL7 Interaction concept. Interaction = tuple (Trigger Event, Composite Message Type).

Transition Issues

Transitioning from the old dynamic model (expressed in terms of Receiver Responsibilities, with an Interaction ID being a tuple of (Trigger Event, Composite Message Type, Receiver Responsibilities) to a CPM based dynamic model calls for several changes to be made. The new CPM based ynamic model should be in place during the January 2007 WGM.


  • Transform to take existing dynamic model content (e.g. receiver responsibilities) in to CPMs. Create identifiers for these “old” CPMs, e.g. by using the existing interaction id for the ‘request’, with new “artifact” portion.
  • Need to have some starting-point patterns for committees
  • Remove Receiver Responsibilities from the concept of Interaction ID.

The introduction of CPMs has a number of consequences for the MCCI materials.

  • Interaction ID turns into a tuple consisting of Trigger Event and Composite Message Type (see Interaction (new dynamic model) for details). If an Application Response was generated based on an Interaction Based trigger event (e.g. a qyery response interaction) then such one interaction requires Acknowledgement/AcknowledgementDetail classes in its wrapper. If an Application Response was generated based on an State Based trigger event (e.g. a Promise interaction) then .. this leads to the question what the role of the Acknowledgement/AcknowledgementDetail classes are in this new dynamic model.
    • It could mean we’ll have only 1 Transmission Wrapper model which is used by all interactions, irrespective of whether they’re used in initial interactions or in responses.
  • An attribute will have to be added to interaction instances to specify to what CPM they conform to.
    • The identification of the CPI (effectively a conversation ID) needs to be added to the transmission(?) wrapper.

Notes

A Laboratory Order, followed by a Promise, an optional modification of the Order by the Laboratory, and a final labresult constitutes a CPM.

Polling Interaction, Query Continuation/Abort Interaction and Batch Based Interactions) is not relevant for an CPM, this is relevant at the Transmission level only.

Ramifications:

  • Implementers will declare:
    • I support application role X, with CPMs A & D, and application role Y with CPMs 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 CPM (because they want to market a different set of constraints a ‘conformant’), they need to convince the committee that it is a useful CPM.
  • Committees will:
    • Define each CPM as a distinct artifact
    • Attempt to re-use application role labels across CPMs where general business responsibility is consistent
  • Other rules:
    • Once a CPM has been invoked, the CPM cannot be changed throughout the duration of the conversation.

Note from the INM out of cycle meeting: Even if a Transmission SLA is in place, we may still have run-time SLA options which have to be conveyed within an interaction instance that may have an influence on how & when an interaction is responded to.

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