Social Care FHIR Store Mappings
Name | Description | Conformance | Codes & Value Set |
---|---|---|---|
LA CODE | For every row of data, please record the LA code associated with all social care collections e.g. for Lincolnshire, the LA code is503. This will be used to ensure thatall data rows can be attributed to specific Local Authorities, and to derive the Local Authority Name. | M | |
REPORTING PERIOD START DATE | The reporting period start date for the data being submitted. Typically, this will the firstday of the reporting month, quarter, or year | M | |
REPORTING PERIOD END DATE | The reporting period end date for the data being submitted. Typically, this will be last day of the reporting month, quarter, or year | M |
Name | Description | Conformance | Codes & Value Set |
---|---|---|---|
PERSON UNIQUE IDENTIFIER | An LA Client ID – a Person Unique Identifier - can be supplied to identify events for the same person, for whom the NHS number is missing | M | |
NHS NUMBER | NHS Number should be provided, as the national unique identifier for persons, which can be used to link to other data sources. | M | |
FIRST NAME | M | ||
LAST NAME | M | ||
GP PRACTICE NAME | M | ||
GP PRACTICE CODE | M | ||
GENDER | Gender is defined as the gender the individual considers themselves to be. ‘Other’ has been added for clients who do not identify as male or female. ‘Unknown’ should be used where the client’s gender has not been recorded. | M | 2 - Female
1 - Male X - Not known Not stated/recorded (or unborn) Neither |
ETHNICITY | Ethnicity should be completed in line with the current NHS Digital Data Dictionary to vastly improved diversity monitoring to ‘Unknown’ should be used where the client’s ethnicity has not been recorded | M | A - White (English / Welsh / Scottish / Northern Irish / British)
B - White Irish - White (Gypsy or Irish Traveller) C - Any other White background D - White and Black Caribbean E - White and Black African F - White and Asian G - Any other mixed / multiple ethnic background H - Indian J - Pakistani - Bangladeshi - Chinese L - Any other Asian background N - African M - Caribbean P - Any other Black / African / Caribbean background - Arab S - Any other ethnic group Z - Refused 99 - Undeclared / Not known - Other Ethnic Group - Black/African/Caribbean/Black British - Asian/Asian British - Mixed/Multiple - a) WBRI - b) WIRI - c) WIRT - d) WOTH - e) WROM - f) MWBC - g) MWBA - h) MWAS - i) MOTH - j) AIND - k) APKN - l) ABAN - m) AOTH - n) BCRB - o) BAFR - p) BOTH - q) CHNE - r) OOTH - s) REFU - t) NOBT A - White British C - Other White G - Other mixed L - Other Asian P - Other Black S - Other T - White Gypsy or Roma or Traveller or Irish Traveller Z - Not stated 99 - Ethnicity is unknown |
DATE OF BIRTH | "The date of birth should be recorded in a DD/MM/YYYY format, i.e. day/month/year as a four digit number. For Annex A the additional guidance is provided: If an expected birth date is available for an unborn child, enter this date, otherwise leave blank. If no date of birth or expected date of birth is not available, leave blank." | M | |
DATE OF DEATH | Date of death recorded as appropriate. For an individual who is not dead, please input the value | M | |
PRIMARY SUPPORT REASON | The latest known Primary Support Reason (PSR) in the reporting period should be recorded for the service user against each event row. If the PSR is not determined i.e., the service user’s journey does not progress past the request stage, then ‘Unknown’ should be chosen. If a service user receives multiple services for different reasons, the most relevant PSR to each event should be chosen. If a service user is also supported by the local authority as an unpaid carer, the event rows that relate to the support provided to the person as a service user should show the most relevant support reason, and the event rows that relate to the person supported because of their caring role, should have a PSR of Social Support | M | Physical Support: Access & mobility only
Physical Support: Personal care support Sensory Support: Support for visual impairment Sensory Support: Support for hearing impairment Sensory Support: Support for dual impairment Support with Memory & Cognition Learning Disability Support Mental Health Support Social Support: Substance misuse support Social Support: Asylum seeker support Social Support: Support for Social Isolation/Other PSR Not Known Sensory Support Physical Support Social Support No Support Reason Not Known |
POSTCODE | The postcode of the person’s normal place of residence should be recorded alongside all event rows for that client in the return. The postcode will be used to assist with identifying missing NHS numbers and to derive geographical fields to support analysis. Where care services are received at the person’s home, the postcode should reflect that. Where someone now lives in a residential or nursing home, the postcode of the residential/nursing home should be used. The same should also apply to clients who move to an out-of-area residential home; the postcode of the out-of-area residential/nursing home should be recorded. Under these circumstances, the activity should be reported by the CASSR where the person is ordinarily resident, where the LA holds responsibility for the person in an out of county placement. Clients who are placed in care homes temporarily should not use the postcode of the care home, as this has not yet become their normal place of residence. For unpaid carers, it is recognised that caring roles can be across LA borders, so as with above, the postcode of the carer’s normal place of residence should be recorded | M | |
ACCOMMODATION STATUS | This data item is collected for clients with a Learning Disability aged 18 to 64, althoughthere is growing appetite for this to be captured for all adult client groups and age bands. For CLD it is required that the Accommodation Status is linked to the latest known address / postcode. ‘Unknown’ should be used where the client’s accommodation status has not been recorded. | M | |
EMPLOYMENT STATUS | This data item should be prioritised for clients with a Learning Disability aged 18 to 64. Where possible, LAs should also include the employment status of unpaid carers. Where possible, LAs should include the employment status of unpaid carers captured within the reporting period. ‘Unknown’ should be used where the client’s employment status has not been recorded | M | |
HAS NPAID CARER CARER | Formerly – ‘Has Informal Carer’ (changed to better represent the role of unpaidcarers and align with current terminology. This should not affect the data submitted.) Whether the person receives support from an informal carer gives a holistic view of a person's support package. These rules are closely aligned to the Carer Status from SALT LTS001b table 2 but is expected for all event types in the dataset, not just where long term support services are provided to the client. This variable is also relevant for unpaid carers, to determine if they themselves are being cared for. It is recognised that there can be multiple informal carers known to the client and actively providing support. For the purposes of the CLD collection, a value of 'Yes' would indicate that at least one carer is known to the client. ‘Unknown’ should be used where it is not recorded if the carer unpaid or not. | M | |
AUTISM SPECTRUM DISORDER (ASD) | A single variable of ‘Autism Spectrum Disorder (ASD)’ to replace the two ‘Autism’ and ‘Asperger’s Syndrome’ variables. ASD is to be adopted in 2022 by the World Health Organisation (WHO) using the latest version of the International Classification of Diseases (ICD-11). In the Light Touch Review of SALT (2018) the National Autistic Society did not see much value in the existing data capture of Autism and Asperger Syndrome, and owingto updates in diagnostic criteria, these Reported Health Conditions / comorbid conditions no longer matched the emerging single categorisation of ‘Autism SpectrumDisorder’. As with Reported Health Conditions previously reported in SALT, ASD Should be diagnosed and relevant to care needs. ‘Unknown’ should be used where the client’s ASD status has not been recorded | M | |
VISUAL IMPAIRMENT | For the purposes of CLD visual impairment should be recorded for all people who are in scope of the CLD collection. ‘Unknown’ should be used where the client’s Visual status has not been recorded | M | |
HEARING IMPAIRMENT | For the purposes of CLD Hearing impairment is reported for all people who are in scope of the CLD collection. ‘Unknown’ should be used where the client’s hearing status has not been recorded. | M | |
DEMENTIA | Dementia should be reported for every client in scope of the CLD collection. As with Reported Health Conditions previously reported in SALT, Dementia should be diagnosed and relevant to care needs. It is expected that Dementia should be identified from young-onset Dementia to diagnosed conditions such as Alzheimer's disease, vascular dementia, frontotemporal dementia, and more. Mild Cognitive Impairment (MCI) would not be included as the symptoms are not usually severe enough to interfere significantly with daily life. ‘Unknown’ should be used where the client’s Dementia status has not been recorded. | M |
Name | Description | Conformance | Value Set |
---|---|---|---|
EVENT TYPE | Event types which occur in the local authority within the reported timeframe should be captured for service users and carers. This includes: • Requests received in the reporting period. • Assessments and reviews commenced and/or completed in the reporting period. No open or ongoing requests, assessments or review events are required, each row should include an event outcome. • Service events that started or ended within the reporting period, or where the service was open and ongoing at the end of the reporting period. This includes events where the start date was before the start of the reporting period, were open at the end of the reporting period or ended after the reporting period. Service events are the only event type in CLD that can be open and ongoing, with an event start date, but no event end date. • Cancelled events should be excluded from the collection. Suspended services should be included as originally intended. It is recognised that different LA’s have different business rules and practices, but the four key steps in the social care pathway are common to all, with data collected on each aspect reported by LAs at some point in the past. These are Requests, Assessments, Services, and Reviews | M | Request
Assessment Service Review |
EVENT REFERENCE | The event reference facilitates identifying events for data quality reporting and is a mechanism to ensure that event rows are not duplicated. It is anticipated that some Local Authority case management systems willautomatically create a unique reference for events when the record is created. Where the event reference is automated, it can be included as the event reference. W here an automated unique event reference is not available, LAs should consider a local method to derive an event reference, using other data items in the collection such as matching dates, event types and/or a combination of other data fields | M | |
EVENT START DATE | Required for all event rows, this will be the date the event started, which may differ from the date the event was recorded on the case management system. For example, where a client received home care from the 20th March, but the service was recorded and authorised on the 22nd March, the start date recorded in CLD should be 20th March | M | |
EVENT END DATE | Event end date should be entered for all events completed or ended during the collection period. An event end date is required for all request, assessment and review events. It is feasible to have an event start and event end on the same date, for example a request for support received by a contact centre which is started and completed over the phone. In this case, please record the same date for both the event start date and end date. | M | |
EVENT DESCRIPTION | The free text ‘Event Description’ provides context and can be the system description of the service, allowing Local authorities to assign further clarification and meaning to event rows. Descriptions of events will vary between Local Authorities | M | |
EVENT OUTCOME | The purpose of this field is to help determine the path taken by individuals in the social care system, particularly in situations in which the sequence of events is not be feasible to infer from linking event records. It is intended to reflect the reason for the ending of an event or indicate the resulting procedure. As a mandatory field, all events require an Event Outcome. It is acknowledged that the Event Outcome is not always easy to extract from LA activity systems. LAs should select the Event Outcomes that best represent the outcomes of each event based on available information. Event outcomes should be known at the point when the event is completed, with no further processing required. They will indicate whether the client’s pathway has ended or indicate the subsequent step in the social care journey. There is no requirement to track cases and derive the usual SALT sequel attached to each unique event. The intention is that the processing of sequels will be done centrally following submission of the data, using agreed transformation rules based on linking records. Event outcomes can be amended for event records that are included in later submissions, where the event outcome has changed or been corrected. For situations in which the event has concluded but the next event is delayed, the expected Event Outcome should be included for the completed event. If there is a change of circumstance that leads to the expected event not taking place, the event outcome for the completed event can be revised in future submissions For example, if an individual that has made a request and is put on a triage list for an assessment, the Event Outcome for the request should be “Progress to Assessment”. If the individual is deemed not to require an assessment or an emergency event such as hospital admission takes place prior to the assessment taking place, the Event Outcome of the request can be revised to reflect the situation. In the case of a service which is open or ongoing at the end of the reporting period, the event outcome should be ‘Provision of Service’. | M | Progress to Reablement/ST-Max
Progress to Assessment / Unplanned Review Admitted to hospital Progress to Re-assessment Progress to Support Planning / Services Progress to End of Life Care No change in package Service ended as planned NFA - Moved to another LA NFA - 100% NHS funded care NFA - Self-funded client (inc 12wk disregard) NFA - Support declined NFA - Information & Advice / Signposting only NFA - Deceased |
Name | Description | Conformance | Codes & Value Set |
---|---|---|---|
REQUEST: ROUTE OF ACCESS | Route of Access is required for all requests for support whether this is for a NEW or EXISTING client. Requests captures referrals from other services/ professionals as well as direct contacts from people contacting the LA on someone else’s behalf. The recording of route of access should follow the SALT convention for STS001 and apply equally to service users and carers, although with the latter, this may not be captured on local systems, so a default of ‘Community / Other route’ should be chosen | M | Planned Entry (Transition)
Discharge from Hospital Diversion from Hospital Services Community / Other route Prison Self-Funder with depleted funds Self-Funder with depleted funds - 12-wk disregard or DPA Discharge from Reablement Transfer from Other LA |
Name | Description | Conformance | Codes & Value Set |
---|---|---|---|
ASSESSMENT TYPE | The CLD LA Reference Group saw the benefit of adding a new variable with structured assessment type values to match SALT concepts, and LAs may choose to capture the system assessment name using the event description. This field has been made mandatory and amended to capture Financial Assessments to support monitoring of Charging Reform implementation. It is recognised that LAs will have different assessment practices and use proportional assessments such as an ‘Initial Conversation’ style assessment or a ‘3-stage’ assessment. LAs will have to de cide how best to reflect this activity as Long Term or Short Term Assessments. Long Term Assessments should include all needs assessments where there is an eligibility determination | M | Short Term Assessment
Long Term Assessment |
INFORMAL CARER INVOLVED IN ASSESSMENT | M | Yes
No Don't know |
Name | Description | Conformance | Codes & Value Set |
---|---|---|---|
SERVICE TYPE | M | Short Term Support: ST-Max
Short Term Support: Ongoing Low Level Short Term Support: Other Short Term Long Term Support: Nursing Care Long Term Support: Residential Care Long Term Support: Community Long Term Support: Prison | |
SERVICE COMPONENT | The reference group saw the benefit of adding a new ‘service component’ field to supplement the existing ‘Service Type’ variable. The following values have been agreed. For instances where a service provision is a direct payment, but that it has a known specified purpose, the purpose should be represented in the Service Component field and Direct Payment should be selected in the Delivery Mechanism field. For cases in which the purpose for the direct payment is not specific or known, Direct Payment should be selected in the Service Component field. unknown. For example, where a direct payment is made for carer respite, the Service Component should be recorded as Carer Respite and the Delivery Mechanism field can be used to record Direct Payment | M | Reablement
Short Term Nursing Care Short Term Residential Care Long Term Nursing Care Long Term Residential Care Home Support Day Support Meals Transport Equipment Direct Payment Shared Lives |
DELIVERY MECHANISM (LONG TERM COMMUNITY OR PRISON ONLY) | Values have been consolidated and apply to carers and prison or community settings and can be identified separately from the service type variable. The inclusion of delivery mechanism provides further insight to the financial information reported for each service row. For CLD the Delivery Mechanism is specific to the service line. This is a change to the Service Setting/ Delivery Mechanism methodology described in SALT, which is based on the hierarchy of all services recorded for the client or carer | Community: Direct Payment
Community: CASSR Managed Personal Budget Community: CASSR Commissioned Support Prison: CASSR Managed Personal Budget Prison: CASSR Commissioned Support |
Name | Description | Conformance | Codes & Value Set |
---|---|---|---|
REVIEW REASON | The Significant Event in SALT LTS002 has been renamed as Review Reason for the Client Level Data collection. As with route of access, rather than adding a new carer specific review reason, please choose the most appropriate review reason if known, else default to ‘planned’ for all carer reviews | M | Planned
Unplanned - Hospital (Planned and unplanned episodes) Unplanned - Carer related Unplanned - Safeguarding concern Unplanned - Other Reason Unplanned - Provider Failure Unplanned - Change in Commissioning arrangements |
REVIEW OUTCOMES ACHIEVED | There is currently a gap in person-centred outcomes measurement linked specifically to needs and packages. To address this, ‘review outcomes achieved’ has been added | M | Fully Met
Partially Met Not Met |
Name | Description | Conformance | Codes & Value Set |
---|---|---|---|
UNIT COST (£) | M | ||
COST FREQUENCY (UNIT TYPE) | There is currently a gap in person-centred outcomes measurement linked specifically to needs and packages. To address this, ‘review outcomes achieved’ has been added with values equivalent to the Safeguarding Adults Collection (SAC) return, Making Safeguarding Personal (MSP) table Fully met e.g. if all outcomes are fully met Partially met e.g. if at least one is fully or partially met Not met e.g. if no outcomes are met Data item: Defined list The item is included as an overview of whether support services have enabled the client to achieve their stated outcomes. It will provide some insights into the success of LA funded support and unmet need for clients known to the LA. It is expected that, in line with Care act 2014 eligibility, clients in receipt of long term support will have specified at least two personal outcomes where there is a need. The process for deciding the extent to which an outcome has been achieved will differ in each Local Authority, but reviews should be conducted as a discussion with the relevant individuals, where the reviewer arrives at a professional judgement on the achievement of their outcomes | M | Per Session
Hourly Weekly Fortnightly 4-weekly Monthly Quarterly Annually One-off |
PLANNED UNITS PER WEEK | Required for services only where the unit cost occurs more frequently than weekly such as hourly, daily, or per session | M |
Name | Description | Conformance | Codes & Value Set |
---|---|---|---|
Name | Description | Conformance | Codes & Value Set |
---|---|---|---|
Name | Description | Conformance | Codes & Value Set |
---|---|---|---|
Name | Description | Conformance | Codes & Value Set |
---|---|---|---|
Name | Description | Conformance | Codes & Value Set |
---|---|---|---|
Name | Description | Conformance | Codes & Value Set |
---|---|---|---|
Name | Description | Conformance | Codes & Value Set |
---|---|---|---|
Name | Description | Conformance | Codes & Value Set |
---|---|---|---|
Name | Description | Conformance | Codes & Value Set |
---|---|---|---|
Name | Description | Conformance | Codes & Value Set |
---|---|---|---|
Name | Description | Conformance | Codes & Value Set |
---|---|---|---|
Name | Description | Conformance | Codes & Value Set |
---|---|---|---|
Name | Description | Conformance | Codes & Value Set |
---|---|---|---|
Name | Description | Conformance | Codes & Value Set |
---|---|---|---|