Go home now Header Background Image
Search
Submission Procedure
share: |
 
Follow us
 
 
 
 
Volume 12 / Issue 3 / Abstract

available in:   PDF (213 kB) PS (399 kB)
 
get:  
Similar Docs BibTeX   Write a comment
  
get:  
Links into Future
 
DOI:   10.3217/jucs-012-03-0252

Quality of Privacy (QoP) for the Design of Ubiquitous Healthcare Applications

Mónica Tentori, Jesús Favela
(Department of Computer Science, CICESE, Ensenada, B.C. México
{mtentori, favela}@cicese.mx)

Victor M. González
(Department of Informatics, University of California at Irvine, USA
vmgyg@ics.uci.edu)

Abstract: Privacy is a complex social process that will persist in one form or another as a fundamental feature of the substrate into which ubiquitous computing (ubicomp) is threaded. Hospitals are natural candidates for the deployment of ubicomp technology while at the same time face significant privacy requirements. 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 its interplay shapes the perception of privacy in a hospital. The results indicate that hospital workers tend to manage privacy by assessing the value of the services provided by a ubicomp application and the amount of privacy they are willing to concede. For ubicomp applications to better deal with this issue we introduce the concept of Quality of Privacy (QoP) which allows balancing this trade-off in a similar way as that of Quality of Service (QoS) does for networking applications. We propose an architecture that allows designers to identify different levels of QoP based on the user's context. Finally, we identify the main privacy risks of a location-aware application and we extend its architecture exemplifying the use of QoP to manage those risks.

Keywords: quality of Privacy, ubiquitous computing, privacy-aware computing, ubiquitous healthcare

Categories: H.5.2, K.4.1

1 Introduction

Ubiquitous computing will surround users with a comfortable and convenient information environment that merges physical and computational infrastructures into an integrated habitat [25]. 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. Thus, the more an application is aware of the user's context, the better it can adapt itself to assist him. Paradoxically, the more an application knows the user the greater the threat to his privacy [6]. Consequently, the use of ubiquitous computing brings some risks, being the potential invasion of privacy among the most important ones.

Because user's demands and expectation for privacy are context dependent, [5; 17], we decided to base our efforts on understanding the contextual variables that shape the perception of privacy in a particular setting: hospital work. Although previous studies have addressed the impact of privacy in ubicomp, hospitals are of particular interest because they are appropriate settings for the deployment of this technology [3], while, at the same time, raising important issues related to privacy.

Page 252

Our work is framed within other efforts aiming to design and deploy ubicomp solutions supporting hospital work [7; 14]. These efforts are a step forward in the direction of providing accurate and timely information to hospital staff in support of adequate decision-making [7; 15]. Despite the benefits of ubicomp in healthcare envisioned by those applications and the fact that the importance of privacy has been highlighted, there have been fewer 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. 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 [8].

Despite this, design of ubiquitous systems for hospital settings have, in general, overlooked privacy issues, because of this, cases of users' distrust and abandonment of potentially useful ubiquitous applications in a hospital have been reported [21]. For instance, by being invisible, these technologies facilitate the collection and use of information about individuals without their knowledge. Thus, a cost, in the form of privacy, might need to be paid to benefit from ubicomp. The risks are high: even a few privacy violations could lead to user distrust and abandonment of ubicomp and to lost opportunities to use the technology to improve their activities [9].A clear example of users' distrust and abandonment of potentially useful ubiquitous applications in a hospital is the nurses' rejection to use of a location-estimation system in the medical center of Castro Valley, California [18].

Based on this, we want to explore the contextual variables that shape hospital workers' perception of privacy. The understanding of how people react to privacy threats will help us identify the contextual variables that influence end-user's privacy needs and propose mechanisms to adequately manage them by incorporating privacy concerns in the design of ubicomp.

The rest of the paper is organizes as follows: We first present in section 2 the results of a case study conducted to identify the contextual information which shapes hospital workers' perception of privacy, discussing how this perception in their everyday practices is affected with the introduction of ubicomp technologies. In Section 3, we present the use of Quality of Privacy and an architecture to manage QoP in ubicomp. Section 4 illustrates the use of our architecture by extending a location-aware application. In Section 5 we discuss previous research related to privacy in ubicomp, and how it compares to our work. Finally, Section 6 presents our conclusions and directions for future work.

2 A case study in hospital work

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, a workshop evaluation helped us understand how hospital worker's 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 [24].

Page 253

2.1 Methodology

The study at the hospital started with a period of systematic observations where we shadowed three medical interns, two nurses, and two physicians throughout their morning, afternoon, and night shifts. Each person was observed for a period of three working days. 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 other where the use of ubicomp is considered We conducted ten interviews with five hospital workers and discussed typical scenarios of usage with them, to get a sense of whether they found the proposed ubicomp systems supporting their work and if the scenarios made apparent privacy concerns. As a result of those interviews we derived a new set of 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 the ubicomp application supporting medical work and its impact on the privacy of those using it.

We presented the four scenarios to 27 medical interns in a workshop evaluation. 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.

2.2 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 medical personnel often act with little concern for privacy in order to cope with specific circumstances or 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 move these documents to other areas to facilitate the study of a case. This situation is generally with the knowledge and even the encouragement of attending physicians as they see it as a way for interns to take full responsibility of a case and to help them improve their decision making.

2.3 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. Table 1 indicates the different ubicomp services that were included in each of the four scenarios we selected.

Page 254

Table 1: Ubicomp services used in the grounded-scenarios

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 scenarios 3 and 4 to illustrate some of the technology proposed for, and privacy issues raised by, the scenarios.

2.3.1 Scenario 3: Physicians Collaborating through Heterogeneous Devices

While Dr. Garcia is evaluating the patient in bed 234, her PDA alerts her that a new message has arrived. Her handheld displays a hospital floor map indicating her that the X-ray results of patient in bed 225 are available. Before Dr. Garcia visits this patient, she approaches the nearest public display that detects the physician' s presence and provides her with a personalized view of the Hospital Information System. In particular, it shows a personalized calendar application and a floor map highlighting recent additions to clinical records of patients she is in charge of, messages addressed to her, and the services most relevant to her current work activities. While she is analyzing the information, she notices in the map, that Dr. Díaz, the traumatologist assigned to this patient, is walking down the corridor in the next floor. By selecting the icon representing Dr. Díaz she can invite him to join a collaborative session. Dr. Díaz receives a message indicating that the cardiologist would like to discuss a case with him and specifying the location of the nearest display available where he can visualize information related to the case. He accepts the invitation and moves to the nearest display. When the display recognizes his presence it shares the running applications like the floor map, the calendar, and the instant messenger with Dr. García. Dr. García display from his PDA information relevant to the case. Both doctors decide to record the discussion to store it for later reference.

Page 255

They can now browse the patient's medical record and analyze the X-ray image to make the clinical decision. As Dr. Díaz is interested in analyzing the treatment more carefully, he decides to store the taped discussion in his PDA to consult it later.

This scenario has a few privacy implications since the physicians are aware of each other's location and availability, also, one of them is using a large display in a semi-public area with sensitive information, and the clinical discussion is being stored. On the other hand, the scenario illustrates how the technology can address the actual need for collaboration in clinical decision making.

2.3.2 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. Then a window showing a map of the area pops-up. The window includes a widget that represents a Timeline and can be used to scroll through time with the map in the window displaying the location of the intern (see Figure 1). The map shows that the intern entered room 239 and spent a few minutes there. 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 the procedure was made. Trough the timeline Mrs. Diaz notices that the intern entered the Internal Medicine office. Trough the photographs displayed, she realizes that the intern 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 throughout the day she realizes that the procedure wasn't made, and assigns it to another intern.

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

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.

Page 256

We included such scenario because it was considered useful by hospital staff' who actually supervise the interns' activities. A head nurse made the following comment during an interview when a preliminary version of 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 at first concerned of their colleagues being aware of their current location, they were not foreseeing the privacy risks raised by the capture of this information and its potential use to track their location for a period of time and infer their activities as illustrated in the scenario.

2.4 Contextual information

Two sets of contextual information were identified differing in the role they play in preserving privacy. The first set is defined as contextual elements. This refers to the parameters that the user wants to protect while using a ubicomp environment and they are perceived qualitatively. These parameters can be regulated at different levels by the technology satisfying the need for privacy as perceived by the user. On the other hand, we identified the contextual variables that prompt the user to protect his privacy while using a ubicomp application. We define the contextual variables as triggers that will condition the need for privacy using a ubicomp application. The interplay of those elements will ensure a certain level of privacy perceived by the user and regulated by the technology.

In accordance with previous studies [14], location, identity, and time are important factors in assessing privacy concerns. Similar results were obtained in our own study. For example, related to the location, a medical intern made the following comment during an interview: "… 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 concerned 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 haven't because I was in my lunch break" In this case, for instance, 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. In addition, when they're in these places, they in general, wouldn't require 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 to these variables, we found activity, access, and persistence as being highly relevant context when assessing privacy risks.

Based on our findings we propose that a ubicomp application should take into account contextual information to adapt its behavior in order to preserve end-user privacy. Our aim with this is to help designers and users support a spectrum of trust levels and privacy needs in order to create privacy aware applications for ubicomp.

3 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 she can login into the hospital information system sharing only her role as a physician, and not her identity.

Page 257

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. For instance, a physician can choose to share his detailed location with fellow doctors, but other staff, medical interns, for instance, will only know if he is in the same floor or in the hospital. 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. To define and manage, at the users and system level, the amount of privacy one is willing to concede, we introduce the concept of Quality of Privacy (QoP). This comes from an analogy with that of Quality of Service (QoS), well known in computer networks [12].

3.1 Quality of Privacy (QoP)

Quality of Service (QoS) is a broad term used to describe the overall experience a user or application will receive over a network [13]. For example, suppose that two physicians are discussing an X-ray image of a patient trough video conferencing. In this case, the network has to provide high quality video showing both the X-ray image and the video of the physicians. If network congestion is experienced the quality of the services might be degraded. In that case the network would implement a QoS setting that for instance, would reduce the quality of the video but will preserve the X-ray image quality as much as possible. Quality of Service is implemented by allowing the user to demand a specific performance from the network in order to reserve resources for certain services. In the example, the physicians might want to preserve the quality of the X-ray image over that of the video, so the users can demand certain QoS to the application. In this case the users' needs are expressed qualitatively, based on their perception (i.e. high, medium or low quality). For instance, in case of congestion they might specific a QoS that set a low quality of the video. On the other hand, the network uses parameters that are expressed quantitatively, such as bandwidth or jitter.

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 cope with this we introduce the concept of Quality of Privacy (QoP) following the analogy with QoS. We characterize the level of QoP based on five contextual elements which we 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 one 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. The level of QoP demanded from the user will depend on contextual variables and the degree of privacy desired while using the ubiquitous 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.

Page 258

Consequently, to represent different levels of QoP and manage user and technology views of QoP we designed an ontology in which the values associated to each contextual element will depend on the application's logic and the nature of the ubiquitous environment.

3.2 An ontology to manage QoP

The ontology allows us to balance the privacy trade-off enforcing privacy conditions demanded by users and enforced by the ubicomp environment. This ontology uses the Event-Condition-Action (ECA) model [14]. We use XML to express privacy configurations based on this ontology. The ontology we designed includes three components: (1) an event describing the need to execute an action, and it is characterized by the five contextual variables: location, identity, time, activity and artifacts, which change dynamically while the user's context varies; (2) a condition defining rules that must be enforced to determine which action might need to be executed and; (3) an action containing a set of functions that may be executed to enforce or relax privacy policies. In this case the actions might be executed interactively, when a user explicitly executes an action; or passively, when the environment reacts based the user's context.

Table 2 shows an example of an ontology used to regulate QoP. It shows, how the level of detail of the information shared decreases as the QoP increases. This example shows the values corresponding to the design of a context-aware hospital application. Similarly, a context-aware tour guide won't need to define the identity by roles or the location by rooms, In this case it might be better to use age groups for the identity and geographic position for location.

Location Identity Access Activity Persistance
X, Y position Name Free Available Indefinite
Room Role With confirmation Busy Months
Floor Anonymous Denied Unavailable Days

Table 2: Contextual elements to regulate privacy using a certain level of QoP

3.3 An architecture for privacy-aware computing

Privacy mechanisms must be triggered when the information is captured [11], as well as when the information is being requested [16]. 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 agent-based framework reported in [22].

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

Page 259

Similarly, when an application requires information about the user, a context-aware filter in the server (s-filter) negotiates the QoP set by the user and shares this information with the client's applications maintaining the QoP set by the user.

Figure 2: An architecture for privacy-aware computing

3.3.1 Broker

An Agent Broker handles communication between agents, which represent users, services and devices. Information is communicated through XML messages. To implement this service we have used the Jabber open-source instant messaging server (www.jabber.org) and extended its Extensible Messaging and Presence Protocol XMPP. This server also stores the state of people and agents and notifies their changes to other agents subscribed to them.

3.3.2 Context-aware privacy c-filter

This agent controls the information shared by the user with the ubicomp environment acting as a filter between the user and the broker. It uses a module negotiation which allows reaching an agreed level of QoP between the user and the ubicomp environment. For example, if a user decides to join the ubicomp environment with certain level of QoP this filter adapts the user's information to be shared with the broker. In addition, after the negotiation, this agent must inform the result of the contract to the broker.

3.3.3 Context-aware privacy s-filter

This agent controls the information shared by the broker and the other agents who represent users, services and devices, respecting the level of QoP demanded by the user and the policies specified by the agents. Each time an agent requires information of the users connected to the system, this filter evaluates the need of privacy and based on this evaluation decides to admit or reject the request.

Page 260

If the request is accepted users' policies must be applied adapting the users' information. Four modules compose this agent. The monitoring module monitors the contextual elements to determine the level of QoP desired at a certain moment. After some conditions are met the policing module ensures that all parties adhere to the level of QoP. Through the user and services repository the policing module obtains the policies specified by the user and compares then with the requested information. After that, the users' information used by the ubiquitous environment is updated in the access behavior repository. Finally, the tailoring module adapts the information in order to preserve the level of QoP demanded.

3.3.4 A protocol to deal with privacy

The SALSA development framework provides an expressive language that enables the exchange of different kinds of objects between agents (such as actions, perceived information, or simple messages), between agents and users (such as the user's profile and events generated by the user's actions), and between agents and services (such as the service's state). These objects are encoded using XML (eXtensible Markup Language). Thus, SALSA provides developers an API that facilitates the composition, sending, and receiving of messages between agents. We extend this protocol with mechanisms that allow programmers to specify the ontology to manage privacy depending on the nature of the application. For instance, the method sendXMLcommand(xmlContent, agentID) is used by an agent to request another agent to execute a specific action. When it is invoked, the method will form an XML message by adding the tags that specify the kind of message and to whom it is addressed as illustrated in Figure 3.

Figure 3: XML message sent by the privacy s-filter agent to a user agent, requesting the adaptation of the information preserving a desire QoP

Page 261

The message incorporates the event/condition/action paradigm to preserve users' privacy. Then, it will add the content of the message which is contained in xmlContent. This variable specifies the action or method to be executed by the agentID.

4 The Location-aware Migration Component

To illustrate how the proposed architecture can be used in the design of privacy-aware applications we re-designed a location-aware migration component reported in [2]. This component allows users to seamlessly transfer information to any device in the vicinity, such as a PDA, a PC or a public display, from a handheld computer. To provide this functionality we designed and implemented a migration component that allows the transfer of information between diverse heterogeneous devices. The information to be transferred includes digital files and URLs, while the source and target devices could include PDAs, PCs and public displays. The command is activated from the file system by using a selection in the option menu that is visualized with the right-click. In the PDA the user needs to hold the stylus for a few seconds over the file he wants to transfer, for the option to appear. In figure 4, we can observe the result of such action. The file transfer component can also be triggered from another application that whishes to invoke this service. For instance, URL's can be transferred by directly clicking on the URL in the Web browser and selecting the device to which the information will be transferred.

Figure 4: Screen that illustrates the selection of the file to be transfer from the PDA

Once the options menu appears, the user needs to select the Transfer To... option. When selecting this option, the list of devices present in the vicinity is displayed. These are the possible target devices to which the information can be transferred. The information migration takes place when the user chooses the target device. Once the information has been transferred, a notification is sent to the source device and the file is opened by an application in the target device, according to its filetype.

Page 262

Privacy is an important issue in the use of large public displays [23]. For this reason we placed special emphasis on protecting the users' privacy by allowing the control of the information and providing feedback about how it's used [5]. Within the context of this application, we identified that the persistence of the information, the identity of the sender and how the information is displayed must be managed to protect privacy. For example, during a meeting, a user might need to transfer a document from his PDA to a public display. In this case, he would like to share the information with the participants until the meeting ends and he might not want to automatically display the information for privacy concerns. For this, when a user transfers information to a public display he will expect the system to erase his information once the meeting is finished. In our approach, the system allows the users to specify privacy policies to manage the persistence of the information shared and how the information will be displayed. In addition of these policies, the system provides feedback informing the privileges that a particular file/url has. For instance, the privacy bar can show how much time the file can be displayed or stored. In both cases, the user could be able to change their policies based on his needs.

Also, because presence is privacy-sensitive information, the protocol for presence information must be able to protect the data from possible threats, such as eavesdropping, corruption, tamper and replay attacks. To protect the communication confidentiality we used the methods proposed in [20], which enable the sender to sign and/or encrypt an instant message sent to a specific recipient, sign and/or encrypt presence information that is directed to a specific user, and sign and/or encrypt any arbitrary message directed to a specific user. To achieve this, our clients must manage Stanza Security ensuring confidentiality and integrity of transmitted XMPP stanzas between endpoints according to [10]. To do this, a payload XML structure is created, which contains the full stanza to be secured, into OpenPGP [19] format. An example of a paylod signed presence stanza is illustrated in Figure 5.

<presence to='map-a@server_jabber' from='pd-a@server_jabber'>
  <status>Online</status>
  <x xmlns='x:QoP' QoP='id'/>
  <x xmlns='jabber:x:signed'>    
        QA/AwUBOjU5dnol3d88qZ77EQI2JACfRngLJ045brNnaCX78ykKNUZaTIoA
        oPHI2uJxPMGR73EBIvEpcv0LRSy+=45f8
  </x>
</presence>

Figure 5: A signed presence stanza

Figure 6 shows the elements of the migration component, which include the source device, the target device, the resource to be sent and, the component that carries out the transfer of the information and, if required, adapts the information based on the nature of the target device. The component is implemented with four agents. The Source Proxy agent represents the information to be transferred by the user to another device. Besides, it includes the mechanisms required to transfer the information, as well as the permissions granted by the source device to the information being sent.

Page 263

The Information Adaptation agent adjusts the information based on the characteristics of the target device and the specifications defined by the source device. In this case, for instance, medical images being moved to a PDA might be reduced in size before being transferred. Finally, the Target Proxy agent represents: characteristics (capabilities, type of applications, etc.) of the device that receives the information; the device itself which will decide whether to accept or reject the transfer request; and the actions to be performed with the information received, which could include, storing or opening the file with a specific application.

Figure 6: Architecture of the location-aware migration component preserving the user's privacy conditions

In order to preserve privacy we add a layer between the broker and the migration component. The additions to the architecture are included in two proxies' nodes which represent the filters in the server and client side discussed in Section 3. Each one includes one new agent component that communicates with each other and with other components through the Agent Broker. This has allowed for a seamless integration of the new components, since only minor modifications were required to other components. The context-aware privacy c-client acts as a proxy between the user and the ubicomp environment. It incorporates an interface to adequately manage the negotiation of privacy. And the context-aware privacy s-agent acts as a proxy between users and agents in the environment and the broker. All information requests for a service in the ubicomp environment go trough this agent, which monitors the environment to determine whether conditions are such that the system must adapt its behavior in order to preserve privacy. It makes use of a users and provider policies repository to maintain the privacy configuration specified by the users or services.

Page 264

4.1 Sample application

Figure 7 illustrates how the system's components interact to support the following scenario.

Figure 7: The sequence diagram illustrates the negotiation of QoP to use a service provided by the ubicomp application

Everyday, at the internal medicine office, the medical interns meet with the attending physician to discuss the status of their patients. They help each other by discussing the diagnosis as well as future treatments for the patients.

Page 265

The physicians decide to discuss the case of the patient in bed 226 who is not responding to treatment as expected. They present on the public display the information related to the patient, such as X-Ray results and the medical record.

During the meeting the physicians might want to share articles, working papers, presentations and different kind of documents relevant to the discussion. In this case, the physicians might need to protect the privacy of the information shared by controlling the persistence and the way in which it is displayed. While the physicians discuss the case of the patient in bed 226, Dr. Garcia, the attending physician, wants to display a recent article he considers relevant to the current discussion. Using the migration component, Dr. García selects the article that he wants to share with the group but he wants to keep it public only during the meeting and he doesn't want to involuntarily display the article. In this case, he chooses a certain level of QoP specifying the time of persistence and the display mode. 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 to all the devices in the vicinity and those that agree with such conditions are displayed on Dr. Garcia' PDA. By selecting the icon that represents the public display, Dr. Garcia decides to transfer the article from his PDA to the public display. The context-aware privacy s-filter compares Dr. Garcia' QoP with the policies announced by the agents that represent the devices in the vicinity. In this case, the public display accepts the QoP demanded by the user and doesn't display automatically the article.

5 Related work discussion

Privacy has been identified as an important issue in the ubicomp literature. Most of the work in this area has focused on field studies aimed at better understanding the privacy issues faced by ubicomp users, and providing frameworks and design proposals to address the risks of privacy raised by ubicomp technologies.

Adams [1], conducted an empirical investigation into the individual's perception of privacy in environments outfitted with audio/video capture equipment. She found that the subjects' perceptions of privacy in these environments depend on the interrelation of the identity, the information receiver and the use given to that information, as well as its sensitivity. In addition to these variables, we found the content of the information, the location of its storage, and its persistence as being highly relevant. On the other hand, information privacy is not the only issue which needs to be protected; we found that the activity of the information's owner is also significant. Thus, privacy can be managed if we attend to the context in which the entities interact, and in particular pay attention to the contextual variables found to be of major concern to the users.

The Principle of Minimum Asymmetry introduced by Jiang et al. seeks to minimize the imbalance between the people about whom information is being collected, and the systems and people that collect and use that information [9]. In our study we obtained evidence of this asymmetry in the hospital setting and that this asymmetry is more evident in hierarchical relations, as the one between medical interns and their supervisors.

Page 266

Beckwith [4] reports on an ethnographic study he conducted in an eldercare facility with a sensor-rich environment that monitors the locations and activities of residents and staff. A key finding was that different stakeholders can have drastically different perceptions of the invasiveness of a technology, its potential for abuse, and even its purpose. In this case the design of the system must be flexible enough to support different perceptions. Even though that study was made in a hospital environment it was not focused on the practices of hospital workers'; in addition, it only evaluated the perception on privacy related to the ubicomp services available in the specific environment where the study took place. Our study explores different services proposed in ubicomp and deals with how hospital workers' perception of privacy during their everyday practices changes with the introduction of ubicomp technologies in such environment.

The privacy awareness system (pawS) for ubiquitous computing environments allows data collectors to both announce and implement data usage policies, as well as providing data subjects with technical means to keep track of their personal information as it is stored, used, and possibly removed from the system [12]. The limitation of the pawS' approach is that the privacy protection is only managed when the capturing is taking place, once the information is shared with the system the user's only can track its use. Meanwhile, Myles et. al. [16] developed a system that gives users fine-grained control over the release of their location information. This system protects the information shared, once an application has requested it. In this case validators determine whether the information requested can be released and, if so, whether it should impose any special constraints (such as reducing the accuracy of the locatio's data). In this case the information is protected once it is in the system, so, in contrast with pawS information which a user's hasn't agreed to share is stored and managed. In our design we consider both issues, by adding filters in both sides in which the information is managed (on the client as well on the server). Thus, we guarantee that the user shares the minimum of information necessary, as well as how it is shared.

6 Conclusions

In this paper, we propose mechanisms to deal with privacy in ubiquitous computing environments. Our efforts include a workplace study conducted in a hospital to identify the contextual variables and its role in privacy management. Based on how hospital workers use context to shape their privacy, we inform how an adequate management of contextual information will allow designers to deal with privacy concerns in the design of ubicomp. To cope with this, 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 amount of privacy a user is willing to concede and the value of the services that can be provided by the application, in a similar fashion as Quality of Service (QoS) does in computer networking. 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. We exemplified our proposal extending a location-aware migration component which presented several privacy risks that were addressed during its re-design.

Page 267

We plan to analyze the privacy implication in several ubicomp services and apply the concept of QoP to cope with the risks identified. Furthermore, we want to improve our proposals to help designers reduce the privacy trade-off. Finally, we plan to deploy a privacy application at hospital to explore the implications of using privacy-aware tools in everyday work.

Acknowledments

We thank the personnel at IMSS General Hospital, in particular Simitrio Rojas and Julia Mora and to Professor Marcela Rodriguez who provided helpful comments on this work. This work was funded by UCMEXUS under contracts Conacyt-CN-02-60 and Conacyt-U- 40799, and through scholarships provided to Victor M. González, and Mónica Tentori.

References

[1] Adams, A. 2000. "Multimedia Information Changes the Whole Privacy Ballgame". In Proc. of the Computer, Fredom and Privacy. Toronto, Ontario Abril 4-7, 2000 ACM Press. pp. 1-8.

[2] Amaya, I., J. Favela, and M. Rodriguez. 2005. "Componentes de software para el desarrollo de ambientes de cómputo ubicuo". In Proc. of the Ubiquitous Computing and Ambient Intelligence. Granada, Spain September, 14-16 Editorial Thompson. pp. 173-180.

[3] Bardram, J. 2004. "Applications of ContextAware Computing in Hospital Work - Examples and Design Principles". In Proc. of the ACM Symp. on Applied Computing. Nicosia, Cyprus March, 14-17 ACM Press. pp. 1574-1579.

[4] Beckwith, R. 2004 "Designing for Ubiquity: The Perception of Privacy." IEEE Pervasive. 2(2): 40-46.

[5] Bellotti, V. and A. Sellen. 1993. "Design for Privacy in Ubiquitous Computing Environments". In Proc. of the European Conference of Computer Supported Cooperative Work. Milan, Italy September, 13-17 Kluwer Academic Publishers. pp. 77-92.

[6] Brown, P.J. and J.F. Gareth. Context-awareness and privacy: an inevitable clash?, in Department of Computer Science. 2004, University of Exeter: Exter, United Kingdom. p. 20.

[7] Collins, J. 2004 "RFID Cabinet Manages Medicine". RFID Journal. 1081(1): 10-22.

[8] Hong, J.I. and J.A. Landay. 2004. "An Architecture for Privacy-Sensitive Ubiquitous Computing". In Proc. of the Mobile Systems, Applications and Services. Boston, Massachusetts Junio 6-9, 2004 ACM SIGCHI. pp. 177 - 189.

[9] Jiang, X. and J.A. Landay. 2004 "Modeling Privacy Control in Context-Aware Systems". In IEEE Pervasing Computing. 1(3): 59-63.

[10] Karneges, J. JEP-01xx: Stanza Security. 1999.

[11] Langheinrich, M. 2001. "Privacy by Design - Principles of Privacy-Aware Ubiquitous Systems". In Proc. of the Ubicomp. Atlanta, GA September,30 - October, 2 Springer-Verlag LNCS. pp. 273-291.

Page 268

[12] Langheinrich, M. 2002. "A Privacy Awareness System for Ubiquitous Computing Environments". In Proc. of the Ubicomp. Göteborg, Sweden Septiembre 29 a Octubre 1, 2002 Springer-Verlag LNCS. p. 8.

[13] Lawrence, T.F. 1999 "Quality of Service (QoS) A Model for Information". IEEE Fourth International Workshop on Object-Oriented Real-Time Dependable Systems. 4(6): 180-183.

[14] Lederer, S., J. Mankoff, and A.K. Dey. 2003. "Who Wants to Know What When? Privacy Preference Determinants in Ubiquitous Computing". In Proc. of the Conference on Human Factors in Computing Systems. Fourt Lauderdale, Florida Abril 5-10, 2003 ACM SIGCHI. pp. 724-725.

[15] Munoz, M.A., M. Rodriguez, J. Favela, A.I. Martinez-Garcia, and V.M. Gonzalez. 2003 "Context-Aware Mobile Communication in Hospitals." IEEE Computer. 36(8): 38-46.

[16] Myles, G., A. Friday, and N. Davies. 2003 "Preserving Privacy in Environments with Location-Based Applications". IEEE Pervasive computer. 2(1): 56-64.

[17] Palen, L. and P. Dourish. 2003. "Unpacking 'privacy' for a networked world." In Proc. of the Conference on Human Factors in Computing Systems. Vienna, Austria April, 24-29. ACM SIGCHI. pp. 129-136.

[18] Reang, P. 2002. "Dozens of nurses in Castro Valley balk at wearing locators". In Proc. of the The Mercury News. San Jose, CA September, 6. p. 4-4.

[19] RFC2440. OpenPGP Message Format. 1998. Available at: http://www.faqs.org/rfcs/rfc2440.html

[20] RFC3923. End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol(XMPP). 2004. Available at: http://www.xmpp.org/specs/rfc3923.html

[21] Rice, K. 2002 "Nurse Tracking Systems: Do the Benefits to Nurse Managers Outweigh Risks to Nurses' Privacy?: Writing for the CON Position." MCN, American Journal of Maternal Child Nursing. 27(2): 73 - 73.

[22] Rodriguez, M., J. Favela, A. Preciado, and A. Vizcaino. 2005 "Agent-based Ambient Intelligence for Healthcare". AI Communications. 18(3): 10-16.

[23] Tan, D.S. and M. Czerwinski. 2003. "Information Voyeurism: Social Impact of Physically Large Displays on Information Privacy". In Proc. of the Conference on Human Factors in Computing Systems. Lauderdale, Florida April, 5-10 ACM SIGCHI. pp. 748-749.

[24] Tentori, M., J. Favela, and V. González. 2005. "Designing for Privacy in Ubiquitous Computing Environments." In Proc. of the Ubiquitous Computing and Ambient Intelligence. Granada, Spain September, 14-16 Editorial Thompson. pp. 27-35.

[25] Weiser, M. 1998 "The future of ubiquitous computing on campus". Communications of the ACM. 1: 41-42.

Page 269