Thursday, June 27, 2013

Why Old Issues Regarding CDA Are Once Again New

In two posts from the last few days (here and here) I comment on recent intense exchanges within the HL7 CDA community concerning proper coding of clinical data using CDA. The reader is invited to examine these exchanges and to determine whether she agrees with me in the conclusion that HL7 CDA is, like the RIM on which it is based, so clunky, and so counterintuitive, as to threaten  dangers for safety and security (dangers which become all the more worrying to the degree that HL7 CDA is associated with government edicts requiring its use). 

Yesterday I added a further post, recalling Eric Browne's argument from January 2012 to the effect that this state of affairs is bringing about a situation where (to paraphrase only slightly) 
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. 

No news here, therefore; we should all just move along and get back to the more important issues of the day. 

But what is Grahame's response?

Eric’s key issue is that HL7 CDA allows data to 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.

As Grahame points out, CDA is built around the notion of the twin forms – a human presentation, and a computer processible version. But when Eric complains that clinicians have no way to inspect how the data and the narrative relate, nor is there an algorithm to test this, his response is 
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? 

Is it that HL7 CDA structured data is good because the problem of uncheckability (either by human beings or by algorithms) is faced by all attempts to create structured healthcare data?

Does experience thus far (including experience of panic on the strucdoc listserv in just the last few days) suggest that HL7 CDA is a good candidate to overcome this  problem, given that we are all agreed that it needs to be overcome?

No comments: