Towards a better understanding of privacy in medical Requirements Engineering: A case study among Dutch hospitals

(1)

Towards a better understanding of

privacy in medical Requirements

Engineering

A case study among Dutch hospitals

Deveney Brehler 10760385

Bachelor thesis Credits: 18 EC

Bachelor Opleiding Informatiekunde

Supervisor Drs. A. Vreeken

(2)

Acknowledgement

First of all, I would like to thank my supervisor, Arjan Vreeken, for all of his clear and constructive feedback. I truly believe your recommendations and feedback have taken my thesis to a higher level. Furthermore, I would like to thank my boyfriend, Jesse van der Sar, for always taking the time to hear out my, thesis-related, struggles and for proofreading significant parts of my thesis.

Lastly, I would like to thank my parents for their continuous support and for always believing in me.

(3)

Abstract

In the past few years, advanced Information and Communication Technology (ICT) have extensively been implemented in the healthcare domain to improve

the quality of services. At the foundation of each of these Information and Communication systems lies an elaborate requirements engineering (RE) process. However, a major percentage of these IT projects would have at least

partly failed, due to lack of systematic consideration of human factors in the RE process. It is argued that the RE approaches in this difficult domain often

fail to include the, perhaps most important stakeholder and final customer: the patient (i.e. the data subject) and his or her privacy-related concerns and perspectives. This research therefore aimed at evaluating the currently known

approaches to medical RE with regard to a data subject’s privacy. An elaborate literature study was conducted to describe the currently known RE approaches, the profound concept of privacy and the inclusion of this concept in these approaches. Also, a case study was conducted among Dutch hospitals,

and within one of the largest medical software companies in the Netherlands, to further compare the data subject’s and data holder’s perspectives on privacy requirements. It was concluded that current approaches to privacy in RE are mainly concerned with a data subject’s informational privacy, and that

not all relevant aspects are sufficiently represented. The data subject’s needs and perspectives on privacy should, in future projects, be more included in RE.

(4)

Abbrevations

RE RE

(7)

Concepts

Data subject The person or entity whose data is stored in a system.

Data holder The person or organisation that has insight into and/or possesses the data of the system subject.

Stakeholder Persons or groups with vested interests in an organisations deci-sions and the evidence that supports that decision.

Company Doctor A doctor who is employed by a company to look after the health of its employees.

Infection Prevention Specialist Someone who specializes in the prevention and control of infectious disease outbreaks in a hospital setting.

(8)

1 Introduction

In the past few years, advanced Information and Communication Technology (ICT) have extensively been implemented in the healthcare domain to improve the quality of services. At the foundation of each of these Information and Communication systems lies an elaborate requirements engineering (RE) pro-cess. This process was designed to elicit individual stakeholder requirements and to specify them, so that they can serve as the basis of all other system de-velopment activities. However, multiple authors argue that a major percentage of the IT projects in the healthcare domain have at least partly failed, due to the lack of systematic consideration of human and other non technology factors in the RE process (Teixeira et al., 2012; Goguen & Linde, 1993).

RE has never been more important, and its criticality will continue to grow. However, according to Jarke et al. (2011) RE needs to innovate and improve. It needs to be approached in new ways, where we for example intertwine require-ments and context, evolve designs and ecologies. RE and its research needs to be expanded into a new direction, and include other fields like behavioural economics, for example, that have not been considered before. Jarke et al. (2011) argue that these other, new fields, need to be included in the design of complex software within a living and therefore evolving world. A world that includes humans, a world that changes. The domain of RE needs to change with this world, especially in domains where complex software needs to be designed. Domains like, for example, the healthcare domain.

Cottaar (2012) describes that the problems in the healthcare domain are a consequence of the healthcare domain still being in development. While most domains already have a complete toolbox for engineering, the healthcare do-main is still creating hers. The healthcare dodo-main is much more complex than the other domains. When building a bridge as an engineer, you have to take into account the distance between the banks, the amount of traffic that needs to pass the bridge, and what material it must be made of. This engineer is not confronted with bumpy banks, anxious concrete or negligent steel. Healthcare, however, is more than just engineering, much more than just the technical de-tails; it is about humans. This view is supported by Zowghi & Coulin (2005), who argue that there is a large number of contextual, economic and also human factors that have an effect on the efficiency of RE. Christel & Kang (1992)also describe there are many problems associated with RE, one of which is the prob-lem of fostering understanding among the different communities affected by the development of a given system. Problems like these in the RE process may lead to poor requirements, and eventually to the development of a system that is later judged unsatisfactory or unacceptable.

An example of an IT project in the healthcare domain that has experienced a relatively bumpy road, is the Electronic Patient Record (EPR). The EPR has raised a lot of discussion, especially in the field of privacy. Most authors in this field have focussed on the privacy legislations for example, or the ethical issues surrounding privacy in the EPR. The patient him- or herself however, whom the EPR stores data about, has according to Zurita & Nohr (2004) only rarely been involved in this research. Most authors evaluate the system based on legislation, but rarely include the experience of perhaps the most important user: the patient himself. Zurita & Nohr (2004) therefore researched how patients

(9)

were experiencing the introduction of the EPR. Their research showed that patients were indeed open to the idea of an EPR, but that they were also concerned about their privacy and the possibility that external parties would have access to their files. Their research concludes that, in the future, more attention should be paid to the privacy problems that the patient experiences in the development phases of a health information system. The authors, however, do not describe how this should be done.

Another author supporting the involvement of the patient, is Cysneiros (2002). According to Cysneiros, most of the software build to work in the healthcare domain does not take into account the most important user: the patient. Software developers and healthcare providers tend to ignore that the final customer is the patient and that therefore the patients concerns should be taken into account. Cysneiros argues that in RE in the healthcare domain, the engineer should understand the reasons that underlie the processes in the domain. He should also understand the positive and negative aspects of doing things the way they are done today, and think of alternative and more effective ways of achieving the goals of a system. Simons & Verhagen (2008) also support this view, by arguing it is of high importance to use methods that do not only focus on technical and economic feasibility, but also add value for users and are a good fit with societal objectives and concerns in the long run (regarding privacy for example). Other authors, for example Chitti (2013), argue that privacy is indeed a critical factor in RE, but that this factor completely revolves around the encryption and decryption of data and the flow of information and accessi-bility of such data. The patient is considered a stakeholder in her research, but is purely represented by technologies and laws protecting the patients data.

This thesis presents a research on the RE process in the healthcare domain. The main goal of the thesis is to determine whether the current process, the current toolbox for RE in healthcare, is still sufficient in developing a complex system that deals with some very personal, very privacy-sensitive information. Some authors, for example, describe in their research that the patients concerns should also be included in the early development phases of a system, i.e. the RE process (Zurita & Nohr, 2004; Cysneiros, 2002). Literature on RE with regard to privacy usually describes the use of laws or domain experts, to represent the privacy of the patient (the data subject). However, there is barely any, to no literature on whether the privacy concerns of the data subject should be included in the RE process as well, and if so, then how this should be put into practice. This research will therefore focus on whether this approach to the privacy aspect in RE is sufficient, meaning that the stakeholders that are indeed included in formulating the requirements represent all the privacy concerns of the data subject.

(10)

2 Research Design

2.1 Research Question

The research question that is central to this thesis can be described as follows: To what extent are the known approaches to RE sufficient in devel-oping a healthcare information system that fully takes into account the privacy aspects that are relevant to the data subject?

The above described research question is focussed on determining whether the current approach to privacy in RE in the healthcare domain is still sufficient or not. With sufficient, we mean that the final system design takes into account all privacy aspects that are relevant to the data subject, and relevant to the functioning of the system. After all, the data subject is the one supplying the system with his or her data. Without this data, the system simply cannot function. We therefore aim at determining what aspects of privacy are relevant to the data subject, and to what extent these aspects are included in the RE process.

2.1.1 Sub questions

To be able to answer the main research question, a couple of sub questions have been formulated:

Q1 What methods/approaches for RE are suggested in general?

Q2 What methods/approaches for RE for projects in the healthcare domain are suggested?

With the first two questions, we try to gain as much knowledge possible about how RE in general, and more specifically in the healthcare domain, is approached by scientific literature. The general RE approaches found in the literature study will be compared to approaches to RE in the healthcare domain. Comparing them might prove useful in making recommendations for RE in the healthcare domain.

From the third question on, we focus more on the privacy aspect in RE.

Q3 How can privacy be defined, and how is it perceived by people?

Q4 How do data subjects and data holders perceive privacy in the healthcare domain?

Q5 What methods/approaches for involving privacy in RE in the healthcare domain are suggested?

Q6 To what extent are the privacy aspects found in question 4 involved in these RE approaches?

First of all, we want to understand what privacy is, and how people perceive it in general (see sub question 3). How people perceive privacy is important in understanding what aspects of privacy are generally important to people. From the fourth question on, we start focussing on the healthcare domain, and on

(11)

the two most important actors in (medical) privacy issues: the data subject and the data holder (see sub question 4). We want to understand how data subjects perceive privacy, and what privacy aspects they feel are important in the healthcare domain. The reason for also including the privacy perceptions of the data holder here, is because these perceptions may influence the data holders requirements on privacy.

The fifth question focusses on how privacy is currently included in RE in the healthcare domain. The goal of the sixth question is to describe to what extent the privacy aspects that are important to the data subjects are included in the RE process. This question partly aims at determining the sufficiency of the RE approaches with regard to privacy in the healthcare domain.

Q7 To what extent do the needs and requirements on privacy between the data subject and the data holder in the healthcare domain correspond? Q8 To what extent are the privacy aspects that are relevant to the data subject

included in the requirements on privacy of the data holder?

The last two questions are focussed at gathering more evidence of either the sufficiency or insufficiency of privacy in RE in the healthcare domain. Sub question 7 and 8, in combination with the elaborate literature study, will try to work towards an answer of the main research question.

2.2 Methodology

A combination of an elaborate literature study and a exploratory case study was used to answer the subquestions and, eventually, the main research question.

2.2.1 Literature Study

An elaborate literature study was conducted. The literature study contains an in-depth study of the concepts of RE, privacy and the involvement of privacy in RE. Studying these concepts in depth was important for a number of reasons:

• A literature study forces the writer to educate him/herself on as much information as possible (Denney & Tewksbury, 2013).

• A literature study relates the study to the larger, ongoing dialog in the lit-erature about a topic, filling in gaps and extending prior studies (Marshall & Rossman, 1989).

The literature study was performed because the above described reasons. It was aimed at gaining more knowledge of the main concepts in this thesis: RE, privacy, and the involvement of privacy in RE. Furthermore, the literature study was aimed at finding gaps in literature on the above described concepts that needed further exploration. The literature study also contributed to filling these identified gaps.

Approach to Literature Study

The literature study was structured according to an approach described by (Randolph, 2009), who describes the following steps in conducting a literature study:

(12)

• Problem formation: narrowing down the concepts that are central in the study.

• Data collection: determining which sources of potentially relevant sources to examine.

• Analysis and interpretation: synthesizing retrieved studies.

• Public presentation: applying editorial criteria to separate important from unimportant information.

The concepts that were identified include, as earlier described: RE, privacy and privacy in RE. Sources that were selected for the acquisition were Google Scholar, ScienceDirect, JSTOR, Taylor & Francis Online, Elsevier and Springer Link. Retrieved studies on the above identified concepts were analysed, inter-preted and relevant information that was found has been described.

2.2.2 Case Study - The Arbo file

The software company that the case study was conducted within, was founded from the need to make healthcare records more efficient. What began with a small stand alone billing program for medical specialists has become a fully integrated Electronic Patient Record (EPR) for individual and collaborative healthcare institutions across the entire care chain. Nowadays, around 50 per cent of the hospitals in the Netherlands work with their software. It supports the care chain with a fully integrated system that offers tailored solutions for both the latest smart devices and fixed workstations.

Improving the Registration of Needlestick Injuries

Recently, multiple Dutch hospitals have expressed a need for an employee file, where, for example, vaccinations, infections and needlestick injuries of inter-nal employees can be registered. At the moment, most hospitals register these needlestick injuries, vaccinations and infections of employees in self-made sys-tems or in simple Excel spreadsheets. With the Arbo file, they hope to gain a more complete dataset which would, amongst others, contribute to more effec-tive monitoring of needlestick injuries. However, in research about the reporting of needlestick injuries in the Netherlands, van Wijk et al. (2009) argue that at least 50 per cent of the needle stick injuries is not reported by the employee. They describe a Belgian (unpublished) study by Leens et al., where it was concluded that 50 per cent of all blood exposure accidents were not reported. Another study by van Gemert-Pijnen et al. (2006), however, showed that only 19 per cent of the health care workers in the Netherlands does not report an accident. van Wijk et al. (2009) therefore argue that there are way more acci-dents in practice, which might not be reported. According to van Wijk et al. (2009), one of the reasons healthcare workers do not to report their needlestick injuries, is because they fear other colleagues will be able to take notice. They fear for their privacy, and the consequences that the accident might have for their reputation. The underreporting of needlestick injuries is therefore a se-rious (privacy) issue, resulting in an incomplete dataset about the amount of injuries.

(13)

Designing the Arbo-file

The concerning software company wants to design such an Arbo-file, since the company doctor in a hospital currently has no access to their system. However, designing and implementing such a file comes with some serious privacy- and development issues. For instance, besides the company doctor, the department trusted with infection prevention within a hospital should have access to the file as well. However, other departments and other colleagues should not be able to see this file. Also, as described above, the issue of the underreporting of needlestick injuries forms a serious constraint to the efficiency of this file. The Arbo-file should be able to easily give a complete overview of the amount of needlestick injuries. However, when employees do not report these injuries, it is impossible for the Arbo-file to give a complete overview of all the needlestick injuries.

2.2.3 Case study - Approach

A case study was conducted, targeting sub questions Q7 – To what extent do the needs and requirements on privacy between the data subject and the data holder in the healthcare domain correspond? – and Q8 – To what extent are the privacy aspects that are relevant to the data subject included in the requirements on privacy of the data holder? In other words, the case study was conducted to further explore the sufficiency of privacy in RE in a real-life case.

This was done by comparing the perspectives of privacy of two important actors in healthcare: the data holder and the data subject. First of all, inter-views were conducted to gather requirements on privacy from the concerned data holders in hospitals. After that, the data subject’s perspective on privacy in RE was retrieved through a qualitative survey and compared to the require-ments gathered from the data holders. In this case study, the data holders were embodied by the company doctor and the specialists infection prevention. The data subjects were embodied by the employees, who are required to report their needlestick injury, thereby having their data recorded in the system to be developed.

Requirements from the data holder’s perspective and from the data subject’s perspective were compared, which contributed to concluding the sufficiency of the inclusion of relevant privacy aspects in RE. In addition, the case study aims at answering the ’how’ of the earlier described gap in literature. It gives sugges-tions on how to incorporate privacy issues from the data subject’s perspective in RE in the healthcare domain. In principle, this aim was not necessarily cen-tral to this thesis but can, for instance, be used in future research that is more focussed on the ’how’ of this subject. Therefore, this is also relevant to include in the case study’s conclusion.

Data collection - Interviews

As described above, interviews were conducted to gather requirements on pri-vacy with regard to the requested Arbo File. Company doctors and specialists infection prevention from two Dutch hospitals participated in these interviews. These hospitals were chosen, because they are part of the group of hospitals who have requested the Arbo file. The interviews were conducted at the hospitals, with one employee at once.

(14)

The process of gathering requirements was structured according to approaches described in literature on RE (see chapter 3). Interviews were chosen as the re-quirements elicitation method, as this is, according to multiple authors (Pohl, 2010; Hull et al., 2010; Jacob & Dekkers, 2015), the best and most common way to elicit requirements. Furthermore, the interview was semi-structured, as this is a very helpful technique in case studies (Drever, 1995). In a semi-structured interview, the interviewer has some discretion about the order in which questions are asked, but at the same time provides the participants with the freedom to interfere, when they feel necessary (Harrell & Bradley, 2009). A list of questions for the interview was created beforehand in co-operation with employees from the medical software company. Because the questions were cre-ated in co-operation with these employees, some questions were not specifically relevant for this thesis, but were only of specific interest for the company itself (See appendix A). Afterwards, the gathered requirements were analysed and documented, again according to the described RE approaches in chapter 3.

Data collection - Survey

The survey was focused on data subjects in the healthcare domain (more specif-ically those who are prone to needlestick injuries, see 3.4). The survey was cre-ated using a survey software called Qualtrics. Since they are no specific rules when determining an appropriate sample size in qualitative research, the sample size can be determined by the time allotted and resources (Patton, 1990). The size of the sample group was aimed at 30, because of the time span and avail-able resources. The distribution of the Survey was initially to be done by the company (see 3.4) where the case study was conducted within. However, due to difficulties within this company, the survey was distributed through direct and personal contacts by the author. Known acquaintances within hospitals were approached and kindly requested to fill in the survey and to share them with colleagues. For the analysis of the collected data, the Python Data Analysis Library was used.

Combining the collected data

The collected data, in the form of interviews and surveys, was finally combined and compared. The employee’s requirements on privacy, and the requirements gathered from the company doctors and infection prevention specialists were compared.

2.3 Relevance

This research is relevant for the following reasons:

• The research targets a gap in scientific medical RE, that is: whether, and how, to include the data subject’s concerns on privacy in RE.

• The research contributes to the discussion on how to better incorporate privacy in RE.

• The research is socially relevant, because it contributes to obtaining insight into the (privacy-related) barriers in reporting and registering needlestick injuries.

(15)

2.4 Structure

This research is structured into three parts. Chapter five consists of an elaborate literature study on RE, and its application to the healthcare domain. This chapter addresses the first two sub questions, and gains more insight into the approaches and methods for RE. In chapter six of this thesis, literature on the privacy aspect, and its inclusion in RE is described. This chapter addresses questions Q3 to Q6. Chapter seven contains a conducted case study and findings from this study are described to answer the last two questions: Q7 and Q8.

(16)

3 Literature Study on Requirements

Engineer-ing (RE)

This chapter will elaborate on suggested approaches to RE in literature, in general and in the healthcare domain. The chapter is divided into multiple sec-tions. The first section concerns the general RE process, and how this process is structured nowadays. The second section focuses on the application of the RE process to the healthcare domain. The chapter ends with a comprehen-sive conclusion of findings in the academic literature, by comparing general RE approaches with suggested medical RE approaches.

3.1 RE

Requirements engineering (RE) in its broadest sense can be described as the process of eliciting individual stakeholder requirements and needs and develop-ing them into detailed, agreed requirements documents and specified in such a way that they can serve as the basis for all other system development activities (Pohl, 2010). Other definitions of RE include:

1. RE is the process of studying user needs to arrive at a denition of system, hardware, or software requirements. It is the process of studying and refining system, hardware or software requirements (Radatz et al., 1990). 2. RE is the part of the development in which people attempt to discover

what is desired (Gause & Weinberg, 1989).

3. RE first defines the problem scope, and then links all subsequent develop-ment information to it (Hull et al., 2010).

The several definitions of RE all take a different perspective on the process. The IEEE definition emphasizes the importance of involving the user in the RE process, whereas the definition of Hull et al. (2010) is more focused on the technical side of RE. Hull et al. (2010) literally describe that ’RE is a technical process’. The definition of Gause & Weinberg (1989) is however a bit ’vague’, for example; who are the people that attempt to discover the desires? The definition of Pohl (2010) feels like the most evident and inclusive one, and will therefore be used throughout this entire thesis.

As for the definition of a requirement, the term as defined in the EEE 610.12-1990 standard will be used (Radatz et al., 610.12-1990):

1. A requirement is a condition or capability needed by a user to solve a problem or achieve an objective.

2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.

3. A documented representation of a condition or capability as in (1) or (2).

The rest of this section will be structured based on the RE framework of Pohl (2010). This framework consists of four main building blocks, and will be used

(17)

Figure 1: Pohl’s RE framework

as the main guideline throughout this chapter. The framework is structured as shown in Figure 1.

The framework describes three core activities that are of relevance to RE: elicitation, documentation and negotiation. Other literature on RE also de-scribes these activities, or a similar form of the activities, as the basis of the RE process (Hull et al., 2010; Wohlin et al., 2005; Nuseibeh & Easterbrook, 2000; Kaur & Singh, 2010). These activities are performed iteratively to establish a vision of the desired system, and need to be performed within the existing context of the system (Pohl, 2010). The context of the system contains the requirements sources and strongly influences how the system requirements are defined. A sufficient understanding of the context is therefore essential for a good requirements documentation. The system context consists, according to Pohl (2010), of four structured parts: the context facets (See 5.1.1). Within these facets, the three core activities can be performed. Besides the three core activities, Pohls framework also defines two other, cross-sectional, activities that are essential for the success of RE: the validation activity and the management activity.

3.1.1 System context

The context of a system defines the environment in which the system is supposed to operate (Finkelstein & Savigni, 2001). This is especially important in RE, because the environment can also influence the requirements for the system to be developed (Pohl & Rupp, 2011).

The environment can consist of anything in the world that provides a sur-rounding for the system, and can influence the behaviour of the system. The environment will most likely have an influence on the final system and its be-haviour, and should therefore also have an influence on the requirements of the system. The part of the system environment that has to be considered during

(18)

system development, is called the system context.

To be able to define the system context, the environment needs to be thor-oughly explored, including the political, organisational and social aspects related to the system (Zowghi & Coulin, 2005). Already existing work processes in the environment, and the related problems that should be solved by the system need to be described. According to Kaur & Singh (2010), the owners of these prob-lems are usually people, and therefore RE mainly needs to focus on the human being. For instance how the human being perceives and understands the world around them, and how they interact with it. Pohl (2010) however believes that there are more aspects of the environment that need to be considered, which can be structured in several, separate so called context facets. The context facets, as described by Pohl (2010) are: the Subject facet, the Usage facet, the IT system facet and the Development facet. Within these facets, the context aspects can be identified. Context aspects can be material or immaterial objects of the sys-tem context and can for example be organisational, political or social (Zowghi & Coulin, 2005).

The Subject Facet

The Subject facet includes the objects and events in the system context that are relevant for the system. Information about these objects and events must be stored, and represented in the system. Objects in this facet are the subjects that are being represented (e.g. patients in a hospital system), or people who have an interest in these subjects but are not system users (Pohl, 1997). Subjects themselves are usually not included in the RE process, because they often do not have enough knowledge of the system (Pohl, 1997). For example, according to Pohl, they know nothing about the degree to which they are administered by the system. To ensure correct consideration of these subjects, domain experts are often included in the RE process. They form one of the requirements sources in this context facet, and can provide information about the objects that the system must represent information about. Other requirements sources include lawyers and data privacy officers, textbooks about the subject domain and laws that are relevant for the particular domain. Other relevant information may be gathered from existing systems. This is also called continuous RE (See 5.1.6).

The Usage Facet

The usage facet comprises all (context) aspects concerning the system usage by people and other systems. One of the requirements sources in this facet is compromised by the direct or indirect users of the system. According to Pohl (2010), an indirect users possesses the following characteristics:

• The person or system does not use the system himself (itself) but it is indirectly involved in the usage.

• The person or system influences the usage of the system. • The person or system benefits from the usage indirectly.

Eason (2005) defines the direct and indirect users more precisely, by categorizing the user types into groups: the primary users; the direct users of the system

(19)

who may be full-time users, secondary users; the occasional users or people who work directly with the output of the system and the tertiary users; people who are affected by the operation of the system but are not direct users. Information about the needs and desires of these user types should be included in the usage requirements for a system.

IT System Facet

The IT system facet comprises all (context) aspects of the operational and tech-nical environment. This includes policies and strategies, that define restrictions or a guideline for the use of any type of technology. All the aspects of the technical and operational environment, as well as the constraints resulting from them, influence the system requirements.

Development Facet

The development facet entails all aspects of the context that are present in the development process of the system. Stakeholders in this facet are all persons who deal with the planning, design, and operation of the IT system environment. This can, for example, be process engineers, process managers and/or process executors (e.g. architects). The client as a stakeholder can, for example, in this facet demand that only certified tools are used during system development.

3.1.2 Requirements Elicitation

After the context of the desired system has been defined, the process of RE continues by eliciting, also described as gathering, the requirements from the several stakeholders involved. Requirements elicitation is concerned with learn-ing and understandlearn-ing the needs of users and project sponsors with the ultimate aim of communicating these needs to the system developers (Zowghi & Coulin, 2005). It is one of the three core activities of RE as described by Pohl (2010), and consists of three sub-activities:

1. Identifying relevant requirements sources 2. Eliciting existing requirements

3. Developing new and innovative requirements

The goal of the first step of requirements elicitation is to identify all relevant requirement sources in the system context (see 4.1.1). Requirements can be elicited by techniques such as interviews, focus groups, surveys, etc. (Jacob & Dekkers, 2015; Anwar & Razali, 2012; Pohl, 2010). An interview is most often used to elicit requirements, as it is the most suitable in covering all three sub-activities of the elicitation process (Pohl, 2010). There are several types of requirements that can be elicited from the elicitation process. Pohl (2010) describes the following types of requirements:

1. Functional requirements: requirements that specify the services and functions the system should provide to its users and how it should react and behave. Functional requirements can for example describe behaviour, data, interaction or interfaces.

(20)

2. Quality requirements: requirements that define a quality property of the entire system or a system component, service, or function.

3. Constraints: organisational or technological requirements that restrict the way in which the system shall be developed. Constraints can for exam-ple be cultural (i.e. constraints originating from the cultural background of system users) or legal (i.e. constraints originating from laws and stan-dards).

The process of requirements elicitation is generally considered as a vital, but also a extremely difficult part of software development projects. Requirements elicitation therefore comes with some serious pitfalls. Zowghi & Coulin (2005) describe a few pitfalls that need to be considered when eliciting requirements. One of these pitfalls concerns the conflicts that may rise between the several stakeholders. Stakeholders all have a different views on what the system should do, and often do not understand each others needs.

3.1.3 Requirements negotiation

The system that needs to be developed should consider and preferably realise all needs and wishes of the different stakeholders. These needs, however, often contradict each other and therefore conflicts arise as project stakeholders such as future system users, acquirers, developers or maintainers frequently pursue mismatching goals (Boehm et al., 2000). These conflicts need to be solved, as unsolved conflicts often compromise the acceptance of the system by the stakeholders. The requirements negotiation process is therefore included in Pohls framework as one of the three core RE activities. The overall goal of requirements negotiation is to understand the objectives of the stakeholders, and to develop mutually acceptable agreements. The goal is not to make sure that stakeholders do not disagree, but to understand why stakeholder disagree (Gr¨unbacher & Seyff, 2005).

There have been several researches on how to approach the negotiation activ-ity. A well-known and often used approach is the Win-Win approach (Boehm et al., 2000). The Win-Win approach consists of three situation: win-lose, lose-lose and win-win. A win-lose situation takes place when some stakeholders achieve their goals in a conflict at the expense of other stakeholders. A lose-lose situa-tion when no conflicting stakeholder achieves their goals. Of course, the goal of this approach is to make all stakeholders winners. A win-win situation is there-fore the most preferred one, and results in all conflicting stakeholders achieving their goals completely or partially. For a requirements engineer to achieve a win-win situation, the engineer must know how stakeholders want to win. He should also not raise unrealistic expectations for the system to be developed. Striving to reach a win-win situation therefore supports the negotiation strategy and the creative solution strategy for conflict resolution.

3.1.4 Requirements documentation

The aim of the requirements documentation is to document important informa-tion elicited or developed when performing a RE activity, for instance elicitainforma-tion (see 4.1.2) or negotiation (see 4.1.3). Relevant information that needs to be doc-umented can for instance include: the different stakeholder viewpoints, interview

(21)

results, new and innovative requirements, risks, stakeholder arguments or the utilised context aspects (Pohl, 2010). Documentation of requirements is not the same as specification. Sometimes, information from a certain RE activity needs to be specified, explained more elaborate, before it can be documented as a requirement.

Pohl (2010) uses the term requirement artefact to describe the documented requirement. A requirement artefact can in fact be anything that is a some-what tangible representation of the requirement. This artefact can be formed by simply writing down the requirements, whether during or after they have been expressed through, for example, natural language. But an artefact can also be a case-diagram or a work-flow, representing the requirement(s). A re-quirements document can be created for several purposes. It can, for example, be useful to facilitate communication between users, domain experts, require-ments engineers, software developers, etc. But it can also be used as a reference model for creating an architectural design, for negotiation of requirements or as the basis for deriving manuals such as user manuals or maintenance manuals.

3.1.5 Validation & Management of Requirements

In the final steps of the RE process as described by (Pohl, 2010), the require-ments that have been documented need to be validated and managed. Valida-tion is aimed at checking the artefacts (documented requirements) and checking whether the right inputs have been used to produce the artefacts. To check the quality of these artefacts, the artefacts are usually communicated back to the stakeholders with the purpose of detecting deviations between the documented requirements and the stakeholders’ true needs and wishes. The management of these RE artefacts is again part of the management activity. Furthermore, the management activity includes managing (observing) the possible changes in system context and managing the RE process by defining the RE activity (elicitation, documentation, etc.) that is to be executed next.

3.1.6 Continuous RE

Continuous RE is concerned with defining requirements for a new system based on the the analysis of an existing system or process (Pohl, 2010). Typically, the new system (partly) automates and thereby (partly) replaces existing sys-tems and processes. The most used method for analysing existing syssys-tems is Structured Analysis (SA), as proposed by DeMarco (1979). In SA, data flow diagrams are used to document the system functions and the input and output data flows of each function. SA suggests documenting the current state in the so called ’current state model’ based on the analysis of existing systems and/or processes. The desired changes are then integrated into the current-state model, thereby defining the desired-state model. SA, as a method of continuous RE supports the RE process in cases where there is already a system and/or pro-cess in place and where the RE propro-cess is aimed at changing or improving this system and/or process.

(22)

3.2 RE in the healthcare domain

In some domains, usually the complex ones, the known approaches and/or tech-niques for RE need to be carefully applied to work efficiently. The healthcare domain, with its political and legal issues is one of these complex domains (Cys-neiros, 2002). Also, information systems in this domain usually deal with very personal, high-confidential and therefore privacy-sensitive information.

This subsection therefore reviews literature on RE in the healthcare domain, and to what extent the process of RE is different and/or similar to the traditional process as described by for instance Pohl (2010), Hull et al. (2010) and Wohlin et al. (2005). For example, the definition of a tertiary user (as described in 5.1.1.2) is quite similar to that of an object considered in the subject context (as described in 5.1.1.1). So how should we deal with certain actors in the healthcare domain, like patients, who dont really use the information system but who are affected by the operation of the system (tertiary user), and are at the same time subject to the system? Should this actor be considered in the subject context, and therefore be represented by laws and domain experts, or be considered as an indirect user?

3.2.1 User-centered RE approach

An user-centered RE approach in healthcare, more specifically in the hemophilia field, is described by Teixeira et al. (2012). They were asked to perform a study by the hematology service of a regional hospital, in order to assist the hemophilia patient care at this hospital. To specify the health information system or application that could be used in this field, the authors used a user-centered RE methodology. The patient was included in this research, as he was required to register the bleeding episodes (which is common with hemophilia1₎

in the system himself. It was therefore, according to the authors, important to include the patient, so that the process of registering the bleeding episodes would be clear to them. The authors also took into account the domain that the system would be developed within. They represented the domain model through a class of UML notation. The technological solution that finally resulted from their study, is a user-friendly web application that allows communication among, for example, hemophilia patients and doctors. It also made information on treatments effectiveness, and patient clinical data, as well as other disease related information available to the patient. This way, the patients could have direct access to relevant information, and, for example, allowing them to view their clinical history. In this particular case of RE, the patient was considered a direct user, as the patient himself also had direct interactions with the system.

3.2.2 Customer-focused RE approach

RE in the healthcare domain can also be customer-focused, by thinking in terms of customers and providers. In the healthcare domain, customers can, according to Kossmann (2014), be governmental bodies, local councils or, in the case of the software system, the department of a private hospital or a manufacturer of advanced hospital equipment. Providers of these systems or products may be

1_{Hemophilia is an inherited genetic disorder that impairs the body’s ability to make blood} clots, a process needed to stop bleeding.

(23)

private or public industrial companies. The customer-focused RE approach, in its main activities, is quite similar to the general RE approach, as it also con-sists of elicitation, documentation and negotiation. The customer-focused RE approach is primarily focused on supporting the communication between cus-tomer and provider. Other stakeholders in this RE approach are not included.

3.2.3 Deficiencies of current RE approaches

Most of the software build to work in the healthcare domain does not take into account the most important consumer of healthcare: the patient (Cysneiros, 2002). Software developers and healthcare providers tend, according to Cys-neiros (2002), to ignore that the final customer is the patient and that therefore the patients concerns should be taken into account. The following example is given: a clinical analysis laboratory establishes a system that asks for drawing one blood sample for each different sector within the lab where the tests will be processed. Thus, if a physician asks for eight different tests, it is not unusual to use four different samples. However, many patients may not feel comfortable with that. While the patient here is not a direct user of the system, he or she might feel uncomfortable with the ways the system is used. The requirements engineer in the healthcare domain should therefore understand the reasons that underlie the processes in the healthcare domain. Cysneiros (2002) argues that the requirements engineer should ask him or herself: why are things done that way? What are the positive and negative aspects of doing things the way they are done today? The requirements engineer should think in alternative and more efficient ways of achieving the goals of a system, and understand the as-pects that can contribute to achieving this. Cysneiros (2002), however, does not further elaborate on how to actually include the data subject in the RE process. Activities that, according to Cysneiros, should be included in the med-ical RE process include the following activities: understanding the vocabulary used, eliciting (non-functional) requirements, reading existing documents and creating questionnaires and interviews to elicit the requirements.

3.3 Conclusion

Overall, there is not yet that much literature on RE in the healthcare domain. The existing literature about the RE process in the healthcare domain, for example Cysneiros (2002) and Kossmann (2014), include activities that are quite similar to the general RE process as, for example, described in Pohl (2010) and Hull et al. (2010). However, which stakeholders are considered relevant in the RE process seems to differ by author. Most authors describe the (direct) user of the system as the data holders as the most important stakeholder, while Cysneiros (2002), for example, argues that the patient (the data subject) is the most important stakeholder. Furthermore, multiple authors argue that the approach to RE that needs to be taken is highly dependent on the context that the health information system is developed within (Jorgensen & Bossen, 2003; Kossmann, 2014).

Due to its political and legal issues, RE in the healthcare domain differs from other, perhaps more simple, domains. This is, amongst others, due to the fact that information systems in this domain usually deal with very personal, high-confidential and therefore privacy-sensitive information. We have seen that

(24)

some authors, among which Cysneiros (2002), argue that we should therefore consider including the patient, the data subject of a system, and his or her concerns amongst which those with regard to privacy in the early development phases. The next chapter thus elaborates on how privacy can be defined, and how data subjects experience and perceive privacy. It describes what aspects of privacy are relevant to data subjects in the healthcare domain, and how (and to what extent) these aspects are included in the RE process.

(25)

4 Literature Study on Privacy in RE

RE in the healthcare domain has already proven to be more difficult than other domains, as it deals with some very privacy-sensitive information. In RE, there are usually laws to protect a data subject’s (and/or patient’s) privacy. But do the laws sufficiently take the privacy aspects and concerns of the data subject into account? For instance, medical IT systems are often bought by hospital directors and insurance companies, whose interests in account management, cost control and research are not well aligned with the patients interests in privacy (Anderson & Moore, 2006).

To fully understand the sufficiency of the involvement of the privacy aspect, first the concept of privacy, and how people perceive the concept in general, will be described (section 5.1). The following subsection (section 5.2) will focus on the application of the privacy concept to the healthcare domain. The third subsection (section 5.3) describes the perception of privacy in the healthcare domain. More specifically, it describes the perception of privacy of the data subject and data holder in the healthcare domain and what aspects of privacy are important to them in this domain. The chapter ends with an integration of privacy and RE in the healthcare domain. Literature on how privacy issues should be included in RE, according to several authors, in the healthcare domain will be described. The chapter will end with a conclusion on to what extent the described privacy aspects, that are important to the data subject, are included in the RE process in the healthcare domain.

4.1 The Concept of Privacy

Privacy knows several - sometimes even contradictory - definitions. Privacy was first defined by Warren & Brandeis (1890), who described privacy as ’the pro-tection of personal space and the right to be left alone’. Another well-known interpretation of privacy is described by Westin (1968), who argues that privacy is equal to having control over and safeguard of personal information. Privacy is, according to Westin, the claim of individuals, groups or institutions to de-termine for themselves when, how, and to what extent information about them is communicated to others. Where Warren and Brandeis’ definition focuses pri-marily on the physical aspects of privacy, the definition of Westin focuses more on a person’s information. Noam (1997) later describes privacy as an inter-action in which the information rights of different parties collide. The general issue of privacy, according to Noam (1997), is that of control over information flow by parties that have different preferences of information permeability. The concept of privacy as defined by Noam (1997) and Westin (1968) can therefore be described as informational privacy (DeCew, 1997). However, other authors like Burgoon et al. (1989) argue that privacy is not always necessarily concerned with an individual’s information. According to Burgoon (1982) (via Burgoon et al., 1989), privacy can be described as the ability to control and limit physical, social (interactional), psychological and informational access to the self or one’s group. Burgoon et al. (1989) therefore argues there are four dimensions (the above described physical, social, psychological and informational) that should be considered when approaching privacy. We have already described the con-cept of informational privacy above, but we will now further explore the other domains of privacy as defined by Burgoon et al. (1989) and as described in

(26)

(Nanhekhan, 2013).

4.1.1 Physical Privacy

Physical privacy is concerned with the extent to which a person is physically accessible for others. An individual’s physical privacy is infringed when an individual’s personal space or territory is violated.

4.1.2 Social Privacy

Social privacy is concerned with the ability of individuals to control social con-tacts. Individuals experience social privacy when they have control about how they maintain relationships with others.

4.1.3 Psychological Privacy

Psychological privacy is primarily concerned with an individual’s ability to con-trol cognition and emotional influences. This results in the individual having complete control over his or her life and what he or she wants to accomplish. Privacy in this dimension is infringed when an individual’s autonomy (an indi-vidual’s control over his or her life) and/or self-consciousness (how an individual sees him or -herself) are negatively influenced by others.

The privacy dimensions described above might influence how people, subjec-tively, perceive and value privacy. This will be further explored and described in the following sections on the economics of privacy (section 4.1.4) and the perceptions of privacy (section 4.2).

4.1.4 The economics of Privacy

The economics of privacy is concerned with the incentives and trade-offs of disclosing information (Acquisti, 2010). When considering privacy from an eco-nomic perspective, we are concerned with a ’transaction’ of information between different parties to gain access to a certain product or service. Acquisti (2004), however, argues that privacy means different things to different stakeholders, i.e. the parties involved. For example, different parties might have opposite interests about the amount of information to disclose during such a transaction. This interaction usually includes two specific parties: a party who discloses information and whose data will be stored, and a party who receives the infor-mation and who will use it. In this thesis, these parties are respectively called the ’Data Subject’ and the ’Data holder’. The data subject discloses his or her information to the system that the data holder uses, in order to benefit from the product or service that the data holder offers. According to the economics of privacy, before a transaction is made, the data subject first sets up a balance of the advantages and disadvantages of disclosing his or her information. By doing so, the data subject assigns a certain value to his or her privacy. This value, however, is very subjective and dependent on how the data subject ex-periences, or perceives, his or her privacy and what aspects of privacy (which can for example be informational, physical, social and/or psychological) he or she considers important.

(27)

4.2 Perceptions of Privacy

In their research about the perception of privacy of Dutch internet users, Roosendaal et al. (2015) describe that the most valued aspects of privacy are associated with online privacy and privacy of information (informational privacy). For exam-ple, at least 70 per cent of the respondents thinks it is important to know who has access to information about them. Besides that, at least 80 per cent of the respondents thinks it is important to have control over who has access to and insight into their personal data. Respondents were also asked to which degree they trust certain organisations in using and protecting their personal data. Respondents felt they could trust the police the most (45.5 %) and social media organisations the least (74.8 %). Other organisations that respondents trust relatively much with their personal data include tax authorities (43.2%) and healthcare organisations (42.6%).

The perception of privacy is usually dependent on an individual’s subjective experience of privacy. According to Roosendaal et al. (2015), most people expe-rience their informational privacy the most valuable. However, as described in section 4.1, privacy can also be approached from a physical, social and psycho-logical perspective. Therefore, as is also argued by Dienlin (2014), the percep-tion of privacy can also be approached according to these dimensions. According to Dienlin (2014), the higher the level of privacy perception, the more people will engage in a subsequent act of self-disclosure. People perceive a current sta-tus of privacy, which they compare with the desired stasta-tus of privacy. Based on this comparison, people will aim at achieving the desired level of privacy.

To explore these perceptions, Dienlin (2014) argues that the dimensions of informational, social, psychological and physical privacy can again be applied. Therefore, the four dimensions of privacy will be used to further explore the perception of privacy of the stakeholders central in this thesis (the data sub-ject and the data holder) in chapter 4.4. Perceptions of both stakeholders will be described, as both stakeholders can interpret and perceive privacy, in all its dimensions, differently. Conflicts between the interests and values of differ-ent stakeholders can also result in differdiffer-ent perceptions of privacy (Introna & Pouloudi, 1999).

4.3 Privacy in the healthcare domain

While the implementation of advanced ICT in the healthcare domain has lead to certain benefits (reduced expenses, easier information sharing, immediate access to information), it has also lead to serious privacy concerns amongst patients (Lapke et al., 2017). At the same time, privacy in the healthcare domain is often seen as the most important principle of the patient-physician relationship (Appari & Johnson, 2010). In this relationship, patients are required to share information with their physicians to facilitate treatment. Nevertheless, patients may also refuse to divulge information as a result of privacy concerns that they are experiencing.

In recent years, numerous privacy laws and regulations have been drawn up and implemented to protect the patient’s health information. In Europe, the European Directive on personal data protection has been implemented. The so called ’Wet bescherming persoonsgegevens’ (Wbp) is the Dutch version of this directive, and has been in force in the Netherlands since September of 2001

(28)

(Autoriteit Persoonsgegevens, n.d.-b). Hospitals are required to comply with these legal requirements to protect the confidentiality of patients’ protected health information.

4.3.1 Healthcare related privacy laws

The most important privacy law in the dutch healthcare domain, with regard to health information systems, entails the above described Wbp: the law for the protection of personal information. The law, as described in article 16 of the Wbp (July 6th, 2000) prohibits the processing of personal information. This prohibition does not apply when the processing of personal information is done by, for example, healthcare providers, insurance companies to assess the risk (that is to be insured by the insurer, or employers in the case of reintegration or guidance of employees with illness or disability) (Art. 21 of the Wbp, july 6th, 2000). Article 21 of the Wbp also prescribes that all personal information with regard to someones health can be processed and used, provided that this is essential to a proper treatment or care of the person concerned.

Another article worth discussing here, is article 8 of the European Directive on personal data. This article grants protection to sensitive data, including the processing of data concerning a persons health. This sensitive data may only be processed under certain clearly-defined circumstances, one of which being that the data subject has given his explicit consent (Prins, 2006). However, personal health data may be processed without explicit consent for the purpose of sci-entific research, when asking for explicit permission is impossible or demands a disproportionate effort (Art. 23, Wbp, july 6th, 2000). The processing of personal information should therefore always be done with a purpose, and when possible with explicit consent of the data subject. Also, the data subject should be provided with the rights of correction, amendment, and deletion of data that have been recorded about him or her.

The existing privacy laws, including those relevant to the healthcare domain, are often quite vague and open to interpretation. Therefore, the privacy laws can be interpreted in different ways, and are therefore highly dependent on the context (Prins, 2017).

4.4 Perceptions of privacy in the healthcare domain

As described in section 4.2, privacy is generally interpreted and perceived from many different perspectives. With medical data disclosures being the second highest reported breach (Hasan & Yurcik, 2006), perceptions of privacy in the healthcare domain are usually rather negative. A recent survey in the USA suggests that 75 per cent of patients are concerned about health institutions sharing information without their permission (Raman, 2007). This negative perception of privacy in the healthcare domain is further fuelled by stories on the misuse of data. For example, it was recently revealed that dutch municipalities were using privacy-sensitive patient data of their citizens to determine who should, and who shouldn’t, receive social care (Sjerps, 2017).

Throughout this entire thesis, we have distinguished both data subjects and data holders. In this section, we again look at these different actors, and their perception of the data subjects’ privacy. These actors often have different in-terests and value the privacy of the data subject differently, which may result

(29)

in different, and perhaps contradictory, perceptions of privacy. As Scott (2000) describes: nearly everyone agrees that it is ethically correct to protect a pa-tient’s health information, but just how much privacy protection to give that information is a question over which people sharply disagree.

4.4.1 Perceptions of the Four Dimensions of Privacy in the health-care domain

In their research about adolescents’ needs for privacy in healthcare, Britto et al. (2010) describe, based on Burgoon’s framework of the four dimensions of privacy, which aspects are mainly perceived as important. They concluded that maintaining informational privacy was most salient to the adolescents. There was, however, a difference between the younger and older adolescents. Younger adolescents were mainly concerned with information being disclosed to others (i.e. health care providers), whereas older adolescents worried more about information being disclosed to parents. However, Britto et al. (2010) also argued that the other privacy aspects (psychological, social and physical) were also important. With regard to their psychological privacy, adolescents were cautious about revealing sensitive information for the fear of being judged by healthcare providers. Furthermore, to protect their social privacy, they were reluctant to talk with unfamiliar or multiple providers, and they did not want to discuss issues they perceived as unrelated to their healthcare. Finally, with regard to physical privacy, adolescents said that they thought about their physical safety during physical examinations, as well as their visibility to others. According to Britto et al. (2010), the participants also said that they were more comfortable when examination was performed by female rather than male providers.

Data Subjects

Data subjects in the healthcare domain are the people whose data is stored in a health information system. These data subjects are often patients, but can, for example, also be health workers. Health workers can, for example, be data subjects with regard to their employee file. Also, health workers can be treated as patients in their own hospital.

The perception of these data subjects is, according to multiple authors, often based on the sensitivity of the concerned information (King et al., 2012; Karro et al., 2005; Lohr et al., 1994; Simons & Verhagen, 2008). Sensitive items of medical records are, for example: sexually transmitted diseases, abortion or infertility, family medical history, list of previous operations/procedures/dates, etc. (King et al., 2012). Data subjects also fear, according to Lohr et al. (1994), that both those with and without bona fide access would be able to call up a remarkably comprehensive and intrusive dossier comprising detailed biographic information, employment information and, unless prevented, medical record information about every citizen participating in the system.

Other research by Lin & Lin (2010) described the factors predicting a pa-tient’s perception of privacy for emergency care. From this research it appeared that, again, the informational aspects of privacy mostly influenced the per-ception of privacy. The factor that most highly correlated with the patient’s (data subject’s) perception of privacy included ’personal information overheard by others’. Lin & Lin (2010) describe that a twenty-one per cent of patients

(30)

agreed and strongly agreed that they withheld some information from healthcare providers, because they felt that information may be disclosed inappropriately. In addition to the informational aspects, other significant factors associated with patient’s overall perception of privacy included: being seen by irrelevant persons (which can be assigned to the social dimension of privacy), privacy of space when being physically examined (which can be assigned to the physical dimension of privacy), and a provider’s respect for privacy.

Therefore, privacy concerns can lead data subjects to withhold vital infor-mation from clinicians. According to Sankar et al. (2003), this is especially common amongst HIV patients and adolescents. Both parties would not trust the clinical setting to be able to keep the information confidential, and they fear refusal of treatment or discrimination. These privacy concerns can be placed within the psychological dimension of privacy, as the parties concerned feared judgment of healthcare providers. Therefore, privacy concerns amongst data subjects (patients, for instance) should indeed be taken seriously, as these con-cerns lead to them withholding important information from the data holder (health professionals, for instance). Approaching these concerns from the dif-ferent dimensions of privacy can contribute to a better understanding of the grounds for these concerns and to a better understanding of the inclusion of these privacy aspects in RE.

Data Holders

Data holders in the healthcare domain can, for example, be health professionals that have access to, and use the system(s) where the data of the data sub-jects is stored. Health professionals have, according to the law, the obligation to protect the privacy of the data subject. However, research shows there is a clear disconnect between privacy requirements and the employee’s behaviour with regard to privacy. For example, Lapke et al. (2017) conclude that health-care providers do not view privacy as a high-priority within the context of their duties. They argue that healthcare professionals prioritise personal and organ-isational gain, as well as mitigating personal and organorgan-isational loss over the patients privacy. Eikey et al. (2015) also describe that health professionals often try to find workarounds to bypass system features that make accomplishing their work difficult. This is because health information systems are often designed with features that limit sharing and restrict unauthorized access to patient in-formation. Therefore, these workarounds are often very privacy-compromising. The importance of the data subject’s privacy seems, therefore, not to be of high importance to the data holder in the healthcare domain. Their percep-tion of the data subject’s privacy highly differs, as the data holder is primarily concerned with personal and organisational gains. For example, a health profes-sional is mostly concerned with caring for patients and working as efficient and quickly as possible. Protecting a patient’s privacy is usually not their highest priority.

4.5 Privacy engineering in the healthcare domain

In the previous section, we have explored the concept of privacy and the percep-tion of the concept, both from a data subjects and a data holders perspective. This section elaborates on literature on the representation of this concept in the

(31)

medical RE process. Privacy in RE can, for example, be represented by legisla-tive requirements, also called constraints (see 4.1.2), who aim at protecting the data of the data subject. However, privacy can also, according to some authors, be included in the RE-process as a non-functional requirement.

4.5.1 Privacy as a legislative requirement

Legislative privacy requirements describe the privacy laws that the healthcare organisations must comply with. To meet these legislative requirements, health-care organisations usually implement privacy and security policies that deter-mine who can, and is authorised to, access electronically stored health data. Also, many governments have come up with a set of guidelines to enforce le-gal requirements for the handling of healthcare data as a way of achieving the intended level of privacy (Pussewalage & Oleshchuk, 2016). Legislative requiments are therefore often privacy policies, based on existing privacy laws, re-stricting the way in which the system shall be developed.

4.5.2 Privacy as a non-functional requirement

Privacy is also sometimes seen as a non-functional requirement, as it can also be used as a criterion to judge the operation of a system. Cysneiros & Breit-man (2002) describe that patients may be concerned with their privacy when, for example, an information system is used to upload their information to any equipment. Patients expect, according to these authors, that they their name is always omitted. Privacy as a non-functional requirement seems to be a mea-sure for the operation of the system, after it has been developed. It tests the developed system based on its quality with regard to the protection of pri-vacy. These tests are usually done when healthcare organisations want to get certified according to certain standards. In the Netherlands, the ISO (Inter-national Organization for Standards) standards are often applied to test the quality of health information systems. The ISO standard 27001 is one of the ISO standards concerned with the protection of a patients information and pri-vacy (NEN, 2017). Healthcare organisations, and the systems they use, can get ISO certified when they comply with these ISO standards. So, privacy as a non-functional requirements is more concerned with validating the system with regard to privacy ´after there is already some prototype of the system. Privacy as a legislative requirement, on the other hand, restricts the actual development of the system in its early development phases.

4.5.3 Engineering Privacy by Design

Privacy by Design is concerned with an early focus on privacy enhancing mea-sures during the development of products and services, such as information sys-tems (Autoriteit Persoonsgegevens, n.d.-a). According to G¨urses et al. (2011), privacy by design in developing systems is to be done by the foundational en-gineering principle of privacy: data minimisation. Other research about the engineering of personal health records describes addressing the stakeholder’s perspectives in engineering privacy (Kaletsch & Sunyaev, 2011). Kaletsch & Sunyaev (2011) argued that, in engineering privacy, information technology so-lution providers should be included to first assess threats to sensitive system,

Towards a better understanding of privacy in medical Requirements Engineering: A case study among Dutch hospitals