Waiting Times Validation Manual - ISD Scotland...Waiting Times Validation Version: 4.2 4 ISD...

Waiting Times Validation

Version: 4.2

Waiting Times Validation Manual Version 4.2 published July 2016

Version history

Title Waiting Times Validation Manual

Date Published July 2016

Version V 4.2

Document status Final

Author Stuart Kerr

Owner Service Access, National Information and Intelligence, ISD Scotland

Approver Fiona MacKenzie

Version Date Summary of Changes

1.0 February 2009 No previous version

1.1 March 2009 Removal of commas, change to wording (VE58A, VE76, VE77, VE96)

2.0 September 2009 New Refresh flags indicating error impact added. New rules of VE11A, VE11B, VE60C, VE60D added with flag 1. VE9, 9A, 67-78, 91 and 92 switched off. Appendix E added with summary of validation errors and flags.

2.1 April 2010 Changes not released

Re wording of VE35, VE35A and VE35B. VE34 relaxed and replaced with VE34A and VE34B. VE61B relaxed and replaced with VE61C, D,

F, G, H and I. VE60A and VE60B switched off as their validation is

encompassed in VE61H and VE61I .

2.2 23 May 2010 Re wording of VE35, VE35A and VE35B. VE34 relaxed and replaced with VE34A and VE34B. VE61B relaxed and replaced with VE61C, D, F, G. VE60A and VE60B re-instated.

2.3 October 2010 VE60C and VE60D relaxed and replaced by VE60E and VE60F. VE60C and VE60D switched off.

3.0 August 2011 New rules VE120, RTT1A, RTT1B, RTT2, RTT3, RTT4, RTT5 and RTT6 added in conjunction with revised schema v0-7.xsd.

3.1 January 2012 Correction to Appendix E to remove reference to VE32 and VE47A. These rules have always been switched off.

4.0 July 2014 Updated manual to bring into line with redeveloped warehouse in line with TTG guidance.

4.1 October 2015 VE42, VE107, VE111A, VE112 and VE112A switched off.

4.2 July 2016 New rule VE129 added


Version: 4.2

Linked Documentation

Document Title

Waiting Times Recording Manual

CEL32: Patient Rights (Scotland) Act 2011 – Treatment Time Guarantee Guidance

CEL 33: NHS Scotland Waiting Time Guidance


Version: 4.2

0

INTRODUCTION 1

USING THIS DOCUMENT 3

VALIDATION RULES 5

APPENDIX A: VALIDATION ERROR SUMMARY AND ALLOCATION OF FLAGS 28

APPENDIX B: FILE SCHEMA 32


Version: 4.2 1

Introduction

This guidance gives detail of the validation that is applied to waiting times records that are submitted to the Waiting Times Data Mart. The data for monitoring waiting times is held centrally within the Data Mart, and is sourced from individual Patient Administration Systems (PASs) in use throughout Scotland. As there are many different types of PAS, there is not a definitive list of validation checks that are performed within every system. For this reason, when loading data into the Waiting Times Data Mart, validation is performed to ensure its integrity. Records are subjected to two levels of validation:

Level 1: The format of the file is validated to check that the file has been submitted in the correct format. If the file fails Level 1, an automated e-mail is sent to pre-agreed recipients to advise them that the file has failed. The problem with the file needs to be resolved and the file resubmitted.

Level 2: The content of the file is validated to ensure that the file’s contents comply with predefined data rules necessary for monitoring waiting times. This document contains the validation rules that are currently being applied to the waiting times data.

An automated e-mail is sent when the validation has completed to advise recipients how many records have passed/failed validation, with a breakdown of the assigned flags. A further automated load e-mail is sent when the data has loaded into the warehouse. The detail of the validation results can be viewed in the Waiting Times Error Reporting Business Objects Universe https://www.bi.nhsnss.scot.nhs.uk/. The validation results in two types of error:

Schema Errors

Data Errors

Schema Errors Schema Errors apply to records which contain an error that will corrupt the data mart if they are not rejected. Information on records with schema errors is only available in the Waiting Times Error Reporting Universe. There are two types of schema error:

S1: cases where the type of data item submitted is inconsistent with the data type, i.e. when a date is submitted in a non date format.

S2: Cases where the integrity of the data structure is corrupted. For example, where an appointment record has been submitted for a patient but there is no information on the patient currently in the data mart to link the record to (i.e. VE118A)


Version: 4.2 2

Data Errors Flags are added to all records that pass schema validation to identify whether the record is fully valid or contains an error that can affect the calculation of wait. There are four flags:

0: All data passes current business validation. This data is suitable for National Statistics publication.

1: Data fails business validation but the error does not significantly affect the quality of the data. A wait can still be calculated. This data is suitable for National Statistics publication.

2: Data fails business validation which affects the quality of the data however a wait can still be calculated. This data is not suitable for National Statistics publication.

3: Data fails business validation which significantly affects the quality of the data and a wait is not calculated. This data is not suitable for National Statistics publication.

A record can only be allocated one flag. If a single record contains multiple validation errors the

flag allocated will relate to the most serious scenario:

See Appendix B for the allocation of flags to validation rules.

Any changes to the validation rules go through the Validation Change Control Process (Appendix A), overseen by the Validation Group.


Version: 4.2

3 ISD Scotland

Using this Document

This document describes the validation rules that are applied to each record.

For each validation rule the following information is given: Rule Reference: A reference number is allocated to each validation rule Error Message: This is the message that is displayed in the BO Universe summarising why a record has failed a validation rule

Affected Data Items: These are the data items that are directly involved in producing the validation error and therefore need to be investigated in order to resolve the error prior to resubmission

The WT or GEN reference in brackets following each Data Item (e.g. Referral Date (WT1)) is the reference used in the Waiting Times Recording Manual.

Rule Notes: The notes gives details of what the validation is conditional on, i.e. if the rule is only valid for New Outpatients where the Initial Start Date is on after 01/01/2009

Numbers shown in brackets refer to the code given to the Data Item Category, e.g. the Non-Attendance Category of Could Not Attend (2).

There are a limited number of data items that are identified as mandatory in this document. Where a data item is identified as being mandatory, this means that it is required for all records whether partial or complete. Where a field is mandatory under certain circumstances, this will be defined as part of the rule notes.

Flag: This indicates the type of schema error or flag associated with the data error.

Points to note on validation and terminology: Initial Start Date The Initial Start Date is referred to in some of the rules and this relates to the date when the patient’s wait started. The Initial Start Date for New Outpatients is the Referral Received Date and the Initial Start Date for Inpatients, Day Cases and Return Outpatients is the Waiting List Date. Patient Removed from List A patient is deemed to have been removed from the Waiting List when either the Removal Date or Removal Reason has been supplied. Dates All dates must be in the valid format ccyymmdd when submitted in the extract. This may differ from how the date appears in the PAS.


Version: 4.2

4 ISD Scotland

Appointment Information If a validation rule refers to an Offer of Appt/Admission this is checking that a data item from the list below has been submitted with the same file ID and MUI:

Offer Type

Offer Date

Appt/Admission Date

Response Received Date

Offer Outcome

Non-Attendance Date

Non-Attendance Category

Non-Attendance Outcome

Subsequent Offers If a validation rule refers to Subsequent Offers the data items listed under Appointment Information are used to determine how subsequent offers are ordered. The offer ordering needs to be derived from the data items submitted because there is no time stamp included in the data set. Subsequent offers are important for the calculation of wait because declining subsequent offers and the non-attendance of appointments resets the clock. Unavailability information If a validation rule refers to a Period of Unavailability this is checking that a data item from the list below has been submitted with the same file ID and MUI:

Unavailability Type

Unavailability Start Date

Unavailability End Date Review Information If a validation rule refers to a Review this is checking that a data item from the list below has been submitted with the same file ID and MUI:

Unavailability Start Date

Planned Review Date

Review Date

Review Outcome


Version: 4.2

5 ISD Scotland

Validation Rules

Rule Reference: VE2

Error Message: Referral Received Date must be a valid date in the format ccyymmdd

Affected Data Items: Referral Received Date (WT2)

Rule Notes: Conditional check applied only when a Referral Date has been supplied

Flag: S1

Rule Reference: VE3

Error Message: Referral Received Date must be supplied for New Outpatients


Rule Notes: Conditional check applied only when the Patient Type is New Outpatient (21)

Referral Received Date is mandatory for New Outpatients because it is used as the Initial Start Date when measuring waiting

Flag: 3

Rule Reference: VE4

Error Message: Referral Received Date must be a valid date in the format ccyymmdd


Rule Notes: Conditional check applied only when a Referral Received Date has been supplied

Flag: S1

Rule Reference: VE5

Error Message: Referral Received Date must be on or after the Referral Date

Affected Data Items: Referral Received Date (WT2); Referral Date (WT1)

Rule Notes: Conditional check applied only when a Referral Received Date and Referral Date have been supplied

A patient’s referral cannot be received prior to the patient being referred. If a telephone referral is made and followed by written confirmation the date of the telephone referral should be recorded as the Referral Received Date

Flag: 3


Version: 4.2

6 ISD Scotland

Rule Reference: VE6

Error Message: Referral Received Date must be on or before the Extract Submission Date


Rule Notes: Conditional check applied only when a Referral Received Date has been supplied A patient’s referral cannot be in the future

Flag: 2

Rule Reference: VE7

Error Message: Waiting List Date must be supplied for Inpatients/Day Cases and Return Outpatients

Affected Data Items: Waiting List Date (WT3)

Rule Notes: Conditional check applied only when Patient Type is Inpatient (01), Day Case (11) or Return Outpatient (23)

Waiting List Date is mandatory for this group of patients because it is used as the Initial Start Date when measuring waiting

Flag: 3

Rule Reference: VE8

Error Message: Waiting List Date must be a valid date in the format ccyymmdd


Rule Notes: Conditional check applied only when a Waiting List Date has been supplied

Flag: S1

Rule Reference: VE10

Error Message: Waiting List Date must be on or before the Extract Submission Date


Rule Notes: Conditional check applied only when a Waiting List Date has been supplied

A patient cannot be added to the waiting list in the future

Flag: 3


Error Message: Invalid Waiting Time Standard Code used

Affected Data Items: Waiting Time Standard (WT4)

Rule Notes: Conditional check applied only when a Waiting Time Standard has been supplied

Flag: 2


Version: 4.2

7 ISD Scotland


Error Message: Invalid Urgency Category Code used

Affected Data Items: Urgency Category (WT5)

Rule Notes: Conditional check applied only when an Urgency Category has been supplied

Flag: 1


Error Message: Offer Type must be supplied for an Offer of Appt/Admission

Affected Data Items: Offer Type (WT6)

Rule Notes: Conditional check applied only when: - Appt/Admission data have been submitted for that MUI - Patient Type is Inpatient (01), Day Case (11), New Outpatient (21), Return Outpatient (23)

Offer Type is mandatory where an offer exists because the validation for Written and Verbal offers differs from the validation for PFB offers, i.e. VE14A

Flag: 3


Error Message: Invalid Offer Type Code used

Affected Data Items: Offer Type (WT6)

Rule Notes: Conditional check applied only when an Offer Type has been supplied

Flag: 3

Rule Reference: VE14A

Error Message: Incompatible combination of Offer Type and Offer Outcome

Affected Data Items: Offer Type (WT6); Offer Outcome (WT10)

Rule Notes: Conditional check applied only when Offer Type and Offer Outcome have been supplied

Where Offer Type is Written (01) or Verbal (02) the Offer Outcome must not be Responded to PFB invite (50, 60)

Where Offer Type is PFB (3) the Offer Outcome can only be Responded to PFB invite (50, 60) or No Response (70, 80, 90)

Flag: 3


Error Message: Offer Date must be supplied for an Offer of Appt/Admission

Affected Data Items: Offer Date (WT7)


Version: 4.2

8 ISD Scotland

Rule Notes: Conditional check applied only when: - Appt/Admission data have been submitted for the MUI - Patient Type is Inpatient (01), Day Case (11), New Outpatient (21), Return Outpatient (23)

The Offer Date is one of the data items used to order the offers of appointment

Flag: 3


Error Message: Offer Date must be a valid date in the format ccyymmdd


Rule Notes: Conditional check applied only when an Offer Date has been supplied

Flag: S1


Error Message: Offer Date must be on or after the Waiting List Date for Inpatients/Day Cases and Return Outpatients

Affected Data Items: Offer Date (WT7); Waiting List Date (WT3)

Rule Notes: Conditional Check applied only when: - an Offer Date has been supplied - the Patient Type is Inpatient (01), Day Case (11) Return Outpatient (23)

A patient cannot be offered an appointment before they have been added to the waiting list

Flag: 3


Error Message: An accepted Appt/Admission Date can only be within a Period of Unavailability when associated with a Non-Attendance Category

Affected Data Items: Appt/Admission Date (WT8); Unavailability Start Date (WT20); Unavailability End Date (WT24); Offer Outcome (WT10); Non-Attendance Category (WT16)

Rule Notes: Conditional Check applied only when: - an Appt/Admission Date has been supplied - Offer Outcome is Accepted (10) - the patient has been removed from the list - the Initial Start Date is after the 31/12/2007 - the Patient Type is Inpatient (01), Day Case (11), New Outpatient (21), or Return Outpatients (23)

When the patient has been removed from the waiting list an accepted appointment can only be recorded when the patient was unavailable if there is a non-attendance category associated with the appointment, i.e. the patient cancelled their appointment because they will be on holiday and are therefore unavailable

Flag: 3


Version: 4.2

9 ISD Scotland

Rule Reference: VE17B

Error Message: Offer Date must be on or after the Referral Received Date for New Outpatients

Affected Data Items: Offer Date (WT7); Referral Received Date (WT2)

Rule Notes: Conditional Check applied only when: - an Offer Date and Referral Received Date have been supplied - the Patient Type is New Outpatient (21)

A patient cannot be offered an appointment before their referral has been received

Flag: 3

Rule Reference: VE17C

Error Message: Removal Date must not be within a Period of Unavailability when the Removal Reason is 10; 11; 12 or 13

Affected Data Items: Removal Date (WT27); Unavailability Start Date (WT20); Unavailability End Date (WT24)

Rule Notes: Conditional Check applied only when: - a Removal Date has been supplied - the Removal Reason is Attended/admitted (10), Attended/admitted at GJNH (11), Attended/admitted at SRTC (12) or Attended/admitted at Private Sector (13) - Removal Date is after the 31/12/2007

A patient cannot attend an appointment whilst they are unavailable

Flag: 3


Error Message: Offer Date must be on or before the Extract Submission Date.


Rule Notes: Conditional check applied only when an Offer Date has been supplied An Offer Date cannot be in the future

Flag: 3


Error Message: Appt/Admission Date must be supplied for a Written or Verbal Offer

Affected Data Items: Appt/Admission Date (WT8)

Rule Notes: Conditional check only applied when: - an Offer of Appt/Admission has been supplied - Offer Type is Written (01) or Verbal (02)

If a Written or Verbal offer has been made then the Appt/Admission Date being proposed must be recorded. PFB Offers are only an invite to contact the hospital to arrange a date therefore an Appt/Admission Date would not


Version: 4.2

10 ISD Scotland

have been known when the letter was sent

Flag: 3


Error Message: Appt/Admission Date must not be supplied for a PFB Offer


Rule Notes: Conditional check applied only when Offer Type is PFB (03) PFB Offers are only an invite to contact the hospital to arrange a date therefore an Appt/Admission Date would not have been known when the letter was sent

Flag: 3


Error Message: Appt/Admission Date must be a valid date in the format ccyymmdd


Rule Notes: Conditional check applied only when an Appt/Admission Date has been supplied

Flag: S1


Error Message: Appt/Admission Date must be on or after the Offer Date

Affected Data Items: Appt/Admission Date (WT8); Offer Date (WT7)

Rule Notes: Conditional check applied only when an Appt/Admission Date and an Offer Date have been supplied

The Offer Date, which is the date the offer was made and not the date of the appointment offered, must be prior to the proposed Appt/Admission Date

Flag: 3


Error Message: Response Received Date must be a valid date in the format ccyymmdd

Affected Data Items: Response Received Date (WT9)

Rule Notes: Conditional check applied only when a Response Received Date has been supplied

Flag: S1


Error Message: Response Received Date must be on or before the Appt/Admission Date

Affected Data Items: Response Received Date (WT9); Appt/Admission Date (WT8)

Rule Notes: Conditional check applied only when the Response Received Date and


Version: 4.2

11 ISD Scotland

the Appt/Admission Date have been supplied

A response to an offer must be received prior to the Appt/Admission Date proposed in the offer

Flag: 3


Error Message: Response Received Date must be on or before the Removal Date

Affected Data Items: Response Received Date (WT9); Removal Date (WT27)

Rule Notes: Conditional check applied only when the Response Received Date and the Removal Date have been supplied

A patient cannot respond to an offer after they have been removed from the waiting list

Flag: 3


Error Message: Response Received Date must be on or after the Offer Date

Affected Data Items: Response Received Date (WT9); Offer Date (WT7)

Rule Notes: Conditional check applied only when the Response Received Date and the Offer Date have been supplied

A patient cannot respond to an offer before they have been made the offer

Flag: 3


Error Message: Offer Outcome must be supplied for an Offer of Appt/Admission

Affected Data Items: Offer Outcome (WT10)

Rule Notes: Conditional check applied only when Appt/Admission data have been submitted for the MUI

The Offer Outcome is used to determine whether the patient has accepted their appointment, is to be removed from the list or if the patient’s waiting time clock should be reset to the Response Received Date if they have declined two offers

Flag: 3


Error Message: Invalid Offer Outcome Code used

Affected Data Items: Offer Outcome (WT10)

Rule Notes: Conditional check applied only when an Offer Outcome has been supplied

Flag: 3


Version: 4.2

12 ISD Scotland


Error Message: Offer Outcome must be No Response (70 80 or 90) when there is no Response Received Date

Affected Data Items: Offer Outcome (WT10); Response Received Date (WT9)

Rule Notes: Conditional check applied only when an Offer Outcome has been supplied

Offer Outcome must always be completed even if the patient has yet to respond to the offer

Flag: 3


Error Message: Offer Outcome cannot be 70 80 or 90 when the Response Received Date has been entered

Affected Data Items: Offer Outcome (WT10); Response Received Date (WT9)

Rule Notes: Conditional check applied only when an Offer Outcome and the Response Received Date have been entered

Offer Outcome cannot be No Response – Awaiting Decision (70), No Response – New offer made/to be made (80), No Response – Removed from list (90)

Flag: 3


Error Message: Invalid Non-Attendance Category Code used

Affected Data Items: Non-Attendance Category (WT16)

Rule Notes: Conditional check applied when a Non-Attendance Category has been supplied

Flag: 3


Error Message: Non-Attendance Category must be supplied where an offer has been accepted and a subsequent offer exists

Affected Data Items: Non-Attendance Category (WT16)

Rule Notes: Conditional check applied only on Offer of Appt records that are not the first offer

A further offer cannot be made if the patient has already accepted an offer unless that offer has been cancelled or not attended

This rule is dependent on how the offers have been ordered

Flag: 3



Version: 4.2

13 ISD Scotland

Error Message: Non-Attendance Date; Non-Attendance Category and Non-Attendance Outcome must all be supplied for a Non-Attendance

Affected Data Items: Non-Attendance Date (WT17); Non-Attendance Category (WT16); Non-Attendance Outcome (WT19)

Rule Notes: Conditional check applied only when a Non-Attendance Date, Non-Attendance Category or Non-Attendance Outcome have been supplied

All data items that relate to a non-attendance must be supplied and are used in the calculation to determine the order of offers

Flag: 3


Error Message: Non-Attendance Date; Non-Attendance Category or Non-Attendance Outcome cannot be recorded where an offer has not been accepted

Affected Data Items: Non-Attendance Date (WT17); Non-Attendance Category (WT16); Non-Attendance Outcome (WT19) ; Offer Outcome (WT10)

Rule Notes: Conditional check applied only when: - an Offer Outcome has been supplied - the offer has not been Accepted (10)

The rationale for this rule is that a patient cannot fail to attend or cancel an appointment they have not agreed to

Flag: 3


Error Message: Non-Attendance Date must be a valid date in the format ccyymmdd

Affected Data Items: Non-Attendance Date (WT17)

Rule Notes: Conditional check applied only when a Non-Attendance Date has been supplied

Flag: S1


Error Message: Non-Attendance Date must be equal to the Appt/Admission Date where the Non-Attendance Category is Did Not Attend or Did Not Attend – Wait Unaffected

Affected Data Items: Non-Attendance Date (WT17); Appt/Admission Date (WT8)

Rule Notes: Conditional check applied only when: - a Non-Attendance Date has been supplied - the Non-Attendance Category equals Did Not Attend (3) or Did Not Attend – Wait Unaffected (7)

Flag: 3



Version: 4.2

14 ISD Scotland

Error Message: Non-Attendance Date must be on or before the Appt/Admission Date where the Non-Attendance Category is Could Not Attend or Could Not Attend – Wait Unaffected


Rule Notes: Conditional check applied only when: - a Non-Attendance Date has been supplied - the Non-Attendance Category equals Could Not Attend (2) or Could Not Attend – Wait Unaffected (6)

Flag: 3


Error Message: Non-Attendance Date must be on or before the Appt/Admission Date where the Non-Attendance Category is Cancelled by Hospital


Rule Notes: Conditional check applied only when: - a Non-Attendance Date has been supplied - the Non-Attendance Category equals Cancelled by Hospital (5)

Flag: 2


Error Message: Non-Attendance Date must be on or after the Response Received Date where the Non-Attendance Category is Could Not Attend or Could Not Attend – Wait Unaffected

Affected Data Items: Non-Attendance Date (WT17); Response Received Date (WT9)

Rule Notes: Conditional check applied only when: - a Non-Attendance Date and a Response Received Date have been supplied - the Non-Attendance category is Could Not Attend (2) or Could Not Attend – Wait Unaffected (6)

The patient cannot cancel an appointment before they have agreed to attend

Flag: 3


Error Message: Non-Attendance Date must be on or before the Extract Submission Date where the Non-Attendance Category is Did Not Attend.

Affected Data Items: Non-Attendance Date (WT17)

Rule Notes: Conditional check applied only when: - a Non-Attendance Date has been supplied - the Non-Attendance Category is Did Not Attend (3) - the Non-Attendance Category is Did Not Attend – Wait Unaffected (7)

Flag: 3


Version: 4.2

15 ISD Scotland


Error Message: Non-Attendance Date must be on or before the List Removal Date

Affected Data Items: Non-Attendance Date (WT17); Removal Date (WT27)

Rule Notes: Conditional check applied only when a Non-Attendance Date and a List Removal Date have been supplied

The patient cannot fail to attend or cancel an appointment after they have been removed from the list. If this was allowed and the clock was reset this would result in a negative wait

Flag: 3


Error Message: Non-Attendance Date must be on or after the Initial Start Date

Affected Data Items: Non-Attendance Date (WT17); Referral Received Date (WT2), Waiting List Date (WT3)

Rule Notes: Conditional check applied only when: - a Non-Attendance Date has been supplied - Patient Type is Inpatient (01), Day Case (11), New Outpatient (21), Return Outpatient (23)

The patient cannot fail to attend an appointment before they have been added to the waiting list. If this was allowed the clock would be reset to a date prior to their initial start date

Flag: 3


Error Message: If the Offer Outcome is 10 (Accepted) a subsequent offer can only be made if there has been an associated non-attendance with non-attendance outcome 20 (Retained) or 90 (to be confirmed)

Affected Data Items: Subsequent Offer of Appt Records


The validation does not need to check that there has been a non-attendance recorded just that the Non-attendance Outcome is 20 or 90 because VE28 & VE29 check that there must be a Non-Attendance Outcome specified for a Non-Attendance Category.

Flag: 3


Error Message: A subsequent offer cannot be made where the Offer Outcome of the current offer is 30 (Declined – Removed from list) or 60 (Responded to PFB invite – invitation declined/not wanting appointment) or 90 (No response – Removed from list).



Version: 4.2

16 ISD Scotland


There is no requirement to account for NULLs in this validation rules. If the Offer Outcome is NULL this will produce a VE24 error and the record will be allocated a Flag 3. The validation is not checking offer outcomes of 40 (Declined – Awaiting decision) and 70 (No response – Awaiting decision)

Flag: 3


Error Message: Subsequent Offers of Appt/Admission can only be accepted where the patient has responded to the current offer



Flag: 3


Error Message: Subsequent offers cannot be made before the date of cancellation or date of DNA of the current offer


Rule Notes: Conditional check applied only on Offer of Appt records that are not the first offer where the previous appointment is associated with a non-attendance

Flag: 3


Error Message: Subsequent offers cannot be made before the Response Received Date of the current offer


Rule Notes: Conditional check applied only on Offer of Appt records that are not the first offer where the Offer Outcome is NOT No Response – new offer made/to be made (80)

A subsequent offer can only be made after the Response Received Date of the previous offer.

Flag: 3


Error Message: Unavailability Start Date must be supplied for a Period of Unavailability

Affected Data Items: Unavailability Start Date (WT20)

Rule Notes: Conditional check applied only when Unavailability information has been supplied


Version: 4.2

17 ISD Scotland

Flag: 3


Error Message: Unavailability Start Date must be a valid date in the format ccyymmdd

Affected Data Items: Unavailability Start Date (WT20)

Rule Notes: Conditional check applied only when an Unavailability Start Date has been supplied

Flag: S1


Error Message: Unavailability Type must be supplied for a Period of Unavailability

Affected Data Items: Unavailability Type (WT21)

Rule Notes: Conditional check applied only when a Period of Unavailability has been supplied

The type of unavailability affects how the wait is calculated

Flag: 3


Error Message: Invalid Unavailability Type Code used


Rule Notes: Conditional check applied only when Unavailability Type has been supplied

Flag: 3


Error Message: Indefinite Unavailability can only be submitted on records where the Initial Start Date is on or after 01/10/2012.


Rule Notes: Conditional check applied only when Unavailability Type has been supplied

Flag: 3


Error Message: The Unavailability End Date must be specified for all but the final Period of Indefinite Unavailability

Affected Data Items: Unavailability End Date (WT24)


Flag: 3


Version: 4.2

18 ISD Scotland


Error Message: The Unavailability End Date must be specified for all periods of Definite Unavailability


Rule Notes: Conditional check applied only when a Period of Definite Unavailability has been supplied

Flag: 3


Error Message: The Unavailability End Date must be a valid date in the format ccyymmdd


Rule Notes: Conditional check applied only when Unavailability End Date has been supplied

Flag: S1


Error Message: Unavailability End Date must be on or after the Unavailability Start Date

Affected Data Items: Unavailability End Date (WT24); Unavailability Start Date (WT20)

Rule Notes: Conditional check applied only when Unavailability End Date and Unavailability Start Date have been supplied

Flag: 3


Error Message: Periods of Unavailability must not overlap

Affected Data Items: Unavailability Start Date (WT20); Unavailability End Date (WT24)


Flag: 3


Error Message: The Unavailability End Date must not fall before the Initial Start Date

Affected Data Items: Unavailability End Date (WT24); Referral Received Date (WT2); Waiting List Date (WT3)

Rule Notes: Conditional check applied only when: - an Unavailability End Date has been supplied - Patient Type is Inpatient (01), Day Case (11), New Outpatient (21), Return Outpatient (23)

Flag: 3


Version: 4.2

19 ISD Scotland


Error Message: Planned Review Date must be a valid date in the format ccyymmdd

Affected Data Items: Planned Review Date (WT23)

Rule Notes: Conditional check applied only when a Planned Review Date has been supplied

Flag: S1


Error Message: Review Date must be a valid date in the format ccyymmdd

Affected Data Items: Review Date (WT25)

Rule Notes: Conditional check applied only when a Review Date has been supplied

Flag: S1


Error Message: Removal Date must be a valid date in the format ccyymmdd

Affected Data Items: Removal Date (WT27)

Rule Notes: Conditional check applied only when a Removal Date has been supplied

Flag: S1


Error Message: Removal Date must be entered when a Removal Reason has been entered


Rule Notes: Conditional check applied only when a Removal Reason has been supplied. See VE59A.

Flag: 3


Error Message: Removal Date must be on or after the Waiting List Date

Affected Data Items: Removal Date (WT27); Waiting List Date (WT3)

Rule Notes: Conditional check applied only when a Removal Date and a Waiting List Date have been supplied

Flag: 3


Error Message: Removal Reason must be entered when a Removal Date has been entered


Version: 4.2

20 ISD Scotland

Affected Data Items: Removal Reason (WT28)

Rule Notes: Conditional check applied only when a Removal Date has been supplied. VE58A is checking that Removal Date must have a reason and this is doing the reverse check. Basically both data items have to be supplied.

Flag: 2


Error Message: Invalid Removal Reason Code used

Affected Data Items: Removal Reason (WT28)

Rule Notes: Conditional check applied only when a Removal Reason has been supplied

Flag: 2


Error Message: Removal Date must be on or after the Referral Received Date

Affected Data Items: Removal Date (WT27); Referral Received Date (WT2)

Rule Notes: Conditional check applied only when: - Removal Date and Referral Received Date have been provided

A patient cannot be removed from the list prior to their referral being received at the hospital. In cases where a telephone referral is made and followed by written confirmation the date of the telephone referral should be recorded as the Referral Received Date

Flag: 3


Error Message: Removal Date must be on or before the Extract Submission Date


Rule Notes: Conditional check applied only when - a Removal Date has been supplied

A patient cannot be removed from the list prior to the extract being taken

Flag: 3


Error Message: Removal Date must be the same as the Appt/Admission Date when the Outcome of Offer is 10 (Accepted) and the Removal Reason is 10 (Attended/Admitted)

Affected Data Items: Removal Date (WT27); Removal Reason (WT28); Appt/Admission Date (WT8)

Rule Notes: Conditional check only applied to New Outpatient, Day Case, Inpatient and Return Outpatient records where the Initial Start Date is on after the 31/12/2007


Version: 4.2

21 ISD Scotland

The Removal Date is used in the calculation of the patient’s waiting time, which is why it is important that it is recorded as the same date as the Appt/Admission. This rule does not take into consideration the fact that there may be a Non-Attendance associated with the accepted Appt/Admission Date.

Flag: 2

Rule Reference: VE61D

Error Message: Where the Removal Reason is 10 (Attended/Admitted) then an appointment must be recorded.

Affected Data Items: Removal Reason (WT28); Appt/Admission Date (WT8)


This rule will only check that there is an appointment recorded in the data mart. VE58A and VE59A check that Removal Date and Removal Reason must both be entered.

Flag: 3

Rule Reference: VE61F

Error Message: Where the Non-attendance Category is 5 (Cancelled by Service) and the Non-attendance Outcome is 10 (Removed) then the Removal Reason must not be 10 (Attended/admitted)

Affected Data Items: Removal Reason (WT28); Non-Attendance Category (WT16); Non-Attendance Outcome (WT19)


Flag: 2

Rule Reference: VE61G

Error Message: Where the Removal Reason is 10 (Attended/admitted) then the Offer Outcome of the most recent Appointment Date must be 10 (Accepted)

Affected Data Items: Removal Reason (WT28); Offer Outcome (WT10)


This rule will fire if the offer outcome was not 10 (accepted) i.e. if 20,30,40,50,70,90,99 or XX have been recorded. This rule will not fire if the Removal Date and Appt/Admission Date are different as this will be captured by the validation associated with VE61C.

Flag: 3


Version: 4.2

22 ISD Scotland


Error Message: Patient Type must be supplied

Affected Data Items: Patient Type (WT30)

Rule Notes: Must be present

Flag: 3


Error Message: Invalid Patient Type Code Used

Affected Data Items: Patient Type (WT30)

Rule Notes: Conditional check applied only when the Patient Type has been supplied

Flag: 3


Error Message: Postcode must be supplied

Affected Data Items: Postcode (GEN7)

Rule Notes: Must be supplied

Flag: 1


Error Message: Invalid Postcode Used

Affected Data Items: Postcode (GEN7)

Rule Notes: Conditional check applied only when Postcode has been supplied. See the Waiting Time Recording Manual for guidance on the correct format.

Flag: 1


Error Message: Location must be supplied on record closure for Inpatients/Day Cases and Return Outpatients

Affected Data Items: Location (GEN10)

Rule Notes: Conditional check applied only when Patient Type is Inpatient (01), Day Case (11) and Return Outpatient (23)

Flag: 2


Error Message: Location must be supplied on record closure for New Outpatients



Version: 4.2

23 ISD Scotland

Rule Notes: Conditional check applied only when Patient Type is New Outpatient (21) and the Removal Reason is Attended/admitted (10), Attended/admitted at GJNH (11), Attended/admitted at SRTC (12) or Attended/admitted at Private Sector (13)

The location of outpatient treatment may not be known until the patient has been removed from the list (treated)

Flag: 2


Error Message: Invalid Location Code used


Rule Notes: Conditional check applied only when: - Location Code has been supplied - the location type is where treatment can take place, i.e. not ADMOFFICE, ASCON, CPCON, HOSPWARD, or GPPRA, and where the records Initial Start Date falls before the Location Close Date on the reference file, i.e. the hospital is still open - Patient Type is Inpatient (01), Day Case (02), New Outpatient (21), Return Outpatient (23) - the Initial Start Date is after 31/12/2007

NB. Location type is checked when patient has been removed from list for attending appointment (Removal Reason 10, 11, 12 or 13).

Flag: 2


Error Message: Specialty must be supplied

Affected Data Items: Specialty (GEN11)


Flag: 2


Error Message: Invalid Specialty Code used

Affected Data Items: Specialty (GEN11)

Rule Notes: Conditional check applied only when Specialty has been supplied

Flag: 2


Error Message: Consultant/HCP Code must be supplied and must be in the correct format

Affected Data Items: Consultant/HCP (GEN12)

Rule Notes: Conditional check applied only when Patient Type is New Outpatients (21), Inpatients (01), Day Cases (11) and Return Outpatients (23)


Version: 4.2

24 ISD Scotland

Consultant/HCP Code is not mandatory for New Outpatients where the Removal Reason is Referred back to GP - inappropriate referral (42) Consultant/HCP Code is not mandatory for Inpatients, Day Cases and Return Outpatients (for procedure) where the Removal Reason is Inappropriate Addition to List (43) The Consultant/HCP Code must be 6, 7 or 8 characters in length and must agree with any of the following data formats: nnnnnn nnnnnnn Dnnnnnn nncnnnnc ccnnnnnn where n = any number (0-9), c = any letter (A-Z) & D = letter “D” Any of the four dummy codes are permitted if the Consultant/HCP is not known when the patient is added to the waiting list. To identify that the HCP is a Doctor (9999998), Dentist (D999999), Nurse (99X9999X) or AHP (XX999999) If the Consultant/HCP is in the correct format but does not exist on the National Reference Files a NULL key is assigned. For cases which have already been assigned the NULL key the system will attempt to find consultant/HCP until record closure

Flag: 2


Error Message: Patient Category must be supplied

Affected Data Items: Patient Category (GEN13)


Flag: 2


Error Message: Invalid Patient Category Code used

Affected Data Items: Patient Category (GEN13)

Rule Notes: Conditional check applied only when the Patient Category has been supplied

Flag: 3


Error Message: Missing or Invalid Provider Code

Affected Data Items: Provider Code (GEN15)


Version: 4.2

25 ISD Scotland

Rule Notes: Conditional check applied only when: - Patient Type is Inpatient (01), Day Case (02), New Outpatient (21), Return Outpatient (23) Must exist in the reference file (see Appendix B) where the records Initial Start Date falls after the Provider Open Date on the reference file, i.e. the Provider Code is a current valid code - the Initial Start Date is after 31/12/2007

Flag: 2


Error Message: A Mandatory Unique Identifier must be supplied

Affected Data Items: Mandatory Unique Identifier (MUI)


Flag: S2


Error Message: An Action Type must be supplied and must be an Insert (I) Amendment (A) or Delete (D)

Affected Data Items: Action Type


If a MUI is submitted for the first time and the Action Type is Amendment (A) the record will be treated as an Insert (I) and added to the Data Mart accordingly

Flag: S2


Error Message: MUI already exists and cannot be provided as an Insert against the sending location

Affected Data Items: Mandatory Unique Identifier (MUI)

Rule Notes: If a MUI already exists a subsequent record cannot be accepted with an Insert for the same MUI. The Action Type can only be Amendment (A) or Delete (D)

Flag: S2


Error Message: Appointment Record with this MUI has no corresponding master record

Affected Data Items: Record

Rule Notes: The MUI submitted for the Appointment Record must match a MUI in the Master Record in the incoming file

Flag: S2


Version: 4.2

26 ISD Scotland


Error Message: Unavailability Record with this MUI has no corresponding master record


Rule Notes: The MUI submitted for the Unavailability Record must match a MUI in the Master Record in the incoming file

Flag: S2


Error Message: Unavailability Review Record with this MUI has no corresponding master record


Rule Notes: The MUI submitted for the Unavailability Review Record must match a MUI in the Master Record in the incoming file

Flag: S2


Error Message: Multiple master records detected for MUI. Only one master record is permitted


Rule Notes: Duplicate master records cannot exist

Flag: S2


Error Message: Invalid UCPN format used

Affected Data Items: Unique Care Pathway Number (WT32)

Rule Notes: Conditional check applied only when a UCPN has been supplied

The UCPN must be 13 characters in length and the format SSS999999999C, where SSS is a three character alphanumeric system identifier (assigned by ISD), 999999999 is a 9 digit sequential number and C is a check character.

Flag: 1


Error Message: UCPN is invalid

Affected Data Items: Unique Care Pathway Number (WT32)

Rule Notes: Conditional check applied only when a UCPN has been supplied

Check character, calculated on preceding 12 characters, must be valid

Flag: 1


Version: 4.2

27 ISD Scotland


Error Message: Invalid RTT Clinic Outcome Code used

Affected Data Items: RTT Clinic Outcome Code (WT33)

Rule Notes: Conditional check applied only when a RTT Clinic Outcome code has been supplied

RTT clinic outcome code must be one of the National codes or will be zero keyed

Flag: 1


Error Message: RTT Clinic Outcome Code must be supplied on record closure for New or Return Outpatients

Affected Data Items: RTT Clinic Outcome Code (WT33)

Rule Notes: Conditional check applied only when Patient Type is New Outpatient (21) or Return Outpatient (23) and the Removal Reason is Attended/Admitted (10), Attended/Admitted at GJNH (11), Attended/Admitted at SRTC (12) or Attended/Admitted at Private Sector (13).

Flag: 1


Error Message: RTT Clinic Outcome Date must be a valid date in the format yyyy-mm-dd

Affected Data Items: RTT Clinic Outcome Date (WT34)

Rule Notes: Conditional check applied only when a RTT Clinic Outcome Date has been supplied

Flag: S1


Error Message: Invalid RTT Stop Reason Code used

Affected Data Items: RTT Stop Reason (WT36)

Rule Notes: Conditional check applied only when a RTT Stop Reason Code has been supplied

RTT Stop Reason Code must be one of the National Codes or will be zero keyed

Flag: 1


Error Message: RTT Stop Date must be a valid date in the format yyyy-mm-dd

Affected Data Items: RTT Stop Date (WT35)

Rule Notes: Conditional check applied only when a RTT Stop Date has been supplied


Version: 4.2

28 ISD Scotland

Flag: S1


Error Message: Records must not be submitted where the Initial Start Date is before 01 April 2009


Rule Notes: Records with Initial Start Date before 01 April 2009 will be rejected.

Flag: S2


Error Message: Records must not be submitted where the Initial Start Date is before 01 April 2009


Rule Notes: Records with Initial Start Date before 01 April 2009 will be rejected.

Flag: 3

Appendix A: Validation error summary and allocation of flags RULE REFERENCE

ERROR MESSAGE FLAG

2 Referral Date must be a valid date in the date format of ccyymmdd S1


Version: 4.2

29 ISD Scotland

3 Referral Received Date must be supplied for New Outpatients 3

4 Referral Received Date must be a valid date in the date format of ccyymmdd S1

5 Referral Received Date must be on or after the Referral Date 3

6 Referral Received Date must be on or before the Extract Submission Date 2

7 Waiting List Date must be supplied for Inpatients/Day Cases and Return Outpatients 3

8 Waiting List Date must be a valid date in the format ccyymmdd S1

10 Waiting List Date must be on or before the Extract Submission Date 3

11 Invalid Waiting Time Standard Code used 2

12 Invalid Urgency Category Code used 1

13 Offer Type must be supplied for an Offer of Appt/Admission 3

14 Invalid Offer Type Code used 3

14A Incompatible combination of Offer Type and Offer Outcome 3

15 Offer Date must be supplied for an Offer of Appt/Admission 3

16 Offer Date must be a valid date in the format ccyymmdd S1

17 Offer Date must be on or after the Waiting List Date for Inpatients/Day Cases and Return Outpatients 3

17A An accepted Appt/Admission Date can only be within a Period of Unavailability when associated with a Non-Attendance Category

3

17B Offer Date must be on or after the Referral Received Date for New Outpatients 3

17C Removal Date must not be within a Period of Unavailability when the Removal Reason is 10; 11; 12 or 13

3

18 Offer Date must be on or before the Extract Submission Date 3

19 Appt/Admission Date must be supplied for a Written or Verbal Offer 3

19A Appt/Admission Date must not be supplied for a PFB Offer 3

20 Appt/Admission Date must be a valid date in the format ccyymmdd S1

21 Appt/Admission Date must be on or after the Offer Date 3

22 Response Received Date must be a valid date in the format ccyymmdd S1

23 Response Received Date must be on or before the Appt/Admission Date 3

23A Response Received Date must be on or before the Removal Date 3

23B Response Received Date must be on or after the Offer Date 3

24 Offer Outcome must be supplied for an Offer of Appt/Admission 3

25 Invalid Offer Outcome Code used 3

26 Offer Outcome must be No Response (70 80 or 90) when there is no Response Received Date 3

26A Offer Outcome cannot be 70 80 or 90 when the Response Received Date has been entered 3

27 Invalid Non-Attendance Category Code used 3

28A Non-Attendance Category must be supplied where an offer has been accepted and a subsequent offer exists

3

29 Non-Attendance Date; Non-Attendance Category and Non-Attendance Outcome must all be supplied for a Non-Attendance

3

29A Non-Attendance Date; Non-Attendance Category or Non-Attendance Outcome cannot be recorded where an offer has not been accepted

3

30 Non-Attendance Date must be a valid date in the format ccyymmdd S1

31 Non-Attendance Date must be equal to the Appt/Admission Date where the Non-Attendance Category is Did Not Attend or Did Not Attend- Wait Unaffected

3

31A Non-Attendance Date must be on or before the Appt/Admission Date where the Non-Attendance Category is Could Not Attend or Could Not Attend- Wait Unaffected

3

31B Non-Attendance Date must be on or before the Appt/Admission Date where the Non-Attendance Category is Cancelled by Hospital

2

32A Non-Attendance Date must be on or after the Response Received Date where the Non-Attendance Category is Could Not Attend or Could Not Attend- Wait Unaffected

3

33 Non-Attendance Date must be on or before the Extract Submission Date where the Non-Attendance Category is Did Not Attend

3

33A Non-Attendance Date must be on or before the List Removal Date 3

33B Non-Attendance Date must be on or after the Initial Start Date 3

34A If the Offer Outcome is 10 (Accepted) a subsequent offer can only be made if there has been an associated non-attendance with non-attendance outcome 20 (Retained) or 90 (to be confirmed)

3

34B A subsequent offer cannot be made where the Offer Outcome of the current offer is 30 (Declined – Removed from list) or 60 (Responded to PFB invite – invitation declined/not wanting appointment) or 90 (No response – Removed from list).

3

35 Subsequent Offers of Appt/Admission can only be accepted where the patient has responded to the current offer

3


Version: 4.2

30 ISD Scotland

35A Subsequent offers cannot be made before the date of cancellation or date of DNA of the current offer 3

35B Subsequent offers cannot be made before the Response Received Date of the current offer 3

43 Unavailability Start Date must be supplied for a Period of Unavailability 3

44 Unavailability Start Date must be a valid date in the format ccyymmdd S1

46 Unavailability Type must be supplied for a Period of Unavailability 3

47 Invalid Unavailability Type Code used 3

47B Indefinite Unavailability can only be submitted on records where the Initial Start Date is on or after 01/10/2012.

3

48 The Unavailability End Date must be specified for all but the final Period of Indefinite Unavailability 3

48A The Unavailability End Date must be specified for all Periods of Definite Unavailability 3

49 The Unavailability End Date must be a valid date in the format ccyymmdd S1

49A Unavailability End Date must be on or after the Unavailability Start Date 3

50 Periods of Unavailability must not overlap 3

50A The Unavailability End Date must not fall before the Initial Start Date 3

52 Planned Review Date must be a valid date in the format ccyymmdd S1

54 Review Date must be a valid date in the format ccyymmdd S1

58 Removal Date must be a valid date in the format ccyymmdd S1

58A Removal Date must be entered when a Removal Reason has been entered 3

59 Removal Date must be on or after the Waiting List Date 3

59A Removal Reason must be entered when a Removal Date has been entered 2

60 Invalid Removal Reason Code used 2

61 Removal Date must be on or after the Referral Received Date 3

61A Removal Date must be on or before the Extract Submission Date 3

61C Removal Date must be the same as the Appt/Admission Date when the Outcome of Offer is 10 (Accepted) and the Removal Reason is 10 (Attended/Admitted)

2

61D Where the Removal Reason is 10 (Attended/Admitted) then an appointment must be recorded 3

61F Where the Non-attendance Category is 5 (Cancelled by Service) and the Non-attendance Outcome is 10 (Removed) then the Removal Reason must not be 10 (Attended/admitted)

2

61G Where the Removal Reason is 10 (Attended/admitted) then the Offer Outcome of the most recent Appointment Date must be 10 (Accepted)

3

63 Patient Type must be supplied 3

64 Invalid Patient Type Code used 3

87 Postcode must be supplied 1

88 Invalid Postcode used 1

96 Location must be supplied on record closure for Inpatients/Day Cases and Return Outpatients 2

96A Location must be supplied on record closure for New Outpatients 2

97 Invalid Location Code used 2

99 Specialty must be supplied 2

100 Invalid Specialty Code used 2

101 Consultant/HCP Code must be supplied and must be in the correct format 2

103 Patient Category must be supplied 2

104 Invalid Patient Category Code used 3

106 Missing or Invalid Provider Code 2

113 A Mandatory Unique Identifier must be supplied S2

114 An Action Type must be supplied and must be an Insert (I) Amendment (A) or Delete (D) S2

115 MUI already exists and cannot be provided as an Insert against the sending location S2

118A Appointment Record with this MUI has no corresponding master record S2

118B Unavailability Record with this MUI has no corresponding master record S2

118C Unavailability Review Record with this MUI has no corresponding master record S2

119 Multiple master records detected for MUI. Only one master record is permitted S2

121 Invalid UCPN format used 1

122 UCPN is invalid 1

123 Invalid RTT Clinic Outcome Code used 1

124 RTT Clinic Outcome Code must be supplied on record closure for New or Return Outpatients 1

125 RTT Clinic Outcome Date must be a valid date in the format yyyy-mm-dd S1


Version: 4.2

31 ISD Scotland

126 Invalid RTT Stop Reason Code used 1

127 RTT Stop Date must be a valid date in the format yyyy-mm-dd S1

128 Records must not be submitted where the Initial Start Date is before 01 April 2009 S2

129 Records must not be submitted where the Initial Start Date is before 01 April 2009 3


Version: 4.2

32 ISD Scotland

Appendix B: File Schema Data Item Description Position Field Format

Notes

Priority

File Record Type A single character that identifies that the

record is the parent detail record within the

file. The main detail record contains the core

details relating to a waiting list record (e.g.

referral date, patient details). Will always be

‘M’ for the Main record.

1:1 Char(1) M

Date of Referral to

Service

The date the patient was referred to the

service.

2:9 CCYYMMDD S

Date of Receipt of

Referral

The date the referral was received by the

hospital, from the GP.

10:17 CCYYMMDD S

Date Decision Taken to

Place on Waiting List

The date the hospital decided to put the

patient onto the waiting list.

18:25 CCYYMMDD S

Waiting Time Standard

Applied

A code denoting the waiting time

standard that was applied.

26:28 Varchar(3) S

Urgency Category A code denoting the urgency category. 29:30 Varchar(2) S

Availability for

Admission/Appointment

at Short Notice

A code denoting whether the patient is

available for admission/appointment at

short notice.

31:31 Char(1) O

Minimum Days Notice

Required for

Admission/Appointment

Date

The minimum number of days notice

required by a patient prior to the

appointment/admission date.

32:33 Numeric(2) O

Suitability of Patient to

be Considered Part of

Pooled List

A code denoting the suitability of the

patient to be considered part of the

pooled list.

34:34 Char(1) O

Patient Willing to

Change Clinician

A code denoting the patient’s willingness

to change clinician.

35:35 Char(1) O

Patient Willing to

Change Health Board

A code denoting the patient’s willingness

to change Health Boards.

36:36 Char(1) O

Date of Removal from

List

The date the patient was removed from

the waiting list.

37:44 CCYYMMDD S

Reason for Removal The reason that the patient was removed

from the list.

45:46 Varchar(2) S

Patient Status The current status of the patient. 47:48 Varchar(2) O

Patient Type A code identifying whether the patient is

an Inpatient, Day Case, New Outpatient,

Return Outpatient or Planned Repeat.

49:50 Varchar(2) S

Referrer Urgency

Category

A code denoting the urgency category

specified by the person that referred the

patient.

51:52 Varchar(2) S

Patient Family Name The patient’s family name (surname). 53:87 Varchar(35) O

Patient Given Name The patient’s given name

(forename/initial).

88:122 Varchar(35) O

Patient Date of Birth The patient’s date of birth. 123:130 CCYYMMDD O

Patient Sex A code denoting the patient’s current 131:131 Char(1) O


Version: 4.2

33 ISD Scotland

Data Item Description Position Field Format

Notes

Priority

gender.

Patient CHI Number The patient’s CHI number. 132:141 Varchar(10) S

Health Record

Identifier/CRN

Unique Health Record Identifier/Case

Reference Number for the treatment.

142:155 Varchar(14) S

Patient Postcode The postcode of the patient. 156:163 Varchar(8) S

Ethnic Group A code denoting the patient’s ethnic

group.

164:165 Varchar(2) S

GP Practice Code A code identifying the practice that the

patient is registered to.


Location A code identifying the location that the

patient was referred to for treatment


Specialty/Discipline A code denoting the specialty/discipline

that the patient is being treated under.


Consultant/HCP

Responsible for Care

The code for the Consultant/HCP

responsible for the patient’s care.


Patient Category A code identifying the patient category,

e.g. NHS.

188:188 Char(1) S

Provider Code The code the provider of treatment. 189:193 Varchar(5) S

Main Condition A code denoting the main condition that

the patient is being treated for.


Other Condition A code denoting any other condition that

the patient is being treated for.


Main Operation A code denoting the main operation that

the patient is on the waiting list for.


Referral Source A code denoting the source of the

referral.

214:214 Char(1) S

Action Type A type code that identifies whether the

record is an Insert (I), Amendment (A) or

a Deletion (D)

215:215 Char(1) M

Mandatory Unique

Identifier

A unique identifier for each record. This

is required to be unique within each

sending location and will be used within

the warehouse to recognise the records

to update.

216:226 Varchar(11) M

UCPN A code used to identify a patient’s

journey of care.

227:239 Varchar(13) S

RTT Clinic Outcome

Code

A code denoting the RTT Clinic

Outcome.


RTT Clinic Outcome

Date

The date the RTT Clinic Outcome Code

was recorded.

243:250 CCYYMMDD S

RTT Stop Date The date the RTT journey stopped. 251:258 CCYYMMDD S

RTT Stop Reason A coding denoting the reason the RTT

journey stopped.


Local Sub-specialty

Code

A code used locally denoting the sub-

specialty the patient is to be treated

under.

264:278 Varchar(15) S


Version: 4.2

34 ISD Scotland

Data Item Description Position Field Format

Notes

Priority

Local Sub-specialty

Description

A description of the code used locally

denoting the sub-specialty the patient is

to be treated under.

279:328 Varchar(50) S

Local Clinic Code A code used locally denoting the clinic

the patient is to be treated at.

329:343 Varchar(15) S

Local Service Code A code used locally denoting the service

the patient is to be treated under.

344:358 Varchar(15) S

Local Service Code

Description

A description of the code used locally

denoting the service the patient is to be

treated under.

359:408 Varchar(50) S

RTT True Wait Time

(days)

The number of days between the start

and end of the RTT patient journey.

409:412 Numeric(4) S

Infrequent Service Flag A code denoting whether or not a service

was infrequent.

413:413 Char(1) S

Waiting Times Validation Manual - ISD Scotland...Waiting Times Validation Version: 4.2 4 ISD...

Documents

Transcript of Waiting Times Validation Manual - ISD Scotland...Waiting Times Validation Version: 4.2 4 ISD...