Next: The Crisis in e-health standards II

Background

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