• International Classification of Diseases (ICD)
• International Classification of Diseases for Oncology (ICD-O)
• National Interim Clinical Imaging Procedure Code Set (NICIP Code Set)
• NHS dictionary of medicines and devices (dm+d)
• OPCS Classification of Interventions and Procedures
• Read Coded Clinical Terms
• SNOMED CT®
• SNOMED CT Refset

Requests for Change:

Requests for Change:

• Change requests for CLINICAL TERMINOLOGY CODES and CLINICAL CLASSIFICATION CODES released by NHS England should be made through the Request Submission Portal on the NHS England website at: Welcome to the Request Submission Portal.
• 
  
• Requests for medicines or devices terminologies should be made via the Service Desk at: information.standards@nhs.net.

• XML Schema Download:

• XML Schema Download:

• XML Schema TRUD Download
• 
  XML Schema Constraints:

XML Schema Constraints:

• Cancer Outcomes and Services Data Set XML Schema Constraints
• Diagnostic Imaging Data Set XML Schema Constraints
• Electronic Prescribing and Medicines Administration Data Set XML Schema Constraints
• Emergency Care Data Set Version 4 XML Schema Constraints
• HIV and AIDS Reporting Data Set XML Schema Constraints
• 
  Data Set Constraints:

Data Set Constraints:

• Community Services Data Set Constraints
• Improving Access to Psychological Therapies Data Set Constraints
• Mental Health Services Data Set Constraints
• National Neonatal Data Set Constraints
• Radiotherapy Data Set Constraints
• Systemic Anti-Cancer Therapy Data Set Constraints

The Commissioning Data Set Addressing Grid below illustrates which ORGANISATION CODES should be used to populate the CDS PRIME RECIPIENT IDENTITY and CDS COPY RECIPIENT IDENTITY for each PATIENT / NHS SERVICE CONTRACT.  See the specific ORGANISATION CODE Data Elements for further information on their usage and Organisation Data Service Default Codes etc.

Commissioning Data Set Addressing Grid is only applicable for Commissioning Data Set version 6-2, as CDS PRIME RECIPIENT IDENTITY and CDS COPY RECIPIENT IDENTITY have been replaced with ORGANISATION IDENTIFIER (CDS RECIPIENT) in Commissioning Data Set version 6-3.

Health Care Providers need to specify the ORGANISATIONS that have a right to the commissioning data set data as a CDS PRIME RECIPIENT IDENTITY or CDS COPY RECIPIENT IDENTITY. This is so that they can access the data once it has been stored in the Secondary Uses Service.

Please note that payment via the National Tariff Payment System is not determined by the CDS PRIME RECIPIENT IDENTITY or CDS COPY RECIPIENT IDENTITY.

Important Notes:

• For submissions of CDS V6-2, the CDS PRIME RECIPIENT IDENTITY is Mandatory for submission in the CDS Type 005B (CDS Transaction Header Group - Bulk Update Protocol) and CDS Type 005N (CDS Transaction Header Group - Net Change Protocol). However, it no longer forms part of the key for the process of determining duplicate records within the Secondary Uses Service. Note that the CDS PRIME RECIPIENT IDENTITY continues to be used to determine data access requirements within the Secondary Uses Service for Commissioning Data Set version 6-2 submissions.
• 
  
• Note that if two recipients are identical for example, the ORGANISATION CODE (RESIDENCE RESPONSIBILITY) may be the same as the ORGANISATION CODE (CODE OF COMMISSIONER), only one entry for that ORGANISATION should be made for that recipient.
  
• Specialised service ACTIVITY commissioned by a regional Specialised Commissioning Hub should include their ORGANISATION CODE as a CDS COPY RECIPIENT IDENTITY.

Commissioning Data Set Addressing Grid for users of Commissioning Data Set version 6-2

Commissioning Data Set Addressing Grid for users of Commissioning Data Set version 6-2

Notes:

Key to population codes:

M*: This Data Element is mandatory in the CDS-XML schema. Submissions will not flow if this Data Element is absent
O*: This Data Element is optional

** Specialised Services and Other Commissioning Consortia Service Agreements include SERVICES that are commissioned by regional Specialised Commissioning Groups and local arrangements for commissioning ACTIVITY through shared service ORGANISATIONS.

The Commissioning Data Sets have notation to identify the business and/or processing rules which apply to individual Data Elements.  This notation appears in the Rules column of the Commissioning Data Sets details page. 

Population Validation

Population Validation

All Data Elements are subject to length validation.  Some Data Elements are also subject to format and content validation against a list of permitted values defined in the NHS Data Model and Dictionary. The value lists are held on the Attribute which the Data Element is based on, plus default codes which are held on the Data Element itself.

Business Rules

Business Rules

Some Data Elements are subject to additional Business Rules as indicated below:

• Prefix H = Healthcare Resource Group Business Rules.
• Prefix I = CDS-XML Schema notes, anomalies and issues.
• Prefix N = NHS Data Standards and Policy Rules
• Prefix S = Secondary Uses Service Business Rules

It is acknowledged that the Secondary Uses Service processes can be directed to create duplicate Commissioning Data Set records and on occasion to wrongly delete records. This may occur if data senders do not correctly apply the rules associated with the Commissioning Data Set Submission Protocol such as the protocol dates and the sender and recipient codes applicable to interchanges.

It is not advisable to mix the use of Bulk and Net protocol for Commissioning Data Set submissions for the same sender ORGANISATION and ORGANISATION SITE as duplication or wrongful record deletion can occur.

Anticipating possible causes of duplication

Anticipating possible causes of duplication
Data senders can take steps to avoid Commissioning Data Set duplication in the Secondary Uses Service by anticipating situations which could result in changes to the data applied in the Commissioning Data Set Submission Protocols and by taking action to ensure that key data items that need to be retained consistently in the lifetime of the Commissioning Data Set record are not changed.

Data senders should note the following guidance on situations where extra vigilance is needed and action to ensure consistent and correct application of data elements used in net or bulk protocols.

New Patient Care or other local systems used in Commissioning Data Set processing

New Patient Care or other local systems used in Commissioning Data Set processing
When a new PATIENT care system or other system is implemented or used for preparing the Commissioning Data Set output data, it must be ensured that the Commissioning Data Set is generated to the appropriate specification required. The sender must ensure that any data events that may impact on key fields in the Commissioning Data Set are managed correctly.

Sub-contracting

Sub-contracting
If a provider sub-contracts healthcare services and associated Commissioning Data Set submissions to a second provider, both parties need to actively engage in coordinating their arrangements for Commissioning Data Set submissions, ensuring that Commissioning Data Set Submission Protocol rules are applied appropriately to maintain the Commissioning Data Set data integrity in the Secondary Uses Service database.

New XML Schema translation supplier

New XML Schema translation supplier
If a provider changes supplier arrangements for XML Schema translation, it is important that the new supplier is provided with the information required about the Commissioning Data Set Submission Protocols that have been used in previous Commissioning Data Set submissions in order to ensure that data integrity is maintained in the ongoing Commissioning Data Set XML Schema processes and in the Secondary Uses Service database.

The Commissioning Data Set is the basic structure used for the submission of commissioning data to the Secondary Uses Service and is designed to be capable of individually conveying many different Commissioning Data Set structures, encompassing Urgent and Emergency Care Activity, Care Professional Out-Patient Attendances, Care Professional Admitted Care Episodes.  (Elective Admission List is also defined in Commissioning Data Set version 6-2 only).

The Commissioning Data Sets have been defined in specific components known as a CDS Type.

Specific notation is used to indicate the requirements of the Commissioning Data Set XML Schema Design conditions for submission of data in the Commissioning Data Sets.

The structure of the Commissioning Data Set XML Schema is shown by the use of Data Groups and Sub Groups within those Data Groups.  For each Data Group, Sub Group and individual Data Element, the allowed cardinality at each level is also shown in the "Status" and "Repeats" columns.

The CDS Type specifications must therefore be read in this hierarchy, using the Status and Repeat conditions within the Data Groups and Sub Groups, to determine the requirements for the individual Data Elements.

Status Column Notation

Status Column Notation

The Notation used for the "STATUS" column is as follows:

Repeats Column Notation

Repeats Column Notation

Examples of the Notation used for the "REPEATS" column are as follows:

Rules Column Notation

Rules Column Notation

An entry in the "Rules" column shows that a specific Rule applies to submission of an individual Data Element.

The meaning of these Rules can be found in Commissioning Data Set Business Rules.

Notation Examples

The following are examples of some common scenarios:

The Commissioning Data Sets (CDS) are maintained and developed by NHS England, in accordance with the needs of the NHS and the Department of Health and Social Care.

Commissioning Data Sets form the basis of data on ACTIVITY carried out by ORGANISATIONS reported centrally for monitoring and payment purposes. They support the current Healthcare Resource Group (HRG) version for calculation of payment to trusts and monitoring of other initiatives.

Requests for changes to the Commissioning Data Sets should be submitted via email to enquiries@nhsdigital.nhs.uk, stating "Commissioning Data Sets" in the subject line.

For further information on Commissioning Data Sets, see:

• Commissioning Data Sets Overview
• Commissioning Data Set Version 6-2 Type List
• Commissioning Data Set Version 6-3 Type List
• Commissioning Data Set Versions

• Commissioning Data Set Addressing Grid
• Commissioning Data Set Business Rules
• Commissioning Data Set Data Duplication
• Commissioning Data Set Mandated Data Flows
• Commissioning Data Set Notation
• Commissioning Data Set Submission and Organisation Mergers
• Commissioning Data Set Submission Protocol
• Referral To Treatment Clock Stop Administrative Event
• Security Issues and Patient Confidentiality

• CDS XML Schema:

• CDS XML Schema:

• Commissioning Data Set XML Schema Overview
• Commissioning Data Set XML Schema Design
• Commissioning Data Set XML Schema Version Numbering
• Commissioning Data Set XML Schema Documentation
• XML Schema TRUD Download

• XML Schema Constraints:

• XML Schema Constraints:

• Commissioning Data Set Version 6-2 XML Schema Constraints
• Commissioning Data Set Version 6-2-3 XML Schema Constraints
• Commissioning Data Set Version 6-3 XML Schema Constraints

Introduction

The purpose of the Commissioning Data Sets is to enable conformant health ACTIVITY information to be generated, independent of the ORGANISATION or system that maintains it. This enables health CARE PROFESSIONALS to measure and compare the delivery and quality of care provided and to support them in sharing information with other health professionals and ORGANISATIONS.

Commissioning Data Sets currently support the following ACTIVITIES:

• monitoring and managing NHS SERVICE CONTRACTS
• developing commissioning plans
• supporting the National Tariff Payment System
• underpinning clinical governance
• understanding the health needs of the population
• reporting waiting time measurement

Information on care provided for all PATIENTS by Health Care Providers (both NHS and Independent Sector Healthcare Providers for NHS PATIENTS only) must be submitted to the Secondary Uses Service according to the Commissioning Data Set Mandated Data Flows guidelines.

The Department of Health and Social Care requires accurate data for all PATIENTS admitted, treated as out-patients or treated as Urgent and Emergency Care Activity by Health Care Providers, including PATIENTS receiving private treatment. The Commissioning Data Sets also includes NHS-funded PATIENTS treated electively in the independent sector and overseas.

Referral To Treatment Clock Stop Administrative Events may also flow using the CDS V6-2 Type 020 - Outpatient Commissioning Data Set or CDS V6-3 Type 020 - Outpatient Commissioning Data Set. This allows the Secondary Uses Service to build accurate PATIENT PATHWAYS for the reporting of waiting time measurement.

Where possible the definitions and items collected in the Healthcare Operational Data Flows (Acute) Data Sets are aligned with those collected in the Commissioning Data Set V6.3.

CDS Types

CDS Types

The Commissioning Data Sets are the basic structure used for the submission of commissioning data to the Secondary Uses Service and is designed to be capable of individually conveying many different Commissioning Data Set structures encompassing Urgent and Emergency Care Activity, Care Professional Out-Patient Attendances, and Care Professional Admitted Care Episodes for both CDS version 6-2 and CDS version 6-3.    CDS version 6-2 also supports the submission of Future Out-Patient Attendances and Elective Admission List data.

Further Information

Further Information

Further guidance material for submission of data to the Secondary Uses Service can be found at: Secondary Uses Service (SUS Guidance).

The Commissioning Data Sets submitted by providers carry information to determine the update method to be used by the Secondary Uses Service in order to update the national database.

These update rules are known as the Commissioning Data Set Submission Protocol and the set of data controls used to indicate this are carried in the Commissioning Data Set Transaction Header Group which must be present and correct in every CDS Type submitted to the Secondary Uses Service.

Net Change:

Net Change:
Net Change processes are managed by specific data settings as defined in the CDS V6-2 Type 005N - Commissioning Data Set Transaction Header Group - Net Change Protocol / CDS V6-3 Type 005N - Commissioning Data Set Transaction Header Group - Net Change Protocol / ECDS V4 Type 005N option of the CDS Transaction Header Group. The Secondary Uses Service uses the following data to manage the database:

• CDS SENDER IDENTITY/ORGANISATION IDENTIFIER (CDS SENDER)
• CDS UNIQUE IDENTIFIER
• CDS APPLICABLE DATE
• CDS APPLICABLE TIME

Note that CDS SENDER IDENTITY is used for CDS V6-2. ORGANISATION IDENTIFIER (CDS SENDER) is used for CDS V6-2-3 Type 011 - Emergency Care Commissioning Data Set / Emergency Care Data Set Version 4 and CDS Version 6-3 onwards. 

Each CDS Type must have a CDS UNIQUE IDENTIFIER which must be uniquely maintained throughout the life of that Commissioning Data Set record. This is a particular consideration where mergers and/or healthcare systems are changed or upgraded, see Commissioning Data Set Submission and Organisation Mergers. Any change to the CDS UNIQUE IDENTIFIER during the "lifetime" of a Commissioning Data Set record will almost certainly result in a duplicate record being lodged in the Secondary Uses Service database.

A Commissioning Data Set record delete transaction must be sent to the Secondary Uses Service database when any previously sent Commissioning Data Set record requires deletion/removal, for example to reflect Commissioner changes etc. 

Where CDS UPDATE TYPE 1 is required (delete/cancellation), an empty XML element called 'Delete Transaction' can be used instead of submitting he original CDS Type record, after the CDS V6-2 Type 005N - CDS Transaction Header Group - Net Change Protocol / CDS V6-3 Type 005N - Commissioning Data Set Transaction Header Group - Net Change Protocol. See the CDS V6-2 or CDS V6-3 XML Schema Release Notes which can be downloaded via the XML Schema TRUD Download page.

The CDS APPLICABLE DATE and CDS APPLICABLE TIME must be used to ensure that all Commissioning data is updated in the Secondary Uses Service database in the correct chronological order.

The CDS SENDER IDENTITY/ORGANISATION IDENTIFIER (CDS SENDER) must not change during the lifetime of the CDS data.  This is particularly significant for multiple and/or merged ORGANISATIONS, and for those services who submit data on behalf of another NHS Trust, NHS Foundation Trust or Independent Sector Healthcare Provider.

Bulk Replacement

Bulk Replacement
Bulk Replacement processes are managed by specific data settings as defined in the CDS V6-2 Type 005B - Commissioning Data Set Transaction Header Group - Bulk Update Protocol/CDS V6-3 Type 005B - Commissioning Data Set Transaction Header Group - Bulk Update Protocol option of the CDS Transaction Header Group. The Secondary Uses Service uses the following data to manage the database:

• CDS SENDER IDENTITY/ORGANISATION IDENTIFIER (CDS SENDER)
• CDS BULK REPLACEMENT GROUP CODE
• CDS EXTRACT DATE
• CDS EXTRACT TIME
• CDS REPORT PERIOD START DATE
• CDS REPORT PERIOD END DATE

Note that CDS SENDER IDENTITY is used for CDS V6-2. ORGANISATION IDENTIFIER (CDS SENDER) is used for CDS V6-2-3 Type 011 - Emergency Care Commissioning Data Set / ECDS V4 and CDS V6-3 onwards.

Every CDS Type must be submitted using the correct CDS BULK REPLACEMENT GROUP CODE.

The CDS REPORT PERIOD START DATE and the CDS REPORT PERIOD END DATE, (i.e. the effective date period), must be valid and consistent, and reflect the dates relevant to the Commissioning data contained in the interchange.

The CDS SENDER IDENTITY/ORGANISATION IDENTIFIER (CDS SENDER) must not change during the lifetime of the Commissioning Data Set record. This is particularly significant for multiple and/or merged ORGANISATIONS, and for those services who submit data on behalf of another ORGANISATION.

For submissions of CDS V6-2, the CDS PRIME RECIPIENT IDENTITY is Mandatory for submission in the CDS Type 005B (CDS Transaction Header Group - Bulk Update Protocol) and CDS Type 005N (CDS Transaction Header Group - Net Change Protocol). However, it no longer forms part of the key for the process of determining duplicate records within the Secondary Uses Service. Note that the CDS PRIME RECIPIENT IDENTITY continues to be used to determine data access requirements within the Secondary Uses Service for Commissioning Data Set version 6-2 submissions.  For Commissioning Data Set version 6-3 and CDS V6-2-3 Type 011 - Emergency Care Commissioning Data Set / Emergency Care Data Set Version 4, data element ORGANISATION IDENTIFIER (CDS RECIPIENT) is used for this purpose.

If it is necessary to change any of this data during the lifetime of a Commissioning Data Set record, then the Secondary Uses Service (SUS) Service Desk should be contacted for advice. See the NHS England website at: Secondary Uses Service (SUS).

It is strongly advised that users of the Bulk Replacement Mechanism maintain a correctly generated CDS UNIQUE IDENTIFIER within the Commissioning data. This will establish a migration path towards the use of the Net Change Mechanism and will also then minimise the risk of creating duplicate Commissioning Data Set data.

Sub contracting

Sub contracting
If a Health Care Provider sub-contracts healthcare provision and its associated Commissioning Data Set submission to a second ORGANISATION (eg a different Health Care Provider or a Shared Services Organisation), arrangements to submit the Commissioning Data Set data must be made locally to ensure that only one ORGANISATION sends the Commissioning Data Set data to the Secondary Uses Service.

If the second ORGANISATION wishes to add other Commissioning data to the Secondary Uses Service database to that already submitted by the first ORGANISATION, both parties need to ensure that a different CDS SENDER IDENTITY/ORGANISATION IDENTIFIER (CDS SENDER) is used.

Note: Data sent using the same CDS SENDER IDENTITY/ORGANISATION IDENTIFIER (CDS SENDER) by two different parties will most likely overwrite each other's data in the Secondary Uses Service database. Further advice can be obtained from the Secondary Uses Service (SUS) Service Desk, see the NHS England website at: Secondary Uses Service (SUS) Guidance.

Users should be aware of how the 15 character code of their CDS INTERCHANGE SENDER IDENTITY (also known as the EDI Address) is created. This may depend on how their XML interface solution has been set up. It may not be possible to rely on a change to the ORGANISATION CODE (CODE OF PROVIDER)/ORGANISATION IDENTIFIER (CODE OF PROVIDER) in order to change the CDS INTERCHANGE SENDER IDENTITY should this become necessary.

The Commissioning Data Set versions since 2001.

Current versions:

Current versions:

• April 2021: CDS Version 6-2-3
• April 2022: CDS Version 6-3 Type List

Retired versions:

Retired versions:

• November 2012 to 1 March 2023: CDS Version 6-2-2
• October 2017 to April 2022: CDS Version 6-2-1
• November 2008 to June 2015: CDS Version 6-1 Type List
• December 2007 to November 2012: CDS Version 6-0
• April 2005 to March 2008: CDS Version NHS005 Type List
• April 2001 to March 2005: CDS Version NHS003 and 4 Type List

The XML Schemas and supporting information can be downloaded from Technology Reference Update Distribution (TRUD) at: NHS Data Model and Dictionary XML Schemas.

The use of XML was mandated by the e-Government Interoperability Framework (e-GIF) programme as the standard to be used for messaging by government organisations and was adopted by the NHS for the submission of Commissioning Data Set data to the Secondary Uses Service.

XML Schema Standards

XML Schema Standards
The overall standards applied and supported by the schema are:

• W3C schema standards
• W3C schema standards
• e-Government Interoperability Framework (e-GIF)
• e-GOV Best Practice guidelines for XML Schema
• The NHS Data Model and Dictionary

Note:
e-GIF and the Government Data Standards Catalogue have been archived and are available for reference only.

XML Schema Naming Conventions

XML Schema Naming Conventions
These are in CamelCase reflecting recommended e-GOV guidelines for best practice. Wherever possible, schema data item names are compliant (or intuitively identifiable) with the NHS Data Model and Dictionary data naming conventions.

XML Schema Components

XML Schema Components
The schema consists of the following components:

• The CDS XML Message Root
• The CDS XML Standard Data Structures
• The CDS XML Standard Data Elements
• CDS Type Sub-Schemas

The XML Schema Root

The XML Schema Root
The schema root is the control section of the schema and uses the "XML Include" technique to call schema sub-components:

• The Standard Data Structures
• The Standard Data Elements
• All CDS Type sub-component schemas, including the Commissioning Data Set Headers and Trailers

• SchemaVersion
• SchemaDate

XML Schema Component: Standard Data Structures

XML Schema Version 6-0 introduced standard data structures which are invoked from the CDS Type sub-component schemas. This simplifies the management and definition of data structures and eliminates (as far as is possible) the multiple definitions of the many common structures used across the CDS Type components. It also helps to eliminate naming and spelling inconsistencies.

This implementation of the schema does not enforce the sequence of data elements within its data structures (nor its data structures within the schema), nor is it foreseen that this will be enforced in future. For ease of understanding, users are advised to implement the structure sequences as published.

In general, the restraints on the permitted occurrences of data groups have been removed and in most cases, unbounded occurrences of iterating data structures are supported. The NHS Data Model and Dictionary defines the actual requirements for the use of NHS data.

XML Schema Component: Standard Data Elements

XML Schema Component: Standard Data Elements
XML Schema data items are defined with _Type suffixes and usually refer to a standard list of XML data types which are usually qualified with an enumeration list to reflect the NHS Data Standards as published in the NHS Data Model and Dictionary.

Schema Component: XML Attributes

Schema Component: XML Attributes
XML Attributes are used (sparingly) to enforce certain logical data and structure relationships, an example being to determine the type of Critical Care Period data being carried.

The use of XML was mandated by the e-Government Interoperability Framework (e-GIF) programme as the standard to be used for messaging by government organisations and accordingly this has been adopted by the NHS.

Note:
e-GIF and the Government Data Standards Catalogue have been archived and are available for reference only.

For the most part, the XML Schema applies the data specifications as authorised by the NHS and documented in the NHS Data Model and Dictionary.

The Issued Documentation

The Issued Documentation
The following XML Schema artifacts are issued:

• The XML Schema Files (generated using ALTOVA XMLSPY ©)
  The XML Schema files consist of a series of interpretable XML/HTML statements which define the data structures and content rules for the use of the message. User systems use the XML Schema to either populate or interpret an 'XML Schema instance' that is the resultant XML formatted message file which carries the data.

The XML Schema therefore represents the 'design' of the message and it may be necessary therefore to interpret and understand the information inherent in the XML Schema file code.

• The XML Schema Documentation (generated using ALTOVA XMLSPY ©)
  These files are generated using XMLSPY software and may be read in any browser, e.g. Microsoft Edge©. The files consist of a 'root' entry HTML formatted file and a (usually) large number of supporting .png graphic files used by the root HTML.

This documentation enables useful "drill down" functions for investigating structures and data items, but these features are not as powerful as when using a full XML Schema editor (see below).

Most browsers will support printing and thus the XML Schema details can be printed as required but users are warned that browser based prints often generate a large number of pages.

The CDS XML Schema generates approximately 450+ pages of details, printing is therefore not advised.

• The XML Schema Release Notes
  This is a pdf document identifying the changes applied to the XML Schema release, from the previous release.
  References to Information Standards Notices and other technical change requirements are detailed.

Reading XML Schema

Reading XML Schema

It is recommended that XML Schemas are read using an XML interpreter (such as ALTOVA XMLSPY ©), many of these are freely available on the internet.

XML Schema technicians may prefer to use such software to examine XML Schemas more deeply as the interactive facilities provided are generally more powerful than browsing the XML/HTML supplied Schema code.

The use of XML was mandated by the e-Government Interoperability Framework (e-GIF) programme as the standard to be used for messaging by government organisations and was adopted by the NHS for the submission of Commissioning Data Set data to the Secondary Uses Service.

The CDS XML Schema is supported and applied in the Secondary Uses Service to enforce a nationally agreed data specification and thus help protect the data quality and integrity of the data submitted to and stored within the Secondary Uses Service.

It should be noted that after accepting the XML Schema interchange data, the Secondary Uses Service then applies further logical data validations and may identify and report further data conditions.

For the most part, the XML Schema applies the data specifications as authorised by the NHS and documented in the NHS Data Model and Dictionary. However, as the NHS Data Model and Dictionary is updated on a continuous time basis and XML Schemas may be less dynamic and updated on a longer time cycle, there may be subtle differences in the data specifications applied in the XML Schema. For example, additional National Codes may be supported in one version of the Commissioning Data Set XML Schema but not in earlier versions. Where this is the case, information relating to the supported National Codes can be found on the CDS Version 6-2 XML Schema Constraints / CDS Version 6-3 XML Schema Constraints page and associated Attributes and/or Data Elements.

Additionally an XML Schema may deliberately retain historic National Codes as well as supporting the new National Codes in order to enable NHS users to be able to process historic data.

XML Schema Standards

XML Schema Standards
The overall standards applied and supported by the XML Schema are:

• W3C schema standards
• e-Government Interoperability Framework (e-GIF)
• e-GOV Best Practice guidelines for XML Schema
• The NHS Data Model and Dictionary

Note:
e-GIF and the Government Data Standards Catalogue have been archived and are available for reference only.

XML Schema Naming Conventions

These are in CamelCase as accepted best practice. Wherever possible, XML Schema data item names are compliant (or intuitively identifiable) with the NHS Data Model and Dictionary naming conventions.

XML Schema Documentation

XML Schema Documentation
XML Schema documentation usually consists of several related publications:

• Information Standards Notices (ISN) issued for NHS business, process and definition changes; these will usually include the Data Sets, Data Element definitions etc.
• Information Standards Notices or Data Dictionary Change Notices issued to authorise the CDS XML Schema itself
• The CDS XML Schema Release Notes which provides a technical overview of the release (in pdf)
• The XMLSPY© generated XML Schema Documentation which is a large collection of HTML files.

XML Schema Components: Schema Root

The XML Schema root is the control section of the XML Schema and is the only entry point and uses the "XML Include" technique to call all XML Schema sub components:

• The Standard Data Elements
• The Standard Data Structures
• All sub-component XML Schemas for CDS Types including the Commissioning Data Set Headers and Trailers

The XML Schema Version numbering format used in the Commissioning Data Sets.

The CDS XML Schema Version Number Format

The CDS XML Schema Version Number Format

The use of XML was mandated by the e-Government Interoperability Framework (e-GIF) programme as the standard to be used for messaging by government organisations and was adopted by the NHS.

Note:
e-GIF and the Government Data Standards Catalogue have been archived and are available for reference only.

The CDS XML Schema adopts version numbering techniques in line with published e-GOV best practice guidelines. All schema components are version numbered and date qualified; the following is an example of the adopted format:

CDS XML Message Root:

CDS XML Message Root:

Example: V6-0-2007-03-01 (Note that dash separators are used).
[Schema Filename] + [Major Version Number] + [Minor Version Number] + [Version Date]

The Major Version Number:

The Major Version Number:

This is incremented when fundamental change has taken place such as:

• Major addition / deletion / change of XML Schema business functionality
• Major change to the technical design of the schema
• Re-alignment of the XML Schema Version Number after cumulative changes

The Minor Version Number:

The Minor Version Number:

This is incremented for all XML Schema changes not warranting a Major Version Number increment (as above).
Examples are:

• Minor changes to XML Schema business functionality
• Minor changes to the XML Schema data structures that are not upwardly compatible*
• Addition and/or deletion of data items that are not upwardly compatible*
• Changes to data item facet definitions that are not upwardly compatible*

Version Date:

Version Date:

This may be adjusted as a defined reference point for a no risk XML Schema release to reflect minor changes and corrective releases.
Examples are:

• Minor changes to the XML Schema data structures that are upwardly compatible* for instance the addition of an optional data item.
• Changes to data item facet definitions that are upwardly compatible* for instance the addition (but not the deletion) of code values to a data item enumeration list.
• Interim development versions, released for information only

* Upwardly Compatible:

* Upwardly Compatible:Minor changes and adjustments to the XML Schema which introduce little or no risk of increased data rejection are deemed upwardly compatible.

Minor changes and adjustments to the XML Schema which introduce little or no risk of increased data rejection are deemed upwardly compatible.

For example, corrective adjustments, which align the XML Schema to the authorised NHS Data Standards as published in the NHS Data Model and Dictionary often fall within this category.

The XML Schema Date:

The XML Schema Date:

All XML Schema releases have a designated SchemaDate XML Attribute.

XML Schema Version Control - The Schema Root:

XML Schema Version Control - The Schema Root:

The schema root is the single entry point to the XML Schema and XML Attributes for the following are validated:

• SchemaVersion
• SchemaDate

Guidance Notes relating to MAIN SPECIALTY CODE and TREATMENT FUNCTION CODE.

For further information regarding the definition and use of MAIN SPECIALTY see the attribute MAIN SPECIALTY CODE.

For further information regarding the definition and use of TREATMENT FUNCTION see the attribute TREATMENT FUNCTION CODE.

Note:

• New National Codes for MAIN SPECIALTY CODE and TREATMENT FUNCTION CODE were introduced from 2 April 2020 as part of the update to the DCB0028: Treatment Function and Main Specialty Standard. Submission of these codes for the Commissioning Data Sets is only possible where the healthcare provider has updated their CDS-XML schema version to CDS-XML version 6-2-0. Users of the original CDS-XML schema version 6-2 will be unable to submit the new codes introduced in the release of DCB0028: Treatment Function and Main Specialty Standard in April 2020 or the addendum to DCB0028 released in January 2021 to add a new TREATMENT FUNCTION CODE to represent Post-COVID-19 Syndrome Services.

Table 1 Main Specialty codes

Table 1 Main Specialty codes

Notes:

Table 2 Treatment Function codes

Table 2 Treatment Function codes

Notes:

Notes:

National Cancer Waiting Times Monitoring Data Set: Concept of Operation and Patient Pathway Scenarios.

National Cancer Waiting Times Monitoring Data Set: Concept of Operation and Patient Pathway Scenarios.

The National Cancer Waiting Times Monitoring Data Set is a generic data set designed to support the monitoring of waiting times for a variety of different pathways of cancer care. For the purpose of this data collection cancer is defined using the International Classification of Diseases (ICD) codes. The full list of International Classification of Diseases (ICD) diagnosis codes is available on the NHS England website at: Cancer Waiting Times.

Collection and submission of the National Cancer Waiting Times Monitoring Data Set is to be managed according to the maximum waiting time and information requirements of the pathway of care for each individual PATIENT. These requirements for providers of cancer SERVICES to return data to the Cancer Waiting Times Database are defined using different scenarios.

Scenarios

• Scenario 1a:
  The Health Care Provider where the PATIENT is first seen following a REFERRAL REQUEST with PRIORITY TYPE 'Two Week Wait', or where an urgent referral is from an NHS Cancer Screening Programme, and where the PATIENT has not had a Decision To Treat, has not had the diagnosis outcome communicated, and the PATIENT has not been excluded from the Cancer Faster Diagnosis Pathway. No inter-provider transfers are in progress.
• Scenario 1b:
  The Health Care Provider where the PATIENT is first seen following a REFERRAL REQUEST with PRIORITY TYPE 'Two Week Wait', or where an urgent referral is from an NHS Cancer Screening Programme, and where the PATIENT has not had a Decision To Treat, has had the diagnosis outcome communicated, and the PATIENT has not been excluded from the Cancer Faster Diagnosis Pathway. No inter-provider transfers are in progress.
• Scenario 1c:
  The Health Care Provider where the PATIENT is first seen following a direct access diagnostic test result that suggested an urgent suspected cancer referral with PRIORITY TYPE 'Two Week Wait' was required, and where a locally agreed escalation process to secondary care has been followed (as defined in National Cancer Waiting Times Monitoring Data Set - A Guide), where the PATIENT has not had the Decision To Treat, and has not had the diagnosis outcome communicated, and the PATIENT has not been excluded from the Cancer Faster Diagnosis Pathway. No inter provider transfers are in progress.
• Scenario 1d:
  The Health Care Provider where the PATIENT is first seen following a REFERRAL REQUEST with PRIORITY TYPE 'Two Week Wait', or where an urgent referral is from an NHS Cancer Screening Programme, and where the PATIENT has had the Decision To Treat, has had the diagnosis outcome communicated, and the PATIENT has not been excluded from the Cancer Faster Diagnosis Pathway. No inter-provider transfers are in progress.
• Scenario 1e:
  The Health Care Provider where the PATIENT is first seen following a REFERRAL REQUEST with PRIORITY TYPE 'Two Week Wait', or where an urgent referral is from an NHS Cancer Screening Programme, and where the PATIENT has not had a Decision To Treat, has not had the diagnosis outcome communicated, and the PATIENT has not been excluded from the Cancer Faster Diagnosis Pathway. The Health Care Provider sends the PATIENT to another Health Care Provider, that is, makes an inter-provider transfer.
• Scenario 1f:
  The Health Care Provider receiving an inter-provider transfer of a PATIENT, where the PATIENT is first seen at a different Health Care Provider, and where the PATIENT has not had a Decision To Treat, has not had the diagnosis outcome communicated, and the PATIENT has not been excluded from the Cancer Faster Diagnosis Pathway. The Health Care Provider then subsequently sends the PATIENT to another Health Care Provider, that is, makes a further inter-provider transfer.
• Scenario 1g:
  The Health Care Provider where the PATIENT is first seen following a REFERRAL REQUEST with PRIORITY TYPE 'Two Week Wait', or where an urgent referral is from an NHS Cancer Screening Programme, and where the PATIENT has not had a Decision To Treat, has not had the diagnosis outcome communicated, and the PATIENT has been excluded from the Cancer Faster Diagnosis Pathway. No inter-provider transfers are in progress.
• Scenario 2a:
  The Health Care Provider where the PATIENT receives First Definitive Treatment for cancer following a REFERRAL REQUEST with PRIORITY TYPE 'Two Week Wait', or where an urgent referral is from an NHS Cancer Screening Programme, and where the PATIENT has had the Decision To Treat, has had the diagnosis outcome communicated, and the PATIENT has not been excluded from the Cancer Faster Diagnosis Pathway. No inter-provider transfers are in progress.
• Scenario 2b:
  The Health Care Provider where the PATIENT receives First Definitive Treatment for cancer following an inter-provider transfer, and where the PATIENT has had the Decision To Treat, and has had the diagnosis outcome communicated, and the PATIENT has not been excluded from the Cancer Faster Diagnosis Pathway.
• Scenario 3:
  The Health Care Provider where the PATIENT receives second or subsequent treatment for cancer following a REFERRAL REQUEST with PRIORITY TYPE 'Two Week Wait', or where an urgent referral is from an NHS Cancer Screening Programme. No inter-provider transfers are in progress.
• Scenario 4:
  The Health Care Provider where the PATIENT receives First Definitive Treatment for cancer following a consultant upgrade onto a 62 day PATIENT PATHWAY. No inter-provider transfers are in progress.
• Scenario 5:
  The Health Care Provider where the PATIENT receives second or subsequent treatment for cancer following a consultant upgrade onto a 62 day PATIENT PATHWAY. No inter-provider transfers are in progress.
• Scenario 6:
  The Health Care Provider where the PATIENT receives First Definitive Treatment for cancer following a REFERRAL REQUEST from another SOURCE OF REFERRAL FOR OUT-PATIENTS or a different PRIORITY TYPE. No inter-provider transfers are in progress.
• Scenario 7:
  The Health Care Provider where the PATIENT receives second or subsequent treatment for cancer following a REFERRAL REQUEST from another SOURCE OF REFERRAL FOR OUT-PATIENTS or a different PRIORITY TYPE. No inter-provider transfers are in progress.

The columns in the table below show which data items are required for a range of health care scenarios:

Data Set Notation:

Data Set Notation:

• M = Mandatory: the Standard Contract Schedule 5 requires NHS provider ORGANISATIONS to submit this information on a monthly basis. NHS England require the data to be submitted a number of working days after the end of each month or quarter. This submission schedule is set out on the NHS England website at: Cancer Waiting Times Data Collection (CWT).
• M* = Mandatory if applicable: the Standard Contract Schedule 5 requires NHS provider ORGANISATIONS to submit this information on a monthly basis, where collection of the item was applicable to them. NHS England require the data to be submitted a number of working days after the end of each month or quarter. This submission schedule is set out on the NHS England website at: Cancer Waiting Times Data Collection (CWT).
• O = Optional
• O* = Optional if applicable: These optional fields should only be populated if they relate to the PATIENT PATHWAY identified in the scenarios and the conditions required for their use are met.
• N/A = Not Applicable

Note: Inter-Provider Transfers:

Note: Inter-Provider Transfers:

• # First transfer involving the Health Care Provider
• ## Second transfer involving the Health Care Provider. There can be up to ten inter-provider transfers involving many ORGANISATIONS, but an individual ORGANISATION can only be involved in two transfers of a PATIENT.

Full details of the validation rules and processes are available on the NHS England website at: Cancer Waiting Times.

The OPCS Classification of Interventions and Procedures (OPCS-4) is a Fundamental Information Standard which is revised periodically.  The classification is used by Health Care Providers and national and regional ORGANISATIONS.

OPCS-4 is used to support operational and strategic planning, resource utilisation, performance management, reimbursement, research and epidemiology.  It is used by NHS suppliers to build/update software to support NHS business functions and interoperability.

The classification consists of two volumes; Tabular List and Alphabetical Index. It is accessible in the Classifications Browser at https://classbrowser.nhs.uk which also contains links to the National Clinical Coding Standards.

The classification is also available for purchase in paper format from The Stationary Office at www.tsoshop.co.uk

National information standards and data collections, such as Commissioning Data Sets requiring OPCS-4 coding should use the latest mandated version of the OPCS-4 as given in the table below:

*Tables of Coding Equivalences are issued for mapping back to previous versions and are available from Technology Reference Update Distribution (TRUD).

For further information see the NHS England website at: Terminology and Classifications.

OPCS-4 Requests Portal

OPCS-4 Requests Portal

The OPCS-4 Requests Portal allows stakeholders to submit change requests to the Terminology and Classifications Delivery Service all year round. A cut-off date for receipt of change requests for consideration in the next release is published on the Requests Portal.  Requests received after the cut-off date will be considered in a subsequent release.

For further information and access to the OPCS-4 Requests Portal, see the NHS England website at: Clinical Classifications.

High Cost Drugs and Chemotherapy Regimens

High Cost Drugs and Chemotherapy Regimens

The listings of High Cost Drugs and Chemotherapy Regimens which are mapped to OPCS-4 codes are provided as look-up tables downloadable from Delen at Publications & Resources.

This guidance explains the circumstances under which Hospital Provider Spells should close and reopen as a result of a merger or demerger, in terms of NHS Information Standards.

It specifies which ORGANISATION CODES / ORGANISATION IDENTIFIERS should be used for Hospital Provider Spells which must be closed and reopened for:

• DISCHARGE DESTINATION etc, for the closing Hospital Provider Spell and
• SOURCE OF ADMISSION etc, for the new Hospital Provider Spell.

• A Hospital Provider Spell is provided by one ORGANISATION acting as a Health Care Provider. This means that the Hospital Provider Spell is linked to the ORGANISATION CODE / ORGANISATION IDENTIFIER of the Health Care Provider.
• If the ORGANISATION CODE / ORGANISATION IDENTIFIER changes, the spell must end and another begin with the new ORGANISATION CODE / ORGANISATION IDENTIFIER.
• If the Hospital Provider Spell does end, the Care Professional Admitted Care Episode within the Hospital Provider Spell must also end.

  The following scenarios explain what this means in terms of ORGANISATION mergers or demergers. Note that these assume that nothing changes other than the fact that the ORGANISATIONS merge or demerge, e.g. the CONSULTANT stays the same, etc.

Mergers

• Trust A merges with Trust B to produce Trust C, which has a new ORGANISATION CODE / ORGANISATION IDENTIFIER.
  • The ORGANISATION CODE / ORGANISATION IDENTIFIER will change for both Trust A and B.
  • Therefore Hospital Provider Spells in both Trust A and B should close, and new Hospital Provider Spells should be opened using the new ORGANISATION CODE / ORGANISATION IDENTIFIER for Trust C.
• Trust A merges with Trust B to produce an ORGANISATION which uses Trust A's ORGANISATION CODE / ORGANISATION IDENTIFIER.
  • For those Hospital Provider Spells in Trust A, the ORGANISATION CODE will not change. Therefore Trust A's Hospital Provider Spells should not be closed just as a result of the merger. However, for Trust B the ORGANISATION CODE / ORGANISATION IDENTIFIER will change.
  • Therefore Hospital Provider Spells in Trust B should close, and new Hospital Provider Spells should be opened using the new ORGANISATION CODE / ORGANISATION IDENTIFIER for Trust A.

Demergers

• Trust A splits into Trust B and Trust C, both of which have a new ORGANISATION CODE / ORGANISATION IDENTIFIER.
  • The ORGANISATION CODE / ORGANISATION IDENTIFIER will change for both Trust B and C.
  • Therefore all Hospital Provider Spells in Trust A should close, and new Hospital Provider Spells should be opened in Trust B and C using the new ORGANISATION CODES / ORGANISATION IDENTIFIERS for each.
• Trust A splits into Trust B and C. Trust B retains Trust A's ORGANISATION CODE / ORGANISATION IDENTIFIER and Trust C is issued with a new one.
  • The ORGANISATION CODE / ORGANISATION IDENTIFIER for Hospital Provider Spells in Trust A which are taken over by Trust B will not change.
  • Therefore they should not be closed just as a result of the merger.
  • However, Trust A's Hospital Provider Spells which are taken over by Trust C should close, and new Hospital Provider Spells should be opened using the new ORGANISATION CODE / ORGANISATION IDENTIFIER for Trust C.

If Hospital Provider Spells are to be closed and reopened only as a result of Organisation Mergers or demergers, for most cases the codes below should be used.

• The CLOSED Hospital Provider Spell

DESTINATION OF DISCHARGE

This depends on the type of WARD the PATIENT is in, but will be either:

• 51     NHS other Hospital Provider - WARD for general PATIENTS or the younger physically disabled
• 52     NHS other Hospital Provider - WARD for maternity PATIENTS or Neonates
• 53     NHS other Hospital Provider - WARD for PATIENTS who are mentally ill or have Learning Disabilities

METHOD OF DISCHARGE

• 1   PATIENT discharged on clinical advice or with clinical consent

• The REOPENED Hospital Provider Spell

METHOD OF ADMISSION

• 81     Transfer of any admitted PATIENT from other Hospital Provider other than in an emergency

Note that this ADMISSION METHOD is classed under "Other Admission". It is not elective and the PATIENT does therefore not have an entry on an Elective Admission List.

ADMISSION SOURCE

Again, this depends on the type of WARD the PATIENT is in, but will be either:

• 51     NHS other Hospital Provider - WARD for general PATIENTS or the younger physically disabled or Emergency Care Department
• 52     NHS other Hospital Provider - WARD for maternity PATIENTS or Neonates
• 53     NHS other Hospital Provider - WARD for PATIENTS who are mentally ill or have Learning Disabilities

REFERRER CODE

This will be the referrer to the Hospital Provider Spell within which the PATIENT was receiving care before the merger, i.e. the "original" Hospital Provider Spell.

Guidance for Merging Organisations to support Sending of Commissioning Data Sets to the Secondary Uses Service

Guidance for Merging Organisations to support Sending of Commissioning Data Sets to the Secondary Uses Service

• The Secondary Uses Service have published information regarding issues that may affect the approach to submitting data to the Secondary Uses Service.
• The guidance is available on the NHS England website at: Secondary Uses Service (SUS) Guidance: Sending data.

Data senders are directly responsible for the integrity of the data they submit. This means that data senders must not flow legally restricted or identifiable information using data items that are not designed for this purpose.

• A. Removal of name and address where the NHS Number is present

A. Removal of name and address where the NHS Number is present

• From 1 April 1999, PATIENT NAME and PATIENT USUAL ADDRESS (not POSTCODE OF USUAL ADDRESS) must be removed from all Commissioning Data Sets where a valid NHS NUMBER is present. This applies to all nationally defined Commissioning Data Set data and any additional locally agreed flows from service providers to commissioning bodies.

• A valid NHS NUMBER is one that has passed the check digit calculation on entry into the source system. If an NHS NUMBER is not valid (i.e. does not conform with the check digit algorithm) then PATIENT NAMES and PATIENT USUAL ADDRESSES should not be removed, as the reliability of the NHS NUMBER will not be known.

• The NHS NUMBER STATUS INDICATOR CODE is a mandatory part of the Commissioning Data Set. PATIENT NAME and PATIENT USUAL ADDRESS should be removed when a valid NHS NUMBER is present, even if the NHS NUMBER STATUS INDICATOR CODE does not have a status of 01, Number present and verified.

  B. Sensitive data

• The NHS NUMBER STATUS INDICATOR CODE is a mandatory part of the Commissioning Data Set. PATIENT NAME and PATIENT USUAL ADDRESS should be removed when a valid NHS NUMBER is present, even if the NHS NUMBER STATUS INDICATOR CODE does not have a status of 01, Number present and verified.

B. Sensitive data

• The Human Fertilisation and Embryology Act 1990 as amended by the Human Fertilisation and Embryology (Disclosure of Information) Act 1992 imposes statutory restrictions on the disclosure of information about identifiable individuals in connection with certain infertility treatments.

• The latest approved list of codes which can be used to identify the relevant PATIENT record in which the patient-identifiable data are to be omitted from the CDS Types can be accessed via the Secondary Uses Service website.  In these cases the NHS NUMBER, LOCAL PATIENT IDENTIFIER/LOCAL PATIENT IDENTIFIER (EXTENDED), PATIENT NAMES, POSTCODE OF USUAL ADDRESS and PERSON BIRTH DATE should be omitted from the Commissioning Data Set submission.

• From Commissioning Data Set Version 6-2 onwards, records where the patient-identifiable data has been withheld should be submitted using the PATIENT IDENTITY - WITHHELD IDENTITY STRUCTURE data group in the Commissioning Data Set XML schema.  This data group allows only the NHS NUMBER STATUS INDICATOR CODE (the actual value held on source systems should be used), ORGANISATION CODE (RESIDENCE RESPONSIBILITY)/ORGANISATION IDENTIFIER (RESIDENCE RESPONSIBILITY) and WITHHELD IDENTITY REASON to flow.  The WITHHELD IDENTITY REASON allows Health Care Providers to inform their Commissioners why a record has been anonymised.  Note that the same rules apply to the additional PATIENT IDENTITY structures relating to Mother and Baby in the Delivery and Birth CDS types.

• Other statutory restrictions on the disclosure of PATIENT information do not prohibit the disclosure to individuals involved with the treatment and prevention of certain specific diseases (HIV/AIDS and venereal diseases) in the population.

• All records containing patient identifiable information, other than those covered by the Sensitive Data section, should be treated as sensitive. ORGANISATIONS may continue to exchange records containing NHS NUMBER, POSTCODE OF USUAL ADDRESS and PERSON BIRTH DATE in these cases, but receiving ORGANISATIONS must ensure that only those staff with legitimate need have access to this information, e.g. public health departments, and strictly on a need to know basis. No-one should have unrestricted access unless fully justified in accordance with the Caldicott Principles.

• Where PATIENT level data is required for other purposes within an ORGANISATION, it should be anonymised/aggregated prior to disclosure by someone with legitimate access. If this is not practicable, local protocols defining which CDS Types are particularly sensitive (including, but not necessarily restricted to HIV/AIDS and venereal disease) agreed by the ORGANISATION Caldicott Guardian, should be put in place and identifiers stripped from these records.

• Your Caldicott Guardian will be able to advise you further on all issues relating to patient confidentiality.

• Where appropriate, further information about confidentiality is contained within the notes for individual data items.

• XML Schema Download:

• XML Schema Download:

• XML Schema TRUD Download
• 
  Data Set Constraints:

Data Set Constraints:

• Critical Care Minimum Data Set Constraints
• Devices Patient Level Contract Monitoring Data Set Constraints
• Drugs Patient Level Contract Monitoring Data Set Constraints
• Patient Level Contract Monitoring Data Set Constraints

This item is being used for development purposes and has not yet been approved.Constraints applied in the NHS Data Model and Dictionary to XML Schemas and Data Sets.

• XML Schema Constraints pages:
  • Show any differences between the data elements as described in the NHS Data Model and Dictionary and required constraints to these which have been coded into the XML Schema for a specific data set. This may include differing format/lengths of data elements, constrained lists of allowed National Codes, or additional validation to allow a constrained range of values or a specific data pattern.
• Data Set Constraints pages:
  • Show the same information, but the constraints are not applied in the XML Schema which is used to submit data (or the submission is not in XML format). In these cases the validation of allowed data would take place at the data landing stage.

XML Schema Constraints:

• Cancer Outcomes and Services Data Set XML Schema Constraints
• Commissioning Data Set Version 6-2 XML Schema Constraints
• Commissioning Data Set Version 6-2-3 XML Schema Constraints
• Commissioning Data Set Version 6-3 XML Schema Constraints
• Diagnostic Imaging Data Set XML Schema Constraints
• Electronic Prescribing and Medicines Administration Data Set XML Schema Constraints
• HIV and AIDS Reporting Data Set XML Schema Constraints

Data Set Constraints:

• Community Services Data Set Constraints
• Critical Care Minimum Data Set Constraints
• Devices Patient Level Contract Monitoring Data Set Constraints
• Drugs Patient Level Contract Monitoring Data Set Constraints
• Improving Access to Psychological Therapies Data Set Constraints
• Mental Health Services Data Set Constraints
• National Neonatal Data Set Constraints
• Patient Level Contract Monitoring Data Set Constraints
• Radiotherapy Data Set Constraints
• Systemic Anti-Cancer Therapy Data Set Constraints

XML Schemas and Release Notes can be downloaded from Technology Reference Update Distribution (TRUD).

Background:

Background:

In order to access the XML Schemas and Release Notes on Technology Reference Update Distribution (TRUD), users will be required to:

• Create a TRUD account at: TRUD: Account Creation (if an account does not currently exist. This only has to be done once to access any XML Schema)
• Log into TRUD at: TRUD: Log in
• Access NHS Data Model and Dictionary XML Schemas and subscribe to the XML Schema to be downloaded
• Accept the licence and request the subscription (an email will be sent immediately to confirm that the request has been accepted and the files can be downloaded, which avoids any delays)
• Once the "Subscription accepted" email has been received, download the zip file from NHS Data Model and Dictionary XML Schemas.

Once an XML Schema has been added to TRUD, users who have subscribed to that item will be automatically notified by email of any updates to that area, for example, new versions, retirements etc.

XML Schema Download:

XML Schema Download:

XML Schemas and Release Notes for the following Data Sets in the NHS Data Model and Dictionary can be downloaded from Technology Reference Update Distribution (TRUD) at: NHS Data Model and Dictionary XML Schemas.

• Cancer Outcomes and Services Data Set (COSDS)
• Community Services Data Set (CSDS)
• Commissioning Data Set (CDS) V6-2 and V6-2-0
• Commissioning Data Set (CDS) V6-2-3
• Commissioning Data Set (CDS) V6-3
• Diagnostic Imaging Data Set (DIDS)
• Electronic Prescribing and Medicines Administration Data Sets (EPMA)
• HIV and AIDS Reporting Data Set (HARS)
• Maternity Services Data Set (MSDS)
• National Cancer Waiting Times Monitoring Data Set (NCWTMDS)

For supplementary information on the XML Schema Publication and Download, see the NHS Data Model and Dictionary Service part of the NHS England website at: Policies: XML Schema Publication and Download guidance.

A unique identifier for a TREATMENT FUNCTION.

A TREATMENT FUNCTION CODE is recorded to report the specialised service within which the PATIENT is treated.

It is based on MAIN SPECIALTY but also includes approved sub-specialties and treatment specialties used by lead CARE PROFESSIONALS including CONSULTANTS.

TREATMENT FUNCTION, rather than the Royal College or Faculty specialty, is required on most activity returns and in the Commissioning Data Sets.

TREATMENT FUNCTION CODES should be used for all data sets/collections unless otherwise stated e.g. National Workforce Data Set uses MAIN SPECIALTY CODES.

GENERAL MEDICAL PRACTITIONER, NURSE and Allied Health Professional/ Biomedical Scientist/ Clinical Scientist ACTIVITY should be recorded against the TREATMENT FUNCTION under which the PATIENT is treated.

Joint Consultant Clinic ACTIVITY should be recorded against the TREATMENT FUNCTION which best describes the specialised service.

Assigning a Treatment Function Code:

Further information on the groupings and scope of each TREATMENT FUNCTION CODE is provided at: Main Specialty and Treatment Function Codes Table.

Assigning a Treatment Function Code:

• Assigning a TREATMENT FUNCTION CODE for a SERVICE is a decision which must be made locally. For national reporting purposes, only the TREATMENT FUNCTION CODES listed in the table below must be used.
• Recording of activity according to TREATMENT FUNCTION CODES is not on the basis of the procedure carried out, but should be allocated according to whether a specialised SERVICE exists within the Health Care Provider for that TREATMENT FUNCTION CODE, such as a CLINIC OR FACILITY.
• TREATMENT FUNCTION CODES have not been mapped to procedures or MAIN SPECIALTY.
• TREATMENT FUNCTION CODE should be assigned irrespective of the type of CARE PROFESSIONAL responsible. This is also applicable where the name of the TREATMENT FUNCTION CODE suggests it is limited for use by a particular Healthcare Profession.
• A change in TREATMENT FUNCTION CODE, but no change in responsible CARE PROFESSIONAL, does not initiate a new episode of care. For the Commissioning Data Sets, the ACTIVITY TREATMENT FUNCTION CODE reported should be that which is recorded at the CDS ACTIVITY DATE.

Note:

• New National Codes for TREATMENT FUNCTION CODE were introduced from 2 April 2020 as part of the update to the DCB0028: Treatment Function and Main Specialty Standard. Submission of these codes for the Commissioning Data Sets is only possible where the healthcare provider has updated their CDS-XML schema version to CDS-XML version 6-2-0. Users of the original CDS-XML schema version 6-2 will be unable to submit the new codes introduced in the release of DCB0028: Treatment Function and Main Specialty Standard in April 2020 or the addendum to DCB0028 released in January 2021 to add a new TREATMENT FUNCTION CODE to represent Post-COVID-19 Syndrome Services.

Further information on the groupings and scope of each TREATMENT FUNCTION CODE is provided at: Main Specialty and Treatment Function Codes Table.

National Codes:

XML Schema Constraints applied to the Cancer Outcomes and Services Data Set.

Key to XML Schema Constraint Column Headings:

Key to XML Schema Constraint Column Headings:

XML Schema Constraints:

XML Schema Constraints: