© 2005 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for

creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained

from the IEEE.

For more information, please see www.ieee.org/portal/pages/about/documentation/copyright/polilink.html.

MOBILE AND UBIQUITOUS SYSTEMS

www.computer.org/pervasive

Pervasive Computing Support for Hospitals: AnOverview of the Activity-Based Computing Project

Jakob E. Bardram and Henrik B. Christensen

Vol. 6, No. 1January–March 2007

This material is presented to ensure timely dissemination of scholarly and technicalwork. Copyright and all rights therein are retained by authors or by other copyright

holders. All persons copying this information are expected to adhere to the terms andconstraints invoked by each author's copyright. In most cases, these works may not be

reposted without the explicit permission of the copyright holder.

44 PERVASIVEcomputing Published by the IEEE Computer Society ■ 1536-1268/07/$25.00 © 2007 IEEE

Pervasive ComputingSupport for Hospitals: An Overview of the Activity-BasedComputing Project

Aprofessional hospital staff’s work ischallenging to pervasive computingresearchers in several ways. Cliniciansmust handle large volumes of shareddata such as patient records and x-

rays. Their work is team oriented, with much col-laboration between different fields of expertise. It’snomadic because treatment involves talking to

patients, attending conferences,and conferring with colleagues—and physicians and nurses don’tusually have desks. Their envi-ronment is hectic and filled withdisruptions, so they must mem-orize several parallel pendingactivities. And they need quick

access to relevant data for alternating work situa-tions while keeping sensitive medical data private.

However, even though hardware has seen manybreakthroughs—making computers small, wear-able, and mobile—the software infrastructure hasevolved surprisingly little. Operating systems andapplications running on small devices are basicallyscaled-down implementations of desktop softwarethat supports stationary, noncollaborative workon private data in an office setting—that is, char-acteristics that are directly opposite of those thatdistinguish the reality of clinicians’ work. This put

our research group in an odd position. We coulddemonstrate all sorts of wonderful devices for clin-icians—wall displays for large x-rays and bulkyinformation networked with PDAs—but the avail-able software infrastructure hindered our visionsof software that would ease secure data access, col-league collaborations, and pending and paralleltask management.

As an illustration, consider a physician trying tofind a diagnosis for a patient. Our field workshowed that this process is typically lengthy andincremental, gathering bits of information in manydifferent locations. For example, at the patient’sbedside, the physician enters notes in the electronicpatient record (EPR). During the radiology con-ference, the physician studies x-ray images with aradiologist. At the morning conference, the physi-cian discusses proper medication with colleagueswhile browsing medicine catalogs. Later, the labreleases a blood sample result, and the physicianmust study it with a colleague. So, the physicianmust have access to many applications that showthe proper data in different locations, while stilltending to other activities and usually sharingmaterial with colleagues. Prevailing operating sys-tems introduce a lot of overhead because the physi-cian must constantly log in and out of devices athand, starting and stopping sets of applications,

The activity-based computing project researched pervasive computingsupport for clinical hospital work. Such technologies have potential for supporting the mobile, collaborative, and disruptive use ofheterogeneous embedded devices in a hospital.

H E A L T H C A R E

Jakob E. BardramIT University of Copenhagen

Henrik B. ChristensenUniversity of Aarhus

and browsing each to present the properview for alternating activities.

Our response to these challenges hasbeen activity-based computing, which letsusers organize their handling of devices,services, and data in terms of computa-tional activities that facilitate recreating,sharing, and swiftly switching computa-tional context on demand at whateverdevice is at hand.

Research processABC’s principles result from a user-

centered design process. It began in 2001as a joint project between a major DanishEPR vendor, a large university hospital,and the Centre for Pervasive Healthcare.Building on the ABC project’s long his-tory, the current design principles andtechnology crystallize solutions for nu-merous fundamental challenges in de-signing computer technology for medicalwork in hospitals.

The ABC project has followed an iter-ative design process, addressing five med-ical themes that reflect major workingareas in large hospitals: medicine admin-istration by nurses, medicine prescriptionby physicians, collaboration between clin-icians, medical conferences, and surgery.Each theme has engaged in the followingresearch activities:

• extensive field studies of medical workin hospitals, which identify core aspectsof medical work and existing technol-ogy use;

• a vision workshop for problem identi-fication, idea generation, and focus se-lection;

• a design workshop for moving toward

a specific design of pervasive comput-ing technology;

• a prototype implementation of the pro-posed pervasive computing technology;and

• an evaluation workshop at which theresearch prototype was presented tothe clinicians, who then used and eval-uated it.

In all stages, clinicians have beenheavily involved: more than 20 clini-cians (including nurses, physicians, sur-geons, anesthesiologists, radiologists,and pharmacists) have participated inthe project, and we’ve conducted morethan 15 day-long workshops for evalu-ating our design and technology. Clini-cians who had never been introduced toABC and had not seen our frameworkparticipated in four of these evaluationworkshops.

Each workshop lasted approximatelysix hours. We applied scenario-based eval-uation methods, asking clinicians to role-play several clinical scenarios. We video-taped and later analyzed all workshops.The evaluation illustrated how an EPRwould look if built using the ABC frame-work. This included EPR applications

such as

• a medicine schema, which providedan overview of a patient’s prescribedmedicine and contained tools for pre-scribing and administering medicine;

• medical data charts, which containedcharts on a patient’s blood pressure,pulse, temperature, and weight; and

• an x-ray viewer, which showed anoverview of a patient’s most recentradiology images.

Figure 1 shows the test facilities’ basiclayout (the layout varied from workshopto workshop, but figure 1 illustrates thebasic components in our test setup). Wemodeled a large room as a hospital wardwith a bed room, a medicine room, asmall team conference room, and a hall-way connecting these rooms. In addition,we used a remote room (not shown) asthe radiology conference room. Figure 2shows pictures taken during the evalua-tion sessions.

Reflecting on this design process, themost striking observation is that the fivethemes didn’t result in five singular solu-tions addressing the challenges withineach theme. Instead, proposals gradu-

JANUARY–MARCH 2007 PERVASIVEcomputing 45

Medicine room Bed ward

Hallway

Medicine cabinet withmedicine and a built-in computer

Conference table witha built-in computer

Wall display

Team room

The context-aware hospital bedwith a built-in computer

Figure 1. The layout of our “Future Hospital” evaluation facility configured to resemble a hospital ward. The wardcontained a medicine room, a team conference room, a bed ward, and a hallway.

ally merged into a coherent conceptualand technical framework that success-fully addressed the range of challengessimultaneously. We think that one of theABC project’s main contributions is thatthe ABC concepts and technical princi-ples constitute a coherent conceptualframework for a pervasive computingplatform, which supports a wide rangeof pervasive computing aspects, rangingfrom mobility to collaboration to con-text-aware computing.

Other projects have explored aspectsof our principles (see the Related Worksidebar), but to the best of our knowledge,none has intensively tested them involvingpeople outside the research groups ordomain experts in realistic settings.

Activity-based computing principles

Our work within the five themes leadto a number of principles that underlieABC.

Activity centeredClinicians must handle a large amount

of data that’s often tied to specific workactivities. However, when studying howclinicians are using computers, differentcomputer applications often support dif-ferent parts of an activity. For example,a picture, archiving, and communicationsystem (PACS) supports the applicationfor viewing x-ray images, the medicineschema is shown as part of an EPR, andordering blood tests is part of a bookingand scheduling system. Although all theseapplications support the same human

activity, such as diagnosing a patient,there’s little support for aggregatingrelated sets of applications, services, anddata into the logic bundle associated withthis activity. Consequently, cliniciansspend considerable time starting appli-cations, finding proper data, browsing,and navigating user interfaces to presentall relevant information.

The principle of activity-centered com-puting suggests that computational activ-ities should be a first-class object in thecomputing environment along with, forexample, files and applications. A com-putational activity (“activity” for short)bundles a coherent set of applications,their associated data and resources, andthe user interface state needed to supporta specific human activity. Figure 3 illus-trates how an activity groups togetherrelated services and applications and rel-evant medical data.

An activity-centered computing plat-form significantly reduces the users’overhead of starting applications, databrowsing, and user interface navigation:the activity embodies all this informa-tion, and when the users select it, theactivity-based platform performs all thissetup. Because many types of clinicalactivities are recurring, support for re-using activities, cloning them, or usingactivity templates helps clinicians set uprelevant digital working environmentsthat contain the needed services andreadily accessible data.

In our evaluations of the ABC tech-nology, users appreciated the support foraggregating related resources into activ-

ities. Collecting patient-related informa-tion into one activity had an immediatebenefit and was clearly useful. But thesupport for creating other activitiesacross a set of patients—for example, aradiology conference activity containingdata from patients with the same prob-lem—was also useful. In most EPR sys-tems, all interaction centers on thepatient, making it difficult to bundle datafor multiple patients in, for example, aconference situation. ABC’s activity con-cept doesn’t include semantics, so theuser is free to bundle any applicationsand resources in an activity. We call suchactivities lightweight because they aren’tsemantically restricted to, for example,one patient.

This lightweight property was, how-ever, a challenging part of ABC. Becausean activity carries no semantics, it wasoften hard for clinicians to distinguishactivities. A recurrent observation wasthat one activity merged into another—there was no clear demarcation of whereone activity (for example, prescribingmedicine for patient A) ended and whereanother (looking at medical data forpatient B) began. This problem surfacedwhen a physician would perform anactivity labeled “prescription for Mr.Hansen” and then also look up medicaldata for Ms. Pedersen. This causedmuch confusion because our prototype’sactivity browser showed the name “Mr.Hansen” when the underlying data inthe EPR concerned “Ms. Pedersen.”Furthermore, when should you create anew activity—when doing the same

46 PERVASIVEcomputing www.computer.org/pervasive

H E A L T H C A R E

(b)(b) (c)(a) (b)

Figure 2. Evaluation workshops included (a) activity roaming and discovery during patient medication, (b) a radiologist in asynchronous sharing activity, and (c) a clinician roaming the activity to the wall display while engaging in activity sharing.

JANUARY–MARCH 2007 PERVASIVEcomputing 47

S everal other projects and systems have explored aspects or

principles similar to those developed in activity-based com-

puting. We distinguish between two types of related work:

• projects that researched the activity-centered approach and

• projects that researched architectural, technical, and user-

oriented aspects relevant for activity-based computing.

The first group is rather small. The most comparable work is

Project Aura,1 which is similar to ABC in its research question

and proposed architecture. It also explores the activity concept

(denoted tasks), suspend-resume, and roaming. However, Aura

hasn’t reported discovery results or explored the collaboration

aspect that’s vital in hospitals and other domains. Furthermore,

ABC has tested the principles in practical real-life settings, while

Aura has focused on technical evaluations.

The IBM Unified Activity Management project proposes an

activity as an explicit computation construct supported by an

infrastructure.2 UAM’s activity concept embodies human intent

and purpose, which works as a semantic glue between users’

tasks and computational objects such as email, calendar entries,

chats, WWW resources, and so forth. In comparison, the ABC

approach is more lightweight; a computational activity only

bundles applications, leaving users to define the bundle’s se-

mantics. Domain-specific semantics is useful, however, and it

would be interesting to combine the approaches.

Numerous projects in the second group have explored issues

similar to those arising in ABC. ABC’s central principles are ac-

tivity suspend-resume and roaming, which entail state preser-

vation and migration between devices. Similar techniques are

central in process migration and have been explored in various

contexts, including operating systems, programming languages,

and agent systems.3 Typically, the process state is device de-

pendent (for example, on memory contents or the processor

state) and might use a binary image as a snapshot. Although

agent systems such as MASIF4 and MetaGlue5 allow agent mi-

gration over heterogeneous devices, they still rely on a compa-

rable execution environment such as a Java virtual machines or

CORBA middleware. ABC, in contrast, represents state in a form

independent of the operating system and application details.

Different research projects have presented approaches to

seamlessly switch between different sets of applications.

Rooms6 was the first to introduce virtual desktops, allowing

users to arrange applications in “rooms” and easily switch

between them. GroupBar7 and Task Gallery8 are recent exam-

ples in this tradition, where “tasks” are defined as sets of appli-

cations. However, these systems are mainly window mana-

gers, so they don’t support adaptation, roaming, sharing, or

discovery. The SunRay system (http://sun.com/sunray) sup-

ports roaming of running X Window sessions running on a

server, but ABC adds support for persistence, collaboration,

and adaptation over heterogeneous devices.

Finally, medical-informatics research has recognized the need for

making medical applications that are aware of clinicians’ tasks—for

example, as workflow support systems9 or clinical guideline sys-

tems.10 However, these systems are clinical applications supporting

the flow of medical work and, as such, aren’t basic middleware

support for pervasive computing.

REFERENCES

1. D. Garlan et al., “Project Aura: Toward Distraction-Free Pervasive Com-puting,” IEEE Pervasive Computing, vol. 1, no. 2, 2002, pp. 22–31.

2. T. Moran, “Unified Activity Management: Explicitly Representing Activ-ity in Work-Support Systems,” ECSCW 2005 Workshop Activity: From a The-oretical to a Computational Construct, 2005; www.daimi.au.dk/~bardram/ecscw2005.

3. D.S. Milojicic et al., “Process Migration,” ACM Computing Surveys, vol.32, no. 3, 2000, pp. 241–299.

4. D. Milojicic et al., “MASIF: The OMG Mobile Agent System Interoperabil-ity Facility,” Personal Technologies, vol. 2, no. 2, 1998, pp. 117–129.

5. M. Coen et al., “Meeting the Computational Needs of Intelligent Envi-ronments: The MetaGlue System,” Proc. 1st Int’l Workshop ManagingInteractions in Smart Environments (MANSE 99), Springer, 1999, pp.201–212.

6. J.A. Henderson and S. Card, “Rooms: The Use of Multiple Virtual Work-spaces to Reduce Space Contention in a Window-Based Graphical UserInterface,” ACM Trans. Graphics, vol. 5, no. 3, 1986, pp. 211–243.

7. G. Smith et al., “GroupBar: The TaskBar Evolved,” Proc. OZCHI 2003,2003, pp. 34–43.

8. G. Robertson et al., “The Task Gallery: A 3D Window Manager,” Proc.SIGCHI Conf. Human Factors in Computing Systems (CHI 00), ACM Press,2000, pp. 494–501.

9. F. Malamateniou and G. Vassilacopoulos, “Developing a Virtual PatientRecord Using XML and Web-Based Workflow Technologies,” Int’l J.Medical Informatics, vol. 70, July 2003, pp. 131–139.

10. P. Ciccarese et al., “Architectures and Tools for Innovative Health Infor-mation Systems: The Guide Project,” Int’l J. Medical Informatics, vol. 74,July 2005, pp. 553–562.

Related Work in Activity Support

48 PERVASIVEcomputing www.computer.org/pervasive

H E A L T H C A R E

activity (for example, writing prescrip-tions) for a new patient or when shiftingto a new activity altogether (for exam-ple, from writing prescriptions to dis-persing medicine)?

In general, the cost of using activity-centered computing is the need for theuser to create and manage activities.Based on observations during the work-shops, different solutions for loweringthis overhead emerged, including sup-port for activity templates for frequentlyused activities and a post hoc bookmarkof an important place in the unfoldingof activities. For example, if the physi-cian had finished caring for Ms. Peder-sen, he could bookmark the activity andlater recollect his treatment of her in hisoffice. These solutions gradually mergedinto the overall principle of activity dis-covery that’s designed to mitigate thecost associated with handling activities.

Activity discoveryThis principle suggests that the com-

puting infrastructure should help usersidentify, create, and manage activities ineveryday work. On the basis of recur-ring activity heuristics and context infor-mation regarding location, and by usingprototypical activity templates, the infra-structure should be able to hypothesizewhat activities are going on and prepare

relevant computational resources forclinicians’ use. Experiments have testedboth procedural and logic-programmingtechniques to handle activity discovery.1

For example, by combining knowledgeabout a medicine-administration activ-ity template, the patient’s identity, andthe medicine tray closest to a nurse (asreported by a location-and-context-awareness system), ABC’s infrastructurecan retrieve and display relevant med-ical information and services for thenurse’s use. Similarly, in our current useof ABC technology in operating rooms,the technology’s infrastructure createsactivities on the basis of knowledgeabout scheduled operations. Such activ-ities contain links to the patient’s med-ical record and recording equipment inthe room (that is, to data and servicesthat the surgeon might need during theoperation).

Activity discovery’s main benefit isthat it lowers the overhead of creatingactivities by supporting semicreation ofrelevant activities for a specific work sit-uation. The main drawback of these prin-ciples is the possibility of creating trivialor meaningless activities that could dis-tract or confuse the user rather than help.During the evaluation, clinicians deemedactivity discovery useful in certain situa-tions, especially where there’s a simple

relationship between some real-worldcontext information and a relevant activ-ity. This typically applied to nurses’ work,such as dispensing medicine. Activity dis-covery was less obvious in other cases,such as creating activities to support out-patient treatment. This couldn’t wait un-til the patient was at the physician’s officebut had to be created earlier to preparethe physician for the consultation. Rele-vant context information doesn’t just in-clude the physical context but also thedigital context (that is, the daily sched-ule of outpatient consultations can revealrelevant activities for the physician). Weuse this approach in our current activitydiscovery for supporting surgical opera-tions.

Activity suspend-resumeHospital physicians are typically re-

sponsible for the treatment of 10 to 15in-hospital patients and for 100 ormore patients in the outpatient clinic.In addition, they often have research,teaching, and administrative responsi-bilities. So, physicians juggle many con-current activities that require differentlevels of attention during a day. Andbecause all hospital work is highly col-laborative, interruptions are frequent.

The activity suspend-resume principlesuggests that users should be able toquickly switch between activities. So,while working on activity A, the user canselect activity B, reconfiguring the com-puting device with B’s applications, data,and user interface state. This suspendsactivity A, which is then dormant untillater resumed.

The benefit is that the platform sup-ports many parallel activities, largelyavoiding interruptions in the workflowdue to the overhead of starting an appli-cation and browsing the user interface.Selecting any pending activity does this

Levels ofabstraction

120966-0089 Inger Pedersen [Leukemia}Activity

Applicationand service

Medicalrecord X-ray

images Bloodtest

results Medicalcharts

Data file anddocument Self-

Self-

Figure 3. The activity labeled “120966-0089 Inger Pedersen [Leukemia]” is usedto bundle a set of services and associateddata relevant for Ms. Pedersen’s leukemiatreatment.

automatically. As such, support for ac-tivity suspend-resume is somewhat sim-ilar to virtual desktops as pioneered byRooms.2 At the user interface level inour ABC prototypes, we experimentedwith a real task bar that switches be-tween activities and not applications (asis the case in Windows).

Our evaluations of the ABC technol-ogy clearly showed that support for han-dling multiple parallel activities usingsuspend-resume in a medical setting wasuseful. The clinicians typically createdone activity for each patient, and theyfrequently suspended and later resumedsuch activities during the workshops.Activities were also saved across work-shops so that the users could keep themthroughout the evaluation period. Thesupport for saving the user interface’sexact state was deemed crucial in thesupport for fast switching between activ-ities; when users resumed an activity,they would return to the same look-and-feel as when they left the activity.

Activity roamingClinical work is nomadic. A typical

working day for the average physicianor nurse involves walking several kilo-meters—for one nurse that we followedduring our field work, up to 14 km dur-ing a shift. Clinicians’ activities aren’ttied to a specific location but ofteninvolve a few small steps in many dif-ferent places.

The principle of activity roaming sup-ports nomadic and mobile computing byletting clinicians resume computationalactivities on arbitrary devices, includingembedded and handheld devices.

By decoupling computational activi-ties from computational devices, weessentially decouple the clinician’s activ-ities from specific locations in the hos-pital; for example, the physician canresume writing a prescription anywhereif he or she has access to a device. Weused activity roaming consistently dur-

ing the evaluation workshops, and clin-icians appreciated the ability to suspendwork in one location and resume it laterin another. For example, a nurse would

walk back and forth between the medi-cine room and the bed ward (see figure2a) numerous times each day, so havingactivity roaming in these places wasessential. Physicians who roam aroundthe entire hospital found the activity-roaming support even more useful. Wefound that activity roaming is a funda-mental requirement in creating efficienthospital information systems.

Although our technology lets usersroam activities to a PDA or a mobilephone, this didn’t make much sensebecause these devices provide little or noview on medical data. So, in the evalua-tion workshops, we used larger displays(at least 1,024 � 768 pixels), includingtablet PCs, laptops, desktop PCs, andwall displays (see figure 2c). Earlier ver-sions of the ABC technology had no sup-port for adapting the activity to differ-ent screen resolutions, but we addressedthis problem in later versions with anactivity-zooming feature.3

Activity sharingMedical work in general, and in hos-

pitals in particular, is highly collabora-tive owing to the specialized nature ofmedical treatment. Treatment and careare inherently distributed among differ-ent medical doctors, nurses, and careassistants, who need to collaborateacross time, space, and organizationalboundaries.

The principle of activity sharing states

that an activity lists participants who canall access and use it. Activities can beshared asynchronously when two ormore participants take turns in resum-

ing the activity. Here users can take overthe activity from others and see what hasbeen done so far. A typical example ishanding over some activity across shifts.An activity can also be shared synchro-nously when two or more participantsresume the activity simultaneously ondifferent computers (resulting in closecollaboration among participants work-ing from different locations). A typicalexample is a radiologist and physiciandiscussing diagnosis and treatment whileexamining x-ray images.

At the technical level, activity shar-ing is achieved by reusing the state man-agement mechanisms used in activitysuspend-resume.4 Asynchronous activ-ity sharing is equivalent to activity sus-pend-resume and activity roaming formore than one user. In synchronousactivity sharing, the prototype systemdistributes state information among theonline participants. In addition, it pro-vides different collaborative widgetsthat support synchronous activity shar-ing across remote computers, includingtelepointers, a voice link between par-ticipants, and a window showing theactivity’s participants.

Figures 2b and 2c show the evalua-tion of real-time activity sharing. In gen-eral, clinicians appreciated the system’snative support for activity sharing. Theyalso considered support for distributed,real-time activity sharing between, forexample, a radiologist in the radiology

JANUARY–MARCH 2007 PERVASIVEcomputing 49

Medical work in general, and in

hospitals in particular, is highly

collaborative due to the specialized

nature of medical treatment.

department and a physician at a ward,to be relevant in the daily working of ahospital.

The use of real-time activity sharingwas, furthermore, extended considerablyin use. We initially designed and built itfor remote collaboration with active par-ticipants, such as in the radiology case.During the workshops, however, clini-cians used the collaboration supportextensively for ad hoc, collocated col-laboration. For example, a nurse and aphysician both being in the bed wardwould have the same activity running onthe display in the bed and on a tablet PC.The nurse, for example, would be talk-ing to the patient about medicine whilethe physician browsed the medical re-cord and made notes.

ABC technologyThe ABC framework crystallizes sup-

port for the ABC principles we’ve justdescribed. The framework has a hybridarchitecture (see figure 4) using client-server communication for activity andstate management and peer-to-peer com-munication for telepointers, voice link,and other collaborative widgets used insynchronous activity sharing.5 On theclient side, ABC is integrated into theWindows XP operating system and win-dow management system.3 The client-

side architecture has a plugable user-interface layer, which we’re using todevelop an ABC client application foruse in surgical operations. Besides theWindows XP client, ABC clients for thePocket PC and Symbian mobile phonesexist. The infrastructure layer handlesactivity storage, roaming, and sharing.The activity state is modeled in an XMLactivity ontology called the ActivityMarkup Language (AML), which resem-bles Aura task definition6 but is moregeneric in its use. Communication occursthrough a dedicated ABC protocol(ABCP) that supports a request-responseschema and publish-subscribe notifica-tions. An ABCP handler exists which,for example, makes valid the URLabcp://cfph.au.dk/ms_pedersen. Typingthis URL in a browser would activate thems_pedersen activity. Finally, Java andC# APIs support easy development ofABC-aware applications.

Although we’ve intensivelytested the ABC approach andtechnology in a laboratorysetup, we haven’t yet evalu-

ated it inside a hospital. We’re currentlyworking on ABC-enabling an EPR anda PACS for deployment in a hospital forfurther evaluation. In particular, we’re

focusing on taking ABC into the oper-ating room to test its usefulness in anextreme clinical environment.

To manage complexity in a futurewhere users continuously use numerouscomputers and devices, we must movecomputational support from accessingfiles, applications, and services closer tothe users’ tasks and goals. We proposeABC as one approach to help users man-age this complexity.

ACKNOWLEDGMENTSWe thank the anonymous reviewers for extensivecomments that strengthened our focus and pre-sentation. The Danish Center of Information Tech-nology, ISIS Katrinebjerg, and the Danish ResearchAgency (NABIIT) funded this research. Anders K. Ol-sen, Jonathan Bunde-Pedersen, and Martin Mo-gensen have developed parts of the ABC technol-ogy, and Claus Bossen has participated in the fieldwork.

REFERENCES1. H.B. Christensen, “Using Logic Program-

ming to Detect Activities in PervasiveHealthcare,” Proc. 18th Int’l Conf. LogicProgramming (ICLP 2002), LNCS 2401,Springer, 2002, pp. 421–436.

2. D.A. Henderson Jr. and S. Card, “Rooms:The Use of Multiple Virtual Workspaces toReduce Space Contention in a Window-Based Graphical User Interface,” ACMTrans. Graphics, vol. 5, no. 3, 1986, pp.211–243.

3. J.E. Bardram, J. Bunde-Pedersen, and M.Soegaard, “Support for Activity-BasedComputing in a Personal Computing Oper-ating System,” Proc. SIGCHI Conf. HumanFactors in Computing Systems (CHI 06),ACM Press, 2006, pp. 211–220.

4. J.E. Bardram, “Activity-Based Computing:Support for Mobility and Collaboration inUbiquitous Computing,” Personal andUbiquitous Computing, vol. 9, no. 5, 2005,pp. 312–322.

5. J.E. Bardram, J. Bunde-Pedersen, and M.Mogensen, “Differentiating between Ac-countable and Ephemeral Events in theABC Hybrid Architecture for Activity-Based Collaboration,” Proc. IEEE Int’lConf. Collaborative Computing (Collabo-

50 PERVASIVEcomputing www.computer.org/pervasive

H E A L T H C A R E

Infrastructurelayer

Contextservice

Activitystore

User interfacelayer

Client/OSlayer

Activitybar

UIcomponents

Cache

Activity controller

Servicemanager

Serviceregistry

Collaborationwidgets

Collaborationcontroller

IP network

Collaborationmanager

Activitymanager

Figure 4. The current activity-based computing architecture.

rateCom 2005), IEEE Press, 2005, pp.168–176.

6. D. Garlan et al., “Project Aura: Toward Dis-traction-Free Pervasive Computing,” IEEEPervasive Computing, vol. 1, no. 2, 2002,pp. 22–31.

For more information on this or any other comput-ing topic, please visit our Digital Library at www.computer.org/publications/dlib.

JANUARY–MARCH 2007 PERVASIVEcomputing 51

the AUTHORSJakob E. Bardram is a professor at the IT University of Copenhagen. His research in-terests include pervasive computing, software architecture, computer-supported co-operative work, human-computer interaction, and pervasive healthcare. He receivedhis PhD in computer science from the University of Aarhus. He’s a member of theIEEE and ACM. Contact him at the IT Univ. of Copenhagen, Rued Langgaards Vej 7,DK-2300 Copenhagen S; bardram@itu.dk.

Henrik B. Christensen is an associate professor in the Department of ComputerScience at the University of Aarhus. His research interests include computer scienceeducation research and software architecture with a special interest in methods,tools, and techniques to ensure reliable and flexible architectures. He received hisPhD in computer science from the University of Aarhus. Contact him at the Dept.of Computer Science, Univ. of Aarhus, Aabogade 34, 8200 Aarhus N, Denmark;hbc@daimi.au.dk.