This wiki has undergone a migration to Confluence found Here
Difference between revisions of "INM assumptions with regards to CPM"
Jump to navigation
Jump to search
Rene spronk (talk | contribs) |
(MnM vote and amendment) |
||
| (8 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | {{INM Workitem}} | ||
| + | |||
The [[CPM]] is the new (yet to be defined) dynamic model. The INM TC is working on a new set of wrappers (See [[MCCI R2]]). That project won't be put on hold pending discussion of the CPM. This pages documents INM's assumptions as to what the CPM will look like. These assumptions will form the basis of the new wrappers. | The [[CPM]] is the new (yet to be defined) dynamic model. The INM TC is working on a new set of wrappers (See [[MCCI R2]]). That project won't be put on hold pending discussion of the CPM. This pages documents INM's assumptions as to what the CPM will look like. These assumptions will form the basis of the new wrappers. | ||
Also see: [[Behavioral Contract Wrapper (new wrapper mechanism)]]. | Also see: [[Behavioral Contract Wrapper (new wrapper mechanism)]]. | ||
| + | |||
| + | {{INM Motion| 20070205 INM Telcon: To introduce the concept of "conversation ID" in the new controlAct wrapper to link all interactions in a conversation, and to introduce the concept of "conversation Type ID" in the new controlAct wrapper to identify the type of conversation. These concepts can be used regardless of if & when a new dynamic model will be created. Once accepted, the committee will seek informative feedback from MnM on the contents of this motion.}} | ||
| + | |||
| + | :20070209 MnM Telcon: M&M did consider a "sense of the meeting" motion - Patrick Loyd moved, Lee Coller seconded, passed unanimously. The send of the meeting motion reads: "M&M has no objection, in principal to Conversation.id and Conversation.typeCode, indeed they seem logical extensions, but we wish to defer formal review until the new dynamic model is closer to adoption." | ||
==Assumptions== | ==Assumptions== | ||
[[Image:Inm new dyn model.gif|400px|right|thumb|Transmission Exchange]] | [[Image:Inm new dyn model.gif|400px|right|thumb|Transmission Exchange]] | ||
| − | "HL7 will be silent on what happens to Transmission id and how it moves from node to node, that's left to | + | Let's have a look at the exchange of HL7 interactions shown at the right hand side. Let's assume all of these interactions are related and have somehow been caused by "Transmission 1". |
| + | *How are these interactions currently linked to each other? | ||
| + | *#By means of Transmission.id. The Acknowledgement class would link to the Message.id attribute of the Transmission it is acknowledging. | ||
| + | *#By means of a Business-level ID (mostly the Act.id of the payload [[Entry Point|entry class]]), e.g. PrescriptionID, Placer Order ID. In queries: QueryID. | ||
| + | |||
| + | Both of these identifiers used to link interactions have a number of problems associated with them: | ||
| + | #Transmission.id: The thinking of what Transmission.id really is has shifted: "''HL7 will be silent on what happens to Transmission id and how it moves from node to node, that's left to [[MIL]]s. Transmission id should be dealt with at the appropriate transmission level''." (see [[Transmission.id]]). This is influenced in part by the [[ATS]] as well as by [[SOA]] who would like to see a more abstract [[Transmission Wrapper]]. What does this shift mean? | ||
| + | #*Transmission.id is controlled by the [[MIL]], and not by [[HL7 Application]]s. Transmission.id can be changed at will by any [[Interface Engine]] or other [[Middleware Role]]s, rendering it useless for end-to-end identification purposes. | ||
| + | #Business-level ID: This works fine for end-to-end identification purposes and to create a link between the interactions as shown in the diagram at the right hand side. However: | ||
| + | #*There are interactions that do not have a bussiness-level identifier. If one of the interactions doesn't contain/reference the business-level ID the link between the interactions is broken. | ||
| + | #*The receipt of an interaction with OrderID 1 may trigger another interaction with a different type of payload entry class and a different bussiness-level ID. | ||
| + | #*The bussiness-level ID can't be used in prolonged exchanges of interactions. | ||
| + | |||
| + | |||
| + | '''Conclusion #1: INM will introduce the concept of "conversation ID" in the new controlAct wrapper to link all interactions in a conversation.''' | ||
| + | *If we continue to use the current [[Receiver Responsibilities]] dynamic model, the conversation ID will link the interaction with its response, basically fulfilling the role currently played by Transmission.id | ||
| + | *If something akin to [[CPM]] is adopted, conversation ID will have a similar role as [[CPI]].id. | ||
| + | |||
| + | Endorsed by MnM 2007-09-17 (Q3) Grahame/Charlie 14/0/2 | ||
| + | |||
| + | |||
| + | '''Conclusion #2: INM will introduce the concept of "conversation code" in the new controlAct wrapper to identify the type of conversation.''' | ||
| + | *If we continue to use the current [[Receiver Responsibilities]] dynamic model, the conversation Code will identify the receiver responsabilities, basically taking on that role from the one currently played by InteractionID | ||
| + | *If something akin to [[CPM]] is adopted, conversation Code will have a similar role as [[CPM]] artefact ID. | ||
| + | *conversation Code should be of type CS | ||
| + | |||
| + | Endorsed by MnM 2007-09-17 (Q3) Grahame/Charlie 15/0/1 | ||
Latest revision as of 18:25, 17 September 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.
The CPM is the new (yet to be defined) dynamic model. The INM TC is working on a new set of wrappers (See MCCI R2). That project won't be put on hold pending discussion of the CPM. This pages documents INM's assumptions as to what the CPM will look like. These assumptions will form the basis of the new wrappers.
Also see: Behavioral Contract Wrapper (new wrapper mechanism).
- 20070209 MnM Telcon: M&M did consider a "sense of the meeting" motion - Patrick Loyd moved, Lee Coller seconded, passed unanimously. The send of the meeting motion reads: "M&M has no objection, in principal to Conversation.id and Conversation.typeCode, indeed they seem logical extensions, but we wish to defer formal review until the new dynamic model is closer to adoption."
Assumptions
Let's have a look at the exchange of HL7 interactions shown at the right hand side. Let's assume all of these interactions are related and have somehow been caused by "Transmission 1".
- How are these interactions currently linked to each other?
- By means of Transmission.id. The Acknowledgement class would link to the Message.id attribute of the Transmission it is acknowledging.
- By means of a Business-level ID (mostly the Act.id of the payload entry class), e.g. PrescriptionID, Placer Order ID. In queries: QueryID.
Both of these identifiers used to link interactions have a number of problems associated with them:
- Transmission.id: The thinking of what Transmission.id really is has shifted: "HL7 will be silent on what happens to Transmission id and how it moves from node to node, that's left to MILs. Transmission id should be dealt with at the appropriate transmission level." (see Transmission.id). This is influenced in part by the ATS as well as by SOA who would like to see a more abstract Transmission Wrapper. What does this shift mean?
- Transmission.id is controlled by the MIL, and not by HL7 Applications. Transmission.id can be changed at will by any Interface Engine or other Middleware Roles, rendering it useless for end-to-end identification purposes.
- Business-level ID: This works fine for end-to-end identification purposes and to create a link between the interactions as shown in the diagram at the right hand side. However:
- There are interactions that do not have a bussiness-level identifier. If one of the interactions doesn't contain/reference the business-level ID the link between the interactions is broken.
- The receipt of an interaction with OrderID 1 may trigger another interaction with a different type of payload entry class and a different bussiness-level ID.
- The bussiness-level ID can't be used in prolonged exchanges of interactions.
Conclusion #1: INM will introduce the concept of "conversation ID" in the new controlAct wrapper to link all interactions in a conversation.
- If we continue to use the current Receiver Responsibilities dynamic model, the conversation ID will link the interaction with its response, basically fulfilling the role currently played by Transmission.id
- If something akin to CPM is adopted, conversation ID will have a similar role as CPI.id.
Endorsed by MnM 2007-09-17 (Q3) Grahame/Charlie 14/0/2
Conclusion #2: INM will introduce the concept of "conversation code" in the new controlAct wrapper to identify the type of conversation.
- If we continue to use the current Receiver Responsibilities dynamic model, the conversation Code will identify the receiver responsabilities, basically taking on that role from the one currently played by InteractionID
- If something akin to CPM is adopted, conversation Code will have a similar role as CPM artefact ID.
- conversation Code should be of type CS
Endorsed by MnM 2007-09-17 (Q3) Grahame/Charlie 15/0/1
