COSD technical guidance v10.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 Disease Registration Service (NDRS) API. In addition, it provides assurances that the proposed approach supports the implementation of DAPB521 Amd 89/2022.

This is an update to an existing information standard DAPB1521 Amd13/2019. This 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.

To maintain the clinical accuracy, it is important to regularly review COSD with clinical experts from across the NHS. Occasionally other information standards have specific data items which interact with COSD. Where this happens, the Head of Cancer Datasets has liaised with the developers of those standards, to ensure all data items remain accurate and are updated.

Finally, extensive reviews have been held with both the NHS Data Model and Dictionary Service and the Data Design Authority, as well as experts within the classification and terminology teams within NHS England. These reviews have ensured that all data items now meet the national standards and expectations for effective data set design within the NHS.

The following is the amendment history for this document.

Over time documents may change, it is important that you are always referencing the correct version.

This document provides support in the submission of COSD v10.0.1 and should be read in conjunction with:

• the information standards notice, specification and implementation guide: reference DAPB5121 Amd 89/2022
• the COSD supporting documentation
• the XML schema that can be downloaded from the TRUD website.
• the COSD user guide v10.0.1

Please note that over time versions may change, therefore, it is recommended to check that you are always referencing the latest issues of any document.  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 01 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 via the NDRS API portal for uploading to ENCORE.

The required format for submissions for COSD is Extensible Markup Language (XML). Upon receipt, patient level data is validated and linked with existing records as appropriate.

For technical queries relating to the creation of these files please contact your local NDRS office in the first instance.

For queries regarding the:

• data set and schema, contact COSDenquiries

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

Further help and tutorials on XML can be found online

To help and support you with your data submissions, the following list of key submission principles has been created:

1. Providers MUST only submit data relating to patients for whom they have provided cancer services.
2. All COSD files MUST be submitted via the API portal.
3. Files MUST reach the regional NDRS 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).
4. Each file may include records for more than one tumour group.
5. The data set is divided into sections, each of which represents an activity or related group of activities along the care pathway.
6. Individual records MUST contain the section ‘core linkage items’ including both patient identity and diagnostic details.
7. 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.
8. Records in each submission MUST include all applicable sections.
9. Demographic section MUST be submitted by each provider on the first submission of a record.

Notes:

• the data submission files MUST comply with the COSD XML schema specifications pack (note - all data must be submitted 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 contains the following folders:

• change log
• sample xml
• schema
• schema browser
  • including an interactive web browser index, containing an overview, categories, and data types

The data type schema contains the formats for submitted data. 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. 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 and 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

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.

For all other disease types (which do not have their own specific subsection), will be recorded under ‘OtherRecord’, this will include Head & Neck cancers from v10 onward. This simplifies data recording.

The top-level schema in the hierarchical structure is COSD-v10-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-v10-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.

It is recommended that developers use the schema packs for their main development, as the schema examples (that can be downloaded from TRUD) are viewed in explorer, and are easy to follow. These display schema example using colours to highlight elements that help easily understand the construction of the XML data type, name, and submittable data.

The examples in this technical guide are exactly that, examples, designed to help and guide you through the creation of data into xml reportable formats and reports.

The use of the user guides also provides added context and extended information about each data item and would also be a user tool for developers.

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

<Id root=”uuid” />

• the root attribute will be a universal unique identifier (UUID) for the submission, this takes the form of an 8-4-4-4-12 hexadecimal characters, for example DEAEDCC2-76AA-411E-B994-8FDD98C3FFFA
• a UUID Library should be used to create it

<OrganisationIdentifierCodeOfSubmittingOrganisation extension="orgcode"/>

•  the extension attribute should contain the Organisation Data Service (ODS) code of the submitting Provider

<RecordCount value="count" />

•  the value attribute should identify the number of <COSDRecord> elements being supplied with this submission

<ReportingPeriodStartDate> and <ReportingPeriodEndDate>

• these elements give the time period for the data submission, this is normally the “trigger event” date range and takes the (ISO) format YYYY-MM-DD 

<FileCreationDateTime>

• this is the timestamp of when the submission was generated and takes the format YYYY-MM-DDTHH:MM:SS, for example 1900-01-01T10:11:12

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 'TrippleDiagnosticAssessment' for a 'BreastRecords', 'LungHealthCheckIndication' for a LungRecord.

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:

<BreastRecord>
    <Id root>
    <LinkagePatientID>
        <!-- LinkagePatientID Elements -->
    </LinkagePatientID>
    <PrimaryPathway>
         <LinkageDiagnosticDetails-->
             <!-- LinkageDiagnosticDetails Elements -->
         </LinkageDiagnosticDetails>
         <!-- Additional PrimaryPathway Elements -->
     </PrimaryPathway>
     <AdditionalPathwayDetails>
         <!-- AdditionalPathway Elements -->
     </AdditionalPathwayDetails>
<BreastRecord>

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

<BreastRecord>
    <Id root>
    <LinkagePatientID>
        <!-- LinkagePatientID Elements -->
    </LinkagePatientID>
    <NonPrimaryPathway>
        <!-- DateOfNonPrimaryCancerDiagnosisClinicallyAgreed -->
        <!-- Additional NonPrimaryPathway Elements -->
    </NonPrimaryPathway>
    <AdditionalPathwayDetails>
        <!-- AdditionalPathway Elements -->
    </AdditionalPathwayDetails>
<BreastRecord>

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:

<CancerCarePlan>
     <PlannedCancerTreatmentType code="..."/>
     ...
     <NoCancerTreatmentReason code="..."/>
     <AdultComorbidityEvaluation code="..."/>
</CancerCarePlan>

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

<CancerCarePlan>
     <PlannedCancerTreatmentType code="..."/>
     ...
     <NoCancerTreatmentReason code="..."/>
     <AdultComorbidityEvaluation code="..."/>
     <CancerCareALL>
         <AcuteLymphoblasticLeukaemia code="..."/>
     </CancerCareALL>
</CancerCarePlan>

Note:

• a full sample of a lung record is included in Appendix 1 - Creating a new COSD record

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:

class CoreGenerator 
    constructor: () ->
 
    buildOtherRecord: (tumour) -> 
    @buildCore(tumour)

    # Core section
    buildCore: (tumour) ->
        @buildLinkagePatientId(tumour.patient)
        @buildLinkageDiagnosis(tumour)
        # ...
        @buildCancerCarePlan(tumour.cancercareplan)
 
    buildLinkagePatientId: (patient) -> 
        alert "build LinkagePatientId"
 
    buildLinkageDiagnosis: (tumour) -> 
        alert "build LinkageDiagnosis"

    # ...
 
    buildCancerCarePlan: (cancercareplan) -> 
        alert "build CancerCarePlan"

class ColorectalGenerator extends CoreGenerator
     # Core section
    buildCoreDiagnosis: (diagnosis) ->
    super diagnosis
    alert "build ColorectalCoreDiagnosis/ColorectalDiagnosis"
    # TODO: add SynchronousTumourIndicator Code(ColorectalCancerAtDiagnosis) 
here
 
generator = new ColorectalGenerator 
generator.buildColorectalRecord(...)

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 field within COSD v10.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 MDT data for activity month July 2023 on the 05 September 2023 at 10:30:22 AM will be:

• COSD_MDT_X09_2023-07-01_2023-07-31 2023-09-05T10_30 22.xml

Note:

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

Cardinality

It is important to remember that each section and data item within the data set is controlled by its own published cardinality rule. This will help you understand the relationship each section or data item has within the overall file. There is a range of cardinality within the data set, these are at both the section and data item level.

Section level cardinality:

• (1..*)   this indicates that the section is mandatory and ‘must be at least one occurrence per submission’

• (1..1)   this indicates that the section is mandatory and ‘must be one occurrence per record’

• (1..2)   this indicates that the section is mandatory and there ‘must be at least one of the following choices per record’

• (0..*)   this indicates that the section is required and ‘may be multiple occurrences per submission’

• (0..1)   this indicates that the section is required and ‘may be up to one occurrence per record’

Data item level cardinality:

• (1..1)   this indicates that the data item is mandatory and must be submitted

• (1..*)   this indicates that the data is mandatory and that multiple selections are allowed to be reported

• (0..1)   this indicates that the data item is required/optional

• (0..*)   this indicates that the data is required/optional, but that multiple selections are allowed to be reported

Notes:

• if a data item is ‘Mandatory’ it MUST be submitted

• if a data item is ‘Required’, then you only submit that data if it is available and applicable to the patient, diagnosis, and/or treatment pathway

• throughout the data set there are ‘choices’, these will help select only the data required or that is applicable to the patient and improve data quality

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 uploaded via the NDRS 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.

Who will submit the data?

Trusts were mandated to collect and submit COSD and COSD Pathology data in XML from January 2016, ensuring that:

• files should be submitted by NHS providers of any adult or children cancer services
• the submission files should relate to a single provider and only for data that they own
• 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/P) 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

These data items are 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

These data items are 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

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

P = Pilot

These data items are only required by the Trusts who have agreed to be part of the pilot phase or where the data item is a pilot within COSD, but covers a specific area, for example Neuroendocrine tumours.

Validations

The data will be validated within the API 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 NDRS has developed standardised reports and feedback, which are available to all providers submitting data through the NDRS secure CancerStats2 platform. (Link opens in a new window). Both patient identifiable and anonymised data (where appropriate) will be made available for analysis and reporting purposes, although all is strictly controlled through strong information governance rules and processes.

These are only available through the NHS Health and Social Care Network (HSCN).  The HSCN is a 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 NDRS office to request any data they require which is not made available via standardised reporting.

The National Disease Registration Service (NDRS) cannot design or influence the overall design of a cancer information system; however, we can help with the way data is extracted and reported. This document has been developed to help you understand xml reporting, the way sections are created and how child and parent groups are formed and interact with each other throughout the data set.

To create a new COSD record, system suppliers or IT departments must use the published documents to help and support them through this process as follows:

• COSD v10.0.1 data set
• COSD user guide
• COSD schema pack
• COSD technical guidance
• COSD specification document
• COSD implementation guide document

To support new developers, the following additional guidance has been created, with examples of data looking at a primary cancer diagnosis on a Lung cancer pathway.

The examples of the xml are by section, but these should be used as examples only. It is important that you set-up an account with NHS Digitals Technology Reference Update Distribution (TRUD) by using this link, then download the latest COSD schemas.

There are very clear examples in the schema packs, which may be easier to follow and provide more detailed examples at a more granular level. These include both primary and non primary cancer pathways and all site specific tumour group examples as well.

This document is segmented and follows the general layout of the data set spreadsheet and user guide. For full xml examples and structures, please refer to the examples in the schema packs.

Notes:

• the regional Data Liaison Managers can support system suppliers and Trusts, including any testing required for new reporting of data
• help and support with testing your beta versions is also available from the NDRS teams upon request
  • this is especially important when a new system is implemented, or an upgrade rolled out by a system supplier or Trust IT team

All submission files must contain an XML header. 

<COSD:COSD xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xmlns:COSD="http://www.datadictionary.nhs.uk/messages/COSD-v10-0-1">
<COSD>
    <Id root="e74a5Ec1-3271-9BDB-1A8C-CC6D1BA7b80A"/>
    <OrganisationIdentifierCodeOfSubmittingOrganisation extension="ER2"/>
    <RecordCount value="5277790"/>
    <ReportingPeriodStartDate>2023-06-25</ReportingPeriodStartDate>
    <ReportingPeriodEndDate>2023-06-25</ReportingPeriodEndDate>
    <FileCreationDateTime>2023-06-25T08:44:38</FileCreationDateTime>

Every individual record must have an XML header – record identifier (1..1)

<LungRecord>
    <Id root="CEaeA583-e71B-b77d-E0Ae-783C998A68db"/>

These items are mandatory for every record to link patient records. To ensure that records submitted can be linked appropriately, some key data fields must be completed for each record submitted. These are shown in the Core Linkage section.

There will be one linkage section completed each time the record is submitted.

<LinkagePatientId>
    <NhsNumber extension="8649681476"/>
    <LocalPatientIdentifier>Qy8rwQITRSUdJPiIl0ZM</LocalPatientIdentifier>
    <NhsNumberStatusIndicatorCode code="04"/>
    <PersonBirthDate>2023-06-25</PersonBirthDate>
    <OrganisationIdentifierCodeOfProvider extension="HFUKZ"/>
</LinkagePatientId>

Notes:

• there is a choice for the linkage identifier, where you can use a combination of either ‘NHS Number’ and/or ‘Local Patient Identifier’
• these are mandatory for the schema
• both can be submitted, but a record cannot be submitted without at least one of these data items, preferably the NHS Number where available

One of the two cancer pathway sections must be provided within this section/choice, per submission. In this example, the ‘Pathway Choice (Primary Pathway)’ choice 1 has been used.

<LinkageDiagnosticDetails>
    <PrimaryDiagnosisIcd code="15BKwC"/>
    <TumourLaterality code="B"/>
    <DateOfPrimaryDiagnosisClinicallyAgreed>2023-06-25</DateOfPrimaryDiagnosisClinicallyAgreed>
</LinkageDiagnosticDetails>

Notes:

• the non primary cancer pathway (if chosen) then has a choice to distinguish between a recurrence, progression, or transformation pathway
• examples of these are available in the schema pack

Demographic details are required for every record to ensure that the correct patient can be identified, and information can be correctly linked.

The Demographics section should be completed by every Provider the first time a record is submitted.

There will only be one Demographics section completed for each record. Demographic linkage items will be required each time the record is submitted.

<Demographics>
    <PersonFamilyName>JkuvgnJnwFwHjv9x0dqjYW6PUoSm</PersonFamilyName>
    <PersonGivenName>gv85aadv1VuczQZlwNO8EufEx8</PersonGivenName>
    <Address>
        <StructuredAddress>
            <StreetAddressLine>JwrEcBW3QPY7j1uKfDyr6njeSg</StreetAddressLine>
        </StructuredAddress>
    </Address>
    <PostcodeOfUsualAddressAtDiagnosis>YZod01ub</PostcodeOfUsualAddressAtDiagnosis>
    <PersonStatedGenderCode code="2"/>
    <PersonSexualOrientationCodeAtDiagnosis code="4"/>
    <GeneralMedicalPractitionerSpecified extension="Cvgp2Dd5"/>
    <GeneralMedicalPracticePatientRegistration extension="RSA578"/>
    <PersonFamilyNameAtBirth>C5n48kzrpyAwmZbIx</PersonFamilyNameAtBirth>
    <EthnicCategory code="P"/>
</Demographics>

Notes:

• address can be either an175 or 5 lines each an35
• ‘Ethnic Category 2021’ will become a data item soon and COSD and its schemas have been equipped to submit these new data when available

This section includes details from referral up to the first appointment (for the primary diagnosis) and is therefore to be recorded once for each new primary cancer diagnosis. This is essential to support analysis for outcomes and work on presentation and routes to diagnosis.

There will only be one 'Referral' section completed for each record. These details include information relating to the first stage of the 'Patient Pathway'.

<ReferralAndFirstStageOfPatientPathway>
    <SourceOfReferralForOut-patients code="16"/>
    <DateFirstSeen>2023-06-25</DateFirstSeen>
    <ConsultantFirstSeen>
        <ProfessionalRegistrationIssuerCode-ConsultantFirstSeen code="09"/>
        <ProfessionalRegistrationEntryIdentifier-ConsultantFirstSeen>OHpK6nwbM6FfdoAJiSBxW0VdTJYZZp3I</ProfessionalRegistrationEntryIdentifier-ConsultantFirstSeen>
    </ConsultantFirstSeen>
    <OrganisationSiteIdentifierProviderFirstSeen extension="MV8AW"/>
    <DateFirstSeenCancerSpecialist>2023-06-25</DateFirstSeenCancerSpecialist>
    <OrganisationSiteIdentifierProviderFirstCancerSpecialist extension="QFEDWLM"/>
</ReferralAndFirstStageOfPatientPathway>

Notes:

• this section will only be completed for 'primary cancer diagnoses'
• for 'recurrent cancers', the section labelled ‘Core – Non Primary Cancer Pathway’ will be completed instead

Imaging procedures carried out to diagnose or stage the cancer are included in this section.

Details of specific imaging procedures and outcomes required for specific disease groups are included in the appropriate site-specific sections and must be included in monthly submissions.

There are now 3 choices to make when adding data within this section. This is because not all data are required, if the NICIP or SNOMED CT data items are completed.

<Imaging>
    <OrganisationSiteIdentifierOfImaging extension="5C4M0"/>
    <ProcedureDateCancerImaging>2023-06-25</ProcedureDateCancerImaging>
    <ImagingOutcome code="02"/>
    <ImagingCodeNicip code="vJM52M"/>
    <ImagingCodeSnomedCt code="712672768325464850"/>
    <ImagingDetails>
        <CancerImagingModality code="C08A"/>
        <ImagingAnatomicalSite code="8XC5B"/>
        <AnatomicalSideImaging code="B"/>
    </ImagingDetails>
    <ImagingReportText>7pcUw4d9xkCXFOUHzfsNM0elHjuo5C7O3i7hgBonK7SrKcw</ImagingReportText>
</Imaging>

Notes:

• it is not expected that all data items in the three choices are required (as shown in the example above)
  • any one of the three choices would be sufficient, although they could all be collected and reported if known
• if Trust A performs the imaging but due to capacity it is reported in another Trust (Trust B), or is sent there for a second opinion, it is the responsibility of Trust A to report this through COSD and not Trust B

This allows for all diagnostic procedures to be correctly recorded within the data set. The organisation code and date are mandatory, however, either OPCS or SNOMED CT can be used to record the diagnostic procedure, but if selected are mandatory.

There will be linked ‘child groups’ throughout the data set to ‘CORE - Diagnostic Procedures’, this is to allow greater depth of data collection whilst maintaining accuracy and ensuring that both the organisation and date are recorded. Please refer to the data set and schema pack for examples of these data items, and how they are structured.

<DiagnosticProcedures>
    <OrganisationSiteIdentifierDiagnosticProcedure extension="4WMKATJ"/>
    <DiagnosticProcedureDate>2023-06-25</DiagnosticProcedureDate>
    <DiagnosticProcedureSnomedCt code="160087094149075032"/>
    <SentinelNodeBiopsy>
        <SentinelNodeBiopsyOutcome code="P"/>
    </SentinelNodeBiopsy>
    <DiagnosticProceduresLung>
        <DiffusionCapacity>
            <DiffusionCapacityDlcoOrTlcoResult value="199"/>
        </DiffusionCapacity>
    </DiagnosticProceduresLung>
</DiagnosticProcedures>
<DiagnosticProcedures>
    <OrganisationSiteIdentifierDiagnosticProcedure extension="ATJX5"/>
    <DiagnosticProcedureDate>2023-06-25</DiagnosticProcedureDate>
    <DiagnosticProcedureOpcs code="R912"/>
    <SentinelNodeBiopsy>
        <SentinelNodeBiopsyOutcome code="P"/>
    </SentinelNodeBiopsy>
    <DiagnosticProceduresLung>
        <Bronchoscopy>
            <BronchoscopyPerformedType code="5"/>
        </Bronchoscopy>
    </DiagnosticProceduresLung>
</DiagnosticProcedures>

In this example I have shown you how a child is linked/nested to its parent section/group. As we move forward, I will separate out each group (if they become very large) but will reference you to the schema examples, so you can easily see how the whole xml is structured and should look.

Remember that if there is no data in a section, you do not have to report blank data, simply omit the section from your xml (unless it is mandatory).

Each example above has a different choice both within the core procedure type (NICIP or SNOMED CT) and site specific (Diffusion Capacity or Bronchoscopy). There are other site specific lung diagnostic procedures, so be mindful to use the same structure as above to correctly nested them.

Sentinel node biopsy (0..1)

• this is a child of ‘CORE – Diagnostic Procedures’ group

Diagnostic procedures lung (0..1)

• these are all a child of ‘CORE – Diagnostic Procedures’ group

Diagnosis details in the linkage section are required for every record to ensure that the correct record can be identified, and information can be correctly linked.

Recording an applicable diagnosis, including a ‘Date of Diagnosis’, triggers inclusion of the record in the submission.

Both ICD10 codes and morphology (SNOMED and/or ICD-O-3) should be completed for all cases, however morphology ICD-O-3 must be provided for all haematological, sarcoma and CTYA malignancies.

There will only be one diagnosis section completed for each record.

<Diagnosis>
    <OrganisationSiteIdentifierOfDiagnosis extension="8SIHOFG"/>
    <BasisOfDiagnosisCancer code="1"/>
    <MorphologyIcd-o-3 code="lTSiATn"/>
    <MorphologySNOMED>
        <MorphologySnomedDiagnosis code="X75I5RAG"/>
        <SnomedVersionDiagnosis code="03"/>
    </MorphologySNOMED>
    <TopographyIcd-o-3 code="35oEArf"/>
    <Ki67 value=”29”/>
    <GradeOfDifferentiationAtDiagnosis code="G1"/>
    <PerformanceStatusAdult code="4"/>
    <DiagnosisCodeSnomedCt code="937563396795368931"/>
    <MetastaticTypeAndSiteDiagnosis>
        <MetastaticType code="01"/>
        <MetastaticSite code="04"/>
    </MetastaticTypeAndSiteDiagnosis>
    <MetastaticTypeAndSiteDiagnosis>
        <MetastaticType code="02"/>
        <MetastaticSite code="12"/>
    </MetastaticTypeAndSiteDiagnosis>
</Diagnosis>

Notes:

• the ICD10 codes for secondary cancer should only be used when the primary diagnosis is not known
• the main reported xml will have all the child groups nested within the diagnosis section (where applicable), please refer to the schema pack examples for full details

This is a child group of ‘CORE – Diagnosis’

<DiagnosisAdditionalItems
    <PrimaryDiagnosisSubsidiaryComment>vJkcx45UzV7vbUBq</PrimaryDiagnosisSubsidiaryComment>
    <SecondaryDiagnosisIcd code="XGFi"/>
    <OtherSignificantDiagnosisSubsidiaryComment>dO5G3VNMxRXBvr7MCNVC</OtherSignificantDiagnosisSubsidiaryComment>
    <FamilialCancerSyndrome code="N"/>
    <FamilialCancerSyndromeSubsidiaryComment>hS4E1gQZ11ieLTaPAEBMdkGEm</FamilialCancerSyndromeSubsidiaryComment>
    <FunctionalSyndromeClassificationIndicator code="N"/>
    <FunctionalSyndromeClassificationType>
        <FamilialSyndromeClassificationType code="02"/>
    </FunctionalSyndromeClassificationType>
    <FunctionalSyndromeClassificationType>
        <FamilialSyndromeClassificationType code="98"/>
        <OtherFamilialSyndromeClassificationType>dO5G3VNMxRXBvr7MCNVC</OtherFamilialSyndromeClassificationType>
    </FunctionalSyndromeClassificationType>
</DiagnosisAdditionalItems>

This is a child group of ‘Core – Diagnosis’ and this allows for where a patient’s disease has progressed whilst on their original primary pathway to be recorded.

Although the section is required, all these data items are now mandatory (if selected) and must be submitted per submission

More than one submission is permitted per diagnosis

<DiagnosisProgression>
    <MetastaticTypeAndSiteDiagnosisProgression>
        <MetastaticType code="01"/>
        <MetastaticSite code="03"/>
    </MetastaticTypeAndSiteDiagnosisProgression>
    <MetastaticTypeAndSiteDiagnosisProgression>
        <MetastaticType code="02"/>
        <MetastaticSite code="12"/>
    </MetastaticTypeAndSiteDiagnosisProgression>
    <ProgressionDatePrimaryPathway>2023-06-25</ProgressionDatePrimaryPathway>
</DiagnosisProgression>

This is a child group of ‘CORE – Diagnosis’ and this allows for where a patient’s disease has transformed whilst on their original primary pathway to be recorded.

Although the section is required, all these data items are now mandatory (if selected) and must be submitted per submission.

More than one submission is permitted per diagnosis

<DiagnosisTransformation>
    <TransformationDatePrimaryPathway>2023-06-25</TransformationDatePrimaryPathway>
    <DiagnosisTransformationMorphology>
        <MorphologySnomedTransformation code="DX13GHOZ"/>
        <SnomedVersionTransformation code="01"/>
    </DiagnosisTransformationMorphology>
</DiagnosisTransformation>

Note:

• there is a choice here for Diagnosis Transformation Morphology, in this example I have used ’choice two’

There may be multiple occurrences per record

<PersonObservation>
    <PersonObservationHeightInMetres value="1.70"/>
    <PersonObservationWeight value="75.793"/>
    <BodyMassIndex value="26.2"/>
    <DateObservationMeasured>2023-04-25</DateObservationMeasured>
</PersonObservation>
<PersonObservation>
    <PersonObservationHeightInMetres value="1.70"/>
    <PersonObservationWeight value="72.152"/>
    <BodyMassIndex value="25.0"/>
    <DateObservationMeasured>2023-06-25</DateObservationMeasured>
</PersonObservation>

This section has been updated with additional risk factors, which will help improve our understanding of causative risk factors across all tumour sites.

There may be up to one occurrence per record

<ClinicalNurseSpecialistAndRiskFactorAssessments>
    <ClinicalNurseSpecialistIndicationCode code="Y1"/>
    <TobaccoSmokingStatus code="2"/>
    <TobaccoSmokingCessation code="8"/>
    <HistoryOfAlcoholCurrent code="1"/>
    <HistoryOfAlcoholPast code="2"/>
    <DiabetesMellitusType1AndType2Indicator code="1"/>
    <MenopausalStatus code="2"/>
    <PhysicalActivityCurrent code="9"/>
</ClinicalNurseSpecialistAndRiskFactorAssessments>

This section has been updated with the support of NHSE and Macmillan, linking the HNA and PCSP sections together with the addition of a choice.

There may be multiple occurrences per record

<ClinicalNurseSpecialistHolisticNeedsAssessmentandPersonalisedCareAndSupportPlanning>
    <AssessmentOffered code="03"/>
    <AssessmentCarePlanStatus code="05"/>
    <AssessmentCarePlanDate>2023-06-25</AssessmentCarePlanDate>
    <AssessmentCarePlanPointOfPathwayt code="04"/>
    <HnaPcspStaffRoleChoice>
        <StaffRoleCarryingOutTheAssessment code="03"/>
    </HnaPcspStaffRoleChoice>
</ClinicalNurseSpecialistHolisticNeedsAssessmentandPersonalisedCareAndSupportPlanning>

In this example I have shown a HNA through the choice, you could simply replace the HNA tag with the PCSP one for staff role as follows to record a PCSP record:

    <HnaPcspStaffRoleChoice>
        <StaffRoleCarryingOutThePlanningy code="04"/>
    </HnaPcspStaffRoleChoice>

Record all Multidisciplinary Team Meetings (MDT)’s, where the patient was discussed. A new MDT section should be added if a patient was discussed at another Trust, therefore multiple MDTs can be submitted depending on the patient pathway.

There is now a choice at the start to indicate if a patient was not discussed at the MDT or this was unknown (choice 1), or if the patient was discussed (including minuting) for ‘patients on predefined standard of care reviewed outside MDT’ (choice 2).

<MultidisciplinaryTeamMeetings>
    <MultidisciplinaryTeamMeetingDiscussion code="1"/>
</MultidisciplinaryTeamMeetings>
<MultidisciplinaryTeamMeetings>
    <MultidisciplinaryTeamMeetingDetail>
        <MultidisciplinaryTeamMeetingDiscussionType code="3"/>
        <MultidisciplinaryTeamMeetingDate>2023-06-25</MultidisciplinaryTeamMeetingDate>
        <OrganisationSiteIdentifierOfMultidisciplinaryTeamMeeting extension="SX77WT"/>
        <MultidisciplinaryTeamMeetingType>0102</MultidisciplinaryTeamMeetingType>
        <MultidisciplinaryMeetingTypeComment>D2kOBJtvU57DOt</MultidisciplinaryMeetingTypeComment>
    </MultidisciplinaryTeamMeetingDetail>
</MultidisciplinaryTeamMeetings>

Note:

• you would only have an either/or within this choice, but you can have multiple of choice two

This section includes details applicable to care planning, including performance status, prognostic factors and treatment options which are normally discussed at the MDT meeting.

The ‘Cancer Care Plan Date’ will be the MDT after all the investigations have been completed and the treatment plan is agreed. At this point all the information will be available to record the Final pre-treatment TNM and Stage Grouping too.

Important notes ‘Cancer Care Plan’:

• there will only be one cancer care plan section completed for each record

• most of the data items in this section will normally be available at the meeting at which the first definitive treatment was discussed

• after treatment starts, the treatment plan may change due to medical reasons, this does not create a new cancer care plan, merely changes the treatment plan

Additional notes:

• if a patient is treated prior to MDT, they should be added to the next MDT for discussion

• this can be classed as discussed at MDT at the point of treatment, for the cancer care plan episode

• therefore, if a patient has a treatment prior to MDT and is subsequently added to the next MDT, the care plan can be documented as care plan agreed (this often happens for skin)

There may be up to one occurrence per Primary Cancer Pathway

<CancerCarePlan>
    <MultidisciplinaryTeamDiscussionDateCancer>2023-06-25</MultidisciplinaryTeamDiscussionDateCancer>
    <CancerCarePlanIntent code="C"/>
    <PlannedCancerTreatmentType code="01"/>
    <NoCancerTreatmentReason code="08"/>
</CancerCarePlan>

There are many site-specific data items (child groups) to Core - Cancer care plan, and these will be recorded at this point in the patient pathway. See site-specific schema xml examples sections for further details.

Some of the data items in the Care Plan sections of the site-specific data sets will only be available after the initial treatment has been completed or at a subsequent MDT discussion. The items in this section will not therefore necessarily relate to the date of the MDT recorded as ‘Multidisciplinary Team Discussion Date (Cancer)’.

The ‘TNM Coding Edition’ and ‘Version Numbers’ are mandatory, this helps improve the data quality of stage being submitted from Trusts.

The stage of a cancer is a description of how far the cancer has spread. The Union for International Cancer Control (UICC) TNM stage is the most widely used system for staging cancers. The American Joint Committee on Cancer (AJCC), and ENETS (European Neuroendocrine Tumour Society) coding systems can also be recorded throughout these fields. The addition of a TNM coding edition field allows for accurate allocation.

<Staging>
    <TCategoryFinalPretreatment>h9qwPtXWJFuGXlu</TCategoryFinalPretreatment>
    <NCategoryFinalPretreatment>PXFcOGbfAmFwy</NCategoryFinalPretreatment>
    <MCategoryFinalPretreatment>BM2uYJD5opIdv</MCategoryFinalPretreatment>
    <TnmStageGroupingFinalPretreatment>g8ARhXVIgcGOzvI</TnmStageGroupingFinalPretreatment>
    <OrganisationSiteIdentifierReportedPretreatmentTnmStage extension="Y91O4"/>
    <StageDateFinalPretreatmentStage>2023-06-25</StageDateFinalPretreatmentStage>
    <TCategoryIntegratedStage>cqr6rZleYzMGQHe</TCategoryIntegratedStage>
    <NCategoryIntegratedStage>HBrvjQjJdKLYJjl</NCategoryIntegratedStage>
    <MCategoryIntegratedStage>E8dchisaTgZ3Kmu</MCategoryIntegratedStage>
    <TnmStageGroupingIntegrated>Tvm1BChbIqlg9</TnmStageGroupingIntegrated>
    <OrganisationSiteIdentifierReportedIntegratedTnmStage extension="MUT5O"/>
    <StageDateIntegratedStage>2023-06-25</StageDateIntegratedStage>
    <TnmCodingEdition code="1"/>
    <TnmVersionNumberStaging>8</TnmVersionNumberStaging>
</Staging>

This is required to record and improve the tumour specific ‘site specific stage’ by enforcing both the date and organisation where the stage took place. The stage date is a mandatory data item and should only be reported if there is a linked site specific stage also reported. The organisation site field has been downgraded to ‘Required’ from v10, to help support ascertainment and data quality.

Please refer to the individual tumour specific sections where there is a site specific stage, for example:

• Central Nervous System (CTYA):
  • Chang Staging System Stage
• Children Teenage and Young Adults (CTYA):
  • Wilms Tumour Stage
  • International Neuroblastoma Risk Group (INRG) Staging System
  • Pretext Staging System Stage
  • Pretext Annotation Factors
  • International Staging System For Retinoblastoma
• Gynae:
  • Figo
• Haematology:
  • Ann Arbor Stage
  • Binet Stage
  • R-ISS Stage for Myeloma
• Haematology (CTYA):
  • Murphy (St Jude) Stage
• Liver:
  • Barcelona Clinic Liver Cancer (BCLC) Stage
• Urology (Testicular):
  • Stage Grouping (Testicular)

There is no site specific stage for Lung, but I have given an example below for Figo stage:

<StagingSiteSpecific>
    <OrganisationSiteIdentifierSiteSpecificStage extension="86QATOD"/>
    <StageDateSiteSpecificStage>2023-06-25</StageDateSiteSpecificStage>
    <StagingGynaecological>
        <FinalFigoStage>Z7qtxT0</FinalFigoStage>
    </StagingGynaecological>
</StagingSiteSpecific>

The initial record is completed up to the first treatment, but all subsequent treatments are also required. Treatments are also reported for cases covered by Cancer Waiting Times although some additional details are included in COSD in both generic core and site specific sections.

May be multiple occurrences per record.

<Treatment>
    <AdjunctiveTherapy code="2"/>
    <CancerTreatmentIntent code="04"/>
    <TreatmentStartDateCancer>2023-06-25</TreatmentStartDateCancer>
    <CancerTreatmentModalityRegistration code="08"/>
    <OrganisationSiteIdentifierOfProviderCancerTreatmentStartDate extension="R1QHF"/>
    <ConsultantTreatment>
        <ProfessionalRegistrationIssuerCode-ConsultantTreatment code="03"/>
        <ProfessionalRegistrationEntryIdentifierConsultantTreatment>4PkBF9jRIcaZTxxkPWOq8l5sQVAxTzex</ProfessionalRegistrationEntryIdentifier-ConsultantTreatment>
    </ConsultantTreatment>
    <EndOfTreatmentSummaryDate>2023-06-25</EndOfTreatmentSummaryDate>
    <DischargeDateHospitalProviderSpell>2023-06-25</DischargeDateHospitalProviderSpell>
    <DestinationOfDischargeHospitalProviderSpell code="48"/>
</Treatment>

Notes:

• Surgery is a child of Treatment and examples have been separated out below due to size
• in the xml, these would be nested within the treatment section
• there will also be many site specific child groups which need to be nested correctly within the xml
  • please refer to the schema document and examples for reference

This section is a child of ‘Core – Treatment and carries only the surgery details.

May be up to one occurrence per Core - Treatment (0..1)

<Surgery>
    <ProcedureDate>2023-06-25</ProcedureDate>
    <SurgicalAdmissionType code="1"/>
    <ConsultantSurgery>
        <ProfessionalRegistrationIssuerCode-ConsultantSurgeon code="09"/>
        <ProfessionalRegistrationEntryIdentifier-ConsultantSurgeon>ze7VjkAlpiEKw1Inpfl5fDzU9FnCIZa7</ProfessionalRegistrationEntryIdentifier-ConsultantSurgeon>
    </ConsultantSurgery>
    <ConsultantSurgery>
        <ProfessionalRegistrationIssuerCode-ConsultantSurgeon code="02"/>
        <ProfessionalRegistrationEntryIdentifier-ConsultantSurgeon>ECqCeKthhS3zD6iVCp7hecJONV78A4EM</ProfessionalRegistrationEntryIdentifier-ConsultantSurgeon>
    </ConsultantSurgery>
    <PrimaryProcedureOpcs code="G253"/>
    <PrimaryProcedureSnomedCt code="248473119506478709"/>
    <ProcedureOpcs code="U989"/>
    <ProcedureSnomedCt code="570043691852073271"/>
    <UnplannedReturnToTheatreIndicator code="N"/>
    <AsaScore code="6"/>
    <SurgicalAccessType code="4"/>
    <SurgeryLCCOP>
        <RegionalAnaestheticTechnique code="1"/>
    </SurgeryLCCOP>
</Surgery>

Notes:

• within the group above is the nested Lung ‘Surgery LCCOP’ data item, Regional Anaesthetic Technique
• this is how all nested child groups would be formatted

This is section is designed to capture Acute Oncology (AO) episodes within a Trust.

The purpose of these items is to capture the unplanned care cancer patients receive in an acute care environment. These data are only for collection by those hospitals with an Acute Oncology Service (AOS) in place.

May be multiple occurrences per record.

<AcuteOncology>
    <AcuteOncologyAssessmentDate>2023-06-25</AcuteOncologyAssessmentDate>
    <OrganisationSiteIdentifierAcuteOncology extension="JLK8I"/>
    <AssessmentLocation code="03"/>
    <PatientType code="04"/>
    <Outcome code="11"/>
</AcuteOncology>
<AcuteOncology>
    <AcuteOncologyAssessmentDate>2023-06-25</AcuteOncologyAssessmentDate>
    <OrganisationSiteIdentifierAcuteOncology extension="6R5TU"/>
    <AssessmentLocation code="03"/>
    <PatientType code="08"/>
    <Outcome code="13"/>
</AcuteOncology>

Note:

• there are extended supplementary information notes within the user guide, to support collection of each data item

This group is designed to enforce all laboratory results to be reported with both the date and organisation where the test was done. This will be the parent group to many child sections across the data set and site specific sections.

May be multiple occurrences per record.

<LaboratoryResults>
    <LaboratoryResultDate>2023-06-25</LaboratoryResultDate>
    <OrganisationIdentifierLaboratoryResult extension="JHV"/>
    <LaboratoryResultsGeneral>
        <LdhValue value="208577"/>
        <BetaHumanChorionicGonadotropinSerum value="90621013"/>
        <AlphaFetoproteinSerum value="55747610"/>
    </LaboratoryResultsGeneral>
</LaboratoryResults>
<LaboratoryResults>
    <LaboratoryResultDate>2023-06-25</LaboratoryResultDate>
    <OrganisationIdentifierLaboratoryResult extension="J8Q"/>
    <LaboratoryResultsGeneral>
        <LdhValue value="155502"/>
        <BetaHumanChorionicGonadotropinSerum value="9093636"/>
        <AlphaFetoproteinSerum value="91781917"/>
    </LaboratoryResultsGeneral>
</LaboratoryResults>

Notes:

• as this section is small I have included the child group Core - Laboratory Results – General (0..1), so that the format of the reported xml is easier to follow
• if there are no laboratory results, then you do not have to report this section

There may be some data items within the site specific sections which are not part of a parent Core section. In these situations, they would be added to the end of each xml report as the following Lung data items ‘Mediastinal Sampling Indicator’ and ‘Lung Health Check Indication’ highlight:

        <MediastinalSamplingIndicator>
            <MediastinalSamplingIndicator code="9"/>
        </MediastinalSamplingIndicator>
        <HealthCheck>
            <LungHealthCheckIndication code="1"/>
        </HealthCheck>
    </LungRecord>
</COSD:COSD>

This would also close the xml record as highlighted above.

Please refer to the data set, user guide and schema documents to fully understand each data item and how they are formed within the xml report.

In addition, please take advantage of the examples in the schema document and the support of the NDRS teams, for frequently asked questions and beta testing of any changes to your system.