Transmission.id

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)

Known Issues

Gateway Transformation

On the MnM teleconference of June 24, 2005 there has been a discussion regarding the "sameness" of two interactions. Based on the resulting motion, 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."

(Miroslav Koncar) Question - if an HL7 application transforms an HL7v2.x message to the HL7v3 message with the *same* content, does it require to assign a new Message.id to the final message? (Rene Spronk) The Transmission class is defined as (RIM): Represents information about a specific transmission of information from one application to another. Transmission.id is defined as: Unique identifier of the transmission.

Given that v2 was peer-to-peer only, we have yet to establish whether Transmission.id is a business-level id, or a transmission-level id (i.e. snapshot id, used in 1 single peer-to-peer transmission).

See the defintion of Interaction Patterns and Transmission Patterns. A consequence of such models is that Transmission.id is NOT a business-level id, and that we'll have to revisit the "adding code translations do not require a new identification" motion.

Note:

1. The ATS-statement as referenced above (about two messages being the same when they have the same samentic effect) should probably be refined to state that this is true for the non-transmission-wrapper part of an interaction.
2. This raises a question whether or not we'd need a business-level-id to link all transmissions in an Interaction Pattern.

Duplication detection

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.