9

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.

Suri
  • 91
  • 1
  • 1
  • 3
  • 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? –  Apr 01 '14 at 14:07

7 Answers7

3

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… ;-)

jlmorin
  • 408
  • 3
  • 5
3

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.

Ed Daniel
  • 247
  • 2
  • 2
2

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.

Micke
  • 2,251
  • 5
  • 33
  • 48
1

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.

Community
  • 1
  • 1
Michel Floyd
  • 18,793
  • 4
  • 24
  • 39
0

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.

Glimpse
  • 462
  • 2
  • 8
  • 25
0

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.

lmsurprenant
  • 1,723
  • 2
  • 14
  • 28
0

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.

Phil Frigo
  • 1