The Power, the Glory and the Dangers of structured health data
It is now over eighteen months since I publicly aired my grave concerns regarding a critical safety issue for Australia’s Personally Controlled Electronic Health Records (PCEHR) system, which centred around the lack of scrutiny of the quality of data in CDA documents to be contributed to people’s records. I have no idea if anyone other than Grahame Grieve took my concerns seriously. Certainly, no-one else has ever contacted me regarding the serious safety and quality issues I raised at the time, least of all NEHTA.
But it does appear that safety and quality issues have been getting slightly more attention in recent months than they did 18 months ago – at least in Australia. And on this front, I have some further good news.
By way of background, for most of that 18 months I was working for SA Health on the integration and migration of ( mainly Adelaide-based public ) hospital systems to work with a new potentially statewide public hospital EMR and Patient Administration System known affectionately as EPAS. The network’s “central” components comprise a number of Allscripts Sunrise products, an Intersystems Ensemble Integration Engine, and an Enterprise Patient Master Index built around the IBM Initiate EMPI product. It is undoubtedly one of Australia’s largest health system integration undertakings, with over 200 interfaces supported by the single integration engine. I was responsible for the specification and documentation of many of these interfaces and for testing a number of key ones, including much of the integration with EPAS. Nearly all of the interfaces use some variant of HL7 v2.3.1. I became acutely aware of the structural and semantic issues associated with integration on this scale, and even more so with the issues pertaining to codes and code mapping. The primary clinical system, Sunrise Clinical Manager, alone has well over a thousand code tables (Dictionaries) many of which were in a cyclical state of flux during the configuration and testing phases of the project. Over 10,000 new codes were introduced just to describe patient locations – hospitals, campuses, wards, rooms, beds, chairs etc. in a uniform fashion. The integration task was, and still probably is, a herculean task. We had full time team of 12 involved.
Despite HL7′s dominance in the e-health messaging world over the past 15 or so years, there has never been any viewer produced anywhere in the world (to my knowledge) that allows or assists technical IT people, let alone clinicians, to view HL7 messages in a “meaningful” way, with their codes decoded into human readable form. Until now!
I have spent the past two months changing the situation. I’ve taken the embryonic version I started for Healthbase Australia’s Pathology message validator some 2.5 years ago and radically improved it to the point where I think it worth making it available to the community. The current incarnation “understands” most of the internal HL7 message codes, it can display the meaning of SNOMED, LOINC, AMT, AUSTPATH, some ICD-O morphology codes, ISO+ units, and I have started to incorporate the new Pathology Units and Terminology descriptions developed under the Royal College of Pathologists Australasia (RCPA) led PUTS project. The view hides, by default, the arcane codes used by HL7 and presents pathology, diagnostic imaging and other HL7 v2 based messages in a form readily understandable to clinicians and even patients. It follows the evolving Australian AS4700.2 standard, and conventions. It renders inline images directly, it supports and displays embedded narrative reports – PIT, JPG, HL7 formatted text, PDF, RTF and HTML as described in the Standards Australia Handbook HB262. It supports the viewing of multiple messages per file.
The previous federal Health Minister announced shortly before the September election, some funding and an undertaking to accelerate the uploading of pathology results to the PCEHR. From the rumours that have been going around, this is likely to be done using PDF versions of each report, uploaded somehow from GP desktops. If only we could, instead, harness the power already inherent in the HL7 v2 messages already sent by most pathology labs to GP systems. The Healthbase Results Viewer gives a glimpse of how that might add value that a PDF file could never do. The following image is a snapshot of a result where the viewer has interpreted the structured data and automatically added links to one or more detailed authoritative web sites describing the tests undertaken, their context for use, their typical reference ranges and any qualifiers and warnings. The two authoritative sources for this test information, that I have already built into the viewer are the LabTestOnline site and the RCPA manual. The viewer links directly to the relevant test page. Moreover, to illustrate how universal and flexible an approach this is, I have also included links to much of the Spanish version of LabTestsOnline and the viewer picks up these links through a LOINC/viewer/labtestonline synonym table.
But I think what the viewer has most to offer, is the ability to dramatically allow focus on quality and safety issues, particularly around coding, code mapping and display names. It allows clinicians to assess and address message quality and safety issues in a way never before possible.
So if you sit on a safety and quality committee, if you are a vendor or developer of healthcare software that shares information electronically, if you contribute to e-health messaging standards, if you are a systems integrator, health informatician, clinical terminologist, if you are a clinician or researcher with a focus on the quality of data in e-health, then you cannot take your role seriously without having the ability to assess that quality in the millions of messages being exchanged daily via HL7. This is true if you live in Namibia, New York or Newcastle. You now have the ability to shine a light on what until now has been far too dark a place for most people to venture. If you care about quality and safety, please switch on the light!
Hi Eric,
glad to see you have discovered HL7V2 and its potential. If we actually invested in the quality of the V2 thats out there and awful lot of real progress could be made without throwing away years of investment in systems.
Eric, it’s somewhat ironic to criticise the safety issues in CDA, and then recommend using v2 with the same issues and a whole lot of entrenched poor safety/consitstency as well. Andrew’s right: “If we actually invested in the quality of the V2″ – only, we’d have to invest a very great deal. At least some of that is happening with PITUS. Yay.
Grahame,
HL7 v2 is a well entrenched protocol for shipping path results around in Australia. The atomic data is being used extensively in many public hospitals – e.g. in South Australia. There are undoubtedly quality and safety issues, but switching to some untried alternative helps no-one in the short term. What beggars belief, is that even after all these years not the HL7 organisation, not any affiliate organisations, nor any national standards bodies, nor any national programs, nor any safety/quality units or projects have seen fit to try to display message contents in a “meaningful” way, so that quality and safety issues can be aired and resolved. HL7 v2 is built on, and dependent upon multiple, poorly governed, poorly distributed code sets. CDA probably even more so. I see zero attempt to try to display the structured content of CDA documents in any meaningful way whatsoever. My post wasn’t about recommending HL7 v2, it was about illustrating the potential and dangers of structured data, letting anyone who cares about data quality and safety that a new tool is available to make the data in pathology messages meaningful for inspection. Ultimately this should lead to an improvement to safety and quality.
A significant issue I raised about CDA and the PCEHR was that, unlike V2 messages, these clinical documents risked piling up with their atomic data uninspected potentially for weeks, months or years. This is different to v2 pathology messages, whose atomic components are usually digested into a system, looked at and acted upon immediately, or else discarded in favour of some PDF/RTF/PIT report in the message.
How about letting me know how to improve the viewer. Alternatively, how about trying to build or have someone else build something similar for FHIR messages/documents? I’m quite sure its not possible for CDA – that’s a lost cause.
“There are undoubtedly quality and safety issues” – yes, in spades. As for CDA, well, you’ve been proven right. We don’t process the data because we can’t, and we can’t because we don’t (the NPDR documents are an exception). But the real underlying problem is that we don’t have consensus. Pathology is easy, comparatively, as I said, and even there we don’t.
As for FHIR: I’m definitely going to follow your recommendation about an automated rendering, and that will be published as part of the reference implementions in the spec (javascript, xslt, java, c#, pascal – should be something for everyone there)
Back in 2006, DoHA was trying to get Divisions, as they then were, to develop means of extracting HbA1C from GP databases. I got this happening in a small way, using CARDIAB and Argus. It was hard work though.
At a Divisions Network IM meeting that year, I floated the idea that this data could be sent directly to Divisions by pathology providers, who’d implemented HL7 messaging, in the main, simply by us obtaining the GP’s permission and forwarding it to the pathology provider. Several provider contacts saw no problems in this.
Nonetheless, nothing came of it. From your article it sounds like we’ve gone backwards in this respect. PDFs!! Great, not!!!