The data you need to send

Mandatory

These data items MUST be reported without exception. Failure to submit these items will result in the rejection of the record.

Required

These data items MUST be reported where they apply. It is a legal and contractual requirement to submit these data items where the service has been provided to a patient. Failure to submit these data items will not result in the rejection of the record but may affect the derivation of national indicators or national analysis. Please note that the purpose of the data set is not to change clinical practice.

Optional

These data items MAY be submitted on an optional basis at the submitter's discretion.

Pilot

These data items have been included within the specification for piloting purposes only to support future implementation. These data items have not been approved and/or mandated and SHOULD NOT be submitted unless specifically requested by NHS Digital.

Find out more about the minimum requirements for submitting the IDB.

The 3 mandatory tables in CSDS are CYP000Header, CYP001MPI and CYP002GP.

Within the Technical Output Specification (TOS) document, it can be seen in column N whether a field is mandatory, required or optional.

The CYP000Header table has all fields as mandatory.

The CYP001MPI table has fields LocalPatientID and OrgID_LocalPatientID as mandatory.

The CYP002GP table has fields LocalPatientID and OrgID_GP as mandatory.

Limiting a submission to just the above would not make for a very good submission. There would be little data to construct any meaningful analysis and national reporting would not display any results for certain measures.

It's important to pass into the other fields any data that you store. Examples of these fields, which are not mandatory, but we might expect an organisation to record and therefore to be within the submission are, as example, fields in the CYP001MPI table such as DateOfBirth, Gender, Postcode and EthnicCategory.

You should look at the other tables which could be populated from the data you record for the services you provide, such as the CYP101Referral table. This table records all open referrals within a reporting period and is a common table to populate. When looking to send data for these other tables it must be recognised which fields within these other tables are mandatory. The TOS and the user guidance [Archive Content] will help to see how these tables are connected (an example is that the CYP001MPI table and the CYP101Referral tables are connected by the field LocalPatientID).

CSDS is referral driven - each monthly submission should include all open referrals within that reporting period, which includes referrals that:

• were opened in the reporting period
• that closed in the reporting period
• that were open throughout the reporting period, even if no activity took place

Having unique identifiers for records is seen throughout the data submission and is the base of defining the relationships across tables.

An example of where a unique identifier is used is the LocalPatientID field of the CYP001MPI table. The value we are looking for here is a unique ID that has been assigned to this patient. The value is expected to be fixed to a single patient and should not be repeated or reused for any other patient. Usually such an ID is automatically generated within the patient data recording system used by the provider.

Similarly, we look for a unique identifier for each referral and we see this as the ServiceRequestID within the CYP101Referral table. Some other examples of unique identifiers are the CareContactID field from the CYP201CareContact table and the CareActivityID field from the CYP202CareActivity table. The Data Linkage sheet of the TOS provides a list of the identifiers and within which tables they are used.

As part of the submission process to SDCS Cloud, there are certain tables checked for any duplication of unique IDs. Such duplication will result in records being rejected. The TOS provides information on how this validation of data is executed.