Selecting the submission method

SUS supports BULK Update and NET Change submission methods.

When using ‘BULK Update’, all records within a specified period are submitted, replacing any activity currently held on the database for activity held between the dates specified.

Many organisations that deal with multiple source data sets are not able to submit using NET Change submission method due to technical difficulties in isolating records, and therefore submit using BULK update.

When using ‘NET Change’, only records that are new, or where details within the record have changed, are submitted. This can also include record-specific deletions.

NET change allows for more precision in managing records and generally reduces the load on the system due to the reduced number of records and processing required.

Although only 30 percent of submissions currently use NET Change submission method, many patient administration systems are capable of automatically producing CDS submission data files containing only the records that are new or have changed for a specified period. Where a single data source is used for CDS this would directly enable NET submission by those organisations.

Required data items

Details about the process and the CDS data items required for both BULK update and NET Change are defined on the Commissioning Data Set Submission Protocol page of the NHS Data Dictionary.

an1

The assigned EDI Address of the physical ORGANISATION or site responsible for sending commissioning data.

an3 or an5

The identity of the organisation acting as the Sender of a CDS submission.

an3

The CDS Group into which CDS Types must be grouped when using BULK update. 

an10 ccyy-mm-dd

The date (along with an associated CDS EXTRACT TIME) of the update event. Used to identify the date when the update was made.

HH:MM:SS

The time (with an associated CDS EXTRACT DATE) of the update event. Used to identify the time when the update was made.

an10 ccyy-mm-dd

The start date (for the date range of the data being replaced) of the Bulk update time period. 

an10 ccyy-mm-dd

The end date (for the date range of the data being replaced) of the Bulk update time period.

an10 ccyy-mm-dd

"CDS Originating Date" specifically identified for each CDS TYPE.

When a CDS interchange is submitted, SUS identifies the CDS SENDER IDENTITY. On doing so, it verifies all 5 characters, meaning that a code of RNN is different from RNN00 and both are different from RNN01 even though they are all clearly related to the same Organisation.

Using CDS REPORT PERIOD START DATE and CDS REPORT PERIOD END DATE the Sender ID and date combination is then verified against reference data which logs all previous submission periods for that sender.

Each CDS TYPE belongs to a Bulk Replacement Group. The CDS BULK REPLACEMENT GROUP CODE is used with the other listed data items to determine which records are replaced and processed. 

If the sender has not previously sent data with the same CDS REPORT PERIOD START DATE and CDS REPORT PERIOD END DATE, the interchange will be accepted for processing.

If data has previously been sent for the same report period start and end dates, SUS verifies the CDS EXTRACT DATE and CDS EXTRACT TIME.

Rejected Interchanges (Not Applied)

If the interchange extract date and time is less than any interchange previously received from the same CDSS SENDER IDENTITY, the interchange will not be processed.  However, the system will record that the attempted transaction took place. Non-processed interchanges are identified in SUS Tracker as ‘Not Applied’.

Accepted Interchanges

If the interchange extract date and time combination is greater than or equal to the equivalent date and time in any interchange previously received from the same CDS SENDER IDENTITY, the interchange will be accepted for processing.  All matching data is deleted between the report start and end dates. The records in the new BULK interchange are appended to the SUS database.

Matching records have

• The same CDS BULK REPLACEMENT GROUP CODE
• The same CDS SENDER IDENTITY
• A CDS ACTIVITY DATE (episode end date for FCEs) between the CDS REPORT PERIOD START DATE and CDS REPORT PERIOD END DATE in the new BULK interchange

For example, where data is sent for 1st to 31st May and then re-sent with a later CDS EXTRACT DATE, also for the 1st to 31st May, the previously submitted records within these date parameters will be deleted and replaced with the new submission.

However, where data is submitted for 1 to 31 May and then resubmitted with the same, a later or an earlier CDS EXTRACT DATE  but for 1 to 30 May, only the previously submitted records within these date parameters will be deleted.  The records for 31 May will not be affected. If the new file contains data for 31st May records for this day will be duplicated on SUS.  

There is no check at SUS to ensure activity dates are within the stated report period dates. Care should therefore be taken when defining the report period dates as this is often a manual stage in the process. This error can be most easily rectified by resubmitting May data with the correct report period dates of 1 and 31 May and a later extract date than previous submissions.

Historically, the CDS PRIME RECIPIENT IDENTITY data item was a required field for BULK update submissions. Since April 2013 (SUS Release 13) this requirement was removed in order to eliminate the risk of duplication of data due to changes in the patient’s postcode. However, removing CDS PRIME RECIPIENT IDENTITY from the update method now means that changing the CDS SENDER IDENTITY of a record can have two possible effects.

A new code that has not previously been received by SUS for the interchange report period will cause a duplication of those previously submitted records of the same included Bulk Replacement Groups containing the original CDS SENDER IDENTITY.

Records containing a CDS SENDER IDENTITY code that has been received previously will replace those existing records for the same CDS Sender Identity, Interchange Report Period and included Bulk Replacement Groups. This does not necessarily equate to a direct replacement of like for like records.  Senders with more than one data flow, from multiple sites should be aware of this, particularly when different sites at the same organisation are sending their own data.

Details about the process and the CDS data items required for both BULK update and NET Change are defined on the Commissioning Data Set Submission Protocol page of the NHS Data Dictionary.

an15

The assigned EDI Address of the physical ORGANISATION or site responsible for sending Commissioning data.

an3 or an5

The identity of the organisation acting as the Sender of a CDS submission.

an35

A CDS data element providing a unique identity for the life-time of an episode carried in a CDS message.  This field must not contain any data that could be used to identify the patient.  This includes but is not limited to NHS Number and Local Patient ID. 

an10 CCYY-MM-DD

The date (with an associated CDS EXTRACT TIME) of the update event (or the nearest equivalent) that resulted in the need to exchange this CDS. 

an8 HH:MM:SS

The time (with an associated CDS EXTRACT DATE) at which the CDS extract was undertaken.

an1

1 indicates a CDS Deletion or Cancellation, 9 indicates a CDS Original or Replacement. 

an3

The code to identify the specific type of Commissioning Data Set data. 

When an interchange is submitted using NET change submission method CDS SENDER IDENTITY and CDS APPLICABLE DATE / CDS APPLICABLE TIME are verified against SUS reference data. CDS UNIQUE IDENTIFIER is verified against existing SUS data. CDS TYPE CODE  is then used to determine the corresponding records to be updated. Where CDS Update Type = 9 (CDS Original or Replacement) and a CDS UNIQUE IDENTIFIER is not already present in SUS for that CDS SENDER IDENTITY, the record is accepted for processing. 

When a subsequent interchange is submitted using NET change it is possible to update or delete records held in SUS.

Where CDS Update Type = 9 (CDS Original or Replacement) and a CDS UNIQUE IDENTIFIER is already present in SUS for that CDS SENDER IDENTITY, the record is accepted for processing.

Where CDS Update Type = 9 and one or more records for the same CDS SENDER IDENTITY with the same CDS UNIQUE IDENTIFIER are found to exist in SUS, and where the CDS APPLICABLE DATE and CDS APPLICABLE TIME is later than the CDS APPLICABLE DATE and CDS APPLICABLE.

TIME on the existing record, those existing records will be replaced with the records in the new interchange.

Where CDS Update Type = 1 and one or more records for the same CDS SENDER IDENTITY with the same CDS UNIQUE IDENTIFIER are found to exist in SUS, and where the CDS APPLICABLE DATE and CDS APPLICABLE TIME is later than the CDS APPLICABLE DATE and CDS APPLICABLE TIME on the existing record, those existing records will be deleted.

NET Change submission enables data senders to delete records themselves by sending a NET delete record (CDSD Update Type = 1, CDS Deletion or Cancellation). This is a ‘self-delete’ record where all matched records (i.e. records containing the same CDS Sender Identity and CDS UNIQUE IDENTIFIER) will be flagged as logically deleted. This means that SUS does not physically delete the record itself but rather marks the record as deleted.

The APC CDS Types in the table below allow NET submission method to update or delete an existing record containing a different CDS Type.

These changes may include

• unfished to finished
• general to birth
• birth to general

As you can see from the table, it is also possible to make the following change

• finished to unfinished

Data senders can use NET Change and BULK Update according to which method is most suited for the interchange and CDS type they are sending to SUS.

Bulk updates will replace data sent as net change. All bulk processing procedures above will apply with regard to Report Period, Sender Code, Bulk Replacement Group and Extract Date and Time.

Net changes will be applied to data sent as bulk update. All net processing procedures above will apply with regard to CDS Unique Identifier, Sender Code and Applicable Date and Time.

New records that meet acceptance criteria can be submitted under either method.

Risks

Mixing NET and BULK submission methods for the same CDS Types brings with it the following associated risks. 

If the system finds one or more records for the same CDS SENDER IDENTITY with the same CDS UNIQUE IDENTIFIER, but where the Applicable date and time is earlier than the previous NET applicable date and time (or BULK Extract date and time) for all existing records the interchange will not be accepted. The previous applicable date and time includes test submissions and deletion submissions.

NET change cannot identify BULK records without a CDS UNIQUE IDENTIFIER and, since this ID is mandatory for NET change submission method NET change cannot be used to replace BULK records without a CDS UNIQUE IDENTIFIER.  Effectively, this practice means all records are duplicated when resubmitted in a NET interchange under these circumstances as they are all considered to be new records.