Transmission Addressing
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.
Open action: to create definitions for logical sender/logical receiver as the next step to resolve addressing issues.
Description of the Issue
Within the Transmission Wrapper the Device.id attribute contains the logical identification of the sending/receiving applications. The Transmission Wrapper also contains place and organization. Are they part of the addressing – their semantic interpretation in v3 is not clear. Note that in V2 they are part of the addressing scheme (see below).
Sending organization is not intended for routing purposes. It’s intended to identify legal responsibility for the message. We have a number of things
- Physical address – this doesn’t belong in the transmission wrapper (it is a Messaging Infrastructure Layer issue)
- Logical address – where does this logically end up. The thing addressed by device is not a transport end-point, it’s the logical thing of where the message is going.
- Who do I want to act on the content in this message (i.e. a human, or an organization). This is never processed by machine. The application should read the recipient from the payload.
The standard should clearly state that all the levels of the addressing should match.
Motion: Remove LocatedEntity and Agent from the transmission wrapper and we deal with addressing beyond the transmission endpoint represented by the device somewhere in the control act wrapper or the payload. (INM out of cycle, May 2006, to get discussion going. Moved Rene, Seconded Sandy, 18 - 10 – 5)
We probably need a more sound definition of what a Transmission is. Draft: “A Transmission is the transfer of data by some means from a logical sender to a logical receiver. This is independent of the method of transfer as supported by the Messaging Infrastructure Layer.”
This definition has the consequence that Device.id contains the logical endpoints of the Transmission (SENDER and RECIEVER), and not endpoints at the MIL layer (SOURCE and DESTINATION).
Relevant V2.x history
Quotes from the V2.5 standard:
- Receiving Application ID - This field uniquely identifies the receiving application among all other applications within the network enterprise. The network enterprise consists of all those applications that participate in the exchange of HL7 messages within the enterprise.
- From HL7 V2.2: available for interface with lower level protocols.
- Receiving Facility ID: - This field identifies the receiving application among multiple identical instances of the application running on behalf of different organizations.
- From HL7 V2.2: addresses one of several occurrences of the same application within the receiving system. Absent other considerations, the Medicare Provider ID might be used with an appropriate sub identifier in the second component.
From this one can conclude that in V2
- the Application ID identifies the physical entity that is the messaging endpoint
- the Facility ID is part of the message addressing mechanism which addresses a logical entity beyond the messaging endpoint identified by Application ID.
Discussion
Some snippets of discussion, mainly by those not agreeing with the above motion:
- Andrew: against the motion because it’s used this way in NHS. We do need to use organization in the addressing – the device Id may only take you as far as the data center, some other delivery mechanism may be required, and if this is left to the payload it’s not clear how this happens. But you don’t want a person at this level, and though the NHS does do this, we need to change the way this is done.
- Grahame: Australia has the requirement. Removing these are ok; but leaving the other things to controlAct or Payload is not ok
- Gaby: we may not be using it right the way it is, but in the payload – that requires too much negotiation. Putting it into the transmission wrapper allows for much simpler conformance and negotiation
- Charles: virtualization of addresses is paramount. Passing descriptive information of the address is a mistake - this should be done by registry.
(Miroslav, WGM San Diego January 2007) - ATS got a negative saying that MIL also deals with the logical addressing, which IMHO is true. Alan Honey is suggesting using (business) "identifiers" instead of "physical addressing" in the HL7 messages.
