Social Care FHIR Store Mappings

Submission Information

Name	Description	Conformance	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

Person Details.

Name	Description	Conformance	Code & 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

Events (ALL)

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

Events (Requests Only)

Name	Description	Conformance	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

Events (Assessments Only)

Name	Description	Conformance	Value Set

Events (Services Only)

Name	Description	Conformance	Value Set

Events (Reviews Only)

Name	Description	Conformance	Value Set

Costs (Services Only)

Name	Description	Conformance	Value Set

SAC

Name	Description	Conformance	Value Set

Contacts

Name	Description	Conformance	Value Set

Early Help

Name	Description	Conformance	Value Set

Refererral

Name	Description	Conformance	Value Set

Assessments

Name	Description	Conformance	Value Set

Section 47 Enquiries and Initial Child Protection Conferences

Name	Description	Conformance	Value Set

Children in Need

Name	Description	Conformance	Value Set

Child Protection

Name	Description	Conformance	Value Set

Children in Care

Name	Description	Conformance	Value Set

Leaving Care Services

Name	Description	Conformance	Value Set

Community Data Items

Name	Description	Conformance	Value Set

Secure Setting Data Items

Name	Description	Conformance	Value Set

Outcome Profiles

Name	Description	Conformance	Value Set

Data Linkage

Name	Description	Conformance	Value Set