Summary of main concepts

There are a number of identifiers that could be used to calculate the total number of unique individuals.

The NHS Number pseudonym not only allows distinct individuals to be identified but also allows for onward linkage. However, this number is missing from a number of records, with completeness often varying depending on event type. There are also those drawing on care and support who may not have an NHS number, with analysis of the submissions showing this is more likely among Gypsy, Roma and Traveller communities.

Local authorities submit a local unique identifier field however LAs have provided feedback that despite best endeavours, an individual could have more than one LA ID. As such, this could lead to over-counting and the issue may be prevalent in some LAs more than others.

As it is likely that the first approach will under-report, and the second over-report, a hybrid methodology has been developed where NHS number is used in the first instance as a nationally recognised identifier, then local authority ID used where NHS Number is missing to increase coverage (but hasn’t already been present associated with an existing NHS number record). This approach incorporated feedback from our local authority working group to maximise coverage whilst minimising double counting however it is acknowledged that in a small number of cases (0.16%), where no distinct ID can be reliably found, event rows may be removed from subsequent analysis.

There are slight differences with the methodology used in the Department of Health and Social Care (DHSC) local authority dashboard and monthly statistics which adopts a simplified approach however the two are broadly aligned.

Worked example showing ID allocation and scenario leading to event removal

Once time period is filtered by the code for each local authority (for example events falling in scope of quarter1 23/24 by local authority) four rows appear in the data with IDs as follows:

Date of birth is removed from the pseudonymised view for disclosure purposes however to provide insight by age, a more precise metric than ‘derived age at event start date’ is required. This is particularly important for any metrics based on previous SALT definitions where the totals were calculated based on the date at the end of the reporting period. Derived Birth Month and Birth Years are available, and so a proxy date of birth is created, DDMMYY using the first day of the month as DD, the derived birth month as MM and derived birth year as YY. The difference between the date of interest and this proxy date of birth is calculated to derive an age at any given point in time.

Analysis has shown a notable proportion of clients aged 115 and older, possibly influenced by dummy dates of birth in the source data. These may have always been included in the 65 and over category however this cohort will become more prominent once age analysis is undertaken beyond the traditional 18-64 and 65 plus age bands.

As more submissions are made by LAs over time, scenarios will arise where an Event submitted as ‘open’ (i.e. no Event End Date) is superseded in a more recent submission by an Event row containing an End Date. This has been accounted for and factored into the methodologies, with Events being removed from the analysis cohort if a recently added Event End Date means it no longer falls within the scope of the time period. This is done by selecting the latest submission covering the period of interest. For 2023/24 data, this will be as follows:

Find the latest submitted Import File for each Local Authority for the period of interest, within the submission window.

• import date after 31/03/2023 and before 01/08/2024
• reporting period start date on or before 01/04/2023
• reporting period end date on or after 31/03/2024

For some metrics, which need to consider records across reporting periods, it will not be possible to use the latest submission, and so they will consider all records submitted by the local authority.

This technical document is aimed to support users of Client Level Data (CLD) who are familiar with SALT, and therefore looking to recreate metrics in a comparable way. As such, it assumes a level of familiarity with SALT principles, however for completeness, some of the key concepts referred to in this document are detailed here.

New clients are defined as those not in receipt of long-term support at the time the event of interest started. For example, for requests from new clients, this is identified by whether the event start date of the request occurred on or after the event start date of a long term service, and before or on the event end date of the service.

Where multiple services are provided within a year, or multiple services running in parallel, SALT uses a hierarchy to avoid double counting. Further details can be found in the SALT collection guidance.

The following general principles are applied in order when trying to identify the sequel to an event:

1. Identify all subsequent events within a given number of days, if no subsequent events exist then the event outcome is used as the sequel (see appendix for mapping tables):

1. Requests – all activity within 28 days of the request
2. ST-Max for new clients – all activity within 3 days of the ST-Max event

2. Where subsequent activity exists within the given number of days, any events occurring within 3 days of each other are grouped together and considered related.

3. If a service event is found in the subsequent events then service type is used as the sequel (see mapping table)

4. If the same event is found to one which the sequel is being derived for (for example a request event is found when looking for the sequel to a request), then the original event is removed and the second event is retained, following the steps above.

5. If a non-service event is found which isn’t the same event type as the event which the sequel is being derived for (for example an assessment or review when deriving the sequel to the request) then event outcome is considered:

1. If the event outcome of the non-service event equals NFA or Progress to End of Life Care then this is used as the sequel.
2. Otherwise the event outcome of the original event which the sequel is being derived from is used as the sequel (see appendix for mapping tables).

This document reflects the approaches that will be used when calculating the CLD equivalent of the ASCOF measures for 2023/24, for comparison purposes. The Department of Health and Social Care (DHSC) may consider improving and broadening certain definitions for future updates, where CLD makes this possible. Ongoing feedback is therefore welcomed to help inform the development of the measures for future years.

Local authorities and other stakeholders can continue to send queries about the guidance and specification to [email protected].

The NHS Arden and Greater East Midlands Commissioning Support Unit (AGEM CSU) team can be contacted at [email protected].