This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Transformer Bridge"
Jump to navigation
Jump to search
| Line 1: | Line 1: | ||
'''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 interaction. In this 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. | '''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 interaction. In this 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. | ||
*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. | *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. | ||
| − | *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. | + | *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 Transformer | + | **(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? |
Revision as of 13:05, 8 March 2006
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 interaction. In this 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.
- 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.
- 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?
