Ruminations on ‘design’ in e-health

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.

About wolandscat

I work on semantic architectures for interoperability of information systems. Much of my time is spent studying biomedical knowledge using methods from philosophy, particularly ontology and epistemology.
This entry was posted in Computing, Health Informatics and tagged , , . Bookmark the permalink.

4 Responses to Ruminations on ‘design’ in e-health

  1. Eric Browne says:


    I totally agree with your analysis.

    There’s another interesting perspective on Standards Committees recently posted by Glen Marshall at , wherein he says

    “Thus I expect that current activities to standardize healthcare IT, even within a narrow scope, will have an outcome that is similar to past outcomes. It’s only human. We are a small community, with many shared experiences and values. What we do is perform rituals to reaffirm our community, even if some people strongly desire innovation. We avoid disruptive change.”

    Perhaps it is an explanation of what you refer to as “the interference of the committee”?

  2. Tony Shannon says:

    Many thanks Tom,

    Good post, timely and provocative.
    Sounds like a good book by Brooks.

    This post material overlaps with one of those I put on my frectal blog on change and people.
    In my view this design by committee issue further reinforces the lack of understanding of complex versus complicated systems.
    Its a “draft” article so forgive if not the easiest to read but 4 patterns emerge from this Cynefin framework
    #Chaos- needs action and leadership , best provided by one person..
    #Complex- needs an understanding of the patterns within a system.. they say you need to have spent 10,000 hours to be able to do this. (eg the length of my specialist medical training etc). Usually works best if a few diverse minds tackle this.. usually a v small group.
    #Complicated.. this is very misunderstood….. its the Boeing 747 in my mind which is “complicated” but all wires and control levers are documented and understood. Not so in my Emergency Department.
    Too many folk in too many committees that are too large take this on and devise complicated solutions that dont fit with the work of the committee next door.
    However if these groups are given the right *tools* then they can devise related complicated solutions from complex patterns (eg the millions who reuse Linux Torvalds linux)
    #Simple.. the data entry stuff..or whatever.. some (eg Noad Raford of LSE) talk about 10hours training to be able to do this work.

    So I’m absolutely with the argument that “chaos” (eg in ehealth) needs leadership , “complex” patterns need solving by small group (ie reference models, key archetypes etc), these can be QA by larger “complicated” groups and if the right solution and tools are in place, their use will grow as some of the related work can be then delegated as simple tasks.

    For me its key that we all understand health as a complex not complicated system, which therefore demands ecosystem oriented solutions, which should include open standards and open source.

    Thanks again,


  3. Michael Osborne says:

    I would disagree with some of what Thomas says here. As a standards community, we are just constraining what is already a standard (HL7). We are taking what works in the community (eg. Pathology messaging) and documenting it, so that others can create non-ambiguous messages for others to consume. Sure we make mistakes, but eventually they get found out as other implementations are developed, and they are corrected. I have been involved in 4 primary healthcare implementations of HL7 v2.3.1 orders/results, and each time I do it I feed back to the IT14 group anything I find that needs improving and generally it gets included in the next version. This is the way standards organisations should work, and I’m sorry if your experiences have tarred us all with the same brush.

    • wolandscat says:

      What you say sounds right with respect to HL7v2 messaging – it is quite old/mature, a known quantity, not too complex. The comments in my post in as far as they apply to HL7 apply to HL7v3, not v2.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s