D6 - SMART BEAR Architecture

CALL H2020-SC1-FA-DTS-2018-2020 Trusted digital solutions and Cybersecurity in Health and Care

TOPIC DT-TDS-01-2019 Smart and healthy living at home

SMART BEAR "Smart Big Data Platform to Offer Evidence-based Personalised

Support for Healthy and Independent Living at Home"

D6 - SMART BEAR Architecture

Due date of deliverable: 31/05/2020 Actual submission date: 30/06/2020

Grant agreement number: 857172 Lead contractor: CNR Start date of project: 01/09/2019 Duration: 48 months

Project funded by the European Commission within the EU Framework Programme for Research and Innovation HORIZON 2020

Dissemination Level

PU = Public, fully open, e.g. web

CO = Confidential, restricted under conditions set out in Model Grant Agreement CI = Classified, information as referred to in Commission Decision 2001/844/EC.

Int = Internal Working Document

D6 – SMART BEAR Architecture

The work described in this document has been conducted within the project SMART BEAR, started in September 2019. This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 857172

Copyright by the SMART BEAR Consortium.

D2.2 (D6) – SMART BEAR Architecture

Editor Kloukinas, Christos (CITY)

Contributors Basdekis, Ioannis (STS); Bucur, Anca (PHILIPS); Cavero, Carlos (ATOS);

Giotis, Giorgos (ATC); Kalatzis, Fanis (UoI); Kouris, Ioannis (ICCS); Maggesi, Jonatan (UMIL); Pozdniakov, Konstantin (CITY)

Reviewers Petrescu, Claudiu (ITSS); Zanini, Alberto (LISPA)


Executive Summary

This deliverable describes the architectural design of the SMART BEAR platform. It includes an overview of the different main sub-components of the platform, that is: (1) the SMART BEAR Cloud infrastructure, where the participant data are eventually stored and analysed using Big Data algorithms according to workflows defined by the clinical researchers; (2) the SMART BEAR HomeHub, co-ordinating home devices and data collection; (3) the SMART BEAR mobile phone app that allows participants to interact with their devices and the functionalities required by the different clinical studies; (4) the links to external health record systems. The main part of the deliverable deals with identifying the general components, their utility in the platform, the main dataflow interactions, and security/deployment design decisions. The appendices provide detailed specifications of each of these, following the general structure/order of the main document. Apart from the persons listed as contributors, other colleagues have also provided valuable input to the discussions held to form the content of this deliverable, listed below in alphabetical order: Bellandi, Valerio (UMIL); Blouin, Myriam (STREAMVISION); Gallo, Luigi (CNR); Haaz, Stephan (CATEL); Iliadou, Eleftheria (NKUA); Lopes, Carlos (Uninova) Pateraki, Maria (FORTH); Petrescu, Claudiu (ITSS); Railhet, Stephane (STREAMVISION); Zanini, Alberto (ARIA); Zissis, George (ATC).


Contents

Executive Summary ......................................................................................................................................3

List of tables .....................................................................................................................................................7

List of figures ...................................................................................................................................................8

1 Introduction ....................................................................................................................................... 10 1.1 Overview ........................................................................................................................................................... 10 1.2 Goals of the deliverable .............................................................................................................................. 10

2 Overall Architecture ........................................................................................................................ 12 2.1 Overview ........................................................................................................................................................... 12 2.2 Architecture Diagram .................................................................................................................................. 12 2.3 Components Description ............................................................................................................................ 13

3 Components Specifications ........................................................................................................... 14 3.1 Smart Home ..................................................................................................................................................... 14

3.1.1 Purpose .................................................................................................................................................. 14 3.1.2 General Overview .............................................................................................................................. 14

3.2 Participant Devices ....................................................................................................................................... 17 3.2.1 Purpose .................................................................................................................................................. 17

3.3 Data Repository .............................................................................................................................................. 18 3.3.1 Purpose .................................................................................................................................................. 18

3.4 Mobile Application ........................................................................................................................................ 19 3.4.1 Purpose .................................................................................................................................................. 19

3.5 Enabling Sensors ........................................................................................................................................... 19 3.5.1 Purpose .................................................................................................................................................. 19

3.6 Big Data Analytics Engine .......................................................................................................................... 20 3.6.1 Purpose .................................................................................................................................................. 20

3.7 EHR Systems .................................................................................................................................................... 21 3.7.1 Purpose .................................................................................................................................................. 21

3.8 Decision Support System – DSS ............................................................................................................... 21 1.1.1 Purpose .................................................................................................................................................. 21

3.9 Dashboard ........................................................................................................................................................ 22 3.9.1 Purpose .................................................................................................................................................. 22

4 Interaction Specifications .............................................................................................................. 23 4.1 Examples of typical interactions ............................................................................................................. 23

5 Platform Security .............................................................................................................................. 26 5.1 Overview ........................................................................................................................................................... 26

6 Deployment Infrastructure ........................................................................................................... 28

7 Requirements .................................................................................................................................... 29


8 Concluding Remarks ....................................................................................................................... 38

9 References .......................................................................................................................................... 39

Appendices .................................................................................................................................................... 40

10 Appendix 1 – Smart Home ............................................................................................................. 41 10.1 Functional Capabilities and Interfaces ................................................................................................. 41

10.1.1 Bindings Functionality ..................................................................................................................... 41 10.1.1.1 Things Functionality ......................................................................................................................... 44 10.1.1.2 Items Functionality ........................................................................................................................... 49 10.1.1.3 Rules Functionality ........................................................................................................................... 54 10.1.2 Accessing HomeHub ......................................................................................................................... 56 10.1.3 Related Requirements ..................................................................................................................... 57

11 Appendix 2 – Participant Devices ............................................................................................... 62 11.1 Functional Capabilities and Interfaces ..................................................................................... 62 11.1.1 Hearing Aids (HAs) ............................................................................................................................ 62 11.1.2 Smart Watch ......................................................................................................................................... 64 11.1.3 Smart Pillbox ........................................................................................................................................ 67 11.1.4 Smart Blood Pressure Tracker ..................................................................................................... 67 11.1.5 Smart Weight Scale ........................................................................................................................... 68 11.1.6 Smart Glucometer .............................................................................................................................. 69 11.2 Related Requirements ..................................................................................................................... 69

12 Appendix 3 – Data Repository ...................................................................................................... 71 12.1 Functional Capabilities and Interfaces ..................................................................................... 71 12.2 Related Requirements ..................................................................................................................... 85 12.3 Application programming interfaces ........................................................................................ 86

13 Appendix 4 – Mobile Application ................................................................................................ 89 13.1 Functional Capabilities and Interfaces ..................................................................................... 89 13.2 Related Requirements .................................................................................................................. 101

14 Appendix 5 – Enabling Sensors ................................................................................................. 107 14.1 Functional Capabilities and Interfaces .................................................................................. 107 14.1.1 Smart Weather Station (Indoor and Outdoor) ................................................................... 107 14.1.2 GPS sensors ....................................................................................................................................... 110 14.1.3 Accelerometer .................................................................................................................................. 111 14.1.4 Other motion sensors .................................................................................................................... 111 14.1.5 Light sensors ..................................................................................................................................... 112 14.1.6 Send data to repository (via mobile device or home hub) ........................................... 113 14.2 Related Requirements .................................................................................................................. 113

15 Appendix 6 – Big Data Analytics Engine ................................................................................ 116 15.1 Functional Capabilities ................................................................................................................. 116 15.2 Related Requirements .................................................................................................................. 130


16 Appendix 7 – EHR Systems ......................................................................................................... 132 16.1 Functional Capabilities ................................................................................................................. 132 16.2 Related Requirements .................................................................................................................. 135

17 Appendix 8 – Decision Support System – DSS ...................................................................... 137 17.1 Functional Capabilities ................................................................................................................. 137

18 Appendix 9 – Dashboard ............................................................................................................. 139 18.1 Functional Capabilities ................................................................................................................. 139 18.2 Related Requirements .................................................................................................................. 142

19 Appendix 10 – Interaction Specifications ............................................................................. 144 19.1 Smart home ................................................................................................................................................... 144 19.2 BDA ................................................................................................................................................................... 150 19.3 Data repository ............................................................................................................................................ 154 19.4 Dashboard ..................................................................................................................................................... 155 19.5 Analysis scheduler ..................................................................................................................................... 157 19.6 Model explanation ...................................................................................................................................... 157 19.7 Devices and sensors .................................................................................................................................. 158 19.8 Mobile application...................................................................................................................................... 159 19.9 EHR ................................................................................................................................................................... 161

20 Appendix 11 – Platform Security ............................................................................................. 162 20.1 Security Threats .......................................................................................................................................... 162

20.1.1 Users with enhanced administration rights ........................................................................ 162 20.1.2 System Components ...................................................................................................................... 162 20.1.3 Cryptography .................................................................................................................................... 162 20.1.4 External Attacks .............................................................................................................................. 163 20.1.5 Secure Storage Devices ................................................................................................................. 164

20.2 Security Assumptions, Objectives, and Key Capabilities ........................................................... 164 20.2.1 Security Assumptions ................................................................................................................... 164 20.2.2 Security Objectives ......................................................................................................................... 165 20.2.2.1 SMART BEAR Security Objectives............................................................................................ 165 20.2.3 Security Capabilities Summary ................................................................................................. 166

20.3 Security Manager One .............................................................................................................................. 166 20.3.1 Purpose ............................................................................................................................................... 166 20.3.2 Functional Capabilities and Interfaces .................................................................................. 166

21 Appendix 12 – Deployment infrastructure .......................................................................... 168


List of tables

Table 1 openHAB functional issues and actions ............................................................................................... 56


List of figures

Figure 1 Architecture .................................................................................................................................................... 12 Figure 2 The architecture of the HomeHub ........................................................................................................ 15 Figure 3 Smart Scale to Repository dataflow: Vendor app/cloud ............................................................. 23 Figure 4 Smart Scale to Repository dataflow: SB@App and HomeHub. ................................................. 23 Figure 5 Smart Scale to Repository dataflow: SB@App, no HomeHub. .................................................. 24 Figure 6 DSS to Diet App recommendation use case ...................................................................................... 24 Figure 7 Indoor Tracker data collection and analysis use case .................................................................. 25 Figure 8 The Binding Management UI ................................................................................................................... 42 Figure 9 Configure a Binding ..................................................................................................................................... 42 Figure 10 The things management UI ................................................................................................................... 45 Figure 11 Managing a specific thing from the PaperUI .................................................................................. 47 Figure 12 The Channel Linking with an Item ..................................................................................................... 47 Figure 13 The things REST API operations ......................................................................................................... 48 Figure 14 The management UI of items ................................................................................................................ 50 Figure 15 The main PaperUI that diplays the items ........................................................................................ 51 Figure 16 The item - channel linking ..................................................................................................................... 52 Figure 17 The functions that are provided by the items REST API .......................................................... 53 Figure 18 The rules REST API ................................................................................................................................... 55 Figure 19 Data Scientist Workflow Management ......................................................................................... 140 Figure 20 Workflow Creation ................................................................................................................................ 141 Figure 21 System Administration ......................................................................................................................... 142 Figure 22 HomeHub to Item interaction ........................................................................................................... 144 Figure 23 HomeHub to Bluetooth device interaction .................................................................................. 145 Figure 24 HomeHub to Mobile interaction ....................................................................................................... 146 Figure 25 HomeHub to Service interaction ...................................................................................................... 146 Figure 26 HomeHub to External cloud interaction ....................................................................................... 147 Figure 27 HomeHub to WiFi device interaction ............................................................................................. 147 Figure 28 HomeHub to Sensor interaction ....................................................................................................... 148 Figure 29 HomeHub to Binding interaction ..................................................................................................... 148 Figure 30 HomeHub to Thing interaction ......................................................................................................... 149 Figure 31 HomeHub to Repository interaction .............................................................................................. 149 Figure 32 Transformation tool to BDA core execution interaction ....................................................... 150 Figure 33 Transformation tool to BDA core interaction ............................................................................ 150 Figure 34 Transformation tool to BDA core interaction ............................................................................ 151 Figure 35 Transformation tool to BDA core interaction ............................................................................ 151 Figure 36 Transformation tool to BDA core interaction ............................................................................ 152 Figure 37 Transformation tool to BDA core interaction ............................................................................ 152 Figure 38 Transformation tool to BDA core interaction ............................................................................ 153 Figure 39 Schedule and execution of the workflow ..................................................................................... 153 Figure 40 Data repository to Dashboard, BDA and Model Explanation interaction ...................... 154


Figure 41 Data repository to Dashboard, BDA and Analysis scheduler interaction ...................... 154 Figure 42 Data repository to Dashboard and Mobile interaction .......................................................... 154 Figure 43 Data repository to Dashboard and Transformation tool interaction............................... 155 Figure 44 Dashboard to Repository and Transformation tool interaction ........................................ 155 Figure 45 Dashboard to Repository, Model Explanation and Analysis Scheduler interaction .. 155 Figure 46 Dashboard to Repository, Transformation and Validation tools interaction ............... 156 Figure 47 Dashboard to Repository and Authentication Server interaction ..................................... 156 Figure 48 Analysis Scheduler to Repository and Transformation tool interaction ........................ 157 Figure 49 Model Explanation to Repository and Dashboard interaction ........................................... 157 Figure 50 Smart Watch and Smart Pillbox to Repository and Mobile interaction .......................... 158 Figure 51 Hearing Aid and Blood Pressure Tracker to Repository and Mobile interaction ....... 158 Figure 52 Smart Weight Scale and Smart Glucometer to Repository interaction ........................... 159 Figure 53 Mobile to Bluetooth and WiFi devices interaction ................................................................... 159 Figure 54 Mobile to Repository, Bluetooth devices and Authenticated user interaction ............ 160 Figure 55 Mobile Repository interaction .......................................................................................................... 160 Figure 56 Mobile to Repository and Authentication Server interaction ............................................. 161 Figure 57 EHR to Repository interaction .......................................................................................................... 161


1 Introduction

1.1 Overview The primary goal of the SMART BEAR project is to develop an integrated platform gathering numerous health-related data flows, with further analysis of day by day participant activities. The continuous data collection and processing will provide evidence-based personalized interventions for the healthy and independent living of the participants. Data flows are acquired by the interactions with external devices and systems, such as hospital medical systems, smart house sensors, mobile phones, smartwatches and a variety of different devices. Additionally, big data analytics capabilities are a part of the SMART BEAR platform functionality through its Big Data Analytics (BDA) engine subsystem. It is supported by a data repository for securely storing big amounts of data. The collected data are used for the evidence based decision making, as well as the participant’s health monitoring. The SMART BEAR architecture mainly consists of the following components: smart home sensors, mobile devices, data repository, BDA engine, external medical systems, a decision support system, and a user dashboard. The next section will cover these components in detail.

1.2 Goals of the deliverable This deliverable determines the SMART BEAR architecture in order to:

• define the functionality constraints and capabilities to drive the platform development;

• identify the security layer of the architecture to ensure GDPR compliance;

• specify the interfaces and structural relations between different components;

• identify the component interactions with each other as part of the platform;

• define the dependencies between components based on their interfaces;

• identify data flows, access control, data storage. In order to meet those goals, the document contains a description of the following:

• The general representation of the architecture of the SMART BEAR project.

• The detailed component descriptions: component functionality and access interfaces.

• The security requirements related to the GDPR rules implementation. The architecture is based on the requirements identified at earlier stages of the project. Secure interactions and privacy of data were considered as high importance during the design stage. It needs to be noted that although the architecture was thoroughly designed and all aspects of the system are based on the most reasonable current industrial-strength solutions, there is an inevitable possibility of future architecture changes. Such changes might appear during the realization phase and will be kept minimal, based on the project needs. These cases will be documented and justified. The structure of deliverable is the following – after the executive summary of the deliverable (“Executive summary”), section 1 gives the general overview, introduces the goal and structure of the document (“Introduction”). Then section 2 describes the general SMART BEAR architecture (“Overall architecture”) and section 3 introduces the components (“Components specifications”), with more


information about their exact interfaces, etc. in the appendices. Some examples of data flows for implementing a few representative clinical use case scenarios are presented in section 4, with more detailed interaction specification diagrams presented in Appendix 10. Section 5 introduces the security principles of the SMART BEAR platform, with further detailed information in Appendix 11. Finally, section 6 provides information regarding the deployment infrastructure, section 7 describes the requirements addressed during the design activity, and section 8 concludes the deliverable. Appendices 1-12 provide all the detailed information that the sub-system and component developers will need.


2 Overall Architecture

2.1 Overview This section describes the overall SMART BEAR architecture. It illustrates all high-level components of the system, which will be introduced in the next section in more detail. Components are mainly interconnected via REST API interfaces, to facilitate integration. The following “Architecture diagram” subsection contains the diagram and general architecture description.

Figure 1 Architecture

2.2 Architecture Diagram Figure 1 shows the overall SMART BEAR architecture. As can be seen, there are three main systems – the Mobile Phone App (SB@App), the SMART BEAR HomeHub (HomeHub), and the SMART BEAR Cloud (SB@Cloud). The other elements are external to the core system and play a supporting role in data exchanging with external devices. The core components of the SB@Cloud are the Dashboard (3.9), which also contains the Analysis Workflow Validation tool, the BDA engine (3.6), which also contains the Analysis Workflow Transformation tool, the Data Repository (3.3), and the Decision Support System (DSS) (3.8), which also contains the Analysis Scheduler and the Model Explanation tools. The main purpose of these components is to accumulate, store and analyze the data gathered from different sources. The user interface is presented by the Dashboard, which allows to input data, set up Analysis Workflow data models, validate these models (through the Analysis Workflow Validation tool), register/unregister external data sources, execute data analytics workflows, and retrieve/visualize executions results. The user of the system is considered to be a data scientist or health worker performing data analysis. The Dashboard interacts with other components via REST interfaces. The REST layer is also used for retrieving, saving or analyzing the data stored in the database. It provides the interfaces not only for the Dashboard but for external (to SB@Cloud)


components like External Healthcare Record (EHR) systems (3.7), the HomeHub (3.1) or the mobile phone app (3.4). Additionally, REST services provide interaction capabilities to the BDA engine and Data Repository as part of the SB@Cloud. Thus, the user can load a data analytics workflow with multiple tasks to the BDA engine for analysis. According to the input configuration of the analytics workflow, the BDA engine will use the Analysis Workflow Transformation tool to translate the submitted workflow into lower-level analysis algorithms and retrieve all data needed for the requested algorithms directly from the Data Repository. The BDA engine supports different statistical analysis and Machine Learning algorithms. The Data Repository holds all information retrieved from devices, sensors, mobile phones, EHR systems, and the BDA engine itself (e.g., intermediate/final results of analysis workflows), providing a distributed and reliable way to store all this data. SB@Cloud interacts with the HomeHub and the SB@App, as well as with EHR systems and external device vendor clouds, through REST interfaces. The HomeHub component is the subsystem accumulating inputs from house-bound external sensors such as house temperature sensors, house light sensors, etc. All information is preprocessed and sent to the Data Repository via REST services. The data reaching the SB@Cloud is already anonymized before transmission and stored in the Data Repository in compliance with GDPR rules. Interactions between components, as well as, authentication at the Dashboard are secured by the Secure Manager One component, while user account information is held in the Secure User Data Storage component; SMART BEAR’s security design is further discussed in section 5 (on p. 26) and Appendix 11 (on p. 162).

2.3 Components Description The next section introduces the different components identified here, to present readers with a fuller picture of their utility and how they fit the overall architecture. Their detailed interfaces are specified in the respective appendices (1-9). Cross-cutting, security-related components are described in section 5 and Appendix 11 (on p. 162).


3 Components Specifications

3.1 Smart Home The Smart Home HomeHub component of the SMART BEAR project is based on the openHAB platform 1. The openHAB is an open source implementation of the Eclipse Smart Home Framework, which aims to provide a common approach for solving problems related to protocol connectivity, security and software development in the world of Internet of Things, including common smart home and smart city solutions.

3.1.1 Purpose The openHAB technology forming the core of HomeHub is an open source, Java-based software system that is installed in the home and allows interaction with the sensors and devices (Things) that are located inside the home. Its capabilities will be extended, as required, so that openHAB can also interact with any software system, service or hardware that can be located even outside of the home. The openHAB is a server software (or better a framework) that exposes its own API, functionality and programmable environment (using Eclipse and Java SDKs 8, 11). openHAB is also called openHAB Server as it is executed as a server software using Jetty Application Server of an Apache Karaf (https://karaf.apache.org/) deployment runtime (for this reason the openHAB is also called openHAB runtime). An important note is that openHAB is built using OSGi (Open Service Gateway Initiative) which is a Java specification that allows the modular development of software components and modules, with many applications in the Smart IoT world as it allows independent vendors to glue their hardware devices with modular controller code. This is of particular importance when things from different vendors need to be integrated in a single solution and one of the main reasons for which the openHAB framework was chosen as the HomeHub solution. The openHAB operates as a smart integrator while it seamlessly unifies all the devices of interest in a single platform and provides a common device-agnostic operational interface for controlling the hosted things.

3.1.2 General Overview The architecture of the HomeHub solution and its interactions with the SB ecosystem is depicted in the following figure with the main functional components.

1 https://www.openhab.org/

https://karaf.apache.org/

https://www.openhab.org/


Figure 2 The architecture of the HomeHub

The house-bound devices of SMART BEAR are integrated with openHAB through the utilization and development of specific functional extensions that are called “add-ons” in the openHAB framework. The “add-ons” are subcategorized to:

a. Bindings: Software bundles that are based on the OSGi reference model and allow the connection to external devices and services. External devices and services are called Things.

b. System Integrations: Software components that integrate openHAB with external systems like Google Calendar.


c. Actions: They are specific openHAB software functions that allow scripts and rules (according to openHAB manual rules are used for automating processes 2) to be executed so as to interact with the Things. An example of an action is to publish a message on an MQTT topic; “MQTT is an ISO standard (ISO/IEC 20922) lightweight, a publish-subscribe network protocol that transports messages between devices” [8] .

d. Data Persistence: It allows openHAB to save/store device data (and time-series data) to a storage framework including Java Persistence API (JPA), JDBC, MySQL, MongoDB etc.

e. Data Transformations: As the name implies, they are used to transform data values being exchanged at the Smart Home environment.

The main add-on that is developed and primarily used in any openHAB installation is the “binding” component. An openHAB “Binding” is a software component that is developed with the open source Eclipse SmartHome Framework 3 using a specific software design pattern in Java that is based on the OSGi reference model and is implemented as a bundle. In the world of openHAB the binding is a main software component that allows integration of services (e.g., MQTT, REST Service, Software platform), protocols (e.g., SMTP) or devices (e.g., smart scale, blood pressure monitor, hearing aid). The following list presents the main openHAB framework terms:

• Things are both physical devices and software services that are added to the home automation. “Things tell openHAB which physical entities (devices, web services, information sources, etc.) are to be managed by the system”. “Things do not have to be physical devices; they can also represent a web service or any other manageable source of information and functionality.” The functions of things are made available through channels.

• Binding is the most important component that makes things available and operational to the system.

• Items is a virtual layer that has a state and represents the functionality used by the application’s automation logic 4.

• Rules provide the main services of executing actions, calling services, making mathematical calculations. Rules are programmable and they are a sub-category of “actions”.

• Actions are used to execute functions or commands, send data to services and devices. Scripts and rules use actions 5.

According to deliverable D2.1, the HomeHub will support the user components that were described as MyHeart, MyBalance, MyMood, MyDiary, MyDiet, MyHearing, MyMemory, MyMedication, MySmartbear, MyAppointments. In order to accomplish the functionality, the openHAB will support all these components by utilizing openHAB actions through specific openHAB rules. In order to support the requirements, the openHAB must be connected to the user and home devices through appropriate bindings. The key architectural point is that the same actions and rules can be

2 https://www.openhab.org/docs/configuration/rules-dsl.html 3 https://www.eclipse.org/smarthome/ 4 Items details and definition: https://www.openhab.org/docs/configuration/items.html 5 Actions details and definitions: https://www.openhab.org/docs/configuration/actions.html

https://www.openhab.org/docs/configuration/rules-dsl.html

https://www.eclipse.org/smarthome/

https://www.openhab.org/docs/configuration/items.html

https://www.openhab.org/docs/configuration/actions.html


used to control hardware devices of the same type from different vendors so the binding that connect the things @Home is transparent to the items, rules and actions that are implemented in a virtual layer. The functional operations that need to be supported by the HomeHub can become simpler openHAB bindings:

a) The user bindings, such as for a weather station. b) The home bindings for smart light sensors/bulbs, sensors on the fridge and/or in the kitchen,

sensors in the bathroom, sensors on the door, home temperature, home humidity, etc. The design and functional specifications of bindings are defined according to the structure of an OSGi bundle and based on the development pattern of the Eclipse Smart Home architecture 6. Appendix 1, on p. 41, provides in detail how one can develop bindings, actions, and rules.

3.2 Participant Devices

3.2.1 Purpose Participants will be using various types of devices (depending on their comorbidities and medical advice). This section considers the devices that are not tethered to their house:

• a set of hearing aids (HAids), to track HAid usage (section 11.1.1 in Appendix 2);

• a Smart Watch, used as heart rate and physical activity tracker (section 11.1.2 in Appendix 2);

• a Smart Pillbox, to track missed medication (section 11.1.3 in Appendix 2);

• a Smart Blood Pressure tracker (section 11.1.4 in Appendix 2);

• a Smart Weight scale, to track weight/impedance (section 11.1.5 in Appendix 2);

• A Smart Glucometer, to track blood glucose levels (section 11.1.6 in Appendix 2).

The SB@App mobile application acts as an integration backbone between these devices and the SB@Cloud backend. Among other responsibilities, the SB mobile application handles the data ingestion workflows resulting from the monitoring of metrics of interest (e.g., HAid usage data, heart rate bpm, etc.), where these devices do not come with a device vendor cloud. In general terms, the devices either provide an SDK or a programming interface (API), which allows them to directly consume the data flows generated by their usage, or they upload their data on their own vendor cloud, to be consumed from there. The SB@App will support both models, depending on what is available for a specific device. It is expected that the vendor clouds are hosted on EU region servers, where region refers to a physical location where the data centers reside. In case of vendor clouds hosted outside the EU region, a clear statement about GDPR compliance should be included. With regards to the data collection from a vendor cloud, two possible modes are available:

6 https://www.eclipse.org/smarthome/documentation/development/bindings/how-to.html

https://www.eclipse.org/smarthome/documentation/development/bindings/how-to.html


• Push mode: the vendor cloud supports publishing the collected data to an event-emitting component (e.g., a message broker or an object repository), from which data can be collected to the SB@Cloud Data Repository component.

• Pull mode: the vendor cloud only allows polling some REST endpoints to export collected data.

Appendix 2, on p. 62, provides detailed interfaces for collecting data from these devices.

3.3 Data Repository The SB@Cloud Data Repository refers to the data storage entities into which data will be partitioned for analytical or reporting purposes.

3.3.1 Purpose The SB@Cloud Data Repository will be responsible for storing the data that will be transmitted by the HomeHub, the SB@App, and the external vendor clouds. The data will be stored in the repository in either raw or aggregated format. The data will be available to the Decision Support System and the Big Data Analytics Engine, to process them with the analytics and decision models, to suggest and make decisions on personalized interventions. Data in the Data Repository will be primarily saved in a NoSQL document database (e.g., MongoDB), to allow the support of data provided from different vendors and collected/analysed by different modules. The Data Repository will also support the storage of structured and semantically enriched data like ontology model datatypes (e.g., SPARQL, GraphDB). A relational database will be used for the role-based access control of the platform. The system access to users will be based on their role in the platform (e.g., participant, doctor, admin, researcher, etc.) and the users will be grouped into roles based on common responsibilities and system access needs. Using the role-based access on the system, the access rights will be systematic and repeatable. Compared to a NoSQL database, the relational database will allow a much easier way to audit user rights and correct any issues identified. Role-based access will implement the requirements that will be described in WP5, ensuring the security and data privacy of the platform. An Access Control List (ACL) will be defined for each user group to a specific object or group of objects, along with the permitted actions on each object. According to the requirements (deliverable D2.1), data from sensors will be structured or unstructured. Most data will be time-dependent (e.g., measurements from sensors, made at regular time intervals), and the processing of that data will also consider time intervals as the main selection and processing criteria (e.g., average use over 1 day, 1 week, etc.). This means that the repository will be mainly dealing with so-called time-series data. The potential volume of data received and stored in the repository is very high (there will be thousands of sensors, each sending several data points at potentially small time intervals), which along with the requirement for supporting unstructured data leads to our decision to employ a NoSQL database engine as the Data Repository’s main storage solution. Appendix 3, on p. 71, provides detailed interfaces for the other components to interact with the Data Repository, as well as, an initial overview of the data models that will be supported by it, as needed to guide the architectural design – the repository and data structure will be further described in more detail in D4.2.


3.4 Mobile Application

3.4.1 Purpose The mobile application, SB@App, is considered a key component in the data acquisition layer of the SMART BEAR architecture as it acts as a gateway for data flowing from the various participant devices, mostly the Bluetooth enabled devices but also for the rest as an alternative ingestion workflow whenever the HomeHub component has connectivity issues. It will be responsible to send all the aforementioned data flows to the main platform but also receive informational material and results from the data analysis having taken place by the platform. The functionality of the SB@App also includes notifications/alerts management, reporting on participant’s interaction with the SB platform, calendar-based appointment setup with clinicians, questionnaire and test surveys (auditory training, cognitive etc.) visualised in a gamified way and controlling/remote finetuning of HAids. All interactions between a SB participant and the SB platform, through the SB@App, are profile-based. The SB@App interface is designed to be user-friendly and contains functionalities that span the six medical comorbidities that SMART BEAR targets, namely MyHeart, MyBalance, MyMood, MyDiary, MyDiet, MyHearing, MyMemory, MyMedication, MySmartBear and MyAppointments. Based on each participant’s profile, specific icons are activated allowing him/her to also receive profile-based notifications/alerts for the comorbidities he/she participates in. The process of publishing the SMART BEAR mobile application consists of two steps:

• the application gets prepared for release; • the application is released to the SMART BEAR users.

The process of preparing the SB application involves several tasks like configuring, building, signing and testing a release version and finally updating the application resources for release. The option to release the SB@App through a private server will be adequately tested to make sure that future release versions of the application can be automatically delivered to the SB users. This implies that we host the release-ready APK file on a private server and provide a download link to the SB users through a push notification mechanism. When the SB users browse the download link from their Android-powered devices, the file gets downloaded and automatically starts installing itself on the device. However, if technical difficulties arise with regard to the automatic update of the SB@App releases, the option of publishing the app through the GooglePlay marketplace is considered as an alternative (this implies that a Google account is available for each SB user). It should be also noted that the SB@App complies to a single account model of delivery. In other words, each mobile device that the SB@App is installed on is uniquely correlated to a single SB user account. The mobile application will be, among other responsibilities, the main point of interaction between participants and the SMART BEAR platform. Thus, a large set of functional capabilities have been derived from the functional requirements defined in D2.1 – these are presented in Appendix 4, on p. 89.

3.5 Enabling Sensors

3.5.1 Purpose Relevant data will be collected in SMART BEAR in multiple ways: through a wide range of devices, through the mobile phone, and through heterogeneous sensors. The role of the sensors in the SB architecture is to collect data elements both from the participant (sleep tracker, activity tracker, location) and from the participant’s environment (e.g. temperature, humidity, lights) and to provide


this information to the SB data repository via the Home Hub, the SB mobile app SB@App or the SB vendor cloud. As described by the project scenarios, data from a variety of sensors will be collected, stored, and analyzed. These may comprise motion capture sensors; wearable sensors (smart bracelet, sensorised soles); smarthome sensors for temperature, humidity, lights; sound sensor; sensors on the door and fridge (in the kitchen); and sensors integrated in medical devices which are described in section 3.2. Based on their participation in the project scenarios, each participant will use a subset of the sensors described in this section. The main types of sensors and their use are as follows:

• The outdoor weather sensors will provide information on temperature, humidity, extreme weather conditions to support the participants in their (daily) outdoor activities.

• The indoor humidity and temperature sensors will indicate potentially unfavourable conditions in home that are unhealthy and need to be addressed.

• GPs-equipped soles and GPS trackers will provide information on activity level, location, daily routines.

• The accelerometer will provide fall detection information and help detect when the user is at rest.

• Sensors on doors (bathroom, entrance, fridge) will provide information on activity and patterns of behaviour (including going outdoor or being sedentary, eating too little or potentially overeating, lack of sleep).

• The light sensors will provide information on the lighting level in the home. The selected sensors will have wireless connectivity (WiFi or Bluetooth) and provide an API or SDK to facilitate data extraction. Appendix 5, on p. 107, provides further details on the interfaces of these and the types of data they can provide.

3.6 Big Data Analytics Engine

3.6.1 Purpose The Big Data Analytics Engine (in the following, BDA), is the component that is responsible of the execution of analytics workflows on the data collected by the SMART BEAR platform. The execution of these workflows is based on the definition of Data Analytic Workflows (DAWs). A DAW is an ordered sequence of Data Analytic Tasks (or simply Tasks) of the following types:

• Data Processing task: focused principally on data preparation, like data source selection for feature reduction, data cleaning, or data type transformation.

• Statistical Analysis task: focused on performing statistical analysis on a given dataset, like ANOVA, Breusch-Pagan Test, etc.

• Data Mining task: focused on more elaborated analysis (e.g., clustering, machine learning), involving supervised or unsupervised algorithms like Random Forest, K-means, etc.

A DAW is expressed as a detailed procedural workflow and requires to be translated into an executable form for the BDA Engine (Executable DAW, or EDAW). This transformation is carried out by the Analysis Transformation Tool (ATT). The ATT receives a JSON representation of the workflows


expressed as a DAW and then it creates the proper EDAW workflow that can be executed on the Big Data Analytics platform. Appendix 6, on p. 116, provides the detailed specifications of the BDA component interfaces used for describing workflow tasks, managing workflows, and transforming them.

3.7 EHR Systems SMART BEAR aims at connecting with EHR systems to exchange clinical information with the Data Repository. Hospitals and GP EHR systems do not always allow to connect directly to their Hospital Information or EHR Systems (e.g., using APIs), since regional or national laws prevent some pilots from providing this kind of access. In these cases, information can be extracted using other methods as detailed in the later sub-section and in Appendix 7, on p. 132.

3.7.1 Purpose Relevant information for SMART BEAR scope is stored in the EHR system of each country. Clinical information usually lacks standardization since providers are still using proprietary formats. Thus, it is crucial to formalize the data using common information models such as HL7. To achieve semantic interoperability between systems, the codification is basically annotating the concepts with well-known medical terminologies such as SNOMED. Legal restrictions prevent pulling or pushing directly the data from certain EHR systems; therefore, data processing must be done at hospital or GP premises using indirect methods such as exporting files. Appendix 7 contains methods for extracting/importing data from/to EHR systems of the type used in the project pilots.

3.8 Decision Support System – DSS

1.1.1 Purpose The SMART BEAR Decision Support System will realise the process of deciding upon the adoption and execution of interventions driven by the decision models specified in Task 4.2. Each participant’s profile will be considered, taking into account their medical profile, preferences profile, historical evidence and analysis of the effects arising from the adoption of interventions. SMART BEAR DSS will model human reasoning and the decision-making process, so that measurable facts from the participants, will be processed and interventions will be suggested evaluating different decisions, in order to select the most robust and cost-effective. The DSS will process the aggregated and raw data stored in the data repository and will evaluate the results of the BDA. Machine Learning, AI principles and methods will be incorporated, to analyse and provide reasoning on the personalized interventions. The DSS will also permit the periodic re-computation of analysis workflows through its Analysis Scheduler sub-component as shown in Figure 1, allowing clinical researchers to track the evolution of metrics and the effect of interventions. It will also provide an aid to them through the Model Explanation sub-component, so that they can better understand the results of Machine Learning methods on the data collected and help them establish how interventions should be adapted so as to improve the living conditions of the participants. Appendix 8, on p. 137, contains the detailed specifications of the interfaces that need to be implemented for the DSS component.


3.9 Dashboard

3.9.1 Purpose The Dashboard of the platform is the component that is responsible of the interaction between the administrator and clinical users and the services in the backend, just like SB@App is the interface for the pilot participants. This component is responsible for connecting all the API’s behind the scene, so as to provide administration capabilities of the platform, monitoring of the status of the devices managed by the platform, creation and management of the workflows and the possibility to visualize the results in a meaningful way. In order to provide these functionalities, the Dashboard behaves differently based on the role assigned to the user by the Role-Based Access Control (RBAC) capabilities of the Authorization component. As an example, a user that is an admin could explore the data inside the repository or manage the devices in the platform, while a clinical user could only manage the workflows or create new workflows, validate them using the Analysis Workflow Validation component, and visualize the data based on the configuration chosen. The detailed data flows supported by the Dashboard are in Appendix 9, on p. 139.


4 Interaction Specifications

Having introduced the components that form the architecture of the SMART BEAR platform, we present here a few interaction specification diagrams that are representative of the main data flows required to support the applications that pilot participants will be using. These are taken from the requirements deliverable D2.1 and relate to functionalities of the SB@App mobile app as described there – in particular to the MyDiet functionality on p. 68, and the MyMood functionality described on p. 65 (the different functionalities of SB@App can be seen on Figure 20, p. 62, of D2.1). Further detailed interaction specification diagrams for each of the identified architectural components are in Appendix 10, on p. 144.

4.1 Examples of typical interactions

Figure 3 Smart Scale to Repository dataflow: Vendor app/cloud

Figure 4 Smart Scale to Repository dataflow: SB@App and HomeHub.

In order for the MyDiet functionality to be able to suggest appropriate dietary advice to a participant, we need first to collect their current weight. This is done through the smart scale device, as shown in Figure 3 In this instance, the smart scale device has a vendor-provided mobile phone app that allows the participant to use it and measure their weight. The vendor-provided app will then transfer the new measurement to the vendor’s cloud, from where the Data Repository of SB@Cloud will retrieve these measurements periodically. Figure 4 shows an alternative flow, when the device (smart scale) does not have a vendor-provided mobile app or vendor cloud. In this instance, the SB@App collects the device’s data and transmits them to the HomeHub, which in turn transmits them to SB@Cloud’d Repository.


Finally, in Figure 5, we show the alternative flow of Figure 4, when the HomeHub is not available – in this case, SB@App anonymises its own data and connects directly to SB@Cloud to transfer it to the repository.

Figure 5 Smart Scale to Repository dataflow: SB@App, no HomeHub.

Figure 6 DSS to Diet App recommendation use case

Figure 6 shows how the measurements stored in the Data Repository of SB@Cloud are taken into account by the DSS component (along with other data, such as particular dietary requirements from the participant’s profile, etc.), to form a set of recommended recipes for that specific participant. This set is then transmitted to the SB@App app running on the participant’s mobile phone, which shows them to the participant and notes the choice they have made through its MyDiet functionality. Finally, the participant’s choice is transmitted back to the Data Repository, to allow further analysis of appropriate recipes and the uptake of the MyDiet functionality’s suggestions.


Figure 7 Indoor Tracker data collection and analysis use case

Figure 7 shows how information is collected from the indoor tracker devices by the participant’s HomeHub in order to support the MyMood functionality of the SB@App. Unlike the smart scale device used in the MyDiet functionality, the indoor trackers (used to monitor the participant’s level of mobility inside their home) do not come with a vendor-provided usage app or a vendor-supported cloud. Indeed, a participant would only interact with these trackers implicitly and not have to perform explicit actions using a particular UI (User Interface). The indoor trackers will interact with the (openHAB server running inside the) HomeHub, to send it data relating to the participant’s indoor movements. The HomeHub is then responsible for transmitting these data to SB@Cloud’s Data Repository, from which the DSS component will be reading them to decide (along with other data contained in the participant profile) whether to send a notification to the MyMood functionality on the participant’s mobile phone SB@App to move more/engage in some physical activity.


5 Platform Security

5.1 Overview The design of the security and privacy capabilities required for the SMART BEAR platform (SB@Cloud) has been based on an analysis of potential threats. To ensure that due consideration has been given to this critical aspect of the SB@Cloud design, our threat analysis has been based on threats identified as part of Common Criteria protection profiles for all the key types of components that constitute part of the SB@Cloud platform (namely the Dashboard, the REST layer, the BDA engine, the Data Repository, the DSS the Big data analytic platform), as well as the Mobile SB@App and the HomeHub (assuming that external vendor cloud enforces agreements to maintain security standards, policies, and best practices). To cover these components, we have considered the following Common Criteria protection profiles and threat analysis documents:

• The protection profile for mobile applications produced by U.S. Government [1]

• The protection profile for database management systems produced by U.S. Government [2]

• The protection profile for secure (physical) storage devices produced by Standard Protection Profile [5]

• The protection profile for general software applications produced by National Information Assurance Partnership [4]

• The threat and risk analysis for big data analytic platforms produced by ENISA [5]

• The Privacy and data protection in mobile applications produced by ENISA [6] In the following, we provide an overview specification of the identified threats and the security objectives that we have adopted and aim to address in the SMART BEAR platform, as well as the security objectives which arise from them and the security capabilities that are needed to address them. For the purposes of this document, we have assumed the following definitions for threats, security objectives and capabilities:

• Threat – A threat is an adverse action performed by a threat agent on an asset of the system that is to be secured. Threat agents are human actors, software or hardware components, which cause the occurrence of a threat. A threat agent can be described by aspects such as expertise, resources, opportunity, and motivation.

• Security objective – A security objective defines a desired security state of the system. It represents the primary goal of the security policy which is identified by the system requirements. The security objectives are defined based on the threats described above.

• Security capability – A security capability represents functions which the system is required to achieve. It identifies the solution based on the threats and security objectives. The functions illustrate an implementation of the security objectives.

This specification for testing the correctness and effectiveness of the security of the platform once it is fully implemented in a process following a Common Criteria like approach, constitutes the initial version of potential threats and associated preventing/assessing mechanisms to be performed via a security audit using the SPHYNX Security Assessment Tool. SMART BEAR will advocate a continuous security and privacy assurance approach. This will involve developing probes for continuous monitoring and dynamic testing of the platform to generate evidence that can support the continuous assessment of the security and privacy provisions of the platform, making it transparent,


audible and trustworthy. This initial analysis will guide the efforts of developing the mechanisms supporting the privacy-aware and secure by design operation of the platform. This specification will be later redefined as the implementation of the security features of the SMART BEAR platform will progress. Further details on the security analysis and design for SMART BEAR are in the Appendix 11 on p. 162, including details on its components (e.g., the Security Manager One).


6 Deployment Infrastructure

Cloud deployment technologies are used to place workloads into a cloud computing environment. They provide the foundation to facilitate execution of applications and services. Such technologies range from bare metal to serverless, and enable organizations to realize the benefits of cloud computing. In SMART BEAR, we will examine the following three technology options for cloud deployment: bare metal, VMs, and containers. The selection will be done case by case, evaluating the best solution for each component of the platform. For instance, if the execution of DSS ML algorithms requires a GPU-accelerated Deep Neural Network library, it will be implemented in bare metal, whereas, for modules that are part of microservice-based modules and are stateless and immutable, containers will be used (such as Docker and Kubernetes). Further details on the deployment infrastructure are provided in Appendix 12, on p. 168.


7 Requirements

This section collates all the requirements from D2.1 that have been addressed during the design activity documented in the D2.2 deliverable.

# Description Operation Smart home

R101 Selected devices must provide an SDK library Install Binding. R102 Selected devices must provide an API for interfacing Configure Binding. R103 The prototype gateway device should be light, cheap, easily

replaceable. Deployment of the openHAB server. Application of the openHAB technology provides interoperable and easily maintenance technology.

R104 The prototype gateway is fault tolerant. Components for monitoring the state of the gateway are available

openHAB allows efficient integrations to monitor the HomeHub.

R105 A local data storage must be available to support the scheduling of data transfer operations when the connectivity is on.

Add a thing. A thing that supports local persistence is supported and will be installed.

R106 Artificial Intelligence modules must be available locally to support data classification and summarization.

The rules REST API (figure 13). openHAB rules can provide personalized actions from locally processed data.

R107 Support multiple types of Health factors at the same time Install Bindings, Add things, Add items. A thing that is managed from openHAB can support all health sensors and home devices.

R108 The participant is provided with SB@App as a component of HomeHub

openHAB REST API is available to mobile app.

R109 Periodically reports are generated and transmitted to the participant via SB@App

Add Items, Configure Items. openHAB provides data monitoring per item that can be arranged in a report and provided with the REST API.

R110 Automatic alerts for dangerous events can be notified to the participant via SB@App

Rules REST API. The openHAB rules can trigger rules to perform automated actions for alerting each participant. Automatic alerts are emails and push notifications from the openHAB’s internal actions.

R111 SB@App communicates with the HomeHub Use openHAB REST API R112 SB@App communicates with each HomeHub single device By using the openHAB REST API. R113 SB@App collect data from HomeHub only openHAB Persistence will be enabled

per installation being also accessible by the openHAB REST API. “openHAB can store data over time; this is known as persistence. The data may be retrieved at a later time, for example to restore your system after startup, or to prepare graphs for display on a UI.”

R114 SB@App collects data from HomeHub single device Configure Items and access openHAB persistence.

R115 SB@App identifies problems in the communication with the HomeHub only

Add rules for alerting communication connect/disconnect of the openHAB server through openHAB.


R116 SB@App identifies problems in the communication with the HomeHub single device

Add rules for alerting communication connect/disconnect of each device through the openHAB.

R117 Users can rate the HomeHub services openHAB persistence can store the results through the REST API.

R118 Users can visualize the history of ratings on the HomeHub openHAB can provide stored results from the persistence storage through the REST API.

R119 Multiple Care Plans can be supported by the SB@App Add Rules. Specific personalized rules will be installed according to the care plans.

R120 SMART BEAR Care Plans can be configured by selecting the goals to be achieved

Configure Rules. Specific personalized rules will be configured according to the care plans.

R121 Care Plans can be updated remotely by updating the SB@App Configure Rules through the openHAB REST API. .

R122 SMART BEAR platform should allow clinicians to select a different device, based on participant’s preferences and record this selection

Install Bindings. (For any device a binding can be installed or developed to allow the communication with any sensor’s API)

R123 SMART BEAR platform and SB@App should be able to visualize HomeHub device usage

Add Items. Appropriate Items are providing the visual information layer of things.

R124 SB@App support multiple Clinical Tests openHAB REST API allows clinicians to create data collections for Clinical Tests.

R125 SB@App should be able to connect to the user profile in the social networks

openHAB REST API can support such communication by allowing item data to be shared.

R126 SB@App should be able to store the user consent action for accessing personal data

SB@App will support authentication and access control for secure consent approval.

R127 HomeHub should be able to record different data streams Install Bindings, Install Things. It is supported bi-directional per sensors and home device.

R128 SB@App shows the data stored in the HomeHub View Items and GET items OPERATIONS of the REST API.

R129 HomeHub should be able to analyze the participant activity in the social networks

GET /persistence/items from the openHAB REST API

R130 HomeHub should be able to analyze devices’ data and upload them to SMART BEAR repository in an ad hoc basis in case of an event

PUT /persistence/items/{itemname} from the openHAB REST API

R131 SB@App should notify SMART BEAR users to fill-in a questionnaire

Add Rules with the specific notification type.

R132 SB@App should be able to extract, in an application-friendly standard format (i.e. txt, csv, xls, etc.), personal data

GET /persistence/items from the openHAB REST API in JSON format and apply transformers.

R133 Data upload timing from HomeHub can be configured by clinicians

Configure Bindings, Configure Things

R134 HomeHub should be able to register a new device Install Binding, Install Thing R135 HomeHub should be able to register/update/cancel a new

user The openHAB does not support user accounts but the SB@App will manage the user and its home automation at each home installation.

R136 HomeHub should be able to assign a role to the user The user of the openHAB installation will be managed by the SB@App.


R137 HomeHub should be able to assign access right to roles Using the SB@App. R138 SB@App should provide up-to-date communications from

clinicians Operation PUT new/updated RULES with the REST API.

R139 The performance of HomeHub and its components should not degrade with an increase in the number of the users or/and the available datasets.

Each home will have its own installation, and this depends on the selected home hardware. openHAB server is running on Apache Karaf thus implying a degree of scalable performance due to the selected technology.

R140 HomeHub and its components should be designed to meet high usability

Selection of the open-source openHAB technology provides strong evidence of high usability by being applied to previous EU-funded projects and supporting a large development community.

R141 HomeHub has to support at least the Android OS Yes, it supports both iOS and Android. Furthermore, any operating systems that can effectively execute Java (JDK) code can host the HomeHub server (including low cost Raspberry PI installations).

Participant devices R-ED-3: The smartwatch in connection with the smartphone should

be able to track physical activity and allocate scores to each user hence to allow a gamified approach to physical activity.

collectPhActivityData, evaluateAdherence, pushNotification

R-CVD-6: The mobile app needs to be able to analyse daily exercise goals and encourage participant.


R-ED-5: The mobile app should be able to give to the user tips on exercising based on an individualised profile (dynamically adapted with each recording).


R-CD-17: SMART BEAR mobile app should be able to provide an overview of the latest activity.


R-CVD-4: The mobile app needs to be able to communicate, store, analyse data from the blood pressure recorder.

collectBlPressureData

R-CVD-5: The mobile app needs to be able to communicate, store, analyse data from the smart pillbox.

collectPillboxData

R-BD-19: The Platform must detect via heart rate and accelerometer information and possibly through self-reporting if the user is at rest.

collectHRData, collectAccData

R-BD-22: The Platform is able to report and display to the user on his/her mobile device of the steps he/she has walked.

collectAccData

R-ED-2: The mobile app should be able to support either automatic entry of glucometer readings or manual entry by the participant.

collectGlucoseData

Data repository R207 Initiate data analysis session Start analysis session R208 Administrate (create, update, delete) analysis’ outcomes Create/Update/Delete analysis R209 Notification when analysis is complete Get analysis notification R210 Visualizations of the analysis outcome Get analysis reporting data R211 Support of progressive notifications and save of the

outcomes on data analysis Get analysis progress

R212 Access management features for the analysis outcomes Get analysis outcome R213 Visualize comparative data analysis sessions Get data analysis results R215 Different visualization modes of the recorded data Get recorded data


R216 Collect timestamped data related to an event or configurable period

Store timestamped data

R217 Manage and visualize a detected event log Access to event logs R218 Visualize a list of data types that are collected in the platform Get data types R219 Select from a list of data types Filter data types R220 Record the participant’ responses to various standardized

questionnaires Store questionnaire results

R221 Create record for SMART BEAR device fitting Store fitting data for HAs R224 SMART BEAR platform analyses. outcome measures Get analysis results R225 Associate outcome measures with collected SMART BEAR

device usage data and participants’ feedback Get data associations for devices

R226 Access to questionnaires’ answers Get questionnaire responses R227 Analyze questionnaires’ answers Get analytics for questionnaire

responses R228 Objective recording about SMART BEAR device malfunctions

and related problems of SMART BEAR device users Get malfunctions list for the devices

R229 Analyze issues, concerns and problems with SMART BEAR devices reported by SMART BEAR devices users

Get analytics on the malfunctions of the devices

R230 Register/update/cancel a new user User management R231 Assign a role to the user Role assignment R232 Assign access right to roles Assign access rights to roles R233 Insert a new algorithm Add new data processing algorithm R234 Configure an algorithm (parameters, data sources) Modify algorithm parameters

Mobile Application R-HA-1: The Platform must be able to retrieve HA usage data. collectHAData, storeHAData R-HA-3: The Platform must be able to monitor HA usage data

automatically and check whether usage falls within specified ranges.

collectHAData, storeHAData

R-HA-4: The Platform must be able to produce notifications to the user when their HA usage is outside the specified ranges.

PushNotification

R-HA-5: The Platform must be able to produce follow-up notifications to the user and/or the case manager and/or the formal/informal caregiver within specific periods after the initial notification, depending on the user's HA usage and the ICF/actor's acceptance to receive such notifications.

PushNotification

R-HA-6: The Platform must be able to produce notifications reminding the user to fill in their GHAB questionnaire and do so periodically.

PushNotification

R-HA-30: The Platform must be able to produce periodic notifications for tasks the user must perform (e.g., auditory training).

PushNotification

R-BD-12: The Platform must be able to notify the user via text on the smartphone and vibration on the smartwatch.

PushNotification

R-BD-20: The Platform collects external weather conditions and provides notification to the mobile device in case of possible critical cases (we need to define the critical cases).

PushNotification

R-CD-10: SMART BEAR should be able to send reminders for cognitive training to participants on a periodically basis.

PushNotification

R-CD-22: SMART BEAR should be able to provide suggestions/advises on sleep activity to a participant. ??

PushNotification

R-CD-25: SMART BEAR should provide a notification/alert mechanism which can be triggered by several events/actions/conditions (i.e. participant's medication schedule, participant's goal achievement, home sensor thresholds, etc.) (ie. participant's

PushNotification


medication schedule, participant's goal achievement, home sensor thresholds, weather, etc.)

R-CVD-1: The mobile app needs to be able to send periodic notifications/alerts to the participant based on preset parameters.

PushNotification

R-CVD-2: The mobile app needs to be able to send periodic notifications/alerts to the case manager based on preset parameters.

PushNotification

R-HA-7: The Platform must be able to display an interactive questionnaire.

retrieveQuestionnaire, submitQuestionnaire

R-HA-8: The Platform must be able to keep active the interactive questionnaire while it has not been filled in and its time period has not elapsed.


R-CD-23 SMART BEAR mobile app should be able to provide Closed-ended questionnaire.


R-HA-9: The Platform must be able to calculate GHAB scores. retrieveQuestionnaire, submitQuestionnaire

R-HA-10: The Platform must offer the user of retrieving and visualising their GHAB scores.

retrieveGHABScores

R-HA-11: The Platform must be able to compare (and visualise) historic GHAB scores.

retrieveGHABScores

R-HA-12: The Platform must be able to produce a periodic HA usage report, annotated by brief explanations.

makeReport

R-HA-13: The Platform must be able to notify periodic HA usage reports to (a) the user, (b) audiologists, (c) case managers, subject to their existence and acceptance to receive such notifications/ICF.

makeReport

R-HA-27: The Platform must be able to provide records of HA usage data for different combinations of noise types/levels/duration of exposure.

makeReport

R-HA-32: The Platform must be able to provide feedback on the auditory training to the user and the audiologist.

makeReport

R-CD-11: SMART BEAR should be able to send report of training results and goals to participants on a periodically basis.

makeReport

R-CD-24: SMART BEAR should provide a reporting mechanism that will support reports on participants' data (reports such as participants' answers on questionnaires).

makeReport

R-HA-14: The Platform must be able to book a call with the audiologist using the MyAppointments app, following the user's request.

scheduleAppointment, confirmAppointment

R-HA-16: The Platform must be able to allow the user to book an appointment with their audiologist for the issues registered by the user.


R-HA-17: The Platform must be able to produce reminders for appointments at specified times.


R-HA-20: The Platform must be able to allow the recipient of an appointment request to confirm and save the appointment.


R-HA-21: The Platform must be able to allow the audiologist to activate the remote fine-tuning function of the HA.

controlHAData

R-HA-29: The Platform must allow the audiologist to view the participant's profile and select an auditory training program.

performAuditTraining

R-HA-33: The Platform must be able to change the auditory training to the next level when certain milestones are reached (discrimination, discrimination in noise).


R-HA-34: The Platform must be able to collect self-reporting on the auditory training by the participant.



R-HA-31: The Platform must be able to collect the results of the auditory training.


R-BD-6: The smartphone supports speech-based interaction and text. Methods need to be reviewed for TTS, cloud-based, android-API solutions.

transcriptSpeech

R-BD-7: The mobile device must be able to display the output of the report and notify and deliver the report to the use case manager.

displayReport

R-BD-15: The App must be able to trigger instructions upon incorrect execution of the exercise.

pushNotification


retrievePhysicalActivity (from SB Data Repository)

R-CD-1: The mobile app must be able to support digital tests (ie MoCA).

PerformAuditTraining

R-CD-7: The mobile app must be able to play personalized verbal messages.

transcriptSpeech

R-CD-12: The mobile app should be able to provide rehabilitation programs to participants.

retrieveRehabiliationProgram (from SB Data Repository)

R-CD-13: The mobile app should provide a list of cognitive exercises that supports multiple level of difficulty.




R-CD-18: SMART BEAR mobile app should provide list with the top training results/scores of all users.

HandleBadges, handleLeaderboard

R-CD-26: The mobile app should provide a calendar for a participant's medication schedule.

retrieveMedicationSchedule

R-CD-32: SMART BEAR Platform notification/alert mechanism can be postponed/disabled.

disableAlerting

R-CD-33: The mobile app should provide a list of cognitive games with different levels of difficulty.

retrieveCognitiveTests (from SB Data Repository)

R-ED-6: The mobile app should follow a gamified approach for increased user motivation.


Enabling sensors R-CD-25 SMART BEAR should provide a notification/alert mechanism

which can be triggered by several events/actions (i.e. participant's medication schedule, participant's goal achievement, home sensor thresholds, etc.)

collectGPSLocation collectAcceleration collectAcceleration collectMotion pushSensorData collectGPSLocation collectOutdoorTemperature. collectOutdoorPressure collectOutdoorHumidity collectRainIntensity pushSensorData deleteSensorData collectGPSLocation pushSensorData collectAcceleration collectMotion pushSensorData startSchedule stopSchedule

R-CD-30 SMART BEAR should provide a notification/alert mechanism which can be triggered by several events/actions (ie.

collectGPSLocation collectAcceleration collectAcceleration


participant's medication schedule, participant's goal achievement, home sensor thresholds, etc.)

collectMotion pushSensorData collectGPSLocation collectOutdoorTemperature. collectOutdoorPressure collectOutdoorHumidity collectRainIntensity pushSensorData deleteSensorData collectGPSLocation pushSensorData collectAcceleration collectMotion pushSensorData startSchedule stopSchedule

R-CD-34 SMART BEAR should provide a notification/alert mechanism which can be triggered by several events/actions/conditions (i.e. participant's medication schedule, participant's goal achievement, home sensor thresholds, weather, etc.)


R-CD-39 SMART BEAR should provide a notification/alert mechanism which can be triggered by several events/actions (ie. participant's medication schedule, participant's goal achievement, home sensor thresholds, etc.)


R-CD-35 SMART BEAR should be able to collect physical activity data collectGPSLocation, collectAcceleration


R-CD-31 SMART BEAR should be able to collect home sensors data collectGPSLocation, collectAcceleration R-CD-16 SMART BEAR should be able to record the physical activity of

a participant collectGPSLocation, collectAcceleration

R-BD-19 The Platform must detect via heart rate and accelerometer information and possibly through self-reporting if the user is at rest.

collectAcceleration, collectMotion

R-BD-21 The steps and heart rate are recorded in the Platform from the devices

pushSensorData

R-CD-3 The Platform should provide a mechanism for collecting data of different types, as well as geo-located data

collectGPSLocation

R-CD-15 SMART BEAR should be able to notify caregivers on participant's location and trajectory

collectGPSLocation

R-BD-20 The Platform collects external weather conditions and provides notification to the mobile device in case of possible critical cases (we need to define the critical cases)

collectOutdoorTemperature. collectOutdoorPressure collectOutdoorHumidity collectRainIntensity

R-CD-29 SMART BEAR should be able to analyse home sensor data pushSensorData deleteSensorData

R-BD-3 The Platform must collect data from sensing devices, aggregate information, perform an analysis of previously collected data to extract progress levels.

pushSensorData deleteSensorData

R-CD-37 SMART BEAR should be able to report physical activity (i.e. steps, km) and cognitive data

collectGPSLocation pushSensorData





R-CD-20 SMART BEAR should be able to record and report sleep activity of a participant

collectAcceleration collectMotion pushSensorData

R-CD-27 SMART BEAR Platform should be able to start recording home devices data on a scheduled basis.

startSchedule stopSchedule

Big Data Analytics Engine R203 SMART BEAR Backend should be able to filter data based on

selected factors ExecuteWorkflow

R204 SMART BEAR Backend should cluster the relevant studies based on potential factors

ExecuteWorkflow

R206 SMART BEAR Backend should be able to support different types of data analysis

CreateWorkflow, CloneWorkflow, AddTask

R207 SMART BEAR Backend should be able to initiate data analysis session

ExecuteWorkflow,StartWorkflow, RerunWorkflow

R208 SMART BEAR Backend should be able to administrate (create, update, delete) data analysis sessions

StopWorkflow,DeleteWorkflow, ModifyWorkflow

R233 SMART BEAR Backend should be able to insert a new data analytics

AddTask

R234 SMART BEAR Backend should be able to configure an algorithm (parameters, data sources)

AddWorkflow

EHR Systems R303 Implement privacy by design All EHR storage/interaction functions

will incorporate security mechanisms of the platform in order to meet privacy requirements with respect to GDPR rules

R304 Implement privacy by default All EHR storage/interaction functions will incorporate security mechanisms of


the platform in order to meet privacy requirements by default

R306 Respect data subject rights All EHR storage/interaction functions will incorporate access control mechanisms of the platform in order to respect data subject rights

R311 Maintain records of processing activities Getters/Setters and storage functions will reliably maintain and process all EHR records

R312 Implement security measures All EHR storage/interaction functions will incorporate security mechanisms of the platform by design

R313 Notify and communicate personal data breaches Notifications mechanism will be available using platform capabilities

R314 Conduct data protection impact assessments Monitoring will be implemented via corresponding functions

R315 Implement pseudonymisation, anonymization or deletion All EHR storage/interaction functions will incorporate security mechanisms of the platform by communication flow architecture; the deletion will be available as well

Dashboard R207 SMART BEAR Backend should be able to initiate data analysis

session Done using BackendRepository API

R208 SMART BEAR Backend should be able to administrate (create, update, delete) data analysis sessions

Done using BackendRepository AP

R210 SMART BEAR Backend should be able to provide visualizations of the analysis outcome

Implemented by the Dashboard Visualization

R211 SMART BEAR Backend should be able to send progressive notifications and save the outcomes accordingly when (25%, 50%, 75% and 100% of the) minimal data set has been analysed.

Done using the BDA API

R212 SMART BEAR Backend should be able to provide features of access management for the analysis outcomes related to a policy formulation process. Outcomes should be able to be accessed by individual stakeholders, who should be able to express their views regarding the analysis outcome

Implemented by the Dashboard UI interface

R213 SMART BEAR Backend should be able to visualize comparative data analysis sessions

Done using the Visualization API

R215 SMART BEAR Backend should be able to provide different visualization modes of the recorded data, both on a single and an aggregated level

Done using BackendRepository API

R218 SMART BEAR Backend should be able to visualize a list of data types that are collected in the platform.


R230 SMART BEAR Backend should be able to register/update/cancel a new user


R231 SMART BEAR Backend should be able to assign a role to the user


R232 SMART BEAR Backend should be able to assign access right to roles


R233 SMART BEAR Backend should be able to insert a new data analytics algorithm


R234 SMART BEAR Backend should be able to configure an algorithm (parameters, data sources)



8 Concluding Remarks

The deliverable described the SMART BEAR platform design and architecture. It represented the interconnections and mutual relations between different platform components such as: SmartHome, Participant devices, Data repository, Mobile application, Enabling sensors, Big data analytical engine, EHR systems, Decision support system and Dashboard. The current version of the deliverable included all interfaces of the components listed above, covering effective functionality of the SMART BEAR infrastructure in order to gather, store and analyse the patients’ information. The document described not only core elements, integrated within the SMART BEAR cloud, but also the ones deployed at the participants’ homes. Additionally, the approach to the security and deployment for the Smart Bear architecture was presented. The deliverable showed the different external and internal dataflows and interactions between external/internal components.


9 References

[1] U. S. Government, “Protection Profile for Mobile Device Fundamentals,” 2014. [2] U. S. Government, “Base Protection Profile for Database Management Systems V 2.07,” 2015. [3] NIAP, “Standard Protection Profile for Enterprise Security Management Access Control Version

2.1,” 2013. [4] National Information Assurance Partnership, “Protection Profile for Application Software V1.2,”

2016. [5] Damiani, E; Ardagna, C. A.; Zavatarelli, F.; Rekleitis, E. (ed.) and Marinos, L, “Big data threat

landscape and good practice guide”, (ENISA 2016). [6] ENISA, “Privacy and data protection in mobile applications”, ver. Jan 29, 2018. [7] CCRA, “Common Criteria for Information Technology Security Evaluation,” Security, no.

September. pp. 1–321, 2012. [8] OASIS, "MQTT 3.1.1 specification". December 10, 2015. http://docs.oasis-

open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html Retrieved April 25, 2020.

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html


Appendices


10 Appendix 1 – Smart Home

10.1 Functional Capabilities and Interfaces

10.1.1 Bindings Functionality Bindings are the main software components that are required to integrate a hardware device, software service or external system to the openHAB. PaperUI is the default User Interface of the openHAB server that allows the management of any installation in a home environment. The main functionality allows to Install, Uninstall, Configure, List a binding.

Operation Description Install a new Binding

Input parameters

Name Type Description

Install User Interface Action Figure 8

Use the Paper UI of the openHAB to INSTALL a new binding.

Output parameters


Install User Interface Action Figure 8

The Paper UI is updated, and the new binding is highlighted.

Operation Description Uninstall a Binding

Input parameters


Uninstall User Interface Action Figure 8

Use the Paper UI of the openHAB to Uninstall a binding.

Output parameters


Uninstall User Interface Action Figure 8

The Paper UI is updated, and the binding is simply displayed.


Figure 8 The Binding Management UI

Operation Description Configure a Binding. Any binding provides things and the parameters of things can be or need to be configured (the polling time of reading a sensor value)

Input parameters


Configure User Interface Action Figure 9

Use the Paper UI of the openHAB to configure a binding.

Output parameters


Save the new configuration User Interface Action Figure 9

A configure binding will update its behaviour during the operation of the things. Typically, when configuring a binding the things are configured.

Figure 9 Configure a Binding


Operation Description List Bindings. All the installed bindings per home application are listed by the Configuration->Bindings menu of the Paper UI.

Input parameters


List Action User Interface Action Use the Paper UI of the openHAB menu to list/view the bindings.

Output parameters


View all Installed Bindings User Interface Action The Paper UI presents all installed bindings. By selecting (clicking) a binding the user proceeds to the configuration.

REST API Binding are also supported by a REST API functions

Operation Description Function GET bindings. The service can be used from external systems to check the availability of installed bindings in a home installation.

Input parameters


GET URL: /rest/bindings The request URL is prefixed with the https protocol path including the "Accept: application/json" header tag.

Output parameters


RESPONSE JSON [{"author": "First Last", "description": "Text that describes the binding", "id": "sensor_Name", "name": "Sensor A Binding",

The response presents all the installed bindings.


"configDescriptionURI": "binding:sensor_name" }]

Operation Description Function GET binding config. The service can be used from external systems to get/read a binding configuration.

Input parameters


GET URL: /rest/bindings/{bindingId}/config

The request URL is prefixed with the https protocol path including the "Accept: application/json" header tag. The {bindingId} is available from the get bindings service request.

Output parameters


RESPONSE JSON { "param1": "value", "param2": “value:, "paramN": "value", }

The response presents the configuration parameters of the specific {bindingId}.

10.1.1.1 Things Functionality A thing is the real physical entity that we need to use in our installation per home. All things are available through the appropriate binding. Having a binding to a Smart Watch can provide us one thing for the GPS, one thing for the accelerometer and one thing for the time/date. An important functionality that is provided by openHAB allows for any installed device to choose the things that can be added for the specific case through the PaperUI. The main functionalities that are supporting the things are the ADD, CONFIGURE, DELETE, LIST things. Things are providing channels that are the usable and meaningful properties of each thing which are exchanging data with the user. It is important to mention that the things are included and provided inside the source code of a binding and it is obvious that each binding is providing its own things (and channels).

Operation Description Add a thing (the virtual layer of managing a physical device)

Input parameters



Add User Interface Action Figure 10

Use the Paper UI of the openHAB to add a thing by selecting an installed binding.

Output parameters



The Paper UI is updated, and the added thing is presented in the list of all enabled things. Things can be enabled or disabled by user actions.

Operation Description Delete a thing

Input parameters


Delete User Interface Action Figure 10

Use the Paper UI of the openHAB to delete an active thing by clicking the trash button.

Output parameters



The Paper UI is updated, and the thing is not displayed.

Figure 10 The things management UI


Operation Description Configure a thing (channels). Things are made available and configured through channels. Channels are providing the links to use a thing in the home while they are the roads that are allowing data to be exchanged between the user and the thing. In Figure 6 are displayed 3 channels for a thing (the thing is a network interface) that they are going to provide the data (properties of the thing) if online_status, last_seen_date and latency_time.

Input parameters



Use the Paper UI of the openHAB to configure the properties of a thing. A thing property can be its IP address, https URL address, or a username and password. In the configuration view of the Paper UI the channels of an active thing are presented automatically in order to allow linking of the channel with an item.

Output parameters



The Paper UI is updated, and the configured thing is enabling its channels. With active channels we can proceed for data exchange between the thing and the user.


Figure 11 Managing a specific thing from the PaperUI

The key point for building the HomeHub functionality is the linking of channels with items (presented in the next section) as displayed in

Figure 12 the channel “Online” is a property that links the data (by making a ping) of the loopback network interface with an item called “network_pingdevice_lap_online”; the item name is very important as it used by the actions of the hub functionalities and provides the feedback to users and systems.

Figure 12 The Channel Linking with an Item

REST API The REST API of the thing’s mechanism is providing 12 REST operations that are available through the openHAB REST API and are displayed in Figure 13. The details of each REST operation are


described with example in the openHAB documentation. In our SB case we present the GET things operation that includes all the useful JSON properties.

Figure 13 The things REST API operations

Operation Description Function GET things. The service can be used from external systems to retrieve and read the functional operations of a thing.

Input parameters


GET URL: /rest/things The request URL is prefixed with the https protocol path including the "Accept: application/json" header tag.

Output parameters


RESPONSE JSON [ { "label": "string", "bridgeUID": "string", "configuration": {}, "properties": {}, "UID": "string", "thingTypeUID": "string",

The response presents all the details of a thing including the channels which are the important data exchange blocks provided by the thing that


"channels": [ { "uid": "string", "id": "string", "channelTypeUID": "string", "itemType": "string", "kind": "string", "label": "string", "description": "string", "defaultTags": [ "string" ], "properties": {}, "configuration": {} } ], "location": "string", "statusInfo": { "status": "UNINITIALIZED", "statusDetail": "NONE", "description": "string" }, "firmwareStatus": { "status": "string", "updatableVersion": "string" }, "editable": false } ]

is included in a binding installation.

10.1.1.2 Items Functionality Items are the software components of the home hub that are final viewable to the end-users through all available UIs (web, mobile, notifications). The definition of an item is a configuration process that is dependent on the capabilities that are provided by the channels of a link. Items are the functional blocks that are used in actions and rules meaning that the end-user, the device, the platform and a software service are communicating through items. The main functionalities that are provided by the items are the ADD, CONFIGURE, DELETE and LIST items.

Operation Description Add an item

Input parameters



Use the Paper UI of the openHAB to add a new item. The item name and the value of an item are the most important properties that are edited from the UI when an item is added or configured


since both will be used in the rules and the action programmable environments.

Output parameters



The Paper UI is updated, and the added item is presented in the list of all enabled items. Items can be edited but active items which are linked with channels cannot be deleted.

Operation Description Delete an item

Input parameters



Use the Paper UI of the openHAB to delete an item. An item can be deleted when it is not linked with a channel.

Output parameters



The Paper UI is updated, and the item is not displayed any more.

Figure 14 The management UI of items


Operation Description Configure an item.

Input parameters



Use the Paper UI of the openHAB to configure the properties of an item. Once an item has been added its name and data type cannot be edited; to change the item name it needs to create a new item.

Output parameters



The Paper UI is updated, and the configured item is displayed.

Items are supporting predefined data types that are used when they are connected with the things through the channels. The data types that are supported by items are: Switch (On/Off), Number, String, DateTime, Dimmer, Location, Image, Color, Contact. The unique name and the data type are the major item parameters that are displayed to the end-user thus allowing the interaction of the user with the thing (connected/supported by a binding). In Figure 15 the main UI of the openHAB installation will display the things (a thing is displayed in its own card) with their active items as these are provided by the current installation. A “DateTime”-type item present date time information from a “device” (hardware or software) and “Switch”-type items presents a blue witch for setting/checking the on/off state of a device. In Figure 11 is presented the process that makes the item live and more specific the linking of a channel with an item. If the item does not exist, it can be created during the linking and automatically linked with the channel of the thing. An item can be turned on/off but the item control is effectively performed through the channel options.

Figure 15 The main PaperUI that diplays the items


Figure 16 The item - channel linking

REST API The items are supported through many functions of an extended REST API that is provided by the openHAB server system. This API is utilized to allow the control of all items from the out world or to inform the environment (house, mobile phone etc) of the end-user about the total operativity of sensors and systems that are installed in its premises. In a similar case as per the things universal REST API, the REST API that is provided by the openHAB system is supporting the functionality to connect with external systems through 14 REST functions, being displayed in Figure 17, that are described with details and examples in the openHAB documentation (the GET (List) all items REST functionality is following the figure).


Figure 17 The functions that are provided by the items REST API

Operation Description Function GET items. The service can be used from external systems to retrieve and read the functional operations of items.

Input parameters


GET URL: /rest/items The request URL is prefixed with the https protocol path including the "Accept: application/json" header tag.

Output parameters


RESPONSE JSON [ { "type": "string", "name": "string", "label": "string", "category": "string", "tags": [

The response presents all the details of an item including the links that are


"string" ], "groupNames": [ "string" ], "link": "string", "state": "string", "transformedState": "string", "stateDescription": { "minimum": 0, "maximum": 0, "step": 0, "pattern": "string", "readOnly": false, "options": [ { "value": "string", "label": "string" } ] }, "commandDescription": { "commandOptions": [ { "command": "string", "label": "string" } ] }, "metadata": {}, "editable": false } ]

connecting each item with a channel.

10.1.1.3 Rules Functionality In the HomeHub architecture the rules are going to play the final operational roles since they are providing the unique software components to support process automation (perform actions to hardware and software systems) when they triggered by predefined decisions (for example turn ON the lights when the door opens, or turn ON the climate-system when a specific SMS arrives to the home installation). The rules are pieces of software code that are created by programmers since they are following its own syntax. All rules are created in specific text files and are placed inside each openHAB installations. An example of a rules is presented next in order to architecturally and functional display that by using simple item statuses any action can be automatically triggered. rule "Loopback Notification ON" when Item network_pingdevice_lap_online changed from OFF to ON then val mailActions = getActions("mail","mail:smtp:HMail") val cv=network_pingdevice_lap_lastseen.state.toString mailActions.sendMail("[email protected]", "Test subject", "OFF ---> ON "+cv+" --- ") end rule "Loopback Notification OFF"


when Item network_pingdevice_lap_online changed from ON to OFF then val mailActions = getActions("mail","mail:smtp:HMail") val cv=network_pingdevice_lap_lastseen.state.toString mailActions.sendMail("[email protected]", "Test subject", "ON ---> OFF "+cv+" --- ") end

The rules are executed per openHAB installation and can be accessed or updated with a REST API. The REST operations that are currently available are presented in the Figure 18.

Figure 18 The rules REST API

According to Figure 18 an external software client platform (web, mobile, console) can efficiently operates the HomeHub by managing the required rules. The details of the openHAB rules engine are providing a new functionality that will be used in HomeHub and it is stated in the latest documentation as “Since openHAB 2.4 another Rule Engine has been added. It works fundamentally different than what you find with our current Rules. It allows Rules to be edited in a graphical fashion and to interact with JSR223 Scripts (Javascript, Jypthon, etc).” (https://www.openhab.org/docs/configuration/rules-ng.html)

https://www.openhab.org/docs/configuration/rules-ng.html

https://www.openhab.org/docs/configuration/rules-ng.html


10.1.2 Accessing HomeHub There are some specific functional specifications and operations that need to be considered for the effective application of the openHAB server to the HomeHub architecture with the appropriate functional action that will be configured for Smart Bear overall case regarding the final HomeHub solution. Table 1 presents the functional issues and the actions that will be applied in the HomeHub case.

No. Functional Operation of the openHAB server (HomeHub). Applied Action

1 openHAB server is installed at the user side. Installation will be done for each home separately.

2 openHAB server does not support authentication so in a specific house all persons that are using the same network can access/interact with the overall installation.

The personalized SB@App that will be authenticated will communicate with the home installation using the openHAB REST API.

3 openHAB server uses HTTP (un-encrypted plain text) access.

The HTTPS will be enabled.

4 openHAB REST API is not authenticated. A user that is using the same network with the openHAB server can access everything by using the REST API without auth.

The REST API will be used only in-house from the user’s SB@App.

5 Access to the openHAB items, rules is supported only inside the network of the installed instance so when outside of the home any connectivity is not supported for the REST API functions.

This is the reason that the openHAB will be controlled only inside the house through the REST API by the SB@App.

6 A custom mobile phone application cannot normally access an openHAB server installation.

The openHAB REST API will be used to provide the functionality of the openHAB from the SB@App.

Table 1 openHAB functional issues and actions

Finally, this is an example to present the access to any HomeHub installation by using the REST API of the openHAB.

Example Scenario (that will be applied in all cases) for retrieving all rules of a home installation. GET Service Request inside home: curl -X GET --header "Accept: application/json" http://localhost:8082/rest/rules


10.1.3 Related Requirements The following tables presents the fulfilment and the handling of the appropriate requirements as they were presented in D2.1.

# Name Role Description Operation

R101 SDK System

Selected devices must provide an SDK library

Install Binding.

R102 API System Selected devices must provide an API for interfacing

Configure Binding.

R103 Gateways System The prototype gateway device should be light, cheap, easily replaceable.

Deployment of the openHAB server.

Application of the openHAB technology provides interoperable and easily maintenance technology.

R104 Monitorable Gateways

System The prototype gateway is fault tolerant. Components for monitoring the state of the gateway are available

The SB@App will allow efficient integration to monitor the HomeHub in the house.

R105 Memory System A local data storage must be available to support the scheduling of data transfer operations when the connectivity is on.

Add a thing.

A thing that supports local persistence is supported and will be installed.

R106 Intelligence System Artificial Intelligence modules must be available locally to support data classification and summarization.

The rules REST API (figure 13).

openHAB rules can provide personalized actions from locally processed data.

R107 Multiple factor detection

System Administrator

Support multiple types of Health factors at the same time

Install Bindings, Add things, Add items.

A thing that is managed from openHAB can support all health sensors and home devices.

R108 Mobile App Participant

The participant is provided with SB@App as a component of HomeHub

openHAB REST API is available to mobile app.

R109 Personal Report

Clinician Periodically reports are generated and transmitted to the participant via SB@App

Add Items, Configure Items.

openHAB provides data monitoring per item that can be arranged in a report and provided with the REST API.

R110

Automatic alerts

Participant

Automatic alerts for dangerous events can be notified to the participant via SB@App

Rules REST API.

The openHAB rules can trigger rules to perform automated actions for alerting each participant.


Automatic alerts are emails and push notifications from the openHAB’s internal actions.

R111 Mobile App communication vs Hub

Data Scientist

Auditor

Mobile app communicates with the HomeHub

Use openHAB REST API

R112 Mobile App communication vs single devices

System Auditor

Mobile app communicates with each HomeHub single device

Use openHAB REST API.

R113 Mobile App data collection vs hub

System Auditor

Mobile app collect data from HomeHub only

openHAB Persistence will be enabled per installation being also accessible by the openHAB REST API.

“openHAB can store data over time; this is known as persistence. The data may be retrieved at a later time, for example to restore your system after startup, or to prepare graphs for display on a UI.”

R114 Mobile App data collection vs single device

System

Auditor

SB@App collects data from HomeHub single device

Configure Items and access openHAB persistence.

R115 Mobile App fault detection vs Hub

System Administrator Auditor

SB@App identifies problems in the communication with the HomeHub only

Add rules for alerting communication connect/disconnect of the openHAB server through the openHAB REST API.

R116 Mobile App fault detection vs single device


Auditor

SB@App identifies problems in the communication with the HomeHub single device

Add rules for alerting communication connect/disconnect of each device through the openHAB REST API.

R117 User ratings

Participant

Users can rate the HomeHub services

openHAB persistence can store the results through the REST API.

R118 Visualize ratings

Participant

Users can visualize the history of ratings on the HomeHub

openHAB can provide stored results from the persistence storage through the REST API.

R119 Care Plans System Administrator

Multiple Care Plans can be supported by the SB@App

Add Rules.

Specific personalized rules will be installed according to the care plans.

R120 Configurability of Care Plans


SMART BEAR Care Plans can be configured by selecting the goals to be achieved

Configure Rules.

Specific personalized rules will be configured according to the care plans.


R121 Care Plans updates


Care Plans can be updated remotely by updating the SB@App

Configure Rules through the openHAB REST API.

R122 Select HomeHub devices

Clinician SMART BEAR platform should allow clinicians to select a different device, based on participant’s preferences and record this selection

Install Bindings.

(For any device a binding can be installed or developed to allow the communication with any sensor’s API)

R123 Visualize HomeHub device usage

Data Scientist

SMART BEAR platform and SB@App should be able to visualize HomeHub device usage

Add Items.

Appropriate Items are providing the visual information layer of things.

R124 Clinical Tests Clinician

SB@App support multiple Clinical Tests

openHAB REST API allows clinicians to create data collections for Clinical Tests.

R125 Mobile app connects to the user profile in the social networks

Clinician SB@App should be able to connect to the user profile in the social networks

openHAB REST API can support such communication by allowing item data to be shared.

R126 Mobile app stores user consent action for accessing personal data


SB@App should be able to store the user consent action for accessing personal data

The SB@App will be able to store the user consent.

R127 SMART BEAR Hub records different data streams

Data Scientist

HomeHub should be able to record different data streams

Install Bindings, Install Things.

It is supported bi-directional per sensors and home device.

R128 Mobile app shows the data stored in the Hub

Data Scientist

SB@App shows the data stored in the HomeHub

View Items and GET items OPERATIONS of the REST API.

R129 Analyze participant activity in the social networks


Auditor

HomeHub should be able to analyze the participant activity in the social networks

GET /persistence/items from the openHAB REST API

R130 HomeHub on demand data upload

Data Scientist Auditor

HomeHub should be able to analyze devices’ data and upload them to SMART BEAR repository in an ad hoc basis in case of an event

PUT /persistence/items/{itemname} from the openHAB REST API


R131 Mobile app proposes questionnaire


SB@App should notify SMART BEAR users to fill-in a questionnaire

Add Rules with the specific notification type.

R132 Mobile app extracts personal data in an application-friendly standard format


SB@App should be able to extract, in an application-friendly standard format (ie. txt, csv, xls, etc.), personal data

GET /persistence/items from the openHAB REST API in JSON format and apply transformers.

R133 Data upload timing


Data upload timing from HomeHub can be configured by clinicians

Configure Bindings, Configure Things

R134 Register a new device


HomeHub should be able to register a new device

Install Binding, Install Thing

R135 Register/update/cancel a new user


HomeHub should be able to register/update/cancel a new user

The SB@App will provide the user operations.

R136 Assign a role to the user


HomeHub should be able to assign a role to the user

The SB@App will provide the role operations

R137 Assign access right to roles


HomeHub should be able to assign access right to roles

The SB@App will provide the role access rights.

R138 Mobile app provides up-to-date communications from clinicians

Clinician Participant Auditor

SB@App should provide up-to-date communications from clinicians

Operation PUT new/updated RULES with the REST API.

R139 Scalability System

The performance of HomeHub and its components should not degrade with an increase in the number of the users or/and the available datasets.

Each home will have its own installation, and this depends on the selected home hardware.

openHAB server is running on Apache Karaf thus implying a degree of scalable performance due to the selected technology.

R140 Usability System HomeHub and its components should be designed to meet high usability

Selection of the open-source openHAB technology provides strong evidence of high usability by being applied to previous EU-funded projects and supporting a large development community.


R141 Android support

System HomeHub has to support at least the Android OS

Yes, it supports both iOS and Android. Furthermore, any operating systems that can effectively execute Java (JDK) code can host the HomeHub server (including low cost Raspberry PI installations).


11 Appendix 2 – Participant Devices


11.1.1 Hearing Aids (HAs) The connection between the hearing aids set and the SB mobile application will be established over the Bluetooth Low Energy (BLE) mode preferably. Compared to classic Bluetooth, Bluetooth Low Energy is intended to provide considerably reduced power consumption and cost while maintaining a similar communication range. Android based mobile operating systems natively support Bluetooth Low Energy technology. This component offers the following functional capabilities:

• Hearing aid usage patterns: This is a key capability for monitoring the use of the hearing aids. When the program or volume is changed on the hearing aid, it transmits the new values over Bluetooth to the mobile application. This functional capability is implemented by the following operations that are presented below in details: modeChangeHAOP.

• Hearing test mode: This is a key capability for monitoring a participant’s hearing thresholds. The hearing aids set in conjunction with the SB mobile application can measure the participant’s hearing thresholds and also perform speech tests/auditory training. This functional capability is implemented by the following operations that are presented below in details: modeHearingTestHAOP.

• Sound environment parameters: This capability is important for contextualizing the audio environment that the participants experience as well as monitoring the sound/noise levels. It transmits the contextual estimates of the sound environment from the hearing aid to the mobile application over Bluetooth. This happens automatically as long as the hearing aid is turned on, while it requires that the mobile app is connected to the hearing aid for the data logging to take place. This functional capability is implemented by the following operations that are presented below in details: environmentDataHAOP.

modeChangeHAOP:

Operation Description This operation is triggered whenever a user changes the program and/or the volume on his/her paired hearing aids set. The SMART BEAR mobile application can use this operation to monitor which program is selected.

Input parameters


Program change Changes the program of both hearing devices when transmitted from the mobile application.


Volume Changes the volume of a single hearing device when transmitted from the mobile application.

Output parameters


Program change Unsigned Integer The hearing aid transmits this value when the user changes the program. The two devices link their programs, so there will be messages from both hearing aids. It is triggered once there is a program change or a read request from the mobile application.

Volume change Signed Integer The hearing aid transmits this value when the user adjusts the volume. The two devices link their programs, so there will be messages from both hearing aids. It is triggered once there is a program change or a read request from the mobile application.

modeHearingTestHAOP:

Operation Description The audiogram can be measured using audiometry and the Sound Pressure Levels transmitted from the hearing aid (environmentDataHAOP) to calibrate the outputs of the mobile phone to the acoustic level of the sound presented to the user.

Input parameters


Current program Unsigned Integer The mobile device should read and store (locally) the current program identifier. Thereafter change to the first program.

Current volume Signed Integer The mobile device should read and store (locally) the current volume step. Thereafter set the volume to 0.

Output parameters



Current HA program Unsigned Integer After completion of the hearing test or auditory training restore the previously selected HA program.

Current HA volume Signed Integer After completion of the hearing test or auditory training the previously selected volume step.

environmentDataHAOP:

Operation Description Transmits the sound environment parameters over BLE. This operation runs on minimum intervals initiated by the hearing aid itself. The mobile application can request the data as well, but the read intervals are determined. In this context, a raw stream of byte values is expected as output from the HAs.

Input parameters


-

Output parameters


ParameterName – frequencyRange

Representation of floats Parameters like SPL (on frequency ranges), Noise floor (on frequency ranges), Signal to noise ratio (on frequency ranges) etc.

Sound environment parameter

ENUM The output of the sound environment ideally classified as:

• 0: Quiet

• 1: Speech

• 2: Speech in noise

• 3: Noise

11.1.2 Smart Watch A smart watch device will be used to provide a set of services, including: track a participant’s heart rate, GPS tracker and monitoring of participant’s/ device motion. There is also a native way for the SB mobile application to monitor the accelerometer since most Android-powered devices have built-in motion sensors that measure acceleration forces.


This component offers the following functional capabilities:

• Heart rate monitoring: This functional capability is implemented by the following operations that are presented below in details: collectHRData, pushNotification.

• Accelerometer information monitoring: A wearable tracker (built in sensor) continuously senses the movements of the body on a 3-axis accelerometer. This enables the tracker to trace if the individual/participant is walking forward, running fast, or standing still. This functional capability is implemented by the following operations that are presented below in details: collectAccData.

• Physical activity monitoring: A participant is periodically notified to perform physical activities. Various types of physical activity can be supported, including track walking with regard to the period or steps achieved. In response, the SB mobile application produces alerts whenever a participant’s level of adherence to the training activities exceeds thresholds defined in his/her profile (scarce adherence). This functional capability is implemented by the following operations that are presented below in details: collectPhActivityData, evaluateAdherence, pushNotification.

collectAccData:

Operation Description Measures the acceleration force in m/s2 that is applied to a device on all three physical axes (x, y, and z), including the force of gravity. It registers a sensor event listener that monitors accelerometer sensor changes.

Input parameters


sensorRate Time/Frequency The minimum rate at which to acquire sensor data.

Output parameters


sensorData AccelerometerSensorType Acceleration force measurements per axe (x, y, z), timestamped.

collectHRData:

Operation Description Measures the heart rate as beats per minute. It registers a sensor event listener that monitors sensor changes.

Input parameters




Output parameters


sensorData HRSensorType Heartbeat rates per minute measurements, timestamped.

collectPhActivityData:

Operation Description Measures the progress in a physical activity. It registers a sensor event listener that monitors sensor changes.

Input parameters


activity ActivityType The type of physical activity that is to be tracked.


Output parameters


sensorData PhysicalActivitySensorType Depending on the type of physical activity performed either steps per minute or total number of steps measurements, timestamped.

evaluateAdherence:

Operation Description Evaluates the level of adherence achieved while performing physical activities. A classification of type scarce automatically triggers a notification to the participant. SB mobile application API.

Input parameters



activity activityType The type of physical activity that is to be evaluated.

frequency Time The invocation frequency of the evaluation method.

Output parameters


adherenceLevel Enum Level of adherence to a training set evaluations, timestamped. Possible classes: scarce, adequate, good.

11.1.3 Smart Pillbox This component offers the following functional capabilities:

• Pillbox cases monitoring: A participant uses a smart pillbox device that allows to control and monitor the medication during his/her drug therapy. This functional capability is implemented by the following operations that are presented below in details: collectPillboxData.

collectSPData:

Operation Description Tracks changes on the pillbox cases capacity. A boolean value per pillbox case indicates whether it is empty or not. It registers a sensor event listener that monitors sensor changes.

Input parameters



Output parameters


sensorData PillboxSensorType Changes on the pillbox capacity per case, timestamped.

11.1.4 Smart Blood Pressure Tracker This component offers the following functional capabilities:

• Blood pressure monitoring: It tracks a participant’s systolic and/or diastolic blood pressure in a manometric unit of pressure, a millimetre of mercury (mmHg). This functional capability is


implemented by the following operations that are presented below in details: collectBlPressureData.

collectBlPressureData:

Operation Description Tracks the systolic and/or diastolic blood pressure in millimetre of mercury (mmHg). It registers a sensor event listener that monitors sensor changes.

Input parameters



Output parameters


sensorData BloodPressureSensorType Blood pressure millimetres of mercury (mmHg) measurements, timestamped.

11.1.5 Smart Weight Scale This component offers the following functional capabilities:

• Weight changes monitoring: It tracks a participant’s weight measurements. Events that indicate significant deviations (weight gain/loss exceeds predefined threshold based on participant’s profile) trigger notifications to the participants. This functional capability is implemented by the following operations that are presented below in details: collectWeightData, pushNotification.

collectWeightData:

Operation Description Tracks a participant’s weight measurements in kilos. It registers a sensor event listener that monitors sensor changes.

Input parameters


Output parameters



sensorData WeightSensorType Weight measurements in kilos, timestamped.

11.1.6 Smart Glucometer This component offers the following functional capabilities:

• Blood glucose level monitoring: It tracks a participant’s blood glucose levels, usually post-prandial, in terms of a molar concentration, measured in mmol/L (millimoles per litre). This functional capability is implemented by the following operations that are presented below in details: collectGlucoseData.

collectGlucoseData:

Operation Description Tracks a participant’s blood glucose level in mmol/L. It registers a sensor event listener that monitors sensor changes.

Input parameters


Output parameters


sensorData GlucoseSensorType Glucose level measurements in mmol/L, timestamped.

11.2 Related Requirements

R-ED-3: The smartwatch in connection with the smartphone should be able to track physical activity and allocate scores to each user hence to allow a gamified approach to physical activity. R-CVD-6: The mobile app needs to be able to analyse daily exercise goals and encourage participant. R-ED-5: The mobile app should be able to give to the user tips on exercising based on an individualised profile (dynamically adapted with each recording).




R-CVD-4: The mobile app needs to be able to communicate, store, analyse data from the blood pressure recorder.

collectBlPressureData

R-CVD-5: The mobile app needs to be able to communicate, store, analyse data from the smart pillbox.

collectPillboxData

R-BD-19: The Platform must detect via heart rate and accelerometer information and possibly through self-reporting if the user is at rest.

collectHRData, collectAccData


collectAccData

R-ED-2: The mobile app should be able to support either automatic entry of glucometer readings or manual entry by the participant.

collectGlucoseData


12 Appendix 3 – Data Repository

12.1 Functional Capabilities and Interfaces The repository contains the following data model areas:

a. Identity management data model b. Sensors data model c. Devices data model d. Activity data model e. Medication data model f. Geospatial data model g. Hearing aid data model h. Questionnaires data model i. Calendar data model j. Adherence data model k. Intervention data model l. Transformation model

In the following section the details for the data models are provided. It must be noted that the data will be stored using JavaScript Object Notation (JSON) and JavaScript Object Notation for Linked Data (JSON-LD), to allow flexibility on the data storage and semantic annotation of them. The identified datatypes are not limiting the expansion of the models to cover the requirements. JSON is a way to store information in an organized, easy-to-access manner. It gives us a human-readable collection of data that we can access in a logical manner. JSON-LD is an implementation format for structuring data analogous to Microdata and RDF. Typically, JSON-LD is implemented leveraging the Schema.org vocabulary to create a unified structured data vocabulary.

The description of the models below is not restrictive. It allows to define the models of the Data Repository that will be precisely defined in T4.1. The type of each object is could be either a SQL data type, or a JSON object, providing the flexibility to tailor the data repository to potential schema changes throughout the project. In order to allow the compatibility between the data stored, each JSON entry should define the version number it uses.

Identity management data model Each platform user will be represented by a Person entity, which will be part of the Access-Control List (ACL) of the system. The details of the ACL are not included in this deliverable but will be described in detail in the deliverables of WP4. Details for the participants and the actors of the system will have the following structure

Property Details

PersonId FK to ACL database


DateOfBirth Date of birth in ISO 8601 format

Facility Details on facility where the person is assigned to (e.g. medical center, hospital, etc)

Role This will be in line with the ACL

Authorisation Details of the ACL will be defined in this object

Location The location of the participant (related to the pilot site)

MetaData This field will contain data in JSON format

Gender The gender of the person

Operation Description Exchange identity data

Input parameters


GET, POST, PUT, DELETE

URL: /cloud/identity Request body is using application/json

Output parameters


RESPONSE JSON

{ "version": 1, "personId": "abc123456789", "dateOfBirth": "1950-01-01T00:00:00.000Z", "facility": "ABC hospital", "role": "doctor", "authorisation": [ { "action": "register", "permission": "allow" }, { "action": "read", "permission": "allow" }, { "action": "write", "permission": "deny" } ], "location": { "pilotSite": "Greece",

The response provides identity data


"county": "Palaio Faliro" ... }, "metaData": { "communication": { "telephone": "123412341234", "email": "[email protected]" } ... }, "gender": "male" }

Sensor data model Sensor data model will be used to globally store the data from the sensors of the platform (HAs, blood pressure meter, weight, etc.)

Property Details

SensorType Enumeration: HearingAid, BloodPressure etc

MeasurementType Depending on the SensorType (e.g. for HA could be hours of usage, environmental noise levels, etc.)

MetaKey This key will be dynamically defined to uniquely identify the measurement


DataValue This field will contain the measurement data in JSON format

StartDatetime Measurement start datetime in ISO 8601 format

EndDatetime Measurement end datetime in ISO 8601 format

SampleRate This field is optional, required for measurements with sample rate

Location Location of the sensor

Unit Unit of the measured value (dB, mmHG, kg, etc.)

PersonId FK Reference to the person

Operation Description Exchange sensor data

Input parameters


mailto:[email protected]



URL: /cloud/sensor Request body is using application/json

Output parameters


RESPONSE JSON

{ "version": 1, "sensorType": "humidity", "measurementType": "float", "metaKey": {}, "metaData": {}, "dataValue": "0.84", "startDatetime": "2020-04-16T18:02:02.079Z", "endDatetime": "2020-04-16T18:02:02.079Z", "sampleRate": { "frequency": "50", "unit": "Hz" }, "location": "ceiling", "unit": "mmHg", "personId": "abc123456789" }

The response provides sensor data

Devices data model This model describes the devices that will collect the sensor data.

Property Details

DeviceId The unique identifier of the device (smart home sensor, wearable device, etc.)

DeviceType Description of the device type (wearable, ambient sensor, etc.)

DeviceModel Details on the device brand, model etc. (serial number of each device will also be stored)

MetaKey This field will contain details of the identifier of the data (JSON)


Location Location of the device


Operation Description Exchange device data


Input parameters



URL: /cloud/device Request body is using application/json

Output parameters


RESPONSE JSON

{ "version": 1, "deviceId": "XYZ123123", "deviceType": "wearable", "deviceModel": "V124124", "metaKey": {}, "metaData": {}, "location": { "pilotSite": "Greece", "county": "Palaio Faliro" }, "personId": "abc123456789" }

The response provides device data

Activity data model The activity data model will collect data related to the physical activity of the participant.

Property Details

Activity Enumeration of the detected activity

Distance Details of the walked distance for the detected activity

StartDatetime Measurement start datetime in ISO 8601 format

EndDatetime Measurement end datetime in ISO 8601 format

Intensity Intensity of the activity performed

DeviceId The related device that records the activity

Location This field will record the location of the activity

MetaData This field will contain data in JSON format that are not included in other fields



Operation Description Exchange activity data

Input parameters



URL: /cloud/activity

Request body is using application/json

Output parameters


RESPONSE JSON

{ "version": 1, "activity": "walk", "distance": { "value": "1.4", "unit": "km" }, "startDatetime": "2020-04-16T18:21:29.166Z", "endDatetime": "2020-04-16T18:21:29.166Z", "intensity": "moderate", "location": { "pilotSite": "Greece", "county": "Palaio Faliro" }, "metaData": {}, "personId": "abc123456789" }

The response provides activity data

Medication data model The data model of the medication will contain details for medication of the participant and will be used in parallel with the adherence data model.

Property Details


MedicationSchema The schema of the medication for the participant. This will

DrugName Details of the drug

UnitOfMeasurement Dosage schema

ActiveIngredient Active ingredient of the drug



Operation Description Exchange medication data

Input parameters



URL: /cloud/medication


Output parameters


RESPONSE JSON

{ "version": 1, "personId": "abc123456789", "medicationSchema": { "unit": "tablet", "value": "2", "frequency": { "day": "1", "time": "2020-04-16T18:32:02.146Z" } }, "drugName": "G-DIL", "unitOfMeasurement": { "unit": "mg", "value": "20" }, "activeIngredient": [ "Isosorbide mononitrate" ], "metaData": { "barcode": "123123123123", "atcCode": "C01DA14" } }

The response provides medication data

Geospatial data model Details of the location where the participant is moving around. The data will not contain fine grain details of the location.

Property Details

District District of where the participant is moving

City City of where the participant is moving

CoordinatesFromBase Coordinates from the base location of the user (home or living facility)

Timestamp The datetime of the location ISO 8601 format




Operation Description Exchange geolocation data

Input parameters



URL: /cloud/geolocation


Output parameters


RESPONSE JSON

{ "version": 1, "personId": "abc123456789", "district": "Center", "city": "Athens", "Coordinates": { "longitude": "31.14", "latitude": "41.22" }, "Timestamp": "2020-04-16T18:35:33.667Z", "metaData": {} }

The response provides geolocation data

Questionnaires data model Details of the questionnaires the user is asked to complete in daily/weekly basis.

Property Details

QuestionnaireId Reference to the questionnaire

Type Type of the questionnaire

Values The responses on the questionnaire

Timestamp The datetime of questionnaire completion in ISO 8601 format

MetaData This field will contain data in JSON format for the questions (version, scores, etc.)


Operation Description Exchange questionnaire data


Input parameters



URL: /cloud/questionnaire


Output parameters


RESPONSE JSON

{ "version": 1, "questionnaireId": "123", "type": "cognitive", "values": [ { "question": "How are you feeling today?", "type": "multipleChoice", "select": [ "option 1", "option 2", "option 3" ] } ], "timestamp": "2020-04-16T18:41:50.662Z", "metaData": { "language": "gr", "version": 2 }, "personId": "abc123456789" }

The response provides questionnaire data

Health record data model This data model will contain details for the health record of the participant, fetched from external systems

Property Details

ParticipantData Metadata for the participant

VisitData Details for visits to medical professionals

Orders Details for the medical orders (with reference to HL7)

Observations Details for the observations (with reference to HL7)




Operation Description Exchange EHR data

Input parameters



URL: /cloud/ehr


Output parameters


RESPONSE JSON

{ "version": 1, "participantData": { "symptoms": [ "cough", "nausea" ] }, "visitData": { "location": "Hospital Z", "datetime": "2020-04-16T18:57:23.912Z", "reason": "scheduled" }, "orders": {}, "observations": [ { "id:f005": {}, "identifier:6327": {}, "status:final": {}, "code:": "'Hemoglobin [Mass/volume] in Blood', given as 'Hemoglobin [Mass/volume] in Blood'})", "effective:05/04/2013 10:30:10 AM --> 05/04/2013 10:30:10 AM": {}, "issued:05/04/2013 3:30:10 PM": {}, "value:": "'g/dL')", "interpretation:": "'Low', given as 'Low'})" }, { "id:f204": {}, "identifier:1304-03720-Creatinine": {}, "status:final": {}, "code:Creatinine(Serum)": {}, "subject:Roel": {}, "issued:04/04/2013 2:34:00 PM": {}, "performer:Luigi Maas": {}, "value:": "'umol/L')", "interpretation:": "'Serum creatinine raised', given as 'Serum creatinine raised'};

The response provides EHR data


{http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation code 'H' = 'High)" } ], "metaData": {}, "personId": "abc123456789" }

Calendar data model This model will contain details of the appointments of the participant.

Property Details


Event Type of the event (appointment, health assessment, etc.)

StaffId Details of the medical professional

Location Location of the appointment

Service Type of service of the appointment

Datetime The datetime of the appointment in ISO 8601 format


Operation Description Exchange calendar data

Input parameters



URL: /cloud/calendar


Output parameters


RESPONSE JSON

{ "version": 1, "personId": "abc123456789", "event": "scheduledAppointment", "staffId": "ABC31321312", "location": { "pilotSite": "Greece", "county": "Palaio Faliro" }, "service": { "examination": {

The response provides calendar data

http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation

http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation


"type": "regular" } }, "datetime": "2020-04-16T19:09:40.214Z", "metaData": {} }

Adherence data model

Property Details

MedicationId FK of the medication


MedicationSchema Schema of the medication

Timestamp Time of medication definition in ISO 8601 format


Operation Description Exchange adherence data

Input parameters



URL: /cloud/adherence


Output parameters


RESPONSE JSON

{ "version": 1, "medicationId": "M0011C111", "personId": "abc123456789", "schedule": { "unit": "tablet", "value": "2", "frequency": { "day": "1", "time": "2020-04-16T19:33:16.238Z" } }, "medicationSchema": { "unitOfMeasurement": { "unit": "mg", "value": "20" }

The response provides adherence data


}, "timestamp": "2020-04-16T19:33:16.238Z", "metaData": { "received": true } }

Intervention data model

Property Details

Action Enumeration for the type of the action


Reason What triggered the intervention

Datetime Datetime of the intervention in ISO 8601 format

EvidenceReference Reference to the workflow that triggered the intervention

MetaData This field will contain data in JSON format (version of the decision model, extra data used for the proposed intervention selection, etc)

Operation Description Exchange intervention data

Input parameters



URL: /cloud/intervention


Output parameters


RESPONSE JSON

{ "version": 1, "action": "sendNotification", "personId": "abc123456789", "reason": "hypertension", "datetime": "2020-04-16T20:08:44.046Z", "evidenceReference": { "workflowId": 99123 }, "metaData": {} }

The response provides intervention data

Transformation data model


Property Details

TransformationId Identifier of the transformation

Configuration Configuration in JSON format

Workflow Workflow details

Datetime Datetime in ISO 8601 format


Operation Description Exchange transformation data

Input parameters



URL: /cloud/transformation


Output parameters


RESPONSE JSON

{ "version": 1, "transformationId": 123, "configuration": { "WorkflowName": "K-means", "StartNodeName": "data-input", "ActionNode": "Args": [ {"Arg": "urlDb=${urlDb}"}, {"Arg": "queryInputData=${queryInputData}"}, {"Arg": "inputData=${inputData}/${wf:id()}"} ], " NextAction": "Kmeans", }} }, "workflow": { "DawId": "DAW1234", "Description": "kmeans", "ExecutionType": "", "Name": "kmeans Unimi Avg_HA_Daily_Usage Edu_Level", "Parameters": "queryInputData=SELECT EDU_LEVEL, CAST(AVERAGE_HA_DAILY_USAGE AS FLOAT) AS AVG_HA_DAILY_USAGE from TableData;",

The response provides transformation data


"Tasks": "DataSelection, kmeans, DataSave", "Dependencies":"" }, "datetime": "2020-04-16T20:53:01.240Z", "metaData": {} }


Requirement # Details

R207 Initiate data analysis session

R208 Administrate (create, update, delete) analysis’ outcomes

R209 Notification when analysis is complete

R210 Visualizations of the analysis outcome

R211 Support of progressive notifications and save of the outcomes on data analysis

R212 Access management features for the analysis outcomes

R213 Visualize comparative data analysis sessions

R215 Different visualization modes of the recorded data

R216 Collect timestamped data related to an event or configurable period

R217 Manage and visualize a detected event log

R218 Visualize a list of data types that are collected in the platform

R219 Select from a list of data types

R220 Record the participant’ responses to various standardized questionnaires

R221 Create record for SMART BEAR device fitting

R224 SMART BEAR platform analyses. outcome measures


R225 Associate outcome measures with collected SMART BEAR device usage data and participants’ feedback

R226 Access to questionnaires’ answers

R227 Analyze questionnaires’ answers

R228 objective recording about SMART BEAR device malfunctions and related problems of SMART BEAR device users

R229 Analyze issues, concerns and problems with SMART BEAR devices reported by SMART BEAR devices users

R230 Register/update/cancel a new user

R231 Assign a role to the user

R232 Assign access right to roles

R233 Insert a new algorithm

R234 Configure an algorithm (parameters, data sources)

12.3 Application programming interfaces The data repository is designed to store the participant generated data (either provided by HomeHub or the External Vendor Cloud) and then provide the data to BDA and DSS to train the models that will provide evidence for the interventions for the participants. The APIs for the data exchange are designed using a generic pattern, to allow flexibility on the data exchange and tweaking if required. Specific details for the data and parameters of the APIs will be provided in the deliverables of WP4. For that purpose, there will be the following main APIs:

• Publish API This API is used to retrieve data from the devices of the participant (mainly from the HomeHub)

• Connect API This API is used to exchange data between the data repository, BDA and DSS for the analysis of the collected data, the execution of the models and the storage of the interventions

• Client API This API is used by the client applications of the participant (smartphone app, tec.), to consume data regarding the interventions, the notifications etc. (generated by the analytics models), and by the Visualisation module, that provides data to the dashboard


Below a sample of the APIs is provided for reference. Each endpoint is using versioning, to allow the evolve of the requirements and results that will be adjusted throughout the project duration.

Operation Description Publish data to the cloud

Input parameters



URL: /cloud/publish


Output parameters


RESPONSE JSON

{ "objectType": "sensor", "version": 1, "datetime": "2020-04-17T10:24:20.279Z", "data": {} }

The response provides publish data

Operation Description Connect collected data with models

Input parameters



URL: /cloud/connect


Output parameters


RESPONSE JSON

{ "objectType": "sensor", "version": 1, "datetime": "2020-04-17T10:31:12.444Z", "flow": "outgoing", "data": {}, "parameters": [ { "type": "sensor" }, { "type": "bloodPressure" }, { "type": "activity"

The response provides connect data


} ] }

Operation Description Consume data processed in the Cloud Backend

Input parameters



URL: /cloud/client


Output parameters


RESPONSE JSON

{ "objectType": "notification", "version": 1, "datetime": "2020-04-17T10:34:23.719Z", "flow": "outgoing", "data": {} }

The response provides client data


13 Appendix 4 – Mobile Application

13.1 Functional Capabilities and Interfaces The following list presents an overview of the functional capabilities that the SMART BEAR mobile application will provide. Every capability is accompanied by a detailed specification of the operations that implement it.

• HAs data collection: The application will be able to communicate with the HA embedded software and collect information with regard to the HA usage, the environmental data during the use of the HA as well as the results of the auditory trainings conducted by a participant. This information will be temporarily stored in the mobile device and it will be transmitted to the SMART BEAR platform for further analysis once an Internet connection is available. The application will make sure that all data are secured not only while in transit but also while at rest. Thus, cryptographic schemes will be applied to all data while those reside inside the mobile application. The communication schema between HAs and application will be based on the Bluetooth Low Energy while the one between the application and the platform will be based on a set of secure REST services. This functional capability is being implemented by the following operations that are presented below in details: collectHAData, storeHAData.

• Notifications/Alerts sending: The application relies on a messaging system comprising of topic-based message queues that offer durable messaging guarantees. Specifically, the guarantee offered is the ‘at-least-once' delivery. This means that a message will never get lost, but a message might end up being delivered to a consumer more than once. The message broker handles routing and delivering the messages/notifications reliably to the right participant devices. Based on the publish/subscribe model, topic messaging allows to send a message to multiple devices that have opted into a particular topic. The first time a participant connects to the SMART BEAR platform with his/her mobile application, it automatically retrieves his/her profile and subscribes him/her on the appropriate topic. Actually, each profile corresponds to a specific message queue. The messages will be displayed in a sticky way making sure that they are always highly visible to the users. Moreover, the notification/alerting mechanism can be used by other SMART BEAR components for triggering notifications like reminders for appointments, various types of questionnaires etc. The alerts are actually notifications with a high severity. This functional capability is being implemented by the following operations that are presented below in details: pushNotification.

• HA controlling/finetuning: The application will provide the option to adjust the operation of the HAs. Moreover, an automatic adjustment of the HAs will be also available based on predefined fitting parameters, so as to avoid the risk of accidentally configuring a potentially harmful setting of the HA. The update of settings in the SMART BEAR HAs is constrained to the programs defined by the corresponding clinician/audiologist. This functional capability is being implemented by the following operation that is presented below in details: controlHAData.

• Questionnaires: The application will support clinicians to create and make surveys on participants. These surveys, in the form of questionnaires, will be comprised of a basic set of question types, in order to be quick and easy to fill in. Closed-ended questionnaires is a basic type that will be supported by the platform. The collected answers will be sent to the platform for further analysis. Part of the analysis is the calculation of GHAB score for a given questionnaire. This functional capability will be implemented by the following operations that


are presented below in details: retrieveQuestionnaire, triggerGHABScoreCalculation and submitQuestionnaire.

• Appointments scheduling: The application will support clinicians, specifically audiologists, to schedule appointments with participants. The appointment scheduler sub component will rely on mobile’s native calendar app to setup the scheduled events. Automated event notifications either for new appointments confirmations or for cancelations will be sent automatically to all invitees in order to ensure that everyone stays in sync. This functional capability will be implemented by the following operations that are presented below in details: scheduleAppointment, confirmAppointment.

• Auditory training: The application will support, among various types of tests, auditory training tests to be performed by a participant. Specifically, auditory training tests as well as digit recall tests will be supported. The auditory tests consist of a set of questions accompanied by either by a set of possible answers per question or a request to recall a pattern (I.e. a sequence of numbers like the last n numbers) that the user were previously shown. In order to facilitate the realization of the auditory tests the questions will be transcripted to audio files (properly translated to the participant’s native language) and then will be displayed to a participant asking him to provide his/her answers. This functional capability will be implemented by the following operations that are presented below in details: performAuditTraining.

• Speech-To-Text: The application will support the transcription of sound files to text files. This functionality will be built on top of an open source Speech-To-Text engine like DeepSpeech 7 using a pre trained model based on machine learning techniques. Project DeepSpeech base its implementation on Google's TensorFlow 8. This functional capability will be implemented by the following operations that are presented below in details: transcriptSpeech.

• Gamification: In order to stimulate a participant’s interest in participating more actively in the various tasks he/she has to perform (like cognitive tests, auditory training tests, physical activities etc) a gamified approach will be followed in the SB@App. Specifically, the participants will have the feeling of participating in a virtual game where their achievements in the tasks result in a higher ranking or a badge is earned when some events raises. A badge is a distinction win by a player when he/she does something significant, on event. This functional capability will be implemented by the following operations that are presented below in details: handleBadges, handleLeaderboard.

• Reporting: The application will produce reports based on the participant’s collected data. Reports will be generated either on a periodical basis or on demand. Typical use cases refer to HA usage reports, training test results reports and questionnaire reports. This functional capability will be implemented by the following operations that are presented below in details: makeReport.

• Localisation: The SB@App should be installed on many devices in many regions. Specifically, pilots in 5 different countries will take place during the project, namely the Greek, French, Italian/Portugal, Spanish and Romanian pilot. A resource configuration per pilot/language will

7 https://github.com/mozilla/DeepSpeech 8 https://www.tensorflow.org/

https://github.com/mozilla/DeepSpeech

https://www.tensorflow.org/


be packaged in the SB@App to support all of them. Resources are text strings, layouts, sounds, graphics, and any other static data. When a SB user runs the app, Android automatically selects and loads the resources that best match the device settings.

collectHAData:

Operation Description

A gateway between the HAs and the mobile application. It collects, in the form of timestamped logged events, HA usage data and HA environment data.

Pre-conditions HA embedded software provides services to export timestamped data. Required HA functions: modeChangeHAOP, environmentDataHAOP.

Post-conditions HA data are stored in the mobile application.

Input parameters


Frequency Time Specifies the time intervals on which the HA data aggregation takes place. The data are temporarily stored inside application’s internal database until uploaded to the platform.

Program Change Threshold

The range or threshold criterion that will be applied on program change events.

Volume Change Threshold

The range or threshold criterion that will be


applied on volume change events.

Output parameters


storeHAData:


Stores aggregated HA data in the platform.

Pre-conditions HA data have been collected and are transmitted in the SB Data Repository.

Post-conditions HA data are stored in the platform.

Input parameters


Timestamp DateTime Event timestamp.

Type of HA Data Usage data / Program change Usage data / Volume change

Each HA data type corresponds to a different collection in SB Data Repository.

Value int The aggregated value.

Output parameters


pushNotification:


Send a push notification.


Pre-conditions An event registered as a notification source occurs.

Post-conditions

Input parameters


notificationData Object The notification data to be showed at the mobile app.

Output parameters


pushNotification Object The message to the user that is showed at the SMART BEAR mobile app.

controlHAData:


Sets HA settings and parameters.

Pre-conditions HA embedded software exposes functions that allow remote access to control the settings and parameters configuration.

Post-conditions HA configuration is updated accordingly.

Input parameters


Program Selected Signed int The default program that the HA selects once it is turned on.


Volume Step int The default volume step/value.

Output parameters


scheduleAppointment:


Schedule an appointment event between a participant and his/her audiologist.

Pre-conditions A participant is linked to an audiologist.

Post-conditions A scheduled appointment event is stored in the platform.

Input parameters


Issues List<Enum> A list of issues registered by the participant that refer to the motives behind the appointment booking.

ScheduledOn DateTime The date and time of the scheduled appointment.

Invitees List<Recipient> A list of recipient addresses for the appointment.

Output parameters


Appointment event Event A scheduled event is stored in the platform and it is synced in the


calendars of all involved parties.

confirmAppointment:


Confirm an appointment event between a participant and his/her audiologist.

Pre-conditions A participant has scheduled an appointment event.

Post-conditions A scheduled appointment event is updated in the platform based on whether the clinician has accepted or declined the appointment. The updated event is synced between all involved parties calendars.

Input parameters


Appointment ID int The Id of the scheduled event.

isConfirmed Boolean Indicates whether the corresponding clinician confirms or declines the scheduled event.

Output parameters


Appointment event Event A scheduled event is updated in the platform and it is synced in the


calendars of all involved parties.

triggerGHABScoreCalculation:


Triggers the score calculation of a GHAB questionnaire from the platform.

Pre-conditions User has filled in and submitted the GHAB questionnaire.

Post-conditions GHAB questionnaire score responses are stored in the platform.

Input parameters


Questionnaire ID int The Id of the questionnaire.

Output parameters


GHAB Score int A GHAB Questionnaire score.

submitQuestionnaire:


Submits the answers of a questionnaire to the platform.

Pre-conditions User has filled in the questionnaire.

Post-conditions Questionnaire responses are stored in the platform

Input parameters



User Answers User input The answers selected by the user through the mobile application.

Answered On DateTime The date and time that the questionnaire was answered.

Output parameters


Questionnaire ID int The Id of the questionnaire.

answers Object list A list of the answers to the questionnaire. Every object contains the questionID and the answerID.

Answered On DateTime The date and time that the questionnaire was answered.

retrieveQuestionnaire:


Gets the active questionnaires from the platform.

Pre-conditions Questionnaires have been added to the platform.

Post-conditions Questionnaires appear at the user’s mobile screen.

Input parameters


Questionnaire Info Text The general Information of the


questionnaire, e.g. title, description, etc

Questions Object list A list of all included questions. Each question object contains its title, type and possible answer options.

Output parameters


Rendered Questionnaire

Application Page The questionnaire displayed on the mobile device.

transcriptSpeech:


Transcripts an audio/speech file to the corresponding text file.

Pre-conditions Machine learning model exists.

Post-conditions

Input parameters


Audio File Stream<Byte>

An audio file of a recorded speech segment.

Language Enum<LangCode> The language of the recorded speech.

Output parameters



TransText String The transcribed text content of the input audio file.

PerformAuditTraining:


It initiates an auditory training test, it collects the results and any self reported information by the user and stores the results on the SB Data repository.

Pre-conditions RetrieveQuestionnaire API succeeds.

Post-conditions The auditory training results and any self-reported information are stored in SB Data repository.

Input parameters

Name Type Description auditTrainingId ID

The id of the corresponding questionnaire.

Output parameters


auditTrainingResults Map<auditTrainingId, List<Result>>

The auditory training results are stored in SB Data Repository.

handleBadges:


The Badges API binds events of goal


achievements to badge acquisition.

Pre-conditions The participant executes a physical activity or performs a training or cognitive test.

Post-conditions

Input parameters

Name Type Description taskId ID

The id of the task performed (activity, test etc).

Event JSON

EventType and EventValue, I.e. {“type”: “taskCompleted” “value”: 95% }

Output parameters

Name Type Description badges List<Badge>

A list of acquired badges/ achievements.

handleLeaderboard:


The LeaderBoard API maintains the ranking of participants.

Pre-conditions The participant executes a physical activity or performs a training or cognitive test.

Post-conditions

Input parameters



taskId ID The id of the task

performed (activity, test etc.).

Output parameters

Name Type Description leaderboard List<Rankink>

A list of anonymised user rankings.

makeReport:


It generates report on a specific type of collected data.

Pre-conditions Data has been collected.

Post-conditions

Input parameters

Name Type Description dataType Enum

The type of collected data. I.e. HA Usage, Questionnaire, Training results etc.

reportType Enum The type of the

exported report, I.e. PDF, JSON.

Output parameters

Name Type Description report Document

The report in the exported format type.

13.2 Related Requirements The requirements addressed (partially or fully) by this component are as listed below.


Requirement Operation

R-HA-1: The Platform must be able to retrieve HA usage data. R-HA-3: The Platform must be able to monitor HA usage data automatically and check whether usage falls within specified ranges.

collectHAData, storeHAData

R-HA-4: The Platform must be able to produce notifications to the user when their HA usage is outside the specified ranges. R-HA-5: The Platform must be able to produce follow-up notifications to the user and/or the case manager and/or the formal/informal caregiver within specific periods after the initial notification, depending on the user's HA usage and the ICF/actor's acceptance to receive such notifications. R-HA-6: The Platform must be able to produce notifications reminding the user to fill in their GHAB questionnaire and do so periodically. R-HA-30: The Platform must be able to produce periodic notifications for tasks the user must perform (e.g., auditory training). R-BD-12: The Platform must be able to notify the user via text on the smartphone and vibration on the smartwatch. R-BD-20: The Platform collects external weather conditions and provides notification to the mobile device in case of possible critical cases (we need to define the critical cases). R-CD-10: SMART BEAR should be able to send reminders for cognitive training to participants on a periodically basis.

PushNotification


R-CD-22: SMART BEAR should be able to provide suggestions/advises on sleep activity to a participant. ?? R-CD-25: SMART BEAR should provide a notification/alert mechanism which can be triggered by several events/actions/conditions (i.e. participant's medication schedule, participant's goal achievement, home sensor thresholds, etc.) (ie. participant's medication schedule, participant's goal achievement, home sensor thresholds, weather, etc.) R-CVD-1: The mobile app needs to be able to send periodic notifications/alerts to the participant based on preset parameters. R-CVD-2: The mobile app needs to be able to send periodic notifications/alerts to the case manager based on preset parameters.

R-HA-7: The Platform must be able to display an interactive questionnaire. R-HA-8: The Platform must be able to keep active the interactive questionnaire while it has not been filled in and its time period has not elapsed. R-CD-23: SMART BEAR mobile app should be able to provide Closed-ended questionnaire.


R-HA-9: The Platform must be able to calculate GHAB scores.

triggerGHABScoreCalculation

R-HA-10: The Platform must offer the user of retrieving and visualising their GHAB scores. R-HA-11: The Platform must be able to compare (and visualise) historic GHAB scores.

retrieveGHABScores


R-HA-12: The Platform must be able to produce a periodic HA usage report, annotated by brief explanations. R-HA-13: The Platform must be able to notify periodic HA usage reports to (a) the user, (b) audiologists, (c) case managers, subject to their existence and acceptance to receive such notifications/ICF. R-HA-27: The Platform must be able to provide records of HA usage data for different combinations of noise types/levels/duration of exposure. R-HA-32: The Platform must be able to provide feedback on the auditory training to the user and the audiologist. R-CD-11: SMART BEAR should be able to send report of training results and goals to participants on a periodically basis. R-CD-24: SMART BEAR should provide a reporting mechanism that will support reports on participants' data (reports such as participants' answers on questionnaires).

makeReport

R-HA-14: The Platform must be able to book a call with the audiologist using the MyAppointments app, following the user's request. R-HA-16: The Platform must be able to allow the user to book an appointment with their audiologist for the issues registered by the user. R-HA-17: The Platform must be able to produce reminders for appointments at specified times. R-HA-20: The Platform must be able to allow the recipient of an appointment request to confirm and save the appointment.


R-HA-21: The Platform must be able to allow the audiologist to activate the remote fine-tuning function of the HA.

controlHAData


R-HA-29: The Platform must allow the audiologist to view the participant's profile and select an auditory training program. R-HA-33: The Platform must be able to change the auditory training to the next level when certain milestones are reached (discrimination, discrimination in noise). R-HA-34: The Platform must be able to collect self-reporting on the auditory training by the participant. R-HA-31: The Platform must be able to collect the results of the auditory training.


R-BD-6: The smartphone supports speech-based interaction and text. Methods need to be reviewed for TTS, cloud-based, android-API solutions.

transcriptSpeech

R-BD-7: The mobile device must be able to display the output of the report and notify and deliver the report to the use case manager.

displayReport

R-BD-15: The App must be able to trigger instructions upon incorrect execution of the exercise.

pushNotification



R-CD-1: The mobile app must be able to support digital tests (ie MoCA).

PerformAuditTraining

R-CD-7: The mobile app must be able to play personalized verbal messages.

transcriptSpeech

R-CD-12: The mobile app should be able to provide rehabilitation programs to participants.

retrieveRehabiliationProgram (from SB Data Repository)

R-CD-13: The mobile app should provide a list of cognitive exercises that supports multiple level of difficulty.





R-CD-18: SMART BEAR mobile app should provide list with the top training results/scores of all users.


R-CD-26: The mobile app should provide a calendar for a participant's medication schedule.

retrieveMedicationSchedule

R-CD-32: SMART BEAR Platform notification/alert mechanism can be postponed/disabled.

disableAlerting

R-CD-33: The mobile app should provide a list of cognitive games with different levels of difficulty.

retrieveCognitiveTests (from SB Data Repository)

R-ED-6: The mobile app should follow a gamified approach for increased user motivation.



14 Appendix 5 – Enabling Sensors


14.1.1 Smart Weather Station (Indoor and Outdoor) This component offers the following functional capabilities:

• Outdoor temperature monitoring: It measures the outdoor temperature in degrees Celsius. This functional capability is delivered by the following operation that is presented below in more detail: collectOutdoorTemperature.

• Outdoor pressure monitoring: It measures the barometric pressure in mmHg. This functional capability is delivered by operation collectOutdoorPressure

• Outdoor humidity monitoring: Measures the outdoor humidity in % RH. This functional capability is delivered by operation collectOutdoorHumidity

• Rain detection: It reports rain intensity in mm. This functional capability is delivered by operation collectRainIntensity

• Indoor temperature monitoring: It measures the outdoor temperature in degrees Celsius. This functional capability is delivered by the following operation that is presented below in more detail: collectIndoorTemperature.

• Indoor humidity monitoring: Measures the outdoor humidity in % RH. This functional capability is delivered by operation collectIndoorHumidity

collectOutdoorTemperature:


Tracks the outdoor temperature. It registers a sensor event listener that monitors sensor changes.

Input parameters


Output parameters


sensorData EnvironemntTemperatureType

Temperature in the environment, in degrees Celsius, timestamped.


collectOutdoorPressure:


Tracks the outdoor barometric pressure. It registers a sensor event listener that monitors sensor changes.

Input parameters


Output parameters


sensorData BarometricPressureType

Pressure in the environment, in mmHg, timestamped.

collectOutdoorHumidity:


Tracks the outdoor humidity. It registers a sensor event listener that monitors sensor changes.

Input parameters


Output parameters


sensorData EnvironmentHumidityType

Humidity in the environment, in percentage Relative Humidity (% RH), timestamped.


collectRainIntensity:


Tracks the rain intensity. It registers a sensor event listener that monitors sensor changes or receives information for weather station

Input parameters


Output parameters


sensorData RainIntensityType

Registers rain intensity, in mm, timestamped.

collectIndoorTemperature:


Tracks the indoor temperature. It registers a sensor event listener that monitors sensor changes.

Input parameters


Output parameters


sensorData EnvironemntTemperatureType

Temperature in the environment, in degrees Celsius, timestamped.


collectIndoorHumidity:


Tracks the indoor humidity. It registers a sensor event listener that monitors sensor changes.

Input parameters


Output parameters


sensorData EnvironmentHumidityType

Humidity in the environment, in percentage Relative Humidity (% RH), timestamped.

14.1.2 GPS sensors GPS-equipped insoles and other GPS trackers will provide accurate location data that can be used to extract information on activity level, location of users and walking routes, daily routines. This component offers the following functional capabilities:

• GPS location monitoring: It provides the location (GPS coordinates) of the user measured in DD (decimal degrees). This functional capability is delivered by the following operation that is presented below in more detail: collectGPSLocation.

collectGPSLocation:


Tracks the GPS location. It registers a sensor event listener that monitors sensor changes.

Input parameters


Output parameters



sensorData GPSLocationType Location in decimal degrees (DD), timestamped.

14.1.3 Accelerometer An accelerometer accurately measures acceleration in any direction, which is the rate of change of the velocity of an object. They measure in meters per second squared (m/s2) or in G-forces (g). This can be used as wearable sensors to detect falls and frequent loss of balance. This component offers the following functional capabilities:

• Acceleration monitoring/ fall detection: It provides the acceleration value of the wearable accelerator. This functional capability is delivered by the following operation that is presented below in more detail: collectAcceleration.

collectAcceleration:


Tracks the acceleration. It registers a sensor event listener that monitors sensor changes.

Input parameters


Output parameters


sensorData AccelerometerSensorType

Acceleration measure in meters per second squared (m/s2) or in G-forces (g), on all 3 directions,.timestamped.

14.1.4 Other motion sensors The project will make use of a range of motion detection sensors, collecting data relevant in a multiplicity of use cases. These include sensors on doors (bathroom, entrance, fridge) to collect


information on activity and patterns of user behaviour (activity, eating patterns, sleep patterns). Such sensors, depending on type, can measure position, velocity, and/or acceleration of moving objects. This component offers the following functional capabilities:

• Motion monitoring: It provides the movement information from the sensors. This functional capability is delivered by the following operation that is presented below in more detail: collectMotion.

collectMotion:


Tracks movement in the home and is attached to different objects. It registers a sensor event listener that monitors sensor changes.

Input parameters


Output parameters


sensorData MotionDataType Provides information from the motion detectors, detecting movement for instance providing the changes in location information of the object on which it is attached, measured in coordinates. timestamped.

14.1.5 Light sensors Light sensors will be used in SMART BEAR to measure the amount of ambient light in the home and help adjust the amount of light to adequate levels for the time of day and the current activity of the user. This component offers the following functional capabilities:

• Light monitoring: It measures the lighting intensity as detected by the sensors. This functional capability is delivered by the following operation that is presented below in more detail: collectLightIntensity.

collectLightIntensity:



Tracks the lighting levels in the home. It registers a sensor event listener that monitors sensor changes.

Input parameters


Output parameters


sensorData LightIntensityType Provides information from the light sensors, detecting illuminance, measured in lux (Lum/m2). timestamped.

14.1.6 Send data to repository (via mobile device or home hub) This component manages the data collected from sensors and sends it to the repository. It is relevant for all sensor types. It offers the following functional capabilities:

• Data push to repository: Send relevant measurements to the data repository through the home hub or the mobile device pushSensorData

• Delete redundant data: Delete data that is redundant or not relevant (based on rules established in the scenarios deleteSensorData

• Start persisting data: Start storing data from the devices according to set schedule startSchedule

• Stop persisting data: Stop persisting data based on the set schedule stopSchedule


R-CD-25 SMART BEAR should provide a notification/alert mechanism which can be triggered by several events/actions (i.e. participant's medication schedule, participant's goal achievement, home sensor thresholds, etc.) R-CD-30 SMART BEAR should provide a notification/alert mechanism which can be triggered by several events/actions (ie.

All operations above


participant's medication schedule, participant's goal achievement, home sensor thresholds, etc.) R-CD-34 SMART BEAR should provide a notification/alert mechanism which can be triggered by several events/actions/conditions (ie. participant's medication schedule, participant's goal achievement, home sensor thresholds, weather, etc.) R-CD-39 SMART BEAR should provide a notification/alert mechanism which can be triggered by several events/actions (ie. participant's medication schedule, participant's goal achievement, home sensor thresholds, etc.)

R-CD-35 SMART BEAR should be able to collect physical activity data R-CD-31 SMART BEAR should be able to collect home sensors data R-CD-16 SMART BEAR should be able to record the physical activity of a participant

collectGPSLocation collectAcceleration

R-BD-19 The Platform must detect via heart rate and accelerometer information and possibly through self-reporting if the user is at rest.

collectAcceleration collectMotion

R-BD-21 The steps and heart rate are recorded in the Platform from the devices

pushSensorData

R-CD-3 The Platform should provide a mechanism for collecting data of different types, as well as geo-located data R-CD-15 SMART BEAR should be able to notify caregivers on participant's location and trajectory

collectGPSLocation

R-BD-20 The Platform collects external weather conditions and provides notification to the mobile device in case of possible critical cases (we need to define the critical cases)

collectOutdoorTemperature.

collectOutdoorPressure

collectOutdoorHumidity

collectRainIntensity

R-CD-29 SMART BEAR should be able to analyse home sensor data R-BD-3 The Platform must collect data from sensing devices, aggregate information, perform

pushSensorData deleteSensorData


an analysis of previously collected data to extract progress levels.

R-CD-37 SMART BEAR should be able to report physical activity (i.e. steps, km) and cognitive data R-CD-17: SMART BEAR mobile app should be able to provide an overview of the latest activity. R-BD-22: The Platform is able to report and display to the user on his/her mobile device of the steps he/she has walked.


R-CD-20 SMART BEAR should be able to record and report sleep activity of a participant

collectAcceleration collectMotion pushSensorData

R-CD-27 SMART BEAR Platform should be able to start recording home devices data on a scheduled basis.

startSchedule stopSchedule


15 Appendix 6 – Big Data Analytics Engine

15.1 Functional Capabilities The BDA is responsible for the execution and management of the workflows that clinicians intend to launch on the data entered within the platform in order to obtain meaningful results for their analysis. The component must be able to perform these batch analyses on a large amount of data (such as those of the sensors) in a reasonable time. For this reason, it was decided to use already battle-tested Big Data frameworks that can support this type of execution and to develop some components capable of providing the other features required to support all the requirements specified in the list. In order to fulfil the requirements, the BDA Engine is based on a set of sub-components:

1 BDA Infrastructure: Big Data Processing infrastructure that supports analytic workflow execution and libraries to supports statistical and data mining tasks, such as Apache Spark.

2 Task Catalogue: a component that contains all the methods to list/add/modify/delete all the Tasks (i.e., Processing, Statistical and Data Mining) for which an executable implementation is available in the BDA. For instance, the Task Catalogue will include Spark_ANOVA as an implementation of a task ANOVA or Spark_SVM_Prediction as an implementation of a task that performs an SVM prediction.

3 Workflow Catalogue: a component that contains all the methods to list/add/modify/delete all the EDAWs. These workflows are composed of tasks appearing in the Task Catalogue and a coded logic driving the task execution.

4 Management/Catalogue Backend: management backend for the BDA Infrastructure based on Ambari and for the Task and Workflow catalogues. It is used mainly for administrative management of the BDA Engine and Catalogues management.

5 API Module: RESTFUL APIs for the EVOTION components interacting with the BDA. 6 Analysis Transformation Tool: it’s the subcomponent that transforms a JSON representation

of the workflows in an EDAW that could be executed by the platform id AddWorkflow(EDAW, params)

AddWorkflow It permits to add a Workflow into the Catalogue.

Input parameters


EDAW Structured type. It is the Workflow Catalogue entry including executable/orchestrated workflow, scheduling preferences, formal parameters, etc.


Params List of Structured types representing each Tasks’ actual parameters.

It contains all the requested parameters for each Task in the EDAW. The EDAW is structured to take parameters at Task level.

Output parameters


Id Numeric It represents the id of the loaded EDAW as stored in the Workflow Catalogue

id CreateWorkflow(EDAW, params)

CreateWorkflow It permits to create and add a new EDAW into the Workflow Catalogue.

Input parameters



Output parameters



id CloneWorkflow(DAWID)

CloneWorkflow It permits to clone and create a new EDAW into the Workflow Catalogue.

Input parameters



DAWID Structured type. It is the Workflow Catalogue entry including executable/orchestrated workflow, scheduling preferences, formal parameters, etc.

Output parameters



<list of EDAWs> listWorkflows()

ListWorkflows It returns the list of workflows in the Workflows Catalogue

Input parameters


Output parameters


list of EDAWs List of Structure type It contains the list of the EDAWs in the Workflow Catalogue

<list of EDAWs> FindWorkflowModel(DAWID)

FindWorkflowModel Find all the EDAW referred to a given Model Instance Data Analytic Workflow (DAWID) from the Catalogue.

Pre-conditions DAWID must refers to an existing Model Instance

Input parameters



DAWID String Unique identifier for a DAW Model Instance

Output parameters


list of EDAWs List of Structured type The list of EDAWS that refer to a specific DAWID in the Catalogue

EDAW FindWorkflowInstance(EDAWID)

FindWorkflowInstance Find a given EDAW from the Catalogue.

Pre-conditions EDAWID must refers to a loaded EDAW.

Input parameters


EDAWID numeric Unique identifier for a loaded EDAW

Output parameters


EDAW Structured type The EDAW as it is in the Catalogue

ret ModifyWorkflow (EDAW,params)

ModifyWorkflow It permits to modify a given EDAW, like for instance updating the formal parameters, the schedule preference, the EWAD code, of a loaded EDAW. It allows to modify also the actual parameters.

Pre-conditions The EDAW must be already loaded into the Catalogue. If the EDAW is running, it is first


stopped, modified and then re-executed.

Post-conditions Ret corresponds to a valid output message

Input parameters



Params List of Structured types representing each Tasks’ actual parameters

It contains all the requested parameters for each Task in the EDAW. The EDAW is structured to take parameters at Task level.

Output parameters


Ret boolean Positive in case of success, negative in case of error (e.g., EDAW is not available in the Catalogue)

ret RemoveWorkflowModel(DAWID)

RemoveWorkflowModel Remove all the EDAW Instance Data Analytic Workflow (DAWID) from the Catalogue.

Pre-conditions DAWID must refers to an existing Model Instance in the Ontology Manager.

Post-conditions Ret correspond to a valid output message.

Input parameters



DAWID String Unique identifier for a DAW Model Instance

Output parameters


Ret boolean Negative if the given DAWID is not present in the Catalogue, positive otherwise. boolean

ret RemoveWorkflowInstance(EDAWID)

RemoveWorkflowInstance Remove a given EDAW from the Catalogue.

Pre-conditions EDAWID must refers to a loaded EDAW.

Post-conditions Ret correspond to a valid output message.

Input parameters



Output parameters


Ret boolean Negative if the given EDAWID is not present in the Catalogue, positive otherwise. boolean

ret ExecuteWorkflow(EDAWID)

ExecuteWorkflow Execute a loaded EDAW given its EDAWID according to the scheduler preference. It can be also used to force re-execution of an EDAW coherently with the schedule preference.


Pre-conditions EDAWID must refers to a loaded EDAW

Post-conditions The Job id given by the Workflow Scheduler is saved into the Workflow Catalogue entry related to EDAWID to manage the running/scheduled EDAW.

Input parameters



Output parameters


ret boolean Negative if the given EDAWID is not present in the Catalogue, positive otherwise. boolean

RerunWorkflow(EDAWID)

RerunWorkflow Rerun a loaded EDAW given its EDAWID according to the scheduler preference. It can be also used to force re-execution of an EDAW coherently with the schedule preference.



Input parameters




Output parameters


ret boolean Negative if the given EDAWID cannot be rerunned, positive otherwise. boolean

ret SuspendWorkflow(EDAWID)

SuspendWorkflow Suspend a loaded EDAW given its EDAWID according to the scheduler preference. It can be also used to force re-execution of an EDAW coherently with the schedule preference.

Pre-conditions EDAWID must refers to a loaded EDAW and the EDAW should be in RUNNING state of execution


Input parameters



Output parameters



ret boolean Positive if the EDAWID can be suspended, negative otherwise

ret ResumeWorkflow(EDAWID)

ResumeWorkflow Resume a loaded EDAW given its EDAWID according to the scheduler preference. It can be also used to force re-execution of an EDAW coherently with the schedule preference.

Pre-conditions EDAWID must refers to a loaded EDAW and the EDAW should be in a SUSPENDEND state of execution


Input parameters



Output parameters


ret boolean Positive if the EDAWID can be resumed, negative otherwise


ret StopWorkflow(EDAWID)

StopWorkflow Stop the execution of an EDAW and perform the relative rollback activities if required.

Pre-conditions EDAWID must refers to an EDAW under execution

Post-conditions Ref correspond to a valid output message

Input parameters


EDAWID numeric Unique identifier for loaded EDAW

Output parameters


Ret boolean Positive if the EDAWID can be stopped, negative otherwise.

status WorkflowStatus(EDAWID)

WorkflosStatus It returns the execution status of an EDAW


Post-conditions

Input parameters


Status String The status of execution of an EDAW

id AddTask (ImplDAWTask)

AddTask It allows to add an implementation of a given DAW Task (ImplDAWTask) into the Task Catalogue.


Pre-conditions This API is for internal use only and it requires BDA Administration authorizations to be executed.

Input parameters


ImplDAWTask A structured Type It represents an entry of the Task Catalogue

Output parameters


Id numeric It represents the id of the Implemented Task as it is inserted into the Task Catalogue

Ret ModifyTask (ImplDAWTask)

ModifyTask It allows to modify any of the Task related attributes, like pointing to different implementation, modifying the reference library to name but a few.

Pre-conditions This API is for internal use only and it requires BDA Administration authorizations to be executed. ImplDAWTask must refers to an Implemented Task available in the Task Catalogue.


Input parameters


ImplDAWTask Structured Type It represents the entry of the Task Catalogue for which we want to modify some of its attributes

Output parameters


Ret boolean Positive in case of successful modification, negative in case of error (e.g., EDAW not available in the Catalogue)

Ret RemoveTaskModel (DAWTaskID)

RemoveTaskModel It allows to remove all the implementation of a given a DAW task model

Pre-conditions This API is for internal use only and it requires BDA Administration authorizations to be executed. DAWTaskID must refer to a DAW Task present in the EVOTION Ontology Manager

Input parameters


DAWTaskID String representing a DAW Task ID.

It is an unique identifier.

Output parameters



Ret boolean Negative if the given DAWTaskID is not present in the Catalogue, positive otherwise

RemoveTaskInstance (ImplDAWTaskID)

RemoveTaskInstance It allows to a specific implementation of a given Task.

Pre-conditions This API is for internal use only and it requires BDA Administration authorizations to be executed. ImplDAWTaskID must refer to an Implemented Task available in the Task Catalogue.

Input parameters


ImplDAWTaskID Numeric. It represents an Implemented DAW Task. It is optional.

It represents the entry of the Task Catalogue. If present the deletion refers just to this ID otherwise to all the implemented Task related to the DAWTaskID

Output parameters


Ret boolean Negative if the given ImplDAWTaskID is not present in the Catalogue, positive otherwise

<ImplementedTasks> FindTask(DAWTaskID)

FindTask It permits to search for an implementation of a given DAW Task ID. It returns the details needed to generate an


EDAW involving the retrieved Implemented Task.

Input parameters


DAWTaskID A String representing a DAW Task ID.

It is an unique identifier.

Output parameters


ImplementedTasks List of Implemented Tasks as they are specified in the Task Catalogue (i.e., the list of corresponding Catalogue Entries)

It contains the Implemented Analytic Tasks’ details relative to a given DAW Task ID.

<ImplementedTasks> ListTask()

FindTask It returns all the tasks in the catalogue.

Input parameters


Output parameters


ImplementedTasks List of Implemented Tasks as they are specified in the Task Catalogue (i.e., the list of corresponding Catalogue Entries)

It contains the Implemented Analytic Tasks’ details relative to a given DAW Task ID.

JobID AddEDAWJob (EDAWID)

AddEDAWJob It adds an EDAW to the schedule according to the preference.



EDAWID must refer to an EDAW available in the Workflow Catalogue.

Input parameters


EDAWID Numeric Type representing an EDAW

It represents the entry of the Workflow Catalogue for which we want to set up a schedule.

Output parameters


JobID Job identifier It represents the identifier related to the EDAW in execution as it is represented by the Execution Manager/Scheduler

<EDAWID> ListRunningEDAWJob

ListRunningEDAW It lists all the EDAW that are running.


Output parameters


<EDAWID> List of EDAWID It contains the list of all the EDAWID that are running



R203 - SMART BEAR Backend should be able to filter data based on selected factors

ExecuteWorkflow


R204 - SMART BEAR Backend should cluster the relevant studies based on potential factors

ExecuteWorkflow

R206 - SMART BEAR Backend should be able to support different types of data analysis

CreateWorkflow, CloneWorkflow, AddTask

R207 - SMART BEAR Backend should be able to initiate data analysis session

ExecuteWorkflow,StartWorkflow, RerunWorkflow

R208 - SMART BEAR Backend should be able to administrate (create, update, delete) data analysis sessions

StopWorkflow,DeleteWorkflow, ModifyWorkflow

R233 - SMART BEAR Backend should be able to insert a new data analytics algorithm

AddTask

R234 - SMART BEAR Backend should be able to configure an algorithm (parameters, data sources)

AddWorkflow


16 Appendix 7 – EHR Systems

16.1 Functional Capabilities The exchange of information use Health record and Medication data model (see section 4.3). For the modelling on certain types of data HL7 will be used in JSON format. Below details on different pilots are broken down: Italian pilot In Lombardy Region aggregated data instead of single data sources will be used. It is crucial to assure the anonymised consumption of data (e.g. number of prescriptions) from the EHRs of patients clustered per pathologies, aiming to compare them against the data retrieved by the SMART BEAR project. The Italian pilot may take into account patients living in Lombardy Region that are affected by at least one of the six pathologies addressed by SMART BEAR and are not involved in the pilot. The output from the Lombardy Region's EHR, hosted by ARIA, may be a cluster (or more) of anonymised patients with the relevant clinical history - since the year 2000 - for each of them. Clinical history means both prescriptions and health services provided by hospitals, medical centre, health operators. This model would be allowed, under certain conditions, to UMIL which is today a certified user of ARIA Data providing services (DaaS). Such data will be provided without requiring an A2A (Application-to-Application) integration with the SMART BEAR Cloud, structured files (.csv, .xls or similar) will be provided instead. The idea is to collect indicators like - for example - "people affected by the pathology X typically require N prescriptions per year, have Y encounter with a specialist, etc". In a preliminary phase, the choice of the "right" indicators will be paramount for the pilot's success. Then, the Italian SMART BEAR pilot could gather relevant, similar data from the enrolled patients, e.g. number of prescriptions during the pilot, etc; the pilot could finally compare the number(s) gathered from this EHR cluster with similar indicators collected by the Italian SMART BEAR pilot, in order to measure and evaluate the pilot success. In other words, enrolled patients' outcomes would be assessed against Regional historical data. This pilot is twofold, involving Italy and Portugal to collect statistical data and compare with the data gathered by the SMART BEAR pilot. French pilot The public EHR DMP (“Dossier Médical Partagé”, in English “Shared Medical File”) may be connected through APIs. GPs are interested in obtaining reports on the participant generated by SMART BEAR. Romanian pilot This pilot will integrate the outcomes from SMART BEAR with the EHR system used by GP’s. The parameters collected (or reports generated on these parameters) through SMART BEAR, such as values of blood pressure, blood sugar levels, weight, physical activities, sleep quality, etc can be integrated in the EHR the GPs already use for their patients. SMART BEAR will not open a new/different interface/app for having access to the patients’ already measured parameters, the approach would be to visualize the outputs from SMART BEAR directly in their existing system. Spanish pilot


The Spanish pilot at Quirón Hospital will include a two-way integration between SMART BEAR and its EHR system Casiopea: From Casiopea to SMART BEAR

• Consent forms, that will originally be stored in Casiopea

• All information filled by participants in the portal (this information previously travels to Casiopea in a secure way). For example: blood pressure measured at home.

• Possibility to send additional clinical data from participants generated within the hospital such as laboratory results or nursing scales

From SMART BEAR to Casiopea

• All direct communications to participants, such as alerts or recommendations. These communications will be immediately forwarded to participants through the Casiopea portal.

• Raw data coming from the devices. This data does not need to come in a real-time basis (pulse to identify atrial fibrillation and data from ECG are required in real time). It could be sent by blocks periodically. Real-time care is only necessary for participants with abnormal values that are already defined. Every time SMART BEAR sends an alert for a particular participant, it must send to Casiopea all the information coming from that participant generated since the last block of information was sent.

Greek pilot

No integration with pre-existing EHR system is envisaged. A pull for all such systems, so we need one retrieval component for each of the 4 pilots (Spain, Romania, France, Italy) that will connect EHR systems and push system for certain pilots (Spain, Romania and France).

The operations are not fully defined because we would need much more information from the hospitals. We describe here the more general ones:

Operation Description Store parameters in the EHR

Input parameters


POST /ehr/$id/parameter

Parameter JSON body

Output parameters


RESPONSE JSON

HTTP/1.1 201 Created HTTP/1.1 401 Unauthorized { "code": 401, "message": "Authentication is required"

The response provides the result of the operation (201 - Created or error code)


}

Operation Description Get parameters from EHR

Input parameters


GET /ehr/$id

Get the EHR given the anonymous id of the patient

Output parameters


RESPONSE JSON

/cloud/ehr The EHR information of the patient in HL7 format

Operation Description Store information in the EHR

Input parameters


POST /ehr/$id

Parameter JSON body

Output parameters


RESPONSE JSON

HTTP/1.1 201 Created HTTP/1.1 401 Unauthorized { "code": 401, "message": "Authentication is required" }


Operation Description Get aggregated data from EHR

Input parameters



GET /ehr/aggregated

Get the aggregated data given some query

Output parameters


RESPONSE JSON

TBD The aggregated data for the EHR stored in HL7 format

Operation Description Store participant reports in the EHR

Input parameters


POST /ehr/$id/report

Store a pdf report in the EHR given a patient id

Output parameters


RESPONSE JSON

HTTP/1.1 201 Created HTTP/1.1 401 Unauthorized { "code": 401, "message": "Authentication is required" }


16.2 Related Requirements R303 Implement privacy by design In close cooperation with the

hospital IT responsible, all EHR storage/interaction functions will incorporate security mechanisms of the platform in order to meet privacy requirements with respect to GDPR rules

R304 Implement privacy by default In close cooperation with the hospital IT responsible, all EHR storage/interaction functions will incorporate security mechanisms of the platform in order to meet privacy requirements by default


R306 Respect data subject rights In close cooperation with the hospital IT responsible, a ll EHR storage/interaction functions will incorporate access control mechanisms of the platform in order to respect data subject rights

R311 Maintain records of processing activities Getters/Setters and storage functions will reliably maintain and process all EHR records

R312 Implement security measures In close cooperation with the hospital IT responsible, a ll EHR storage/interaction functions will incorporate security mechanisms of the platform by design

R313 Notify and communicate personal data breaches In close cooperation with the hospital IT responsible, notifications mechanism will be available using platform capabilities

R314 Conduct data protection impact assessments Monitoring will be implemented via corresponding functions

R315 Implement pseudonymisation, anonymization or deletion

In close cooperation with the hospital IT responsible, a ll EHR storage/interaction functions will incorporate security mechanisms of the platform by communication flow architecture; the deletion will be available as well


17 Appendix 8 – Decision Support System – DSS

17.1 Functional Capabilities The following components are part of the DSS: a) the Analysis Scheduler module, and b) the Model Explanation module. The inputs of the DSS are the Data Repository and the BDA Engine that provide data loaded, transformed and processed from the Data Repository. The output of the DSS is provided back the Data Repository so that can be consumed by the Visualisation module and the participant applications. Analysis Scheduler: This module is triggered by the BDA Engine to execute the series of transformations and model executions. This component is capable to execute the same workflows over time, to continuously and progressively train the model with the acquisition of new data from the data streams. The outputs of the data analysis are stored in the Data Repository, to provide evidence for the interventions and to allow monitoring of the proposed interventions over time. The Analysis Scheduler module allows the retrieval of the saved workflows (which include the transformations on the data) and the scheduling of the execution of the analysis. In that way, the results of multiple executions of the BDA engine are stored for future analysis and comparison between the results with different datasets. This module will also provide insights on the evolution of the execution of the workflows and how incremental datasets or tweaking of the parameters alter the results of the analysis. This module will provide parameterization of the BDA execution workflows and more specification will allow the following actions (related to the actions performed by the BDA):

• Creation of a new schedule for a workflow (single or multiple executions)

• Modification of an existing scheduled workflow

• Monitoring of the execution of a workflow

• Stop of the execution of a workflow The above actions will be performed via the internally accessible API of the DSS. The request will have the following formatting.

Operation Description Schedule a BDA workflow

Input parameters



URL: /bda/workflow


Output parameters


RESPONSE JSON

{ "version": 1, "workflow": "wf_ha_004", "action": "schedule",

The response provides dba workflow data


"datasource": { "dataset": 228, "transformation": "tr_014" }, "schedule": { "timeStart": "2020-04-25T14:37:12.466Z", "timeout": 10000, "repeat": { "enabled": true, "frequency": { "hours": "2" } } } }

Model Explanation: This module will support the interpretability and explainability of the datasets and machine learning models. Explainability tools will be used, so that the resulted models can be understood by the human experts. This module will perform an offline analysis of the results provided by the scheduled executions of the BDA workflows. The results of the trained models will be stored in the Data Repository and will be available for analysis by this module. Model specific and model agnostic methods will be tested as part of the development of this module and the selection of the most appropriate method will be reported in T4.3. This task will focus on feature importance of the predictive models, to understand if input features are important, and how significantly they are. The execution of the Model Explanation execution will be triggered by the respective API that will have the following contract.

Operation Description Provides trained model explanation

Input parameters



URL: /bda/explain


Output parameters


RESPONSE JSON

{ "version": 1, "modelId": "sbr_mdl_009", "local": true, "model": "specific" }

The response provides trained model explanation data


18 Appendix 9 – Dashboard

18.1 Functional Capabilities The Dashboard is composed by the following components:

• UI: the main component that is responsible to guide the user in the interaction within the system API’s

• Analysis Workflow Validation: the component provides the capability to validate the configuration of the workflow chosen by the user-base

• Visualization: is responsible to shows the results of an analysis using charts like pie-chart, bar-chart, line-chart, scatter plot, etc.

The UI component is responsible to show to the user the different types of data that are stored on the system, the workflows that are in execution, the workflows stored in the system as a template. Showing that information is important because the user could be guided to choose the right algorithm to get the data that is needed to their evaluation and is also important in order to select the appropriate visualization. If the user is an admin, it could manage the devices controlled by the platform and modify the configuration. The Analysis Workflow Validation is the component responsible to get in input the configuration by the user and check if is an appropriate one in order to execute the workflow. The Visualization module is responsible to get the results of the execution of the workflow from the Data Repository and provide the capabilities to shows those ones using the charts selected by the user. The Figure 19 depicts a simplified workflow for the Data Scientist that get access to the dashboard. After the login step, the user could see the list of workflows already launched by himself and then he can proceed to create/clone a workflows(WF) using a template that can be configured using the parameter that the UI shows to him lowering the chance that the system can reject the configured WF. The Visualization step is possible only after the execution is done.


Figure 19 Data Scientist Workflow Management

Instead Figure 20 shows how a user can perform a data exploration on the data lake, this helps the user to create/customize a workflow and then save it for a later execution or just to create a template that other users can use as a base.


Figure 20 Workflow Creation

The dashboard could be used also by the System Administrator in order to manage the devices and the users. As depicted in Figure 21, the user cannot run or see the workflows or the visualization of the results of older execution, they can only perform administrative tasks, like assigning users to groups or add/delete devices


Figure 21 System Administration



R207 - SMART BEAR Backend should be able to initiate data analysis session


R208 - SMART BEAR Backend should be able to administrate (create, update, delete) data analysis sessions


R210 - SMART BEAR Backend should be able to provide visualizations of the analysis outcome

Implemented by the Dashboard Visualization

R211 - SMART BEAR Backend should be able to send progressive notifications and save the outcomes accordingly when (25%, 50%, 75% and 100% of the) minimal data set has been analysed.


R212 - SMART BEAR Backend should be able to provide features of access management for the analysis outcomes related to a policy formulation process. Outcomes should be able to be accessed by individual stakeholders, who should be able to

Implemented by the Dashboard UI interface


express their views regarding the analysis outcome

R213 - SMART BEAR Backend should be able to visualize comparative data analysis sessions

Done using the Visualization API

R215 - SMART BEAR Backend should be able to provide different visualization modes of the recorded data, both on a single and an aggregated level


R218 - SMART BEAR Backend should be able to visualize a list of data types that are collected in the platform.


R230 - SMART BEAR Backend should be able to register/update/cancel a new user


R231 - SMART BEAR Backend should be able to assign a role to the user


R232 - SMART BEAR Backend should be able to assign access right to roles


R233 - SMART BEAR Backend should be able to insert a new data analytics algorithm


R234 - SMART BEAR Backend should be able to configure an algorithm (parameters, data sources)



19 Appendix 10 – Interaction Specifications

This section contains interaction specifications for the components and functions identified in the main part of the deliverable and the appendices.

19.1 Smart home

Figure 22 HomeHub to Item interaction


Figure 23 HomeHub to Bluetooth device interaction


Figure 24 HomeHub to Mobile interaction

Figure 25 HomeHub to Service interaction


Figure 26 HomeHub to External cloud interaction

Figure 27 HomeHub to WiFi device interaction


Figure 28 HomeHub to Sensor interaction

Figure 29 HomeHub to Binding interaction


Figure 30 HomeHub to Thing interaction

Figure 31 HomeHub to Repository interaction


19.2 BDA

Figure 32 Transformation tool to BDA core execution interaction

Figure 33 Transformation tool to BDA core interaction



Figure 39 Schedule and execution of the workflow


19.3 Data repository

Figure 40 Data repository to Dashboard, BDA and Model Explanation interaction

Figure 41 Data repository to Dashboard, BDA and Analysis scheduler interaction

Figure 42 Data repository to Dashboard and Mobile interaction


Figure 43 Data repository to Dashboard and Transformation tool interaction

19.4 Dashboard

Figure 44 Dashboard to Repository and Transformation tool interaction

Figure 45 Dashboard to Repository, Model Explanation and Analysis Scheduler interaction


Figure 46 Dashboard to Repository, Transformation and Validation tools interaction

Figure 47 Dashboard to Repository and Authentication Server interaction


19.5 Analysis scheduler

Figure 48 Analysis Scheduler to Repository and Transformation tool interaction

19.6 Model explanation

Figure 49 Model Explanation to Repository and Dashboard interaction


19.7 Devices and sensors

Figure 50 Smart Watch and Smart Pillbox to Repository and Mobile interaction

Figure 51 Hearing Aid and Blood Pressure Tracker to Repository and Mobile interaction


Figure 52 Smart Weight Scale and Smart Glucometer to Repository interaction

19.8 Mobile application

Figure 53 Mobile to Bluetooth and WiFi devices interaction


Figure 54 Mobile to Repository, Bluetooth devices and Authenticated user interaction

Figure 55 Mobile Repository interaction


Figure 56 Mobile to Repository and Authentication Server interaction

19.9 EHR

Figure 57 EHR to Repository interaction


20 Appendix 11 – Platform Security

20.1 Security Threats This section elaborates on the security threats to be assumed for the SMART BEAR platform and the mechanisms intended to be applied to address them. These threats have been classified with respect to the type of the behaviours of the attackers. The threat and risk analysis for big data analytic platforms produced by ENISA [5] .

20.1.1 Users with enhanced administration rights Threat.1: Administrative errors of omission. Administrators, Operators, Officers or Auditors fail to perform some function essential to security. Threat.2: User abuses authorization to collect and/or send data: User abuses granted authorizations to improperly collect and/or send sensitive or security-critical data.

Threat.3: User error makes data inaccessible.

Threat.4: Administrators, Operators, Officers and Auditors commit errors. An Administrator, Operator, Officer or Auditor commits errors that change the intended security policy of the system or application or maliciously modify the system’s configuration to allow security violations to occur.

Threat.5: Unidentified Action. Administrator fails to identify and act upon an unauthorized action

20.1.2 System Components Threat.6: Critical system component fails: Failure of one or more system components results in the loss of system critical functionality.

Threat.7: Malicious code exploitation. An authorized user, IT system, or hacker downloads and executes malicious code, which causes abnormal processes that violate the integrity, availability, or confidentiality of the system assets.

Threat.8: Message content modification. A hacker modifies information that is intercepted from a communications link between two unsuspecting entities before passing it on to the intended recipient.

Threat.9: Flawed code. A system or applications developer delivers code that does not perform according to specifications or contains security flaws.

Threat.10: FLAWAPP. Applications loaded onto the Mobile Device may include malicious or exploitable code. This code could be included intentionally by its developer or unknowingly by the developer, perhaps as part of a software library. Malicious apps may attempt to exfiltrate data to which they have access. They may also conduct attacks against the platform’s system software which will provide them with additional privileges and the ability to conduct further malicious activities. Malicious applications may be able to control the device's sensors (GPS, camera, microphone) to gather intelligence about the user's surroundings even when those activities do not involve data resident or transmitted from the device. Flawed applications may give an attacker access to perform network-based or physical attacks that otherwise would have been prevented.

20.1.3 Cryptography Threat.11: Disclosure of private and secret keys. A private or secret key is improperly disclosed.


Threat.12: Modification of private/secret keys.

Threat.13: Sender denies sending information. The sender of a message denies sending the message to avoid accountability for sending the message and for subsequent action or inaction.

Threat.14: Plaintext Compromise. Unlike full disk encryption, selectable encryption products also need to protect against data leaks to other applications on the machine. Many file creators and editors store temporary files as the user is working on a file and restore files if the machine experiences an interrupt while a file is open. Any of these files, if not properly protected or deleted, could leak information about a protected file to an attacker. Other applications might also access volatile or non-volatile memory released by the file encryption product, and the software used to create files prior to encryption may retain information about the file even after it has been encrypted. As the user creates and saves a new document, the plaintext will be stored on the machine's hard drive. An attacker could then search for the plaintext of the sensitive, encrypted information. An attacker may not even have to access the encrypted file for the protected information to be compromised. When the user wishes to encrypt the document, this plaintext file should be replaced with the new encrypted version. For non-mobile devices, it is expected that if the volatile and/or non-volatile memory space where the plaintext file was stored is merely released back to the machine without being first wiped clean of the data that was stored there, then the information the user wishes to protect will still be accessible. While protection of the encryption algorithm itself is vital, memory must also be properly managed by the file encryption product or the TOE platform for security to remain intact. For mobile devices, it is assumed that the File Encryption product will not be responsible for providing memory management cleanup and the environment's platform has met the Mobile Device Fundamentals Protection Profile.

20.1.4 External Attacks Threat.15: Hacker gains access. A hacker masquerades as an authorized user to perform operations that will be attributed to the authorized user or a system process or gains undetected access to a system due to missing, weak and/or incorrectly implemented access control causing potential violations of integrity, confidentiality, or availability.

Threat.16: Hacker physical access. A hacker physically interacts with the system to exploit vulnerabilities in the physical environment, resulting in arbitrary security compromises.

Threat.17: Social engineering. A hacker uses social engineering techniques to gain information about system entry, system use, system design, or system operation.

Threat.18: Plaintext_Data_spoofing: For certain modes of encryption, it is possible for a malicious person to modify cipher text data to force unintended modification to the underlying plaintext data, without the user being notified. There are various failures that may occur on the part of the TOE, to include: failure to verify the integrity of the data prior to decryption, failure to provide integrity on the sensitive data, failure to use a cryptographic or secure hashing code and failure to differentiate the File Authentication Key (FAK) from the FEK; the FAK is any secret value used as input to a keyed hashing function or as part of an asymmetric authentication process.

Threat.19: An attacker is positioned on a communications channel or elsewhere on the network infrastructure. Attackers may engage in communications with the application software or alter communications between the application software and other endpoints in order to compromise it.


Threat.20: The user loses the mobile device. Loss of Platform components can impose high security threats since a malicious user can gain access to the infrastructure.

20.1.5 Secure Storage Devices Threat.21: TSF_COMPROMISE: A malicious user or process may cause TSF data or executable code (e.g., the firmware on the USB flash drive) to be inappropriately accessed (viewed, modified, or deleted) to gain access to key material or user data

Threat.22: Keying_Material_Compromise: Material Attacks against the encryption product could take several forms; for example, if there is a weakness in the random number generation mixing algorithm or the data sources used in random number generation are guessable, then the output may be guessable as well. If an attacker can guess the output of the pseudorandom number generator (PRNG) at the time an encryption key is made, then the output may be used to recreate the keying material and decrypt the protected files. As the encryption program runs, it will store a variety of information in memory. Some of this information, such as random bit generation (RBG) inputs, RBG output, copies of the plaintext file, and other keying material, could be very valuable to an attacker who wishes to decrypt an encrypted file. If the encryption product does not wipe these memory spaces appropriately, an attacker may be able to recreate the encryption key and access encrypted files.

Threat.23: MALWARE_PROPOGATION. A malicious entity on the host device places a (malicious) system file on the USB flash drive that automatically transfers itself to hosts into which the TOE is inserted, thus compromising the integrity and security features of that host.

20.2 Security Assumptions, Objectives, and Key Capabilities

20.2.1 Security Assumptions In the following, we list assumptions, which are made regarding the operation of the SMART BEAR platform, and whose satisfaction is a prerequisite for the effective protection of the security and privacy of the platform and/or its users. The term "TOE" in the following means "Target of Evaluation" and refers to the SMART BEAR platform. Assumption.1: CONFIG. It is assumed that the TOE’s security functions are configured correctly in a manner to ensure that the TOE security policies will be enforced on all applicable network traffic flowing among the attached networks. This assumption will ensure that threats 8, 11, 12, 14, 18, 19, 22 and 23 probability of happening is low.

Assumption.2: NOTIFY: It is assumed that the mobile user will immediately notify the administrator if the Mobile Device is lost or stolen.

Assumption.3: PRECAUTION: It is assumed that the mobile user exercises precautions to reduce the risk of loss or theft of the Mobile Device.

Assumption.4: De-personalisation of individual participant data transferred via the mobile application or the HomeHub and held in the SMART BEAR platform.

Assumption.5: Confidentiality of participant data held in the SMART BEAR platform

Assumption.6: No_General_Purpose. There are no general-purpose computer capabilities, e.g. compilers, available on DBMS servers, other than those services necessary for the operation, administration and support of the DBMS.


Assumption.7: Connect: All connections to and from remote trusted IT systems and between separate parts are physically or logically protected within the TOE environment to ensure the integrity and confidentiality of the data transmitted and to ensure the authenticity of the communication end points.

Assumption.8: PLATFORM. The TOE relies upon a trustworthy computing platform for its execution. This includes the underlying platform and whatever runtime environment it provides to the TOE.

Assumption.9: PROPER_USER: The user of the application software is not fully negligent or hostile and uses the software in compliance with the applied enterprise security policy.

Assumption.10: PROPER_ADMIN: The administrator of the application software is not careless and administers the software within compliance of the applied enterprise security policy.

20.2.2 Security Objectives The security objectives listed below are based on the protection profiles ([1] [2] [3] [4] [5] [7] ). Security objectives are distinguished into those referring to the SMART BEAR platform and those referring to its operational environment.

20.2.2.1 SMART BEAR Security Objectives Objective.1: COMMS: Protected Communications: To address the network eavesdropping and network attack threats described in 5.2 Security Threats, concerning wireless transmission of Enterprise and user data and configuration data between the TOE and remote network entities, conformant TOEs will use a trusted communication path. The TOE will be capable of communicating using one (or more) of standard protocols like IPsec, TLS, DTLS, or Bluetooth (4.0 or newer). The protocols are specified by RFCs that offer a variety of implementation choices. Requirements have been imposed on some of these choices (particularly those for cryptographic primitives) to provide interoperability and resistance to cryptographic attack. While conformant TOEs must support all the choices specified in the ST, they may support additional algorithms and protocols. If such additional mechanisms are not evaluated, guidance must be given to the administrator to make clear the fact that they were not evaluated. Objective.2: STORAGE: Protected Storage: To address the issue of loss of confidentiality of user data in the event of loss of a Mobile Device, conformant TOEs will use data-at-rest protection. The TOE will be capable of encrypting data and keys stored on the device and will prevent unauthorized access to encrypted data.

Objective.3: AAA: Authorization, Authentication and accounting : To address the issue of loss of confidentiality of user data in the event of loss of a Mobile Device (Threat.20), users are required to enter an authentication factor to the device prior to accessing protected functionality and data. Some non-sensitive functionality (e.g., emergency calling, text notification) can be accessed prior to entering the authentication factor. The device will automatically lock following a configured period of inactivity to ensure authorization will be required in the event of the device being lost or stolen. Authentication of the endpoints of a trusted communication path is required for network access to ensure attacks are unable to establish unauthorized network connections to undermine the integrity of the device. Repeated attempts by a user to authorize to the TSF will be limited or throttled to enforce a delay between unsuccessful attempts.

Objective.4: Mobile Device Integrity: To ensure the integrity of the Mobile Device is maintained conformant TOEs will perform self-tests to ensure the integrity of critical functionality, software/firmware and data has been maintained. The user shall be notified of any failure of these self-


tests. To address the issue of an application containing malicious or flawed code (Threat.10), the integrity of downloaded updates to software/firmware will be verified prior to installation/execution of the object on the Mobile Device. In addition, the TOE will restrict applications to only have access to the system services and data they are permitted to interact with. The TOE will further protect against malicious applications from gaining access to data they are not authorized to access by randomizing the memory layout.

Objective.5: Integrity.SRV: Data Integrity: Integrity of raw participant data and data produced by data analytic tasks

Objective.5: Privacy: Data Privacy: Protection of privacy of users of SMART BEAR platform

Objective.6: Quality: To ensure quality of implementation, conformant TOEs leverage services and APIs provided by the runtime environment rather than implementing their own versions of these services and APIs. This is especially important for cryptographic services and other complex operations such as file and media parsing. Leveraging this platform behavior relies upon using only documented and supported APIs.

20.2.3 Security Capabilities Summary The primary security capabilities required for the SMART BEAR platform are as follows:

• Web Service Security

• Audit covering security-related events

• Security Management for user and domain administration

• Protection of User and TSF data through secure channels

• Cryptographic functionality, including cryptographic algorithms, support of the Transport Layer Security (TLS) protocol, and key management

Protected storage: encryption of data and keys stored on the device to prevent unauthorized access to encrypted data. Access to encrypted data is only provide once the user has been successfully authenticated.

20.3 Security Manager One

20.3.1 Purpose The Security Manager One (SMO) is used to protect SB@Cloud and provide administrative services. The Security Manager One controls the data flow inside the SMART BEAR platform. SMO will act as an API GATEWAY that will be the only exposed interface of the server-side platform making it able to secure and monitor all traffic and requests. The Security Manager provides encryption and administrative services. The encryption provides the capability of SMART BEAR to encrypt the data flow from inside and outside the platform. The administration provides the capability of data access controls.

20.3.2 Functional Capabilities and Interfaces The functional capabilities required for securing the SMART BEAR platform with respect to the threats identified in Sect. 5.2, the assumptions listed in Sect. 5.3.1 are as follows:


• Cryptography: This capability includes the functionality that enables the encryption and decryption of different types of data transmitted to and from the SMART BEAR platform and stored by it whether temporarily or permanently. This capability support for the encryption and decryption of data.

• Key management: This capability includes the functionality covering the generation, storage, distribution and management of keys required for the encryption and decryption of data transmitted to and from the SMART BEAR platform and stored by it whether temporarily or permanently.

• Authentication: This capability includes the functionality that is necessary for authenticating the different types of users of the SMART BEAR platform as well as all the mobile devices, openHAB instances, and applications, which may interact with it. Successful authentication will be required before accessing both certain types of protected SMART BEAR functionality (e.g., mobile devices, back end repository administrative functions), and data. The capability will also enable automatic locks following a configured period of inactivity in order to minimize risks arising from loss or steals of devices and/or user negligence.

• Integrity: This capability includes the functionality that is necessary for checking the integrity of data transmitted across different components of the SMART BEAR platform. It also covers mobile device and software integrity, i.e., secure device booting and performing self-tests to ensure the integrity of critical functionality, software/firmware and data has been maintained. A key element in this is that the user should be notified of any failure of these self-tests.

• Authorization/access control: This capability includes the functionality that checks the authorization rights of the different types of users of the SMART BEAR platform as well as all the devices and applications to access specific data held in different parts of the SMART BEAR platform as well as to invoke and execute different operations of it.

• Auditing: This capability provides functionality that audit the operations which they are used to modify the data in the data repository, updating personal credential and adjust security setting.

• Security configuration: This capability will support the configuration and application of security policies defined by the users and/or administrators of the SMART BEAR platform. Administrator security policies will have precedence over user specified security policies.


21 Appendix 12 – Deployment infrastructure

Cloud deployment technologies are used to place workloads into a cloud computing environment. They provide the foundation to facilitate execution of applications and services. Such technologies range from bare metal to serverless, and enable organizations to realize the benefits of cloud computing. In SMART BEAR, we will examine the following three technology options for cloud deployment: bare metal, VMs, and containers. The selection will be done case by case, evaluating the best solution for each component of the platform. For instance, if the execution of DSS ML algorithms requires a GPU-accelerated Deep Neural Network library, it will be implemented in bare metal, whereas, for modules that are part of microservice-based modules and are stateless and immutable, containers will be used (such as Docker and Kubernetes). For SMART BEAR project, the network infrastructure design is a critical component of the project success, as it will be the backbone service of the whole platform. The network infrastructure design must meet the specific configuration requirements and network management needs for the following devices:

• Structured Cabling

• Servers

• Firewalls

• Routers and Switches

• Rack and Stack

• Automation

• DNS The infrastructure will be built for the purposes of the project will provide a continuous monitoring of the network infrastructure to ensure it is always up and running. An infrastructure lifecycle management will be adopted, to successfully handle the capacity of the available resource and optimize them, based on the resource forecasting. As part of the infrastructure monitoring, the majority of the system modules will be executed in virtual assets (virtual machines), so tools to monitor the activity and performance of the VMs will be used. All the modules will require to pass a series of test to verify that they fulfill their purpose, before they are used in the production. Unit and integration tests will be part of the acceptance criteria to include a component in the final system. Extensive testing in a sandbox environment will be performed, before the integration of each component to the hosting services. Regarding the requirements for high availability (a feature which provides redundancy and fault tolerance) the goal is to ensure that the service is always available even in the event of a failure. To ensure this a number of servers will be set up in a cluster, so that if one server fails the others will continue processing and take on the processing load of the failed server. They will also provide a number of backup internet connections to ensure the services are still accessible on the internet. An automatic failover mechanism will be installed, to provision the uninterrupted service provision in the cases of device malfunctions. Regarding other hardware fault tolerance requirements, RAID setup for the hard drives will be implemented in the servers. It will provide redundancy and fault tolerance, along with a positive impact on performance. Hardware requirements


Data storage and hosting will be in a single location, serving all the pilot studies. The SMART BEAR hosting setup will require a minimum of three hosts, all with access to the Internet and with an individual fixed public IP address. These can be either physical server computers or virtual machines running in a self-hosted data-centre infrastructure. Each computer host must have the following minimum specifications: 4 Core CPU, 4 vCPU or equivalent, 64 GB of RAM for the backend hosts 1 TB SSD Regarding the network, all hosts must be in the same subnet, each with a fixed public IP address, and must be connected to the Internet in order to get updated and to communicate with the smartphone (SB@App) and the HomeHub. The minimum specifications for the network are: 1 GB Ethernet (internal network) Latency max 50ms (internet) 100 Mbits/second for bandwidth (internet) Fixed public IPs (one for each host)

D6 - SMART BEAR Architecture

Documents

Transcript of D6 - SMART BEAR Architecture