Applying ISO/IEC 25010 on Mobile Personal Health Records

Soﬁa Ouhbi

, Ali Idri

, Jos

e Luis Fern

andez-Alem

, Ambrosio Toval

and Halima Benjelloun

Software Project Management research team, ENSIAS, Mohammed V University, Rabat, Morocco

Department of Informatics and Systems, Faculty of Computer Science, University of Murcia, Murcia, Spain

Autonomic Nervous System research team, Faculty of Medicine, Mohammed V University, Rabat, Morocco

Keywords:

Personal Health Records, Mobile Applications, ISO/IEC 25010, Software Quality.

Abstract:

Software product quality requirements reﬂect 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 identiﬁes 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 inﬂuence of the mPHR requirements on software prod-

uct quality. Furthermore, the degrees of inﬂuence of mPHR requirements on software product quality are

calculated and analyzed. A set of recommendations for mPHRs developers and stakeholders is provided.

1 INTRODUCTION

Personal health records (PHRs) provide users with the

possibility of managing their own health data. Many

patients are using PHRs to communicate with doc-

tors in order to improve healthcare quality and efﬁ-

ciency (Fern

andez-Alem

an et al., 2013). An mPHR

is a mobile application that allows users to access and

coordinate their lifelong health information through

their smartphones and to make appropriate data avail-

able to those who need it. MPHRs are very useful

for people with chronic diseases (Chang et al., 2010).

A large number of companies have emerged to pro-

vide consumers with the opportunity to use mPHRs

within a healthcare platform (Kharrazi et al., 2012).

An increasing number of studies have been published

discussing different mPHR characteristics, function-

alities and requirements (Chang et al., 2010; Simon

and Seldon, 2012; Kharrazi et al., 2012; Al-Habsi and

Seldon, 2013; Dohan et al., 2014). General inherent

property requirements should be taken into consider-

ation before the development of an mPHR. These re-

quirements include functional requirements and soft-

ware quality requirements (SQR). An SQR represents

a target value of the software quality (SQ) measure

(ISO/IEC-25030, 2007). A previous research work

(Ouhbi et al., 2013) has shown that an increasing

amount of attention has been paid to SQR since 2007.

Deﬁning SQR is a critical stage in the soft-

ware requirements process and SQR can be used

in the process of software product quality require-

ments elicitation or as input for an evaluation pro-

cess (ISO/IEC-25010, 2011). The ISO/IEC 25030

standard (ISO/IEC-25030, 2007) presents guidelines

concerning the deﬁnition and the evaluation of SQR.

This standard is part of the international research

standardization project SQuaRE which developed the

ISO/IEC standard series 250nn for software prod-

uct quality, evaluated from the viewpoint of users

and stakeholders. The ISO/IEC 25010 standard

(ISO/IEC-25010, 2011), which has replaced the

ISO/IEC 9126-1 (ISO/IEC-9126-1, 2001), deﬁnes a

software product quality model along with a system

quality in use model. The ISO/IEC 25010 software

product quality model is composed of eight character-

istics, which are subdivided into sub-characteristics

that can be measured internally or externally. The

use of a software product quality model is essential in

the quality requirement deﬁnition process (ISO/IEC-

25030, 2007). The aim of this paper is to propose

a general set of mPHR requirements reported in lit-

erature and to identify which requirements should be

involved in the software product quality evaluation of

an mPHR. This paper also aims to suggest a check-

list for mPHR SQR and to evaluate the degrees of in-

ﬂuence of mPHR requirements on software product

quality characteristics by using the ISO/IEC 25010

standard (ISO/IEC-25010, 2011).

The remainder of this paper is organized as fol-

lows: Section 2 extracts general requirements for

405

Ouhbi S., Idri A., Fernández-Alemán J., Toval A. and Benjelloun H..

Applying ISO/IEC 25010 on Mobile Personal Health Records.

DOI: 10.5220/0005216604050412

In Proceedings of the International Conference on Health Informatics (HEALTHINF-2015), pages 405-412

ISBN: 978-989-758-068-0

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

an mPHR from literature. Section 3 presents an

overview of the ISO/IEC 25010 standard. Section

4 provides an analysis of the inﬂuence of mPHR re-

quirements on software product quality. The results

are presented in Section 5 and discussed in Section 6.

Section 7 shows the conclusions of this study and an

overview of future work.

2 MPHR REQUIREMENTS

This section presents the general requirements for an

mPHR that should be taken into consideration dur-

ing the requirements elicitation phase. The follow-

ing requirements were extracted from several stud-

ies on mPHRs and also from the evaluation of exist-

ing mPHRs in app repositories. The study by (Khar-

razi et al., 2012) attempted to identify the data ele-

ments and application features implemented in cur-

rent mPHRs in order to deﬁne the common com-

ponents of a typical mPHR. The paper by (Simon

and Seldon, 2012) has also presented some mPHR

functionalities while discussing an exchange data

method for mPHRs. Some requirements were ex-

tracted from a study concerning diabetics’ mPHR

(Chang et al., 2010) and requirements for web-based

PHRs were also taken into consideration (Fern

andez-

Alem

an et al., 2013). The general requirements for

an mPHR were selected and gathered in six blocks:

app’s accessibility, user’s personal information, user’s

physical body quantitative data, user’s health infor-

mation, user’s actions, and app’s features.

2.1 App’s Accessibility

App’s accessibility (AA) refers to the availability of

the mPHR for users either before or after installa-

tion in the user’s smartphone. AA1: OS type. This

requirement for the operating system (OS) type con-

cerns the availability of the mPHR in app repositories.

Is it limited to a speciﬁc store? The well-known OS

types are: Android, iOS, Blackberry and Windows

Phone. AA2: OS version. This requirement is im-

portant as regards the accessibility of the mPHR. An

agreement should be reached as to whether the app

will be accessible to a certain OS version or it should

be available for all smartphones using the same OS.

AA3: cost. Is the mPHR free or does it cost money?

This requirement should be taken into consideration

by stakeholders as free apps are more popular (Pet-

sas et al., 2013) but paid apps might have a more ad-

vanced set of functionalities (d’Heureuse et al., 2012).

AA4: target audience. This requirement should spec-

ify whether the mPHR targets a certain audience type,

such as people suffering from a chronic disease, or it

is open for all users. AA5: geographical limitation. It

is necessary to deﬁne whether the app should be avail-

able for a certain geographic area, or should have an

open access for users from allover the world. AA6:

network operator’s limitation. In some cases, the net-

work operator sponsors apps which will be available

only for its users.

2.2 User’s Personal Information

An mPHR should contain a proﬁle section which con-

tains the user’s personal information (PI). The user’s

proﬁle can be of great importance if s/he wishes to

share information with another party. The user pro-

ﬁle requirements should therefore cover the following

data: PI1: full name, PI2: age, PI3: marital status,

PI4: insurance type, PI5: phone number, PI6: email

and PI7: address.

2.3 User’s Physical Body Quantitative

Data

The role of the mPHR is to help the user keep track of

his/her physical body quantitative data (QD). The fol-

lowing data should ﬁgure in any mPHR to help users

with different kinds of health problems track their

measurements: QD1: height, QD2: weight, QD3:

temperature, QD4: heart frequency, QD5: glucose

and QD6: blood pressure.

2.4 User’s Health Information

The user’s medical record should contain some or all

of the following health information (HI): HI1: ill-

ness history. HI2: family illness history. HI3: blood

group. HI4: medication list. HI5: allergies. HI6:

fertility. HI7: surgical procedures. HI8: social his-

tory such as: alcoholism, drug addiction and tabag-

ism. HI9: immunizations. HI10: psychological dis-

orders. HI11: emotional disorders.

2.5 User’s Actions

Different user’s actions (UA) should be speciﬁed in

the requirements document. UA deﬁne the set of ac-

tions that the user can take while using the mPHR. It

should be speciﬁed whether the user can or cannot:

UA1: add information, UA2: remove information,

UA3: modify information, UA4: be authenticated.

An authentication method can be a login/ password

or a two-factor authentication or biometric authentica-

tion, UA5: import data UA6: export data UA7: share

information and UA8: backup data.

HEALTHINF2015-InternationalConferenceonHealthInformatics

406

2.6 App’s Features

An app’s features (AF) are the functionality of the

app. Requirements for AF may contain: AF1: health

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-

take time or appointments with doctors. AF5: notiﬁ-

cation messages. Messages can be push notiﬁcations

or short message service SMS which are sent by an-

other party in order to notify the user. AF6: inter-

nationalization. Is the mPHR available in more than

one language? International access is reﬂected by the

number of languages supported by the mPHR. AF7:

usability guidance. This contains information that can

help the user handle the app. This information should

be clear and concise. AF8: emergency contact. In the

case of an emergency, the user should have an easy ac-

cess to the phone numbers to be contacted. AF9: con-

nection with EHR. EHR stands for Electronic Health

Record. AF10: connection with labs. AF11: con-

nection with hospitals. AF12: connection with health

devices. AF13: connection with other PHRs.

3 ISO/IEC 25010 STANDARD

The ISO/IEC 25010 quality model deﬁnes: (i) qual-

ity in use, which is a measure of the overall quality

of the system in its operational environment for spe-

ciﬁc users, for carrying out speciﬁc tasks, (ii) soft-

ware product quality, which is composed of eight

characteristics that are further subdivided into sub-

characteristics that can be measured internally or ex-

ternally: (1) external SQ addresses properties related

to the execution of the software on computer hard-

ware and the application of an OS, (2) internal SQ

addresses properties of the software product that are

typically available during the development. Internal

SQ has an impact on external SQ which again has an

impact on SQ in use (ISO/IEC-25010, 2011). Note

that the ISO/IEC 25010 standard has replaced the

ISO/IEC 9126 standard in 2011. The ISO/IEC 25010

quality model differs somewhat from the ISO/IEC

9126 quality model: security becomes a characteristic

in ISO/IEC 25010 rather than a sub-characteristic for

functionality as it was in ISO/IEC 9126, compatibil-

ity is added as a new characteristic in ISO/IEC 25010

and quality in use has ﬁve characteristics instead of

the four characteristics of ISO/IEC 9126.

The SQ measures deﬁned in ISO/IEC 2502n are

useful for formalizing stakeholder SQR. Software

product requirements are divided into inherent and as-

signed property requirements. The inherent proper-

ties are composed of function and quality properties.

“Functional properties determine what the software

is able to do, while quality properties determine how

well the software performs” (ISO/IEC-25010, 2011).

4 MPHR REQUIREMENTS

INFLUENCE ANALYSIS

This section presents the analysis process used to cal-

culate the inﬂuence of the mPHRs requirements de-

ﬁned in this study on software product quality, along

with an illustration example. The analysis process is

based on that of (Idri et al., 2013) but was adapted to

our needs in order to answer the following questions:

Q1 Which mPHR requirements should be considered

when evaluating mPHR quality?

Q2 What inﬂuence do mPHR requirements have on

software product quality?

In order to answer Q1, the mPHR requirements are

analyzed and SQR are identiﬁed by using the deﬁ-

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-

teristics and sub-characteristics. The product qual-

ity model ISO/IEC 25010 was analyzed in order

to understand the meaning of each external sub-

characteristic. In order to obtain a better idea of the

meaning of the mPHR SQR, the ISO/IEC 25023 stan-

dard should be used. However, the standard for the

measurement of system and software product quality

ISO/IEC 25023 is under development and the met-

rics from the ISO/IEC 9126-2 external metric tech-

nical report were therefore studied. All the compli-

ance quality sub-characteristics were discarded owing

to the fact that conventions and compliance with reg-

ulations are not relevant to this study.

Step 2. Checklist of mPHR requirements using

ISO/IEC 25010 software product quality model. The

potential inﬂuence of an mPHR requirement on an ex-

ternal sub-characteristic is checked. A software prod-

uct quality sub-characteristic is considered to be inﬂu-

enced by a requirement if the variables used in the cal-

culation of the external metric are inﬂuenced by this

requirement. The unavailability of ISO/IEC 25023

led us to use the external metrics deﬁned in ISO/IEC

9126-2. In the case of the new sub-characteristics of

ISO/IEC 25010, whose previous model did not pro-

vide external metrics, we analyzed the deﬁnitions pro-

vided by ISO/IEC 25010 in order to estimate the in-

ﬂuence of mPHR requirements on them.

Step 3. Calculation of degree of inﬂuence of

mPHR requirements on software product quality.

ApplyingISO/IEC25010onMobilePersonalHealthRecords

407

Requirements+Block Functional+Suitability Reliability Performance+Efficiency Operability Security Compatibility Maintainability Transferability

0.50 0.00 0.00 0.06 0.20 0.06 0.03 0.44

0.50 1.00 1.00 0.67 0.20 0.00 0.17 0.00

1.00 1.00 1.00 0.67 0.30 0.17 0.02 0.04

0.85 1.00 1.00 0.69 0.34 0.18 0.10 0.00

Figure 1: Degree of inﬂuence of a block of requirements on an external characteristic.

Three degrees of inﬂuence are calculated:

1. DI(EC,B) =

∑

DI(EC, R) / N(R), where DI(EC,B)

is the degree of inﬂuence of a block of require-

ments B on an external characteristic EC and N(R)

is the total number of requirements in that block.

2. DI(EC, R) = N(EsC, R) / N(EsC), where

DI(EC,R) is the degree of inﬂuence of a require-

ment R on an external characteristic EC, N(EsC,

R) is the number of sub-characteristics EsC of EC

that are inﬂuenced by that R, and N(EsC) is the

total number of sub-characteristics of EC.

3. DI(EsC, B) =

∑

DI(EsC, R) / N(R), where

DI(EsC,B) is the degree of inﬂuence of a block

of requirements B on an EsC and N(R) is the total

number of requirements in that block.

N(EC,R), N(EC), and N(R) are calculated from the

checklist deﬁned in Step 2. According to the result,

each degree of inﬂuence is classiﬁed into ﬁve groups:

Very high if the result is between 0.90 and 1.00; High

if the result is between 0.7 and 0.89; Moderate if the

result is between 0.4 and 0.69; Low if the result is

between 0.2 and 0.39; and Very low if the result is

between 0 and 0.19.

Illustration Example. In this example we fo-

cus on the degree of inﬂuence of block AA, which

contains six requirements, on the Transferability (T)

characteristic. In order to calculate DI(T, AA) it

is necessary to calculate the degree of inﬂuence of

each AA requirement on Transferability: DI(T, AA)

∑

i=1

(DI(T, AAi))/6. The requirement AA1 inﬂu-

ences three Transferability sub-characteristics: Porta-

bility, Adaptability and Installability. Thus, DI(T,

AA1) = (1+1+1)/3 = 1. Following the same logic, we

obtain that: DI(T, AA2) = 1; DI(T, AA3) = 0; DI(T,

AA4) = 0; DI(T, AA5) = 1/3; and DI(T, AA6) = 1/3.

So, DI(T, AA) = (1+1+0+0+1/3+1/3)/6 = 0.44.

In this example we also calculate the degree of in-

ﬂuence of block AA on the Portability (P) sub-

characteristic: DI(P, AA) =

∑

i=1

(DI(P, AAi))/6.

Portability is inﬂuenced by AA1 and AA2, thus DI(P,

AA1) = 1; DI(P, AA2) = 1; and DI(P, AA3) = DI(P,

AA4) = DI(P, AA5) = DI(P, AA6) = 0.

So, DI(P, AA) = (1+1+0+0+0+0)/6 = 0.33. The re-

sults show that DI(T, AA1) and DI(T, AA) are mod-

erate while DI(P,AA) is low.

5 RESULTS

This section presents the results of the mPHR require-

ments inﬂuence analysis.

5.1 Requirements Used to Evaluate

mPHR Software Product Quality

The software product quality of an mPHR on a smart-

phone with an OS should be evaluated using exter-

nal requirements. “External software quality require-

ments are used as the target for technical veriﬁcation

and validation of the software product” (ISO/IEC-

25010, 2011). Requirements in block AA for cost

and OS version are “assigned property requirements”

(ISO/IEC-25030, 2007). These requirements cannot

therefore be used as SQR as they can be changed

without changing the software. The remaining mPHR

requirements identiﬁed in this study should be in-

cluded in the evaluation of the mPHR’s software

product quality. Each requirement should be speci-

ﬁed with a target quality measure in the requirements

document approved by the mPHR stakeholder.

5.2 Inﬂuence of mPHR Requirements

Table 1 shows the results of the software product

quality model checklist. This checklist contains 30

software product quality sub-characteristics. Only a

few mPHR requirements are concerned with more

than 50% of the external SQ sub-characteristics,

while 60% are not dealt with. UA8 inﬂuences

half of the sub-characteristics. UA4, AF9, AF10,

AF11 and AF13 have an impact on 16 external

sub-characteristics, while AF12 impacts on 17 sub-

characteristics. The requirements in block AA have

a very low impact on SQ. Figure 1 presents the de-

gree of inﬂuence of the blocks of requirements on

the external characteristics. The impact of the blocks

PI, QD, HI, UA and AF on Reliability and Perfor-

mance efﬁciency is very high. In fact these blocks are

the only blocks which have an impact on these two

characteristics. The UA inﬂuence on Functional Suit-

ability is also very high. All the blocks have a very

low inﬂuence on Compatibility and Maintainability.

HEALTHINF2015-InternationalConferenceonHealthInformatics

408

Table 1: mPHR requirements vs software product quality characteristics checklist.

Functional Suitability

Reliability

Performance Efﬁciency

Operability

Security

Compatibility

Maintainability

Transferability

mPHR Requirements

Appropriateness

Accuracy

Availability

Fault tolerance

Recoverability

Time-behavior

Resource-utilization

Appropriateness recognisability

Learnability

Ease of use

Helpfulness

Attractiveness

Technical accessibility

Conﬁdentiality

Integrity

Non-repudiation

Accountability

Authenticity

Replaceability

Co-existence

Interoperability

Modularity

Reusability

Analyzability

Changeability

Modiﬁcation stability

Testability

Portability

Adaptability

Installability

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 - - - - - - - - -

Transferability is inﬂuenced moderately by AA. All

the blocks have a low inﬂuence on Security. They

have a moderate inﬂuence on Operability except AA

which has a very low inﬂuence on this characteristic.

Figure 2 presents the degree of inﬂuence of the

mPHR requirements on the external characteristics.

All requirements have an inﬂuence on Functional

suitability. Operability is inﬂuenced by 92% of

mPHR requirements, while 88% of the requirements

affect Reliability and Performance efﬁciency. Secu-

rity and Maintainability are respectively inﬂuenced

by 69% and 63% of the mPHR requirements, while

Compatibility and Transferability are affected by only

18% and 8% respectively. Figure 3 shows the de-

gree of inﬂuence of the blocks of mPHR require-

ments on the external sub-characteristic. This ﬁgure

provides a detailed view on the impact of mPHR re-

quirements on each external characteristic by identi-

fying which of its components is concerned. The sub-

characteristic Appropriateness of Functional suitabil-

ApplyingISO/IEC25010onMobilePersonalHealthRecords

409

0.50

1.00

0.50

1.00

0.50

1.00

0.50

1.00

0.17 0.17

0.67

1.00

0.67

0.40

0.40 0.40

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.20 0.20 0.20

1.00

0.20 0.20 0.20 0.20 0.20

0.20

0.80

0.33

0.33 0.33 0.33 0.33 0.33

0.33 0.33 0.33

0.67

0.33

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.17

1.00

0.33 0.33

0.33

0.00

1.00

2.00

3.00

4.00

5.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 inﬂuence of a requirement on an external characteristic.

AA AA

PI PI PI PI PI

PI PI PI

QD QD QD QD QD

QD QD QD

HI HI HI HI HI

HI HI HI

UA UA UA UA UA

UA UA UA

AF AF AF AF AF

AF AF

0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

Appropriateness

Accuracy

Availability

Fault tolerance

Recoverability

Time-behavior

Resource-utilization

Appropriateness recognisability

Learnability

Ease of use

Helpfulness

Attractiveness

Technical accessibility

Confidentiality

Integrity

Non-repudiation

Accountability

Authenticity

Replaceability

Co-existence

Interoperability

Modularity

Reusability

Analyzability

Changeability

Modification stability

Testability

Portability

Adaptability

Installability

Figure 3: Degree of inﬂuence of a block of requirements on an external sub-characteristic.

ity is inﬂuenced by all the mPHR requirements. The

sub-characteristics of Reliability and Performance ef-

ﬁciency are equally inﬂuenced by all the blocks ex-

cept AA. Learnability and Helpfulness, which are

sub-characteristics of Operability, are inﬂuenced by

only one mPHR requirement in block AF. The Se-

curity sub-characteristic that is most inﬂuenced by

mPHR requirements is Conﬁdentiality. Compatibil-

ity is mainly inﬂuenced through the sub-characteristic

Interoperability. None of the mPHR requirements

has inﬂuenced the following Maintainability sub-

characteristics: Analyzability, Changeability, Modiﬁ-

cation stability, and Testability. Installability, which is

a sub-characteristic of Transferability, is moderately

inﬂuenced by block AA.

6 DISCUSSION

This section summarizes the principal ﬁndings of this

study and presents their implications for mPHR stake-

holders and developers.

6.1 Principal Findings

The requirements listed in this study were extracted

from literature and from a compilation of existing

mPHRs. Requirements such as Medication (HI4) and

Allergies (HI5) exist in all the mPHRs evaluated by

(Kharrazi et al., 2012) and the absence of these re-

quirements may severely affect mPHR market pen-

etration (Kharrazi et al., 2012). The mPHR require-

ments identiﬁed were analyzed in order to select those

that should be included in the evaluation of software

product quality. Software product quality is evaluated

by using SQR (ISO/IEC-25040, 2011). Apart from

requirements concerning cost and OS version in block

AA, the other requirements can be translated to SQR

by assigning a quality attribute that can have a target

measure to each requirement. The inﬂuence analysis

results show that the requirements UA4, UA8, AF2,

and AF9–AF13 have a great inﬂuence on software

product quality:

Authentication (UA4) has a great inﬂuence on

mPHR software product quality. Information secu-

rity in mobile devices is a serious limitation and threat

to the users’ personal data (Wasserman, 2010). Pro-

tecting users’ health information is one of the aspects

that may distinguish one mPHR from another. Var-

ious biometric authentication methods are being de-

veloped for smartphones (Klonovs et al., 2013; Meng

et al., 2013), which may enhance the protection of

mPHR users’ personal medical records. The mPHR

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

data ﬁles (Wasserman, 2010). One solution to this is

the use of a cloud service, which can act as a stor-

age mechanism and an intermediary for data transfer.

HEALTHINF2015-InternationalConferenceonHealthInformatics

410

However, an Internet connection is required, and the

user may once again confront some serious mobile

environment limitations such as frequent disconnec-

tion and variable bandwidth (Peng, 2013). Moreover,

the study by (Ion et al., 2011) has shown that smart-

phone users do not trust the cloud as a data-storage

environment and prefer to use home-based storage so-

lutions, such as storing data on their laptops.

Social media (AF2) usage highly inﬂuences

mPHR software product quality. Using social net-

works implies privacy and security issues, particu-

larly as regards sharing information related to health

data. Despite the lack of privacy in social media, the

mPHR users of social networks can obtain support

and information from the social network community

which could help them to confront their health con-

dition (Fern

andez-Alem

an et al., 2013). Block AF

includes requirements for mPHR app’s features that

have a great inﬂuence on mPHR software product

quality, particularly requirements concerning mPHR

connections with other parties, such as EHR, labora-

tories and medical devices. According to (Al-Habsi

and Seldon, 2013), the lack of a standardized form of

data exchange is one of the most common problems in

medical data exchange. (Al-Habsi and Seldon, 2013)

have used free tools and open source software to de-

velop a communication module between mPHRs and

web-based PHRs. Their module uses a common mes-

sage standard Continuity of Care Record (CCR), and

message vocabulary standards.

The results also show that the external character-

istics which are highly inﬂuenced by mPHR require-

ments are Reliability and Performance efﬁciency. A

previous study (Idri et al., 2013) has shown that

Reliability is inﬂuenced by frequent disconnection,

variable bandwidth, and limited energy autonomy,

while Performance efﬁciency is inﬂuenced by lower

bandwidth and limited storage capacity. In the re-

quirements elicitation phase, the mPHR requirements

should be speciﬁed by taking into consideration these

mobile environment limitations. Functional suit-

ability through Appropriateness, Operability through

Ease of use, Attractiveness and Technical accessibil-

ity, and Security through Conﬁdentiality are also in-

ﬂuenced by the mPHR requirements. The Operability

characteristic in ISO/IEC 25010 refers to the Usabil-

ity characteristic in ISO/IEC 9126 and was renamed

to avoid conﬂict with the deﬁnition of usability in

(ISO/IEC-25062, 2006). Operability may confront

the limited user interface of smartphones (Idri et al.,

2013). The study by (Zapata et al., 2014) has ana-

lyzed 24 mPHRs (Android and iOS only) and has con-

cluded that these mPHRs are not suitably structured

in compliance with Android and iOS usability guide-

lines. Security is inﬂuenced by authentication and

interoperability with other parties. A cloud service

can overcome problems of security in smartphones

and (Zonouz et al., 2013) has proposed a cloud-based

comprehensive and lightweight security solution for

smartphones.

6.2 Implications and Advice for mPHR

Stakeholders and Developers

This study provides a general view of mPHR require-

ments. It is up to stakeholders, developers and eval-

uators to translate them to SQR. The mPHR SQR

can be used by those responsible for specifying and

evaluating software product quality. Software prod-

uct quality evaluation can be performed “during or af-

ter the development process or acquisition process by

the developer organization, the acquirer organization

or an independent evaluator” (ISO/IEC-25040, 2011).

The mPHR requirements for external software qual-

ity characteristics should be stated quantitatively in

the quality requirements speciﬁcation using external

measures and then used as criteria when the mPHR

is evaluated (ISO/IEC-25010, 2011). A checklist of

mPHR requirements and their inﬂuence on software

product quality may be of great use to mPHR devel-

opers. Stakeholders could formulate their mPHR re-

quirements by taking into consideration the sugges-

tions made in this study.

6.3 Limitations

This study may have some limitations such as: (i)

Other mPHR requirements, which do not ﬁgure in

our list, may have been relevant to this study. How-

ever, the mPHR requirements presented in this study

were extracted from a large and relevant collection of

mPHR literature. (ii) The use of the deﬁnition of soft-

ware product quality characteristics rather than their

metrics. This limitation is owing to the fact that the

ISO/IEC 25023 standard is unavailable since it is still

under development. The ISO/IEC 9126-2 technical

report has therefore been used to alleviate this threat.

These limitations may have slightly affected the re-

sults of our study. Nevertheless, we believe that our

ﬁndings may be used in future works on mPHRs.

7 CONCLUSION AND FUTURE

WORK

This paper has extracted and analyzed 51 mPHR re-

quirements from literature. A list of mPHR require-

ments that should be included in the mPHR quality

ApplyingISO/IEC25010onMobilePersonalHealthRecords

411

evaluation is suggested. The ISO/IEC 25010 software

product quality model has been applied to the mPHR

requirements identiﬁed in this study. A checklist con-

taining 30 external sub-characteristics has been pre-

sented to calculate the inﬂuence of mPHR require-

ments on software product quality. The degrees of

inﬂuence of mPHR requirements on a software prod-

uct are calculated and analyzed. The results of this

study have shown that some characteristics, through

certain sub-characteristics, are more inﬂuenced by the

mPHR requirements than others, particularly, Func-

tional suitability, Reliability, Performance efﬁciency,

Operability and Security characteristics. As future

work, we intend to use the results from this study

as a basis to carry out an empirical evaluation of an

mPHR. We intend also to express the disparity and

variability in the degree of inﬂuence of the various

mPHR requirements.

ACKNOWLEDGEMENTS

This research is part of the mPHR project in Morocco

ﬁnanced by the Ministry of High education and Sci-

entiﬁc research in Morocco 2014-2016.

REFERENCES

Al-Habsi, A. A. A. and Seldon, H. L. (2013). A commu-

nication module for mobile personal health record. In

IEEE 7th International Power Engineering and Opti-

mization Conference, PEOCO, pages 727–731.

Chang, I.-C., Hsiao, S.-J., Hsu, H.-M., and Chen, T.-H.

(2010). Building mPHR to assist diabetics in self-

healthcare management. In 7th International Con-

ference on Service Systems and Service Management,

ICSSSM, pages 1–5.

d’Heureuse, N., Huici, F., Arumaithurai, M., Ahmed, M.,

Papagiannaki, K., and Niccolini, S. (2012). What’s

app?: a wide-scale measurement study of smart phone

markets. ACM SIGMOBILE Mobile Computing and

Communications Review, 16(2):16–27.

Dohan, M. S., Abouzahra, M., and Tan, J. (2014). Mobile

personal health records: Research agenda for applica-

tions in global health. In 47th Hawaii International

Conference on System Sciences, HICSS, pages 2576–

2585.

Fern

andez-Alem

an, J. L., Seva-Llor, C. L., Toval, A.,

Ouhbi, S., and Fern

andez-Luque, L. (2013). Free

web-based personal health records: An analysis of

functionality. Journal of Medical Systems, 37(6):1–

16.

Idri, A., Moumane, K., and Abran, A. (2013). On the use of

software quality standard ISO/IEC 9126 in mobile en-

vironments. In 20th Asia-Paciﬁc Software Engineer-

ing Conference, volume 1 of APSEC, pages 1–8.

Ion, I., Sachdeva, N., Kumaraguru, P., and

Capkun, S.

(2011). Home is safer than the cloud!: privacy con-

cerns for consumer cloud storage. In 7th Symposium

on Usable Privacy and Security, page 13. ACM.

ISO/IEC-25010 (2011). Systems and software engineer-

ing – Systems and software Quality Requirements and

Evaluation (SQuaRE) – System and software quality

models.

ISO/IEC-25030 (2007). Software engineering – Soft-

ware product Quality Requirements and Evaluation

(SQuaRE) – Quality requirements.

ISO/IEC-25040 (2011). Systems and software engineer-

ing – Systems and software Quality Requirements and

Evaluation (SQuaRE) – Evaluation process.

ISO/IEC-25062 (2006). Software engineering – Soft-

ware product Quality Requirements and Evaluation

(SQuaRE) – Common Industry Format (CIF) for us-

ability test reports.

ISO/IEC-9126-1 (2001). Software engineering – Product

quality – Part 1: Quality models.

Kharrazi, H., Chisholm, R., VanNasdale, D., and Thomp-

son, B. (2012). Mobile personal health records: An

evaluation of features and functionality. International

Journal of Medical Informatics, 81(9):579–593.

Klonovs, J., Petersen, C. K., Olesen, H., and Hammershoj,

A. (2013). ID proof on the go: Development of a

mobile EEG-based biometric authentication system.

IEEE Vehicular Technology Magazine, 8(1):81–89.

Meng, Y., Wong, D. S., Schlegel, R., et al. (2013). Touch

gestures based biometric authentication scheme for

touchscreen mobile phones. In Information Security

and Cryptology, pages 331–350. Springer.

Ouhbi, S., Idri, A., Fernandez-Aleman, J. L., and Toval, A.

(2013). Software quality requirements: A systematic

mapping study. In 20th Asia-Paciﬁc Software Engi-

neering Conference, APSEC, pages 231–238.

Peng, C. (2013). Cellular Network for Mobile Devices

and Applications: Infrastructure Limitations and So-

lutions. PhD thesis, University of California.

Petsas, T., Papadogiannakis, A., Polychronakis, M.,

Markatos, E. P., and Karagiannis, T. (2013). Rise of

the planet of the apps: a systematic study of the mobile

app ecosystem. In Internet Measurement Conference,

IMC, pages 277–290. ACM.

Simon, S. K. and Seldon, H. L. (2012). Personal health

records: Mobile biosensors and smartphones for de-

veloping countries. Global Telehealth, 2012:125–131.

Wasserman, A. I. (2010). Software engineering issues for

mobile application development. In FSE/SDP Work-

shop on Future of Software Engineering Research,

FoSER, pages 397–400. ACM.

Zapata, B. C., Ni

nirola, A. H., Idri, A., Fern

andez-Alem

an,

J. L., and Toval, A. (2014). Mobile PHRs compliance

with Android and iOS usability guidelines. Journal of

Medical Systems, 38(8):1–16.

Zonouz, S., Houmansadr, A., Berthier, R., Borisov, N., and

Sanders, W. (2013). Secloud: A cloud-based compre-

hensive and lightweight security solution for smart-

phones. Computers & Security, 37:215–227.

HEALTHINF2015-InternationalConferenceonHealthInformatics

412