In defence of the Spine

Ewan Davis

Ewan Davis surprises himself by taking up the case in defence of the NHS Spine. He argues that if we didn’t have it we’d have to invent it.

The Conservative Parties independent review of NHS IT, conducted by Dr Glyn Hayes, has much to recommend it, focusing as it does of the development of NHS based on local needs centred on the patient.

However, while I agree that centralisation with a focus on a small number of national systems is bad, the complete devolution of IT to a local level is not better, but simply differently bad. The real answer is more complex.

We do need more local choice, control and diversity, but for reasons of both efficiency and interoperability some things need to be done at a regional or national level and this requires that we build on not sweep away the national infrastructure delivered by the NPfIT. I believe that the Hayes report understands this, but that this message is being lost in the spin and political rhetoric surrounding its publication.

Spine necessary to Conservative’s NHS plans

In particular, it seems the Conservatives are close to making a commitment to scrapping the NHS Spine, apparently unaware that this will undermine their own vision for future NHS IT. Such a move would also bring down existing services including GP2GP record transfer, Choose and Book and the Electronic Transmission of Prescriptions. These are all valuable services, that after a long and costly gestation are now beginning to deliver real benefits.

The Conservative rhetoric with regard to the Spine is based on a common failure to understand what the Spine is and what it does. The aim of this article is to try and address these common misconceptions around the Spine, and offer a reminder of what it does and why it matters.

My vision, shared by many others and reflected in the Hayes Report is for NHS IT, is to create an open platform which will allow components and applications to be selected locally to meet the needs of individual health services. GP practices hospital departments would know these components are able to interoperate to enable the appropriate sharing of information, and provide access to knowledge services designed to support the process of care.

If delivered, this vision would move us away from nationally imposed monolithic systems, centralisation and a one-size-fits-all approach to one that enables choice, diversity and innovation.

Build on what we now have

Just as importantly, although ambitious, it is a vision that can be achieved by building on what we already have. We don’t need to start over. Crucially, in implementing this vision of choice, backed by open standards and interoperability, we can take advantage of the global investment in Internet technologies, Service Oriented Architectures, Software as a Service and apply them to the health domain.

Delivering this vision requires four things:

• Generic technology standards (broadly Internet technologies), that provide SOAs and web services that enable the interoperability of heterogeneous software components;
• Healthcare specific standards, that allow the representation of healthcare information in a form that makes it computable and allows it to be processed and communicated without loss of meaning;
• Core functionality, that enable discovery and location of patient records and knowledge in local systems and national services; which manages security and enables communication between the components on the platform;
• Governance structures, to ensure quality and privacy and to resolve issues that arise between actors in a health community using the same platform.

In this article I want to focus on the third of these, and demonstrate how the Spine already delivers most of what will be needed. The Spine can also be fairly easily extended to provide those few additional functions – such as pointers to locally held data – it does not currently provide.

Core functionality required for an open health platform

Lets consider what core services you need to support an open platform in a health community, whatever its size.

First, you need a central reliable register of patients. This needs to contain only enough information to enable patients to be unambiguously identified and pointers to where other information is held.

Personal Demographics Service

The Spine Personal Demographics Service (PDS) already does most of this, and could be extended to hold pointers to locally held information supporting publication and discovery of data by local systems – a central recommendation of the Hayes review.

The PDS has already streamlined access to and improved the quality of demographic data previously managed by a number of legacy systems and provides a good basis for the central patient registry of an open platform. A national demographic service, or enterprise master patient index, is one of the crown jewels of the NHS in the Internet era. We shouldn’t heedlessly throw it away.

Directory Service

Secondly, you need a directory of actors -staff and systems – enabling routing of information to the appropriate system or individual. This should provide details of roles and access privileges and support the proper attribution of actions and the recording of the provenance of data. These services are essential for the protection of patient privacy and the maintaining the quality and medico-legal validity of electronic records. The Spine Directory Service (SDS) already provides support for these functions. Again, we should think hard about what you’d replace this with.

Security

Security also requires central support for authentication and to enable the tracking of roles, legitimate relationships, workgroups and stop-noting. The Spine Access Control Framework (ACF) is central here, with SDS and PDS also providing information that drives the security model.

Single sign-on

On a platform with users accessing many systems single sign-on becomes essential and needs to be handled centrally. The Spine ACF also supports this functionality

Transaction Messaging Service

Next, you need some form of messaging service to handle transactions between local systems and between local systems and Spine services. The Spine Transaction Messaging Service (TMS) does this. One of its main functions is to provide the message fabric for GP2GP, ETP and Choose and Book. In the environment proposed by the Conservatives messaging becomes even more critical, providing the necessary sharing of data between local systems.

Secondary Uses Service

Last, but not least, you need a service that will allow extracts from local systems for secondary purposes, such as medical research and healthcare planning This service needs to protect confidentiality and support privacy enhancing techniques including aggregation, anonamisation and pseudo-anonamisation. The Spine Secondary Uses Service (SUS) provides much of this functionality and is central in the support of policy around key areas as such as the 18 week waits target, practice based commissioning and payment by results. There is no indication the Conservative’s wish to dispense with these key NHS strategic initiatives.

Spine Personal Information Service

So what is it that the Conservatives don’t like about the Spine? The answer seems to be the Spine Personal Information Service (PSIS), and here I have some sympathy within their position. Its worth noting thought hat what PSIS is and might become seems to be very confused with various factions having different ambitions for the future of PSIS. This lack of clarity over the purpose and content of the spine record is what has stoked fears about patient database, and makes it difficult to have an informed debate.

Summary Care Record

I would agree with the Hayes Report that detailed care records should be maintained locally. However, although not the first priority there is obvious value in sharing some information nationally as has been done intelligently by the Scottish Emergency Care Summary. But summaries need to be created for defined purposes. The concept of a all-purpose summary is just nonsense.

Summaries need to be developed though a process of joint publication between health care professionals and patients, which respects the patient’s wishes about what should be shared. In England the initial lack of clarity with regard to the purpose of the SCR and an unnecessarily authoritarian approach to consent has created concerns.

But these issues have now been substantially resolved and it would be foolish to abandon the SCR as it currently exists, rather we should build on in carefully considering what additional information might be shared nationally (for example a single medication record) and what other specific purposes a summary care record might support.

Conclusion: build don’t dismantle

So in summary the Spine is already providing most of the services that will be critical to support the sort of devolved IT envisaged by the Conservatives and these service need to be preserved and improved, not carelessly swept away.

The Spine has its problems, but it provides facilities that work well enough to support currently important services and provides a basis from which future federated services can be developed. These will be essential to enable the vision of an open health platform supporting multiple applications, chosen locally to support patient needs that is at the heart of the Hayes Report, and which I wholeheartedly endorse. Delivering the conservative vision requires the Spine and if we didn’t have it we would soon need to develop something very much like it.

Ewan Davis, Woodcote Consulting,

Declaration of interest: The author has worked as a consultant to BT Health (although not directly on the Spine).