Docstoc

Contents - NHS Connecting for Health NHS Connecting for Health

Document Sample
Contents - NHS Connecting for Health  NHS Connecting for Health Powered By Docstoc
					File Name:                           SUS Best Practice Guide
Version:                             V1
Status:                              Final draft
Issue Date:                          August 2010
                                     Craig Walker, Section Head - SUS & HES
Author:
                                     Data Quality and Operational Support




                              Secondary Uses Service
                                  Best Practice Guide




For more information on the status      Telephone: 0113 2547000
of this document, please contact        Fax: 0113 254 7299
The Information Centre for Health       Email: enquiries@ic.nhs.uk
and Social Care:
                                        Internet: www.ic.nhs.uk
Secondary Uses Service – Best Practice Guide




          Author:                  Craig Walker
          Directorate:             SUS Programme
          Version:                 V1
          Status:                  Final version
          Date:                    August 2010

DOCUMENT MANAGEMENT

REVISION HISTORY
   Version          Date                                  Summary of Changes
V0.2         20.07.2010                 Final draft review
V1           23.07.2010




APPROVED BY
Name                      Signature                Title                 Date of   Version
                                                                         Issue
Stuart Richardson                                  Programme Manager               1
                                                   Data Quality &
                                                   Support Services
Andy Banks                                         Information Manager             1

REVIEW DETAILS
 Review Date:                                      August 2010
 Reviewer                                          John Wilshaw




                                               Page ii
Secondary Uses Service – Best Practice Guide




CONTENTS
1 Background .................................................................................................................................4
2 How to use this Document ..........................................................................................................4
3 A Brief Introduction to SUS .........................................................................................................4
4 Access, Security and Confidentiality ...........................................................................................5
   4.1    Registration .....................................................................................................................6
   4.2    Role Based Access Control (RBAC) ...............................................................................6
   4.3    Pseudonymisation ...........................................................................................................7
5 The Commissioning Data Set Submission Process ....................................................................7
   5.1    XML Validation ................................................................................................................7
   5.2    CDS Versions..................................................................................................................8
   5.3    Testing the Submission Process .....................................................................................9
   5.4    SUS Submission Patterns ...............................................................................................9
   5.5    Submission Protocols (Net and Bulk)............................................................................10
   5.6    Organisations Intending to Submit Data on Behalf of another Provider ........................12
   5.7    Provider Sub-Commissioning Activity ...........................................................................13
   5.8    Submitting Sensitive Data .............................................................................................13
6 SUS Modules and Accessing Data ...........................................................................................14
   6.1    Reasons for Access ......................................................................................................14
   6.2    SUS Extract Mart (SEM) ...............................................................................................15
   6.3    PbR Mart (PbR Online) .................................................................................................15
   6.4    Running Extracts (best practice tips).............................................................................16
   6.5    SUS Extract Inbox Management ...................................................................................19
   6.6    Tracker/DQR .................................................................................................................19
   6.7    Monthly Database Counts .............................................................................................20
   6.8    e-DQRS.........................................................................................................................20
   6.9    Strategic Data Deletion Service (SDDS) .......................................................................20
   6.10 Information Retention Policy (IRP) ................................................................................21
7 Data Quality ..............................................................................................................................21
   7.1    Data Quality Dashboards ..............................................................................................21
   7.2    Quarterly Data Quality Publications ..............................................................................22
   7.3    SUS KPI Data Quality Reports......................................................................................22
   7.4    SUS RTT Data Quality Reports.....................................................................................22
   7.5    ‘Preparedness for RTT reporting through SUS’ Reports ...............................................22
   7.6    Data Quality Service......................................................................................................22
8 Service Management and Support............................................................................................22
   8.1    BT Contacts...................................................................................................................23
9 Training .....................................................................................................................................23
10 Reference Documentation ........................................................................................................23
   10.1 Organisational Merger, Separation and System Change..............................................24
   10.2 Shared Services ............................................................................................................25
   10.3 Joint Commissioning Arrangements..............................................................................25
11 Appendix 1 - Common Data Quality issues in SUS ..................................................................26
12 Appendix 2 - Glossary of terms .................................................................................................31




                                                                 Page iii
Secondary Uses Service – Best Practice Guide




1    BACKGROUND
Healthcare Providers who send patient data to the Secondary Uses Service (SUS) are providing data
that is used to support commissioning, the development of health care and use of resources.
Consistency and compliance with national standards are therefore essential, as Providers are measured
and judged by the quality of data supplied.

SUS processes up to 8 million incoming records and 200 million outgoing records everyday. Therefore it
is important that SUS users apply the recommendations of this document in business as usual in order
to maintain a consistent and reliable source of data for all.

If the NHS is to continue to improve the quality and safety of its services it is business critical to provide
high quality information for management and clinical decision making. High quality data is not an
optional extra; it is a fundamental basis for the business of each organisation. As such, it should always
be considered at the centre of any future developments and kept under review.


2    HOW TO USE THIS DOCUMENT
This document contains useful information about SUS but its objective is to highlight areas of best
practice to assist users to understand data submission and extraction processes. Users are
encouraged to read other material for more background specific to SUS where required. The latter
stages of this paper include sections on how to log problems identified with SUS and training.

The SUS Best Practice Guide provides information on the services and management arrangements for
SUS. It provides advice for users on how to get the best out of SUS with particular emphasis on
submitting data, extracting data and data quality. Best practice principles and key examples are
highlighted throughout the document in grey boxes and warnings are highlighted using boxes containing
the    symbol. See examples below:




                    Warning Message



Common data quality problems are documented in Appendix 1 at the back of this document.

This document will be reviewed and updated as required. When changes are made, users will be
notified through the regular SUS Bulletin or ‘What’s New’ section of the SUS website.


3    A BRIEF INTRODUCTION TO SUS
SUS is jointly managed and developed by NHS Connecting for Health (NHS CfH) and the Information
Centre for health and social care (NHS IC), with support from the Department of Health (DH) Informatics
Directorate. The purpose of the service is the capture, management and reporting of information for
purposes other than direct patient care, hence “secondary” uses.

The main delivery mechanism for the SUS data warehouse is through the national NHS Care Record
Service contract delivered by BT, a National Application Service Provider (NASP).
SUS content is largely person-specific, built on existing data flows such as commissioning datasets
(CDS).


                                                 Page 4 of 31
Secondary Uses Service – Best Practice Guide




These Acronyms are included in the glossary.

Figure 1, Overview of the SUS Data Warehouse

The initial focus for SUS development was to provide a single consistent and authoritative system to
process data flows to replace the NHS wide clearing service (NWCS) and support Payment by Results
(PbR). The system continues to be developed e.g. to support the ongoing functionality of PbR.

SUS has been designed to support Government objectives and to reduce the use of person identifiable
information for purposes other than that of direct patient care. SUS has significantly improved the
security and confidentiality of data managed through a combination of:

    • Comprehensive and rigorous access controls.

    • Anonymisation of data and the use of encrypted pseudonyms to replace information that could be
       used to identify individuals, which is accessed or transferred from the SUS environment.

    • Enabling the linkage of data from different sources relating to the same care pathway.


4    ACCESS, SECURITY AND CONFIDENTIALITY
SUS has a robust Information Governance process to ensure that the data is protected from
unauthorised access. Approval to access SUS and view patient data is required from the Ethics and
Confidentiality Committee (ECC). If approved, individuals are able to view only information that is
relevant to the purpose they applied for. They are issued with an NHS Care Records Service
Smartcard, a pass code and Unique User Identification (UUID) to ensure data is kept secure. SUS will
provide access and outputs in clear or pseudonymised form dependent upon each user’s access rights.
Where access to pseudonymised data is appropriate, elements which could identify a patient are
encoded in order to provide greater protection of privacy.


                                               Page 5 of 31
Secondary Uses Service – Best Practice Guide




An N3 connection is required to access the Spine and SUS; also known as the National Network, N3
provides fast, broadband Networking services to the NHS and is vital to delivery of the National
Programme for IT.

         For access to SUS users should approach their local Registration Agent (RA), local
         HR department or Strategic Health Authority Chief Information Officer for details.



4.1   Registration
All CDS Senders need to complete a CDS Sender Registration Form (SR1) and return it to the BT
Helpdesk. Link below:
http://www.knowledge.ic.nhs.uk/assets/attachments/sus/146/SR1_registration_20091016124225.doc
This registration ensures that the data Sender and all organisations they submit data for are registered
with SUS. This form includes the primary and secondary e-mail contacts for notification of interchange
failures. It is recommended that the named contacts are staff members directly connected to the local
SUS submission process, who are able to take appropriate corrective action. It is essential that Sender
organisations ensure this information is kept up to date. They should make provision for if the stated
named contacts are out of the office when data is submitted. Likewise this information should be
updated promptly with BT if contacts leave the organisation to ensure that all notifications reach the
appropriate staff member straight away.

         Senders must notify the BT helpdesk of any changes to nominated contacts:
         bt.sus.helpdesk@bt.com or 0845 600 2558.

The links below direct users to SUS guidance and forms necessary for SUS registration.
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/reference/index_html#susforms
http://nww.connectingforhealth.nhs.uk/etdnasp/spine-applications/registration-authority


           Warning Message 1:
           SUS automatically removes the user licence of any users who have not accessed SUS for
           three months. The document at the link below explains this process and the underlying
           rationale in more detail, along with the process to follow so that access can be re-established.

           http://www.connectingforhealth.nhs.uk/systemsandservices/sus/progress/licences/housekeepin
           g



4.2   Role Based Access Control (RBAC)
SUS is currently only directly available to NHS organisations (or their information suppliers such as
Shared Services organisations). The Patient Information Advisory Group (PIAG), now NIGB, imposed
conditions limiting access to 3 users per organisation. To access SUS, individuals must have a Spine
Smartcard together with the correct access rights (Business Functions) assigned by the local RA
sponsor. Sharing of Smartcards is prohibited. More information can be found in the link below:

http://www.connectingforhealth.nhs.uk/systemsandservices/sus/reference/index_html#reg

SUS holds patient identifiable data and access to this data is tightly controlled. SUS provides data
outputs in both clear and pseudonymised form dependent upon each user’s access rights. A
combination of Activities or Business Functions (BFs) and the organisation determines which data a
user has access to. The link below contains useful information for Registration Agents:


                                              Page 6 of 31
Secondary Uses Service – Best Practice Guide



http://www.connectingforhealth.nhs.uk/systemsandservices/sus/reference/rbacactivities.pdf

          The above link lists the business functions that should be assigned to SUS users
          based on their role within the organisation. Local Registration Authority (RA)
          personnel should review this link when granting RBAC rights. More details can be
          found at the following link:
          http://www.connectingforhealth.nhs.uk/systemsandservices/rasmartcards

RBAC works by collecting information about a user and what their role requires them to do from their
Smartcard. When this information is presented to SUS, SUS interprets it to allow access to the relevant
functionality and data. After completing the registration process outlined in Section 4, users will need to
register one or more User Role Profiles (URP) and have assigned Activities/Business Functions to
these, which give access to the various applications on the SPINE. More information can be obtained
from the link below:
http://nww.connectingforhealth.nhs.uk/etdnasp/spine-applications/registration-authority.

          SUS supports the implementation of Information Governance principles. No single
          user should have access to clear and pseudonymised data within one user profile.


4.3   Pseudonymisation
The approach to implementation of pseudonymisation to support secondary uses in NHS organisations
is based on each local organisation undertaking its own pseudonymisation as appropriate. This
approach has been adopted in order to support the increasing direct flows between Providers and
Commissioners necessary for NHS business operations. It requires that organisations will need to
review and modify, where necessary, aspects of their management and user access to identifiable and
pseudonymised data as well as business processes, end user applications and the relevant logging and
auditing facilities.

The Pseudonymisation Implementation Project (PIP) is concerned with enabling the NHS to undertake
secondary use of patient data in a legal, safe and secure manner. For more information please click the
link: http://www.connectingforhealth.nhs.uk/systemsandservices/sus/delivery/pseudo


5     THE COMMISSIONING DATA SET SUBMISSION PROCESS
The Department of Health mandate the collection and submission of all NHS commissioned activity
(Acute and Mental health) including services provided for the NHS by the Independent Sector. This
represents a vast array of organisations of varying sizes and submission patterns.

         Providers of NHS care should review data collected on local systems and ensure all
         CDS data is submitted to SUS.
         http://www.datadictionary.nhs.uk/web_site_content/cds_supporting_information/cds_
         mandated_data_flows.asp?shownav=1.
         This link provides more information on mandatory Commissioning Data Sets.

The following section describes the system and technical aspects Sender that organisations must
consider in order to successfully send data to SUS. Organisations proposing to submit data to SUS
must read all elements of this section carefully.

5.1   XML Validation
SUS will only accept data in XML format. XML is a text based mark-up language for encoding
structured information and it allows consistent error checking based on a data definition expressed in an


                                               Page 7 of 31
Secondary Uses Service – Best Practice Guide



XML schema. Senders must select an XML supplier from the NHS CfH accredited list of suppliers
before they can to submit data to SUS. The terms of this contract are negotiated between the Sender
organisation and the XML supplier.

         Senders must secure the services of an approved/accredited XML supplier
         (http://www.connectingforhealth.nhs.uk/systemsandservices/sus/reference/index_ht
         ml# ) who has achieved tactical authority to deploy (TATD) their product.

Implementation guidance for XML can be found in the latest deployment guide and checklist which can
be downloaded at:
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/reference/index.html#edt
The guidance includes details of approved suppliers and how to work with them.

Interchanges are validated against a centrally held version of the XML schema maintained by NHS CfH.
If valid, the interchange is transmitted to SUS where SUS performs additional validations to ensure that
data can be processed. At this point a local confirmation is generated and stored.

Definitions of the CDS can be found on the web as follows:

   • The data dictionary descriptions are available from:
      http://www.datadictionary.nhs.uk/web_site_content/cds_supporting_information/commissioning_d
      ata_set_message_schema_versions.asp?shownav=1.

   • The XML schemas are available from the data standards website:
      http://www.datadictionary.nhs.uk/web_site_content/cds_supporting_information/cds-
      xml_message_schema_overview.asp?shownav=1

   • Information Standard Notifications (ISNs) and Data Set Change Notices (DSCN), where changes
      to the definitions are documented are available from: http://www.isb.nhs.uk/library/isn and
      http://www.isb.nhs.uk/library/dscn.

         Trusts should work to implement the above standards and ensure that data within
         the originating systems (e.g. PAS) are consistent with the data requirements of CDS
         returns. Users can subscribe to the Consultation and Distribution list at the following
         link: http://www.isb.nhs.uk/yoursay.

Electronic Data Transfer (EDT) 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, e.g. APC or MHMDS. EDT is a simple application with no user interface.
Sender organisations and their XML suppliers will be responsible for installing EDT, keeping up-to-date
with new versions, scheduling EDT to make data transfers and for the security of the local EDT host.
The security model of EDT is based on the Transaction Messaging Service (TMS) using system to
system authentication (it does not employ Smartcards). The EDT host must be registered as a secure,
‘authenticated endpoint’ with the BT Helpdesk bt.sus.helpdesk@bt.com.


5.2   CDS Versions
The CDS version refers to the structure and validation of the Commissioning Data Set. SUS can only
support two different CDS versions at any one time. Each new version is an enhancement of the
previous. Failure to submit data using a supported CDS version will mean that the interchange will be
rejected.

         SUS users are encouraged to review the NHS CfH SUS website for details of the
         current CDS versions and release dates.



                                               Page 8 of 31
Secondary Uses Service – Best Practice Guide



         http://www.connectingforhealth.nhs.uk/systemsandservices/sus.

It is recommended that Senders move to the latest version of CDS as soon as is practicable. Senders
should ensure that they have sufficiently tested the new version prior to submitting to SUS for the first
time. The new CDS version will not be accepted from a Sender by SUS until a successful test
interchange has been submitted. Senders should note that there may be a delay between successfully
testing the new CDS version and BT accepting the new version for live production data from a particular
Sender. Once approval has been given to submit a new version the Sender can not revert to the
previous version.

         Senders are advised to take account of inclusion dates when moving to a new
         version of CDS and allow adequate time for testing the submission process.


5.3   Testing the Submission Process
Senders must successfully complete the submission process prior to sending live data following
changes in the message construction process.

EDT offers two test paths for data suppliers:

   • An offline ‘Validate Only’ option allows suppliers to test local applications without the use of an
      NHS Net connection. In this mode no external connections will be made so Senders are able to
      test local EDT integration. This approach allows Senders to test the file format and data content
      accepted by their XML solution software without sending to SUS. The result of a successful test
      is the creation of a valid XML message that would be ready to send to SUS.

   • A full online mode is where test interchanges can be sent to SUS. The test indicator is set in the
      XML message at the interchange level (CDS Interchange Header). Any errors encountered will
      be reported to the Sender in the normal way; however the interchange will not update the SUS
      database.

         Senders must submit a test interchange successfully prior to sending live data to SUS.

Users are not permitted to send test and production (live) CDS mixed in the same interchange. For a
test interchange the whole CDS Interchange is marked as test by setting the CDS INTERCHANGE
TEST INDICATOR in the CDS Interchange Header.

          Warning Message 2:
          Senders should NOT use the field CDS TEST INDICATOR found in the protocol header – this
          is not supported by SUS and will be ignored resulting in test records carrying this item applied
          to SUS. It may result in deletion of records on SUS without replacement.



Completing an end-to-end test process will ensure the required change is realised and there are no
unexpected effects on the SUS data. There is a risk that the changes listed above could cause
duplicate records in SUS.

5.4   SUS Submission Patterns
To a large extent, the submission pattern for an organisation will be determined by the operational
environment of the organisation. However, there are submission patterns which optimise the efficiency
of SUS processing. Senders are encouraged to limit the number of interchanges to 10 per day, or 400,
000 records. This optimisation benefits the sending organisation, other sender organisations and the


                                                Page 9 of 31
Secondary Uses Service – Best Practice Guide



NHS as a whole. Work is underway to limit CDS interchanges to contain the current year data plus the
previous two financial years’ data. At time of writing this guidance this has not yet been implemented.

To ensure any rejections have time for resubmission users are encouraged to submit data in good time
before the PbR Inclusion Date. The 2010/11 CDS submission timetable can be found at the link below:
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/progress/serviceavailability


             • Where possible users should aim to send fewer than 400,000 records per 24
                hour period limiting the number of submissions to 10 per day.
             • Avoid submitting historic data in the week before an inclusion date – if at all
                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 please send the most recent data first and if
                possible send a month at a time. This ensures that the most relevant data is
                processed and will be visible first. For instance, if a year end refresh is
                required these will be processed more quickly if you send a month per
                interchange and if you send March, then February, then January etc.
             • Use NET interchanges to submit data – NET interchanges are not only the
                most efficient to process into SUS they are also the most efficient to produce
                and transmit. They are also the safest as there is far less chance of an
                organisation accidentally deleting data using the NET protocol.
                (Organisations have in the past submitted an erroneous Bulk Header Record
                for instance with a year of 2001 instead of 2010. This resulted in the deletion
                of 9 years of data.)

The link below takes users to the Datasets frequently asked questions area of the NHS CfH website.

http://www.connectingforhealth.nhs.uk/systemsandservices/data/nhsdmds/faqs/datasets.

5.5   Submission Protocols (Net and Bulk)
The CDS messages from Providers carry information that allows the Sender’s chosen update
mechanism to take place in accordance with the specified rules. The two available update mechanisms
are:
   • Net Change (Net)

   • Bulk Replacement (Bulk)


             Warning message 3:

                 •   A Bulk interchange will delete all Net records irrespective of ‘Applicable Date’.

                 •   If a Bulk interchange has not used a ‘Unique CDS ID’ then multiple records can be
                     replaced by a single Net record.

             Net submissions will pass over Bulk records without a ‘Unique CDS ID’ and since this ID is
             mandatory for Net submissions, Net cannot be used to replace Bulk records without a
             ‘Unique CDS ID’. In effect records in this case could be duplicated.




                                              Page 10 of 31
Secondary Uses Service – Best Practice Guide



More information on how the Net and Bulk submission protocols work can be found in section 2 of the
‘Guidance on Migration from Bulk update protocol to Net change for Commissioning Dataset
Submissions’ link below:
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/whatsnew/080508guide.pdf.


  5.5.1    Mixing bulk and net interchanges
Users are discouraged from mixing Bulk replacement (Bulk) and Net change (Net) interchanges which
can lead to unintended loss of data. If Net and Bulk are mixed Bulk will update all Net records in SUS
for the Sender, prime recipient, report start and report end date combinations irrespective of extract
dates and applicable dates for that Bulk replacement group.


            Example:
            A user sends 10,000 records as General APC data, CDS type 130, using the Net
            protocol. The user then sends 500 records as Delivery APC data, CDS type 140,
            using the Bulk protocol under the same Sender code, prime recipient, report start
            and end dates. Because CDS types 130 and 140 are part of the same Bulk
            replacement group (BRG 10) the second submission overwrites all the first
            submission leaving 500 records as opposed to the 10,500 APC records.


It is possible to send a Bulk interchange with many records with the same ‘Unique CDS ID’ for the same
Sender.

A Net submission will replace all the records for the same Unique CDS ID for the Sender providing the
applicable date is later than or equal to the extract date. Thus if all the records in a Bulk interchange
have the same ‘Unique CDS ID’ and a subsequent Net change deletion record is submitted with that
‘Unique CDS ID’ it follows that all the Bulk records will be deleted.


            Example:
            A user sends 10,000 records using the Bulk protocol where Unique CDS ID is
            equal to '99999999' for all records as this field is not part of the Bulk protocol and
            not used as a ‘key field’. The user then sends one single record under the same
            Sender code where Unique CDS ID is equal to '99999999' using the Net
            protocol. This single record in the second submission overwrites all the records
            from the first Bulk submission leaving one record as opposed to 10,001 records.


The above examples highlight the two main risks of mixing Bulk and Net.

SUS validation checks applicable date against extract date when Net records update Bulk records, but
do not check applicable date when applying a Bulk to Net change.

          Users are discouraged from mixing Bulk replacement (Bulk) and Net change (Net)
          interchanges which can lead to unintended loss of data.




                                                Page 11 of 31
Secondary Uses Service – Best Practice Guide




              Warning message 4:
              When producing the CDS, Bulk submitters must ensure the CDS report period start date is
              entered correctly and checked carefully. A number of Senders have inadvertently deleted
              data over a number of years by populating this field incorrectly, e.g. 01/01/2001 instead of
              01/01/2010. Users are encouraged to use automated validation and, where possible,
              Senders should use data within the interchange to construct the header and apply
              parameters used within the header to construct the interchange message.


5.6   Organisations Intending to Submit Data on Behalf of another Provider
Some Providers subcontract healthcare and the associated CDS submission to another Provider.
Arrangements to exchange this data must be made locally. There is no provision for exchange of data
from Provider to Provider through SUS.

        Only one Provider should send data relating to this activity to SUS as agreed between
        these organisations. If a second Provider wishes to add data to that already on the
        data base for the first Provider, they must identify the first Provider using a different
        configuration of the Sender code in the header e.g. change the last 2 digits of the 5
        digit code (site element).


              Warning message 5:

              If data is submitted using either Bulk or Net using the same Sender code as the previous
              submission then it will delete and replace that which was originally in the database, not add
              to it.


Where an organisation acts on behalf of another organisation to submit data, care must be taken to
ensure the correct use of the following identity fields. This will reduce inadvertent duplication or deletion
of records held on SUS.
The CDS SENDER IDENTITY is the mandatory NHS Organisation Code of the organisation acting as
the physical Sender of Commissioning Data Set submissions. This is found in the CDS transaction
header group for either NET or BULK protocol and is used in the identification of records to replace or
change or delete.

It is distinct from the Provider Code (ORGANISATION CODE (CODE OF PROVIDER)) also sent in the
CDS Message which may contain the same value, a different value (eg another site at the same
Provider organisation) or a value from a different Trust if an organisation acts on behalf of another
organisation to submit data.

The CDS INTERCHANGE SENDER IDENTITY is the assigned EDI Address of the physical
organisation or site responsible for sending Commissioning data. This is found in the CDS interchange
header.

         Users are encouraged to thoroughly test any changes that may affect the CDS
         generation or SUS submission processes including changes to:
              •   The submission protocols (Net/Bulk)
              •   PAS changes
              •   XML amendments
         Following the successful submission of live data to SUS users should check the
         submission using the ‘Activity Counts’ section of the SUS Data Coverage Dashboard


                                               Page 12 of 31
Secondary Uses Service – Best Practice Guide



            or Monthly database counts report to verify if any duplicate records have been created.
            http://www.connectingforhealth.nhs.uk/systemsandservices/sus/delivery/dataquality/op
            support/trackerreports/index_html


5.7       Provider Sub-Commissioning Activity
Where an NHS Trust commissions from a UK Independent Provider it is the responsibility of the NHS
Trust to ensure that the CDS data is sent. Where an NHS Trust commissions from an overseas
Provider it is the responsibility of the NHS Trust to ensure that the CDS data is sent, except where a
lead Commissioner is involved, in which case the lead Commissioner is responsible for ensuring the
CDS data is sent.

           Users should be aware of how the 15 character Sender code of their EDI address is
           created, i.e. is it derived from their Provider code or not? This will depend on how XML
           solutions have been configured. It may not be possible to rely on a change to the
           Provider code in order to change the Sender code when or should this become
           necessary.

A range of documentation is available to support SUS implementation and use of SUS services. These
documents will signpost users to available training materials to support the implementation. Guidance
can be downloaded from the Reference Documents section of the SUS website at:
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/reference.

CDS Authentication was introduced as a means to prevent Senders overwriting other organisation’s
data and is now fully integrated into SUS. Only Senders authorised to submit a Provider’s data can
submit that organisation’s data to SUS.

          Senders wishing to submit data on behalf of a different Provider must complete an SR1
          form and return it to the BT helpdesk. See section 4.1


5.8       Submitting Sensitive Data
Users must be aware that restrictions exist on submitting sensitive records e.g. IVF, HIV as defined in
DSCN 41/98. Providers are required to remove all patient identifiable data: NHS Number or Patient
name and Address, Local Patient Identifier, Date of Birth and Postcode.

Submission guidance and a full list of sensitive diagnosis and procedure codes can be found in the link
below.

http://www.connectingforhealth.nhs.uk/systemsandservices/sus/reference/sensrechandling.pdf.

           Senders must review the link above before sending sensitive records or records listed
           under Section 10 of the Data Protection Act to SUS.
       
The link above also explains how SUS handles sensitive records. Where one of the listed diagnosis or
procedure codes is found in a record, SUS will either anonymise (completely remove patient identifiers)
or pseudonymise the data. The SUS derived field Confidentiality Category indicates how the record has
been handled:
    • 1 - indicates not marked as confidential
    • 2 - extremely sensitive and all patient details will be null
    • 3 - sensitive and if patient details are supplied by the provider they will be pseudonymised
    • 4 - other sensitive and all patient details will be null



                                                Page 13 of 31
Secondary Uses Service – Best Practice Guide




6     SUS MODULES AND ACCESSING DATA
Users can obtain data from SUS via an online service accessed using their Smartcard. This service
enables Providers, Commissioners and SHAs to run extracts, summary analysis and reporting. More
information is available covering the different service areas at: www.CfH.nhs.uk/sus/reference.

Users are able to access records in datasets within the SUS data warehouse appropriate to their role
and organisation which is controlled through the Spine and the SUS RBAC mechanism. The online
service enables users to access SUS directly and download data into local systems to support local
summary analysis and reporting. Requested extracts are delivered to the user’s inbox within SUS.
Providers and Commissioners may have access to clear data whilst SHAs can only access
pseudonymised data managed through Smartcards. There is a limit of 3 Smartcards for SUS Ardentia
extract users per organisation. These should never be shared with any other users.

6.1   Reasons for Access
Organisations are given access to patient level data based on codes that are completed by the data
Sender to enable relevant recipients in these organisations access to the data in SUS.

        Data Senders should use the Commissioning Data Set Addressing Grid to help
        determine who has access to CDS data once it has been submitted to SUS.
        http://www.datadictionary.nhs.uk/web_site_content/cds_supporting_information/cds_a
        ddressing_grid.asp?shownav=1.

Users can select all or a combination of ‘reasons for access’ when requesting data extracts from SEM.
These reasons for access reflect the commissioning and public health responsibilities of PCTs. They
reflect the values for data items included within the CDS submitted by Providers of NHS care and/or
derived during SUS processing from data recorded by the Provider within the CDS using PDS data.

More information on how to use ‘reasons for access’ in generating an extract can be found in the
‘Running extracts (best practice tips)’ section of this guide. The ‘reasons for access’ codes are outlined
below:

                                This operates on the value assigned by the
 Prime Recipient Code
                                Provider of NHS care responsible for the data.
                                This operates on the value assigned by the
 Copy Recipient Code
                                Provider of NHS care responsible for the data.
                                This operates on the value of the Organisation code (Code of Provider)
 Provider Code
                                submitted by the Provider of NHS care.
                                This value is derived from data recorded with the Person Demographics
                                Service (PDS) using the patient’s NHS number as recorded by the
 PCT of Responsibility
                                Provider of NHS care. The GP practice held on PDS is used to derive
 Code (SUS derived)
                                PCT of Responsibility. Where a derivation from PDS is not possible, SUS
                                derives the PCT from the submitted GP practice.
                                This value is derived from data recorded with the Personal Demographics
                                Service (PDS) using the patient’s NHS number as recorded by the
 PCT of Residence Code
                                Provider of NHS care. The Postcode held on PDS is used to derive PCT
 (SUS derived)
                                of Residence. Where a derivation from PDS is not possible, SUS derives
                                the PCT from the submitted postcode.
 PCT of Residence Code
                                This operates on the original Organisation Code (PCT of Residence)
 (Incoming Trust provided
                                assigned by the Sender.
 value)
                                This operates on the Organisation Code (Code of Commissioner)
 Commissioner Code              assigned by the Provider of NHS care and is used in the configuration of
                                SUS PbR extracts.


                                              Page 14 of 31
Secondary Uses Service – Best Practice Guide




        Senders of NHS data should populate the reasons for access fields for those
        organisations that require access to the data.


6.2   SUS Extract Mart (SEM)
The SEM application can be used by any organisation with a right to view and extract that data from
SUS. Data is accessed using a Smartcard via the Spine system allowing the user to extract data where
their organisation is identified as one of the 'reasons for access' (see section 6.1). For details of what
data items are available in SEM follow the link below:
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/reference/index_html#extract.

         Providers are responsible for checking the quality of the data they submit to SUS,
         and can do this by running SEM extracts. This is particularly important following any
         amendments or changes to XML or PAS suppliers as this can result in duplicate
         records being created in SUS.



6.3   PbR Mart (PbR Online)
The PbR mart was developed to support the Payment by Results (PbR) initiative and includes additional
fields derived by SUS including spell, HRG and tariff data items. As with SEM, the PbR Online
application can be accessed using a Smartcard and allows the user to extract PbR data from SUS
based on various snapshots (e.g. at reconciliation or post-reconciliation), or the current view of data.
For details see the PbR Online User guide:
 http://www.connectingforhealth.nhs.uk/systemsandservices/sus/supports/pbr/pbr-
guidance/r7onlineserveguidev1.pdf
or the Screen Walkthrough:
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/supports/pbr/pbr-
guidance/r7walkthrough.pdf

There is a lot of guidance material available on PbR. Users are advised to review the ‘Release 7 – SUS
– PbR 2010/11 Read me first’ user guidance. This paper will assist users in understanding the
documentation that is available and its relevance to their particular needs:
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/supports/pbr/pbr-guidance/.

        More information on how to generate an extract can be found on page 85 of the SUS
        R7 User Guide which can be found at the link below:
        http://nww.connectingforhealth.nhs.uk/etdnasp/spine-applications/secondary-uses-
        services.

Data in the SEM and PbR marts can be extracted in .csv (MS Excel) format, fixed width (.txt file) format
or delimited format.

           Warning message 6:

           Care must be taken when a .CSV or Delimiter output is requested. The output fields are
           separated by the comma or delimiter. If the delimiter character or comma is present within the
           data, then there is no way of distinguishing between the delimiting character or comma and the
           data. As a result the format of the output columns can be misinterpreted by applications such
           as Excel. Options to resolve this are on page 88 of the SUS – Data Access Service User
           Guide
           http://nww.connectingforhealth.nhs.uk/etdnasp/spine-applications/11738-SUS-R7.doc



                                              Page 15 of 31
Secondary Uses Service – Best Practice Guide



Users can preview the first 50 rows of the data extract before it is submitted to SUS to check that it has
been configured correctly and that it is returning data as expected by selecting the preview button on
the extract screen.

          When creating a SEM or PbR extract for the first time users should preview the file to
          ensure it fulfils their requirement.


6.4   Running Extracts (best practice tips)
SUS can process up to 40 extracts simultaneously. Where more than 40 extracts are scheduled, an
extract will wait in the queue until there is a free slot on one of the schedulers. Extract delivery time
depends on the actual runtime of the extract plus the time queued for a slot. To maximise the
throughput of extracts the NHS IC recommend the following tips to ensure efficient use of SUS system
resources:

      Users wishing to run data extracts from SUS are encouraged to take part in the e-learning
      application from the spine application screen.
      http://nww.connectingforhealth.nhs.uk/etdnasp/spine-applications/suspbrr7/index.htm/.


  6.4.1    Managed service extracts
These are made available to Providers and Commissioners on a monthly basis to support PbR
reconciliation and post reconciliation data challenges. These reports are generated and made available
on a push rather than pull basis so users receive these extracts in their inbox by 08:30 on the scheduled
date automatically without requesting them. These extracts are prefixed ‘MS’. See the links below:
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/progress/serviceavailability/pbrhes1011
updated.pdf.
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/reference/index_html#reg

Where possible, the Managed Service Extracts should be used instead of ad-hoc reports run on PbR
on-line or SEM.

      In order to receive Managed Service Extracts, users must have the appropriate business
      functions on their Smartcard:
      B1023 Clear view; B0164 Pseudonymised view or B1841 Spatial pseudonymised view.


  6.4.2    Facility to share extract reports
SUS Release 7 introduced a facility enabling users to share data extract configurations with other SUS
users at other NHS organisations, as well as automatically sharing the actual data extracts with other
users within the same organisation who have the same level of access as the requestor. This affects
‘Extract mart 2010’ and ‘PbR 1011’ output format.

      Users can learn more by participating in the e-Learning module ‘Data Access Service (inc
      PbR) e-Learning Modules (R7)’ at the link below:
      http://nww.connectingforhealth.nhs.uk/etdnasp/spine-applications/suspbrr7/index.htm/.

There are a number of benefits to this enhancement:

   • Reduce the need to duplicate reports

   • Reduction of processing time



                                               Page 16 of 31
Secondary Uses Service – Best Practice Guide



However, when the report is made available in the inbox the name may not indicate the report content
to the shared users. Therefore, users are advised to follow a standard naming convention to prefix all
extract names with their: Organisation code, their initials and the data it included in the extract for
example: AE, OP A&E.


      Example:

      If Fred Bloggs from RXN ran an APC report the name should be as follows:

                             RXN_FB_APC_Rec_Financial_Int_Comm_01



      Users are advised to adopt the above naming convention to enable them to easily find
      their own extracts and also extracts that have been run by another user within their
      Organisation.


  6.4.3   Avoid busy periods
Most SEM and PbR Online extracts are scheduled at the beginning of the week. Monday mornings are
the busiest time for producing extracts. This tails off into Tuesday (the second busiest day). Where
possible, schedule extracts outside of these times. There is also a higher demand for extracts in the
week immediately prior to a month-end Reconciliation or Freeze deadline, and these times should also
be avoided if possible. For more information on the PbR Online service users are encouraged to use
the SUS PbR online service user guide.

Finally, the contracted hours of service for SUS are 0830 to 1730 on normal workdays. Although BT
tries to maintain system availability outside of these service hours this is the time when BT can, and
does at times, take the system out of service for maintenance and tuning activities. It is therefore
advisable to schedule extract requests to run as soon as possible during the working day.

  6.4.4   Avoid large data ranges
Many users extract 1 or 2 years data repeatedly on a daily or weekly basis. These extracts will take a
long time to run and will impact extract performance for other users as slots will be unavailable. It is
strongly advised that organisations do not extract data across extended date ranges on a regular basis.
Where it is necessary to extract a large quantity of historic data please bear in mind that SUS is tuned to
perform best when servicing queries in one month blocks. Extracts requesting historic data will
therefore run more quickly if broken into month units.

  6.4.5   Restrict extracts to as few organisations as possible
Sometimes it will be necessary to extract data for a large number of organisations in a single extract.
Users are therefore encouraged to only schedule extracts for the organisations they require data for. In
addition, if possible, request separate extracts for each organisation.

  6.4.6   Use reason for access options sparingly
The ‘reason for access’ facility can be a powerful way of extracting data for a number of Providers.
However, selecting multiple ‘reasons for access’ can significantly increase the processing required to
generate the data. The data will be delivered faster if each extract uses only one reason for access.

  6.4.7   Supplementary extracts can run slowly
Supplementary extracts in the PbR Online system can be particularly slow to process. They can be
requested on the Additional Extracts tab on the extract screen. Please do not request Supplementary
extracts unless required. Where possible please avoid busy processing times when requesting
Supplementary extracts.


                                               Page 17 of 31
Secondary Uses Service – Best Practice Guide



  6.4.8   Ensure that a scheduled extract is cancelled if it is not intend to be downloaded
Many extracts are scheduled as regular jobs, but infrequently downloaded. Thousands of extracts have
been run on SUS that have never been downloaded; this results in loads on SUS that slows down other
user extracts. SUS Release 7 delivered a facility which automatically shares extracts between users in
an organisation. If another user in the same organisation and same role has requested an extract, the
extract will be available in both your inboxes once signed in. Hopefully this will reduce the practice in
some organisations for multiple users to submit the same extract request to cover unforeseen
absences.

  6.4.9   Extract status
Please do not resubmit extracts where the status is Active or Waiting. The SUS Extract Scheduler
processes extracts in a strict first in first out order. Resubmitting an extract that is Waiting or Active will
not produce the extract any quicker – to the contrary, it places additional load on SUS and will hinder
extracts for other users.

            Warning message 7:

            Please note: if an extract’s status is Failed it will not complete. Users must resubmit the extract
            request to get that data. SEM is updated between the hours of 2am and 7am but interchanges
            may still be processed over this time, consequently extracts run during this update period may
            not include all the data submitted at that time.


  6.4.10 Deletion of downloaded extract files
It is encouraged that users delete extracts that are no longer required. Users have the ability to delete
the links to extracts that have been created by another user from their own inbox, but the extract will still
be visible to other analysts.

  6.4.11 Running a PbR extract for multiple organisations (Shared Services & SHAs)
The screenshot below shows how to construct a managed service equivalent
extract that does not have duplicate rows.                                               Reconciliation or Post
                                                                                         reconciliation are the
                                                                                         main extracts run and
                                                                                         the only ones
                                                                                         produced by the
                                                                                         managed service.


                                                                                         To quickly select
                                                                                         multiple organisations:
                                                                                         Select the first
                                                                                         organisation, drag the
                                                                                         scrollbar to the bottom
                                                                                         of the list, press shift
                                                                                         and click the last one.
                                                                                         Control click will turn
                                                                                         individual organisation
                                                                                         on and off.
                                                                                         Configurations can be
                                                                                         saved.



                                                                                         Selecting one ‘reason
                                                                                         for access’ as a
                                                                                         managed service
                                                                                         avoids duplicate rows
                                                                                         and speeds up the
                                                                                         query.


                                                 Page 18 of 31
Secondary Uses Service – Best Practice Guide



PbR Extracts are optimised to run for a single financial period so the Reconciliation and Post
Reconciliation extracts will be much faster than multiple date range extracts. PbR Extracts are
optimised for Provider and Commissioner codes, so selecting other reasons for access will slow
extracts.

          Selecting more than one reason for access in a single extract will slow the
          production of extracts.

If only one reason for access is selected then multiple organisations may run more quickly than running
the same extract for each organisation and combining them locally. Extract timings can be variable
depending on the load on the database server. Extracts will take longer to get to the top of the queue
(change from Active or Waiting to Processing) at busy times e.g. immediately after a Reconciliation
point.

          If users select multiple reasons for access and multiple organisations some rows will
          be duplicated. Duplicates will not be generated if users run multiple reasons for
          access and one organisation or multiple organisations and one reason for access.


6.5   SUS Extract Inbox Management
An over full inbox creates a system load and will slow the system responses to the user. Users should
download the data to local systems rather than hold them in the mailbox environment.

          Users are encouraged to manage their own SUS inboxes keeping the number of
          extracts to a minimum and deleting old extracts once the data has been used or any
          shared extracts that are not required.



           Warning message 8:
           Extracts will be automatically deleted from user mailboxes 3 months after the extract date.
           This is an IG requirement. More information is available at:
           http://www.connectingforhealth.nhs.uk/systemsandservices/sus/progress/serviceavailability/mo
           nhousekee0510.pdf.
           http://www.connectingforhealth.nhs.uk/systemsandservices/sus/progress/licences/housekeepin
           g


6.6   Tracker/DQR
Tracker can be accessed via the Spine system and gives details of the status of interchanges into SUS
and whether they have been processed. Users can then drill down into these interchanges and view
Data Quality Reports (DQR) for the data within them. The rule definitions (invalid, other and missing)
for the DQR can be obtained from the ‘help’ button on the first ‘Data Quality Reports’ screen.

  6.6.1   Tracker reports
Tracker information is also provided in Excel spreadsheet format on the SUS website. See the “Weekly
Trust Statements” here:
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/delivery/dataquality/opsupport/trackerre
ports.




                                              Page 19 of 31
Secondary Uses Service – Best Practice Guide



These reports are generated on a weekly basis to track the status of all the data submissions up to the
date displayed on the report heading. The main function of this report is to check the status of all
submissions for a particular organisation.

        Senders are encouraged to use the Tracker reports to check that data has successfully
        been received at SUS, particularly after any organisational or system (PAS or XML)
        changes have been made.


6.7   Monthly Database Counts
This report is generated on a monthly basis to track the number of records present at staging by activity
month back to April 2008. Activity is displayed for each CDS type on a separate worksheet and can be
used to highlight any peaks and troughs in activity submissions or when an organisation has duplicated
or deleted data, started or stopped submitting data. See the link below:
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/delivery/dataquality/opsupport/trackerre
ports.

6.8   e-DQRS
e-DQRS is a SUS data quality reporting tool accessed via Smartcard that is being gradually rolled out to
users across the NHS. The main purpose is to target a number of key fields in each dataset and
provide a thumbnail data quality picture for CDS data Providers and Commissioners. Users requiring
access to the e-DQRS tool can gain access by emailing enquiries@ic.nhs.uk.

A more detailed overview and guidance will be published at the link below shortly:
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/delivery/dataquality/quality

6.9   Strategic Data Deletion Service (SDDS)
SDDS is a web-based user interface to identify data to be deleted. The service allows organisations to
remove duplicates or incorrect data from SUS for all CDS types including MHMDS. A data deletion is a
single submitted request for an individual Sender irrespective of the number of records that the deletion
affects. Data can be deleted by CDS Sender code for a reporting period, by an interchange ID, or by
individual generated record ids (GRIDs). Net users still have the option to delete the data by
resubmitting it using ‘update type’ of 1.

       Organisations should use the latest Data Coverage Dashboard to monitor the number of
       duplicates they have in SUS. If this is unreasonably high the organisation will need to
       identify the duplicate records and use the Strategic Data Deletion Service to delete these
       records. Where organisations are unable to identify these duplicate records they should
       contact enquiries@ic.nhs.uk

For information on how to delete data from SUS see the user guide at the following link:
http://nww.connectingforhealth.nhs.uk/etdnasp/spine-applications/secondary-uses-services/
http://nww.connectingforhealth.nhs.uk/etdnasp/spine-applications/10462-SUS-R4.doc.

           Warning message 9:

           When preparing the Strategic Data Deletion request users must be careful to ensure all dates
           and Bulk replacement group (not CDS) details are entered correctly and checked. Failure to
           do so could result in the wrong data being deleted from SUS.


      Users are encouraged to review the SDDS user guide and take part in the Strategic Data
      Deletion e-learning course to help understand this process before attempting to delete live


                                              Page 20 of 31
Secondary Uses Service – Best Practice Guide



      data in SUS.
      http://nww.connectingforhealth.nhs.uk/etdnasp/spine-applications/secondary-uses-
      services/sddic/index.htm/
      Users can request authorisation for access to the SDDS at any time. They do not need to
      wait until they have duplicate or incorrect records.



6.10 Information Retention Policy (IRP)
From a future release extracts from SUS will be limited to contain data for the current financial year + 2
previous years. There will be the facility to retrieve data older than the IRP (intended for emergency
purposes only) which will be documented once the requirement has been fully specified. The use of this
data will be considered on a case by case basis and there are no SLAs agreed with BT concerning the
production of this data. At the time of this paper’s release IRP has not been implemented. Prior to
implementation an announcement will be made using the What’s New page of the NHS CfH website.
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/whatsnew



7     DATA QUALITY
SUS data remains the responsibility of the NHS organisations that collect it. If the data submitted is of
poor quality the benefits of SUS will be significantly reduced. Good quality information on health and
social care activity is vital for planning, performance management, monitoring and clinical care. Data
submitted to SUS is used across a number of organisations for measuring Trust performance (including:
Dr Foster, Care Quality Commission, Public Health Observatories) and is increasingly being included in
contracts with Commissioning bodies and, moving forward, will be replacing Unify2 reporting.


         Appendix 1 of this guidance outlines some of the common data quality issues in
         SUS. Providers are encouraged to review appendix 1.

Changes to NHS policy necessitate continual improvements in data quality.


         The submission of Commissioning Data Set (CDS) data to SUS has raised the profile
         of data quality as an issue of major importance. Users are encouraged to make use
         of the tools outlined below to monitor the data quality of their organisation’s data.

Organisations should refer to the data quality page on the SUS web site for advice on CDS submissions
to the SUS interface and guidance.

http://www.connectingforhealth.nhs.uk/systemsandservices/sus/delivery/dataquality.


7.1   Data Quality Dashboards
To support users, a number of dashboards have been developed by the NHS IC to monitor and drive
improvements in the quality and completeness of SUS data. These report on the coverage and quality
of the Admitted Patient Care, Outpatient and Accident & Emergency CDS types, as well as focussing on
other key areas for improvement – Maternity and Adult Critical Care data. A new dashboard is under
development to support Mental Health. More information is available via the link below, where users
can also register for the dashboards:
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/delivery/dataquality/quality/dqdashboar
ds




                                              Page 21 of 31
Secondary Uses Service – Best Practice Guide




7.2   Quarterly Data Quality Publications
These reports are produced on a rolling quarterly basis focusing on validity over time of NHS Number.
See the link below to access the reports.
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/delivery/dataquality/quality/kpireports

7.3   SUS KPI Data Quality Reports
These reports are produced monthly to look at aspects of CDS submissions outlined by the NHS
Operating Framework. The following are reported: Comprehensive coding, Net submission, basic RTT
fields completion, NHS Number data quality and GP practice data quality. See the link below to access
the reports.
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/delivery/dataquality/quality/kpireports

7.4   SUS RTT Data Quality Reports
These reports are produced monthly to look at aspects of RTT CDS submissions for OP and finished
APC CDS types. These indicators are provided to help local health communities monitor progress in
the collection and submission of key data elements relating to RTT activity for RTT clock stops, clock
pauses and transfers between organisations. See the link below to access the reports.
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/delivery/dataquality/quality/kpireports

7.5   ‘Preparedness for RTT reporting through SUS’ Reports
These reports are produced monthly to provide information on Provider organisations’ preparedness for
RTT reporting through SUS in terms of data submission and data quality for OP and finished APC CDS
types. This report combines information from various different sources – CDS submissions to SUS,
RTT data in CDS, RTT data submitted to Unify and CDS schema versions.
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/delivery/dataquality/quality/kpireports


7.6   Data Quality Service
The Data Quality Service is a national programme to help users improve data quality by raising
awareness and connecting users sharing knowledge, expertise and best practice. One element of the
Data Quality Service is the Data Quality Guild where issues can be discussed via an online community.

       Users are encouraged to join the Data Quality Guild at the links below to connect with
       other SUS users and discuss data quality issues.
       http://www.ic.nhs.uk/services/the-data-quality-service




8     SERVICE MANAGEMENT AND SUPPORT

This section is a brief introduction to SUS Service Management and Support. The links below explain:
    • What users can expect from the service (Hours of operation, notification of planned outages
        etc,)
    • How to raise a service call;
    • What users can expect from BT in handling an incident;
    • How to escalate a service call.

http://www.connectingforhealth.nhs.uk/systemsandservices/sus
http://nww.connectingforhealth.nhs.uk/servicemanagement/status/
http://nww.connectingforhealth.nhs.uk/servicemanagement



                                              Page 22 of 31
Secondary Uses Service – Best Practice Guide



http://www.connectingforhealth.nhs.uk/systemsandservices/sus/progress/serviceavailability/escalationfo
rm.doc.
8.1   BT Contacts
If BT do not meet the expectations above, or if the system does not behave as expected, please raise a
call with the BT Helpdesk. Users can email on bt.sus.helpdesk@bt.com for SUS issues or
bt.spine.helpdesk@bt.com for SUS Spine issues (access to SUS) and/or telephone on 0845 6002558.

Service calls are generally resolved quicker if details of the issue are emailed using the incident report
form at the following link:
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/progress/serviceavailability/incidentrepo
rtform.doc. This usually ensures that all the information needed to resolve the issue quickly is available.
Users can expect a confirmation email and call reference number within 8 hours of BT receiving the
query.

               Users are encouraged to complete an incident report form. If the issue is
               urgent users should follow up the email with a telephone call to the helpdesk.



9     TRAINING
The responsibility for ensuring organisation and delivery of training for SUS is shared between the NHS
CfH, NHS IC and BT Training Team.

SUS training is delivered using the most appropriate mechanism for the user group and functionality
involved. Typically, training is provided in the form of e-Learning modules and user guides that are
specific to a particular area of SUS functionality e.g. PbR, RTT and CAB. Classroom-based training is
usually provided for specific user groups and purposes, such as the introduction of new reporting tools
and interfaces to SUS.

The e-Learning training course is an interactive on-line course incorporating demonstrations,
walkthroughs and quizzes available to run on a hosted system or stand-alone PC. This e-Learning
utilises Macromedia Flash and JavaScript technology and the PC must be able to support these.

Information on new training available is communicated on the What’s New section of the SUS website.
These communications also identify the user groups that the training is designed to support.

           Users are encouraged to review the ‘What’s New’ and e-Learning materials
           regularly for new training materials.
           http://www.connectingforhealth.nhs.uk/systemsandservices/sus/whatsnew
           http://nww.connectingforhealth.nhs.uk/etdnasp/spine-applications/secondary-
           uses-services/.



10 REFERENCE DOCUMENTATION
There are a number of websites, in addition to those already in this document, where information
directed at SUS users is made available which include: Data Set Change Notices, Information
Standards Notices, guidance material and updates on the SUS What’s New web page.

       SUS users are encouraged to review information sources regularly.
       http://www.isb.nhs.uk/library/dscn



                                               Page 23 of 31
Secondary Uses Service – Best Practice Guide



       http://www.isb.nhs.uk/library/isn/
       http://www.connectingforhealth.nhs.uk/systemsandservices/sus/whatsnew
       http://www.connectingforhealth.nhs.uk/systemsandservices/sus/reference
       http://www.connectingforhealth.nhs.uk/systemsandservices/sus/delivery/dataquality/quali
       ty
       http://www.knowledge.ic.nhs.uk/ebulletins/sus/index.asp
       http://www.connectingforhealth.nhs.uk/systemsandservices/sus/delivery/dataquality
       http://www.datadictionary.nhs.uk/
       http://www.connectingforhealth.nhs.uk/systemsandservices/sus
       http://www.dh.gov.uk/en/Publicationsandstatistics/index.htm
       http://www.connectingforhealth.nhs.uk/systemsandservices/sus/progress/serviceavailabil
       ity
       http://www.connectingforhealth.nhs.uk/systemsandservices/sus/progress
       http://nww.connectingforhealth.nhs.uk/servicemanagement
       http://nww.connectingforhealth.nhs.uk/servicemanagement/status/



       Users should set up internal processes to review DSCN and ISCN so that they are kept
       aware of all changes that affect them.



       Finally, it is recommended that SUS users within an SHA region, Independent Sector or
       Shared Service organisation meet as a local group to discuss data quality and SUS
       related issues. It is also recommended that the group appoint a Commissioner and
       Provider, where appropriate, to attend the National SUS user group meetings to
       represent their organisation and cascade information back.


10.1 Organisational Merger, Separation and System Change
Organisations (Providers or Commissioners) that merge should, in addition to setting up the appropriate
Organisational Data Service (ODS) codes, notify the BT SUS Helpdesk of the merger, providing a point
of contact to assist the Help Desk with any data issues. Similarly, any Trust that is making any changes
to systems which generate CDS – at any point during the year – should contact the BT SUS Helpdesk
to discuss the implications. For example, if the Local Patient ID changes as part of the system
migration, this would affect the PbR spell construction. The Helpdesk should be contacted, whether or
not the change is being undertaken as a result of the National Programme for IT.

      Organisations about to undergo a merger, separation from an organisation (de-merger) or
      system change should review the ‘Guidance for Merging Organisations to Support
      Sending of Commissioning Data Sets to SUS’ document and make the BT Helpdesk
      aware. At time of writing this guidance the above document has not yet been released.
      An announcement will be made using the What’s New section of the NHS CfH website
      when the guidance is available. The guidance will be available from the following website:
      http://www.connectingforhealth.nhs.uk/systemsandservices/sus/delivery/dataquality/quality




                                             Page 24 of 31
Secondary Uses Service – Best Practice Guide




10.2 Shared Services
Third parties such as Shared Services organisations and Health Informatics Services may have access
to the data within SUS relating to the organisations which they support. Information on third party
connectivity and the process for registration is available in the guidance document SUS and Shared
Services:
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/reference/sharedservs.pdf.

10.3 Joint Commissioning Arrangements
The standard view for a PCT Commissioner will be a combination of their “resident” and “responsible”
population i.e. patients resident within the PCT or registered with GP practices for which the PCT is
responsible. There may be instances where there are joint commissioning arrangements across a group
of PCTs, with one PCT acting as lead for the group.
Each PCT would have access to their resident and responsible views. If, in addition, the lead PCT
requires access to all data for the commissioning group, then this would be achieved by defining the
lead PCT as a shared services agency responsible for its group. The shared Services Registration form
can be obtained from the link below:
http://www.connectingforhealth.nhs.uk/systemsandservices/sus/whatsnew/susshared.doc




                                            Page 25 of 31
Secondary Uses Service – Best Practice Guide




11 APPENDIX 1 - COMMON DATA QUALITY ISSUES IN SUS
What follows is a list of some of the data quality issues present in SUS; this is not an exhaustive list.

    Data Quality Issue         Consequence                           Best Practice
 Submitting Morphology         These codes are too long to pass      These codes are for local use only.
 codes to SUS                  validation so users shorten the       Senders should not submit Morphology
                               code in order to submit to SUS        codes in the CDS to SUS.
                               making them invalid and resulting
                               in an ungroupable HRG. These
                               codes are removed in HES.
 Duplicate records -           Any re-submitted records with the     Check the Data Coverage Dashboard
 usually due to a change       new Sender code (or Prime             or Monthly Database Count reports on
 in CDS Sender code or         Recipient) do not overwrite the       the DQ website for evidence of
 Prime recipient (for          previous records because the key      duplicates, then remove them through
 BULK submitters)              fields don't match.                   the SDDS


 Patient id fields             SUS removes the content of            On submission of sensitive records e.g.
 populated for sensitive       these fields                          IVF as defined in DSCN 41/98
 conditions.                                                         Providers are required to remove all
                                                                     patient identifiable data; nothing should
                                                                     be submitted in its place.
 Unpopulated or invalid        For records where no Provider         Provider Code should always be
 Provider codes                code is submitted, these will be      populated with a valid, current
                               excluded from PbR grouping            organisation code.
                               process and not appear in PbR
                                                                     http://nww.connectingforhealth.nhs.uk/o
                               extracts. Invalid (usually out of
                                                                     ds
                               date) Provider codes may cause
                               confusion for users of SEM or
                               PbR extracts, and require
                               mapping to valid codes in HES.

 Maternity tails – large       Values for the first and only baby    This problem happens during XML
 number of delivery            are sometimes populated through       translation. Once the interchanges have
 records containing            all tails in the CDS submission       landed in SUS, Providers should run a
 spurious birth tails.         creating data that appears to         SEM extract to make sure duplication
 Typically 6 delivery tails    represent 6 or sometimes 9            hasn't occurred.
 are present.                  identical babies for a single
                               delivery.


 Providers submitting          These will be 'cleaned' in HES        Delivery and Birth episodes should be
 maternity data (CDS           Autocleans to become Maternity        submitted as the correct CDS type.
 types 120 or 140) as          records, by looking at the            Refer to the Maternity Data Quality
 general episodes (CDS         Procedure code or DOB/Episode         Dashboard for numbers of General
 type 130)                     Start Date/ Admission Method/         records that HES will clean to Maternity.
                               Episode Order, which will relate
                               to maternity. However this will
                               leave blank fields that are
                               mandatory in SUS because these
                               fields are not available in general
                               CDS type.




                                                Page 26 of 31
Secondary Uses Service – Best Practice Guide




    Data Quality Issue      Consequence                           Best Practice
 Submitting Critical Care   This puts unnecessary data            Critical care data should only be
 records with every APC     processing pressure on SUS            appended to an APC record once the
 episode                                                          Critical care activity has taken place



 Unpopulated or invalid     The majority of invalid               Commissioner Code should always be
 Commissioner codes         Commissioner Codes are due to         populated with a valid, current
                            out of date/invalid Primary Care      organisation code. Refer to the Data
                            Trust codes. The implication of       Quality Dashboards or Quarterly
                            this invalid data element is that     Publication reports for information on
                            the record will hold-up PbR           counts of errors.
                            processing for that Provider
                            organisation. A missing               http://nww.connectingforhealth.nhs.uk/o
                            Commissioner Code could result        ds
                            in the Provider receiving no
                            payment.



 Losing data that was       One reason could be because the       Refer to table referencing CDS types
 submitted under an         Sender is submitting the general      with BRGs.
 earlier interchange        CDS types (120,130,140)
                            separately (for Bulk submitters       Refer to the Mixing Bulk and Net
                            only). These should all be sent       guidance.
                            under the one BRG (Bulk
                                                                  http://www.connectingforhealth.nhs.uk/s
                            replacement Group). Otherwise
                                                                  ystemsandservices/sus/reference/index
                            the latest CDS type will overwrite
                                                                  _html#reg
                            the previous CDS types for the
                            same reporting period.
                                                                  Also check Monthly Reconciliation
                            Another reason could be if the
                                                                  report for counts from the DQ website.
                            Sender is mixing Bulk and Net
                            interchanges. Without                 http://www.connectingforhealth.nhs.uk/s
                            understanding the protocols           ystemsandservices/sus/delivery/dataqu
                            clearly these can overwrite each      ality
                            other. It is not recommended to
                            mix Bulk and Net. Another reason
                            - using incorrect BULK Start and
                            End dates in submissions to
                            SUS.


 High number of             A valid HRG has not been              Refer to the Data Quality Dashboard to
 ungroupable HRG            successfully derived in SUS and       determine if the number of ‘U’ codes is
 codes being assigned       so no tariff can be applied. This     higher than expected, and to the Error
 by SUS PbR (UZ01Z)         could be because key fields for       Extracts from PbR Online for detailed
                            derivation are not populated/valid,   reasons for these errors.
                            such as Diagnosis.




                                            Page 27 of 31
Secondary Uses Service – Best Practice Guide




    Data Quality Issue       Consequence                           Best Practice
 Unpopulated or Invalid      It is not possible to determine the   Site Code of Treatment should always
 Site Code of Treatment      hospital site where treatment took    be populated with a valid, current and
 codes                       place. This could have potential      accurate organisation site code. The
                             impacts on monitoring of patient      code should not end in '00' as this gives
                             safety, and limits the use of the     no information on site, and all records
                             information for patient choice.       for a Provider should not be submitted
                                                                   under the same site code. Refer to the
                                                                   Data Quality Dashboards or Quarterly
                                                                   Publication reports for information on
                                                                   counts of errors.
                                                                   http://www.connectingforhealth.nhs.uk/s
                                                                   ystemsandservices/sus/delivery/dataqu
                                                                   ality
                                                                   To register additional site codes follow
                                                                   guidance at the link below:
                                                                   http://www.connectingforhealth.nhs.uk/s
                                                                   ystemsandservices/data/ods
 Invalid NHS Number          The code 90 is not a valid code       Valid codes for NHS Number Status
 Indicator (e.g. 90 or       and should not be submitted.          Indicator should be submitted.
 single character codes)     Submission of single character
                             codes does not meet the
                             standard of values ('01' to '08'),
                             and will mean that SUS cannot
                             derive GP and PCT fields from
                             PDS data.


 Future Outpatient (CDS      Submitting these in the               Future appointments should be
 021) Appointments in        Outpatient CDS results in poor        submitted as CDS 021. When the
 Outpatient CDS 020 (i.e.    data quality in a number of fields    outpatient appointment has happened
 where Attended Or Did       that aren't relevant to future        the submitted Future Outpatient data is
 Not Attend = 0)             appointments.                         not refreshed in SUS.


 Invalid clinical codes in   A&E clinical codes (Diagnosis,        Standards should be followed for the
 A&E CDS                     Investigation and Treatment) are      submission of these codes. See NHS
                             6-character codes concatenating       CfH Data Dictionary.
                             a number of codes that should be
                             submitted in specified positions of
                             the code. Inconsistency in the
                             submission of each part of the
                             codes can lead to them being
                             misinterpreted, and can result in
                             the records being ungroupable by
                             SUS PbR.


 Missing or invalid          Lack of diagnosis code will lead      Valid diagnosis code should be
 Diagnosis Codes,            to records being ungroupable by       submitted for all records.
 including the use of the    SUS PbR, and also limits the
 'R69X' code.                other secondary uses of the data.




                                              Page 28 of 31
Secondary Uses Service – Best Practice Guide




    Data Quality Issue     Consequence                           Best Practice


 Unpopulated or Invalid    Limits the use of SUS data for        PCT of Residence should always be
 PCT of Residence          geographical purposes,                populated with a valid, current
 codes                     particularly for sensitive records    organisation code. Refer to the Data
                           where SUS will remove the             Quality Dashboards for information on
                           patient's postcode. It could also     counts of errors.
                           impact on validity of the Prime
                           Recipient field.


 Invalid CDS Activity      CDS Activity Date should be           CDS Activity Date should always be
 Date                      populated with the same date as       populated with the originating date.
                           the 'originating date' within the
                           CDS (e.g. Episode End Date in
                           APC, Appointment Date in OP
                           etc). Where this is not the case,
                           the incorrect Age at Activity Date
                           could have been assigned,
                           derivations from PDS may not be
                           from the correct time period, and
                           there will be impacts on the data
                           included in future SUS reports.


 Incorrect construction    Where the construction of this        The standard for construction of this
 of CDS Unique ID          field includes patient identifiers,   field should be followed. See NHS CfH
                           there is a potential Information      Data Dictionary.
                           Governance risk, as this field is
                           not anonymised for sensitive
                           records.


 Inclusion of sensitive/   Inclusion of sensitive/patient        VGP fields should not be populated in
 patient information in    information in free-text VGP fields   data submitted to SUS.
 Very General Purpose      is a potential Information
 (VGP) fields              Governance risk.


 Unpopulated or Invalid    Lack of Ethnic Category code (or      Ethnic Category should be recorded
 Ethnic Category codes     overuse of the 'not known' or 'not    and submitted. Senders should migrate
                           stated' codes) limits the             to CDSv6.1 as soon as possible to
                           monitoring that can be done for       allow the flow of this information for the
                           ‘health inequalities related to       Outpatient and A&E CDS types.
                           ethnic diversity’.



 Inconsistency between     In cases where Operation Status       Both fields should be populated with a
 Procedure codes and       indicates that a procedure took       valid, consistent code. Refer to the
 Operation Status          place, but no OPCS code has           Data Quality Dashboards for
                           been submitted, it is impossible to   information on counts of errors.
                           determine what happened to the
                           patient. This limits the use of the
                           data and could have financial
                           implications in PbR.


                                            Page 29 of 31
Secondary Uses Service – Best Practice Guide




    Data Quality Issue      Consequence                               Best Practice



 Invalid Source of          DSCN16-2007 revised the list of           Only the new valid codes should be
 Referral for Outpatients   codes for this field. Not all             submitted. Refer to the Data Quality
                            Providers have transitioned to the        Dashboards for information on counts of
                            new set of values, which has              errors.
                            resulted in inconsistency of the
                            field at a national level, limiting its
                            use.


 Unpopulated or Invalid     The Time fields in the A&E CDS            Times should always be submitted, as
 A&E times                  are not always all submitted, and         accurately as possible. Refer to the
                            where they are there can be               Data Quality Dashboards for
                            tendencies for these not to be            information on counts of errors.
                            correct to the minute. This limits
                            the use of the data for measuring
                            waiting times in A&E.


 Unpopulated or Invalid     NHS Number is key to make it              NHS Number should be submitted
 NHS Number                 possible to "share patient                (except for sensitive records or those
                            information safely, effectively and       covered under Section 10 of the Data
                            accurately across NHS                     Protection Act). Refer to the Data
                            organisations". Missing NHS               Quality Dashboards or SUS KPI report
                            Numbers will impact on tracing            for information on counts of errors.
                            patients, linking SUS data and
                            the ability for SUS to derive
                            additional fields from PDS.




                                              Page 30 of 31
Secondary Uses Service – Best Practice Guide




12 APPENDIX 2 - GLOSSARY OF TERMS

 A&E                Accident and Emergency
 APC                Admitted Patient Care
 BRG                Bulk Replacement Group
 CAB                Choose and Book
 CDS                Commissioning Data Set
 CRG                Care Record Guarantee
 DH                 Department of Health
 DPA                Data Protection Act
 DQ                 Data Quality
 ECC                Ethics and Confidentiality Committee
 EDT                Electronic Data Transfer
 HES                Hospital Episode Statistics
 MHMDS              Mental Health Minimum Data Set
 N3                 National Broadband Network for the NHS
 NHS                National Health Service
 NHS CfH            NHS Connecting for Health
 NHS IC             NHS Information Centre for Health and Social Care
 NIGB               National Information Governance Board
 NPfIT              National Programme for IT
 NWCS               NHS-Wide Clearing Service
 ODS                Organisational Data Service
 OP                 Outpatient
 PbR                Payment by Results
 PCT                Primary Care Trust
 PDS                Patient Demographics Service
 PIP                Pseudonymisation Implementation Project
 RBAC               Role Based Access Control
 RTT                Referral to Treatment
 SDDS               Strategic Data Deletion Service
                    CfH Service Bridge - act as a contact point for BT High Severity Incident
                    Management and High Severity Dispute, as they facilitate and communicate the
 Service Bridge
                    status of the Service for the National IT programme along with mediation back to the
                    End User
 SHA                Strategic Health Authority
 SUG                SUS User Group
 SUS                Secondary Uses Service
 TATD               Tactical Authority To Deploy
 TMS                Transaction Messaging Service
 UUID               Unique User Identifier
 XML                Extensible Mark-up Language (encoding) for information




                                              Page 31 of 31

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:121
posted:5/14/2011
language:English
pages:31