On Problems with HL7 Documentation and with HL7 XML

I respond below to two critical comments from Kevin Coonan which, following the earlier comments from Graham Grieve, point to a welcome new trend for those submitting comments to this blog, in that they are submitted non-anonymously. (Comments to HL7 Watch are moderated, but all signed comments are passed through automatically.)

Comment 1 (to HL7 RIM: still no coherent way to track concerns):

KC: I too wish to echo's Grahame concern that you seem quite liberal in quoting comments out of context and seem all to eager to find the most minute publication error as further evidence to support your "interesting" theory about how HL7 works or what you can do with the organizations work products.

BS: I am afraid I do not yet have a theory about how HL7 works, because, like many others, I do not understand the HL7 documentation. This is in part because it is unclear -- a problem which HL7 has already acknowledged and is itself attempting to ameliorate -- but in part, and more seriously, because it is inconsistent. Gunther Schadow, Charlie Mead and Mead Walker defend this state of affairs by arguing that:

As different people edit parts of the specification, inconsistencies in form and quality may emerge; as some ambiguities are clarified, other previous systematic ideas may be corrupted; and well meant glossary entries may cause confusion. Sometimes irreconcilably opposed conceptualizations may coexist and one resorts to vague or ambiguous language in the interest of moving forward in areas where parties can not agree.

Some would argue, however, that this is a state of affairs that raises questions for an organization that is proposing standards for information exchange, especially in a critical domain such as health care, and especially in a context in which large government investments depend on making the right sorts of standards decisions.

KC: While you at times do happen upon a legitimate concern about HL7, you do a great disservice to those who read your blog by misconstruing ongoing self critique by HL7, and discussion of very difficult technical issues as flaws.

BS: Such self-critique is of course an entirely positive thing. It would be a flaw in a system only if actual errors or inconsistencies or unclarities or ambiguities identified through such critique would be ignored at the stage where the artifacts in question become normative.

KC: Should more people read (or care) what you publish, it could have a detrimental effect by stiffing the public discourse which marks a healthy SDO.

BS: Good point. I hereby commit to closing down this blog just as soon as there is evidence that it is succeeding in becoming influential.

KC: Since you are such an ardent lurker of the lists, perhaps you might wish to attend some of the frequent tutorials to give you a better working knowledge of HL7 methods and models, and then consider directly contributing to the ongoing efforts to find workable solutions.

BS: I devote a lot of time to the OBO Foundry standards efforts (we also organize many interesting tutorials). The developers of all the ontologies within the Foundry recognize the value of criticism from outsiders, since outsiders are able to provide a fresh perspective -- for example by exposing ways in which our documentation falls short. Science, I believe, makes progress only to the degree that it maintains a healthy culture of criticism from outsiders.

Comment 2 (to Big HIT) (responding to the identification of major problems with HL7 XML):
KC: HL7 XML is standard. It follows published W3C standards, which as far as most are concerned are the standards about XML which matter.
BS: Correct. But not all standards are equally good, I'm afraid. See, as concerns HL7 XML, the arguments here (summarized already here).
KC: HL7 itself is a ANSI SDO, and anything that HL7 publishes as normative BY DEFINITION is a standard.
BS: An ANSI standard, yes; all the more reason, therefore, to ensure that everything is checked very carefully before publication as normative, for example to ensure consistency.
KC: Finally, HL7 contributes, collaborates and uses the same ISO standard (21090) for data types, which is by-and-large the XML which makes up "HL7 XML."
BS: Unfortunately most HL7v2 and HL7v3 message standards do not follow this ISO standard. Moreover 21090 is not a full ISO standard. It is in the DIS-stage and therefore under development: http://www.iso.org/iso/catalogue_detail.htm?csnumber=35646 [See update below]
KC: Please, when you make statements such as that, you should constrain yourself to the facts, and not make such invalid and irresponsible statements.
BS: I hope, with respect, that we are both doing our best to confine ourselves to the facts.

Update August 2011: http://www.iso.org/iso/catalogue_detail.htm?csnumber=35646 now published as an ISO standard.