Bridge

Application Architecture

A Bridge is an Intermediary role that serves two main purposes. First, it provides Message Protocol translation (i.e. relaying) and/or message routing capabilities in cases where the HL7 message needs to travel over heterogeneous healthcare communication environments. An example of this use case would be the relaying of messages from Web Services to ebXML transport and vice versa. Second, the Brige provides HL7 message translation between various flavours of HL7 standard, where there's no change in the semantic meaning between the original and resulting message. A Bridge is never identified in the Device.id attribute of the HL7 message.

Notes

• Question - if I have a use case where application A speaks HL7v3 and application B speaks EDI, and I use an Intermediary that transforms HL7v3 to EDI and vice versa with no semantic meaning change, is that Intermediary a Bridge or Gateway?
  • Answer - in order to make this use case realized, that Intermediary needs to posess both the HL7v3 and EDI knowledge to perform the function. To use the analogy from IT business, when application A wants to speak to application B, application B will "outsource" the transformation function to that Intermediary. Application B will sign a contract (SLA) with Intermediary to pefrom that functionality, and publish the that contract and identification of Intermediary as it's "HL7v3 representative". In that case A actually speaks to Intermediary considering that communication as talking directly to B. Consequently, Device.id will contain the identification of the Internediary, which means that Intermediary is serving a role a Gateway.