HBPF: a Home Blood Pressure Framework with SLA guarantees to follow up hypertensive patients

HM architecture

The cloud-based architecture of HM scales easily with increasing number of patients, physicians, and hospitals. This is done by using the SLA to adjust the number of available Virtual Machines (VMs, widely used in cloud computing environments) and the number of requests entering the module (see Mateo et al., 2014; Vilaplana et al., 2014b; Vilaplana et al., 2014c; Vilaplana et al., 2015 for more information).

The current HM architecture is made up of 2 hosts (nodes), each with one AMD Opteron 6100 processor of 12 cores running at 2.1 GHz (see Fig. 3). We plan to add more hosts as the system grows. Note that nodes can be different, conforming a heterogeneous framework. All the software technologies used to implement HBPF were carefully selected with several criteria in mind. First, they had to be open-source, in order to facilitate future shared development of the apps. In addition, these technologies had to be robust, efficient, and be widely deployed and supported. VMs are deployed across the hosts on top of the OpenStack (http://www.openstack.org). OpenStack is an open source Cloud platform that allows to manage and deploy large networks of Virtual Machines. All the VMs run Ubuntu GNU/Linux 3.2.0-41-virtual x86_64. We believe in a distributed design because the degree of administrative and geographic scalability increases with the number of hosts.

The scheduler is mapped into a VM with 512 MB RAM and 1 core in host 1. It is implemented using the Scheduler of Apache Tomcat7. The rest of VMs, that service the requesting tasks, are provided with 4 GB and 2 cores. These VMs are the computing VM nodes, where the HM module copies (each performing the same operation) are deployed on top of Apache Tomcat (http://tomcat.apache.org/), an open-source web server developed by the Apache Software Foundation (ASF).

Task scheduling determines which VM executes the tasks. VM consolidation instead determines the mapping of VMs to hosts. The HM task scheduling and VM consolidation follows a Round-robin policy, which states that tasks (VMs) are assigned to VMs (hosts) by following a circular ring ordering.

All VMs are configured with the AJP (Apache JServ Protocol—Apache Tomcat Connector) protocol enabled, which is used by the scheduler to communicate with the nodes. AJP is a protocol that can proxy inbound requests from a web server (Apache HTTP server) to an application server (Tomcat).

The database is implemented using a MySQL Cluster (https://www.mysql.com/products/cluster/), a technology that provides shared-nothing clustering and auto-sharding for the MySQL database management system. The database is distributed between the hosts (nodes) making up the cloud framework. The MySQL Cluster is implemented with 2 VMs with 4 GB RAM and 2 cores (of two different hosts). Having multiple computing and data-sites ensures a high degree of load and administrative scalability and reliability.

BP design

Currently, there are many alternative technologies for developing applications for mobile devices. An important design requirement was that the application should be compatible with all the major platforms Android and iOS. Because of this, the BP app was implemented using HTML, CSS, Javascript, JQuery Mobile and PhoneGap (http://phonegap.com).

PhoneGap is an open-source development tool for creating cross-platform mobile applications with countless libraries available for use. PhoneGap has APIs to control I/O devices efficiently (such as cameras, GPS, databases, file system, etc.) in a similar way to those obtained with native code. Phonegap currently supports the two mainstream platforms (Android and iOS).

The features that retrieve information from HM need to establish a connection by means of web services. This ensures low data capacity requirements and avoids legal problems, as medical data is only stored in HM instead of in each individual smartphone. However, this introduces a low penalty in obtaining the required information remotely, although it does not significantly affect the user experience. We created ad hoc web services, which are used to exchange data in JSON format between the clients (BP instances) and the server (HM).

BP operation

The BP app can be used to register patients, edit their profile, download or upload data regarding blood pressure and pulse readings from/to the HM server, visualize informative videos uploaded by the clinicians, analyze patient trends by plotting and listing the evolution of the patients’ state and readings, and provide information about collaborating hospitals. Finally, BP can be used for chatting (instant messaging) between patients and clinicians. Whenever required, a patient can easily ask the doctor a question through the chat window.

The application also helps the patients with useful advice. Once the blood pressures and the pulse have been sent, the app immediately shows the results of the analysis (done in HM) through a traffic light indicating the status of the patient. In addition, a short message indicates medical advice. The medical advice depends on the results of the analysis of the readings.

There are three possible states (light colors) and three associated messages:

1. Good (green). Everything was fine. Remember to keep measuring and sending your pressure readings.

2. Regular (yellow). Do not forget, salt-free diet. Remember to take the medication and do some physical activity.

3. Bad (red). We have seen your records, do not worry. We will contact you to bring your next clinical appointment forward.

BP can show a graphic evolution of the patients’ measurements. Different types of visualization can be chosen. By clicking global, the plot of the blood pressure (Fig. 4) appears. The morning and afternoon buttons separate the samples by these times of day. Start and finish dates can be selected. Alternatively, 1, 3 and 6 months selectors are available.

Testbed

Experiments on the HM tool were carried out on five Virtual Machines [VM1 … VM5] deployed over OpenStack, installed on a host with 1 AMD Opteron processor with 12 cores running at 2.1 GHz each. To emulate VM heterogeneity, we set VM1 … VM5 with 4 GB RAM and 2 cores.

Application stress tests via HTTP requests were performed using the Apache JMeter (http://jmeter.apache.org/) tool, which measures performance and functional behavior. These requests simulated patients consulting or introducing their data and clinicians using HM.

The effect of number of simultaneous requests on HBPF performance was tested by systematically varying the number of users. There were generated 100 requests per user. All users would be performing their requests within a single 50 s period. The time between user requests was constant and therefore these requests were uniformly distributed in the 50 s test interval.

The performance metric we used was the Response Time and Throughput, as these parameters are widely used for measuring system efficiency. Throughput was also the parameter chosen to fix the SLA.

Response time

Testing the response time of the application was done using all five available VMs. Figure 5 summarizes the response time of the system in terms of the median, average and 90% Line when the number of users increased from 200 to 800. The 90% Line (or 90th percentile) is the value below which 90% of the samples were processed in less than the time specified on the y-axis. This metric is more meaningful than the median or average value in terms of SLA (Service Level Agreement). Although the system starts to overload at 80,000 requests (i.e., 800 users), the average and median response time still remains below 1 s (the users will not notice a lack of interactivity with the system). Obviously, worse results were obtained for the 90% Line (1,7 s).

Throughput

Another measure of efficiency is throughput (TR), which is defined as the number of requests served per unit of time: (1)${\displaystyle \mathrm{TR}=\frac{\text{number}\text{of}\text{requests}}{\text{time}}.}$

Here, we benchmark the effect of changing the number of available VMs on the TR and the number of users from 50 to 800. Figure 6 compares the TR of the system when we use one (VM1), three (VM1–VM3), or five VMs (VM1–VM5). Figure 6 summarizes the results.

A general feature of the system’s response is that TR increases linearly with the number of requests, until it peaks at approximately 40,000 requests (30,000 for 1 VM). After this threshold, TR performance decreases slightly and the SLA is not guaranteed. We note that the SLA should be fixed according to the required TR, depending on the number of requests and the number of VMs available. This behaviour is consistent with previous simulations of a similar model system, using an approach based on queuing theory (Vilaplana et al., 2013; Vilaplana et al., 2014b).

Going from one to three VMs leads to an increase in peak TR of 28.5%. In contrast, going from three to five VMs leads to an increase in peak TR of approximately 16.8%. This suggests that peak relative performance increment decreases every time additional VMs are activated. Internal tests suggest that this loss was due to the delay introduced by the remote communication between VMs located in different cores, which is a known frequent bottleneck in distributed computing applications.

Thus, as was the case in the simulated system (Vilaplana et al., 2013; Vilaplana et al., 2014b), we face a situation where our system overloads, leading to a significant increase in the response time and a decrease in TR. However, in contrast with the simulated system, adding more VMs to the real HBPF system only partially solves the problem, and a law of diminishing returns is observed with an increase in number of VMs. Overall, these experiments suggests that the most efficient strategy for distributing work between VMs allocated to HBPF is to first deploy work to local VMs. When these are saturated, work should then be sent to remote VMs.

Scalability

We also investigated the scalability of the system in its cloud environment by using an event-driven simulator to test the behaviour of that environment. We use the CloudSim 3.0.2 software (Calheiros et al., 2011) in these tests because it allowed us to easily emulate the HBPF architecture presented and evaluated in ‘HM architecture’ and ‘HM’ respectively. CloudSim allows the behaviour of the AMD Opteron 6,100 (the one chosen for this simulation) to be emulated. The CloudSim task scheduling and VM consolidation followed a Round-robin policy. As we chose the same processor and scheduling policies as the HM architecture (see ‘HM architecture’), the results obtained in the simulation should be directly applicable to the real system.

Figure 7 shows the system behavior when scaling it by increasing the number of VMs and hosts. VMs were made up of 2 cores and 4 GB each. As in ‘HM’, one host was made up of one processor. The simulation environment was carried out by executing 1,000 tasks with a size of 100,000 instructions each. Further experiments varying these parameters gave proportional results.

We can appreciate that increasing the number of VMs and hosts significantly decreases the total execution time (in time units) of the overall tasks. Figure 7 shows that by adding VMs, the performance approaches asymptotically to a limit where it does not have enough computational resources (RAM, CPUs, etc. making up the hosts) to map the tasks, and so the execution time stabilizes. Similar behavior occurs when adding more hosts without adding more VMs.

Performance

Typically, two important bottlenecks in application performance are the start up of the app and the operational processes in which that app accesses Internet.

BP was installed and tested on smartphones and tablets running modern versions of Android and iOS. The devices and operating systems used to verify the correct operation of BP are listed in Table 2. This table shows the elapsed time of the start up for BP. These times were the average of three independent measurements.

The cross-reference APIs used by PhoneGap introduced a considerable penalisation in the BP start up time (10 ms). However, the application performed well in all the tested devices. In all cases, overall response time fell below one second, which guarantees that the user’s flow of thought is uninterrupted (Miller, 1968).

The communication time sending a chat message to HM was also measured. To do so, we computed the average time for all Android and iOS devices. We tested two types of connections, WiFi (with 100 Mb/s download and 10 Mb/s upload speed) and 4G Data Internet. Each experiment was repeated 10 times per device. Communications were very fast, taking on average 329 ms for WiFi and 861 ms for 4G. WiFi bandwidth was entirely dedicated to communications done using the BP app. This validates the design of the communication mechanism between the app and HM.

Usability

Here we perform a preliminary evaluation of BP’s usability. This was done by asking both, clinicians and patients, to fill in a Google-forms questionnaire. This questionnaire was sent by the HM server to all 90 registered patients and the three clinicians of the Clinic hospital of Barcelona. 38 patients and all the clinicians answered it. Table 3 summarizes the results of this evaluation. This table only shows the affirmative answers.

Clinicians are highly satisfied with the app and all are convinced of its usefulness and efficiency. In addition, they don’t find its use monotonous. In addition, two of the three clinicians found BP very easy to use. We note that these evaluations are anecdotal and a larger number of clinicians must answer the survey before we can come to a reasonable conclusion about usability of BP from the clinician’s point of view. In terms of user evaluation, we focus more on the feedback from patients than that from clinicians for two reasons. First, patients will be the vast majority of final BP users. Second, we need to obtain input from additional clinicians, given the low number of professionals that answered the survey. Between 54% and 87% of all patients reported full satisfaction with the various aspects of using the BP app, indicating that they are mostly happy with the application. The weakest point we detected was that 39% of the patients found the use of BP monotonous. This is in striking difference with the clinicians that had the opposite opinion. We need to further and specifically understand what the patients found boring in order to improve that aspect of the app.

In general, clinicians and patients recognized the usefulness of the app for remote monitoring of hypertensive patients and to reduce traveling costs. We note that we are now in the process of compiling patient and clinician suggestions to help us improve the user-friendliness of the app.