See

discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/274699048

Applying ISO/IEC 25010 on Mobile Personal

Health Records

Conference Paper January 2015

DOI: 10.5220/0005216604050412

CITATIONS READS

4 258

5 authors, including:

Sofia Ouhbi Ali Idri

University of Murcia Ecole Nationale Suprieure d'Informatique e
21 PUBLICATIONS 54 CITATIONS 125 PUBLICATIONS 676 CITATIONS

SEE PROFILE SEE PROFILE

Jos Luis Fernndez-Alemn Ambrosio Toval

University of Murcia University of Murcia
99 PUBLICATIONS 593 CITATIONS 146 PUBLICATIONS 1,244 CITATIONS

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Green in Software Systems and Software Engineering-UMU (GINSENG-UMU) View project

Implementation of Software Engineering Competence Remote Evaluation for Master Graduates

(ISECRET) View project

All content following this page was uploaded by Sofia Ouhbi on 09 October 2015.

The user has requested enhancement of the downloaded file. All in-text references underlined in blue are added to the original document
and are linked to publications on ResearchGate, letting you access and read them immediately.
 Applying ISO/IEC 25010 on Mobile Personal Health Records

Sofia Ouhbi1 , Ali Idri1 , Jose Luis Fernandez-Aleman2 , Ambrosio Toval2 and Halima Benjelloun3
1 Software Project Management research team, ENSIAS, Mohammed V University, Rabat, Morocco
2 Department of Informatics and Systems, Faculty of Computer Science, University of Murcia, Murcia, Spain
3 Autonomic Nervous System research team, Faculty of Medicine, Mohammed V University, Rabat, Morocco

[email protected], [email protected], {aleman, atoval}@um.es, [email protected]

Keywords: Personal health records, Mobile applications, ISO/IEC 25010, Software quality

Abstract: Software product quality requirements reflect the stockholders needs in terms of quality. They play a central
role in the success of the system and the software product quality. This paper lists mobile personal health
record (mPHR) requirements extracted from literature and identifies the requirements which should be in-
cluded in the mPHR quality evaluation. Moreover, the ISO/IEC 25010 software product quality model is
used to present a checklist with which to calculate the influence of the mPHR requirements on software prod-
uct quality. Furthermore, the degrees of influence of mPHR requirements on software product quality are
calculated and analyzed. A set of recommendations for mPHRs developers and stakeholders is provided.

1 INTRODUCTION in the process of software product quality require-

ments elicitation or as input for an evaluation pro-
Personal health records (PHRs) provide users with the cess (ISO/IEC-25010, 2011). The ISO/IEC 25030
possibility of managing their own health data. Many standard (ISO/IEC-25030, 2007) presents guidelines
patients are using PHRs to communicate with doc- concerning the definition and the evaluation of SQR.
tors in order to improve healthcare quality and effi- This standard is part of the international research
ciency (Fernandez-Aleman et al., 2013). An mPHR standardization project SQuaRE which developed the
is a mobile application that allows users to access and ISO/IEC standard series 250nn for software prod-
coordinate their lifelong health information through uct quality, evaluated from the viewpoint of users
their smartphones and to make appropriate data avail- and stakeholders. The ISO/IEC 25010 standard
able to those who need it. MPHRs are very useful (ISO/IEC-25010, 2011), which has replaced the
for people with chronic diseases (Chang et al., 2010). ISO/IEC 9126-1 (ISO/IEC-9126-1, 2001), defines a
A large number of companies have emerged to pro- software product quality model along with a system
vide consumers with the opportunity to use mPHRs quality in use model. The ISO/IEC 25010 software
within a healthcare platform (Kharrazi et al., 2012). product quality model is composed of eight character-
An increasing number of studies have been published istics, which are subdivided into sub-characteristics
discussing different mPHR characteristics, function- that can be measured internally or externally. The
alities and requirements (Chang et al., 2010; Simon use of a software product quality model is essential in
and Seldon, 2012; Kharrazi et al., 2012; Al-Habsi and the quality requirement definition process (ISO/IEC-
Seldon, 2013; Dohan et al., 2014). General inherent 25030, 2007). The aim of this paper is to propose
property requirements should be taken into consider- a general set of mPHR requirements reported in lit-
ation before the development of an mPHR. These re- erature and to identify which requirements should be
quirements include functional requirements and soft- involved in the software product quality evaluation of
ware quality requirements (SQR). An SQR represents an mPHR. This paper also aims to suggest a check-
a target value of the software quality (SQ) measure list for mPHR SQR and to evaluate the degrees of in-
(ISO/IEC-25030, 2007). A previous research work fluence of mPHR requirements on software product
(Ouhbi et al., 2013) has shown that an increasing quality characteristics by using the ISO/IEC 25010
amount of attention has been paid to SQR since 2007. standard (ISO/IEC-25010, 2011).
Defining SQR is a critical stage in the soft- The remainder of this paper is organized as fol-
ware requirements process and SQR can be used lows: Section 2 extracts general requirements for
an mPHR from literature. Section 3 presents an such as people suffering from a chronic disease, or it
overview of the ISO/IEC 25010 standard. Section is open for all users. AA5: geographical limitation. It
4 provides an analysis of the influence of mPHR re- is necessary to define whether the app should be avail-
quirements on software product quality. The results able for a certain geographic area, or should have an
are presented in Section 5 and discussed in Section 6. open access for users from allover the world. AA6:
Section 7 shows the conclusions of this study and an network operators limitation. In some cases, the net-
overview of future work. work operator sponsors apps which will be available
only for its users.

2 MPHR REQUIREMENTS 2.2 Users personal information

This section presents the general requirements for an An mPHR should contain a profile section which con-
mPHR that should be taken into consideration dur- tains the users personal information (PI). The users
ing the requirements elicitation phase. The follow- profile can be of great importance if s/he wishes to
ing requirements were extracted from several stud- share information with another party. The user pro-
ies on mPHRs and also from the evaluation of exist- file requirements should therefore cover the following
ing mPHRs in app repositories. The study by (Khar- data: PI1: full name, PI2: age, PI3: marital status,
razi et al., 2012) attempted to identify the data ele- PI4: insurance type, PI5: phone number, PI6: email
ments and application features implemented in cur- and PI7: address.
rent mPHRs in order to define the common com-
ponents of a typical mPHR. The paper by (Simon 2.3 Users physical body quantitative
and Seldon, 2012) has also presented some mPHR data
functionalities while discussing an exchange data
method for mPHRs. Some requirements were ex- The role of the mPHR is to help the user keep track of
tracted from a study concerning diabetics mPHR his/her physical body quantitative data (QD). The fol-
(Chang et al., 2010) and requirements for web-based lowing data should figure in any mPHR to help users
PHRs were also taken into consideration (Fernandez- with different kinds of health problems track their
Aleman et al., 2013). The general requirements for measurements: QD1: height, QD2: weight, QD3:
an mPHR were selected and gathered in six blocks: temperature, QD4: heart frequency, QD5: glucose
apps accessibility, users personal information, users and QD6: blood pressure.
physical body quantitative data, users health infor-
mation, users actions, and apps features. 2.4 Users health information
2.1 Apps accessibility The users medical record should contain some or all
of the following health information (HI): HI1: ill-
Apps accessibility (AA) refers to the availability of ness history. HI2: family illness history. HI3: blood
the mPHR for users either before or after installa- group. HI4: medication list. HI5: allergies. HI6:
tion in the users smartphone. AA1: OS type. This fertility. HI7: surgical procedures. HI8: social his-
requirement for the operating system (OS) type con- tory such as: alcoholism, drug addiction and tabag-
cerns the availability of the mPHR in app repositories. ism. HI9: immunizations. HI10: psychological dis-
Is it limited to a specific store? The well-known OS orders. HI11: emotional disorders.
types are: Android, iOS, Blackberry and Windows
Phone. AA2: OS version. This requirement is im- 2.5 Users actions
portant as regards the accessibility of the mPHR. An
agreement should be reached as to whether the app Different users actions (UA) should be specified in
will be accessible to a certain OS version or it should the requirements document. UA define the set of ac-
be available for all smartphones using the same OS. tions that the user can take while using the mPHR. It
AA3: cost. Is the mPHR free or does it cost money? should be specified whether the user can or cannot:
This requirement should be taken into consideration UA1: add information, UA2: remove information,
by stakeholders as free apps are more popular (Pet- UA3: modify information, UA4: be authenticated.
sas et al., 2013) but paid apps might have a more ad- An authentication method can be a login/ password
vanced set of functionalities (dHeureuse et al., 2012). or a two-factor authentication or biometric authentica-
AA4: target audience. This requirement should spec- tion, UA5: import data UA6: export data UA7: share
ify whether the mPHR targets a certain audience type, information and UA8: backup data.
2.6 Apps features ties are composed of function and quality properties.
Functional properties determine what the software
An apps features (AF) are the functionality of the is able to do, while quality properties determine how
app. Requirements for AF may contain: AF1: health well the software performs (ISO/IEC-25010, 2011).
advice. This could help the user to improve his/her
way of life. AF2: social media. AF3: images. AF4:
alarm system. Alarms can be set for medication in- 4 MPHR REQUIREMENTS
take time or appointments with doctors. AF5: notifi-
cation messages. Messages can be push notifications INFLUENCE ANALYSIS
or short message service SMS which are sent by an-
other party in order to notify the user. AF6: inter- This section presents the analysis process used to cal-
nationalization. Is the mPHR available in more than culate the influence of the mPHRs requirements de-
one language? International access is reflected by the fined in this study on software product quality, along
number of languages supported by the mPHR. AF7: with an illustration example. The analysis process is
usability guidance. This contains information that can based on that of (Idri et al., 2013) but was adapted to
help the user handle the app. This information should our needs in order to answer the following questions:
be clear and concise. AF8: emergency contact. In the Q1 Which mPHR requirements should be considered
case of an emergency, the user should have an easy ac- when evaluating mPHR quality?
cess to the phone numbers to be contacted. AF9: con- Q2 What influence do mPHR requirements have on
nection with EHR. EHR stands for Electronic Health software product quality?
Record. AF10: connection with labs. AF11: con-
nection with hospitals. AF12: connection with health In order to answer Q1, the mPHR requirements are
devices. AF13: connection with other PHRs. analyzed and SQR are identified by using the defi-
nition from ISO/IEC 25030. In order to answer Q2,
three steps are carried out in the analysis process:
Step 1 Analysis of the product quality charac-
3 ISO/IEC 25010 STANDARD teristics and sub-characteristics. The product qual-
ity model ISO/IEC 25010 was analyzed in order
The ISO/IEC 25010 quality model defines: (i) qual- to understand the meaning of each external sub-
ity in use, which is a measure of the overall quality characteristic. In order to obtain a better idea of the
of the system in its operational environment for spe- meaning of the mPHR SQR, the ISO/IEC 25023 stan-
cific users, for carrying out specific tasks, (ii) soft- dard should be used. However, the standard for the
ware product quality, which is composed of eight measurement of system and software product quality
characteristics that are further subdivided into sub- ISO/IEC 25023 is under development and the met-
characteristics that can be measured internally or ex- rics from the ISO/IEC 9126-2 external metric tech-
ternally: (1) external SQ addresses properties related nical report were therefore studied. All the compli-
to the execution of the software on computer hard- ance quality sub-characteristics were discarded owing
ware and the application of an OS, (2) internal SQ to the fact that conventions and compliance with reg-
addresses properties of the software product that are ulations are not relevant to this study.
typically available during the development. Internal Step 2 Checklist of mPHR requirements using
SQ has an impact on external SQ which again has an ISO/IEC 25010 software product quality model. The
impact on SQ in use (ISO/IEC-25010, 2011). Note potential influence of an mPHR requirement on an ex-
that the ISO/IEC 25010 standard has replaced the ternal sub-characteristic is checked. A software prod-
ISO/IEC 9126 standard in 2011. The ISO/IEC 25010 uct quality sub-characteristic is considered to be influ-
quality model differs somewhat from the ISO/IEC enced by a requirement if the variables used in the cal-
9126 quality model: security becomes a characteristic culation of the external metric are influenced by this
in ISO/IEC 25010 rather than a sub-characteristic for requirement. The unavailability of ISO/IEC 25023
functionality as it was in ISO/IEC 9126, compatibil- led us to use the external metrics defined in ISO/IEC
ity is added as a new characteristic in ISO/IEC 25010 9126-2. In the case of the new sub-characteristics of
and quality in use has five characteristics instead of ISO/IEC 25010, whose previous model did not pro-
the four characteristics of ISO/IEC 9126. vide external metrics, we analyzed the definitions pro-
The SQ measures defined in ISO/IEC 2502n are vided by ISO/IEC 25010 in order to estimate the in-
useful for formalizing stakeholder SQR. Software fluence of mPHR requirements on them.
product requirements are divided into inherent and as- Step 3 Calculation of degree of influence of mPHR
signed property requirements. The inherent proper- requirements on software product quality. Three de-
 Requirements+Block Functional+Suitability Reliability Performance+Efficiency Operability Security Compatibility Maintainability Transferability
AA 0.50 0.00 0.00 0.06 0.20 0.06 0.03 0.44
PI 0.50 1.00 1.00 0.67 0.20 0.00 0.17 0.00
QD 0.50 1.00 1.00 0.67 0.20 0.00 0.17 0.00
HI 0.50 1.00 1.00 0.67 0.20 0.00 0.17 0.00
UA 1.00 1.00 1.00 0.67 0.30 0.17 0.02 0.04
AF 0.85 1.00 1.00 0.69 0.34 0.18 0.10 0.00

Figure 1: Degree of influence of a block of requirements on an external characteristic

grees of influence are calculated: 5 RESULTS

1. DI(EC,B) = DI(EC, R) / N(R), where DI(EC,B)
This section presents the results of the mPHR require-
is the degree of influence of a block of require-
ments influence analysis.
ments B on an external characteristic EC and N(R)
is the total number of requirements in that block.
5.1 Requirements used to evaluate
2. DI(EC, R) = N(EsC, R) / N(EsC), where
DI(EC,R) is the degree of influence of a require- mPHR software product quality
ment R on an external characteristic EC, N(EsC,
R) is the number of sub-characteristics EsC of EC The software product quality of an mPHR on a smart-
that are influenced by that R, and N(EsC) is the phone with an OS should be evaluated using exter-
total number of sub-characteristics of EC. nal requirements. External software quality require-
ments are used as the target for technical verification
3. DI(EsC, B) = DI(EsC, R) / N(R), where
and validation of the software product (ISO/IEC-
DI(EsC,B) is the degree of influence of a block
25010, 2011). Requirements in block AA for cost
of requirements B on an EsC and N(R) is the total
and OS version are assigned property requirements
number of requirements in that block.
(ISO/IEC-25030, 2007). These requirements cannot
N(EC,R), N(EC), and N(R) are calculated from the therefore be used as SQR as they can be changed
checklist defined in Step 2. According to the result, without changing the software. The remaining mPHR
each degree of influence is classified into five groups: requirements identified in this study should be in-
Very high if the result is between 0.90 and 1.00; High cluded in the evaluation of the mPHRs software
if the result is between 0.7 and 0.89; Moderate if the product quality. Each requirement should be speci-
result is between 0.4 and 0.69; Low if the result is fied with a target quality measure in the requirements
between 0.2 and 0.39; and Very low if the result is document approved by the mPHR stakeholder.
between 0 and 0.19.
Illustration example: In this example we focus on 5.2 Influence of mPHR requirements
the degree of influence of block AA, which contains
six requirements, on the Transferability (T) charac- Table 1 shows the results of the software product
teristic. In order to calculate DI(T, AA) it is nec- quality model checklist. This checklist contains 30
essary to calculate the degree of influence of each software product quality sub-characteristics. Only a
AA requirement on Transferability: DI(T, AA) = few mPHR requirements are concerned with more
6i=1 (DI(T, AAi))/6. The requirement AA1 influ- than 50% of the external SQ sub-characteristics,
ences three Transferability sub-characteristics: Porta- while 60% are not dealt with. UA8 influences
bility, Adaptability and Installability. Thus, DI(T, half of the sub-characteristics. UA4, AF9, AF10,
AA1) = (1+1+1)/3 = 1. Following the same logic, we AF11 and AF13 have an impact on 16 external
obtain that: DI(T, AA2) = 1; DI(T, AA3) = 0; DI(T, sub-characteristics, while AF12 impacts on 17 sub-
AA4) = 0; DI(T, AA5) = 1/3; and DI(T, AA6) = 1/3. characteristics. The requirements in block AA have
So, DI(T, AA) = (1+1+0+0+1/3+1/3)/6 = 0.44. a very low impact on SQ. Figure 1 presents the de-
In this example we also calculate the degree of in- gree of influence of the blocks of requirements on
fluence of block AA on the Portability (P) sub- the external characteristics. The impact of the blocks
characteristic: DI(P, AA) = 6i=1 (DI(P, AAi))/6. PI, QD, HI, UA and AF on Reliability and Perfor-
Portability is influenced by AA1 and AA2, thus DI(P, mance efficiency is very high. In fact these blocks are
AA1) = 1; DI(P, AA2) = 1; and DI(P, AA3) = DI(P, the only blocks which have an impact on these two
AA4) = DI(P, AA5) = DI(P, AA6) = 0. characteristics. The UA influence on Functional Suit-
So, DI(P, AA) = (1+1+0+0+0+0)/6 = 0.33. The re- ability is also very high. All the blocks have a very
sults show that DI(T, AA1) and DI(T, AA) are mod- low influence on Compatibility and Maintainability.
erate while DI(P,AA) is low. Transferability is influenced moderately by AA. All
 Table 1: mPHR requirements vs software product quality characteristics checklist

Performance Efficiency
Functional Suitability

Maintainability

Transferability
Compatibility
Operability
Reliability

Security
Appropriateness recognisability

Technical accessibility

Modification stability
mPHR Requirements

Resource-utilization

Non-repudiation
Appropriateness

Interoperability
Confidentiality
Fault tolerance

Accountability
Time-behavior
Recoverability

Replaceability
Attractiveness

Changeability
Analyzability
Co-existence

Installability
Authenticity

Adaptability
Learnability

Helpfulness
Availability

Reusability
Ease of use

Modularity

Portability
Testability
Accuracy

Integrity
AA1 x - - - - - - - - - - - - - - - - - - - - - - - - - - x x x
AA2 x - - - - - - - - - - - - - - - - - - x - - x - - - - x x x
AA3 x - - - - - - x - - - - - - - - - - - - - - - - - - - - - -
AA4 x - - - - - - x - - - - - x x - - - - - - - - - - - - - - -
AA5 x - - - - - - - - - - - - x x - - - - - - - - - - - - - - x
AA6 x - - - - - - - - - - - - x x - - - - - - - - - - - - - - x
PI1 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
PI2 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
PI3 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
PI4 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
PI5 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
PI6 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
PI7 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
QD1 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
QD2 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
QD3 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
QD4 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
QD5 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
QD6 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI1 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI2 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI3 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI4 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI5 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI6 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI7 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI8 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI9 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI10 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI11 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
UA1 x x x x x x x x - x - x x - - x - - - - - - - - - - - - - -
UA2 x x x x x x x x - x - x x - - x - - - - - - - - - - - - - -
UA3 x x x x x x x x - x - x x - - x - - - - - - - - - - - - - -
UA4 x x x x x x x x - x - x x x x x x x - - - - - - - - - - - -
UA5 x x x x x x x x - x - x x - - x - - - - x - - - - - - - - -
UA6 x x x x x x x x - x - x x - - x - - - - x - - - - - - - - -
UA7 x x x x x x x x - x - x x - - x - - - - x - - - - - - - - -
UA8 x x x x x x x x - x - x x - - x - - x - - - x - - - - x - -
AF1 x - x x x x x x - x - x x - - - - - - - - x - - - - - - - -
AF2 x x x x x x x x - x - x x x - - - - - - x x - - - - - - - -
AF3 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
AF4 x x x x x x x x - x - x x - - - - - - - - x - - - - - - - -
AF5 x x x x x x x x - x - x x - - - - - - - - x - - - - - - - -
AF6 x x x x x x x x - x - x x - - - - - - - - x - - - - - - - -
AF7 x - x x x x x x x x x x x - - - - - - - - x - - - - - - - -
AF8 x - x x x x x x - x - x x - - - - - - - - x - - - - - - - -
AF9 x x x x x x x x - x - x x x x x x - - - x - - - - - - - - -
AF10 x x x x x x x x - x - x x x x x x - - - x - - - - - - - - -
AF11 x x x x x x x x - x - x x x x x x - - - x - - - - - - - - -
AF12 x x x x x x x x - x - x x x x x x - - x x - - - - - - - - -
AF13 x x x x x x x x - x - x x x x x x - - - x - - - - - - - - -

5.00
0.67

0.33 0.33 0.33 0.33 0.33

0.17 0.17
1.00

0.80

0.80

0.80

0.80

0.80

4.00 0.33 0.33 0.33 0.33 0.33

0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.17 0.17 0.17
0.17
0.17 0.17 0.17 0.17 0.17 0.17 0.17 0.17 0.17 0.17 0.17 0.17 0.17 0.17 0.17 0.17 0.17 0.17 0.17 0.17 0.17 0.17 0.17 0.17 0.17
0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.17 0.20 0.17
1.00

3.00
0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67

0.67
1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00
1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

2.00
1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00
1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00 1.00 0.17

0.40
0.33 0.33
0.33 0.17 0.40 0.40
1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

1.00

0.17
0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.50

0.00
AA1
AA2
AA3
AA4
AA5
AA6
PI1
PI2
PI3
PI4
PI5
PI6
PI7
QD1
QD2
QD3
QD4
QD5
QD6
HI1
HI2
HI3
HI4
HI5
HI6
HI7
HI8
HI9
HI10
HI11
UA1
UA2
UA3
UA4
UA5
UA6
UA7
UA8
AF1
AF2
AF3
AF4
AF5
AF6
AF7
AF8
AF9
AF10
AF11
AF12
AF13

Functional Suitability Reliability Performance Efficiency Operability Security Compatibility Maintainability Transferability

Figure 2: Degree of influence of a requirement on an external characteristic

 7.00

6.00
AF

5.00 AF
UA AF AF AF AF AF AF AF AF

4.00 UA AF
HI UA UA UA UA UA UA UA UA UA
AF
3.00 HI
HI UA
QD HI HI HI HI HI HI HI HI HI

2.00 QD
QD
PI QD QD QD QD QD QD QD QD QD
AF
AF
1.00 PI
PI
AF
AA UA PI PI PI PI PI PI PI PI UA UA AF PI
AF UA AA
AA AA AA AF UA UA AA AA
0.00 AF AF UA UA UA AA AA
ss

ce

ty

y
y
ity

y
y

ce

ss

ty

ty

ity

y
us
lit

lit

lit
lit
lit
io

es
ac

lit

lit

lit

lit

lit

lit

lit

lit

lit
ne

tio

io

ili
en
ne

ili

ili

i
gr
an

ic

ar
bi

bi

bi
bi
bi
v

en
bi

bi

bi

tia

bi

bi

bi

bi

i
at

ab
ur

of
te

ha

sib

ab

ab
ist
za

te
ul

nt
ra

za

lla
ea
ea

ul
er
ila

isa

na

ra

sta

sta

rta
di
tiv
ia

cc

us
en

In
se

pf

ex
ili

nt

pt
be

he
ve
ol

od
es

ng
ac

ly

sta
pu

pe
pr

va

ar
A

ac
gn

Po
Re

Te
el
Ea

fid
ut

da
ou
tt

n
o-

na
e-
co

cc

ut

pl

ha
ro

ro
Le

-re
A

In
tio
H

ttr
-

co
m

C
ul

A
A
la

on

cc

Re
ce
Re

A
pp

te

C
A

on
Ti
Fa

ca
re

A
ur

ca

In
C
A

ifi
N
ss
so

ni

od
ne

ch
Re

M
te

Te
ia
pr
ro
pp
A

Figure 3: Degree of influence of a block of requirements on an external sub-characteristic

the blocks have a low influence on Security. They holders and developers.
have a moderate influence on Operability except AA
which has a very low influence on this characteristic. 6.1 Principal findings
Figure 2 presents the degree of influence of the
mPHR requirements on the external characteristics.
All requirements have an influence on Functional The requirements listed in this study were extracted
suitability. Operability is influenced by 92% of from literature and from a compilation of existing
mPHR requirements, while 88% of the requirements mPHRs. Requirements such as Medication (HI4) and
affect Reliability and Performance efficiency. Secu- Allergies (HI5) exist in all the mPHRs evaluated by
rity and Maintainability are respectively influenced (Kharrazi et al., 2012) and the absence of these re-
by 69% and 63% of the mPHR requirements, while quirements may severely affect mPHR market pen-
Compatibility and Transferability are affected by only etration (Kharrazi et al., 2012). The mPHR require-
18% and 8% respectively. Figure 3 shows the de- ments identified were analyzed in order to select those
gree of influence of the blocks of mPHR require- that should be included in the evaluation of software
ments on the external sub-characteristic. This figure product quality. Software product quality is evaluated
provides a detailed view on the impact of mPHR re- by using SQR (ISO/IEC-25040, 2011). Apart from
quirements on each external characteristic by identi- requirements concerning cost and OS version in block
fying which of its components is concerned. The sub- AA, the other requirements can be translated to SQR
characteristic Appropriateness of Functional suitabil- by assigning a quality attribute that can have a target
ity is influenced by all the mPHR requirements. The measure to each requirement. The influence analysis
sub-characteristics of Reliability and Performance ef- results show that the requirements UA4, UA8, AF2,
ficiency are equally influenced by all the blocks ex- and AF9AF13 have a great influence on software
cept AA. Learnability and Helpfulness, which are product quality:
sub-characteristics of Operability, are influenced by Authentication (UA4) has a great influence on
only one mPHR requirement in block AF. The Se- mPHR software product quality. Information secu-
curity sub-characteristic that is most influenced by rity in mobile devices is a serious limitation and threat
mPHR requirements is Confidentiality. Compatibil- to the users personal data (Wasserman, 2010). Pro-
ity is mainly influenced through the sub-characteristic tecting users health information is one of the aspects
Interoperability. None of the mPHR requirements that may distinguish one mPHR from another. Var-
has influenced the following Maintainability sub- ious biometric authentication methods are being de-
characteristics: Analyzability, Changeability, Modifi- veloped for smartphones (Klonovs et al., 2013; Meng
cation stability, and Testability. Installability, which is et al., 2013), which may enhance the protection of
a sub-characteristic of Transferability, is moderately mPHR users personal medical records. The mPHR
influenced by block AA. user who is willing to back up his/her data (UA8)
is confronted with mobile limitations. Compared
with computers, smartphones have a limited memory,
which will limit their ability to store images and large
6 DISCUSSION data files (Wasserman, 2010). One solution to this is
the use of a cloud service, which can act as a stor-
This section summarizes the principal findings of this age mechanism and an intermediary for data transfer.
study and presents their implications for mPHR stake- However, an Internet connection is required, and the
user may once again confront some serious mobile interoperability with other parties. A cloud service
environment limitations such as frequent disconnec- can overcome problems of security in smartphones
tion and variable bandwidth (Peng, 2013). Moreover, and (Zonouz et al., 2013) has proposed a cloud-based
the study by (Ion et al., 2011) has shown that smart- comprehensive and lightweight security solution for
phone users do not trust the cloud as a data-storage smartphones.
environment and prefer to use home-based storage so-
lutions, such as storing data on their laptops. 6.2 Implications and advice for mPHR
Social media (AF2) usage highly influences stakeholders and developers
mPHR software product quality. Using social net-
works implies privacy and security issues, particu- This study provides a general view of mPHR require-
larly as regards sharing information related to health ments. It is up to stakeholders, developers and eval-
data. Despite the lack of privacy in social media, the uators to translate them to SQR. The mPHR SQR
mPHR users of social networks can obtain support can be used by those responsible for specifying and
and information from the social network community evaluating software product quality. Software prod-
which could help them to confront their health con- uct quality evaluation can be performed during or af-
dition (Fernandez-Aleman et al., 2013). Block AF ter the development process or acquisition process by
includes requirements for mPHR apps features that the developer organization, the acquirer organization
have a great influence on mPHR software product or an independent evaluator (ISO/IEC-25040, 2011).
quality, particularly requirements concerning mPHR The mPHR requirements for external software qual-
connections with other parties, such as EHR, labora- ity characteristics should be stated quantitatively in
tories and medical devices. According to (Al-Habsi the quality requirements specification using external
and Seldon, 2013), the lack of a standardized form of measures and then used as criteria when the mPHR
data exchange is one of the most common problems in is evaluated (ISO/IEC-25010, 2011). A checklist of
medical data exchange. (Al-Habsi and Seldon, 2013) mPHR requirements and their influence on software
have used free tools and open source software to de- product quality may be of great use to mPHR devel-
velop a communication module between mPHRs and opers. Stakeholders could formulate their mPHR re-
web-based PHRs. Their module uses a common mes- quirements by taking into consideration the sugges-
sage standard Continuity of Care Record (CCR), and tions made in this study.
message vocabulary standards.
The results also show that the external character- 6.3 Limitations
istics which are highly influenced by mPHR require-
ments are Reliability and Performance efficiency. A This study may have some limitations such as: (i)
previous study (Idri et al., 2013) has shown that Other mPHR requirements, which do not figure in
Reliability is influenced by frequent disconnection, our list, may have been relevant to this study. How-
variable bandwidth, and limited energy autonomy, ever, the mPHR requirements presented in this study
while Performance efficiency is influenced by lower were extracted from a large and relevant collection of
bandwidth and limited storage capacity. In the re- mPHR literature. (ii) The use of the definition of soft-
quirements elicitation phase, the mPHR requirements ware product quality characteristics rather than their
should be specified by taking into consideration these metrics. This limitation is owing to the fact that the
mobile environment limitations. Functional suit- ISO/IEC 25023 standard is unavailable since it is still
ability through Appropriateness, Operability through under development. The ISO/IEC 9126-2 technical
Ease of use, Attractiveness and Technical accessibil- report has therefore been used to alleviate this threat.
ity, and Security through Confidentiality are also in- These limitations may have slightly affected the re-
fluenced by the mPHR requirements. The Operability sults of our study. Nevertheless, we believe that our
characteristic in ISO/IEC 25010 refers to the Usabil- findings may be used in future works on mPHRs.
ity characteristic in ISO/IEC 9126 and was renamed
to avoid conflict with the definition of usability in
(ISO/IEC-25062, 2006). Operability may confront
the limited user interface of smartphones (Idri et al., 7 CONCLUSION and FUTURE
2013). The study by (Zapata et al., 2014) has ana- WORK
lyzed 24 mPHRs (Android and iOS only) and has con-
cluded that these mPHRs are not suitably structured This paper has extracted and analyzed 51 mPHR
in compliance with Android and iOS usability guide- requirements from literature. A list of mPHR require-
lines. Security is influenced by authentication and ments that should be included in the mPHR quality
 evaluation is suggested. The ISO/IEC 25010 software Ion, I., Sachdeva, N., Kumaraguru, P., and Capkun, S.
product quality model has been applied to the mPHR (2011). Home is safer than the cloud!: privacy con-
requirements identified in this study. A checklist con- cerns for consumer cloud storage. In 7th Symposium
taining 30 external sub-characteristics has been pre- on Usable Privacy and Security, page 13. ACM.
sented to calculate the influence of mPHR require- ISO/IEC-25010 (2011). Systems and software engineer-
ing Systems and software Quality Requirements and
ments on software product quality. The degrees of Evaluation (SQuaRE) System and software quality
influence of mPHR requirements on a software prod- models.
uct are calculated and analyzed. The results of this ISO/IEC-25030 (2007). Software engineering Soft-
study have shown that some characteristics, through ware product Quality Requirements and Evaluation
certain sub-characteristics, are more influenced by the (SQuaRE) Quality requirements.
mPHR requirements than others, particularly, Func- ISO/IEC-25040 (2011). Systems and software engineer-
tional suitability, Reliability, Performance efficiency, ing Systems and software Quality Requirements and
Operability and Security characteristics. As future Evaluation (SQuaRE) Evaluation process.
work, we intend to use the results from this study ISO/IEC-25062 (2006). Software engineering Soft-
as a basis to carry out an empirical evaluation of an ware product Quality Requirements and Evaluation
mPHR. We intend also to express the disparity and (SQuaRE) Common Industry Format (CIF) for us-
ability test reports.
variability in the degree of influence of the various
ISO/IEC-9126-1 (2001). Software engineering Product
mPHR requirements. quality Part 1: Quality models.
Kharrazi, H., Chisholm, R., VanNasdale, D., and Thomp-
son, B. (2012). Mobile personal health records: An
ACKNOWLEDGEMENTS evaluation of features and functionality. International
Journal of Medical Informatics, 81(9):579593.
This research is part of the mPHR project in Morocco Klonovs, J., Petersen, C. K., Olesen, H., and Hammershoj,
A. (2013). ID proof on the go: Development of a
financed by the Ministry of High education and Sci-
mobile EEG-based biometric authentication system.
entific research in Morocco 2014-2016. IEEE Vehicular Technology Magazine, 8(1):8189.
Meng, Y., Wong, D. S., Schlegel, R., et al. (2013). Touch
gestures based biometric authentication scheme for
REFERENCES touchscreen mobile phones. In Information Security
and Cryptology, pages 331350. Springer.
Al-Habsi, A. A. A. and Seldon, H. L. (2013). A commu- Ouhbi, S., Idri, A., Fernandez-Aleman, J. L., and Toval, A.
nication module for mobile personal health record. In (2013). Software quality requirements: A systematic
IEEE 7th International Power Engineering and Opti- mapping study. In 20th Asia-Pacific Software Engi-
mization Conference, PEOCO, pages 727731. neering Conference, APSEC, pages 231238.
Chang, I.-C., Hsiao, S.-J., Hsu, H.-M., and Chen, T.-H. Peng, C. (2013). Cellular Network for Mobile Devices
(2010). Building mPHR to assist diabetics in self- and Applications: Infrastructure Limitations and So-
healthcare management. In 7th International Con- lutions. PhD thesis, University of California.
ference on Service Systems and Service Management, Petsas, T., Papadogiannakis, A., Polychronakis, M.,
ICSSSM, pages 15. Markatos, E. P., and Karagiannis, T. (2013). Rise of
dHeureuse, N., Huici, F., Arumaithurai, M., Ahmed, M., the planet of the apps: a systematic study of the mobile
Papagiannaki, K., and Niccolini, S. (2012). Whats app ecosystem. In Internet Measurement Conference,
app?: a wide-scale measurement study of smart phone IMC, pages 277290. ACM.
markets. ACM SIGMOBILE Mobile Computing and Simon, S. K. and Seldon, H. L. (2012). Personal health
Communications Review, 16(2):1627. records: Mobile biosensors and smartphones for de-
Dohan, M. S., Abouzahra, M., and Tan, J. (2014). Mobile veloping countries. Global Telehealth, 2012:125131.
personal health records: Research agenda for applica- Wasserman, A. I. (2010). Software engineering issues for
tions in global health. In 47th Hawaii International mobile application development. In FSE/SDP Work-
Conference on System Sciences, HICSS, pages 2576 shop on Future of Software Engineering Research,
2585. FoSER, pages 397400. ACM.
Fernandez-Aleman, J. L., Seva-Llor, C. L., Toval, A., Zapata, B. C., Ninirola, A. H., Idri, A., Fernandez-Aleman,
Ouhbi, S., and Fernandez-Luque, L. (2013). Free J. L., and Toval, A. (2014). Mobile PHRs compliance
web-based personal health records: An analysis of with Android and iOS usability guidelines. Journal of
functionality. Journal of Medical Systems, 37(6):1 Medical Systems, 38(8):116.
16. Zonouz, S., Houmansadr, A., Berthier, R., Borisov, N., and
Idri, A., Moumane, K., and Abran, A. (2013). On the use of Sanders, W. (2013). Secloud: A cloud-based compre-
software quality standard ISO/IEC 9126 in mobile en- hensive and lightweight security solution for smart-
vironments. In 20th Asia-Pacific Software Engineer- phones. Computers & Security, 37:215227.
ing Conference, volume 1 of APSEC, pages 18.

View publication stats