We have recently completed a pilot study as part of the Ontario Osteoporosis Strategy to investigate wide network transmission over our own implementation of a secure HL7 standard that we are tentatively calling HL7e. The purpose of this study was to investigate the overall feasibility and loading characteristics of a fault tolerant point-to-point HL7 messaging network.
The HL7e protocol, loosely defined, is a wrapper for the general standard, encapsulating each message in an SSL encrypted tunnel. The main actors in our implementation are:
- HL7e Gateway Processes
- The HL7e Server
HL7e Gateway
These gateway processes listen for regular HL7 messages from modalities, encrypt the contents, and re-transmit to sequences of further gateways or HL7e Servers. The purpose of the gateway is to secure messages, and act as both a carrier and queue for further transmission. Our HL7e Gateways are fully standards compliant, and can be plugged into any HL7e workflow, maintaining data endpoints, and even providing a temporary store in the event that recipient resources are offline.
Through-the-Pipe Encryption
Because HL7 Messages are encrypted by the first gateway in the chain, re-transmission in a gateway-to-gateway pathway is possible while maintaining data security and integrity. Implementation of our very own conditional FluxML workflow XML language ensures that path failover occurs in the event of gateway outages, and data safely arrives at its destination.
HL7e Server
The HL7e server is the final point in an HL7e network. It receives encrypted HL7e messages, decrypts them, and stores them in a local database for later use. As the final purpose of our tests is to establish the feasibility of mass HL7 data aggregation, this final destination is a temporary store of unaltered HL7 messages from the originating modalities. Our HL7e protocol ensures that HL7 data remains untouched throughout the process, and industry standard encryption technology is harnessed to ensure integrity down the entire pipe.
