I’ve been silent for a while, but luckily an excellent paper on one of my favourite topics – the open platform for e-health has appeared. It comes from the Apperta Foundation, and is called “Defining an Open Platform”; you can get the PDF and also comment here.

Firstly, let me mention the authors, representing a wide range of clinical, health informatics and health system economics experience from around the UK:

• Ewan Davis – Woodcote Consulting
• Dr Tony Shannon – Ripple Foundation
• Dr Ian McNicoll – openEHR Foundation
• Dr Roland Appel – Maycroft Consulting
• Silas Davis – Monax
• Dr Rebecca Wassall – Apperta Foundation
• Peter Coates – NHS Digital Code4Health

The work of the report was sponsored and signed off by:

• Dr Bill Aylward MA MB BChir FRCS FRCOphth MD, Chair Apperta Foundation
• Dr Rebecca Wassall PhD, CEO Apperta, Clinical Lecturer / StR in Special Care Dentistry, Newcastle University

The report is more or less a manifesto and call to arms for the National Health Service, vendors, healthcare provider organisations and clinical professionals to make a commitment to a new way of doing e-health – the open platform – and in doing so, to start to retire the monolithic, expensive silos of applications and data currently asphyxiating care delivery. Here’s the first paragraph:

Healthcare systems around the world are under increasing pressure and while there is a widespread belief that digital technologies have the potential to have a transformational impact, as they have in other sectors we are yet to see this in health and care. This failure flows from the complexity (technical, cultural, and regulatory) of the health and care environment which creates insurmountable barriers for the sort of innovative start-ups that have been the engine of transformation in other sectors.

The rest of the report fills in motivations for an open platform – enabling innovator companies, removing vendor lock-in, and the creation of not just a technological ecosystem, but an economic one as well.

At the most basic level, committing to an ‘open platform’ means committing to published APIs, information models (describing what can be written and read through the API), and models of semantics, i.e. models that describe or express the meaning of both the data and the workflow represented by performing multiple calls to achieve a goal.

What is a Platform?

The Apperta paper describes things in a bit more detail, in terms of 8 characteristics of an open platform [see p16]:

1. Open Standards Based *
2. Shared Common Information Models *
3. Supporting Application Portability *
4. Federatable
5. Vendor and Technology Neutral
6. Supporting Open Data
7. Providing Open APIs *
8. Operability (as in DevOps)

To be pedantic, I have marked some with an asterisk, meaning they apply to the platform definition, while the others mostly apply to platform implementations.

I would also add a few more characteristics of an open platform definition:

• self-consistent – all ‘standards’ and other specifications cohere formally, so that the platform as a whole is always coherent, in terms of information typing, knowledge meta-models and API semantics – i.e. the ‘bag of standards’ approach must be avoided (see this previous post);
• semantically scalable – the semantic and knowledge framework for the platform can scale without limit, so that 10s or 100s of thousands of evolving definitions of clinical terminology, data and process concepts can be realistically and economically produced (see this previous post);
• operationally adaptive:  semantic (i.e. domain and business) definitions can change and grow in the long term, and be consumed by deployed software and databases, rather than causing continual new deployments.

All of this taken together defines what an open platform is. A much shorter definition I came up with a few years ago was this:

• A platform is a set of self-consistent specifications for a pluggable infrastructure.

This doesn’t quite capture some of the dynamic aspects, but it’s not a bad one for manager types to use.

Who Owns the Platform?

The report goes into some of the services that a platform would need, and also commercial and governance issues. There is much complexity here, but the key question is:

• who owns the platform (definition)?

The report doesn’t answer the question concretely, saying (quite correctly):

As many come to the conclusion that the problem is too big for even the largest players to solve with proprietary approaches and that only an open approach towards a digital healthcare commons, that allows for cooperation to address the complexity of health and care can succeed. [p13, my emphasis]

There are some other good statements on this theme [p26; my emphasis]:

However, it must be recognised that many established vendors have business models reliant on customer lock-in and will resist opening up their systems in a way that undermines this core business approach. While they will be supportive of providing limited APIs such as those proposed by INTEROPen, they will resist more fundamental changes to open up all of the data in their systems, removing the commercial benefit they currently gain through data lock-in.

Many vendors have partner programmes designed to facilitate third parties wishing to connect to their systems. As the number of third parties wishing to connect grows, this “many-to-many relationship” creates serious problems. These problems affect both the vendor and the third party.

…We know from the GPSoC Programme that giving legacy vendors too much power (for instance in who connects and how they connect), severely restricts interoperability.

These statements are not intended as criticisms of companies, but observations about how an ecosystem has to be constructed in order to make it function properly – just like the wider economy, or a social democracy, influence and power have to be shared equitably.

Standards

The question of standards for the platform is discussed, and sensible observations are made about categories of standards (technical, content, API etc), as well as key issues such as:

Defining content is primarily a clinical rather than a technical problem … Content is ideally defined in a way that is agnostic to any particular technical representation. This is particularly important as content standards tend to be convergent and stable over the long-term whereas technical standards are constantly changing. [p28/29; my emphasis].

Naturally in this discussion, FHIR and openEHR come up. I’ll avoid any discussion here and point to a previous post on this topic.

The main conclusion from the above statement I believe we should draw is that we should be aiming for a single-source semantic modelling knowledge framework, in which models of content and other clinical semantics – workflows, clinical pathways, guidelines and so on, as well as underlying terminology and ontology – are defined in one place, and in the same formalism, independent of particular data formats, messages, of document structures. We know we are going to have at least O(10k) definitions just of content, and equal numbers of guidelines are eventually likely. We cannot afford to define these semantics in more than one place, or buried inside a particular kind of concrete format.

At the moment we are not there yet: FHIR has its own way of defining content; SNOMED CT is not yet harmonised with the binding mechanisms of archetypes, and formalising guidelines is still an art, not a science. In the UK I hope people with vision will carefully consider the consequences of doing nothing in this area.

The Apperta document also delves into the UI/UX area, which I think is good, because as we have learned over the decades, UI/UX isn’t about forms and fields, it’s about a human/machine cognitive experience that closely (or not) matches the mental models of the humans. It is pointed out that there is little solid science or established tooling / code for good UI/UX in health, so this area is necessarily one in which any new platform ecosystem will push new boundaries.

Delivering on the promise

To quote from the report [p41]:

Delivering the vision of an open platform is not about creating a single instance of a platform, but rather it is about creating an open platform ecosystem where a number of platform providers compete for business with each other.

There are various models that might emerge for the creation of an open platform ecosystem. These include:

• The establishment of an open health and care commons/marketplace for open platform oriented components and services. The 1% Open Digital Challenge Fund push across the UK and Ireland has already evidenced the appetite in the market for such a change.

This in my view is the right kind of thinking. It is impossible for all the answers to appear at this point of course, and the Apperta group have a very good set of recommendations, including establishing a working group dedicated to aligning existing efforts to a common platform approach; establishing a custodian for a platform definition; and various initiatives for managing APIs, content definitions and open source code.

There is much more detail in the report and I recommend reading the whole thing, both from a UK internal point of view, but also as a model of thinking that needs to be applied in most other countries.

Time for the UK government to get serious about enabling this vision to be realised.