Reference Architectures, Platforms, and Pilots for European Smart and Healthy Living—Analysis and Comparison

Abstract

Motivated by the aging trend, much effort is being invested into implementing ICT (Information and Communications Technology)-enabled systems to provide a better quality of life and support the independent living of older people. As a result, many systems, often labeled as eHealth or AAL (Ambient/Active Assisted Living), were developed over the years. In creating such systems, which very often serve various needs, different architectures have emerged. This work focuses on analyzing and comparing the work and architectures from seven (six of which are in progress) EU-funded healthcare projects, with a total budget of 126MEUR in which we participate. After establishing the theoretical foundation by defining core concepts, we give a brief background on architectures in eHealth and AAL. We elaborate on the chosen analysis method based on three established healthcare and AAL taxonomies we identified by performing a literature survey and the selected Reference Architecture Model (RAM). Since there is no standard way of describing architectures in the eHealth and AAL domain, we conducted the online survey during August and September 2020 and identified CREATE-IoT 3D RAM as the most appropriate option. We present a classification of selected projects based on established taxonomies and map projects’ architectures to CREATE-IoT 3D RAM, which we also propose as standard RAM for future digital healthcare and AAL projects. During our analysis, we identify the most common types of assistance: communication support, reminders, monitoring, and guidance to address health and communication issues. We conclude that proper ecosystems are critical for lowering entry barriers and facilitating sustainable solutions for smart and healthy living.

1. Introduction

Much effort is being invested towards achieving the ICT-enabled independence of older adults to enhance their quality of life and overall wellbeing [1,2]. Technology is used for assistance, physical and cognitive support, rehabilitation, monitoring, learning, communication, and increasing safety, resulting in quite a few groups of products and services addressing the needs of older people and their immediate caregivers and family members. In a recent survey of AAL systems and the main issues related to their development, Cicirelli et al. [3] argued that AAL systems became, especially during the pandemic, essential for communication, safety, and security.

At the beginning of 2021, The Green Paper on Aging [4] was released for the EU’s public consultation. It promotes healthy and active aging and raises awareness of the socio-economic impact of demographic change as one of the top three megatrends shaping European society (alongside climate change and digitalization). The European population is getting older, while, at the same time, the working population is decreasing, and the average size of households is declining. According to the European Commission Report on the Impact of Demographic Change, about a third of households consist of a single person, meaning that a growing number of people over 65 live alone. This major challenge is also an opportunity for the “silver economy”, a so-called concept that includes all activities, products, and services for older people, to mitigate the gap and find innovative ways to provide high-quality care more efficiently and on a larger scale.

Consequently, because of the demographic change and aging society fueled by increased longevity, there is rising pressure on national healthcare systems, which is expected to increase even further in the coming years and decades. Aging is often accompanied by the increasing prevalence of chronic conditions, age-related disorders, and decreased functional capabilities. Despite the advances in medical science, the expenditures for health and long-term care are increasing. In addition to promoting integrated care, disease prevention programs, efforts to move healthcare from hospitals to more cost-effective primary care, and new innovative solutions that increasingly use digital technologies are recognized as innovative and promising answers to the problems mentioned. A 2019 report from the European Commission’s Expert Group on Health System Performance Assessment concluded that “patients require the provision of care in the alternative, lower intensity settings, typically closer to home” [5] (p. 50).

Under Horizon 2020, research and innovation are supported and funded to further use digital technologies in health and long-term care. One initiative in this direction, launched by the European Commission, is the European Innovation Partnership on Active and Healthy Ageing (EIP on AHA), a “communication and information hub for all actors involved in Active and Healthy Ageing through Europe”. EU supports cross-border interoperability and prioritized access of health data (e.g., Electronic Healthcare Records, EHRs) to support the free flow of patients and provision of good healthcare.

There are different definitions of eHealth. Oh et al. [6] identify 51 published eHealth definitions in their systematic review of published eHealth definitions (by analyzing 1209 abstracts, 430 citations, and 1158 websites). In most definitions of eHealth, technology is mentioned as a tool to expand and assist human activities. In one of the most recent analyses of eHealth, Hallberg and Salimi [7] confirm findings by Oh et al. and expand the survey to the concept of mHealth, where the focus is on using mobile devices. According to the WHO (World Health Organization), eHealth is “the cost-effective and secure use of ICT in support of health and health-related fields”, including telehealth, telemedicine, mHealth, and associated related fields.

The term Active and Assisted Living, before 2014 known as Ambient Assisted Living, originates from the EU Joint Programme under the same name. The primary goal of Ambient/Active and Assisted Living (AAL) systems is to improve the quality of life of older people by extending their independence in preferred (mostly home, but also work and outdoor) environments. AAL solutions aim to achieve this by using ICT technologies and building personalized and somewhat adaptive systems often comprised of sensors, actuators, robots, user interaction devices, and accompanying communication infrastructure. Provision of remote healthcare and telehealth, reduction of social isolation, fall detection, and medication intake reminders are all among common scenarios in the field.

All eHealth and AAL projects, which utilize some software solutions, achieve this by defining the desired qualities and properties of the system and document them through architecture description that is to be realized, implemented, and deployed to serve the required purpose. A standardized way of representing architecture descriptions often does not exist, making the process of comparing and analyzing the work challenging and corresponding results scarce. Very often, the visualization of the architecture follows no common standards and mixes different architecture views (functional, system, user, information, and communication). Purpose, primary goals, and stakeholders are most often omitted from the description of the architecture event though they are critical for its understanding. When mapping our selected projects to the chosen RAM, we found that the layers and cross-cutting functions outlined by the CREATE-IoT 3D RAM model were sufficiently broad enough to describe each project’s architecture comprehensively. For this reason, we propose the CREATE-IoT 3D RAM model as a standard RAM for future digital healthcare and AAL projects.

The following Section 2 explains the terminology used in the paper and gives more detail on eHealth and AAL systems’ architectures. Section 3 introduces the selected projects we are assessing and provides information on their goals and objectives. In Section 4, the analysis method is defined, and established taxonomies described and most-voted RAMs from the online survey we performed in summer 2020. Section 5 presents the result and related discussion, Section 6 concludes the paper, while Section 7 elaborates on future directions.

2. Background

2.1. Reference Architecture Model (RAM), Reference Architecture (RA), Concrete Architecture (CA), System

Since terms discussed in this paper may have a different meaning to different people, we start by making their definitions explicit to ensure a common understanding.

According to IEEE/ISO/IEC 42010-2011 [8], architecture represents “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution”. The term system (as described in ISO/IEC 15288) refers to entities whose architectures are of interest, that are “man-made and may be configured with one or more of the following: hardware, software, data, humans, processes, procedures, facilities, materials, and naturally occurring entities”.

OASIS (Organization for the Advancement of Structured Information Standards) [9] defines a reference model as “an abstract framework for understanding significant relationships among the entities of some environment”. The Reference Architecture Model (RAM) serves as an abstract framework consisting of interlinked concepts providing common understanding and logical groupings within architectures.

Reference Architecture (RA), as defined by Bass et al. [10], is a “reference model mapped onto software elements (that cooperatively implement the functionality defined in the reference model) and the data flows between them”. Reference architectures aim to capture the essential characteristics of systems’ (concrete) architectures in a specific domain. However, it is often unclear what precisely they should contain and which fundamental concerns they should cover.

Architecture descriptions should, in most cases, identify:

• System stakeholders (including users, operators, owners, developers, maintainers);
• Fundamental concerns (including the purpose of the system, suitability of the architecture to fulfill the set objective, feasibility, risks, maintainability, evolution);
• Architecture views (representing a related set of concerns as seen from a perspective a view is taken, a viewpoint); and
• The rationale for each important architecture decision.

In practice, however, the architecture descriptions are often fuzzy. There have been attempts to improve the understanding of RA, such as the one by Nakagawa et al. [11], who proposed their RAModel (Reference Architecture Model). They concluded that a RA for a given application domain should address the business rules, architectural styles (addressing quality attributes), best software development practices, and technical, business, and customer context knowledge. Furthermore, they identified groups of elements for RA as a domain (legislation, quality, compliance, regulation), application (goals, needs, risk, scope, functional requirements, domain data), infrastructure (software and hardware elements, best practices), and cross-cutting (internal and external communication, domain terminology, decisions with rationale).

Concrete Architecture (CA) can be considered an instance of RA for a specific context and addresses particular requirements for involved stakeholders. It is implementation-specific, defining what the system will do and how.

The relation between RAM, RM, CA, and the system (as the implementation of the CA) is shown in the following figure (Figure 1). Definition of CA involves making many different design decisions to define boundaries for implementing a concrete system.

2.2. Architectures in eHealth Systems

Merilampi and Sirkka [12] identified seven partially overlapping groupings of eHealth technologies: (1) assistive technologies, (2) safety and social technologies, (3) health technologies, (4) self-activation and personal development technologies, (5) design-for-all and AAL technologies, (6) gerontechnology, and (7) hospital technology and EHR (Electronic Health Record) systems.

Internet of Things (IoT) is revolutionizing health technologies, and trends include network architectures and platforms, new services and applications, interoperability, and security [13]. Different distributed devices send medical information to the cloud in IoT-based healthcare, making it possible to process and analyze large amounts of data [14]. Dang et al. [15] surveyed IoT and cloud computing for healthcare and confirmed challenges such as data security, privacy, system development process, and business models. Ahmadi et al. [16], in a review of 60 papers published between 2000 and 2016, found that home healthcare service was among the main application areas of IoT in healthcare. New trends in IoT-based solutions for healthcare include moving AI (Artificial Intelligence) to the edge [17], motivated by cloud systems’ response times and availability. Birje et al. [18] propose IoT-based distributed healthcare system (IoT-DHS) architecture composed of five layers, namely users/things (at home or hospital, clinical staff, medical equipment, mobile patient), health application hosting devices (including laptops, desktop, mobile phone), communication system, Internet, and IoT healthcare cloud. Naresh et al. [19] propose a fog-based architecture for IoT-based healthcare applications to address the latency issues, which contains three layers: sensing, fog, and cloud layers.

As an international non-profit, open industry group, Continua Health Alliance promotes a RA that identifies critical issues for the architecture in this area as interoperability of the IoT gateway and with Wireless Personal Area Network (WPAN), multimedia streaming, and secure communication. Continua Design Guidelines promote the international standard for safe, secure, and reliable data exchange to and from personal health devices [20]. Critical aspects of eHealth architectures are reliability, security [21], and accuracy [22].

Largely facilitated by the rise of IoT, the Cyber-Physical Systems (CPSs), as the next generation of ICT systems that integrate sensing, computing, storage, and communication capabilities to control and interact with a physical process [23], are also being utilized in eHealth. Healthcare CPSs, compared to eHealth, involve much more physical components and aim to improve quality in healthcare by providing real-time supervision from a distance [24]. According to a survey by Plaza et al. [25], healthcare CPS should meet the following architectural requirements: heterogeneity and dynamic discovery of sensor(s), scalability, interoperability, dynamic reconfiguration, security, and privacy. The survey authors propose a RA for healthcare CPS as four-tier architecture: perception tier, middleware/gateway tier, application tier, and programming abstraction tier.

2.3. Architectures in AAL systems

El Murabet et al. [26] give a survey of the AAL system’s models and architectures and confirm no commonly accepted RAM for AAL. Analysis of AAL models and architectures showed that dealing with heterogeneous data sources and data flow is one of the inherent aspects of the AAL domain. However, no AAL RA specifics were identified. Kara et al. [27] identified a data quality model for AAL systems, based on ISO/IEC 25012 and ISO/IEC 25010, comprising of the following criteria: accuracy, completeness, recoverability, confidentiality, efficiency, precision, reliability, security. One reason for the non-existence of more widely accepted RA for AAL lies in the fact that many solutions are not single-purpose and try to deliver different functionalities to a wide range of end-users. By striving to satisfy different needs of various stakeholders and fulfilling a wide range of expectations at once, AAL solutions face numerous challenges.

IoT often serves as a technical enabler for many application domains, including AAL. For this reason, IoT and AAL share many research and open issues such as standardization, heterogeneity, security, and privacy. To achieve the full potential and to bring forth the solutions that will be widely accepted, easy to use, maintain, and affordable by many, the AAL domain misses more nationwide initiatives, interdisciplinary collaboration, standardization, regulation, legislation. With the growing amount of (sensitive and other) data, cross-cutting concerns such as security, privacy, and interoperability come into focus, which is also confirmed in a survey on IoT reference architecture by Di Martino et al. [28].

A survey by Memon et al. [29] showed the AAL systems often address only a limited set of features and ignore many essential aspects such as medical device interoperability and integration, security, privacy, data protection, quality attributes (usability, accuracy, dependability), user experience, availability, reliability, AAL system architecture, frameworks, open solutions, technology standards, and specification.

A survey by Calvaresi et al. [30] showed, by analyzing 236 selected papers, that the most popular surveyed architectures are ad hoc solutions (51%), Multi-Agent Systems (19%), and Service-Oriented Architectures (SOA) (12%). Part of the reason for ad hoc architectures lies in the fact that many solutions aim to provide multiple services simultaneously. Furthermore, only a third of the papers report a detailed evaluation of the proposed architectures, while most do not provide details on the design process.

In an example by Nikoloudakis et al. [31], it is seen that even in the network layer, some new and coming functionalities are used to address use cases in the AAL domain. Authors show that the utilization of Virtual Network Function (VNF) for smart enhanced living environments can enable caretakers and first responders to constantly monitor a patient’s indoor/outdoor position and receive notification in case of emergency. This approach also considers the case of a patient drifting away from their premises. In that case, the VNF retrieves the closest-to-the-patient third party agents (caretakers, hospital, police, volunteers, first responders) through the Location-to-Service-translation (LoST) protocol and alerts them via a Session Initiation Protocol (SIP)-based Voice over IP (VOIP) communication channel.

Many AAL systems address health, which is understandable considering the AAL field is primarily motivated by the aging society. An increasing number of older people need appropriate care and support, to a great extent, because of progressively complicated health-related issues. Rodríguez et al. [32] give one of the very few analyses of reference architectures for healthcare in the AAL domain (for which they used RAModel, mentioned in Section 2.1). They identify four application domains addressed by reference architectures in the AAL domain as (1) personal care, (2) person-centered health management, (3) telemonitoring and self-management of chronic diseases, and (4) personal activity management.

3. Selected Health and Care Projects in A Nutshell

All projects selected for analysis in this paper are funded under the EC (European Commission) umbrella program “Societal Challenges—Health, demographic change and wellbeing”. More concretely, they are part of H2020-EU.3.1.4. Active ageing and self-management of health, H2020-EU.3.1.4.1.—Active ageing, independent and assisted living, and H2020-EU.3.1.5.1.—Improving health information and better use of health data. Projects are also part of the Health and Care Cluster under OpenDei Coordination and Support Action (CSA) aiming to align reference architectures, open platforms, and large-scale pilots in digitizing the European industry [33]. Projects involve stakeholders from the demand and supply side and aim to demonstrate operating systems across multiple sites and with many reals users. Large-scale validation of resulting pilots will observe how pilots operate under conditions, loads, and constraints in real-life scenarios.

3.1. Activage Large Scale Pilots

ACTIVAGE (ACTivating InnoVative IoT smart living environments for AGEing well, H2020-IOT-2016, #732679, 2017-2020, 25.2MEUR) [34] aimed to build the first European IoT ecosystem across 9 Deployment Sites (DS) in seven European countries, reusing and scaling up underlying open and proprietary IoT platforms, technologies, and standards.

ACTIVAGE IoT Ecosystem Suite (AIOTES) is a set of techniques, tools, and methodologies for interoperability at different layers between heterogeneous IoT platforms and an open framework for providing semantic interoperability of IoT platforms for AHA. AIOTES enables the deployment and operation at a large scale of active and healthy ageing IoT-based solutions and services, supporting and extending the independent living of older adults in their living environments, and responding to the needs of caregivers, service providers, and public authorities. Although the project ACTIVAGE has formally ended, the results are transferred to the ACTIVAGE.ORG association with the mission to create a digital market of solutions and services for independent living, active aging, and the wellbeing of senior people.

ACTIVAGE Large Scale IoT Pilot for Ageing Well was conceived as a unique opportunity to scale up use cases (UCs) that the demand side of the representative sites considers strategic for the aging well of the target populations. These UCs are activities of daily living, integrated care, monitoring outdoor, emergency triggers, promoting exercise for fall prevention, preventing cognitive decline, preventing social isolation, offering safety and comfort, and support for transportation. ACTIVAGE Large Scale Pilot (LSP) aims to align, set up, deploy and measure several relevant use cases that provide value for the assisted persons in nine deployment sites across several European countries: Spain, France, Italy, Germany, Greece, Finland, and the United Kingdom.

3.2. Adlife Large Scale Pilots

ADLIFE (Integrated Personalized Care For Patients With Advanced Chronic Diseases To Improve Health And Quality Of Life, H2020-SC1-DTH-11-2019, #875209, 2020-2024, 7.5MEUR) [35] aims to improve the quality of life of advanced chronic patients through intelligent digital integrated, personalized care. The envisioned digital solution supports and promotes a patient-centered multidisciplinary and multi-sectorial approach focus on early detection of care needs to tailor dynamic and personalized care provision. It also enhances patients’ and caregivers’ autonomy by encouraging them to participate in informed decision-making, fostering their empowerment and adherence to care plans.

ADLIFE includes the following tools: (1) a personalized care plan management platform that enables the multidisciplinary professional team to manage and adapt patient-centered care plans, (2) clinical decision support services (CDSS) for physicians and nurses that detect care needs and suggest dynamic and personalized care interventions and (3) a patient empowerment platform that enables patients (and if necessary their caregivers) to better manage their conditions by viewing and coordinating their care plans. These tools will be well-integrated with the electronic health records used at the clinical sites: continuous two-way information exchange is essential to share care plans, patient preferences, feedback, and patient recorded data.

ADLIFE will be deployed in seven different countries and health systems, involving 577 healthcare professionals from 75 different hospitals, clinics, and primary care services. It will evaluate its effectiveness in 882 patients and 1243 caregivers. Patients will be seniors (over 55) with severe heart failure (NYHA III-IV) or COPD (FEV1 < 50%). The effectiveness and efficiency of the intervention are planned to be assessed by evaluating the quality of life, health gain, use of resources, and economic costs. The project will produce guidelines and policy recommendations providing sustainable, flexible, and replicable solutions to deploy at a large scale to other patient groups in the EU and beyond.

3.3. Gatekeeper Large Scale Pilots

GATEKEEPER (Smart Living Homes—Whole Interventions Demonstrator For People At Health And Social Risks, H2020-SC1-FA-DTS-2018-2, #857223, 2019-2023, 23.6MEUR) [36] aims to create an ecosystem to connect healthcare providers, businesses, entrepreneurs, older citizens, and the communities where they reside. The project focuses on creating combined digital solutions for personalized early detection and interventions that harness the next generation of healthcare and wellness innovations. Within the GATEKEEPER project will be delivered a digital platform implemented through fault-tolerant, secure, flexible, and scalable micro-services infrastructure, based on open source and data standards with the strong developer community, built on top of reference W3C-Web of Things architectural models and including services referred to the health domain through HL7-FHIR (Health Level Seven—Fast Healthcare Interoperability Resources) and to the home domain through SAREF, for the establishment of a new generation of digitalized multi-domain health services validated within the large scale pilot.

GATEKEEPER aims to demonstrate its value by scaling up the deployment of solutions involving around 40.000 older citizens, supply and demand side (authorities, institutions, companies, associations, academies) in 11 communities, eight from seven EU (European Union), and three from Asian member states. Each pilot will address a subset of nine reference use cases (RUCs) based on three types of interventions addressing the general population, moderate complexity chronic patients, and highly complex and chronic and palliative patients.

3.4. Pharaon Large Scale Pilots

PHARAON (Pilots for Healthy and Active Ageing, H2020-SC1-FA-DTS-2018-2, IA, #857188, 2019-2023, 21.3MEUR) [37] aims to create an open ecosystem for smart and active aging of the European population by putting together a range of integrated and highly adaptable interoperable open platforms with advanced services, devices, and tools including IoT, artificial intelligence (AI), robotics, cloud computing, smart wearables, big data, and intelligent analytics. The project includes 41 partner organizations from 12 EU countries. Use cases include cognitive stimulation, health monitoring, health management, socialization, learning, a safe and comfortable environment, and improvement of care and wellbeing.

Pharaon Large Scale Pilots (LSPs) are being realized at six different pilot sites: Murcia and Andalusia (Spain), Portugal, the Netherlands, Slovenia, and Italy, with the plan to involve 2500 users and 350 experts.

3.5. Shapes Large Scale Pilots

SHAPES (Smart and Healthy Ageing through People Engaging in Supportive Systems, H2020-SC1-FA-DTS-2018-2, IA, #857159, 2019-2023, 20.9MEUR) [38] aims to build an interoperable Platform integrating smart digital solutions to collect and analyze older individuals’ health, environmental, and lifestyle information, identify their needs and provide personalized solutions that uphold the individuals’ data protection and trust. Standardization, interoperability, and scalability of the SHAPES platform sustain increased efficiency gains in health and care delivery across Europe, bringing improved quality of life to older individuals, their families, caregivers, and care service providers.

The SHAPES large-scale piloting campaign engages 2000+ older individuals in 15 pilot sites in 10 EU Member States, including six EIP on AHA reference sites. It involves hundreds of key stakeholders to bring forth solutions to improve the health, wellbeing, independence, and autonomy of older individuals while enhancing the long-term sustainability of health and care systems in Europe. SHAPES’ multidisciplinary approach to large-scale piloting is reflected across seven themes that, together, provide a clear understanding of the reality of European health and care systems and enable the validation of cost-efficient, interoperable and reliable innovations capable of effectively supporting healthy and independent living of older individuals within and outside the home.

3.6. Sphinx Pilots

SPHINX (A Universal Cyber Security Toolkit for Health-Care Industry, H2020-SC1-FA-DTS-2018-1, #826183, 2019-2021, 5MEUR) [39] aims to introduce a Universal Cyber Security Toolkit, thus enhancing the cyber protection of the Health IT Ecosystem and ensuring patient data privacy and integrity. SPHINX toolkit will provide an automated zero-touch device and service verification toolkit that will be easily adapted or embedded on existing medical, clinical, or health available infrastructures. In contrast, a user/admin will choose from several available security services through the SPHINX cybersecurity toolkit. The SPHINX toolkit will enable service providers to specify complete services and sell or advertise these through a secure and easy-to-use interface.

The SPHINX proposed technology and business framework will be demonstrated and validated against performance, effectiveness, and usability indicators under real operating conditions in Greece, Portugal, and Romania. The scenarios identified will consider cross-border medical data exchange, intra-region patient data transfer, and tampering with medical devices and medical sensors. The main objective of the SPHINX pilots is to showcase how independent components of the SPHINX toolkit can be utilized per threat in a fast and simple-to-use solution.

3.7. Smart Bear Large Scale Pilots

The SMART BEAR (Smart Big Data Platform to Offer Evidence-based Personalised Support for Healthy and Independent Living at Home, H2020-SC1-FA-DTS-2018-2, IA, #857172, 2019-2023, 22.4MEUR) [40] project aims to leverage analytics. It uses data continuously collected through devices to offer evidence-based personalized support to older citizens, improve their health, and help them maintain their independent living. SMART BEAR also supports the ingestion of FHIR-compliant medical data of participants from other, non-device sources, such as EHR (Electronic Health Record) systems and medical repositories developed by other H2020 projects for the participants that are common to both SMART BEAR and these projects. It incorporates heterogeneous sensors, and assistive medical and mobile devices.

SMART BEAR provides big data analytics and learning functionality applied to the collected data to generate the evidence mentioned above for making decisions about personalized interventions. Information security and privacy capabilities are incorporated by design, protecting the data at rest, transit, and processing.

The goal of SMART BEAR is to recruit around 5000 participants and cover six comorbidities: hearing loss, cardiovascular diseases (heart failure, arrhythmias, hypertension), balance disorders, mental disorders (depression, anxiety), frailty, and mild cognitive impairment. These participants will be recruited in six EU countries: France, Greece, Italy, Portugal, Romania, and Spain.

4. Analysis Method Definition

To systematically assess previous work in the field and to lay the foundations for our future analysis, we performed a focused literature survey and review. An additional reason for opting for such an approach was to remain as objective as possible since defining our analysis framework would lead to bias and possibly raise questions on objectivity.

4.1. Selection of Established Taxonomies

After surveying the taxonomies in the field using keywords including eHealth, healthcare, Ambient Assisted Living, Active Assistive Living, and taxonomy, we have selected three relevant and established taxonomies that we shortly introduce in the subsequent Section 4.1.1, Section 4.1.2 and Section 4.1.3.

4.1.1. Pervasive Healthcare Systems (PHS) Taxonomy

Muras et al. [41] proposed a taxonomy of Pervasive Healthcare Systems (PHS) that extends the World Health Organization (WHO) International Classification of Functioning, Disability and Health (ICF). The taxonomy defines seven main feature categories, namely:

• Body functions (including mental, sensory, voice and speech, movement-related, cardiovascular, respiratory, immunological), to imply the appropriate User Interface (UI);
• Activities and participation (including general tasks, communication, mobility, self-care, domestic life), indicating tasks that the user cannot manage;
• Support (including participants, caregiver, vicinity), to imply who may benefit from the system;
• Source of data for sensor (including participant, object, environment, time), to mean the kind of data that triggers the action;
• The target of actuator’s action (including participant, caregiver, object, data store), to imply identity or object a device’s outcome is executed;
• Environment (including indoors and outdoors), to indicate where the pervasive system is used;
• Products and technology, to imply areas of use (including use in daily living, indoor and outdoor mobility, communication, protection, health) and types of assistance (including localization, guidance, reminding, communicating, monitoring, assisting).

4.1.2. AAL Taxonomy

Byrne et al. [1] reviewed AAL systems and proposed a taxonomy to classify them. The proposed AAL taxonomy, or AAL functional services classification as the authors also refer to it, is shown in the following figure (Figure 2).

4.1.3. Data Quality-Oriented AAL Taxonomy

Beevi et al. [42] presented a data quality-oriented AAL taxonomy based on a literature survey and the authors’ own experience from developing an AAL platform. The summary of that taxonomy, composing of 10 dimensions, is illustrated in the following figure (Figure 3).

4.2. Selection of Reference Architecture Model (RAM)

Supported by the CSA OpenDei [43], WorkGroup 4 (Architectures, Standards, and Reusable components) was initiated as a cross-project initiative among healthcare projects. Apart from the discussions, information exchange, initial planning, and state-of-the-art overviews, one of the first notable outcomes was the survey design and related information collection. The online survey was opened for all Health and Care Cluster project participants during August and September 2020. Responses were received from 22 participants from academia, industry, public sector, and SMEs (Small and Mid-size Enterprises).

From the group of questions related to architecture on the applicability of the reference model, a total of 73% of the participants agreed (most of which strongly agreed) that the RAM to be used should be technology-agnostic. The question was formed in a way not to reveal the specific RAM or RA name, but instead only their layers of the functional domain (“The architecture of the project I am working on could be illustrated using following layers or functional domains [select all that apply]:”) to avoid prejudice and to ensure more reasoned answers. The suggested options, identified via the previous desk research survey (performed by the WG4 leader and the first co-author of this paper), were

• IDS RAM (International Data Spaces Association, Reference Architecture Model) 3.0 [44];
• IIRA (Industrial Internet Reference Architecture) [45];
• IoT reference model by ITU-T Y.2060 [46];
• CREATE-IoT 3D RAM [47];
• RAMI4.0 (Reference Architecture Model Industrie) [48];
• ISO/IEC 30141: 2018 IoT RA [49]; and
• None.

The most voted option in terms of individual votes was IDS RAM 3.0, while the most voted option in terms of votes coming from Health and Care Cluster projects was CREATE-IoT 3D RAM.

4.2.1. IDS RAM 3.0

The IDS RAM 3.0 [44], released in April 2019, has a five-layer structure (system, information, process, functional, and business) and three cross-cutting perspectives (security, certification, and governance). The main goal of IDS RAM is to facilitate secure data exchange and trusted data sharing (following the principle of data sovereignty), one of the critical requirements in eHealth and AAL systems (as mentioned in Section 2.2 and Section 2.3). The IDS RAM aims to become a blueprint for European Data Sharing Spaces implementing EU strategy for data and realizing a genuine single data market, focuses on creating a trusted data exchange environment and linking different cloud platforms.

4.2.2. CREATE-IoT 3D RAM

The following figure (Figure 4) shows the CREATE-IoT 3D RAM, a result of a project CREATE-IoT (CRoss fErtilisation through AlignmenT, synchronization and Exchanges for IoT) [50], running from January 2017 to June 2020 to stimulate collaboration between IoT initiatives and supporting the development of IoT ecosystems based on open technologies and platforms. The CREATE-IoT 3D RAM consists of horizontal functional layers (reflecting the IoT implementations across various domains), cross-cutting functions (addressing functionalities spanning across several layers), and system properties (addressing global system properties). Further analysis (in Section 5.2) is based on this RAM.

5. Presentation of Results

5.1. Classification Based on Selected Taxonomies

In Section 4.1, established taxonomies are identified and selected, and this section presents the results of the classification of projects according to selected taxonomies.

5.1.1. PHS Taxonomy-Based Classification

The following table (

Table 1. Projects’ classification based on Pervasive Healthcare Systems (PHS) taxonomy.

Category	Activage	Adlife	Gatekeeper	Pharaon	Shapes	Sphinx	Smart Bear
Envisioned types of UI	Mobile, web, embedded	GUI	GUI, robot	GUI, robot	GUI, Digital Assistant	GUI	GUI, Digital Assistant
Activities	Daily living, integrated care, monitoring outdoor, emergency triggers, fall prevention, cognitive decline, social isolation, transportation	Communication, self-care, multidisciplinary care team coordination	Early prevention and intervention at a different level	Communication, self-care, transportation	Communication, Self-care, Remote care, Homecare	Communications, Remote care	Communication, Self-care
Primary users	Older people, caregivers	People with multiple chronic conditions, informal caregivers, Multidisciplinary care team members	People with multiple chronic conditions (High and moderate risk), general population.	Older people	Elders, Care practitioners,	ICT personnel, General hospital visitors	Elders, medical research teams
Source of data for the sensor	Participant, Environment, care provider	Participant, EHR, sensor devices	Participant, EHR, sensor devices	Participant, environment, time	Participants, Sensors devices	Home environment, Medical Sensors devices	Participant, EHR, mobile devices, Smart home sensors
The target of the actuator’s action	Participant, caregiver	Participant, caregiver, datastore	Patients, Citizens, caregiver, healthcare provider	Participant, caregiver, datastore	Participant, caregiver, datastore	ICT infrastructure	Participant, datastore
Environment	Indoor, Outdoor	Indoor	Indoor, outdoor	Indoor, outdoor	Indoor, outdoor	ICT infrastructure	Indoor, outdoor
Areas of use	Communication, health	Communication, health	Communication, health	Communication, health	Communication, health	Communication, health	Communication, health
Types of assistance	Training, guidance, monitoring, communicating	Guidance, reminding, communicating, monitoring	Reminding, communicating, monitoring	Reminding, communicating, monitoring	Voice		Guidance, reminding, monitoring

) summarizes the classification of projects based on the Pervasive Healthcare Systems (PHS) taxonomy. Each of the seven selected projects is analyzed through eight PHS taxonomy categories.

The following figure (Figure 5) summarizes the PHS taxonomy-based classification commonalities of projects from Table 1. Any entry mentioned only once is omitted from the figure to emphasize only the common properties, making it more apparent where most projects converge.

To better identify the connections between projects and inter-dependencies concerning the taxonomies, a graphical representation of the projects’ mappings are given in the following figure (Figure 6). The figure content is based on the content of the analysis from the previous table (Table 1). The most relevant information is at the edges of the provided chord diagram. The primary purpose is to show the connections between concepts from the selected taxonomies (nodes of the graph), making it apparent where projects converge most.

The most common type of user interface is GUI, following by robots and digital assistants. Communication is one of the core identified activities followed with different kinds of care, including integrated care, remote care, self-care. Primary users are naturally older people and caregivers. Even though people with chronic conditions are shown as separate user groups, they are often considered interchangeable with older user groups. The data sources are participants (older people) and the environment, and the typical way of collecting the data is by using different sensors. Such sensors are typically non-medically certified ones.

5.1.2. AAL Taxonomy-Based Classification

Since project Sphinx focuses on cross-cutting cybersecurity aspects and is agnostic to specific applications, its analysis based on AAL taxonomy was omitted from the following table (

Table 2. Projects’ classification based on AAL taxonomy.

Category	Primary Function	Activage	Adlife	Gatekeeper	Pharaon	Shapes	Smart Bear
Smart Homes	General Health Monitoring	+		+	+	+	+
	Platforms	+		+	+	+
Intelligent life assistants	Wandering Prevention tools	+
	Electronic Home Control Systems	+		+	+	+
	Fall Detection Systems	+			+	+
Wearables	On-the-body sensors	+	+	+	+	+	+
Robotic Assistance	Intelligent Physical Movement Aids					+
	Health					+
	Service and Companion			+	+	+

+ addressed.

).

All selected projects that deliver end-to-end applications to primary users use wearable on-the-body-sensors, and almost all do that within their homes (in a smart home domain). Project Shapes focuses on robotic assistance for health and physical movement aid, which no other project provides.

5.1.3. Data Quality-Oriented AAL Taxonomy-Based Classification

For the same reason as with AAL taxonomy (Section 5.1.2), the analysis of cross-cutting Sphinx was omitted for this taxonomy and the following table (

Table 3. Projects’ classification based on data quality-oriented AAL taxonomy.

Dimension	Function	Activage	Adlife	Gatekeeper	Pharaon	Shapes	Smart Bear
Activities and participation	General tasks and demands	+		+	+	+
	Mobility	+		+	+	+
	Self-service	+	+	+	+	+	+
	Communication	+	+	+	+	+	+
	Domestic life	+	+	+	+	+
Data type	Structured	+	+	+	+	+	+
	Semi-structured	+	+		+	+
	Unstructured					+
Functionality	Monitoring	+	+	+	+	+	+
	Integrating	+	+	+	+	+	+
	Interacting	+	+	+	+	+	+
	Acting	+		+	+	+
Destination of data	Remote server	+	+	+	+		+
	Local server	+			+	+
	Embedded memory	+			+	+
Interoperability	Open	+	+	+	+	+	+
	Closed
Deployment	Wearable			+	+	+	+
	Ambient		+	+	+	+	+
Data distribution	Live streaming	+		+	+	+
	Store and forward	+	+	+	+	+	+
Type of response	Alarm	+	+	+	+	+	+
	Data	+	+	+	+	+	+
	Assistance	+	+	+	+	+	+

+ addressed.

).

Since the categories of body functions (implying an appropriate type of UI) and source of data for the sensor are very similar in Pervasive Healthcare Systems taxonomy as well as in data quality-oriented AAL taxonomy, the corresponding rows are omitted from Table 3 in order not to repeat the information from Table 1 rows #1 and #4.

The following figure (Figure 7) summarizes the data quality-oriented AAL taxonomy-based classification of projects from Table 3.

All selected projects that deliver end-to-end applications to primary users use monitoring, integration, and interaction functionalities to facilitate self-service and communication and, in the process, provide data, alarms, and assistance.

5.2. Mapping to Selected RAM

The CREATE-IoT 3D RAM focuses on standardizing the architecture description of a single system, unlike IDS RAM, which addresses mechanisms for establishing trust while exchanging data in an ecosystem comprising of different cloud-based systems. CREATE-IoT 3D RAM was designed to ensure a standard view of diverse IoT systems layers and provide additional viewpoints to the various stakeholders. Since the IoT can be considered one of the significant technological backbones of eHealth and AAL systems, it seems appropriate to analyze the architectures of our large-scale pilots concerning this model, building upon the previous state of the art. For these reasons, in addition to being the most voted option (as mentioned in Section 4.2), the CREATE-IoT 3D RAM was selected as a framework for our further analysis.

CREATE-IoT 3D RAM horizontal functional layers are:

• Collaboration and Process layer (People and Business Processes), which focuses on enabling integration with external systems;
• Application Layer (Dynamic Applications), which focuses on visualizing the device data;
• Service Layer (Services), which focuses on the development environment, service orchestration, advanced analytics;
• Abstraction Layer (Data Abstraction), which focuses on event and action management, basic data normalization, reformatting, and cleaning;
• Storage Layer (Data Accumulation), which focuses on storing data in databases;
• Processing Layer (Edge Computing), which focuses on device management and data processing at the edge;
• Network Communication Layer (Connectivity), which focuses on network connectivity and bridges from IoT gateways to Cloud;
• Physical Layer (Devices), which focuses on operating systems, drivers, sensors, and actuators.

The following table (

Table 4. Projects’ architectures mapped to CREATE-IoT 3D RAM layers.

CREATE-IoT RAM Layer	Activage Layer	Adlife Layer	Gatekeeper Layer	Pharaon Layer	Shapes Layer	Sphinx Layer	Smart Bear Layer
Collaboration and Process layer	Market place, ACTIVAGE Ecosystem, IPSM Alignments	Change Management for Personalised Integrated Care Delivery	GK Layer 5 COMPOSE	Collaboration and Process layer	Market place	A knowledge repository, Common Cybersecurity Toolkit	Continuous cross-pilot collaboration with other projects (Smart4Health, HoloBalance). Management of personalized interventions for six comorbidities.
Application Layer	Data Layer	Personalized Care Plan Management and Patient Empowerment Platforms	GK Layer 4 SHARE	Application layer	Front-end Applications	Cybersecurity oriented applications	Web-based front-end for visualizing data and performing data analytics. Mobile application for visualizing participant’s personal data and interventions.
Service Layer	Service Layer: Developer tools, Data analytics, Deployer tools	Pilot Design and Implementation	GK Layer 3 FIND	Service layer	Service layer	Service layer	Identification, Authorization, Privacy Management, Data Analytics, Intervention Generation, Data Visualization.
Abstraction Layer	Semantic Interoperability layer: AHA ont., AIOTES Core Ont.	Semantic Interoperability Suite	GK Layer 3 FIND	Platform layer	SYMBIOTE, FHIR	STIX 2.1	Common data model: FHIR; Semantic annotation (SNOMED-CT)
Storage Layer	Data Lake, Metadata storage server	FHIR Repository (onFHIR.io)	GK Layer 2 ACCESS	Platform layer	Data Lake, Metadata storage server	-	FHIR compatible repository
Processing Layer	Deployment manager, SIL-GW	Clinical Decision Support Services	GK Layer 2 ACCESS	Platform layer	Platform layer	Platform layer, Anonymization	Mobile phone processing; Home-hub server processing. Cloud-servers processing. Pseudo-anonymization.
Network Communication Layer	SIL Bridges	Technical Interoperability Suite	GK Networked Things	Device and Network Layer	Device and Network Layer	Device and Network Layer	Device and Network Layer
Physical Layer	IoT Platform/device Layer	Medical Devices	GK Networked Things	Device and Network Layer	Device and Network Layer	Device and Network Layer	Device and Network Layer

) summarizes the mapping of LSPs to CREATE-IoT 3D RAM layers to the corresponding layers of the selected projects.

CREATE-IoT 3D RAM cross-cutting functions are:

• Identifiability—enables the system to uniquely identify an entity such as device, application, service, communication interface or session, location, or data instance.
• Trustworthiness—reflects confidence and faith in the system. It builds on the reputation of the vendor organization, level of adherence to regulation, law, ethical principle, standards, and essential requirements related to cybersecurity, safety, reliability, and privacy.
• Security—of devices, communication networks, data, and the system is of pivotal importance. The security dimensions (such as access control, authentication, non-repudiation, data confidentiality, communication security, data integrity, availability, and privacy) must be applied to provide end-to-end security.
• Safety—as the ability of a system not to harm persons or objects is strictly regulated and prescribed by standards.
• Privacy—is about enabling the chosen information to stay private. Privacy concerns, such as profiling, localization, tracking, secure data transmission, self-adaptive dynamic data management, and confidentiality have to be adequately addressed. Here, one of the requirements is to follow the European General Data Protection Regulation (GDPR).
• Connectivity—is about connecting the system, composing different devices, and a communication network(s).
• Resilience—is about system reaction and recovery from damaging effects or states caused by power shortage, cyberattack, hardware, or software malfunction.
• Reliability—is about delivering the service following the defined performance specification for a specified period.

The following table (

Table 5. Projects’ architectures addressing CREATE-IoT 3D RAM cross-cutting functions.

CREATE-IoT RAM Cross-Cutting Functions	Activage	Adlife	Gatekeeper	Pharaon	Shapes	Sphinx	Smart Bear
Identifiability	++	0	0	++	+	+	+
Trustworthiness	+	++	++	+	++	++	+
Security	++	++	++	++	++	++	++
Safety	+	+	+	+	++	++	--
Privacy	++	0	++	++	++	++	++
Connectivity	++	+	++	++	++	++	+
Resilience	0	-	++	0	+	+	+
Reliability	0	++	++	+	++	++	+

-- unimportant, - of little importance, 0 moderately important, + important, ++ very important.

) summarizes the perceived level of importance of CREATE-IoT 3D RAM cross-cutting functions for each LSP, implying the amount of focus and effort invested, using a five-point Likert scale [52] as a psychometric tool.

The following figure (Figure 8) summarizes the CREATE-IoT RAM cross-cutting functions-based classification of projects from Table 5.

The cross-cutting function that is very important for all observed projects is security, followed by connectivity and privacy, which are very important for six out of seven projects.

The CREATE-IoT 3D RAM system properties are:

• Interoperability—is the ability of a system to exchange information with other systems.
• Composability—is a design principle promoting the reusability and composition of new services by reusing the existing ones.
• Scalability—is the ability of a system to manage increasing demand, such as new devices or data throughput.
• Integrability—as a degree of effectiveness, the system can be integrated with other systems developed separately.
• Manageability—is a system’s ability to be maintained to perform and run smoothly (thus facilitating reliability, availability, and serviceability).
• Dependability—is the ability to avoid or quickly fix service failures.
• Availability—as a degree to which the system is operational and accessible.
• Intelligence—in terms of Artificial Intelligence (AI) features, functions, and behaviors.

The following table (

Table 6. Projects’ architectures addressing CREATE-IoT 3D RAM properties.

CREATE-IoT RAM Property	Activage	Adlife	Gatekeeper	Pharaon	Shapes	Sphinx	Smart Bear
Interoperability	++	++	++	++	++	++	+
Composability	+	++	++	++	+	++	-
Scalability	++	+	++	+	++	++	+
Integrability	+	++	+	+	+	++	-
Manageability	+	+	+	+	+	+	+
Dependability	+	+	0	0	0	0	+
Availability	+	0	++	+	+	+	+
Intelligence	++	++	++	++	++	++	++

- of little importance, 0 moderately important, + important, ++ very important.

) summarizes the perceived level of importance of CREATE-IoT 3D RAM properties for each LSP, implying the amount of focus and effort invested.

The following figure (Figure 9) summarizes the CREATE-IoT RAM properties-based classification of projects from Table 6.

Intelligence is the most important property for all observed projects (which follows the global AI trends), followed by interoperability. No single solution or platform can fulfill all the needs and be selected widely as a single standard offering. Composability and integrability follow the high importance of interoperability. Availability and manageability are recognized as important, which is understandable considering pilot projects generally use well-established and mature input solutions to deliver services to a wide range of geographically dispersed users.

5.3. Discussion

Cicirelli et al. [3] identified the four main steps in developing an AAL system: sensor selection, data acquisition, recognition of elementary actions, and evaluations of complex behaviors. We also observe that most AAL solutions include sensing, transmitting, storing, and using data. Sensors acquire data from the user or user’s environment. That data is then (in raw or preprocessed format) transmitted to a central point (typically Cloud), where it is used to provide service (typically delivered via applications). AAL applications often overlap and can sometimes be categorized as smart home, eHealth, fitness, lifestyle, gamification, videoconference, and localization.

In most cases, the AAL solutions focus on indoor habitats and home environments, while those that focus on outdoor are rarer. Indoor ones typically include environment monitoring, fall detection, social isolation prevention, reminders, games, activity recognition, while outdoor ones typically include wearables and location monitoring and geofencing. Within the AAL program, the typical distinction of applications is labeling them @on the move, @home, or @work. Here, the environment is summarized as standard indoor or outdoor. The indoor environment is more targeted by selected projects, which is also true for AAL projects in general as they often include IoT and AmI (Ambient Intelligence) technologies. The most common types of assistance offered are communication support, reminders, monitoring, and guidance to address health and communication issues. Five properties, namely health, communication, GUI, indoor, and participant, are covered by all projects and can be considered universal in our overview.

The use of horizontal layers and established architecture views help in the process of understanding the architectures. Simultaneously, different terminology for the same things introduces confusion. Architectures, especially architectures in the same domain, describe systems that perform many of the same activities. Depending on the effort invested in them, they can be very elaborate or very focused. Every project is carried out within a specific context, so each architecture is influenced by different decisions with other priorities. The same architectural decision can be excellent in one context while devastating in another. Architectural choices, and resulting architectures, are most often made considering functional and non-functional requirements, while technical and business constraints are in most cases only implicit. Since such restrictions set the boundaries of what the project is supposed to do and what it is not supposed to do, it would be beneficial to accompany the architectural descriptions with additional contextual information to understand them better. Quality attributes such as performance, interoperability, reliability, maintainability, usability, and security are often vaguely described, unlike, e.g., functional requirements, where much more details are given. Furthermore, some trade-offs, e.g., between maximum cybersecurity and usability, are also necessary to balance the system.

Since AAL and eHealth projects have to cover various functionalities, some capabilities are better when deployed. Some struggle to deliver wanted results, especially when put under peak performance and 24/7 availability regimes. It is not easy from the architecture description to objectively assess how much effort was invested into specific capabilities. The performance reports, especially ones that observe more extended running platforms and services, are missing, since projects end before collecting them. The architecture as such is often not a deciding factor when measuring the success of some projects. Usually, this has to do with the execution in terms of implementation, deployment, appropriate openness, interoperability, community size, licenses, good documentation, regular maintenance, and upgrades. For more in-depth analysis of the projects, when they come to their final stages, it would be interesting to compare attributes such as performance (in terms of latency and throughput), usability (in terms of learnability and user interaction design), and security (in terms of confidentiality, integrity, availability), and analyze how they compare.

Some future directions in solutions for smart and healthy living could also be recognized in the analyzed projects, and they include the application of IoT, AI (Artificial Intelligence), robotics, and blockchain. With the increasing amount of high-quality data, AI-enabled solutions can significantly improve many aspects of older persons’ lives. AAL and healthcare solutions follow the technology megatrends and increasingly apply ML (Machine Learning) and AI techniques to deliver a new generation of self-adaptive and intelligent applications. In such an attempt, all AI-related (sub)fields such as ML, NLP (Natural Language Processing), robotics, computer vision, expert systems, and speech processing are being utilized to deliver new capabilities and a better customer experience. Solutions for trustworthy sharing of data between different parties and data providers, such as blockchain, are also increasingly being used in AAL projects, e.g., Nehra et al. [53] recently presented energy-efficient blockchain for AAL applications’ critically ill patients.

6. Conclusions

We have performed an analysis of our seven selected projects for smart and healthy living based on three established healthcare and AAL taxonomies, which we identified by a literature survey. Taxonomies-based analysis showed the most common type of user interface is still GUI, followed by robots and digital assistants. With the advancements in robotics, robot companions are becoming more popular as interfaces for older people living alone. Communication is one of the identified core activities among all projects followed by different care types, including integrated care, remote care, and self-care. For monitoring, the primary data sources are still older people and their environment where sensors, in most cases, non-medically certified, passively collect the data. All observed projects apply wearable and on-the-body sensors and focus on the indoor (typically smart home) environments. All projects deliver end-to-end applications, which usually provide data, alarms, and assistance.

The limitation of the PHS and AAL-related taxonomies classification is the focus on the only end (older) user-facing components. In aging populations, multiple comorbidities pose an increasing risk in managing a person’s health, which requires a growing number of healthcare professionals who need to collaborate to deliver holistic care plans for patients satisfying their health needs. Clinician-facing functions and systems should be included as an extension to current AAL taxonomies to represent better and acknowledge the healthcare professionals’ involvement in the delivery of AAL systems for the care of older patients.

Communicating the architecture to its stakeholders is one of the critical factors of their successful evaluation. Since there is no broad consensus on how the architectures should be described and which information should be accompanying them, it becomes very challenging to detect the primary goal of the architecture and the pain-point(s) it aims to address. Similarly, there is no standard way of describing architectures in the AAL and eHealth domain, and there are no widely accepted reference architectures. There are some more popular approaches and solutions, but they often have to be observed from different standpoints. For example, some architectures and approaches are more appealing and appropriate for researchers and technology enthusiasts, while others are more appealing for companies. However, when mapping projects to the chosen RAM, we found that the layers and cross-cutting functions outlined by the CREATE-IoT 3D RAM model were sufficiently broad enough to comprehensively describe the architecture within each selected project. For this reason, we propose that CREATE-IoT 3D RAM as a standard RAM for future digital healthcare and AAL projects.

Apart from delivering their main functionalities, AAL and eHealth solutions must appropriately address and overcome many ethical, legal, and organizational challenges. Obtaining proper consent from the potential users, ethical approvals from the national bodies before designing and delivering reliable, safe, secure, privacy-aware, GDPR-compliant, easy to use, and valuable solutions are necessary, although often very time-consuming. Since every country has its laws and procedures, deploying solutions in multiple countries is not straightforward and includes somewhat different strategies. Proper ecosystems are highly desirable to ensure sustainability and lower entry barriers.

7. Future Directions

As mentioned in the previous Section 5.3, future directions for smart and healthy living solutions include the application of IoT, AI, ML, NLP, robotics, computer vision, expert systems, speech processing, robotics, and blockchain, which are all being utilized to deliver new capabilities and a better customer experience. With technology proliferation, lower initial and operational costs, better availability, easier maintenance, more generous offering, adequate legal regulations, better user experience, and higher benefit awareness should gradually lead to higher adoption and visible impact on the national levels.

Following the trends of privacy awareness, we see a specific need to apply privacy-enhancing techniques in smart and healthy living solutions. One reason is that more and more data is being collected from the end-users while disproportionate privacy measures are being applied. Older users have to be better acquainted with how their data is being processed and how they can customize or redraw their consent at any given time. In this sense, we see techniques such as differential privacy (DP) [54], secure multiparty computation (SMPC) [55], and federated learning (FL) [56] being more and more adopted. We are planning to further explore this also in our currently running projects. Cybersecurity is also a big part of future work, as it can highly and even irreversibly influence the trust of the end-users if not appropriately addressed.

More and more evident is that numerous specialists and subject-matter experts will have to work together in highly multidisciplinary teams to deliver valuable and usable solutions for older people. With the proper support from national and regional governments, regulatory frameworks, and appropriate ecosystems, the delivery of smart and healthy living solutions should enter a new era where more synergy is to be achieved. Synergies between governmental institutions, user organizations, and industry players to realize suitable ecosystems are crucial and should be nurtured in every way.