There is a growing recognition that we need an open platform concept to solve e-health interoperability and reuse problems. Some evidence of this I noted in my recent post ‘What is an open platform’, including various US-based cross vendor platform alliances. The great value of a well-designed open platform is that it enables two things:

• a growing platform-based economy of producers to collaborate technically while operating commercially and/or in an open source mode
• adaptation to the constant stream of new requirements.

This is in contrast to the typical de jure standard based on a particular use case: it solves a locked down definition of the problem in a locked down way.

Within a platform, there are many interoperability points, and therefore many places where ‘standards’ might apply. However, the implication isn’t that you can just go and obtain a shopping basket of existing, separately developed, and possibly highly evolved standards and glue them together to get a platform.

But why not?

One aspect of a ‘platform’ evident to engineers, but which I didn’t discuss in the earlier post is that a platform evolves in time, from simpler to greater sophistication. This means that the ‘standards’ in use at the interoperability points in the platform also must do this – evolve from simple to more complex.

Another aspect which I have repeated endlessly is that all of the elements of the platform, including those in-built standards, must be mutually coherent. That can generally only come about by co-evolution (even if some of the standards is external in origin).

Enrico Coiera puts it like this in his excellent post Are standards necessary? (my bolding):

Clearly, some standardisation may be needed to allow the different elements of a complex human system to work together, but it is not clear how much ‘standard’ is enough, or what goes into such a standard. My theoretical work on the continuum between information and communication system design provides some guidance on when formalisation of information processes makes sense, and when things are best left fluid

Some of the malign effects of ‘ruthless standardisation’ are described in Ewan Davis’s post ‘Farewell to ruthless standardisation’ (referring primarily to the horribly expensive failure of the NHS National Program for IT, aka NPfIT), and one of his prescriptions for the sickness is:

• Learn from the processes that have allowed us to create the Internet, the Web and Wikipedia and apply them to health informatics.

These are all open platforms which evolved into place (and continue to evolve), not by creating fixed use-case standards, but by creating an adaptive ecosystem.

I myself have railed long and hard against the poor quality and general approach of e-health standards (The crisis in e-health standards).

But we can state one of the big problems in far fewer words:

• standards that solve one use case (or one use case at a time), in terms of a rigid message, document or interface definition actually work against e-health interoperability, because each such standard is its own requirements and solution silo. The failure to co-evolve such definitions over time as a coherent platform leads to overlap and technical lock-in. Use cases in reality change constantly, but rigid use-case-based standards don’t.

In a platform-based approach, message and document content will generally be determined at runtime. Only the elements can be known in advance. What can be standardised are:

• elements of content and process – meaning we need libraries of such things, and
• automated and semi-automated methods for generating final use-case based artefacts.

The fact is, use-case based artefacts will only be relevant for a while, and will either have to be modified, or replaced. A standards-based platform therefore can’t afford to be made of such artefacts.

As an aside, that’s why in openEHR, ISO 13606 and now CIMI, which are archetype based, we create archetypes to define the elements, and templates to represent the use-case specific data sets. The templates are modified or thrown away and replaced easily. Further, the concrete downstream formats such as APIs, message XSDs, document XSDs and in some cases, UI forms, are generated from templates, not manually built. This means they can always be regenerated from new templates.

There is no escape from reality changing every day into a new version of itself. We humans like certainty and stability, but the best we can do in e-health, as in all other modern technical domains, is to set up an adaptive ecosystem and let it evolve over time. The best way we can spend our energies in e-health today is on a well-designed ecosystem, not trying to prefabricate fixed species to fill a zoo.