I have often bemoaned the state of standards for the e-health sector. Earlier posts provide details. The main argument is that the key specifications the sector needs are for interoperable data, information and knowledge, but that the main approach to getting these is via standards agencies, whose processes almost guarantee failure. Hence the ‘standards crisis’ in health informatics. The failure is not innate in standards agencies as such; it is just that standards agency committees in the e-health sector are doing the wrong thing. They are acting as de facto R&D fora rather than as a choosing mechanism on proven designs from industry. In my view (and experience) this is because among the members and leaders of those committees are almost no engineers, i.e. people who understand a) how standards actually work in other industries and b) that design is an essential element of what is being standardised. The consequence of the situation in e-health standards is ‘design-by-committee’.

Why doesn’t design by committee work? What is ‘design’ in fact? My own contention has always been that design is in no way a consensus process, nor does it involve large numbers of people. It is a creative, abstract mental process, in which a response to a conceptualisation of the problem at hand is developed. The design output should be elegant, comprehensive, and robust (there are parallels with the nature of ‘theories’ here, and it is correct in my view to consider good designs as theories). It usually references existing paradigm(s) (e.g. the use of a syntax parsing approach) and may even invent new ones. Such a process cannot be performed by separate mental entities. It could be performed by separate people, but only acting as one … this means they have to spend some time in the same room. Where a team of designers are involved, each must have in his own mind the same design concept as the others. Even in this situation, there is almost always a single person responsible for generating the core design concept, with others acting as a kind of ‘senate’ to the key person. Without this there can be no coherence.

Fred Brooks in his recent book The Design of Design makes the following statement (ch 19, p239) [emphasis mine]:

Since conceptual integrity is the most important attribute of a great design, and since that comes from one or a few minds working uno animo, the wise manager boldly entrusts each design task to a chief designer.

Accompanying this is the following end-note:

The British Deputy Prime Minister sought from the Royal Academy of Engineering a report on how to make rail travel safer. The RAE delegated the task to a committee of only one person: its President, Sir David Davies. The report was done in record time and is crisp and forthright, rich with concrete recommendations[Davies, 2000].

Earlier on (Ch 19, p235) he lists some of the reasons why consensus stifles great design. One of them deserves to be understood by standards people:

Finally, consensus process starve innovative design by eating the resource. Consensus building takes meetings, lots of meetings. Meetings take time, lots of time. Great designers are few and far between; their time is exceedingly precious.

So what has gone wrong in e-health? The people who turn up to standards meetings generally understand a lot about the problem space, and often include some of the key people from the sector. There is no lack of intelligence or skills here – indeed many are trail-blazing doctors, and champions of innovation. Unfortunately, what most do not think about is the fact that an e-health standard is a technical artefact, and all good technical artefacts require design. Somehow they assume that the standards committee whose meetings they attend will ‘make it happen’. What happens in the e-health standards committees is generally one of the following:

• the required artefact is evolved in camera, i.e. actually within meetings and the follow-up email discussions. There are usually no professional designers present at all, and nothing resembling a design process;
• the required artefact is solicited from someone who is a designer or software developer, but who is constrained to work within the committee process so that what might otherwise have been a reasoned response to a clearly described problem is so compromised by the interference of the committee in both the problem description and the artefact under development, that it cannot help but suffer from the same problems as standards produced by the method above.

Following this, drafts are published, review comments are received, and the proposed alterations determined either by voting (again in a committee room), or by imperial fiat of a core group, typically not including any engineers (for those who think that my use of the word ‘engineer’ is in some way elitist… well it is, in some way. Next time you have a heart attack / battle with cancer / other major medical crisis, please consider whether you would like a qualified physician (i.e. a member of an elite) to operate on you, or an amateur from the street who read a book on biology. See also comments from software industry experts quoted from my entry on FOSE 2000).

In my posts on the standard crisis, I proposed some arguably complicated solutions to the situation. But I should have taken a step back, and identified the underlying problem, which is: the lack of a single entity tasked with producing a single industry-wide framework for managing health information and knowledge. Why only one? The same reason we don’t have two kinds of internet, and we don’t have two parallel rail networks. (We do still have (very stupid) wars for mobile phone transmission and digital cabling, but at least all of the competitors work!). I.e. we cannot afford it. In the health ICT industry, the large vendors cannot perform this task because it is inimical to their existence: they survive by secret data formats and product lock-in. Cross-enterprise communications is not what they do. In absence of an industry actor to take on the job, the standards committees have morphed from talking shops into producers of the required standards. Unfortunately, due to the problems described above, the outputs are of very low quality.

So we need an industry actor that a) understands the ‘main problem’ (interoperability) b) involves qualified software & systems engineers and c) understands and supports a proper design process. Then we have a chance of success. Not before.

[Davies, 2000] Davies, Sir David [2000]. Automatic Train Protection for the Railway Network in Britain: A study; Report to the Deputy Prime Minister. London: Royal Academy of Engineering.