Difference between revisions of "Interaction (new dynamic model)"
(→Discussion: link to CPM) |
Rene spronk (talk | contribs) |
||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 2: | Line 2: | ||
''See [[Interaction]] for details of Interactions in the context of the old/current dynamic model.'' | ''See [[Interaction]] for details of Interactions in the context of the old/current dynamic model.'' | ||
| − | A unique association between a specific [[Composite Message Type]] and a particular [[Trigger Event]] that initiates or "triggers" the transfer. It is a unique, one-way transfer of information. | + | A unique association between a specific [[Composite Message Type (new wrapper mechanism)]] and a particular [[Trigger Event]] that initiates or "triggers" the transfer. It is a unique, one-way transfer of information. |
A single Interaction explicitly answers the questions: | A single Interaction explicitly answers the questions: | ||
| Line 11: | Line 11: | ||
*[[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. | ||
| − | *[[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. | + | *[[Composite Message Type (new wrapper mechanism)]] – The set of static model definitions (wrappers and message types) that define the structures of the data that is transmitted by the interaction. |
Under the [[Communication Process Model]], [[Receiver Responsibilities]] are no longer part of the Interaction. The initial interaction which starts a communication process will identify the appropriate [[CPM]] ID somewhere in the composite message type, it wont be precoordinated within the Interaction identifier. | Under the [[Communication Process Model]], [[Receiver Responsibilities]] are no longer part of the Interaction. The initial interaction which starts a communication process will identify the appropriate [[CPM]] ID somewhere in the composite message type, it wont be precoordinated within the Interaction identifier. | ||
| + | |||
| + | {{INM Motion|20070503 WGM Strawvote: (10-0-0): To explore the option of introducing StaticModelID and TriggerEventID as explicit mandatory components in our message structure. This would replace the mandatory InteractionId as present in current messages.}} | ||
==Discussion== | ==Discussion== | ||
| Line 24: | Line 26: | ||
(Lloyd) I can get sold on de-coordinating the TE. However, the composite message type corresponds to the "arguments" of the interaction "method" As arguments are generally taken as part of the signature for a method (Ed: i.e. ''the method's name along with the number and types of the parameters -and their order''), it makes sense that they should be considered part of the interaction. | (Lloyd) I can get sold on de-coordinating the TE. However, the composite message type corresponds to the "arguments" of the interaction "method" As arguments are generally taken as part of the signature for a method (Ed: i.e. ''the method's name along with the number and types of the parameters -and their order''), it makes sense that they should be considered part of the interaction. | ||
| − | (M&M Q3 | + | (M&M Q3 20060913) Discussion continued from above however in specifying the interaction patterns for a committee, there will remain a need to bind (and identify) trigger events and composite messages. See [[Communication Process Model|CPM]] on Wiki for requirement to identify the interaction patterns. Although pre-coordinating ALL uses of a composite message type may not be feasible, there is certainly a reason to pre-coordinate these in many circumstances. Final designation of "interaction" content must await completion of the CPM discussions. |
| + | |||
| + | Discussion continued on the "desirability" of specifying CPM patterns in an HL7 standard. This discussion must be part of the determination of: what CPMs (with what level of granularity, and with what level of optionality) should be included in: an HL7 balloted standard; an affiliate-constrained CPM; a project contract; etc. etc. Sense that "[[Receiver Responsibilities]]" must be defined (however designated) in HL7 standards. | ||
| + | |||
| + | (M&M Q3 20070430) Mark Tucker argues that TE should be taken out of InteractionId, using object/function analogy. f(x,y) returns z. | ||
| + | *f is asking for a particular action. f combined with z currently is the tuple(ConversationType,TE); x,y would be the static model. | ||
| + | *In v2, the O01 trigger event (as in ORM^O01) identifies both the TE as well as the recever responsibility to reply with an ORR (as well the definition of the static model, although ORM plays an important role in that). So in v2 the trigger event (as a string) is equal to f (as an identifier of the function). | ||
Latest revision as of 09:57, 9 May 2007
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.
See Interaction for details of Interactions in the context of the old/current dynamic model.
A unique association between a specific Composite Message Type (new wrapper mechanism) and a particular Trigger Event that initiates or "triggers" the transfer. It is a unique, one-way transfer of information.
A single Interaction explicitly answers the questions:
- How a system knows when to send a particular type of message;
- What the particular message type is.
As the list above indicates, each Interaction is defined as a tuple 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 (new wrapper mechanism) – The set of static model definitions (wrappers and message types) that define the structures of the data that is transmitted by the interaction.
Under the Communication Process Model, Receiver Responsibilities are no longer part of the Interaction. The initial interaction which starts a communication process will identify the appropriate CPM ID somewhere in the composite message type, it wont be precoordinated within the Interaction identifier.
Discussion
- The current methodology states that each interaction has 1 Trigger Event associated with it. Either we have to change the statement to say that an 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.
Question: can TE be taken out of the Interaction? What is the benefit of pre-coordinating TE and Composite Message Type in 1 Identifier?
(Lloyd) I can get sold on de-coordinating the TE. However, the composite message type corresponds to the "arguments" of the interaction "method" As arguments are generally taken as part of the signature for a method (Ed: i.e. the method's name along with the number and types of the parameters -and their order), it makes sense that they should be considered part of the interaction.
(M&M Q3 20060913) Discussion continued from above however in specifying the interaction patterns for a committee, there will remain a need to bind (and identify) trigger events and composite messages. See CPM on Wiki for requirement to identify the interaction patterns. Although pre-coordinating ALL uses of a composite message type may not be feasible, there is certainly a reason to pre-coordinate these in many circumstances. Final designation of "interaction" content must await completion of the CPM discussions.
Discussion continued on the "desirability" of specifying CPM patterns in an HL7 standard. This discussion must be part of the determination of: what CPMs (with what level of granularity, and with what level of optionality) should be included in: an HL7 balloted standard; an affiliate-constrained CPM; a project contract; etc. etc. Sense that "Receiver Responsibilities" must be defined (however designated) in HL7 standards.
(M&M Q3 20070430) Mark Tucker argues that TE should be taken out of InteractionId, using object/function analogy. f(x,y) returns z.
- f is asking for a particular action. f combined with z currently is the tuple(ConversationType,TE); x,y would be the static model.
- In v2, the O01 trigger event (as in ORM^O01) identifies both the TE as well as the recever responsibility to reply with an ORR (as well the definition of the static model, although ORM plays an important role in that). So in v2 the trigger event (as a string) is equal to f (as an identifier of the function).
