In a recent post (see: Publishing Test Results in Patient Portals: Holding a Tiger by the Tail), Bruce Friedman raised the difficulties of displaying test results to a patient through a portal. In the introduction to the note, he wrote:
We in the world of pathology have not yet completely mastered the task of displaying test results to physicians but are now embarking on a similar task for patients
...and this is after several (human) generations working it. And if anything, we (clinical diagnostics) are falling behind due to the availability of new features of report presentation (colour, graphics, interactiveness) that are now technically possible, but only gradually becoming supported by the mature clinical laboratory systems, and still imperfectly understood.
Bruce went on to write:
The problem of displaying lab test results for patients in the patient portal is even more complicated than their acquisition and storage in the LIS. Recall that we use HL7 interfaces to copy results to the EHR and subsequently to the patient portal server. Recall also that such interfaces act as what Ulysses Balis has called a data shredder, deconstructing the formatting that we have carefully developed over decades on our LISs. Additional errors can be introduced when test results are passed from the EHR to the patient portal
The term “data shredder” is absolutely appropriate. Anyone setting out to write a general case [HL7 v2 message] to [presentation media] process faces a daunting task. The ever flexible OBX segment presents a plethora of fields, types and codes that can be used to represent the same thing in several different ways. Some of the differences are purely syntactical and some convey implications that can only be fully understood by the source system – that is, only when HL7 v2 is used completely correctly.
Recent work by HL7 to publish more specific lab reporting profiles has improved the situation significantly, but it’s still not a bounded problem – there is no way to know whether a process is clinically safe in the general case: that any HL7 message received will be correctly parsed and presented. Nor are comprehensive suites of test messages easily available (if at all, in fact). Even if all these issues could be overcome, the EHR system is still a secondary user of the data, and important information about how thew results should best be represented is not carried in the raw data in the HL7 message.
In Australia, most diagnostic reports are returned to the requesting physician using HL7 v2 messages. We have dealt with the challenge of proper representation of diagnostic reports by adding a final OBX segment that carries a proper representation of the report. This is defined in the relevant Australian standard (AS 4700.2).
This means that there is a series of OBX segments that carriy the atomic test results, and one final one that carries either a PDF, RTF, or HTML file which is the lab’s own defined display format for the test results. A clinical system can still process the atomic results for clinical decision support or consistent display, but physicians can (or should be able to) view the original report from the laboratory as it intended, and it is on this basis that the clinical service provision (with its attendant legal obligations) is based. This system is not yet perfect – there are still clinical safety failures caused by technical limitations relating to consistent handling of fonts, colours, and other presentation features across various IT platforms, so the conformance rules are still being refined to prevent adverse outcomes.
But these issues are orders of magnitude easier to resolve than the challenge of reconstructing the correct presentation from the atomic data in the message. Unless and until there is an agreed standard method to convert a message to a display, with a maintained testing process where both source and presentation systems are checked, there can be no expectation that the presentation will be anything but random, except to the degree that the labs and EHR managers can agree to invest in testing and customisation.
Holding a tiger by the tail? Sounds more like Russian Roulette to me.