Towards the Design of Privacy-Aware Computing: A ... - UC Berkeley

1 downloads 0 Views 233KB Size Report
designing software and in creating interactions that are effective in helping end-users manage their privacy [6]. In addition, despite the fact that the importance of ...
Towards the Design of Privacy-Aware Computing: A Case Study in Hospital Work Mónica Tentori1, Jesús Favela1, Víctor M. Gonzalez2 and Marcela D. Rodríguez1 1 Departamento de Ciencias de la Computación, CICESE, Ensenada, BC, México {mtentori, favela, marcerod}@cicese.mx 2 Universtity of California, Irvine, CA, USA [email protected] ABSTRACT Privacy is a complex social process that will persist in one form or another as a fundamental feature of the substrate into which ubicomp is threaded. To better understand the privacy issues related to the use of ubicomp we place our efforts in understanding the contextual information relevant to privacy and how their interplay shapes the perception of privacy in a particular setting, such as a hospital. We introduce the concept of Quality of Privacy (QoP) which allows balancing the trade-off between the amount of privacy a user is willing to concede and the value of the services that can be provided by a ubicomp application, in a similar way as that of Quality of Service (QoS). We propose an agent-based architecture that adapts the ubicomp application’s behavior based on the user’s context. Finally, we exemplify our architecture extending a context-aware mobile communication system.

the fact that the importance of privacy has been highlighted, there have been no attempts to understand the privacy concerns of medical workers, how those concerns affect their practices, and how they are affected by the introduction of ubicomp technologies. Based on this, we want to corroborate if our work still hold in this particular setting. In addition, we think that these situations can be used as insights and issues that can be helpful to design grounded privacy-aware ubicomp applications, and provide directions for new opportunities for research and development in this field. The rest of the paper is organized as follows: We first present, in Section 2, the results of a case study that allowed us to identify the contextual information which shapes hospital workers’ perception of privacy. In Section 3, we introduce the concept of Quality of Privacy (QoP) and present an architecture aimed at addressing privacy issues in ubicomp. Finally, Section 4 presents our conclusions.

INTRODUCTION Ubiquitous computing will surround users with a comfortable and convenient information environment that merges physical and computational infrastructures into an integrated habitat [15]. Context-awareness will allow this habitat to take on the responsibility of serving users, by tailoring itself to their preferences as well as performing tasks and group activities according to the nature of the physical space. Moreover the more an application has a rich knowledge of each user the better it can perform its task. Paradoxically, the more an application knows the user the greater the threat to his privacy [4]. Thus, the pervasive computing era also brings some risks, being the potential invasion of privacy among the more important ones.

A CASE STUDY: UNDERSTANDING PRIVACY IN UBIQUITOUS HOSPITAL ENVIRONMENTS For a period of three months we conducted a workplace study at a public hospital. This study helped us assess some of the privacy issues hospital workers face on their everyday practice, how they deal with it, and the way it influences their decision making. In addition, it helped us understand how hospital workers perception of privacy changes by the foreseeing use of ubicomp technologies. Next we briefly describe the results of the case study more detailed information is described in [14].

Because previous research has indicated that the privacy demanded and expected by a user is context dependent [1, 11], we decided to base our efforts on understanding the contextual variables and the interplay among them that shape the perception of privacy in the particular case of hospitals. Important work has been made in the last few years in the design and deployment of ubicomp solutions in support of hospital work which are a step in the direction of providing accurate and timely information to hospital staff in support of adequate decision-making [2, 9]. Despite the benefits of ubicomp for hospitals, cases of users’ distrust and abandonment of potentially useful ubiquitous applications have been reported, and among other factors, privacy concerns have been identified as a central aspect to be considered[12]. Paradoxically, the the design of ubicomp for hospital has, in general, overlooked privacy issues due among other factors to the lack of understanding about how in practice they can be integrated into the system’s architecture.

Methodology The study at the hospital started with a period of systematic observations where we followed for a period of three working days, three medical interns, two nurses, and two physicians throughout their morning, afternoon, and night shifts. Our observations in the hospital helped us identify specific instances where privacy was compromised, or decisions were made taking privacy issues into consideration. We used this information to generate two sets of scenarios, one based on current practices, and a second one using ubicomp. We conducted ten interviews to five hospital workers and discussed the scenarios with them, to get a sense of whether they found the proposed ubicomp systems to support their work and if the scenarios made apparent privacy concerns. As a results of those interviews we derived a new set of four four ubicomp scenarios that were both useful for medical work but rose privacy concerns for hospital workers. Each scenario was defined to explore both the benefit of an ubicomp application supporting medical work and its impacts for privacy of those using it.

The problem is that developers currently have little support in designing software and in creating interactions that are effective in helping end-users manage their privacy [6]. In addition, despite

We organized a group evaluation to show the four scenarios to medical workers. Following an scheme proposed by Caroll, we

1

illustrate some of the technology proposed for, and privacy issues raised by, the scenarios.

presented the scenarios to 27 medical interns.. The participants were asked to situate themselves in a specific role within the scenario. After each scenario, they were asked to complete a survey with 7 Likert-scale assertions for each scenario, to evaluate the threats raised by the technology to their privacy. Finally, we applied these findings to identify the contextual information used to regulate and manage privacy using a ubicomp application.

Scenario 4: Medical Supervising through the Floor Map Mrs. Diaz, a head nurse, wants to know if an intern made a clinical procedure to the patient in bed 222. She approaches a semi-public display where she selects the name of the intern in charge of the patient and a window showing a map of the area pops-up. The window includes a widget that represents a Timeline. Thru it, she can scroll through time and the map in the window will display the location of the intern (see Figure 1). The map shows that the intern entered room 239 and spent a few minutes in this room. Mrs. Diaz stops the Timeline to find the intern’s activities in this room. The display shows the electronic medical record related to the patient in room 239 and photographs of the intern’s activities taken at the time. Trough the timeline Mrs. Diaz notices that the intern entered the Internal Medicine office. Trough the photographs displayed, she realizes that the intern resident was chatting with Rita, another intern until Dr. Perez arrives to the office; and then the three discuss a clinical case. Following the activities of the intern through the day she realizes that the procedure wasn’t made, and assigns it to another intern.

Privacy management From our observational data we identified a set of privacy concerns that emerged during the enactment of work of those individuals that we observed. These concerns center around the individuals themselves, the information they manage, and the people they interact with. In general, we noticed that the perception of the importance of each concern can be affected by the particular circumstances experienced by people. We observed that sometimes medical personnel tend to relax the privacy implications of some of their actions in order to cope with the circumstances experienced or in order to facilitate their work. For instance, despite that the medical record is an official document that, according to the rules, cannot be removed from a particular area of the hospital; sometimes the medical interns take those documents to other places to facilitate the study of a case. This situation is generally with the knowledge and encouragement of physicians supervising interns as they see it as a way for interns to take full responsibility of a case and to help them improve their decision making. Medical interns, as they become used to medical practices, people’s styles and routines, learn to adapt their privacy concerns to each particular kind of circumstance.

Activities Photos

Ubicomp scenarios that raise privacy concerns With the results of the interviews, we defined four scenarios that integrate one or more of the ubicomp services that have been proposed in support for healthcare and other working environments. The scenarios were also identified as being useful while raising privacy concerns for the medical worker involved. Table 1 indicates the different ubicomp services that were included in each of the four scenarios we selected. Scenarios 1 2 3 Ubicomp services √ Displaying info from a personal device √ Monitoring people’s location √ Locating services √ √ Context-based notifications and reminders √ Data transfer between heterogeneous devices Tracking people’s movements √ Audio/video capture of people’s activities √ Memory aid √ Identify people with similar needs/interests Table 1. Ubicomp services used in the grounded-scenarios

Timeline

Public Map

Figure 1. With the timeline tool a supervisor can follow the location and activities performed by medical interns.

4

This scenario has serious privacy implications since the nurse (and potentially other supervisors) can track the location of the intern throughout the day, including photos of the intern’s activities. Nonetheless, we included such scenario because it was found useful by hospital staff’ who actually supervise the interns’ activities. A head nurse made the following comment during an interview when the scenario was shown to her: “I find this system really helpful because I can evaluate through the photos if my staff follows the norm, besides these photos could be used as study reference”. In addition, although the people interviewed were not very concerned of colleagues knowing their location, they were not foreseeing the potential use of this information in the future as illustrated in the scenario.

√ √ √ √

The first scenario illustrates how an intern requests laboratory studies and receives context-aware notifications of the availability of the results through a handheld. The second scenario shows how photographs of the intern’s activities, taken while performing a surgical procedure, can help her as memory aid when she is interrupted by an emergency, and later on needs to resume the task. The third scenario shows how colleagues collaborate discussing a clinical case through heterogeneous devices. Finally, the fourth scenario illustrates how a supervisor can find out if a given procedure has been performed, by looking at where the intern was throughout the day and looking at pictures of him taken at different times during his shift. We next describe scenario 4 to

Contextual information We identified two sets of contextual information differing in the role that this information play in order to preserve privacy. The first set of contextual information is defined as contextual elements. The contextual elements are the parameters that the user wants to protect while using a ubicomp environment and they are perceived by the user qualitatively and regulated quantitatively by the technology. In accordance with previous studies [8], location, identity, and time are important factors in assessing privacy concerns. In addition to these variables, we found access and persistence as being highly relevant.

2

stored for long periods of time and could be used to derive secondary contextual information. Such as, the places that the individual visits more often or with who does he normally interacts.

The identity, the location and the activity of hospital staff members determines their perception of privacy in specific situations. Thus, a ubicomp application has to manage the precision with which these information is given and provide mechanisms to help the end-users regulate them. Related to the location, a medical intern made the following comment during an interview: “For example, when you have time off you might also have pending tasks, and if you’re in the break room or in the dinning room I’ll would be concern if my location is being shared; because this information could be used to get a sense of the amount of work that I’ve done, or I’ve haven’t because I was in my lunch break”. In this case, if a medical intern is in the bathroom or the dinning room, he wouldn’t want to be disturbed or he might not want others to know how much time they spent in this particular location.

We are currently working on these concerns shaping them in a form of design principles; in order, to help designers analyze the privacy concerns during the design of ubicomp and help them incorporate mechanisms to reduce the privacy risks of the ubicomp application they develop. We expected with this to create a new direction in the development of ubicomp: the development of privacy-aware ubiquitpus computing applications. PRIVACY-AWARE COMPUTING There is a trade-off between the amount of privacy a user is willing to concede and the value of the services that can be provided by a ubiquitous application. For instance, if a physician doesn’t want to be easily located he can login into the hospital information system sharing only her role as a physician, and not her identity. In this case, she might not be able to access the records of her patients, but still be able to access services such as the hospital’s digital library. Similarly, users should be able to control the precision with which their location is made available to others, based on contextual variables such as the identity of the receiver. In the above examples, the physician requests the level of privacy he expects when joining the ubiquitous environment and based on contextual information the environment adapts in order to preserve privacy.

In addition, when they’re in these places, they in general, wouldn’t want access to a patient’s medical records. In this case, they would rather have the system know only their general location, for instance the fact that they are in a given floor, or within the hospital. In addition, the right of access and persistence has serious implications in losing control of the information shared with other people an the treatment of the information stored. The interplay of those elements and its values will ensure a certain level of privacy perceived by the user and regulated by the technology. Design principles to built privacy-aware computing As a result of our analysis we identified the main privacy issues faced by hospital workers using ubicomp technology. We have grouped them into three main areas.

Quality of Privacy (QoP) A similar trade-off is presented between the services offered by a ubiquitous environment and the cost that the users’ might need to pay in regard to privacy. Similarly, privacy can be considered at two levels: the qualitative perception of the user and the quantitative parameters managed by the technology. To address this we introduce the concept of Quality of Privacy (QoP) following the analogy with Quality of Service (QoS), a concept used in computer networks. We characterize the level of QoP based on five contextual elements: location, identity, activity, access and persistence as discussed in section 2. Based on this, a user can demand a certain level of QoP to the ubiquitous environment using a qualitative measure (i.e., logging into the system as an anonymous user). On the other hand, the perception of anonymity will be mapped by the system to certain values of one or more contextual elements. In this case, the ubiquitous application must adapt its behavior considering the user’s context in order to satisfy the level of QoP, that both, the application and the user have agreed upon.

Sharing. This includes risks related to loosing control over the information and devices shared with other people. We propose in Scenario 3 that physicians can store in their PDA the discussion of a clinical case. In this case the owner of the information can loose control over the files exchanged between colleagues. Although hospital workers were not concerned with sharing information at the moment when the exchange takes place, they were not foreseeing future uses of this information. In the same direction, when hospital workers share devices, like their PDA, the owner loses control over the device and the information contained in it. They might not predict that his colleague can browse his personal information until it happens. Sensing. Related to the invisibleness of the ubiquitous environment there are concerns when the technology monitors the user’s context. Through the use of the floor map presented in scenario 3 and 4 the hospital workers’ expressed anxiety about not knowing how the system becomes aware of their location and if the system can monitor them anywhere at anytime, for example when they are in the bathroom. They start to wonder what information is being monitored and if they will notice it. For example, a medical intern commented: “This sensor only monitors my location? Nobody can here my conversation through it, right?”. In addition, the information captured must be the minimum necessary.

To cope with both, the user and technology views, of QoP; we’re designing an ontology which uses the Event-Condition-Action (ECA) model reported in [14]. This ontology will manage the level of QoP demanded from the user and it will depend on contextual variables and the degree of privacy desired while using the ubicomp application. On the other hand, the information that the user is willing to share with the system determines the services the environment is willing to provide her. For example, a contexaware hospital application can control the identity by roles or the location by rooms. But, a context-aware tour guide might want to manage this information differently. In this case, it might be better to use age groups for the identity and geographic position for location.

Storing. This is related to the treatment of the information that is stored once captured. Through our study we found that the content of the information, where it is stored, and the fact that it is persistent are highly relevant variables to manage privacy. We describe in Scenario 4 how a supervisor can evaluate if a procedure was made by accessing the activities that the interns performed during their work day. Although the people interviewed were not very concerned of colleagues knowing their location in real-time, they were not foreseeing that this information might be

Towards an architecture for privacy-aware computing Privacy-aware mechanisms must be triggered when the information is captured [7], as well as when the information is

3

being requested [10]. This has suggested us to regulate privacy both in the side of the user (client) as well as in that of the environment (server). Figure 2 shows our proposed agent-based architecture for privacy-aware computing, that extends the SALSA framework reported in [13].

information he decides to consult a patient’s medical record. The system at this point knows Dr. Díaz as a physician. Taking this into consideration the system allows Dr. Díaz to consult part of the patient’s medical record. Dr. Díaz decides to print the patient’s medical record and he sends his request to the application. The context-aware privacy s-filter compares Dr. Diaz’ QoP with the policies announced by the agent that represents the printer. Because, the printer agent needs to know his identity (a higher level of QoP) to provide this service, Dr. Diaz’ request is rejected asking them to renegotiate his QoP.

In this architecture, a broker handles the communication between all services using an extension of the agent communication language, itself based on the Extensible Messaging and Presence Protocol XMPP which incorporates the ECA model to preserve users’ privacy. This protocol includes privacy related information based on the ontology discus above, in order to manage QoP provisions. A Context-aware filter running on the client (c-filter) allows the user to set his preferred level of QoP. In this case, when the user joins the ubicomp environment, or the user’s context changes, the desired level of QoP is negotiated between the user and the broker. Similarly, when an application requires information about the user, a context-aware filter in the server (sfilter) negotiates the QoP set by the user and shares this information with the client’s applications maintaining the QoP set by the user. Middleware SALSA

Context-aware privacy C-FILTER

Context-aware privacy S-FILTER

Tailoring

Policlicing

Negotiation

Monitoring

Figure 3. The sequence diagram illustrates the negotiation of QoP to use a service provided by the ubicomp application. The doctor uses the PDA to negotiate their desired QoP (a) and to be aware of the availability and location of users given a certain level of QoP (b, c).

User & Service provider policies

CONCLUSIONS Over the last few years research has been conducted towards the design of ubicomp solutions in support of hospital work. Through the design and evaluation of those solutions several privacy issues have been pointed out as a critical factor for their adoption. To explore these issues we conducted a workplace study in a hospital. We identified the contextual variables that influence the user’s perception of privacy and how they deal with it. We introduce the concept of Quality of Privacy (QoP) which can be used to develop privacy-aware computing systems that balance the trade-off between the amounts of privacy a user is willing to concede and the value of the services that can be provided by the application. We describe an architecture that considers the users’ context to satisfy the level of QoP that both, the application and the user have agreed upon. Finally, we exemplified our proposal extending a context-aware mobile communication system.

Agent Broker: IM&P Server

Figure 2. An architecture for privacy-aware computing

A sample application To illustrate how our architecture can be used in the design of privacy-aware applications we re-designed a context-aware mobile communication system (CHIS) reported in [9]. The architecture of CHIS was extended to deal with privacy allowing the users to negotiate a level of QoP and adapting ubicomp applications and services behavior. To exemplify this consider the following scenario. Dr. Díaz wants to study with more detail the evolution of a patient who presents a rare combination of symptoms. In this case, he wants to print the patient’s medical record to study it in detail later on, and probably discuss it with a colleague. At the same time, since he is out of duty, during the use of the ubicomp environment he wants to protect his privacy. Figure 3 illustrates how the system’s components interact to support this scenario.

As we argued, contextual information is required to regulate privacy for ubicomp, and additional time and efforts are required to find proper solutions. During the workshop, we would like to receive feedback as to how our proposals could be improved from the results others are doing in this area. Also we want to present how the results of our study can be applied in the design of ubicomp managing privacy. For this, we want to show the scenarios in more detail, as well as, particular ubicomp services for hospitals that we’ve re-designed to address privacy concerns. In addition, we want to corroborate if the contextual information that we identified so far, make sense in other settings; and, we want to know if other researchers are interested in incorporating some of our ideas in their work. Finally, we want to discuss if our work is useful and still hold in other settings besides hospitals.

While Dr. Díaz joins the ubicomp environment he chooses a level of privacy setting the privacy-bar to medium as Figure 3a shows. The context-aware privacy c-filter receives this information and adapts the information of the user based on the privacy ontology for the system. This agent sends the user’s presence to the broker specifying the contract between the ubicomp environment and the user as a certain level of QoP. The agent broker notifies all users and agents in the environment. They update the information related to Dr. Díaz in order to preserve his privacy, adapting the information shown by the list of users presenting only his role (figure 3b) and the floor map lowers the precision with which his position is shown (figure 3c). After Dr. Díaz visualizes the

4

REFERENCES 1. Adams, A. Multimedia Information Changes the Whole Privacy Ballgame. in Conference on Computers, Freedom, and Privacy,. 2000. 2. Bardram, J. Applications of ContextAware Computing in Hospital Work - Examples and Design Principles. 2004: ACM Press, 2004. 3. Bardram, J.E. and C. Bossen. Moving to get aHead: Local Mobility and Collaborative Work. 2003: Kluwer Academic Publishers. 4. Brown, P.J. and J.F. Gareth, 2004., Context-awareness and privacy: an inevitable clash?, in Technical Report. Department of Computer Science, E. 4PT, Editor. 2004, University of Exeter: Exter, United Kingdom. 5. Caroll, J., Scenario-Based Design: Envisioning work and technology in system development, ed. J.W. Sons. 1995, New York. 6. Hong, J.I. and J.A. Landay. An Architecture for PrivacySensitive Ubiquitous Computing. in MobiSys. 2004: ACM Press. 7. Langheinrich, M. A Privacy Awareness System for Ubiquitous Computing Environments. in Ubicomp 2002. 2002: SpringerVerlag. 8. Lederer, S., Designing Disclosure:Interactive Personal Privacy at the Dawn of Ubiquitous Computing, in Computer Science Division. 2003, University of California: Berkeley, California. p. 196. 9. Munoz, M.A., M. Rodriguez, J. Favela, A.I. Martinez-Garcia, and V.M. Gonzalez, Context-Aware Mobile Communication in Hospitals. IEEE Computer, 2003. 36(8): p. 38-46. 10. Myles, G., A. Friday, and N. Davies, Preserving Privacy in Environments with Location-Based Applications. IEEE Pervasive computer, 2003. 2(1): p. 56-64. 11. Palen, L. and P. Dourish. Unpacking 'privacy' for a networked world. in ACM Press. 2003. 12. Reang, P., Dozens of nurses in Castro Valley balk at wearing locators, in The Mercury News. 2002. 13. Rodriguez, M., J. Favela, A. Preciado, and A. Vizcaino, Agentbased Ambient Intelligence for Healthcare. Accepted for publication in AI Communications, 2005. 14. Tentori, M., J. Favela, and V. González, Designing for Privacy in Ubiquitous Computing Environments. Accepted for publication in Proc. of the Ubiquitous Computing and Ambient Intelligence, 2005. 15. Weiser, M., The future of ubiquitous computing on campus. Communications of the ACM., 1998. 1: p. 41-42.

research involves using qualitative ethnographic methods to evaluate media-rich/activity-rich environments, the adoption of information-visualization systems, and the use of home information technologies. He received an MS in information and computer science from UC Irvine and an MSc in telecommunication and information systems from the University of Essex, UK. Marcela Rodríguez is a doctoral student in computer science at CICESE and a lecturer in computer engineering at the Autonomous University of Baja California (UABC). Her research interests include ubiquitous computing, autonomous agents, and CSCW. She received an MSc in computer science from CICESE and a BSc in computer engineering from UABC.

THE AUTHORS Mónica Tentori is a graduate student in computer science at the Center of Scientific Research and Higher Education of Ensenada (CICESE), where her research focus is on medical informatics, ubiquitous computing, and human computer interaction(HCI). She received a BSc in computer sciences from the Universidad Autonoma de Baja California (UABC). Jesus Favela is a professor of computer science at CICESE, where he leads the Collaborative Systems Laboratory and heads the Department of Computer Science. His research interests include CSCW, ubiquitous computing, and information retrieval. Favela received a PhD in computer-aided engineering from the Massachusetts Institute of Technology. Victor M. González is a doctoral student in information and computer science at the University of California, Irvine. His

5