First we have this.
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.
More here:
The good here is the Eric has spotted a serious risk and has actually done something to help people address it. All we need is awareness of the risk and for care to be taken!
Second we have the above mentioned Grahame Grieve discussing complexity.
Complexity of Standards – Updated
Posted on November 14, 2013 by Grahame Grieve
A rough plot of the internal complexity of the standard (y, log) vs the complexity of content that the technique/standard describes
They wanted to know where FHIR sits on the graph. Well, here’s a guess:
(Click below to see picture)
Comments:
- The goal is go downwards and right
- While I think that FHIR is inherently simpler than HL7 v2, it’s breadth of functionality is a lot wider, so I couldn’t rate it as overall simpler
- FHIR has more semantic depth than CDA in several directions, though the core clinical statement in CDA can go further – but both CDA and FHIR become exercise in extension at that level. So FHIR wins by a little
See blog for picture here:
What I see as useful here is to see people putting in a serious effort to make things safer and easier. Only the very naïve think all the answers are easy and out there - especially in the safety and semantic domains - they simply are not!
David.
No comments:
Post a Comment