COSD technical guidance v9.0.2

The purpose of this document is to provide instruction to informatics personnel within provider organisations and IT software suppliers (inhouse and commercial), regarding file creation and submission of the Cancer Outcomes and Services Data set (COSD) data. It should be read in conjunction with the documents listed within.

This document describes the standards for file submission, including the XML construction and file naming to facilitate uploading onto the National Cancer Registration and Analysis Service (NCRAS) database (ENCORE). In addition, it provides assurances that the proposed approach supports the implementation of DAPB1521 Amd 13/2019.

This is an update to an existing information standard DAPB1521, and is required to ensure that the data still meets the business objectives, scope and content of the standard and continues to be clinically accurate and relevant.

In order to maintain the clinical accuracy, it is important to regularly review COSD with clinical experts from across the NHS, including analysts at NHS Digital and NHS England.

Occasionally other information standards have specific data items which interact with COSD. Where this happens, liaison with the developers of those standards was concluded to ensure all data items remain accurate and are updated where necessary.

This document provides technical guidance to support providers of cancer services and IT software developers (inhouse and commercial), in the submission of the Cancer Outcomes and Services Data set (COSD) v9.0. It should be read in conjunction with:

• the information standards notice: reference DAPB1521Amd 13/2019
• the COSD Specification and supporting documentation
• the XML schema that can be downloaded from the TRUD website.
• the COSD user guide v9.1.3

Users may also wish to read the COSD Implementation Guide, which provides further support on implementation of the changes to the standard. See the downloads section of this page for access to these documents and other information.

Providers of cancer services are required to provide a monthly return on all cancer patients diagnosed from 1 January 2013 using this data set. The data are stored in the National Cancer Registration and Analysis Service (NCRAS) database (ENCORE). Submissions are made by each provider to the relevant NCRAS branch office for uploading to ENCORE.

Data may be extracted from a number of different electronic sources and submitted as separate files. The required format for submissions for COSD is XML. These and other details of the submission should be included in the COSD data transfer agreement, agreed between the provider organisation and their local NCRAS office.

Data is collated and mechanisms for transmission of data from providers to NCRAS offices have been extended to carry the COSD data items. On receipt, patient level data is validated and linked with existing records as appropriate.

Reporting mechanisms exist to provide consistent feedback on submissions and additional reports to local providers. These feedback reports can be accessed via the secure CancerStats2 platform. (Please note this opens in a new window). Both patient identifiable and anonymised data (where appropriate) will be made available for analysis and reporting purposes.

For technical queries relating to the creation of these files please contact your local NCRAS office in the first instance (see data transfer agreement for local details).

For queries regarding the:

• data set, contact [email protected]
• data model and dictionary service, contact [email protected]
• schema, contact [email protected]

Further help and tutorials on XML can be found online

To help support data submissions:

• providers MUST only submit data relating to patients for whom they have provided cancer services
• submitted files MUST be sent by secure file transfer methods as agreed with your regional NCRAS office
• files MUST reach the regional NCRAS office by the 25th working day following the end of month of the ‘trigger event’ for each diagnosed cancer (see user guide and Implementation guide for details of trigger events)
• each file may include records for more than one tumour group
• the data set is divided into sections each of which represents an activity or related group of activities along the care pathway
• individual records MUST contain the section ‘core linkage items’ including both patient identity and diagnostic details
• providers should aim to complete all the relevant data items as soon as possible, however as long as the mandatory fields (core linkage items) are completed the record can be submitted
• records in each submission MUST include all applicable sections where possible
• demographic section MUST be submitted by each provider on the first submission of a record
• for updated records, only the updated/amended sections and core linkage items need to be submitted

Notes:

• the data submission files MUST comply with the COSD XML schema specifications pack (note - all data must be submitted to the NCRAS in XML format only)
• where the ‘Diagnosis (ICD10 Pathological)’ code only has 3 characters, for example C01, please add “X” as a ‘packing digit’ to meet the validation rules (such as C01.X, C07.X, C73.X)
• the reporting format excludes the decimal CXX.X or DXX.X, all xml reports must be recorded as CXXX or DXXX

The required format for submission of data for the COSD will be extensible markup language (XML) as specified in the COSD XML schema specification pack. This contains all of the schema documents listed below and all embedded schema referenced in the above documents.

This schema pack also contains the data type schema, containing the formats for submitted data. The XML schema pack is available on request from the NHS Data Model and Dictionary Service. The XML schema can also be downloaded from the TRUD website.

XML schemas (XSD) have been designed for a generic core COSD data set and for 13 tumour site specific data sets, which each include the core data items. In addition:

• these schemas define the expected structure of the XML submissions
• schema design is segmented into separate schema, defining the different sections of COSD data specification
• these schemas are embedded in a hierarchical manner into a single schema
• these schemas contain information on the expected values for a data element

Data submitted in XML format will be required to conform to the schemas for the appropriate cancer site, or ‘Other’ only where tumour ICD10 code does not fall into a specific site.

Within the data set ‘core’ is a 4-letter word which describes:

• the subset of COSD data items (and their corresponding sections) that are common to all site groups
• if you are submitting a lung record and need to provide the core and lung specific data items, this is perhaps the more obvious definition
• 'CORE’ is no longer the non-specific site group that is used when a record does not belong to any of the other well-defined groups

In v9 the word CORE is not used within the schema, rather the site-specific group sections and records are now known as a, 'BreastRecord', 'CNSRecord', 'UpperGIRecord', 'UrologyRecord' etc., this is a change from v8.

For all other disease types (which do not have their own specific subsection in v9), will be recorded under ‘OtherRecord’. This simplifies data recording when compared to v8.

The top-level schema in the hierarchical structure is COSD-v9-0.xsd.

For a Record which does not fall into any of the tumour groups, such as a Record with only core elements, then the default schema path for a Record is used which is defined in the master file - COSD-v9-0.xsd.

This will only allow a record to build using what is deemed as Core sections as per the data set specification. The following list outlines the tumour specific site and associated schema, embedded within the above schema:

Character set: UTF-8: information on permitted formats are contained in the data type schema 

The root element of a COSD XML file is and only one is permitted and required per submission – such as in each individual xml file. There are 6 child elements that need to be provided within the root element, these are:

The <{*}Record> element is a child element of the <COSD> element. This element is a choice of single tumour record within the submission, for example 'BreastRecord', 'CNSRecord' etc. As with the <COSD> element it has an <Id root> element with a UUID value attribute. This is a unique identifier for the tumour record and does not need to be preserved across submissions – such as {*}Records pertaining to the same tumour in future submissions do not need to have the same UUID.

The choice of {*}Record determines what elements can be submitted for that type of record, for example 'PrognosticIndex' for 'BreastRecords', 'Pretreatment Assessments' for Head and Neck.

The choice of record element determines what can be submitted for that particular record. It will allow all core elements and any site specific elements where specified by the data set.

In addition, each record will denote if the data relates to a primary or non primary cancer diagnosis. For example, a 'BreastRecord' (primary cancer record) is represented in COSD XML, like:

Whereas a non primary pathway record is represented in COSD XML like:

Note:

• site-specific data sets don’t just add additional data items to their content group (and sub sections), they also augment core group sections where necessary

For example, a 'CancerCarePlan' section may contain:

Whereas a haematological 'CancerCarePlan' section may also contain ‘Acute Lymphoblastic Leukaemia’ data:

Note:

• for clarity a sample of a single gynaecological record is included in Appendix 1

The hierarchical nature of the data set may lead providers to adopt an object orientated programming (OOP) approach to developing the COSD XML submission, but it is also possible to use a more procedural approach to generate the XML and to use condition logic to include or exclude specific data items.

This may be simpler to produce, but might be harder to maintain in the longer term and whilst OOP may be the more elegant solution, providers may need a pragmatic approach with constrained resources, existing skills/technologies, etc.

A working example of the OOP paradigm is given below. The code is far from complete but demonstrates the key principle of inheritance. The use of CoffeeScript is merely for convenience – to all intents and purposes consider it pseudo code:

XML has reserved characters which should not be used in data submissions, these are:

Notes:

• if it is unavoidable that these reserved characters are used in data submission, they should either be replaced by the corresponding entity reference or encapsulated with the <![CDATA[ {data text} ]]> tag
• particular care should be taken with the imaging report text fields within COSD v9.0

File naming convention

The submission file must be named using the following convention: XML file:

COSD_<FILE SOURCE>_<Submitting Org>_<Reporting Period Start
Date>_<Reporting Period End Date>_<Date of file creation>.xml

Where:

<COSD> is a fixed value
<FILE SOURCE> is MDT or PAS or PATH or RIS (or other source description as agreed with NCRAS)
<Submitting Org> is the Organisation Code (e.g. AB3) for the submitting organisation
<Reporting Period Start Date> must always be in the format CCYY-MM-DD
<Reporting Period End Date> must always be in the format CCYY-MM-DD
<Date and time of file creation> Timestamp when the file was created in the format CCYY-MM-DDThh:mm:s

Example

The file name for organisation (X09) submitting its own pathology data for activity month July 2020 on the 5th September 2020 at 10:30:22 AM will be:

COSD_MDT_X09_2020-07-01_2020-07-31 2020-09-05T10_30 22.xml

Files may be zipped prior to transmission, in this case the file extension .zip will be acceptable.

Note:

• each file submitted must have a unique filename as generated by the above method

XML data should be validated against the schema prior to submission.

XML data submissions should be given a new UUID in the <COSD> element, where submissions are altered and re-submitted a new UUID should be applied. Each tumour record in the submission should have a unique UUID as the root attribute for the <COSDRecord> element. New UUID must be created for resubmissions of data.

All data submissions must be transmitted between either nhs.net email accounts (or alternative email accounts that are accepted as part of the nhs.net framework), or via the new API portal. Details of using the API portal can be found in the main COSD User Guide. The regional NDRS offices will provide providers with the relevant recipient account.

Monthly data submissions are required from each provider within 25 working days of the relevant month end. A schedule of submission deadlines is available in the schedule section on main COSD page of this website.

Trusts should complete the COSD submission template which should be attached to each email submission, along with the data submission files themselves. This provides a summary overview of their submission and alerts the NCRAS to any special or extenuating circumstances which may have affected the submission that month. See Appendix 2.

Who will submit the data?

Trusts were mandated to collect and submit COSD data in XML from January 2016, with an agreed delayed start until July 2016 for September 2016 submissions.

1. Files should be submitted by NHS providers of any adult or children cancer services.
2. The submission files should relate to a single provider and only for data that they own.
3. Providers must clarify arrangements or changes for submitting the data with their local NCRAS office.

Note: a separate user guide, technical guide and schema pack has been created for the pathology data set.

What data items should be submitted?

All applicable data items specified as either mandatory or required in the data set and XML schema documentation should be submitted as soon as available.

The mandatory, required or optional (M/R/O) column indicates the recommendation for the inclusion of data. This applies specifically to the XML files but should also be used to decide on data to be included through other message formats.

M = Mandatory

This data item is mandatory; the record or part of the record cannot be submitted if the mandatory data items are not completed. The file will be rejected if the mandatory linkage items are absent and/or sections will be omitted where mandatory items are missing, even if other data items are completed.

R = Required

This data item is required as part of NHS business rules and must be included where available or applicable, however, the section can be submitted without completing all the required items.

O = Optional

This data item can be included at the discretion of the submitting organisation and their commissioners as required for local purposes.

Validation

The data will be validated in ENCORE according to a set of rules. If the data validation rules are not met, the whole or relevant parts (data set sections or records) of the extract may be rejected and returned to the provider.

The provider will normally be expected to resolve any errors/issues or add missing data and re-extract the file for sending to the NCRAS within 5 working days, for re-validation. The turnaround time for validation, any re-submission and subsequent re-validation is necessarily short as delays will adversely affect the timeliness and quality of the data and the validity of conformance reporting.

A record of rejected files will be kept by the NCRAS as an audit trail and to support conformance monitoring; original files may be retained in order to make a comparison with subsequent files received.

It is good practice to identify the areas which require attention prior to submission in the form of check reports, outlining if there are key (Mandatory) fields missing. This can be in the form of an error report or other explanation, allowing correction to prevent the records from being rejected. Equally a warning message could be created and displayed on the screen, where there is an attempt to save a record on a system without the mandatory data items.

The NCRAS has developed standardised reports which are available to all providers submitting data through the NCRAS secure portal CancerStats2. (Please note this opens in a new window). This platform requires an N3/HSCN secure network connection. To ensure the best user experience, we encourage the use of modern web browsers such as Google Chrome, Mozilla Firefox or Microsoft Edge to access the platform. A small number of platform users have reported issues when opening reports using Internet Explorer.

The HSCN is a new data network for health and care organisations which replaced N3. It provides the underlying network arrangements to help integrate and transform health and social care services by enabling them to access and share information more reliably, flexibly and efficiently.

Analytical reports are being developed separately via the CancerData platform.

Providers should continue to contact their regional NCRAS office to request any data they require which is not made available via standardised reporting.

Note: generic file names as listed should align with the sources identified in the data transfer agreement. Any other file sources should be referenced using consistent terminology as agreed with the NCRAS.

Guidance published: 15 November 2019