Difference between revisions of "Communication Process Model"
Rene spronk (talk | contribs) (add MnM manadatory payload motion) |
Rene spronk (talk | contribs) (add Lloyds comments) |
||
| Line 30: | Line 30: | ||
''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)'' | ''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. | 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 | ||
| + | #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. | ||
Revision as of 20:13, 23 January 2006
An Interaction Pattern is a sequence of interactions that are related because they belong to one and the same business process. 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".
At this level of abstraction the delivery method of the interactions is of no relevance whatsoever.
- The use of some Interactions (e.g. Syntax 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 an
Interaction 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
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. 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:
- 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.
