SUS Data Quality Briefing,

1

• SUS Data Quality Briefing,
• London, June 2007

2
Agenda
3
SUS DevelopmentsOpportunities and Challenges
Roger Dewhurst Director of Operations,
Information Centre for health and social care
4
Objectives of SUS

• Improve access to data to support the business
  requirements of the NHS and its stakeholders
• Provide a range of software tools and
  functionality which enable users to analyse
  report and present this data
• Be the single, authoritative and comprehensive
  source of high quality data to
• enable linkage of data across all care settings
• ensure the consistent derivation of data items
  and construction of indicators for analysis
• improve the timeliness of data for analysis
  purposes
• Provide a secure environment which enables
  patient confidentiality to be maintained
  according to national standards

5
What is SUS?
Commercial in Confidence

• The single repository of person and care event
  level data relating to the NHS care of patients.
• Data is submitted by all organisations providing
  NHS care
• At present SUS receives data submissions (CDS)
  relating to
• Accident and emergency attendances
• Outpatient attendances
• Admitted patient care, including maternity care
• Elective admission waiting lists
• Mental health care spells
• In 2007/8 SUS will also receive data from Choose
  and Book and the Patient Demographics Service, as
  well as new CDS relating to future appointments
  and diagnostic events
• In future SUS will receive data relating to
  patients prescriptions and will have the
  capability of managing data relating to the
  primary and social care provided to patients and
  service users.

6
What is SUS?
Commercial in Confidence

• SUS comprises
• A common and consistent information governance
  model
• Access control
• Use of pseudonyms to replace identifiers
• Design (e.g. small number suppression etc.)
• A core data warehouse and data marts
• Consistent metadata and reference data
• Associated applications utilising data from the
  core warehouse
• Consistent analysis and reporting tools

7
What is SUS?
Commercial in Confidence
Security and confidentiality ensured by
consistent access control and design
PBC Support
Landing
Staging
Web based application for Practices, PCTs, SHAs
Universal Data Warehouse
HES
A Core Warehouse and Data Marts
Data submitted by all providers of NHS acute
and Mental Health Care
HES reports and extracts
PBR
NHS CDS Extract
Other Extract
Clinical Audit
Consistent metadata business and technical
Extracts for Non NHS organisations
Extracts and Reports to all PCTs, Trusts, SHAs
8
SUS Releases in 2007/8

• Release 1 for PBR 07/08 and data for PBC
  comparators (April 2007)
• PBC Comparators (May 2007)
• Improvements to interchange tracking (end of June
  2007)
• Release 2 giving non-functional upgrade to Oracle
  10g and uplift for more users
• Further improvements in data quality reporting
  and a strategic data deletion service
• Release 3L providing landing capability for cds
  v6, plus loads from PDS and Choose and Book
• Release 3R providing processing and reporting for
  18 weeks and further reporting for PBC

9
Opportunities

• A single secure data management environment
  provides the ability to construct consistent
  comparators and indicators
• Expressed demand and incidence
• Identified prevalence
• Efficiency and productivity
• Outcomes
• Relating to service providers, commissioning
  organisations, registered and area populations
  etc.

10
Opportunities

• A single secure data management environment
  provides an opportunity to reduce transaction
  costs of implementing systems reforms through
• Enabling access to data
• Deriving essential data items consistently and
  once
• Undertaking standard processing

11
Immediate Data Quality Challenges

• Ensuring that the data currently submitted to and
  managed within SUS is
• Comprehensive
• Timely (for different uses)
• Consistent with agreed standards
• Accurate

12
Immediate Information Governance Challenges

• Supporting NHS analysis requirements, while
  ensuring the security and confidentiality of
  identifiable data
• Meeting the Governments commitment to minimise
  the use of identifiable data for non-direct care
  purposes

13
Immediate local implementation challenges

• Achieving the migration from Edifact to XML
  submissions
• Must be completed before Release 2 of SUS
• A significant opportunity to improve data quality
  and adherence to NHS standards
• Migrating from the use of bulk protocols for data
  submission
• Reduces processing time and complexity
• Quicker access to data
• Improved linkage
• Reduces occurrence of duplicate records

14
Immediate Data Quality Challenges

• Improving the coverage of data
• Missing data
• Ensuring interchanges, which are rejected are
  resubmitted in a timely fashion
• Up to date contact details
• Creation of duplicate records
• Ensuring the correct use of update protocols

15
Immediate Data Quality Challenges

• Improving the content of individual records
• Invalid and inaccurate data
• Prevents consistent linkage of data
• Prevents commissioners accessing data
• Leads to incorrect financial payments
• Leads to misleading comparators and indicators
• Increases the unnecessary and inappropriate use
  of identifiable data

16
Immediate Data Quality Challenges

• Who needs to address these challenges
• Providers of NHS care
• Improve standards for patient record keeping
• Invest in support services and training
• Implement quality assurance programmmes
• Commissioners
• Require improvements through the contracting
  process

17
Immediate Data Quality Challenges

• Who needs to address these challenges
• IC / CfH
• Ensure improved functionality in SUS to track
  data and identify data quality problems
• Publish guidance and provide support
• Publish data on quality and enable comparison
• DH / SHAs
• Performance manage organisations to improve
  quality
• Regulators and Auditors
• Audit and review data quality
• Systems Suppliers
• Comply with NHS Standards

18
Forthcoming Challenges

• Implementing local processes that
• Enable more frequent submission of data
  (including future activity) to allow prospective
  and retrospective analysis of the achievement of
  the 18 weeks target
• Ensure accurate and full clinical coding in line
  with PbR payment cycles and commissioners
  requirements
• Ensure data is comprehensive and accurate to
  support comparator construction
• Ensuring that the data submitted to SUS in the
  future meets requirements
• redefining the information model to reflect care
  service developments
• filling the gaps

19
Commissioning Data Set 6
20
Commissioning Data Set purpose

• Allows organisations to receive activity level
  data
• Supports Commissioning
• Feeds Hospital Episode Statistics
• Covers
• Past, current and future admitted patients
  including day case, long stay and psychiatric
• Past and future out-patients including
  ward-attenders, nurse/midwife/therapist and
  diagnostics
• Past Accident and Emergency attendances

21
Commissioning Data Set 6

• Evolution over 15 years, not revolution
• Move to re-use common components
• Summary of time-table
• Notice of change published in May '06
• Schema and Tables published May 07
• Expected to be mandatory April 08

22
Commissioning Data Set 6

• XML protects the integrity of the data
• Commissioning Data Set 5 has proved challenging
  to some providers
• Prevents invalid data for almost all fields
• Exceptions include NACS, ICD, OPCS, READ

23
Categorisation of data quality
24
Categorisation of data quality
25
If the admission is in a series of regular day or
night admissions Then use either National Code 0
or 1 Otherwise, dont send the field
26
A number
One digit long
Values 0 or 1
27
(No Transcript)
28
Main new content

• PbR
• Paediatric and neonatal critical care
• Discharge ready date
• Age

• 18 Weeks
• Pathway identifier
• RTTP data items
• Future out-patients
• Earliest reasonable offer date

29
Big impact - Content

• Future out-patients
• Elective Admission List
• Critical Care
• Patient Pathways
• Referral to treatment periods
• Diagnostic systems

30
Big impact - Submission

• Frequency moving to within 4 days of a change
• Net change protocol for all routine submissions

31
Timetable - content
32
Timetable - submission
33
Key contact information

• The Dictionary www.datadictionary.nhs.uk
• The help desk datastandards_at_nhs.net
• The service website www.connectingforhealth.nhs.uk
  /datastandards
• Open days
• Courses
• Excel copy of validation table
• Consultation site access forthcoming standards

34
SUS PbR Reconciliation

• John Nickson
• SUS Project Team

35
Business drivers

• Wrangling between PCTs and Trusts over
  differences in data when problems reflect
  differences in timing
• Concern over inconsistent local application of
  derivations and tariff, and grouping
• PCTs have problems in handling a wide range of
  divergent local data
• Problems for PCTs in managing a large number of
  divergent flows
• Need to support national monitoring, analysis and
  indicators
• On the basis of reconciliation work lack of an
  audit trail from episode to tariff in many local
  systems

36
SUS PbRBusiness Functions

• Provide assured processes for
• grouping
• identification of APC currencies (spells)
• application of national tariffs
• Provide a consistent view of data to support
  dialogue between Commissioner and Provider
• Maintain a frozen view of data to support
  financial reconciliation around flex and freeze
  dates
• Output via patient extracts requires local
  analysis
• Does not provider local contract functionality

37
Why do we need to reconcile SUS-PbR?
The issue Although SUS-PbR output has been
available for some months now, many NHS
organisations are not yet using the output. There
have been issues of data quality, but although
these have been substantially resolved, there
remains mistrust of the data. As SUS-PbR is
intended to be the definitive source of PbR
information this is a problem.
The reconciliation approach A standard
reconciliation process is being developed that
NHS organisations can follow to provide
reassurance that the SUS-PbR output can be
trusted. This reconciliation will cover both
activity (spells) and finance ( PbR
Spend/Income). Processes will be available for
both commissioners and providers
The benefit NHS organisations can use SUS-PbR
output as intended, which will provide definitive
information. Thus will reduce the need (and
cost) of running and auditing local systems that
duplicate processes, and have to be individually
locally updated as PbR changes nationally. The
NHS can adopt SUS PbR as the definitive source.
38
What needs to be reconciled ?
lt Local
Systems gt
Data Validation
Grouper
Spell Construction
Tariff
For both Commissioners and Providers
39
What has been done previously ?
Some acute providers and some PCTs have carried
out financial reconciliation (PbR income/spend)
internally
SUS-PbR
Local Systems
Landing
Staging
HES
Some reconciliation between Local Systems and
Staging, available from IC. This is activity
only, and is only CDS type by provider.
Reconciliation between SUS-PbR and HES being
conducted by IC. This is activity only, by
provider.
40
What have been the results?
41
How much can be reconciled ? PbR financial
coverage
PbR covers about 60 of Acute Spending,
representing around 50 of PCT spend

• Includes
• Community services
• Mental health services
• Ambulance services (other than patient transport
  services)
• Learning disabilities
• Primary Care Services
• Walk in Centres

42
How much can be reconciled ? Local thresholds
Non Elective IP To share financial risk between
providers and commissioners, a tariff of 50 will
applies to emergency spells above a 2005/06
outturn threshold. If the threshold level of
activity is not met, 50 of tariff will be
withdrawn for the difference between actual and
threshold.
AE Organisations will be funded at tariff for
their planned weighted activity.
Under-performance will be withdrawn at 20 of
tariff over performance will be funded at full
tariff.
43
How much can be reconciled ? Other local
commissioning
Collaborative Commissioning Although there may
be a tariff, an individual PCT will not pay
actual activity x tariff, as commissioning is
pooled across a geographical area. (Mainly
Elective IP)
Local Tariff Unbundling Where PCT have agreed
local prices for standard tariff items, or a
local care pathway has unbundled part of the
treatment normally included in a standard tariff.
(Mainly, but not exclusively Outpatients)
44
To summarise How much can be reconciled?

• Actually, it can all be reconciled
• Known exceptions are very easy to identify at a
  local level
• The value of known exceptions will vary
  organisation-by-organisation

45
How is this being done ?

• SUS Programme Team lead/carry out reconciliation
  of one PCT and one acute provider pair
• Refine process based on experience
• Produce draft guidance for NHS organisations
• Second PCT and Acute Provider pair carry out own
  reconciliation, using draft guidance with SUS
  Programme Team in support
• Refine process based on experience
• Produce final guidance for NHS organisations
• Roll out nationally
• SUS Programme Team to provide initial support on
  request.

46
Different scenarios

• Ease of reconciliation depends on a range of
  issues
• Maintenance of net key
• Ability to access data as sent to SUS
• Audit trail within local systems
• Critical items
• Importance of adopting a step by step approach
• Start small to establish process
• Importance of using data from PbR tail

47
Data returned

• All CDS data is returned
• APC Starts by creating hospital provider spell
  and then excluding in accordance with DH
  algorithm
• All episodes in Hospital Provider Spell
  maintained, linked to spell, with reason for
  exclusion if excluded

Static definition
Hospital Provider Spell
0
PbR Spell
Used to define PbR APC Currency - likely to
change
Episodes In PbR
PbR Excluded episodes
Episodes in Hospital Provider Spell
48
Spell data
Episode summary
49
Underlying detail
50
Data Quality, Data Submissions and SUS

• Lorraine Gray
• SUS Data Quality Advisor

51

• Data Quality
• Overview
• Issues
• Examples
• Who uses the data?
• SUS update

52
Data Quality

• Good quality health care information is essential
• For
• Planning
• Performance management
• Activity reporting
• Monitoring of targets
• Clinical care

53
Data Quality

• The Acute sector provides the majority of health
• related data, however this is changing.
• CDS version 6
• Extends the number of mandated datasets
• Includes new data for 18 week waiting times
• Now incorporates Diagnostics
• All these new requirements will bring new
  challenges
• to provides of NHS care

54
Data Quality

• SUS is populated with NHS data!
• Providers and Commissioners have a responsibility
  to
• make sure that all staff collecting, managing and
  the
• collating data are trained and fully aware that
  data
• must be
• Accurate
• Consistent
• Timely
• Fit for Purpose

55
Data Quality issues

• Coverage
• Duplicate Records
• Missing Data
• Deficient Record Content
• Non standard values
• Missing values
• Incorrect values

56
Data Quality

• Duplicate Records
• Statement
• Duplicate records are created by SUS
• Answer
• No SUS does not create duplicate records
• These are created because CDS senders fail to
• apply data manual standards and rules.

57
Data Quality

• So how are duplicate records created? Cont.
• By changing the CDS Sender Identity. This is a
  NACS code and the problem is caused by failing to
  consistently use the same format. If a submitting
  organisation switches between the formats Rnn00,
  Rnn or Rnn01 then duplicate records will be
  produced despite these all being different and
  legitimate variants of the same organisations
  NACS code.
• By changing the CDS Prime Recipient Identity.
  This is again a NACS code and duplication can be
  caused by changing between variants as above. It
  is also caused by changing the primary recipient
  when organisation codes change. PCTs merged in
  October and for example 5G7 and 5G8 merged to
  become 5NH. Changing the prime recipient from 5G7
  to 5NH will cause duplication when resubmitting
  data relating to activity before October

58
Data Quality

• How are duplicate records created? Cont.
• 3. Natural duplicates. This is caused when the
  provider sends the same record twice in the same
  file as two different records. This is usually
  because someone has entered the patient event
  twice on their system.
• 4. False Duplicates. These are not duplicates
  but are where a shared service user requests data
  for two different organisations and the data may
  be accessed by both. For example if you live in
  Leeds but are registered with a GP in Wakefield
  both organisations will be able to access your
  data.

59
Data Quality

• Duplicates why do they occur?
• Mistakes by senders, often when organisations
  merge or the inconsistent application of NACS
  organisation codes.
• As a result of inadequate functionality in local
  source systems e.g. deficiencies in the local PAS
• Suppliers inappropriately/inadvertently changing
  sender codes e.g. changing translation suppliers
• Duplication rates rose in 2006/07 as a result
• of the mid year PCT re-organisation.

60
Data Quality examples

• HES Duplications Q3 2006/07

61
Data Quality examples

• SUS Duplications 2006/07 year end

62
Data Quality examples

• Missing Data
• Whole periods of data missing e.g. one or more
  months
• CDSs not submitted
• e.g. 204 provider sites submit data for hospital
  based deliveries CDS type 140 whilst -

63
Only 23 providers submit data for other
deliveries CDS type 160
64
Data Quality examples

• AE 2006/07
• Activity Providers
• QMAE 11,410,462 169
• SUS 10,378,279 121
• Difference -1,032,183 -48
• Financial Difference 61,930,980

65
(No Transcript)
66
(No Transcript)
67
Data Quality

• Field level issues
• GP GP Practice
• Post Codes
• NHS number coverage
• Ethnicity
• Decision to admit date
• Treatment function codes
• Consultant codes

68
(No Transcript)
69
(No Transcript)
70
(No Transcript)
71
(No Transcript)
72
(No Transcript)
73
(No Transcript)
74
Data Quality

• Why do field level errors occur?
• This data is recorded and collected by
• Receptionists (OP, AE)
• Medical Records
• Clinical Coders
• Secretaries
• Ward Clerks
• Nurses
• Doctors
• Allied Health Professionals and Others

75
Data Quality

• Why do field level errors occur?
• This data is recorded and collected by
• Receptionists (OP, AE)
• Medical Records
• Clinical Coders
• Secretaries
• Ward Clerks
• Nurses
• Doctors
• Allied Health Professionals and Others

76
Data Quality

• How can we prevent field level data issues?
• Systems which are fit for purpose and collect
  data to the expected standards. PAS,
• AE Maternity, Diagnostics etc.
• If local derivations of data are collected they
  must be mapped back to national
• standards for CDS submission purposes.
• Medical Record standards content and legibility.
• All staff must be trained and be competent in the
  use of systems and have an
• awareness of the
• Purpose of data collection
• Standards of data collection
• Timeliness of data collection

77
Who uses Secondary Uses Data?

• Department of Health
• Audit Commission
• Healthcare Commission
• Imperial College
• Public Health Observatories
• Clinicians
• Others

78
Who uses Secondary Uses Data?

• Requests for Information

79
Examples of data requests

• How many hospital admissions for asthma sufferers
  there were in (a) England, (b) North Yorkshire
  and (c) York and the Humber in the latest period
  for which figures are available?
• What the average waiting time was for (a)
  in-patient, (b) day cases and (c) out-patient
  appointments at each hospital in London in (i)
  1992, (ii) 1997, (iii) 2001, (iv) 2005 and (v)
  the most recent year for which figures are
  Available?
• What assessment she has made of the survival
  rates from (a) heart attack and (b) all cancers
  (i) for the most recent period for which figures
  are available, (ii) in 1997 and (iii) in 1987.
  134158. This is answered using a combination of
  HES and ONS deaths data

80
SUS Update

• Interchange Processing
• Data Integrity
• Service Tracking DQR
• Helpdesk
• Data Deletion
• XML

81
Interchange Processing

• BT working hours 9 hours 5 days a week 08.00 to
  17.00.
• SLA target based upon processing average over a
  month
• 8 hours from receipt of data to availability on
  Tracker
• 4 business hours to notify end user of
  interchange failure
• status
• 4 business hours to notify IC of interchange
  failures
• 12 hours from receipt of data to its availability
  on DQR
• 60 hours from receipt of data to availability in
  PbR Mart
• 60 hours from receipt of data to availability in
  Extract mart

82
Interchange Processing

• Please Note
• These timescales may be a bit longer at times of
  exceptionally high data processing demand
  (e.g.Flex/ Freeze/HES year end)
• Occasionally normal processing may be suspended
  for a short period, for example when data
  deletions are being performed. This may affect
  how long your interchanges take to process.
• Moving to XML is expected to improve/reduce
• processing times.

83
Interchange Processing

• Most failures are associated with Bulk
  submissions!
• Bulk Submissions
• Review submission schedules do you need to send
  all this data month on month?
• More risk
• Processing implications
• Net Submissions
• Have you thought about changing to NET
  submissions?
• If not it is worth discussing with your
  suppliers.
• Less risk

84
Interchange Processing

• Most common failures for CDS Types
• Unfinished / Psychiatric Census
• EDIFACT
• 50mb file size limit (EDIFACT)
• Elective Admission Lists

85
Interchange Processing

• Volumes

86
Data Integrity

• Monthly staging reports continue to be published
• by CDS type on SUS website
• The SUS/HES data input team have contacted a
• number of organisations who have data gaps and
• duplicate records.
• Coverage has improved since Q3

87
SUS Tracker and DQR reporting

• Tactical interchange tracking deployment due end
  of June 2007
• Tactical DQR deployment due Sept/Oct 2007
• Review of all outstanding BT Assyst calls
• Continuing with interim weekly and monthly
  reporting

88
Helpdesk

• General apprehension in the quality and content
• of helpdesk responses
• Often explanations rather than resolution
• Timeliness of responses
• Escalation ask for the team leader
• We are working with BT and IC staff to improve
  services

89
Data Deletion

• Tactical Solution
• APC (120, 130 140), OP and AE
• Intention to clean duplicates before
• 15th June 2007 HES year end
• PbR Q4 Freeze
• Emailed all Trusts on the 11th May who have
  previously raised Assyst calls for Data Deletion
• Emailed all Trusts who we believed may have
  duplicates

90
XML

• All existing service providers (ESPs) now have
• Tactical Approval to Deploy.
• 488 EDI addresses submit CDSs
• 18 organisations have gone live with XML V5
• 204 organisations have registered to send test
  XML
• 47 organisations are sending tests XML
• We believe the slow migration to live is due to
  the PbR
• Q4 freeze and HES year end on the 15th June and
  that
• organisations are being cautious before
• moving to live.

91
(No Transcript)