The Spine, an English national programme.
The contents of this whitepaper are public domain.
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. IntroductionThe 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.
Figure 1. Spine architecture
The Spine consists of the following major components:
2. Spine componentsThe 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:
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.
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
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 & servicesA 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 myhealthspaceMyhealthspace (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 ServerMessages 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 SystemsLocal 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. ConclusionsThe 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. AcknowledgementsWe'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 bvRingholm 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.