HBPF: a Home Blood Pressure Framework with SLA guarantees to follow up hypertensive patients A peer-reviewed version of this preprint was published in PeerJ on 13 June 2016. View the peer-reviewed version (peerj.com/articles/cs-69), which is the preferred citable publication unless you specifically need to cite this preprint. Cuadrado J, Vilaplana J, Mateo J, Solsona F, Solsona S, Rius J, Alves R, Camafort M, Torres G, Betriu A, Gutierrez JM, Fernández E. 2016. HBPF: a Home Blood Pressure Framework with SLA guarantees to follow up hypertensive patients. PeerJ Computer Science 2:e69 https://doi.org/10.7717/peerj-cs.69 https://doi.org/10.7717/peerj-cs.69 https://doi.org/10.7717/peerj-cs.69 HBPF: a Home Blood Pressure Framework with SLA guarantees to follow up hypertensive patients Josep Cuadrado, Jordi Vilaplana, Jordi Mateo, Francesc Solsona, Sara Solsona, Josep Rius, Rui Alves, Miquel Camafort Hypertension or high blood pressure is a condition on the rise. Not only does it affect the elderly but is also increasingly spreading to younger sectors of the population. Treating it involves exhaustive monitoring of patients. A tool adapted to the particular requirements of hypertension can greatly facilitate monitoring and diagnosis. This paper presents HBPF, an efficient cloud-based Home Blood Pressure Framework. This allows hypertensive patients to communicate with their health-care centers, thus facilitating monitoring for both patients and clinicians. HBPF provides a complete, efficient, and cross-platform framework to follow up hypertensive patients with an SLA guarantee. Response time below one second for 80,000 requests and 28% increase in peak throughput going from one to 3 virtual machines were obtained. In addition, a mobile app (BP) for Android and iOS with a user-friendly interface is also provided to facilitate following up hypertensive patients. Among them, between 54% and 87% favorably evaluated the tool. BP can be downloaded for free from the website Hesoft Group repository (http://www.hesoftgroup.eu). PeerJ Preprints | https://doi.org/10.7287/peerj.preprints.2073v1 | CC-BY 4.0 Open Access | rec: 25 May 2016, publ: 25 May 2016 HBPF: a Home Blood Pressure Framework with SLA1 guarantees to follow up hypertensive patients2 Josep Cuadradoa, Jordi Vilaplanab, Jordi Mateob, Francesc Solsonaa,b,1,3 Sara Solsonaa, Josep Riusb, Rui Alvesc, Miquel Camafortd4 aHesoft Group, Partida Bovà, 15, E-25196, Lleida, Spain5 bDepartment of Computer Science & INSPIRES, University of Lleida. Jaume II 69,6 E-25001 Lleida, Spain7 cDepartament of Basic Medical Sciences & IRBLleida, University of Lleida, Avda.8 Alcalde Rovira Roure 80, E-25198 Lleida, Spain.9 dDept. of Internal Medicine, Clinical Institute for Medicine and Dermatology, Hospital10 Cĺınic, Institute of Biomedical Research Agust́ı Pi i Sunyer (IDIBAPS), University of11 Barcelona, Hospital Universitari Villarroel 170, E-08036, Barcelona, Spain.12 Abstract13 Hypertension or high blood pressure is a condition on the rise. Not only14 does it affect the elderly but is also increasingly spreading to younger sectors15 of the population. Treating it involves exhaustive monitoring of patients.16 A tool adapted to the particular requirements of hypertension can greatly17 facilitate monitoring and diagnosis.18 This paper presents HBPF, an efficient cloud-based Home Blood Pres- sure Framework. This allows hypertensive patients to communicate with their health-care centers, thus facilitating monitoring for both patients and clinicians. HBPF provides a complete, efficient, and cross-platform frame- work to follow up hypertensive patients with an SLA guarantee. Response time below one second for 80 000 requests and 28% increase in peak through- put going from one to three virtual machines were obtained. In addition, a mobile app (BP) for Android and iOS, with a user-friendly interface, is also provided to facilitate following up hypertensive patients. Among them, be- tween 54% and 87% favorably evaluated the tool. BP can be downloaded for free from the website Hesoft Group repository (http://www.hesoftgroup.eu). Email addresses: jcuadrado@hesoftgroup.eu (Josep Cuadrado), jordi@diei.udl.cat (Jordi Vilaplana), jmateo@diei.udl.cat (Jordi Mateo), francesc@diei.udl.cat (Francesc Solsona), sara@hesoftgroup.eu (Sara Solsona), jrius@diei.udl.cat (Josep Rius), ralves@cmb.udl.cat (Rui Alves), camafort@clinic.cat (Miquel Camafort) 1Corresponding author 1. Introduction19 Hypertension is one of the most important risk factors in cardiovascular20 diseases, the leading cause of death worldwide [1]. It affects about 20% of21 the adult population, a percentage that increases with age [2].22 Home blood pressure (HBP) consists of patients taking readings at home23 and registering these using a digital device. The patients then send the24 readings to a health professional who is responsible for taking appropriate25 action [3].26 In a recent scientific article, the American Heart Association concluded27 that HBP monitoring should become a routine component of blood pressure28 measurement in the majority of patients with known or suspected hyperten-29 sion [3]. HBP readings may also be better predictors of cardiovascular and30 renal outcomes than surgery readings [4, 5]. Furthermore, HBP readings31 provide a more accurate assessment of true blood pressure than alternative32 measurement methods, such as surgery blood pressure or rapid titration of33 antihypertensive therapy. They also avoid the white-coat syndrome and fa-34 cilitate the identification of masked hypertension, leading to a greater patient35 involvement in managing hypertension, a condition that is typically asymp-36 tomatic [6].37 Having ways to monitor HBP in a continuous and rigorous way, with a38 fluid communication between patient and doctor may be crucial in ensuring39 satisfactory control of blood pressure, which is currently a great challenge.40 Information and communication technology (ICT) can play an important role41 in achieving this monitoring capabilities [7, 8]. In this context, we developed42 and present HBPF (Home Blood Pressure Framework). HBPF is made up of43 two parts, the HM (Hypertension Module) server and the BP (Blood Pressure44 monitoring) mobile app.45 HBPF provides high performance for a given SLA (Service Level Agree-46 ment). An SLA is a contract negotiated and agreed between a customer47 and a service provider for which a customer only pays for the resources and48 services used according to negotiated performance requirements at a given49 price [8, 11]. Throughput is one of the most important performance metric50 in a cloud-computing context [8, 11]. It was also the performance parameter51 chosen in this work to fix the SLA.52 Frameworks such as HBPF generate large amounts of data that need to53 be continuously stored, processed, and available. This require the use of54 cloud computing services [12]. Earlier versions of the concept underlying55 2 HBPF [8, 11, 13] were tested in a private cloud-based server, before mov-56 ing the HM into a real-world cloud environment. These applications used57 SMS communications between clinicians and patients. This was limiting in58 many ways. The current platform uses Internet communication, providing59 physicians with access to standard medical records and allowing them to60 write reports and to follow up and communicate (i.e. charting and sending61 videos) with patients by means of HBPF. Efforts were made to design a scal-62 able framework when the number of both patients and hospitals increased63 by providing Service Level Agreement (SLA) guarantees [13, 14, 15, 16, 17].64 The remainder of the paper is organized as follows. Section 2 details the65 related work addressing the problem of tele-moritoring hypertensive patients.66 In Section 3.1, we present HM. Section 3.2 is devoted to explaining the op-67 eration and functionality of the BP app. This app and its performance is68 evaluated in Section 4. Finally, Section 5 outlines the main conclusions and69 future work.70 2. Related Work71 There is a potentially important role for novel techniques to lower er-72 rors in collecting blood pressure readings, especially in primary care, where73 management of hypertension mainly takes place [6, 18]. One such techniques74 is mHealth - health care and public health practice supported by mobile75 devices [19].76 Earlier work identified 60 web sites that provided functionality to manage77 and present home blood-pressure readings. Out of these, 20 could be freely78 used. A comparison between these 20 web sites was carried out between June79 and August 2009 [20]. The results showed that none of these 20 web sites80 were directly linked to common electronic medical records. In addition, none81 of them provided any tools for sending alert messages in any format.82 Studies have shown the positive impact of mHealth on adherence-related83 behavior among patients. For example, short message service (SMS) ap-84 pointment reminders have led to an increase in attendance of HIV [21], tu-85 berculosis [22], and quitting tobacco patients [11, 13]. Patient-physician86 short messaging through a telemedicine system was also tested as a means87 to improve control of hypertension in the follow-up of medium-to-low-risk88 patients in primary care [23]. A control group (CG) recorded the data on89 paper and could only deliver it to their GP personally in routine visits. This90 study showed that 50% of the telemedicine-enabled patients strictly adhered91 3 to the treatment protocol, versus 25% in the CG. This suggests that more92 flexible and continuous ways of interaction and follow up of patients might93 have a greater impact in treatment adherence.94 A study among 107 mHealth articles assessed the role of adherence of95 patients to chronic diseases management [24]. 40.2% (43/107) of studies96 used SMS exclusively and 23.4% used specialized software or a smartphone97 app. These programs focused mainly on a combination of devices, such as an98 electrocardiogram or a BP monitor. As a conclusion, the authors suggested99 that future mHealth tools need to provide optimal user-interfaces, or targeted100 motivational messages.101 With all this in mind, we designed and implemented HBPF to include a102 flexible and user friendly interface that provides motivational messages to the103 patients and enable immediate and real-time communication between patient104 and physician by means of the BP app. In addition, the app provides self-105 monitoring, reading sampling, charts, reports, tips, and advice, in line with106 other existing hypertension apps (see Table 1, for a comparison of the main107 features between the various apps). However, with the exception of BP, none108 of the apps features on-line physician support for the patient, chat between109 physician and patient, or broadcasting communication among a group of110 patients. In addition, BP is the only app available for both, iOS and Android111 operating systems.112 app DC NC Charts RH AB AP OS BP Lite No No Yes Yes No No iOS iBP No No Yes Yes No No iOS IBPTouch No No Yes Yes No No iOS BPMonitor No No Yes Yes No No iOS BP Yes Yes Yes Yes No No iOS/Android iCare BP Monitor No No Yes Yes No Yes Android BP Watch No No Yes Yes No No Android Finger BP Prank No No No No No Yes Android Table 1: Comparison between BP with other similar hypertension apps. app: Application name. DC: Doctor Chat (direct chatting with the physician). NC: Nearby centers (pro- vides information about the distance to specialized centers). Charts: graphical evolution Charts. RH: Readings’ History. AB: Automatic sampling of the Blood Pressure by means of an external device. AP: Automatic sampling of the pulse rates by means of an external device. OS: Operating System. 4 https://itunes.apple.com/us/app/blood-pressure-lite-bp-tracker/id534134435?mt=8 https://itunes.apple.com/us/app/ibp-blood-pressure/id306526794?mt=8 https://itunes.apple.com/kh/app/ibptouch-blood-pressure-tracking/id307828432?mt=8 https://itunes.apple.com/us/app/bpmonitor/id423175333?mt=8 http://www.hesoftgroup.eu/index.php?option=com_content&view=article&id=87&Itemid=220 https://play.google.com/store/apps/details?id=comm.cchong.BloodPressure https://play.google.com/store/apps/details?id=com.boxeelab.healthlete.bpwatch https://play.google.com/store/apps/details?id=com.galaxyfinger.fingerboodstar HBPF provides a means to communicate across a wide range of platforms113 and devices with a doctor, as does HealthTap. In addition, HBPF provides a114 complete, efficient, and cross-platform framework to follow up hypertensive115 patients with an SLA guarantee. Furthermore, the transparent architecture116 of HBPF was designed to facilitate the involvement of additional third par-117 ties, and the integration with existing healthcare systems, while providing118 ad-hoc adaptation of monitoring parameters to each individual, in a similar119 way to [25].120 3. HBPF121 Fig. 1 summarizes the overall operation of HBPF. First of all, patients122 send their readings with the BP app from a smart phone to the server (1),123 via Internet (2).124 Mobile Clinician Internet Blood pressure Pa5ent database Server 1 2 3 5 4 HM BPcontrol Figure 1: HBPF operation. On receiving a message, the server redirects it to the cloud-based HM. HM125 is responsible for checking and saving the readings in a database. Clinicians126 can inspect the patients’ readings from the database (3). Next, depending127 on the data and the criteria specified by the clinicians, HM responds to the128 patient’s mobile with another message through the server (4 and 5). HM129 also provides additional facilities to follow up hypertensive patients.130 The main objective of the BP app is to extend the communication systems131 of the HM tool, adding the most widely used communication functionalities132 for smartphones. These include instant messaging (chat), among others. In133 this way, patients participate actively in controlling their disease and follow134 their medical evolution, communicating with the medical team in real time.135 5 http://www.healthtap.com 3.1. Hypertension Module (HM)136 Figure 2: HM. The names that appear in the figure are invented. The Hypertension Module (HM) (see Fig. 2) was designed for collect-137 ing and managing data from hypertensive patients. Its functions are to138 record and print/display measurement statistics, show the evolution of pa-139 tients graphically using charts, provide instant messaging tools (i.e. chat),140 aid clinicians with diagnose, and generate alerts or suggestions for treatment,141 patient monitoring, medication and nutrition, among others.142 One of the main features of HM is that it plots patients’ readings (systole143 and diastole blood pressures and pulse). These readings can be registered144 automatically by means of the BP app or manually by the clinicians. HM145 automatically calculates the mean values for each day, showing an overall146 average value per day in the plot. HM performs a data verification check,147 in order to avoid incorrect or invalid measurements, such as negative or148 physically implausible values.149 HM allows target limits from both systole and diastole blood pressures to150 be established individually depending on the characteristics of each patient.151 If these limits are exceeded, an alert is shown on the main page of the HM152 tool, so that clinicians can act quickly and, if needed, intervene or send an153 alert message to the patient.154 HM is currently designed to communicate with the patients through an155 Internet connection (via a smartphone with the BP app). This somewhat156 6 determines the design of the architecture, currently made up of a server and157 a database (see Fig. 1). In order to increase the reliability and availability158 of the overall system, the server can contain multiple processing units, like159 processors, cores, or Virtual Machines. As the current web servers are usually160 mounted on cloud systems, “VMs” is the terminology used from here on. An161 analysis of the performance provided by the server according to the number162 of VMs is performed in the results section (Sec. 4).163 The clinician is responsible for registering the patient in the HM tool.164 Once registration is done, the patient must send the blood pressure mea-165 sured at home through BP on a weekly or biweekly basis, depending on the166 requirements established by the doctor. This design feature facilitates future167 deployment of personalized medicine approaches to the treatment and follow168 up of hypertensive patients.169 According to the personalized monitoring plan of each patient, the system170 periodically reminds the patient to send their blood pressure readings. The171 system monitors that the data format and values it receives are appropriate,172 before recording them and sending a message to the BP app. The contents173 of the message depend on the information entered by the medical team and174 on the readings provided by the patients.175 3.1.1. HM Architecture176 The cloud-based architecture of HM scales easily with increasing number177 of patients, physicians, and hospitals. This is done by using the SLA to178 adjust the number of available Virtual Machines (VMs, widely used in cloud179 computing environments) and the number of requests entering the module180 (see [14, 16, 17, 13] for more information).181 The current HM architecture is made up of 2 hosts (nodes), each with182 one AMD Opteron 6100 processor of 12 cores running at 2.1GHz (see Fig 3).183 We plan to add more hosts as the system grows. Note that nodes can be184 different, conforming a heterogeneous framework. All the software technolo-185 gies used to implement HBPF were carefully selected with several criteria in186 mind. First, they had to be open-source, in order to facilitate future shared187 development of the apps. In addition, these technologies had to be robust,188 efficient, and be widely deployed and supported. VMs are deployed across189 the hosts on top of the OpenStack2. OpenStack is an open source Cloud plat-190 2OpenStack. http://www.openstack.org 7 form that allows to manage and deploy large networks of Virtual Machines.191 All the VMs run Ubuntu GNU/Linux 3.2.0-41-virtual x86 64. We believe192 in a distributed design because the degree of administrative and geographic193 scalability increases with the number of hosts.194 Apache Scheduleer MySQL Cluster VM VM VM VM VM VM host 1 host 2 OpenStack OpenStack Task Firewall AJP Figure 3: HM architecture. The scheduler is mapped into a VM with 512MB RAM and 1 core in host195 1. It is implemented using the Scheduler of Apache Tomcat 7. The rest of196 VMs, that service the requesting tasks, are provided with 4GB and 2 cores.197 These VMs are the computing VM nodes, where the HM module copies (each198 performing the same operation) are deployed on top of Apache Tomcat3, an199 open-source web server developed by the Apache Software Foundation (ASF).200 Task scheduling determines which VM executes the tasks. VM consol-201 idation instead determines the mapping of VMs to hosts. The HM task202 scheduling and VM consolidation follows a Round-robin policy, which states203 that tasks (VMs) are assigned to VMs (hosts) by following a circular ring204 ordering.205 All VMs are configured with the AJP (Apache JServ Protocol - Apache206 Tomcat Connector) protocol enabled, which is used by the scheduler to com-207 3Apache Tomcat. http://tomcat.apache.org/ 8 http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html http://tomcat.apache.org/ http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html municate with the nodes. AJP is a protocol that can proxy inbound requests208 from a web server (Apache HTTP server) to an application server (Tomcat).209 The database is implemented using a MySQL Cluster4, a technology210 that provides shared-nothing clustering and auto-sharding for the MySQL211 database management system. The database is distributed between the212 hosts (nodes) making up the cloud framework. The MySQL Cluster is im-213 plemented with 2 VMs with 4GB RAM and 2 cores (of two different hosts).214 Having multiple computing and data-sites ensures a high degree of load and215 administrative scalability and reliability.216 3.2. BP217 BP is designed to update and expand the current system of communi-218 cation with the HM tool, offering an application that was not previously219 available for smart phones. BP is a user-friendly app that extends the HM220 services to Android and iOS smartphones.221 3.2.1. BP Design222 Currently, there are many alternative technologies for developing applica-223 tions for mobile devices. An important design requirement was that the ap-224 plication should be compatible with all the major platforms Android and iOS.225 Because of this, the BP app was implemented using HTML, CSS, Javascript,226 JQuery Mobile and PhoneGap5.227 PhoneGap is an open-source development tool for creating cross-platform228 mobile applications with countless libraries available for use. PhoneGap has229 APIs to control I/O devices efficiently (such as cameras, GPS, databases, file230 system, etc.) in a similar way to those obtained with native code. Phonegap231 currently supports the two mainstream platforms (Android and iOS).232 The features that retrieve information from HM need to establish a con-233 nection by means of web services. This ensures low data capacity require-234 ments and avoids legal problems, as medical data is only stored in HM instead235 of in each individual smartphone. However, this introduces a low penalty in236 obtaining the required information remotely, although it does not signifi-237 cantly affect the user experience. We created ad hoc web services, which are238 used to exchange data in JSON format between the clients (BP instances)239 and the server (HM).240 4MySQL Cluster. https://www.mysql.com/products/cluster/ 5PhoneGap. http://phonegap.com. 9 3.2.2. BP Operation241 The BP app can be used to register patients, edit their profile, download242 or upload data regarding blood pressure and pulse readings from/to the HM243 server, visualize informative videos uploaded by the clinicians, analyze pa-244 tient trends by plotting and listing the evolution of the patients’ state and245 readings, and provide information about collaborating hospitals. Finally BP246 can be used for chatting (instant messaging) between patients and clinicians.247 Whenever required, a patient can easily ask the doctor a question through248 the chat window.249 The application also helps the patients with useful advice. Once the250 blood pressures and the pulse have been sent, the app immediately shows251 the results of the analysis (done in HM) through a traffic light indicating the252 status of the patient. In addition, a short message indicates medical advice.253 The medical advice depends on the results of the analysis of the readings.254 There are three possible states (light colors) and three associated mes-255 sages:256 Good (green). Everything was fine. Remember to keep measuring and257 sending your pressure readings.258 Regular (yellow). Do not forget, salt-free diet. Remember to take the259 medication and do some physical activity.260 Bad (red). We have seen your records, do not worry. We will contact you261 to bring your next clinical appointment forward.262 BP can show a graphic evolution of the patients’ measurements. Different263 types of visualization can be chosen. By clicking global, the plot of the264 blood pressure (Fig 4) appears. The morning and afternoon buttons separate265 the samples by these times of day. Start and finish dates can be selected.266 Alternatively, 1, 3 and 6 months selectors are available.267 4. Results268 Here we report a series of benchmark experiments used to evaluate the269 performance and efficiency of HBPF. We benchmark HM and the BP app270 separately and present the results in sections 4.1 and 4.2 respectively.271 The main performance criteria by which the HM server and the BP app272 should be evaluated are only partially overlapping. Because of this we sep-273 arately evaluated the server and the app. For the HM server we evaluated274 10 Figure 4: Consultation readings for blood pressure. response time, throughput, and scalability. For the BP app, we evaluated275 startup time, communication time and usability.276 4.1. HM277 4.1.1. Testbed278 Experiments on the HM tool were carried out on 5 Virtual Machines279 [V M1 . . . V M5] deployed over OpenStack, installed on a host with 1 AMD280 Opteron processor with 12 cores running at 2.1 GHz each. To emulate VM281 heterogeneity, we set V M1 . . . V M5 with 4GB RAM and 2 cores.282 Application stress tests via HTTP requests were performed using the283 Apache JMeter6 tool, which measures performance and functional behavior.284 These requests simulated patients consulting or introducing their data and285 clinicians using HM.286 The effect of number of simultaneous requests on HBPF performance was287 tested by systematically varying the number of users. There were generated288 100 requests per user. All users would be performing their requests within289 a single 50 sec. period. The time between user requests was constant and290 therefore these requests were uniformly distributed in the 50 second test291 interval.292 6JMeter. http://jmeter.apache.org/ 11 The performance metric we used was the Response Time and Through-293 put, as these parameters are widely used for measuring system efficiency.294 Throughput was also the parameter chosen to fix the SLA.295 4.1.2. Response Time296 Testing the response time of the application was done using all five avail-297 able VMs. Fig. 5 summarizes the response time of the system in terms of298 the median, average and 90% Line when the number of users increased from299 200 to 800. The 90% Line (or 90th percentile) is the value below which 90%300 of the samples were processed in less than the time specified on the y-axis.301 This metric is more meaningful than the median or average value in terms of302 SLA (Service Level Agreement). Although the system starts to overload at303 80,000 requests (i.e. 800 users), the average and median response time still304 remains below 1 second (the users will not notice a lack of interactivity with305 the system). Obviously, worser results were obtained for the 90% Line (1,7306 s).307 0 200 400 600 800 1000 1200 1400 1600 1800 20 30 40 50 60 70 80 T im e ( m s ) # Requests (thousands) 90% Line Average Median Figure 5: Evolution of response time (average, median and 90% Line). 4.1.3. Throughput308 Another measure of efficiency is throughput (TR), which is defined as the309 number of requests served per unit of time:310 TR = number of requests time (1) Here, we benchmark the effect of changing the number of available VMs311 on the TR and the number of users from 50 to 800. Fig. 6 compares the312 12 0 100 200 300 400 500 600 700 800 900 0 10 20 30 40 50 60 70 80 T h ro u g h p u t # Requests (thousands) 5 VM 3 VM 1 VM Figure 6: Evolution of system throughput when using 1, 3 and 5 VMs. TR of the system when we use one (VM1), three (VM1-VM3), or five VMs313 (VM1-VM5). Fig. 6 summarizes the results.314 A general feature of the system’s response is that TR increases linearly315 with the number of requests, until it peaks at approximately 40,000 requests316 (30,000 for 1 VM). After this threshold, TR performance decreases slightly317 and the SLA is not guaranteed. We note that the SLA should be fixed318 according to the required TR, depending on the number of requests and319 the number of VMs available. This behaviour is consistent with previous320 simulations of a similar model system, using an approach based on queuing321 theory[15, 16].322 Going from one to three VMs leads to an increase in peak TR of 28,5%.323 In contrast, going from three to five VMs leads to an increase in peak TR324 of approximately 16,8%. This suggests that peak relative performance in-325 crement decreases every time additional VMs are activated. Internal tests326 suggest that this loss was due to the delay introduced by the remote commu-327 nication between VMs located in different cores, which is a known frequent328 bottleneck in distributed computing applications.329 Thus, as was the case in the simulated system [15, 16], we face a situation330 where our system overloads, leading to a significant increase in the response331 time and a decrease in TR. However, in contrast with the simulated system,332 adding more VMs to the real HBPF system only partially solves the problem,333 and a law of diminishing returns is observed with an increase in number of334 VMs. Overall, these experiments suggests that the most efficient strategy for335 distributing work between VMs allocated to HBPF is to first deploy work to336 13 local VMs. When these are saturated, work should then be sent to remote337 VMs.338 4.1.4. Scalability339 We also investigated the scalability of the system in its cloud environ-340 ment by using an event-driven simulator to test the behaviour of that en-341 vironment. We use the CloudSim 3.0.2 software [26] in these tests because342 it allowed us to easily emulate the HBPF architecture presented and evalu-343 ated in sections 3.1.1 and 4.1 respectively. CloudSim allows the behaviour of344 the AMD Opteron 6,100 (the one chosen for this simulation) to be emulated.345 The CloudSim task scheduling and VM consolidation followed a Round-robin346 policy. As we chose the same processor and scheduling policies as the HM347 architecture (see section 3.1.1), the results obtained in the simulation should348 be directly applicable to the real system.349 Fig. 7 shows the system behavior when scaling it by increasing the num-350 ber of VMs and hosts. VMs were made up of 2 cores and 4GB each. As351 in section 4.1, one host was made up of one processor. The simulation en-352 vironment was carried out by executing 1, 000 tasks with a size of 100, 000353 instructions each. Further experiments varying these parameters gave pro-354 portional results.355 1 2 3 4 0 20 40 60 80 100 0 400 800 1200 1600 Hosts VM 0 400 800 1200 1600 Figure 7: Execution times depending on the number of VMs and the number of hosts. We can appreciate that increasing the number of VMs and hosts signifi-356 14 cantly decreases the total execution time (in time units) of the overall tasks.357 Fig. 7 shows that by adding VMs, the performance approaches asymptoti-358 cally to a limit where it does not have enough computational resources (RAM,359 CPUs, etc.. making up the hosts) to map the tasks, and so the execution360 time stabilizes. Similar behavior occurs when adding more hosts without361 adding more VMs.362 4.2. BP363 4.2.1. Performance364 Typically, two important bottlenecks in application performance are the365 start up of the app and the operational processes in which that app accesses366 Internet.367 BP was installed and tested on smartphones and tablets running modern368 versions of Android and iOS. The devices and operating systems used to369 verify the correct operation of BP are listed in Table 2. This table shows370 the elapsed time of the start up for BP. These times were the average of 3371 independent measurements.372 Device Operating System BP start up time Samsung Galaxy S2 Android v. 4.2.2 10.583 Samsung Galaxy S3 Android v. 4.3 10.121 Nexus 5 Android v. 5.1.1 9.638 Ipad 2 iOS v. 8.4 10.346 Iphone 6 iOS v. 8.4 9.949 Table 2: Performance comparison between devices (in ms). The cross-reference APIs used by PhoneGap introduced a considerable373 penalisation in the BP start up time (10 ms). However, the application374 performed well in all the tested devices. In all cases, overall response time375 fell below one second, which guarantees that the user’s flow of thought is376 uninterrupted [27].377 The communication time sending a chat message to HM was also mea-378 sured. To do so, we computed the average time for all Android and iOS379 devices. We tested two types of connections, WiFi (with 100 Mb/s download380 and 10 Mb/s upload speed) and 4G Data Internet. Each experiment was381 repeated 10 times per device. Communications were very fast, taking on382 average 329 ms for WiFi and 861 ms for 4G. WiFi bandwidth was entirely383 15 dedicated to communications done using the BP app. This validates the384 design of the communication mechanism between the app and HM.385 4.2.2. Usability386 Here we perform a preliminary evaluation of BP’s usability. This was done387 by asking both, clinicians and patients, to fill in a Google-forms questionnaire.388 This questionnaire was sent by the HM server to all 90 registered patients389 and the 3 clinicians of the Clinic hospital of Barcelona. 38 patients and all390 the clinicians answered it. Table 3 summarizes the results of this evaluation.391 This table only shows the affirmative answers.392 Clinicians are highly satisfied with the app and all are convinced of its393 usefulness and efficiency. In addition, they don’t find its use monotonous. In394 addition, two of the three clinicians found BP very easy to use. We note that395 these evaluations are anecdotal and a larger number of clinicians must answer396 the survey before we can come to a reasonable conclusion about usability of397 BP from the clinician’s point of view. In terms of user evaluation, we focus398 more on the feedback from patients than that from clinicians for two reasons.399 First, patients will be the vast majority of final BP users. Second, we need to400 obtain input from additional clinicians, given the low number of professionals401 that answered the survey. Between 54% and 87% of all patients reported full402 satisfaction with the various aspects of using the BP app, indicating that403 they are mostly happy with the application. The weakest point we detected404 was that 39% of the patients found the use of BP monotonous. This is in405 striking difference with the clinicians that had the opposite opinion. We406 need to further and specifically understand what the patients found boring407 in order to improve that aspect of the app.408 In general, clinicians and patients recognized the usefulness of the app409 for remote monitoring of hypertensive patients and to reduce traveling costs.410 We note that we are now in the process of compiling patient and clinician411 suggestions to help us improve the user-friendliness of the app.412 5. Conclusions413 This article presents HBPF, an efficient eHealth framework to manage414 and follow up hypertensive patients. HBPF comes with with SLA guarantees415 and it can significantly reduce the costs associated with patient travelling.416 Its efficiency and SLA guarantees are provided by HM, the HBPF server417 component.418 16 Question Patients Clinicians Would you recommend it? 87 100 It is useful for monitoring hypertension? 73 100 Is it use monotonous? 39 0 Is it easy to use? 79 66.6 Is it useful to reduce the visits to the hospital? 82 100 Table 3: Evaluating the use of BP. Affirmative answers (in %). The use of PhoneGap when implementing BP was a successful decision419 because it has proven to be a very suitable framework for cross-platform420 applications, increasing its flexibility and functionality. We tested its perfor-421 mance in the iOS and Android operating systems on both smartphones and422 tablets. Despite the difficulties of adapting the interface in some cases, the423 results achieved were satisfactory.424 However, the user experience could possibly be improved by using native425 development due to the fact that PhoneGap has a slightly higher response426 time than native applications. Accordingly, we are migrating the current ap-427 plication to native environments for iOS and Android platforms. We expect428 to improve this aspect, which we assume will be temporary. We will then429 compare the performance of PhoneGap against native frameworks.430 Future trends are aimed at testing how the use of this comprehensive and431 personalized monitoring tool can minimize the risk of heart attacks, strokes432 and other effects of hypertension. We plan to add a wireless or bluetooth433 interface to the sampling device without requiring the patient to manually434 submit the data, thus facilitating automatic data transfer and avoiding tran-435 scription errors. Moreover, we plan to implement data analytics so we can436 provide aggregated data to the clinicians in order to detect trends and pat-437 terns within their patient groups.438 References439 [1] R Craig, J Mindell, eds. Health survey for England 2006. London: Her440 Majesty’s Stationery Office. 2006.441 [2] Hypertension in the very old; prevalence, awareness, treatment and con-442 trol: a cross-sectional population-based study in a Spanish municipality.443 http://www.biomedcentral.com/1471-2318/9/16.444 17 [3] Pickering TG, Miller NH, Ogedegbe G, Krakoff LR, Artinian NT, Goff445 D, American Heart Association, American Society of Hypertension, Pre-446 ventive Cardiovascular Nurses Association. Call to action on use and re-447 imbursement for home blood pressure monitoring: a joint scientific state-448 ment from the American Heart Association, American Society of Hyper-449 tension, and Preventive Cardiovascular Nurses Association. J Cardiovasc450 Nurs, 23(4):299-323. 2008.451 [4] Ohkubo T, Imai Y, Tsuji I, Nagai K, Kato J, Kikuchi N, Nishiyama452 A, Aihara A, Sekino M, Kikuya M, Ito S, Satoh H, Hisamichi S. Home453 blood pressure measurement has a stronger predictive power for mortality454 than does screening blood pressure measurement: a population-based455 observation in Ohasama, Japan. J Hypertens, 16(7):971-975. 1998.456 [5] Bobrie G, Chatellier G, Genes N, Clerson P, Vaur L, Vaisse B, Menard J,457 Mallion JM. Cardiovascular prognosis of masked hypertension detected458 by blood pressure self-measurement in elderly treated hypertensive pa-459 tients. JAMA, 291(11):1342-1349. 2004.460 [6] McManus RJ, Mant J, Bray EP, Holder R, Jones MI, Greenfield S,461 Kaambwa B, Banting M, Bryan S, Little P, Williams B, Hobbs FD. Tele-462 monitoring and self-management in the control of hypertension (TAS-463 MINH2): a randomised controlled trial. The Lancet, 376(9736):163-172.464 2010.465 [7] Green BB, Cook AJ, Ralston JD, Fishman PA, Catz SL, Carlson J,466 Carrell D, Tyll L, Larson EB, Thompson RS. Effectiveness of Home467 Blood Pressure Monitoring, Web Communication, and Pharmacist Care468 on Hypertension Control: A Randomized Controlled Trial. JAMA,469 299(24):2857-2867. 2008.470 [8] Vilaplana J, Solsona F, Abella F, Cuadrado J, Teixidó I, Mateo J, Rius J.471 H-PC: A Cloud Computing Tool for Supervising Hypertensive Patients.472 Journal of Supercomputing, 71(2):591-612. 2015.473 [9] Law MR, Morris JK, Wald NJ. Use of blood pressure lowering drugs in the474 prevention of cardiovascular disease: meta-analysis of 147 randomised tri-475 als in the context of expectations from prospective epidemiological stud-476 ies. BMJ, 338:b1665. 2009.477 18 [10] Dickinson HO, Mason JM, Nicolson DJ, Campbell F, Beyer FR, Cook478 JV, Williams B, Ford GA. Lifestyle interventions to reduce raised blood479 pressure: a systematic review of randomized controlled trials. J Hyper-480 tens, 24 215-33. 2006.481 [11] Vilaplana J, Solsona F, Abella F, Cuadrado J, Alves R, Mateo J. S-PC:482 An e-treatment application for management of smoke-quitting patients.483 Computer Methods and Programs in Biomedicine, 115(1):33-45. 2014.484 [12] Abbas A, Khan SU. A Review on the State-of-the-Art Privacy-485 Preserving Approaches in the e-Health Clouds. Journal of Biomedical486 and Health Informatics, 18(4):1431-1441. 2014.487 [13] Vilaplana J, Solsona F, Abella F, Cuadrado J, Teixidó I, Mateo J, Rius488 J. H-PC: a cloud computing tool for supervising hypertensive patients.489 The Journal of Supercomputing, 71(2):591-612. 2015.490 [14] Mateo J, Vilaplana J, Pla LM, Lerida JL, Solsona F. A Green Strat-491 egy for Federated and Heterogeneous Clouds with Communicating Work-492 loads. The Scientific World Journal, 2014:1-11. 2014.493 [15] Vilaplana J, Solsona F, Abella F, Filgueira R, Rius J. The cloud494 paradigm applied to e-Health. Bmc Medical Informatics And De-495 cision Making, Vol 13(35):1-10. http://www.biomedcentral.com/1472-496 6947/13/35. 2013.497 [16] Vilaplana J, Solsona F, Teixidó I, Mateo J, Abella F, Rius J. A queuing498 theory model for cloud computing. Journal of Supercomputing, 6(1):492-499 507. 2014.500 [17] Vilaplana J, Solsona F, Mateo J, Teixido I. SLA-Aware Load Balancing501 in a Web-Based Cloud System over OpenStack. Lecture Notes in Com-502 puter Science, 8377:281-293. 2014.503 [18] Lai CC, Lee RG, Hsiao CC, Liu HS, Chen CC. A H-QoS-demand per-504 sonalized home physiological monitoring system over a wireless multi-hop505 relay network for mobile home healthcare. Journal of Network and Com-506 puter Applications, 32(6):1229-1241. 2009.507 [19] World Health Organization. Second Global Survey on eHealth (Global508 Observatory for eHealth). Geneva: World Health Organization; 2011.509 19 mHealth: New horizons for health through mobile technologies510 URL: http://www.who.int/goe/publications/goe mhealth web.pdf. Ac-511 cessed 2016-01-04.512 [20] Patel B, Turban S, Anderson C, Charleston J, Miller E, Appel L. A Com-513 parison of Web Sites Used to Manage and Present Home Blood Pressure514 Readings. J Clin Hypertens, 6:389-395. 2010.515 [21] Bigna JJR, Noubiap JJN, Kouanfack C, Plottel CS, Koulla-Shiro S.516 Effect of mobile phone reminders on follow-up medical care of children517 exposed to or infected with HIV in Cameroon (MORE CARE): a mul-518 ticentre, single-blind, factorial, randomised controlled trial. The Lancet519 Infectious Diseases, 14(7):600-608. 2014.520 [22] Liu Q, Abba K, Alejandria MM, Sinclair D, Balanag VM, Lansang MA.521 Reminder systems to improve patient adherence to tuberculosis clinic522 appointments for diagnosis and treatment. Cochrane Database Syst Rev,523 18(11):CD006594. 2014.524 [23] Carrasco MP, Salvador CH, Sagredo PG, Márquez-Montes J, González525 de Mingo MA, Fragua JA, Rodŕıguez MC, Garćıa-Olmos LM, Garcia-526 López F, Carrero AM, Monteagudo JL. Impact of patient-general practi-527 tioner short-messages-based interaction on the control of hypertension in528 a follow-up service for low-to-medium risk hypertensive patients: a ran-529 domized controlled trial. IEEE Trans Inf Technol Biomed, 12(6):780-91.530 2008.531 [24] Hamine S, Gerth-Guyette E, Faulx D, Green BB, Ginsburg AS. Impact532 of mHealth Chronic Disease Management on Treatment Adherence and533 Patient Outcomes: A Systematic Review. J Med Internet Res, 17(2):e52.534 2015.535 [25] Benharref A, Serhani MA. Novel cloud and SOA-Based framework for536 E-health monitoring using wireless biosensors. Biomedical and Health537 Informatics, IEEE Journal of 18(1):46-55. 2013.538 [26] Calheiros R, Ranjan R, Beloglazov A, De Rose C, Buyya R. CloudSim:539 A Toolkit for Modeling and Simulation of Cloud Computing Environ-540 ments and Evaluation of Resource Provisioning Algorithms. Software:541 Practice and Experience, 41(1):23-50. 2011.542 20 [27] Miller RB. Response time in man-computer conversational transactions.543 Proc. AFIPS Fall Joint Computer Conference, 33:267-277. 1968.544 21 Figure 1(on next page) HBPF operation Mobile Clinician Internet Blood pressure Pa5ent database Server 1 2 3 5 4 HM BPcontrol 2 HM. The names that appear in the figure are invented Figure 3(on next page) HM Architecture Apache Scheduleer MySQL Cluster VM VM VM VM VM VM host 1 host 2 OpenStack OpenStack Task Firewall AJP 4 Consultation readings 5 response time 6 throughput 7 scalability