A tailored smart home for dementia care

Abstract

Dementia refers to a group of chronic conditions that cause the permanent and gradual cognitive decline. Therefore, a Person with Dementia (PwD) requires constant care from various classes of caregivers. The care costs of PwDs bear a tremendous burden on healthcare systems around the world. It is commonly accepted that utilising smart homes (SH), as an instance of ambient assisted living (AAL) technologies, can facilitate the care, and consequently improve the quality of PwDs well-being. Nevertheless, most of the existing platforms assume dementia care is a straight application of standard SH technology without accommodating the specific requirements of dementia care. A consequence of this approach is the inadequacy and unacceptability of generic SH systems in the context of dementia care. Contrary to most of the existing SH systems proposed for dementia care, this study considers the specific requirements of PwDs and their care circle in all development steps of an SH. In addition, it investigates how utilising novel design and computing approaches can enhance the quality of SHs for dementia care. To do so, the requirements of dementia care stakeholders are collected, analysed and reflected on in an SH system design. Extensions and adaptation of existing frameworks and technologies are proposed to implement a prototype based on the resulting design. Finally, thorough evaluations and validation of the prototype are carried out. The evaluations by a group of stakeholders show the suitability of the proposed methodology and consequently the resulting prototypes for reducing dementia care difficulties as well as its potential for deployment in the real-world environment.

1 Introduction

Dementia encompasses a family of chronic diseases that gradually causes permanent damage to the brain tissue. It comes with symptoms that affect people’s cognitive and motor abilities. People who are diagnosed with dementia often struggle to engage in discussions, to remember scheduled events, and to determine appropriate words for expressing situations. With the progress of dementia, they forget names, repeat words, face orientation problems, become confused about date and time, and wander around during the night times. In more advanced stages, the behaviour of People with Dementia’s (PwDs) changes dramatically. Their sleeping and eating habits are negatively affected. In final stages, the PwDs face serious physical problems such as muscle weakness, clots in the lung, or heart attacks that eventually cause death. The time-frame for dementia progress from early to late stages varies widely (i.e., 5–10 years). The most common type of late-stage dementia is Alzheimer’s disease (AD). In many cases, PwDs with mild cognitive impairment (MCI) will never progress to AD and can live with an acceptable degree of independence (McKhann et al. 2011).

The disease is more likely to occur in older age, and as the elderly population grows, the proportion of PwDs grows also. Although some medications can slow the progress of dementia, there is currently no way to stop its development altogether or reverse its impact on brain cells. Therefore, maintaining an acceptable quality of life for PwDs is challenging. Expectations show that 20% people will be older than 65 by 2030 (Wild et al. 2004). Also, about 3% of people aged 65–74, 19% of people aged 74–84 and nearly half of people more than 84 suffer dementia (Umphred et al. 2013). Most of the PwDs prefer to stay in their homes and communities, a phenomenon that is known as age-in-place. It has been observed that age-in-place reduces the speed of dementia progress, improves people quality of life (Cutchin 2003; Hyde et al. 2015) through enabling them to be surrounded by their families. However, informal care at home can be excessively expensive, and in some cases, it is not possible at all (Wimo et al. 2010).

Smart home (SH) technologies support people to have a better quality of life through enabling them to independently age-in-place. An SH environment is usually equipped with a collection of inter-related software and hardware components to monitor the residents’ behaviours and to understand their activities. By doing so, the SH system can inform about risk situations and take actions on behalf of the residents to their satisfaction (Amiribesheli et al. 2015). The SH technology can be used for different types of care: informal by family members, formal by geriatric physician and dementia nurses and social by non-medical caregivers. The concept of adapting assistive technologies such as SHs to support independent life for the PwDs is not new. A variety of assistive technologies has been employed for dementia care. Commonly, they provide support applications for memory aid, executive functions, visuospatial functions, social interactions, activities of daily living support, personal safety, behavioural monitoring, and mood monitoring (Bharucha et al. 2009).

It is widely accepted that SHs cannot help unless they are designed by considering the typical requirements of their users (Green et al. 2004; Amiribesheli and Bouchachia 2016). This suggests that SHs for dementia care should address requirements of different user groups including PwDs, informal caregivers, formal caregivers and social caregivers (Hawkey et al. 2005; Amiribesheli et al. 2015). Design initiatives (e.g., user centred design, participatory design, universal design, design for all and inclusive design) that involve users in the design process are often considered as the most viable approaches to understand and capture user’s requirements, and to assure the ability of the final system to satisfy the requirements. However, given the peculiarities (e.g., memory restraints and mobility difficulties), and the evolving nature of dementia, the process of designing SHs for dementia faces challenges such as:

• PwDs are unique individuals who know what they want and need. However, they are often not capable of making themselves clearly understood by others. This lead to collecting inaccurate requirements (Carswell et al. 2009; Nunes et al. 2010).

• Caregivers are not aware of all the PwD’s needs, and often their experience and expertise are restricted to supporting a particular group of PwDs. Therefore, caregivers cannot be the only source for collecting PwDs’ requirements.

• Depends on the needs and preferences of a PwD and their care circle, a unique set of hardware devices and software systems are required for individual SHs. Also, the requirements are evolving by gradual progress of the PwD’s disease. Therefore, the SH should be designed in a way that could be easily personalised by non-technical users.

• Other stakeholders of the system (e.g., care home managers, insurance companies) have various needs and preferences depending upon their interests and responsibilities. It means there is a much wider socio-technical aspect of the SH system. The system should be designed in a manner that can accommodate the majority of stakeholders needs.

In an effort to overcome the challenges of the requirements elicitation in the context of dementia care, the study (Lindsay et al. 2012) applied a participatory design method to create a digital aid tool for safe walking. In the study (Wherton and Monk 2008), PwDs and their caregivers were involved in requirements definition process of an SH. It was found that PwDs need support for dressing, taking medicine, maintaining personal hygiene, preparing food and socialising. The author (van Kasteren et al. 2011) investigated the effectiveness of SHs for age-in-place using interviews and observation. In that study, an SH prototype was developed and used to analyse a group of old people. The prototype was equipped with various functions such as movement monitoring, fire detection, wandering detection and fall detection. It was found that PwDs appreciate safety and security, especially fall detection. The study (Mihailidis et al. 2008) studied the application of SHs for the purpose of assisting people with moderate dementia in the accomplishment of their daily living activities. It evaluated an audio-visual system dedicated to the task of hand-washing in a bathroom. Also, the system uses video processing techniques to perceive how the washing activity is done. The system can remind the person or call the caregiver if the person does not follow wash instructions.

The authors (Kaye 2008) suggested that monitoring dementia progress via sensor data of an SH reveals new information which can be adopted to develop more efficient prevention treatments. To establish the point, they compared data collected by the sensors and conventional assessment approaches and concluded that sensor data illustrates meaningful change over time. Morris et al. (2005) reviewed health technology advances in monitoring, compensation, and prevention. Results related to ethnography and feedback suggested that adoption of health technologies will increase if monitoring is woven into preventive and compensatory health applications.

The majority of existing studies mainly focus on certain care scenarios instead of covering the needs of all types of stakeholders. The studies are designed for particular lab environments and user settings (Intille and Larson 2005). In contrast, this study presents an SH prototype that addresses all the stakeholders’ needs. To do that, it includes software solutions for stakeholders’ common and unique requirements.

Fig. 1

Development steps

Various types of caregivers (i.e., informal, formal, social) participate in forming a dementia care circle, each with a particular skill set and responsibilities. To ensure all requirements are elicited, all types of caregivers were involved in this study. Figure 1 presents the methodology adopted throughout this work.

The study offers the following scientific contributions:

• The common care scenarios required by the SH for dementia care (see Sect. 2).

• A five-level approach that enables the SHs to emulate the dementia caregivers for intervening in the PwDs lives (see Sect. 2.3).

• A reasoning engine based on a fuzzy rule-based system that allows the caregivers to use the natural description of situations in linguistic terms, rather than precise numerical values (see Sect. 5.2.4).

• A functional SH prototype based on the dementia care requirements. It is designed to satisfy fundamental requirements of dementia care, as well as, providing the caregivers with tools to personalise the system (see Sects. 3, 5).

Details of scenario development and requirements election are presented in Sects. 2, 3. Steps of prototype development are shown in Sect. 5. The evaluation approaches, results, and discussions are provided in Sects. 6, 7. Ultimately, the study is concluded in the Sect. 8.

2 Scenario development

The phase consists of developing a set of scenarios that portray most common needs of PwDs. In the following, details of the scenario development are specified.

2.1 Gathering dementia symptoms and the stakeholders

The common approaches of requirement gathering (e.g., free-format brainstorming, focus groups and interviews) might not lead to full coverage of PwDs’ need in the context of dementia care. Moreover, considering a large number of dementia symptoms, it is quite unlikely for one caregiver or a few caregivers to have experienced all of them. Therefore, comprehensive PwDs’ needs cannot be captured just relying on the stakeholders’ feedback. A way to cope with this challenge is to study and collect dementia symptoms from the existing body of literature. Consequently, here, the scenario development begins by collecting PwDs’ symptoms. The symptoms were then presented in scenario format that could be efficiently evaluated by the stakeholders. To accurately portray each scenario, we are compelled to identify stakeholders (also known as actors). In this study the key stakeholders are:

• 1. PwDs The principle users of the SH system. To make the development process more accurate, in this study, the prototype SH is designed for PwDs who have Mild Dementia or less severe stages (Reisberg et al. 1982).

• 2. Informal caregivers Family or acquaintances of PwDs with no or very little healthcare education. Ultimately, the SH should provide them with monitoring information that increases their peace of mind.

• 3. Social caregivers Non-medical caregivers who support PwDs in their homes or care homes. Mainly, the SH system should provide them with customised care guidelines and inform them of the emergency changes in the PwDs’ health or well-being conditions.

• 4. Formal caregivers Medical caregivers who support PwDs such as dementia nurses, and geriatric physiologists. The system provides them with healthcare monitoring information. Furthermore, They should be able to customise the system reactions to the PwD’s needs.

• 5. Geriatric psychologists The system should provide the psychologists with information (e.g., PwDs activity level) that portrait PwDs’ state of well-being. Additionally, their expertise is applied in the design process to choose appropriate intervention mechanisms for the SH interaction with PwDs.

Looking at the existing literature (Herrmann and Gauthier 2008; Sörensen et al. 2006), most of the PwDs directly experience the following symptoms that need caregivers’ support:

• 1. PwDs often repeat statements, questions or words. The repetitive speech is a prevalent symptom of dementia, and its occurrence increase has a direct correlation with dementia stage.

• 2. PwDs get dehydrated as they forget to drink a sufficient amount of water. The signs of dehydration for PwDs are persistent fatigue and inactivity, thirst, muscle cramps, general weakness, notably decreased urination, headaches, dizziness, confusion, rapid deep breathing, increased heart rate, and severe sudden memory loss.

• 3. PwDs often suffer from isolation and loneliness which are common threats to PwDs’ health and well-being. They can cause depression, which is manifested in PwD’s inactivity.

• 4. Older adults misplace or loose personal items inside their home. However, in PwDs’ case, it occurs more often. This can increase PwDs’ anxiety. Also, the increase in occurrences has a direct correlation with dementia stage.

• 5. It is difficult for older adults to learn how to use previously unseen devices. For PwDs, the learning process is even more complicated. The problem causes an increase in PwD’s anxiety and losing the sense of control.

• 6. PwDs face pacing and night-time wandering incidents. The incidents commonly occur when PwDs need to go to the toilet or drink water during the night-time. It is caused by PwDs’ orientation problems.

• 7. Caused by memory difficulties, PwDs tend to be extremely forgetful. The number forgetting incidents increases with the progress of dementia. Common manifestations of this chronic symptom are PwDs’ inability to remember the date, time, season, and names.

• 8. The vision difficulty is a common symptom of dementia, which can significantly increase the numbers of in-home accidents (e.g., falling). It occurs in two forms of “misperception” and “misidentification” of objects, and it occurs mostly during the dark hours of a day.

2.2 Development of initial scenarios

Scenarios are defined as what a stakeholder should do and what he or she will see step-by-step while interacting with the SH. In this study, the scenarios narratives were written as short stories portraying situations made by dementia symptoms through different personas. The personification enhances the process of evaluation by making the scenarios simpler to be addressed by the caregivers during the initial interviews. For instance, Table 1 presents an initial scenario prepared for the learning difficulty scenario.

Table 1 Sample initial scenario

In this study, initial scenarios were carefully evaluated by four social caregivers and two dementia psychologists. The evaluation process included an open-ended interview session for each interviewee. As a result of the interviews, the scenarios were enriched with details, and in a few cases, new scenarios were developed. For instance, the “personal grooming” scenario was not on the initial list, and it was later added after receiving a number of suggestions from social caregivers. Ultimately, the preliminary scenarios were validated and transformed into a set of 13 scenarios (see Table 2).

2.3 Intervention levels

In dementia care, it is essential for caregivers to allow PwDs to do things for themselves instead of taking over their lives. Having the sense of control increases the PwDs’ well-being and helps maintain their pride, confidence and self-esteem, rather than making them feel helpless (Amiribesheli and Bouchachia 2016). Looking at the literature, it is clear that an outstanding issue of existing SHs based solutions for dementia care is their inability to simulate the caregivers’ intervening approaches to the PwDs’ lives. They often developed to perform the activities of daily living instead of the residents. In a care circle, the caregivers avoid unnecessary interventions by utilising various levels of intervention depending on particular care circumstances. The SH can support PwDs’ independence and guarantee their sense of control by following the concept of intervention levels. In the study, the following five levels of intervention (Seligman 1975; Oppenauer et al. 2007) were adopted: inviting awareness, suggesting, prompting, urging, and performing.

• Inviting Awareness In this level, the system does not take actions on behalf of the PwDs. It merely monitors the activities. The data is used to produce reports which serve as basis for inviting awareness about a situation.

• Suggesting In this level, the system does not take actions on behalf of PwDs. It only suggests them to choose a particular action. PwDs are free to consider suggestions or take an alternative decision. The system does not need to monitor PwD’s reactions to the suggestion.

• Prompting In this level, the system takes actions on behalf of the PwDs only if they ignore its suggestions. The system reminds the PwD to perform an activity in a particular way. In contrast to “suggesting”, PwDs should not ignore the prompts and if the they do, the system will intervene.

• Urging In this level, the system performs an activity on behalf of the PwDs and prompts them to act simultaneously. This level is particularly beneficial for tasks that involve both the PwD and the system actions.

• Performing In this level, the system takes actions on behalf the PwDs without any conditions. Often, this type of intervention happens as a swift reaction to a risky situation.

2.4 Evaluating the scenarios

In order to provide a more detailed examination of the scenarios, each of the scenarios that were accepted in the last phase, was presented as a ‘case study’ to all the participants (i.e., four social caregivers and two dementia psychologists). They associate adequate intervention levels to the scenarios. In this stage, the main goal was to assure the genuineness of the final scenarios. As it can be seen in Table 2 in some cases, scenarios have more than one intervention level associated. This occurs when a care procedure has multiple purposes, or it needs a higher level of intervention (e.g., performing) as the PwD is not responding to the lower levels (e.g., suggestion).

For participants to envision their expectations of an SH and for the developers to illustrate the SH capabilities, the concept of ‘creativity triggers’ (Pommeranz et al. 2012) was adopted in the project. A dollhouse equipped with the PIR sensors was used as a creativity trigger during the scenario evaluation process. The scenarios were acted in a dollhouse. Simultaneously, the participants were asked to verify or alter them. 13 scenarios (see Table 2) were prepared and evaluated at the end of this phase which later used for the requirements elicitation.

Table 2 List of the use cases

3 Requirements elicitation

It is necessary to perform this step accurately, as its outcomes will be analysed, modelled and specified to shape the SH prototype. The system efficiency is defined by both its functional and its non-functional characteristics (i.e., quality attributes). Notwithstanding, in the SH literature, there has been a disproportionate emphasis on the functionality of the system, even though the SH as a whole is not functional or usable without the necessary non-functional characteristics (Amiribesheli et al. 2016).

Some stakeholder’s requirements change with the PwD’s dementia progress. As an example, a formal caregiver might require a constant update on the number of PwD’s repetitive speech incidents to diagnose the disease progress from MCI to AD. However, the numbers are not as useful for monitoring a PwD that is already diagnosed with AD. Furthermore, individuals in the care circle have different preferences. Thus, the system should be personalisable. The personalisation is a non-functional requirement that plays a significant role for the acceptability. Lack of this ability can overshadow the system functionality. To reflect on the significance, the section provides a dedicated sub-section to this topic. In order to design such an adaptive and personalised system, tools capable of user modelling are required. Tools such as personas, scenarios, and use-cases. Excluding the PwDs from requirement gathering process through only relying on user-modelling tools based on existing literature, and interviews with caregivers can lead to a range of ethical questions and concerns. For instance, what are possible effects of relying on caregivers for collecting the requirements? These issues can be thoroughly addressed after the implementation by observing stakeholders’ interactions with the system. Thus, these points were not heavily focused upon by this study. Having said that, we lay the foundation stone of ethical design by incorporating non-functional requirements such as transparency (Sect. 3.2.4), and seamless integration. It is worthy to mention that, using provided guidelines in the study Mahoney et al. (2007) during the SH trial could further assure the reflection on the ethical perspective on the SH design.

In this step, first, the most common functional and non-functional requirements of an SH for dementia care are collected. Later, the design is extended with components to satisfy the personalisation requirements.

3.1 Functional requirements

Functional requirements are collected in the form of documents that describe system operations and activities. They were elicited by extracting elements of the scenarios and manifesting them as use cases. The process of analysing the use cases led to the gradual emergence of the necessary software and hardware components of the system. For instance, Table 3 present a use case produced at this stage. Rest of the use cases can be found in a URL ¹. Each table incorporates four sections: concept, the rationale of the system behaviour, scenario, and the required components (Amiribesheli and Bouchachia 2016). The key SH components and their inter-relation is thoroughly introduced in Sect. 4.

Table 3 Use case 1: learning new interactions

3.2 Non-functional requirements

Besides the particular features and functions that an SH offers to the stakeholders, there exists another group of requirements that affect the overall operation of the system, rather than its specific behaviours. These requirements are described as ‘non-functional requirements’ or ‘quality attributes’. For instance, the reliability is not a feature for SHs, yet, it is required. The non-functional requirements emerge from the entire system architecture rather than any specific component. They play a significant role in the system acceptability amongst the users. A suitable method for obtaining the non-functional requirements is to investigate the concerns and issues raised by the caregivers.

The system should have a group of quality attributes to adequately address the concerns. For instance, during the interviews, some stakeholders had concerns regarding the possible increase of PwDs’ anxiety resulted by simply putting unfamiliar devices (e.g., sensors) in the home environments. To address this concern, the system hardware should be installed in a seamless manner. In the following, necessary quality attributes of the SH are provided.

The modularity, distribution, seamless integration and transparency are considered as principal non-functional requirements of SHs for dementia care.

3.2.1 Modularity

As mentioned earlier, the personalisation in one of the key requirements of the SH. In a personalisable SH, stakeholders can choose their preferred care approach and technology (e.g., sensing devices, and alerting systems). To achieve this, an approach is to make the SH modular. The modularisation concept can be applied to a system in composition and decomposition methods. In the composition (bottom-up) method, modules are put together to form a larger system. In this approach, all the components are built as separate units and then connected to form the system. For instance, an SH software could have interface, sensors, and reasoning engine modules. An alternative is to take a larger system and decompose it into smaller modules. This approach is described as the decomposition or top-down method. It is applied to analysing and improving a large system. For instance, for an SH system, the interface module can be designed using two separate sub-modules of administration and users’ interfaces.

Both modularisation approaches can be used in developing SH system. The Service-Oriented Architecture (SOA) is a common development approach for a modular system. The SOA-based SHs can provide services that are platform-independent and reusable. Moreover, an SOA SH is extensible, which implies stakeholders can add or remove services at any given time.

3.2.2 Distribution

The SOA architecture can address the modularity requirements of the SH. However, they often utilise a client-server model. It means all processes run on a computing unit (gateway), that puts all the load on a single machine. This causes the SH system to suffer from a “single point of failure”, which leads to issues with the SH system, particularly reliability. In the client-server design, the gateway failure causes all the SH services to be unavailable. Client-centric distributed design methods prevent these problems by allowing the processing load to be divided into different hosts.

A client-centric SH can be designed adopting a group of multi-node architectural patterns (e.g., peer-to-peer computing, mobile computing, cloud computing, and virtualisation). In a client-centric SH, the process is distributed over individual nodes, and the collected data can be stored on a single or distributed database. Hence, a client-centric SH can run on multiple physical devices simultaneously.

3.2.3 Seamless integration

When a new piece of assistive technology is introduced to the dementia care circle, often it is not accepted by users because of design issues rather than the functionality-related ones. A common problem is when unfamiliar devices (e.g., sensors and actuators) are introduced to the PwD’s living environment as they can cause them anxiety Tiberghien et al. (2012); Maitland et al. (2011). To prevent this from happening, all the in-home physical components of an SH system must be seamlessly integrated into the environment. For instance, the communication between PwD and the SH should occur through natural user interfaces or familiar devices such as radio and TV.

3.2.4 Transparency

It is defined as the clear flow of information amongst stakeholders and the system. An SH is transparent if the users are capable of answering questions such as what are the types of data collected by the SH? Who has the right to access the collected data? Caregivers and PwDs repeatedly raised concerns regarding transparency of the SH system (Lê et al. 2012). Lack of transparency can damage the users’ trust in the system and decrease its acceptability. To address the issue, a dedicated framework (Amiribesheli et al. 2016) is introduced for transparency in intelligent environments.

3.3 Personalisation of the SH

Dementia care stakeholders adopt distinct ways for attending a care situation. Also, PwDs are individuals with different needs that change over time. Therefore, the system should be personalised by its users. For instance, for the night-time wandering scenario (see Table 2), a geriatric physician might ask the system to provide the PwD with instructions to take a sleeping pill to going back to bed; while another physician might only request the system to provide the PwD with instructions to return to the bed without taking pills.

The personalisation is a multifaceted challenge that involves altering the software and sometimes hardware components of the system. In this work, it is addressed from the software-development viewpoint. The personalisation allows the users to define customise reactions to the changes in the environment and PwD’s states. The variations in the states and their required reactions can be expressed in the form of rules. A rule defines a pattern of changes and specific actions that should be triggered when it occurs. To work with the rules, the SH requires two key software components of the rule management interface and the reasoning engine. The interface empowers relevant stakeholders to enter new rules to the system or to manage the existing ones in an effortless manner. The reasoning engine extract information, deduce knowledge, and constantly matches the rules with the collected information and deduced knowledge to set the reactions of the SH.

4 System design

The design phase includes the process of defining a structure for the system that can satisfy the stakeholder’s requirements. To that aim, it produces a group of diagrams that depict the system architecture by describing the components, relations among them, and properties of both components and the relations. In this study, the unified modelling language (UML) was adopted for expressing the diagrams that later are employed for the system development.

For this study, both static and dynamic UML diagrams are employed. First, the SH functions and their primary users are visually represented by the use case diagram. Then, the behaviour of each component is introduced in more details through the sequence diagram. Next, a blueprint of the system components is illustrated through a component diagram. Finally, a deployment approach for the SH is depicted using the deployment diagrams.

4.1 Use case diagram

The use case diagram provides an easily comprehensible view of system functions and their targeted users. Figure 2 presents the SH prototype use case diagram. Apart from the ‘monitoring vital signs’, ‘repeating speech’ and ‘losing personal items’, the other use cases are primarily focused on SH interaction with the PwD, and their functions are extended by an incident monitoring interface to provide information for caregivers.

Fig. 2

SH use case diagram

4.2 Sequence diagram

The UML sequence diagram is adopted to illustrate the interconnection and the behaviours of system components. To provide a comprehensive picture, the system components are not introduced following a specific programming paradigm (e.g., object-oriented, modular). They are the essential elements that shape system functions and can be implemented as classes or modules. In the requirements elicitation phase, the following components were identified: a communication protocols, a middleware component, a reasoning engine, managing and monitoring interfaces, a database management system.

• Communication interface The SH system requires a number of communication devices and protocols to enable in-home and remote communication amongst the components and users. The communication protocols are in charge of providing and maintaining the link between the system and the outside world.

• Middleware component The role of the middleware is to bridge physical devices (e.g., sensors) with rest of the system. Also, it should include the necessary abilities for discovering, adding and configuring new hardware devices to the SH. Ideally, the processes should occur without the need for restarting or reconfiguration of the system.

• Reasoning engine The role of the reasoning engine is to infer knowledge from the collected data and decides the SH reactions. The reasoning engine enables the SH system to change its behaviours (e.g., reactions) in reaction to the changes in the users’ and the environment contexts.

• Web interfaces The interfaces enable the stakeholders to change the SH configuration and to monitor the PwDs situation (e.g., incidents monitoring). Considering the users’ diversity, it is necessary to develop cross-platform interfaces that are available on a variety of devices (e.g., mobile phone, tablet and PC). Later, this component is decomposed to two sub-component of managing and monitoring, and the rule management interfaces (ee Sect. 5.2).

• Database management system As an SH uses and generates a high volume of data, a set of databases are required to store them. Therefore, the SH needs a database management system.

Fig. 3

Learning difficulties sequence diagram

Figure 3 presents the sequence diagram for “learning new interactions” use case. It shows the following actions: (1) Opening the microwave door activates a contact switch sensor. (3) The sensor triggers a signal that communication interface receives. (4) Communication interface sends a message to the middleware using a supported protocols (e.g., a simple text of CSS_MW_on_off). (5) The middleware records the event by manipulating the relevant database using the DataBase Management Services (DBMS). (6) The reasoning engine reads the database and triggers the associated rules for the event. For instance, “the rule is to play an audio instruction in the kitchen using the digital radio as an actuator”. (7) The communication interface transmits the order to the digital radio located in the kitchen that plays the guides for using the microwave.

4.3 Component diagrams

In the previous step, the SH components and their exchanged messages were formally presented. Here, all the components are presented together in a UML component diagram. The component diagram portrays the system as a whole by exposing the components interconnections. Considering the nature of the design phase, this diagram might be modified and updated during prototype implementation. Figure 4 presents the components that are architecturally significant for the deployment of the prototype. Furthermore, it presents the services provided and used by the components within the system. As an instance, the reasoning engine uses the DBMS service to perceive changes in the PwD’s situation or the environment. The engine uses the middleware services to react to the changes. Furthermore, if a new device is connected to the SH, the middleware can employ the reasoning engine service updating feature to improve the SH functions accordingly.

Fig. 4

SH components

4.4 Deployment diagram

Up until here, the SH components and their relationships were presented. Here, details of physical deployment of the prototype are introduced. The UML deployment diagram depicts the run-time architecture of the system. It incorporates system platforms and software modules that run on top of them. In the diagram, the platforms are either hardware devices or software execution environments. Figure 5 illustrate the system deployment diagram.

Fig. 5

The deployment diagram

The diagram includes four key platforms:

• Gateways they are physical devices that host primary interface, logical and data tier components. For providing basic functions, the SH requires at least one functional gateway device. Considering the distribution requirement (see Sect. 3.2) of the SH, the modules should be able to run on a group of separate gateways as well. It means the system should be deployed in a way that supports several gateways. For the prototype implementation, multiple gateways were used.

• Caregiver devices to access the SH interfaces, caregivers will use a variety of devices (e.g., PC, mobile). Ideally, the interfaces should be easily accessible across all the commonly used devices. To address that, the SH prototype interfaces are developed as web applications accessible through standard web browsers.

• Sensors and actuators these platforms include devices that can collect data from residents and the environment, and change the state of the environment. These platforms include a diverse set of physical devices such as binary sensors, vital signs monitoring kits, and switches for controlling in-home power plugs remotely.

• In-home interfaces these platforms are advanced interactive or non-interactive displays conveying information between the system and the SH residents. They include devices such as tablets placed on a surface, smart radios and smart TVs. They are equipped with standard web browsers modules.

5 Prototype implementation

In this section, a prototype is developed based on the presented designs. An evolutionary implementation approach is followed. The approach begins by developing a robust initial prototype and refines it through iterative evaluations. The iteration continues until the prototype is deemed as adequate and safe by the stakeholders. In the following, the hardware and software components of the prototype are introduced in details.

5.1 Hardware components

Studying, optimising and evaluating hardware components of an SH are not the key objective of the study. Nevertheless, the prototype capabilities cannot be fully illustrated and evaluated without running them on adequate hardware devices. In our implementation, two groups of hardware devices were used: (1) sensor, actuators and in-home interfaces and (2) gateways. They are described in the following section.

5.1.1 Sensor, actuators and in-home interfaces

Hardware manufacturers are in a constant competition over producing more affordable and ever more customisable SH technologies (e.g., temperature sensors, vital sign monitoring technologies). Naturally, an SH function can be developed utilising a variety of hardware devices coming from different providers. For instance, to check the PwD’s location, employing both passive infrared sensors and cameras could be equally effective. Therefore, the prototype should be developed in a way that can function utilising different available technologies. This gives the SH users the ability to choose based on their prefrences. Ideally, the SH should be an open system where devices join and leave while offering a particular service to the users. Such a design would improve the SH abilities to be personalised and it is modular which is aligned with the elicited non-functional requirements.

Although the SH system ideally should be developed as an open system, for this implementation, the prototype was set up to utilise only binary sensors and vital sign reading. This approach complied more with PwDs’ privacy  (Demiris and Rantz 2004) and transparency requirements. Additionally, it prevented the prototype from being resource-intensive (Lifton et al. 2007)

For generating the necessary data for the prototype, CSS sensors, PIR (motion) sensors, and pressure sensors were used. PIR sensors were used to simulate data that shows the PwDs’ presence in different in-home locations. CSS sensors were used to simulate data gathered from the room doors and cabinets for identifying the PwD’s interaction with these objects. Furthermore, pressure sensors were used to simulate the collected data from sofas, beds, chairs and floors. Also, to generate health monitoring data, we employed an e-health sensor kit that included sensors for vital signs monitoring such as SPO2, airflow, body temperature, and blood pressure.

As mentioned earlier, the SH in-home interfaces are a group of interactive and non-interactive devices (e.g., tablets, smart radios and smart TVs) that convey information between SH and the residents (i.e., caregivers and the PwD). For the prototype, a tablet with Android OS was used as a digital frame mounted on the home wall. Also, a digital wireless radio was used to test the SH capability for playing sounds (e.g., guides and instruction).

5.1.2 Gateways

The prototype gateway device should be light, cheap, easily replaceable and fault tolerant. Principally, several single board computers can satisfy these needs. In this work, the Raspberry Pi (model B) was chosen as it was affordable and widely available. It had a 700 MHz processor, 512 MB of RAM, and communication ports including USB and general-purpose input/output (GPIO).

The power source of a gateway is one of the key challenges that affect its reliability. It is important for gateways to function even during an unexpected event such as electrical disturbance at home. The Raspberry Pi addressed this issue by accepting the following alternative power sources:

• Solar chargers that are available for mobile phones.

• Universal serial bus (USB) ports, powered USB banks.

• Alkaline batteries.

In our prototype, a non-graphical version of Linux operating system, an Apache web server, the middleware, a PHP service, a Python compiler, Java virtual machine (JVM), and an instance of MySQL DBMS were installed on the gateway. For the fault tolerance, the gateway was configured in a way that the settings and collected data were backed up automatically on another identical machine utilising file transfer protocol. The backup machine (also known as the passive gateway) was always ready to function as the prototype gateway at any given time.

Fig. 6

Prototype communication interfaces

5.2 Software components

The following five key software components were used in the prototype: Communication interfaces, Middleware, Managing and monitoring interfaces, Reasoning lngine, and Rule management interface.

5.2.1 Communication interfaces

Physical communication ports are required for connecting the interface, logic and data tier components. Figure 6 illustrates the prototype communication ports. To use the ports, the components require communication interfaces (i.e., computer networking and proprietary protocol) running on the gateway device.

The Raspberry Pi wired Ethernet networking card is utilised to connect the system to the Internet through a router. To secure the SH inner-communications, the gateway is equipped with a functioning Linux-based firewall (i.e., the uncomplicated firewall package). Furthermore, all the network traffic between the active and passive gateways goes through a secure VPN connection (OpenVPN package).

There exists a variety of sensor networking protocols for in-home communication as sensors and actuators might require proprietary network protocols. By default, the gateway is equipped with GPIO, inter-integrated circuit (I2C), and serial peripheral interface (SPI) protocols. They enable it to communicate with a broad range of binary sensors and switches (i.e., binary actuators) devices. In our implementation, the gateway is enabled to contact indoor sensors using the GPIO. As the Raspberry Pi has a limited number of GPIO ports, a GPIO port extender is used.

5.2.2 Middleware

The middleware software enables the physical devices (e.g., sensors, actuators) to communicate with rest of the system. It provides a software connectivity layer to make the devices accessible by the other software components. There exist several open-source middleware systems for SHs that can be adjusted to meet the necessary requirements of the prototype (Tazari et al. 2012; Wolf et al. 2010). In this work, to save resources, we opted for this solution instead of developing a new middleware from scratch. The open Home Automation Bus (openHAB) (OpenHab 2017) is an open-source middleware developed based on Java open service gateway initiative (OSGi), which is one of the most common approaches to implementing SOA (see Sect. 3.2). As the middleware was based on a Java OSGi framework, it requires a JVM to run on the gateways. Also, it allowed the devices to be added and removed without causing any negative ripple effects on the system functionality.

Fig. 7

Middleware modules

Figure 7 illustrates the openHab modules that were used in the prototype. The rules management module shown in the diagram accepts basic if-then statements written in the Java Xtent programming language. The event bus module is responsible for the middleware reactions to events. It reacts to two types of events (a) changing the state of a device based on the rules, (b) updating the database in reaction to status changes in the devices. The binding module connects the event bus to the SH devices through the communication platforms.

Considering the dementia care requirements, the default rule management module of the middleware is unsuitable for the knowledge deduction and decisions making. For that reason, a dedicated reasoning engine was developed, which will be discussed in Sect. 5.2.4. The middleware executes the reasoning engine commands by performing the following steps: (1) the reasoning engine changes a specific entry in the commands database. For instance, it changes the living room light entry value from 0 to 1. (2) The middleware rule management module runs the rules associated to each of the commands entries using the event bus. For instance, if the living room light entry is 1, it turns on the living room light. Furthermore, the sensor data is collected by performing the following steps: (1) a sensor changes state and it sends a signal to the middleware through the communication interfaces. (2) The event bus writes the event and its time stamp to the sensor database.

5.2.3 Managing and monitoring interfaces

The interfaces are responsible for enabling the stakeholders to interact with the system to monitor the PwD and to determine the SH intervention behaviours. Ultimately, adopting tools (e.g., movement monitoring) provided by the interfaces improve PwDs’ quality of life through enhancing their in-home safety. Furthermore, the interfaces help formal and social caregivers to perform their tasks efficiently. Additionally, the informal caregivers’ peace of mind is increased as a result of highly accurate constant online monitoring information.

Fig. 8

List of available monitoring functions for a PwD (PC view)

After selecting the monitoring option, following the authentication of the user, each caregiver was presented with a list of PwDs whom they care for. After selecting the PwD, the facts about the activity and the health of the selected PwD were displayed. Figure 8 shows the default available SH monitoring functions (e.g., sleeping hours) and the overall situation from a PC browser. Also, by clicking on the PwD details button a short form of the medical record would be presented.

Fig. 9

Critical events detected by the system (PC view)

Fig. 10

Sleep type per hours (PC view)

Figure 9 shows the screen that allows the caregivers to adjust the intervention level for an alert. In case the type of action was not adjusted by the caregiver, the system performs the default intervention. For instance, if the geriatric set the required threshold for the daily urination times “often” and the collected data illustrated “seldom”, then the system assumed that the PwD is not drinking enough water. Hence, it would play a pre-recorded audio reminder via a wireless speaker in the PwD’s location. Furthermore, an email alert would be sent to the caregivers for information. By clicking on each alert, the relevant data was visualised. For instance, Fig. 10 presents the PwDs’ sleeping hours and types collected (0 = deep sleep, 4 = awake) by a mobile phone located on the bed.

5.2.4 Reasoning engine

The key functionality of the engine is to extract information from sensor data, to deduce knowledge from the information, and to decide the SH reactions based upon the deduced knowledge. In this work, the knowledge deduction and decision-making were conducted based on a set of rules. As an example, a geriatric physician creates a rule that requires the system to automatically activate a phone call to emergency services if the PwD falls and does not move for ‘a long time’. In principle, the engine enables the SH to reason and behave like a vigilant caregiver who continuously monitors the PwD and act based on formal caregivers’ specific instructions.

The engine adopts various levels of contexts to extract information and deduce knowledge:

• 1. It uses the micro-contexts to extract information (also known as activities) from the raw sensor data (e.g., PIR sensor readings). This process often includes applying activity recognition techniques.

• 2. It needs the macro-context for transforming information to knowledge (e.g., PwD is wandering). To do that, the system should be fully equipped with reasoning methods such as rule-based systems to map an activity or a group of activities to a given event.

Ultimately, to gain wisdom and react, the engine employs a rule-based system to match the occurrence of specific events with decisions.

Fig. 11

Reasoning engine structure

Figure 11 shows the structure of the engine and its relation to rest of the SH components. The engine transforms collected raw data into knowledge and wisdom. The sensors and in-home interfaces generate raw data which an activity recognition unit processes to recognise activities (e.g., sitting on a sofa, PwD’s location) from. Following, an inference system matches the activities and direct pieces of information from the caregivers (e.g., PwD has a cold) to a group of rules to discover events (also known as situations). The inference engine matches gathered events to the rules to produce decisions. For instance, reminding the PwD to take his sleeping pills when he is experiencing an intermittent insomnia episode. In this study, we do not aim to explore and improve activity recognition techniques. Therefore, it is assumed that all the required information are precisely collected and reasonably inferred. In the following, a rule-based system is introduced and develop to deduce knowledge and gain wisdom.

The rule-based system is used to match the extracted information with a set of rules to deduce knowledge. It is also used to match the knowledge with rules to make decisions. Each rule is an IF-THEN statement that has antecedents (also known as premises) after the ‘if’, and consequences that come after the ‘then’. The rule-based system checks the validity of the antecedent against the information or the knowledge, and if it is validated as true, it triggers the consequences of that rule. The process is forward chaining as it begins by processing information to reach an outcome (e.g., an action).

A rule-based system is developed with either imperative (e.g., Java, Python) or domain-specific rule-based (e.g., Prolog, CLIPS) programming paradigms. In this work, the imperative paradigm is used. The paradigm considers the antecedent of a rule as a Boolean proposition with true or false value. Using the logical operators (e.g., AND, OR), it also enables the rules to have more than one antecedents. The antecedents are considered true if they meet a distinctly defined condition. For instance, assuming that the average number of night-time wandering incidents per night over a month precisely corresponds to N, to set a rule, the following statement with a threshold is needed:

In the real-world, members of the care circle rarely follow rules with precise numeric thresholds. For instance, a formal caregiver asks informal caregivers “if the PwD’s pulse rate is slow, inform a caregiver”. There are multiple approaches (e.g., probability theory and fuzzy logic) for a system to cope with uncertainty. The most common way is to employ fuzzy logic (Zadeh 1965; Medjahed et al. 2011; Doctor et al. 2014). Using fuzzy logic, users can define rules that have premises with linguistic variables. Fuzzy rules are IF-THEN statements where the antecedents and consequences are fuzzy propositions that include linguistic variables (e.g., too many, too few). An antecedent is to a certain degree true or false. Considering the example of night-time wandering incidents:

A fuzzy set X is defined for “high” linguistic variable, let N be the average number of night-time wandering incidents per night over a month and $\mu (N)$ is a membership degree from 0 to 1. Thus, $X = \left\{ N, \mu (N)\right\}$. The $\mu (N)$ is defined as:

• For $N \le 10$: $\mu (N) = 1$

• For $N = 0$: $\mu (N) = 0$

• For $10>N>0$: $1>\mu (N)>0$

To create a fuzzy set, the membership degree $\mu (x)$ is calculated using a mathematical function. The function (also called a membership function) defines how an element is mapped to a membership degree. For instance, three membership functions are needed to map the N to linguistic variables of ‘low’, ‘acceptable’ and ‘high’. There are different forms of membership functions such as triangular, trapezoidal, piecewise linear, Gaussian, and singleton.

The fuzzy rule-based system is a rule-based system that accepts fuzzy rules. It requires the following elements to function:

• Fuzzy Rules In this work, they are stored in a database that is accessible by the engine.

• Membership functions In this work, a group of formal caregivers (i.e., five geriatric physiologists) provided the necessary information (i.e., thresholds) to develop the membership functions for the common care linguistic variables. They were asked about their interpretations of vital sign and healthcare sensor readings (e.g., as blood pressure, glucose level, sleeping hours, numbers of night-time wandering incidents) for an elderly PwD with type two diabetes. Later, different types of membership functions (i.e., Triangular, and Trapezoidal) were used to implement them.

• Input information In this work, they are stored in a database accessible by the engine.

In addition to knowledge deduction, the rule-based system utilises specific occurrences of each symptom expressed by linguistic variables to determine a health index. The index indicates a PwD’s overall health condition. It is calculated by incorporating the adverse outcomes of the symptoms on PwD’s health. It is expressed as a number between 0–100 (i.e. 0 indicates that the PwD’s health is critical, and the 100 indicates that he is entirely healthy). To calculate the index, the system should be informed on the relationship between the symptoms and the health index. For example, if the PwD has a ‘high’ average of night-time wandering incidents per night over a month the index should be reduced.

To function, the fuzzy rule-based system requires three types of rules:

• 1. Knowledge extraction rules They are used to deduce knowledge (also known as fact) from information. Caregivers do not need to change or updated these rules for each PwD. Also, as they form the knowledge of the system, they should be fired before any other types of rules. For instance:

  R1 IF ‘Current_time’ IS ‘Sleeping’ AND ‘Accelerometer_Active_Time’ IS ‘Too Long’ THEN Signal ‘NTW’ AND Update ‘SUM_NTW’ ++

  Where: The ‘Current_time’ is fuzzy set for time with two membership functions of ‘Awake’ (e.g., 6 a.m.–11 p.m.) and ‘Sleeping’ (e.g., 10 p.m.–8 a.m). The ‘Accelerometer_Active_Time’ is a fuzzy set for accelerometer activation time with three membership functions of ‘A short time’, ‘Acceptable’ and ‘Too Long’. The Signal is a programming function that changes an event status to ‘True’. The NTW is a variable that represents the occurrence of night-time wandering incident. The Update is a programming function that change the value of a variable. The ‘SUM_NTW’ is sum of nigh-time wandering incidents.

  R2 IF ‘Avg-in-home activity’ IS ‘Low’ AND ‘Avg-out-home activity’ IS ‘Low’ THEN Signal ‘Over-all in-active’.

  Where: The ‘Avg-in-home activity’ is fuzzy set for average in-home activity over a month period collected by sensors with three membership functions of of ‘Low’, ‘Acceptable’ and ‘High’. ‘Avg-out-home activity’ is fuzzy set for average out-home activity over a month collected by sensors (e.g., mobile GPS) with three membership functions of ‘Low’, ‘Acceptable’ and ‘High’. The ‘Over-all in-active’ is a variable that represent the PwD is overall inactive.

• 2. Health index calculation rules They are fired to calculate the health index. They explicitly define the relationships between the occurrence of symptoms and the health index. These rules should be tuned for each PwD. Caregivers provide constant negative values for each symptom. The value demonstrates the negative significance of a symptom on the PwD’s health. Later, in this section, the calculation process is presented.

  R3 IF ‘Avg_ntw’ IS ‘High’ THEN HealthConcern.

  Where: The ‘Avg_ntw’ is fuzzy set for an average number of night-time wandering incidents over a month. It has three membership functions of ‘Low’, ‘Acceptable’ and ‘High’. HealthConcern is a programming function that reduces the health index.

  R4 IF ‘Avg_sleeping_hours’ IS ‘Low’ THEN HealthConcern.

  Where: The ‘Avg_sleeping_hours’ is fuzzy set for average of monthly sleeping hours. It has three membership functions of ‘Low’, ‘Acceptable’ and ‘High’.

• 3. Decision-making rules They are fired by the inference system to make decisions. Some of these rules are built into the system, and some are written by the caregivers. Their consequences include SH actions for different situations.

  R5 IF ‘Dehydration’ IS ‘True’ THEN Inform (formal caregiver).

  Where: The ‘Dehydration’ is an incident statement that is either ‘true’ or ‘false’. The ‘Inform’ is a programming function that sends a message to a/a group of people via their preferred medium.

  R6 IF ‘Over-all inactive’ THEN Inform (all the caregivers).

  Where: The ‘Over-all inactive’ is an incident statement that is either ‘true’ or ‘false’.

  R7 IF ‘A pill is missed’

  THEN Play_BedroomSpeakers (reminder).

  Where: The ‘A pill is missed’ is an incident that is either ‘true’ or ‘false’. The ‘Play_BedroomSpeakers’ is a programming function that uses the bedroom speaker to play a pre-recorded audio reminder.

In this work, the Takagi-Sugeno (also known as the TSK fuzzy model) (Sugeno 1985) is used. TSK accepts fuzzy rules in the following format:

IF input IS $linguistic\_variable$ AND/OR $input_2$ IS $linguistic\_variable_2$ THEN $Z=function$.

Where $linguistic\_variable$ and $linguistic\_variable_2$ are fuzzy sets in the antecedent, while $Z=function$ is a crisp function in the consequent that determine an output level. Commonly, the Z is a polynomial that includes the input variables (e.g., $f(input, input_2)$), however, in this work, Z is a constant, that makes the inference method a zero-order Sugeno fuzzy model.

To infer rules, TSK performs the following five tasks:

• 1. Fuzzification of the inputs.

• 2. Calculation of the rule weights.

• 3. Calling the consequence function.

• 4. Calculation of the health index.

The fuzzification is simply the process of adopting membership functions to map discrete inputs to a membership value. In this research, membership functions that are formed by straight lines such as TRiangular-shaped Membership Function (TRIMF) are used. TRIMF is defined by a lower limit a, an upper limit b, and a value m, where $a< m < b$. The function is expressed as follow:

$$\begin{aligned} \text {TRIMF} (input, [a,m,b]) = \left\{ \begin{array}{ll} 0 &{}\text {input}\, \le a\\ \frac{input-a}{m-a} &{}a< \,\text {input }\,\le m\\ \frac{b-input}{b-m} &{}m< \,\text {input}\, <b\\ 0 &{}\text {input}\, \ge b\\ \end{array}\right. \end{aligned}$$

For example, the following membership functions are defined: The ‘a long time’ = TRIMF (input walking minutes, [5, 10, 10]), the ‘a short time’ TRIMF (input walking minutes, [0, 0, 7]).

Fig. 12

Rule weight calculation

In the second step, the inference method applies the fuzzified inputs to antecedents of the fuzzy rules for the purpose of calculating the rule weight. Figure 12 visualise the process of calculating a rule weight of $w_i$ for a rule including a binary type and a linguistic variable in the antecedent. We used the natural interpretation of the conjunction and disjunction to perform multi-criteria decision making. This approach is also known as Godel t-norm (Hájek 2002).For the binary value, the on and the off linguistic variables are used. In a rule, when there are more than one fuzzy inputs, fuzzy logical operations are used to calculate the weight:

$$\begin{aligned} \mu (A) \,\hbox {AND} \,\mu (B)= & {} \text {min} \left\{ \mu (A), \mu (B) \right\} \\ \mu (A) \,\hbox {OR} \,\mu (B)= & {} \text {max} \left\{ \mu (A), \mu (B) \right\} \end{aligned}$$

In the third step, the output level Z of each rule is multiplied by the weight of that rule to calculate an outcome Outcome=$w_i * Z$. For instance, if Z = 1, for the rule showed in Fig. 12, the output is calculated as $0.5 \times 1=0.5$. To fire a rule, the system calculate the outcome. It only fires the rule if the outcome is greater than 0.8.

The health index is calculated using the rules and a constant negative value that is associated to each symptom. To do that, all the rules weights are multiplied by their constant and the result is reduced from 100:

$$\begin{aligned} \textit{health}\_\textit{index} = 100- \mathop {\sum }\nolimits _{i=1}^{n} (W_i \times C_i) \end{aligned}$$

where $C_i$ is a constant weight that shows the adverse significance of each symptom. The constant is chosen by the caregivers in the way that $\sum _{i=1}^{n} C_i$ is not more than 100.

To execute, the engine constantly match the rules against the knowledge and information. To avoid making wrong decisions, the rules are fired in an order. It begins by running the rules for deducing knowledge, then it runs the rules for the health index calculation, and finally, it executes the decision-making rules.

Caregivers’ rules and the default system reactions might conflict. To handle this, the reasoning engine prioritises all the caregivers’ defined rules to the default ones. Also, amongst caregivers defined rules the more recent ones are executed.

5.2.5 Rule management interface

In this section, a web interface is introduced that enables the caregivers to enter and manage the rules. The rules such as “IF the PwD IS inactive THEN inform a formal caregiver. In a real-world setting, the majority of high-level care decisions are made by the formal caregivers such as dementia nurses and geriatric physician. The rest of the care cycle follow the formal caregivers’ instructions. Hence, the formal caregivers are the principal users of the rule management interface.

Considering formal caregivers diversity and their different computer literacy levels, the interface should be designed in a way that the interaction with it, requires minimum efforts. Moreover, the interface should provide a clear view of SH functions and capabilities to allow caregivers to create efficient rules. To do that, in this work, the interface is specifically designed as an end-user development (EUD) tool. The EUD refers to a set of methods, techniques and tools that allow non-expert end-users to modify, extend and create software artefacts.

The interface is designed as a visual attribute programming tool. The visual attribute programming is a subcategory of EUD in which the users interacts with the system through an interface that includes modifiable visual layouts. It presents the system functions, as attributes of a visual representation (e.g., position, colour) that can be changed by users. It can be implemented by methods such as the jigsaw pattern, the form generators, and the trigger-action programming.

Some studies  (Ur et al. 2014; De Russis and Corno 2015) propose the trigger-action programming as the most suitable way of enabling the users to generate rules for an intelligent environments. In this approach, users set the SH reactions by specifying triggers (e.g., “IF the blood pressure IS too high”), and the consequence actions (e.g., Send a message to the geriatric physician). Also, popular web applications such as IFTTT (Tibbets 2016) that allow users to generate rules for automation can be regarded as a successful implementation of drag and drop trigger-action interfaces. In this work, the prototype interface was developed as a drag and drop trigger-action environment.

Fig. 13

Main page of the rule management (PC view)

Fig. 14

List of rules (PC view)

Here, the rule management interface is implemented using PHP, JavaScript language and can be accessed through tablets, mobile phones and PCs. After clicking on the link located at the home page of the SH website, the caregiver is directed to the main page of the ‘rule management ’ (see Fig. 13). They are presented with the list of all the PwDs they provide care for. After clicking on the PwD’s name, a new web page opens that includes the rules (see Fig. 14). The page enables the users to modify the existing rules or add new ones. An intervention level bar indicates the level of intervention of the consequence of each care rule based on the physical devices (e.g., actuator) involved. For instance, reducing the light in the living room is classified as ‘a performing level’ intervention, and sending an email to a caregiver is ‘inviting awareness level’ (see Sect. 2.3).

6 Evaluation

Performing one evaluation could not include the great variety of the prototype applications. Accordingly, two separate evaluations were designed and conducted. The first one focused on assessing the prototype functions in successfully delivering support for the common care scenarios. The second evaluation focused on assessing prototype functions in delivering personalised care reactions. Further, the second evaluation assessed the amount of task load added to the prototype users while interacting with the system.

6.1 Evaluation 1: common care scenarios

Fig. 15

Physical setup of the evaluation prototype

To evaluate the prototype on the common care scenarios, a set of experimental tools were adopted that examined whether the system satisfies the specified requirements. Moreover, considering the general healthcare sensitivities, the evaluation process was designed to assure that the system as a whole does not put PwDs’ health and safety at risk. An SH system can be assessed from different aspects (e.g., functionality, reliability or usability). In this evaluation, the prototype was thoroughly evaluated from the functionality point of view . The preferable method of evaluating an SH is to deploy it in real-world environments and observe the stakeholders’ interactions with it for a substantial period. Observing the SH users interaction enables us to assess its impacts on the quality of the users’ experiences. However, the real-world deployment of a healthcare system is not possible without speculating on its potential benefits and its effects on the residents’ health and safety.

The evaluation is intended to illustrate that the SH system successfully achieves what it is designed to do (i.e., functionality), and it has the required quality attributes to be accepted and used by the users. Five geriatric specialists participated in two 45-min-long evaluation sessions in which they were presented with the prototype (see Fig. 15). The prototype was equipped with three sets of sensor devices including two groups of binary sensors [(passive infra-reds (PIRs) and contact switch sensors (CSSs)] and an e-health monitoring kit that included sensors for vital signs monitoring such as SPO2, airflow, body temperature, and blood pressure. Binary sensors and the e-health sensors were used to populate the databases through the process of acting the scenarios in the doll house. The participants could interact with the prototype using a tablet and a PC.

The key objectives of the evaluation were to answer the following questions based on the participants’ feedback:

• Does the system have the adequate monitoring capability to be installed in a real-world setting?

• Can the system reduce the care difficulty?

• Does the system consider PwDs’ health and safety?

• Can the system improve the quality of dementia care?

In the following, we provide the details of the process.

6.1.1 Evaluation approach

The SH evaluation approach should be sensitive to the individual differences of the caregivers and reflect their priorities in the final results. Moreover, it should not overlook any of the prototype components and their functions. Considering these, the following evaluation approach was selected.

Two evaluation sessions were held for each caregiver. We asked them to answer the questions before and after being introduced to the prototype. In the first session, we examined the importance, the difficulty, and effect of care actions on PwDs assuming that the caregivers performed them. In the second session, we investigated the difficulty and effect of the care actions on the PwDs assuming that the system performed them.

Three measures were utilised in the questionnaires. The “importance” and the “difficulty” were adopted from the study Wessels et al. (2002), while “effect” was introduced in this study.

• Importance The measure is applied to estimate the overall importance of a care response. It allows to examine the importance from monitoring PwDs and compensating their limited capabilities. Moreover, it enables the participants to judge the relevance of all the questions. The scale of this measure ranges from 0 to 5: 0 indicates that a care response does not have any importance at all, and 5 indicates that the question topic is significantly important.

• Difficulty The measure is applied to examine the difficulty of performing a care action with or without using the SH system. Naturally, it is anticipated to observe a significant drop in the difficulty level, after the SH is introduced to the participants. The scale ranges from 1 to 5: 1 means that the care response is quite easy to be performed and 5 indicates that it is extremely difficult to perform it.

• Effect The measure is applied to investigate the effect of performing a care action of the caregivers or the SH on the well-being of PwDs. It is expected for the care responses with higher importance to have a greater effect on PwDs. Using technology may result in a novel type of care that did not exist before. Therefore, its effects on the PwDs might change. The scale ranged from 1 to 5: 1 means that the care response does not have any effect on the well-being of PwDs and 5 suggests that it has a major effect on them.

6.1.2 Results

We asked 48 questions from the five participants in the first evaluation round. The questions included three sets of 16 items regarding the importance, the difficulty, and the effect of the care responses. In the second evaluation round, after introducing the SH to the participants, 36 questions were related to the difficulty and the effect of care responses. Therefore, each participant responded to 84 questions. As an instance, Table 4 illustrate the study questions regarding the dehydration risk, communication difficulties, and misplacing items for PwDs. Based on the answers, a difficulty score $D_{(score)}$ and an effectiveness score $E_{(score)}$ were calculated using the following expressions:

$$\begin{aligned} D_{(score)}&=&{{\text{``}importance\text{''}}} \, {\times } \,{\text{``}difficulty\text{''} }\\ E_{(score)}&=&{{\text{``}importance\text{''}}}\, {\times } \,{{\text{``}effect\text{''}}} \end{aligned}$$

For instance, the second participant, a geriatric specialist with 20 years of experience, supposed the results of monitoring repetitive speech symptoms provided critical diagnosis information $(i=5)$. He thought it was troublesome for the caregivers to record the change in the frequency of PwD’s repetitive speech $(d_1=4)$. Considering the possible imperfections of the manually collected data, reviewing them could have little effect on his diagnosis and consequently, on the quality of dementia care $(e_1= 3)$. After being presented with the prototype, he thought the difficulty of collecting the fluctuations dropped drastically $(d_2=1)$. Moreover, he would trust the sensor collected data more than manually collected data and the visualisation made the changes more explicit. Hence, it could have a more significant impact on his diagnosis and the quality of care $(e_2=4)$.

Figures 16 and 17 present the median D and E scores for each participant. The median of difficulty score was 16 in the first round of evaluation. It slashed drastically to 5 in the second round. Moreover, the median of effectiveness score was 16 which increased to 20 in the second round of evaluation.

Table 4 Study questions regarding dehydration risk, communication difficulties and misplacing items

Fig. 16

Median E scores for each participant in the two evaluation sessions

Fig. 17

Median D scores for each participant in the two evaluation sessions

6.2 Evaluation 2: personalisation and the task-load

Five geriatric physicians participated in the prototype evaluations that was extended with the rule management interface and the fully functional reasoning engine. The evaluation looked at the system functionality from three aspects of the importance of the system functions, the difficulty of utilising it, and its effectiveness in improving the quality of care. Moreover, the evaluation investigated the prototype usability through performing NASA-TLX (Hart and Staveland 1988) assessment that measured the amount of task-load added to caregivers’ routines when they use the system. During the sessions, participants were presented with a prototype that was equipped with the ‘monitoring and management’, and the ‘rule management’ interfaces. The interfaces could be accessed by mobile phones, tablets, or personal computers. Main objectives of the evaluation were to provide answers for the followings questions.

• Do the system functions match the needs of the users?

• Can the system reduce care difficulties for the formal caregivers?

• Does adopting the system improve the quality of delivering care?

• How much tasks-load employing the system adds to its users?

• What are the stakeholder’s concerns? Is the system capable of addressing them?

6.2.1 Evaluation approach

Two rounds of evaluations per participant were held. The first round began by providing the participants with a hypothetical PwD’s profile with her brief medical record. The profile was created consulting a geriatric physician to ensure its authenticity. The participants were presented with two care scenarios: (1) Monitoring PwD’s general health, and (2) monitoring PwD’s sleeping patterns. In the first round, they answered questions on the approaches for handling situations considering the PwD’s profile. They provided the concerns that they have when they attempt to gather information through conventional method (e.g., PwD’s feedback). Also, they wrote necessary care instructions for other stakeholders regarding each scenario. At the end of the first round, they provided scores (see Sect. 6.1.1) for importance, difficulty and effectiveness of each scenario.

During the second round, the participants were introduced to the system. After choosing their preferred interaction device (e.g., tablet, laptop), they were asked to provide instructions for the two scenarios employing the system. They provided scores for the difficulty and effectiveness based on the system functions. Also, they judged if the system addressed the concerns that they mentioned in the first round. At the end of the session, their interactions task-load were gathered adopting the NASA-TLX approach.

Table 5 Backgrounds of the participants

Table 5 presents participants’ (i.e., formal caregivers) experiences in dementia care and their self-declared general computer literacy level. Table 6 displays her brief medical record. The records only include information, that potentially affect the participants’ instructions.

Table 6 Medical record

6.2.2 Baseline study—round 1

Scenario 1 In the first scenario, the participants ask Angela or a social caregiver to report Dorothy’s vital sign readings (VSRs) (e.g., blood pressure, blood glucose, pulse) to them. Caregivers should also notify the participants if a substantial change occurs in the readings. If deemed necessary, the participant could request for additional medical tests. For instance, if the blood pressure is high, the caregiver checks the possibility that the PwD has forgotten to take the necessary medications (i.e., Simvastatin). The informal and social caregiver needs to assure that the PwD takes the pills at the correct times and if the blood pressure does not return to the normal range he or she has to inform a formal caregiver. The participants were asked to elaborately answers two questions and provide instruction for the social and informal caregivers. At the end of first round, they gave the importance, difficulty and effectiveness scores of the scenarios for the time the scenario is performed by the social and informal caregivers.

Table 7 provides an instance of the participants’ answers in the round 1 for the scenario 1. Table 8 shows the participants’ scores for the scenario 1 round 1.

Table 7 Round 1 scenario 1: participant 1’s responds

Table 8 Round 1 scenario 1 scores

Scenario 2 The participants provided their feedback for a situation that they require Angela or a social caregiver to report on Dorothy’s night-time activities. The caregiver collects the number of pacing and night-time wandering incidents and report them to a formal caregiver. Commonly, these information are used to perceive the PwD’s dementia progress. This information is especially valuable in noticing PwD’s transition from MCI stage to Alzheimer’s disease. In this scenario, the participants were asked to provide the necessary guidelines for the caregivers on handling night-time wandering incidents as well as collecting the numbers of occurrences.

Table 9 provides an instance of the participants’ answers in the Round 1 for the Scenario 1. Table 10 shows the participants’ scores for the scenario 1 round 1.

Table 9 Round 1 scenario 2: participant 1’s responds

Table 10 Round 1 scenario 2 scores

6.2.3 Interacting with the system—round 2

In the followings, the participants’ scores and feedback after interacting with the system to perform the scenarios are provided. Table 11 shows sample rules generated by the participants for the first scenario. Table 12 presents the scores provided by the participants for performing scenario 1 using the system and number of rules their generated. Table 13 shows the summary of participants’ feedback regarding the scenario 1 and their opinion regarding the system capability to address them. Table 14 shows sample rules generated by the participants. Table 15 shows the scores provided by the participants for using the system to perform scenario 2 and number of rules their generated. Table 16 shows the summary of participants’ feedback regarding the scenario 2 and their opinion on the ability of the system to address them.

Table 11 Round 2 scenario 1 sample rules

Table 12 Round 2 scenario 1 scores

Table 13 Scenario 1: participants feedback regarding the SH efficiency

Table 14 Round 2 scenario 2 sample rules

Table 15 Round 2 scenario 2 scores

Table 16 Scenario 2: participants feedback regarding the SH efficiency

Fig. 18

Average D scores in the two rounds

Figures 18 illustrates participants’ average E and D scores for in two rounds of the dynamic prototypes evaluation.

6.2.4 NASA-TLX results

NASA-TLX is a multi-dimensional rating procedure that provides an overall task-load score based on a weighted average of ratings on 6 sub-scales of mental demands, Physical demands, Temporal demands, Own performance, Effort and Frustration. The assessment results illustrate speculated amount of task-load (from 1 to 100). Table 17 presents the outcome of the NASA-TLX for each participants while interacting with the system.

Table 17 Participants’ TLX results

7 Discussion

A functional SH prototype for the dementia care was introduced by tailoring a group of widely available hardware devices, open-source platforms and a collection of well-designed software components. The prototype was developed reflecting on blueprints that were designed based on the stakeholders’ requirements. It included interfaces that empowered caregivers to monitor PwDs and determine the SH reactions to different situations. Further, the prototype incorporated a variety of in-home interfaces and actuators to intervene in the PwDs’ lives in ways, which were prudently chosen by the caregivers.

Considering the results of the first evaluation shown in Sect. 6.1.2, it is fair to assume that the prototype SH reduces the difficulties of dementia care for common care scenarios dramatically. It increases the caregivers’ peace of mind and allows them to spend more time on tasks that improve the well-being of PwDs.

Individual stakeholders’ needs, as well as, the progressive nature of dementia, cause the necessity of the SH personalisation. This implies that the system should enable the caregivers to define care instructions without the need of going through exhaustive software engineering process. Focusing on this aspect, the second evaluation (see Sect. 6.2) demonstrated that employing a personalisable system further reduces the caregivers’ difficulty and improves the effectiveness of the delivering care. This phenomenon is rooted in the fact that the personalising empowers the caregivers to monitor the PwD or provide care for them in the ways that were not possible through conventional fixed-function systems.

Looking at the participant answers’ in the first round of second evaluation, it is evident that they have different approaches to handle an incident. They also have contradicting ideas about the possibility of involving social and informal caregivers in the monitoring process, and how trustworthy the non-medical caregivers’ observations are. Using the system they still had their various approaches. Nevertheless, they had fewer trusting issues in regards to the collected data by the system. Tables 13, and 16, illustrate that the majority of participants agreed that the system could address most of the concerns. The only concern that was not dealt with by the prototype was regarding the expenses of installing and maintaining SHs. This was predictable considering the exploratory nature of the study (Fig. 19, 20).

Fig. 19

Average E scores in the two rounds

Fig. 20

NASA-TLX results

The participants used the interfaces to enter their instructions as rules to the system. In some cases, they added rules that have not been mentioned in their instructions to the caregivers in the first round. For instance, none of the participants asked for monitoring information regarding PwD’s weekly journey to the cafe. However, after seeing the option in the interface, some provided it as a rule to the system.

Participants took part in a NASA-TLX assessment after interacting with the prototype. The amount of participants’ task-load score correlates with their self-declared level of computer literacy. The first participant with a low score, efficiently adopted the drag and drop interface while the fifth participant with a high score, found it physically and mentally demanding. Since the average computer literacy level of formal caregivers is rising globally, it is expected that the task-load for such interfaces will decrease. Ultimately, even the participant with the highest TLX scores was able to successfully define rules and use the system.

Finally, limitations of the study include few number of participants and overlooking the challenges that will only be faced when the system is deployed in a real-world environment. For instance, the prototype flawless success in the decision-making was based on the assumption that the activities (e.g., walking, and sleeping) were accurately recognised. However, in a real setting, the activity recognition is a challenging task.

8 Conclusion and future Work

The present research comprehensively reports on the requirements elicitation, design and evaluation of a tailored SH prototype for dementia care. The prototype was built in a way that addressed common and unique needs of PwDs and their caregivers. Results of evaluating the prototype show that it is able to satisfy the elicited requirements, without demanding complicated interactions from users.

In the next decade, utilising SHs will have profound effects on dementia care. However, for them to be accepted by the stakeholder, they still face some challenges. For instance, to precisely deduce knowledge and make decisions, the SH requires means of acquiring a set of unique information about the PwD. For instance, what is considered as a ‘high’ blood pressure for a PwD might be ‘acceptable’ for another one. In this study, we merely relied on the caregivers to provide the information. Machine learning can be used to discover and tune the information by processing the users’ activities. Future studies in this area can significantly improve the performance of the reasoning process.

SH for dementia care should be accurately assessed from both functionality and usability perspectives. The functionality evaluation carefully assesses aspects such as the system robustness, its ability to reduce the difficulties associated with performing care scenarios, and its effectiveness. The usability evaluation targets aspects such as ease-of-use of interfaces, and accessibility. Further studies to create standard evaluation frameworks for SH technologies in dementia care would be of interest as they enable researchers to compare different solutions using similar measures. They could also include, ethical, clinical, economic aspects of the SH adaptation.