An administrative data set may be:An Administrative Data Set may be:

• essential for the safe management of care
• collected in order to administer the functions of a Health Care Provider.

This item has been retired from the NHS Data Model and Dictionary.

The last live version of this item is available in the ?????? release of the NHS Data Model and Dictionary.

Access to this version can be obtained by emailing information.standards@hscic.gov.uk with "NHS Data Model and Dictionary - Archive Request" in the email subject line.

CDS TYPES:
Accident and Emergency CDS Type:
CDS V6-1 Type 010 - Accident and Emergency CDS: Details

Care Activity CDS Types:
CDS V6-1 Type 020 - Outpatient CDS: Details
CDS V6-1 Type 021 - Future Outpatient CDS: Details

Admitted Patient Care CDS Types:
CDS V6-1 Type 120 - Admitted Patient Care - Finished Birth Episode CDS: Details
CDS V6-1 Type 130 - Admitted Patient Care - Finished General Episode CDS: Details
CDS V6-1 Type 140 - Admitted Patient Care - Finished Delivery Episode CDS: Details
CDS V6-1 Type 150 - Admitted Patient Care - Other Birth Event CDS: Details
CDS V6-1 Type 160 - Admitted Patient Care - Other Delivery Event CDS: Details
CDS V6-1 Type 170 - Admitted Patient Care - Detained and/or Long Term Psychiatric Census CDS: Details
CDS V6-1 Type 180 - Admitted Patient Care - Unfinished Birth Episode CDS: Details
CDS V6-1 Type 190 - Admitted Patient Care - Unfinished General Episode CDS: Details
CDS V6-1 Type 200 - Admitted Patient Care - Unfinished Delivery Episode CDS: Details

Elective Admission List CDS Types - End Of Period Census Types:
CDS V6-1 Type 030 - Elective Admission List - End of Period Census (Standard) CDS: Details
CDS V6-1 Type 040 - Elective Admission List - End Of Period Census (Old) CDS: Details
CDS V6-1 Type 050 - Elective Admission List - End Of Period Census (New) CDS: Details

Elective Admission List CDS Types - Event During Period Types:
CDS V6-1 Type 060 - Elective Admission List - Event During Period (Add) CDS: Details
CDS V6-1 Type 070 - Elective Admission List - Event During Period (Remove) CDS: Details
CDS V6-1 Type 080 - Elective Admission List - Event During Period (Offer) CDS: Details
CDS V6-1 Type 090 - Elective Admission List - Event During Period (Available / Unavailable) CDS: Details
CDS V6-1 Type 100 - Elective Admission List - Event During Period (Old Service Agreement) CDS: Details
CDS V6-1 Type 110 - Elective Admission List - Event During Period (New Service Agreement) CDS: Details

CDS DATA FLOW CONTROLS - (Mandatory for every CDS Interchange):
CDS V6-2 Type 001 - CDS Interchange Header
CDS V6-2 Type 002 - CDS Interchange Trailer
CDS V6-2 Type 003 - CDS Message Header
CDS V6-2 Type 004 - CDS Message Trailer

CDS Transaction Header Group - (Mandatory for every CDS TYPE):
CDS V6-2 Type 005B - CDS Transaction Header Group - Bulk Update Protocol or
CDS V6-2 Type 005N - CDS Transaction Header Group - Net Change Protocol

CDS TYPES:
Accident and Emergency CDS Type:
CDS V6-2 Type 010 - Accident and Emergency CDS

Care Activity CDS Types:
CDS V6-2 Type 020 - Outpatient CDS
CDS V6-2 Type 021 - Future Outpatient CDS

Admitted Patient Care CDS Types:
CDS V6-2 Type 120 - Admitted Patient Care - Finished Birth Episode CDS
CDS V6-2 Type 130 - Admitted Patient Care - Finished General Episode CDS
CDS V6-2 Type 140 - Admitted Patient Care - Finished Delivery Episode CDS
CDS V6-2 Type 150 - Admitted Patient Care - Other Birth Event CDS
CDS V6-2 Type 160 - Admitted Patient Care - Other Delivery Event CDS
CDS V6-2 Type 170 - Admitted Patient Care - Detained and/or Long Term Psychiatric Census CDS
CDS V6-2 Type 180 - Admitted Patient Care - Unfinished Birth Episode CDS
CDS V6-2 Type 190 - Admitted Patient Care - Unfinished General Episode CDS
CDS V6-2 Type 200 - Admitted Patient Care - Unfinished Delivery Episode CDS

Elective Admission List CDS Types - End Of Period Census Types:
CDS V6-2 Type 030 - Elective Admission List - End of Period Census (Standard) CDS
CDS V6-2 Type 040 - Elective Admission List - End Of Period Census (Old) CDS
CDS V6-2 Type 050 - Elective Admission List - End Of Period Census (New) CDS

Elective Admission List CDS Types - Event During Period Types:
CDS V6-2 Type 060 - Elective Admission List - Event During Period (Add) CDS
CDS V6-2 Type 070 - Elective Admission List - Event During Period (Remove) CDS
CDS V6-2 Type 080 - Elective Admission List - Event During Period (Offer) CDS
CDS V6-2 Type 090 - Elective Admission List - Event During Period (Available or Unavailable) CDS
CDS V6-2 Type 100 - Elective Admission List - Event During Period (Old Service Agreement) CDS
CDS V6-2 Type 110 - Elective Admission List - Event During Period (New Service Agreement) CDS

Central Return Data Sets support:

• information requirements of national and local performance management, planning and clinical governance
• assurance of the quality of health and social care services
• the monitoring of National Service Frameworks (NSFs)
• information requirements for national and local performance management, planning and clinical governance
• assurance of the quality of health and social care services.

The information in the Central Return Data Sets is transmitted at aggregate level.The information is transmitted at aggregate level.

Some of these Central Return Data Sets are transmitted to Unify2.
Unify2 is the data collection system used by the Knowledge and Intelligence team in the Department of Health to collect a wide range of performance information.Central Return Data Sets are transmitted to Unify2. Unify2 is the data collection system used by the Knowledge and Intelligence team in the Department of Health to collect a wide range of performance information.

The Unify2 homepage can be found at the following address: http://nww.unify2.dh.nhs.uk/unify/interface/homepage.aspx.Note: access to this address requires a Unify2 account and password.

Note: access to this address requires a Unify2 account and password. Any queries about the site can be addressed to the Unify2 helpdesk by:Further information can be found at:

• emailing Unify2@dh.gsi.gov.uk or
• calling your SHA User Manager from the "Contact Us" page at http://nww.unify2.dh.nhs.uk/Unify/interface/contactus.aspx.
• Unify2 homepage
• Request a new User Account
• Unify2 Contact Us page.

The Department of Health uses the information gathered from Central Returns to monitor service provision at a high level and to support trend analysis for health service activity and health needs assessment. In addition, the returns support the monitoring of progress in the achievement of overall objectives for the NHS and contribute towards the development of policy and the process of funding allocation.The Department of Health uses the information gathered from the Central Return Forms to monitor service provision at a high level and to support trend analysis for health service activity and health needs assessment.

Each Central Return contained within this publication has an image of the Central Return form itself and provides guidance on its content and completion. The guidance also describes how data items held in the NHS Data Model and Dictionary are used to derive the information required for Central Returns. Physical definitions of data items, such as the code values, are included.The Central Return Forms in the NHS Data Model and Dictionary are under review and will either be retired or replaced with Central Return Data Sets.

Important Notes

1. Some of the Central Return Forms covered in this publication are under review. Changes arising from these reviews are not covered in this publication as they were not available in time for publishing. Users should therefore use this publication in conjunction with relevant change notifications as they are published. These were issued as Data Set Change Notices (DSCNs) at time of writing, but the Information Standards Board for Health and Social Care may use a different notification system.

2. Not all mandated Central Return Forms are contained within this publication. For those returns not yet covered, please consult the Notes for Completion provided with the form for detailed information requirements.

• Central Return Forms Introduction
• 
  Central Return Forms:
• Ambulance
• Community
• Hospital
• Mental Health
• Primary Care
• Sexual and Reproductive Health Service

The Clinical Content section covers information standards which are not secondary use data sets.The Clinical Content section covers information standards which are not secondary use data sets.

They may be one of the following types:

• PATIENT Registers
• Data Recording Systems
• Standardised requirements for PATIENT identification
• Electronic Record specifications
• Primary Use Clinical Data Sets.

• information requirements of national and local performance management, planning and clinical governance
• assurance of the quality of health and social care services
• the monitoring of National Service Frameworks (NSFs)

Clinical Data Sets define a standard set of information that is generated from care records, from any ORGANISATION or system that captures the data.

Clinical Data Sets generally relate to a specific area of care, disease, or SERVICE and are at PATIENT level.

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 AGREEMENT.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 AGREEMENT.  See the specific ORGANISATION CODE Data Elements for further information on their usage and Organisation Data Service Default Codes etc.

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 Payment by Results is not determined by the CDS PRIME RECIPIENT IDENTITY or CDS COPY RECIPIENT IDENTITY.

Important Notes:

• The CDS PRIME RECIPIENT IDENTITY must be allocated on the first creation and submission of a CDS TYPE for a PATIENT and must not change even if the ADDRESS or Primary Care Trust of the PATIENT changes during the lifetime of the Commissioning Data Set record otherwise duplicate Commissioning Data Set data may be lodged in the Secondary Uses Service database.
  See the supporting information in Commissioning Data Set Submission Protocol for a detailed explanation.
• The CDS PRIME RECIPIENT IDENTITY must be allocated on the first creation and submission of a CDS TYPE for a PATIENT and must not change even if the ADDRESS or ORGANISATION CODE (RESIDENCE RESPONSIBILITY) of the PATIENT changes during the lifetime of the Commissioning Data Set record otherwise duplicate Commissioning Data Set data may be lodged in the Secondary Uses Service database.
  See the supporting information in Commissioning Data Set Submission Protocol for a detailed explanation.
• 
  
• Note that if two recipients are identical for example, the ORGANISATION CODE (PCT OF RESIDENCE) may be the same as the ORGANISATION CODE (CODE OF COMMISSIONER), only one entry for that ORGANISATION should be made for that recipient.
• Note that if two recipients are identical for example, the ORGANISATION CODE (PCT OF RESIDENCE) 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 Group should include their ORGANISATION CODE as a CDS COPY RECIPIENT IDENTITY. ACTIVITY commissioned by a shared service ORGANISATION or other consortium of Primary Care Trusts, should similarly include the ORGANISATION CODE of the shared service or the lead Primary Care Trust, if this does not already appear as a CDS COPY RECIPIENT IDENTITY or CDS PRIME RECIPIENT IDENTITY.

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 Set details page.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

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

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

• Prefix H = Healthcare Resource Group Business Rules.
• Prefix I = CDS-XML Schema 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. 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 site code as duplication or wrongful record deletion can occur.

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 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:

Changes of address in patient demographic data
A change of POSTCODE following a change of PATIENT USUAL ADDRESS can change the CDS PRIME RECIPIENT IDENTITY in bulk update submissions.  Where possible, data senders should monitor changes to postcodes when preparing Commissioning Data Set data for submission in order to help prepare to minimise its impact on the integrity of the Commissioning Data Set data.

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
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.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 message translation supplier
If a provider changes bureau supplier arrangements for XML message translation, it is important that the new supplier is provided with the information required about the Commissioning Data Set Submission Protocols that has been used in previous Commissioning Data Set submissions in order to ensure that data integrity is maintained in the ongoing Commissioning Data Set messaging processes and in the Secondary Uses Service database.If a provider changes bureau supplier arrangements for XML message translation, it is important that the new supplier is provided with the information required about the Commissioning Data Set Submission Protocols that has been used in previous Commissioning Data Set submissions in order to ensure that data integrity is maintained in the ongoing Commissioning Data Set messaging processes and in the Secondary Uses Service database.

The minimum Commissioning Data Set information flow requirement to enable Hospital Episode Statistics, 18 Weeks ACTIVITY reporting, and Payment by Results to be supported by the Secondary Uses Service is shown in the table below.The minimum Commissioning Data Sets information flow requirement to enable Hospital Episode Statistics, 18 Weeks ACTIVITY reporting, and Payment by Results to be supported by the Secondary Uses Service is shown in the table below.

The Secondary Uses Service supports every CDS TYPE but only a subset is mandated to flow.

Commissioning Data Sets may flow to the Secondary Uses Service using either Net Change or Bulk Replacement Commissioning Data Set Submission Protocols.Commissioning Data Sets may flow to the Secondary Uses Service using either Net Change or Bulk Replacement Commissioning Data Set Submission Protocols.  Many Standard NHS Contracts between Health Care Providers and the commissioners of their SERVICES, now specify weekly submission of initially-coded data sets to the Secondary Uses Service.  The use of Net Change Commissioning Data Set Submission Protocols is recommended for submissions of this frequency.  The use of Net Change Commissioning Data Set Submission Protocols is recommended for submissions of this frequency.

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 Accident and Emergency Attendances, Out-Patient Attendances, Admitted Patient Care and Elective Admission List.

Commissioning Data Set Messages have been defined in specific components known as a CDS TYPE.

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

The structure of the Commissioning Data Set message 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

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

Repeats Column Notation

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

Rules Column Notation

An entry in the "Rules" column shows that a specific Rule applies to submission of an individual Data Element.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.The meaning of these Rules can be found in Commissioning Data Set Business Rules.

Notation Examples

The following are examples of some common scenarios.

Information on care provided for all PATIENTS by NHS Hospital Providers and Independent Sector Providers (for NHS PATIENTS only) is specified in the Commissioning Data Sets and must be submitted to the Secondary Uses Service according to issued guidelines.The Commissioning Data Sets (CDS) are maintained and developed by the Health and Social Care Information Centre, in accordance with the needs of the NHS and the Department of Health.

Use the following links to access more detailed information.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.

The Commissioning Data SetsRequests for changes to the Commissioning Data Sets should be submitted via email to enquiries@hscic.gov.uk, stating "Commissioning Data Sets" in the subject line.

• Commissioning Data Set Overview
• Commissioning Data Set Versions
• Commissioning Data Set Notation
• Commissioning Data Set Business Rules
• Commissioning Data Set Mandated Data Flows
• Commissioning Data Set Submission Protocol
• Commissioning Data Set Addressing Grid
• Security Issues and Patient Confidentiality
• Commissioning Data Set Submission and Organisation Mergers
• Commissioning Data Set Data Duplication
• Hospital Episode Statistics
• Hospital Episode Statistics Cross Reference Tables

The CDS-XML MessageCurrent versions of the Commissioning Data Sets can be found at Commissioning Data Set Versions.

• CDS-XML Message Schema Overview
• Commissioning Data Set Message Schema Versions
• CDS-XML Message Schema Design
• CDS-XML Schema Version Numbering
• CDS-XML Message Schema Documentation

For further information on Commissioning Data Sets, see the Commissioning Data Sets Overview.

• CDS Overview
• CDS Version 6-1 Type List
• CDS Version 6-2 Type List
• CDS Overview
• CDS Version 6-1 Type List
• CDS Version 6-2 Type List
• CDS Versions
• 
  
• CDS Addressing Grid
• CDS Business Rules
• CDS Data Duplication
• CDS Mandated Data Flows
• CDS Notation
• CDS Submission and Organisation Mergers
• CDS Submission Protocol
• Hospital Episode Statistics
• Hospital Episode Statistics Cross Reference Tables
• CDS Addressing Grid
• CDS Business Rules
• CDS Data Duplication
• CDS Mandated Data Flows
• CDS Notation
• CDS Submission and Organisation Mergers
• CDS Submission Protocol
• Referral To Treatment Clock Stop Administrative Event
• Security Issues and Patient Confidentiality
• 
  
• CDS-XML Message
• CDS-XML Message Schema Overview
• CDS-XML Message Schema Versions
• CDS-XML Message Schema Design
• CDS-XML Schema Version Numbering
• CDS-XML Message Schema Documentation
• CDS-XML Message Schema:
• CDS XML Schema Overview
• CDS XML Schema Versions
• CDS XML Schema Design
• CDS XML Schema Version Numbering
• CDS XML Schema Documentation
• 
  Schema Constraints:
• Commissioning Data Set Version 6-2
• Schema Constraints:
• CDS Version 6-2 XML Schema Constraints

The primary purpose of national data sets is to enable conformant health information to be generated across the country, independent of the ORGANISATION or system that maintains it. In achieving this, the Health and Social Care Information Centre will enable healthcare 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.The purpose of the Commissioning Data Sets is to enable conformant health ACTIVITY information to be generated across the country, 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.

Information RequirementsCommissioning Data Sets currently support the following ACTIVITIES:

• monitor and manage NHS SERVICE AGREEMENTS;
• develop commissioning plans;
• support the Payment by Results processes;
• support NHS Comparators;
• monitor Health Improvement Programmes;
• underpin clinical governance;
• understand the health needs of the population.
• support reporting against 18 week wait targets
• monitoring and managing NHS SERVICE AGREEMENTS
• developing commissioning plans
• supporting the Payment by Results processes
• underpinning clinical governance
• understanding the health needs of the population
• reporting waiting time measurement

Information on care provided for all PATIENTS by NHS Hospitals and Primary Care Trusts and Independent Sector Providers (for NHS PATIENTS only) is specified in the Commissioning Data Sets and must be submitted to the Secondary Uses Service according to issued guidelines.Information on care provided for all PATIENTS by Health Care Providers (both NHS Trusts 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.

Independent Sector Treatment Centres (TC) are responsible for providing Admitted Patient Care and Out-Patient Attendance Commissioning Data Sets and may submit this data on their own behalf or via a third party. Other Independent Sector activity for NHS PATIENTS is the responsibility of the NHS commissioning body for the provision of the appropriate central returns and data sets.The Department of Health requires accurate data for all PATIENTS admitted treated as out-patients or treated as an Accident and Emergency Attendance by Health Care Providers, including PATIENTS receiving private treatment. The Commissioning Data Sets also includes NHS PATIENTS treated electively in the independent sector and overseas.

The Department of Health requires accurate data of all PATIENTS admitted to or treated as out-patients, or treated as an Accident and Emergency Attendance by NHS Hospital Providers and Primary Care Trusts, including PATIENTS receiving private treatment. The data also includes NHS PATIENTS treated electively in the independent sector and overseas. These Hospital Episode Statistics (HES) are derived from the Admitted Patient Care, Out-Patient Attendance and Accident and Emergency Attendance Commissioning Data Sets as stored in the Secondary Uses Service. This data provides information about hospital and PATIENT management, epidemiological data on PATIENT DIAGNOSES and OPERATIVE PROCEDURES.

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

Commissioning Data Set Data Flow Definitions

CDS TYPES

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 Accident and Emergency Attendances, Out-Patient Attendances, Future Attendances, Admitted Patient Care and Elective Admission List data etc.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 Accident and Emergency Attendances, Out-Patient Attendances, Future Attendances, Admitted Patient Care and Elective Admission List data.

Commissioning Data Set Messages have been defined in specific components known as a CDS TYPE. Each Commissioning Data Set Type as configured into the Commissioning Data Set Message carries only one specific Commissioning Data Set Type, an examples being the Finished Consultant Episode Commissioning Data Set Type etc.

ORGANISATIONS can function as independent senders of Commissioning Data Sets and have service level agreements with Acute, Community or Mental Health NHS Trusts for the submission of this data.ORGANISATIONS can function as independent senders of Commissioning Data Sets and have service level agreements with Acute, Community or Mental Health NHS Trusts for the submission of this data. These agreements usually relate to clinical services that are subcontracted to that provider or where clinical services are facilitated on that site but owned by the commissioner of the agreement.

Organisational mergers of NHS Trusts do not always result in an immediate merger of IT facilities and their often disparate systems to enable a single flow of commissioning data to the Secondary Uses Service. In this case, data flows to the Secondary Uses Service for multiple sites from multiple senders must be very carefully managed in order to avoid inadvertent deletion or duplication of records in the Secondary Uses Service.

In these cases, Senders are strongly advised to only use the Net Change Update Mechanism of the CDS Submission Protocol as data integrity is more manageable using the Net Change process rather than the Bulk Replacement process.In these cases, Senders are strongly advised to only use the Net Change Update Mechanism of the Commissioning Data Set Submission Protocol as data integrity is more manageable using the Net Change process rather than the Bulk Replacement process.

CDS Net Change
When using the Net Change process, multiple data flows from different sites or systems using the same CDS INTERCHANGE SENDER IDENTITY must ensure that each Commissioning Data Set record has a properly maintained CDS UNIQUE IDENTIFIER.

If not, these submissions will most likely conflict and overwrite each other causing substantial data corruption in the Secondary Uses Service data base. It is recommended that wherever possible, individual sites or systems use a uniquely allocated CDS INTERCHANGE SENDER IDENTITY for submissions to the Secondary Uses Service.

CDS Bulk Replacement
When using the Bulk Replacement process, a sender must not make multiple data flows from different organisation sites or systems using the same CDS SENDER IDENTITY and provider site code or the interchanges will conflict and overwrite each other causing substantial data corruption in the Secondary Uses Service data base.

To prevent this happening, individual sites and systems within an organisation must use a unique CDS SENDER IDENTITY and provider site code combination for Commissioning Data Set submissions to the Secondary Uses Service. This can be achieved by utilising Provider and Site Codes already registered with the Organisation Data Service which will then differentiate multiple Commissioning Data Set flows for the same provider by using the last 2 digits of the ORGANISATION CODE.

End Of Year Considerations
It may be necessary to avoid changes to systems processes for multiple flows at the end of the financial year, and retain the ability to use the previously used Commissioning Data Set Submission Protocol for data submitted earlier in the year, until the organisation has completed any refresh of data for that year.It may be necessary to avoid changes to systems processes for multiple flows at the end of the financial year, and retain the ability to use the previously used Commissioning Data Set Submission Protocol for data submitted earlier in the year, until the organisation has completed any refresh of data for that year. This would then ensure a complete set of commissioning data for that year for Payment by Results and Hospital Episode Statistics purposes.

The Commissioning Data Set messages 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.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.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.

Two Update Mechanisms are available:

• Net Change - to support the management of an individual CDS TYPE in the Secondary Uses Service database and enables Commissioning data to be inserted/ updated or deleted.
  CDS Senders are expected to use the Net Change Update Mechanism wherever possible.
• 
  
• Bulk Replacement - to support the management of bulk commissioning data for an identified CDS BULK REPLACEMENT GROUP of data for a specified time period and for a specified CDS PRIME RECIPIENT IDENTITY.
  CDS Senders should only use the Bulk Replacement Update Mechanism in exceptional circumstances.

It is strongly advised that all NHS Trusts should, as a minimum process, commence migration to use the CDS-XML Version 6 Message for weekly Net Change submissions by March 2009 as this is the date mandated by the "NHS Operating Framework".

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

• CDS SENDER IDENTITY
• CDS UNIQUE IDENTIFIER
• CDS APPLICABLE DATE
• CDS APPLICABLE TIME

Each CDS TYPE must have a CDS UNIQUE IDENTIFIER which must be uniquely maintained for the life of that Commissioning Data Set record. This is a particular consideration where mergers and/or healthcare systems are changed or upgraded, see CDS Submission and Organisation Mergers. 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. 

From Commissioning Data Set version 6-2 onwards, the process for submitting Net Change records carrying a CDS UPDATE TYPE 1 (to indicate a CDS deletion or cancellation) changes.  In previous CDS versions, it was necessary to send the original mandatory content of the deleted record in the CDS TYPE attached to the CDS V6-1 Type 005N - Commissioning Data Set Transaction Header Group - Net Change Protocol.  From Commissioning Data Set version 6-2, an empty XML element called 'Delete Transaction' can be used instead of the original CDS TYPE, after the CDS V6-2 Type 005N - CDS Transaction Header Group - Net Change Protocol.  Note that CDS UPDATE TYPE code 1 should still be used to indicate a delete/cancellation when this mechanism is used.

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 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 Primary Care Trust or NHS Trust.

Bulk Replacement
Bulk Replacement processes are managed by specific data settings as defined in the CDS V6-1 Type 005B - Commissioning Data Set Transaction Header Group - Bulk Update Protocol / CDS V6-2 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
• CDS BULK REPLACEMENT GROUP (CDS-XML schema version 6-1-1) / CDS BULK REPLACEMENT GROUP CODE (CDS-XML schema version 6-2)
• CDS EXTRACT DATE
• CDS EXTRACT TIME
• CDS REPORT PERIOD START DATE
• CDS REPORT PERIOD END DATE
• CDS PRIME RECIPIENT IDENTITY

The CDS SENDER IDENTITY 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.

The CDS PRIME RECIPIENT IDENTITY must be identified in each Commissioning Data Set and must not be changed during the lifetime of the Commissioning Data Set record otherwise the data stored in the Secondary Uses Service database may lose its integrity (e.g. duplicate Commissioning data may be stored).

For this reason it is advised that the ORGANISATION CODE (PCT OF RESIDENCE) (CDS-XML schema version 6-1-1) or ORGANISATION CODE (RESIDENCE RESPONSIBILITY) (CDS-XML schema version 6-2) should always be used to determine the CDS PRIME RECIPIENT IDENTITY as detailed in the Commissioning Data Set Addressing Grid.For this reason it is advised that the ORGANISATION CODE (PCT OF RESIDENCE) (CDS-XML schema version 6-1-1) or ORGANISATION CODE (RESIDENCE RESPONSIBILITY) (CDS-XML schema version 6-2) should always be used to determine the CDS PRIME RECIPIENT IDENTITY as detailed in the Commissioning Data Set Addressing Grid. Senders must also be aware that if the ORGANISATION CODE (PCT OF RESIDENCE) or ORGANISATION CODE (RESIDENCE RESPONSIBILITY) is itself derived from the PATIENT's POSTCODE OF USUAL ADDRESS then great care must be taken to manage all elements of this relationship.

If it is necessary to change any of this data during the lifetime of a Commissioning Data Set record, then the Secondary Uses Service help desk should be contacted for advice.

It is strongly advised that users of the Bulk Replacement Mechanism maintain a correctly generated CDS UNIQUE IDENTIFIER within the Commissioning data.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
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 is used. Often this is done by changing the last 2 digits of the 5 digit code (the Site element of the ORGANISATION CODE).

Note: Data sent using the same CDS SENDER IDENTITY 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 helpdesk.

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) in order to change the CDS INTERCHANGE SENDER IDENTITY should this become necessary.

The NHS Data Model and Dictionary contains current and previous versions of the Commissioning Data Sets. The list below contains the Commissioning Data Sets since 2001.Listed below are the Commissioning Data Set versions since 2001.

Current versions
The tables listing the elements in each data set are available in the following type lists.Current versions:

• November 2008: CDS Version 6-1 Type List
• November 2012: CDS Version 6-2 Type List

Retired versionsRetired versions:

• 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 message schema are listed in Commissioning Data Set Message Schema VersionsThe XML Message Schemas and supporting information can be downloaded from the Commissioning Data Set XML Message Schema Versions page.

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 has accordingly been 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
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:
This is incremented when fundamental change has taken place such as:

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

• Minor changes to schema business functionality
• Minor changes to the 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*

• Minor changes to the 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

The Schema Date:
All schema releases have a designated SchemaDate XML Attribute.

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

• SchemaVersion
• SchemaDate

See the Department of Health website for the most up-to-date available statistics.

This item has been retired from the NHS Data Model and Dictionary.

The last live version of this item is available in the ?????? release of the NHS Data Model and Dictionary.

Access to this version can be obtained by emailing information.standards@hscic.gov.uk with "NHS Data Model and Dictionary - Archive Request" in the email subject line.

See the Department of Health - NHS Complaints Website for the most up-to-date available statistics

Data Set Change Notice 18/2006 published in December 2006, defined essential new data items required to support the measurement of 18 week REFERRAL TO TREATMENT PERIODS (monitoring of DH PSA target 13 - "By 2008, no one will have to wait longer than 18 weeks from GP referral to hospital treatment"). In particular, the Data Set Change Notice 18/2006 introduced the following new data items.

• PATIENT PATHWAY IDENTIFIER
• REFERRAL TO TREATMENT PERIOD START DATE
• REFERRAL TO TREATMENT PERIOD END DATE
• REFERRAL TO TREATMENT STATUS (replaced with REFERRAL TO TREATMENT PERIOD STATUS at CDS V6-2)

Strategic reporting of 18 weeks will be undertaken by the Secondary Uses Service using data obtained via the Commissioning Data Sets .Strategic reporting of 18 weeks will be undertaken by the Secondary Uses Service using data obtained via the Commissioning Data Sets. The new data items defined in Data Set Change Notice 18/2006 are enabled to flow in Commissioning Data Set versions 6-1 and 6-2, and will continue to flow in subsequent versions.

However, an event which results in an update to the REFERRAL TO TREATMENT PERIOD STATUS may occur outside the events that are defined in the Commissioning Data Sets (typically Outpatient or Inpatient encounters) and will therefore not flow to the Secondary Uses Service.However, an event which results in an update to the REFERRAL TO TREATMENT PERIOD STATUS may occur outside the events that are defined in the Commissioning Data Sets (typically Outpatient or Inpatient encounters) and will therefore not flow to the Secondary Uses Service. These types of events have been termed as "administrative events". They can be defined as any communication event between the Health Care Provider and the PATIENT that occurs outside of an outpatient attendance or inpatient admission and that results in the PATIENT's REFERRAL TO TREATMENT PERIOD STATUS being changed to stop the 18 week clock. These events are not face to face consultations and do not necessarily involve clinical staff.

These Referral To Treatment Clock Stop Administrative Events may be carried using the Commissioning Data Set Type 020 Outpatient record type. They are differentiated from PATIENT contact ACTIVITY by the FIRST ATTENDANCE value carried within them. FIRST ATTENDANCE national code 5 "Referral to treatment clock stop administrative event" signifies that an ACTIVITY has taken place which has ended the REFERRAL TO TREATMENT PERIOD and changed the REFERRAL TO TREATMENT PERIOD STATUS to one of the following:

• 30 Start of First Definitive Treatment
• 31 Start of Active Monitoring initiated by the PATIENT
• 32 Start of Active Monitoring initiated by the CARE PROFESSIONAL
• 34 Decision not to treat - decision not to treat made or no further contact required
• 35 PATIENT declined offered treatment
• 36 PATIENT died before treatment

When to Use Referral To Treatment Clock Stop Administrative Events

These events may happen because:

• The ACTIVITY ending the event does not qualify as a "patient contact" between a clinician and PATIENT, or
• The ACTIVITY occurred in a setting where IT systems cannot produce REFERRAL TO TREATMENT PERIOD data items, or
• The ACTIVITY would be carried in a Commissioning Data Set record type not currently processed by the Secondary Uses Service

Secondary Uses Service Processing

The Secondary Uses Service currently processes the following Commissioning Data Set record types in order to build Referral To Treatment pathways.

• CDS V6-1 Type 020 - Outpatient CDS / CDS V6-2 Type 020 - Outpatient Commissioning Data Set
• CDS V6-1 Type 130 - Admitted Patient Care - Finished General Episode CDS / CDS V6-2 Type 130 - Admitted Patient Care - Finished General Episode Commissioning Data Set
• CDS V6-1 Type 190 - Admitted Patient Care - Unfinished General Episode CDS / CDS V6-2 Type 190 - Admitted Patient Care - Unfinished General Episode Commissioning Data Set

All other types are not currently processed and so if they carry the  REFERRAL TO TREATMENT PERIOD END DATE for a REFERRAL TO TREATMENT PERIOD, a Referral To Treatment Clock Stop Administrative Event must also be sent in order to inform the Secondary Uses Service of the clock stop.

Note that future versions of the Secondary Uses Service will also process:

• CDS V6-1 Type 030 - Elective Admission List - End of Period Census (Standard) CDS / CDS V6-2 Type 030 - Elective Admission List - End of Period Census (Standard) Commissioning Data Set
• CDS V6-1 Type 060 - Elective Admission List - Event During Period (Add) CDS / CDS V6-2 Type 060 - Elective Admission List - Event During Period (Add) Commissioning Data Set
• CDS V6-1 Type 070 - Elective Admission List - Event During Period (Remove) CDS / CDS V6-2 Type 070 - Elective Admission List - Event During Period (Remove) Commissioning Data Set
• CDS V6-1 Type 080 - Elective Admission List - Event During Period (Offer) CDS / CDS V6-2 Type 080 - Elective Admission List - Event During Period (Offer) Commissioning Data Set

The dates when ORGANISATIONS submitting REFERRAL TO TREATMENT PERIOD data to the Secondary Uses Service can cease having to also send a Referral To Treatment Clock Stop Administrative Event when a clock stop is carried in one of the Elective Admission List Commissioning Data Set Types, will be notified as part of the Secondary Uses Service release documentation. It is also anticipated that CDS V6-2 Type 021 - Future Outpatient CDS will be processed once piloting is complete and its use is approved by the Information Standards Board for Health and Social Care. A cancelled future APPOINTMENT record could carry a REFERRAL TO TREATMENT PERIOD Clock Stop. Again the timescales will be notified as part of the Secondary Uses Service release documentation.

There are no current plans for the Secondary Uses Service to process the remaining Commissioning Data Set Types:

• CDS V6-1 Type 010 - Accident and Emergency CDS / CDS V6-2 Type 010 - Accident and Emergency Commissioning Data Set
• CDS V6-1 Type 040 - Elective Admission List - End Of Period Census (Old) CDS / CDS V6-2 Type 040 - Elective Admission List - End Of Period Census (Old) Commissioning Data Set
• CDS V6-1 Type 050 - Elective Admission List - End Of Period Census (New) CDS / CDS V6-2 Type 050 - Elective Admission List - End Of Period Census (New) Commissioning Data Set
• CDS V6-1 Type 090 - Elective Admission List - Event During Period (Available / Unavailable) CDS / CDS V6-2 Type 090 - Elective Admission List - Event During Period (Available or Unavailable) Commissioning Data Set
• CDS V6-1 Type 100 - Elective Admission List - Event During Period (Old Service Agreement) CDS / CDS V6-2 Type 100 - Elective Admission List - Event During Period (Old Service Agreement) Commissioning Data Set
• CDS V6-1 Type 110 - Elective Admission List - Event During Period (New Service Agreement) CDS / CDS V6-2 Type 110 - Elective Admission List - Event During Period (New Service Agreement) Commissioning Data Set
• CDS V6-1 Type 120 - Admitted Patient Care - Finished Birth Episode CDS / CDS V6-2 Type 120 - Admitted Patient Care - Finished Birth Episode Commissioning Data Set
• CDS V6-1 Type 140 - Admitted Patient Care - Finished Delivery Episode CDS / CDS V6-2 Type 140 - Admitted Patient Care - Finished Delivery Episode Commissioning Data Set
• CDS V6-1 Type 150 - Admitted Patient Care - Other Birth Event CDS / CDS V6-2 Type 150 - Admitted Patient Care - Other Birth Event Commissioning Data Set
• CDS V6-1 Type 160 - Admitted Patient Care - Other Delivery Event CDS / CDS V6-2 Type 160 - Admitted Patient Care - Other Delivery Event Commissioning Data Set
• CDS V6-1 Type 170 - Admitted Patient Care - Detained and/or Long Term Psychiatric Census CDS / CDS V6-2 Type 170 - Admitted Patient Care - Detained and or Long Term Psychiatric Census Commissioning Data Set
• CDS V6-1 Type 180 - Admitted Patient Care - Unfinished Birth Episode CDS / CDS V6-2 Type 180 - Admitted Patient Care - Unfinished Birth Episode Commissioning Data Set
• CDS V6-1 Type 200 - Admitted Patient Care - Unfinished Delivery Episode CDS / CDS V6-2 Type 200 - Admitted Patient Care - Unfinished Delivery Episode Commissioning Data Set

This is the because a Referral To Treatment Clock Stop Administrative Event occurring in the scenarios where these record types are generated, would be rare.This is because a Referral To Treatment Clock Stop Administrative Event occurring in the scenarios where these record types are generated, would be rare. However this will be reviewed as part of the ongoing maintenance of the Referral To Treatment Clock Stop Administrative Event, and the requirements for the Secondary Uses Service.

When NOT to Use a Referral To Treatment Clock Stop Administrative Event

The Referral To Treatment Clock Stop Administrative Event should NOT be used to correct previously submitted records where a REFERRAL TO TREATMENT PERIOD END DATE was submitted incorrectly to the Secondary Uses Service.

For example, if an Out-Patient Appointment took place where First Definitive Treatment was started, but the REFERRAL TO TREATMENT PERIOD END DATE was not sent in the corresponding CDS V6-1 Type 020 - Outpatient Commissioning Data Set/ CDS V6-2 Type 020 - Outpatient Commissioning Data Set record as it was not entered on the Patient Administration System until later; then the CDS V6-1 Type 020 - Outpatient Commissioning Data Set/CDS V6-2 Type 020 - Outpatient Commissioning Data Set record should be resubmitted with the correct data. A Referral To Treatment Clock Stop Administrative Event should NOT be used.

Where an ORGANISATION's Patient Administration System supports the submission of cancelled and Did Not Attend appointments in the CDS V6-1 Type 020 - Outpatient Commissioning Data Set/CDS V6-2 Type 020 - Outpatient Commissioning Data Set, the Referral To Treatment Clock Stop Administrative Event should NOT be used when a PATIENT has a booked Out-Patient Appointment, which is then cancelled because, for example, the PATIENT dies. In these cases the CDS V6-1 Type 020 - Outpatient Commissioning Data Set/CDS V6-2 Type 020 - Outpatient Commissioning Data Set can carry the details of a cancelled CARE ACTIVITY, including the REFERRAL TO TREATMENT PERIOD END DATE and update to the REFERRAL TO TREATMENT PERIOD STATUS. (Note - not all Patient Administration Systems provide functionality to create and submit Commissioning Data Set records for cancellations/Did Not Attend's as this is not yet mandated - you should contact your Patient Administration System support team to ascertain whether your Patient Administration System supports this. If not, then it is permissible to send a Referral To Treatment Clock Stop Administrative Event in order to stop the clock in the Secondary Uses Service instead).

Referral To Treatment Clock Stop Administrative Events only require a sub-set of the data elements contained in the CDS V6-1 Type 020 - Outpatient Commissioning Data Set / CDS V6-2 Type 020 - Outpatient Commissioning Data Set record, to be submitted to the Secondary Uses Service. All other data elements not listed should be omitted from the XML submission of the CDS V6-1 Type 020 - Outpatient Commissioning Data Set/CDS V6-2 Type 020 - Outpatient Commissioning Data Set record to the Secondary Uses Service. The submission of a Referral To Treatment Clock Stop Administrative Event is not reliant on the use of the Net Change Commissioning Data Set Submission Protocol to the Secondary Uses Service The submission of a Referral To Treatment Clock Stop Administrative Event is not reliant on the use of the Net Change Commissioning Data Set Submission Protocol to the Secondary Uses Service

The required data elements making up a Referral To Treatment Clock Stop Administrative Event are:

Supporting Data Sets flow in the Admitted Patient Care Commissioning Data Sets

The purpose of the Supporting Data Sets is to provide a standardised set of data to support Payment by Results, Healthcare Resource Groups, Resource Management, Commissioning and national policy analysis.

Definition:
For Commissioning data, every CDS TYPE has a "CDS Originating Date" contained within the Commissioning Data Set data that must be used to populate the CDS ACTIVITY DATE.

The CDS ACTIVITY DATE is held in the Commissioning Data Set Transaction Header Group and is a mandatory data element for all uses of the Commissioning Data Set for both Bulk Update and Net Change Protocols, see the Commissioning Data Set Submission Protocol supporting information.The CDS ACTIVITY DATE is held in the Commissioning Data Set Transaction Header Group and is a mandatory data element for all uses of the Commissioning Data Set for both Bulk Update and Net Change Protocols, see the Commissioning Data Set Submission Protocol supporting information.

For Bulk Update use, see: CDS V6-1 Type 005B - Commissioning Data Set Transaction Header Group - Bulk Update Protocol / CDS V6-2 Type 005B - CDS Transaction Header Group - Bulk Update Protocol 
For Net Change Use, see: CDS V6-1 Type 005N - Commissioning Data Set Transaction Header Group - Net Change Protocol / CDS V6-2 Type 005N - Commissioning Data Set Transaction Header Group - Net Change Protocol 

The CDS ACTIVITY DATE has an associated "CDS Originating Date" specifically identified for each CDS TYPE as follows:

Usage:
The CDS ACTIVITY DATE is validated by the Secondary Uses Service and Commissioning Data Set Interchanges are rejected if the date is not present, invalid or not compatible with the Commissioning Data Set Submission Protocol controls being used.The CDS ACTIVITY DATE is validated by the Secondary Uses Service and Commissioning Data Set Interchanges are rejected if the date is not present, invalid or not compatible with the Commissioning Data Set Submission Protocol controls being used.

In particular, when using the Commissioning Data Set Bulk Replacement Update Mechanism, the CDS ACTIVITY DATE and its "CDS Originating Date" are used by the Secondary Uses Service to validate that the CDS TYPE date applicability falls within the CDS REPORT PERIOD START DATE and the CDS REPORT PERIOD END DATE.

Usage:
A Recipient may be an agency or service provider that carries out the receiving (and perhaps other) processes on behalf of the NHS ORGANISATION that ultimately uses the data. There may be multiple recipients for Commissioning data.

Organisation Data Service Default Codes for CDS COPY RECIPIENT IDENTITIES are detailed in the Commissioning Data Set Addressing Grid.Organisation Data Service Default Codes for CDS COPY RECIPIENT IDENTITIES are detailed in the Commissioning Data Set Addressing Grid.

Notes:
CDS PRIME RECIPIENT IDENTITY is the mandatory NHS ORGANISATION CODE (or valid Organisation Data Service Default Code) representing the ORGANISATION determined to be the Commissioning Data Set Prime Recipient of the Commissioning Data Set Message as indicated in the Commissioning Data Set Addressing Grid.CDS PRIME RECIPIENT IDENTITY is the mandatory NHS ORGANISATION CODE (or valid Organisation Data Service Default Code) representing the ORGANISATION determined to be the Commissioning Data Set Prime Recipient of the Commissioning Data Set Message as indicated in the Commissioning Data Set Addressing Grid.

Usage:
The CDS PRIME RECIPIENT IDENTITY must be allocated on the first creation and submission of a CDS TYPE for a PATIENT and must not change even if the ADDRESS or Primary Care Trust of the PATIENT changes during the lifetime of the Commissioning Data Set record otherwise duplicate Commissioning Data Set data may be lodged in the Secondary Uses Service database.

CDS PRIME RECIPIENT IDENTITY is a mandatory data item crucial for the correct indexing of the database and must not be changed during the life of the associated Commissioning Data Set. It does not identify the first or most important recipient of data, i.e. there is no inference of primacy of one recipient over another.

Organisation Data Service Default Codes for CDS PRIME RECIPIENT IDENTITIES are detailed in the Commissioning Data Set Addressing Grid.Organisation Data Service Default Codes for CDS PRIME RECIPIENT IDENTITIES are detailed in the Commissioning Data Set Addressing Grid. 

Please note that the following Organisation Data Service Default Codes must not be used in the Commissioning Data Set (CDS) header because they are not default Commissioner codes:

• Q99 - High Level Health Geography/Primary Care Organisation of Residence Not Known
  • for the CDS PRIME RECIPIENT IDENTITY, a valid ORGANISATION CODE (PCT OF RESIDENCE) must be reported
• X98 - Primary Care Organisation Not Applicable (Overseas Visitors)
  • for the CDS PRIME RECIPIENT IDENTITY, the Commissioning Data Set Addressing Grid confirms the correct code that should be reported for Overseas Visitors who are exempt from charges.
• X98 - Primary Care Organisation Not Applicable (Overseas Visitors)
  • for the CDS PRIME RECIPIENT IDENTITY, the Commissioning Data Set Addressing Grid confirms the correct code that should be reported for Overseas Visitors who are exempt from charges.