Energy efficiency in software: A case study on sustainability in personal health records.

A personal health record is an eHealth technology in which users can observe their progress over time for a given condition. A research gap was identified in the literature concerning the study of the amount of energy that these systems need for their operation, and the energy efficiency that may be attained depending on their design. After the selection of five representative personal health records, a total of 20 tasks commonly done, and based on previous work, were performed with regard to two proposed scenarios, namely patient use and health personnel usage. The power consumption of the main components of a host machine was measured during the performance of the proposed duties. To that end, a hardware tool called the Energy Efficiency Tester was employed. The data collected were analyzed statistically, and significant differences were found in the respective consumption of the display (χ2 (4) = 23.782, p = 0.000), the processor (χ2 (4) = 29.018, p = 0.000) and the whole PC (χ2 (4) = 28.582, p = 0.000). For all of these components, NoMoreClipBoard was the personal health record that required the least energy (57.699 W for the display, 3.162 W for the processor and 181.113 W for the whole PC). A total of two strong correlations were found in the energy consumption between the hard disk and the graphics card (r = 0.791, p < 0.001), and the processor and the PC (r = 0.950, p < 0.001). Some features generated special amounts of power consumption, such as the news wall found on PatientsLikeMe, or the use of load icons that had an impact on most PC components. In addition, an in-depth analysis of the user interfaces was performed. A discussion was carried out on the design of the user interfaces, also taking into account recommendations drawn from the literature, checking for their implementation in the personal health records selected. With the aim of promoting sustainability among software developers, a best practice guideline on sustainable software design was proposed. Basic sustainability recommendations were collected for professionals to consider when developing a software system in general, and a personal health record in particular.

Introduction

Technology sustainability that focuses on hardware has attracted a great deal of attention. For example, multiple sensors in mobile technology have been viable thanks to the development of more energy-efficient phones (Cornet and Holden, 2018). However, software plays an important role in the proper use of the resources required for an application to run. The area of software sustainability is therefore one that is emerging with strength.

Sustainable software has the aim of reducing the environmental deterioration created by the massive use of technology, and seeks to raise consciousness regarding care of the planet. This is an important issue to address, due to the fact that Information and Communication Technologies (ICT) significantly affect the levels of CO2 worldwide (Danish et al., 2018). If unchecked, greenhouse gas emissions (GHGE) from ICTs could by 2040 exceed 14% of the level of GHGE that was established in 2016 (Belkhir and Elmeligi, 2018). By way of example, a total of 196 Mt CO2e were emitted into the atmosphere in 2015 from the ICT sector alone (Malmodin and Lundén, 2018). Recent studies conclude that a 6–15% reduction in CO2 emissions could be achieved through smart applications, the increasingly efficient use of energy and the dematerialization of energy-intense technologies (Malmodin and Bergmark, 2015). Note that, depending on how software is implemented, there may be an influence on the power used by the hardware (Wilke et al., 2011). Energy-aware software design studies have proven that a potential power reduction of 30%–90% can be achieved (https://www.networkworld.com/article/2861005). As an example, a particular choice of API in which different sizes of buffer were selected had significant impacts on the energy cost, saving up to 76% of the power initially consumed (Singh et al., 2015).

Sustainable software can be divided into green in software or green by software (Calero and Piattini, 2017). In the first case, the software per se and the process involved in its production is taken into account, with the aim of caring for the environment. The second term, green by software, is related to the use of software as a means to achieve environmental sustainability. Both green in and green by software are key in attempting to achieve a cleaner management of production, especially when software plays an important role in that process. This study was conducted from the perspective of green in software. Environmental sustainability, human sustainability and economic sustainability are the three dimensions for software sustainability (Calero and Piattini, 2017). In this sense, this paper focuses on the environmental sustainability dimension, which deals with how software product development, maintenance and use have an impact on energy consumption and other resources. Thus, the concept of sustainability in this paper is, therefore, related to environmental sustainability. The term refers to the efficient use of energy in order to reduce the impact on the environment caused by ICTs, which is well-known as sustainable energy consumption in the 2030 Agenda for Sustainable Development.

A personal health record (PHR) is an electronic application that lets individuals access, manage, and share their health information with others who are included in the permission assignments (Senor et al., 2012). The different systems can provide varying degrees of functionality (Fernández-Alemán et al., 2013b).

Although there are still some barriers to overcome, such as security and privacy aspects (Flaumenhaft and Ben-Assuli, 2018) or the need to find the right balance between PHR’s independence and its complexity (Tang et al., 2006), a high percentage of the population would be willing to adopt the use of PHR systems (Fernández-Alemán et al., 2013a). Moreover, citizens who have long-term conditions are especially willing to use them (Hemsley et al., 2016). Some of these applications had become popular by the end of 2019; they include Kaiser Permanente (https://healthy.kaiserpermanente.org/) with more than 12.3 million registered users, HealthVet with 2.5 million, and PatientsLikeMe with 0.75 million users. Moreover, the number of PHRs consumers grew rapidly after these applications were introduced, and exceeded 31 million users in 2013 (Ford et al., 2016).

These tools are beneficial for patients because they provide access to a wide range of truthful health knowledge (Tang et al., 2006). Another aspect to bear in mind is that healthcare organizations spend over $6.5 billion on energy each year, and that amount is rising to meet patients’ needs (Energy Smart, n. d.). PHRs are thus expected to gain importance, since they enable more sustainable health care. In the case of health emergencies such as that caused by COVID-19, they can reduce the amount of visits to the health center when medical assistance does not really require the patient to attend in person. This avoids potential infection via social contact. It comes as no surprise, then, that many governments are seeking to build national e-Health infrastructures that include these systems that can potentially be used on a daily basis.

Efficiency has been identified as one of the main challenges regarding the functioning of PHRs (Roehrs et al., 2017). This fact is especially relevant when, for example, a large number of users run an application. A small saving in the energy consumed for a given functionality can imply a large saving in the total energy needed to serve all the web portal customers. This means that in the quest to gain momentum in achieving energy savings in IT systems it may be essential to intervene actively, seeking to produce a reduction of software energy consumption (Ardito and Morisio, 2014). In that sense, this work provides relevant development guidelines that can be applied in computer applications of different topics.

Issues such as functionality (Bachiri et al., 2016), privacy policies (Bachiri et al., 2018), interoperability with electronic health record (EHR) (Plastiras and O’Sullivan, 2017) and usability (Zapata et al., 2015) have recently been investigated in relation to PHRs. It should also be highlighted that good usability of PHRs may lead to a more energy-efficient employment of these eHealth tools. Nevertheless, with such a large amount of elements that are involved in the endeavor to improve usability, some of these may come into conflict with software sustainability.

To the best of the author’s knowledge, no previous studies have measured the power consumption of PHRs. The assessment of whether a PHR is sustainable necessitates the measurement the resources required during its use. Such measurements can be employed, for example, to identify those parts of the PHR that require most energy, so that appropriate software changes can be made in the effort to reduce total energy consumption. The findings, with respect to the energy resources needed to use the PHRs under study, could also be borne in mind by patients as they seek to choose the most environmentally-friendly PHR.

One of the main reasons for choosing web portals in this study is because of the expected continued usage of these in the near future. Technologies such as Progressive Web Apps, halfway between mobile application and web portal, guarantee a long life in this philosophy of use of the Internet. In this paper, PHRs were analyzed in depth in the form of a case study. Although the case study was based on PHRs, findings can be applied to other thematic web portals, such as banking, e-commerce or any mass media webpages.

In order to emphasize the role of software as a means to achieve energy sustainability, and based on the results presented in this paper, a collection of recommendations, entitled CAT-SUST, has been proposed. The objective was to provide professionals with a number of precise guidelines regarding sustainability, to create more energy-efficient systems. This framework is an important contribution towards enhancing the possibilities of bringing about cleaner production by means of software.

A total of five research questions were posed in the effort to form a picture about energy needs in this kind of tools.

RQ1: What is the power consumption of the PC components?

RQ2: Are there significant differences in the power consumption of the PHRs?

RQ3: Are there significant differences in the variation of power required by the PC components?

RQ4: Are there significant differences in the power consumption between the PHR use scenarios?

RQ5: Is there any correlation in the power consumption of the PC components?

The remainder of this paper is organized as follows. In section 2, the PHR selection process is presented, together with the way of assessing the PHRs, a brief explanation of the measurement energy consumption hardware, and the description of the experiment. Section 3 explains the research questions and describes the evaluation and statistical analysis of the data collected from the selected PHRs, with regard to five power measurement sensors: processor, hard disk, graphics card, monitor and the whole PC. In section 4, the sustainability findings are extracted from: (1) the use evaluation of the PHRs and (2) the discussion of the papers from the literature. Finally, some concluding remarks are provided and future work outlined in section 5.

Materials and Methods

Fig. 1 shows the research flow chart followed in this work. The overall research performed in this paper was: (i) establish the selection process to decide which PHRs would be studied, (ii) propose a manner to evaluate energy expenses of the selected PHRs by means of tasks and scenarios, (iii) choose the device with which to measure the power needs, and perform energy measurements during the completion of the tasks, and finally, (iv) run the experiment and answer the research questions with the data collected and the statistical analyzes performed.

Fig. 1

Research flow chart.

Selection protocol for personal health records

The search for free web-based PHRs performed in this work was based on previous literature (Fernández-Alemán et al., 2013b). The task was conducted by using the quality reporting guidelines set out by the Preferred Reporting Items for Systematic reviews and Meta-Analysis (PRISMA) group (Moher et al., 2009), taking functionality aspects as the main feature for selection. This protocol allows researchers to use formal methods to ensure that the search and retrieval process is accurate and impartial. The information sources chosen for use in the search for the PHRs were: Medline, ACM Digital Library, IEEE Digital Library, ScienceDirect and the myPHR website. The myPHR portal is maintained by the American Health Information Management Association (AHIMA), and provides individuals with information related to the use and the construction of the PHRs. From a previous selection performed in the literature (Fernández-Alemán et al., 2013b) an inclusion criterion (IC) was employed, which was web-based format (IC). A total of 19 PHRs were chosen. As shown in Fig. 2 , six exclusion criteria were applied: non-available PHRs (EC1), non-free PHRs (EC2), registration not possible (EC3), malfunctioning (EC4), available only in USA (EC5), and low-popularity PHRs (EC6). Alexa was the tool that made it possible to apply EC6. Alexa is a well-known sorting mechanism for verifying visits to web portals. This online service provides netizens with the popularity ranking for more than 3500 million websites with respect to parameters of visits made to those sites (www.alexa.com).

Fig. 2

PRISMA flow chart.

During the selection process HealthyCircles, Telemedical, Dr. I-Net, MedsFile.com, ZebraHealth, EMRySTICK, Dlife were discarded by EC1, myMediConnect, Juniper Health by EC2, RememberItNow! by EC3, WebMD HealthManager by EC4, PatientPower by EC5 and, finally, myHealthFolders and My Doclopedia PHR, because of having an Alexa ranking value higher than 10 million (EC6).

The PHRs selected were:

HealthVault (https://international.healthvault.com)

HealthVet (https://www.myhealth.va.gov)

PatientsLikeMe (https://www.patientslikeme.com)

NoMoreClipBoard (https://www.nomoreclipboard.com)

Health Companion (https://www.healthcompanion.com).

In the selection of the PHRs to be studied, a collection of functionalities that covered as many options as possible was taken into account. In this sense, the PHRs selected had one feature which made them stand out from the rest. In Table 1 the feature of each one of these is displayed. All of the above makes it possible to affirm that the PHRs studied are a representative sample of the variety of features that can be found in these medical IS. Fig. 2 shows the selection process followed to decide which PHRs are included in the study.

Table 1

PHRs features.

PHR	Main feature
HealthVault	Available in several languages, and one of the PHRs in which a particular functionality was found (Fernández-Alemán et al., 2012).
HealthVet	Target public: US Veterans enrolled in the VA Health Care System.
PatientsLikeMe	User experience similar to a social network.
NoMoreClipboard	Officially approved by Drummond Group’s ONC-ACB certification programme for both outpatient and inpatient use.
Health Companion	ONC HIT certification, and verified by GeoTrust to ensure health information is stored securely and kept confidentially in line with US Federal regulations.

Typical scenarios and user profiles when using personal health records

User profiles can be employed to capture the mental model of the typical PHR performance (LeRouge et al., 2013), which is comprised of their assumptions and expected behavior. Two characters were created: patient and healthcare staff. The patient may not have used PHR tools before, or interacted with them to carry out different health consultations. In contrast, healthcare personnel are used to working with EHRs, or other medical IS such as PHRs, and may perform different tasks, such as adding the patient’s health data. Both profiles were employed as foundational material for creating the two scenarios that represent the most typical usages of PHRs (Carroll, 2000).

Scenarios provide guidance to end-users on what tasks to complete, but not on how to complete them (Russ and Saleem, 2018). The tasks under test were chosen by conducting a preliminary evaluation of the PHRs (Fernández-Alemán et al., 2013b), and by identifying common functionalities for a typical use of PHRs when interacting with patients and healthcare personnel (Kneale et al., 2017). This analysis was supplemented by a review of recommendations of the American Health Information Management Association (AHIMA) (AHIMA, 2018) and scientific literature on different implementations of the PHRs, such as usb-based (Maloney and Wright, 2010), mobile-based (Kharrazi et al., 2012) and web-based (Kim and Johnson, 2002). A template was designed with two scenarios. Scenario 1: the patient registers and accesses the system, gives the health personnel permission to access and consult data on their state of health. Scenario 2: the health personnel, after accessing and consulting the patient’s data, can add information, such as patient illnesses or medications. Table 2 shows the list of 20 PHR common tasks identified and their scenarios.

Table 2

Typical tasks in a PHR.

Tasks	Patient (scenario 1)	Health personnel (scenario 2)
TASK 01: Registration	X	X
TASK 02: System access	X	X
TASK 03: Add profile	X
TASK 04: View profile	X	X
TASK 05: Manage permissions to 3rd parties	X
TASK 06: Add family history	X
TASK 07: Add medication		X
TASK 08: Add new allergy		X
TASK 09: Add vaccine		X
TASK 10: Add disease		X
TASK 11: View medications	X	X
TASK 12: Print report	X	X
TASK 13: View glucose evolution	X	X
TASK 14: Search for information about conditions	X
TASK 15: Export health info	X	X
TASK 16: Schedule appointments and medication reminder	X
TASK 17: Send suggestion/contact	X	X
TASK 18: See privacy policy	X
TASK 19: Exit	X	X
TASK 20: Forgotten password	X	X

Measuring power consumption

In order to evaluate the sustainability of a PHR, a particular hardware device to measure the energy consumed by a software product was employed. In this study, the Framework for Energy Efficiency Testing to Improve eNvironmental Goals of the Software (FEETINGS) was considered a way of performing the power consumption measurements (Mancebo et al., 2018). The Energy Efficient Tester (EET) is the core of this system, and is composed of different sensors that support the power assessment of three different hardware elements: processor, hard disk and graphics card. Furthermore, two additional external sensors quantify the total power consumption of the PC and the monitor connected to the equipment in which the software under test is running.

Description of the experiment

The experiment was carried out by using EET connected to a thin film transistor-liquid crystal display (TFT-LCD) monitor model Philips 170S6FS, and to a host machine. The PC was equipped with a GigaByteTM GA-8I945P-G motherboard, an Intel PentiumTM D @ 3.0GHz processor, a set of 2 modules of 1 GB DDR2 @ 533 MHz RAM memory, a SamsungTM SP 2004C 200 GB 7500 rpm hard disk drive, a Nvidia GeForceTM GTS 8600 graphics card, and an AopenTM Z350-08FC 350 W power supply. As for the software installed on the PC, the operating system was Microsoft Windows 7 ProfessionalTM, and ChromeTM version 62 was the browser where the tasks were done.

The aforementioned tasks (section 2.2.) that configured the proposed scenarios, and which can be applied in different roles, were tested five times. For each sensor the standard deviation was taken to obtain a representative value of the power consumption in each measurement iteration. The average energy consumption of the tasks was therefore calculated by using these five representative energy consumption values from each sensor and task. Both roles, that of patient and that of healthcare personnel, were adopted, in order to explore each scenario based on the PHR functionality.

Results

The statistical analysis carried out with the data collected by the EET device is set out in this section. The results have been classified according to the research questions posed.

With reference to RQ1, the average energy consumption of each PHR and each sensor is displayed in Table 3 . These values are calculated with the data in Appendix A, where the power measurements are shown. The largest values appear shaded in red, while the smallest ones are shaded in green. The maximum and minimum values in Table 3 show the variability of the energy consumption in each PC component and PHR.

Table 3

Average power consumption in Watts.

RQ1: what is the power consumption of the PC components?

Fig. 3 shows the histograms of the power measurements in Watts from the sensors, taking all the values collected from all the tasks and all the iterations. The variance of the sensors data in Appendix A is also shown.

Fig. 3

Histograms with the power consumption of each sensor in Watts.

The Friedman test was used to investigate the differences between PHRs as regards energy consumption. The dependent variable was the power measurements, while the independent variable was the PHR in which the tasks were done. This test was repeated with the data gathered from each sensor.

RQ2: Are there significant differences in the power consumption of the PHRs?

There was a statistically significant difference in the energy consumption depending on which PHR was used with regard to the following sensors: monitor χ2 (4) = 23.782, p = 0.000, processor χ2 (4) = 29.018, p = 0.000, and PC χ2 (4) = 28.582, p = 0.000. However, there was no statistically significant difference in the energy consumption depending on which PHR was used with regard to the sensors of the hard disk χ2 (4) = 5.382, p = 0.250, and graphics card χ2 (4) = 6.327, p = 0.176. Appendix A, Table A.7 compares the mean ranks between the PHRs, and indicates how they differed.

To examine where the differences actually occurred, post hoc analysis of the Friedman test with separate Wilcoxon signed-rank tests was conducted on the different two by two combinations of the PHRs. Ten pairs of PHRs were thereby identified. A Bonferroni correction was applied on the results from the Wilcoxon tests to control the Type I error.

The post hoc tests for monitor, processor and PC were carried out. Regarding monitor energy consumption, NoMoreClipBoard, HealthVault and HealthVet demonstrated high efficiency. Significant differences between HealthVault and Health Companion (Z = −3.636, p = 0.000) and PatientsLikeMe (Z = −2.830, p = 0.005), or between NoMoreClipBoard and HealthVet (Z = −2.637, p = 0.008), or between HealthVet and Health Companion (Z = −3.337, p = 0.001) were found. Concerning energy consumed by the processor, NoMoreClipBoard, HealthVault and HealthVet had the lowest energy consumption. Nevertheless, HealthVault and NoMoreClipBoard stood out from the rest. HealthVault has significant differences with respect to HealthVet (Z = −2.864, p = 0.004), PatientsLikeMe (Z = −3.040, p = 0.002) and Health Companion (Z = −3.724, p = 0.000). NoMoreClipBoard had significant differences in comparison with HealthVet (Z = −2.585, p = 0.010), PatientsLikeMe (Z = −3.059, p = 0.002) and Health Companion (Z = −3.621, p = 0.000). PatientsLikeMe had the highest energy consumption, with significant differences from Health Companion (Z = −2.824, p = 0.005), NoMoreClipBoard (Z = −3.059, p = 0.002) and HealthVault (Z = −3.040, p = 0.002). Observing total energy consumed by the PC, HealthVet, HealthVault, and NoMoreClipBoard achieved the best energy efficiency. Significant differences between these three PHRs and the rest (NoMoreClipBoard and PatientsLikeMe) were found. PatientsLikeMe is, however, the least green PHR. Significant differences between this PHR and NoMoreClipBoard (Z = −3.059, p = 0.002), HealthVault (Z = −3.110, p = 0.002), HealthVet (Z = −2.981, p = 0.003) and Health Companion (Z = −2.981, p = 0.003) were discovered (see the results of this section in Appendix A; Table A.8).

With regard to the power consumption of the host machine during the performance of the tasks, some of the PC components were more sensitive than others to the variation of the energy consumption. The ratio of the standard deviation to the mean value for the power measurements collected from each sensor (Appendix A) was studied. A total of two statistical tests were applied, the asymptotic test for equality of several coefficients of variation (Feltz and Miller, 1996), and the modified signed-likelihood ratio test (M-SLRT) for equality of several coefficients of variation (Krishnamoorthy and Lee, 2014). These statistical analyses allowed significant differences to be detected with respect to the variation of the power data, although the set of measurements for each sensor had very different average values from each other.

RQ3: Are there significant differences in the variation of power required by the PC components?

Both tests were performed with the data gathered from all the sensors, without separating between the tasks and the PHRs. In this case significant differences were found between the PC components (statistic = 900.7525 and p-value = 0 from asymptotic test and statistic = 887.9255 and p-value = 0 from M-SLRT).

These tests were also applied by taking pairs of sensors. Appendix A, Table A.9 and Table A.10 show that significant differences in power variation appeared in all the cases except with the pair of graphics card and monitor. This could be explained by the fact that the performances of both devices are closely linked. The more image variability there is in the monitor, the greater is the performance required of the graphics card.

With respect to RQ4, the power required to perform the disjoint tasks from the proposed scenarios (those that pertained to patients only or health personnel only) were evaluated. The objective was to detect whether one scenario was more sustainable than the other for each PHR. The Mann-Whitney U test was employed to study if there were relevant differences in the power measurements from all the sensors required to perform the disjoint tasks of both scenarios. In these tests, the dependent variable was the energy consumption of the PC components, and the independent variable was the scenario. No statistically significant differences were found in any case (see the results in Appendix A; Table A.11).

RQ4: Are there significant differences in the power consumption between the scenarios?

The correlation between the data gathered from the sensors was calculated in an effort to detect relationships between the amounts of energy required to run the software. This research question was posed because of the importance of studying whether the power consumption in one component affects the rest, providing deeper knowledge derived from the data.

RQ5: Is there any correlation in the power consumption of the PC components?

The power measurements were separated according to the sensor, and the statistical analysis was performed for each pairs of sensors. A total of two strong positive correlations were found between the hard disk drive and the graphics card (r = 0.7905, p < 0.001), and between the CPU and the whole PC (r = 0.95, p < 0.001). No more correlations of interest were found for the other pairs of components (see Appendix A; Table A.12).

Discussion

This section describes the main findings with reference to the RQs. In addition, the collection of recommendations is presented, together with their basis in each case. Finally, the influence of the recommendations on the power consumption is also described.

Main findings according to the research questions stated

In this section, the RQs were interpreted with due reference to the literature and from observation of the PHRs. The discussion is also structured using the research questions as a basis.

The power consumption of the PC components depends on their technical specifications. In this experiment a low-end host machine was employed. The data collected revealed the power needs when using a PHR in these computers.

RQ1: What is the power consumption of the PC components?

In order to answer RQ1, a comparison was made between the power measurements from the experiment (mean values of the host machine) and the power specifications provided by the manufacturer, or from a benchmark, as shown in Table 4 . In some cases, significant differences were found due to component wear that changes performance over time.

Table 4

Comparison of energy consumption data provided by the manufacturer (Graphics card power data at: https://www.tomshardware.com/reviews/geforce-radeon-power,2122-6.html).

	Host Machine	Manufacturer/Benchmark
Hard disk	14.425882	9.5 (Seek/Typical)
Graphics card	1.4109732	61 (3D Full Load)
Processor	5.2833229	90 (Thermal Design Power)
Monitor	62.705551	30 (Typical)
PC	228.16677	245 (70% Efficiency)

As significant differences were found in the measurements of the sensors depending on the PHR, a short description was made of the main reasons that might produce the results shown.

RQ2: Are there significant differences in the power consumption of the PHRs?

Hard disk drive

Disk energy expense can account for a large amount of energy consumption (Lin et al., 2018). However, disk drives expend considerable energy only in their working state (Lin et al., 2014). Attention is drawn to the fact that PHRs do not have frequently-executed I/O-intensive workloads. Consequently, no significant differences between PHRs were found as regards disk drive consumption.

Processor

The energy consumption of the processor also revealed significant differences depending on the PHR. NoMoreClipBoard had the lowest CPU energy consumption, whilst PatientsLikeMe had the highest power needs when carrying out the proposed tasks. With regard to “Task 4: View profile”, NoMoreClipBoard shows all the medical information at once, after selecting the member list. In contrast, PatientsLikeMe is social network-oriented and provides the patients with a wall of updates from the community (i.e. other people that share the same conditions, or people followed by users). This feature in PatientsLikeMe needs to refresh the web page recurrently to retrieve wall updates, as shown in Fig. 4 ; this leads to a high-energy requirement in the use of the PHR.

Fig. 4

Screenshot of PatientsLikeMe home page profile.

These kinds of features impose power requirements that must be taken into account when developing a portal (Du et al., 2016). Fig. 5 shows the peak power consumption periods of the processor in refreshing the social network wall versus the more regular consumption of the graphics card. Moreover, the PHR PatientsLikeMe suffers from low performance caused by I/O access, with high hard disk consumption, as shown in Fig. 5. The greater the amount of navigation on this web component, the more memory that the webpage demands to store the data shown on the wall. To solve this problem, batch replacement policy for buffer management should be applied to maximally exploit sequential I/O and to improve the performance of graph database. Real-world experiments have shown that the technique of buffering reduces PC power consumption in graph-based software systems (Zhou et al., 2016).

Fig. 5

Power consumption (in Watts) of the “Task 02: System access” in PatientsLikeMe.

Graphics card

Screen changes generate switching activity, and the computation needed for screen data production may have an effect on the PC components’ energy consumption. Progress bars, animations and, especially, scrollbars increase the power consumption (Zhong and Jha, 2005). There was no progress bar in any of the PHR studied, which makes the PHRs more energy-efficient. The only exception was Health Companion, which presents a processing icon while the page is loading in most of the tasks. Although it is not an environmentally-friendly practice, loading an icon or image can improve user experience of the website. As far as scroll bars are concerned, they are widely used in all of the PHRs. The need to use scroll bars might be determined by the dimensions and resolution of the display. Although their use is not recommended for efficient power consumption, the availability of scroll bars improves ease of use of the portal (Breuninger et al., 2013).

Moreover, fine patterns and textures increase switching activity, which should be avoided in the endeavor to reduce the power consumption (Vallerio et al., 2006). This characteristic is not a discriminant in the proposed study, since this kind of energy-consuming switching activity has not been found in the PHRs analyzed.

Monitor

In this experiment, the power consumed by the display dominated the power needs of the desktop, as suggested in previous research (Bai and Lin, 2005). Two main graphical user interface (GUI) factors have an impact on the display energy efficiency (Vallerio et al., 2006): energy color scheme and screen changes.

On the one hand, the statistically significant differences of the power consumed by the monitor of the host machine for NoMoreClipBoard and Health Companion can be explained by the fact that both PHRs have different color schemes (Salmela et al., 2014). The use of a low-energy color scheme depends on the kind of monitor. For example, in TFT-LCDs each pixel is made up of a red, green, and blue part, each with a shutter that is open in white and closed in black, whereas in organic light-emitting diode-based technology (OLED), display power consumption is proportional to the number of activated pixels and their luminance. This means that displays based on OLED technology employ more energy when they use white, whereas TFT-LCD technologies require power to show the color black (Fernández et al., 2015). As indicated in the Materials and Methods section, TFT-LCD was the technology used in the experiment. Fig. 6 shows that the presence of more dark areas in Health Companion than in NoMoreClipBoard could explain a higher need for power for Health Companion. The mean gray-scale value of the images captured in “Task 2: System access” indicated that the NoMoreClipBoard screenshot is brighter than the Health Companion screenshot. The mean luminance pixel value is 241.43 in the former, whereas its value is 162.15 in the latter.

Fig. 6

Screenshot comparison of white and dark areas between NoMoreClipBoard (left) and Health Companion (right) in “Task 2: System access.

PC

The most effective way to improve energy efficiency is by enhancing the latency caused by interfacing with humans. GUI can influence power consumption of monitor and processor. For example, actions completed on behalf of a user can reduce the time spent with the PC turned on. Although NoMoreClipBoard, HealthVet, HealthVault and PatientsLikeMe had an efficient UI, these PHRs should improve energy consumption by simplifying the interaction with the user, and by reducing the time required to perform specific operations. Several alternatives that could be implemented in the PHRs, and which may reduce time needed to finish the tasks, are presented below.

Automatic jumping. In specific fields in which the number of characters is known (i.e. phone number, dates, insurance number, etc.), automatic jumping of the cursor could be implemented in the PHRs. Only the PHR HealthVet has a form where the cursor moves to the next field when completing the Social Security Number.

Macros. The use of macros to congregate a set of actions produces a more efficient user interface (Savelyev and Brookes, 2019). Nevertheless, there were no macros found and available to catalyze the PHR usage in any of the PHRs studied.

Autocompletion. In general, user input caches are especially useful when a reduced number of known inputs occurs frequently. Previous experiments have shown that autocompletion functions are more energy-efficient with completions consisting of at least three additional letters (Vallerio et al., 2006). The PHRs PatientsLikeMe, HealthVet, NoMoreClipBoard and Health Companion offer an auto-complete function by recovering previous input to reduce the input time. This function is present in the reason for hospitalization, the name of a medical test, conditions, symptoms and treatments for PatientsLikeMe, and for NoMoreClipBoard the function is there for the name of the insurance company, medical providers, medications, illnesses, medical procedures, immunizations, allergies and conditions. In HealthVet and PatientsLikeMe autocomplete is available when searching for information about conditions, and in Health Companion it can be used to add a condition, laboratory data, medications and vaccine. HealthVault did not have autofilling. It should be highlighted that this feature can be useful for an individual beginning to familiarize themselves with their medical situation, especially as regards health vocabulary, where terms can be complicated to write at first.

Hick-Hyman Law. The human cognitive process of taking decisions can be accelerated by applying the Hick-Hyman Law (Hick, 1952; Hyman, 1953). This law postulates a logarithmic relationship between reaction time and the number of choices available, based on the fact that people subdivide the total number of options into categories, discarding about half of the remaining choices at each step. When users must consider each option one at a time, the relationship between response time and the number of choices has been found to be linear (Cockburn and Gutwin, 2009). The insight is therefore that a GUI should present as few choices as possible if it is to take advantage of the Hick-Hyman Law. The most common functionality can be separated out into a smaller menu (Sears and Shneiderman, 1994). HealthVault, HealthVet and PatientsLikeMe proceeded with this law. In these PHRs the access to the information is divided into drop-down menus that pertain to the UI of the system. In particular, HealthVault focuses the navigation of the portal on a left-hand column with the main options of the PHR, as shown in Fig. 7 , and a second level menu which allows the patient to access the medical information. In HealthVet and PatientsLikeMe there is a first level menu, with the main options placed in the headline of the portal. After a choice from this menu is made, a column appears on the left with the links to the medical information.

Fig. 7

Drop-down menu in HealthVault.

However, several navigation levels could also be a disadvantage, as they prolong the process through a number of screens, bringing about greater consumption of energy. For this reason, there must be a tradeoff between the number of elements in a web page and the complexity of the navigation needed to accomplish a task. Access to medical information in Health Companion, for instance, requires levels of navigation through the PHR, but the UI is not organized as in the previous portals. In this case, there is no clear tendency to organize the links of the web in drop-down menus, and the use of graphic animations to improve the appearance of the UI is preferred. An extreme example was found in one of the PHRs studied. NoMoreClipBoard includes all the medical data together on one page, as shown in Fig. 8 .

Fig. 8

NoMoreClipBoard in “task 4: View profile”.

Fitts Law. Based on the Fitts Law (Fitts, 1954), the time required to hit a target is a function of the distance and the size of the target. This implies that a GUI should use as much screen area as possible for widgets to be hit. Moreover, widgets that are to be clicked sequentially should be placed near to each other. This does in fact happen in the case of Health Companion, whose buttons to access the medical data are large, located close to each other, also offering a sequence to access them, thus following the Fitts Law. Fig. 9 shows this characteristic. In contrast, the screen associated with the “Task 4: View profile” in NoMoreClipBoard presents a less environmentally-friendly layout (Fig. 8). The links to the medical information appear at the beginning of the session, and there is no sequence to follow when reading the medical data. However, when the initial page is filled with data, the presence of thematic icons helps in the search for the medical information. A GUI that employs icons reduces system interaction complexity. Moreover, the mental workload of end users is decreased when the icons are designed properly, thus providing a friendly interaction method with IS (Salman et al., 2012).

Fig. 9

Health Companion in “task 4: View profile”.

The power measurements collected in the experiment revealed notable variations in some of the PC components, depending on the particular PHR used. In Table 3, the mean values in power consumption were shown. The ratios between the maximum and the minimum on each sensor were the following: 4.42% in the graphics card, 0.37% in the HDD, 8.68% in the monitor, 67.06% in the CPU and 25.98% for the whole PC. The main variation appeared in the CPU and the power supply, and shed light on the possibility of power reduction via software.

RQ3: Are there significant differences in the variation of power required by the PC components?

Regarding RQ4, the results revealed that no significant differences were found between the proposed scenarios. However, attention should be paid to the scenario of patients with respect to the energy needs. It is expected that patient usage will happen more frequently (e.g., to consult data) than that of health personnel (e.g., to enter data during the patient’s medical checks).

RQ4: Are there significant differences in the power consumption between the scenarios?

Log out was the task where the highest amount of energy was measured (see Appendix A). These maximum power values appeared in Health Companion for the hard disk and the graphics card, and in PatientsLikeMe for the CPU, the monitor and the power supply. Since log out is a common task in the PHRs, the advisability of reducing the energy spent in this task should be pointed out.

A second group of tasks stood out among those in which the highest amounts of energy were consumed after log out. Sign in to NoMoreClipBoard was the second most energy-demanding task according to the HDD sensor. This could be explained by the fact that all the medical data is shown when accessing the PHR. Forgotten password in HealthVault was the second-highest task as regards energy consumption for the graphics card. To sign into this PHR a Microsoft News® account was required. Moreover, a redirection to the log in page at https://login.live.com/ is performed, which extends the time to fulfil the task. View profile in PatientsLikeMe was the next most demanding task in energy needs after log out for the CPU. This task is performed very commonly by a user that accesses the system regularly.

There are sensors that are more precise, but they are also more expensive. That was the case with EET’s external probes; the one from the monitor was more expensive than the one from the PC, but the former also provided more accurate figures. The existence of correlations between 2 components allows the auditors to invest in the sensor with the best price-quality ratio, using the acquired sensor as a proxy for the other one.

RQ5: Is there any correlation in the power consumption of the PC components?

A total of 2 strong correlations between 2 pairs of sensors appeared in the data. The ideas discussed in this paper to reduce the energy needs may have a twofold effect. Reducing power consumption in the graphics card may also have an impact on the reduction of the energy used by the hard disk drive (r = 0.7905, p < 0.001). Another important power consumption correlation was found between the CPU and the power supply. PatientsLikeMe, for example, was the only PHR in which power consumption peaks came about in the CPU because of the wall of updates (Fig. 5). Taking into account the data and the correlation factor between these components (r = 0.95, p < 0.001), avoiding this feature in a PHR could lead to a reduction in the power supply consumption (see Appendix A).

Best practice guideline on sustainable software design

Sustainability features can be considered when developing an IS (Ouhbi et al., 2018). A set of sustainability recommendations is proposed in this section. A requirements catalogue called CAT-SUST was defined by a Software Requirements Specification (SRS) based on the format proposed in the standard ISO/IEC/IEEE 29148:2018 for better organization of the recommendations. The adoption of the CAT-SUST enables the reuse of basic ideas about developing an IS that takes energy consumption into account. Column 1 of Table 5 presents the subsections in the catalogue that were employed to describe the best practices in sustainability. In addition, the paper and/or the task(s) shown in Table 2 from which the recommendations came can be found in column 2 of Table 5. There are thus 3 groups of recommendations; those based on literature, those based on tasks, or those based on both (Table 6).

Table 5

Specific recommendation section structure.

Recommendations	Related Task(s)/Citation
User interfaces
[REC-01] An appropriate low-energy color scheme shall be chosen according to the technology of the monitor (TFT-LCDs consume more power with dark colors, whereas OLED displays require more power with white/light tones).	2,7, 9–13, 15, 17 (Fernández et al., 2015)
[REC-02] Appropriate tones shall be chosen in a color gradient that depends on the particular technology of the monitor.	2,7, 9–13, 15, 17 (Fernández et al., 2015)
[REC-03] Widgets shall use as much of the screen area as possible to be hit (according to the Fitts Law, the time needed to reach a target depends on distance and the size of the target).	7–10
[REC-04] Widgets to be clicked sequentially shall appear close to each other.	7–10
Communications interfaces
[REC-05] Frequently-executed I/O-intensive workloads shall be reduced.	2
Functions
[REC-06] Macros that congregate a set of coherent actions shall be defined.	Savelyev and Brookes (2019)
Usability requirements
[REC-07] The number of progress bars, animations and, especially, scrollbars used, shall be reduced.	15
[REC-08] Fields with a well-known number of characters (e.g. phone number, dates, insurance number, etc.), shall use automatic jumping of the cursor to another item.	6
Ease of use requirements
[REC-09] The interaction with the user shall be simplified to improve the latency caused by interfacing with humans.	4
[REC-10] Menus shall present as few choices as possible to reduce the human cognitive process of taking decisions (according to the Hick-Hyman Law there is a logarithmic relationship between reaction time and the number of choices available).	6
[REC-11] Information shown in the GUI shall be divided with thematic icons to reduce interaction complexity and to find the information of interest quickly.	11
Learning requirements
[REC-12] Autocomplete functionality with at least three initial letters shall be developed to write complex names quickly.	Vallerio et al. (2006)
[REC-13] A tradeoff shall be achieved between the number of navigation levels and the number of elements in each level.	6 (Cockburn and Gutwin, 2009)
Performance requirements
[REC-14] Excessive use of computer graphics processing units shall be avoided.	18 (Vallerio et al., 2006)
[REC-15] Low energy-consuming states of graphics processing units shall be used.	18 (Salmela et al., 2014)
Design constraints
[REC-16] Screen changes during the performance of the tasks shall be reduced.	18 (Salmela et al., 2014)
[REC-17] Fine patterns and textures to reduce switching activity shall be minimized.	Fernández et al. (2015)
[REC-18] Buffer management shall be applied by means of batch replacement policies to exploit sequential I/O and performance of the graphic database (e.g. a news wall requires constant refreshing for updates).	2 (Zhou et al., 2016)

Table 6

PC Power Consumption in Watts and the difference for recommendation 7.

	NoMoreClipBoard	Health Companion	Difference
Graphics card	1.32	1.48	0.16
Processor	2.92	5.44	2.52
Monitor	56.50	64.67	8.17
Power Supply	180.49	227.16	46.67

Basis for the best practice guideline

The recommendations were obtained from the experiment. Given a recommendation, two PHRs were taken into account: one of them satisfying the recommendation and the other not. Power variations in each component were thus observed for each pair of different PHRs. This process made it possible to detect the components where an impact on the power consumption could be achieved, together with the potential reduction.

REC-1 and REC-2:

Recommendations 1 and 2 were related to the monitor (Fernández et al., 2015). A total of 14 tasks (2–10, 12–13, 15–17) out of 20 produced the highest power consumptions for this component in Health Companion. This PHR was compared with NoMoreClipBoard in which a total of 9 tasks (2, 7, 9–13, 15, 17) required the least amount of energy for the same PC component. They had different tones of brightness, along with a color scheme of stark contrasts (Fig. 6). On the other hand, a color gradient scheme, which increases switching activity, appeared in NoMoreClipBoard, while in Health Companion there was a solid color scheme. As far as the power measurements of the monitor were concerned, the average value was 62.70 W in Health Companion, and 57.69 W in NoMoreClipBoad.

REC-3 and REC-4:

In HealthVet large widgets appeared when performing the tasks from 7 to 10. They were also closed during the completion of the tasks. This PHR revealed the lowest power consumptions for the hard disk drive, which was 14.34 W. On the other hand, the highest mean power consumption was 14.44 W in PatientsLikeMe, where the recommendations were not observed.

REC-5:

Recommendation 5 was checked with the power measurements collected during the performance of “Task 2: System access”, in PatientsLikeMe. As seen in Fig. 5, peaks of energy expenditure were found in the processor due to the wall of updates. An especially noteworthy energy consumption appeared in PatientsLikeMe, with 6.69 W; this can be compared to the minimum energy measurement, 2.98 W in NoMoreClipBoard, where the updates wall appeared.

REC-6:

No macros were found in any of the chosen PHRs. This feature could nevertheless improve sustainability in these tools (Vallerio et al., 2006). Recommendation 6 was considered to be a tentative guideline, because it was not possible to carry out any verification.

REC-7:

As stated in recommendation 7, scrollbars and loading icons may have an impact on the power consumption. Scrollbars appeared in all the PHRs. Processing icons were less common in most cases, but were present in Health Companion, “Task 15: Export health information”. The lowest energy consumption figures were found in the same components for NoMoreClipBoard, in which there were no loading icons.

REC-8:

Automatic jumping of the cursor was implemented in HealthVet for “Task number 6: Add family history”. An instant power consumption of 14.37 W was required by the HDD, whereas in NoMoreClipBoard the consumption of the HDD was of 14.42 W for the same task.

REC-9:

The user interaction to view the profile in HealthVault took around 2 s and was one of the quickest tasks to finish. In the rest of the PHRs, viewing the profile took around 5 s (see Appendix A; Table A.6). The HDD used 14.24 W when performing the task in HealthVault, and 14.47 W in NoMoreClipBoard. In this sense, the less time required to complete the task, the lower the power consumption.

REC-10:

The distribution of the elements in the GUI was evaluated. PHRs were divided according to GUI complexity. Health Companion’s GUI was the simplest one, HealthVet, HealthVault and PatientsLikeMe had a medium-level complexity, and NoMoreClipBoard was the most over-elaborate GUI. Taking these groups into account, the greater the complexity, the greater the amount of energy used by the graphics card in “Task 6: Add family history”. This component consumed 1.35 W when performing the task in HealthCompanion, and 1.41 W in NoMoreClipBoard.

REC-11:

In NoMoreClipBoard thematic icons appeared when accessing medications. HealthVet was an example of the opposite occurring; no thematic icons were displayed when performing the same task. Table 7 shows extreme power measurements found in relation to the implementation of this recommendation.

Table 7

PC Power Consumption in Watts and the difference for recommendation 11.

	NoMoreClipBoard	HealthVet	Difference
Hard disk	14.34	14.46	0.12
Graphics card	1.33	1.46	0.13
Monitor	56.75	60.61	3.86

REC-12:

An autocomplete feature was found when searching for information about conditions in HealthVet and in PatientsLikeMe. On the other hand, this feature was not found in the rest of the PHRs for the same task. No significative differences in power consumption were found in each PHR pairwise, with and without this recommendation. This feature was thus considered as a tentative guideline, and is collected in the literature (Vallerio et al., 2006).

REC-13:

Reaching a good balance between the number of navigation levels and the number of elements in each level provides a convenient and energy-efficient use of the web portals. On the other hand, accumulating links in unexpected places increases complexity for both the web page and the navigation, causing difficulty in locating information (Chen, 2020) and having an impact on energy consumption (Gao et al., 2018). No special differences were found between PHRs in the number of navigation levels and the number of elements in each level. The recommendation was considered a tentative one.

REC-14 and REC-15:

During the performance of the tasks, it was not possible to detect either an excessive use, or low energy-consuming states in the PC components, for either of the two recommendations. These features were marked as tentative only.

REC-16:

The PHR in which fewest display changes came about was NoMoreClipBoard, when performing “Task 18: See privacy policy”. In Health Companion an initial banner appeared that generated extreme power measurements in different PC components when performing the same task (see Table 8 ).

Table 8

PC Power Consumption in Watts and the difference for recommendation 16.

	NoMoreClipBoard	HealthCompanion	Difference
Graphics card	1.32	1.47	0.15
Monitor	55.34	61.53	6.19

REC-17:

Greater energy-consuming modes of the GPU are related to a quick pipeline of CPU cycles; hence the GPU is able to process properly the textures to be displayed on the monitor (Salmela et al., 2014). This recommendation reduces switching activity, making an impact on the brightness of GUI (Vallerio et al., 2006). Since no fine textures were found in the PHRs, this recommendation was pointed to as tentative.

REC-18:

The employment of batch replacement policies could not be detected during the performance of any of the tasks. This recommendation was thus marked as tentative.

Influence of the best practice guideline

Table 9 summarizes the recommendations from the CAT-SUST, based on the experiments and the related literature. Whenever a power reduction was observed for a component in the experiment an emoticon was employed. In addition, the impact of a recommendation on power consumption was highlighted in each component. Observing the power consumption variability shown in Fig. 10 , green was chosen for an order of magnitude impact of tens, yellow for an order of magnitude of units, and red for decimals. It is worth noting that the recommendations where a greater variation in power consumption was generated were less common, and also that a high number of recommendations had a small impact on the energy consumed (see Table 9).

Table 9

PC components in which each recommendation has an impact on the power consumption (icons downloaded from https://www.flaticon.com/).

Fig. 10

Graphical comparisons between maximum component power consumption and power variation when a recommendation is implemented.

Conclusions

In this paper, the sustainability of PHRs is studied. Power consumption was measured throughout the use of the PHRs selected. Data gathered was analyzed in terms of energy efficiency, identifying several characteristics that contribute to sustainability. Recommendations to improve energy efficiency of applications were provided. Programmers and software systems designers may find many benefits in these best practices, allowing the implementation of efficient user services and software architectures. Best practices in energy-efficient computing extracted from this study are summarized as follows.

A tradeoff must be reached between GUI energy efficiency and a good experience from the user’s perspective (related recommendations REC-1, 2, 3 and 4).

Batch I/O to power down devices when not used and move tasks from an energy consuming state to another more energy-efficient environment (related recommendations REC-5, 12 and 18).

Reduce data redundancy and evaluate energy profiles to optimize the energy use (related recommendations REC- 6, 7 and 8).

Design efficient UIs that allow a task to be completed quickly and easily (related recommendations REC-9, 10, 11, 12 and 13).

The definition of patterns that best represent energy efficiency when designing could be another example of the production of knowledge for later reuse (related recommendations REC 14, 15 16 and 17).

The same methodology employed in this paper as displayed in Fig. 1 would be valid in other types of software such as business enterprises, social media, blogs and so on. Only a few changes would need to be carried out. For instance, the software tools should be selected, the task to perform may be adapted to the expected scenarios in the tools selected, and finally, the power measurements should be collected.

The catalogue CAT-SUST proposed in this paper is a contribution that could be a good starting point for the implementation of good practices and of auditing. This catalogue contains recommendations that can be used by programmers when developing software. The main advantage of its use is to create energy efficient applications that allows the sustainable control of any process on a large scale, resulting in cleaner industrial production. A catalogue of these characteristics brings together best practice guidelines from various sources in a single document, thus saving time to the technicians. As a matter of fact, software development represents a potential opportunity for cleaner technologies, in particular in software product lines, which are software-intensive systems developed with similar means on a large scale, or in industrial software, where massive energy expenditure occurs.

As already mentioned, good usability of web portals can be associated with more power-demanding software (e.g. color scheme vs display technology). The evaluation of energy measurements, together with usability assessments, could help to achieve a dual goal; software that is developed to improve usability can at the same time achieve energy efficiency.

This study could be extended for other current technological systems, such as mobile phones or wearables. To this end, power measurements should be available for collection in this kind of devices. By way of example, the ALARCOS group of the University of Castilla-La Mancha is researching in the development of equipment capable of measuring power consumption in cell phones. This work presents important challenges, since the integration of the electronics is on a smaller scale than in computers. These machines will make it possible to move the research presented in this paper to the domain of mobile technology.

Although EET has been validated with other measuring equipment, the approval of this power consumption device under international regulations is intended in the future. This would guarantee accuracy in the experiments, since the use of certified devices would bring more certainty when analyzing the data. Moreover, this kind of instrumentation would make the auditing and comparison in software easier, raising awareness among developers about the issue of sustainability.

CRediT authorship contribution statement

José A. García-Berná: Conceptualization, Data curation, Formal analysis, Investigation, Methodology, Visualization, Writing - original draft, Writing - review & editing. José L. Fernández-Alemán: Conceptualization, Formal analysis, Funding acquisition, Investigation, Methodology, Project administration, Resources, Supervision, Validation, Visualization, Writing - original draft, Writing - review & editing. Juan M. Carrillo de Gea: Formal analysis, Supervision, Validation, Writing - review & editing. Ambrosio Toval: Funding acquisition, Project administration, Resources, Supervision, Validation, Writing - review & editing. Javier Mancebo: Data curation, Software, Writing - review & editing. Coral Calero: Funding acquisition, Project administration, Resources, Software, Supervision, Writing - review & editing. Félix García: Funding acquisition, Project administration, Resources, Software, Supervision, Writing - review & editing.

Declaration of competing interest

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.