What is an Open Platform?

Definition of a Platform

In software design, a platform is an architecture where the applications are separated from the data upon which they operate. The data is stored in a shared repository on the platform which also provides shared services useful to many applications. Applications communicate with the platform via an Application Program Interface (API), simplifying the task of building applications.

Platforms underpin many modern digital services in sectors including banking, travel and retail, and enable innovators to create new services and applications that would be impractical were the platform not available.

What makes a platform "open"?

An open platform is a platform based on open standards such that any willing party can build applications or platform services that work together. The best example of an open platform is the Internet itself.

In health and care, a definition of an open platform has been provided by the Apperta Foundation (a not-for-profit created by NHS England with the remit to support the adoption of open standards across health and care) in “Defining an Open Platform”. The primary author of this document is inidus’ CEO.

Some existing vendors are repositioning their products as a platform, and some are erroneously describing their platform as “Open”. A proprietary platform that includes a limited number of open APIs IS NOT an open platform as it does not satisfy the definition from the Apperta Foundation

Keeping patient data safe

The use of “open” in “Open Platforms” refers to the use of open standards and is not used in the same way as “Open” in “Open Data” that implies the data itself is freely accessible to everyone.

Open platforms make data available in an open format to AUTHORISED users only. inidus allows the patient to decide who is authorised to see their data and what they are allowed to use it for.

Components of an open platform

The key components required to provides a basic open platform configuration are shown in the figure below.

Many other services could be delivered via the platform but the set of facilities shown provided enough to get started with an open platform

Screen Shot 2019-04-16 at 11.35.58

What open standards are used?

The core standards for an open platform are:

  • openEHR - for the storage of structured and coded clinical records;
  • IHE-XDS - For the storage of documents and images linked to openEHR records;
  • HL7 FHIR - for interfacing with existing systems; and
  • SNOMED-CT - the international terminology standard mandated in the NHS

Is this “open source”?

No! Open platforms are about open standards and are agnostic with regard to the licensing model of components. It is irrelevant whether they are open source or proprietary as long as they are compliant to the relevant open standards.

What is openEHR?

openEHR is an open standard supporting the definition, persistence and querying of structured clinical data. A Clinical Data Repository (CDR) compliant with the openEHR standard is a core component of our platform.

We provide further information on openEHR here.

What is IHE-XDS?

IHE-XDS is an open standard for sharing documents. It is widely used as the standard for Vendor Neutral Archives (VNAs), for sharing documents and clinical images. IHE-XDS can be used to store any unstructured or semi-structured data, and is well supported with software available from many vendors. IHE-XDS has been widely adopted in a large number of implementations across the globe.

IHE-XDS and openEHR compliment each other. openEHR is well-suited to handle fine-grained, structured and coded data whilst IHE-XDS is better able to handle clinical images and documents. Two of the largest implementations of an open platform (Moscow and Slovenia) use openEHR and IHE-XDS working together to create a comprehensive Electronic Health Record.

What is HL7 FHIR?

HL7 FHIR is the latest standard from the international standards body HL7. HL7 FHIR emerged from the success of HL7 v2 and the failure of HL7 v3.

FHIR is designed to support the exchange of clinical information between heterogeneous EHR systems, either as a message or via an API call between systems.

The latest version of FHIR, FHIR V4 defines 143 Resources. These resources range from the very specific (like “Medication”) to the much more generic (like “List”) but all need to be “profiled” to be made usable in a given healthcare community. For specific resources, this work is modest but for the more generic resources, this work is substantial with a potential requirement to create many profiles from each of these generic resources.

In the UK the work of creating FHIR profiles has fallen to INTEROPen (a joint industry NHS body) working with TechUK, NHS DIgital and the PRSB. INTEROPen are yet to adopt FHIR V4 but list 239 Resources for use in the UK NHS, in compliance with earlier FHIR versions DSTU2 or STU3.

In order to use FHIR, “sending systems” need to map relevant information from their internal data structures to the relevant FHIR profile, while “receiving systems” need to map information they wish to store from FHIR to their data structures (typically via a managed workflow). This process of mapping to-and-from FHIR works well when the internal data structures of sending and receiving systems are closely aligned to FHIR, but will result in some loss of data fidelity when this is not the case.

FHIR works well for the transfer of a small number of high value pieces of data (like medications and allergies) but  lacks semantic coherence and won’t scale to provide full semantic interoperability (i.e. the ability to exchange all information within the scope of two systems with no loss of fidelity, context and provenance). 

inidus have already built an open source FHIR connector for openEHR 

For an in-depth discussion about issues with FHIR and a comparison with openEHR, refer to this series of blogs from Thomas Beale.

What is SNOMED-CT?

SNOMED-CT is a systematically organized and computable collection of medical terms providing codes, terms, synonyms and definitions used in clinical documentation and records. SNOMED CT contains over 310,000 unique concepts and many more synonyms in a number of languages.

SNOMED-CT works well with openEHR which allows SNOMED-CT codes to be bound to openEHR archetypes or more usually openEHR templates - See  here for more details.

SNOMED-CT is the mandated standard for clinical terminologies in the UK with a target for its implementation across the English NHS by 2020 (see here for more information about NHS implementation plans.)

SNOMED-CT is not strictly an open standard, as it is necessary to purchase a licence in order to use it. However, in over 40 countries, including the UK, a national licence has been agreed that allows its use under a free licence within those countries.

Open platform ecosystems

An open platform ecosystem is a competing and collaborating group of entities providing applications and platform services for health and care organisations and patients, that are compliant with open platform standards.

The open platform approach expects that there will be multiple platform implementations from a variety of vendors. Patients will decide which of these they choose to store their record in. Within the context of the UK, it is highly likely to be the platform provided by their local NHS organisation.

All platform instances:

  • Operate to identical standards;
  • Are federable;
  • Allow applications to seamlessly access data for different patients from multiple repositories; and
  • Allow patient records to be transferred between repositories.

Feral or shadow IT systems

A feral or shadow IT system is a system created “under the radar” of the IT management within health and care organisations. They are created typically by individuals working in health and care organisations or individual contractors and micro-enterprises building small systems to meet needs not met by corporate systems. While some will be professional developers, many are “hobbyist” developers building systems alongside their day job.

The nature of the feral systems market is such that it is difficult to get information about its size. An audit of a number of  large London NHS Trust identified over 1,000 feral systems in use[1]. We understand that this kind of number is typical, with the numbers of feral systems in smaller community and mental Health Trusts being much smaller (we estimate typically 100). This would suggest in excess of 160,000 feral systems across the NHS, with about 25,000 being created each year.