Official Statistics

Adult social care activity report 2024 to 2025: methodology

Published 23 October 2025

Applies to England

Introduction

This document outlines the methodologies and detailed data processing steps for creating activity measures from client level data (CLD), previously submitted by local authorities through the annual short and long term (SALT) return. The methods build upon the central transformation principles developed by NHS England.

Working with local authorities through the CLD reference group, the measures have been adapted based on feedback to improve accuracy and comparability with SALT derived figures and to minimise the impact of known data quality issues. Nevertheless, CLD derived measures are not expected to perfectly match SALT equivalents given the change in the data source, particularly the change in method of collection from aggregate to event level reporting.

This methodology represents our best efforts to measure activity using CLD to date. However, CLD remains a relatively new data source, and we continue to engage with local authorities and receive feedback on uses of the data, including development of new measures of activity not previously captured in SALT.

Further refinements to the methods may therefore be considered in the future, where it is deemed necessary.

Common data processing steps

1. Processing the data for analysis

There are 2 methods of selecting and processing CLD submissions, depending on the data required for analysis:

• single submissions for analysis requiring data covering a period of 12 months
• joined submissions for analysis requiring data covering more than 12 months

Joined submissions are required for the calculation of measures where definitions and/or selection of cohorts rely on information before or after the statistical reporting year, about individuals’ care and event histories, for example, identifying ‘new’ clients.

The main processing steps in production of these tables are:

• selecting submissions covering the required analysis period and filtering the data to events ending in the period and services ongoing during the period
• data cleaning of priority fields (see table below) - invalid values are replaced where the equivalent valid value can be confidently identified
• amending event end dates - to match the date of death where this precedes the service end date, or to match the reporting period end date where the service end date appears to have been erroneously left blank (the service has a blank end date in one submission but is not included in the next submission)
• selecting cohorts - all measures in the activity report exclude carer related events by only including data with the client type ‘service user’. The requests measure is an exception as those with client type of ‘service user’ and ‘unknown’ client type are included. The statistics also only include people aged 18 and over so people are removed where they are younger than 18 at the time of the event
• selecting submissions:
  • single submissions - data is selected by taking the latest submission. The reporting period stated in the submission is used
  • joined submissions - data is selected by combining submissions with prior periods going back to 1 April 2023. The reporting period stated in the submission is not taken as given, instead it is derived by checking the data in each submission
  • deduplication - the table below lists the fields used to determine unique events. For requests, assessments and reviews, the fields used to produce the joined submissions and single submissions tables are the same. For services, some additional fields with time varying information that could change between submissions (delivery mechanism, costs and units) are only used to identify unique service events in the single submissions table

Table 1: fields used in the deduplication of data sets

	Requests	Assessments	Services	Reviews
LA code	Yes	Yes	Yes	Yes
Derived person identifier (NHS number, unless missing then local authority identifier)	Yes	Yes	Yes	Yes
Event start date	Yes	Yes	Yes	Yes
Event end date	Yes	Yes	No	Yes
Client type	Yes	Yes	Yes	Yes
Request: route of access	Yes	No	No	No
Assessment type	No	Yes	No	No
Service type	No	No	Yes	No
Service component	No	No	Yes	No
Single submissions table only	No	No	No	No
Delivery mechanism	No	No	Yes	No
Unit cost	No	No	Yes	No
Cost frequency (unit type)	No	No	Yes	No
Planned units per week	No	No	Yes	No

2. Creating person identifiers

The anonymised person identifier used throughout the activity statistics is the pseudonymised traced NHS number in the first instance. If this is missing, the pseudonymised local authority provided NHS number is used. If both NHS numbers are missing, the local authority unique person identifier is used.

3. Cleaning the data

For variables in the CLD data specification that have a defined list of values, efforts have been made to replace invalid values where there is a clear corresponding valid value. Those invalid values that cannot be validated are recorded as unknown. The ‘CLD data specification’ is in the ‘ASC CLD specification’ section of the AGEM CLD information pages for local authorities.

4. Identifying latest person details

A data set is created which contains the most recent known details for each individual in CLD, across a range of demographic and service-related characteristics. The data set supports person-level analysis by selecting a single, consistent record per individual for a given reporting period.

Cohort

The data set includes individuals who appear in the joined submissions table with any valid event type and either an NHS number or a unique local authority person identifier.

Fields included in the latest person details

For each person in scope, the latest known value is derived for the following fields:

• gender
• ethnicity
• date of birth
• date of death
• employment status
• accommodation status (with imputation logic, described below)
• carer status (based on linked carer records, and the ‘has unpaid carer’ field)
• primary support reason
• age and age bands
• client funding status

Deriving the latest known information

The latest details for each person are selected by applying the following prioritisation:

• known values are preferred over unknown or null values
• if multiple known values exist, the value associated with the most recent submission reporting period is selected
• if multiple values continue to exist, the value associated with the most recent event end date is selected (with nulls prioritised)
• if multiple values continue to exist, the value associated with the most recent event start date is selected
• if multiple records remain after these steps, the final value is classified as ‘unknown - conflicting’, except for age, where the earlier birth date is chosen, and date of death, where the later date is chosen, for conservatism

Special handling of accommodation status

Additional logic is applied to accommodation status for people whose most recent records are marked as ‘unknown’ or if the records are determined unknown because they are conflicting. For these individuals the most recent service type and service component values are used to infer likely accommodation type where possible.

Examples include:

• if the latest service type is long term: nursing care, the accommodation status is reported as ‘registered nursing home’
• if the person is receiving long-term support in the community with a service component of housing support, the accommodation status is recorded as ‘unknown - at home’
• if the person is receiving long-term support in the community without an identified housing-related component, the accommodation status is recorded as ‘unknown - community’

Carer identification

To identify whether an individual has an unpaid carer, the following 2 fields are checked:

• ‘has unpaid carer’
• unique person identifier, which is checked against any of the 3 possible adult linked personal ID fields in the carer data. If a match is found, the individual is flagged as having an unpaid carer, overriding the entry in the ‘has unpaid carer’ field

Age and age bands

Age is calculated by taking the difference between the individual’s date of birth and the event end date (or reporting period end date if the event end date is null), producing an age at event end date field. Individuals are then grouped into standard age bands as required for downstream analysis.

Data output

The final output is stored as a central latest person details database, which can then be joined to other measure-specific tables using the unique person identifier to pull through person information.

Note, not all measures require or use every field from the latest person details table. Which fields are utilised depends on the requirements of each specific measure and whether the latest details are appropriate.

5. Estimating totals to account for missing data

Where a local authority has not submitted any data for a specific event type, estimates of the missing data have been used to calculate regional and national totals. For the financial year 2024 to 2025, this affects STS002a and STS002b with 4 local authorities missing ST-Max events in their data.

We’ve imputed missing values using last year’s SALT data (financial year 2023 to 2024). For each age band, we worked out what proportion of events local authorities with missing data (this year) contributed to the total from SALT (last year). We then applied these proportions to the CLD totals for 2024 to 2025 to estimate figures for the missing authorities. These estimates feed into the regional and England-level totals.

The calculation is:

• scaling factor equals 1 plus (SALT 2023 to 2024 totals by age band for missing authorities) divided by (England SALT 2023 to 2024 age band totals minus missing authority totals)
• England total estimate equals scaling factor multiplied by CLD 2024 to 2025 England total

Requests for support (STS001)

Requests for support (STS001) records the numbers of requests for support received from ‘new’ clients, broken down by the different sequels to that request. 

STS001 cohort

This measure counts the number of requests for adult social care support made by or on behalf of people aged 18 or older, who have not received long-term support in the previous 3 months. The measure also counts the number of people that these requests relate to. The following steps are taken to select the relevant events: 

1. Using the joined submissions table (see ‘Processing the data for analysis’ in the ‘Common data processing steps’ section above) requests are selected where the recorded event end dates are within the statistical reporting year of interest.
2. These request events are included where the age at the event end date is 18 or over and the client type field does not actively indicate that the request is for a carer.
3. Request events that occur within 7 days of one another are treated as part of the same request for support for an individual. In these cases, the events are combined such that the earliest event start date and latest event end date among the events is used. All remaining event details are taken from the event with the latest event end date.
4. Requests are then excluded if the individual had an active long-term support event in the 91 days prior to the request start date.

Request events are combined as described above because it is assumed that these events are likely to be related to the same request for support. 

STS001 breakdowns including sequels to requests 

Requests for support (STS001) is broken down by the route of access recorded for the event, age group and the 3-month sequel to the request. This is determined using the events which occurred during the 3 months after the request ended, alongside information captured in the event outcome field. The following events are used to identify the 3-month sequel: 

• events that occur within 91 days of the request end date or before the start date of a subsequent request if this occurs in the 91-day period
• carer services are not considered

The hierarchy below is applied to categorise the 3-month sequel:

1. Where someone has died and the date of death is within 7 days of the request end date, the sequel is ‘NFA: deceased’ (NFA means no further action).
2. Where a service is provided, the type of service is given as the sequel. In the case of multiple eligible services, the service type hierarchy table (see appendix 1) is used to determine the service type.
3. Where there is no subsequent service during the 3 months, either the event outcome of another event which follows the request is used or the event outcome of the original request. A hierarchy is used to determine which event outcome provides the most useful information (see table in appendix 2).
4. Where there is no subsequent event during the 3-month period following the request, the event outcome of the request is used.

Wherever there is conflicting information about event outcomes across records, a hierarchy is applied to select the sequel (see appendix 2). To identify the route of access, the information is taken from the most recent request event within the cluster. If the most recent is blank then the second route of access in the cluster will be considered until all requests in the cluster have been checked.

Using CLD to determine the sequels presents some challenges. Some local, contextual information is not included in CLD, that may previously have been used by local authorities to help determine the most appropriate sequel to report through SALT. The national methodology described here for determining the sequel in STS001 was created in consultation with local authority analysts, to balance the risk of missing important outcomes with the risk of incorrectly connecting unrelated events. The 3-month sequel was implemented as the best compromise.

When considering sequel categories, CLD offered more choices around what sequels could be considered given the data is event level. For ease of use, the following event outcomes have been aggregated into the category ‘services not provided’:

• NFA - no services offered: other reason
• NFA - other
• NFA - support ended: other reason
• NFA - support declined

In CLD, there is the opportunity for local authorities to use an event outcome that starts with ‘progress to’ when it is thought at the time of the request that the user will move onto a further event. Some pathways may also be incomplete where records of subsequent support have not been provided in CLD. When no subsequent event record is then found for that service user within the 3-month time period, they have been placed in a category called ‘NFA - outcome stated and not found’. The event outcome ‘no change in package’ has also been included in the ‘NFA: outcome stated and not found’ category. Unknown sequels refer to requests with no useable information with which to assign a sequel.

Short-term support to maximise independence (STS002)

The short-term support to maximise independence (ST-Max) measure records the number of episodes of ST-Max provided to people aged 18 or older within the statistical reporting period, broken down by what happened over the next 7 days.

STS002 cohort

This measure counts the number of episodes of short-term support to maximise independence (ST-Max) provided to people aged 18 or older:

• STS002a only includes events relating to people who have not received long-term support in the previous 3 months (‘new’ clients)
• STS002b only includes events relating to people who are in receipt of long-term support at the start of the ST-Max episode, or who received long-term support in the previous 3 months (‘existing’ clients)

The following steps are taken to select the relevant ST-Max events: 

1. Using the joined submissions table (see ‘Processing the data for analysis’ in the ‘Common data processing steps’ section above), ST-Max events are selected where the recorded event end dates are within the statistical reporting year of interest.
2. ST-Max events that occur within 7 days of one another are treated as part of the same ST-Max ‘episode’, creating a cluster of ST-Max records. The episode start and end dates are identified with the earliest event start date and latest event end date among the constituent records. All remaining cluster details are taken from the record in the episode with the latest event end date, and if there is a tie, a hierarchy is applied to the event outcome field to determine the sequel (see appendix 2).
3. ST-Max events are:
   • excluded from STS002a if the individual had an active long-term support event in the 91 days prior to the ST-Max (also known as reablement) episode start date
   • included in STS002b only if the individual has an active long-term service open at the time of the reablement or has had an active long-term support event in the 91 days prior to the reablement episode start date

Note: in SALT, it was required that ST-Max episodes counted in this measure should have a prior request, counted in STS001. The data coverage has shown us that local authorities have very different internal procedures and recording practices for requests into reablement. Therefore, in consultation with local authorities, the requirement for prior requests for ST-Max episodes has been removed. Where there is a prior request, this will still be linked and the route of access reported. A missing prior request will mean that the route of access will be reported as unknown.

STS002 breakdowns

ST-Max episodes are broken down by:

• age band
• primary support reason
• whether the person has an unpaid carer
• route of access

STS002a is also broken down by ethnicity and 7-day sequel. STS002b is also broken down by a 7-day sequel. All breakdowns are derived directly from the fields of the ST-Max episode except ‘has unpaid carer’, which is derived from the latest person details, route of access and the respective sequel categories, which are described below.

Determining 7-day sequels for new clients (STS002a)

For the purposes of STS002a, sequels describe the immediate outcome after reablement. They are used to identify whether a person went on to require further immediate support or whether their reablement successfully helped them regain independence at the end of the reablement. Sequels are identified by considering the services that occurred during the ST-Max episode and in the 7 days after the reablement ended, as well as the information captured in the event outcome field of any assessments or reviews.

The 7-day period was used to ensure that subsequent events that were not directly related to the ST-Max were not included and that the measure is focused on short-term outcomes only. This was agreed in consultation with the CLD reference group. Any event that takes place after the 7-day period will not be used to derive sequels, so it is possible that genuine events relating to the ST-Max events that take longer to occur will be missed. However, the risk of including sequels that were not a direct outcome of the reablement was considered greater if we extended beyond 7 days so, on balance, this period was agreed with the local authority reference group to be optimal.

The procedure used to determine the sequel to the ST-Max episodes is as follows:

1. If there is a date of death prior to, or within 7 days of the end of the ST-Max episode, then set the ST-Max sequel is ‘No further action: deceased’. Otherwise, continue to step 2.
2. If the ‘Event outcome’ field of the ST-Max episode is ‘Admitted to hospital’, then the sequel is set to ‘Admitted to hospital’. Otherwise, continue to step 3.
3. If there is a service open within the 7 days after the ST-Max end date, that started after the ST-Max start date, then the sequel is the ‘service type’ of that service. If there is more than one such service, then the hierarchy listed in appendix 1 is applied to choose one of them to be the sequel. If no services are found, continue to step 4.
4. Consider the ‘Event outcome’ fields of: (a) the ST-Max episode, (b) any non-service events that take place within 7 days after the ST-Max episode (reviews, assessments, requests), and (c) any assessments or reviews that take place while the ST-Max episode is ongoing, and within the 2 weeks prior to the ST-Max end date. If any of these are ‘concluding’ event outcomes (see appendix 2), then the event outcome with the highest rank in the hierarchy in appendix 2 is chosen as the ST-Max episode sequel. If no ‘concluding’ event outcomes are found, continue to step 5.
5. If equipment was delivered during the ST-Max episode, then the ST-Max sequel is set to ‘Short term support: Ongoing low level’. If not, continue to step 6.
6. A concluding sequel has not been found, and no further action has been found. The sequel is set to ‘No further action - reason not found’.

Notes on the above procedure:

• a ‘concluding’ event outcome is one where a definitive outcome can be determined (see appendix 2)
• when the sequel event ‘service type’ is ‘short term support: other short term’, and the ‘service component’ is ‘short term nursing care’, or ‘short term residential care’, the sequel designation of ‘short term support: residential or nursing care’ is attributed to that episode. For all other values of ‘service component’ with this service type, the sequel designation ‘short term support: other short term’ is attributed to the episode
• sequels with an ‘unable to classify’ event outcome (for example, outcomes derived from the last box in the flow chart) are designated as ‘no further action: reason not found’

Deriving sequels describing changes in support for existing clients (STS002b)

For existing clients included in STS002b, the sequel describes the change in support before and after the ST-Max episode. Some examples include:

• move to nursing care from community
• move to residential care from community
• no change in long-term support

To derive these, the identification of existing and/or prior long-term support is required, as well as the 7-day sequel calculated using the same method as in STS002a. The existing and/or prior long-term support settings is identified from long-term service events in the previous 91 days. If more than one long-term service event is found in that period, the service with the latest end date is picked to provide the information. If there are ties, or multiple services that are open at the time of the reablement, the hierarchy for long-term services is applied (see appendix 1).

Determining the route of access

The route of access is determined from request events that occur within the 91 days prior to the start of the ST-Max episode. If another ST-Max episode exists in the 91-day period, the search for a prior request is restricted to only the period between the reference ST-Max episode, and the latest ST-Max episode found in the 91-day window, to avoid attributing requests to more than one ST-Max episode. A significant proportion of ST-Max episodes are missing such a prior request, and in these cases, the route of access is recorded as ‘no prior request found’. If more than one request record is found in this period, the request with the latest end date is chosen to provide the route of access information.

Older people still at home 91 days after discharge (STS004)

The STS004 measure records the proportion of older people (65 and over) who were still at home 91 days after discharge from hospital into reablement and/or rehabilitation services.

This measure cannot be replicated with the information available in CLD and it will not be used to calculate the ASCOF 2D measure. A replacement for ASCOF 2D is under development and more information will be shared in due course. In the meantime, see more information on ASCOF 2D in the Adult social care outcomes framework (ASCOF): handbook of definitions.

Long-term support (LTS001)

This measure counts the number of people over the age of 18, who accessed long-term support at various times.

LTS001 cohort

This measure counts the number of people over the age of 18, who accessed long-term support:

• at any time during the statistical reporting period (LTS001a)
• at the end of the statistical reporting period (LTS001b)
• continuously during the 12-month statistical reporting period (LTS001c). This includes people who have a single continuous long-term service event starting on or before the statistical reporting period start date and ending on or after the statistical reporting period end date. It also includes people who have a chain of long-term services spanning that period, which are either overlapping, or within 7 days of each other

This 7-day allowance is to ensure people are not excluded where they are considered ‘on the books’ continuously, but their service events are paused and restarted within a short period.

LTS001 breakdowns

People in each measure are assigned to an appropriate:

• age band
• primary support reason
• service type
• delivery mechanism
• funding status

LTS001b also includes breakdowns for:

• support from unpaid carer
• gender
• ethnicity

Using the below assignment criteria, each person will only be included once per category.

This assignment to a category is achieved as follows:

1. Select all events where the service type is one of the long-term support categories and the service is active at any time during the statistical reporting period.
2. If there is more than one such long-term service for the same individual, the service with the highest ranked service type is chosen. If there are still ties, the following fields are used to determine which record to choose:
   • service type (hierarchy applied - see appendix 1)
   • delivery mechanism (hierarchy applied - see appendix 3)
   • event start date (latest)
   • event end date (latest - open services are considered the latest)

The person’s age at the end of the statistical reporting period is used. The delivery mechanism is categorised as a direct payment if a ‘direct payment’ is found in either the delivery mechanism CLD field, or the service component CLD field.

Reviews of long-term care and support plans (LTS002)

This measure counts the number of unplanned and unplanned reviews a person receiving long-term support gets at various times.

LTS002 cohort

LTS002a counts the number of unplanned reviews where the person had received long-term support at some point during the statistical reporting year. It also counts planned reviews that led to a care home admission in this cohort. The following process is used to identify the relevant events:

1. Using the joined submissions table (see ‘Processing the data for analysis’ in the ‘Common data processing steps’ section above):

• events for individuals who have received long-term support during the year are selected in LTS002a (see the LTS001a methodology above)
• events for individuals who have received long-term support consistently throughout the reporting year are selected in LTS002b (see the LTS001c methodology above)

2. Review and long-term assessment events are then selected where the individual had received long-term support at any point in the 91 days prior to the review or assessment start date.

3. These review and assessment events are then combined where the dates of the events are within 7 days of one another. In these cases, the events are combined such that the earliest event start date and latest event end date among the events is used. The review is categorised as unplanned if any of the events included are unplanned reviews (based on review reason field).

Long-term assessment events are counted as reviews in these statistics because reassessments are used in the place of unplanned reviews by some local authorities for people receiving long-term support.

LTS002 breakdowns 

These statistics are broken down by: 

• support setting the individual is in prior to the review
• change in support following the review
• whether the review was planned or unplanned
• age band (18 to 64 years and 65 years and over)
• the significant event leading to an unplanned review

Categorisation of support setting 

The support setting (residential care, nursing care, prison or community) is based on the long-term services that are active at some point in the 91 days prior to the review. Where multiple services start before the review, they are first ranked according to when the services ended: services that are ongoing when the review starts are prioritised above those that finish prior to the start of the review. Following this, where there are still multiple services in consideration, the hierarchy in appendix 1 is used to categorise the support setting. 

For example, if someone is recorded as having long-term community support services (based on service type field) as well as long-term residential care in place at the time of the review start, their support setting will be categorised as ‘residential care’. 

Determining a change in support setting 

To determine whether a client has a change in setting following a review, all future events are considered up until the client’s next review. The events during this period are ranked first according to event end date, and then by the support setting hierarchy (see above). The aim of this process is to find out where the client is at the time of their next review and determine whether they have changed setting or not. If there is no next review, the most recent support setting is used, applying the support setting hierarchy as above if necessary.

If no further services are recorded after a client’s review, the sequel is categorised as ‘all long-term support ended’. 

Where the support setting after the review is the same as before the review, this is categorised as ‘no change in setting’. However, where an ST-Max event occurs after the review and before the next review, the sequel is categorised as ST-Max.

Review type 

Review type is reported in CLD returns under the review reason field, distinguishing between planned and unplanned reviews. This is used to provide breakdowns for these statistics. Note that where assessment events are included, these are not categorised as either planned or unplanned but are included in totals.

Significant event

Unplanned reviews are further broken down by the reasons given in the review type field in CLD returns. This is not relevant for planned review and assessment events.

Unpaid carer support (LTS003)

This measure records unpaid carer support provided during the year, broken down by the age of the carer and the type of support provided.

Following our review of the July CLD submissions, the national number of unpaid carers recorded in CLD for 2024 to 2025 remains significantly below the figure reported through SALT 2023 to 2024. There is particularly poor coverage of universal services.

To avoid misinterpretation, this year’s official statistics will exclude CLD measures of local authority support for unpaid carers.

Accommodation and employment status of people receiving long-term support (LTS004)

This measure has been expanded to record the accommodation and employment status of long-term support recipients by age band and primary support reason. The age bands are:

• aged 18 to 64
• aged 65 and over

Previously, employment status breakdowns only concerned adults aged 18 to 64 with a learning disability who were receiving long-term support.

LTS004 cohort

LTS004 uses the same cohort as LTS001a. This counts the number of people accessing long-term support during the statistical reporting year broken down by primary support reason, age band and gender. It also includes information on employment status and accommodation status, both derived from the latest person details.

LTS004 breakdowns 

For each person within scope, the most recent valid information is taken from the latest person details. The latest person details section provides a detailed explanation of how the most recent data is derived, including the special approach used for accommodation status.

The following breakdowns can be found in LTS004:

• accommodation status (see appendix 4)
• employment status
• gender
• primary support reason

Appendix 1: service type hierarchy

Service type	Rank
Short-term support: ST-Max	1
Long-term support: nursing care	2
Long-term support: residential care	3
Long-term support: community	4
Long-term support: prison	5
Short-term support: ongoing low level	6
Short-term support: other short term	7

Appendix 2: event outcome hierarchy

Event outcome	Rank
Admitted to hospital	1
NFA - moved to another local authority	2
NFA - 100% NHS-funded care	3
NFA - self-funded client (including 12-week disregard)	4
NFA - information and advice and/or signposting only	5
NFA - support declined	6
NFA - deceased	7
Service ended as planned	8
NFA - support ended: other reason	9
NFA - no services offered: other reason	10
NFA - other	11
Progress to reablement/ST-Max (see note)	12
Progress to assessment (see note)	13
Progress to re-assessment and/or unplanned review (see note)	14
Progress to financial assessment (see note)	15
Progress to support planning and/or services (see note)	16
No change in package (see note)	17
Provision of service (see note)	18
Progress to end of life care (see note)	19

Note: this hierarchy matches that outlined in the CLD collection guidance. For the purposes of determining sequels for STS001 and STS002, these intermediate outcomes are considered ‘unable to classify’ as it cannot be determined whether or not further long-term support was required. For this reason, these event outcomes are deprioritised over other event outcomes when determining the sequels. The ‘CLD collection guidance’ is in the ‘ASC CLD specification’ section of the AGEM CLD information pages for local authorities.

Appendix 3: delivery mechanism hierarchy

Service type	Rank
Direct payment	1
CASSR managed personal budget	2
CASSR commissioned support	3

Appendix 4: accommodation status mapping

Accommodation status	Supported group	At home group
Approved premises for offenders released from prison or under probation supervision	Supported	Living at home or with family
Shared lives scheme	Supported	Living at home or with family
Sheltered housing, extra care housing, other sheltered housing	Supported	Living at home or with family
Supported accommodation, supported lodgings, supported group home	Supported	Living at home or with family
Mobile accommodation for Gypsy, Roma and Traveller communities	Unsupported	Living at home or with family
Owner occupier or shared ownership scheme	Unsupported	Living at home or with family
Settled mainstream housing with family, friends	Unsupported	Living at home or with family
Tenant	Unsupported	Living at home or with family
Tenant - private landlord	Unsupported	Living at home or with family
Unknown - presumed at home	Unknown	Living at home or with family
Prison or young offenders institution, detention centre	Supported	Not living at home or with family
Registered care home	Supported	Not living at home or with family
Registered nursing home	Supported	Not living at home or with family
Acute or long-term healthcare residential facility or hospital	Supported	Not living at home or with family
Night shelter, emergency hostel, direct access hostel	Unsupported	Not living at home or with family
Other temporary accommodation	Unsupported	Not living at home or with family
Placed in temporary accommodation by the council (including homelessness resettlement)	Unsupported	Not living at home or with family
Refuge	Unsupported	Not living at home or with family
Rough sleeper, squatting	Unsupported	Not living at home or with family
Staying with family, friends as a short-term guest	Unsupported	Not living at home or with family
Unknown - presumed in community	Unknown	Not living at home or with family
Unknown	Unknown	Unknown

Appendix 5: service information mapping to accommodation status

The below mapping is used when a person’s accommodation status is unknown, to try to deduce their accommodation from the services received. If a person is in receipt of multiple services, then a hierarchy is applied in the order they are listed below.

Service type	Service component	Mapped accommodation status	Living at home or with family
Long-term support: nursing care	Any	Registered nursing home	No
Long-term support: residential care	Any	Registered care home	No
Any	Extra care housing	Sheltered housing, extra care housing or other sheltered housing	Yes
Any	Shared lives	Shared lives scheme	Yes
Any	Community supported living	Supported accommodation, supported lodgings, supported home group	Yes
Long-term support: community	Any	Unknown - at home	Yes
Long-term support: prison	Any	Prison, young offenders institution, detention centre	No

Appendix 6: methodology for the long-term user number time series by support setting

DHSC analysts have developed a time series to handle irregularities caused by changes in the data collection and presentation over time of local authority provided or organised social care user numbers. The methodology creates a long-term view of user data from 2003 to 2004 onwards, categorised by age group and support setting. The methodology set out here, especially the assumptions and caveats, should be taken into account when using this time series. 

This data shows the number of local authority provided or organised long-term support users from 2003 to 2004 to present categorised by age group and support setting and is published in table 60 of the accompanying data tables on the Adult social care activity report, England: 2024 to 2025 page.

This data can be used for monitoring trends in local authority provided or organised user numbers over time at a national level. 

Data 

The methodology to produce the time series data table (table 60 in the accompanying data tables) uses the LTS001b metric from adult social care activity statistics and previously SALT data which is defined as the number of people accessing long-term support at the year end (31 March) by age band and support setting.

Before the SALT data collection was created in 2014 to 2015, activity was collected in the referrals, assessments and packages of care (RAP) collection, where the data comes from the metrics:

• P2s.1a - number of clients on the books to receive community-based services on the last day of the period, by primary and secondary client type, for the community care figures
• S1 - council-supported residents at 31 March by type of accommodation and client group for the residential and nursing support setting

There were various changes in the RAP collection over the time it was collected. The full details are available on page 96 of the PDF report of NHS England’s Community Care Statistics, Social Services Activity, England - 2013-14, Final release.

In 2009 to 2010, the columns on the RAP metrics P2f and P2s labelled ‘direct payments’ were expanded to include ‘existing and new direct payments and personal budgets’. Service users who were receiving council-commissioned services through a personal budget or direct payment were only included under this heading and not under the ‘specific service received’. This has impacted the data in this publication during that year. The ‘existing and new direct payments and personal budgets’ category in 2009 to 2010 is assumed to be similar to the ‘direct payments’ category in other years. 

Another notable data change for this publication was in 2010 to 2011 when the ‘existing and new direct payments and personal budgets’ column in the P2s metric were changed to record direct payments only, whether delivered through a personal budget or not. All other P2s components of service columns were altered to count clients receiving the given service as a council-commissioned service, whether or not this was through a personal budget. This will have impacted the community category in our methodology from 2009 to 2011. 

The data up to 2013 to 2014 in table 60 is completed to match ‘Annex M - Compendium 2000-01 to 2013-14’ of NHS England’s Community Care Statistics, Social Services Activity, England - 2013-14, Final release. The data in annex M was compiled in 2013 to 2014. Some of the data in the compendium does not match the published data for individual years due to changes in rounding practices.  

Coverage 

The figures included in the time series data tables are year-end (LTS001b in the activity statistics) and while the methodology could be applied to in-year data (LTS001a in the activity statistics), DHSC has not done any analysis to confirm it would be the best methodology for in-year data. 

Prison settings are not included in table 60 as this data item was added as a voluntary measure in 2015 to 2016 and we do not have any estimates for user numbers in this support setting before this time.

Method of dealing with data changes 

Before 2014 to 2015, the community care setting total includes the total users from home care, day care and direct payments, from the metric P2s.1a in the RAP collection. The residential care total refers to the sum of the independent residential and council-run care home figures in S1 metric in RAP. The nursing care total is the independent nursing total in the RAP. 

From 2014 to 2015 onwards, the community care setting total care is the total users from any care setting prefixed with the word community in LTS001b. From 2014 to 2015 until 2023 to 2024 the nursing and residential care settings categories were the same as published in SALT.

For 2024 to 2025, CLD was used to replicate the LTS001b SALT data structure. This involved mapping CLD fields to SALT definitions for long-term support at year end by age band and support setting. To ensure continuity and validate CLD’s ability to replicate SALT, a dual running approach was adopted for 2023 to 2024. While the replication aimed to maintain consistency with previous years, users should note any methodological adjustments or limitations outlined in this document. 

CLD-derived metrics do not perfectly match SALT equivalents due to differences in data structure and collection methods. SALT aggregated counts, while CLD tracks individual events. 

Changes in 2024 to 2025: 

• transition to CLD for long-term support figures
• recreation of SALT LTS001b structure using CLD
• continued exclusion of prison settings and small number suppression

The totals in the data tables are basic sums of the rows displayed, therefore these are not the published totals that coincide with the activity statistics, SALT or RAP due to both rounding to suppress small numbers and the removal of the prison setting category.

This methodology was developed by DHSC, iteratively trying various other more complex methodologies. All other methodologies created unusual trends that could not be accounted for and could only be assumed to be artefacts of the methodologies themselves. The methodology used here was discussed with colleagues in:

• Local Government Association
• Association of Directors of Social Services
• NHS England
• Ministry of Housing, Communities and Local Government
• Office for National Statistics
• HM Treasury

All agreed the methodology was the best available given the work DHSC had undertaken. 

Assumptions and caveats 

The categories identified in our methodology to include community users before 2014 to 2015 are assumed to be comparable with the community categories included from 2014 to 2015 onwards. This is an assumption based on the analysis and cross-government discussions outlined above and may not align with reality. 

In RAP, clients who receive multiple community-based services simultaneously will be listed in each service type. Therefore, there will be some double counting of clients within the RAP period of our methodology that is not present in SALT or the activity statistics. This will affect comparability between RAP, SALT and the activity statistics and should be taken into account when using the time series. The double counting in RAP’s community service categories, along with RAP, SALT and CLD being separate data collections, results in a data break in 2014 to 2015 when SALT was introduced and a further data break in 2024 to 2025 when CLD was introduced.