Transmission Addressing

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 the HL7 message logically end up. Logical address is the end point of the HL7 dialog; i.e. it is the identification of the Sender and Receiver (application level entities) that communicate using HL7 messages. 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.

Postal analogy

On 20070428 the Wrappers R2 taskforce discussed the transmission addressing issue. Aspart of the discussion an analogy with the postal service was used, which distinguishes between the address as used by the postal service to deliver the letter (typically: a street address), and which parts are used for internal routing (Mr. Smiths postbox in room 25 of building 22).

• Device = HL7 application that knows how to process the message. An HL7 application. Logical endpoint. Entity that are able to produce or consume HL7 interactions. Transport-independent way of IDing endpoints.
• Identification of addressee of the information = InformationRecipient: person or organization (or part thereof). Whom the

content is stated to be for.

Mr. Smith
Shipping department
301 Park lane
1234 Alphaville

Dear Andrew,

InformationRecepient:

• Andrew Smith

Logical Device (destination, an HL7 Application):

• Mr. Smith
• Shipping department
• 301 Park lane
• 1234 Alphaville

Site or country-wide agreements could define the granularity of the Device addressing. Device (using the example) could include "Building 22, 3rd floor", or the address could be "Central Postoffice, Alphaville" on the assumption that the Central Postoffice knows (based on informationRecipient or even contents of the payload) who is the real life person that needs to get the information contained in the message. The diistinguishing feature is that whatever is identified as the logical device (i.e. Device.id attribute) is the HL7 application that can process the message and deliver it somehow to the real life entity that the message is originaly created for. HL7 on the international standard specification level won't be able to define how granular the address should be, in terms of how "close" can it reach the real life recipients (i.e. InformationRecipient).

Motions and Discussion

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

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.

Motion Cologne, May 1st 2007, InM Q1: The Transmission wrapper device id represents the HL7 application (not a person) envisioned to consume or produce an HL7 message. The HL7 application takes responsibility for presenting the information to the intended information recipient (Charlie McCay/Mark Tucker 17-0-1)

Comments:

• Miroslav: this goes in line with the discussion from above. The most important consequences comming out of this motion are illustrated in the definition of the Sender, Receiver and Transmission.

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.