Architectural Question about receiving HL7 via HTTPS
For those that use IRIS for Health, HealthShare, and or Health Connect...
As Health Applications are moving to the Cloud, how have you handled communication from the Application to your instances via HTTPS?
Trying to figure out the best path on designing the proper workflow to allow these messages to be allowed to be eventually sent to our EMR to post to the patient chart.
We are very wary of opening a connection from the internet to our instance of Health Connect.
Thanks
Comments
Health Connect/IRIS for Health can receive HL7 over HTTP/S natively by using EnsLib.HL7.Service.HTTPService as the inbound service. The sender posts the HL7 message in the HTTP request body to a URL such as http://IP:PORT, and the HL7 schema is configured similarly to other HL7 inbound interfaces. [1]
If you choose an HTTPS-based inbound interface, the retrieved material shows that TLS is supported and that inbound and outbound roles use different SSL/TLS configurations: server SSL configurations are used on services to respond to TLS handshakes, while client SSL configurations are used on operations to initiate them. If your system has both inbound services and outbound operations, both types of SSL configuration may be needed. [1][2]
A supported outbound pattern is to avoid exposing Health Connect for inbound internet traffic and instead have the production call outward to a cloud API or HTTPS endpoint. The retrieved material includes examples of using EnsLib.HTTP.GenericOperation for TLS-secured API calls and EnsLib.HL7.Operation.HTTPOperation for sending HL7 over HTTPS, including certificate-based security via the SSLConfiguration setting. [1][3][4]
If you implement TLS or mutual TLS, the documented setup in the returned material is to: choose a certificate authority, create a private key and CSR, obtain your certificate, obtain the peer certificate chain, create the SSL configuration, assign it to the interface, and verify message flow. [1][2]
CAUTION! Make sure that you save your private key in a secure location (preferably in a password-protected format). If you lose this key, your certificate will no longer be usable. If someone else gains access to this key, they will be able to impersonate your server. [1][2]
NOTE: When creating the CSR, make sure that you request an Extended Key Usage of both serverAuth and clientAuth, if you are using mutual TLS. Most CAs are used to signing certificates with only serverAuth key usage. Unfortunately, this means that the certificate can not be used as a client certificate in a mutual TLS connection. [1][2]
For the specific concern about not wanting to open your Health Connect instance directly to the internet, the retrieved material does not provide a definitive recommended architecture or “best path” such as DMZ placement, reverse proxy design, VPN/private connectivity, or other cloud-edge patterns for safely publishing an inbound Health Connect listener. What it does support is that inbound HL7 over HTTP/S is possible, outbound HTTPS patterns are possible, and TLS/mutual TLS can be configured for either direction. [1]
So, based on the returned material, the safest conclusion is:
- inbound HL7 over HTTP/S is supported with
EnsLib.HL7.Service.HTTPService[1] - outbound HL7 over HTTPS is supported with
EnsLib.HL7.Operation.HTTPOperation[1][4] - outbound API-style integrations using HTTP operations over TLS are also demonstrated [1][3]
- the returned sources do not identify a single recommended internet-facing architecture for your environment [1]
Sources: