Make a basic submission

There are four mandatory tables in the MHSDS, which you must submit for a submission to be successful. This is the minimum data that you can supply to us, and we expect to see more tables submitted that reflect the services you provide.

There are 62 tables in version 5.0 of the MHSDS. You will not need to submit data to all of these tables. Which tables you submit will depend on what services you provide and what data you collect locally. More information about these tables is available in the submit additional tables section. 

This section covers information about the mandatory tables and the main columns in each of these tables we would expect to see completed as part of your submission. 

You may find it useful to also read the user guide and Technical Output Specification (TOS) and the validation reports and data quality sections. 

This table contains one row only and all fields are mandatory, so you can’t leave any of them blank.

DATA SET VERSION NUMBER (DatSetVer): Enter the current database version number including the decimal place (currently this is 5.0)

ORGANISATION IDENTIFIER (CODE OF PROVIDER) (OrgIDProvider): This is the ODS code of the organisation providing the services being reported.

ORGANISATION IDENTIFIER (CODE OF SUBMITTING ORGANISATION) (OrgIDSubmit): This is the ODS code of the organisation submitting the data. It will usually be the same as the code of the provider, but in some instances a different organisation may submit on a provider’s behalf. In this case, they would put the ODS code of the organisation they belong to.

PRIMARY DATA COLLECTION SYSTEM IN USE (PrimSystemInUse): This is the system you use to store your data. For some larger providers, this may be a system supplier such as SystmOne or RiO; for some smaller providers, this may be an in-house method such as Excel.

REPORTING PERIOD START DATE (ReportingPeriodStartDate): The first day of the month being reported.

REPORTING PERIOD END DATE (ReportingPeriodEndDate): The last day of the month being reported.

DATE AND TIME DATA SET CREATED (DateTimeDatSetCreate): This should be the date that the database was created, so this may be the date that you are submitting the data. It does not need to include the time.

This table contains demographic information on all patients being reported in the submission. There should be one row per patient.

LOCAL PATIENT IDENTIFIER (EXTENDED) (LocalPatientId): This is a mandatory field so cannot be left blank. This is a code made up of letters/numbers/characters that uniquely identifies a patient within your organisation. It should be unique across all patients and time periods (i.e. don’t re-use a unique ID in a later submission, even if that patient has been discharged).

You can read about unique identifiers for more information on unique IDs. 

ORGANISATION IDENTIFIER (LOCAL PATIENT IDENTIFIER) (OrgIDLocalPatientId): This is a mandatory field so cannot be left blank. This is the ODS code of the provider that assigned the LocalPatientId. It is therefore likely to be your organisation code that you entered in the Header table.

NHS NUMBER (NHSNumber): If you collect NHS numbers, please provide them. If you don’t, this field can be left blank. You may also be eligible to use the Spine Mini Service to find NHS numbers based on demographic information of the patient.  

NHS NUMBER STATUS INDICATOR CODE (NHSNumberStatus): This item takes only a set selection of codes that mean certain things in the MHSDS. The codes can be found in the Technical Output Specification. If you do not collect NHS numbers, enter 07.

PERSON BIRTH DATE (PersonBirthDate): The birthday of the patient. This is important in the calculation of many measures, so ensure you provide it if you have it on your systems.

POSTCODE OF USUAL ADDRESS (Postcode): The postcode of the patient’s permanent residence. Postcodes must have a space at the fourth character from the right and use one of the following formats:

• A1 1AA
• A11 1AA
• AA1 1AA
• AA11 1AA
• A1A 1AA
• AA1A 1AA

If the postcode of the patient isn’t available, you must use one of the following codes:

• Person has no fixed abode - ZZ99 3VZ
• Postcode is unknown - ZZ99 3WZ

GENDER IDENTITY CODE (GenderIDCode): The gender identity of a person as stated by them. This must be recorded as one of the options listed in the Technical Output Specification. 

GENDER IDENTITY SAME AT BIRTH INDICATOR (GenderSameAtBirth): Whether the person’s gender identity is the same as their gender assigned at birth. This must be recorded as one of the options listed in the Technical Output Specification.

PERSON STATED GENDER CODE (Gender): The gender of the patient, declared by the patient or inferred. This must be recorded as one of the options listed in the Technical Output Specification. This field is not considered best practice on how to record gender and has been superseded by the previous two fields. However, it is still required for patient linking so providers should submit all three fields where possible.

ETHNIC CATEGORY (EthnicCategory): The ethnicity of the patient. This must be recorded as one of the options listed in the Technical Output Specification.

All other fields in this table can be left blank, but for more information on whether you may need to submit them, see the user guide and Technical Output Specification. 

This table contains information on the GP of all patients being reported in the submission. There can be more than one row per patient if the patient changes GP during the reporting period.

LOCAL PATIENT IDENTIFIER (EXTENDED) (LocalPatientId): This is a mandatory field so cannot be left blank. It must match a LocalPatientId given in MHS001MPI.

GENERAL MEDICAL PRACTICE CODE (PATIENT REGISTRATION) (GMPCodeReg): This is a mandatory field so cannot be left blank. This is the organisation code of the GP where the patient (represented by LocalPatientId) is registered. Organisation codes can be found by searching the ODS portal or a full list can be downloaded from ODS data downloads. 

If the GP of the patient isn’t available, you must use one of the following codes:

• GP Practice Code not applicable - V81998
• GP Practice Code not known - V81999
• No Registered GP Practice - V81997

START DATE (GMP PATIENT REGISTRATION) (StartDateGMPRegistration): This is the date that the patient registered with the reported GP. This can be left blank, but if you have the information available, please provide it.

END DATE (GMP PATIENT REGISTRATION) (EndDateGMPRegistration): This is the date that the patient finished being registered with the reported GP. This should be provided if you know that the patient changed GP during the reporting period. You would then submit an additional record in this table with the new GP and the relevant start date.

This table records details of referrals into and within your organisation that are open at any point during the reporting period.

SERVICE REQUEST IDENTIFIER (ServiceRequestId): This is a mandatory field so cannot be left blank. This is a code made up of letters/numbers/characters that uniquely identifies a referral. A patient can have multiple referrals, and a referral can have multiple care contacts.

See unique identifiers for more information on unique IDs. 

LOCAL PATIENT IDENTIFIER (EXTENDED) (LocalPatientId): This is a mandatory field so cannot be left blank. It must match a LocalPatientId given in MHS001MPI. This tells us which patient has had this referral.

ORGANISATION IDENTIFIER (CODE OF COMMISSIONER) (OrgIDComm): This is a mandatory field so cannot be left blank. This is the code of the organisation commissioning the service for this patient. This is likely to be a Clinical Commissioning Group (CCG). Organisation codes can be found by searching the ODS Portal or a full list can be downloaded from ODS data downloads.  

REFERRAL REQUEST RECEIVED DATE (ReferralRequestReceivedDate): This is a mandatory field so cannot be left blank. This is the date the referral request was received by your organisation. It is the start date of the referral. It can be before the reporting period if the referral is still open. It cannot be after the reporting period.

REFERRAL REQUEST RECEIVED TIME (ReferralRequestReceivedTime): This is the time the referral request was received. You only need to fill this in if it is an ‘urgent’ priority referral into a service with target waiting times measured in hours, such as rapid response teams or urgent care.

SOURCE OF REFERRAL FOR MENTAL HEALTH SERVICES DATA SET (SourceOfReferralMH): This is where the referral came from. It takes only a set selection of codes that mean certain things in the MHSDS, which are listed in the Technical Output Specification.

CLINICAL RESPONSE PRIORITY TYPE (ClinRespPriorityType): This is the clinical response priority of the referral. It takes only a set selection of codes that mean certain things in the MHSDS, which are listed in the Technical Output Specification.

PRIMARY REASON FOR REFERRAL (MENTAL HEALTH) (PrimReasonReferralMH): This is the main reason a patient was referred for treatment. It takes only a set selection of codes that mean certain things in the MHSDS, which are listed in the Technical Output Specification. If there is more than one reason for referral, you can report these in the table MHS103 Other Reason for Referral (MHS103OtherReasonReferral).

REASON FOR OUT OF AREA REFERRAL (ADULT ACUTE MENTAL HEALTH) (ReasonOAT): If you have received a patient from out of the usual area covered by your organisation, you must submit this field. It is very important for reporting on Out of Area Placements (OAPs), which are closely monitored. It takes only a set selection of codes that mean certain things in the MHSDS, which are listed in the Technical Output Specification. For more information on how to report OAPs, see key measures.

SERVICE DISCHARGE DATE (ServDischDate): This is the end date of the referral and must be provided for any referrals ending in the reporting period. Discharge occurs once all services and teams have finished treating the patient for this specific referral.

All other fields in this table can be left blank, but for more information on whether you may need to submit them, see the User Guide and Technical Output Specification.  

Within both mandatory and required tables, there are also mandatory and required fields.

Mandatory fields must not be left blank, otherwise the record will be rejected when you come to submit the data. If you don’t know the information being requested, there will be a default code to use instead.

Required fields can be left blank and the submission will still be successful. However, if you have the data to complete these fields, you must supply it to us.

You can see which fields are mandatory (M) or required (R) in column H of the Technical Output Specification.

Some required fields are needed to calculate certain measures. For example, you cannot achieve the CYP Access measure using mandatory fields alone. Required fields also impact your DQMI (Data Quality Maturity Index) score. These fields are listed in the DQMI Methodology document. 

Less frequently you may also see fields marked as Optional (O), which means they may be submitted at the provider’s discretion, or Pilot (P), which means they have been incorporated into the IDB to support the implementation of future versions and can be ignored. There are also fields marked as D, which stands for Derived. You do not submit these fields; they are calculated by NHS Digital based on other data you have submitted.

The golden rule is if you have the information, then you must provide it to us.

Understanding unique ID fields

Unique identifiers are used throughout the dataset and are the way relationships are defined across tables.

For example, the LocalPatientID field within the MHS001MPI table is a unique ID. This value uniquely identifies one patient from your organisation. There is also a ServiceRequestID for each referral. NHS Digital uses these to link data across the different tables of the MHSDS, so that we know which things happened with which patients.

The Data Linkage sheet of the Technical Output Specification provides a list of the identifiers and within which tables they are used.

If the system you use to record patient data does not produce these automatically, you will need to establish a process for this. They can be a mixture of letters/numbers/characters, with a maximum length of 20 characters. How you do this is up to you and may depend on factors such as how you store your data and how many patients you see.

The key thing to remember is that there can only be one Local Patient ID per person who enters your care. The IDs then cascade from here, such that each Local Patient ID can have more than one Service Request ID (each person can have more than one referral); each Service Request ID can have more than one Care Contact ID (each referral can involve more than one appointment); each Care Contact ID can have more than one Care Activity ID (each appointment can involve more than one action).

Example method 1: Concatenation

Set Local Patient ID to start from 00001 and increase by 1 for each patient that you see. To create a Service Request ID (i.e. referral number), append ‘_01’ for their first referral. This allows for patients to have multiple referrals, either at the same time or in future. The first patient’s first referral therefore has a Service Request ID of 00001_01.

To produce a Care Contact ID, you may want to append the date of the contact onto the Service Request ID. So if our patient above had an appointment on the 1^st August, the Care Contact ID could be 00001_01_010821.

Beware that in using this method, IDs can get too long depending on how many fields you concatenate and how many digits your original Local Patient ID is. They cannot be more than 20 characters in length.

Example method 2: Generation

To prevent IDs from getting longer each time something is concatenated, you may choose to just generate a sequence of numbers for each of the tables that require an ID.

For example, Local Patient ID links using the MPI table. This is table number 001 in the MHSDS, so you could prefix all your Local Patient IDs with 001, e.g. 001_000001, 001_000002, 001_000003 etc.

Service Request ID links using the Referrals table, which is table number 101 in the MHSDS. So you could start all your Service Request IDs with ‘101_’.

The same is true for Care Contact ID (201) and Ward Stay ID (502), among others.

The downside to this method in comparison to Example 1 is that the IDs don’t tell you at a glance which patient they relate to. You have to be sure that you can relate the correct records to the correct patient and referral, because you enter this information in the submission. 

A null submission is when you have no activity in the reporting period and can be completed by ticking the “Null submission” box on the SDCS Cloud portal. Activity may include new referrals or care contacts that occur in the month. If you have open referrals, but no activity that occurred during the month, this counts as a null submission. This is because all of the dates associated with the open referrals will be outside of the reporting period, and therefore not accepted as a valid MHSDS submission. We would only expect this in specific situations, such as a school-based service that only runs during term time, or a small Voluntary Care Sector provider with very few patients.

There is already an excellent visual guide to this process so we won’t repeat it here:

Submitting data with SDCS Cloud

If your submission is rejected, please read the validation reports and data quality section for trouble shooting advice.