Together about Dementia

1 Introduction andMotivation

The number of people diagnosed with dementia each year is increasing [WHO, 2021]. This is primarily due to the fact that age is the most important risk factor for dementia syndrome and that the worldwide population is aging. As dementia progress and cognitive abilities decline, the persons affected may need to rely increasingly on caregivers and relatives for support. This puts pressure on caregivers and relatives. To alleviate it and to improve the quality of life of persons with dementia (PwD), mobile health (mHealth) devices and applications within dementia care are increasingly being used to support caregivers and relatives in various tasks and enhance the well-being of PwD.

The World Health Organization (WHO) defines mHealth as "the use of mobile and wireless devices to improve health outcomes, healthcare services, and research" [WHO, 2011]. Research on mHealth applications for dementia patients and their caregivers has been conducted in a fair amount [Brown and O'Connor, 2020; Yousaf et al., 2020; Kim et al., 2021]. One of the most identifiable symptoms of dementia is forgetfulness and memory loss. PwD are thus at risk of wandering and getting lost. mHealth apps and devices for tracking and monitoring a PwD's location have thus been described in several studies [Vergara et al., 2015; Aljehani et al., 2018; Ghanem and Alkhal, 2018; Siddiq et al., 2018; Alharbi et al.,

2019; Gupta et al., 2019; Stutzel et al., 2016; Surendran and Rohinia, 2019]. These studies describe mHealth apps and devices with the functionality of tracking the PwD's current location. Among these apps, three of them [Vergara et al., 2015; Ghanem and Alkhal, 2018; Surendran and Rohinia, 2019] include an alert system for caregivers and relatives.

We go beyond the mere monitoring of the current location of a PwD and present "Sammen Om Demens" (together about dementia, SOD), an app that aims at automatically detecting if a person is wandering and, in case, trigger a rescue operation. SOD is developed for the local community of the Danish municipality of Nyborg, who together with TrygFonden provided financial support. A participatory design approach was used in the conception phase of SOD and in the later stages of user testing. The final outcome is an app that accommodates three user types: i) users with dementia (from light to medium cases) who can use to a certain degree a smartphone and remember to bring it with them; ii) closest caregivers and relatives linked to one or more users with dementia; and iii) ordinary citizens not linked to any specific user who volunteer to help in situations of wandering. Relatives to a PwD are handled as volunteers but have enhanced functionalities towards the PwD to whom they are linked.

For the final users, the app consists of three components, each providing a different functionality: a knowledge base (managed through a content management system) providing information about the local offer for PwD by the municipality, a help component providing functionalities to activate relatives and near volunteers in cases of need, and a recreational activity calendar to facilitate social gatherings, including an additional feature (currently inactive) to find accompanying persons.

AI techniques are used to detect whether a PwD exhibits an anomalous behavior consisting of wandering, which is interpreted as a sign of becoming lost or being confused about the location.

The help component offers to a PwD who is feeling lost or confused about the location the possibility to directly trigger an alarm to call for assistance by the nearest relative or volunteer. The alarm initiates a mission whose management has been carefully designed to guarantee a trustful process. Relatives are engaged in this process and coordinate the intervention by one of the nearest volunteers through a call. Further, the address of the PwD is not unveiled to the volunteers, but they are requested to help the PwD reach a safe place, e.g., a care home, a police station, or the like. Alternatively, an alarm can be triggered by a relative linked to a PwD who detects an anomalous wandering of their PwD by means of their exclusive tracking capability that monitors the trajectories of users on a map. In this case, the mission starts with a call from the relatives to their PwD to assess the situation and in case activating volunteers, if necessary. Most interestingly, the same alarm can also be triggered automatically by the app if the AI engine in the backend system detects in the PwD an anomalous behavior of wandering from the stream of location data sent by the frontend.

In all cases, if a mission is actively or automatically triggered, the backend system has the task of sending out a call to the available relative of the PwD and notifications to the three nearest available volunteers. If there is more than one relative, the one registered with the highest priority is chosen. When the notification is received on a device of a volunteer, it triggers an alarm sound to warn the user to react fast. The volunteers that receive the notification can see the location of the PwD and can accept or decline the request for help. When the PwD has been brought to a safe place, the mission is closed by one of the relatives. Protocols are also available for cases where the relative does not respond to the call or the volunteers do not accept to help the PwD. Finally, if no one can help the PwD, the PwD will automatically be prompted to contact emergency services instead.

The development of SOD brought the following novelties and contributions to mHealth.

• The app is the result of a participatory design approach, a process in which all stakeholders (PwD, relatives, nurses, administrative people, volunteers, AI experts, and developers) have been involved in workshops and tests [Cenci et al., 2022]. In particular, this approach has determined the components of the app, the final protocol for the management of a mission, and the communication means in the frontend.
• The design and implementation of an architecture made of a frontend and a backend that use microservices and serverless services to facilitate scalability, maintenance, and continuous refinements of the AI engine [Andersen et al., 2021b].
• The design and testing of AI algorithms for anomaly detection in spatio-temporal data [Andersen et al., 2021a].

We make available: a demonstration video at https://vime o.com/677269330, a dissemination web-page at https://sod. sdu.dk, and the code-base and test data [Andersen, 2021].

2 AutomaticWandering Detection

We set focus on the current AI engine of SOD described more thoroughly in [Andersen et al., 2021a]. The engine is based on past, and real-time location data transmitted by the device of a PwD and relies on personalized models.

Overall the engine consists of two components: one periodic and one real-time. The task of the periodic component is to extract typical historical movement patterns of a PwD from continuously incoming location data points, while the real-time component compares the current pattern with the typical ones to detect significant deviations.

The periodic processing of collected location data is illustrated in Figure 1. The continuous stream of data is decomposed into movement trajectories by determining geographical regions in which the person had prolonged stays. Thus trajectories have geographical regions as origins and destinations. The trajectories are then transformed into sequences of geohashes, which are unique strings to which geospatial coordinates that fall within a grid are mapped. Finally, a set of frequent sequential patterns is extracted via the PrefixSpan algorithm [Pei et al., 2001]. This helps summarize the collected data and organize past trajectories in frequent sequence patterns between different origins and destinations.

The real-time processing of location data is illustrated in Figure 2. Here, we assume available a database D of the typical geohash sequences of a PwD. For an on-going trajectory T ′ , the same segmenting and transformation process as in the periodic component is applied, yielding a partial geohash sequence Vi = [v0, v1, . . . , vi]. Whenever a new element vi+1 is added, a similarity score can be calculated between Vi+1 and the elements of D, that is, si+1 = f(U,Vi+1)/|Vi+1|. The score si+1 uses a sequence alignment function f that counts how many elements of the best matching sequence U ∈ D align with the elements of the on-going sequence Vi+1. From si+1 an anomaly score ai+1 = 1 -minj=0,...,i+1 (sj) can be updated and monitored. If this score rises above a threshold θ ∈ (0, 1], then the trajectory is classified as anomalous, and an alarm procedure is triggered. Clearly, the proper setting of the parameter θ is crucial for the approach [Andersen et al., 2021a].

3 SystemArchitecture

The implementation of the backend has to adhere to efficiency, reliability and maintainability requirements. We chose to use a lightweight Kubernetes distribution called k3s to deploy and run the different elements needed by the help component as microservices or serverless functions. These types of architectural components especially have advantages with respect to efficiency, reliability, and maintainability [Richardson, 2021a; Richardson, 2021b] when deployed to a platform like Kubernetes.

Microservices and serverless functions are architectural components that handle a limited set of tasks. They promote the logical grouping of elements into separate components that use their own isolated environment and are loosely coupled with other components. These characteristics facilitate debugging and maintainability, which are important in our case. Our architecture is illustrated in Figure 3. A key component is Redis, which is used as a message queue and broker in handling the internal communication among the other components. Redis is also a part of the communication layer that enables users of the SOD frontend application to establish a persistent connection for bi-directional real-time messaging with the backend system. Redis essentially enables the possibility of passing relevant messages from one user to another through the backend system.

The implementation of the automatic wandering detection engine is delegated to a microservice developed using the Python Django REST framework [Django REST, 2020]. This component offloads most data processing tasks to serverless functions in the OpenFaaS computing framework [OpenFaaS, 2020] via the OpenFaaS Gateway. In the context of the periodic and real-time processing of location data, OpenFaaS provides a platform for scaling CPU-bound computations implemented as functions.

The Django component also takes care of managing a mission when wandering is detected in a PwD. In particular, the component implements the message flow illustrated in Figure 4. It entails keeping track of the location coordinates of different users (caregivers, relatives, and volunteers) and determining their availability. The component is also responsible for keeping track of the state of the mission at each user and calling the appropriate messages and user interfaces implemented by the frontend. See the linked demonstration video for an example.

4 Conclusion and FutureWork

We have implemented a mHealth application for the involvement of citizens in the care of people with early stages of dementia. The app's main functionality uses AI to detect whether a person is wandering, disoriented, and lost and activate a rescue mission.

SOD has only been tested in synthetic settings at the time of writing. In particular, the automatic wandering detection engine has been tested and compared with an alternative approach from the literature on synthetically generated data

[Andersen et al., 2021a]. Similarly, the scalability and reliability of the architecture have undergone synthetical load tests [Andersen et al., 2021b]. User tests in protected environments have been accomplished at many stages. We are in the process of launching the app on a restricted set of users to closely monitor the performance. The next step will be the assessment of real-life rescue mission episodes 1 .

1 We acknowledge financial support for the SOD project by TrygFonden (ID 127211), Nyborg Kommune and the University of Southern Denmark.