This wiki has undergone a migration to Confluence found Here

Difference between revisions of "INM assumptions with regards to CPM"

From HL7Wiki
Jump to navigation Jump to search
m
Line 5: Line 5:
 
Also see: [[Behavioral Contract Wrapper (new wrapper mechanism)]].
 
Also see: [[Behavioral Contract Wrapper (new wrapper mechanism)]].
  
{{INM Motion| 20060205 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.}}
+
{{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.}}
  
 
==Assumptions==
 
==Assumptions==

Revision as of 00:01, 6 February 2007

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).

Assumptions

Transmission Exchange

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?
    1. By means of Transmission.id. The Acknowledgement class would link to the Message.id attribute of the Transmission it is acknowledging.
    2. 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:

  1. 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?
  2. 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.


Conclusion #2: INM will introduce the concept of "conversation Type ID" in the new controlAct wrapper to identify the type of conversation.

  • If we continue to use the current Receiver Responsibilities dynamic model, the conversation Type ID 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 Type ID will have a similar role as CPM artefact ID.