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

New message translation supplierNew XML Schema 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 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 Accident and Emergency Attendances, Out-Patient Attendances, Admitted Patient Care and Elective Admission List.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.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 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 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.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

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.

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

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 CODE 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 ORGANISATIONS should, as a minimum process, commence migration to use the CDS-XML Version 6 Message for weekly Net Change submissions by March 2009.

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 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 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. See the CDS V6-2- 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 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 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 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 CODE
• CDS EXTRACT DATE
• CDS EXTRACT TIME
• CDS REPORT PERIOD START DATE
• CDS REPORT PERIOD END DATE
• CDS PRIME RECIPIENT IDENTITY

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

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.

For guidance on the Commissioning Data Set Layout, see the Commissioning Data Set Redesign Guidance Notes on the NHS Data Model and Dictionary website.

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.

For the submission of Commissioning Data Set data to the Secondary Uses Service, XML based messaging has been developed to be fully adopted by the end of 2007, replacing all previously published Commissioning Data Set Message formats.

Schema StandardsXML Schema Standards
The overall standards applied and supported by the 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.

Schema Naming ConventionsXML 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.

Schema ComponentsXML 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
• The CDS XML Message Root
• The CDS XML Standard Data Structures
• The CDS XML Standard Data Elements
• CDS Type Sub-Schemas

The Schema RootThe 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

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.

Schema Component: Standard Data ElementsXML Schema Component: Standard Data Elements
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.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
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 schema applies the data specifications as authorised by the NHS and documented in the NHS Data Model and Dictionary.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
NHS Data Standards maintain and issue the following schema documentation:The Data Dictionary and Messaging Team maintain and issue the following XML Schema documentation:

• The Schema Files (generated using ALTOVA XMLSPY ©)
  The 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 schema to either populate or interpret a 'schema instance' that is the resultant XML formatted message file which carries the data.
• 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 a 'XML Schema instance' that is the resultant XML formatted message file which carries the data.

The schema therefore represents the 'design' of the message and it may be necessary therefore to interpret and understand the information inherent in the schema file code.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 Schema Documentation (generated using ALTOVA XMLSPY ©)
  These files are generated using XMLSPY software and may be read in any browser, e.g. MS Explorer©. 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.
• The XML Schema Documentation (generated using ALTOVA XMLSPY ©)
  These files are generated using XMLSPY software and may be read in any browser, e.g. MS Explorer©. 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 schema editor (see below).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 schema details can be printed as required but users are warned that browser based prints often generate a large number of pages.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 CDS XML Schema generates approximately 450+ pages of details, printing is therefore not advised.

• The Schema Release Note
  This is a text based MS WORD document identifying the changes applied to the schema release.
  References to Information Standards and Collections (including Extractions) Notices and other technical change requirements are detailed.
• The XML Schema Release Notes
  This is a pdf document identifying the changes applied to the XML Schema release.
  References to Information Standards and Collections (including Extractions) Notices and other technical change requirements are detailed.

Reading SchemaReading XML Schema
Whilst schema can be read as HTML in most browsers, it may be difficult to fully interpret the schema unless the reader has a detailed understanding of HTML.Whilst XML Schemas can be read as HTML in most browsers, it may be difficult to fully interpret the XML Schema unless the reader has a detailed understanding of HTML.

It is recommended that schema are read using an XML interpreter (such as ALTOVA XMLSPY ©), many of these are freely available on the internet.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.

Schema technicians may prefer to use such software to examine schema more deeply as the interactive facilities provided are generally more powerful than browsing the XML/HTML supplied schema code.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 has accordingly been adopted by the NHS.

For the submission of Commissioning Data Set data to the Secondary Uses Service, XML based messaging has been developed replacing all previously published Commissioning Data Set Message formats.

The CDS-XML Message Schema is supported and applied in the Secondary Uses Service front-end software service (the XML Transfer Service - XTS) 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.The CDS XML Schema is supported and applied in the Secondary Uses Service front-end software service (the XML Transfer Service - XTS) 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 schema instance data, the Secondary Uses Service then applies further logical data validations and may identify and report further data conditions.It should be noted that after accepting the XML Schema instance data, the Secondary Uses Service then applies further logical data validations and may identify and report further data conditions.

For the most part, the 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 schemas may be less dynamic and updated on a longer time cycle, there may be subtle differences in the data specifications applied in the 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 page and associated Attribute and Data Elements.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 page and associated Attributes and/or Data Elements.

Additionally a 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.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.

Schema StandardsXML Schema Standards
The overall standards applied and supported by the schema are: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.

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

• Information Standards and Collections (including Extractions) Notices (ISCE) issued for NHS business, process and definition changes; these will usually include the Data Sets, Data Element definitions etc.
• Information Standards and Collections (including Extractions) Notices issued to authorise the CDS-XML Schema itself
• The CDS-XML Schema Release Notice which provides a technical overview of the release (in MS WORD)
• The XMLSPY©) generated Schema Documentation which is a large collection of HTML files.
• Information Standards and Collections (including Extractions) 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.

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

The CDS-XML Schema Version Number FormatThe 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.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_RootCDS 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 addition / deletion / change of XML Schema business functionality
• Major change to the technical design of the schema
• Re-alignment of the Schema Version Number after cumulative changes
• Re-alignment of the XML Schema Version Number after cumulative changes

• Minor changes to schema business functionality
• Minor changes to the schema data structures that are not upwardly compatible*
• 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*

• Minor changes to the schema data structures that are upwardly compatible* for instance the addition of an optional data item.
• 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

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

Schema Version Control - The Schema Root:XML 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:The schema root is the single entry point to the XML Schema and XML Attributes for the following are validated:

• SchemaVersion
• SchemaDate

Usage: 
This facility enables submitted interchanges to be marked to enable interchange content to be identified and recorded.
All CDS Interchanges must contain this data element.

For each Interchange submitted, the CDS INTERCHANGE CONTROL REFERENCE must be incremented by 1. The maximum value supported is n7 and wrap around from 9999999 to 1 must be supported.

Usage: 
This is a mandatory data element when submitting Commissioning Data Set Interchanges and is used to uniquely identify and if required, to sequence check Commissioning Data Set submissions.CDS INTERCHANGE CONTROL REFERENCE is a mandatory data element when submitting Commissioning Data Set Interchanges and is used to uniquely identify and if required, to sequence check Commissioning Data Set submissions.

Although (for historical reasons) contained in a 14 alpha-numeric format, a maximum value of 9999999 is permitted in the format of n7.

This control reference data may also be presented on Secondary Uses Service service messages and audit logs, etc.This control reference data may also be presented on Secondary Uses Service (SUS) service messages and audit logs, etc.

CDS XML Schema Interchanges:
All CDS-XML interchanges submitted must contain a CDS INTERCHANGE CONTROL REFERENCE.All CDS XML Schema interchanges submitted must contain a CDS INTERCHANGE CONTROL REFERENCE.  

Usage: 
CDS INTERCHANGE DATE OF PREPARATION is a mandatory data element when submitting Commissioning data.

CDS-XML Interchanges:CDS XML Schema Interchanges:
All XML interchanges submitted must contain a CDS INTERCHANGE DATE OF PREPARATION.All CDS XML Schema interchanges submitted must contain a CDS INTERCHANGE DATE OF PREPARATION.

Usage: 
The collection facility for Commissioning data is the Secondary Uses Service.

Usage: 
CDS INTERCHANGE SENDER IDENTITY is a mandatory data element when submitting Commissioning Data Set interchanges.
Every organisation must register its CDS INTERCHANGE SENDER IDENTITY for use with the Secondary Uses Service.

Where an ORGANISATION acts on behalf of another NHS ORGANISATION, care must be taken to ensure the correct use of the identity. For data submitted to the service, the CDS INTERCHANGE SENDER IDENTITY is the EDI Address of the sending site.

Permitted National Codes:

Whilst the data element is optional it is highly recommended that correct values be completed in the data.

On receipt of a Test Interchange, the processes are as follows:
a) All normal validation processes will be carried out
b) The Interchange data will not be entered into the Secondary Uses Service database

Usage: 
This is a mandatory data element when submitting Commissioning Data Set Interchanges.CDS INTERCHANGE TIME OF PREPARATION is a mandatory data element when submitting Commissioning Data Set Interchanges.

CDS-XML Interchanges:CDS XML Schema Interchanges:
All XML interchanges submitted to the service must contain a CDS INTERCHANGE TIME OF PREPARATION.All CDS XML Schema interchanges submitted to the service must contain a CDS INTERCHANGE TIME OF PREPARATION.

Permitted National Codes:

Usage: 
Commissioning Data Set Interchanges should only contain multiple message of the same CDS MESSAGE TYPE.Commissioning Data Set XML Schema interchanges should only contain multiple message of the same CDS MESSAGE TYPE.

Permitted National Codes:

Usage: 
Interchanges must only contain CDS Messages of the same CDS MESSAGE VERSION NUMBER and each and every CDS Type must contain a CDS MESSAGE VERSION NUMBER.

When exchanging Commissioning Data Set data, this is an optional data element and when used is a unique number generated by the sender and inserted into the Commissioning Data Set data to enable senders and recipients to be able to cross-match and uniquely identify each and every Commissioning Data Set record.

The CDS RECORD IDENTIFIER consists of the following components:

* This data item is configured as an14 format element, but a maximum value of 9999999 is permitted in the format of n7.

Usage: 

CDS-XML Interchanges:CDS XML Schema Interchanges:

Definition:
This is used in the Clinical Activity Group of the Commissioning Data Set to denote the scheme basis of an investigation.

Permitted National Codes:

CDS-XML Message:

Permitted National Codes:

CDS-XML Message:

Each use of an NHS ORGANISATION CODE within a Commissioning Data Set message must be associated with the release version of the NHS Organisation Code scheme. At present this may be derived locally by NHS IT systems.

The following values have been informally used in many Commissioning Data Set implementations and are recommended to be used:

* The values of A and B must be used in the formatting of the CDS UNIQUE IDENTIFIER.

NOTE:

PROCEDURE (OPCS) is a procedure other than the PRIMARY PROCEDURE (OPCS).

For Commissioning Data Sets purposes it is recommended that multiple Procedures are recorded and the CDS-XML Message (CDS Version 6 onwards) has been designed to carry as many Procedures as required.For Commissioning Data Sets purposes it is recommended that multiple Procedures are recorded and the CDS XML Schema (CDS Version 6 onwards) has been designed to carry as many Procedures as required.

PROCEDURE (READ) is the Read Coded Clinical Terms for a procedure other than the PRIMARY PROCEDURE (READ).

For Commissioning Data Sets purposes it is recommended that multiple Procedures are recorded and the CDS-XML Message (CDS Version 6 onwards) has been designed to carry as many Procedures as required.For Commissioning Data Sets purposes it is recommended that multiple Procedures are recorded and the CDS XML Schema (CDS Version 6 onwards) has been designed to carry as many Procedures as required.

Note: Read Coded Clinical Terms Version 3 (CTV3) with qualifiers is not supported in the Commissioning Data Sets.Note: Read Coded Clinical Terms Version 3 (CTV3) with qualifiers is not supported in the Commissioning Data Sets. Therefore, the Commissioning Data Set Version 6-2 XML Schema has the format of this Data Element constrained to max an5.

SECONDARY DIAGNOSIS (ICD) is the International Classification of Diseases (ICD) code used to identify the secondary PATIENT DIAGNOSIS.

For Commissioning Data Sets (CDS) purposes it is recommended that multiple Diagnoses are recorded and the CDS-XML Message (CDS Version 6 onwards) has been designed to carry as many Diagnoses as required.For Commissioning Data Sets (CDS) purposes it is recommended that multiple Diagnoses are recorded and the CDS XML Schema (CDS Version 6 onwards) has been designed to carry as many Diagnoses as required.

SECONDARY DIAGNOSIS (ICD) is used by the Secondary Uses Service to derive the Healthcare Resource Group 4. Failure to correctly populate this data element is likely to result in an incorrect Healthcare Resource Group, usually resulting in lower levels of healthcare resource.

For further information, please refer to the Secondary Uses Service Guidance page.

Note:

• The format/length of this Data Element has been corrected as a result of the work undertaken for the development of the Coding Strategy.
• The data set specifications of the data sets that contain this Data Element will be updated in the next version of the information standard where it is not already correct.

SECONDARY DIAGNOSIS (READ) is the Read Coded Clinical Terms used to identify the secondary PATIENT DIAGNOSIS.

For Commissioning Data Set (CDS) purposes it is recommended that multiple Diagnoses are recorded and the CDS-XML Message (CDS Version 6 onwards) has been designed to carry as many Diagnoses as required.For Commissioning Data Set (CDS) purposes it is recommended that multiple Diagnoses are recorded and the CDS XML Schema (CDS Version 6 onwards) has been designed to carry as many Diagnoses as required.

Note: Read Coded Clinical Terms Version 3 (CTV3) with qualifiers is not supported in the Commissioning Data Sets.Note: Read Coded Clinical Terms Version 3 (CTV3) with qualifiers is not supported in the Commissioning Data Sets. Therefore, the Commissioning Data Set Version 6-2 XML Schema has the format of this Data Element constrained to max an5.

XML Schema constraints applied to the Commissioning Data Sets.XML Schema constraints applied to the Commissioning Data Sets.

The "Allowed Values" column indicates the NHS Data Model and Dictionary National Codes and Default Codes present in the XML Schema:

• None = The National Codes and Default Codes are included in the XML Schema
• Removed = The National Codes and Default Codes are not included in the XML Schema.