Here at University Health Network, we exchange about 2 million HL7 messages on an average day over our main ESB (using HAPI every step of the way. I might add). About 25% of this traffic is between us and 24 outside organizations. I'm sure that there are far larger HL7 infrastructures in the world, but we can at least say definitively that we have a big one. One of my longstanding gripes with the world of HL7v2 is that despite all of the improvements made to HL7 over the years (and there have been many) the transport layer protocol has remained stuck in the 70s.
MLLPAs a reminder to the casual reader, MLLP works like this: A client (sender) system initiates a raw socket based connection to a server (receiver) system. The client then sends a single start block character, then sends the raw HL7 message that is being transmitted, then sends two end block characters.
MLLP has been successful because it's simple. It's also a nightmare to implement because it's so simple. There is no security built in, so you have to rely on an agreement with your trading partner around where you might put a username and password (if anywhere) in the message payload. It's generally assumed that you will use raw TCP and it's an uphill battle trying to convince people to implement secure sockets (SSL/TLS).
HTTPSo, how can this be better? I'd like to propose something simple. Let's borrow from any number of successful protocols in the last decade, and define a standard HTTP based transport.
Why HTTP?I can think of plenty of reasons why HTTP is the obvious fit for moving HL7 v2 messages around.
- Although it was obviously originally geared towards moving hypertext documents around, these days HTTP has become the transport of choice for all kinds of applications. SOAP/XML uses it to perform remote RPC. Subversion and Mercurial use it to move version control data around. DAV implementations use it as a kind of "FTP on Steroids". The examples go on..
- There is a good reason that all of those applications use HTTP: It takes care of all of the common infrastructure challenges. HTTP has authentication mechanisms built in. Encrypting HTTP (using TLS) is well understood and implemented everywhere. HTTP management tools are everywhere (Governance tools, Smart HTTP firewalls, etc). HTTP can be compressed easily, and the protocol comes with built in negotiation for this (and other) features. HTTP also tends to play well with content switches, load balancers, firewalls, and other network gear.
- Tool support for HTTP is great by now. Almost every modern programming language already has a good HTTP client built in. Many of them have built-in standalone HTTP servers built in too. Modern ESBs and interface engines generally already have support for HTTP too, so in theory this kind of transport should be possible today with minimal effort.
How would it work?This is where I would like to ask for opinions of the many bright minds doing health information integration out there. The following are some scattered thoughts I have (all of which are nothing more than personal opinions).
- Action: I propose the following:
- The receiving system acts as an HTTP server, and listens for requests.
- The sending system initiates an HTTP POST request, and posts the message being transmitted.
- The receiving system processes the message and replies with an HTTP 200 (assuming success) and responds with a standard HL7 ACK message.
- Addressing: MLLP relies on a specific port being assigned to a given interface. HTTP on the other hand uses paths. So, if a receiving system has multiple incoming interfaces, the sender would identify which interface they wanted to talk to using a POST path.
- Encryption: HTTP over TLS (commonly called https:) should be a standard expectation. HL7 by its nature is used to transmit sensitive information, so discretion should be built in.
- Non-Repudiation: Given the sensitivity of HL7 traffic, support for built-in non-repudiation would be a good thing. One option might be a standard defined HTTP header in the request and the response with a PKCS#7 signature covering the HL7 contents. This should probably be optional, since not every application requires non-repudiation.
- Compression: Subject to both configuration and support negotiation, content compression using GZip could be employed.
How would this look?Here is an example of how such a transaction might look.
Making This HappenI would like to hear ideas, criticisms, opinions, etc. to this proposal. If there is actually agreement out there that this is a worthwhile idea to pursue, here are some things that could happen to move this along.
- A formal specification should be drafted. It would probably make sense to reach out to HL7.org for opinions, but I don't think this needs to "grow up" through HL7 in order to be successful. If the HAPI community could trial something useful, it could probably be proposed as a next step for broader adoption.
- A reference implementation should be created. I propose the creation of a new HAPI subproject which implements this specification, licensed under a separate, business friendly license (Apache?). Potentially this implementation could include conformance verification tools which could be worked into the HAPI TestPanel.
- We could reach out to other open-source HL7 implementations to gauge support for the idea, with the idea that they might be early adopters (Camel/IPF, Mirth, NHAPI, etc.)