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

: 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 deﬁning 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 identiﬁed 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 identiﬁed CREATE-IoT 3D RAM as the most appropriate option. We present a classiﬁcation 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.


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 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. 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 Electronics 2021, 10, 1616 4 of 25 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 implementationspecific, 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. 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 implementationspecific, 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.
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 IoTbased 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 RAM RA (1) RA (N) CA (11) CA (1K) CA (N1) CA (NL) System (11) System (1K) System (N1) System (NL) Figure 1. Relation between the Reference Architecture Model (RAM), the Reference Architecture (RA), the Concrete Architecture (CA), and the system.
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 IoTbased 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 stan-dard 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.

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.

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 selfmanagement 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 largescale 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. 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.

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 Electronics 2021, 10, 1616 7 of 25 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 patientcentered 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.

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.

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.

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.

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 crossborder 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.

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 Electronics 2021, 10, 1616 9 of 25 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.

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.

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 Sections 4.1.1-4.1.3.

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:
Activities and participation (including general tasks, communication, mobility, selfcare, domestic life), indicating tasks that the user cannot manage; 3. Support (including participants, caregiver, vicinity), to imply who may benefit from the system; 4.
Source of data for sensor (including participant, object, environment, time), to mean the kind of data that triggers the action; 5.
The target of actuator's action (including participant, caregiver, object, data store), to imply identity or object a device's outcome is executed; 6.
Environment (including indoors and outdoors), to indicate where the pervasive system is used; 7.
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).

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).

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).

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).

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).

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-

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).

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-

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 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 Sections 2.2 and 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.

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.

PHS Taxonomy-Based Classification
The following table (Table 1) summarizes the classification of projects based on the

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.

PHS Taxonomy-Based Classification
The following table (Table 1) 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. 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. 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.  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.

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).

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). 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.

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). 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 taxonomybased 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. Electronics 2021, 10, x FOR PEER REVIEW 16 of 25 Figure 7. Data quality-oriented AAL taxonomy-based classification summary.
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.

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. CRE-ATE-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) summarizes the mapping of LSPs to CREATE-IoT 3D RAM layers to the corresponding layers of the selected projects.

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) summarizes the mapping of LSPs to CREATE-IoT 3D RAM layers to the corresponding layers of the selected projects. • 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, nonrepudiation, 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) 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 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) summarizes the perceived level of importance of CRE-ATE-IoT 3D RAM properties for each LSP, implying the amount of focus and effort invested.  The following table (Table 6) 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.
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.

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

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.

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.

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 privacyenhancing 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.