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!