|
This standard provides detail on how to connect to NHS Digital Spine Services. |
The External Interface Specification details how to connect to the NHS Digital Spine Services. It is made up of a number of parts detailing core spine subsystems and should be used alongside other specifications such as the NHS Message Implementation Manuals (MIMs), Domain Message Specifications (DMS’s) etc.
The EIS supports the legacy Interfaces to NHS Digital Spine and is currently being uplifted to the Spine-Core website for ease of access.
The EIS is made up of number individual documents, some of which have been deprecated hence will not be available. Each section is versioned separately at the last version of the EIS it was uplifted for its core content, with the whole compilation of documents uplifted to EIS 12.3 for NHS Digital rebranding.
This EIS describes the interfaces for the following national services:
Note – EIS parts 8,9 and 10 have been withdrawn and are no longer in use and Part 1 is an introduction and covered here.
All amendments to each section of the EIS are documented in EIS Part 1 - Introduction
Describes the behaviour and interface protocols for MHS nodes. MHS nodes are responsible for reliable transport of HL7/XML messages to and from NHS Digital Spine.
The NHS Digital Message Handling Service (MHS) is the service that is responsible for handling all messages sent to Spine from local applications. All senders/receivers of NHS digital XML documents and message interactions are required to implement an MHS. The MHS supports both HL7 and non-HL7 XML, each type has differences in processing requirements. The NHS Digital MHS historically referred to as the Transaction and Messaging service (TMS).
The MHS section of the EIS describes the behaviour, protocols, message formats, and service contracts that represent an MHS node communicating with NHS Digital Spine.
For legacy services, the NHS Digital Spine MHS provides 2 modes of operation; ebXML mode, and web service mode. Each mode varies in behaviour and header constructs.
Although the NHS Digital Spine interactions traversing the MHS are [HL7-ebXML] and [HL7-WS], they are not wholly conformant with them. There have been NHS-specific changes to meet specific needs.
Note the nomenclature, [ebXML-MS] uses the term Message Service Handler (MSH) to describe an implementation of [ebXML-MS]. The term used in this specification is MHS. The difference is to enforce the fact that MHS includes both ebXML MSH and web service functionality. When this specification uses the term MSH, it is specifically referring to [ebXML-MS] only.
The core Message patterns in use are:
(coming soon: message examples)
There are 3 types of synchronous messages for Web Service Mode:
Examples: PDS Simple Trace, PDS Retrieval, PSIS Event List Query
Examples: All EPS messages, PDS Update, PSIS GP Summary
Examples: All Choose and Book R1 messages
Examples: All Choose and Book R2 messages, GP2GP messages
Examples: All ERS messages
The ebXML Message Service Specification defines a set of namespace-qualified SOAP Header and Body element extensions within the SOAP Envelope. These are packaged within MIME multipart attachments to allow payloads or other related attachments to be included with the SOAP extension elements.
The (HL7 or other) messages themselves are included in zero or more additional MIME parts in compliance with SOAP Messages with Attachments [SOAP-Att]. Implementations SHOULD ensure that attachments are compliant with [WSI-ATT].
There are two logical MIME parts within the Message Package:
The SOAP header contains [WS-A] elements, while the SOAP body contains the HL7 interaction message. The binding of HL7 elements to the [WS-A] structures were derived from [HL7-WSA]. For responses, the HL7 wrapper is wrapped in a nasp element in order to aid WSDL WS-I Basic Profile compliance. Please refer to [NASP-XML] for all messages that include the wrapping nasp element.
Additional details can be found in EIS Part 2 - Message Handling Service (MHS) or the Spine Core site (coming soon)
This Message Interaction Map section of the EIS outlines HL7/Spine operational forms and message behaviour patterns of the HL7 messages defined in the MIM or DMS. Local system implementations MUST support the MHS, HL7 and Spine non-HL7 behaviours defined in this section of the EIS. The details of the interface behaviour i.e. the contract properties used in ebXML are configured in the SDS and not defined in this section of the EIS.
Each subsection defines the behavioural elements for each MIM/Spine message domain implemented in Release 2008-B. For each domain, the following is provided:
Full details can be found in EIS Part 3 - Message Interaction Map or the Spine Core Site (coming soon)
(also known as Address Finder Service)
The Gazetteer Service supports the validation or retrieval of UK-based addresses. The service will fulfil requests coming from systems external to Spine as well as those from internal clients. It is an address validation service accessing a separate address list Postal Address File (PAF)
The service requires a relatively low level of reliability and as such will implement an MHS relationship with the client in web service mode. The service will be provided via a SOAP web service defined by a WSDL.
The Gazetteer provides the following functionality to external systems:
The Gazetteer service provides various functions for validating an address based on complete/partial address lines provided by the caller subsystems. This includes:
Full details can be found in EIS Part 4 - Gazetteer Service or the Spine Core Site (coming soon)
SDS is a directory-structured facility for the maintenance and publication of reference data about
SDS is a vital component in the architecture that supports NHS Digital Spine systems and processes. As well as providing a straightforward user and services look-up facility, SDS provides accurate addressing of messaging between NHS systems.
For Suppliers of new services or applications (i.e. those which are NOT currently deployed into an operational environment), the SDS FHIR API replaces the need to implement the SDS part of this External Interface Specification Standard for accessing accredited system information and messaging endpoint details.
SDS interfaces with Spine functions such as SSB (Spine Security Broker - a single sign-on mechanism for NHS Digital Spine), CIS (Care Identity Service is previously known as Identity Management), and the ACS (Access Control Service) for Legitimate Relationships to provide authentication. Individual modules of information stored within SDS can be combined to provide extended cross-domain functionality. See Spine Core Site for more details. NB: message contract properties should be queried before an interaction is sent Example UsageReference data may be used by a system such as eRS (Electronic Referrals Service) when searching for an accredited system (service endpoint), by a Patient Administration System which needs to identify a user’s unique Spine identifier from their clinical code, or when a system needs to determine which GP Practice a GP is associated with based on their General Medical Practitioner Code. Authentication functionality provided by SDS and CIS may be used by other systems such as eRS or other systems connecting to Spine to validate access to patient records. Full details can be found in EIS Part 5 - Spine Directory Services (SDS) and practical guidance is here on the Spine Core Site Some Example SDS queries for FHIR endpoint lookup can also be found on the Spine Core site. |
The Spine Security Broker (SSB) interface Specification describes the external interfaces required by system implementers to provide for single sign-on.
The SSB provides services for the security needs of both Web-based and non-Web-based applications. It is delivered in three main building blocks.
User authentication may only occur if the User is formally registered to the Spine. User registration to the Spine includes the creation of a User profile, stored in the SDS, containing the User’s roles and other information that the Authority or Service deems necessary to make appropriate data access decisions. The figure below of the SSB Deployment Model represents a deployment model of the SSB components and shows the interfaces described in this section.
Full details can be found in:
The Spine Security Broker Application Interface details the formal specification of SSB Java and C APIs.
Full details can be found in EIS Part 7 - Spine Security Broker (SSB) API and EIS Part 6 and 7 addendum or here Spine Core Site - Smartcards and there is information about the Warranted Environment Specification.
These have been withdrawn and are no longer in use.
The ACS subsystem service part of the EIS specifically it covers the requirements for the web services to support resource-based access control maintenance and query.
The Service exposes authorisation information on Spines external interface via the following messages and is primarily used for SCR consent:
Full details can be found in EIS Part 11 - Access Control Service
SCRa is a general purpose non-business specific web application which will allow users to access a summary of a patient's Shared Patient Clinical Record clinical record. The overall functionality of the service as required in the context of external systems will be limited to the following interface:
One-click provides a method for a client system to launch SCRa in a specific patient context. It allows systems not directly integrated to the Spine messaging systems to access to the Summary Care Record and related SCRa functionality in a relatively seamless manner. It allows access only to the single patient record that is supplied as part of the initial call to CSA One-click.
When invoked through this interface the SCRa will present the user with functionality that is appropriate to their role.
Note: this functionality will be limited to that described in the 2008B CSA Sub System Requirements Specification.
Full details can be found in EIS Part 12 - One Click CSA
This is a general appendix, referenced by other sections of the External Interface Specification. It provides a list of references, acronyms and includes detailed information on message metadata.
Full details can be found in EIS Appendix A
Provides a description of the Error Base process and how to interpret error bases.
This section of the EIS details two aspects of Spine Errors:
NHS Digital services require both an interface (the interaction in HL7 terminology) and an implementation supported by a Service Provider (this can be national or local services). A service consumer holds a "service contract" with a particular version of the interface. However, the implementation can evolve independently. Service Providers are required to ensure that an interface will return exception codes applicable to that interface version (as defined in the specifications that describe the interface ) unless the following events have occurred with the implementation:
Service consumers should implement a level of abstraction between the error code and text supplied by the service, and the user. This will allow the consumer to provide context-aware reporting to the user and consuming system logs.
Full details can be found in EIS Appendix B - Errors
The validation section of the EIS records the validation rules implemented by the service provider or intermediary where applicable (SPINE) on messages entering SPINE via core message patterns. These include:
This information is provided to inform service consumers (local systems) as to the level of validation performed by the service provider (SPINE). To accurately and concisely describe validation rules XPath expressions have been maintained. Thus readers are assumed to be familiar with XPath and regular expressions.
Full details can be found in EIS Appendix C - Validation