The crisis in e-health standards

Next: The Crisis in e-health standards II


There is a serious problem in e-health today. The main need in e-health is to establish interoperability of various kinds: between systems, between software components, and across enterprises. The current catchphrase is ‘semantic interoperability’, generally meaning that information can be shared (between systems), aggregated (into a single standardised whole), and computed upon, in such a way that originally disparate information about, say a patient, can be safely analysed by a computer program. Achieving this is undeniably hard – I know from having spend 15 years of my life on it. Nevertheless, I know it is solvable. Technically there are many challenges, but also available solutions. It is the political dimension that is harder: this is a ‘commons’ problem, as is any interoperability problem, and it therefore requires the presence of organisations in the public space – usually governments and/or standards organisations. This is recognised, and many countries now have some kind of national ‘e-health programme’ which endeavours to define and promulgate (and possibly legislate) various standards and guidelines to encourage interoperability of health information systems (naturally, within privacy legislation).

The need

So far so good. However, e-health is a complicated space.  Those who know something about it know that it is like a large ecosystem, and as such requires an ecosystem of specifications (I will use this word rather than ‘standards’ for the moment, to avoid ambiguity about official status). There are many things that need to be agreed in some way, including:

  • messages that travel between systems, usually carrying process-related information, but also significant content, e.g. in the case of lab results;
  • documents shared between systems, more content-oriented, typically containing a more narrative style of information, e.g. a consultation note;
  • service interfaces, i.e. interfaces between large components of a system, particularly data repositories such as for EHRs and demographic information;
  • user interfaces – there is great interest in some level of standardisation of user interfaces, because health professionals travel around and between hospitals, and use many kinds of software – they need to be able to rely on the consistent meaning of what they see on the screen;
  • terminologies, used to identify agreed ‘concepts’ (such as diseases, procedures) within a semantic network of relationships (usually at least the IS-A relationship);
  • ontologies, properly scientific and formal descriptions of the domain, in the form of semantic nets; ontologies should encode the ‘truth rules’ for a domain, and can therefore be used to validate all other models purporting to express some domain-related fact, as well as for inferencing and analysis of data;
  • security and access control rules – agreed rules for using and sharing information among systems and individuals, according to various shared notions of ‘rights’;
  • governance and identification of artefacts, since sharing of information necessarily assumes a shared idea of what kind and granularity of items are available, and how to determine provenance and quality.

It is clear from the above list that the disciplines of software engineering, clinical medicine, ontological modelling, security, information management and quality control are all implicated. Experience has shown that numerous ‘standards’ are needed to make any realistic e-health environment function properly. The challenge has been to understand the structure of this specification / model space, since it is also clear that a simple linear list of (for example) message schemas won’t solve the problem.  As with any complex domain, there are various levels of specifications, from the very concrete (XML schemas for messages and documents, WSDL interface definitions), to the abstract (information models) to the foundational (ontologies, basic business rules). These various levels have significant dependence on each other. At the more concrete level, there may be many individual specifications or schemas of some kind – potentially as many as there are clinical concepts such as ‘blood pressure measurement’, ‘antenatal visit’ and so on.

The de jure standards ‘solution’

Now we can start to see the kind of problem we have on our hands. A long-standing assumption has been 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 time 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. In the ICT world, there are many standards used today, from basic character sets, to the standards governing data exchange and the internet. (There have also been famous failures, such as the ISO 7-level OSI network communications standards, but these do not concern us here).

So it would seem that creating standards for e-health should not be that hard – standards seem to work alright in other industries. Not so fast! One of the strange things occurring in e-health is that standards are being developed by the official agencies. Isn’t this normal? you say. Not really. Nearly all successful standards to date were initially developed by engineering organisations, such as telecommunications companies, IT companies, or universities and research networks; they became standards only after they have been not only specified, but implemented, and often commercialised. In other words, in most cases, the standard we have today was created from one or more industry (or academic or military) offerings in a near mature state. The role of the standards organisation was generally to match standards to requirements, and to try to broker compromises when there were competitors. Sometimes, the latter simply took place in the commercial world in a rather brutal fashion – Beta versus VHS being a famous example (Beta is supposed to have ‘lost’ in the public mind but in fact, it simply moved to where it was needed – the professional / studio environment); a more recent example being the DVD Blu-ray versus HDD format wars. Standards organisations usually had to devise some testing method, and define a set of compliance rules for the rest of industry to follow, once the standard had been agreed.

Back to e-health…although the e-health domain relies on numerous ‘underlying’ standards (basic IT standards, imaging standards, clinical guidelines and protocols and so on), the standards most keenly needed – describing the data, information, process, workflow and interchange / sharing rules – are not in fact being produced by the above approach. Instead, official standards organisations (ISO, CEN and the European national organisations, ASTM, HL7, OMG and others) have, in their e-health committees, become developers of standards themselves. The process being used today to a greater or lesser degree is that committees comprising individuals from various countries’ ‘delegations’ self-organise into groups that define their own ‘work items’ and then attempt to create them over the following months or years. Most countries send delegations to at least 2 international standards organisations, in addition to maintaining their national standards processes.

This is a manifestly unsuitable approach for many reasons, including:

  • for a start, 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 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); in the standards world, if a standard is issued (a process whose last stages can take 2 years), you can do  nothing other than wait 4-5 years for the next edition (by which time your patience may have been tried to the point where you have retired to explore the Himalayas or buy your own vineyard…);
  • 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, and possibly world experts in their domain…however, to be coldly objective, would you like me (an engineer) to help say the Royal College of Physicians develop new guidelines on paediatric oncology? I am enthusiastic for the cause – but I would hope that my total lack of competence in this area would prevent me being chosen for such work!
  • actual ‘work’ gets done both in peoples’ spare time, and at ‘working group’ meetings, where the composition of people in any given meeting is mostly dependent on who could come (those who could not might cite school holidays, national budget cuts, travel fatigue, or simply disaffection with progress).

Before I go further I will state that this criticism is in no way aimed at individuals. In fact I participated in standards activities myself from 1999-2004, and met many esteemed colleagues at such meetings. My point is that the process cannot work to generate the expected outcomes.

The crisis

This situation is paralysing national e-health programmes, and at least some parts of the health ICT industry (some elements are of course quite happy to continue with as little interoperability as possible). The problem is that national programmes need an ecosytem of mutually consistent standards, and what they get is mostly a mish-mash of relatively incoherent outputs, available on a completely uncontrolled time line, and with no discernable quality control. There are of course bright spots – it is not as if all e-health standards are useless, and some indeed have been very useful. But compared to what we might expect, the overall result is extremely poor. It is also preventing progress, as many nations simply wait for (possibly by magical means) some coherent agreement from the various bodies and committees, or at least a rapprochement between historically warring approaches.

It is hard to imagine that the current situation will bring any real success, no matter how long we wait. Almost none of the required conditions for success are present in the de jure standards approach to developing standards (remembering that they are in fact quite good at evaluating industry-originated standards proposals, and turning them into standards). To get an idea of what it would take to develop the required ecosystem of standards, we need to look at some precedents:

  • the IETF internet standards: there are 70 or so full standard RFCs in use, developed over 30 years by engineers in a university and industry context, all implemented and tested before release, all designed to be compatible with the previously existing body of RFCs;
  • the W3C XML standards: although I am no fan of XML, in fact the W3C have done a reasonable job of making a set of mutually (more or less) compatible specifications that are generally developed and tested by academic and industry groups before being released as standards. There is a heavily software development-oriented culture in the W3c that helps ensure artefacts are at least formally valid, and usually demonstrable in some kind of software.

What is clear from investigation of the above bodies, and others such as the OMG, as well as numerous open source efforts that a number of pre-requisites are needed to engineer an open (i.e. shared, ‘standardised’) ecosystem of specifications:

  • Coherence: all models and specifications are developed in a SINGLE FRAMEWORK (open source .orgs routinely succeed here);
  • Filtering: any de jure standard that is to be used is re-engineered to a form 100% consistent with existing specifications (this is heresy in the standards world, but only what is done by every single company trying to implement a paper standard containing ambiguities or errors);
  • Engineering development process: engineering analysis, design, implementation and validation process is used;
  • Maintenance: the mechanisms and organisational commitment for ongoing maintenance of the framework (open source .orgs are good at this as well);
  • Openness: the organisation’s requirements and outputs are always open to inspection;
  • Computable dissemination: use in industry should be via small number of solid implementations and/or formal expressions, not continual re-implementation of paper specifications;
  • Quality control: there must be some published means of assuring quality of the deliverables, that is in routine use, for example software-based testing and review.

Very few of these conditions are met by the use of formal standards organisations to develop standards in e-health.

Lessons for governments

I would suggest that national government e-health programmes take a good look at a) the importance of obtaining a solution to standards in e-health, b) their last 5 years’ expenditure on standards participation, and standards-based activities at home,  and c) the last say 10 years’ history of actual delivery from the official organisations. I see the following lessons:

  • ‘Choosing standards’ as a way of governments solving semantic interoperability is a fallacy – official standards in e-health are mostly incoherent;
  • The official standards ‘development process’ cannot generate the required outputs because of the committee approach;
  • Instead, an open source .org approach is needed to create meaningful ‘standards’;
  • Official standards bodies should be restricted to approving particular releases of particular specifications as having been quality-assured for use for a defined scope or purpose.

Where to from here?

We need to build one or more open ‘dot-orgs’ whose business it is to create and maintain the required ecosystem of specifications and models needed in e-health. Such organisations would resemble open source software organisations,  but with a specifications development and publishing capability. Required features would include:

  • Only standing committees should exist, for defining requirements, and for review purposes;
  • All other work should be done by technical project groups;
  • All IP should be developed in a single coherent technical framework, consisting of:
    • A published corpus of formal specifications
    • Software implementations
    • Other formal artefacts, e.g. schemas, models
    • Open source tools should be available for parsing, viewing and editing formal artefacts
    • If it is not formal, it does not compute!
  • Development environment including:
    • Version and release management tools
    • Online issue tracking
    • Wiki
  • Community environment including:
    • Website, mailing lists, wiki
  • Development done by recognised experts from industry and academia, organised into structured projects on the basis of professional competence;
  • There must be a clear line of accountability between ‘customers’ and the delivery organisation, involving requirements setting and delivery planning;
  • Funded by beneficiaries, i.e. governments, relevant health delivery and insurance organisations and industry via a board membership and governance structure.

In other words, we should be thinking of creating ‘open standards’ organisations. My own feeling from 5 years’ participation, and 10 years’ observation of the e-health standards situation is that the current impasse is not going to be resolved by more waiting, or more business-as-usual by the standards organisations. There is a huge amount of talent and solutions sitting around waiting to be used, and a massive problem to be solved. We just need to join the two together.

Here is a slideshow (PPT) about the e-health standards crisis.

Next: The Crisis in e-health standards II

Slide 29

Coherence: all models and specifications are developed in a SINGLE FRAMEWORK
Filtering: any de jure standard that is to be used is re-engineered to a form 100% consistent with existing specifications
Development paradigm: engineering analysis, design, implementation and validation process is used
Maintenance: the mechanisms and organisational commitment for ongoing maintenance of the framework

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 Health Informatics and tagged , , , , , . Bookmark the permalink.

13 Responses to The crisis in e-health standards

  1. Paul Roemer says:

    Very well thought. I believe the industry has underestimated the difficulty of attaining interoperability by several orders of magnitude. Hundreds of vendors, dozens of disparate standards, hundreds of Rhios and HIEs. Believing the current national roll-out approach will work borders on either naiveté or being irresponsible.

    The fact that their exists more than one standards committee means there are no standards.

    Here’s my take on a possible solution. Please comment.

  2. Hello Thomas (and Paul) –

    Great article, and IMHO an accurate capture of where we are. In line with Paul’s drive towards EHR mashup, we have been working on a new approach to health data, that allows mashups, real-time updates, and patient empowerment. Right now we are starting to push out some code and specs at – feel free to get in touch with me if interested.



  3. Interesting summary! You wouldn’t happen to recommend or be involved in any suitable .orgs or .orgs would you?

  4. Gunnar Klein says:

    Response to the “Crisis in e-health standards” by Tom Beale, 2009-09-17

    Despite being one of those silly persons that due to a personality disorder has continued for 17 years to struggle within the de jure standards world for eHealth that is so useless, I cannot escape agreeing with Tom on much of the description of the issues. Yes, interoperability in this field is hard and, as a total solution, far away. The specifications world is indeed messy. And I can feel embarrassed by some of the remarks on the weaknesses of the present results.

    However, I think the “crisis” is misguiding in a few ways.

    a) Technical development of complicated systems to support production of large parts of society (health is some 5-7 % of GDP) is not in general successfully carried out by well working open source groups (“.orgs”). The growth of both knowledge on “how to” and real implementations is far from a straight line. The evolution of a “solutions” as specifications and projects is as a rule messy and most of developments are blind alleys and wasted efforts. Is file sharing using MPEG4 building on Betamax? The same is of course true for development of clinical practice. I am pleased to learn that Tom is not planning to engage in paediatric oncology guideline development even if that could benefit from some input from good engineering, (eg. see paper by Rong Chen et al, Stud Health Technol Inform. 2009;150:653-7.) Medical Science and clinical practice is also not developed by but heavily influenced by both “de jure committees” and open groups but not according to the grand plan for progress. That was a failed strategy tried in certain countries but generally not used any more, certainly not in China the largest communist country. The examples so far of national eHealth programmes have not been very impressive as to cost-effectiveness. Agreed?

    b) Large scale deployment of complicated technology is based on a combination of meeting a need with a number of different integrated engineering results many of them based on years of specifications in the public domains, from de jure standards organisations and other sources plus of course skilful marketing and other commercial efforts.

    c) Health care and eHealth is very complex and we do not need THE solution from standards bodies nor “.orgs” (note that iso is actually .org as a domain). We need many and the standards organisations active in this field have helped people to create many useful solutions that are in use. But of course we could ask for better quality in specifications work including maintenance and let us discuss how we can achieve that. Concretely, not in a general abstract way. I doubt that creating yet another organisation is the solution.

    Gunnar O Klein now a practising physician
    Chair of CEN/TC 251 1997-2006, founder of ISO/TC 215 and still chairman of the ehealth standardization co-ordinaton group which has with little success tried to join forces between WHO, ITU, ISO, CEN, IEEE, HL7, GS1, DICOM, CDISC and IHTSDO.

    • wolandscat says:

      Gunnar, I take your points on board. I should clarify what I meant by calling the solution a ‘.org’ – I actually mean a new kind of organisation that houses a self-consistent set of specifications, uses software as a means of validating the specifications, and uses some of the other well-known ‘.org’ features, such as community mailing lists, wiki, version control, issue tracking and so on, to provide maintenance. The official standards organisations (as you point out they are literally also ‘.orgs’) fail to do this, and the open source software developers certainly do. The former suffer from no/limited internal coherence in their specifications, no maintenance path, and weak accountability to stakeholders, while the latter don’t even tackle the problem of interoperability.

      If we look around today, there are at least 3 other other organisations (all .orgs 😉 that have broken the current mould in certain ways: 1) IHE – the existence of IHE indicates the problem of consistency within and across SDOs; 2) IHTSDO – the structure of this SDO has an international board of government stakeholders, solving the accountability in at least some measure, and 3), which has tried to build a set of specifications which are internally consistent, and also validated in software (it is weak on accountability though). The last of these of course is the one I have been most involved in (critics of the main post here will accuse me of writing a critique that suggests that openEHR is the solution, but that would be misunderstand the causal order of things: is the result of years spent discovering the problems I have documented in the main post.)

      In the end, the following observations seem to be incontrovertibly true:
      a) formal SDOs don’t have a commitment to a self-consistent technical framework, never mind being consistent with the outputs of other SDOs
      b) the committee process of formal SDOs does not lead to the creation of new technical artefacts of quality
      c) formal SDOs have no maintenance plan other than a 4-year wait

      To those such as Gunnar who have struggled with the impossibilities of the process and the recalcitrance of many human beings on the way, I salute you. But I don’t think it is the way of the future in e-health.

  5. This is the best description I have read so far of the current state of affairs and why close to nothing has been delivered an unimaginable pile of money spent later. Also time slips much to fast. Defining the problems and criticism on what has been not done right is very exact and well put IHMO. We, a creative “biblical David”, in this environment have argued quite a lot along the same lines, but never managed to capture a more complete picture as you have done here. Thank you.

    But, when it comes to finding the remedies I can not agree to all. In the article I think some about the role of open source and .org is an after construction of history. Actual inventions or creation of new designs have yet to be developed in such an environment. Open source is so far a means of marketing to other developers and to the academic world. Such orgs. may be very good at governing and extending standards, but that comes well after the engineering development process has completed its first couple of loops. It is not a prerequisite.

  6. wolandscat says:

    With respect to the solution, I did not mean to imply that open source was the solution (I don’t think it is); I think that an open organisation with some of the attributes of the open source organisations is needed. But unlike open source orgs, it needs to have a focussed engineering team(s), not a ‘bazaar’. As it happens I don’t think that open source is nearly as important as open data standards and open interface (service) specifications. But reference software for standards needs to be available in source form for obvious reasons.

  7. Gerard Freriks says:

    Almost 14 years of semantic interoperability activity in HL7, CEN and ISO as formal standardisation bodies has learned me several things.
    -1- When we want to make semantic interoperability a commodity we need to realise that this is daunting. Many will have to play their natural role.
    -2- Like language we need firm stable agreements with respect to the character set, the language and the language syntax. For the words we need regularly updated versions of the dictionaries. Finally we need local agreements of what to store, retrieve and exchange that can be changed any moment in time.
    In other words we need various types of standards and organisations. Some producing stable components and other being very agile. This determines the type of organisation, it working mechanism, its publishing mechanism and business model.
    In general, commodity means that we need an infrastructure where stable and agile components plus governance are standardised in some way.
    -3- To often actors in this field try to play all standardisation roles and types of organisation at the same time. It is obvious that this will lead to problems.
    Or in other words extend their role to an unnatural one.
    -4- Without (national) legal regulations it is impossible to create a functioning stable infrastructure. Stable standards produced by CEN/ISO (like EN13606 EHRcom, EN13940 HISA) can play a role in legislation creating the free movement of goods, people, money and services in Europe.
    Legislation should not be extended to the agile, non-stable parts, other (new) organisations will be needed to handle the agile parts (archetypes/templates, coding systems and ontologies)
    -5- For things to work we need to have all agreements, standards, managed in a stable way and be real publicly owned entities.

  8. Pingback: iNTERFACEWARE

  9. Pingback: Should an Organization like HL7 be Engaged in Building Standards?

  10. Pingback: Should an Organization like HL7 be Engaged in Building Standards? | HL7 Blog

  11. Pingback: Ruminations on ‘design’ in e-health « Woland's cat

  12. Pingback: The standards setting processes are broken and no one seems to care - Australian Hospital & Healthcare

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