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.

 

PHRs – An important but limited role

There is a lot of interest around PHRs at the moment at senior levels within the NHS, but there seems to be a lack of clarity the role PHRs might play in the UK

If we are to make progress we have to develop a shared understanding of what we are hoping to achieve, what we mean by a PHRs and what role they might play in meeting our objectives?

For many, including me,  the key feature that separates a PHR from other forms of health records is that it is controlled by the person to whom it relates – i.e. they decide if it exists, what form it takes, where it is held, what it contains, who has access to it and if and when it might be destroyed.

It seems to me that in the UK context PHRs have a limited, but important, role to play as a driver of innovation and change, but that many of the benefits they might bring would be better archived through patient access to existing records, particular GP records, and by a step-by-step evolution from siloed institutional records to a single logical record under share curation and governance.

In this long blog:

  • I provide some background about the purposes of EHRs and the Rights and Responsibilities of both record subjects and record users, an understanding of which I think is essential to understanding the limitations of PHRs and where they fit in the bigger picture.

  • Some thoughts about what I think are seen of the benefits of PHRs. I believe it is important to start with a shared view of what we are trying to achieve rather than jumping to the conclusion that the answer is PHRs

  • Finally, I lay out what steps I think we should take to move towards a shared record and what this is (which is definitely NOT a single physical record) and how patient record access to existing systems fit into this journey.

I conclude:

PHR are not the solution to the problem of sharing Electronic Health Records, but an intermediate step on a journey to a single shared logical record for every patient under shared governace with the paitient as “first amongst equals”. We should encourage the further development of PHRs and in particular explore the use of a common model for data persistence across multiple PHRs based on OpenEHR. Recognising that this is a long and difficult journey we should also continue to open up patient access to existing EHR systems (particularly GP systems) which for many will provide a better solution than a PHR to support patients engagement in their own care and the relevant sharing of their  data. We don’t know the answers to some of the challenges we will face achieving  our objectives, but answers will emerge from an exploration of PHRs, Patient Record Access and Shared Governance Models.

Background

Before coming back to what we do with PHRs I want to develop three points.

  • The purpose of health and care records

  • Rights and responsibilities in relation to such records

  • What we hope to get out of PHRs?

Purpose of Health Records

Health records have a wide range of purposes and these include:

  • Directly supporting the delivery of care to individuals

This category includes both clinical and administrative activities that are necessary for the maintenance of health and wellbeing of and the delivery of care to identifiable individuals including:

    • The provision of an aide-memoire for those involved in care.

    • To facilitate the engagement of patients and their family and informal carers.

    • As a means of communication within teams responsibly for an aspect of care.

    • As a means of communication between teams responsible for the different aspects of care.

    • The provision of the data need by decision support tools design to provide automated guidance to patients, formal and informal carers

    • The provision of data to support workflows, care processes and transactions related to care.

  • Supporting the Health of Populations

The category includes all those uses that are concerned with the health of populations, the planning of care and the development of health knowledge. These uses don’t offer a direct and immediate benefit to individuals, often don’t require identifiable personal information and are often referred to as secondary uses. These uses include:

    • Healthcare planning and commissioning

    • Public health and epidemiology

    • Risk stratification and risk scoring

    • Predictive modelling

    • Drug safety surveillance and pharmacovigilance

    • Clinical audit and outcome measurement

    • Population based healthcare research

    • Identification of subjects for clinical trials

  • Providing a Medico-Legal Record

Those providing care need to be able to demonstrate that they did so with due professional care, recording relevant information appropriately and acting reasonably on the basis of the information available to them. The medical legal record needs to meet the requirements laid down by statue and common law for the admissibility of evidence in both civil and criminal proceedings (principally the “Civil Evidence Act 1995” and “Police and Criminal Evidence Act 1984”. A medico-legal record needs to:

  • Be able to reliably represent the record as it would have been at any particular point in time

  • Securely represent the provenance of information recorded

  • Ensure that information once recorded cannot be repudiated

  • Provide an audit trail of additions, changes and access to the record

The record has to support the needs of all those involved in care which includes health and care professionals, administrative personnel, family and informal carers and patients themselves.

Rights and Responsibilities

In order to understand the issue surround the use and access to health records I think it is helpful to think in terms of a set of rights and responsibilities.

Rights might include: The right to;

  • Determine where and how the record is stored

  • Determine the information stored in the record

  • Decide who has access to the record and the purposes for which they use it

  • Collect information

  • Know the provenance of information stored in the record

  • Use the information in the record for defined purposes

  • Retain/destroy the record

  • Change, clarify or comment on and challenge the veracity of information in the record

  • Disclose information to others for defined purposes

Responsibilities and obligations might include: The requirement to;

  • To ensure the accuracy of information recorded

  • To maintain the currency of information in the record

  • To protect record from inappropriate use or disclosure

  • T disclose information as required by law, regulation or overriding public interest

  • To protect information from loss or damage

  • To maintain details on the provenance of information

  • To maintain audit records of access to, disclosures of and changes to information

  • To securely destroy particular copies of information (typically in compliance with retention policies)

  • Not to disclose certain information even to the patient

Many individuals and organisations may have some of these rights and responsibilities including the patient; those who have contributed to the record or delivered care on the basis of the record; those responsible for maintaining systems on which the record is stored; those who have paid for care on the basis of information for which the record is the authorative source, third parties referenced in the record and those executing certain regulatory or statutory functions.

A PHR as defined above is a record in which the patient has all of the rights and few if any of the responsibilities and in which others have few if any rights and only those responsibilities that may flow from providing and/or hosting the record on behalf of the patient.

Those who wish to maintain records can take one of two basic approaches (and many variations at points between) to ensure the record is fit for their purposes At one extreme each stakeholder maintains their own record for their own purposes (this is broadly the current situation) and at the other extreme we try and create a single logical record under shared governance that satisfies all.

Why PHRs

What then do we hope to achieve by creating PHR? Proponents of PHRs cite many potential benefits, which include the following:

  1. Greater engagement of patients and their informal carers in their health and care.

  2. Facilitation of innovation and experimentation with new approaches to health and care records.

  3. The creation of a truly integrated life-long record which covers all aspects of wellbeing, health and care.

  4. Greater transparency so that patients and their advocates are better able to assess the cost and quality of care that they receive and if needbe challenge it.

  5. Improvements to the completeness and accuracy of health and care records by allowing patients, their digital devices and their informal careers to contribute to and validate the information recorded in the record..

  6. Provide a mechanism which allows patients to see what is recorded about them and manage informed decisions about the sharing of data for both primary and secondary purposes.

  7. To enable patients to record information about the health and care beliefs, values and preferences.

  8. To allow patients to record data about their health and care for their private use which they don’t wish to be available to others.

However, with the exception of the 5th and 8th points above all of these things could be achieved using facilities that are available now in GP systems and which have been offered to patients by pioneering practices for over 10 years. Extending systems to support the 5th and 8th points while non-trivial, is entirely doable.

So what should we do?

My answer to this question is not a simple one as I think we need to pursue multiple paths.

  • First, we need to push forward with GP record access to meet the Goverment’s commitment that all patients who wish to do so should be able to access their GP record online.

  • Secondly, we need to start to lay plans to provide a single shared record under shared governance and curation with the patient as “First Amongst Equals”

  • Thirdly, we should encourage the development of PHRs as a transitional approach for those patient groups who needs would not well met by access to GP records (these are typically those groups undergoing an extended episode of care outside of general practice e.g. renal patients) and as a vehicle to experiment and drive innovation which will inform the creation of shared record.

  • Finally, we should enforce the Open APIs policy being developed by NHS England which requires all new procurement of systems to make open APIs available and require  all systems to enable patients to obtain a machine readable download along the lines of the US “Blue Button” model

Making GP record access a reality

Given that the technical facilities to allow patient access to GP records have been available to the majority of practices for many years and that they have be used successfully by pioneering practices, Government wrongly assumed that getting wider take up would be easy. What they failed to understand is that pioneering practices had chosen to ignore the risk of the unlawful disclosure of third party information to patients, something neither the Government nor their professional bodies could advise others to do. Solving this problem retrospectively is not practical and as a result a more limited approach is now being proposed as laid out in ‘Patient Online: The Road Map’.   We should get on with this and also work to ensure systems are amended so that future recording of third party data is tagged to enable it to be easiy redacted.

Building a shared record

Building a shared record will be a slow process, but one that can be approached incrementally. It’s also important to understand that I’m not proposing a single national record, but rather that for an individual there should be a single authoritve record. Every application that needs information about the patient would get it from this record and any application that needs to persist data about that patient would write it to this record. There could (and should be) multiple providers of repositories for records and the patient should be able to choose which one they use and be able move their record to another provider should they wish. It might even be appropriate for different sections of a record for a single patient to be stored in different services? It would be the responsibility of the service provider to ensure the security and integrity of the record and to put mechanisms in place to enable all those with an interest in the record to secure their rights and responsibilities in relation to the record.

The record architecture required would need to be flexible and extensible and able to handle record dissonance and maintain multiple versions of the truth where the contributors to the record can’t agree a single version.(I will shortly publish a further blog detailing my proposed model for shared governance and the role of multiple truths) It would need to be based on a set of open standards shared (at least) across the UK to ensure interoperability. For me the only currently available viable contender for this architecture is that provided by OpenEHR, which I believe can meet these complex requirements of my proposed model. In this model record storage becomes a commodity service in the cloud and various organisations could offer such storage under a range of business models, but it the UK I would suggest that the default choice of most citizens would be to use the repository funded by their local public sector care provider.

For this approach to work other things need to be in place:

  1. A discovery service for applications to find where the record for a particular patient is – This could be most simply be provided on a centralised basis by the NHS Personal Demographic Service, but could also be achieved using a distributed directory service .

  2. A service to maintain a registry of those who have contributed to the record or have a legitimate interest in it along with the consents granted by the patient for access and particular uses. Again this might be provided centrally as a service on the NHS Spine or as a distributed service. The work of www.miconsent.org has potential to address aspects of this requirement.

  3. Governance structures (probably with a statutory underpinning) to regulate the record service providers to ensure they are irrevocable obliged to: Satisfy the rights and responsibilities of all those with a legitimate interest in the record,  transfer the record  to an alternative provider if they cease to be able to  do so or on request of the patient and ensure that records are protected from loss in the event of a technical or business failure of a provider.

This architecture is one that I have described before  and is built round an enterprise service bus (ESB) that connects back-end services (which would include record repositories) to front end applications that consume these services. An appropriately designed ESB would:

  • Provide a single interface (API) to the various record repositories and supporting services avoiding the need for applications to deal with multiple APIs with the ESB handling mappings and transformations between different APIs, technical and clinical content standards facilitating incremental progress toward common standards.

  • Protecting services from badly behaved applications and denial of service attacks.

  • Off-load many functions from application and service providers to make their lives easier, requiring these functions to be implemented just once in the ESB rather than in each principal system e.g. authentication, identity management, access control, consent management IG, load balancing (to name a few.)

  • Provide an accounting platform that could support innovative business models for apps (such as pay for use models) and a mechanism for charging the responsible party for compute resource and services consumed by applications.

  • Provide a comprehensive patient portal integrating access to existing NHS national web services; NHS Choices, NHS Direct online and NHS 111 online content with record access, and transactional services.

Migration to a Shared Record

My expectation is that, over time, existing systems would migrate to using the shared record to persist the patient information rather than their own local storage. For this migration to occur existing system vendors and users will need to be confident that the shared record can deliver a level of performance and availability to match that provided by local storage and some may wish to start by maintaining of local cache of the record to improve performance and provide resilience. Also, initially that many will continue to use their own storage simply using the ESB for messaging, interoperability and to provide access to transactional services.

Where does the PHR fit

In this model I see that existing PHRs will also migrate to using the shared record just as other ExRs will do.

Many existing PHR systems are already using the latest web technologies and the agile and innovative nature of most PHR vendors and their flexible business models mean that they should be amongst the first to migrate to the shared record.

Similarly the agile and innovative nature of the PHR sector and the much similar Information Governance issue that exist with PHRs (as the patient is in control) will combine with the emerging shared record to enable of slew of PHR developments in which the developers can concentrate on the user experience and user interface design and experimentation with novel business models free from much of the burden of managing record persistence.

For those wanting to experiment there are already facilities provided by the Leeds Health Innovation Lab Platform  which offers what a test platform that could be used to start to build exactly the sort of shared record I’m suggesting.

EhrScape also based on OpenEHR has also recently annocunced an Open Health Data Platform that could also provide a basis for experimentaion

There are also a number of Open Source PHRs that could provide a rapid route for those wanting to experiment or provide live services quickly. Including Indivo and Renal Patient View

We should encourage and facilitate such activities which will help and refine and develop the shared record and the supporting open digital health ecosystem at a pace not possible with the more complex issued raised in the migration of existing large scale EHR systems.

So, in conclusion:

PHR are not the solution to the problem of sharing Electronic Health Records, but an intermediate step on a journey to a single shared logical record for every patient under shared governace with the paitient as “first amongst equals”. We should encourage the further development of PHRs and in particular explore the use of a common model for data persistence across multiple PHRs based on OpenEHR. Recognising that this is a long and difficult journey we should also continue to open up patient access to existing EHR systems (particularly GP systems) which for many will provide a better solution than a PHR to supporting patients engagement in their own care and the sharing of data. We don’t know the answers to some of the challenges we will face achieving  our objectives, but answers will emerge from an exploration of PHRs, Patient Record Access and Shared Governance Models.