COSD pathology technical guide v5.0.1

The purpose of this document is to provide instruction to informatics personnel within provider organisation pathology laboratory departments, Laboratory Information Management System (LIMS) suppliers and other IT software suppliers (inhouse and commercial), regarding file creation and submission of the Cancer Outcomes and Services Data set (COSD) pathology 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 89/2022.

This is an update to an existing information standard DAPB5121 Amd 13/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.

In order to maintain the clinical accuracy, it is important to regularly review COSD with clinical experts from across the NHS. For this data set, extensive consultation and advice was also sought from the Royal College of Pathologists (RC Path) Working Group on Cancer Services.

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.

This document provides technical guidance to support personnel within provider organisation pathology laboratory departments, Laboratory Information Management System (LIMS) suppliers and other IT software suppliers (inhouse and commercial), in the submission of the COSD Pathology data set v5.0. It should be read in conjunction with:

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

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 main COSD ISN page for access to these documents and other information.

Pathology departments and providers of cancer services are required to provide a monthly return on all cancer patients diagnosed from 01 January 2013 , who then go on and have a pathological excision, sample or other pathological test 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 National Disease Registration Service (NDRS) branch office via secure data transfer or submissions can be made by each provider via the NDRS API portal.

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: [email protected]
• the Data Model and Dictionary Service, contact: [email protected]

Find further help and tutorials on XML

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

1. pathology providers must submit all data relating to patients for whom they have either reported on and authorised the original pathology report or commented on (second opinion) as a specialist centre (creating a supplementary report)
2. submitted files must be sent by secure file transfer methods as agreed with your regional NDRS office
3. files can be submitted direct via the API portal
4. files must reach the regional NDRS office by the twenty-fifth working day following the end of month for all ‘registerable pathology reports’ authorised
5. each file may include records for more than one tumour group
6. individual records must contain the section ‘LinkagePatientID’
7. providers should aim to complete all the relevant data items as soon as possible, however as long as the mandatory fields. within the ‘LinkagePatientID’ are completed the record can be submitted
8. records in each submission must include all applicable sections where possible
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 (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 Pathology 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 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 pathology data set and for 12 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 pathology data specification
• 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 pathology 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 pathology 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.

All other disease types (which do not have their own specific subsection), will be recorded under ‘OtherRecord’. This simplifies data recording.

The top-level schema in the hierarchical structure is: COSD_Pathology-v5-0.xsd.

For a Record which does not fall into any of the tumour groups, i.e. a Record with only core elements, then the default schema path for a Record is used which is defined in the master file: COSD_Pathology-v5-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 is 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 COSD element

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 e.g. 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.

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.

For example, a breast 'COSDRecord' is represented in COSD Pathology XML like:

<BreastRecord>
    <Id root>
    <LinkagePatientID>
        <!-- LinkagePatientID Elements -->
    </LinkagePatientID>
    <Demographics>
        <!-- Demographic Elements -->
    </Demographics>
        </Pathology>
        <!-- Core Pathology Elements -->
        <PathologyBreast>
            <!-- Additional Breast Pathology Elements -->
        </PathologyBreast>
    </Pathology>
<BreastRecord>

It should therefore become clear to the reader that ‘Other' (non-specific site) records have no content group:

<OtherRecord>
    <Id root>
    <LinkagePatientID>
        <!-- LinkagePatientID Elements -->
    </LinkagePatientID>
    <Demographics>
        <!-- Demographic Elements -->
    </Demographics>
    </Pathology>
        <!-- Core Pathology Elements -->
    </Pathology>
<OtherRecord>

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 non specific ‘Other’ pathology record may contain:

<OtherRecord>
    <InvestigationResultDate>...</InvestigationResultDate>
    ...
    <MicrosatelliteInstabilityMsiTesting code="..."/>
</OtherRecord>

Whereas a 'BreastPathology' section may also contain:

<BreastRecord>
    <Pathology>
        <InvestigationResultDate>...</InvestigationResultDate>
        ...
        <MicrosatelliteInstabilityMsiTesting code="..."/>
        <PathologyBreast>
            <CoreBiopsyNode code="..."/>
        </PathologyBreast>
    </Pathology>
</BreastRecord>

Note:

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

The hierarchical nature of the data set may lead providers to adopt an object orientated programming (OOP) approach to developing the COSD Pathology 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, such as 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: () ->
  
  buildCOSDRecord: (pathology) -> 
    @buildCore(pathology)

  # Core section
  buildCore: (pathology) ->
    @buildLinkagePatientId(pathology.patient)
    @buildDemographics(pathology.patient)
    @buildPathology(pathology) for pathology in tumour.pathologies
  
  buildLinkagePatientId: (patient) -> 
    alert "build LinkagePatientId"
  
  buildDemographics: (patient) -> 
    alert "build Demographics"
  
  buildPathology: (pathology) -> 
    alert "build Pathology "

class BreastGenerator extends CoreGenerator
  # Core section

  buildPathology: (pathology) ->
    super pathology
    alert "build BreastPathology/BreastPathology"
    # TODO: add site specific fields here

generator = new BreastGenerator 
generator.buildCOSDRecord(...)

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 pathology report text field within the COSD Pathology v5.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 YYYY-MM-DDThh:mm:s

Example

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

COSD_MDT_X09_2023-07-01_2023-07-31 2023-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.

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 transmitted between nhs.net email accounts (or alternative email accounts that are accepted as part of the nhs.net framework), or in some cases the pathology report may be submitted by direct files transfer (the NDRS API portal) immediately after the report is authorised.

Details of using the API portal will be agreed with each regional NDRS offices and the organisation providing the data.

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 Pathology data in XML from January 2016, ensuring that:

• files should be submitted by NHS providers, where the pathology specimens are authorised and reported or where a second opinion has been sought and a supplementary report is created
• 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 NDRS office

In some cases, the files may relate to a provider who are contracted to report the specimens on behalf of the originating Trust. This may not be the Trust where the excisions or biopsies are performed.

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:

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.

Validation

The data will be validated by the NDRS 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 NDRS 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 NDRS 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 Laboratory Information Management System (LIMS); 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 pathology record, system suppliers or IT departments must use the published documents to help and support them through this process as follows:

• COSD v5.0.1 data set
• COSD pathology user guide
• COSD pathology schema pack
• COSD pathology 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 pathology submission for a Lung specimen.

The examples of the xml are by section, 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 pathology 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 the core pathology record 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_Pathology-v5-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 and are necessary 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.

Note:

• it is important to refer to the pathology user guide if reporting pathology direct from the LIMS as there are different linkage items required

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

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"/>
</Demographics>

Note:

• address can be either an175 or 5 lines each an35

As of January 2016, all pathology should be submitted to the NDRS in structured xml. These reports will include all the data as prescribed below and would be submitted to the NDRS directly from the pathology Laboratory Information Management Systems (LIMS). Once the pathologist has completed and signed off (authorised) each report, they can be submitted either individually or as a monthly batch of data. There is a separate pathology schema for submissions which come directly from the pathology LIMS.

Pathological diagnosis and grade (where applicable) are recorded on biopsies and may be amended after surgical resection (if appropriate), when pathological staging should also be available. Full text pathology reports should be submitted to include these data items if structured coded extracts are not available. In addition, there may be more than one pathology section completed for each record.

The core data set includes general pathological items which are applicable to all tumour sites unless otherwise stated, and site specific pathology items (relating to stage components). These core and site specific items are a subset of the RCPath cancer data sets which have been approved as professional standards by the college.

All the data items across the data set have been aligned exactly with the ‘RC Path – Core’ pathology data items. This has created additional changes to both data item names, descriptions and/or the attribute lists, where these were different in COSD. It is expected that these changes will help improve the data quality and ascertainment, whilst reducing the burden of double reporting.

Where structured reporting systems are not available for pathology, it is expected that many of the relevant data items will be included in the free text pathology report.

Important notes:

• all pathology data items are prefixed with a lowercase ‘p’, for example ‘pCR0780’

• these reports should be sent to the NDRS through pre-agreed methods of submission

• the regional ‘Data Liaison Managers’ can support Trusts with this, and any testing required for new reporting of data

• this is especially important when a new system is implemented, or an upgrade rolled out by a supplier or Trust IT team

A patient may have any number of pathology reports, and there may be more than one pathology report per specimen.

<Pathology>
    <InvestigationResultDate>2023-01-26</InvestigationResultDate>
    <ServiceReportIdentifier extension="XMQawz3fBb3Ndqm8yLZlY1wxDCz8vETK3"/>
    <PathologyObservationReportIdentifier extension="w7yW9VbSyb4mTvkMK5tiIIxSF"/>
    <ServiceReportStatus code="3"/>
    <ConsultantPathologyTestRequestedBy>
        <ProfessionalRegistrationIssuerCode-ConsultantPathologyTestRequestedBy code="03"/>
        <ProfessionalRegistrationEntryIdentifier-ConsultantPathologyTestRequestedBy>VNi5NqAy3bN8xAOwQZ1dWWTfDgp</ProfessionalRegistrationEntryIdentifier-ConsultantPathologyTestRequestedBy>
    </ConsultantPathologyTestRequestedBy>
    <OrganisationSiteIdentifierPathologyTestRequestedBy extension="59SL8"/>
    <SampleCollectionDate>2023-01-26</SampleCollectionDate>
    <SampleReceiptDate>2023-01-26</SampleReceiptDate>
    <OrganisationIdentifierOfReportingPathologist extension="CWIYH"/>
    <ConsultantPathologist>
        <ProfessionalRegistrationIssuerCode-ConsultantPathologist code="03"/>
        <ProfessionalRegistrationEntryIdentifier-ConsultantPathologist>wNnrGpZnF0pZd0GaLhL9Mk37oC6sj</ProfessionalRegistrationEntryIdentifier-ConsultantPathologist>
    </ConsultantPathologist>
    <SpecimenNature code="5"/>
    <TopographyMorphologySnomed>
        <SnomedVersionPathology code="99"/>
        <TopographySnomedPathology code="6YJNAK0"/>
    </TopographyMorphologySnomed>
    <TopographyMorphologySnomed>
        <SnomedVersionPathology code="99"/>
        <MorphologySnomedPathology code="6YJNAK0"/>
    </TopographyMorphologySnomed>
    <DiagnosisIcdPathological code="pMC28"/>
    <TumourLateralityPathological code="8"/>
    <PathologyInvestigationType code="99"/>
    <PathologyReportText>02Nx5qF5DEBU14UJaGJlSepQ0tItzsITvv7YuEj2HsmJm3qqorCPA67jVx</PathologyReportText>
    <LesionSizePathological value="605.02"/>
    <GradeOfDifferentiationPathological code="GX"/>
    <CancerVascularOrLymphaticInvasion code="99"/>
    <PerineuralInvasion code="2"/>
    <ExcisionMargin code="09"/>
    <ExcisionMarginCircumferential code="1"/>
    <SynchronousTumourIndicator code="9"/>
    <NumberOfNodesExamined value="479"/>
    <NumberOfNodesPositive value="173"/>
    <SentinelLymphNodesExaminedNumber value ="22"/>
    <SentinelLymphNodesPositiveNumber value ="12"/>
    <PostSnlbCompletionLymphadenectomy-NodesExaminedNumber value ="22"/>
    <PostSnlbCompletionLymphadenectomy-NodesPositiveNumber value ="12"/>
    <TnmCodingEdition code="1"/>
    <TnmVersionNumberPathological>zw</TnmVersionNumberPathological>
    <TCategoryPathological>gwBRhw4RHLtNf0v</TCategoryPathological>
    <NCategoryPathological>N5d9AGt9H88UkaG</NCategoryPathological>
    <MCategoryPathological>3wlO06kD1hYbFaI</MCategoryPathological>
    <TnmStageGroupingPathological>NW7ZPjjbivLQ</TnmStageGroupingPathological>
    <NeoadjuvantTherapyIndicator code="Y"/>
    <Ki-67Indicator code="1"/>
    <Ki-67Result value="93"/>
    <Mlh1NuclearExpressionIntact code="E"/>
    <Pms2NuclearExpressionIntact code="F"/>
    <Msh2NuclearExpressionIntact code="N"/>
    <Msh6NuclearExpressionIntact code="X"/>
    <PathologyLung>
        <ExtentOfAtelectasis code="5"/>
        <ExtentOfPleuralInvasion code="2"/>
        <PericardialInvasion code="9"/>
        <DiaphragmInvasion code="Y"/>
        <InvasionIntoGreatVessel code="Y"/>
        <InvasionIntoHeart code="Y"/>
        <MalignantPleuralEffusion code="9"/>
        <InvasionIntoMediastinum code="9"/>
        <SatelliteTumourNodulesLocation code="3"/>
    </PathologyLung>
</Pathology>

All site specific data items are reported at the end of each record after the core pathology section, 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, including the cardinality.

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).

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.