Data vs Information: The EMR Readability Problem (Part II)

This is the second part of a guest blog note by Dr. Brian Jackson, a pathologist and informatician from ARUP Labs.  He has been a frequent contributor of guest blog notes to Lab Soft News.  --BAF

In a recent note (see: Data Versus Information: The EMR Readability Problem (Part I)), I described the problem of readability of EMR notes and laboratory results and how existing healthcare IT systems prevent pathologists and laboratories from playing a larger role in improving the clinical usefulness of laboratory information. LIS and EMR formatting requirements force lab results into short, unformatted alphanumeric fields. This approach makes it impossible to communicate the clinical and scientific implications in human-friendly format to test-ordering clinicians.

Paul Valenstein, a pathologist in Michigan, described this problem beautifully a few years back in an Archives of Pathol Lab Med article. Basically, the article describes how journalists might approach the problem of formatting surgical pathology reports. More recently, a Wired Magazine article demonstrated how graphic designers might approach clinical laboratory reports. Both of these articles are compelling. Why can’t we implement their suggestions?

The answer lies in the distinction between data and information. Healthcare IT and academic medical informatics have both had a strong bias toward computer-readable data rather than human-readable information. SNOMED, LOINC and HL7 are all designed to structure and transmit data in computer-readable form. This is not an inherently bad approach to the problem. Unfortunately, structuring data in these forms makes it less human readable. The example I raised in my previous note was publishing a magazine entirely in Twitter format. While this is technically possible, it would force a major rethinking of the content. Most magazine articles could not be communicated with nearly the same level of nuance and storytelling if forced down to 140 unstructured characters and stripped of graphics.

Humans and computers are different and we have different needs. Why don’t we respect that difference within electronic medical records?  The roots may lie in the fact that, in our rapidly disappearing paper chart world, rapid data entry and review also occur inside charting "artifacts." A good example of such an artifact is the hard-copy ICU flow sheet where data entry and review take place on the same physical sheet of paper.

One reason the world wide web evolved so quickly in the 1990s was that it didn’t sacrifice human readability for computability. HTML was the first major standard which was derived from earlier publishing industry markup languages. HTML doesn’t structure data or make it computable. Rather, it defines the visual layout. The development of XML that was used to structure data and make it computable came later. Moreover, XML augmented rather than replaced HTML. The good news in this story is that the current generation of web developers has grown up understanding the need to design human interfaces as a separate layer from the data handling. The bad news is that most of the healthcare IT community has yet to make that same conceptual leap.

As one small step in this direction, ARUP, has begun producing PDF versions of complex lab reports as a parallel reporting process rather than as a replacement for field-defined data. In principle, we could use HTML rather than PDF. Getting these documents into the hands of clinicians has proven to be our primary bottleneck, however. Our existing HL7 interfaces are mostly to other LISs that only store lab results in data form and not document form. Moreover, the downstream interfaces to EMRs are also based on transmitting data rather than documents. Only recently has our own University of Utah hospital implemented a document management system that allows physicians to view primary documents alongside EMR-reconstructed clinical data.

What do all of you think? Is it realistic to hope that medical centers and healthcare IT companies will extend their infrastructure in order to provide all patient data in both computer-friendly and human-friendly forms? Perhaps we an help convince them about this approach through our hospital committee structures and our one-on-one interactions with vendors.

Comments

[Liora Alschuler]

Hi, Bruce, I couldn't agree with you more. The standards, however, are not so much the problem as the policy. HL7's Clinical Document Architecture (CDA) is an XML spec that preserves narrative, in fact, it insists on it in a very HTML-ish rendering. The coded/structured data is optional, according to the standard.
Convincing policy makers and the data-centric informaticists that, yes, this still has value is the uphill slog.
That said, I think we are making some progress. See www.healthstory.com for a group that has become a focal point for lobbying on this point, with some traction. I'll suggest that they post a pointer to this blog. Thanks.