This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Transmission Addressing"

From HL7Wiki
Jump to navigation Jump to search
(restructure)
Line 1: Line 1:
 
{{INM Workitem}}
 
{{INM Workitem}}
  
 +
==Description of the Issue==
  
−
==Discussion==
+
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).
−
Out-of-cycle meeting May2006:
 
  
−
Rene displayed a postal envelope with various elements representing different stakeholders in communication (e.g. middleware) Addressing in the context of middleware is part of ITS discussion.
+
Sending organization is a new thing 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.  
  
−
Model Review
+
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)
−
Device connection to sender and receiver
 
−
Telecom is a characteristic of how to reach sending or receiver.
 
  
−
Is place or organization objects part of the addressing?
+
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]].”
−
Addressing is not just device. Is the information recipient object something that has to be considered in the addressing?
 
  
−
What is a device – it’s a logical thing.  
+
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 discussion ensued about the nature of organization on Device – it’s not quite clear what the semantic implication is.
+
==Relevant V2.x history==
  
−
If the informationRecipient is different to the receiver device then it’s an error, and the standard should clearly state that all the levels of the addressing should match.  
+
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.
  
−
Discussion ensued about scenarios where the receiver of the message is not the final recipient. What is in the device is not addressing the end recipient of the message, so the end recipient was in the organization. If we make the transmission wrapper abstract, we need to clarify what the expectation is in this area.
+
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.
  
−
There was concern that a logical device is not an appropriate recipient for the message. But the device is not necessarily a URL, it can be a logical destination following the transport end-point.
+
==Discussion==
−
 
 
−
Further discussion deferred to the outstanding issues list.
 
−
 
 
−
Rene: this question is about addressing. Does the addressing end with the device? or is the Place/Organisation for information or addressing.
 
−
 
 
−
Motion: We 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. Moved Rene, Seconded Sandy
 
−
 
 
−
Chris: asks about the notion of the endpoint. The endpoint is not a transmission end point, it’s the logical thing of where the message is going. Generally agrees with the proposal
 
−
 
 
−
Joseph: a bit confused by this – already BT/UK have moved these constructs into the control act wrapper. (But there was contention – they do use this).
 
−
 
 
−
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.
 
−
 
 
−
Paul K: the device indicates the logical end point not the physical end point. It may not map directly.
 
−
 
 
−
Grahame: Australia has the requirement. Removing these are ok; but leaving the other things to controlAct or Payload is not ok
 
−
 
 
−
Vassil: removing these is good; makes abstraction easy. The ControlAct information recipient is a good place for this information. Vassil supports this motion to increase the interest in transport specific wrappers.
 
−
 
 
−
Mark T: regenstreif has a system like this. Device is the abstract recipient of the message (i.e. community radiology department). cc:s to the recipient but this person is not an HL7 aware application. The application should read the recipient from the payload. But we should leave these things in because they make sense as they are.
 
−
 
 
−
Brad: is this safe to remove? Have we done due diligence?
 
−
 
 
−
Lloyd: Sending organization is a new thing 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
 
−
*Logical address – where does this logically end up.
 
−
*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
 
−
 
 
−
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
 
−
 
 
−
Joseph: wants to disagree with Lloyd. Agent (person + system) sit in the control act. Make it extensible.
 
−
 
 
−
Charles: virtualization of addresses is paramount. Passing descriptive information of the address is a mistake - this should be done by registry.
 
  
−
Grahame calls the question, Vote: 18 - 10 - 5
+
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.

Revision as of 18:11, 22 August 2006

INM workitem.gif

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.

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 a new thing 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.
Retrieved from "https://wiki.hl7.org/w/index.php?title=Transmission_Addressing&oldid=7973"