Thursday, June 20, 2013

Why do HL7's Attempts to Create a Structured Clinical Document So Conspicuously Fail?

I estimate the total number of words posted to HL7's STRUCDOC (structured documents) listserv for the single day of June 18, 2013 to be in the order of 8,000. The Digest of these postings is provided below. (I do not provide the postings themselves, for reasons of space, though samples of earlier such exchanges are available, for example here.)

The general tone of these exchanges is a mixture of authority (from persons who have been participating in such email fora for a long time), concern (from persons new to HL7 who are interested in learning how to deal with sometimes difficult topics), puzzlement (from persons who wonder why these problems cannot be handled in a simpler and more intuitive way), and panic ("if HL7 generates such furious and seemingly interminable debates of such a high degree of complexity, how will we ever be able to safely use it to address the day-to-day practical problems that we face in coding healthcare information?" "How will we ever be able to teach people to use it?").


I have been asked to explain why I think HL7 generates debates of this sort, and I here provide a first list of what I believe to be the most important factors. 


A. As argued from the very beginning of this blog, the RIM (Reference Information Model), which is the basis of HL7 V3, rests on a fatal confusion between model of information and model of reality. This brings the consequence that the persons involved in these debates lack a clear foundation for debate. I have argued at length that it is impossible to use the RIM to produce an intuitively satisfactory representation of any even modestly complex matter -- since parts of such a representation will relate to information about the world and parts to the world itself (for example to the condition of the patient). (Matters are made worse by the fact that the very framework obfuscates the difference between the two.) 


B. This failure to provide intuitively satisfactory representations implies a failure in consistent understandability. This will mean that (for example) lists of codes and statements of coding principles will be understood differently by different individuals, some of whom will fight over whose interpretation is correct.


C. These fights will sometimes lead to adjustments to the principles. (They may even lead to improvements; some have even led to the addition of elements drawn from realist ontology to the HL7 framework.) Unfortunately, and perhaps most regrettably, the explications of these adjustments do not replace the existing HL7 documentation. Rather, they are simply inserted into the documents alongside the original, logically incoherent, formulations, as outlined here. This means that the result of such adjustments is that the HL7 documentation itself becomes logically ever more incoherent, leading to ever more furious debates over its interpretation.


D. The end-effect is that people leave, and when the new people who join start their work they have to rely  on bloated and confused documentation -- but now without the benefit of having experienced the criticisms of shoddy work advanced (for example on this blog). And so the same mistakes are made all over again.


To see why such issues might be important for reasons other than morbid curiosity, see "Critical Safety Issue for HL7 CDA" above.


STRUCDOC Digest for Tuesday, June 18, 2013.

1. SUBJECT CHANGE: Debate about whether we need to deal with C-CDA reality

2. RE: SUBJECT CHANGE: When to use OTH and when to use UNK when you don't have a code in the Value Set
3. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
4. SUBJECT CHANGE: Debate about complexity of standards
5. Re: SUBJECT CHANGE: Debate about complexity of standards
6. RE: SUBJECT CHANGE: When to use OTH and when to use UNK when you don't have a code in the Value Set
7. Fix CDA's problems, don't encourage half measures.  Was:  RE: SUBJECT CHANGE: When to use OTH and when to use UNK when you don't have a code in the Value Set8. header >> race code ambiguity
9. RE: header >> race code ambiguity
10. Re: SUBJECT CHANGE: When to use OTH and when to use UNK when you don't have a code in the Value Set
11. Re: header >> race code ambiguity
12. Re: header >> race code ambiguity
13. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
14. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
15. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
16. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
17. RE: header >> race code ambiguity
18. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
19. RE: header >> race code ambiguity
20. RE: header >> race code ambiguity
21. SUBJECT CHANGE: raceCode in MU, C-CDA IG, and TTT Validator
22. Re: header >> race code ambiguity
23. RE: SUBJECT CHANGE: raceCode in MU, C-CDA IG, and TTT Validator
24. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
25. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
26. RE: Block Vote 06/20/2013: Structured Form Definition Implementation Guide Ballot Reconciliation
27. Re: header >> race code ambiguity
28. Re: SUBJECT CHANGE: raceCode in MU, C-CDA IG, and TTT Validator
29. RE: Block Vote 06/20/2013: Questionnaire Response Implementation Guide Ballot Reconciliation
30. RE: header >> race code ambiguity
31. Re: header >> race code ambiguity
32. Re: header >> race code ambiguity
33. Re: Value Set question, split from thread "Validator Issue re. CWE Value Set Bindings"
34. Re: Value Set question, split from thread "Validator Issue re. CWE Value Set Bindings"
35. Hijack Subject: Can we indicated "translation closeness" in CD
36. Re: Hijack Subject: Can we indicated "translation closeness" in CD
37. Re: Hijack Subject: Can we indicated "translation closeness" in CD
38. Re: Value Set question, split from thread "Validator Issue re. CWE Value Set Bindings"
39. Re: Value Set question, split from thread "Validator Issue re. CWE Value Set Bindings"
40. Re: Value Set question, split from thread "Validator Issue re. CWE Value Set Bindings"
41. RE: Value Set question, split from thread "Validator Issue re. CWE Value Set Bindings"
42. Automatic Conference Call Reminder for Structured Documents

No comments: