Guidance on prevention and removal of duplicated data on SUS
Programme
Sub-Prog
/
Project
Prog. Director
Owner
Author
NPFIT
Secondary
Uses Service
J Thorp
Lorraine Gray
Anne
Coulton/Julie
Clough
Document Record ID Key
NPFIT-TO-BAR
Version
Status
1.4
FINAL
Version Date
July 2011
Secondary Uses Service (SUS)
Guidance on Data Duplication
Version 1.4 July 2011
V
February 2007
© Crown Copyright 2016
Page 1 of 14
Amendment History:
Version
Date
Amendment History
0.1
1.0
1.1
1.2
1.3
1.5
05/11/2007
28/08/2008
12/03/2009
02/07/2009
08/07/2010
01/07/2011
Document created - AC
Document updated to allow for Tactical Data Deletion Service - JC
Document updated to allow for Strategic Data Deletion Service - JC
Authorisation form updated - JC
Net change updated following SUS release 6 improvements - DO
Encorporate changes to CDS V6.1 and update hyperlinks
Forecast Changes:
Anticipated Change
When
Reviewers:
This document must be reviewed by the following:
Name
Signature
Title / Responsibility
Date
Version
Lorraine Gray
1.1
Julie Clough
1.1
Mark Carr
1.0
Approvals:
This document must be approved by the following:
Name
Signature
Title / Responsibility
Lisa Franklin
Date
Version
1.0
1.0
Distribution:
SUS Website
Document Status:
This is a controlled document.
Whilst this document may be printed, the electronic version maintained in FileCM is the controlled
copy. Any printed copies of the document are not controlled.
Related Documents:
These documents will provide additional information.
Ref no
Doc Reference Number
Title
Version
Glossary of Terms:
List any new terms created in this document. Mail the NPO Quality Manager to have these included in
the master glossary above [1].
Term
Acronym
Definition
© Crown Copyright 2016
Page 2 of 14
Contents
Contents ...................................................................................................................................... 3
1. Introduction ........................................................................................................................ 4
1.1
About this document .................................................................................................. 4
1.2
Audience ..................................................................................................................... 4
1.3
Background ................................................................................................................ 4
1.4
Purpose ....................................................................................................................... 5
2. Processing data for SUS ..................................................................................................... 5
2.1
CDS submission process ............................................................................................ 5
2.1.1
Recording activity data ....................................................................................... 5
2.1.2
Preparing CDS data ............................................................................................ 5
2.1.3
CDS message translation .................................................................................... 6
2.1.4
Transmission and loading CDS data into SUS ................................................... 6
2.2
CDS submission protocols ......................................................................................... 6
2.2.1
Update mechanisms available for SUS .............................................................. 6
2.2.2
Net change .......................................................................................................... 7
2.2.1
How net change protocol works ......................................................................... 7
2.2.2
Net change protocol – update fields used by SUS ............................................. 7
2.2.3
How to avoid data duplication............................................................................ 8
2.2.3
Bulk Replacement .............................................................................................. 9
2.2.1
How bulk protocol works ................................................................................... 9
2.2.2
Bulk change protocol – update fields used by SUS ......................................... 10
2.2.2
How to avoid data duplication.......................................................................... 11
2.2.4
Sub-contracting ................................................................................................ 12
2.2.5
CDS data flows to support PCT mergers ......................................................... 12
3. Anticipating possible causes of duplication ......................................................................... 12
4. Strategic data deletion service .............................................................................................. 14
5. OLA Targets ......................................................................................................................... 14
© Crown Copyright 2016
Page 3 of 14
1.
Introduction
1.1
About this document
This guidance document describes the process to prepare commissioning datasets (CDS) for
submission to the Secondary Uses Service (SUS), and explains how records can be
duplicated on SUS if the data dictionary rules are incorrectly applied by CDS senders. It
provides details on how to avoid data duplication and details how a CDS sender can request
data deletion when duplication has occurred.
Although some of the following concepts are covered, to fully understand this document you
should be familiar with the items:
 Secondary Uses Service (SUS)
 Commissioning Data Sets (CDS)
 Organisation Data Services (ODS) – formerly NACS, OCS
 CDS Sender organisation
 CDS Unique Identifier
 CDS Sender XML translation application
 CDS Authentication
 CDS Submission protocols – NET and/or BULK
 Separation in time of organisation merge and associated technology infrastructure
merge
 Role Based Access Control (RBAC) functionality and access to SUS
 Access to SUS online extracts
 Patient Administration System (PAS)
1.2
Audience
This document is intended for all members of staff in CDS sender organisations who
prepare/extract data for CDS interchanges for submission to SUS.
The guidance may also be relevant for suppliers of PAS systems and other systems used to
generate or populate data for inclusion in the CDS messages, and for suppliers who provide
the middleware application to translate CDS records into XML for transmission to SUS.
1.3
Background
Data sending organisations are owners of data held within SUS and should be possible for
them to manage their data in SUS using the existing NET and BULK protocols of data
submission. But, on some occasions this is not possible due to reorganisation (merges/demerges) and issues arising out of changes to local PAS systems leading to data duplication.
This may result in inflated values of overall business measures getting reported. Hence, there
is a need to identify & remove this duplicate data at an early stage of SUS processing so to
ensure that data present across downstream systems like SEM, PbR, and MH is correct.
A Strategic Data Deletion Service is available in SUS which allows organisations to request
removal of duplicate CDS and MHMDS data.
1.4
Purpose
This guidance is intended to support senders of data to SUS in successfully addressing the
problem of data duplication. It aims to give senders of data an increased awareness of what
causes duplicates on SUS, and particularly, factors that result in incorrect application of the
submission protocols.
The Strategic Data Deletion facility enables senders to take action to remove duplicates
where those have been created in order to restore integrity of the data at the earliest
opportunity. It may not always be possible to remove duplicates in time with this service if
they have been created close to a deadline (Please see latest PbR Submission Timetable on
the Payment by Results Guidance IC webpage). I.e. the deletion service will not be a
replacement for good practice.
2.
Processing data for SUS
2.1
CDS submission process
This section provides an overview of the process involved in submitting CDS data to SUS. It
focuses particularly on the elements of the process which impact upon the integrity of the
CDS message processing and factors which, if not carefully managed, can result in
duplicated data on SUS.
The specific processing activities will vary from provider to provider. There may also be
varying levels of intervention by providers who process other providers’ CDS data, and where
the service delivery and subsequent processing of the activity is sub-contracted to a different
organisation to the provider responsible for the activity.
2.1.1
Recording activity data
Healthcare providers record data on healthcare activity on their PAS or other local system
solutions. Data to be included in CDS submissions to SUS may be sourced from several
systems including clinical systems in the provider, for example: maternity, A&E and ITU
systems.
Providers should strive for all data to be as comprehensive and accurate as possible,
including the patient demographic data. Recording the correct postcode is especially
important in the reporting process to SUS as it will be used to derive the PCT of Residence
which determines the CDS Prime Recipient identity. The prime recipient field is one of the
BULK update keys in the SUS validation routines (see section 2.2.3). Data senders also need
to be aware, however, that updating a patient’s postcode when recording a change of
address may cause a change in prime recipient which can result in duplication of that
record on SUS when the CDS is updated using BULK replacement. It should be noted
that where an address changes locally and there are other records with the same prime
recipient this should not be an issue. Duplication is usually only a problem where there is only
one occurrence of a PCT in the data and when the PCT is changed there is no deletion
message.
2.1.2
Preparing CDS data
The next stage of data processing is the preparation of the data for the CDS submission.
Those providers who submit their data to SUS via a third party will pass their activity data to
the third party organisation to prepare the CDS for SUS processing and submission.
The CDS data preparation will take many different forms dependent upon local arrangements
and systems. One model is where the CDS preparation takes place in the Local Service
Provider data centre and the role of the provider is in reviewing the data before returning it to
the data centre for transmission to SUS. The routines involved in preparing the CDS will take
account of data derivation for fields required to ensure the appropriate commissioning bodies
can retrieve data from SUS.
In most instances the processes and procedures for preparing CDS data is automated,
however staff involved in the process must ensure that:
 CDS data items are conformant with the data standards as defined in the NHS Data
Model and Dictionary
 CDS messages carry the information required to derive the CDS interchange header
 CDS messages carry the information required to derive the CDS message header
 CDS messages carry the information required to identify the CDS transaction header
Information on the above information standards can be found at:
http://www.datadictionary.nhs.uk/web_site_content/navigation/commissioning_data_sets_me
nu.asp?shownav=1
Understanding which data elements in the CDS transaction header act as update keys, and
how to apply the rules in the SUS submission protocol, is of fundamental importance in
managing data processing for SUS. Incorrect application of the SUS submission protocols will
result in interchanges failing validation, duplication, deletion or corruption of data on the SUS
database. It is vital that individuals preparing the CDS have a good level of
understanding of the CDS submission protocols, and an awareness of changes in
recorded data that might impact on the rules applied, such as changes of postcode
potentially resulting in changes to prime recipient. Section 2.2 describes how the
protocols work, and specifically, what can cause data duplication.
On completion of data processing, data to be included in CDS reports to SUS are usually
exported in a user defined format, such as a comma delimited file, for translation to XML.
2.1.3
CDS message translation
A middleware application translates the CDS data to XML using the relevant CDS-XML
message schema. There can be different arrangements for the translation service. It may be
managed off site by use of a managed bureau service or locally on site by the provider’s use
of a local XML translations solution.
The system suppliers of the middleware application will advise providers of the format in
which the CDS data must be formatted to enable translation into XML. The suppliers are
responsible for the system solution and its integration with the External Transfer solution
(EDT) including the registration of EDT as an NCRS ‘Authenticated End-point’.
2.1.4
Transmission and loading CDS data into SUS
The XML files containing the CDS data are passed to the EDT which re-validates the XML
data (currently as either CDS-XML version 6 or version 6.1), and if the application is
successful, transmits the file to SUS. SUS then applies additional ‘business’ validations
before loading to the secure data warehouse.
2.2
CDS submission protocols
2.2.1
Update mechanisms available for SUS
As stated in section 2.1.2 earlier, successful CDS message updating and integrity of
providers’ data on SUS is dependent upon the data senders correctly applying the update
rules which form the ‘CDS submission protocols’ for SUS. The two available mechanisms of
the protocol are NET change or BULK replacement.
NET change supports the management of an individual record, i.e. a CDS type in the SUS
database and enables individual records to be inserted, updated or deleted.
BULK replacement supports the management of BULK data for an identified BULK
replacement group of data for a specified time period and for a specified CDS prime recipient.
BULK replacement is more likely to result in duplication of data than NET change (see
section 2.2.3) Data senders are therefore strongly advised to use NET change wherever
possible as the preferred Submission Protocol.
Each CDS transaction header contains the data elements which function as update keys in
accordance with CDS Type and the associated rules of the NET change or BULK
replacement protocol.
2.2.2
NET change
2.2.1
How NET change protocol works
For NET interchange records the CDS Sender Identity, Unique CDS Identifier and CDS
Applicable Date and Time are checked against SUS and then applied according to CDS
Type.

For CDS Update Type = 9, if a Unique CDS Identifier is not on the database for that
CDS Sender Identity, then the record is added

For CDS Update Type = 9, if the system finds one or more records for the same CDS
Sender Identity with the same Unique CDS Identifier, then it will replace them with
those in the interchange if the CDS Applicable Date and Time is later than or equal to
the CDS Applicable date and Time on the existing record

If a record with matching CDS Sender Identity and Unique CDS Identifier has
previously been sent as BULK then the CDS Applicable Date and Time will be
compared to the CDS Extract Date and Time on the existing record
It is possible to send a NET delete record, CDS Update Type = 1; this will delete a record if it
finds a match in the database with the same CDS Sender Identity and Unique CDS Identifier.
2.2.2
NET change protocol – update fields used by SUS
Data Item
Format
Description
CDS INTERCHANGE
SENDER IDENTITY
an15
The assigned EDI Address of the physical
ORGANISATION or site responsible for
sending Commissioning data.
CDS SENDER
IDENTITY
an5
The identity of the organisation acting as
the Sender of a CDS submission and is
represented by that organisation’s code
CDS UNIQUE
IDENTIFIER
an35
A CDS data element providing a unique
identity for the life-time of an episode
carried in a CDS message.
The date (with an associated CDS
APPLICABLE TIME of the update event
(or the nearest equivalent) that resulted in
the need to exchange this CDS.
The time (with an associated CDS
APPLICABLE DATE of the update event
(or the nearest equivalent) that resulted in
the need to exchange this CDS.
CDS APPLICABLE
DATE
CCYY-MM-DD
CDS APPLICABLE
TIME
HH:MM:SS
CDS UPDATE TYPE
an1
9 for insert or update, 1 for a delete
CDS TYPE
n3
The code to identify the specific type of
Commissioning Data Set data
There are a few CDS types where the NET change protocol will update/delete an existing
record containing a different CDS type. These are listed in the table below:
Incoming CDS Type
Existing CDS Types that incoming CDS type will
overwrite
120
120, 180
130
130,140,190,200
140
130,140,190,200
180
120, 180
190
130,140,190,200
200
130,140,190,200
For all other CDS types (listed below) the NET change protocol will only update/ delete an
existing record containing the same CDS type:
Incoming CDS Type
010
020
021
030
040
050
060
070
080
090
100
110
150
160
170
210
2.2.3
How to avoid data duplication
In summary, the protocols for operating NET change and avoiding data duplication are:

The CDS sender identity must not change during the lifetime of the CDS data. This
means that exactly the same sender identity code must be used for each update of the
CDS, and there must be no change, even in circumstances such as:
o
a change to the code for the sender organisation as a result of organisational change
or mergers. This could be represented in the CDS field ‘Organisation Code_Code of
Provider’, but to maintain the integrity of the CDS data the CDS record must retain
the originally allocated CDS Sender Identity
o
new local systems set up to support the CDS production which have resulted in a
change in the output used to create the sender identity, eg: from 3 to 5 characters.
Note: in the NET change protocol Rnn is a different code to Rnn00, and Rnn01 is
different to both.
o
recording site information at 4th and 5th character level in the CDS sender identity
field in the header which was not previously in the sender identity code.

Each CDS type must have a CDS unique identifier which must be maintained uniquely
and not changed for the lifetime of that CDS.

A CDS delete, CDS Update Type = 1, must be sent to SUS when any CDS previously
sent requires deletion/removal.
2.2.3
BULK Replacement
2.2.1
How BULK protocol works
Within an interchange, SUS will identify each CDS Sender Identity counting all 5 characters
and each CDS Prime Recipient Identity taking all 5 characters into account. Please note that
code Rnn is different from Rnn00 and both are different from Rnn01.
SUS then scrutinises the report start and end dates and checks the existing database for
each pair. If the same pair has
1. not previously sent data for the CDS REPORT PERIOD START DATE and
CDS REPORT PERIOD END DATE. The records will be applied to the database –
this is even if data for the same period has been sent e.g. if data is sent for 1st May
to 31st May then resent with an earlier extract date but for the 1st May to the 30th
May the interchange will be applied deleting later records, except for the ones on the
31st May.
2. previously been sent for exactly the same report period start and end dates SUS will
check the CDS EXTRACT DATE and CDS EXTRACT TIME. If this date is greater or
equal to than any interchange previously applied to SUS, the interchange will be
applied to the database. However if the extract date and time is less than any
interchange previously processed by SUS, the interchange will be ignored. These
interchanges are identified in the Tracking module of SUS as ‘Invalid’
When an interchange is applied, all the matching data in the database is deleted between the
report start and end date if the CDS Extract Date and Time is later or equal to that of the
existing records in the same CDS report period. The records in the BULK interchange are
then inserted. Matching records have:

The same BULK Replacement Group (BRG)

The same CDS Sender Identity and CDS Prime Recipient Identity pair

A CDS Activity Date (episode end date for FCEs) between the CDS Report
Period Start and End dates in the new interchange
Supported Bulk Replacement Groups (BRG) documentation is available under Section 'SUS
Operational Support: Submitting Data' of the IC Guidance and Other Useful Documents
Section.
New Sender/Recipient pairs within the report period date range are inserted as new records.
Any change to the CDS Sender Identity of an existing record will therefore cause duplication
on SUS.
Routine events such as a patient changing address in the lifetime of a CDS may result in a
change of Prime Recipient when a different postcode is used, as the Prime Recipient is
derived from the postcode. Therefore, there is an ongoing risk that incorrect use of BULK
update will result in duplication of data on SUS.
There are discussions to remove Prime Recipient from being a key field for BULK update.
This has not been implemented at the time this document was released.
2.2.2
BULK change protocol – update fields used by SUS
The BULK replacement protocol updates on date-delimited groupings of CDS data.
Data Item
Format
Description
CDS INTERCHANGE
SENDER IDENTITY
an15
The assigned EDI Address of the physical
ORGANISATION or site responsible for
sending Commissioning data.
CDS SENDER IDENTITY
an5
The identity of the organisation acting as the
Sender of a CDS submission.
CDS BULK
REPLACEMENT GROUP
an3
The CDS Group into which CDS Types must
be grouped when using the CDS BULK
replacement update mechanism
CDS EXTRACT DATE
an10 ccyy-mm-dd
The date (with an associated CDS EXTRACT
TIME) of the update event (or the nearest
equivalent) that resulted in the need to
exchange this CDS
CDS EXTRACT TIME
HH:MM:SS
The time (with an associated CDS EXTRACT
DATE) at which the CDS extract was
undertaken.
CDS REPORT PERIOD
START DATE
CDS REPORT PERIOD
END DATE
an10 ccyy-mm-dd
an10 ccyy-mm-dd
CDS PRIME RECIPIENT
IDENTITY
an5
CDS ACTIVITY DATE
an10 ccyy-mm-dd
This defines the start date (for the date range
of the data being exchanged) for the BULK
replacement update time period.
This defines the end date (for the date range
of the data being exchanged) for the BULK
replacement update time period.
The mandatory 5-character NHS organisation
code (or valid default code) representing the
organisation determined to be the CDS prime
recipient of the CDS Message, as indicated in
the CDS Addressing Grid detailed in the NHS
Data Dictionary – Commissioning Data Set
Overview. This is commonly the PCT of
Residence identified in the CDS record.
"CDS Originating Date" specifically identified
for each CDS TYPE
2.2.2
How to avoid data duplication
Incorrect use of Report Period Start Date may result in duplication or loss of data within SUS.
E.g. A trust wishing to submit APC data for Episodes ending April 2009 – March 2010 should
enter Report Period Start and End Dates as 01/04/2009 to 31/03/2010 respectively,
regardless of when their earliest admission date is.
If the same sender/prime recipient pair have been sent for the same report start and report
end dates, but the extract date/time is earlier than a previous interchange, the interchange
will be ignored (not applied).
If the same sender/prime recipient pair have been sent for the same report start and report
end dates, and the extract date/time is the same or later than a previous interchange SUS will
apply the interchange. This will delete all previous records for the same CDS sender and
prime recipient pair which have an activity date within the report start and end dates, and
insert the records in the new BULK replacement interchange. Note that a single CDS record
may therefore result in the deletion of many CDS records previously stored in the SUS
database.
If the report start and report end dates have not been sent before, the interchange will be
applied, even if data for the same period has previously been sent. This means that if data
are sent, eg: for 1st May to 31st May, and then re-sent with an earlier extract date but for 1st
May to 30th May, the interchange will be applied, deleting the later records already applied
even though these relate to the later extract date, although the records for 31st May will be
retained. Hence, it is vital that the report start and end dates for updates for the applicable
date range are consistent.
If the CDS sender identity or CDS prime recipient identity are changed for records previously
submitted, the BULK replacement interchange will not delete those records, and they will be
duplicated.
In summary, the protocols for operating BULK replacement and avoiding data duplication are:

The CDS sender identity must not change during the lifetime of the CDS data. This
means that exactly the same code must be used for each update of the CDS, and there
must be no change, even in circumstances such as those listed above (section 2.2.2)

The CDS prime recipient identity must be identified in each CDS and must not be
changed during the lifetime of the CDS.

The CDS report period start date and report period end dates used for the same BULK
replacement group of data must be valid and consistent, and reflect the dates relevant to
the data contained within the interchange.

Every CDS type must be submitted using the correct CDS BULK replacement group.
There may be circumstances in which the data sender may want to send corrections to the
CDS record, such as changes to a patient’s postcode when recording a change of address.
This can result in the assignment of a different PCT of Residence which may then used to
derive the CDS Prime Recipient resulting in duplication of that record on SUS when the CDS
is updated using the BULK replacement protocol. Data senders should contact the BT
helpdesk (bt.sus.helpdesk@bt.com) for advice before sending the data to SUS.
Data senders are therefore advised to use NET change as the SUS submission protocol in
preference to BULK replacement. Data senders who wish to move from BULK to NET should
maintain the CDS unique identifier as a unique record within the CDS interchanges. This
does not function as an update key in BULK replacement, however if a sender intends to
migrate to NET change this will enable the application of NET change functionality on data
previously submitted in BULK from the same CDS sender identity.
However, it is not advisable to mix NET change and BULK replacement for CDS for the same
sender organisation and site code, as this can also result in data duplication and inadvertent
deletion.
2.2.4
Sub-contracting
If a provider sub-contracts healthcare provision and its associated CDS submissions to
another provider or local IT consortium, arrangements must be in place to ensure that the
correct use is made of the CDS sender identity field. It is important that the second provider is
fully aware of the protocols already in place for CDS submissions for the first provider, and
the key fields required to retain data integrity are supplied consistently and correctly in any
updates of CDS data.
If the second provider wishes to add other/new CDS data to SUS for the first provider, both
parties need to ensure that a different CDS sender identity is used. Often this is done by
changing the last two digits of the 5-digit code (the site element of the organisation code).
Note: data sent using the same CDS sender identity by two different parties will overwrite
data in the SUS database.
2.2.5
CDS data flows to support PCT mergers
Following organisational mergers there may be a requirement to change from multiple data
flows to a single data flow. In these instances often IT systems and facilities may not have
immediately merged. In these instances the submission of CDS data, can still be set up to
flow from multiple sites and senders, by applying an update with the new organisations
registered ODS code. However these scenarios require careful management to avoid
inadvertent duplication or deletion of records in SUS.
Data senders in those instances are advised to use NET change wherever possible in
preference to BULK replacement as data integrity is easier to sustain using NET than BULK.
When using NET change, multiple data flows from different sites or systems using the same
CDS sender identity must ensure that a CDS unique identifier is maintained uniquely for each
CDS.
When using BULK replacement, senders must not make multiple data flows from different
organisational sites or systems using the same sender code and provider site code, or the
interchanges will conflict and overwrite each other, causing corruption of data on SUS.
Instead, to prevent this happening, individual sites and systems within an organisation must
use a unique sender code and provider site code combination for CDS submissions to SUS.
This can be achieved by using provider and site codes already registered with the
Organisation Data Service (ODS) which will differentiate multiple CDS data flows for the
same provider by using the last 2 digits of the organisation code.
It may be necessary to avoid changing processes for multiple flows at the end of the financial
year, and retain the previously used CDS submission protocol for data submitted earlier in the
year, until the organisation has completed any refresh of the data for the previous financial
year. This is to ensure that there is a complete set of data for that year for PbR and for HES.
3. Anticipating possible causes of duplication
Data senders can take steps to avoid data duplication on SUS by anticipating situations
which could result in changes to the data applied in the SUS submission protocols, and taking
action to ensure that key data items that need to be retained consistently in the lifetime of the
CDS are not changed.
Data senders should note the following guidance on situations where extra vigilance is
needed and action to ensure consistent and correct application of data elements used in NET
or BULK protocols:
1. Patients’ changes of address in patient demographic data.
A change of postcode following a change of address can change the assignment of the PCT
of Residence which is used to derive the prime recipient in CDS BULK update submissions.
Where possible data senders should monitor changes to postcodes in when preparing CDS
data for SUS submission in order to help prepare to minimise its impact on the integrity of
SUS data.
2. New PAS or other local systems used in SUS data processing
When a new PAS is implemented or other system used for preparing the CDS output the
data, work will be needed to ensure that the CDS can be generated to the appropriate
standard required. In addition the sender must take action to ensure that any outputs that can
impact on key fields in the CDS are not changed. For example, if the sender code is sourced
from the new system it is important to check that the format of the CDS sender identity will
not be changed (eg from 5 to 3 characters, or inserting site codes in the 4 th and 5th characters
instead of zeros).
3. Sub-contractor
If a provider sub-contracts healthcare services and associated CDS submissions to a second
provider, both parties need to actively engage in arrangements for CDS submissions,
ensuring that submission protocols are applied appropriately to maintain data integrity (see
section 2.2.4).
4. New message translation supplier
If a provider changes bureau supplier arrangements for XML message translation, it is
important that the new supplier is provided with the information required on the messaging
protocols that have been used in previous CDS submissions, to ensure that data integrity is
maintained in the ongoing CDS messaging.
5. Compare SUS totals with expected totals
Data senders can find SUS monthly record counts for each CDS type by opening the latest
service tracking interim report – monthly database count on the SUS What’s new pages. If
the count is significantly higher than expected this is probably due to duplicated data being
created on SUS. A SUS data deletion form should be completed – see section 4.
4. Strategic data deletion service
The SUS Strategic Data Deletion Service (SDDS) is available to all commissioners and
healthcare providers who submit data into SUS. The SDDS allows organisations to request
removal of duplicate CDS and MHMDS data.
Providers that have duplicated data on SUS and wish to submit a request for data deletion
first need to be given authorisation from the SDS (Spine Directory Service). Providers should
request authorisation by completing an Authorisation Form ADD LINK and returning it to the
IC Contact Centre (enquiries@ic.nhs.uk) where their request will be actioned.
The SDDS Authorisation Form is available under Section 'Data Deletions and Duplicates' of
the IC Guidance and Other Useful Documents Section.
Providers will also need to contact their RA (Registration Authority) regarding access to the
Data Deletion Service Request Service Application (B0141).
Please note: It may take up to ten days for SDDS authorisation to be complete. Providers do
not have to have duplicate records to request SDDS authorisation or business function
B0141. If this authorisation is sought in advance the deletion of any future duplicated records
can be processed much more quickly.
5. OLA Targets
This section describes the agreed timings surrounding processing of data deletions requests
(DDR) and any constraints that are outside the control of BT and/or the IC.
The purpose of this is to ensure continuity of service and for BT to ensure that adequate
controls are in place for Month End, Quarterly & Annual reporting phases.




Authorised representative of the IC to either approve DDR or contact the trust with
any concerns within one working day of DDR being requested. E.g. if request raised
on a Friday the IC will respond on the same day or the following Monday by 5pm.
DDRs will be automatically executed as soon as the request has been approved by
the IC, unless this falls within a cut-off period.
If the request is less than 5 working days before a cut-off point the request may not
be approved by the IC until after the deadline date. This is because organisations
need enough time to resubmit their data. This is only applicable to the current
financial year.
The data deletion service cannot be disabled, to allow for processing of monthly SUS
extracts, until all the deletions have been completed. IC need to recognise this when
approving DDRs close to a cut-off point.