Secondary Uses Service SUS Project SUSPbR Payment by Results Awareness Events

1
Secondary Uses Service (SUS) ProjectSUS/PbR
(Payment by Results) Awareness Events

• July 2005

2
Welcome and Housekeeping
3
Agenda

• Introductions
• Aims and Objectives
• Update on SUS Project
• PbR Overview and Managed Service
• Demonstration of PbR application
• Break (approx. 1045)
• Data Quality
• Questions and Answers

4
Introductions
5
Aims and Objectives

• Communicate the status and future of the SUS
  Project
• Share information on PbR implementation progress
• Provide an overview of PbR, and describe the
  Managed Service
• Demonstrate the PbR application
• Identify Data Quality issues and requirements
• Opportunity for you to ask questions about the
  project/PbR

6
Update on SUS Project
7
NHS Care Records

• A single electronic health care record for every
  individual in England
• life-long history of patients health and care
  information regardless of where,
  when and by whom they were treated
• providing healthcare professionals with immediate
  access to medical records and care notes 24/ 7
• supporting the NHS to collect and analyse
  information, monitor health trends and to make
  the best use of clinical and other resources
• secure access and audit trails

8
Secondary Uses Service

• The central repository of health data for
  secondary uses
• Most data to be collected or derived from
  clinical systems as a by-product of direct care
• SUS has all NHS related activity and other
  non-patient record based data.
• Provides the tools and services for an effective
  and secure working environment for analysis and
  reporting

9
Possible Applications for SUS

• Payment by Results
• Access and Choice
• Commissioning, referral patterns, total waits
• Healthcare Commission
• Standards and performance monitoring
• Public health
• Screening ,surveillance, epidemiology
• Patient safety
• Longitudinal studies, adverse drug reactions
• Research and Development
• Effectiveness, outcomes

10
SUS Release 1 from mid 2005

• Support for Payment by Results (PbR)
• Calculation of spells, groups and tariffs
• Initially providing
• Data extracts for each Trust and PCT
• Then introducing
• Further reporting
• Data quality reports
• Online access for analysis and pulling extracts
• Standard derived fields

11
SUS Release 2 early 2006

• Replacement of NHS-Wide Clearing Service
• Facilities to support Payment by Results in
  2006/2007
• Capability to analyse demographics from the
  Personal Demographic Service (PDS)
• Pseudonymisation
• Change to XML formats, enabling greater
  validation of data submissions

12
SUS Release for later in 2006

• Implementation of Cancer Waiting Times
• Implementation of other clinical audit, including
  cancer, CHD and diabetes
• Further functionality and reporting to support
  Payment by Results
• Storage of central returns
• Generation of first central returns (e.g.
  Attribution Data Set (ADS))

13
Confidentiality

• What facilities will the NHS Care Record Service
  provide ?
• Access Control
• Pseudonymisation
• Presentation facilities
• Data quality

14
Confidentiality Actions

• Work with pilot sites
• Liaison with
• PIAG
• SCAG
• CRDB (Care Record Guarantee)
• Iterative development

15
Update on Payment by Results
16
Where we are now

• SUS will be delivered through a set of phased
  releases
• Firstly, via a Managed Service
• Then, via on-line access
• Managed service will start to provide data as at
  29/07
• On line service pilot begins during August
• Training and on-line access will be made
  available from September / October

• XML migration and NWCS replacement will follow
  once testing and end user training have been
  delivered

17
SUS Implementation - Initial Stage
18
SUS Implementation - Second Stage
19
PbR Overview
20
Reminder - PbR scope for 05/06

• PbR in 05/6 now elective APC only
• Full PbR undertaken in shadow mode
• Except
• Foundation Trusts may also operate full PbR
• Early adopters Including South Yorks SHA
• Note change from OATS in 05/06 payment flows
  are now any provider to any Commissioner

21
PbR Requirements

• Assured calculation of national tariffs
• Assured grouping algorithm
• Ability to
• maintain a frozen view of data to support
  financial reconciliation
• support dialogue between commissioner and
  provider when data is queried
• provide extracts to user systems on-line
  reports
• see how charges are made up, why episodes have
  been excluded from PbR spells etc, etc

22
PbR Process
23
Hospital Provider PbR Spell

• All CDS APC, out-patient AE data received by
  NWCS pulled in to SUS PbR and is available for
  inspection
• 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

24
PbR - Grouping

• SUS Grouped HRG used for calculations
• Provider supplied HRG also maintained
• New data causes all episodes in spell to be
  re-grouped for consistency
• SUS PbR uses IC Grouper (Woodward, UNIX)
• Data adjusted (grouping purposes only) to
• Remove punctuation, non-printable characters
• Remove dagger and asterisk flags
• Remove local coding in 5th digit of diagnosis
• Remove morphology codes

25
PbR APC Processing - Exclusions
26
PbR - Reporting payment
SUS PbR Processes
Trust Actions
Commissioner actions
Episode grouping Spell Construction
Check errors re-submit corrections
Option to monitor
Derive currencies apply tariffs
Extract downloads
On-line reports
Current view
Check output
Check output?
27
PbR - Reporting Periods Cut-off Dates

• DH have identified five financial periods
• Q1 to Q3
• Initial and Final in Q4
• Q1 Flex date subject to review Q1 may be shadow
  
• Recent changes
• Some revisions to detail alignment to week-end
  for Q2
• First freeze extended
• Cut-off time is 2359

28
SUS Update Processing

• EDIFACT - as received - constrained by timing of
  NHS submissions
• User Defined Format (passed via McKesson) -
  allow up to 5 days to process

29
PbR Assurance

• Formal testing module, end to end, integration
  etc
• Comparative analysis 550,000 GM records via SUS
  PbR compared with the same data analysed by DH
  team
• Changes made to algorithms to make them more
  robust given variations in in-bound data

30
Commissioner Access

• .for PbR access is by Commissioner
• SUS cannot assign Commissioner for Providers
• Information Governance concerns
• Data will not flow where Commissioner codes
  are invalid/wrong
• Refer to DH guidance on SUS PbR (on web)

31
What SUS PbR does not do

• Contract monitoring We do not hold local data
• Issue invoices SUS is not a financial system
• Take full account of the impact of local
  flexibilities after all, theyre localthough
  derivation to identify re-admission
• Undertake automatic verification against area of
  residence etc prior to applying tariff our aim
  is to facilitate payment, not stop it and the
  information that Commissioners need to check is
  there
• Allow on-line correction - we need to maintain
  consistency with end systems.change through
  resubmission

32
PbR Managed Service
33
SUS PbR Managed Service

• The Managed Service will provide access to PbR
  data for admitted patient care
• The managed service provides a routinely updated
  snapshot extract of spells and the episodes in
  them
• Reports are accessed via SUS portal however
• Only pre-processed managed service reports are
  available
• RBAC control is manually set-up by BT against UUID

34
Component Architecture
PbR Data
PbR Staging
Data Validation
Metadata
Cleanse Data
HRG Derivations
Episode to Spell
Released Data
35
Example Reports
36
Extract Report Structure

• Extract provides CDS data for spell and episodes
  derivations and in two files ( control)

Hospital Provider Spell data
Spell Error Flag
PbR Spell Derivations
Elements TOTAL
CDS Data
Episode in HP Spell

• All Spells returned non-qualifying flagged
• Approach try and create spells where possible,
  flag errors
• Derivations and payment components
• Spell ID supports episode and spell linkage
• All Episodes exclusions and dominant flagged

37
Spell Extract PbR Additions
38
PbR Extracts Identifying Invalid Data

• Extracts generally contain two fields for
  submitted dimensions
• Submitted
• Indexed
• Indexed field will show ??? where data not in
  reference tables. Check submitted field to see
  what was actually submitted

39
Accessing your data

• Access is via SUS Portal
• Log on to Spine access SUS
• Extract downloads will be available for download
• After Q1, there will usually be 2 sets of
  reports
• immediate past
• current quarter

40
3 Steps to get access

• Register on Spine
• Register for SUS with GUID
• Log on to SUS once, asap so that you are known
  to the application

BT Cannot schedule your report until all 3 steps
are completed
41
Demonstration of PbR Application
Tom Rawley Ardentia
42
Break (15 mins)
43
Data Quality
Linda Shurlock SUS Project Data Quality Lead
44
Your Data

• Needs to be good quality to successfully load
  onto SUS
• Needs to load onto SUS to be processed for PbR
• SUS will provide an authoritative mechanism for
  applying national tariffs to data, so
• For PbR the information supporting the payments
  must be comprehensive, timely and correct.

45
Good data quality for SUS/PbR will result in

• Accurate data for commissioners and for national
  reporting
• Good decision-making
• More effective running of your business
• Timely and detailed clinical information
• Better patient care

46
Poor data quality

• PbR specific
• Creates uncertainties in the system
• Will cause providers to lose money
• General
• Misinforms
• Impairs accountability
• Impairs decision support
• Increases risk
• Undermines governance

47
Data quality support we are providing

• Awareness events
• Advice on web site
• Extract report
• Web-based tool

48
Why will SUS reject your data ?

• Inaccuracies with dates
• Issues with Prime Recipient
• Oversized fields (after additional EDIFACT
  processing)
• Textual data in Numeric Fields
• SUS always rejects at interchange not record
  level this is stricter than you are used to
  with NWCS rules
• Interchange rejection causes your organisation a
  processing queue.

49
SUS Data Load Maintenance
50
Dates

• Activity dates new concept - critical dates
  for SUS processing, eg EPISODE END DATE for
  Finished Consultant Episodes- used as basis for
  batch updates (except Elective Admission List
  CDS)
• Reject interchange if- Activity dates NULL or
  invalid
• - Activity dates on records inconsistent with
  header dates for period covered reduces risk of
  inadvertent duplication or deletion

51
Prime Recipient and Commissioner

• Errors in the Prime Recipient Code will cause the
  interchange to fail if
• The Prime Recipient code is invalid
• The code is not listed on the National
  Organisation Codes files (NACS)
• NB check guidance before changing codes which
  have successfully loaded on NWCS to avoid
  unwanted duplicates
• For PbR, Trusts must correctly identify the
  commissioner responsible for the activity

52
Oversized fields

• Input data will be trimmed to remove leading and
  following spaces
• If the output data is numeric, leading zeros will
  be trimmed from the input field
• If the data is still too long for the output
  field as specified in the Data Dictionary, the
  interchange will be rejected

53
Two special cases

• Commissioner Serial Number (6 characters)
• If the field content is greater than 6
  characters, only the first 6 will be stored
• NHS Number aim for full capture
• If the old NHS number( gt 10 characters) is
  provided, the field is set to NULL. The old
  number is not stored.

54
Numeric fields

• Numeric fields, for the Admitted Patient Care
• records, are
• Number of Augmented Care Periods (ACP)
• Age at Census
• ACP number
• Birth Order
• Birthweight
• Diagnosis Sequence
• Episode Number
• Gestation Length
• CDS Message Reference Number
• Procedure Sequence
• Total Previous Pregnancies
• Alpha characters in these fields will cause
  interchange rejection

55
More SUS/PbR data load issues

• Local codes in systems must be mapped to the
  national code before submission
• Only First Forename and Surname accepted
• Detention Category will be ignored
• Demographic data has to be right - for PCT
  allocation
• Administrative Category must be correct - for
  Private Patients

56

• Data Quality PbR

57
Processing for PbR- Treatment Function

• Treatment Function code is used in DH technical
  guidance to define exclusions and out-patient
  tariffs
• There are workarounds where treatment function
  codes are missing for APC
• There are no workarounds available in the case of
  out-patients

58
Processing for PbR Spell Construction
Variables

• Episode Number
• Provider Spell Number
• Last Episode in Spell Indicator
• Date of Birth
• Sex (Gender)
• Postcode
• NHS Number
• Discharge date

59
PbR Data Quality Issues

• Poor clinical coding will cost
• APC tariffs based on HRG for the dominant
  episode. In 05/06 the dominant episode is the
  highest cost episode
• As a rule higher complexity gt higher tariff
  higher complexity lt deeper, accurate coding
• There is no tariff on a U-Code check them and
  resubmit with coding completed

60
Clinical Coding in PbR

• Sources of data error include
• Missing secondary diagnoses
• Complications and co-morbidities missing
• Incomplete record

61
Example of incomplete coding

• Example 1 Incomplete coding
• I21.1 (ICD 10) Acute transmural myocardial
  infarction of inferior wall
• I44.1 (ICD 10) Atrioventricular block, second
  degree
• HRG E12 Costs 1185
• Correct Coding
• I21.1 (ICD 10) Acute transmural myocardial
  infarction of inferior wall
• I44.1 (ICD 10) Atrioventricular block, second
  degree
• K60.1 (OPCS) Implantation of intravenous cardiac
  pacemaker
• Y70.5 (OPCS) Temporary operations
• HRG E07 Costs 2998

62
Example of incomplete coding

• Example 2 Incomplete coding
• T21.3 (ICD10) Burn of third degree of trunk
• T22.1 (ICD10) Burn of first degree of shoulder
  and upper limb except wrist and hand
• S36.2 (OPCS) Full thickness autograft of skin nec
• HRG J26 Costs 2489
• Correct Coding
• T21.3 (ICD10) Burn of third degree of trunk
• T22.1 (ICD10) Burn of first degree of shoulder
  and upper limb except wrist and hand
• T31.2 (ICD10) Burns involving 20-29 body surface
• S35.2 (OPCS) Meshed split autograft of skin nec
• Z49.3 (OPCS) Skin of anterior trunk
• HRG J20 Costs 6987

63
PbR potential for differences in grouping

• Things SUS takes account of before grouping
• Remove non-printable characters
• Remove punctuation (hyphen, full stop etc)
• Remove dagger and asterisk codes (trailing
  D,A), Remove morphology codes (6 characters
  starting M8, M9)
• Remove 5th digit when and only when these are
  local extensions
• Local grouping should do the same, but often
  doesnt

64
Useful References and Websites

• http//www.dh.gov.uk/PolicyAndGuidance/Organisatio
  nPolicy/FinanceAndPlanning/NHSFinancialReforms/fs/
  en
• DH Payment by Results
• http//www.hesonline.nhs.uk/
• Hospital Episode Statistics HES online
• http//www.connectingforhealth.nhs.uk/
• http//www.connectingforhealth.nhs.uk/programmes/s
  us/
• National Programme for IT (NHS Connecting for
  Health) plus SUS
• web pages this provides a link to a set of
  useful documents including SUS Validation Rules
  (Ref NPFIT-NCR-DES-0906.02).
• http//nww.nhsia.nhs.uk/nacs/pages/default.asp
• National Administrative Codes Service (NACS)

65
Go back to basics

• CHECK
• YOUR DATA QUALITY
• YOUR DATA PROCESSING
• YOUR WORKING RELATIONSHIPS

66
Questions and Answers
67
Aims and Objectives

• Communicate the status and future of the SUS
  Project
• Share information on PbR implementation progress
• Provide an overview of PbR, and describe the
  Managed Service
• Demonstrate the PbR application
• Identify Data Quality issues and requirements
• Opportunity for you to ask questions about the
  project/PbR

68
Thank you Please complete and return evaluation
forms www.connectingforhealth/programmes/sus