Australia is poised to produce a system of Personally Controlled Electronic Health Records (PCEHRs) from July 2012, some 6 months from now. According to the recently published Concept of Operations, each person’s PCEHR will comprise a set of electronic documents, the majority of which are to be based on HL7’s Clinical Document Architecture (CDA), in the form of “health summaries”, discharge summaries, referrals, and the like. Having studied both the HL7 specifications in detail as well as dozens, if not hundreds of examples of CDA documents from around the world over the past 5 years, I have come to the conclusion that there are significant safety and quality risks associated with relying on the structured clinical data in many of these electronic documents.
So concerned am I by this issue that I am notifying key stakeholders and urging all individuals and organisations who take safety and quality of clinical data seriously, to investigate this issue thoroughly before committing to any further involvement with the PCEHR system being rushed through by the federal Department of Health and Ageing.
One major problem with HL7 CDA, as currently specified for the PCEHR, is that data can be supplied simultaneously in two distinct, yet disconnected forms – one which is “human-readable”, narrative text displayable to a patient or clinician in a browser panel; the other comprising highly structured and coded clinical “entries” destined for later computer processing. The latter is supposed to underpin clinical decision support, data aggregation, etc. which form much of the justification for the introduction of the PCEHR system in the first place. The narrative text may appear structured on the screen, though is not designed for machine processing beyond mere display for human consumption.
Each clinician is expected to attest the validity of any document prior to sharing it with other healthcare providers, consumers or systems, and she can do so by viewing the HTML rendition of the “human-readable” part of the document ( see the example discharge summary at http://www.healthbase.info/cda_challenge/sample/sample.html ). However, the critical part of the document containing the structured, computer-processable data upon which decision support is to be based is totally opaque to clinicians, and cannot be readily viewed or checked in any meaningful way. Moreover, I know of no software anywhere in the world that can compare the two distinct parts of these electronic documents to reassure the clinician that what is being sent in the highly structured and coded part matches the simple, narrative part of the document to which they attest. This is due almost entirely to the excessive complexity and design of the current HL7 CDA standard.
It seems to me that we are in grave danger of setting in train a collection of safety and quality time bombs, spread around Australia in a system of repositories, with no understanding of the clinical safety, quality and medico-legal issues that might be unleashed in the future.
As an illustration of the sort of problems we might see arising, I proffer the following. I looked at 6 sample discharge summary CDA documents provided by the National E-health Transition Authority recently. Each discharge summary looked fine when the human-readable part was displayed in a browser, yet unbeknownst to any clinician that might do the same, buried in the computer-processable part, I found that each patient was dead at the time of discharge. One patient had been flagged as having died on the day they had been born – 25 years prior to the date that they were purportedly discharged from hospital! Fortunately this was just test, not “live” data.
A second example is the sample electronic prescription document that has been provided with the package of NEHTA specifications currently being “fast-tracked” through Standards Australia to become standards for electronic transfer of prescriptions in Australia. Again, this Level 3 HL7 CDA document contains separate “human-readable” and coded, structured sections, with no connection between the two. The former looks somewhat like a computer-generated printed prescription ( as shown at http://www.healthbase.info/scratch/ePR_rendered.html ). The computer processable, coded entries in this sample both contradict and also contain additional information to the human-viewable part, yet these coded entries are opaque to clinicians. Again, this was just example data, but the principle remains the same. Clinicians cannot see what is in the coded parts of the document.
I contend that it is nigh on impossible with the current HL7 CDA design, to build sufficient checks into the e-health system to ensure these sorts of errors won’t occur with real data, or to detect mismatch errors between the two parts of the documents once they have been sent to other providers or lodged in PCEHR repositories.
This situation must also be of potential concern to patients considering opting in to the PCEHR system. Consumers have been led to believe that they will be able to control what data is sent to the PCEHR and who can see it. But if neither they, nor their healthcare provider can view all the data to be sent and stored in the new system, then how can they possibly have confidence that they will be “in control” of their data?
Surely this must ring alarm bells to all involved!
To allay the concerns raised here, NEHTA should provide an application, or an algorithm, that allows users to decode and view all the hidden, coded clinical contents of any of the PCEHR electronic document types, so that those contents can be compared with the human-readable part of the document.