Monday, 23 July 2012

A call for a new HL7 v2 Transport (HL7 over HTTP)

It's time for a replacement for the aging HL7 Minimal Lower Layer Protocol (MLLP).

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.

MLLP

As 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).

HTTP

So, 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 Happen

I 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.)
So... comments? :)

9 comments:

  1. This is really interesting James. Good write-up.

    I think an idea like this holds a lot of promise but it really depends on how it is implemented. The question is: will HTTP be just the transport or will its features be used to the full? For example, SOAP treats HTTP like a cab driver: 'Take me where I want to go but don't talk to me.' It coerces basically everything to a POST, has its own status codes, etc.

    So in this case would this new standard take into account using the full array of HTTP status codes or would everything be funneled to a 200 or a 500 with internal error info? What about using the four (at minimum) main HTTP methods? What about safety and idempotence?

    On the mailing list, one user mentioned REST when responding. Would there really be a RESTful approach based on running methods against resources (i.e. Patients, Providers) or would it be like SOAP, namely RPC over HTTP? (That seemed to be the way James was leaning in his write-up). If a RESTful approach were desired, would some sort of HATEOS be implemented with a hypermedia system to link from one resource to the next. Keep in mind my experience with HL7 is limited (just getting started with my first HL7 interface) so it's hard for me to wrap my head around the scenarios that others with more experience in HL7 are probably really familiar with and how those scenarios relate to HTTP not just as a transport but as a protocol (i.e. The HTTP RFC).

    I guess my point is if the idea is HTTP just as a transport and building another envelope inside HTTP (like SOAP did) then that's fine but then one would have to stay away from all the RESTful constraints because they just wouldn't fit. On the other hand if the desire is to really use HTTP as a protocol (the whole enchilada as they say) then the first step is to study the HTTP RFC and RESTful constraints and see if/how those might fit into HL7 interfaces and workflows.

    ReplyDelete
  2. We don't have your message load, but in fact we've been trying to move from MLLP to HTTP for providers outside our VPN.

    In our design:

    * We use HTTP Response codes instead of ACCEPT ACK in extended mode.
    - 200 as "CA"
    - 400 as "CR"
    - 500 as "CE"
    * Use TLS to secure connections when needed.
    * Allows the use of XML or ER7 encoding, depending on the provider.

    (Btw we use MIRTH)

    Unfortunately, providers insist on using WS instead simple and pure HTTP.

    ReplyDelete
  3. Sounds like a very interesting subject...

    A CON could be: TLS + 2Million messages + big size of message can impact on the performance of a system well known as efficient until now.

    Cheers!

    ReplyDelete
  4. By the way, my name is not Canada, it is Pablo R. :)

    ReplyDelete
  5. I am agree with Alberto Saez MLLP has been successful because it's simple.

    ReplyDelete
  6. After examine a couple of of the weblog posts on your web site now, and I actually like your means of blogging. I bookmarked it to my bookmark web site record and will probably be checking again soon. Pls check out my web site as well and let me know what you think. san francisco school bus
    san francisco party bus

    ReplyDelete
  7. All the contents you mentioned in post is too good and can be very useful. I will keep it in mind, thanks for sharing the information keep updating, looking forward for more posts. Thanks
    chiropractic soap notes

    ReplyDelete
  8. If you set out to make me think today; mission accomplished! I really like your writing style and how you express your ideas. Thank you.
    swiss taxi

    ReplyDelete