London Borough of Sutton: Access Assure, Technology Enabled Care
Access Technology Enabled Care (TEC) transforms care through combining traditional reactive alarm functionality with proactive digital insights of daily living activities, to support personalised, proactive and preventative care both in and out of the home.
Tier 1 Information
###Name
Access Assure, Technology Enabled Care (TEC)
Description
Sutton Council commissioned a new Technology Enabled Care service to enable residents of the borough to live well, independently and safely in the place they call home, and deliver financial benefits to the Council. The aim of the service is to support residents to take advantage of the opportunities that Technology Enabled Care can offer wherever possible to support self care, anticipate or prevent a crisis in care from ever happening.
The service achieves this by using devices that monitor daily routines. These devices can detect unusual changes, such as missed meals or lack of activity, and alert carers, family/friends or Medequip Connect, allowing for timely support. This proactive approach ensures that potential issues are identified early, preventing crises such as a fall.
The use of Access Assure by Medequip Connect plays a crucial role in delivering this Proactive Preventative service model for TEC, employing technology such as smart plugs, motion sensors and data insights.
Website URL
https://www.theaccessgroup.com/en-gb/health-social-care/access-technology-enabled-care/
Contact email
Tier 2 - Owner and Responsibility
1.1 - Organisation or department
London Borough of Sutton
1.2 - Team
The team responsible for the use of the algorithmic tool are People Services and Commissioning Directorates, London Borough of Sutton.
1.3 - Senior responsible owner
Service Manager for Technology Enabled Care, London Borough of Sutton
1.4 - External supplier involvement
Yes
1.4.1 - External supplier
- The Access Technology Group Limited (The “Access Group”)
- Medequip Assistive Technology Limited (“Medequip Connect”)
1.4.2 - Companies House Number
- The Access Technology Group Limited Companies House Number: 05575609
- Medequip Connect Medequip Assistive Technology Limited Companies House Number: 04198824.
1.4.3 - External supplier role
The Access Group developed and supply the Technology Enabled Care software (algorithmic tool), that is used for the commissioned Sutton Technology Enabled Care service.
The Technology Enabled Care service is delivered for London Borough of Sutton by Medequip Assistive Technology Limited (“Medequip Connect”).
1.4.4 - Procurement procedure type
Competitive Dialogue Procedure of the Public Contracts Regulations 2015, regulation 30.
1.4.5 - Data access terms
Documented in the Data Protection Impact Assessment: London Borough of Sutton are the Data Controller, Medequip Connect are the Data Processor, Access Group are Data Sub-Processors.
Tier 2 - Description and Rationale
###2.1 - Detailed description
Access Technology Enabled Care in-home solution in London Borough Sutton includes a Home Hub, and range of Activities of Daily Living Sensors with optional additional peripherals where an additional need is assessed. Algorithmic based analytics are generated using sensor data in three main domains: (1) Real time alerts based on unusual behaviour, (2) Tracking long term changes in behaviour, (3) LLM based summarisation of activity and behaviour.
For example, people discharged from hospital requiring additional support to regain their independence are offered a 6-week TEC package including a falls detector/alarm button, motion sensors and smart plugs. The AI/data insights detect significant changes to the individual resident’s routine, which then triggers an alert. Medequip Connect’s service specialists make welfare check calls for all alerts, and where they are unable to speak to the resident, will dispatch an emergency responder within 45 minutes to assess their welfare and escalate to get them timely support, including NHS Urgent Community Response or an Ambulance. Medequip responders are trained in First Aid and the use of safe lifting aids to assist people in the event of a non-injurious fall.
At the end of the 6-week period, the algorithmic tool provides a summary of the person’s independence to provide data evidence of their ongoing Care and Support needs.
2.2 - Scope
Access Technology Enabled Care is designed to support people’s individual independence both in and out of the home. It can be used by people in their own home, Supported Living Housing and Residential Care Homes. For example, collecting data to better understand their hydration, nutrition, activity in and out of the home, bathroom visits, sleep routines, falls and smoke detection.
2.3 - Benefit
Connected Telecare Solution to support independent living comprising (1) any combination of Access Assure Hardware & Sensor Peripherals and/or 3rd party Hardware & Sensor Peripherals (deployed in a service-users home or care setting) digitally connected to (2) the Access Assure software platform, which aggregates the data feeds and (3) through the application of an array of proprietary AI & Machine Learning algorithms (4) provides care-givers (via a desktop and/or mobile application) with smart insights to support proactive care interventions.
The 24/7/365 Technology Enabled Care service enables residents of the borough to live well, independently and safely in the place they call home, and deliver financial benefits to the Council. The aim of the service is to support residents to take advantage of the opportunities that Technology Enabled Care can offer wherever possible to support self care, anticipate or prevent a crisis in care from ever happening.
The enhanced support offered would be too costly and impossible to deliver without the the technology, data insights and Artificial Intelligence, delivering long-term benefits to both residents, Social Care, Health and Housing.
2.4 - Previous process
Prior to deployment of Access Assure an alarm-only reactive telecare service was in place providing no data evidence of Activities of Daily Living to support proactive and preventative decision making on individual’s care and support needs. London Borough of Sutton sent letters to all people using services to advise them of the new service and ongoing security of their data.
2.5 - Alternatives considered
The decision to award of the contract to deliver a new Technology Enabled Care Service to the successful provider, Medequip Connect (et al), followed an extensive and robust procurement and evaluation process. Due to the complexities of this service, which has multiple technical components, and the innovation required to deliver the transformational changes, the Council conducted the procurement using a Competitive Dialogue process, pursuant to the competitive dialogue procedure of the Public Contracts Regulations 2015 (PCR2015), regulation 30. Applicants were deemed to understand fully the implications of this process used by the Council to select and appoint a contractor with whom to develop the service in line with the legal agreement.
Utilising this process allowed dialogue between the Council and potential providers, ensuring that key service requirements were fully understood before final bids were submitted. The five highest scoring bidders were invited to participate in Stage 2; with three bids submitted by providers. Based on the evaluations, the most economically advantageous tender combining a single solution was awarded to Medequip Connect.
Tier 2 - Decision making Process
###3.1 - Process integration
Proactive alerts are displayed on a dashboard monitored by Medequip Connect’s 24/7 Contact Centre. Specialist operators within the Contact Centre are trained in handling these alerts and gaining insights from them to determine the appropriate response in-line with decision making matrices and agreed escalation pathways.
3.2 - Provided information
Algorithmic outputs can be categorised in three domains: (1) real time alerts of unusual activity (“service user x has not left the bathroom for over an hour, they may have had a fall”), (2) Long term trends of behaviour (“service user x displays a long term increase in bathroom activity over the past 90 days”), (3) LLM based summarisation of activity. The outputs do not make any direct medical diagnoses.
3.3 - Frequency and scale of usage
Every alert is reviewed by Medequip Connect’s team daily with a welfare check call made to the resident. Deployment of the local-authority offered service is in progress and expected to reach 2000 citizens, with additional growth expected via a private pay offer from Medequip Connect’s community shop.
3.4 - Human decisions and review
Following review of the alert, sensor activity and welfare check call, Medequip Connect follow co-designed proactive escalation pathways if appropriate. These include dispatching Medequip’s 24/7 Emergency Response service, local NHS’s Urgent Community Response service, Emergency Services, relatives, carers, other nominated contacts, or other supporting services. Escalations are made in accordance with operator guidance and decision making matrices to route the escalation to the relevant supporting service. A comprehensive audit trail is recorded including recording of alerts, inbound and outbound call traffic, digital audio recording, call reasons and actions, as well as comprehensive notes recorded in the dashboard to record the actions taken and outcome.
3.5 - Required training
Training and ongoing customer support is provided to Medequip Connect by the Access Group. In-house training on monitoring processes and escalations is provided by Medequip Connect to facilitate the Proactive & Preventative service model is delivered. Guidance on local escalation pathways is provided by London Borough of Sutton and local Health partners, which is then incorporated into processes and corresponding training.
3.6 - Appeals and review
Referrals are made to the service by local Health and Social Care professionals in discussion with the individual and their advocate as appropriate. They have a right to refuse the service. However, where a resident is assessed as lacking capacity to make an informed decision, a best interest decision will be supported by the Local Authority in line with the Mental Capacity Act (2005) and the Care Act (2014).
All alerts and notifications are displayed and directed to trained specialists at Medequip Connect. The data insights support decision-making by the relevant professionals.
Any resident objections, concerns or complaints are directed to Medequip and/or the Local Authority and treated in line with the Local Authority Complaints Procedure.
Tier 2 - Tool Specification
###4.1.1 - System architecture
Real time alerting- uses:
- domain knowledge and customer set parameters to set up alerts based on unusual behaviour (i.e. service user shows no activity or has been in the same room for an unusually long time indicating possible fall),
- A custom build anomaly detection model for automated detection of unusual behaviour.
Long term trends- uses a linear regression model and best fit parameters to determine if a service user shows a marked decline or increase in behaviour (i.e. increased bathroom usage).
Information on the alert infrastructure: https://accessgroup.my.site.com/Support/
4.1.2 - Phase
Production
4.1.3 - Maintenance
We use three different cloud environments: develop, staging (pre-prod), and production. Only production stores and processes actual customer data. The first two environments are for bug/stress testing of and development of new features. Azure DevOps pipelines are used for comprehensive unit testing and deployment of new features. Deployments are made from development to staging every 3 weeks. Stable deployments are then deployed to production after a week of monitoring. We have an array of internal monitoring tools (AWS Cloudwatch) to monitor for performance of both internal resources and algorithm performance. We also have internal alerts (AWS EventBridge) to receive email alerts if any algorithms fail to provide an output
4.1.4 - Models
Rule based: real time alerts (for example: no activity, no return to room, property exit, user has started their day).
Statistical based: (for example: Door left open for longer than usual, unusual high/low bathroom activity, nighttime activity, whole day activity, tv activity). What is “unusual” is determined statistically.
ML based: (for example: Anomaly detection models are used to produce an aggregate output as to whether a service user’s behaviour is unusual).
AI based: (for example: LLM based summary reports use a ChatGPT endpoint to summarise input data which is then returned in markdown format to be displayed to the user).
Tier 2 - Model Specification: Anomaly Detection (1/2)
###4.2.1 - Model name
Anomaly Detection
4.2.2 - Model version
0.21
4.2.3 - Model task
The task is to detect anomalies is in user behaviour by monitoring the sensor data recorded from all sensors set up in the entire house.
4.2.4 - Model input
The input of the model is a binary activations for whether or not sensors were used in the house for a particular period of time.
4.2.5 - Model output
The output of the model is to identify whether or not the time period was an anomaly i.e. a true or false output to determine an anomaly. Further to identify which of the senor usages in specific that caused the anomaly.
4.2.6 - Model architecture
The model architecture is an ensemble of machine learning models: specifically multiple instances of an Isolation forest and K Nearest Neighbour. The model outputs are aggregated. Further SHAP for explainability and to determine which sensor usage pattern is causing the anomaly.
Isolation Forest - https://scikit-learn.org/stable/modules/generated/sklearn.ensemble.IsolationForest.html
KNN - https://pyod.readthedocs.io/en/latest/_modules/pyod/models/knn.html
SHAP - https://shap.readthedocs.io/en/latest/
4.2.7 - Model performance
A manually annotated dataset using statistical methods was used as a baseline and was used to test the efficacy of this method.
For our test dataset we achieved an AUC ROC score of 0.74. With each individual subject score being in the range of approx. 0.71 to 0.76. These results are in line with the state-of-the-art performance for multivariate datasets.
4.2.8 - Datasets
We used a dataset composed of sensor data which represented activity of an individual in their home. The dataset used was from the development environment and only included anonymised sensor data recorded by internal employees within the company. Each model had it’s own dataset which made predictions on each individual persona and individual routine. Models are retrained every week to account for new information from changing routines. No generic dataset card has been created.
The test data referred to below is derived from the larger dataset described here.
4.2.9 - Dataset purposes
The dataset from the development environment (see question above) was split into “training”, “validation”, and “testing” datasets. The “testing” dataset was used in the experimentation phase of the development to ascertain the efficacy of different machine learning methods for training and validation.
Subsequently this dataset has not been used to train models in use and deployment. Models are deployed per subject and use the data for that subject as the training data.
Tier 2 - Model Specification: ChatGPT (2/2)
###4.2.1 - Model name
ChatGPT
4.2.2 - Model version
4o
4.2.3 - Model task
The model is used to create a summary report of the user behaviour from precalculated metrics that are provided to the model as prompts. The summary reports are produced weekly in the Access Assure dashboard and the time period can be adjusted as appropriate.
4.2.4 - Model input
The input of the model is a subset of precalculated metrics for a particular user - eg. start of day time, night time activity etc.
4.2.5 - Model output
The model outputs a 120 word summary of the metrics provided.
4.2.6 - Model architecture
The model is a chatGPT 4o model by OpenAI exposed using private azure endpoint. No further optimisation or finetuning were performed on our end. Link to the specifications of OpenAI azure models - https://learn.microsoft.com/en-us/azure/ai-services/openai/
4.2.7 - Model performance
N/A - This is a qualitative task for providing a report in which the information provided is summarised as a word report. Manual interaction was performed when testing with different prompts to ensure best output. Manual evaluation was also performed to ensure that no hallucinations or inaccurate fields were reported, using approximately 100 generated reports.
4.2.8 - Datasets
N/A - No datasets were used to create the model, pretrained GPT model was used. High level metrics were generated using the internal anonymised sensor dataset. No identifying information is provided in this dataset
4.2.9 - Dataset purposes
N/A- No model was trained or fine-tuned. The data is given to the model is used to create a summary, this data is high level metrics of user behaviour.
Tier 2 - Data Specification
4.3.1 - Source data name
Internal sensor data recorded from 3rd party remote sensors and stored in AWS.
A dedicated AWS environment is used to provide S3 buckets which are used to store anonymised service user data and trained models.
4.3.2 - Data modality
Time series
4.3.3 - Data description
Personal Data might relate to the following categories of data subjects:
Employees or contact persons of Customers (who are natural persons)
Employees, agents, advisors, freelancers of Customer (who are natural persons)
Customer’s service-user data subjects (who are natural persons) authorised by Customer to use the Services and who have themselves explicitly consented to the processing of their data.
Non-personal data includes data sent back from the sensor for example, digital heartbeat, smart plug activity and SIM connectivity
4.3.4 - Data quantities
Processing will continue for the duration of the active contract.
Access does not apply retention schedules to client data other than for backups (see backup section) and deletion of data on termination of contract in line with our Exit policy (unless there is a legal requirement for Access to retain the data)
4.3.5 - Sensitive attributes
In addition to the personal data described in 2.4.3.3 customers may voluntarily submit Special Category Personal Data to the Services, the extent of which is solely determined and controlled by them in their sole discretion and not a system requirement, and which may include, but is not limited to the following categories:
Personal Health Information
4.3.6 - Data completeness and representativeness
Missing sensor data can occur due to packets being dropped when being transferred to the household hub. In the vast majority of cases only one packet will be dropped (i.e. the ON or the OFF message from the sensor not both) and so we can still approximate the service user activity. The sensor data collected will only be representative of the service user; we do not use the same data to make approximations of the population.
4.3.7 - Source data URL
The data is stored in a secure and anonymised format with AWS and is not possible to expose publicly
4.3.8 - Data collection
Medequip’s Customer Services team contact the resident or their advocate to create the service-user record. Customer may submit Personal Data to the Services, the extent of which is determined and controlled by Customer in its sole discretion, and which may include, but is not limited to the following categories of Personal Data: - First and last name - Salutation - Title - Contact information (email, phone, physical address, postcode) - Date of Birth - Friends & Care Circle Telephone Information - ID data e.g., NHS Number - Personal life data - Localisation data
At this point they advise and record that they have clearly communicated to the resident (or advocate) the purpose of collecting personal data, which is necessary for providing our services (as a public task on behalf of the local authority). They have demonstrated their understanding of this explanation and their right to opt out and acknowledged it.
To provide the Services, including to operate the Services, provide customer support and personalised features and to protect the safety and security of the Services.
4.3.9 - Data cleaning
For the collected sensor data, we have several pre-processing steps, including discarding data on days when the hub was offline, converting sensor data into standard pairs, etc. The sensor data is stored in a secure database separately from any personally identifiable information and these datasets are only combined as and when required. The sensor data is digitally transmitted from the devices and by default does not contain personally identifiable information. PII is not currently used or encoded into the analytics data.
4.3.10 - Data sharing agreements
A DPIA (Data Protection Impact Assessment) is in place.
4.3.11 - Data access and storage
Hosted: We receive data uploaded to the service by users, which is stored in a cloud environment in accordance with the options selected by You. Users may instruct the service to share some or all of the data with other users or groups/classes of users.
Tier 2 - Risks, Mitigations and Impact Assessments
###5.1 - Impact assessment
Data Protection Impact Assessment (DPIA) is in place between London Borough of Sutton, Medequip and Access Group.
https://www.sutton.gov.uk/w/privacy-notice-and-data-protection
https://www.medequip-uk.com/privacy
https://www.theaccessgroup.com/en-gb/privacy-notice/
5.2 - Risks and mitigations
AWS Security: https://aws.amazon.com/compliance/data-center/controls/
The analytics alerts that we raise are used in conjuction with the existing social alarm framework (SCAIP protocols) which works alongside as additional protection. We deliver a suite of analytics alerts, some of which are better used for detecting certain service user risks. If for any reason one alert does not capture a specific event, there are other alerts which are likely to also cover the same event (e.g. if the service user has had a fall in the bathroom and it’s not detected by the anomaly detection alert, it is likely to still be detected by the no activity alert or the social alarm fall detector). This reduces the impact of any false negatives, ensuring safety of the individual.
Risk exists in the scrutiny and escalation of alerts generated from Access Assure and how these are handled by the Medequip Connect Contact Centre; these risks are mitigated through robust policies, procedures, training, quality management systems, and external auditing by the recognised standards body for the TEC sector.