Background

Today, HL7 Australia held a one day meeting here in Melbourne, entitled “Implementing CDA in a v2 world“. The meeting was keynoted by Ken Rubin, who gave a very interesting and insightful discussion of the relationship between v2 messages, CDA documents, and SOA (and big thanks to Ken for making the long the trip over from Washington for a few days – instead of taking interesting photos).

Australia has a deep investment in V2, with a widely deployed distribution network that distributes v2 reports from diagnostic services, along with a mix of referrals/discharge summaries/letters between GPs. Just about all GP practices and many specialists are hooked up to the network, though the connection between the network and the tertiary referral hospitals is a bit spotty. It’s not really a network in the classic sense though, distribution is performed by private carrier companies that charge for their services (though the services they offer – clinical desktop support, administration etc are not cheap to provide).

HL7 v2 is deeply enmeshed in this world – and now we are talking about introducing CDA documents. Why? Well, for two reasons:

• CDA is actually a much better fit to the problem than HL7 v2. I’ve written about this before, but since I wrote that, it’s become clear that we’ve taken HL7 v2 as far as it can go. I’ll make another post about this later
• The pcEHR is just over the horizon, and CDA is a perfect fit to it, and also the express choice of the pcEHR architecture

My subject for today was how to transition to providing CDA documents for diagnostic reports in this scenario. The first problem is distribution – NEHTA has developed the specifications to support true network distribution that is self-administering in the way the internet is – secure message transport, with public identifer and certificate registries. But while the infrastructure for this is in place or nearly in place, a transition to this infrastructure is costly (mainly in administration costs), and even thought the end state will be cheaper and better, there’s no enthusiasm for making this transition yet. And we don’t need to – we already have a working distribution mechanism for CDA: putting them in HL7 v2 messages. There’s some open questions about exactly how that works – I’ll take that up in a separate post. But we know how to transmit CDA documents – in v2 messages.

So how do you generate CDA documents? The best way to do it is to generate them at the source, where the HL7 v2 message is generated. But I’m hearing the message loud and clear that due to the prevailing business operating conditions here in Australia, this is just not feasible (more for business reasons than technical reasons). So people are left trying to generate CDA documents from the v2 messages downstream. That’s actually harder in a technical sense, I think.

The rest of this discussion is very specifically about diagnostic reports in HL7 v2 messages following the AS 4700.2 standard. Not electronic ordering – I wouldn’t use CDA for that, but for diagnostic reports – it’s the way to go. And the AS 4700.2 standard lays down enough rules to make it possible to convert from v2 to CDA, and to do that in an off-the-shelf tool. When writing such a tool, there’s several problems to deal with:

• Multiple documents per message?
• Filling out missing identifiers & details
• Ignoring things in v2 not represented in CDA
• Converting Data types / Data Quality issues
• Constructing Narrative (& format conversions)
• Attachments – images and digital signatures

People are pretty interested in these subjects, so I’m going to make a series of posts describing these issues. Though I’ll be writing specifically about AS4700.2, much of what I have to say will be useful in a wider context.

But the some of this is that it’s hard – hard enough to be too much for a challenge for most programmers. Well, a solution is at hand.

Free V2 to CDA Conversion Tool

From today, I am giving away a free v2 to CDA conversion tools. It will convert from conformant AS4700.2 message to a CDA document that is conformant with the pcEHR specifications. It’s available both as a testing GUI, and also the engine will be provided in various forms that make it suitable for inclusion into production code (web services, file transfer, TCP/IP, COM object, others). It will continue to be free for use with AS 4700.2 messages, and I’ll provide free support to fix issues related to conformant messages. And the code is proven reliable – it’s based on the code libraries from HL7Connect.

You can get further details and download it from The CDA Tools page.

The tool itself is currently in beta. The CDA document it produces is still subject to change (the specification is only partially written so far). But the infrastructure (i.e. APIs) will be stable.

Note that a couple of people asked why I’m giving it away. The answer is that I’m being paid by NEHTA to write these specs, and I didn’t see how it was reasonable to charge for a tool that implements specs I get paid to write. Also, I’m frustrated with the slow adoption of CDA, and the pathology industry should be doing better  – this is my small contribution to bringing things forward.