Friday, September 07, 2007

Normativity, Completeness and Flexibility

As we have argued at some length, there is a fundamental incompatibility between the claims made on behalf of HL7 as "the data standard for biomedical informatics" and the need for openness to new discoveries that lies at the heart of the scientific method. To repeat: HL7 V2 is an in some ways impressively successful tool for supporting messaging between healthcare institutions, but with one central flaw: it did not prevent the proliferation of local dialects. HL7 V3 was born to overcome this flaw, effectively by removing the possibility of optionality in the formulation of messages, by imposing a 'normative' set of coding options from which all messages must be derived through combination. And it does not work:

Yes - it is possible and most of the information is available, it is just not as easy for implementers to find and use as it would be if things were optimal. From what is in the repository, it sure looks like someone intended to put in a definitive list, but it never got completed.

There are some problems, though, as Rene has pointed out: there exists no definitive list of all Trigger Events or Interactions. We could generate one for those that are explicitly defined in the normative ballot, but then it would produce a different kind of problem for implementers: the supplied table (value set) would be incomplete, even though it would be presented as complete. I am trying to start a conversation about whether we need something to indicate that a value set for the normative ballot material is known to be incomplete and is not intended to be used 'as is', but is intended to be extended. Other than creating a new value set and redefining the binding for a realm, we don't have other machinery to do this with (to my knowledge). This tells me that either we need to describe and document this for implementers, or we need to explicitly assert the value sets as 'examples' or
a 'starter set'. Which means that they would NOT be bound in the universal realm, and would not be used in strict conformance.

There are a lot of loose gears floating around in the machinery from my viewpoint. I don't know how an implementer can find all the reference material and necessary vocabulary to actually sit down and build an implementation prescriptively based on what we have currently. There is a lot of stuff that is referenced in the normative sections that is not normative or not complete, yet not erroneous. This is very confusing to me, and I don't really know what the right answer is.


No comments: