Signing HL7 v2 Messages
Nov 4, 2011There’s a generic requirement to sign healthcare messages. For different people, it means different things. Generally, of course, the communication between systems should be secure - both sides should authenticate the communication partner, and the communications should be secure from observation or tampering by a third party. This is straight forward, and off the shelf approaches and solutions exist to do this. These solutions are cross platform ones, and there’s no need or reason for HL7 or any derived community to define any standards in this space. However these only deal with securing the message from tampering while it’s in transit. For a variety of reasons, there’s a need to protect the integrity of a message over a longer period of time - from when it was first constructed to when it’s being read at any time. In Australia, that can be a long time later, because we have a lot of clinical reporting using v2 messages, and they’re rather being used like documents.
Of course, it’s easy to sign CDA - you just sign the whole thing as XML signatures are meant to be used. But you can’t do that to an HL7 message - various parts of it, most of all the MSH segment - need to change in transit on interface engines. So signing an HL7 message with a persistent signature is rather more messy. Today, IT-014-06 has published HB 308 2011: Location of digital signatures in HL7 V2 Messages. Here’s a brief description of the method it describes:
Given an example pathology message like this:
MSH|^~\&|TEST^TESTAPP^L|Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-
444553540000^GUID|||20040410141133||ORU^R01...
PID|1||||PATIENT^Test^^^^^^L||20000101||||139 King Street^^
BUDERIM^QLD^ 4556^AU^C|AU
PV1|1|O||||||0341615J^WHITE^MELISSA^^^DR^^^AUSHICPR^L
^^^UPIN|0341615J^WHITE^MELISSA^^^DR^^^AUSHICPR^L^^^UPIN|||||||N
ORC|CE||F71DEE61-D19E-4571-AF7B-BF8C74597CAB^Buderim GE Centre^
7C3E3681-91F6-11D2-8F2C-444553540000^GUID||CM|||||||0341615J^
WHITE^MELISSA^^^DR^^^AUSHICPR^L^^^UPIN
OBR|1||F71DEE61-D19E-4571-AF7B-BF8C74597CAB^Buderim GE Centre^7C3...
OBX|1|FT|28655-9^^LN||This a simple \H\Test Message\N\ To
demonstrate signing a...
OBX|2|SN|5048-4^ANA titre^LN||<^40|titre|||||F
You pick a subset of the interesting and import fields from this message - a scattering of fields from OBX (2,3,4,5,6,7, etc), and somethings out of OBR and PID, and append them all together using a canonical representation to get this:
FT&28655-9&&LN&&&&&&|^&|^F &&&&&&&|^|This a simple \H\
Test Message\N\ To demonstrate signing and \H\ORU\N\ message\
.br\\.br\Another Line \.br\\.br\A few encoded characters \F\
\S\\T\//\.br\\.br\The end&^SN&5048-4&ANA titre&LN&&titre&&&&|
^&|^F&&&&&&&|^|&<&40&&&^FT&SIGNATURE_HEADER&&L&&&&&&|^&|
^F&&&&&&&|^|PKI Signed Message\.br\Patient: PATIENT, Test
DOB:01.01.2000\.br\Report: Physician Discharge Summary Dated:
10.4.2004\.br\Signed: 20/06/2010 4:39:46 PM&^
Then you sign that and stick it into the message in a couple of OBXs like this:
OBX|3|FT|SIGNATURE_HEADER^^L||Digital Signed Message\.br\Patient:
PATIENT, Test DOB:01.01.2000\.br\Report: Physician Discharge
Summary Dated: 10.4.2004\.br\Signed: 10/04/2004 2:28:57 PM||||||F
OBX|4|ED|AUSETAV2^Digital Signature^L||AUSHICPKI^AP^Octet-stream^
Base64^MIIKTgYJKoZIhvcNAQcCoIIKPzCCCjsCAQExCzA..............||||||F
It’s hard to know what to say about this - it’s a horrifying method, but I can’t think of any real improvements. In fact, I argued for adding more facilities which would have made it more complicated (improving the ability to check which parts of the content has been altered, which isn’t really possible under this method). Unfortunately, the committee didn’t listen to me on that one (or was it fortunate? I argued that it was already so horrifyingly complicated that a little bit extra was hardly noticeable). One thing we can sure about - conformance testing this method is going to be hard hard hard.
What we should learn from this is that CDA is a much better way to handle documents. But a lot of people are very resistent to this notion - v2 works well, they say, ignoring that problem that it doesn’t work well in practice. conformance is hard, because there’s two many higher level patterns laid over the top of the v2 messaging. We’ve pushed it too far. In fact, I rather think that Australia has pushed v2 messaging further than anyone else, at least in regard to using it as a general exchange mechanism for clinical content. What other country is doing that?