INM assumptions with regards to CPM

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

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?
   • 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.
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.

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