“A Different Kind Of Response”

The Opportunity

As the impact of the COVID-19 pandemic became apparent, a number of discussions were initiated with local council service providers. The Council is not able to proactively universally identify signs of physical or mental deterioration among its housing tenants. Currently, the Council relies heavily on weekly telephone calls or scheduled physical visits to vulnerable residents.

Council staff were faced with a number of new challenges which they did not have data to support, highlighting the need to find answers to questions, some of which have been noted below:

• How can we ascertain if vulnerable residents are becoming unwell between visits or calls to residents by the Council?
• Is there a way of alerting a decline in activity that provides an indication of the wellbeing of the vulnerable resident?
• Is there a way to guarantee connectivity for in-home devices used by council services?
• Is there a way to remove the need to plug in or charge in-home devices to make them less dependent on maintenance?

COVID-19 and social distancing requirements have provided challenges in ascertaining potential accidents or declining health of residents. In the worst case scenario, this information is obtained too late which results in severe implications for residents who may decline rapidly.

In order to support council COVID-19 intervention decision-making, data is needed to give some early indication to council officers or carers that a resident may be unwell so that invertensions can be applied rapidly.

It is expected that the data which will be collected by this use case will result in the following positive outcomes:

• Improved response times for unwell residents;
• Increased monitoring of residents without further additional staff resources.

How will the solution be delivered?

Based on preliminary soft market testing, a pilot to trial the use of 200 in-home IoT sensors across both the London Borough of Sutton (LBS) and London Borough of Richmond (LBR) has now been commissioned. The trial commenced on 3 February and will take 6 weeks to fully implement, and will run for a period of 12 months to assess and quantify benefits.

Key Requirements
In order to meet the needs of the Council, a list of broad requirements have been collated below.

• Essential requirements:
• A means of early warning of vulnerable residents decline
• No need to plug into a power source (owing to residents turning off plugs)
• No charging required (owing to the need to create a charging routine)
• No battery changes needed (owing to the dexterity challenges this presents or the need for in-home visits by suppliers).
• No complex installation required (minimal install by residents themselves so that there is no need for in-home visits by suppliers)
• No physical maintenance required
• Reliable connectivity in any building type
• Scalable connectivity that will be available across all SLP boroughs
• Secure user access with 2-factor authentication as default
• Email and SMS alerting with customisable alerting parameters to enable integration options (e.g with telecare providers)
• Use of Artificial Intelligence to learn and assess significant behaviour pattern changes resulting in “smarter” and more accurate alerting

Additional expectations of solution functionality are highlighted below:

• Functionality to support the rollout of devices to residents and users in a managed approach
• Grouping / allocation of specific residents to users or teams

Technical Overview

Hardware
A small battery powered sensor is sent directly to the resident. The resident or carer places the device in the kitchen (on a shelf or worktop), with no other installation required. The sensor has no visual recording capacity. The sensor monitors multiple environmental conditions and this data is then sent back to the data platform for processing at routine intervals throughout the day.

Software

Once hardware is deployed and installed, the data platform calibrates by mapping data patterns received from the sensor. Over time, the system will learn and increase accuracy of its tracking.

If any atypical behaviour is detected, the system will send an SMS or email alert to the appropriate carer. These notifications may be classified as “warning” (amber) or “severe” (red) alerts, depending on the length of time the system has noted a lack of normal activity.

The following “dashboard” features would be expected in a solution procured for the SLP:

• separate dashboard instances for each borough;
• reporting / alerting summary showing any residents in decline;
• display full chort and have the ability to inspect individual residents’ data.

Data Considerations

The following key data considerations should be taken into account:

• The system does not store any personal data when it is not necessary.
• Compliance with GDPR and latest government security guidance is essential.
• Access to the system is secure and all data is secured at all times.
• The vendor should act as the data controller for the software training process and must carry out a Privacy Impact Assessment and also agree a Data Protection Agreement with the councils / services involved.
• Data should be stored for a minimum of 8 years and made available to the Council at the end of the trial period.
• Consent to collect and share data from residents will be obtained – capacity of residents to consent to engage will need to be adhered to under the Mental Capacity Act 2005 to ensure decisions are taken in a resident’s best interest.
• The resident profile for the device is defined by the resident’s ability to maintain activities of daily living.

The sensor data should be accessible in at least three different ways:

• online dashboards
• reports
• API (application programming interface)

Regarding the API, the vendor should be asked to provide the following:

• access to all stored data gathered by the sensors (live and historic) via API
• comprehensive API documentation
• serve data in modern JSON structures, allowing each sensor to output multiple data types simultaneously
• enable the ability for 3rd parties to integrate directly with the API – this integration should be facilitated at no additional cost over and above purchase price
• allow for the adaptation of the API to support integration with other systems

Expected Benefits

Expected Benefits to Residents:

• This solution could provide greater resilience in the early identification of decline of vulnerable groups which will further protect and support both residents and care workers across the boroughs.
• The successful adoption of this solution will help to mitigate issues in other legacy systems (e.g. where residents do not press existing pendant alarms) which would reduce the risk of failed emergency alerts.

Expected Benefits to Council:

• The early identification of decline will enable early intervention by council officers. This will improve services and reduce pressure on other functions within the Council, specifically supporting a reduction in hospital admissions and further activities which result from the declining health of residents under the care of the Council.

Expected Benefits to South London Partnership:

• Through the trial of NB-IoT we will be able to inform our future procurements based on the evaluation of the solutions proposed connectivity and battery life benefits.
• If expanded to other boroughs, comparisons will be possible as well as shared learnings and insights from SLP data sets.

Learning Opportunities (in alignment with funding requirements):

• Use of NB-IoT connectivity-based sensors
  Integration with 3rd party end-to-end solution to extract data
• Use of AI-based technologies
  Integration with core SLP IoT data platforms (once established)
• COVID-19 response use case experience
• Data analytics and insights opportunities across the SLP boroughs involved

Find out more
If you would like to have a conversation about how this technology could help your vulnerable residents, please contact Andrew Parsons andrew.parsons@kingston.gov.uk or Pierre Venter pierre.venter@sutton.gov.uk.