## 4 Architecture  
The HealthTracker system was designed with the objective to develop a monitoring infrastructure for patients to store and analyze data provided by devices and store them as a time series so that it can become a medical support tool helping healthcare personnel to evaluate the health conditions of their patients without the need for a face-to-face visit. In its design, we adhered to the following two key principles:1. ease of use: since elderly people are the main portion of our target user base, it is important that the interaction with the system--especially the recording process--is as simple as possible;
2. service-orientation: the use of a microservices architecture, supported by the main cloud technologies, is fundamental to achieve optimal performance while keeping the system running smoothly [15]. Specifically, rather than using the \"one-size-fits-all\" approach as in a monolithic application architecture, a microservices architecture allows the use of a different technology stack for each microservice independently of the others to achieve the desired performance levels. Also, since microservices are loosely coupled, if one microservice needs to improve its performance, it is possible to replace its technology stack with a better one without affecting the other microservices. Finally, microservices are easier to scale than a monolithic application as it is possible to scale only selected services (i.e., the only ones that actually need to be scaled) rather than the whole \"giant\" application. To achieve these goals, we designed and built a software and hardware infrastructure whose architecture is shown in Figure 1, where solid red boxes denote the hardware devices and dashed shapes represent third-party components (e.g., a cloud computing platform) that are used by HealthTracker to run some of its components (e.g., the time-series database). Inside both red boxes and dashed shapes, we indicate with blue boxes the microservice or the communication interface exploited by the hardware component (both explained in detail in Section 6). Finally, arrows denote interactions between components (e.g., an arrow from component \(C_{i}\) to component \(C_{j}\) means that \(C_{i}\) uses the functionality of \(C_{j}\)). As shown in Figure 1, HealthTracker encompasses three distinct subsystems:  
1. a set of Monitoring Devices, which collect patients' health data. As discussed later in the paper (Section 5), as part of this work, we designed and built a novel monitoring device (the _HDC_ device), and we developed the code to interface with a commercially available one (the Viatom CheckMe O2 device);
2. an Android smartphone, running the HealthTracker app that interfaces with the monitoring devices to both control their behavior and retrieve the health data they collected. This app is responsible for user authentication and communication with the monitoring device, as well as for data collection and storage in the cloud. As discussed later in the paper (Section 6.1), the communication protocol between devices and mobile apps can be customized, so other devices, in addition to the currently supported ones, can be integrated into HealthTracker;
3. a Cloud Computing Platform, which provides both secure storage and offline processing for collected health data, and is composed of the following components:  
Figure 1: The architecture of HealthTracker.