0018-9162/03/$17.00 © 2003 IEEE38 Computer

C O V E R F E A T U R E

P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y

Context-AwareMobile Communicationin Hospitals

Information management in a hospital settingrequires significant collaboration, mobility, anddata integration. The care of one patient caninvolve many devices, such as x-ray machinesand blood-pressure monitors; artifacts other

than devices, such as patient records; and a varietyof staff, such as doctors, laboratory personnel, andsocial workers. Moreover, staff members oftenknow each other only as “the doctor on the nextshift” or the “nurse on duty,” which means com-munication is often through roles, not specific identities.

Adding to this complexity is the urgency of theexchange. Communication is often intense and timecritical, which requires a high degree of coordina-tion among both staff members and devices or otherartifacts. Finally, staff members often rely on thedevices themselves to transmit data, which presentsanother contextual variable. Communication mech-anisms must know where the device is, who needsit, when, and why.

In short, managing hospital information is a chal-lenge with unique requirements, and so far, no sys-tem has been able to address the complexity of thehospital environment. Documents are lost, instruc-tions are unclear, and data is incomplete.

Some have attempted to address these deficien-cies through videoconferencing1 and two-waypagers,2 but such solutions ignore that people often

work different shifts3 and that they use devices as acommunication channel. Indeed, many researchersacknowledge that hospital communication typicallyinvolves different locations, work hours, and com-munication paths.3,4

Given that conditions are not likely to change, abetter approach is to empower mobile devices torecognize the context in which hospital workersperform their tasks. Context-aware computing,which some have closely associated with ubiqui-tous computing,5 is an application’s ability to adaptto changing circumstances and respond accordingto the context of use. Mobile users are constantlychanging their context, notably their location, butin a hospital, the context is far more than location.It is also the timing of the exchange; the location ofa worker, device, or artifact; and the person’s role,not just his identity.

We have designed a context-aware mobile systemthat accounts for all these contextual elements,allowing users to send messages and access hospi-tal services when and where they choose. The systemessentially extends the instant messaging paradigmto add context-awareness as part of the message.

With context-aware communication, users canspecify a set of circumstances that must be satisfiedbefore the system delivers the message. These cir-cumstances then become the message’s delivery con-text. For example, the sender can ask that a patient’s

A collaborative handheld system extends the instant messaging paradigmby adding context-awareness to support the intensive and distributednature of information management within a hospital setting.

Miguel A.MuñozMarcelaRodríguezJesus FavelaAna I.Martinez-GarciaCenter of ScientificResearch and Higher Education ofEnsenada, Mexico

Victor M.GonzálezUniversity of California, Irvine

September 2003 39

lab results be delivered to the first doctor to enterthe emergency room or can request that the mes-sage be sent only to a specific doctor when he arrivesat the laboratory the next morning.

To develop our system, we conducted a workplacestudy at IMSS General Hospital in Ensenada,Mexico, a public-health institution that is the coreprovider in a network of healthcare facilities cover-ing the demands of approximately 82 percent of thecity’s population. To deeply understand (beyondrequirements gathering) how workers perform rou-tine and nonroutine work each day, we used quali-tative methods, such as interviews, participantobservation, and analysis techniques borrowed fromthe social sciences. Researchers have applied thesemethods for several years in studying human-com-puter interfaces, computer-supported cooperativework, and software engineering. The “Understand-ing a Hospital Environment” sidebar describes thestudy in more detail.

From our understanding of how work gets done,we shaped our technological design to directlyaddress the contextual elements that characterizehospital information. We then identified charac-teristics that context-aware technologies shouldsupport in this environment. Finally, we built a sys-tem prototype and demonstrated it to hospital staff.The results of an evaluation session based on theTechnology Acceptance Model5 (TAM) show thatstaff members find the system useful and easy touse and want us to deploy it.

CONTEXTUAL ELEMENTSOur study of IMSS General Hospital revealed

four critical contextual elements that a context-aware system would have to consider in supportingthe hospital’s information management and activ-ity coordination.

LocationWhere hospital staff members are at a particular

time determines in part the type of information theyrequire. For example, access to a patient’s medicalrecords is most relevant when the doctor or nurse iswith that patient, so the patient’s bed is the best placeto display detailed information. A nurse doesn’t needto know the appropriate dose of medication untilshe must give it to the patient. Likewise, the headnurse might want to locate the closest cardiologistto perform an emergency checkup. Thus, a systemthat accounts for staff location as part of its designprotects against information overload because itensures that a staff member receives only informa-tion that is useful and relevant for that location.

Delivery timingCommunication exchanges in a hospital

tend to be time sensitive, which means a mes-sage might be relevant for only a certainperiod. For example, a doctor might leave amessage that describes recommendations fortreatment to any nurse on the next shift. Thesystem cannot deliver the message before thenext shift because the patient’s symptomshave had insufficient time to evolve. Likewise,if the system waits until the following morn-ing, the symptoms might have evolved to thepoint where the original treatment is nolonger as effective. Thus, the system must letusers specify when to deliver messages across a 24-hour workday and a seven-day workweek. Theadvantage is not only timely delivery but also flex-ibility. Given that the system does not necessarilysend messages immediately after the users composethem, the users are free to modify or delete the mes-sages they have “sent” if conditions change.

Role relianceIn a hospital setting, parties who might be

strangers or rarely meet must communicate witheach other. Because of work shifts and high person-nel turnover, one patient might see two physiciansand three nurses in the same day. Thus, a user oftenaddresses messages not to particular individuals butto “the nurse on the afternoon shift,” or “the nextdoctor to visit the patient.” The only certainty isabout the role that person will play in attending tothe patient. Thus, the system must be able to recog-nize roles as well as particular individuals.

Artifact location and stateAn artifact, particularly a device, can have many

states, and the state of devices (temperature read-ing) and other artifacts (availability of lab results)can be important triggers for appropriate actions,including information exchanges. The sudden avail-ability of a bed could trigger the transfer of a patientwaiting in the emergency-room corridor. Medicalstaff might need to communicate directly with doc-uments or devices. For example, a doctor mightwant to display the patient’s lab analysis on heroffice desktop as soon as results become available.By monitoring relevant artifacts, the system cansupport the timely delivery of pertinent informa-tion to hospital workers.

Such monitoring must consider both the artifact’slocation (Is the printer near the person who requiresit?) and its ability to provide sufficient information(Is the printer in use, down for maintenance?).

A context-aware system must

consider staff location, delivery

timing, rolereliance, and

artifact location and states.

40 Computer

Artifact location is a critical part of providingcontext. The Ward-in-Hand, for example, is a hand-held system that provides access to patient’s recordsand hospital information through a wireless infra-structure.7 Although this solution seems a step inthe right direction, users must still explicitly requestthe information; the system does not provide it auto-matically on the basis of artifact location.

EXTENDING THE IM PARADIGMAs the scenarios in the sidebar illustrate, context-

aware messaging has many facets. In scenario 2,Dr. Diaz wants to send the message to the first doc-tor on the afternoon shift to be at the patient’s bedonce the lab has sent test results. Alternatively, hecould ask the system to send results to a nearbyprinter or to display them on a particular desktopso that he can discuss them with another doctor.

These scenarios require more than simple instantmessaging, in which two specific users communi-cate. Rather, they imply the need for third-partydecision makers, or agents, with which users can

interact seamlessly. The agents would review thecontext and make decisions about what activitiesto do, when to do them, and what type of infor-mation to communicate to whom. They wouldnegotiate services with other agents and wrap com-plex system functionality.

Some agents could monitor the medical informa-tion system to notify a doctor that results of a med-ical analysis are available, for example. Others couldreport the presence of the nearest public display andnotify other staff so that the doctor can discuss thelab results with a medical specialist. Yet others couldcontrol access to the hospital’s resources, taking intoaccount priorities or security restrictions and users’locations. Finally, another agent could monitor theenvironment to make sure that contextual require-ments are satisfied before delivering the message.

SYSTEM ARCHITECTUREAs Figure 1 shows, we incorporated agents into

our system architecture, along with a context-aware client and an IM server.

To understand IMSS General Hospital’s people, setting, andpractices, we studied three of its high-traffic departments:Urgencies, where more than 70 percent of the patients enterthe hospital; Internal Medicine; and Laboratory Analysis. Mostpatients enter through Urgencies and go to Internal Medicine,and they typically require laboratory services. For three months,we observed work practices and conducted interviews with 20staff, including physicians, nurses, social workers, assistants,a chemist, and lab workers. We took care to select people withdifferent roles, experience, and expertise.

We then assimilated our results to gain a deeper understand-ing of how contextual elements affect information management.From interview transcripts and our written observations, weidentified characteristics that context-aware technologies shouldsupport. We also identified the processes in which the hospitalworkers were most likely to interact frequently, change locationconstantly, and access patient information. We then sorted outactivities that depend on contextual variables such as location,identity, role, or time. We modeled these processes and validatedthem in another set of interviews with workers.

Once we clearly understood the processes, we identified usescenarios—situations that exemplify a distinct and typical usefor a context-aware support system. The scenarios weresketches of user activities. They did not contain details abouthow the tasks would execute or how the system would enablethe required functionality.1 Rather, the scenarios helped usframe our understanding of hospital work practices and gaveus insight into how context-aware computing could augmentthe work. The scenarios let us translate our findings into spe-cific vignettes that captured facets of how context-aware toolsmight fit into current work practices.

The two scenarios below show the kind of contextual sup-port hospital work requires and give a flavor of how technol-

ogy can enhance hospital practices. We used seven scenarios indesigning the system, but the two below are the most repre-sentative examples of daily work.

Scenario 1As Dr. Moreno makes her final round for the day, she notices

that a patient is not responding well to medication. Afterreviewing the patient’s medical record in her handheld, Dr.Moreno decides to leave a note to the physician who will bereviewing the patient in the afternoon shift. She doesn’t knowwho that person will be, so she directs the message to the firstphysician to check the patient after her.

Scenario 2While Dr. Diaz is checking the status of a patient (bed 1 of

room 222), he realizes that he should request a laboratory study.Through his handheld, he adds this request to the patient’s clin-ical record. The chemist responsible for taking samples for theanalysis visits the internal medicine area every morning. Hishandheld informs him that inside room 222 a patient requiresmedical analysis. When the chemist stands in front of thepatient, his handheld lists the samples he must take and the typeof analysis he must perform. Once he performs these analyses,he adds the results to the patient’s clinical record. When Dr.Diaz is about to finish his shift in another area, his handheldalerts him that the test results of the patient in bed 1 of room 222are available. Dr. Diaz goes back to the patient’s room and readsthe results displayed on his handheld. On the basis of the results,he revaluates the patient and decides that surgery is required.

Reference1. J.M. Carroll, Making Use: Scenario-Based Design of Human-

Computer Interactions, MIT Press, 2000.

Understanding a Hospital Environment

September 2003 41

Context-aware clientIn traditional IM systems, users send messages

as quickly as possible, and they generally know therecipient. In context-aware IM, users do not knowthe recipient’s identity and the identity remainsunknown until certain conditions are met. The sys-tem does not know the “chemist who will take thesamples,” for example, until she is next to thepatient’s bed. The context-aware client includes aninterface that requires only peripheral attention (asin most IM systems) to compose a message andspecify its delivery context. The context componentmanages message delivery and requests the user’slocation from a location-estimation agent.

IM serverWe used and extended the Jabber open-source IM

server (www.jabber.org) and its Extensible Mes-saging and Presence Protocol (XMPP), currently anInternet Engineering Task Force draft, to report thestate of people and agents and to handle the inter-action among people, agents, and devices throughXML messages. All communication between thecontext-aware client and the context-aware agentgoes through this server. The system synchronizesthe information in the user’s PDA with the servereach time the device connects to an access point.

AgentsThe context-aware hospital system includes sev-

eral agents we developed with Salsa (Simple AgentLibrary for Seamless Applications), a class frame-work for implementing autonomous agents thatact on the user’s behalf, represent devices, or wrapa system’s functionality.8 Salsa agents might run ina user’s PDA, a desktop computer, or a trustedserver connected to the access point. Either the usercan launch them explicitly or the system can acti-vate them when certain conditions are met. A Salsaagent’s components include

• a protocol that the agent uses to register withan agent directory;

• an interface through which the agent acquiresknowledge or information;

• an IM client through which users, user agents,and device agents interact by sending XMLmessages; and

• the subsystem that implements the agent’sintelligence.

The subsystem includes three modules. The per-ception module gathers knowledge from the envi-ronment’s sensors or directly from the users, otheragents, or devices through the IM server. The rea-

Hospital InformationSystem

Agent directory

Context-aware agentContext

perception

Contextinterface

IMclientReasoning

Action

Initialize and registerWirelessnetwork

Accesspoint

802.11b

Agent directory

Public display proxy agentContext

perception

Deviceinterface

IMclient Reasoning

Action

Initialize and register

Context-aware client

Perception

ContextGUIinterface

Reasoning

Action

IM client

Location-estimationagent

Hospital IS proxy agentContext

perception

HISinterface

IMclientReasoning

Action

Initialize and register

Instant messagingserver

Figure 1. Context-aware handheld sys-tem architecture.The architectureconsists of acontext-awareclient, an instantmessaging server,and severalautonomous agents.The agents act onthe user’s behalf,represent devices,or wrap a system’sfunctionality.

42 Computer

soning module governs the agent’s actions, includ-ing deciding what to perceive next. The actionmodule triggers a user-specified event, such as send-ing a message to any user with a specific role orsending a message to a device to use its service orchange its state.

Context-aware agent. All context-aware messagesgo to this agent, which monitors the environmentto determine whether conditions are such that thesystem can deliver the message. Its perceptionmodule registers the contextual information bymonitoring the environment through the contextinterface.

The context interface consists of a component toconfigure the environment (devices available,groups of users, site map, and so on) and mecha-nisms to detect changes in contextual information,such as the device state and user position. The rea-soning component analyzes the contextual infor-

mation to determine if the message’s delivery con-text matches current conditions. If so, the actionmodule triggers the event the user has specified.Thus, the context-aware agent is a first-class entityregistered in the IM server with an IM roster thatincludes all people and devices whose state it mustbe aware of to deliver its messages. Through theIM server, the context-aware client keeps track ofchanges in users’ locations.

Location-estimation agent. This agent resides in allusers’ PDAs and obtains each user’s position bytriangulating the signal strength from at least three802.11b access points. Its reasoning componentwraps a back-propagation neural network, trainedto map the signal strength from each access pointin the wireless network to the user’s location.

Hospital IS agent. This agent provides access to andmonitors the state of the hospital’s informationsystem, which manages all artifacts other than

Handheldcomputer

Agentdirectory

Agent Printer IMserver

Hospital IS proxy agent

connect()

subscribe()

send(agentRef)

subscribe()

subscribed(presence)

subscribed(presence)

Message(toPrinterAgent)

Message(getinterface)

Message(interface.xml)

Message(interface.xml)

Message(print,doc)

Message(print,doc)

presence(status)

presence(status)

Response(doc)

get(docld)

getStatus()

msg(print,doc)

sendStatus(status)

Figure 2. Thesequence to print a document with a context-awareclient, an IM server,and device-proxyagents. To the rightof the sequence diagram, twoscreens show different states ofthe process: theclient’s roster (top) and the formthrough which theuser interacts withthe printer (bottom).

September 2003 43

devices in the form of digital documents. Forexample, when it detects that a user has updatedthe IS with the results of a laboratory analysis, theagent notifies the physician. It also provides patientinformation to the medical staff according to theirrole and location.

Device-proxy agents. Devices are appliances thatoffer services and are connected to the local net-work. They define possible states, the services theyoffer, and the protocol for users to interact withthem.

The user can specify any device state as part ofthe message-delivery context. For example, theuser can request delivery of a message to the near-est technician when a printer’s state is “low toner.”The device-proxy agent runs as a daemon on acomputing device that is connected to an agentdirectory and the IM server. All device-proxyagents provide a standard mechanism to initializeand register themselves on one or more agent direc-tories, providing information on all the services aparticular device offers.

When a user approaches an access point, theclient in the user’s PDA automatically subscribes toall agents registered in the agent directory associ-ated with that access point. In Figure 2, for exam-ple, the user wants to print a document. When theuser selects the printer in the roster, the client sendsa request to the printer’s proxy agent (Message(toPrinterAgent)). The request is that the agent pro-vide the XML document that describes the protocolthrough which the user can interact with the printer—Message(getinterface) and Message(interface.xml).

As the figure shows, this communication isthrough the IM server. When the client receives thedocument, it parses it to generate the form throughwhich the user can specify the file to be printed andconfigure the printing properties. When the userspecifies the file to be printed (Message(print,doc)),the printer’s proxy agent requests the file to theHospital IS proxy agent (get(docId)), which sendsit back to the printer’s agent (Response(doc)) to besent to the printer. This changes the printer’s stateto “printing,” which, through communicationwith the IM server, the user’s PDA translates as adevice state change.

SAMPLE APPLICATIONIn the sample application described in Scenario

1 in the sidebar, as Dr. Moreno prepares to send themessage, the context-aware client displays theavailable staff and devices on her PDA. As Figure3a shows, the client notes the status of other users

(online, busy, disconnected, and so on), as well asthe resources available in the vicinity (such as print-ers or public displays), their status, and the servicesthey can provide. The client also shows the loca-tion of users and devices if known. In Figure 3a,this information is in brackets after the person’sname (ward or room number).

In contrast to traditional IM, the sender of a con-text-aware message must specify delivery context.Figure 3b shows the form that users follow in writ-ing a message and specifying its context.

Specifying contextual informationThe interface lets users specify a variety of con-

textual information.Recipient. The user can send a message to a specific

user, to all users that meet the specified criteria, oronly to the first user that satisfies the criteria. In ourcurrent prototype, the sender specifies the recipi-ent’s identity by name or role (physician, nurse, andso on). Thus, in Scenario 1, Dr. Moreno specifiesthat the message should go to any physician.

Location. The sender specifies an area where therecipient must be for the message to be delivered.To aid in this process, the system displays a map,as in Figure 3c, that the sender can tap on to selectthe desired region. Thus, Dr. Moreno can specifyany physician in room 226, the patient’s currentlocation. An issue for additional research is howto track the patient, which would require that thepatient wear a location-estimation device.

Time and date. The sender can specify a lowerbound of time and date, an upper bound, or both.The system will then hold the message before thelower bound and not send it after the maximumtime. Dr. Moreno wants to send the message to anyphysician on the next shift, so she specifies thedelivery time lower bound of today after 2:00 pm,which she knows is the beginning of the afternoonshift.

Artifact state and location. Device-proxy agentsdefine all the states their respective devices can haveat any time. The system presents the list of statesfor all registered devices to the user when the deliv-ery context involves specifying a device state. Thus,the user can specify that the message be sent if theprinter is jammed (device state), the laboratoryresults are available (artifact state), and so on.

Figure 3. Interactionwith the context-aware handheld system. (a) The context-aware clientnotes the status andlocation of otherusers and availableresources. (b) Theform Dr. Morenouses to write themessage and specifycontext. (c) The sys-tem displays a hos-pital map, whichhelps the user iden-tify the desired areafor message receipt.

(a) (b) (c)

44 Computer

We have already integrated two devices in thesystem: a laser printer and a video camera. We planto integrate a public display and the laboratoryequipment that analyzes samples from patients.

Verifying delivery contextOnce Dr. Moreno sends the message, the system

begins to verify the contextual conditions for itsdelivery. Figure 4 is a sequence diagram of theprocess.

Dr. Gomez, the physician in the shift after Dr.Moreno’s, begins his daily routine by visiting hispatients. While he moves around the patients’rooms, the context-aware client in his PDA com-municates with the location-estimation agent toconstantly update his position. When his locationchanges, the context-aware client sends new loca-tion information through the IM server to all usersand agents that have registered Dr. Gomez in theirrosters. When Dr. Gomez enters the room of Dr.Moreno’s patient, the context-aware client updateshis location and sends it to the context-aware agent.The agent sees that the delivery-context conditionsfor Dr. Moreno’s message match the current con-text and sends the message to Dr. Gomez.

USABILITY EVALUATIONWe evaluated the system’s core characteristics,

the staff’s intention to use the system, and the staff’sperception of system utility and ease of use.

According to the TAM, these aspects are funda-mental determinants of system use.5

We presented 28 hospital staff members—13physicians, 8 nurses, and 7 support staff, includingthe chemist responsible for laboratory analyses—with animations of Scenarios 1 and 2 and then gavethem a questionnaire to measure how real theythought the scenarios were, if they would changeanything, and if they could envision new scenariosfor context-aware mobile technology.

The participants validated both scenarios andprovided us with additional insights and opportu-nities for applying our technology—for example,to schedule a surgery by tracking the availabilityof the operating room and the specialists involved.The evaluation session helped us see that only whenpeople have a picture of their work can they pro-vide details beyond what we can observe withouttheir input.

We posed additional questions to validate ourfindings, such as “Is it useful to have access to thepatient’s medical records through a handheld com-puter?” Table 1 shows the four questions and theirresponses. The results validate some of our find-ings from the workplace study: The staff finds loca-tion information useful, communication exchangesdepend on context, and handheld computers areappropriate mechanisms for accessing medicaldata. Additionally, most potential users were notconcerned with the likely distractions from the mes-

Context-aware client

Locationagent

Accesspoints

IMserver

Users/agents

Context-aware agent

get my position()

position

SignalStrength?

SignalStrength

presence(state,position)

Updateinterface

Estimateposition

Update(state,position)

notifying()

notifying()

send(message)

Analyzingcontext[match]

Handheld computer

Figure 4. Sequenceleading to the delivery of the context-aware message in Figure 3b.

September 2003 45

sages received; they are already confronted withconstant disruption in their daily work.

After this exercise, we gave a 15-minute demon-stration of the prototype and asked participants toanswer a second questionnaire aimed at predictinguser acceptance. The results show that 91 percent ofthe participants would use the system. Additionally,84 percent believe that using the system wouldenhance their job performance—a high degree ofperceived usefulness—and 78 percent perceived thesystem would be easy to use. Nurses had the lowestease-of-use ratings, which could in part be becausethey are less familiar with IM and PDAs in general.In any case, user training before system deploymentwould help alleviate some of this anxiety.

O ur handheld system supports the intensive anddistributed nature of information manage-ment and collaboration within a hospital set-

ting. Mobile users can send contextual messagesand access hospital services more efficiently by tak-ing context into account. The system will also scalewell. Developers who want to add a new deviceneed only program an interface to the device anddefine an XML document to specify the user’s inter-action with the services the device provides. Nochanges are required to the context-aware clientapplication that interacts with the environment.

An evaluation session with hospital personnelshowed that the system helps users achieve theirgoals. Indeed, since IMSS General Hospital is eagerto deploy the system, our next step is a pilot study,in which we will deploy the system on a small scaleto more deeply understand the role of contextualelements and how to support them. �

AcknowledgmentsWe thank the personnel at IMSS General

Hospital, in particular Simitrio Rojas and JuliaMora. This work was funded by UCMexus undercontracts Conacyt-CN-02-60 and Conacyt-U-

40799, and through scholarships provided toMarcela Rodríguez and Victor González.

References 1. S. Mitchell et al., “Context-Aware Multimedia Com-

puting in the Intelligent Hospital,” Proc. 9th ACMSIGOPS European Workshop, ACM Press, 2000,pp. 13-18.

2. S.A. Eisenstadt et al., “Mobile Workers in Healthcareand Their Information Needs: Are 2-Way Pagers theAnswer?” Proc. AMIA Symp., Am. Medical Infor-matics Assoc., 1998, vol. 26, no. 5, pp. 135-140.

3. C. Bossen, “The Parameters of Common InformationSpaces: The Heterogeneity of Cooperative Work at aHospital Ward,” Proc. ACM Conf. Computer-Sup-ported Cooperative Work, ACM Press, 2002, pp.176-185.

4. M. Reddy and P. Dourish, “A Finger on the Pulse:Temporal Rhythms and Information Seeking in Med-ical Work,” Proc. ACM Conf. Computer-SupportedCooperative Work, ACM Press, 2002, pp. 344-353.

5. A.K. Dey, “Understanding and Using Context,” Per-sonal and Ubiquitous Computing, Springer-Verlag,vol. 5, no.1, 2001, pp. 4-7.

6. F.D. Davis and V. Venkatesh, “Measuring UserAcceptance of Emerging Information Technologies:An Assessment of Possible Method Biases,” Proc.28th Hawaii Int’l Conf. System Sciences, IEEE CSPress, 1995, pp. 729-736.

7. M. Ancona et al., “Mobile Computing in a Hospital:The Ward-in-Hand Project,” Proc. ACM Symp.Applied Computing, ACM Press, 2000, pp. 554-556.

8. M. Rodríguez and J. Favela, “Autonomous Agents toSupport Interoperability and Physical Integration inPervasive Environments,” Proc. Atlantic Web Intelli-gence Conf., Springer-Verlag, 2003, pp. 278-287.

Miguel A. Muñoz is a graduate student in computerscience at the Center of Scientific Research andHigher Education of Ensenada (CICESE), where hisresearch focus is on context-aware computing, ubiq-uitous computing, and computer-supported coop-

Table 1. Results of a questionnaire measuring user acceptance of scenarios and the system’s context-aware features.

Strongly Slightly Slightly Strongly Disagree Disagree Disagree Neither Agree Agree Agree

It is useful to know who is in the hospital and 1 0 0 0 0 7 20 where they are in relation to meIt is useful to send messages that depend on 1 0 0 0 1 7 19context for their delivery It is useful to have access to the patient’s medical 1 0 0 0 0 8 19 records through a handheld computerReceiving messages can distract me from my 9 9 2 3 3 0 1 daily work*

*One person did not respond to this question.

46 Computer

erative work (CSCW). He received a BSc in com-puter engineering from the Institute of Technologyin Zacatecas. Contact him at mimunoz@cicese.mx.

Marcela Rodríguez is a doctoral student in com-puter science at CICESE and a lecturer in computerengineering at the Autonomous University of BajaCalifornia (UABC). Her research interests includeubiquitous computing, autonomous agents, andCSCW. She received an MSc in computer sciencefrom CICESE and a BSc in computer engineeringfrom UABC. She is a student member of the ACM.Contact her at marcerod@cicese.mx.

Jesus Favela is a professor of computer science atCICESE, where he leads the Collaborative SystemsLaboratory and heads the Department of ComputerScience. His research interests include CSCW, ubiq-uitous computing, and information retrieval. Favelareceived a PhD in computer-aided engineering fromthe Massachusetts Institute of Technology. He is amember of the IEEE Computer Society and theACM. Contact him at favela@cicese.mx.

Ana I. Martinez-Garcia is an associate professorof computer science at CICESE, where she coordi-nates the graduate program and works on model-ing and simulating workflow and processes andstudies the application of technology to organiza-tional process reengineering. She received a PhD inadvanced computer science from the University ofManchester, UK. She is a member of the Society forComputer Simulation. Contact her at martinea@cicese.mx.

Victor M. González is a doctoral student in infor-mation and computer science at the University ofCalifornia, Irvine. His research involves usingqualitative ethnographic methods to evaluatemedia-rich/activity-rich environments, the adop-tion of information-visualization systems, and the use of home information technologies. Hereceived an MS in information and computer sci-ence from UC Irvine and an MSc in telecommu-nication and information systems from theUniversity of Essex, UK. Contact him at vmgyg@ics.uci.edu.

I E E E C O M P U T E R S O C I E T Y 5 T H A N N U A L I N T E R N A T I O N A L D E S I G N C O M P E T I T I O N

Be a Part of CSIDC—the Premier Contest for Computer Engineering Students!

The search is on for teams of undergraduate students from around the world to compete in the fifth annualIEEE Computer Society International Design Competition.� Compete with students from all over the world� Rise to the challenge of working with a team� Design a computer application that can change people’s lives� Visit Washington, DC and compete in the exciting World Finals� Turn theory into practice and construct a new computer-based productTeams must design, build, test, and document a working system based on a PC, laptop, or handheld computing device to solve a real-world problem. Teams must submit reports documenting the design and implementation of their prototype.

The 2004 theme: Making the World a Safer Place

IMPORTANT DATESApplications due . . . . . . . . . . . . . . . . . . . . . .1 November 2003Interim reports due . . . . . . . . . . . . . . . . . . . . .20 February 2004Final project reports due . . . . . . . . . . . . . . . . . . . .28 April 2004Top 10 projects selected . . . . . . . . . . . . . . . . . . . . .24 May 2004CSIDC World Finals in Washington, DC . . . . . . .27-29 June 2004

Primary financial support for CSIDC 2003 provided by Microsoft,with additional support from the IEEE Foundation.

For more information or to apply online, see

computer.org/csidc/

PRIZESFirst place . . . . . . . . . . . . .$15,000Second place . . . . . . . . . .$10,000Third place . . . . . . . . . . . . .$6,000Honorable mention . . . . . . . $2,000

Additional CSIDC awards:� Microsoft Award for Software

Engineering� Microsoft Multmedia Award