Interoperability Review: Why have Information Models in Health Informatics Standards?

I recently reviewed a number of standards which deployed the Unified Modeling Language (UML) models to … [to do what exactly?] I know the sentence stopped abruptly, but it accurately reflects my own state of puzzlement as to the purpose of such models within a standard. Given that I am currently the CEN convener of WGI which focuses upon information models, this unprecedented degree of doubt verges on the heretical.

Before going on I must state that this discussion has little to do with the quality of the documents I reviewed. That review process certainly did trigger this line of thought, but my concern, I think, is with something much more pervasive. I have used a Bertrand Russell quotation before to question the value of the electronic health record to patient care: "In all affairs it's a healthy thing now and then to hang a question mark on the things you have long taken for granted.” [1]. Here it serves me well as I seek to question the place and purpose of these UML models found in many Health Informatics standards today.

In recent years, the standards community has come under attack from all sides for a number of perceived and admittedly real problems. Of the many criticisms received, five stand out:

1. The time the process takes to complete vis a vis the rapid change in technology;
2. The duplication, over-lapping and contradictory outputs from standard development organisations (SDOs); and
3. The distance from the consumer.

To these three can be added two old chestnuts:

4. "The nice thing about standards is there are so many of them,” and

5. "When you’ve seen one implementation of standard 'x’, then you have just seen one implementation.”

To return then to my original question; what role do the models and the modeling play in standards and the standardization process? And a further question, do the models mitigate or contribute to these five substantive criticisms?

The role, I think, is currently unclear and as for the latter I think they do both. Modeling (specifically object-oriented and graphical variants) has had a long, established and even foundational role in Health (nee’ Medical) Informatics standardisation. It was introduced in 1986 by IEEE P1157 (Medix), pursued by HL7 in 1987, then by CEN TC251 in 1990 and then by ISO TC215 in 1998; Sadly Medix is no more, but all the other three SDOs have continued to place modeling at the centre of their work. The trend now is towards using UML in all our technical reports and specifications, and in that respect it has become a lingua franca for the international, multi-lingual community. With that particular point in mind, I shall address the five criticisms.

Criticism 1: Too long and thus too late

With respect to the long development of a standard, we should bear in mind that although the standardisation process is competitive it is also consensual. It is undoubtedly bureaucratic (not always in the pejorative sense). The CEN and ISO organisations operate in a similar way. Both SDOs are generic and, as their technical committee numbers of 200 plus imply, their constituencies are diverse and large. Their processes have been put in place to gain international consensus at each of the balloting stages and these have to be above reproach and as robust as possible in order to satisfy their member bodies who expect openness and fair play. This inevitably takes time and, to their credit, there are elements of quality along with safeguards that are inherent in the process and which improve the quality of a standard before it is published. Does the modeling delay matters? In the sense that it is often seen as an additional, time-consuming, and sometimes as an irrelevant step, then yes it does. As an alternative, graphical, visual aid to presentation, that is not natural language, it may be argued that it actually makes the process run smoother and faster. I am not aware of any formal studies that prove that point but I am prepared to believe it helps. However, it is worth while reflecting that the 'U' in the UML is for 'unified' not 'universal’[2], so despite the welcome aspect of a lingua franca to such an eclectic community it would be naïve to believe that it is understood by all people and at all times.

As for the relevance factor, the abstract nature of the models often mean that one can claim implementation independence and therefore achieve a measure of future proofing. There is a further claim that the models could be animated and be either directly executable or at the very least be used to generate code. Unfortunately, in this field we are not there yet and the relevance factor actually relates more to what the planned scope and objective of the standard is than to its techniques and methods for development and presentation.

Criticism 2: Conflicting outputs