Stef et al,
In response to Stef's plea for others' opinions, I'd like to add my voice to Tom's concerns.
I certainly believe that the whole ISO process with respect to health informatics standards is deeply flawed. As Grahame implies with the datatypes standard, the process is politically driven and compromises in modelling, engineering, safety, implementability inevitably occur. The question is how significant are these compromises and what effect will they have on the evolution of e-health?
It is highly unlikely that we would have an ISO standard for "Health Informatics - Harmonized data types for information interchange" without the monumental effort of Grahame Grieve in producing and managing the draft. However, it is, first and foremost, an HL7 flavoured standard. The most recent draft I have seen is, according to its forward, "a shared document between Health Level Seven (HL7) and ISO". ISO 21090 is undoubtedly complex. One has to question the value of an international standard, if it is so complex that it has to be 'profiled' by different organisations before it can be used. By whom, for what purposes, and by what processes, will such profiling be managed?
ISO 21090 suffers some of the significant flaws that permeate much of HL7 specifications. Tom has already cited the peculiar inheritance hierarchy amongst others. Another engineering flaw is the pervasive use of cryptic, often ad hoc enumerations. Even the names of the types wouldn't pass muster in most quality engineering schools. Names like ENP, HXIT, CO, EN, EN.TN, CD.CV, URG are simply inexcusable. Levels of indirection never aid readability, and lead to difficulty in implementation and testing.
It is not necessarily sensible to compare openEHR datatypes with ISO 21090. They are designed for different purposes. openEHR datatypes underpin openEHR's reference implementation and archetype object models for building electronic health record software and so can be augmented by these additional artefacts, as described below. The ISO datatypes should be able to stand on their own in a diverse range of implementation environments. This is a much harder task, and bumps up against fundamental principles of information exchange, whereby the assumptions of participating systems need to be carefully considered. Contraints and constraint mechanisms are pivotal here.
A datatype embodies the "agreed" set of values and operations pertaining to that type. If an item of received data "211414" has been denoted to be of type integer, then the receiving system "knows" how to process it, and will process it differently than if it had been denoted as a date ( AKA TS.DATE in HL7/ISO/DIS 21090 HI-HDTII ). Healthcare includes a very rich vocabulary, and text-based value sets are common in information exchange. A datatype for coded text, say, needs to convey the agreed set of values of that type. Let's firstly consider values for "severity of adverse reaction to medication". Ideally, both a sending and a receiving system needs to agree on the set of values - and may behave sub-optimally if one system uses the set { "undetectable", "mild", "moderate" } and the other uses the set { "mild", "moderate", "severe", "extreme", "almost inevitably fatal" } , even if these values all came from the same terminology. In other words, the sending and receiving system are not actually using the same datatypes in this case.
How do we deal with this in real systems? The United Kingdom's Connecting for Health program has addressed this in their HL7 V3 - based models by carrying the constraint within the datatype - in the coding scheme's identifier. So rather than say the values come from some specific version of SNOMED CT, they constrain the values to a specific subset using a Refset Identifier. And this can be carried in instance data.
Now whilst ISO 21090 is capable of constraining text-based value sets, such constraints are often done by other means - particularly through conformance statements in non-computable documents, most notably HL7 CDA Implementation Guides. We are seeing plenty of this in the US, as a result of their Meaningful Use provisions. In these cases, the datatype does not necessarily carry the constraint. It almost invariably doesn't. This means that in such transactions, the receiving system has no way of knowing the true datatype - i.e. the set of values - for each such data item. The only way for such constraints to be known to the receiving system is through access to HL7 templates - thus violating THE principal tenet of HL7's RIM-based information exchange paradigm.
This leads on to one of William Goosen's favourite topics - that of Coded Ordinals. These have been introduced in ISO 21090 to meet the needs, often encountered in patient assessment forms, whereby weights are given to descriptive phrases to indicate the scope of functionality a patient has to perform, say, activities of daily living (e.g. Barthel Index). The weights can be used to derive an accumulated score for a collection of individual activities. Unfortunately, ISO 21090 can't actually provide for this use case via the CO ( that's code for Coded Ordinal ) datatype, because it has no way of denoting the set of allowed values. Such a set might look like
[ { 0 , "unable"}, { 5, "needs help (verbal, physical, carrying aid" }, {10, "independent"}]
i.e. a set of pairs of weights and phrases. A coded ordinal only describes one value, not the set of permissable values! Now, of course it would be possible to specify these sorts of sets, and to publish them for use in clinical systems and information exchange. My point is that ISO 21090 doesn't support such a type and there currently is not a mechanism for this within HL7 - the primary standard for communicating clinical information. Even after all these years! I'd like to know how William, for one, hopes to solve this problem? Perhaps Ed Hammond has a solution in mind?
So I contend that ISO 21090 cannot solve the typing problem on it's own. Other components are required. And this questions (and always has questioned) the scope of an ISO standard.
One of the many beauties of openEHR is that it long ago recognised the need for a computable constraint mechanism that can help solve these problems. It not only recognised the need, but it has produced excellent specifications that marry datatypes, an information model, a constraint-based archetype object model, and a companion syntax language(ADL) for archetype serialisation. And particularly to Tom Beale's credit, it did so through a well-engineered process that has produced a set of coherent, implementable artefacts for which the health informatics community should be immensely grateful. And it did so openly and for free to the community.
People who question the quality, safety, implementability, suitability of clinical information artefacts should never be characterised as merely "taking broadsides" at another organisation, whoever that may be. There are far too few people of ability and commitment for that . Their skills and commitment are sorely needed. The others can go off and sit in their committees to compromise/compromize and harmonise/harmonize.
- eric
