privacy-aware autonomous agents for pervasive healthcare

NOVEMBER/DECEMBER 2006 1541-1672/06/$20.00 © 2006 IEEE 55Published by the IEEE Computer Society

A g e n t s i n H e a l t h c a r e

Privacy-AwareAutonomous Agentsfor PervasiveHealthcareMonica Tentori and Jesus Favela, CICESE

Marcela D. Rodríguez, Autonomous University of Baja California

Hospitals are convenient settings for deploying pervasive computing technology,

but they also raise important privacy concerns. Hospital work imposes significant

demands on staff, including high availability, careful attention to patients, confidential-

ity, rapid response to emergencies, and constant coordination with colleagues. These

demands shape the way hospital workers experienceand understand privacy. In addition, healthcare pro-fessionals experience a high level of mobility be-cause they must collaborate with colleagues andaccess information and artifacts distributed through-out the premises. Hospital workers, therefore, requireubiquitous access to real-time patient data to makecritical-care decisions. Some researchers envision ahospital as a pervasive computing environment thatintegrates hospital information systems into a site inwhich embedded processors, computers, sensors,and digital communications are inexpensive, ubiq-uitous commodities.1

Through context awareness, such an environmentcan tailor itself to user preferences and perform tasksaccording to the physical space’s nature. Moreover,the more knowledge an application has of each userand his or her context, the better it can adapt itself toassist that user. Paradoxically, the more an applica-tion knows the user, the greater the threat to thatuser’s privacy.2 Nevertheless, the design of perva-sive applications for hospitals has generally over-looked privacy issues. The problem is that develop-ers have little support for designing software andcreating interactions that can truly help users managetheir privacy.

The privacy a user demands and expects is con-text dependent,3 based on the environment’s re-quirements, persisting as a fundamental feature ofthe substrate into which pervasive computing isthreaded. By using the capabilities of autonomousagents, designers can create privacy-aware appli-cations in a scalable, context-reactive, and flexiblemanner. Scalability here means supporting the in-corporation of new agents with their own privacypolicies into the system. Context reactivity meansallowing the adaptation of a pervasive applicationon the basis of dynamic context changes. Flexibil-ity means allowing the specification and manage-ment of different types of contextual informationdepending on the environment’s requirements.

Autonomous agents’ capabilities can thus pro-vide healthcare environments with the means toadapt pervasive applications’ behavior to the user’sparticular privacy conditions and demands, result-ing in an agent-based privacy-aware system. Toexemplify how autonomous agents can support thedevelopment of such a system, we extended theSimple Agent Library for Smart Ambients (SALSA)agent framework.4 We incorporated customizableprivacy-aware mechanisms into SALSA that adaptthe application according to the users’ context to

Pervasive technology

in hospital work

raises important

privacy concerns.

Autonomous agents

can help developers

design privacy-aware

systems that handle

the threats raised by

pervasive technology.

satisfy their privacy needs. We illustratethe privacy-aware facilities incorporatedinto SALSA by describing the implementa-tion of an agent-based pervasive hospitalapplication. This application provides rel-evant information to hospital workers onthe basis of contextual information such astheir locations and roles, and it lets them

communicate through contextual mes-sages. This application raised privacy con-cerns among potential users, which weaddressed using privacy-aware agents.(The “Related Work in Privacy-Aware Sys-tems” sidebar discusses other attempts atmanaging privacy in pervasive computingenvironments.)

Using autonomous agents for privacy management

For three months, we conducted a work-place study in a public hospital. The studyincluded systematic observation, long inter-views, and a scenario-driven evaluation. Weconducted this study to assess the privacyissues hospital workers face in their everyday


56 www.computer.org/intelligent IEEE INTELLIGENT SYSTEMS

The pervasive computing literature addresses privacy issues—as does, to a lesser degree, agent-based systems design. How-ever, despite the topic’s obvious importance, relatively littlesystems-oriented research addresses privacy protection in mul-tiagent architectures.

Marc Langheinrich’s privacy awareness system (pawS) letsdata collectors announce and implement data use policies. Italso lets data users control how much of their personal infor-mation is stored, used, and removed from the system.1 Unfor-tunately, although privacy mechanisms triggered upon infor-mation capture have been useful in client-server applications,they aren’t suitable for agent-based systems. In the latter, theagent representing the user is the first to detect that user’scaptured information. Therefore, the threat of an invasion ofprivacy doesn’t depend on the capture of such information butrather on the communication of this information to the envi-ronment’s other agents. Hence, agent-based pervasive applica-tions require triggering the privacy-aware mechanisms duringcommunication of the information.

On the other hand, Ginger Myles, Adrian Friday, and NigelDavies developed a system that gives users fine-grained controlover the release of their location information.2 This system pro-tects the information shared once an application has requestedit. The problem is that, unlike pawS, this system stores and man-ages information that the user hasn’t agreed to share. The pri-vacy-aware mechanisms we incorporated into SALSA filter theuser’s personal information before sharing it with the brokerand enforce privacy conditions when some entity requests suchinformation. Although enforcing privacy for information re-quests and communication lets data owners control their infor-mation, this approach creates an imbalance between the infor-mation that data owners are willing to share and the datacollectors’ requirements for service delivery. Researchers callthis imbalance the principle of minimum asymmetry.3 Privacy-aware mechanisms could handle this problem by increasingthe information the data collectors share with the data ownersto provide feedback and symmetry.

PRICONIA,4 an agent-based framework based on a consumer-centered access control mechanism, allows negotiation ofmembership on the basis of consumer demands and user pri-vacy conditions. By following a priority delivery mechanism,PRICONIA uses a portal agent to inform users of the informationan application is handling. Although PRICONIA provides userfeedback and reasonable control over the information flow,both the priority delivery and the consumer-centered accesscontrol mechanisms are isolated from the context in which thesystem captures, accesses, and shares the user’s personal infor-mation. The privacy-aware agents we propose deal with the

principle of minimum asymmetry by letting agents negotiatetheir quality of privacy (QoP) level, considering the user’s con-text in enforcing privacy.

The Confab toolkit uses an entity’s contextual informationsuch as location, activity, or name, along with privacy tags tocreate a context tuple that an infospace represents.5 The userstores these infospaces, and infoservers manage them. Thus,applications can retrieve and manipulate such infospaces. Usingan access control mechanism to access the context tuple storedin the retrieved infospace, infoservers enforce privacy condi-tions. However, in this approach, users can’t control their con-text tuple. Therefore, if a user’s context tuple doesn’t meet aservice’s demands, the infoserver denies the user access, withno way to change his or her context tuple to meet the require-ments the service demands or to somehow negotiate access.Because privacy management is a dynamic response to a circum-stance rather than a static enforcement of rules,6 flexibility isrequired. Our approach lets agents change their QoP level asnecessary, establish contracts with other agents, and make spe-cial exceptions if required.

References

1. M. Langheinrich, “A Privacy Awareness System for UbiquitousComputing Environments,” Proc. 4th Int’l Conf. Ubiquitous Com-puting (Ubicomp 02), Springer, 2002, pp. 237–245.

2. G. Myles, A. Friday, and N. Davies, “Preserving Privacy in Environ-ments with Location-Based Applications,” IEEE Pervasive Comput-ing, vol. 2, no. 1, 2003, pp. 56–64.

3. X. Jiang, J.I. Hong, and J.A. Landay, “Approximate InformationFlows: Socially-Based Modeling of Privacy in Ubiquitous Comput-ing,” Proc. 4th Int’l Conf. Ubiquitous Computing (Ubicomp 02),Springer, 2002, pp. 176–193.

4. S. Miyagawa, S. Yamasaki, and E. Uchiyama, “An Agent-BasedInformation Aggregation Framework with Privacy and PriorityControl for Daily Life Support,” Proc. 1st Int’l Workshop Privacyand Security in Agent-Based Collaborative Environments (PSACE06), Springer, 2006, pp. 91–105.

5. J.I. Hong and J.A. Landay, “An Architecture for Privacy-SensitiveUbiquitous Computing,” Proc. 2nd Int’l Conf. Mobile Systems,Applications, and Services, ACM Press, 2004, pp. 177–189.

6. L. Palen and P. Dourish, “Unpacking ‘Privacy’ for a NetworkedWorld,” Proc. SIGCHI Conf. Human Factors in Computing Systems,ACM Press, 2003, pp. 129–136.

Related Work in Privacy-Aware Systems

NOVEMBER/DECEMBER 2006 www.computer.org/intelligent 57

work, how they deal with them, and how theseissues influence their decision making. Wealso wanted to understand how hospital work-ers’perception of privacy changes when theyenvision their hospital using pervasive tech-nologies. Our results indicate that hospitalworkers relax or enforce their privacy de-mands depending on the situation and on thevalue of the application’s services. From a sys-tems design perspective, pervasive applica-tions must meet different users’ privacy per-spectives and be able to enforce or relax users’privacy demands depending on the situation.

Similar to the way a person manages pri-vacy, autonomous agents make decisions, per-ceive different types of contextual information,and react accordingly while acting autono-mously and proactively. These capabilities letautonomous agents adapt pervasive applica-tions’behavior on the basis of each user’s par-ticular privacy conditions and demands.

The results of this study helped us identifyprivacy requirements based on user privacyneeds. To complement these requirements, weanalyzed several design guidelines and designimplications reported in the literature to gainan understanding of developer needs.3,5–7 Weidentified the following requirements.

A common language for usersand agents

Users and systems perceive privacy differ-ently. Users need an upfront qualitative clari-fication of what the technology offers and whatinformation is necessary to access such bene-fits. On the other hand, the technology enforcesprivacy by using a set of policies that definehow the pervasive application must adapt itsbehavior to respect the user’s privacy demands.So, privacy exists at two levels: the user’s qual-itative perception and the technology-managedquantitative parameters. Addressing bothviews is challenging because they’re ex-pressed differently, depending on the appli-cation logic. Thus, a flexible common lan-guage is necessary to define and manage, atboth the user and system levels, the privacythat the user demands.

We introduced the term of quality of pri-vacy, by analogy from the concept of quality ofservice. QoS is the probability that a computernetwork meets a given traffic contract. QoP isthe probability that a pervasive environmentmeets a given privacy contract. Thus, a usercan demand a certain QoP level from the per-vasive environment using a qualitative mea-sure—for example, logging into the system asan anonymous user. On the other hand, the sys-

tem can map the perception of anonymity inthe form of policies representing the privacycontract. In this case, the pervasive applicationadapts its behavior to the user’s context, satis-fying the QoP level agreed to by the applica-tion and the user.

A way to communicateprivacy events

Agents might need to communicate privacyevents to users and other agents. In contrast toa static enforcement of rules, these events letagents dynamically respond to a change incontext.7 For example, whenever an agentchanges its QoP, a notification goes to allagents connected in the environment. When aparticular agent’s context changes, the perva-sive environment must adapt its behavior.Thus, a privacy-aware protocol is necessary.

Awareness and control of theinformation flow context

An agent-based pervasive system mustenforce privacy when an agent communicatesor requests information,6,8 providing feedbackand reasonable control for sharing, accessing,and communicating the users’personal infor-mation.3 Agents must be able to enforce pri-vacy before the system communicates theirinformation to the environment and before itgrants access. However, an inflexible approachunder this scheme could lead to an informa-tion flow asymmetry, which would preventagents from accessing essential informationneeded for their correct execution.5 Thus,agents must follow a negotiation-based accesscontrol so that they’re aware of the informa-tion that services in the environment request.

Negotiation of privacy enforcement under special circumstances

Agents might need to make special excep-tions, depending on the situation. For exam-ple, although removing medical records fromthe hospital isn’t permissible, sometimesphysicians let interns remove specific docu-ments for didactic practices. Hence, privacyviolations might be permissible if both par-ties agree. Agents must be flexible to allowthese negotiations. Similar to the way personsestablish contracts in real life, agents musthave a way to negotiate a contract through aset of clauses.

Privacy-aware autonomous agents

Considering the advantages that auto-nomous agents offer, we created a software

infrastructure for privacy-aware autonomousagents to develop pervasive applications. Sev-eral agent-based middleware platforms, suchas JADE (Java Agent Development Frame-work), SALSA, and the GAIA operating sys-tem (a middleware infrastructure to enableactive spaces), enable the creation and imple-mentation of multiagent pervasive systems.These frameworks have at least partiallyaddressed security issues, but not privacy. Wedecided to design and implement privacy-aware autonomous agents by incorporatingmechanisms into SALSA middleware that adaptthe contextual information satisfying a desiredQoP level.4 We selected SALSA because itscommunication language is flexible enoughto let programmers represent and manage dif-ferent types of contextual information. How-ever, other agent platforms could incorporatesuch capabilities into their designs for privacy-aware pervasive applications.

The SALSA agent framework contains alibrary of abstract classes that enable devel-opers to implement the agent’s componentsfor perceiving, reasoning, and acting and tocontrol the agent’s life cycle (which imple-ments the agent’s behavior).4 When a devel-oper creates an agent, SALSA’S registeringcomponent registers it in an agent directory.Later, SALSA’s acting component activates theagent so that it starts perceiving informationfrom its environment in different ways. Dur-ing the reasoning state, the agent evaluatesthe perceived information, which couldrequire applying a simple or complex rea-soning algorithm to interpret or transformthis information into derived contextualinformation. Depending on the reasoningcomponent’s results, the agent executes anaction. This action might involve communi-cating with other agents, moving its owncode to another platform, continuing to per-ceive information, or terminating its execu-tion (being deactivated and killed). An agentin the suspended state is alive but not per-forming any activity. For example, if an agentis waiting for information it requested fromanother agent, it changes from the commu-nicating state to the suspended state. Then,when the other agent contacts this agent, itsstate returns to communicating.

SALSA also provides a communication plat-form so that users can detect the presence ofother users and agents that offer services rel-evant to their activities. SALSA lets agents con-vey information and negotiate services withother agents or request that they execute anaction. A communication channel, or agent

broker, handles communication among ubiq-uitous devices, services, and users (all ofwhich are represented by agents). A protocolprovides an expressive language for exchang-ing different types of objects between agents(such as perceived context information), be-tween agents and users (such as events gener-ated by user actions); and between agents andservices (such as a service’s state). When anagent perceives information, a SALSA eventoccurs, letting the agent activate the reason-ing component. The SALSA communicationlanguage is flexible enough so that program-mers can specify each message’s content orextend the type of messages.

We extended the SALSA agent’s life cycle,architecture, and communication platformto incorporate privacy mechanisms into theagents.

Life cycle of privacy-aware SALSA agents

Figure 1 shows a SALSA agent’s life cycle,which includes three new states. These stateshelp privacy-aware autonomous agents en-force user privacy.

The announcing state is a substate of the ini-tialized state that communicates the user-demanded QoP level to the agent broker. ThisQoP level is in the form of policies mappedinto a level of the IPA (information provided byan agent) and the IRS (information requestedby a service). The IPA represents the privacyconditions that a user demands from the per-vasive environment specifying the informationa user is willing to share. For example, if a userwants to join the system anonymously with-out sharing his location, his IPA indicates that

his identity must be shared as anonymous andhis location must be shared as unknown. Onthe other hand, the IRS represents the privacyconditions that the agent demands from otheragents that want to use its services. These con-ditions are access requirements for each of theagent’s services. For example, an agent repre-senting a printer must know a user’s identityto let that user print a document. The IRS forthe printing service indicates that the otheragents must share their identity with the printeragent—that is, the service allows no printingby an anonymous agent. The agent brokerenforces this policy mechanism.

Activation of the negotiating state couldoccur when the broker rejects an agentrequest for accessing an agent’s service orinformation. In this case, the broker informsthe agent that the IPA level doesn’t match theminimum IRS level required to access theservice the agent provides. Hence, the agentcould decide to negotiate a contract, stipu-lating clauses (such as expiration time) that,if accepted by both parties, would permit thedelivery of the service. For example, a hos-pital might restrict access to a medical recordto be compliant with HIPAA (the US HealthInsurance Portability and AccountabilityAct). But under special circumstances,accessing a medical record from outside thehospital premises might be permissible.Hence, an agent representing a physiciancould negotiate a contract with the agent thatprovides access to the medical record so thatthe physician could temporarily access thatrecord from outside the hospital premises.This negotiation would be agent to agent,depending on the application logic and the

agents’ nature to select an adequate negotia-tion protocol and clauses. Thus, this compo-nent is an interface that the programmershould overwrite.

Finally, the filtering state accesses an agent’spolicies to control and adapt the contextualinformation that the agent communicates. Inthis state, the agent filters the information itperceives, as well as the information an-nounced to the broker. For example, if a userdecides to join the pervasive environment witha certain QoP level, indicating he’s joining thesystem anonymously, this state filters the user’sidentity, which the agent representing the userknows, treating the user as anonymous.

The three states just discussed trigger thesemechanisms in privacy-aware agents beforeand while communicating information. How-ever, we want to enforce privacy for infor-mation requests as well. So, we extended theagent broker with an enforcing mechanism.

Handling privacy through theagent broker

An agent interacts with other agents andusers through its proxy to SALSA’s agent bro-ker, which handles XML messages. The bro-ker stores the status of users and agents, andnotifies other agents subscribed to them ofchanges. Developers can define new statesaccording to the device or service the agentrepresents.

The developer then defines an IPA andan IRS for each service provided by eachagent in the environment, which the brokerstores. When a request message arrives, thebroker evaluates the information encodedin that message, and triggers and executesan enforcing mechanism. This mechanismis responsible for matching the IPA an-nounced by the service-requesting agentwith the IRS demanded by the service-pro-viding agent. For example, if an agent rep-resenting an anonymous user tries to accessa medical record, the service-providingagent’s IRS doesn’t match the IPA an-nounced by the anonymous user. So, the bro-ker’s enforcing mechanism rejects the re-quest. The broker then sends the result to theservice-requesting agent which could de-cide to negotiate a contract.

The privacy-aware communicationprotocol

We extended SALSA’s communication pro-tocol with methods and events to negotiate pri-vacy contracts between agents, to enforce pri-vacy requests, and to specify different levels



Selectingactions

Reasoning

Initialized

Announcing

Activated

Evaluating

Filtering Suspended

Deactivated

Killed

Acting

Executing

Negotiating

Communicating

Perceiving

Registering

Figure 1. Life cycle of a privacy-aware SALSA agent.


of QoP as policies. We implemented sevenmethods so that agents could

• announce a QoP level,• send and enforce notification when a

request is rejected,• send a contract negotiation request,• notify other agents of a contract’s clauses,• send the status of a contract agreed to by

agents,• send an agent policy, and• convey to other agents the context of infor-

mation handled.

For example, an agent uses the sendPolicy(xml-Content, agentID) method to inform another agentof its IPA or IRS policies. When invoked, theinstance of the method shown in figure 2forms an XML message by adding the tagsspecifying to whom the message is addressed(agentB@aBroker), the type of service requested(policy), and the parameters needed to per-form the action (location and identity).

The programmer handles the code for eachcommunication’s agent policy because thiscommunication depends on the applicationlogic and the details of the pervasive environ-ment’s agent system. This flexibility also sup-ports customizable privacy policies, such asthose for organizational requirements, as wellas the privacy requirements of a user, service,or device. For example, a hospital might de-fine certain rules to be HIPAA compliant—forinstance, that the medical record can’t beremoved from the hospital. We illustrate theprivacy-aware facilities incorporated intoSALSA through our redesign of a context-awaremobile communication system aimed at ad-dressing the privacy concerns raised by poten-tial users.

Design of a privacy-awareapplication

The Context-aware Hospital InformationSystem (CHIS) lets users send messages spec-ifying a set of conditions that must be satis-fied before the system delivers such messages.These conditions, such as the recipients’loca-tion and role or the status of an artifact, thenbecome the message’s delivery context.1 Forexample, a physician can send a message tothe doctor responsible for a patient in the nextshift when the laboratory results become avail-able. In addition, CHIS provides access toinformation and services according to usercontext. CHIS considers contextual informa-tion, such as the user’s identity, role, and loca-tion; device used; time; and status of an infor-

mation artifact (for example, the availabilityof lab results). So, when a physician carryinga PDA is near one of his patients, the systemmight display that patient’s clinical record.CHIS integrates a location estimation mech-anism through which the system providesawareness and determines which informationto send and present to the users. CHIS dis-plays, as a list of users or in a floor map, the hos-pital worker’s and resources’ location. Hence,using a handheld computer, medical staff canlocate patients, other staff members, andresources.

We presented CHIS in a scenario-drivensession to 28 hospital staff members—13physicians, eight nurses, and seven supportstaff—to evaluate the system’s core charac-teristics and the staff members’ intentions touse the system. Although the results showedthat the system would be useful in their dailywork, potential users expressed several pri-vacy concerns that could become obstacles tothe system’s adoption. For this reason, we con-ducted an additional study to specifically eval-uate the potential privacy risks of using CHIS.

Privacy risks of the CHIS systemWe presented two scenarios to hospital

workers to measure their privacy concernsabout the system. The workers identifiedboth scenarios as useful, but they alsoexpressed privacy concerns. The first sce-nario illustrates how an intern can use a hand-held device to request laboratory tests,receive context-aware notifications of the re-sults’ availability, and visualize the locationand name of all hospital workers in the vicin-ity. The second scenario shows how a super-visor can learn whether an employee has per-formed a given procedure by looking atwhere the intern was throughout the day andlooking at pictures of him taken at differenttimes during his shift. This scenario has seri-ous privacy implications because the nurse(and potentially other supervisors) can trackthe intern’s location throughout his workshift. Nevertheless, we included such a sce-nario because the interns’ supervisors foundit useful.

We organized a scenario-driven evaluationto show both scenarios to 27 medical interns.We asked the participants to situate themselvesin a specific role within each scenario. We thenasked them to complete a survey with sevenLikert-scale assertions to evaluate the privacythreats they perceived from this technology.Finally, we applied these findings to identifythe contextual information used to regulate and

manage privacy, as well as the potential risksof using CHIS. We grouped the main privacyrisks the interns identified into three categories.

Sensing. This risk relates to CHIS’ ability toinvisibly track hospital workers’ locations.Privacy concerns centered on where, when,and how CHIS collects this information. Hos-pital workers considered some areas (such asa bathroom) to be personal spaces—areaswhere they didn’t want to be monitored andtherefore wouldn’t use the system. Thus, therisk of an invasion of privacy surpassed thebenefits the system provided. Similarly, thetime of day played a role. For example, dur-ing night shifts, the medical interns sleep fora few hours, at which time they don’t use thesystem. In addition, interns were concernedabout the device’s capability to collect theirlocation information. Although the methodCHIS uses to monitor their location doesn’trepresent a threat, not knowing how and whenCHIS collects the data does.

Sharing. CHIS independently shares iden-tity and location information with all hospi-tal workers in the user’s vicinity. This raisedseveral privacy concerns about when, where,and with whom CHIS was sharing informa-tion. For example, while a medical intern isin the dining room, he’d like to protect hisprivacy by regulating the precision withwhich CHIS shares his location or identity.Thus, the need for privacy when using CHIStends to be location and time sensitive, mean-ing the information a user is willing to sharecould change after a certain period of timeor depending on the user’s location or thetime of day. In addition, CHIS doesn’t lethospital workers specify availability levels,nor select with whom they’d like to sharetheir location or identity. CHIS emphasizeshospital workers’availability without givingthem control over this information. But if amedical intern is in the surgical room, hedoesn’t want a nurse to interrupt him to sign

Figure 2. XML message announcing theagentB@aBroker policy to the printer@aBroker.

<message to=‘printer@aBroker’from=‘agentB@aBroker’ >

<x xmlns=‘x:command’><params><type>policy</type>

<location>room</location><identity>role</identity>

</params></x></message>

a medical note, and he doesn’t want context-aware notifications to inform him of theavailability of laboratory results.

Storing. Related to the management of theinformation CHIS stores, privacy concernsemerged regarding the content and persistenceof information capture. For example, hospitalworkers didn’t realize that their location infor-mation might be stored for long periods oftime and could be used to derive secondarycontextual information, such as the places theyvisit frequently or with whom they normallyinteract. Although CHIS doesn’t store loca-tion information for long periods of time, itdoes store contextual messages until they’redelivered.

Integrating privacy-aware SALSA

agents in CHISBecause the privacy risks raised by CHIS

depend on contextual circumstances such asthe user’s location, identity, and activity, as wellas the persistence of the information captured,we decided to modify CHIS accordingly. Weextended CHIS to harness the capabilities pro-vided by privacy-aware SALSA agents. Our so-lution involved redesigning CHIS to show howconsidering contextual information to incor-porate different QoP levels lets designers ade-quately and easily manage users’privacy. Forinstance, suppose Dr. Diaz, a medical intern,joins the hospital information system, demand-ing a QoP level to communicate his location

and identity information by sharing only theroom he’s in and his role. On the other hand, onthe basis of Dr. Diaz’ QoP level, CHIS willadapt the information it shows him accordingto the other agents’ QoP levels. As figure 3shows, a nurse allows only sharing her infor-mation by symmetry (meaning both personssee the same thing); hence, Dr. Diaz will knowonly the floor she’s on and her role. In addi-tion, as the privacy-aware bar in figure 3ashows, Dr. Diaz is aware that CHIS is moni-toring his information of location and identity;he is also aware of his QoP level and his status(level of availability). By selecting from thisprivacy-aware bar the icon that represents hisQoP level, Dr. Diaz could change this levelwhenever he wants. For example, if he’s in thedining room, he doesn’t want to be monitoredor have other people infer how long he wasthere. So, he decides to share his identity asanonymous without presenting his location oractivity information by changing his QoP level.Therefore, by allowing different QoP levels,the autonomous agents in CHIS provide a clearvalue proposition (identifying the amount ofinformation a user needs to share with theapplication to obtain the benefits that the appli-cation’s services provide), awareness, and ne-gotiation access control.

To provide such functionality, we redesignedCHIS using privacy-aware SALSA agents. Be-cause we incorporated privacy mechanismsinto SALSA’s action, perception, and reasoningcomponents, we didn’t accomplish this re-

design at the architectural level. Rather, we cre-ated the QoP levels for users, devices, and ser-vices to rule the privacy enforcement in CHIS,and we implemented the actions executed byeach agent to enforce privacy.

A CHIS privacy-aware SALSA agentThe privacy that a CHIS user demands and

expects concerns location, identity, and activ-ity. Thus, we propose different QoP levelsaimed at protecting this contextual informa-tion. By extending the context-aware client’sinterface, a user can specify his or her loca-tion, identity, and activity according to threedifferent QoP levels. For example, a user couldset the location QoP level to include the roomhe’s in (low level), the floor he’s on (interme-diate level), or no location information at all(high level). Thus, if a physician doesn’t wantto be monitored while he’s in the dining room,he sets his QoP to high, controlling the loca-tion information shared with CHIS. Similarly,we established three different QoP levels forthe user’s identity and activity, and for theagents who can access this user’s information.The system maps these different QoP levelsto an IPA policy, as figure 4a indicates.

Figure 4b illustrates the structure of a pri-vacy-aware SALSA agent representing a userin CHIS. The agent inherits the SALSA com-ponents for reasoning, action, and perception,along with the privacy-aware mechanismsincorporated into SALSA. We extended the rea-soning component so that an agent can trig-ger privacy events and react to such eventsgenerated by SALSA’s communication proto-col. Extending the reasoning componentinvolved adding rules that allow the executionof privacy actions. For example, if a userchanges his QoP, the announcing mechanismtriggers an ArrivePresenceEvent. The reasoningcomponent maps the requested QoP level tothe corresponding IPA and IRS privacy poli-cies. Using SALSA’s filtering privacy mecha-nism, it then executes the correct action toupdate the information that SALSA’s commu-nicating mechanism communicates to the bro-ker. Similarly, we established different rulesin the reasoning component to allow negotia-tions between agents, such that on the basis ofthese results CHIS can execute the negotiateaction. The negotiate action determines theamount of information required for the deliv-ery of a service by informing the agent’s IRSpolicy.

As figure 4 shows, the following mecha-nisms, which we incorporated in SALSA, sim-plify privacy management, letting program-



Context-Aware IS

System Tools HelpSys

Internal Medicine

Intern

al Med

ic

Physicians

Dr. Perez <244>

Dr. Gomez <224>Dr. Gomez <224>

Physician <Surgery>

Ana <Nurse pavilion>

Printer <Nurse pavilion>

Juan <228>

Nurse <Int. Medicine>

A1 Physicians Nurses Dev

Physician <Surgery>

Devices

2:14p A B2:14pMap

Nursepavilion

246 247

223 222 221

225 226

230 231 232

222JUAN

229

245

Dr. Gomez

Role

Me: IMDiaz Me: 222 Low Level

High Level

SurgeryInternalMedicine

Intermediae Level

Figure 3. Based on the quality of privacy (QoP) level that a user demands, the Context-aware Hospital Information System (CHIS) provides (a) a list of user locations and services, and (b) a floor map.


mers focus on the privacy logic and the QoPlevels that users desire:

• the notification of the QoP level,• the notification of a denied request, and• the context assigned to a particular privacy

event.

Sample applicationFigure 5 shows how the CHIS components

interact with the privacy-aware mechanismswe incorporated in SALSA by considering theuser’s context and adapting the application’sbehavior to the QoP level agreed to by a useragent and a service agent.

When a user joins the system demanding acertain QoP level, the agent representing himmaps this QoP level to the corresponding IPAand IRS privacy policies. The user agent’sregistering mechanism then stores and regis-ters these policies in the agent directory. Con-sequently, the user agent’s filtering mecha-nism filters the user’s information (location,identity, and so on) to respect the user’srequired QoP level. The user agent’s execut-ing component then communicates this infor-mation, along with the user agent’s presenceand IPA and IRS policies, to the broker. Next,the broker broadcasts this information to theagents subscribed in the agent directory. Thecontext-aware privacy client updates the userinformation displayed by CHIS. When theuser agent requests a service, the broker’senforcing mechanism compares the useragent’s IPA with the service agent’s requiredIRS. Because the user agent IPA doesn’tmatch the service agent’s required IRS, thebroker’s enforcing mechanism rejects therequest. The broker informs the user agent ofthis result. The user needs this service, so theuser agent shares this user’s personal infor-mation with the service agent to negotiate acontract. The service agent then tells the useragent the conditions of the contract in a set ofclauses. If the user agent accepts these con-ditions, the service can be delivered. The useragent receives these clauses and signs a con-tract with the service agent, accepting the lat-ter’s conditions. Finally, the user agentupdates its policies to specify the clauses ofthe new contract just acquired.

We are developing mechanisms toautomatically base the QoP level

on the user’s context. These mechanisms takeinto account contextual information such as

the user’s location and identity, the time ofday, the artifacts used, and the presence ofcolleagues to infer hospital workers’ avail-ability and privacy demands. Once a perva-sive application has strong evidence of theusers’ privacy needs, it can adapt itself byselecting the adequate QoP level to proac-tively enforce hospital workers’ privacy. Wewill integrate these mechanisms into the pri-vacy-aware SALSA agents.

AcknowledgmentsWe thank the personnel at IMSS (Instituto Mex-

icano del Seguro Social) General Hospital in Ens-eneda, Baja California, Mexico. This work wasfounded under contracts CO3-42447 and Cona-cyt-U-40799, and through scholarship 179381 pro-vided to Monica Tentori.

References

1. M. Munoz et al., “Context-Aware MobileCommunication in Hospitals,” Computer, vol.36, no. 9, 2003, pp. 38–46.

2. J.X. Jiang and J.A. Landay, “Modeling Pri-vacy Control in Context-Aware Systems,”IEEE Pervasive Computing, vol. 1, no. 3,2002, pp. 59–63.

3. V. Bellotti and A. Sellen, “Design for Privacy inUbiquitous Computing Environments,” Proc.3rd European Conf. Computer-Supported

Cooperative Work (ECSCW 93), Kluwer Aca-demic Publishers, 1993, pp. 77–92.

4. M.D. Rodriguez et al., “Agent-Based Ambi-ent Intelligence for Healthcare,” AI Comm.,vol. 18, no. 3, 2005, pp. 201–216.

5. X. Jiang, J.I. Hong, and J.A. Landay,“Approximate Information Flows: Socially-Based Modeling of Privacy in UbiquitousComputing,” Proc. 4th Int’l Conf. UbiquitousComputing (Ubicomp 02), Springer, 2002, pp.176–193.

6. M. Langheinrich, “A Privacy Awareness Sys-tem for Ubiquitous Computing Environ-ments,” Proc. 4th Int’l Conf. Ubiquitous Com-puting (Ubicomp 02), Springer, 2002, pp.237–245.

7. L. Palen and P. Dourish, “Unpacking ‘Pri-vacy’ for a Networked World,” Proc. SIGCHI

Conf. Human Factors in Computing Systems,ACM Press, 2003, pp. 129–136.

8. G. Myles, A. Friday, and N. Davies, “Pre-serving Privacy in Environments with Loca-tion-Based Applications,” IEEE PervasiveComputing, vol. 2, no. 1, 2003, pp. 56–64.

For more information on this or any other com-puting topic, please visit our Digital Library atwww.computer.org/publications/dlib.

AgentSALSA: Agent

SALSA: Reasoning

AgentReasoning

Adapt Negotiate

SALSA: Action

<AgentPolicy><QoP level=“low”>

<QoP>

<AgentPolicy><QoP>

<QoP>

<QoP level=“medium”>

<QoP level=“high”>

<IPAPolicy><location>room</location><identity>name</identity><activity>online>/activity<recipient>all</recipient>

<location>floor</location><identity>role</identity><activity>busy>/activity

<IPAPolicy>

<IPAPolicy>

<recipient>patient’s staff</recipient>

<location>unknown</location><identity>anonymous</identity><activity>unknown>/activity<recipient>colleagues</recipient>

<IPAPolicy>

<IPAPolicy>

<IPAPolicy>

(b)(a)

Figure 4. Privacy-aware SALSA agent representing a user: (a) IPA (information providedby an agent) policy specifying three QoP levels; (b) class diagram of the agent.

Jesus Favela is a pro-fessor of computer sci-ence at CICESE, where heleads the CollaborativeSystems Laboratory andheads the Departmentof Computer Science.His research interestsinclude computer-sup-

ported collaborative work, ubiquitous computing,and medical informatics. He received a PhD incomputer-aided engineering from MIT. He is amember of the ACM and the American MedicalInformatics Association. Contact him at the Com-puter Science Dept., CICESE, Km. 107 CarreteraTijuana-Ensenada, Ensenada, B.C., 22860, Mex-ico; [email protected].

Marcela D. Rodríguezis a professor in com-puter engineering at theAutonomous Universityof Baja California. Herresearch interests in-clude ubiquitous com-puting, autonomous ag-ents, human-computer

interaction, and computer-supported collaborativework. She received a PhD in computer sciencefrom CICESE. She is a member of the ACM andSociedad Mexicana de Ciencia de la Computacion.Contact her at Facultad de Ingeniería, UniversidadAutonoma de Baja California, Ave. AlvaroObregón y Julian Carrillo S/N, Mexicali, B.C.,21100, Mexico; [email protected]

Useragent

Agent directory Agent brokerContext-awareprivacy clientUsers and agents Service agent

register()

sendPolicy()

filter()

sendPresence(state, QoP, QoPrequired)

sendCommandRequest(printer)

sendEnforceNotification()

notifyPresence()adaptInterface()

enforce()

negotiate()

sendNegotiationRequest()

sendNegotiationRequest()

sendClauses()

sendClauses()

sendContract()

Figure 5. Sequence diagram for negotiating a QoP level for a CHIS application.

Monica Tentori is aPhD student in com-puter science at theCenter of Scientific Re-search and Higher Ed-ucation of Ensenada(CICESE), Baja Califor-nia, Mexico. Her re-search interests include

ubiquitous computing, human-computer inter-action, and medical informatics. She received anMSc in computer science from CICESE. She is astudent member of Sigchi. Contact her at theComputer Science Dept., CICESE, Km. 107 Car-retera Tijuana-Ensenada, Ensenada, B.C., 22860,Mexico; [email protected].

T h e A u t h o r s



privacy-aware autonomous agents for pervasive healthcare

Documents