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 local authorities have provided feedback that despite best endeavours, an individual could have more than one local authority ID. As such, this could lead to over-counting and the issue may be prevalent in some local authorities 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 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 (such as Events falling in scope of Q1 23/24 by local authority) 4 rows appear in the data with IDs as follows:

*as of October 2023 field is 100% populated in CLD

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+ age bands.

As more submissions are made by local authorities over time, scenarios will arise where an Event submitted as ‘open’ (that is to say, 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.

ImportDate 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 the processing will consider all records submitted by the local authority.

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 = 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)