A unique identifier for this transmission (mandatory). It will never be reused in time, nor will it be used by another sending application. As such, it can serve to reliably allow an acknowledgment transmission to refer to the transmission that it acknowledges, and can be used as a bookkeeping index to keep track of transmissions that have been sent and handled. Version 2 mapping: MSH-10 Message Control ID and BHS-10 Batch Control ID. (description from the MCCI domain)
We now have the following statement in the Abstract Transport Specification (ATS) document:
- "From the HL7 perspective two interactions are judged to be the same if they have the exact same effect (in terms of semantic content) on a receiving application. There are a small number of transformations of an interaction (e.g. the removal of non-relevant whitespace characters from an XML message or adding simple code translations) that don't require the use of a new identification for the transformed interaction." (MnM Telcon, 20050624, based on a motion regarding the "sameness" of two interactions). Note: the part in italics has been nullified by a later motion:
- 20070108 MnM/INM: 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. Depending on the transformation (a list will have to be created) one would need to use a new "interaction pattern instance identifer / CPI" (to be introduced in the Behavioral Contract Class). (Rene/Dale, x-0-3)
- "At the semantic (or: business process level) the contents of the Transmission wrapper, with the exception of InteractionID, are not relevant when determining if 2 interactions are the same. At the transmission-level 2 Transmissions are the same if they have the same Transmission.id." (MnM, 20060113, Rene/Günther, 5-0-4). Note: interaction identifies the receiver resposibilities.
By definition, two Transmission which have the same id are the same. Therefore if a Transmission is received which has the same id as a previous Transmission, it shall be considered a duplicate and appropriate action for duplicates (which may be to ignore the duplicate) will be taken.
1 to many cloning of messages
If a Message Broker duplicates an incomming message and sends it to x additional addresses, should the Message.id stay the same? (ATSine item 89)
(Miroslav) "If these destinations were not listed in the original message as the Receivers, than the Message Broker is acting as a Gateway and needs to create x messages and send them to x locations, indicating itself as a Sender and x destinations as Receivers. In that case, it needs to create x new Message.ids. If those x Receivers have been all listed in the original message, than the Message Broker is acting as a Bridge, and just routes the message. The Message.id stays the same." (Rene) Note that a single interaction can't have multiple receivers (as of MCCI Release 2), but his point is well taken when it comes to the second option.