Keywords

1 Introduction

Noncommunicable Diseases (NCDs) are one of the major health challenges, and has caused global concern due to its magnitude and high social cost [1]. The four major groups, cardiovascular disease, cancer, diabetes, and chronic respiratory diseases, have caused about 70% of deaths worldwide [2]. In addition, around 15 million people between the ages of 30 and 70 die each year [3].

In Brazil, NCDs account for about 73% of total deaths [2]. They represent a direct impact on the health system, and are among the main causes of hospitalizations [3]. All socioeconomic levels are affected, especially the most vulnerable groups, such as the poor and the elderly [3].

Several risk factors contribute to the development of NCDs and the worsening of people’s health. Some of these risk factors, such as physical inactivity, and unhealthy eating, can be changed since they are related to lifestyle [3]. For preventing and controlling NCDs, it is necessary to promote habit changes, and to provide a comprehensive care to patients [1].

Some NCDs, such as diabetes and hypertension, allow for the self-monitoring of patients. They can record their own clinical data, and provide them to the health professionals, e.g., during their physician’s appointments, becoming in this way active participants in the healthcare process. In Brazil, this is a common practice, mainly when clinical data are involved, such as blood pressure, glucose levels, and weight.

In order to help in the healthcare of NCD patients, we developed MyHealth system by employing Ubiquitous Computing technologies. The NCD clinical data are collected by these patients using appropriated medical equipment, and recorded on their mobile devices. These data are sent automatically to the cloud for further treatment, and can be accessed and analyzed by health professionals, supporting in this way their decision-making related to the adjustments on treatment, and changes in the lifestyle of the NCD patients.

This paper is further structured as follows: Sect. 58.2 discusses some related works; Sect. 58.3 addresses the problem investigated in this work, and gives an overview of MyHealth system; Sect. 58.4 describes the methodology employed for developing this system; Sect. 58.5 deals with the design, and implementation of MyHealth; and Sect. 58.6 presents our concluding remarks and gives recommendations for future work.

2 Related Work

The literature presents several works looking for solutions to monitor NCD patients. We selected four of them for reporting in this paper, and for comparing with our work.

A system is proposed in [4] for monitoring NCD patients, where clinical data are automatically collected through medical equipment with wireless capacities. These data are transmitted to a server, becoming available for analysis by health professionals. In addition, patients can ask for physician’s appointments, and can send out a SOS for immediately care.

A framework based on ontologies is proposed in [5] for customizing a mobile application to monitor NCD patients. This customization involves parameters, such as the NCD type, patient preferences, monitoring procedure required by the physician, prescribed medication, and patient environment. All this information determines the data to be acquired from the patient, through questionnaires, and/or sensors.

A prototype based on Arduino, and on an Android application is proposed in [6] for monitoring patients with diabetes mellitus. A glucometer with Bluetooth capacity is employed to measure the glucose level, and to transfer it to a mobile application. This application is connected to a server that provides this clinical data for medical service purposes, or to be used during physician appointments.

An approach based on machine learning is proposed in [7] for diagnosing and monitoring heart disease through a mobile application. The clinical data are collected by sensors, and sent to the mobile application via Bluetooth. Then, they are relayed to the cloud for treatment, where classifiers are employed to determine the presence or absence of heart disease.

All these works aim to monitor patients with some specific NCD, and they employ sensors or medical equipment with wireless capacities to directly communicate with mobile devices. Since in Brazil these medical equipment are expensive, mainly for low-income populations, the Brazilian Unified Health System (SUS) provides some of them for free [8]. This was our main motivation for developing MyHealth, a system that allows the patients to manually collect NCD clinical data using SUS’s equipment, and to store these data in their mobile device, which is a very popular technology in Brazil.

3 Problem Description

Since the NCDs are the most significant group of diseases in Brazil, the Brazilian Ministry of Health launched in 2011, in partnership with other institutions, the Strategic Action Plan to Tackle Noncommunicable Diseases [9]. This plan has three main foundations: surveillance, information, evaluation and monitoring; health promotion; and comprehensive care [9]. A set of actions and investments, for the prevention and control of NCDs, were defined to be applied up to 2022. One main goal of comprehensive care is to promote the continuous follow-up of NCD patients [3].

Ubiquitous Computing and Cloud Computing have been employed in Mobile Health (mHealth), mainly in the design of patient monitoring systems. According to the Brazilian Institute of Geography and Statistics (IBGE), in 2017 about 78.2% of the Brazilian population had a mobile phone, and about 74.9% of Brazilian households had internet access, where 97% of this access was done through mobile phone [10].

Considering the Brazilian public policies for prevention and follow-up of NCD patients, and the widespread use of mobile phones in Brazil, we developed the MyHealth system for assisting the monitoring of NCD patients. An overview of this system is illustrated in Fig. 58.1.

Fig. 58.1
figure 1

Overview of MyHealth system

MyHealth is composed of three main modules: Mobile App, a mobile application that alerts the patient to collect his clinical data, allows the patient to register this data in his mobile device, and sends automatically the registered data to the cloud; API Server provides an Application Programming Interface (API) for storing and retrieving the patient clinical data in the cloud; Web App provides and interface for accessing and visualizing the patient clinical data in the cloud.

The patient is responsible for collecting his clinical data using the medical equipment provided by SUS (e.g., pressure monitor, scale, and blood glucose monitor), and for recording these data in the Mobile App. The health professionals (e.g., physician, physiotherapist, and nutritionist) are responsible for accessing the patient clinical data using the Web App, and for analyzing these data for decision-making regarding the patient health.

4 Development Methodology

MyHealth was developed according to Test-Driven Development (TDD), an agile software development method, based on short development cycles, in which automated tests are described previously to the production of code [11]. These tests specify and validate what the code must do [12].

Each TDD cycle is divided into three stages: write an automated test for a small functionality, and considering that this test was developed before the functionality code, it should be fail; then develop a minimum code in order for this functionality to pass the test; and refactor this functionality code for optimization purpose [13]. This cycle avoids code duplication, makes the code clearer, simple and bug-free [11]. Figure 58.2 illustrated this cycle with the Collect Data functionality of MyHealth, which allows the patient for recording his clinical data in the Mobile App.

Fig. 58.2
figure 2

TDD cycle for Collect Data functionality

As shown in Fig. 58.2, first a test for the persistence validation of the patient’s clinical data in the database is written. This test should receive a valid identifier of the data registration in the database, and since the Collect Data functionality was not implemented yet, it will be fail. Then, a minimum code for the Collect Data functionality is produced for passing this test. Finally, this code is refactored for eliminating duplicates, and for increasing it readability and maintainability, always ensuring that it continues to pass this test.

5 MyHealth Design

MyHealth was designed in three main phases: system specification, where the system requirements were identified, analyzed, and formal described; system architecture, where the system was structure into modules; and system implementation, where the system functionalities were implemented and tested using TDD.

5.1 System Specification

At this phase the system requirements were captured, and specified employing the Use Case diagram, and the Sequence diagram of Unified Modeling Language (UML). Figure 58.3 shows the Use Case diagram for Mobile App, focusing in the main actors, functionalities, and interactions of this application.

Fig. 58.3
figure 3

Use Case diagram for Mobile App

Figure 58.3 shows two actors interacting with Mobile App: Patient and Background Service. The first one represents the NCD patient who must register himself in MyHealth, using the Register Patient functionality, and must record his clinical data, using the Collect Data functionality. The second one represents a service that runs in background at patient’s mobile device, for alerting the patient to collect his clinical data, using the Alert Patient functionality, and for sending this data to the cloud, using the Synchronize Data functionality.

Each use case can be refined through a Sequence diagram, for allowing the visualization in time sequence of the interactions needed to perform the corresponding functionality. Figure 58.4 shows an example of this diagram for the Collect Data functionality.

Fig. 58.4
figure 4

Sequence diagram for Collect Data of Mobile App

The following time sequence, for performing the Collect Data functionality, is shown in Fig. 58.4: first the Patient must insert his clinical data into an application form that is displayed in the Screen of his mobile device; then this data is sent to a CollectController, which creates a new Register instance, validates the data, and persists it into the database; and finally a printing of all patient clinical data is displayed in the Screen of his mobile device.

5.2 System Architecture

At this phase the system was structured, according to the client-server architecture, into three modules: API Server, Mobile App, and Web App. Figure 58.5 shows this architecture.

Fig. 58.5
figure 5

MyHealth architecture

API Server is the only module that communicates directly with the database, providing a secure API to Mobile App and Web App client modules to store and retrieve all MyHealth information.

Mobile App is an application for mobile devices with Android operating system. It employs 3G/4G or Wi-Fi networks for internet connection, which is needed only for the patient registration, and for data synchronization. The patient’s clinical data is stored in a local and small database of his mobile device. This application also allows for the patient obtaining an access token, who must forward it to the health professional, for enabling him to access the patient information through the Web App module.

The Mobile App components are organized according to the Clean Architecture, which aims for separating responsibilities across layers, and whose main rule is “the component dependencies can take place only from the outermost to the immediately innermost layer” [14]. Figure 58.6 shows an example of this component organization through the UML Class diagram, focusing on the Syncronize Data functionality.

Fig. 58.6
figure 6

Class diagram for Syncronize Data functionality

As shown in Fig. 58.6, there are three main layers: repository is the outermost layer, it encapsulates the APIClient class that converts the data received from SyncronizeData class to the format to be sent to the API Server; usecases is the intermediate layer, it encapsulates the SyncronizeData class that implements the business rules of this functionality, and depends on the Register class; and entities is the innermost layer, it encapsulates the Register class that has no dependencies with another class.

Web App is an application hosted in the cloud, which enables health professionals for accessing and visualizing their patient’s clinical data through charts. This access is granted by each patient forwarding a token to his health professional. In order to generate this token, Mobile App and Web App modules communicate through the API Server.

5.3 System Implementation

At this phase, the functionalities defined in the specification phase were implemented. For example, an important requirement of Mobile App is to allow the patient to record his clinical data regardless the mobile device is connected or not to the internet. For carrying out this requirement, a service that runs in the background on the mobile device was implemented. This service checks every minute if the device is connected to the internet and if so calls the SynchronizeData functionality, which in turn sends the clinical data to the cloud. Figure 58.7 shows an implementation excerpt of this service, focusing on the SyncService class.

Fig. 58.7
figure 7

Excerpt of the SyncService class

Two other important requirements of Mobile App are to ensure compatibility with most Android-based mobile devices, and to ensure security of the data stored on these devices. For carrying out the first one, Mobile App was implemented using the Android development API version 19, becoming this application compatible with 96.2% of the Android-based mobile devices [15]. For carrying out the second one, the data is stored using the SQLite library with the extension SQLChipher, which provides 256-bit AES encryption for the database.

Figure 58.8 shows two screenshots of the Mobile App User Interface (UI): (a) the UI for allowing the patient to record his clinical data, where the data fields are displayed according to the monitored NCD; and (b) the UI for allowing the patient to visualize his clinical data already recorded, and the ones already sent to the cloud.

Fig. 58.8
figure 8

Mobile App UI: (a) data collecting (b) data history

Web App was implemented in JavaScript using the ChartJS framework, which is responsible for generating the patient clinical data graph. Figure 58.9 shows the UI displayed to the health professional for the patient clinical data visualization. These data are presented through a dynamic chart, where filters, such as the type of clinical data, and time interval to be analyzed, can be specified. The health professional can also obtain details of the clinical data recorded by the patient on a specific day (e.g., time of registration, and observations), by positioning the cursor at certain points on the chart.

Fig. 58.9
figure 9

Web App UI for visualizing the patient’s clinical data

Finally, the API Server was implemented in JavaScript language, and runs over Node, a server-side JavaScript code interpreter. This module uses the Express framework for the implementation of its API, employs the HTTPS protocol for communicating with the other modules of MyHealth, and uses the PostgreSQL database.

6 Conclusion

This paper presented MyHealth, a system that employs Ubiquitous Computing technologies to support the healthcare of patients with certain NCDs. This system allows for storing, treating, and sending to the cloud the patients’ clinical data, which are collected by them using low cost medical equipment, some of these provided for free by the Brazilian Unified Health System. These treated data are them made available to the health professionals, supporting in this way the decision-making process.

Our next work is to evaluate the MyHealth performance, and the usability of this system as perceived by patients and health professionals. As future work, we intended to extend MyHealth with technologies of Internet of Things (IoT) to allow the automatic collecting of patients’ clinical data by wearable sensors.