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.
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:
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 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 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
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).For this reason it is advised that the ORGANISATION CODE (RESIDENCE RESPONSIBILITY) 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 (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 (SUS) Service Desk should be contacted for advice. See the NHS Digital website at: SUS Guidance.
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.
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 (SUS) Service Desk, see the NHS Digital website at: SUS Guidance.
Users should be aware of how the 15 character code of their CDS INTERCHANGE SENDER IDENTITY (also known as the EDI Address) is created. This may depend on how their XML interface solution has been set up. It may not be possible to rely on a change to the ORGANISATION CODE (CODE OF PROVIDER) in order to change the CDS INTERCHANGE SENDER IDENTITY should this become necessary.