Robots for Elderly Care in the Home: A Landscape Analysis and Co-Design Toolkit

Abstract

Over the last two decades, several deployments of robots for in-house assistance of older adults have been trialled. However, these solutions are mostly prototypes and remain unused in real-life scenarios. In this work, we review the historical and current landscape of the field, to try and understand why robots have yet to succeed as personal assistants in daily life. Our analysis focuses on two complementary aspects: the capabilities of the physical platform and the logic of the deployment. The former analysis shows regularities in hardware configurations and functionalities, leading to the definition of a set of six application-level capabilities (exploration, identification, remote control, communication, manipulation, and digital situatedness). The latter focuses on the impact of robots on the daily life of users and categorises the deployment of robots for healthcare interventions using three types of services: support, mitigation, and response. Our investigation reveals that the value of healthcare interventions is limited by a stagnation of functionalities and a disconnection between the robotic platform and the design of the intervention. To address this issue, we propose a novel co-design toolkit, which uses an ecological framework for robot interventions in the healthcare domain. Our approach connects robot capabilities with known geriatric factors, to create a holistic view encompassing both the physical platform and the logic of the deployment. As a case study-based validation, we discuss the use of the toolkit in the pre-design of the robotic platform for an pilot intervention, part of the EU large-scale pilot of the EU H2020 GATEKEEPER project.

1 Introduction

A problem many modern societies face is that of a rapidly aging population. In some countries, the over 65 years old already outnumber the younger cohorts. According to data from “World Population Prospects: the 2019 Revision”¹, by 2050, one in six people in the world will be over 65 (16%). If we consider only upper-middle income countries, one in four people could be aged 65 or over by 2050. Even more significant is the projected number of people over 80 years old, which is estimated to reach more than 400 million by 2050, thrice the current amount. While older people are increasingly seen as contributors to the development and betterment of the society, it is inevitable that in the coming decades many governments will face severe social and financial pressures connected to public systems of healthcare, pensions and social protections for a growing older population.

The most pressing problem presented by an aging population is the strain it will put on the healthcare system [65, 86]. While increasing the number of elderly care facilities seems the obvious solution to the problem, studies show that a diversified and personalised approach to elderly care is more beneficial for older people and provides a better overall quality of life [6]. Moreover, admission to an elderly care facility is often a traumatic experience connected with distress, depression and emotional problems for patients [61, 99]. Hence, a significant effort has focused on implementing systems enabling “ageing in place” and community care, to reduce the need for specialised structures and hospitalisation.

In recent years, many technological solutions have focused on in-house assistance for older adults. For example, advancements in communication technology have simplified the interaction between patients and carers [100]; data science is used to profile users’ habits and fine tune therapies [73]; and virtual assistants provide reminders to promote adherence to medication requirements [89]. In the field of robotics, since the early ‘90s, a wide range of projects has focused on the development of robot applications for “aging in place”, thus expanding the range of this type of applications from general healthcare to in-house intervention. However, even after three decades of activity and many prototypes, there is still no commercially ready robotic intervention for elderly care, which can support independent ageing at home. This is the case mostly because of the intrinsic complexity of the tasks the robot has to achieve [16], the unpredictability of a domestic environment [4], and the unstructured interaction with the users [26].

This work has two main contributions: i) a landscape analysis where we analyse in detail the evolution of in-house robot assistants for elderly care and ii) an intervention-centred framework for the co-design of robotic interventions in healthcare. The analysis highlights a number of limitations, challenges, and shortcomings of common design practices and current applications. To address these, our intervention-centred framework provides a capability-based abstraction of the robot and a toolkit to support the early phases of the intervention design. As a case study-based validation, we discuss the use of the toolkit in the pre-design of the robotic platform for the UK pilot, part of the EU large-scale pilot of the flagship EU H2020 GATEKEEPER project².

GATEKEEPER is a major European initiative, which aims to develop novel solutions to support healthy independent lives for the ageing population. The project is running a number of large-scale pilots in eight EU countries, comprising about forty thousand participants. The need to design pilot interventions at such a large scale has stimulated us to reconsider our design approach, in particular highlighting the need to formulate a more principled methodology, which connects robot capabilities with known geriatric factors, to produce a value-based, impact-driven approach to the design of healthcare solutions.

The paper is structured as follows. Section 2 provides an overview of robotic applications in healthcare with a focus on deployment location, level of agent autonomy, and target users. Section 3 analyses the types of intervention provided by robotic platforms, in particular highlighting the evolution of intervention scenarios and robot capabilities. In Sect. 4, we then provide a critical analysis of the limitations of the state of the art and, in Sects. 5 and 6, we leverage this analysis to define (i) a set of generic application-level capabilities that can drive the design of robotic interventions and (ii) a co-design approach and toolkit situating robot deployments in the context of a broader healthcare intervention. In Sects. 7 and 8, we then apply the framework to the design of three robotic interventions, based on a medical use-case focusing on multimorbidity and poly-medication, and provide a brief discussion of the benefits of the presented approach. Finally, in the concluding section, we briefly discuss a number of open challenges that need to be tackled to ensure an effective deployment of robotic interventions in the home assistance domain.

2 Robots in Healthcare

The landscape of robots in healthcare is vast and includes a wide family of applications: surgical robots [59], hospital management support [31], healthcare worker and robot cooperation [93], patient interactions [92], physical and mental rehabilitation [63], “at home” assistance [10], smart prevention [98] and more. In this section, we define a general classification for healthcare robots, and then specify which subcategories are relevant for our analysis.

2.1 Types of Healthcare Robots

Usually, healthcare robots are classified in terms of their key functionality or application in three categories: surgical, rehabilitation and social robots (see Table 1). While there are no formal definitions of these categories, their differences in terms of functionalities and target users are such that there are no overlaps or similarities between instantiations of these categories, with the notable exception of cognitive rehabilitation tasks that can be performed by social robots.

Surgical robots [52] can be seen as tools for the medical staff, assisting human personnel perform surgery. Patients are the target of the activities of the robot, while the main users are the surgeons controlling the platform. Except for some research-only applications still in an experimental phase [70], surgical robots have limited autonomy, requiring direct or indirect control by a human operator [46]. Surgical robots are designed to assist the surgeon performing minimally invasive procedures by providing access to otherwise unreachable locations, correcting their movements, or returning a detailed visual feedback. As tools, their aim is to assist and enhance the performance of surgeons. Surgical robots are only deployed in medical facilities, even in the case of tele-surgery, where the control terminal can be in any location.

Rehabilitation robots [28] are normally used in post-operation scenarios, to assist with patient recovery. They are physically assistive devices with limited autonomy and exhibit mostly reactive behaviours, which are connected to the activities of the patients. Depending on the targeted body part and the patient condition, they may have significantly different hardware configurations. They range from static platforms used to support the patient’s weight while doing physical activities [14, 62], to wearable exoskeletons to facilitate everyday tasks [23]. In some cases, even general-purpose robotic arms can be used as rehabilitation robots, assisting physiotherapists during the physical therapy [51]. Since the objective of these robots is to assist and compensate natural human movements, they also have a limited autonomy. For instance, in the case of rehabilitation exercises, while they may initiate a movement, they then let the user control its trajectory and intensity. When performing supportive actions (e.g., exoskeletons or smart walkers), they tend to be purely reactive, and usually only respond to activities started by the user. Rehabilitation robots can be deployed in multiple locations depending on their functionalities. When used in physiotherapy, they are normally located in professional environments, such as specialised clinics, even though personal devices also exist [23], which can be used at home or in care facilities.

The third and most heterogeneous category is social robots [29]. Generally, these focus on the interaction with users: direct interactions through conversation [68], cooperation [22], and gaming [8], or indirect interactions as aids for patients’ day-to-day activities [32]. The main objective of social robots is to assist users by trying to help preventing illnesses and accidents, or to support patients with chronic conditions and/or physical and mental impairments. These robots are usually deployed directly in the patient’s house or in retirement homes. Given the variety of functionalities implemented by social robots, it is useful to further divide them in two sub-categories, service and companion robots.

Service robots are usually defined as autonomous platforms created to assist human beings, outside of industrial settings, by performing tasks that are dirty, dull, dangerous or repetitive. Clearly, this definition does not correspond to a technical specification but focuses on their application scenarios. Indeed, service robots can vary significantly in hardware and software configuration and, while usually capable of autonomous navigation, they can also be stationary. Service robots can be equipped with numerous accessories, ranging from a simple tray to multiple fully actuated arms [48]. In some cases, the human-robot interaction aspects are predominant, while in others they operate autonomously without any interaction with the user. Moreover, they can be proficient in a single task (e.g., a simple autonomous vacuum cleaner) or implement a variety of behaviours (e.g., a complex waiter robot). Given their versatility and broad range of functionalities, service robots can be deployed in numerous environments, such as libraries, museums [101], hotels [38], cafes [71], hospitals [92], nursing homes [72], and private houses [37].

Companion robots [2] are designed to foster a sense of companionship for their users. They are often designed to resemble a pet or may have a cartoon-like appearance, to be more easily accepted and avoid the ‘uncanny valley’ drawback, which can be caused by an aesthetically imperfect resemblance of a robot to a human being. Their core functionalities revolve around a direct interaction with the user, often based on non-verbal cues. For example, they can change temperature according to the behaviour of the user or react to being hugged or petted. Companion robots are usually small sized and centre their hardware design around the interaction with the user. They usually have limited autonomy, such as basic navigation capabilities and ability to lead or follow a person.

Table 1 Classification of robots in healthcare

2.2 Parameters of Robotic Intervention

In the scope of a robotic intervention, a platform can be selected from any of the categories listed in Table 1. For example, a smart walker is a rehabilitation robot, an autonomous personal assistant is a service robot, and a robotic pet is a companion robot.

In this regard, we identified three classes of parameters of robotic intervention, which concern the deployment location—where they operate, target users—who they interact with, and level of autonomy—the extent to which the robot is able “to sense the environment, plan based on that environment, and act upon that environment, with the intent of reaching some goal (either given to or created by the robot) without external control” [12].

Deployment Location In what follows, we will focus on robot interventions which aim to provide assistance and support to a patient when trained medical staff is not available. Hence, we will limit our analysis to robotic platforms that can operate in environments such as private houses and care facilities. However, given the complexity of deploying robots in completely unstructured environments, platforms have often been tested in controlled locations outfitted to resemble a living space (i.e., a lab-house).

Target Users When referring to the target user we consider the main actor interacting with the platform. It is important to emphasise that, given a deployment scenario, multiple classes of human participants may interact with a robot. Given our focus on elderly care at home, our target users are people with no specific training, e.g., a person affected by some physical or mental condition and his/her family members.

Level of Autonomy To successfully perform an intervention in the home a robot ought to be able to operate autonomously; a platform that requires constant input and supervision from a human operator would provide limited value. Nevertheless, while the robot needs to be able to perform its core functionalities autonomously, teleoperation and remote control can significantly enhance the intervention capability of a platform. Given the wide variety of hardware and software configurations, autonomy manifests in multiple activities, such as human-robot interaction, navigation, manipulation, environment analysis, etc. The autonomy of a robotic platform can range from limited, such as focusing on a single functionality (e.g., dialogue only), to advanced, a complex coordination of multiple proactive actions (e.g., dialogue, navigation, and manipulation).

Using these three parameters, we identified a number of suitable healthcare robots, i.e. suitable for deployment in a domestic environment and exhibiting a significant level of autonomy. Hence, we have excluded surgical robots, as they require a highly-trained human operator and are deployed in medical facilities. For similar reasons, we have also excluded most rehabilitation robots, as these usually require the participation of a physiotherapist in specialised facilities. However, there are exceptions: for instance, a smart walker is a type of rehabilitation robot that is suitable for robotic interventions in domestic settings. In general, social robots have all the necessary hardware and software requirements to be used for an intervention. In this case, it is mostly the deployment location that matters, since the same capabilities can be used, for example, to implement a robotic guide in a museum and a personal assistant at home.

Fig. 1

Examples of robots used for in-house assistance

3 Robots for In-House Assistance

The MOVAID project [27] is one of the earliest examples of robot for in-house assistance of older adults or people with disabilities. Running from 1994 to 1997, MOVAID (Fig. 1a) is now more than 20 years old; nonetheless, it is still very relevant as some the challenges that it attempted to address are still open issues today. The main output of this project was the development of a mobile manipulator capable of navigating autonomously, removing bed sheets, interacting with a smart microwave to re-heat food, and delivering food to a location. MOVAID was deployed in an extremely structured environment that was specifically designed for the robot and its functionalities. The lab-house had wide corridors and spacious rooms to accommodate the size of the robot and its limited navigation functionalities. Moreover, various workstations were placed around the environment to guarantee enough computational power for the tasks. Given the size, the limited functionalities and autonomy, the robot was never deployed in authentic user settings.

Another late 90s example is the Nursebot project with its main robotic platform, Pearl [72] (Fig. 1b). Differently from MOVAID, this project was less focused on complex interactions with the environment, and more on human-robot interactions. This is reflected in the hardware of the robot: small footprint to aid navigation, large screen to interact with the users, human-looking head to make the robot more acceptable, and absence of a robotic arm. The developers opted for deployment in a structured environment, but instead of using a lab-house, Pearl was deployed in nursing homes. While providing challenges similar to households (e.g., uneven obstacles, unpredictable movements from humans, stairs, etc.), nursing homes are intrinsically less challenging than domestic households, as they are normally designed to accommodate the needs of older adults and people with disabilities. Pearl’s functionalities revolved around direct interactions with the users (i.e., reminders, news, weather information), and navigation (i.e., obstacle and person avoidance, following and leading people).

During the same period, the first iteration of Care-o-bot [82] (Fig. 1c) was designed, and a prototype developed. The original design included an arm to perform some basic tasks and was specifically targeted to help older adults at home. However, the prototype of the Care-o-bot that was eventually deployed was a mobile platform equipped only with a touch screen. Its functionalities included the ability to navigate autonomously and safely in indoor environments and communicate and guide people. However, while Care-o-bot was meant to be a service robot for at-home assistance, its first realization was never deployed in end-user houses. Nevertheless, it was successfully used as a robotic guide and valet in exhibitions and museums [41], interacting directly with humans.

Care-o-bot II [36] (Fig. 1d) was the direct evolution and refinement of the earlier prototype. This second iteration followed closely the original design, maintaining the screen as the main form of interaction and adding a manipulator to interact with the environment. Additionally, the bulkier and more stable base made it possible for the robot to act as a smart walker and support patients with movement impairments. However, the oversized footprint, combined with the limited manoeuvrability of the differential drive configuration, made it impossible for the robot to be deployed in normal houses. Therefore, it was deployed as a smart walker and robotic assistant in elderly care facilities, even though the fetch-and-carry functionalities were tested in a lab-house with trained personnel. This was necessary as the arm, while capable of carrying out autonomous manipulation and grasping tasks, was not suitable for activities with humans-in-the-loop who had not been specifically trained.

The Care-o-bot robot has seen two more iterations and the current model is Care-o-bot 4. The design of Care-o-bot 3 [75] is centred around a tray mounted on the robot that acts as an interaction area between the robot and the user. While there are applications where this robot was used as an assistant for seniors, such as the Accompany project [5], the focus of the platform has shifted from elderly care and in-house assistance to a robotic luxury butler [48, 76]. In particular, Care-o-bot 4 has been deployed in public spaces, such as restaurants, conference centres, museum and supermarkets.

Often service robots are part of a larger system of interconnected services and devices. One of these examples is AILISA [67], a project that integrates multiple sensors (pulse oximeter, arterial pressure meter, weight scale, etc), a smart shirt, and a robot in the same network. Monimad [60] (Fig. 1e), the robot used by the AILISA project, is an assisted walking device, which can help the user transfer from sit to stand and vice versa. Monimad supports the patient when walking and it can be used as a rehabilitation device for post-fall situations. Since the robot was not the main focus of the project, it had limited functionalities and, in particular, did not provide the main interface between the user and the system. However, AILISA pioneered the concept of collaboration between multiple devices to monitor and assist a patient at home, as well as smart technologies to enable remote assistance.

Fig. 2

Robots address two types of mobility issues: sit to stand transition (and vice versa) and walking (both as physical support and guidance for patients with cognitive impairments)

A number of other platforms are also discussed in the literature, which have been designed to assist the user in walking or standing (Fig. 2). These include: GuideCane [96], a robotic cane for the visually impaired; Guido [77], a smart walker to support veteran rehabilitation; and JARoW [53], an active robot walker developed by the Japan Advanced Institute of Science and Technology. All these robots share a similar approach, which focuses on a single functionality providing a robust solution to a specific problem, and a fast deployment cycle, which does not require much training or additional human support for the end user

Another example of a walker integrated in a larger project is RobuWalker (Fig. 1f), in the context of the Domeo³ project. With a design very similar to Monimad, RobuWalker helps the user with the transition from sit to stand and acts as a walking assistant. In Domeo, the smart walker is paired with a service robot called RobuMate (Fig. 1g), which is based on the commercial platform Kompai-1, developed by Kompai Robotics. Kompai-1 is a differential drive mobile platform equipped with a touchscreen and a camera, able to navigate autonomously to previously defined locations. In the RobuMate implementation, the Kompai-1 platform was capable of interacting with users through touchscreen, speech recognition and synthesis. The robot also supported a form of remote teleoperation to let an external user (e.g., relative, nurse, doctor, etc) contact the main user. As it is the case with all the projects discussed so far, Domeo was not deployed directly in user houses, but it was tested on real participants in a structured environment designed to replicate a house.

Another project adopting the Kompai-1 platform is MOBISERV [66] (Fig. 1h). This is another case of a robot being part of a more complex system of sensors and devices. However, differently from AILISA, in MOBISERV the robot is the main interface between the user and the system. Technology-wise, the project had three objectives: to monitor user health using wearable devices, to support good nutrition, and to create a tele-alarm and health report system. Here, the robot is used mainly as an embodied reminder system: it reminds the user to eat and to exercise, and, when appropriate, can also suggest contacting a caregiver. Moreover, the screen on the robot works as a bidirectional interface between the user and the smart environment. MOBISERV again exploits the fact that the robot operates in a well-known and specifically created environment, since all the trials were performed in a fully furnished smart house designed to be a testbed for robotic and smart applications.

Almost in parallel with the MOBISERV project, the same smart house was used in another project, called CompanionAble [8]. The two projects had similar objectives and functionalities for their robots. Hector, the companion robot used in CompanionAble, is a mobile platform equipped with a screen and able to autonomously navigate the environment (Fig. 1i). Its main functionalities include an embodied reminder system for medications and activities, acting as an interface between the user and the smart environment, and providing audio and video bidirectional communication to external users. The main difference between the two projects concerns the use of wearable devices. CompanionAble put more focus on the interface between the robot and the smart environment, for example by using room motion sensors to obtain a rough estimate of the position of the user, while MOBISERV was more centred around health and nutrition and exploited data collected by personal sensors.

The Serroga [37] project was the direct evolution of CompanionAble. The robot, Max (Fig. 1j), provided a new version of Hector, sharing the same base functionalities (i.e., a mobile base with a touch screen). However, this new platform was enhanced by means of an additional RGB-D camera. In addition, in contrast with the aforementioned projects, Serroga augmented experiments in lab-houses with trials in private homes. As in CompanionAble, also in this project the robot acted mainly as a reminder system and as a centralised interface for various communication and measurement systems.

Many other examples exist of mobile robotic platforms equipped with a screen that cover one or more of the functionalities implemented by Domeo, MOBISERV, CompanionAble, or Serroga. For instance, Mario [20], which is based on Kompai-2, is deployed in nursing homes and used to engage patients with mild dementia, while Biron [40] is a robot companion implementing dialog options. A frequently used example of mobile platform with screen is Giraff [35]. This robot is specifically designed to support telepresence and has been successfully used in many projects (e.g., VictoryaHome [85], GiraffPlus [25], and ExCite [21]) to implement video calls and remote interactions between the patient and the caregivers.

As it can be seen from this overview, after the initial success of MOVAID, mobile manipulators have been absent from healthcare robotics for several years, the only exception being Care-o-bot, even though this shifted its focus to different applications, to accommodate for the challenges created by the presence of a robotic arm.

Over the years, many research projects have tackled the difficult task of using manipulators to assist or support users in their everyday tasks. Some examples are Herb [88] and Herb 2.0 [87]. Herb is a mobile platform equipped with a single 7 DoF arm, while the updated version is extended with a second identical arm. Both robots targeted domestic environments and were able to successfully interact with cabinets and receive objects by human users. However, their activities were restricted to short demos performed in structured environments. Additionally, given the hardware configuration, both platforms were extremely expensive, with Herb 2.0 valued at $ 500 000; this significantly limited their use in real-life scenarios. Another example is EL-E [43], a mobile base equipped with a 5 DoF arm specifically designed to pick up objects from flat surfaces. The robot was quite successful in this task, especially when picking up object from tables. However, the approach used did not scale to dynamic or cluttered environments limiting its efficacy as an everyday assistant.

The first project to successfully reintroduce and exploit manipulation as one of the many functionalities offered by an in-house robotic assistant was Hobbit [32] (Fig. 1k). In an effort to create a low-cost platform, the Hobbit team created a new design instead of re-using the available commercial platforms. The first iteration of the design was a mobile base equipped with a screen and a five degrees of freedom arm terminating with a “Fin Ray effect” gripper. This configuration makes the arm lightweight and suitable to grasp most common household objects, such as cups or food packages. The robot implemented most of the functionalities already available in other mobile platforms, such as reminders, fall detection, serious games, and health suggestions. Moreover, it exploited the arm to directly interact with the environment and actively help the user, for example by collecting objects from the ground or by delivering items to the user. The first iteration of Hobbit was tested with real patients but in a lab-house. Using the results obtained from these initial trials, the Hobbit team designed and developed a second iteration of the robot. Hobbit PT2 [10] (Fig. 1l) has fundamentally the same design and functionalities as the first iteration; however, the look-and-feel of the robot is closer to a commercial platform than a prototype. The main achievement of this revamped platform is in the public trials. Hobbit PT2 operated for a continuous period of 21 days in 16 households, producing the longest experiment for a mobile manipulator in private houses [9].

Companion robots have significantly different functionalities from service robots and are often simpler, with limited autonomy. However, multiple studies have shown that their use can have a positive impact on the mental health of the patients [54]. They are created using pets as inspiration and are usually marketed as an alternative when real animals cannot be used. The two most popular examples are Paro [47], a seal-like robot with soft fur that reacts when hugged or petted, and AIBO [33], a dog-like platform with a more robotic appearance, able to request attention and engage users in play. Other examples of robots with shape and feel inspired by different animals are: NeCoRo [55] (cat), Huggable [90] (bear), and Homie [50] (dog).

Fig. 3

Evolution of robotic interventions between 1990 and 2020

4 Types of Robotic Interventions

The presented overview (See Fig. 3 for a visual summary) shows how hardware designs, functionalities, and types of interactions recur in projects and applications. What distinguishes the different robots are the tasks they are designed for, and therefore their potential capabilities in the context of an intervention. Specifically, from the analysis of the landscape, we identified three main roles played by robots in an intervention scenario: 1) supporting a patient’s activity, e.g. fetching an object, 2) mitigating the degradation of the patient’s condition, e.g. reminders, and 3) responding to unexpected events, e.g. fall detection.

4.1 Support

This type of intervention directly or indirectly assists users in their activities. The robot is not required to read or predict the intentions of the user, since the intervention is not time-sensitive and can be activated by the user during their activities. For these reasons, early designs and platforms that are not functionality-intensive tend to implement a support type of intervention. For example, MOVAID was built around supportive actions aimed at replacing human efforts (e.g., deliver food, change bed sheets). This approach was adopted because the robot was not deployed together with humans, therefore the only option was to implement an indirect intervention. A non-healthcare example of this type of indirect support is the iRobot Roomba [44], a robotic vacuum cleaner, which uses a low-tech implementation to facilitate human life by removing the effort to perform a very specific task. Examples of more direct support are smart walkers. Care-o-bot II, Monimad, and RobuWalker cannot operate without an active role from the user and provide direct assistance to walking, sitting, and standing. Since support interventions require an active role of the robot (e.g., item delivery, cleaning, mobility support, etc.), this must be reflected in the hardware configuration and functionalities of the platform.

In summary, support robots must be able to interact physically either with the user (e.g., smart walker) or with the environment (e.g., manipulator). Robots that focus on communicating with the user, rather than physical interacting with them, usually lack this kind of ability, hence they provide no (or very limited) support type of intervention. Both Pearl and Care-o-bot I belong to this category. More recent platforms (RobuMate, Hector, and Max) provide supportive action through telepresence, video calls, and teleoperation, by assisting the user in social activities. In this context, Hobbit demonstrated how the addition of a basic manipulator can greatly extend the variety of support intervention a robot is capable of. By means of this hardware configuration, Hobbit implements the same functionalities offered by previous platforms, while also adding various forms of direct assistance, such as collecting items from the ground, holding and delivering objects.

Companionship is a form of support intervention that is inherently enabled in any social robot. In the extreme case of companion robots (Paro, AIBO, Huggable), the entire platform revolves around this type of intervention and is enhanced by numerous features, such as friendly appearance (e.g., to resemble an animal), showing dependence to the user, and multi-sensorial feedbacks (e.g., soft fur, warm body, calming voice, etc.). While this effect is less prominent in more machine-looking platforms, multiple studies show that users are more willing to perform an activity (e.g., take medication) when suggested by a robot than any other form of automatic reminder [15, 57].

4.2 Mitigation

The mitigation type of intervention concerns the prevention of negative routines through proactive actions. Reminders are the most straightforward example of mitigation intervention in healthcare. In the context of reminding, robots use various strategies, such as engaging users in conversations or physical activities. Pearl was the precursor of reminder-centric mitigation and focused on the task of reminding and guiding users to their physiotherapy appointments. Additionally, it kept the patients mentally active by providing simple information, such as the weather forecast and the news. This type of approach is consolidated in all the other platforms focused on direct interactions, such as RobuMate, MOBISERV, Hector, and Max, all of which provide different types of reminders and suggestions. RobuMate implements a more advanced approach, by providing a programmable agenda and by entertaining users using a set of serious games. MOBISERV is more focused on nutrition, helping the user maintain a healthy eating schedule, using reminders combined with recipe suggestions. Hector and Max target users with mild cognitive impairment (MCI) and hence support a broader reminder system. Here, the robot acts as a personal assistant by helping the user maintain a healthy lifestyle on a physical, cognitive, and social level. It gives reminders for eating, exercising, calling relatives and friends, taking medications, and playing games. It also uses the house sensors to predict when the user is about to leave and reminds them about relevant items (e.g., wallet, keys, etc.) and future appointments. None of the platforms equipped with a manipulator employs their robotic arm for a mitigating intervention. The MOVAID technology was simply too underdeveloped to achieve proactive actions, while Hobbit employed the arm only for supportive actions. In general, a robotic arm can be used in multiple ways for a mitigation type of intervention, such as removing trip hazards from the ground, turning off unsupervised appliances, or enhance reminders by providing the associated item (e.g., medication, food, keys, etc). However, these actions require a combination of complex functionalities unrelated to the arm: object recognition, scene understanding, human behaviour analysis, and more. These dependencies make the achievement of including arm-based mitigating intervention particularly challenging. Hence, it is yet to be reached and indeed, even in the general case, the use of a manipulator in service robotics is uncommon.

Companion robots have very limited functionalities and focus on emotional and mental support. They may include reminders, but usually avoid them to maintain the illusion of a pet instead of a machine.

4.3 Response

A robot performs a response type of intervention when it reacts to an infrequent event. This type of intervention is the most challenging and complex as the robot does not act upon request (i.e., support) or on a fixed schedule (i.e., mitigation). Firstly, the robot must understand normal events or a routine and then has to be able to detect deviation and assess its significance and level of risk for the user. Given this complexity, one of the earliest examples of robot including a responsive intervention is RobuMate from the DOMEO project in 2010. The intervention is very limited but significant: the robot is able to detect falls to identify an emergency situation. If this happens, it can interact with the user and, depending on their answer, call a relative or the emergency services. None of the more recent platforms managed to achieve a significant improvement in this type of intervention. They all include a form of fall detection that is able to contact caregivers or emergency services and, in some cases, they can also identify breaks in the routine. For example, MOBISERV, with its focus on nutrition, can report inconsistencies in eating habits, while the robots used in the CompanionAble and Serroga projects, which were targeted at MCI patients, were able to remind them of missed medications or report a decline in cognitive capabilities.

5 Landscape Analysis

The landscape of healthcare robots for in-house assistance appears to converge on a consolidated set of interventions. Newer approaches are built on the results obtained by previous applications and are often a direct extension, as in the case of Care-o-bot I to Care-o-bot II, Hector to Max, and Hobbit PT1 to Hobbit PT2. Therefore, we can see a small but steady increase in the available functionalities. With the exception of MOVAID, given its unique hardware configuration for the time and the fact that it was not deployed in authentic user settings, healthcare robots started in low-challenge environments (i.e., nursing homes and exhibitions), implemented basic navigation capabilities and focused on simple yet rewarding user interactions (Pearl and Care-o-bot I). Then they evolved their navigation capabilities to tackle more complex environments (i.e., lab-houses), in particular supporting a direct involvement of human participants, and they also extended the user interactions to incorporate reminder-based mitigating interventions (RobuMate, MOBISERV, Hector). More recent approaches have consolidated their methods of interaction with the user and introduced the ability of interacting directly with the environment (Hobbit). Hence, from a general point of view, we can say that the focus has shifted from adding novel capabilities to refining existing ones, to achieve a robust deployment in domestic locations with actual patients.

Currently, Hobbit PT2 represents the gold standard in terms of available functionalities and deployment capabilities. It has an expressive human-like face and built-in screen that makes it acceptable and usable by older adults. Additionally, its robotic arm provides a simple yet effective solution to perform various actions to support the user. Finally, its deployment in patients’ houses requires only minor changes to home settings (e.g. removing dangerous obstacles) and, as a result, Hobbit is capable of full operation in domestic environments for an extended period. However, Hobbit’s design is still extremely derivative with respect to previous applications. The core functionalities still revolve around a reminder-based system and focus mostly on a mitigation type of intervention. Moreover, the robot is presented as an all-in-one interface to simple functionalities, such as an agenda or a videocall system. Arguably, this is a sub-optimal solution, as there are today more affordable, usable and accepted devices that provide the same and more functionalities [56]. This issue is also highlighted by the evaluation results obtained by the project [9], where the most used functionalities were all navigation-related. Moreover, while the addition of the robotic arm is an important step forward for a service robot, its use in the Hobbit project was very limited and not organically interconnected with the rest of the application.

5.1 The Need for a Wider Technological Ecosystem

Robotic solutions for in-house intervention tend to follow their own technical path, however they also have to be reconciled within a larger technological ecosystem. Previous projects, such as AILISA or VictoryaHome, already implemented applications where the robot was part of a broader system while, in other cases, such as CompanionAble and MOBISERV, the platform was deployed in a smart house and could take advantage of some of the available sensors. Nevertheless, none of these approaches support and exploit a bidirectional interaction and data exchange between the robot and the other components within a broader technological ecosystem. Monimad (AILISA) and Giraff (VictoryaHome) were peripheral additions to the system and provided limited functionalities, while Hector (CompanionAble) used motion sensors to detect a user, making the smart house an extension of the robot and not an interconnected system.

Nowadays, many technologies exist that can be used to monitor the routines, behaviour and status of a patient (e.g., smart watches, fitness tracker, smart scales, etc.) and they are usually already part of a broader infrastructure made of hardware and software components. Moreover, smartphones are accepted as the most familiar and immediate interface between users and various technological systems (e.g., virtual fitness coaches, digital doctors, smart houses, etc.). In summary, a modern approach to service robotics should take into account existing technologies, remove functionalities from the platform that are better fulfilled by other devices, and focus on capabilities that are unique to a robot. Hence, it is desirable to have a bidirectional and fully integrated data exchange between the multiple sensors of the robotic platform and the other smart devices connected to the system. Within this scenario, the role of the robot in the system needs to be carefully calibrated and it should be considered as one of a number of components comprising a smart infrastructure that addresses the needs of the users.

Table 2 Mapping between the application-level capabilities and the robots in the literature. More dots indicate an advanced use of the capability

5.2 Application-Level Capabilities

The analysis of intervention scenarios also provides the opportunity to identify application-level robotic capabilities, which can be used to engage with care providers and patients and shape the design and evaluation of an intervention. Indeed, the literature includes several contributions that attempt to define the concept of robot capability. In many cases, capabilities or tasks are defined for a specific family of physical platforms and used as building blocks for task allocation and planning [19, 49, 97, 102]. In more recent approaches, there has been an effort to exploit the concept of capability as a technological tool to create an abstraction layer supporting the developer at a higher level than that provided by the physical platform [11, 94, 95]. A similar solution is to postpone the selection of the robotic platform and focus on the subsystems (i.e., sensors and actuators), which are commonly available in most robots. This idea is exploited by projects such as the Multimodal Elderly Care Systems [83],⁴ and it provides a hardware-centric view on the problem of separating the design of the application from the physical properties of the robot. In general, these approaches create an abstraction of low-level robot functionalities (e.g., direct access to sensors and actuators), but the granularity of these representations is still too low to be used during the design phase. For this reason, in an effort to bridge the gap between the specification of a robot and the requirements of an intervention, we identified a set of application-level capabilities. These capabilities, which are strongly influenced by knowledge-level models of problem solving in Artificial Intelligence [3, 64] are derived using the recurring functionalities of service robots found in the literature and the general requirements of an intervention, In particular, we distinguish six capabilities:

Exploration This application-level capability is strongly connected to the ability of a robot to navigate autonomously and avoid static and moving obstacles. Therefore, it requires the low-level capabilities of mapping and basic scene understanding. The exploration capability means that the robot is able to fulfil a variety of tasks, such as patrolling a house, autonomously reaching a specific location, learning and updating the house configuration, detecting and identifying living areas, and others.

Identification One of the key abilities of a robot is sensing, and this application-level capability is the concretisation of this concept. By using the platform sensors as well as other environmental information, the robot can acquire knowledge about the environment, which is instrumental to carry out complex tasks. Examples include object identification for grasping, object classification and labelling, person recognition, human activity recognition, and emergency detection (e.g., fall detection, trip hazards, etc.).

Remote Control While robots are defined by their autonomy, it is important to provide remote control capabilities. Usually, a robot is remotely controlled for initial configuration, diagnosis, and recovery. However, for medical use cases a remote control capability can be needed to perform an intervention. For example, to verify the safety of the house, to perform remote medical exams, or as an enhanced form of telepresence. Hence, multiple forms of remote control may be required, ranging from a direct control of the movements of the platform, to a location-driven system (i.e. a command to trigger an autonomous navigation to a predefined location). Moreover, this capability requires user interfaces accessible by different actors with different tasks and training (e.g., relatives, caregivers, nurses, doctors, etc.).

Communication In most applications, robots can operate with minimal interaction with the user and do not require complex interfaces. In the case of robotic intervention it is important to provide direct and indirect ways for the user to communicate with the robot and vice versa. Suitable interfaces are speech recognition and synthesis, gesture detection, built-in touch screen, interaction through external devices, and contextual actions (e.g., person leading or following).

Manipulation A robotic arm adds an additional layer of interaction between the robot and the environment, but also significantly increase the implementation complexity of the application. While this trade-off must be carefully considered, the manipulation capability allows the robot to perform tasks, such as, collecting objects from the ground, delivering items upon request, removing trip hazards, interacting with switches and doors, and others.

Digital Situatedness Nowadays, users have access to a multitude of devices connected to a shared information system, such as smartphones, fitness trackers, smart scales, smart TVs, virtual assistants, and others. To achieve a more robust and comprehensive intervention, it is important for the robot to be able to exploit the data produced by other devices and to provide value-adding information to the interconnected system. Moreover, by exploiting the information provided by other devices, the robot can significantly improve the success rate of its tasks. For example, it can refine the results of human activity recognition by using accelerometer data coming from a smartwatch.

Table 2 shows how the platforms analysed in the previous sections can be characterised using these application-level capabilities. It is immediately clear that Exploration is the predominant one, a result of the derivative and incremental design adopted in interventions for home assistance. Additionally, the table also highlights the key functional limitations of the reviewed interventions, e.g., by showing the lack of Situatedness in almost all approaches. Unsurprisingly, Manipulation is present only sporadically, given the technological burden of pairing a robotic arm with a mobile base. Finally, we can also see that Remote Control is rarely used as an actual functionality of the robot and is usually considered a maintenance tool.

5.3 Summing Up

In summary, the design and development of robots for healthcare assistance in the home tend to follow a bottom up approach that starts from the technological features of the platform and maps them to a possible application. This leads to a derivative design that is based on minor advancements from previous implementations. While this approach is not inherently wrong, it has led to a recurrence of low-impact functionalities, such as providing reminders or stimulating the user with games, which are better fulfilled by different devices. Moreover, this approach also tends to isolate the platform from the broader technological landscape, limiting the integration with external systems and smart environments. To move away from this path of limited self-improvement, we believe that it is necessary to rethink the design process. In particular, we propose to consider robot technology and intervention as a whole, by adopting a co-design approach at early stage, which takes into account the requirements and limitations of both in the definition of robotic capabilities and, therefore, of the design of the platform.

6 Co-Design of Robotic Intervention in Healthcare

Co-design is not new in the context of robotics. Different engagement strategies and approaches (e.g., user-centred design, stakeholder-centred design and participatory design) had been successfully tested at various stages of robot design and development. It is worthwhile noticing that each design stage has different reference stakeholders/users, constraints in terms of form and functionalities, and aims (e.g. requirement elicitation, refinement, validation). In particular, co-design strategies had been widely experimented in the design of social robots. A common approach is collaborative design engaging users supported by, for instance, an Interaction Composer [34] or Design Toolkit for Human-Robot interaction flow [45]. A more general need is for the use of user-centred design during the validation and refinement of robot platforms, capabilities and HRI. An example is the use of a questionnaires for measuring the acceptance of assistive social robots [42].

The co-design of platform and intervention at pre-design stage is important but often overlooked [84]. Indeed, the approach adopted by many projects, such as Domeo, MOBISERV,CompanionAble, and Serroga, starts with the definition of a generic intervention based on the request of an external actor. Based on a description of the intervention, the most appropriate platform is identified from the commercially available robots. The given capabilities of the robot are then used directly or re-adapted to fulfil the requirements of the intervention. An alternative approach, used in the Pearl, Care-o-bot and Hobbit projects, starts with the design and development of the robot platform (not necessarily for healthcare purposes), followed by the design of an intervention for the purpose of testing and benchmarking the capabilities of the robot.

Fig. 4

The double diamond design process

The main limitation of both approaches concerns the disconnect between the development of the platform and the design of the intervention. A better approach in our view focuses instead on co-designing the robotic platform in the context of the design of the broader healthcare intervention. To better clarify the scope of this cooperative design, we refer to the double-diamond model [39] shown in Fig. 4. According to this model the path between the identification of a problem and the definition of a solution is divided in four phases: discover, define, develop and deliver. Many instance of cooperative design exists in robotics, such as developing specific forms of interaction for children with ASD [24, 79] or the design of the second iteration of Hobbit [30]. Examples of participatory design applied to robotics also exists [7, 80, 81], where many stakeholders are involved in the design process, but they are mostly applied to the design of the robotic platform after the main objective of the intervention has already been defined.

In summary, the existing co-design approaches are applied after the problem definition, or, as defined by the double-diamond model, during the develop and deliver phases of the design process. On the contrary, our suggested approach is focused on the early phases of the design process, i.e., discover and define. We define a multi-disciplinary strategy for the process of problem definition by taking into account the input from healthcare professionals, in the form of requirements for the healthcare intervention, and from robotics experts, in the form of functionalities and limitations of the target platform. Since the interaction between different experts happens early in the design process, this can lead to better exploitation of robot functionalities and greater fulfilment of healthcare requirements.

The proposed cooperative design can be achieved by defining scenarios that include details about both the intervention and the robot. Regarding the robotic platform, the design needs to provide a list of the available capabilities, their relations with users’ health factors, and how critical are they with respect to the requirements of the scenario. In this regard, the intervention design should map the robot capabilities (presented in Sect. 5.2) to the health factors, which define the goals of the intervention. Hence, the design process grounds the role of a robot within the scope of the intervention, in terms of benefits at scale (e.g., for the user, hospital, or healthcare system), positive effects on the targeted frailty factor, and types of users/patients, characterised in terms of the severity and type of their conditions.

While the notion of healthcare intervention is not new, in what follows we introduce the Robotic Intervention Design Toolkit we developed for bridging the logic of the healthcare intervention within the design of a robotic platform.

6.1 Design for Healthcare Intervention

In the healthcare context, the design of a robotic intervention aims to take advantage of the technical capabilities of the robotic platform to define a set of robot activities in the target environment, which can positively impact on a patient’s health and wellbeing. Hence, the design process needs to identify:

• 1. Type and level of performance of the robot capabilities needed by the planned deployment.

• 2. Type and role (within the deployment environment) of the robot activities that may achieve the expected effect on the intervention targets (e.g. conditions, risks, or frailties).

• 3. Relation between robot performance in the envisaged activities and impact on the intervention targets.

In other words, the design of a robotic intervention focuses on impact. Therefore, capabilities, activities and performances of the robotic platform have to be evaluated in relation to the effects achieved by the intervention.

The impact of the intervention is the result of the interaction between the robot, the deployment environment, and the actors operating within and cooperating with the intervention. Indeed, the role of a robot and, therefore, its direct effects can vary. For instance, a robot can be deployed as the main intervention technology (e.g., in the case of a smart walker) or as a backup technology, operating only in case of emergencies (e.g., house monitoring). In the first case, the actions of the robot have a direct effect on the patient ability to move. In the second case, the presence of the robot may be sufficient in the context of a reorganisation of care protocols—e.g. as it may enable emergency remote intervention through the robot in the context of a comprehensive active monitoring through wearables and home sensors.

The impact of the intervention is also the result of the relation between the robot activities and the intervention target. The source of an intervention target can be a person condition, behaviour or the environment in which they live in (e.g. social, household, community or urban). In this view, the robot activities can produce positive effects on a variety of different factors. For instance, as discussed previously, robots are effective in reminding users of medications, appointments and exercises and, therefore, in supporting a correct behaviour in terms of adherence with medications and physical activity. Differently, robots specialised in administering cognitive tests can monitor, for instance, memory loss and other cognitive skills associated with geriatric conditions. In the first example, the robot activity (i.e., reminder) aims to achieve a direct effect on the patient behaviour (e.g. adherence to medication). In the second example, the robot activity (i.e., conversation) is used to assess cognitive skills enabling and supporting a timely intervention from the specialist in care of the patient, i.e. there is an indirect effect here, which results in the direct intervention of a carer.

Thus, consistently with a co-design approach, the design of the robot intervention requires an in-depth understanding of the healthcare intervention. Indeed, the definition of the healthcare intervention drives and informs the definition of the role of the robotic platform within a wider “ecosystem” of the patient, as the system interrelation between their social connections, household settings, carers and living areas, and how these systems operate in mitigating or exacerbating the targets of the intervention. In this regard, the co-design approach needs to introduce concepts of the intervention domain to bridge the definition of the scenarios, the robot capabilities, and evaluation criteria, with the expected effects and impact criteria of the intervention. In what follows, we will adopt a specific framework, the City4Age frailty and MCI risk model (City4Age) [69, 78], which we will use as a schema to characterise geriatric risks factors in the context of the healthcare interventions presented in Sect. 7.

Our design toolkit aims at facilitating the instantiation of the core concepts of impact and evaluation of a healthcare intervention in the context of the design of the robotic intervention. Intuitively, the instantiation concerns a mapping between robotic capabilities and the frailty factors that are targeted by the healthcare intervention. In particular, the geriatric frailty factors considered by City4Age concern: 1) Mobility, e.g., moving across rooms, 2) Physical activity, e.g., going out, 3) Basic activities, e.g., grooming, 4) Instrumental activities of daily living, e.g., shopping, 5) Socialization, e.g., visits, 6) Cultural engagement, e.g., reading, 7) Environmental, e.g., quality of housing, 8) Dependence, e.g., the degree to what a patient depends on carers, 9) Physical health, e.g., pain, and 10) Cognitive health, e.g., mood. Thus, the robotic intervention identifies the target factors in the healthcare intervention that can be directly and indirect influenced by the robot. For example, in the case of a smart walker, a robotic intervention can directly target the Mobility factor by mitigating the effects of physical impairments and by providing support for navigation and mobility across the rooms, thus aiming to have positive impacts on reducing joint pain (Physical health) and on mood improvement (Cognitive health).

As discussed, the target of a robot intervention is limited to factors that a robot can either directly or indirectly influence. For instance, the City4Age model identifies frailty factors concerning a) the patient’s behaviour and b) the status of both patient and environment. The behaviour cluster include health related activities, self-management and socialisation, while the status cluster ranges from health and physical conditions to the patient’s immediate environment (e.g., household and neighbourhood). As in the example of the smart walker, a robotic intervention could target a set of the patient’s activities (e.g., walking) and, therefore, influence the factors in the behaviour cluster (e.g., mobility across rooms).

Summarising, the goal of a robotic intervention can be characterised as that of impacting positively on one or more frailty factors, e.g., those identified by the City4Age model, through the provision of support, mitigation and/or response services. While the deployment environment of the robot can guide the identification of the directly influenced factors, much more challenging is the identification of the indirect targets of a robotic intervention. Thus, the mapping between the healthcare domain and the design space of the robotic intervention should be paired with a model of the interrelations between factors, exposing both direct and indirect potential target factors.

In this regard, the Robotic Intervention design toolkit includes the following:

• a. The Ecological Model of Intervention and the Intervention Deployment Matrix, two design framing tools to identify the opportunities for positive impact of the robot in the domain of the healthcare intervention and to support the communicability of the role of the robotic platform within the broader context of the healthcare intervention.

• b. The Capabilities to Factors Evaluation Matrix, a design evaluation tool used to support the assessment of the impact of the robotic intervention based on the performance of the target robotic activities in the broader frame of a healthcare intervention.

6.2 Framework of Robotic Intervention

The focus on the impact of the robotic solution requires re-framing the design of a robotic platform as a derivative of the design of the healthcare intervention. In this view, the identification of requirements should be the result of the analysis of the role of the robotic solution within the wider scope of the healthcare intervention and the systems responsible for the provision of care services. In this regard, an effective approach emerging from an overview of the healthcare literature [13, 18, 58, 74, 91] suggests adopting an “ecological” perspective in the analysis of the healthcare intervention, centred on the definition of an ecological model of the systems involved in the healthcare intervention. This approach is effective in highlighting intra-system synergies and potential detrimental effects influencing the condition of a patient and/or the capability to provide care services.

Similarly, we propose an Ecological Model of Intervention centred on the patient but reframed with respect to the factors that are relevant to the design of a robotic intervention. In particular, while ecological models focus, for instance, on the different scales of the healthcare system (proximity, area, city, regional and national healthcare structures), an ecological perspective for the design of a robotic intervention should focus on highlighting the system components which are central for or related to the activities of the robot.

The identification of the system components interweaving with the robot activities is also used to guide the evaluation of the robot intervention, focusing on the user-centric impacts, rather than a robot-centric analysis of activity performance. In this regard, the proposed design toolbox also includes a mapping between changes in the intervention targets and robot capabilities emerging from the ecological model, the Ecological Model of Robot Deployment.

Fig. 5

The Ecological Model of Intervention describes the interrelations between the four systems: conditions, activities, relations and environment. The model is used to highlight the source and the eight City4Age categories and the effect chain affecting the different systems

6.2.1 Ecology of Intervention

In the context of robotic intervention, the factors concerning the patient’s activities are the ones within the domain of the robot influence (see Fig. 5). For instance, a home robot can virtually contribute to most of the activities in a household, from reminding medication times to locating, fetching and carrying objects. In this view, the older adults’ activities provide the system of reference in which the robot is deployed. On the other hand, activities are not necessarily under a person control, but they are instead the result of (i) conditions influencing the need or ability to act; (ii) the social relations of an older adult and the care support they have access to; and (iii) the quality of the environment and opportunities available.

Given this context, the environment, social relations and conditions define the set of systems connected with older adults’ activities, which can be the target of a robotic intervention. For instance, a robot able to move objects can improve the quality of the household environment by identifying and removing obstacles and reduce the dependence of the patient by fetching objects on behalf of other family members. The ecological model includes four distinct but interrelated systems:

• 1. Conditions The system of older adult’s physical and mental conditions and their mutual influence. For instance, physical weakness and its relationship with low mood.

• 2. Activities The system of older adult’s activities concerning self-management and daily life activities with an influence on health and wellbeing.

• 3. Relations The system of social relations ranging from the household to family, friends, neighbours, close community and carers.

• 4. Environment The system of the older adult’s environment ranging from the household to the neighbourhood and town, including geography, weather, infrastructures, services and organisations.

Then, as discussed, the ecological model is used in combination with the domain knowledge of the general intervention to support the identification of potential target factors. In particular, in our case study, the ecological model is used for mapping the City4Age frailty factors as follows (see Fig. 5):

• The conditions system considers the following categories:

  • Health-physical & Health-cognitive. Conditions related to health and wellbeing.

  • Mobility. Movement activities, such as walk, climb, balance and moving to different locations. In City4Age, mobility is considered as an activity, but in this context of robotic intervention we consider it a special category of physical and cognitive conditions that result in low mobility.

• The activities system considers the following categories:

  • Basic Activities of Daily Living. Self-management activities concerning hygiene, dressing, feeding and going out.

  • Dependence. Need for external support in carrying out activities.

  • Instrumental. Household management activities concerning cleaning, cooking, use of home appliances and communication devices.

  • Cultural Engagement. Cultural and entertainment activities at home or outside.

  • Physical Activities. Movement and all types of physical exercise, such as walking, stretching, steps and physiotherapy that can affect the older adult’s health and wellbeing. In the context of robotic intervention, we extend this City4Age category to mobility activities.

• The relations system considers the following category:

  • Socialization. Opportunity to spend time with other people at home, outside or remotely. In City4Age, socialisation is considered an activity, but we treat it as a quality of life indicator grounded on the configuration of the older adult’s social relations.

• The environment system considers the following category:

  • Environment. Factors concerning the quality of the household and the neighbourhood. In the context of a robotic intervention, we extend this list to infrastructure, services and organisations operating in the older adult’s environment, viewed as source of (or lack of) support and as opportunities having an indirect impact on health and wellbeing.

Table 3 The Intervention Deployment Matrix is used to identify the potential direct and indirect impacts for the selected deployment system. For instance, the matrix is used to highlight the categories of City4Age factors that can be potentially influenced directly or indirectly through different types of intervention. This table provides the analysis framework describing the types of interventions in each system that could have potential indirect benefit on the primary target. This table is used to instantiate the Intervention Deployment Matrix in the intervention design

6.2.2 The Intervention Deployment Matrix

As introduced in Sect. 6.1, a robotic intervention focuses on impact. During the design phase, it is important to define which are the direct and indirect effects of the intervention. In particular, the ecological model of robot deployment highlights the potential target factors for each specific system (see Fig. 5). In this regard, the mapping between systems and factors is used to define the Intervention Deployment Matrix. This matrix identifies which target factors are directly or indirectly impacted by the robotic intervention. In this framing, a specific deployment system identifies a specific range of direct target factors while the non-deployment systems are considered sources of potential secondary factors. We characterised as the primary factors of an intervention those frailty factors that are directly targeted by the robotic intervention.

Secondary factors are instead those frailty factors outside the reach of the robotic intervention, which can nonetheless be impacted by the robotic intervention. For instance, air pollution has a negative effect on preexisting respiratory conditions, while the availability of green space and socialisation opportunities in the community have a positive effect on a person’s mood. Following this example, a robotic intervention can target air pollution by encouraging patients to go out outside traffic peak time.

In our case study, the Intervention Deployment Matrix (see Table 3) identifies the relationships between City4Age frailty factors, clustered for each system identified in the ecological model (see Fig. 5). For instance, in the first row, we examine potential interventions on factors concerning activities, relations and environment that could have an impact over conditions. Thus, the matrix is used for a systematic analysis of potential interventions on secondary factors for each hypothesis of deployment system.

6.2.3 Connecting Intervention and Robot Capabilities

Robot evaluation and the logic of intervention are not naturally aligned. On the one hand, robot evaluation is grounded in the concept of performance, the optimisation of the capability to constantly accomplish a given task. On the other hand, an intervention is assessed under the light of the achieved impact, in terms of steering a positive change in a trend. In this view, a positive change is not necessarily the result of the performance of an isolated system, but of complex interactions and synergies within an only partially predictable socio-technological system. The definition of this connection is the core challenge of the co-design activity: defining the robotic intervention in terms of casual relations between the robot activities and the impact on the target factors. This connection is specified by instantiating the Capabilities to Factors Evaluation Matrix (see Fig. 6, instantiated in Tables 4, 6 and 8).

The Capabilities to Factors Evaluation Matrix is used as a pre-evaluation tool for the design of the intervention. For instance, the mapping can be used to apply a value-based analysis, using tools, such as the EU MAFEIP [1], on historical data on costing and evolution of conditions and hypothesis of performance/impact of the solution. Secondly, the mapping should also guide the definition of the evaluation and testing of the piloting of the robotic platform.

For instance, in the case of healthcare, the intervention impact concerns the relation between the applied robot capabilities and the frailty factors that define the object of the intervention, such as improving a user’s mobility at home. In this example, the mapping is grounded on a hypothesis of correlation between user’s mobility and robot’s ability to identify and remove obstacles and hazards from the user’s path. Under this hypothesis, the performance of the Exploration capability could be defined by the household area covered by the patrolling robot. However, from the perspective of the intervention, the impact should be measured considering the increase of the Mobility frailty factor and a possible reduction in the number of accidents (Health-physical frailty factor).

Fig. 6

Capabilities to Factors Evaluation Matrix. This model specifies the mapping structure connecting the logic of the intervention impact and robot evaluation, as positive interactions (and causal) relations between the evaluation of change of the target factors and the performances of robot capabilities

6.2.4 Scenario of Robotic Intervention

The presented design toolbox is used in the definition of scenarios of robotic intervention. A scenario of robotic intervention is the result of the co-design process and describes:

• 1. Definition of intervention focusing on identifying positive impacts concerning the patient’s activities, relationships, conditions, environment.

• 2. Given an intervention, identify and define robot capabilities that can effectively enable the intervention.

Hence, at the core of the design of an intervention is the identification of key activities which could trigger a cascade of positive interactions. In this view, the sustainability of robot interventions can be grounded on a design addressing multiple healthcare objectives, by targeting activities connecting multiple systems. For instance, a robot able to use communication technologies on behalf of the patient can support socialization by facilitating video calls, improve the access to healthcare services by taking appointments, and enabling remote visits, thus reducing dependence and the effects of isolation. Furthermore, the development of a scenario should also address the plurality of healthcare objectives and the complexity of the intervention ecosystem by providing a rationale based on explicit assumptions on the correlation between robot and expected impact. In this regard, the scenario should also report:

• 3. Evaluation plan of the scenario including the key performance indicators used to assess and monitor the hypothesis of positive contribution of robot activities in the intervention.

In the following section, we will illustrate how the proposed design toolbox can be used to describe robotic interventions in three real-world scenarios.

7 Robotic Intervention in GATEKEEPER

Table 4 Intervention deployment matrix of the “A Safer House” scenario

Table 5 Capabilities to factors evaluation matrix of the “A Safer House” scenario

This section presents the robotic interventions designed to address the use cases from the GATEKEEPER project: support poly-medication and multimorbidity patients at home. In the frame of GATEKEEPER, the definition of the interventions is the result of a participatory process involving caregivers, patients, technology providers and experts in technology for healthcare. The objective of these interventions is to increase medication and adherence to treatments by supporting their management, such as timing, dosages, movement and diet regime, self-assessment and logging. In this intervention, a home robot should provide timely reminders to mitigate the negative effects of minor cognitive impairments (e.g. forgetfulness) and respond to medical emergencies. As a secondary effect, the robot should reduce social isolation, distance from healthcare services, and the risk of living alone.

This medical use case concerns more broadly the support to health and wellbeing of patients managing multiple conditions over the years. These patients can live independently and in good health for many years, however their adherence to a regime of medications and to a correct lifestyle plays an essential role. Indeed, the effects of non-adherence and an unbalanced lifestyle cumulate, increasing the risk of degeneration [17]. Furthermore, patients with multiple conditions are at risk of insurgency of new conditions or health events requiring frequent monitoring. The expected value of the intervention concerns the reduction of hospitalisations by slowing the deterioration of conditions and extending the independent living of multimorbidity patients.

In this intervention, the deployment of a robot in patients household living alone (or elder couples) in rural areas can mitigate the lack of proximity healthcare services and physical presence of informal carers (e.g. family members and friends). Hence, this intervention requires a robot platform able to situate the user in the household, to learn habits by identifying activities and situations, to engage with the physical environment of the household, and also to interact with users both by means of a face-to-face modality and remotely.

In the context of this healthcare intervention, we identified three applicative scenarios. Each scenario is defined using a description of the robot task, a list of application-level capabilities and performance measures, the expected direct and indirect benefits of the intervention, and a mapping between capabilities and benefits.

The rest of the section describes the three scenarios by using the following structure and the presented design tools:

• a. Scenario description, a brief description of the deployment context, activity and expected impact of the intervention.

• b. Intervention Deployment Matrix highlighting the primary and secondary targets as direct and indirect benefits and the type of intervention. The scenario intervention deployment matrixes are the result of the application of the analysis framework for the Intervention Deployment Matrix (see Table 3).

• c. Capabilities to Factors Evaluation Matrix describing the mapping between performance criteria with evidences of impact for the primary and secondary factors, instantiating the general model in Fig. 6.

All three scenarios are based on the same ecological model of the robotic intervention identifying the source and potential relations between systems (see Fig. 5). It is worthwhile highlighting that the following scenarios set the deployment of the robotic intervention in the activities system. Rather than a general rule, this is a design choice grounded on project constraints, demanding a strong focus on supporting the self-management in a domestic environment.

Table 6 Intervention deployment matrix of the “Supporting Daily Chores” scenario

Table 7 Capabilities to factors evaluation matrix of the “Supporting Daily Chores” scenario

7.1 Scenario 1: A Safer House

For an older adult, the house can be full of risks, ranging from a bag left on the way to a kettle forgotten on the stove. In this view, this intervention focuses on mitigating the risks related to low mobility and mild cognitive impairment by identifying and removing hazards to mobility and preventing potential accidents caused by forgetfulness.

Within this scenario, when the user is not occupying a room, the robot will explore it and collect relevant information. This activity has multiple aims: to learn the layout of the room (i.e., continuous mapping); to learn the position of some specific objects (e.g., keys on the coffee table); to identify emergency situations (e.g., the stove is left on) and potential hazards (e.g., objects or cables on the floor); and to identify any significant discrepancy from previous observations.  Information about the layout of the room and the objects in it can be used to create an enhanced map to help the robot navigate and, eventually, guide the user to a specific location. Emergency situations can be resolved by interacting with the smart environment, for example turning off an electric heater, or by notifying the user. Better equipped robots can intervene directly to solve the potential hazard, for example by removing the object from the ground or by pushing it away.

The main focus of this intervention (see Table 4 Intervention Deployment Matrix) is the mitigation of the user’s low mobility, while the secondary targets are a) improving the quality of the house environment by supporting the access to the different house locations, b) mitigating mood swings caused by lack of confidence in moving around the house, and c) mitigating the risks of falls. The evaluation of the robot’s role (see Table 5Capabilities to Factors Evaluation Matrix) in the wider healthcare intervention is based on the hypotheses that a) the extension of the patrolling area can increase the confidence of the user and the fruition of the house, and b) the identification of hazards and interventions (through direct physical and digital actions, or through the involvement of a caregiver) can reduce the risks and number of falls, and improve the user’s perception of safety. The impact is evaluated through self-assessment questionnaires and direct measures of, e.g., number of transitions between rooms and risks identified.

Table 8 Intervention deployment matrix of the “Remote Presence” scenario

Table 9 Capabilities to factors evaluation matrix of the “Remote Presence” scenario

7.2 Scenario 2: Supporting Daily Chores

For older adults living alone, simple activities can become a burden, both from a physical point of view and in relation to the cognitive effort required by the need to concentrate, remember things, etc. In this view, the intervention focuses on supporting basic daily activities by, on the one hand, mitigating the effects of mild-cognitive impairment on scheduling and completing daily chores and, on the other hand, performing physically demanding tasks such as searching, lifting and fetching objects.

In this scenario, by creating a list of objects of interest (e.g., car keys, mobile phone, sunglasses, etc.), the robot can collect these objects from a previously known location and bring them to the user. During an early setup phase, the user can select a few objects and let the robot learn to easily identify them in the environment. When patrolling, the robot can identify and record the location of these specific objects. Later, the user can ask the assistance of the robot to locate or retrieve an object. Additionally, the robot can support user activities by delivering relevant items. This functionality is necessarily limited to a list of selected objects due to the limitations associated with object identification and grasping.

The intervention (described in Table 6 Intervention Deployment Matrix) addresses as primary target the user’s activities and as a secondary target the person’s conditions. Concerning activities, the intervention concerns a) the support to activities of daily living to be measured, e.g., in the capability of cooking food, doing housekeeping and taking medications, b) the support to cultural engagement to be measured on, e.g., reading of newspaper or books, and watching TV, and c) mitigation of dependence from others, to be measured as lowering the need for external support. Concerning conditions, the intervention focuses on the mitigation of the effects of cognitive impairments as improvement of attention and memory in daily activities.

The Capabilities to Factors Evaluation Matrix (see Table 7) specifies the performance criteria considered for the three robot capabilities required in this scenario: (1) exploration is evaluated by number of object identified, (2) manipulation is assessed by the number of actions carried out on request and (3) communication is evaluated by the number of reminders and information provided to the user. Considering the wider healthcare intervention, the impact of the exploration and communication capabilities should be evaluated via a self-assessment questionnaire for the users aimed at identifying the impact of mild memory and attention impairment within the activities of daily living. Concerning manipulation, we should consider, e.g., logs of robot actions (quantity) and a self-assessment questionnaire (qualitative analysis) to evaluate the actual presence of robot within the daily activities.

7.3 Scenario 3: Remote Presence

Being lonely becomes a habit when associated with a material difficulty in going out or when caused by a physical distance from family and friends. In this view, the intervention focuses on supporting social relations by having the robot acting as a proxy for remote presence in the contexts of socialization and care.

In this scenario, an external agent (e.g., a relative, a healthcare specialist, a friend) can remotely connect with or control the robot to assist the user or explore the environment. Any teleoperation activity must be agreed with the user first, by defining a specific timeslot (e.g., every Monday from 14:00 to 14:30) or by answering a telepresence call. Furthermore, as a result of a health event identified by a wearable device (e.g. measuring blood pressure and saturation, and/or fall detection capability), the robot can activate a call or suggest it to the user. During the teleoperation mode the external agent can communicate using the robot as an avatar or by video feed through a different device. The agent can guide the robot to explore the environment; here, different options are available: location-based (e.g., go to the kitchen), goal-based autonomous navigation (i.e., go to a specific place selected on the map), vision-based remote control (i.e., navigation from the robot point of view), and assisted remote control (i.e., directly guide the robot while avoiding obstacles).

Similarly to the previous scenario, this intervention focuses primarily on supporting activities of daily living (see Table 8 Intervention Deployment Matrix), while addressing as secondary target the mitigation of lack of mobility objectives in social relations and access to care, and supporting social relations within the neighbourhood. The impact is assessed considering the number of different social interactions facilitated by the robot, e.g., the variety of places accessible via telepresence, the number of calls fostered/initiated by the robot, the increase in the number of physical visits (see Table 9Capabilities to Factors Evaluation Matrix ). The evidences of impact should be collected considering the user’s perception of change of their relations within the neighbourhood (a self-assessment) as well as considering factual information (e.g., number of calls).

8 Discussion

The presented scenarios show elements in common with the landscape analysis of robot platforms presented in Sect. 3, specifically with respect to robot functionalities. Nevertheless, the proposed approach provides various potential benefits. Firstly, by relying on the definition of broader scenarios of healthcare interventions the applications designed have a more focused approach, giving priority to the impact of the robot, instead of maximising the number of functionalities of the platform. An example concerns the use of teleoperation in Scenario 3—Remote Presence. Usually, teleoperation is considered a secondary function, mainly used for early setups and debugging but, in Scenario 3, it is central to achieving the expected impact on factors such as Socialisation and Physical Health. Indeed, the focus on the healthcare intervention in the design of the robotic application introduces a significant divergence from the scenarios found in our landscape analysis, away from the specific capabilities implemented, and focusing on the potential benefits for the end users. This intervention-guided approach partially solves the issue of the derivative design seen in the literature, as it drives developers toward novel solutions or to repurpose existing applications to satisfy the requirements of the intervention, instead of reiterating previously adopted approaches.

Relying on a co-design approach during the early definition of the robotic intervention is also fundamental to define a trade-off between different implementations of the same capabilities. For instance, in our scenarios, the Manipulation capability appears in two different situations with different requirements. These are not necessarily incompatible, but they push the development towards two different directions. Thanks to the structure provided by the healthcare intervention, robot designers can prioritise one development route instead of the other, depending on which one is more impactful, or which one can be more easily realised.

Lastly, maintaining a connection between the healthcare intervention and the design of the robotic application also helps to define clear expectations to all the actors involved in the process. Often healthcare professionals are not aware of the real complexity associated with a specific task, and may wrongly assume that something trivial (e.g., indoor navigation) is challenging, while a complex functionality (e.g., fine manipulation) is misinterpreted as readily available. Moreover, a developer can define early the performance metrics that will be used to score the success or impact of the robot. Using the Capabilities to Factors Evaluation Matrices it is possible to define a bridge between the functionality of the robot and the expected impact, which can be used as a starting point to define precisely which capabilities will be deployed and how they will be evaluated in a later deployment phase.

9 Conclusions

The main contribution of this work is to provide an overview on how robots have been used to realise in-house personal assistants for older adults in the last few decades. What emerged is that this field followed a similar evolution to many others in AI and robotics where early prototypes were ambitious (e.g., MOVAID) but then, because of the complexity of the problem, researchers later scaled down requirements and focused on problems with more immediate solutions, such as navigation and human robot interaction. Unfortunately, the early successes of these focused approaches (e.g., Nursebot) led to a derivative approach where every new application was based on a previous one with minor increments. This approach is so widespread that even more recent solutions (e.g., Hobbit), which employ novel hardware configurations, only partially exploit them in their applications. As a result, robots for healthcare intervention are by and large implemented as reminder-centric assistants focused on mitigation and basic emergency reaction (i.e., fall detection).

For these reasons, our methodological contribution (the design toolkit) focuses on providing an approach to link the logic of robot deployment within a broader ecological model of healthcare intervention: a framework that do not prescribe a specific design process but can be integrated with different design methodologies. It is authors’ believe that addressing the gap between robot and healthcare intervention should be addressed at pre-design phase by defining explicit hypothesis about how the robot’s capabilities should achieve a measurable impact as part of a wider intervention.

In this regard, we defined the concept of application-level capabilities, a set of high-level functionalities that are significant for this specific range of applications. These can be combined with frailty factors commonly defined for healthcare intervention, resulting in a direct and measurable correlation between the robotic application and the benefit for the patients. The result is a co-design approach that combines the functionalities of the platform with the healthcare requirements. It is a bidirectional process that feeds the requirements of the intervention into the design of the robot and uses the limitation of the physical platform to estimate the benefits. The expected output is an application where the intervention stimulates innovation, by providing new challenges and a clear evaluation framework.

As a case-study based validation, we reported on the use of the toolkit in a real pilot, part of a wider large-scale pilot of the GATEKEEPER project. The case study illustrate the use of the Framework of Robotic Intervention in three different scenarios. Each scenario revolves around a primary target, as shown in the Intervention Deployment Matrix, which influences some specific frailty factors through an intervention. Additionally, secondary targets are identified, which are positive side effects. Using the Capabilities to Factors Evaluation Matrix we can clearly define the high-level capabilities of the robot involved in each scenario and highlight how they impact the frailty factor of the patient. Moreover, the approach highlights both the specific action connected to each capability and the tool used to measure performance. The two matrices are connected through matching frailty factors, with this relation defining the bi-directional relations between the deign of the robotic platform and the aims of the healthcare interventions described in the scenarios.

In the future, we will iterate on the co-design toolkit to refine both the definition of the functionalities of the robot and the activities performed in the intervention. Our long term objective is to achieve a design that is general, i.e., adaptable to similar robots and intervention, portable, i.e., easily deployed in multiple locations, self-contained and replicable, i.e., contains all the necessary information for repeated deployments.