Overview

What are the good parts of HL7 - The parts that work and are proven. So what are the good parts? It depends on your perspective but in Australia the good parts, from the point of view of people outside of the Hospital is the Laboratory Messaging, and inside Hospitals you can probably add ADT messaging. These are mature V2 standards and for the most part work and work well. The are far from perfect of course, but they still work.

The so called Laboratory messaging is however just clinical messaging, which is not Laboratory specific and building on this for clinical messaging is a path forward that offers the smoothest way forward. Clinical data can be more complex that Lab data however and requires more than single (OBX segment) "Name = value" pairs. This wiki looks at the issues of using V2 messaging for arbitrarily complex clinical data and ways to do this reliably and in backward compatible ways. Once we have this Clinical Decision Support becomes possible.

This page was inspired by the book by Douglas Crockford's "Javascript The Good Parts" which brings sanity and power to the javascript world. The aim of this wiki is to document the experience Medical-Objects has learnt in the last 10 years of dealing with HL7 V2 messaging on an everyday basis. It is biased to the Australian versions of the HL7 V2 standards, but is applicable generally.

What needs to be enhanced to Allow HL7 V2 to carry Complex data

The simple answer to this is Metadata and nested "Name=Value" pairs

By Metadata I mean a specification to carry a complex set of data items such as a Patient History summary or a record of a clinical score such as an Apgar or a Crohns's Disease Activity Index (CDAI). This Metadata needs to describe the hierarchical data structure, the terminology and the constraints on usage and cardinality etc. The best option for this currently is the ISO 13606-2 standard, but its possible to describe it in a document format.

We need document sections and ways to represent complex items in a tree structured way. In HL7 V2 the name value pairs are "OBX" segments and out of the box they come as a linear list of items, and to achieve our aims this needs to be enhanced. It also needs to remain standards compliant and backward compatible and this is the way we can move forward without breaking existing working messaging

This page is a work in progress, but the aim to to explain how to do this in a powerfull way. The aim is to show how something like a HL7 V3 CCD document and be represented in HL7 V2 and to show how to use ISO-13606-2 Archetypes to Automate the representationof complex hierarchical data.

Introduction to Structured OBX Data

Improving the Display of Data in HL7v2

One of the practical issues in getting uptake of data exchange using HL7v2 is the quality of display at the recipients end. HL7V2 text formating using the "FT" or freetext class is quite basic and demands a mono-spaced font. The only real formatting is highlight and that's about it. People are used to much richer display and this can be achieved by including a html display OBX which allows a standard, text based format that permits rich formatting and also allows binary data, such as images to be embedded into the document. Virtually every platform has a browser and the document is human readable for debugging purposes. There is a Standards Australia to define a Standard way of doing this and the straw man is being developed here.

Reliable Parsing of HL7V2

Experience has taught us the the classic encoding of V2 data is very efficient and very backward and forward compatible. However many implementations of parsers by recipient systems do not fully implement the process and this can introduce significant errors and negate many of the advantages. The issues around the encoding are all in the manual, but they are scattered over several chapters and what is needed is a developers guide detailing the "gotchas" and "tips and tricks" with the information in one place so that a new implementer can create a parser based on this information. This is the place where this will be written. HL7v2 parsing

Requests for Historical Results

A common task in medical practice is to request copies of investigations or reports that have already been performed on a patient. This avoids costly duplication of testing in many cases and is often vital to understanding to current condition of the patient. In many cases the patient may not be aware of exactly what tests have been done and who actually performed the investigations. Often there are only a small number of service providers in an area and a request for past information is issued to all the local providers even though there is no certainty that they hold any reports. Depending on the use case all testing may be significant, or the request may target a specific test type only. The requester may want all reports going back many years, or only bve interested in very recent results. These requests have privacy implications and the filler of the request often needs a human to decide on the appropriateness of the request, making an asynchronous process desirable. This document defines a mechanism to support these orders using standard HL7V2 order mechanisms. This is the place where this will be written. HL7v2 HistoricalData

Representing Codes in HL7V2 with focus on SNOMED-CT

HL7v2 can be used to carry complex coding information. This is a presentation done for HL7 Australia that covers many of the issues.