Should an Organization like HL7 be Engaged in Building Standards?

A nice summary of problems with current approaches to standards development in the eHealth domain is presented here.

The author begins by pointing to the long-standing assumption

that we should rely on official standards bodies to standardise things, and indeed, our entire modern civilisation does rely on this. From the thickness of car-window glass (look carefully for the standards mark etched into the window next to you get in your car) to power voltage and frequency, to mobile phone and internet communication standards, the sanity of our world today relies on successful standardisation of every conceivable physical and electromagnetic phenomenon which comes into play when one object or person interacts with another.

He then goes on to point out that there is an abnormal situation in the eHealth domain, which consists in the fact that standards are being developed by official agencies, including HL7 (an "ansi-accredited standards developing organizations"). This is in contrast to what has been the normal situation elsewhere, where standards were initially developed by engineering organisations, such as telecommunications companies, IT companies, or universities and research networks, and became standards only after they had been not only specified, but also implemented and thoroughly tested. The author provides a variety of reasons why a committee process of the type employed by HL7 and similar standards organizations is an unsuitable approach for addressing the problems of semantic interoperability. The reasons include:

a consistent ecosystem of standards is not likely to emerge from multiple standards organisations, with significantly different rules, and cultures, and which are quite competitive;

the international standards organisations in the e-health area are large enough that even internally they generate inconsistent standards;

development of technical artefacts by committee is almost destined to fail;

good technical artefacts can only be developed by an engineering process (that is to say: requirements, analysis, design, implementation and validation – as old-style or agile as you like);

most standards in e-health are being developed without a sound model of the ecosystem, in other words, they are developed as ‘point-to-point’ specifications, or responses to specific problems, with no reference to an underlying design framework;
there is in general very little culture of implementation or testing – many e-health standards are issued untested;

there is little or no organisational commitment to maintenance, in the sense that software developers understand – i.e. if a bug is found, there should be a way to report it, and track its progress, and on the development side, the organisation should be capable of issuing new releases in a timely fashion (organisations that do do this always have two things you can find – an online version control repository and an online issue tracker);

timelines for delivery are notoriously unreliable;

the groups created for delivering a given work item typically do not contain people with the required engineering competence, but rather enthusiasts ...

I am pleased to see that the OBO (Open Biomedical Ontologies) Foundry, an initiative in which I am involved, has embraced an approach which avoids the majority of these problems in its attempt to create a standard set of semantically interoperable ontology resources to support biomedical research. Two principal marks of the OBO effort are 1. its striving for logical consistency and for non-redundancy even as the suite of involved ontologies grows, and 2. its commitment to thorough testing of all OBO artifacts and to careful peer review before ontologies are accredited for use by the OBO Foundry community.