Data sender deployment

A list of approved XML Service suppliers can be found at the end of this guidance.

Management and clinical systems collect CDS data and export it in a User Defined Format (UDF) such as in a comma separated values file. An XML middleware application translates the UDF data to XML

SUS applies additional ‘business rules’ before loading into the secure data warehouse.

Where submitted data fails XML schema checks on SUS or SUS business rule validation, SUS Service Management notifies the Data Sender and works with them until any problems are resolved. It is the responsibility of the data sender and their XML supplier to provide local error resolution address XML validation and business rule failures.

Workflow ID for SUS+ submission via MESH is SUS_CDS  CDS interchange receiver id is 260000001200001. SUS+ receiver MESH mailbox is X26HC023.

General XML submission model  

Locally installed service

A provider hosts the XML translation middleware and MESH locally. Management of the XML solution may be local or operated remotely by the software supplier.

Bureau service

The XML supplier hosts the translation middleware and MESH at their data centre and the provider sends UDF files to the bureau for validation, translation to XML and submission to SUS.

LSP model

The management and clinical systems are hosted in the LSP’s data centre where the CDS data is created. The data is sent to the trust for review (and possible addition of data from local systems) before being returned to the LSP data centre for MESH transmission to SUS

Each CDS-XML data flow must be made via a supplier who is responsible for the conversion of data to CDS-XML.

Requirements

Before the process can begin the data sender must have:

• contracted a supplier to manage the CDS-XML translation and submission via MESH or confirmed they will undertake the role of supplier
• registered their 15-character EDI address as a data sender. Providers only need to register if they are not currently registered, or their registration information has changed (e.g. contact details). Please use this opportunity to review the registration
• appropriate SUS Access business functions assigned to a smartcard

To inform NHS Digital that you wish to start LIVE XML submissions, please email National Service Desk with the following information:
To: [email protected]

Subject:    Begin LIVE CDS-XML body
Name:
Email:
Phone:
XML software name/version:
XML software supplier name/contact:
First submission date:
The EDI Address(es) to be migrated are:
EDI Address (15 Character):
Organisation name:
Organisation NACS

CDS Data senders are registered by EDI address. To register a CDS-XML data flow, or to update registration details, please complete the SR1 Secondary Uses Service, CDS Data Sender Registration Form available on the SUS Guidance webpage.

A CDS Interchange Sender Identity (10 character EDI address) can be obtained from the NHS address registration service.
 

Although CDS-XML is not an EDI flow, SUS continues to use the existing EDI addresses to manage interchange receipt. The CDS Interchange Sender Identity is used to identify the organisation that submits an interchange. It is a 10-character EDI id with a 5 character ‘local tail’ making a total of 15 characters. Typically, it might look like 190000099900001 where 1900000999 is the EDI identifier and 00001 is the ‘local tail’. A single MESH client may send interchanges from multiple EDI addresses and different MESH clients may send data from the same EDI address.
 

The first 10 characters are mapped to a registered ODS code. On receipt of an interchange the 10 characters are used to look up the ODS code, If no registered ODS code is found the interchange is rejected.

Where the interchange is accepted, if the interchange fails validation, notification messages are sent to the individuals registered against the mapped ODS code.

This SUS ODS table is maintained at three characters for Trusts – Rnn, Care Trusts – Tnn and 5 characters for non-NHS senders  NAnnn). With XML, although mapping is made at the 10-character level, all 15- character EDI addresses must be registered. If the 15-character codes are not registered, the interchange will be rejected.

CDS Interchange Sender Identity (EDI Address) is used to sequence data at the 15-character level. SUS processes interchanges in the order received from the MESH client.

Following validation errors, SUS blocks processing of interchanges for the affected 15-character CDS Interchange Sender Identity (EDI Address). Processing will not resume until the helpdesk is informed by the registered contact that they understand the failure and will take appropriate action. The blocked queue is irrespective of CDS type.

Request conflicts in EDI address migration have highlighted issues around organisations using a single EDI address to send data from multiple sites. For example:

• a clinic is hosted at a partner hospital site
• a hospital system sends data on behalf of a number of local providers

The configuration and use of interchange flows via MESH and EDI addresses is a local matter. However, it is recommended that logically distinct flows employ separate EDI addresses.

The potential impacts of sharing a 15- character CDS Interchange Sender Identity across multiple CDS flows include:

Delayed processing

Only one interchange within a sequence from the same ID can be processed at a time.

Blocked processing

This follows a validation failure for the Sender ID. (A major hospital flow could be interrupted by errors in another provider’s submission via the same Sender ID).

Difficulty managing multiple contacts 

Multiple contacts may exist for a single sender and it may become complex to ensure that all users are aware of failures and submission issues.

Please ensure the migration of shared EDI address is coordinated between all senders.

SUS adheres to the rules set out by NHS Data Standards and documented in the NHS Data Dictionary. The Data Standards helpdesk email address is [email protected].  Alternatively, contact Data Standards via: [email protected]. 

There are 2 levels of validation applied to interchanges they are:

XML schema validation is applied at SUS+ landing. Before sending an interchange, users are advised to validate the interchange against the appropriate XML schema locally.

SUS business validation applied at the SUS server. Following receipt of the interchange, a number of ‘business’ validations are applied. If the interchange fails any of the validations it is rejected, and a notification is sent to the registered user(s). A single error will cause failure of the entire interchange.

Details of the validation applied at CDS attribute level and the Mandatory/Optional status of each attribute can be found in the NHS Data Dictionary in the Commissioning Data Sets section.

SUS uses 2 update submission methods; ‘bulk update’ and ‘net change’. Both of these support updates based on a composite key which uniquely identifies a record. 

Bulk update does not require records to be assigned a unique key, updates are made in date delimited blocks.

Net change does require each record to be maintained with a unique identifier, the updates are based on the unique id. The updates keys are

 Sender Code (Organisation)
<OrganisationCode_CDSSenderIdentity>

Bulk Replacement CDS Group<CDSBulkReplacementGroup>

Report Period Start Date

<CDSReportPeriodStartDate>

Report Period End Date
<CDSReportPeriodEndDate>

Sender Code (Organisation)

<OrganisationCode_CDSSenderIdentity>

Record Identifier

<CDSUniqueIdentifier>

Note that any changes to keys when attempting to update a record will cause a new record to be created, and duplication within the SUS database.

CDS data senders can send test interchanges to SUS+ by submitting a “1” in the CDS INTERCHANGE TEST INDICATOR. Test interchanges are processed by SUS+ and can be seen in the SUS+ Portal Interchange Tracker. Test interchanges will always have a zero-record count on Tracker due to no records being committed to the SUS+ live database.