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

Difference between revisions of "Transformer Bridge"

From HL7Wiki
Jump to navigation Jump to search
(add image)
(overhaul, incorporate Miroslav's comments in definition)
Line 1: Line 1:
 
[[Image:Ats_nonpeer.gif|275px|right|thumb|Application Architecture]]
 
[[Image:Ats_nonpeer.gif|275px|right|thumb|Application Architecture]]
A '''Transformer Bridge''' is a specific scenario for an [[Interface Engine]] that is allowed to change the contents of HL7 composite message without being the final destination of the HL7 interaction in the particular case. [[Interface Engine]], in the role of the Transformer Bridge, has no receiver responsibilities, is not addressed in the Transmission wrapper, and does not assign new Transmission IDs to transformed transmissions.  
+
A '''Transformer Bridge''' is a role of an [[Interface Engine]] that is allowed to change the contents of HL7 composite message without being the final destination of the HL7 interaction. A Transformer Bridge has no receiver responsibilities, is not addressed in the Transmission wrapper, and does not assign new Transmission IDs to transformed transmissions.  
  
Note for the implementors - the configuration parameters and communication contracts for Transformer Bridge scenarios need to be well defined and negotiated, since the Receiver needs to '''always''' trust the HL7 interaction that has been transformed by the Transformer Bridge.
+
By definition a Transformer Bridge either has a trust-relationship with the [[Sender]] (i.e. transformations are done on behalf of, and with the knowledge of, the organization responsible for the sending application), the [[Receiver]] (i.e. transformations are done on behalf of, and with the knowledge of, the organization responsible for the receiving application), or both. These trust-relationships often (but not exclusively so) exist in intra-enterprise communication scenarios.
*Rationale - Discussion from Phoenix WGM (copy/paste from the minutes): Mark Tucker - Existing V3 definitions do not support common uses of integration engines in the "real world."  Integration engine typically does do minor changes to application data payload but does not accept receiver responsibility.  Paul Biron echoes that sentiment.  HL7 has no business telling implementers that they cannot do this.  Rene Spronk: Aim is to create concepts that are useful.  Is the ATS model broken because it does not support this use case? Paul: yes, certainly.  It does not support real world use cases.  Mark: suggest we could add a concept of "transforming router" that serves role defined above.  Paul: Libertarian viewpoint: his institution owns the network, it can do whatever it wants.  Rene: Can live with this with the caveat that language emphasizes this is intra-enterprise.  Introduce this new concept of transforming router to ATS.
+
 
**(Miroslav) I share Rene's concern here. To me it seems that we are stepping into a dangereous territory by having the inter/intra enterprise distinction in the document. That's why I'd be in favour not having this in the definition of the Transformer Bridge.
+
The trust-relationship as well as the configuration parameters and communication contracts for Transformer Bridge scenarios need to be well defined and negotiated, since a Receiver needs to '''always''' be able to trust the HL7 Interaction that it receives (in terms of semantic content as well as the identification of the [[Sender]]), irrespective of whether or not is has been transformed by the Transformer Bridge.
*Discussion from Phoenix WGM (copy/paste from the minutes): This role should only be used in environments where there is an agreement of parties to use such a "transformer bridge", and that such agreement is likely to exist in intra-enterprise scenarios, whereas this is not likely in inter-enterprise environments.
 
**(Miroslav) - Although this is a real life scenario, I see this as a potential threat in breaking the enterprise concepts in a professional/business environments. The main question is how can we make sure that [[Interface Engine]], in the role of Transformer Bridge, is *always* trusted?
 
  
 
----
 
----
  
Back to the [[Open_ATS_Issues]]
+
Back to the [[Open ATS Issues]]

Revision as of 17:52, 10 March 2006

Application Architecture

A Transformer Bridge is a role of an Interface Engine that is allowed to change the contents of HL7 composite message without being the final destination of the HL7 interaction. A Transformer Bridge has no receiver responsibilities, is not addressed in the Transmission wrapper, and does not assign new Transmission IDs to transformed transmissions.

By definition a Transformer Bridge either has a trust-relationship with the Sender (i.e. transformations are done on behalf of, and with the knowledge of, the organization responsible for the sending application), the Receiver (i.e. transformations are done on behalf of, and with the knowledge of, the organization responsible for the receiving application), or both. These trust-relationships often (but not exclusively so) exist in intra-enterprise communication scenarios.

The trust-relationship as well as the configuration parameters and communication contracts for Transformer Bridge scenarios need to be well defined and negotiated, since a Receiver needs to always be able to trust the HL7 Interaction that it receives (in terms of semantic content as well as the identification of the Sender), irrespective of whether or not is has been transformed by the Transformer Bridge.


Back to the Open ATS Issues