Prev: The crisis in e-health standards
Next: The crisis in e-health standards IIa

In my last post I made three basic points:

1. that the committee-based process used by official standards organisations is not designed to be used for standards development and will not generate the required outcomes in e-health;
2. that the process of  ‘choosing standards’ by governments (or anyone else) will not result in an integrated set of specifications on which widespread e-health interoperability can be based.
3. a new way of producing standards for e-health is needed.

Although for most engineering and other technical people, these points are obvious, it is nevertheless reasonable to present some evidence.

On ‘development’ versus ‘solicitation’

From my personal knowledge of the last 10 years’ of standards activities in HL7 and CEN TC251 (including direct involvement over 5 years), it was clear that the mode of development was mostly ‘in-house’. Let’s look at HL7 first: it has produced v3 specifications (RIM, data types, message refinement methodology), CDA, vocabularies, an EHR ‘functional specification’, and more recently a services approach. Nearly all of this production has occurred within a committee environment, often by people with excellent domain knowledge, but also often with limited engineering skills. The same can also be said of the work done in CEN TC251, which has produced EN13606, HISA, EN13940 among many others. Likewise, in ISO TC 215, even though there is little de novo development, the process of choosing standards to fast-track into ISO also produces incoherence (but now with standards numbers attached) – this is also because of weak understanding of the technical consequences.

I want to be sure readers here do not mistake these statements for any kind of criticism of individuals. When I say ‘limited engineering skills’ here, I mean particularly people who have not worked in engineering contexts in which not only the artefacts being currently elaborated are intimately understood, but also the long term consequences of those artefact types are understood. Consequences include: costs of implementation, costs of maintenance, resilience to changed requirements, usability, likely performance characteristics, and so on. Not to mention that professional developers know the main patterns and design paradigms of their domain.  In software, only people with experience of the whole engineering cycle can look at (say) UML models and have a feel for a) the quality of the model with respect to known design patterns, and b) the forward consequences. The senior software developers and engineers in companies do this every day for a living, and as part of the process, very quickly discard non-viable approaches. This is not happening in e-health standards development.

Just consider how weak someone like myself (an engineer with a basic knowledge of human physiology, biology, and some aspects of clinical practice, due to study and access to medical colleagues – but no professional medical training or experience) would be trying to judge what to do with a young patient presenting with what appears to be symptoms of schizophrenia. My very limited knowledge of the subject at hand (schizophrenia and other mental health issues) could easily lead me to spend a lot of time thinking about how to treat the patient for today’s problem. But any professional clinician is quite likely to a) be much more careful with the diagnosis, widening the investigation to family and social  environments and b) think very carefully about the forward consequences of certain kinds of management on the family and social network. In other words, a professional will use his experience and formal training to partially focus on the future, and work backwards to help decide what kind of intervention plan makes sense, and how much effort to put into correct diagnosis. This is like a chess player being able to see 8 moves ahead; you can do it in your own area of expertise, but not in other fields.

The problem in e-health even manifests itself with people who have knowledge of one part of the ecosystem (say terminology) but not another (say software development). It is very easy for such people to come up with brilliant solutions in their own area but also to propose things that software people know just won’t work (e.g. because of querying performance). The complex ecosystem required for e-health means that even the so-called technical experts can easily fall prey to this  ‘illusion of expert knowledge’.

The consequences of people without engineering development experience trying to create engineering artefacts can easily be seen in the current e-health standards: weak or even incorrect design paradigms, ‘bugs’, poor implementability, over-complexity, and often poor fitness for purpose (i.e. incorrect mapping of solution to requirements). These statements will no doubt seem very unfair to the many dedicated people who have spent years in many cases trying to perfect the many standards in e-health. I feel very sympathetic, but unfortunately it doesn’t change the facts: from the stakeholder point of view, the result is a series of mostly weak, mutually incoherent specifications.

The lesson here is this: technical standards (and all standards are technical in the sense that they are formal and have to be engineered into some real world product, like software or a terminology) should not be developed ‘in-house’ by standards organisations, but should instead be developed in a professional engineering-oriented environment. This need is all the more acute because we are talking about a large ecosystem of standards, easily rivalling the W3C or IETF examples I gave in my former post.

On the results of ‘choosing standards’

Some countries have had an active e-health programme for nearly 10 years, and certainly in the last 5 years, many OECD countries have been actively spending money at a federal level, including the UK, Netherlands, Finland, Sweden, Denmark, Norway, Australia, and Canada, with various efforts in many other countries. Many of these countries’ programmes have lost time ‘waiting for standards’ as well as ‘choosing standards’ and ‘struggling with standards’. These experiences are so common we have stopped even imagining it could be any other way. It would be a long (and possibly far more controversial!) post indeed to provide a summary of what has happened in these national programmes to date. One thing that has been clear however is that the standards on offer have been very far from providing the solution sought after; if they had, we would have a clear agreement across some countries at least as to what constituted the ideal reference set of standards and models. Instead, there is little commonality, and no clear commitment to any de jure standard. Indeed, IHE (see below), CCR and others are appearing to fill the gap.

Other evidence: the new wave

There are various organisations and projects whose very existence is evidence for the incoherence of standards.

Integrating the Healthcare Enterprise (IHE)

This presentation is as good a statement as any of IHE’s raison d’être and modus operandi. From slide 4 (my italics):

• IHE: A common framework for harmonizing and implementing multiple standards
  • Application-to-application
  • System-to-system
  • Setting-to-setting
• Enables seamless health information movement within and between enterprises, regions, nations

• Promotes unbiased selection and coordinated use of established healthcare and IT standards to address specific clinical needs.

On the following slide, IHE’s point of view about today’s standards (mirroring more or less my own):

Standards are:

• Foundational – to interoperability and communications
• Broad – varying interpretations and implementations
• Plentiful – often redundant or disjointed
• Focused – standards implementation guides focus only on a single standard, may not consider relationships between standards domains

IHE started life in 1997 making DICOM work with HL7v2 messages; since both of these standards were well-scoped and worked reasonably well for their main use cases (images and lab requests / results respectively), the combination worked. IHE has since gone much further. It differs in at least 3 key ways from the official standards bodies.

• Firstly, it has enlisted stakeholder organisations as sponsors, including many US professional colleges of medicine.
• Secondly, its modus operandi is oriented to integrating existing standards (by creating ‘profiles’, each based on a use case), including filling up missing gaps with new specifications.
• Thirdly, it validates its outputs by well-publicised ‘Connectathons’ in which various profiles are shown working.

Some of its well known ‘profiles’ include Patient Demographic Query (PDQ) and Patient Identifier cross-referencing (PIX), there are around 20 currently (see technical specifications). So far, IHE sounds like nirvana: an organisation that has not only correctly diagnosed the problem, but involved stakeholders directly, meaning there is a line of accountability (one of the necessary conditions I propose for reformed standards building). Does IHE tick the other boxes? We can certainly say that some of its outputs are not only useful, but in real use; this alone proves that there is a problem and that solutions are needed.

However there is a major weak point in IHE. Because it creates meta-specifications to integrate existing (sometimes very fine-grained) pieces of standards, and is largely content-agnostic, it has both a very limited handle on information semantics, and no real coherent underlying ecosystem of basic concepts. It is essentially a top-down set of meta-specifications sitting over the chaos below. For logistical use cases, like ‘find me the servers containing any information on patient 123 from the last 6 months’, it works well. For any semantic processing of the information however, it is extremely limited, because it treats most content as being opaque, and works only with meta-data extracted from content.

In the end therefore, I suggest while it is adding a lot of value in the realm of system integration/routing services, but will not provide much in the way of semantic interoperability – in other words, it helps find and share data, but not aggregate it or process it. My other concern is that the specifications are (necessarily) quite complex, not always fully formal, and include endless cross-references to different standards.

International Health Terminology Standards Development Organisation (IHTSDO)

IHTSDO is a much more recent organisation, and exists primarily to manage the Snomed-CT terminology, previously owned by the College of American Pathologists. The key noteworthy aspect of IHTSDO within the context of the discussion here is that it has established a structure in which the key stakeholders (governments) are on the board and also providing funds, meaning that it has solved both the unaccountability and funding problems. This is a major advantage.  Since IHTSDO has been effectively operational since 2007 only, it is early days yet.  However I can say (from personal involvement) that the signs are positive that many of the problems of previous standards organisations are likely to be dealt with: the work is done by experts and there are good software tools. The only real limitation of IHTSDO is that its scope is terminology, and therefore does not really address other aspects of the ecosystem. Integration with information and service standards will therefore be challenges for the future.

Healthcare Information Technology Standards Panel (HITSP)

HITSP was founded in 2005 and is funded by the US department of Health and Human Services. From its website: [HITSP] is a cooperative partnership between the public and private sectors. The Panel was formed for the purpose of harmonizing and integrating standards that will meet clinical and business needs for sharing information among organizations and systems. Sound familiar? I will admit at the outset I personally don’t have experience in HITSP as an organisation, so will no doubt be upbraided by readers of this post for errors here. My current understanding is that it is somewhat like IHE, although with more focus on clinical study information and systems, rather than point of care systems (but: see the home page). It also assumes IHE’s standards, and mixes and matches parts or all of IHE profiles as needed by HITSP use cases – in this sense it is a ‘meta-meta-standards organisation’. Most of HITSP specifications are wrappings of IHE and other US standards such as HL7, ASTM etc, for specific use cases.

In terms of potential for solving the e-health standards problem, HITSP has the same weak point as IHE: not having any underlying coherent technical framework,  but being instead a set of profiles that try to integrate parts of existing standards. No doubt it satisfies a similar general business case: without its existence, today’s sea of official standards would be completely unusable and every use case would be solved differently be every implementer (an NxM mess), which of course is far less preferable.  The lack of a coherent ecosystem means for example that there is no clear picture of how to deal with terminology or service interfaces, only a per-use case view.

openEHR Foundation (openEHR.org)

The openEHR Foundation is an organisation that has taken a different approach to the challenge of specifying an e-health interoperability ecosystem, and it is the organisation I have spent significant time on in the last 8 years (I am currently the chair of the Architecture Review Board). The Foundation’s approach has been to build a de novo open set of  open specifications, based on the evidence and work of the past, including many EU-funded projects (see here for a simple exposition of the technical work). Its specifications include information models for concepts ranging from data types to ‘EHR’. It also defines a language for querying, and a whole knowledge modelling framework based on a concept called ‘archetypes’ (due to which fact it has a much greater direct involvement of clinical professionals in ‘modelling’ activities than other comparable organisations). Service models are starting to appear. It is not my purpose here to further describe its technical approach, but to point out that, for its growing community, including various national governments, having a 100% internally consistent technical framework has been crucial to solving some of the ‘real’ problems of semantic interoperability, namely, modelling clinical content and process in a flexible way that integrates with terminology, so that information can actually be processed on a semantic basis by all kinds of other applications, such as decision support, business intelligence applications and personal health record systems.

Critics of openEHR often point out that ‘it is not a standards organisation’, and that therefore it can’t readily be adopted by governments or other jurisdictional agencies. From a technical standpoint, we have already seen that this is likely to be unimportant, although in terms of formal governance (which is a reasonable requirement of any user of standards on which, say, a national health ICT environment might be based), it is undoubtedly weaker than it should be.

In terms of my ‘recipe for an ideal organisation’ in the last post, openEHR’s strong points include: an engineering process basis for standards development; fully formal and computable specifications; software-based testing and validation; a vision and mechanisms for maintenance similar to an open source software organisation (proper version control, release management, issue tracking). In terms of dealing with existing standards, the approach is simple: map it or re-engineer it. This rather uncompromising stance might not be welcomed by some, but by those stakeholders who seek not just standards, but standards that work, it is certainly an advantage. Notwithstanding this, the organisation will make the best use possible of  de jure standards in continuing to build its platform. Its weakest points are probably lack of direct accountability (since it does not have a board like IHTSDO, or other similar ‘buy-in’ mechamism) and consequently funding.

Can it solve everything? This is almost a rhetorical question. openEHR is a generalised framework, rather than being based on specific use cases. So in contrast to IHE for example, it is less clear on first sight whether it answers any given use case. There are certainly cross enterprise use cases where IHE in fact provides more or less what is needed (e.g. patient id cross-indexing, notification of document availability etc), that openEHR does not try to address; such specifications are likely to be ideal candidates for direct integration into the openEHR platform. Other core use cases to do with EHR, clinical process, distributed sharing and merging are clearly addressed. Only in the longer term will we see how the platform progresses and what its weak points turn out to be.

Conclusions (so far)

What does the above teach us? I would suggest that the evidence is clear for my points at the top of the post: developing standards inside SDOs doesn’t work; choosing a selection of standards to create a generalised ecosystem doesn’t work, although carefully engineered ‘profiles’ can be made to work for specific use cases. From the above we can see some of the features needed of an organisation(s) that can try to solve the problem of a standards ecosystem for e-health.

To my many colleagues in this field, I will simply finish this post with a comment an Australian colleague made some years ago, when he told me he had stopped putting ‘with hope for progress BIR’ (before I retire) at the end of emails in his health organisation, and instead was putting ‘BID’.

In the next post I will look more closely at what might be needed to ‘really solve things’ in the future.

Prev: The crisis in e-health standards
Next: The crisis in e-health standards IIa