Radiology Data Mart - Information Services Division · PHI Public Health and Intelligence, which includes Information Services Division (ISD). RIS Radiology Information System Sending

NSS Information Technology © National Services Scotland, 2016 Private and Confidential

Radiology Data Mart

File Extract Specification

Version 1.2

File Extract Specification 2 of 22 Version 1.2

DOCUMENT CONTROL SHEET

Version Date Issued Author Description

0.1 06/06/2018 Angela Forbes

Initial draft

Only limited validation has been specified. Any additional validation will be specified when the functional specification has been agreed.

0.2 20/07/2018 Angela Forbes Updated following meeting with Raj.


Document previously called Radiology Data Mart File Specification.

File processing schedule changed to hourly.

Accession number and insourced data items added.

0.4 17/10/2018 Angela Forbes Updated following Glasgow and Perth meetings.


Date format changed to YYYYMMDD.

Patient ID made non-mandatory.

National codes must be submitted for specialty therefore specialty description removed because now redundant.

Request and Booked Status data items changed to include code and description.

Validation updated to reflect the changes.

0.6 26/11/2018 Angela Forbes Version used for meeting with data management and analysts.

0.7 31/01/2019 Angela Forbes Validation modified.


Document name changed - previously Radiology National Dataset File Specification.

Planned Exam Date added back in with modified definition.

National reporting changed to National analysis.

0.9 28/02/2019 Angela Forbes Integrates feedback from Kat and Andrew.

0.10 04/03/2019 Angela Forbes Status of mandatory data items which are not being validated changed to should be provided.

1.0 14/03/2019 Angela Forbes Clinician added to Definitions and Acronyms section.

1.1 05/06/2019 Angela Forbes Added note to Accessing Validation Results section that a read only area will be created for NSS data management to access files that have failed validation.


Dependency between records submitted in the request and master file removed. The possible impact on the integrity of the data has been accepted.

Note removed that duplicate records will be flagged.

Approvals: Version Date Approved Name Designation

1.0 21/03/2019 Fiona Russell Head of Service (Data Management)

1.1 08/08/2019 Elaine McNish Information Manager

Business Contacts: Name Designation

Elaine McNish Information Manager

Kat Reid Data Manager

Elaine Parry Principal Information Analyst

James Hardy Information Analyst

Eddie Adie Principal Information Development Manager


NSS IT Contacts: Name Designation

Irene Gow Project Manager

Angela Forbes Analyst

Abhishek Deshmukh Technical Analyst

Neil Sinclair Technical Lead

Jill Smith Head of Business Intelligence


Contents

1 Introduction .............................................................................................. 5

1.1 Document Purpose .................................................................................... 5 1.2 Supporting Documentation......................................................................... 5 1.3 Definitions and Acronyms .......................................................................... 5

2 Overview ................................................................................................... 6

2.1 Diagnostic Pathway ................................................................................... 6 2.2 General Assumptions ................................................................................. 7

3 File Extracts .............................................................................................. 8

3.1 File Delivery ............................................................................................... 8

3.2 File Processing .......................................................................................... 8

3.3 File Processing Schedule........................................................................... 9 3.4 Validation ................................................................................................... 9

3.5 Accessing Validation Results ..................................................................... 9 3.6 Notifications ............................................................................................... 9

4 File Format .............................................................................................. 10

4.1 File Name................................................................................................. 10

4.2 Header Record ......................................................................................... 10 4.3 General File Extract Rules ....................................................................... 11

4.4 Data Element Rules ................................................................................. 11

5 Request File ............................................................................................ 12

5.1 Request Data Assumptions...................................................................... 12

5.2 Request File Content ............................................................................... 12

5.3 Request Unique Record ID ...................................................................... 14

6 Master File .............................................................................................. 15

6.1 Master Data Assumptions ........................................................................ 15 6.2 Master File Content .................................................................................. 16 6.3 Master Unique Record ID ........................................................................ 19

Appendix A Valid Sending Locations ........................................................... 20

Appendix B Validation ................................................................................... 21


1 Introduction

1.1 Document Purpose

The purpose of this document is to detail the file schema and processing rules for files submitted to a

new data mart for reporting on the full national radiology dataset. The signed off document will be used

in conjunction with other supporting documentation by the Business Intelligence (BI) team to develop

the data mart as specified.

1.2 Supporting Documentation Document Owner

NRIIP Radiology Dataset – Definitions and Recording Guidance PHI

1.3 Definitions and Acronyms Acronym/Term Description

BI Business Intelligence

CDW Corporate Data Warehouse – a central data store maintained by NSS IT. It is made up of a collection of data marts which share a common database (CDD) for reference information.

CHI Community Health Index number – a unique patient identifier issued to Scottish residents when they register with NHS Scotland.

CHI seeding A probability matching algorithm using patient information to derive a CHI number for the patient.

Clinician For data collection purposes clinician is not restricted to individuals who are clinically skilled but is used to identify anyone involved in delivering the patient’s diagnostic/interventional pathway.

Common Dimension

A dimension holds reference information, e.g. patient details, and will hold history where appropriate e.g. patient postcode changes. The dimensions are referred to as common because they can be used by multiple data marts if required to provide consistent reference information across datasets although it is possible that a dimension may only be used by one data mart.

CR Change request

Data mart A subset of a data warehouse, which has been designed to satisfy a particular function or reporting area within an organisation.

Insourcing Activity performed anywhere within the NHS by clinicians working outwith their standard contracted hours.

NICIP National Interim Clinical Imaging Procedure codes

Null No value will be available.

Outsourcing Activity performed by a third party non-NHS provider.

PHI Public Health and Intelligence, which includes Information Services Division (ISD).

RIS Radiology Information System

Sending Location The location responsible for submitting the data.

Unique Record ID Uniquely identifies a record. This may be determined from a combination of data items on a record.


2 Overview

A national radiology dataset has been agreed by the Clinical Imaging Network following consultation

with national radiology service representatives.

NHS Boards will submit the dataset to NSS IT in files in the format specified in this document. The data

will be processed and held in a Radiology data mart within the NSS Corporate Data Warehouse (CDW).

The CDW will be the central repository for this dataset and a key data source for the Radiology

dashboard, which will be used for management reporting and benchmarking.

2.1 Diagnostic Pathway

The following radiology diagnostic/interventional pathway can exist:

Order/Request > Justification > Vet> Booking > Exam/Procedure > Report/Verified > Addendum.

Stage Requirement Additional Information

Request Information on all requests for diagnostic/interventional exams/procedures recorded on the sending location’s RIS.

To include rejected requests.

To include requests for exam/procedures that did not need justification or an appointment booked, e.g. exams performed immediately.

Patient identifiers and demographic information.

A request will be created for all diagnostic/interventional exams/procedures required.

A request can be for one or more exams.

Justification To identify whether or not the exam/procedure requested was justified to go ahead and the date the decision was made.

Requests can go through multiple stages until they are justified and can proceed to booking.

Not all exams/procedures requested need to be justified.

Where the request does not require formal justification the earliest of the Appointment Date, Cancelled Date or Exam Start Date will be used as a proxy.

Vet Vetting specific information is not required. Vetting is not performed by all Boards.

Booking Latest booking information available for each exam/procedure requiring an appointment.

Justified requests will move to booking.

Appointments are not required for all exams.

History of booking changes is not held.

Exam Information on all diagnostic/interventional exams/procedures justified, booked or performed.

To include cancelled/aborted exams/procedures.

Screening information is not required.

Exam is the finest grain of data required.

Exams/procedures can be booked, cancelled, aborted or performed.

One or many exams can be performed at a single attendance.

Report

Verified

Information on verified reports.

Ability to identify where a report contains information from multiple exams.

Ability to identify where no report was required.

One or more exams can contribute to a single report.

Not all exams need to be reported on by the radiology service.

Some exam results will be double reported.

Addendum Addendum specific information is not required.

If the system holds multiple addendum dates the verified date submitted will reflect the latest date an update was made. This is required to ensure the information submitted is consistent irrespective of the source system.

An addendum is any update to the report after it has been verified.

Some systems update the verified date to reflect the latest date it was updated.


2.2 General Assumptions

The following general assumptions have been made

Assumption Additional Information

1 Only data from the RIS for interventional/diagnostic exams/procedures will be provided.

There will be no restrictions applied when loading data so if this restriction is not applied at source there may be inconsistencies in the data available from different sending locations for analysis.

2 Data will be submitted to NSS in the format specified in this document.

The file will be rejected if it does not conform to the format validated for.

3 Monthly extracts will be provided. The submission frequency will be reviewed. The data mart will be developed to accommodate more or less frequent submissions.

4 Extracts will include open and closed records that have been added or updated on the RIS since the previous submission.

5 All sending locations will be able to provide a system generated Unique Record ID for a request and an exam.

This is required to avoid duplicate records being processed and to allow records to be updated within the data mart.

6 IDs provided may only be unique for the sending location.

A combination of the ID and sending location identifier will be used within the data mart to ensure uniqueness across Scotland.

7 The same diagnostic/interventional pathway can be recorded on multiple RISs if the care is delivered by different Boards.

This may result in duplicated information being held in the data mart if the same information is submitted by different sending locations.

8 A minimum of two years historic data can be provided by all sending locations in the format specified in this document.

Data for a longer historic time period can be submitted for local trend analysis if required.

9 The data collected will not support operational service management, e.g. patient booking, waiting times.

10 PHI do not intend to use the data mart as the source of the data for the Diagnostic Monthly Management Information (DMMI) reports.

The data will not be suitable for monitoring national waiting times using the current waiting times calculation.

If the data are of a suitable quality it will be possible to monitor lag times between events, e.g. the time between an exam and report.

11 Local resource will be available to verify the proposed mapping of local values to national values required for national analysis and to respond to validation and data verification queries.

12 The dataset may need to be refined/expanded in the future.


3 File Extracts

The following file extracts will be submitted to the data mart by the NHS Boards

File Description

REQUEST

Contains details of requests for diagnostic/interventional exams/procedures recorded on the RIS including rejected requests.

Request ID will uniquely identify the request and must not be duplicated within the file.

Will include demographic information.

MASTER

The file is referred to as the Master file because it will include appointment, exam/procedure and report information for exams/procedures which have been justified, booked or performed including cancelled/aborted exams/procedures.

The file will contain multiple grains of data

Request: A request can be for more than one exam. The Request ID will be repeated on all records associated with the request and will be used to join the Request and Master files.

Exam: The finest grain. There will be one record per exam/procedure justified/booked/performed. The Master ID will uniquely identify the record and must not be duplicated within the file.

Attendance: Multiple exams can be performed at a single attendance. The Attendance ID will uniquely identify the attendance and will be repeated on all records associated with the attendance.

Report: Multiple exams can contribute to a single report. The Report ID will uniquely identify the report and will be repeated on all records associated with the report.

NOTE

1. The data are being submitted in two files because feedback has indicated that

o Exam/procedure level information only becomes available when the exam/procedure

requested is made available for booking (this will include exams/procedures which do not

require an appointment). This is the stage where it will be possible to create a unique

identifier for the exam/procedure, which is referred to as the Master ID for file purpose of

this dataset.

o Request information is not always at exam/procedure level and information is required

for all exams/procedures requested and not only those that are justified, which is why the

Request file is needed.

2. The demographic information is included in the Request file because feedback has indicated that

o Request level information will be populated for all exams/procedures requested including

those which do not require justification or an appointment.

o Request ID is carried through when exams/procedure requests are booked/progressed

so it will be possible to link the Request and Master files.

3. Files will include records which have been added or updated since the previous submission.

4. Historic data must be submitted in the format specified in this document.

3.1 File Delivery

Files will be submitted by the NHS Boards using Automated File Transfer.

3.2 File Processing

The files will be processed using an insert and update methodology.

The Request file will be processed before the Master file for a sending location.

The following logic will be applied

If a record is submitted and the Unique Record ID does not exist in the data table the record will

be inserted/added to the data table.

If a record is submitted and the Unique Record ID already exists in the data table it will overwrite

the record already held in full - it is not a selective update so the update record must contain all

of the relevant information.

It is important that the latest record submitted for a Unique Record ID contains all of the relevant

information.


Records can be submitted or resubmitted from any historic timeframe if required.

Records cannot be automatically deleted. If a record needs to be deleted a fast track CR will be raised

to have the record removed.

3.3 File Processing Schedule

The file processing will run hourly. This can be modified if required.

3.4 Validation

The validation is required to ensure that the file/data can be processed (see Appendices).

If the file fails any of the validation rules the file will be rejected. The error must be corrected by the

sending location and the file resubmitted.

Invalid data item formats or values will be null for analysis where they do not cause the file to be

rejected.

Dates will be presented as text and also as valid dates where possible.

3.5 Accessing Validation Results

Validation results will be accessed using Business Objects.

A read only area will be available for NSS data management to access files that have failed validation.

3.6 Notifications

The following emails will be generated.

Email Description Recipient

Passed/Failed To advise if the file received has passed or failed validation.

SENDING LOCATION EMAIL ADDRESSES TO BE PROVIDED

[email protected]

Loaded To advise when the data mart refresh has completed successfully and the new data are available for analysis.

SENDING LOCATION EMAIL ADDRESSES TO BE PROVIDED

[email protected]

Failed To advise that the data mart refresh has failed. BI team


4 File Format

4.1 File Name

The file will fail validation if the file name does not conform to the following format.

DATASET_EXTRACT TYPE_SENDING LOCATION_EXTRACT DATE.EXTENSION

e.g. RADIOLOGY_MASTER_N_20180224.csv

Where:

Item Description Example

Dataset Identifies the dataset the files are submitted for. RADIOLOGY

File Extract Type The type of file extract. MASTER

Sending Location A single digit code used to identify the sending location.

See Appendices for valid sending locations. N

Extract Date The date the file was compiled.

Date format YYYYMMDD 20180224

File Extension Identifies the file type. csv

NOTE

1. The file name is not case sensitive.

2. The 9-digit NHS Board codes will not be used to identify the sending location because files will

be submitted from two locations in Highland. The data from the two Highland locations will be

combined for the core analysis, but will need to be distinguishable for quality assurance

purposes.

4.2 Header Record

The first row in the file must contain a header record which contains details of the file. All data items in

the header record are mandatory and must be in the specified format. The information in the header

record should be consistent with the information supplied in the file name.

The file will fail validation if the header format does not conform to the following comma delimited

format.

DATASET,EXTRACT TYPE,SENDING LOCATION,EXTRACT DATE,SUBMISSION REFERENCE

NUMBER,RECORD COUNT

e.g. RADIOLOGY,MASTER,N,20180224,1,131

Where

Item Description Format Example

Dataset Identifies the dataset the files are submitted to. Varchar (9) RADIOLOGY

Extract Type The type of file extract. Varchar (7) MASTER

Sending Location

The single digit code used to identify the sending location.

See Appendices for valid sending locations.

Varchar (1) N

Extract Date The date the file was compiled. Date 20180224

Submission Reference Number

A unique number identifying the number of the submission for the sending location.

Integer 1

Record Count A count of the number of records in the file (excluding the header record and column names).

Integer 131

NOTE

1. The header record is not case sensitive.

2. The Submission Reference Number is required to allow multiple files for the same location to be

processed in the correct order, and to flag if there are any gaps in the received files. The

Submission Reference Number must increment per successful validation for each sending


location. Files which are invalid and rejected for any reason must be corrected and resubmitted

with the same Submission Reference Number as the original.

3. Trailing commas will be removed when the file is processed.

4.3 General File Extract Rules

The following rules will apply to the file extract.

Category Description

Columns

The columns are comma delimited to separate fields and must be in the order specified in

the file specification.

If a field is empty the column must still be included in the extract.

Column Names The file will contain column name headings. The headings are for local use only and will be ignored when the file is loaded. The name can only contain a comma when surrounded by double quotes.

Column Width The column width is the minimum width from a development perspective. A wider width than documented will be used in the development to ensure that the field is not truncated to a valid value.

Blank Rows Blank data rows must not be included in the data file.

Null/Missing Values Empty fields will indicate where a value is null (missing). Zero must not be used.

Spaces (non-printable values)

Spaces should not be present between fields. The comma alone should delimit fields.

4.4 Data Element Rules

The data will follow the general standards detailed in the table below.

Category Description

Number Type

Numeric data items will appear in the text file as a string of continuous numeric digits. For large numbers the ‘thousand’ display format characters such as the comma will not be included. Where the number contains decimals, the period character ‘.’ will be used as the decimal point.

Text/Character Type

Text will be converted to upper case for all data items where appropriate – the format of the Dose Unit will not be modified.

The value can only contain a comma when surrounded by double quotes.

Spaces should not be present between fields.

Leading and trailing spaces will be removed.

Multiple spaces will be removed to ensure there are only single spaces.

National values should be used where available.

Date Type Date type will be formatted as YYYYMMDD (e.g. 20181001).

Time Type Time type will be formatted as hh:mm using the 24 hour clock (e.g. 14:13).

If a 4 character time is submitted it will be left zero padded to 5 characters.

Leading Zeros

Leading zeros must not be stripped off values which have been identified as having

leading zeros.

If a 9 character CHI number is submitted it will be left zero padded to 10 characters.

If a 4 character time is submitted it will be left zero padded to 5 characters.

Data Item Priorities

The priority categories for data items are as follows:

M = Mandatory the data item must be populated

S = Should be populated if available

O = Optional


5 Request File

5.1 Request Data Assumptions

The following assumptions have been made about the data to be sourced from this file


1 Multiple requests can be made for the same patient.

Where this occurs the demographic information will be repeated on all of the relevant records for the patient.

2 Patient ID may not uniquely identify the patient across sending locations.

The same Patient ID could be associated with different patients within the data mart therefore the UPI associated with the submitted CHI Number will be the key patient identifier for national analysis.

3 All requests will be recorded on the RIS irrespective of the source (internal/external) or type of request (paper/electronic).

4 Requests can be received from another NHS Board, e.g. where there is not capacity in the home Board to perform the exam/procedure.

5 A request can be associated with multiple exams, i.e. the request is not at exam/procedure level.

Exam/procedure information associated with the request will be included in the Master file which will contain information on requests which are to be progressed. Therefore it will only be possible to assess the demand for specific exams/procedures/modalities when the request has been approved.

6 Request status can be used to determine if the request was justified or rejected.

7 Information recorded on the RIS when the request is received (‘pending’) may be cleared when the request is moved to booking on some systems.

This information must be included in submitted updates irrespective of where it has been extracted from on the source database.

5.2 Request File Content

The table below gives details of each data item in the order that it will appear in the file.

Data Item Description Format Priority

1 Request ID Unique identifier for the request (order).

Must be unique within the file.

Varchar (20)

M

2 Patient ID Code used locally to identify the patient. Varchar (15)

S

3 CHI Number Unique identifier for the patient within Scotland Varchar (10)

S

4 Patient Surname Patient’s surname. Varchar (35)

S

5 Patient Forename Patient’s forename. Varchar (35)

S

6 Patient Date of Birth Patient’s date of birth. Date S

7 Patient Postcode Patient's postcode of residence. Varchar (8)

S

8 Patient Gender Patient’s gender code.

Must be 1 (Male), 2 (Female), 0 (Not Known) or 9 (Not Specified).

Varchar (1)

S

9 Requesting Clinician ID Code used locally to identify the clinician who made the request.

For local analysis only.

Varchar (15)

S



10 Requesting Clinician Surname Surname of the clinician who made the request.


Varchar (35)

S

11 Requesting Clinician Forename Forename of the clinician who made the request.


Varchar (35)

S

12 Requesting Source Code Code used locally to identify the source of the request.

Local values will be mapped centrally for national analysis.

Varchar (10)

S

13 Requesting Source Description Description used locally to identify the source of the request.


Varchar (100)

S

14 Requesting NHS Board Code Code used locally to identify the NHS Board which generated the order/request/referral.


Varchar (10)

S

15 Requesting NHS Board Name Name used locally to identify the NHS Board which generated the order/request/referral.


Varchar (100)

S

16 Requesting Location Code Code used locally to identify the location which made the request.

Must be a hospital, Dental Practice, GP practice or domiciliary (D299N) location.


Varchar (10)

S

17 Requesting Location Name Name used locally to identify the location which made the request.

Must be a hospital, GP practice or domiciliary (D299N) location.


Varchar (100)

S

18 Requesting Clinician Specialty Code

Code used nationally to identify the speciality of the clinician who made the request.

Varchar (3)

S

19 Requesting Department Department which made the request [free text].


Varchar (100)

O

20 Request Received Date Date the request was received. Date M

21 Request Received Time Time the request was received. Time S

22 Patient Type Code Code used locally to identify the type of patient.


Varchar (10)

S

23 Patient Type Description Description used locally to identify the type of patient.


Varchar (100)

S

24 Clinical Indication Free text description of the clinical reason for the exam/procedure.


Varchar (200)

O

25 Request Status Code Code used locally to identify the request status.


Varchar (10)

S



26 Request Status Description Description used locally to identify the request status.


Varchar (100)

S

5.3 Request Unique Record ID

The following data items will be used to uniquely identify a record for file processing

Request ID

Sending Location


6 Master File

6.1 Master Data Assumptions

The following assumptions have been made about the data to be sourced from this file


1 Multiple exams can be performed at one attendance.

Where this occurs the Attendance ID will be repeated on all of the relevant master records.

2 Exam code/description will reflect the exam/procedure information available when the data are extracted and may change over time.

The history of any changes will not be maintained.

3 Urgency code/description will reflect the urgency recorded when the data are extracted and may change over time.

The history of any changes will not be maintained.

4 Not all exams/procedures will need to be justified by a clinician.

If the Appointment Date, Cancelled Date or Exam Date is populated it will be assumed that the request was justified.

5 Booked Status can be used to determine the attendance status.

Booked status will be mapped to attendance status.

6 Appointment information will not be populated on the RIS if the exam is completed immediately, e.g. walk-ins, theatres, one-stop clinics.

7 A history of changes to appointment bookings is not maintained on the RIS and the data will reflect the latest information available.

8 Only one period of unavailability can be recorded for an exam/procedure. If a patient advises of multiple periods of unavailability local protocol will be followed when selecting the period recorded.

9 Cancellations may not be recorded consistently. If an appointment is cancelled and rebooked the information will be updated. If an appointment is cancelled and no longer required a cancelled date will be populated.

This may result in the undercounting of cancellations if the appointment is rescheduled.

10 Exam Start Date and Exam End Date may not be recorded for all modalities.

11 Exam Start Time and Exam End Time may be for the attendance and not the exam/procedure. The information is unlikely to be accurate given that some RISs hold the time the information is entered which may not be at the exam/procedure start/end.

The data items have been retained in the dataset and it is recognised that they will be of little value until the RISs are modified to support more accurate recording.

12 A report can include information from more than one exam.

Where this occurs the report information will be repeated on all exam records associated with the report.

13 Multiple reports will not include information from the same exam.

14 Report Clinician ID, Date and Time populated for the initial reporting clinician may only be populated where double reporting has occurred.

15 Verified Clinician ID, Date and Time are the key reporting information for analysis. Verification and Addendums are combined on some systems, i.e. the Verification Date is the latest date the report was updated which includes the addition of addendums.

The Verified Date Time is used for lag analysis therefore the lag between the exam being performed and report verification may be inflated if the verified date is updated when an addendum is added.



16 Book Status cannot be used to determine if the exam did not require a report because on some RIS instances the No Report Required flag defaults to issued after 24 hours.

No Report Required (NRR) flag has been included in the dataset because the information cannot be determined from other data items submitted.

6.2 Master File Content

The table below gives details of each data item in the order that it will appear in the file.


1 Master ID Unique record identifier for the exam/procedure justified/booked/performed.

This may be the accession number if the number is used locally to identify an exam/procedure attendance or created from a combination of data items, e.g. accession number + study sequence number.

Must be unique within the file.

Varchar (20) M

2 Request ID Unique identifier for the request (order).

This will be repeated on all master records associated with the request and will be used to join the information submitted in the Master and Request files.

Varchar (20) M

3 Attendance ID Unique identifier for the attendance.

This may be the accession number if the number is used locally to identify an attendance and will be repeated on all master records associated with the attendance.

Varchar (20) S

4 Exam Code Code used locally to identify the exam/procedure justified/booked/performed.


Varchar (10) S

5 Exam Description Description used locally to identify the exam/procedure justified/booked/performed.


Varchar (200)

S

6 Modality Code Code used locally to identify the imaging modality.


Varchar (10) S

7 Modality Description Description used locally to identify the imaging modality.


Varchar (100)

S

8 Urgency Code Code used locally to identify the clinical urgency allocated by the radiologist.


Varchar (10) S

9 Urgency Description Description used locally to identify the clinical urgency allocated by the radiologist.


Varchar (100)

S

10 Special Pathway Type Code Code used locally to identify the pathway the patient was on.


Varchar (10) S

11 Special Pathway Type Description Description used locally to identify the pathway the patient was on.


Varchar (100)

S



12 Justification Date Date the decision was made to justify the exam/procedure requested.

Date S

13 Justification Time Time the decision was made to justify the exam/procedure requested.

Time S

14 Justification Clinician ID Code used locally to identify the clinician who justified the request.

For local use only.

Varchar (15) S

15 Justification NHS Board Code Code used locally to identify the NHS Board which justified the request.


Varchar (10) S

16 Justification NHS Board Name Name used locally to identify the NHS Board which justified the request.


Varchar (100)

S

17 Justification Outsourced Flag Indicates if the justification was outsourced. Varchar (1) S

18 Justification Insourced Flag Indicates if the justification was insourced. Varchar (1) S

19 Booking Date Date the appointment was booked.

This is not the date the exam/procedure was scheduled to take place.

Date S

20 Booking Time Time the appointment was booked.

This is not the time the exam/procedure was scheduled to take place.

Time S

21 Appointment Date Date of the appointment for the exam/procedure.

May also be known as Booked Date.

This may be null if the exam/procedure was cancelled.

Date S

22 Appointment Time Time of the appointment for the exam/procedure.

May also be known as Booked Time.

This may be null if the exam/procedure was cancelled.

Time S

23 Unavailability Start Date Start date of the period of unavailability which affects the diagnostic/interventional pathway.

Date S

24 Unavailability End Date End date of the period of unavailability which affects the diagnostic/interventional pathway.

Date S

25 Unavailability Reason Code Code used locally to identify the unavailability reason.


Varchar (10) S

26 Unavailability Reason Description Description used locally to identify the unavailability reason.


Varchar (100)

S

27 Cancellation Date Data the booked exam/procedure was cancelled.

Date S

28 Cancellation Time Time the booked exam/procedure was cancelled.

Time S

29 Book Status Code Code used locally to identify the booking status.

Local values will be mapped centrally for the national analysis of attendance status.

Varchar (10) S



30 Book Status Description Description used locally to identify the booking status.

Local values will be mapped centrally for the national analysis of attendance status.

Varchar (100)

S

31 Planned Exam Flag Indicates if the exam/procedure had been planned as part of an ongoing course of care.


Varchar (1) O

32 Planned Exam Date Date of the next exam planned in the ongoing course of care.

Date O

33 Room ID Unique identifier of the room/equipment where the exam/procedure was performed.


Varchar (20) S

34 Operator 1 Clinician ID Code used locally to identify the clinician who performed the exam/procedure.

For local use only.

Varchar (15) S

35 Operator 2 Clinician ID Code used locally to identify the clinician who supported with the exam/procedure.

For local use only.

Varchar (15) O

36 Exam Start Date Date the exam/procedure started. Date S

37 Exam Start Time Time the exam/procedure started. Time S

38 Exam End Date Date the exam/procedure ended. Date S

39 Exam End Time Time the exam/procedure ended. Time S

40 Dose Amount Dose amount.


Number S

41 Dose Unit Dose unit.


Must not be converted to uppercase.

Varchar (10) S

42 Exam NHS Board Code Code used locally to identify the NHS Board where the exam/procedure was performed.


Varchar (10) S

43 Exam NHS Board Name Name used locally to identify the NHS Board where the exam/procedure was performed.


Varchar (100)

S

44 Exam Location Code Code used locally to identify the location where the exam/procedure was performed.



Varchar (10) S

45 Exam Location Name Name used locally to identify the location where the exam/procedure was performed.



Varchar (100)

S

46 Exam Outsourced Flag Indicates if the exam/procedure was outsourced.

Varchar (1) S

47 Exam Insourced Flag Indicates if the exam/procedure was insourced.

Varchar (1) S

48 No Report Required Flag Indicates that the exam does not need to be reported on.

Varchar (1) S



49 Report ID Unique identifier for the report. Varchar (20) S

50 Report Clinician ID Code used locally to identify the clinician who completed the report.


Varchar (15) S

51 Report Date Date the report was completed.

May only be populated if double reported.

Date S

52 Report Time Time the report was completed.

May only be populated if double reported.

Time S

53 Report NHS Board Code Code used locally to identify the NHS Board which completed the report.


Varchar (10) S

54 Report NHS Board Name Name used locally to identify the NHS Board which completed the report.


Varchar (100)

S

55 Report Outsourced Flag Indicates if the report was outsourced. Varchar (1) S

56 Report Insourced Flag Indicates if the report was insourced. Varchar (1) S

57 Verified Clinician ID Code used locally to identify the clinician who was the last to verify/update the report.


Varchar (15) S

58 Verified Date Latest date the report was verified or subsequently updated.

Date S

59 Verified Time Latest time the report was verified or subsequently updated.

Time S

60 Verified NHS Board Code Code used locally to identify the NHS Board which verified the report.


Varchar (10) S

61 Verified NHS Board Name Name used locally to identify the NHS Board which verified the report.


Varchar (100)

S

62 Verified Outsourced Flag Indicates if the verification was outsourced. Varchar (1) S

63 Verified Insourced Flag Indicates if the verification was insourced. Varchar (1) S

NOTE

1. Justification information has been included in the master (and not request) file because the

justification is associated with the exam and not request, which could include multiple exams.

2. Special Pathway, Insourcing and Outsourcing data items have been included pending

exploration of how these can be delivered. This information may only be of value for local

analysis initially.

6.3 Master Unique Record ID

The following data items will be used to uniquely identify a record for file processing

Master ID

Sending Location


Appendix A Valid Sending Locations

Sending Location Name Sending Location Code

NHS AYRSHIRE & ARRAN A

NHS BORDERS B

NHS DUMFRIES & GALLOWAY Y

NHS FIFE F

NHS FORTH VALLEY V

NHS GRAMPIAN N

NHS GREATER GLASGOW & CLYDE G

NHS HIGHLAND H

NHS HIGHLAND – ARGYLL & BUTE C

NHS LANARKSHIRE L

NHS LOTHIAN S

NHS TAYSIDE T

NHS WESTERN ISLES W

GOLDEN JUBILEE K

NOTE

1. Grampian will submit data for Orkney and Shetland. The data submission will be combined for

the three Boards.

2. Highland data will be submitted from two locations within the NHS Board.


Appendix B Validation

The following validation will be applied to the file

The File Extract Type ALL refers to the Request and Master files.

File Type Error Code

Error Type

Error Severity

Error Message Additional Information

ALL FE1 File Name

Error Invalid File Name: Dataset is missing or not recognised

Must be RADIOLOGY

ALL FE2 File Name

Error Invalid File Name: File extract type is missing or not recognised

Must be REQUEST or MASTER

ALL FE3 File Name

Error Invalid File Name: Sending location is missing or not recognised

Must be one of A, B, Y, F, V, N, G, H, C, L, S, T, W, K

ALL FE4 File Name

Error Invalid File Name: Extract date is missing or invalid. Should be a date in the format YYYYMMDD

ALL HE1 Header Error Invalid Header Record: Header could not be read – check format

Trailing commas will be removed

ALL HE2 Header Error Invalid Header Record: Dataset is missing, not recognised or does not match the file name

ALL HE3 Header Error Invalid Header Record: File extract type is missing, not recognised or does not match the file name

ALL HE4 Header Error Invalid Header Record: Sending location is missing, not recognised or does not match the file name

ALL HE5 Header Error Invalid Header Record: Extract date is missing, invalid or does not match the file name. Should be a date in the format YYYYMMDD.

ALL HE6 Header Error Invalid Header Record: The submission reference number supplied is out of sequence for the supplied sending location

ALL HE7 Header Error Invalid Header Record: The number of records is inconsistent with the number of records submitted

ALL SE1 Schema Error Data record could not be read – check file format

REQUEST SE2 Schema Error Request ID must be provided and must be unique within the file

MASTER SE3 Schema Error Master ID must be provided and must be unique within the file

MASTER SE4 Schema Error Request ID must be provided and must exist in the data mart

Request IDs submitted in the Master file do not have to exist in the Request file if they are already in the data mart.

REQUEST VE1 Data Error Request Received Date must be provided and must be a valid date in the format YYYYMMDD

NOTE

1. Invalid data item formats or values will be null for analysis where they do not cause the file to be

rejected.

2. All dates will be presented as text and also as valid dates where possible.


Documents

Radiology Data Mart - Information Services Division · PHI Public Health and Intelligence, which includes Information Services Division (ISD). RIS Radiology Information System Sending