On Tue, Jan 30, 2018 at 9:35 AM, Flores, Finnie
Hi John,Thanks for questions. At this point, we plan to publish this for our reference data model/dictionary (which eventually will be implemented in solutions).
HL7 (Health Level 7) is a collection of standards and proposals for healthcare-specific data exchange between computer applications. Considerable efforts are being invested by governments and industry to use HL7 as part of national health IT projects. Many claims are made on behalf of HL7 by its advocates. The goal of this blog is to investigate the merits of these claims, and to provide some needed independent perspective on the HL7 project.
we are in grave danger of setting in train a collection of safety and quality time bombs, spread around [the world] 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 Grahame Grieve points out in his comment to this post, he had already responded to Eric's argument on his healthintersections blog in February of that year.
This is true – and it would be a whole lot more concerning except that this is true of all the forms of exchange we currently have – it’s just that they don’t have any human fall back to act as a fail safe check.Thus the miserable complexity and clunkiness and unteachability of the structured part of HL7 CDA (thus of the HL7 part) are not a problem – because ... well, because of what?
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 here). 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.
The 'core principles' referred to are documented here.On Sun, May 19, 2013 at 9:48 PM, <firstname.lastname@example.org> wrote:Graheme,I am opposed to this as I think it just adds confusion when the implementer looks at anything else such as PHIN VADS VASC, CTS2 or the core principles. At some point it is just better to say that the implementers need to learn the jargon rather than trying to change every other group to use yet another ambiguous term.Cecil