[image: (c) 2014 Imogen Brand Rakers Photography]

I have argued for an open platform approach in e-Health for some years now, as have others (Ewan Davis’s Nobody Can Own the Platform post is a nice summary of the issue). It’s clear that the idea is starting to resonate in some places like the NHS, bits of ONC thinking, the VA, and in some other countries. But how can governments and other fund-holders go about realising an e-Health platform?

The main problem from the government (national or otherwise) level is the gap between the existing sea of standards and a coherent platform, which probably still seems like a Chimera beckoning from the horizon. I hear them saying: yes, well, that sounds right, but how do we achieve it?

Firstly let’s just remind ourselves what doesn’t work: standards as a shopping list, or as I call it, the bag of standards approach. This is the thinking that each area needing standardisation (terminology, EHR, clinical content, guidelines, APIs, messaging, …) can be solved by nominating a supposedly appropriate standard, and that the resulting list equals some sort of national e-health architecture that can then be given to industry.

This approach has failed comprehensively over the last 15 years, and cost the governments of the UK, Canada, US, Australia, France, Netherlands, Sweden and others varying but always large amounts of taxpayer cash. Even worse, it has cost time. The lesson that was learned is that the collective cost of industry trying to integrate standards was far greater than the sum of the costs of using each standard on its own. There is no surprise here – imagine walking into a Galactic junkyard and expecting to assemble a working spacecraft from the leftover bits of 20 different types of machine.

But there are standards, and some of them do useful things, and industry uses them in various ways. However, used on their own, they create silos and stovepipes of products and expertise. So something still needs to be done.

Let’s consider what a platform is. It’s actually a set of self-consistent specifications for a pluggable infrastructure. To get from the various sets of mutually inconsistent specifications published by Standards Development Organisations (SDOs) and Standards-Related Organisations (SROs) to a platform will require work at the specifications level. It will require changes to those specifications or at least adaption / conversion layers to make them work together. More importantly it requires them to be situated within the correct part of an overall architecture, which means having… an overall architecture. Some standards will not be required, and/or will be subsumed by others.

This kind of work can’t be done in an ad hoc way, by random meetings of disparate people from various organisations, it requires focus and dedication.

Without a dedicated work effort, no progress will be made on the silos and pipes situation; it will continue to repeat itself ad infinitum. A dedicated work effort means creating a funded project whose job is to define the platform for e-health, and make best use possible of existing standards, specifications, and extant ideas to do so. This will require not just funding, but assembling a group of experts who subscribe to the idea of a single platform, and undertake to work together on a common architecture. The project will need requirements and architecture teams, just like a software project, as well as implementation and validation teams.

It could be done internationally, or as a network of national projects. However, it won’t work if it is essentially a meeting place for existing SDOs and SROs to ‘harmonise’. Harmonisation is an illusion.

Initially, it may be that different countries have to fund their own version of the open platform project, and the best results be determined by comparative reviews across these projects.

One thing is sure: if nothing at all is done, nothing at all will result. Platforms don’t assemble themselves by magic, just as a 747 will not be assembled by a tornado passing through a junkyard.

However, I believe it is worth doing, because the costs of a specifications-level integration project pale into insignificance against the costs of each industry player individually paying the prices of trying integrate today’s mutually incoherent standards.