Open Interfaces, Open Standards and Open Source

Everyone I talk to agrees that we have to create an Open Digital Health and Care Ecosystem in which a range of digital health and care service can be delivered. This needs to support the interoperability and orchestration of ecosystem components and provide the infrastructure to make it easier for innovators to deliver safe and secure services by offloading the technical and governance complexities from applications and by supporting a diversity of business models to enable sustainable digitally enabled health and care services.

In this context, pretty much everyone I talk to agrees that the existence of stable, robust, open interfaces on both legacy and contemporary systems is critical. Also most agree that both Open Standards and both Open Source have a role to play in the creation of Open Interfaces. However, I think there is some conflation of various issues, which I think could be usefully clarified and I attempt to do this in this blog.

Neither Open Source or Open Standards are necessary or sufficient in the creation of Open Interface and Open Standards and can be a Barrier to Innovation

Open Source and Open Standards have a role to play in the creation of robust Open Interfaces and I’ll attempt to describe what I think this is, but both are neither necessary nor sufficient and in some circumstance insisting on either can be a barrier to innovation and progress. What’s important is the availability of freely available, robust open interfaces not necessarily that they are Open Standard or Open Source.

Interfaces can exist at file levels of maturity which are illustrated in the diagram below.

Open API Pyramid

What’s important is the availability of freely available, robust open interfaces not necessarily that they are Open Standard or Open Source.

At the lowest level (5) Closed Systems lack stable, documented interfaces. Such a design approach is still encountered in monolithically architected legacy systems which were designed to “stand alone” at a time when, amongst other reasons, hardware constraints made the use of modular software architectures too computationally expensive. The only way to interface with such systems is to “hack” into the systems source code and data structures (always possible with Open Source systems, in the gift of the IPR owner otherwise.) Such interfaces tend to be fragile and are easily broken by changes to the underlying system.

Systems at the next level Private Interfaces (4) are the most commonly found in health and care systems today, with more modular software architectures. Such systems will typically have both internal interfaces (between modules) and external interfaces. Private interfaces are intended for the use of the systems software developer and are typically insufficiently documented and less robust than is required for their easy and safe use by third party developers. With proprietary systems access to the interfaces is controlled by the IPR owner; with Open Source anyone can use and improve the interfaces.

The concept of a partner interfaces (3) applies only to proprietary systems and such interfaces are commonly found in health and care systems in use today. Partner interfaces are designed and documented to make them easily and safely usable by third party developers, but access to them is controlled by the IPR owner who can choose with whom they wish to partner – Otherwise partner interfaces are identical to open interfaces (2)

Open interfaces (2) are designed and documented for safe and easy use by third party developers and differ from partner interfaces only insofar as the IPR owner has made the interfaces irrevocable freely available to all. This is automatic in the case of Open Source systems and can be achieved by a range of licensing or contractual arrangements in the case of proprietary systems – Public policy encourages public bodies to insist on the availability of open interfaces as a contractual requirement in procurement of systems. Open interfaces may be produced directly by the system developer or by a third party as a layer above a freely available private interface – Typically as an Open Source plug-in.

At all levels described above the technical and content characteristics of the interfaces are defined by the software developer but at this highest level Open Standard Interfaces (1) the interface implements wildly accepted open standards for both technical and content aspects of the interface. Such standards might be formal (ISO, CEN, BSI etc.) Industry/community de-facto (IHE, HL7,etc) or NHS (ISB, PSRB, etc). While a requirement for the use of open standards where such standards exist is highly desirable, insistence on the adoption of formal/NHS standards before they are fully mature, stable and widely accepted can be a serious barrier to innovation and adoption, as can onerous accreditation requirements in relation to standards compliance. Often a better approach can be the partial use of open standards in open interfaces (2) covering those characteristic where there is consensus.

The priority then is to get to level 2 – Open Interfaces. Ideally such interfaces should make use of those technical and content standards that support aspects of what they do, but the priority should be to expose rich interfaces able to allow access to all of the data and functions supported by the system.


Leave a Reply

Your email address will not be published. Required fields are marked *