Exchange HL7 messages over the internet [closed]

Question

We're new to using HL7. Currently we're exchanging HL7 messages over TCP/IP with a standard HL7 TCP/IP Listener/Sender. This all works fine and doesn't pose any problems BUT we're a hosted EMR we have to create and maintain VPNs on our servers to do this.

My question is this. Is there no way that we can bypass the VPN and exchange HL7 messages over the internet (HTTPS) to and from our web services???

I've searched and searched but I can't find any answer one way or another. And please nothing about HL7 version 3 because NOBODY actually seems to use it. My customers are all using HL7 Versions 2.3 to 2.5, have for years and show no inclinations to change.

Galvanism

I am using Epic Interconnect => HL7 over https => PA SIIS And it is fairly persistent and fail safe; however, troubleshooting is a problem. We sometimes get AE and have no idea what the cause is. Also, experimenting with implementing using Intersystems Ensemble, HAPI and Mirth. Curious if there has been any other successful endeavors as well, at this time? – Almswoman

Answer 1

HL7 over the internet is fairly new for most healthcare organizations. If you want to reduce complexity and remain completely independent from the client system and/or infrastructure, I’m afraid VPN is your best option. People trust it and it’s fairly easy to deploy.

If you want to get away from a VPN strategy, the system sending you HL7 messages must have the capability to wrap them in HTTPS requests (or some other secure protocol). Very few clinical systems have such off-the-shelf protocol mediation capabilities. If you add an integration engine into the equation, it would help you translate TCP and LLP to HTTPS communication. You could deploy this integration capability as a solution component at the customer site but, often, it introduces new complexity and costs.

If you find viable alternatives, let me know… ;-)

Overcash

Answer 2

Yes, there is a solution available that you can use today. The other answer is right on the money, the problem with exchanging HL7 over the internet is NOT because it's difficult, it's because a) there is not (and will never be) an internet "standard" for HL7 Version 2.xx and b) HL7 is a two way conversation and you don't control both sides. This means that IF you design your web service and it works beautifully and IF you actually found someone willing to exchange HL7 with you, the odds are probably even that THEY would have designed their OWN beautiful web service which they would want you to adapt to and use.

The solution must be one that YOU can implement UNILATERALLY, without requiring that your HL7 trading partner change anything outside of their usual HL7 interfacing methods.

Look at the UltraPort HL7 Postmaster

It actually solves the problem by implementing a dual interface. One is an "inward pointing" HL7 standard TCP/IP or file based interface and the second is an "outward pointing" custom interface that interacts directly with your HL7 Web Service. They will even provide you with ASP.Net shell templates for how to build the "front door" to your web service. I've worked with two customers on this and they were able to compile and publish the DEMO web service provided by the Vendor to their test server and have it running in less than 20 minutes.

It's shown in some more detail in the online help Click Here.

Hope this helps.

Coxcomb

Answer 3

You might be able to use two instances of Mirth, as a HTTPS "relay". Inbound HL7 from system A, outbound thru HTTPS. Then the other way around. It should be possible to make this setup fairly transparent to the involved systems.

Seawards

Answer 4

Cloak Labs has a software HL7 security solution to the problem of securely passing HL7 messages between enterprises. We basically take HL7 messages and encrypt them at the sending end (using AES256 with the key protected by RSA, the whole thing signed with RSA/SHA). The messages are passed redundantly through CloudPrime and routed to the receiver as a store & forward message so that messaging can become asynchronous instead of synchronous. This eliminates many common sources of errors (the VPN being down or the receiving side being down).

Integration with HL7 is done via a protocol-specific HL7 connector, requiring very little time. No additional inbound firewall rules need to be added. Keys only exist at the endpoints so that no one but sender and receiver, not even Cloak Labs engineers or sys admins can read the messages. Endpoints can only communicate with other trusted elements to foil any kind of DNS exploits.

In essence applications at two different enterprises can securely message each other without requiring network changes or new VPNs. Cloak Labs will sign a BAA agreement for its services.

Full disclosure, I am CEO at Cloak Labs. I hope you find this helpful.

Bequeath

Answer 5

I would recommend setting up an SFTP server in some distro of Linux to upload the messages. In two years, an encrypted protocol is required to have HIPPA compliant software.

Rodman

Answer 6

There is a recent initiative within the HAPI / HL7 community to specify how HL7 v2 messages should be passed over HTTP(S). Please see http://hl7api.sourceforge.net/hapi-hl7overhttp/ for more information.

Typhoon

Answer 7

Our security guy suggested ssh port forwarding on both client and receiver. No smooth way to deploy on a typical interface engine. Need to share the public rsa key from the listener side to the hl7 tcp senders and use the resulting ssh connection to push the HL7 payload (with encryption). Would need a lot of port-forwarding ssh daemons on both sender and listener sides for this.

Phil - University of Chicago Medicine.

Greater

Answer 8

As pointed out by @msurprenant, there is now a HL7-over-HTTP specification which defines sending HL7 request/responses over HTTP(S) POST. It supports exchanging HL7v2 ER7 (classic pipe-based format), HL7v2 XML, HL7v3 XML, FHIR XML, FHIR JSON, CDA based on the Content-Type. You would have to add some authentication on top of that: the spec suggests using mTLS but you could use other options.

However, I have not yet found a system which would support that in practice.

What I have found used in practice, is using HL7v2 XML over SOAP over HTTPS POST (HL7 message directly encapsulated in the SOAP Body).

Warning: contrast to HL7v2 ER7, HL7v2 XML serialization is not compatible between different HL7 2.x versions.

Because the XML encoding makes explicit use of constructs touched by the changes mentioned above, inter-version backward compatibility is not a given. For example, if a data type for a field is changed from IS (primitive) to CE (composite), the CE composite data type introduces its own tags, in other words, the former IS field now has child elements drawn from the composite CE data type.

However, it should be easy to achieve XML transformations from an XML instance for one version to another using corresponding transformation rules or style sheets (which are not provided here).

Puerilism