This article was downloaded by: [UQ Library]On: 02 November 2014, At: 00:28Publisher: Taylor & FrancisInforma Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer House,37-41 Mortimer Street, London W1T 3JH, UK

Information Systems ManagementPublication details, including instructions for authors and subscription information:http://www.tandfonline.com/loi/uism20

Deriving Long-Term Value from Context-AwareComputingGuruduth Banavar a , Jay Black b , Ramón Cáceres c , Maria Ebling c , Edie Stern d & JosephKannry ea The Pervasive Computing Infrastructure Department , IBM T.J. Watson Research Centerb The School of Computer Science at the University of Waterloo , Ontarioc Research staff members at the IBM T.J. Watson Research Center.d A Senior Technical Staff Member at IBM.e An Assistant Professor in Medicine as well as the Chief of the Division of ClinicalInformatics, Director of the Center for Medical Informatics, and Director of IT for theDepartment of Medicine at Mount Sinai Medical Center.Published online: 21 Dec 2006.

To cite this article: Guruduth Banavar , Jay Black , Ramón Cáceres , Maria Ebling , Edie Stern & Joseph Kannry (2005)Deriving Long-Term Value from Context-Aware Computing, Information Systems Management, 22:4, 32-42, DOI:10.1201/1078.10580530/45520.22.4.20050901/90028.4

To link to this article: http://dx.doi.org/10.1201/1078.10580530/45520.22.4.20050901/90028.4

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the information (the “Content”) containedin the publications on our platform. However, Taylor & Francis, our agents, and our licensors make norepresentations or warranties whatsoever as to the accuracy, completeness, or suitability for any purpose of theContent. Any opinions and views expressed in this publication are the opinions and views of the authors, andare not the views of or endorsed by Taylor & Francis. The accuracy of the Content should not be relied upon andshould be independently verified with primary sources of information. Taylor and Francis shall not be liable forany losses, actions, claims, proceedings, demands, costs, expenses, damages, and other liabilities whatsoeveror howsoever caused arising directly or indirectly in connection with, in relation to or arising out of the use ofthe Content.

This article may be used for research, teaching, and private study purposes. Any substantial or systematicreproduction, redistribution, reselling, loan, sub-licensing, systematic supply, or distribution in anyform to anyone is expressly forbidden. Terms & Conditions of access and use can be found at http://www.tandfonline.com/page/terms-and-conditions

32 W W W . I S M - J O U R N A L . C O M

F A L L 2 0 0 5

DERIVING LONG-TERM VALUE FROM CONTEXT-AWARE COMPUTING

Guruduth Banavar, Jay Black, Ramón Cáceres, Maria Ebling, Edie Stern, and Joseph Kannry

Modern businesses are increasingly dynamic in nature, which creates a need for computer systems that can sense and respond to rapid changes in the environment, or “context,” of the enterprise. This article presents the authors’ vision of a context “ecosystem” that helps enter-prises, applications, and developers respond to these dynamic changes and derive long-term value from context information. The ecosystem includes providers of raw context information, components that derive more abstract context information from lower level sources, middle-ware that provides systematic context services to applications, development tools, and con-text-aware applications.

ODERN BUSINESSES ARE DYNAMICin nature. To stay competitive, theyneed to optimize their business pro-cesses by understanding and reacting

to the rapid changes in their environment. Forexample, changes in market demand, invento-ry levels, transportation constraints, and sched-uling should ideally influence a supply chain.Similarly, current workload, availability, prox-imity, and expected travel time should affectinsurance claim handling. These and other ex-amples in domains as diverse as financial ser-vices, distribution, fleet management, andhealthcare suggest that business processescould be optimized and enhanced with suffi-cient information about the current and pro-jected states of the participating entities,combined with the ability to respond to thosechanges. This ability to adapt business process-es to changes in the environmental context isof growing interest to enterprises.

Custom solutions address some of theseproblems, but at a high cost. For example, com-panies have deployed fleet management appli-cations that track mobile resources andoptimize scheduling. The cost of building cus-tom solutions that exploit highly dynamic data

is prohibitive, and assets developed for one so-lution cannot easily be reused or extended forothers — even within the same domain. In ad-dition, when the data sources change, such aswhen an enterprise subscribes to a differentcellular provider for location information, theapplication must often change as a conse-quence.

Context-aware computing has been at-tempting to solve these kinds of problems in amore general and systematic manner for sometime. However, most of the attempts have beensmall-scale solutions within the confines of aroom or a building, where the data sources,points of data aggregation, and applications aresmall in number, limited in variety, and underthe control of a single organization. Althoughthis is a necessary first step, our experiencesuggests that the real value of context-awarecomputing can be realized only when these so-lutions scale to support a large and diverse setof sources and aggregation points that can bebuilt and managed by multiple stakeholders,but that remain open and reusable by third par-ties. For example, the supply chain examplementioned previously requires context datafrom retailers, warehouses, transportation

M

GURUDUTH BANAVAR heads the Pervasive Computing Infrastructure Department at the IBM T.J. Watson Research Center.

JAY BLACK is an associate professor in the School of Computer Science at the University of Waterloo, Ontario.

RAMÓN CÁCERES and MARIA EBLING are research staff members at the IBM T.J. Watson Research Center.

EDIE STERN is a Senior Technical Staff Member at IBM.

JOSEPH KANNRY is an Assistant Professor in Medicine as well as the Chief of the Division of Clinical Informatics, Director of the Center for Medical Informatics, and Director of IT for the Department of Medicine at Mount Sinai Medical Center.

UBIQUITOUS COMPUTING

Dow

nloa

ded

by [

UQ

Lib

rary

] at

00:

28 0

2 N

ovem

ber

2014

33I N F O R M A T I O N S Y S T E M S M A N A G E M E N T

F A L L 2 0 0 5

UBIQUITOUS COMPUTING

companies, and manufacturers routed throughdifferent service providers, each of which canbe owned and operated by a different business.Furthermore, this data can be aggregated toprovide useful services by third parties, such as“current demand for electronic toys” in oursupply chain example. We envision that anopen market will eventually emerge, com-prised of many independent application devel-opers and data providers. This will enable avariety of new business models. We refer to thiskind of large-scale, multi-party, open, extensi-ble system as a context ecosystem.

Context-aware computing has the potentialto become broadly established in a variety ofdomains. A context ecosystem is not specific toany particular domain, and so context sourcescommon to many domains (e.g., locationsources) can be shared and reused. The ecosys-tem will cover data adaptation from externalcontext sources, data analysis and compositioninto higher abstractions, and applications tak-ing context-influenced actions, with the sys-tem respecting the security of sensitive dataand the privacy rights of individuals. With suchan ecosystem in place, enterprises stand to de-rive value over the long term because applica-tions become easier to build and evolvegracefully as new components are added and astechnology improves.

It is important to note, however, that evenbefore context-aware computing develops tothis level, enterprises stand to derive valuefrom the context available within their own do-mains. Just as intranets provided business valuebefore the Internet matured, so too can intra-enterprise context provide business value be-fore the full context ecosystem emerges. Infact, this intra-enterprise use represents thefirst step toward realizing a context ecosystem.

The context ecosystem described here willneed to be supported by a comprehensivetechnological infrastructure. This article pre-sents an overview of this infrastructure neededfor a context ecosystem. We describe a proto-type of a comprehensive software infra-structure to build context-aware solutions in anextensible, reusable, and scalable way. This in-frastructure facilitates collecting, processing,and analyzing environmental context data andultimately enables dynamic changes to the realworld in response. We argue that the techno-logical infrastructure presented here is capableof supporting the requirements of a context eco-system.

The next section presents healthcare sce-narios, which we use as running examples in

the rest of the article. They motivate the re-quirements for a context ecology discussed inthe following section. The requirements, inturn, are used as background for the sectionthat surveys previous work in context-awarecomputing, leading to a presentation of our ar-chitecture and prototype. Finally, we describeour experience with the prototype and presentour conclusions and areas for further work.

HEALTHCARE SCENARIOSWe present scenarios in the healthcare domainin which we compare and contrast the activi-ties as they occur today and as they might oc-cur in the future within a context ecosystem.The present state presumes a paper-based hos-pital with clinical information available on onlya limited number of workstations and patientstatus monitored by lights and sounds at thefront desk, exploiting the patient’s proximityto the nursing station. The future state demon-strates the use of an intra-hospital context eco-system that improves patient safety andincreases operational efficiency:

❚❚ Patients are instrumented with vital-signmonitors and positioning devices (e.g., activeRFID tags).

❚❚ Physicians and nurses have wireless personaldigital assistants (PDAs), also instrumentedwith positioning technology (e.g., triangula-tion on 802.11 base stations).

❚❚ Context applications optimize physicianrounds, support nurse triage, simplify theuser interface to pervasive devices, provideadditional data for billing reconciliation, sup-port compliance with government require-ments, and provide clinical communications.

The right information, at the right time, inthe right way — in accordance with legislationsuch as the U.S. Health Insurance Portabilityand Accountability Act (HIPAA, 2005) — is theobjective. As technology, particularly pervasiveand sensor technology, undergoes rapid evolu-tion, middleware can play a crucial role in pro-viding a stable base for applications andbringing cohesion to this type of complex en-vironment.

Scenario 1Present State. Staff physician Dr. Ready ar-rives on the second floor of the hospital. Helooks at a sheet of paper with patient locationand some clinical information. This sheet of pa-per, called a SignOut, is generated by hand orprinted from the SignOut system (Kannry and

he future state demonstrates the use of an intra-hospital context ecosystem that improves patient safety and increases operational efficiency.

T

Dow

nloa

ded

by [

UQ

Lib

rary

] at

00:

28 0

2 N

ovem

ber

2014

34 W W W . I S M - J O U R N A L . C O M

F A L L 2 0 0 5

UBIQUITOUS COMPUTING

Moore, 1999; Kushniruk et al., 2003). Hemakes a quick decision about whether any ofthese patients need to be seen urgently and, ifnot, simply moves from room to room follow-ing the room number order. He has no ideawhether a patient is in his or her room or isaway because of a scheduled test or procedure.Dr. Ready enters the first room. After checkingthe bathroom, he determines that John Doe isoff the floor. Dr. Ready does not have time totrack down Mr. Doe or to determine when Mr.Doe will return. Finding out when Mr. Doe willbe back on the floor would be a multi-step pro-cess of looking for the nurse, walking to thefront of the floor, checking a transportationschedule, etc. When asked by his attendingphysician (supervisor) if Mr. Doe went for theechocardiogram this morning, Dr. Ready re-sponds that he thinks that’s where Mr. Doe isbecause the test was ordered yesterday. Dr.Ready pauses to record the necessary billing in-formation for the time required to visit Mr.Doe.

Dr. Ready walks into a room to see his nextpatient, April Dancer, and finds he has very lit-tle information on Ms. Dancer from the doctorwho admitted her. Valuable minutes tick by be-cause he has to leave the room to get more in-formation. He returns as Ms. Dancer is whiskedoff to diagnostic testing.

Future State. A physician, Dr. Able, arriveson the second floor of the hospital. A graphicappears on his PDA showing the rooms as-signed to his patients. Rooms are marked differ-ently depending on whether the patient iscurrently in the room. Because Mr. John Doe isnot currently in his room, the PDA also showshis current location and the time at which he isexpected to return. Ambulating patients are no-tified that the doctor is making rounds. As Dr.Able enters his next patient’s (April Dancer)room, a subset of her medical record, togetherwith her current vital signs, appears on thedoctor’s PDA. Dr. Able’s proximity to the pa-tient is logged, for input to (or reconciliationwith) billing applications. Dr. Able leaves theroom to see his next patient, while Ms. Danceris whisked off to diagnostic testing.

Scenario 2Present State. Sydney Bristow experiencesdifficulty breathing. Dr. Ready hears one of thenurses shouting, “Is there a doctor? … I needhelp!” Dr. Ready pulls out his SignOut sheet andfortunately finds Ms. Bristow on it. He realizes

there’s a lot he doesn’t know about Ms. Bris-tow, such as a complete list of medications, al-lergies, and the like. Neither the nurse nor thedoctor knows how long she has been short ofbreath, but it looks like she may need ventila-tion.

Future State. Sydney Bristow experiencesdifficulty breathing. The patient monitoring ap-plication, given her medical history, triggers analert that this is a serious condition. Notifica-tion is sent to the assigned nurse (Nurse Bak-er), to the nearest nurse (Nurse Charles), and,because he is in the hospital, to her primaryphysician (Dr. Able) identified by the SignOutsystem (physician coverage application). NurseCharles enters Ms. Bristow’s room. Nurse Bak-er and Dr. Able are notified that someone hasresponded. If no one had responded within areasonable time, the next care provider on theescalation path (e.g., the nursing supervisor onduty and Dr. Able’s coverage) would have beennotified (Kuperman et al., 1996; Wagner et al.,1999). The escalation path is, itself, contextsensitive.

Scenario 3Present State. Nurse Baker views her triagelist on the crumpled piece of paper on whichshe rapidly scribbled notes before the previousnursing shift left work. She looks over the listand makes decisions on priorities as best shecan. She was told all patients are stable and sim-ply decides to visit the patients room by room.

Future State. Nurse Baker views her triagelist on her PDA, where her assigned patientsare ordered according to an assessment of theircurrent need for her care (e.g., from sensors,call buttons, and medical history, etc.). The or-dering is determined by a combination of med-ical practice and hospital policy. Nurse Bakerdoes not see an electronic chart, but rather ared–yellow–green summary of vital signs alongwith the triage list. Jane Smith is clearly most inneed of her help, but along with the vital-signsummary, a notation shows that another nurseis with her. Nurse Baker proceeds to respondto the next most-critical patient.

Scenario 4Present State. Dr. Ready, an attending phy-sician, finishes patient rounds and now an-swers his pager, which has five pages he hasnot answered. All he knows is the phone num-bers. He has no context in terms of who paged

Dow

nloa

ded

by [

UQ

Lib

rary

] at

00:

28 0

2 N

ovem

ber

2014

35I N F O R M A T I O N S Y S T E M S M A N A G E M E N T

F A L L 2 0 0 5

UBIQUITOUS COMPUTING

him, why they paged him, or how urgent thepage is. A few hours later, while routinelychecking laboratory results, he discovers an ab-normal result and then goes to look for thechart. He then looks at the X-rays on a worksta-tion. Treatment is delayed by several hours(Tate et al., 1995). A few weeks later he findsout that one of the residents has violated gov-ernmental regulations on hours worked(Conigliaro et al., 1993; Kelly et al., 1991; Thor-pe, 1990).

Future State. Dr. Able, an attending physi-cian, finishes patient rounds. Now that he is nolonger “busy,” all pending nonemergency notifi-cations are presented on his PDA. There aretwo. One is a notification that one of the resi-dents under Dr. Able’s supervision is about toviolate governmental regulations on hoursworked per four-week period. The notificationis based on the resident’s schedule and on herlocation as logged within the hospital in thisfour-week period. Because the resident hasalso been notified, Dr. Able takes no action atthis time. The other notification is an important(but not urgent) lab result for Jane Smith. Dr.Able taps the lab result item and it appears onthe PDA, along with a subset of her electronicchart needed to make sense of the result. Hewalks to the nursing station to view Ms. Smith’sX-ray on a widescreen display. Based on hisproximity to the display, he is presented with apick list containing the last three patients seenas well as three other nearby patients. Dr. Ablereviews Ms. Smith’s data and decides on acourse of treatment.

DISCUSSION: THE VALUE OF A CONTEXT ECOSYSTEMThese four scenarios provide qualitative dem-onstrations of the value of context informationto physicians in their day-to-day tasks. Prelimi-nary studies have shown that availability of in-formation is a key determinant of utility tophysicians (Cohen et al., 1982; Covell et al.,1985; Curley et al., 1990). Handhelds provideimmediate availability. A workstation-based dis-play showing patient status, availability, andalerts by room number was tested and found tobe effective (Geissbuhler et al., 1997). Alertingstudies have found that time to respond de-creased significantly (Shabot et al., 2000; Ku-perman et al., 1999; Tate et al., 1995) whenalerting was automated and sent to a pager ortwo-way messaging device. A randomized con-trol trial by Kuperman and his colleagues

(1999) demonstrated a response time reduc-tion of 38 percent. Key features of the alertingsystem are coverage schedules and escalationalgorithms (Wagner et al., 1998; Wagner et al.,1999).

A context ecosystem can support futurestates as described in these scenarios. Adaptersgather raw context information such as vitalsigns, the location of individuals, or shift sched-ules. Data aggregators or “composers” processinformation from the adapters to yield higherlevel information (in this case, conditions con-stituting medical alerts and red–yellow–greensummaries of patient information for a nurse).Context also feeds into back-end systems (suchas accounting applications) and causes notifica-tions to be sent to people based on a rich rep-resentation of communication semantics. In amature ecosystem, manufacturers of medicaldevices provide context information in stan-dardized form and composer specifications re-duce the cost of producing context-awareapplications. New applications are built anddeployed quickly; in this scenario, they im-prove patient care, improve hospital efficiencyand auditability, and reduce nurse and physi-cian workloads for routine situations. Based onthe ability of a context ecosystem to supportfuture scenarios such as the ones above, we as-sert that a context ecosystem can bring long-term value to the healthcare domain.

REQUIREMENTS FOR A CONTEXT ECOSYSTEMAs described previously, the healthcare domainprovides a number of interesting and high-val-ue scenarios for context-aware applications. Itis also a demanding domain, with highly sensi-tive, rapidly changing biometric data requiringtimely evaluation and analysis, and for whichthe handling is constrained by national privacylaws. Broad and rapid adoption of the future-state scenarios described above is inhibited bythe lack of supporting middleware and appro-priate data sources — that is, by the lack of ahealthcare context ecosystem.

Biometric monitoring provides a good ex-ample. Such telemetry data today is analyzedby dedicated software, generally supplied bythe same company that supplies the sensor de-vice. A new source device requires the hospitalto purchase a new system for analysis. A patientmay be required to use the hospital sensorseven though a superior data source (e.g., an im-planted monitor) is available simply becausethe implanted device is incompatible with the

hese scenarios provide qualitative demonstrations of the value of context information to physicians in their day-to-day tasks.

T

Dow

nloa

ded

by [

UQ

Lib

rary

] at

00:

28 0

2 N

ovem

ber

2014

36 W W W . I S M - J O U R N A L . C O M

F A L L 2 0 0 5

UBIQUITOUS COMPUTING

hospital’s monitoring system. What is needed isthe ability to transform this data so it is usable,to preserve the privacy of the patient, and toprotect the application investment of the hos-pital. As the population ages and makes moreuse of remote biometric monitoring, scalabilityand manageability will become critical.

In addition to the healthcare industry, anumber of other industries have deployed cus-tom solutions using context data over the lastdecade. Location-based services (e.g., en-hanced 911) and sensor-based applications(e.g. utility-consumption monitoring) haveused context data in a variety of consumer ser-vices. Examination of the successes and fail-ures of such custom solutions suggests thatbroader requirements are necessary to take fulladvantage of what largely are a set of newlyavailable data sources.

A context ecosystem will include produc-ers of context data, providers of context-aware-ness middleware, developers of context-awareapplications, as well as system administratorsand end users. Based on our observations of ex-isting custom solutions, and the combinedneeds of these participants, we articulate elev-en general requirements for the technology in-frastructure of a context ecosystem:

❚❚ Valuable applications: First and foremost,the ecosystem must provide useful applica-tions that demonstrate a clear return oninvestment to all participants in the ecosys-tem, including the enterprises and the con-sumers.

❚❚ Low barriers to entry: Initial intra-enterpriseapplications will be developed using onlyone or two context sources. As the ecosys-tem matures, additional sources will be avail-able. To mature fully, the ecosystem needs acritical mass of context sources from adiverse set of data providers.

❚❚ Development tools: Developers require toolsto enable rapid context-aware applicationdevelopment. With such tools, developersshould be able to produce reusable compo-nents, feeding back into the ecosystem.

❚❚ Extensibility: It must be easy to add newkinds of context data. Adding new contextsources should not require changes to exist-ing applications.

❚❚ Open interchange: In an inter-enterpriseecosystem, precise, open specifications ofthe syntax and semantics of context data willenable the exchange of context informationamong unrelated individuals and organiza-tions. The use of open standards such as XML

will encourage interoperability, includingdata exchange protocols and data encodings.The syntax and semantics of context datamust also encompass a variety of metadata,such as quality of information, data origin, ordata cost.

❚❚ Aggregation: The system must make it easyto aggregate, filter, transform, and summa-rize data. Application developers, and even-tually data providers, will write composersand offer them as plug-ins to standard mid-dleware offerings.

❚❚ Security and privacy: Robust notions ofsecurity and privacy are essential to the suc-cess of a context ecosystem, especially inapplication areas such as healthcare wheregovernment requirements impose significantconstraints. Less stringent constraints on theprivacy of individuals and enterprises mustalso be accommodated, such as restricting towhom the location of a person can be dis-closed.

❚❚ Scalability: The system must support scal-ability along a number of dimensions. First, itmust cope with a growing number of diverseand geographically distributed data sourcesthat may dynamically come into and go outof existence. Second, because it must copewith a high volume of data elements comingfrom these sources, it must be capable ofaggregating and filtering this information set.Finally, it may need to support a large num-ber of applications and end users.

❚❚ Dynamic discovery: As this context ecosys-tem grows, querying the infrastructuredynamically for available context informa-tion becomes a critical requirement, as dothe dynamic discovery of evolving sourcesand the rebinding of composer instances tonew providers.

❚❚ Manageability: Large context ecosystemswill need to be autonomic systems, but willalso require tools to manage and administerthem, especially with context exchangesamong enterprises. Autonomy and manage-ability must be considered at design timerather than when failures occur. As the eco-system evolves into a multi-enterprise envi-ronment, it must cope with competinginterests and the lack of a single administra-tive authority.

❚❚ Actuation: Context-aware applications mayact on the environment in addition to observ-ing it. Although some applications may takedirect action, others may need the middle-ware to transform high-level, abstract actionsinto low-level, concrete operations.

context ecosystem will include producers of context data, providers of context-awareness middleware, developers of context-aware applications, as well as system administrators and end users.

A

Dow

nloa

ded

by [

UQ

Lib

rary

] at

00:

28 0

2 N

ovem

ber

2014

37I N F O R M A T I O N S Y S T E M S M A N A G E M E N T

F A L L 2 0 0 5

UBIQUITOUS COMPUTING

EXAMPLES OF CONTEXT-AWARE COMPUTING SYSTEMSA significant body of work exists in the generalarea of context-aware computing systems. Inthis section, we identify representative exam-ples in the areas of applications, middleware,and data sources and comment on how eachsatisfies a subset of the requirements just de-scribed.

ApplicationsSome of the earliest context-aware applica-tions were built around the use of location.The ActiveMap project (Want et al., 1992) an-notated the floor plans of a space with the lo-cation of people and objects. Similarly, theCyberGuide (Abowd et al., 1997) and Guide(Davies et al., 2001) systems concentrated onsupporting tourists (indoors in the case of Cy-berGuide and outdoors in the case of Guide).These early projects focused on the position-ing, networking, and device technologies. Theyshowed the relevance of context informationto specific application domains by offeringproofs of the concept. As a consequence, theystopped short of any concerted effort to sys-tematize their approach to some general formof context information. These applications re-main good examples of the types of applica-tions a context ecosystem must support.

Another early system, Cooltown (Kindbergand Barton, 2001), examined the use of Webtechnology in supporting users of pervasive de-vices interacting with their environment. Theauthors explored how content can be pulledfrom the environment onto the pervasive de-vice (e.g., display conference room serviceswhen entering a banquet hall) as well as howcontent could be pushed from the device tothe environment (e.g., push the URL for a pre-sentation to a projector or push an image froma user’s camera to a local printer). The user’sproximity to or interaction with a device locat-ed in the environment enabled this interaction.The interaction permitted small devices to re-act to the user’s context and also allowed thosedevices to control aspects of the environment.The focus of this work was on understandingthe interactions required to support a userwithin a particular location. It was not focusedon supporting the more general context eco-system we have outlined here, although a gen-eral context ecosystem should support thetypes of interactions these authors envisioned.

MiddlewareThe Context Toolkit (Dey et al., 2001) was oneof the first efforts to provide a more generalframework for supporting context-aware appli-cations. In this system, context widgets cap-ture raw context information from devices orapplications and retain it for possible historicalanalysis. Context interpreters combine one ormore pieces of context to produce a new item,and context aggregators present interfaces toall the context information related to a singleentity. Services execute actions on behalf of ap-plications and are closely tied to widgets; in-deed, the first implementation of servicesincorporated them into the associated widgets.“Discoverers” provide context registration anddiscovery services, and the authors also envis-age “situations” as an abstraction for combiningdisjoint pieces of context with complex condi-tions. The Context Toolkit contains support formany of the requirements identified previously,including aggregation, extensibility, and lowbarriers to entry, but faces challenges in the ar-eas of privacy, tooling, and manageability.

iQueue (Cohen et al., 2002) and Solar (Chenand Kotz, 2002) represent another approach toenabling context-aware applications. These sys-tems model context information as streams ofevents originating in a publish–subscribe sys-tem; events are encoded as serialized Java ob-jects. There is a tree- or graph-structuredhierarchy of operators, similar to what we havetermed composers in our ecosystem, and a hi-erarchical naming scheme for context data. TheiQueue system offers the first high-level ab-straction (Cohen et al., 2002) to allow develop-ers of context-aware applications to writequeries for needed data. iQueue and Solar fo-cus on many of the same requirements, includ-ing aggregation, extensibility, and scalability.iQueue provides more in the way of toolingthan Solar, but Solar provides more support inthe areas of privacy and dynamic source dis-covery. Neither system provides support formanageability or actuation.

As part of the Aura project (Garlan et al.,2002), Judd and Steenkiste (2003) developedthe Context Information Service (CIS). Theymodel context with four types of providers:people, areas, networks, and devices. Clientapplications issue queries against the CIS,which are processed by a query synthesizer todecompose them into simpler queries that canbe handled by the various context-informationproviders. The providers may compute queryresults dynamically, retrieve them froma cache, or perform an SQL query against a

ome of the earliest context-aware applications were built around the use of location.

S

Dow

nloa

ded

by [

UQ

Lib

rary

] at

00:

28 0

2 N

ovem

ber

2014

38 W W W . I S M - J O U R N A L . C O M

F A L L 2 0 0 5

UBIQUITOUS COMPUTING

normal relational database. Queries can in-clude references to metadata such as accuracy,confidence, update time, and sample interval.CIS focuses on support for aggregation and forquality of information (an aspect of the syntaxand semantics requirement). It also addressesscalability. The authors make no mention ofhow CIS approaches actuation, manageability,or dynamic source discovery, and it offers min-imal support in the way of tooling.

SourcesOther research has examined sources of con-text information. Given the importance of loca-tion as a source of context, a significantamount of work has been done in this area,which we will not review here. Interested read-ers are referred elsewhere for a survey of thiswork (Hightower and Borriello, 2001).

Beigl and his colleagues have examinedhow to augment everyday items, such as coffeemugs, to provide and respond to context infor-mation (Beigl et al., 2001). Researchers at theMIT Media Lab have also investigated addingcontext to everyday items, such as beds andtrivets (Leiberman and Selker, 2000).

The MUSE system (Castro and Muntz, 2000)explores the concept of fusion services that in-fer context information from sensor data. Thesystem uses Bayesian networks and applies aninformation–theoretic approach to estimate aprobabilistic indoor location from an IEEE802.11 network. Although the system also pro-vides some middleware support, the focus ofthis work falls into the area of data aggregationand interpretation.

Shafer and his colleagues explored visualcontext, multimodal interactions, and automat-ed behaviors as part of their Easy Living project(Shafer et al., 2001). They obtained visual con-text from cameras embedded in the environ-ment, using gaze direction to resolve objectreferences and presence near a device to acti-vate that device. This use of visual context is aninteresting example. In this case, both the in-put data (e.g., the camera feed) and the inter-pretation of that input (e.g., user gazing atlamp) can be viewed as forms of context infor-mation, yet the analysis of that data may needto be performed in the middleware, especiallyif that interpretation depends not just on thecamera input but also on the location obtainedfrom another source.

This brief survey shows the breadth of pre-vious work on context-aware computing andpoints out that none of that work has really

addressed the more comprehensive notion of acontext ecosystem and how it might be en-abled in a systematic fashion. We address this inthe next section.

ARCHITECTUREThis section describes the technological infra-structure of a context ecosystem designed toaddress the requirements presented in the pre-vious section. We also present a concrete exam-ple of the middleware component of such anecosystem.

Figure 1 presents a layered view of the tech-nology infrastructure underlying a context eco-system, as illustrated by our CxS prototype(Cohen et al., 2005). At the lowest level of theinfrastructure, raw information is obtainedfrom sources such as sensors, vehicles, devic-es, and software. Examples of such informationare the presence and contents of an RFID tag,the level of pollen sensed in the air, the weightand location of a vehicle, the contents of a per-son’s calendar, and the idle or busy status of aworkstation. The data sources can thus be ei-ther domain specific (e.g., glucose or cardiacmonitor) or domain independent (e.g., loca-tion, availability). In general, context sourcesmay push information to the middleware sponta-neously or may provide it in response to explicitrequests. These raw sources of information arewrapped by Adapters, which transform the na-tive information into a form that can flowacross the DataProvider interface. In our pro-totype, data transmitted across this interface isencoded with XML according to a schema spe-cific to each provider kind, and the transmis-sion can follow either a push or a pull model.These data sources represent basic data provid-ers.

The CxS middleware can be deployed on anetwork of server nodes. Inside one or moreCxS server, Composers process data objects re-ceived from adapters and other composers andmake that data more easily consumable by ap-plications. Composers can, in general, imple-ment arbitrary algorithms over their inputs,such as aggregation, summarization, and com-bination. For example, a composer might usethe state of a person’s computer keyboard andmouse, telephone, and office door to provideapplications with a good indication of “inter-ruptibility” (Fogarty et al., 2005). Similarly, thecurrent pollen count combined with a patient’slocation could be used by a medical applica-tion to suggest changes in medication dosage.At the highest level, composers in turn offer

t the lowest level of the infrastructure, raw information is obtained from sources such as sensors, vehicles, devices, and software.

A

Dow

nloa

ded

by [

UQ

Lib

rary

] at

00:

28 0

2 N

ovem

ber

2014

39I N F O R M A T I O N S Y S T E M S M A N A G E M E N T

F A L L 2 0 0 5

UBIQUITOUS COMPUTING

application-oriented context data via theDataProvider interface. The use of a commoninterface as input and output of the composersallows the infrastructure to support a hierarchyof composers.

Thus, the middleware layer is crucial to sat-isfying a number of our requirements. Theadapters, composers, and data provider inter-face support low barriers to entry, extensibili-ty, aggregation, and dynamic discovery. The useof XML enables the middleware to support theopen interchange of context data once the con-text ecosystem evolves to support open stan-dards.

Valuable applications are the driving forcebehind a context ecosystem. In our prototypeinfrastructure, applications submit queries fordata providers to the middleware and the mid-dleware responds with one or more data pro-viders satisfying the query. The applicationthen chooses one or more data providers andrequests (or subscribes to) the required data.As the actual data providers satisfying a querychange, the flow of data through the composerhierarchy is adjusted dynamically (Cohen et al.,2005). In this way, the desired information isreceived despite, for example, physical move-ment of an RFID-enabled package past a num-ber of individual RFID readers. This aspect ofCxS helps satisfy our requirement for dynamicdiscovery.

Using CxS, we have constructed compos-ers programmatically through Java program-ming interface, which we call the Java data-composition facility (JDCF), and through the

use of an abstract, high-level description,which we call iQL, of the computations theyperform (Cohen et al., 2002). We have also ex-perimented with building Eclipse-based toolsto support application and composer develop-ers, but tooling remains an area in need of ad-ditional exploration.

Our prototype middleware is designed toallow CxS servers to run independently onmany different machines, running in multipleadministrative domains. This feature supportsour scalability and manageability requirements.Our experience and tooling in these areas islimited, however, because this is currently anactive area of research.

Although some applications will simply re-trieve context information for use in support-ing their users, others may need to go beyondsimple sensing of the context to also effectingchanges. Notification is one of the most com-mon actions taken in response to dynamic da-ta. For example, an application might respondto location and traffic data by telling a driver toturn left in two blocks to avoid a traffic jam.This concept is shown in Figure 1 by the “ef-fecting” arrow at the top and the arrow into thenotification component. This aspect of CxShelps satisfy our requirement for actuation.

As we explored how to support context-aware applications, we recognized that onecould not responsibly build such support or ap-plications without also providing the ability tocontrol access to the information. Many cus-tom solutions we have seen either ignored theprivacy issue or built their system to avoid it

FIGURE 1 CxS Architecture

Application

Sensing Effecting

DataProvider

DataProvider

Adapters

Composers

CxS

Servers

Context Analysis,Abstraction,

Management

Notificationand Privacy

Management

Transactions, DB,Messaging

Sensors, Vehicles, Devices, Software...

Dow

nloa

ded

by [

UQ

Lib

rary

] at

00:

28 0

2 N

ovem

ber

2014

40 W W W . I S M - J O U R N A L . C O M

F A L L 2 0 0 5

UBIQUITOUS COMPUTING

(making the system significantly less useful).Instead, we chose to address the problem di-rectly. The goal of the Privacy Managementcomponent is to mediate the privacy concernsof both individuals and enterprises. No contextinformation is released by CxS without consul-tation of the Privacy Management component.We recognize that different entities (e.g., thehospital, patient, physician, and insurer) willhave different policies about context data. Thiscomponent allows CxS to control access in anappropriate fashion. This aspect of CxS helpssatisfy our requirement for security and privacy.

COMPONENT PROTOTYPES FOR A CONTEXT ECOSYSTEMAt the time of writing, prototypes for a numberof components that support the vision of a con-text ecosystem are underway. The CxS middle-ware presented in the previous section is acentral component. In addition, data providersand composers of various types have been de-veloped. Most importantly, we have proto-typed a number of applications in thedemanding domain of healthcare.

Adapters that allow the context middle-ware to obtain data from more than a dozen dif-ferent context sources have been prototyped,including sources such as:

❚❚ Location information (obtained from 802.11triangulation, active badges, and cell towerdata)

❚❚ Calendar scheduling (obtained from LotusNotes)

❚❚ Instant messaging presence (obtained fromLotus Sametime)

❚❚ Virtual activities (obtained from desktopcomputers and PDAs)

❚❚ Connectivity information (obtained from theWebSphere Everyplace Connection Man-ager)

❚❚ Telephone status (obtained from a PBX andfrom a VoIP soft phone)

❚❚ Web services (obtained from a weather siteand from a stock quotation site)

Each new source of context requires a shorttime (a day or two, in our experience) to inte-grate into the system.

A number of composers that aggregate thesedata sources into higher level context informa-tion have also been developed. These composersinclude one that monitors patient status by ag-gregating all telemetry for one patient. It gener-ates alerts for unusual data reported by thatpatient’s monitors. Another composer enhances

context information with more static informa-tion maintained in back-end databases.

Three prototype applications are describedbelow. Each of these prototypes thus far em-ploys human notification as the sole actuator.(Work on the design and implementation of“effecting” interfaces on the downward path,as implied by the dashed boxes in Figure 1, iscurrently under way.)

❚❚ Nursing triage application. The goal of thisapplication was to increase the efficiency ofthe nursing staff by showing each nurse asummary of the status of each patient in hisor her care. The application took data frommock biometric sensors (access to digitalbiometric sensors was not available at thetime), aggregated that data, analyzed it, andpresented a summary view in a Web-basedtriage display. A per-patient view allowed thenurse to access detailed data for eachpatient. The expectation is to develop thisprototype further with additional biometricsensors.

❚❚ Resident-hours monitoring application.The goal of this application was to verifycompliance to current U.S. regulations con-cerning the number of hours residents arepermitted to work in a hospital. Violatingthese regulations can result in a teaching hos-pital losing its accreditation. For this applica-tion, residents are given active badges andthe hospital entrances used by those resi-dents are instrumented with RFID readers. Inaddition, the application has access to theresidents’ schedules. With this information,the application tracks the hours worked byeach resident. If the rules are violated, theadministrator charged with supervising theresident is alerted immediately. More impor-tant, if completion of scheduled hours wouldplace a resident in violation of the regula-tions, the resident and the supervisor arenotified of the potential violation.

❚❚ Operating-room monitoring application.The goal of this application was to helpensure patient safety by verifying that thecorrect patient is in the correct operatingroom. Patients are outfitted with activebadges during their preoperation proce-dures. When a patient enters the operatingroom, the system detects this event and veri-fies that the patient is in the correct operatingroom based on operating-room schedules. Inthe event of an error, numerous alarms go off,including both audible and visual alerts. Inaddition, electronic notification messages are

ach of these prototypes thus far employs human notification as the sole actuator.

E

Dow

nloa

ded

by [

UQ

Lib

rary

] at

00:

28 0

2 N

ovem

ber

2014

41I N F O R M A T I O N S Y S T E M S M A N A G E M E N T

F A L L 2 0 0 5

UBIQUITOUS COMPUTING

sent to the staff in charge of the operatingroom. These alerts escalate until the situationis resolved.

CONCLUSIONMaking businesses responsive to dynamic,changing environments is crucial, and contextinformation is key to adapting to such environ-ments. This article has presented a vision of acontext ecosystem designed to help enterpris-es respond to such environments and generalrequirements for a technology infrastructure tosupport it. Because the ecosystem is not specif-ic to any particular domain, context sourcescommon to many domains can be shared. Wehave argued that such an ecosystem enablesenterprises to derive value over the long termbecause applications become easier to buildand evolve gracefully as technology improves.

This article has also described a key compo-nent of the context ecosystem — a middlewaresystem prototype (CxS) that provides contextinformation to applications and services — aswell as application prototypes for a healthcarecontext. For a context ecosystem to evolve, fur-ther work is needed in a number of areas. First,a critical mass of context data sources must beavailable to application developers “out of thebox,” to reduce the effort needed to make newapplications context aware and the benefits ofusing the middleware immediate and obvious.Second, there must be standardization of theexchange of context information. Third, thesoftware infrastructure must be scalable, tosupport large numbers of possibly verbose con-text sources. Finally, it is clear that we need arich set of tools that can effectively open thepower of context technologies to developers.

ACKNOWLEDGMENTSThis work was done while one of the authors,Jay Black, was on sabbatical at the IBM TJ Wat-son Research Center. This article has built onthe work of the entire Context Technologiesteam at IBM and has benefited greatly from thecomments of Norman Cohen, the support ofBarry Leiba, and the applications built by Mari-on Blount, John Davis, Archan Misra, WolfgangSegmuller, and Daby Sow. ▲

ReferencesAbowd, G.D., C.G. Atkeson, J. Hong, S. Long,

R. Kooper, and M. Pinkerton (1997). Cyberguide: A Mobile Context-Aware Tour Guide, Wireless Networks, 3(5):421–33.

Beigl, M., H.-W. Gellersen, and A. Schmidt (2001). Mediacups: Experience with Design and Use of Computer-Augmented Everyday Artefacts, Computer Networks, 35(4):401–09.

Castro, P. and R. Muntz (2000). Managing Context Data for Smart Spaces, IEEE Personal Communications, 7(5):44–46.

Chen, G. and D.Kotz (2002). Context Aggregation and Dissemination in Ubiquitous Computing Systems, Proceedings of the Fourth IEEE Workshop on Mobile Computing Systems and Applications (WMCSA), Callicoon, NY, 105–14.

Cohen, N.H., H. Lei, P. Castro, J.S. Davis II, and A. Purakayastha (2002). Composing Pervasive Data Using iQL, Proceedings of the Fourth IEEE Workshop on Mobile Computing Systems and Applications (WMCSA), Callicoon, NY, 94–104.

Cohen, N.H., P. Castro, and A. Misra (2005). Descriptive Naming of Context Data Providers, Proceedings of the Fifth International and Interdisciplinary Conference on Modeling and Using Conference (CONTEXT-05), Paris, France, forthcoming.

Cohen, N.H., A. Purakayastha, L. Wong, and D.L. Yeh (2002). iQueue: A Pervasive Data-Composition Framework. Proceedings of the Third International Conference on Mobile Data Management, Singapore, 146–53.

Cohen, S.J., M. Weinberger, S.A. Mazzuca, and C.J. McDonald (1982). Perceived Influence of Different Information Sources on the Decision-Making of Internal Medicine House Staff and Faculty. Social Science and Medicine, 16(14):1361–4.

Conigliaro J., W.H. Frishman, E.J. Lazar, and L. Croen (1993). Internal Medicine Housestaff and Attending Physician Perceptions of the Impact of the New York State Section 405 Regulations on Working Conditions and Supervision of Residents in Two Training Programs. Journal of General Internal Medicine, 8(9):502–7.

Covell, D.G., G.C. Uman, and P.R. Manning (1985). Information Needs in Office Practice: Are They Being Met? Annals of Internal Medicine, 103(4):596–9.

Curley, S.P., D.P. Connelly, and E.C. Rich (1990). Physicians’ Use of Medical Knowledge Resources: Preliminary Theoretical Framework and Findings. Medical Decision Making, 10(4):231–41.

Davies, N., K. Cheverst, K. Mitchell, and A. Efrat (2001). Using and Determining Location in a Context-Sensitive Tour Guide, Computer, 34(8):35–41.

Dey, A.K. (2001). Understanding and Using Context, Personal and Ubiquitous Computing Journal, 5(1):4–7.

Dey, A.K., D. Salber, and G.D. Abowd (2001). A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications. Human–Computer Interaction (HCI) Journal, 16(2–4):97–166.

aking businesses responsive to dynamic, changing environments is crucial, and context information is key to adapting to such environments.

M

Dow

nloa

ded

by [

UQ

Lib

rary

] at

00:

28 0

2 N

ovem

ber

2014

42 W W W . I S M - J O U R N A L . C O M

F A L L 2 0 0 5

UBIQUITOUS COMPUTING

Fogarty, J., S.E. Hudson, C.G. Atkeson, D. Avrahami, J. Forlizzi, S. Kiesler, J.C. Lee, and J. Yong (2005). Predicting Human Interruptibility with Sensors, ACM Transactions on Computer–Human Interaction, 12(1):119–46.

Garlan, D., D.P. Siewiorek, A. Smailagic, and P. Steenkiste (2002). Project Aura: Toward Distraction-Free Pervasive Computing, IEEE Pervasive Computing, 22–31.

Geissbuhler, A., J.F. Grande, R.A. Bates, R.A. Miller, and W.W. Stead (1997). Design of a General Clinical Notification System Based on the Publish-Subscribe Paradigm. Proceedings of the American Medical Informatics Association (AMIA) Annual Fall Symposium, Nashville, TN, 126–30.

Hess, C.K. and R.H. Campbell (2003). A Context-Aware Data Management System for Ubiquitous Computing Applications, Proceedings of the International Conference on Distributed Computing Systems (ICDCS), Providence, RI.

Hightower, J. and G. Borriello (2001). Location Systems for Ubiquitous Computing, IEEE Computer, 34(8):57–66.

HIPAA (2005). Information available at www.hipaa.org.

Judd G., and P. Steenkiste (2003). Providing Contextual Information to Pervasive Computing Applications, Proceedings of the First IEEE International Conference on Pervasive Computing and Communications (PerCom), 133–42.

Kannry J. and C. Moore (1999). MediSign: Using a Web-based SignOut System to Improve Provider Identification, Proceedings of the American Medical Informatics Association (AMIA) Symposium, Washington, D.C., 28(6):550–4.

Kelly A., F. Marks, C. Westhoff, M. Rosen (1991). The Effect of the New York State Restrictions on Resident Work Hours. Obstetrics & Gynecology, 78:468–73.

Kindberg, T. and J. Barton (2001). A Web-Based Nomadic Computing System, Computer Networks, 35(4):443–56.

Kuperman, G.J., J.M. Teich, D.W. Bates, F.L. Hiltz, J.M. Hurley, R.Y. Lee, and M.D. Paterno (1996). Detecting Alerts, Notifying the Physician, and Affering Action Items: A Comprehensive Alerting System, Proceedings of the American Medical Informatics Association (AMIA) Symposium, Washington, D.C., 704–8.

Kuperman, G.J., J.M. Teich, M.J. Tanasijevic, N. Ma’Luf, E. Rittenberg, A. Jha, J. Fiskio, J. Winkelman, and D.W. Bates (1999). Improving Response to Critical Laboratory Results with

Automation: Results of a Randomized Controlled Trial. Journal of the American Medical Informatics Association, 6(6):512–22.

Kushniruk A., T. Karson, C. Moore, and J. Kannry (2003). From Prototype to Production System: Lessons Learned from the Evolution of the SignOut System at Mount Sinai Medical Center. Proceedings of the American Medical Informatics Association (AMIA) Symposium, 381–5.

Leiberman, H. and T. Selker (2000). Out of Context: Systems That Adapt To, and Learn From, Context, IBM Systems Journal, 39(3–4): 617–32.

Román, M., C.K. Hess, R. Cerqueira, A. Ranganathan, R.H. Campbell, and K. Nahrstedt (2002). A Middleware Infrastructure for Active Spaces, IEEE Pervasive Computing, 1(4):74–83.

Shabot, M.M., M. LoBue, and J. Chen (2000). Wireless Clinical Alerts for Physiologic, Laboratory and Medication Data. Proceedings of the American Medical Informatics Association (AMIA) Symposium, Los Angeles, CA, 789–93.

Shafer, S.A.H., B. Brumitt, and J. Cadiz (2001). Interaction Issues in Context-Aware Intelligent Environments, Human–Computer Interaction, 16(2–4):363–78.

Tate, K.E., R.M. Gardner, and K. Scherting (1995). Nurses, Pagers, and Patient-specific Criteria: Three Keys to Improved Critical Value Reporting. Proceedings of the Nineteenth Annual Symposium on Computer Applications in Medical Care, New Orleans, LA, 164–8.

Thorpe, K.E. (1990). House Staff Supervision and Working Hours: Implications of Regulatory Change in New York State [see comments]. Journal of the American Medical Association, 263(23):3177–81.

Wagner, M.M., S.A. Eisenstadt, W.R. Hogan, and M.C. Pankaskie (1998). Preferences of Interns and Residents for E-mail, Paging, or Traditional Methods for the Delivery of Different Types of Clinical Information, Proceedings of the American Medical Informatics Association (AMIA) Symposium, Orlando, FL, 140–4.

Wagner, M.M., F.C. Tsui, J. Pike, and L. Pike (1999). Design of a Clinical Notification System, Proceedings of the American Medical Informatics Association (AMIA) Symposium, Washington D.C., 989–93.

Want, R., A. Hopper, V. Falcao and J. Gibbons (1992). The Active Badge Location System, ACM Transactions on Information Systems, 10(1):91–102.

Dow

nloa

ded

by [

UQ

Lib

rary

] at

00:

28 0

2 N

ovem

ber

2014