Ringholm-Logo Ringholm
 Whitepaper
Ringholm page header
Training    Services   |   Whitepapers    Blog    Events    Links   |   About us    Partners    Clients    Contact

The Spine, an English national programme.

The contents of this whitepaper are public domain.
See http://www.ringholm.com/docs/00970_en.htm for the latest version of this document.
Author: René Spronk - Sr.Consultant, Ringholm bv
Document status: Final, version 1.3 (2007-03-19)  
Please sent questions and comments to Rene.Spronk@Ringholm.nl


Summary

The English Spine (the national IT infrastructure for healthcare) will provide a commonly accessible patient based resource, making information from multiple sources available to all those with a legitimate care relationship to the patient. This includes all health professionals whether they work in a hospital, in primary care or in community service. The architecture of the Spine is based on a centralized partial care record, supported by directory services and HL7 version 3 messaging.

1. Introduction

The demand for high quality healthcare continues to rise and the care provided nowadays is much more complex, both technically and organisationally, than ever before. This is the reason why the NHS (i.e. the NHS in England) has created an agency called 'Connecting for Health' (CfH). Its primary role is to deliver integrated IT systems and services to National Health Service of UK and ensure care is centered on the patient. It aims to connect over 100,000 doctors, 380,000 nurses and 50,000 other health professionals and give patients access to their personal health and care information. CfH contains a number of projects related to improving the use IT within the NHS. One of the programmes (National Programme for IT, or NPfIT) is related to the development of the Spine (a.k.a. National Spine).

The Spine was developed to provide a commonly accessible patient based resource, making information from multiple sources available to all those with a legitimate care relationship to the patient. This includes all health professionals whether they work in a hospital, in primary care or in community service. The Spine will address the sharing of EPR information, by creating an electronic highway.

This whitepaper describes the architecture of the Spine, including some of the major components related to the Spine. It doesn't describe the current situation nor any legacy applications.

The components of the Spine and their relationships. The Spine components are detailed below.
Figure 1. Spine architecture

The Spine consists of the following major components:

  • TMS: Transaction and Messaging Spine; the master "router" of all messages between systems. All messaging via the TMS is based on the HL7 version 3 [HL7v3] XML messaging standard.
  • SDS: Spine Directory Services; provides various Directory Services (e.g. organisational details of GP practices). SDS excludes patient related demographics.
  • PDS: Personal Demographics Services; provides a National Service holding all personal, demographic and related information for each patient.
  • NCR: National Care Record; holds a summary of clinical and associated information. Note: NCR was formerly known as the NHS Care Record (NCR), the Personal Spine Information Service (PSIS) and Integrated Care Record Service (ICRS).
  • LRS: Legitimate Relationship Service; controls what access a healthcare professional has to a person's clinical data.
The following applications are attached to the Spine by means of the exchange of messages via the TMS:
  • Common applications & services: Services (new and existing) offered at a national/regional level to all healthcare providers, e.g. the support for e-Booking and e-Prescription.
  • Local systems: Systems used by healthcare providers that are Spine-enabled, i.e. linked to the Spine. Examples include GP, Acute, Community, Mental health and Social Care IT systems.
The following applications are attached to the spine by other means (i.e. not via the TMS):
  • CSA: Clinical Spine Applications Service; allows healthcare professionals to have access to the NCR/PDS data if their system isn't Spine-enabled (yet).
  • myhealthspace: a web-based portal which allows patients to have access their own NCR/PDS data.

2. Spine components

The Spine is comprised of various components. The major components of the Spine are described in this section.

2.1 Transaction and Messaging Spine (TMS)

All clinical messages are routed via the TMS. The TMS must route the message flows from the local system to the NCR and, where applicable, from the NCR to the local system. It is responsible for moving HL7 XML messages from one system to another within a distributed network environment. Messages are moved from a system that requires the use of a national service to a system that implements the service (such as EBS, PDS, and LRS).

The TMS is build on top of the functionality of the NHS Message Handling Service (MHS). The MHS is responsible for handling all XML-constructed messages sent between systems. All messages from business systems to national services must pass through the Spine MHS node for forwarding to the requested service. For a number of national services (such as PDS and LRS) the Spine is also the service destination MHS. On the other hand, in the case of EBS, the Spine is a true intermediary node.

2.2 Personal Demographics Services (PDS)

The PDS is to be the prime definitive source of NHS patient demographics. PDS queries will constitute a major messaging application on the Transaction and Messaging Spine.

The PDS will provide a repository designed to be directly accessed by new national services and to be a universally available demographic database, to which all primary and secondary care systems can be aligned. Currently patient identifiers are created and maintained by various local and national organizations; these will have to be migrated.

The PDS will have to support the following:

  • A "Get NHS number" query (based on demographic data).
  • The retrieval of a patients demographics history (between given dates),
  • Mother and baby and family linkages.
  • Facilities to add, revise, close, merge, unmerge and re-open records.
  • The allocation of temporary NHS Numbers.
  • Hold “current GP” information in the form of the GP name and a unique professional registration identifier.
  • Hold all patient consent details.

Retaining integrity of the PDS database is paramount. This will require restricting update access. The role-based access infrastructure of NCR will be used to control PDS query down to the individual item level. Registration and update will require very rigorous controls, however less fine grained.

The PDS has a provision for anonymised and pseudo-anonymised clinical information to support research, surveys etc. To support such services the PDS is able to deliver, for instance, the identities all patients living in Cornwall in a certain age range etc. Appropriate anonymisation and pseudo-anonymisation process are applied as part of the extraction process. Some such requirements remain identifiable, for instance for public health.

2.3 Spine Directory Services (SDS)

The SDS contains a unique ID for NHS resources (e.g. staff members and organisations). It consists of 2 parts: a National Register of Healthcare Professionals and a register of Healthcare Organisations.
  • The National Register of Healthcare Professionals provides a listing of each member of staff’s unique ID number and a code representing their authority to request/justify/authorise and/or reject a particular diagnostic examination or groups of them. It also copes with ‘locum’ employment, sometimes on short notice contracts.
  • The register of Healthcare Organisations contains a unique identifier for each Healthcare Organisation, sub-organisation/speciality and for each sub-organisation site. Examples include identifiers of Practices, clinics, an Acute Trusts, Diagnostic Imaging Departments and sites.
Next to the identifiers the full address details are also listed in the SDS.

2.4 National Care Record (NCR)

The NCR contains some of the clinical data. These include Clinical Summaries, Encounters, Episodes, Diagnoses and Family History. The NCR also notifies provider applications of Clinical Alerts. The NCR aims to be a Summary Care Record. The Detailed Care Record contains more detailed information and will be held at the local level where most healthcare is administered. In other words: the NCR holds a summary of clinical and associated information, or is aware of information in a provider's local system. The Spine architecture states that it should be fully transparent to a querying system if information is held locally in NCR or remotely in a local system.

If information is not available in a local system, a query would be generated to NCR - a NCR Query. If the information is held on NCR it would be returned to the local system. If all or part of it is on another local system, the Spine would obtain the information from that system and return it to the requesting system: this process is called drill-down. An example of this is a radiological image held on a PACS system: it would be impractical to hold the image on NCR, but NCR should be aware of its existence and location. [Spine, section 2.4.5]

During the various phases of implementation, NCR may contain varying amounts of data. For example, in the early stages where local systems may not be fully integrated, more data may be stored on the Spine - the "thick Spine". During later phases the degree of integration will be much higher and the amount of information held on the Spine smaller - the "thin Spine". Therefore the actual location of a type of information will change over time, increasing the need for the process to be transparent to the user. [Spine, section 2.4.5]

Initially the NCR will contain only the GP (General Practitioner) part of the Summary Care Record. The GP Summary Record will be derived from practices which have a National Programme compliant clinical computer system and with data that meets defined quality criteria. The data quality will have to be assessed and approved before a practice can upload its patient’s data. If these two criteria are met, a summary of patient data can be uploaded to the SPINE. This summary will initially include major diagnoses, major procedures, current and regular prescriptions, drug allergies, adverse reactions, and drug interactions. Whenever any significant data is changed on the GP clinical system, a new summary will be generated and this will be uploaded to the NCR. Older versions of the summary, although needing to be held on the NCR for medico-legal reasons, will be hidden from view.

The NCR/PDS information is either updated by means of

  • an implicit update, with the TMS extracting the information from a flow between local systems, a local system sends information in a flow to another local or national system, and causes the NCR to be updated. Example: Electronic Transfer of Prescriptions (ETP) enables prescribers to create and transfer prescriptions electronically to a patient's community pharamcist and the Prescription Pricing Authority (PPA). It will also ensure that prescription information is updated in NCR.
  • an explicit update, if the information would be of relevance in the clinical summary, but would not normally be sent to another local or national system, e.g. an allergy. In terms of the HL7 version 3 standard the explicit update increasingly relies on the use of HL7 v3 document (CDA) standard.
The NCR will notify relevant parties of clinical alerts. These are sent to clinical systems, and possibly directly to patients. The alert information will be stored on NCR and presented as part of the Clinical Summary. Alerts may be detected by the NCR application, or a healthcare provider may wish to alert other healthcare providers of an alert that was discovered locally. Examples include overdue mammogram, medication or dietary supplement interaction.

2.5 Legitimate Relationship Service (LRS)

In NHS, the patient's consent is required for care professionals to view their NHS Care Record. The LRS controls the access rights on a patient's clinical data. The LRS will provide a single log-in and a record of each healthcare professional accessing a patient's NHS Care Record. All information will be provided on a need-to-know basis and based on user's role 'legitimate relationship' with the patient. It will store details of those relationships between healthcare professionals and patients, as well as patient preferences on information sharing. For example, a GP will see most things, a user in Acute Trust will only see what is applicable to them, a healthcare worker in an emergency room will be able to see most things for a time limited period, other users will have more restricted access to clinical data. The LRS forms the core of a role-based access control mechanism.


3. Common applications & services

A number of services are offered at a national/regional level to all healthcare providers. These services are not part of the Spine.

3.1 Clinical Spine Applications Service (CSA)

In the early stages of NCR implementation, healthcare professionals will not have access to the Spine via their local systems; the systems will not be “Spine-enabled”. They will still require access to data held on NCR and PDS, and to be able to amend and update it. The CSA (a web front-end) allows healthcare professionals to have access to the NCR/PDS data. The CSA can't be used to communicate with Local systems or other Common Applications & Services. This service is meant to be used by all healthcare professionals other than the patient.

3.2 myhealthspace

Myhealthspace (a web front-end) allows the patient to have access to their NCR/PDS data. Myhealthspace can't be used to communicate with Local systems or other Common Applications & Services. This service is meant to be used by patients only.

3.2 e-Booking service (eBS)

The Electronic Booking Service (eBS) provides a mechanism for GPs and other primary care staff to register a request for a service for a patient and either book an appointment there and then or allow the patient to book a suitable appointment themselves at a later date through a number of routes.

3.3 Terminology Server

Messages will make use of standard structured vocabularies wherever possible. This will involve clinical terminologies already stated as NHS standards, such as SNOMED CT, administrative terminologies, such as the Data Dictionary, and the HL7-defined vocabulary domains. A terminology translation service is provided as part of the NHS infrastructure. Organisations must ensure that their respective systems employ this service to ensure that translations between different terminologies are performed in a consistent manner.

4. Local Systems

Local systems must be "Spine-enabled", i.e. the local application must be modified to supports the communication roles and flows required. Examples include GP, Acute, Community, Mental health and Social Care IT systems.

It is the responsibility of the Local System to use NHS standard identifiers and clinical terminologies in messages. Any translations/mappings of local identifiers or codes have to be performed by the local system prior to any message communications to the Spine or Common applications & services.

5. Conclusions

The Spine appears to be based on a fairly mature architecture. It has yet to be seen how closely the implementation of the architecture is linked to the centralized organisation of the NHS; this particular architecture may be hard to implement in other European countries. For example, the Dutch national infrastructure [AORTA whitepaper] is based on a "thin Spine" because of privacy laws and decentralized management of healthcare in general.

6. Acknowledgements

We'd like to thank the members of HL7 UK for their comments on draft versions of this whitepaper.

7. References

[HL7v3] "HL7 Version 3", HL7 Inc. http://www.hl7.org/
[SPINE] "Domain Scoping Report - Spine v1.0", NHS NPfIT, 2003 http://www.hl7.org.uk
[AORTA whitepaper] "AORTA, the Dutch national infrastructure: a whitepaper.", Ringholm, 2007 http://www.ringholm.com/docs/00980_en.htm


About Ringholm bv

Ringholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards.
See http://www.ringholm.com or call +31 33 7 630 636 for additional information.