Requirements for SUS users

SUS is currently only directly available to NHS organisations (or their information suppliers such as shared information services) and to a limited number of staff in each organisation. In order to access this information, users must have a Smartcard with the correct business functions assigned by their local RA (Registration Authority).

To obtain a Smartcard, users must contact their local Registration Authority (RA), who is responsible for issuing cards. The RA will enter the users’ details on the NHS Care Record Service User Directory, known as the Spine User Directory (SUD) and the user will receive a Unique User Identifier (UUID). The record relating to the new user on the SUD will contain details of the organisation the user works for or is acting on behalf of, for example. for a shared Informatics service. 

User Role Profile (URP)

Users must contact their local RA and a registration form must be signed off for users to be assigned the required SUS Business Functions (BFs) by the RA. The RA will then update the Spine Directory Service (SDS) with the business functions to create the users URP.

The following business function codes are the most common used for access to SUS.

• B0163 Access PbR (clear)
• B0164 Access PbR (pseudo)
• B1505 Access SEM (clear)
• B1510 Access SEM (pseudo)

After following the above steps users should be able to enter the SUS Portal and access data relating to their organisation.

All organisations required to send data must be registered with SUS using the SR1 registration form, available on the SUS guidance. 

You should log a new call with NSD weblog, with the completed SR1 form attached, and a request raised to process the sender registration.

The registration process ensures that the data sender, and all organisations for which they submit data, are registered with SUS.

The SR1 form includes primary and secondary email contacts that will receive notification of CDS interchange failures. It is recommended that the named contacts are staff members, directly involved in the local submission process, and who are able to take appropriate corrective action where necessary. It is important that data senders keep this information up to date and provision should be made for when named contacts are out of the office when data is submitted.

Users should complete an SR1 form if they

• have NOT sent data before
• wish to send data using a new CDS Interchange Sender Identity (EDIFACT/EDI Address)
• wish to change the registered organisation code
• wish to change contact details for email notification of interchange failure.

Data senders must notify NSD of any changes to nominated contacts. CDS Interchange sender identity In order to send a CDS Interchange, a CDS interchange sender identity is required.

CDS Interchange Sender Identity

A CDS Interchange Sender Identity is required to send a CDS Interchange. 

This comprises a 10 character EDIFACT address and a local 5 character tail specified by the data sender. The code used to manage physical interchange senders, particularly to ensure that interchanges are processed in sequence, flow blocking following an error is also managed at this level.

Most senders use the same 5-character suffix for all data, for example 00001. Some senders use a different suffix for different dataset types (APC, OP etc) or for different PAS systems. However, there are risks associated with this practice. Users are advised to make sure they fully understand the update protocols before choosing to use specific suffix identifiers.

Some senders use a different suffix for different dataset types (APC, OP etc) or for different PAS systems. However, there are risks associated with this practice. Users are advised to make sure they fully understand the update protocols before choosing to use specific suffix identifiers

Each provider should enlist the help of an XML translation service to translate the provider’s data into XML format. It is the responsibility of the XML translator to assist in obtaining and managing the EDIFACT address required by the provider.

SUS can only accept data submitted as XML (Extensible Markup Language) which is a text based language for encoding structured information. It allows consistent error checking based on NHS Data Dictionary definitions which are detailed in an XML schema.

Data senders requiring the use of an XML translation service must select a supplier from the list of accredited suppliers before they can submit data to SUS. The terms of this contract are negotiated between the sender organisation and the XML supplier.

Learn more about the Implementation guidance for XML. 

Interchanges are validated against the XML schema on submission. If an interchange passes validation it is transmitted to SUS where additional validations, referred to as SUS business rules, are performed to ensure that the data can be processed.

Definitions of the CDS types and validation rules can be found on the NHS Data Dictionary and ISB websites as follows:

• the NHS Data Dictionary describes the structure and content of each CDS type. It includes codes that denote whether data is mandatory and the level of XML validation (such as whether format or values are validated) and the SUS business rules that are applied to each data item.
• XML schemas are also available on the NHS Data Dictionary website
• changes to the definitions are documented via Information Standard Notifications (ISNs), formerly known as Data Set Change Notices (DSCNs), which can be found on the ISB website.

Providers should implement the above standards and ensure that data within the originating systems, such as PAS (Patient Administration System), are consistent with the data requirements of CDS returns.

Message Exchange for Social Care and Health (MESH) is used to transfer batch data securely to SUS. The basic unit of transfer is an interchange. An interchange is a discrete file of data which may contain one or more individual data messages (APC, OP, etc.).

Sender organisations and their XML suppliers are responsible for

• installing the MESH client
• keeping MESH up to date with new versions
• safeguarding the security of the local MESH host The MESH mailbox id must be registered as a secure, ‘authenticated endpoint’ with SUS+ (white listing) via national service desk

The MESH mailbox id must be registered as a secure, ‘authenticated endpoint’ with SUS+ (white listing) via National Service Desk. 

The current CDS version is CDS v6.2. CDS versions identify the structure and validation rules within the CDS. Each new CDS version is an enhancement of the previous version and may contain structural changes, additional or removed data items, content revisions and amendments to allowable data item formats and values.

SUS can support up to two CDS versions at any one time. Failure to submit data using a supported CDS version will mean that an interchange will be rejected.

Senders should ensure that they have sufficiently tested the new CDS version prior to submitting for the first time. The new CDS version will not be accepted until a successful interchange has been submitted. There may be a short delay between successfully testing the new CDS version and SUS accepting the new version for live data.

Data senders are therefore advised to consider submission timetable inclusion dates when moving to a new version of CDS and allow adequate time for testing the submission process before the deadline.

Once approval has been given to submit a new CDS version it is not possible to revert to the previous version.

To a large extent, the submission pattern for a data sender will be determined by the operational environment of the organisation. However, there are submission patterns which optimise SUS processing efficiency. Data senders are encouraged to limit the number of interchanges to a maximum of 10 per day.

Where larger data submissions are required, it is recommended that larger interchanges are sent, rather than more interchanges. This optimisation reduces the processing burden on the system and benefits the sending organisation and other sender organisations because interchanges can be processed more quickly.

To ensure that there is time to resubmit any rejected interchanges; users are encouraged to submit data in good time before the PbR inclusion date. The latest CDS submission timetable can be found on the SUS PBR guidance webpage. 

Submission recommendations

• submissions should be limited to a maximum of 10 per day 
• avoid submitting historic data in the week before an inclusion date. If possible, please only submit data which is pertinent to the current reconciliation and post reconciliation period in the week before each inclusion date
• when sending historic data, the most recent data should be sent first and, if possible, sent a month at a time. This will ensure the most relevant data is processed first and will be visible sooner.