REQUIREMENTS ENGINEERING TO AUDIT PRIVACY ISSUES IN

MEDICAL AND HEALTH SOFTWARE

Miguel A. Martinez, Ambrosio Toval and Manuel Campos

Computer and Systems Departament, University of Murcia, Campus de Espinardo (Murcia), Spain

Keywords:

Personal Data Protection, Audit, Requirements Engineering, Privacy, Reuse.

Abstract:

In recent years, there has been a growing interest to guarantee that health organizations make a suitable treat-

ment and protection of the personal data with which they deal in their daily activity. The privacy of personal

data is regulated by law in many countries and is considered an important issue in a number of Quality Stan-

dards. This paper presents a systematic method to make an audit of the privacy in health sector software based

on Requirements Engineering (RE). The aplication and validation of the method is ilustrated in a operative

tool of report and clinical record management in the Intensive Care Unit (ICU) in a hospital.

1 INTRODUCTION

The Information Systems (IS) Audit is a discipline

whose practice has increased considerably during the

last few years. IS Audit is deﬁned as the system-

atic process of gathering, grouping and evaluating ev-

idences to determine whether an IS safeguards the as-

sets, whether it maintains the integrity of the data,

whether it effectively carries out the aims of the orga-

nization, and whether it uses the resources efﬁciently

(Weber, 1988). A special type of audit within this

discipline is the software audit. The purpose of au-

diting software is to verify that the software accom-

plishes the requirements (both functional and non-

functional). A security audit is deﬁned as ”an in-

dependent revision and examination of the registries

and activities of a system in order to verify if the con-

trols of the system are adapted to guarantee the fulﬁl-

ment of the established policy and the operative pro-

cedures, to detect security problems, and to recom-

mend possible changes in the control policy and pro-

cedures” (ISO/IEC-7498-2:1989, 1989). A security

audit can include many aspects, such as the protection

level of the facilities or people, but this paper we will

focus on the security related to data and information

(privacy) of personal nature, that is a crucial aspect in

the security of clinical IS and clinical software. More

concretely, in this work we deﬁne a method to audit

the aspects related to the privacy on clinical software,

and we illustrate its use by means of an application

to software for Electronic Clinical Record and report

management for an Intensive Care Unit (ICU) that is

being deployed in a hospital.

The method used to carry out the audit is based on

SIREN, a general method of Requirements Engineer-

ing (RE) based on standards of this discipline (IEEE-

Std.830-1998, 1998; IEEE-Std.1233-1998, 1998) and

that is focused on the reusability of requirements.

SIREN (SImple REuse of software requiremeNts) is

a practical proposal to select and to specify the re-

quirements of a software system. The key elements in

SIREN are a spiral process model, requirements doc-

ument templates and a reusable requirements reposi-

tory which is organized by catalogs. The SIREN cata-

log related to privacy aspects is called PDP (Personal

Data Protection) (Toval et al., 2002b).

At the moment, SIREN can be applied in four dif-

ferent ways:

1. As a method for RE (Toval et al., 2002a; Toval

et al., 2002b) so that the fulﬁlment of the applica-

ble norm (for example, on security and PDP) can

be guaranteed from the beginning of the develop-

ment of IS, by using suitable catalogs.

2. As guide and support to conduct an audit for de-

termining the existence of security controls and its

degree of fulﬁlment in an organization who deals

with sensible data (Martinez et al., 2006).

3. As a method for auditing software (either devel-

oped by the organization or acquired) in opera-

tion.

4. As a method of consulting in the acquisition of

A. Martinez M., Toval A. and Campos M. (2008).

REQUIREMENTS ENGINEERING TO AUDIT PRIVACY ISSUES IN MEDICAL AND HEALTH SOFTWARE.

In Proceedings of the First International Conference on Health Informatics, pages 74-81

 SciTePress

new software, so that it can be guaranteed that this

software satisﬁes the expected level of security.

In this paper, we show a specialization of the

method presented in (Martinez et al., 2006) that can

be used in applications 3 and 4, that is, as a method

for auditing and consulting. In order to conduct the

audit in a simple and agile way, it is necessary to de-

ﬁne a new method for auditing software that fulﬁls the

standards of different disciplines, such as IEEE830

(IEEE-Std.830-1998, 1998) and CobiT (Control for

Objectives Information Technologies) (CobiT, 2005),

as well as the different laws in security and protection

of personal data.

The rest of the paper is organized as follows: Sec-

tion 2 describes brieﬂy the method used for auditing.

In Section 3, we describe the phase of practical appli-

cation in our case study. In Section 4, some related

works are presented and compared with our proposal.

Section 5 describes the lessons learned after the ap-

plication of the method proposed in the practical case.

Finally, we enumerate the conclusions and the future

work in this line.

2 A METHOD FOR AUDITING

SOFTWARE BASED ON SIREN

The method proposed belongs to the scope of the

Spanish legislation (LOPD, 1999; SMR, 1999),

which is an adaptation of the European Union legisla-

tion (Directive-1995/46/CE, 1995). Nevertheless, the

proposal is easily generalizable since this legislation

has been adapted in a similar way by other European

countries. For example, in Italy, the law that regulates

the personal data protection is the Italian Law 196, of

30 of June of 2003, in Germany the counterpart is the

Federal Law of Data Protection (BDSG), and in the

United Kingdom, it is the Data Protection Act of 24

from October of 1998. In the United States, there is

a sectorial conception of the law and has as source a

mixture of legislation, regulation and self-regulation.

Rights of information privacy in a variety of sectorial

laws have been granted, like for example the law The

Privacy Act of 1974, the Fair Credit Reporting Act of

1970, or the Electronic Communications Privacy Act

of 1986.

In addition, our method has a direct correspon-

dence with the referential frame of CobiT in its more

recent version (CobiT, 2005), which is widely ac-

cepted by the international community of IS auditors.

With this proposal, we intend to help to fulﬁl the Co-

biT Control Objectives that deal with privacy aspects,

since the identiﬁcation and veriﬁcation of the fulﬁl-

ment of the requirements related to these aspects is fa-

cilitated by the use of the requirements of the SIREN

PDP catalog.

The method for auditing software based on

SIREN contemplates the following phases (see Fig-

ure 1):

Figure 1: Phases of the method for auditing data protection

in software.

Phase 1. - Analysis of the situation of the software.

This phase consists of a ﬁrst interview for establish-

ing the scope of the audit so that an initial budget can

be elaborated. The objective is to gather all kind of in-

formation about the treatment of the data used by the

software. The information comes from two sources:

on the one hand, the information facilitated by the de-

velopment team of the software (manual of use, UML

diagrams, etc.), and, on the other hand, from the ex-

perience acquired by the auditor after testing the soft-

ware.

Phase 2. - Requirements veriﬁcation with the

SRS (Software Requirements Speciﬁcations) of the

SIREN PDP catalog. The auditor veriﬁes the fulﬁl-

ment or breach of the requirements contained in the

SRS of the catalog. Personnel responsible in the or-

ganization should support and facilitate, as much as

possible, this veriﬁcation. The veriﬁcation consists of

choosing those requirements of the SIREN PDP cata-

log that can be applied to the organization and of veri-

fying whether they are fulﬁlled or not in the software.

For example, if the software is going to be used in an

organization to whom a high level of data protection

is going to be demanded, according to the SMR (Se-

curity Measures Regulation), the auditor will extract

from the SRS those requirements necessary to reach

this protection level and will verify if these require-

ments are present in the tool. This extraction or ﬁlter

of requirements of the catalog is possible thanks to

the use of the meta-information associated to each re-

quirement (in this case, through the attribute ”security

level”).

Phase 3. - Execution tests. In this phase, the auditor

must check the proper operation of the software once

REQUIREMENTS ENGINEERING TO AUDIT PRIVACY ISSUES IN MEDICAL AND HEALTH SOFTWARE

it has been integrated in the system. In case that some

of the evaluated measures are not fulﬁlled in the tool,

the auditor must describe the risks that exist in the

IS of the organization where the software is going to

be used. In order to perform the tests, the Software

Test Speciﬁcation (STS) of the SIREN PDP catalog

will be used. In this way, any person (even with little

experience) could make the tests systematically.

Phase 4. - Preparation and writing of the ﬁnal re-

port. The product of the audit is a ﬁnal report where

all aspects from the evaluation are written. At least

the report will have the following information:

• Situation: which describes brieﬂy the resultant

weakness after the analysis carried out in the soft-

ware tool.

• Threats: where the possible risks which the soft-

ware tool are exposed to, are enumerated.

• Recommendations and action plans proposed to

the development team.

The aim of the SRS used for the audit is to gather

the requirements about the functionality of the sys-

tem, external interfaces, performance, design restric-

tions and attributes of software (portability, main-

tenance, security, availability and reliability). This

speciﬁcation of requirements has been made in agree-

ment with the IEEE 830-98 Standard that is respon-

sible for deﬁning the characteristics and contents of a

good software requirements speciﬁcation.

A particular characteristic of the SIREN method

is that in the requirements speciﬁcation there exist

what we call parameterized requirements. A parame-

terized requirement contains some parts that must be

adapted to each application or system when they are

reused in a concrete project. For example, the fol-

lowing requirement extracted from the SIREN PDP

catalog ”the system will not conserve the data, once

cancelled, so that the identiﬁcation of the subject in-

terested is not allowed during a period no inferior to

[time in months] on the basis of which they had been

successfully obtained or registered”, gives the analyst

the possibility of choosing a period of suitable time to

the necessities of the concrete project.

The SRS of the PDP catalog used for the audit

presented in this work is currently composed by 48 re-

quirements. In addition to the statement, each require-

ment of the catalog contains meta-information (at-

tributes with information about each requirement) that

enriches the requirement. Among the 18 attributes

that have been deﬁned up to now, we can point out

the following ones: source, exceptions, security level,

motivation and fulﬁlment.

3 CASE STUDY

In this work, we present a concrete application of the

method to a software tool for clinical record man-

agement that deal with personal data and, therefore,

needs a high protection level in its data. The tool

used is called CH4 and has been developed by the

Artiﬁcial Intelligence and Knowledge Engineering re-

search group of the University of Murcia and is being

deployed at the moment in the ICU of the Hospital

Universitary of Getafe (Madrid).

With the objective of taking advantage of the

case study as an experience to validate the proposed

method, we have decided to use a method of quali-

tative investigation in software engineering, denomi-

nated Action-Research (Baskerville, 1999) (the use of

this method will be explained in Section 4.1).

CH4 has the aim of managing the clinical record

as much as facilitating the daily work and communi-

cation between medical staff in an ICU. CH4 is cen-

tered in the process of patient management along their

stay in the ICU by registering personal and clinical

data, and allowing the staff to automatically gener-

ate reports. In this way, a documentary database with

admittance, evolution and discharge report is created

and available for its later access.

In the development of this report oriented tool,

three scenarios have been considered: the admittance,

the daily evolution and the discharge. In each one of

them, data relative to tests (physical, complementary

examinations, analytical explorations, classiﬁcations,

. . . ) treatments and diagnoses can be introduced. The

tool includes facilities, as the treatment proﬁles, to

easy the management of the most habitual cases. Each

diagnosis or problem can be related to the concrete re-

sults of tests, to the treatments or even to other prob-

lems, allowing in this way a traceability of all the as-

pects deﬁned for a patient.

3.1 Design of the Experiment

The application of Action-Research gives rise to a

cyclical process in which the different implied parts

participate, examining the existing situation (which

they consider of some problematic way) with the ob-

jective to change it and to improve it (Wadsworth,

1998). Action-Research is one of the few approaches

valid to study the effects of speciﬁc alterations in

development methodologies and maintenance of sys-

tems in human organizations (Baskerville and Wood-

Harper, 1996). Following the terminology of Action-

Research, in this case study the following participants

are considered:

• The “researcher” is the research group in Software

HEALTHINF 2008 - International Conference on Health Informatics

Engineering of the University of Murcia.

• The “researched” object is the application of the

PDP catalog in a method for auditing a software

tool for clinical record management that needs a

high protection level in the ﬁles of personal data

that handles.

• The “critical reference group” (CRG), in other

words, the one for which the research is carried

out, is formed by the members of the development

team of the tool, is the research group of Artiﬁ-

cial Intelligence and Knowledge Engineering of

the University of Murcia. According to Action-

Research, the CRG must also participate in the

research process, although less actively than the

researcher.

• The “stakeholders” will be all those organizations

who can beneﬁt from the results of the research,

in particular, the members themselves of the CRG

and, in general, other groups whose development

activities are similar to those of the tool audited.

In this research, a participative application of

Action-Research has been made, in which the CRG

puts into practice the recommendations made by the

researcher, and shares its effects and results.

3.2 Audit of Software for Clinical

Record Management in an ICU

Within IS Audit, we distinguished two basic types of

audit: system audits and software audits. The ﬁrst one

corresponds to veriﬁcations on the own IS (an exam-

ple of real application using method SIREN can be

seen in (Martinez et al., 2006)). The second type is

centered in verifying that the software tools accom-

plish to the requirements, both functional and non-

functional (norms, laws, etc.). This work belongs to

the second type, where the tool audited is a practical

case of a software tool related to the clinical sector.

We have used the SRS of the SIREN PDP catalog as

guide to make the audit process shown in Figure 1.

After analyzing the information obtained in the

different interviews with the development team of the

tool made in Phase 1 of the audit, and after the test

of the tool made by the auditor, we pass to Phase 2.

Since we have at our disposal the SRS of SIREN PDP

catalog, only two meetings were necessary to com-

plete this phase. In these meetings, the fulﬁlment or

breach of the requirements of SIREN PDP catalog has

been checked one by one in the tool.

Once the two ﬁrst phases of the audit method have

been completed, the pertinent tests were made to ver-

ify the operation of the tool once it has been integrated

in the IS.

Table 1: Results of the audit of the software.

Software requirement

Fulﬁlled 22

Not fulﬁlled 10

Undetermined 16

Finally, all the results of the evaluation were writ-

ten in a ﬁnal report. This ﬁnal report was given to the

development team and they included in the tool the

improvements and safety measures proposed in the

audit. It is important to emphasize that implantation

of such measures is not part of the audit, since a ba-

sic principle of the audits is that these ﬁnalize with

conclusions and possible solutions, but never get to

implement solutions as part of the audit.

In this way, after maintaining several interviews

with the development team of the tool and the person

in charge of security of the system, we have collected

the data shown in Table 1.

According to the results of the Table 1, we see that

the tool fulﬁls 45.8% of the referring requirements to

the SRS of the SIREN PDP catalog. If we do not take

into account the requirements that can not be applied

to this tool (those marking like undetermined), a ful-

ﬁlment of 68.7% with respect to the SRS of SIREN

PDP catalog is obtained.

Some examples of requirements of the SIREN

PDP catalog that were not fulﬁlled in the audited tool

are the following ones:

• SRSL2. The application will warn the user that a

password needs to be changed.

• SRSL6. The [identiﬁcation procedure] and [au-

thentication procedure] will limit the possibility of

repeatedly trying a non-authorized access to the

application.

• SRSL9. The subsystem implementing the [iden-

tiﬁcation procedure] and [authentication proce-

dure], or other system related to this one, will log

all accesses to the application. The log will con-

sist of: user identiﬁcation, timestamp of the ac-

cess, ﬁle accessed, access type, and the result of

the access.

• SRSL14. The application will allow the cancel-

lation of the registered personal data (within the

ten following days to its request by the interested

part). The data will be accessible only by Public

Administration and Courts for the investigation of

possible responsibilities due to the treatment dur-

ing the term of prescription of these responsibili-

ties.

The breach of these requirements is caused by di-

verse reasons. For example, requirement SRSL2 is

REQUIREMENTS ENGINEERING TO AUDIT PRIVACY ISSUES IN MEDICAL AND HEALTH SOFTWARE

not fulﬁlled since the application did not provide a

control to automatically warn the users about the ne-

cessity of changing the passwords. The breach of re-

quirement SRSL6 put in serious danger the security

of the application, because a user without permissions

granted in the application could try to access many

times; instead of only closing the session if an at-

tempt of no authorized access takes place, the user

rized access must be registered. Requirement SRSL9

is breached since the application did not consider reg-

istering the access information; as a solution, we pro-

posed to use the database and application logging fa-

cilities to store the user accesses. Finally, requirement

SRSL14 is not fulﬁlled since the application elimi-

nates the data completely when a cancellation is re-

quired; instead of that, the data should be marked as

unavailable or stored in a temporary database so that

could be accessed in case they are required by the

Public Administration.

4 RELATED WORK

In this section, we make a review of the most out-

standing papers related to our proposal. In order to

facilitate its reading, we have organized these works

by topics, according to the essential related aspect

treated. These topics are: 1) Personal data protec-

tion audits applied to the health sector; 2) Software

tools audits; 3) Principles of the data protection in the

European Union; 4) RE applied to the security ﬁeld.

4.1 Personal Data Protection Audits

Applied to the Health Sector

In (Sandhu and Samarati, 1996), an introduction to

the personal data audit is provided, emphasizing its

importance in the organizations that deal with them.

Here, audit is understood like the process that gath-

ers data on the system activities to analyze them in

search of security violations. In (Hughes, 2005), the

authors make a study about the relations between au-

dits and research methods applied to the health sector

of the United Kingdom. More concretely they apply

Action-Research, which is a method with a special

relevance in the health sector, where there is an im-

portant social factor. Nevertheless, in these papers,

the approach is different from ours, since they do not

audit a speciﬁc tool but the stored personal data in

a system, and because neither application to a study

case appears, nor the speciﬁc phases of an audit pro-

cess are distinguished.

4.2 Software Tools Audits

Some of the software audit tools (in general, not only

of the health sector) more used are GASP and Web-

Census, both available in trial version in the BSA

(Business Software Alliance) website

, that is the

main organization dedicated to the development of

legal and safe computer science. These tools allow

the auditors to identify and to track licensed and un-

licensed software installed in a computer. Both tools

are easy to use (WebCensus can be run through Web,

without requiring installation by the user) and their

high degree of accuracy has converted them in audit

tools standard in numerous companies and govern-

mental bureau worldwide. These tools have a differ-

ent approach from the methodology that we propose,

since they exclusively are limited to make a testing of

the software installed in a system, contributing data

related to the licenses and manufacturers, but they do

not cover in any way the audit of software speciﬁc

concerns (functional or non-functional requirements).

4.3 Principles of the Data Protection in

the European Union

In (Van der Haak et al., 2003) and (Massacci et al.,

2005), two practical applications about the use of per-

sonal data protection law in different European coun-

tries (concretely, Germany and Italy) are described.

The ﬁrst paper focuses on the identiﬁcation of spe-

ciﬁc legal requirements related to data security and

data protection of patients included in electronic clin-

ical records. It is based on the set of German laws on

data protection. The second paper presents a practical

case of the application of a RE methodology for the

fulﬁlment of the Italian legislation in privacy and data

protection.

In these papers, authors do not provide the re-

quirements engineers with a PDP requirements cat-

alog (or similar) related to data privacy in a easily

understandable language. So, the application of the

data protection law in IS becomes a more tedious and

difﬁcult task for the requirements engineer.

The PDP requirements catalog that we have used

(and improved) in this paper, is valid, with slight

modiﬁcations, in any country of the European Union,

since it is based on, among others, (Directive-

1995/46/CE, 1995) and on (Directive-2002/58/CE,

2002). As (Lusignan et al., 2006) exposes, these di-

rectives are the base of the privacy laws of any Euro-

pean Union country. The authors show a table with

the chronological order of the different treaties the

www.bsa.org

HEALTHINF 2008 - International Conference on Health Informatics

fundamental principles of personal data protection of

the European Union, and another table with a compar-

ison of these principles (including general principles

of the ethics in health computer systems).

4.4 Requirements Engineering applied

to the Security Field

In the line of RE, we draw attention to the work

by Firesmith (Firesmith, 2003), which provides ex-

amples and directives for requirements engineers to

specify suitably security requirements. The different

types of security requirements are identiﬁed and de-

ﬁned, among which privacy, security audit and phys-

ical protection requirements are highlighted. (Olv-

ingson et al., 2002) presents a minimal data set for

requirements elicitation in the area of public health.

This minimal data set is a data collection that supports

the elicitation of users’ voices that later will constitute

the foundation on which to identify the true require-

ments and describes the problems found by health

professionals in their daily activities in countries like

Sweden and the United States. Thus, it is possible

to prioritize the requirements in an early phase of the

construction of the system, e.g. the RE phase, and

thus capture the most important characteristics to be

implemented in IS. In these two papers, proposals are

made considering thinking only RE and without fol-

lowing any RE methodology. On the contrary, we

have followed the SIREN methodology and made a

proposal for conduct audits.

In contrast to with the works described previously,

our paper offers an integrated and repeatable system-

atic method to make an audit of software tools based

on international standards of audit (CobiT) and good

practices of Software Engineering (SIREN and inter-

national standards of RE). This method has been val-

idated in a real study case where personal data are

treated. In this way, our work complements other cur-

rent proposals in the audit area but is new because

allows the auditor to verify the fulﬁlment of privacy

laws in software tools which deal with personal data.

5 LESSONS LEARNED

After carrying out this work we can identify three

main lessons learned of our experience as software

tools auditors.

On the one hand, this type of audits supposes a

decisive aid to improve the used tools so that they ad-

just to the norms used as base; for example, in this

case, the norms are the personal data protection laws.

On the other hand, we have realized that thanks to

the existence of a previous requirements catalog, we

have been able to reduce the time dedicated to meet-

ings and other activities of the audit. The interviews

with the development team and board of directors of

the organization (usually with very just a short time

available) can be focused and guided directly to the

crucial points that concern the audit.

Finally, we have detected weak points in the re-

quirements catalog used in the audit. The inconsis-

tencies consist fundamentally of the existence of am-

biguities in the writing of certain requirements, which

impede to the auditor team to make a ﬁrm decision on

his fulﬁlment or breach in the software tool.

In relation to this last point, in addition to be-

ing able to detect what requirements were fulﬁlled or

not in the current version of the developed tool, and

thanks to the feedback obtained from the development

team of the audit tool, ambiguous requirements and

bad-written requirements in the SRS of the SIREN

PDP catalog have been identiﬁed during the audit.

Of the 48 requirements that composed the SRS of

the SIREN PDP catalog, 7 of them were identiﬁed

by the development team of the audit tool, like can-

didates to a possible modiﬁcation since they were not

clear and precise enough. Some examples of these

requirements, along with its corresponding improve-

ment, are showed next:

SRSL2-Old. The software will have to warn that

a password needs to be changed.

SRSL2-New. In case that the authentication

mechanism is based on the existence of passwords,

the software will warn that a password needs to be

changed, once ﬁnished the validity period set to [time

in days].

SRSL5-Old. The software will allow that the In-

formation Systems and data processing facilities can

be subjected to an internal or external audit, at least

every two years.

SRSL5-New. As much as every two years, the

software will warn of the need to make an audit (inter-

nal or external) of the Information Systems and data

processing facilities to verify the fulﬁlment of the Se-

curity Measures Regulations.

SRSL26-Old. The software will allow the people

in charge of treatments of public and private owner-

ship, as well as the organizations in which they group

themselves, to formulate codes of ethics.

SRSL26-New. In this case the requirement re-

mains equal, it is necessary to add the following addi-

tional information in the attribute “Rationale” of the

requirement: The aim of codes of ethics is to estab-

lish the conditions of organization, operating condi-

tions, applicable procedures, norms of security of the

surroundings, use and obligations of the software and

REQUIREMENTS ENGINEERING TO AUDIT PRIVACY ISSUES IN MEDICAL AND HEALTH SOFTWARE

hardware implied in the treatment and use of the per-

sonal information, as well as the guarantees, in its

scope, for the exercise of the people rights and its de-

velopment norms.

6 CONCLUSIONS AND FURTHER

WORK

Finally, we show the most important conclusions, ob-

tained after carrying out this research:

• A systematic method has been extended to make

a data protection audit to a software tool which

deals with specially protected data. More specif-

ically, we have applied the method to audit a tool

for clinical record management in an ICU at a hos-

pital that deals with sensible data.

• With the application of the proposed method, we

helped to adapt the tool audited to the security

measures and to the regulations demanded by law.

• An improvement of the PDP requirements catalog

has been obtained (Toval et al., 2002b), which cor-

responds with one of the SIREN method phases.

In this sense, the quality of the existing require-

ments has been improved: some requirements,

identiﬁed as necessary or advisable, have been in-

serted in the PDP SIREN catalog.

• The use of “good practices” in Software Engineer-

ing considerably facilitates the subsequent audit

work.

• As a result of the audit, we can provide a precise

degree (in %) of fulﬁlment of a software tool with

respect to the requirements document.

• With the application of the method, the treatment

of legal requirements and the audit process im-

plied is contemplated in the organization that uses

the software tool. This process is considered im-

portant in Quality Standards like ISO 9001 or ISO

9004.

• The result of the audit provide the development

team with a very useful and direct set of sugges-

tions to be included in the software tool in order

to accomplish the norms.

As limitation of our proposal, we can say that al-

though our method is generalizable to other functional

and non-functional software concerns, it is necessary

to have a requirements catalog similar to the one used

in this paper. At the moment, we have developed the

following reusable requirements catalog:

• Personal Data Protection (PDP) (Toval et al.,

2002b).

• Security in Information System (Toval et al.,

2002a).

• Teleoperated Systems (Nicolas et al., 2006).

In lack of a predeﬁned speciﬁc requirements cata-

log on the concern or concerns that we want to audit,

some other alternative sources of broad acceptance

could be used. For example, standard ISO/IEC 9126

(ISO/IEC-9126-1, 2001) could be used as guide for

an audit of software quality.

As future work, we are already working on the

development of a more speciﬁc requirements cata-

log of Electronic Clinical Record (ECR). This cata-

log will not only cover the legal aspects in the LOPD

and the SMR but will also bring together the obli-

gations imposed in the General Health Law (Law

14/1986) and the Law on the Autonomy of the Patient

(Law 41/2002). Finally, we have developed a website

where it is possible to consult the results obtained af-

ter audit, to download the SIREN PDP catalog and to

request a change of the current catalog requirements.

ACKNOWLEDGEMENTS

This work has been partially ﬁnanced by the Span-

ish Ministry of Science and Technology, project

DEDALO (Desarrollo de sistEmas De calidad

bAsado en modeLos y requisitOs), TIN2006-15175-

C05-03, by the project FoMDAs (Formalizacion de

(Meta-) Modelos y transformaciones en un marco

MDA para el Desarrollo Automatico de SIW), URJC-

CM-2006-CET-0387, by the project IDEATIO (Her-

ramientas inteligentes para el control de la calidad

asistencial en procesos de seguimiento integrado in-

tra/extrahospitalario de pacientes: Una aproxima-

cion basada en guias de practica clinicas), TIN2006-

15460-C04-01, and by the Junta de Castilla-La Man-

cha (Spain), project DESERT (DEveloping Secure

systEms through Requirements and Tools), PBC-05-

012-3.

REFERENCES

Baskerville, R. L. (1999). Investigating information sys-

tems with action research. Communications of the As-

sociation for Information Systems, 2(3):4.

Baskerville, R. L. and Wood-Harper, A. T. (1996). A criti-

cal perspective on action research as a method for in-

formation systems research. Journal of Information

Technology, 11(3):235–246.

CobiT (2005). Control Objectives for Informa-

tion and related Technology. 4th Edition.

http://www.isaca.org/cobit.htm.

HEALTHINF 2008 - International Conference on Health Informatics

Directive-1995/46/CE (1995). Directive Num. 95/46/CE of

the European Parliament and Council, dated October

24th: about People protection regarding the personal

data management and the free circulation of these

data. DOCE no. L281, 23/11/1995, P.0031-0050.

Directive-2002/58/CE (2002). Directive Num. 2002/58/CE

of the European Parliament and Council, of July 12,

2002, relative to the processing of personal data and

the protection of privacy in the electronic communica-

tions industry (Ofﬁcial Gazette of the European Union

L 201 of 31.7.2002).

Firesmith, D. (2003). Engineering security requirements.

Journal of Object Technology (JOT), 2(1):53–68.

Hughes, R. (2005). Is audit research? the relationships

between clinical audit and social research. Inter-

national Journal of Health Care Quality Assurance,

18(4):289–299.

IEEE-Std.1233-1998 (1998). Guide for Developing System

Requirements Speciﬁcations. In Volume 1: Customer

and Terminology Standards The Institute of Electrical

and Electronics Engineers, Inc. IEEE Software Engi-

neering Standards Collection.

IEEE-Std.830-1998 (1998). Guide to Software Require-

ments Speciﬁcations (ANSI). In Volume 4: Resource

and Technique Standards The Institute of Electrical

and Electronics Engineers, Inc. IEEE Software Engi-

neering Standards Collection.

ISO/IEC-7498-2:1989 (1989). Information processing sys-

tems. Open Systems Interconnection. Basic Reference

Model. Part 2: Security Architecture.

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

Quality - Part1: Quality Model.

LOPD (1999). Spanish Constitutional Law 15/1999, De-

cember 13th, on Personal Data Protection. BOE no.

298, 14/12/1999 (In Spanish). http://www.agpd.es.

Lusignan, S., Chan, T., Theadom, A., and Dhoul, N. (2006).

The roles of policy and professionalism in the protec-

tion of processed clinical data: A literature review. In-

ternational Journal of Medical Informatics.

Martinez, M. A., Lasheras, J., Toval, A., and Piattini, M.

(2006). An Audit Method of Personal Data Based on

Requirements Engineering. In Proceedings of the 4th

International Workshop on Security in Information

Systems, (WOSIS’06), In conjunction with ICEIS’06,

Paphos, Cyprus, pages 217–231.

Massacci, F., Prest, M., and Zannone, N. (2005). Using

a security requirements engineering methodology in

practice: The compliance with the italian data protec-

tion legislation. Computer Standards and Interfaces,

27:445–455.

Nicolas, J., Lasheras, J., Toval, A., Ortiz, F. J., and Al-

varez, B. (2006). A collaborative learning experi-

ence in modelling the requirements of teleoperated

systems for ship hull maintenance. In Proceedings

of the Learning Software Organizations + Require-

ments Engineering (LSO+RE 2006), Hannover, Ger-

many, pages 71–80.

Olvingson, C., Hallberg, N., Timpka, T., and Greenes, R.

(2002). Using the critical incident technique to de-

ﬁne a minimal data set for requirements elicitation in

public health. International Journal of Medical Infor-

matics, 68:165–174.

Sandhu, R. and Samarati, P. (1996). Authentication, Access

Control and Audit. ACM Computing Surveys (CSUR),

28(1):241–243.

SMR (1999). Spanish Royal Decree 994/1999, June 11th,

by means of which the Security Measures Regulations

of Automated Files which contain personal data is ap-

proved. BOE no. 151, 25/06/1999, page 24241 (In

Spanish). http://www.agpd.es.

Toval, A., Nicol

as, J., Moros, B., and Garcia, F. (2002a).

Requirements Reuse for Improving Information Sys-

tems Security: A Practitioner’s Approach. RE J.,

6(4):205–219.

Toval, A., Olmos, A., and Piattini, M. (2002b). Legal Re-

quirements Reuse: A Critical Success Factor for Re-

quirements Quality and Personal Data Protection. In

RE, pages 95–103. IEEE Computer Society.

Van der Haak, M., Wolff, A., Brandner, R., Drings, P., Wan-

nenmacher, M., and Wetter, T. (2003). Data security

and protection in cross-institutional electronic patient

records. International Journal of Medical Informatics,

70:117–130.

Wadsworth, Y. (1998). What is participatory action re-

search? Action Research International. Paper 2,,

2004.

Weber, R. (1988). EDP Auditing: Conceptual Foundations

and Practice. 2nd Edition. Mc Graw Hill.

REQUIREMENTS ENGINEERING TO AUDIT PRIVACY ISSUES IN MEDICAL AND HEALTH SOFTWARE