A COMMUNITY-CENTERED ARCHITECTURE FOR THE

DEPLOYMENT OF UBIQUITOUS TELEMEDICINE SYSTEMS

Federico Cabitza, Marco P. Locatelli and Carla Simone

Universit`a degli studi di Milano-Bicocca, Via Bicocca degli Arcimboldi 8, 20126 Milano, Italy

Keywords:

Ubiquitous Computing, Home Care, Telemedicine, Hypertension, Awareness.

Abstract:

In this paper, we present an ubiquitous and pervasive computing architecture, CASMAS, aimed at supporting

cooperation among the members of a community and their devices. We also show how CASMAS can be

augmented by the WOAD framework, which was developed independently to model and express coordination

mechanisms in document-mediated communities. We take the distributed hypertension monitoring case as

an exemplifying and sufﬁciently complex scenario to show the feasibility and advantages of the our seman-

tically informed modular approach. The scenario is then declined in terms of architectural components and

cooperation-oriented mechanisms that are shared between the devices and entities of the designed community

of care.

1 INTRODUCTION

The technological trend toward Ubiquitous/Pervasive

Computing allows for an easy and cheap connectiv-

ity among the various actors involved in the care of

patients with chronic diseases: the patient, her family

doctor and relatives, the caring facilities of the city

where they live, and so on. Being connected however

is not enough. What it is needed is to make those con-

nected people a social network that could provide the

patient with a communication environment where she

can feel safe. This is obviously true for elder people

who can otherwise experience loneliness and fragility

with respect to their disease but it also holds true for

people who are engaged in full time activities involv-

ing work, family care, leisure and so on. What is dif-

ferent is the kind of social network that is needed in

the various situations to deal with the normal moni-

toring of the disease development and to face unex-

pected conditions when ad hoc treatments which can

involve several actors at the same time are needed.

On the other hand, even if the physical conditions

are the same, patients and their relatives are not alike

when confronting those events: individual and fam-

ily history can generate different psychological states

that require a strongly personalized communication to

avoid that these factors have a negative impact on the

caring process. The communication dimension is a

necessary factor for this to happen but it is not sufﬁ-

cient: for a patient to feel safe, for a family to feel con-

ﬁdent and for a doctor to feel able to achieve the best

possible results, they all need to be part of a caring

process where they cooperate to achieve a common

goal. The technology has to be challenged against this

richer view, in that technological solutions should not

only be conceived from an engineering point of view

to make connectivity robust, fast, protected since it

involves sensible data, and so on, but equally from

the point of view of the disciplines that take coop-

eration through and in interaction with the technol-

ogy as their main concerns. In this respect, Com-

puter Supported Cooperative Work (CSCW), Com-

puter Human Interaction (CHI) and what has been re-

cently called Computer Supported Cooperative Care

(CSCC) (Consolvo et al., ) offer a rich set of indica-

tions that are mostly derived from observations and

studies in the ﬁeld and from experimental practices

oriented to the evaluation of the impacts of technol-

ogy introduction both in work and every day life situ-

ations. Too often indeed technology adoption is con-

sidered a “secondary” problem to be considered “af-

ter” that the technology has been already put there.

We like to take the opposite attitude: since technol-

ogy can be “easily” put there, we have to anticipate

its impacts on the basis of a stratiﬁcation of expe-

riences (sometimes of failures) that the above men-

tioned studies offer to the research and development

of new solutions. This paper is a step in this direction.

Cabitza F., P. Locatelli M. and Simone C. (2008).

A COMMUNITY-CENTERED ARCHITECTURE FOR THE DEPLOYMENT OF UBIQUITOUS TELEMEDICINE SYSTEMS.

In Proceedings of the First International Conference on Health Informatics, pages 9-16

 SciTePress

1.1 Our Main Contribution

Telemedicine (as any other tele-something involving

cooperation) is not a technological ﬁeld that aims to

reproduce the current social relations among the in-

volved actors nor to change them in a predeﬁned way

by “optimizing” communication patterns. Both goals

have been proved impossible: technology becomes an

effective support if its developers and users under-

stand that technology is unable, on the one hand, to

reproduce the reality without losing some of its pe-

culiar and tacit aspects; and, on the other hand, to

constrain human behavior to prescriptive rules that

can hold just in a virtual world. In telemedicine (as

in any other application domain), technology has to

harmonize with real life in both directions: i.e., to-

ward both the offering of new possibilities and ca-

pabilities, and the modiﬁcation of the current ones

without disrupting or disregarding existing individ-

ual and social behaviors. For these reasons, we like

to speak of communities of care, which are consti-

tuted by the patient, close relatives, selected health

assistants and nurses, the family doctor and possi-

bly involved specialists: practitioners are members of

a number of communities, one for each of their pa-

tients. Accordingly, in order to conceive of a support-

ive technology, we claim that design has to be based

on an application layer (i.e., a layer on top of the un-

avoidable one that guarantees physical connectivity)

that reﬂects the nature and needs of those communi-

ties. To this aim, we propose a framework that in-

corporates the notion of community as a ﬁrst class

object and it allows to express the community’s co-

operation mechanisms abstractly, i.e., at the seman-

tic level of articulation work. From the technological

point of view, the framework recognizes the need of

allowing for a high degree of ﬂexibility and adaptabil-

ity to the actual domain and current situation since it

separates the cooperation and communications con-

cerns of all the entities involved in a telemedicine

systems by taking a semantically informed modular

approach. These characteristics make our approach

quite different from that recently adopted to make

computation “ambient aware” (Baker et al., 2007).

Indeed, our proposal is not only aimed at making

the members of a community of care aware of what

happens in the enlarged environment. Rather, it is

aimed at making these distributed and heterogeneous

actors aware of the local conventions by which they

can make sense of environmental conditions, consider

them as meaningful parts of a patient-centered logic

environment of care and trust, and correlate those

conditions with timely and effective behaviors when-

ever they occur. Consequently, for our implementa-

tion, we do not adopt third-party middlewares that

are mainly devoted to context awareness, such as the

Context Toolkit (Salber et al., 1999) or the Java Con-

text Awareness Framework (JCAF) (Bardram, 2005);

these can provide “only” the context abstraction and

reasoning part of our model. Conversely, we need,

and achieve, support for both coordination and prop-

agation of awareness information, in addition to the

ability to enhance the behavior of any application

by providing it with a larger access to its context of

use (Dey et al., 2001).

Our approach will be illustrated by means of a

reference scenario that is described in the next sec-

tion. The following sections present the approach

and illustrate it through a subset of functionalities

we focus on for the sake of simplicity. We chose

the domain of hypertension monitoring as the refer-

ence domain where to place our technological pro-

posal since high blood pressure is recognized as one

of the most dangerous silent killer (Hoel and Howard,

1997) and the main concern of physicians involved

in its treatment is that many hypertensive persons are

unaware of the importance of following monitoring

and treatment with commitment in a lifelong perspec-

tive (WHO/ISH, 1999).

2 AN INTEGRATED CARE

SCENARIO

Let us imagine that a patient, Ms Dorothy, has been

inserted in the Hypertension Monitoring Programme

(HMP) by her family doctor, Dr. Robert. HMP pa-

tients suffer for a kind of hypertension that requires

both lifestyle change and medication. For this rea-

son, Ms Dorothy is provided with a series of devices

aimed at making continuous monitoring easier and

seamless with respect to her daily life at home: these

devices are, namely, (1) an electronic agenda; (2) an

automatic drug dispensing machine; (3) an automatic

blood pressure machine; (4) an electronic paper form;

and (5) a simple mobile phone (her own was ﬁne).

All these devices are able to transmit and receive in-

formation from the communicationnetwork, although

in different ways (e.g., via GPRS, cabled ADSL, wi-

ﬁ and GSM) and have been selected to require an as

much as natural interaction with the patient, which

in many cases can lack the necessary skills and prac-

tice to use personal computers, palmtops and complex

smart-phones.

In order to take her blood pressure, Ms Dorothy

uses the Automatic Blood Pressure Machine (ABP).

She can use it on her own since the process is com-

pletely automatic and does not require a speciﬁc tech-

nological skill. Today, Ms Dorothy has just taken

her blood pressure and her values are 140/90 mmHg.

Then, she switches on the electronic paper form (EPF)

to send those values to her family doctor, Dr Robert.

The EPF is an A5-sized touch screen using E Ink’s

technology

that is thinner than a postcard, has the

clarity of a traditional paper sheet, can be bent with no

distortion and can be inscribed with a regular stylus.

Once switched on, the EPF presents Dorothy with a

regular form, where her latest pressure values, the cur-

rent date and her identity data (e.g., name, social se-

curity number) are copied in the corresponding ﬁelds

of the form automatically. As any other HMP patient,

also Ms Dorothy is supposed to ﬁll in additional ﬁelds

by hand. The most important is the ‘further remarks’

ﬁeld: this is where she is asked to annotate the pres-

sure data with some notable past event or condition

that could help the doctor make sense of the pressure

measurement (e.g., “I had a discussion with a neigh-

bor the morning before I took the pressure”). While

the patient is left free to either jot down her remarks

or not when all is well, the system invites her to add a

further justiﬁcation to collected data whenever it has

detected unexpected pressure values, with respect to

either previous data, current trends or medication reg-

imens.

Since today Ms Dorothy exhibits a blood pressure

that is fairly high for a person under pharmacological

treatment and with her risk factors (i.e., overweight,

smoker), the system also automatically imports from

Dorothy’s personal agenda those items that she had

labeled as ‘work overload’ (i.e., a series of meetings

in the previous two weeks), according to some con-

ventions agreed upon with Dr Robert: speciﬁcally,

they agreed upon the need to note into an electronic

agenda Ms Dorothy’s daily engagements and, when-

ever reasonable, to characterize her schedules in terms

of simple categories of events, like ‘passive sport’

(e.g., watching a football match on tv), ‘active sport’

(e.g., working out at the gym), but also ‘business

meeting’, ‘ofﬁce assignment delivery’ and any event

that could be associated with stressful states, discom-

fort and anxiety. These conventional data allow the

doctor to ﬁnd speciﬁc correlations between high pres-

sure peaks and risky behaviors and to isolate the ac-

tual risk factors of a speciﬁc person in order to iden-

tify more discriminating dietary and less generic prac-

tice restrictions and hence a better and patient-focused

treatment. Obviously, these schedule data are strictly

conﬁdential and Ms Dorothy can remove the entries

reported in the EPF. If she leaves them, Dr Robert can

read them only after that Ms Dorothy also gives ex-

plicit consent by signing the form. Since the pressure

values are high and Dorothy was used to be an inten-

http://www.eink.com/products/index.html

sive smoker, the system also asks Ms Dorothy to ﬁll

in the form and to report how many cigarettes she has

smoked in the last week (if any), as well as any event

that could justify these values. Also this rule has been

agreed upon by Dr Robert and Ms Dorothy. She re-

ports she did not take any cigarette in that time lapse

and jots down in the remark ﬁeld that she has often

had evening headaches, fatigue and anxiety. More-

over, since Dr Robert has prescribed her a low-calory

diet, the form displays a ﬁeld where to ﬁll in the cur-

rent weight also. Indeed, the EPF form can change its

structure according to the doctor’s requests and addi-

tional ﬁelds can be presented to patients to be ﬁlled

in; in this case, after that Ms Dorothy has annotated

her weight on the EPF, Dr. Robert can also assess

if the dietary regimen is yielding its fruits and give

her some feedback on that. To put it brieﬂy, the EPF

form is a regular document that can hold extra-data

beyond what regularly fed in by digital devices. It is

used to consolidate those health data, in that to sign

it implies giving an explicit consent for their manage-

ment. Besides the reasons of legal accountability, the

form is also used to have patients get an active ap-

proach in monitoring their own blood pressure, since

trend awareness and active inclusion in the monitor-

ing process can give patients the necessary motiva-

tion to change her lifestyle if this is the case. The

EPF form is also used to enable asynchronous com-

munication between patients and their doctor via ei-

ther typed or handwritten messages. Asynchronous

messaging is used in order to reduce the number of

phone calls that could interrupt doctors during their

work. This kind of messaging is particularly appreci-

ated by Ms Dorothy since the EPF represents a writ-

ten source of information to rely on for those doubts

that do not require vis-a-vis or phone talks. Handwrit-

ing with a regular stylus is allowed to enable patients

that do not have - or are not conﬁdent with - personal

computers and keyboards to write messages and send

them online. As last thing before signing the form,

Ms Dorothy writes down in the question ﬁeld whether

she can have some herb tea before going to bed. Then

she puts her signature at the bottom of the form and,

in doing so, the form content is sent to the Dr Robert

ofﬁcially. Besides being an input device, the EPF is

also a ﬂexible output device. The form can also serve

to reproduce the ofﬁcial headed notepaper where the

doctors jots down drug prescriptions and puts her sig-

nature. In this way, the form can be used to buy drugs

at the pharmacist. Likewise, prescriptions can be up-

dated by the doctor even remotely without any effort

by the patient. The mobile phone is the other main

output device at patients’ home. The mobile phone

is used to convey small messages to remind the pa-

tient, for instance, that she has to take the pills, that

the family doctor has changed the therapy remotely

(and it is available at the EPF) or that he has just sent

her a message.

The doctor, Dr Robert, is informed of the incom-

ing message from her patient while he is going up-

stairs, headed to his ofﬁce. Indeed, also family doc-

tors are endowed by a couple of smart devices that

are supplied for the HMP to convey alerts when they

are not at their desktop or are engaged in some im-

portant administrative task. These alerts regard the

occurrence of extremely high pressure values of a pa-

tient or, less critically, the notiﬁcation that a patient

has sent a message via the electronic form. Then Dr

Robert’s mobile phone vibrates and a short message

tells him that Ms Dorothy has written him. He can-

not recall exactly who she is and puts away the mo-

bile as he opens the door of his ofﬁce. When he sits

at his desk, he switches on a small, ﬂat monitor and

sees a couple of pulsating circles on it. This monitor

is much alike a digital picture frame like the Widget-

Station

. This smart frame (SF) runs various “wid-

gets”, i.e., small, user-tuned applications that perform

a variety of tasks, like displaying current agenda, cal-

endar, website and news feeding. One of these wid-

gets is devoted to represent the patients involved in

the HMP programme. Each patient is a small dot

and the color indicates whether she is under drug

therapy or not and whether her last pressure values

are on average or not. If the dot’s border winks,

the corresponding patient has sent the doctor a mes-

sage that has been also forwarded to his email client

and to his mobile if he is out of ofﬁce. If pressure

values of a patient become critical, the correspond-

ing dot enlarges to become a small quivering cir-

cle whose color indicates the seriousness of the case

(e.g., red, orange, yellow). By touching the circle,

the doctor can have the electronic patient record of

the related patient displayed, as well as a timeline

overview of the pressure data collected so far and

the related medications (in a manner quite similarly

to that used in the Danish TMBP project (Bardram

et al., 2005)). Once seated, Dr Robert touches the

only circle whose border is also winking and the sta-

tion displays the name ‘Ms Dorothy’. He then tips

again on the circle and maximizes in a two-side view

both the last page of Dorothy’s personal record and

her current pressure trend. Since the trend over a two

month period does not show any signiﬁcant pressure

reduction, Dr Robert decides that the previous ther-

apy is not enough and an additional drug is neces-

sary. He then changes the current drug regimen in the

Ms Dorothy’s ﬁle within his electronic patient record.

http://www.emtrace.com/widgetstation/

Finally, he opens his mail client and ﬁnds the mes-

sage from Ms Dorothy quite immediately amidst the

daily spam since the system has assigned the message

a high priority as it comes from a patient of the HM

programme. Dr Robert answers Ms Dorothy that herb

teas are ﬁne as long as they do not contain theine.

This message will be displayed on the EFP of Ms

Dorothy in a thread-like fashion inside the question

ﬁeld the next time that she will switch the form on.

In a while, a number of devices at Ms Dorothy’s side

react to the new drug prescription. Ms Dorothy’s mo-

bile rings once and a short message notiﬁes her that a

message and a new prescription have been dispatched

from Dr Robert. The prescription can be displayed at

full screen on the EPF form so that it can be presented

to the pharmacist at due time.

Also the Automatic Drug Dispensing Machine

(ADD) receives the prescription data. According to

these data, the ADD provides the patient with the

right drugs by dispensing just the right dosage and by

allowing the patient to open the drug-till only at the

right interval of time. When the patient withdraws the

drug pill, the ADD records the drug administration as

accomplished. In our vignette, the ADD detects that

the new drug is not loaded in its tills. Consequently,

both Ms Dorothy and her closest relatives are notiﬁed

of it by mobile phone. Speciﬁc relatives or friends

that were pointed out as the patient’s closest helpers

are also notiﬁed whenever the patient has skipped two

drug administrations in a row or if she presents very

high values of hypertension. This is done to commit

the relatives in paying attention to their dears and in

reminding them due commissions at due time.

3 THE CASMAS

ARCHITECTURE

In the architecture that we deﬁned in (Cabitza et al.,

2006), ubiquitous-computing systems are viewed as

constellations of dynamically deﬁned communities of

human and technological entities that interact through

cooperation mechanisms and coordinate themselves

on the basis of awareness information related to the

community context. Communities are identiﬁed by

points of aggregation, called community fulcra: en-

tities gather around them to access the information

that characterizes the community and contributes to

its deﬁnition. The structure of an entity and how it

relates to the other elements of the model is described

in Figure 1. Each entity — composed of inner ele-

ments as depicted in Figure 1.a — is depicted as a

rounded rectangle, and can be linked to multiple ful-

cra to enable intra- and inter-community coordination

(see Figure 1.b) and to awareness topological spaces

(represented as graphs, space site in Figure 1.a) to

promote awareness information sharing. More specif-

ically, a Coordination agent (C-agent, C in Figure 1.a)

is instantiated for each connection to a fulcrum, i.e.,

for each of the communities in which the entity partic-

ipates; an Awareness agent (A-agent, A in Figure 1.a)

is instantiated for each connection to an awareness

space.

An example of technological entity is the ABP de-

vice; this is typically connected to a fulcrum of an en-

tity that represents a person, Ms Dorothy in this case,

so as to be part of the community of devices that are

associated to that person. The notation used to depict

this situation is showed in Figure 1.c; in this case,

a C-agent is created when an entity connects to an-

other one and it docks to its own entity fulcrum. Fig-

ure 2 represents the set of entities corresponding to

the patient community of care described in Section 2:

in this case the community encompasses both human

and technological entities.

Once created, all C-agents are provided with

generic inference capabilities and with a set of entity-

speciﬁc facts (i.e., declarative data structures) and

mechanisms (i.e., rules). By being connected to a

community fulcrum (Figure 1.b), C-agents associated

to entities can share information (facts) and acquire

community-speciﬁc behaviors (mechanisms) that are

either deﬁned at design-time or injected into the ful-

crum by other entities at run-time. To this aim, the

model provides mechanisms, for instance to either

insert facts into fulcra (i.e.,

assertion

) or to move

facts from a source’s to a destination’s fulcrum (i.e.,

translation

), by which to deﬁne the behavior of C-

agents (Cabitza et al., 2006).

The behaviors of C-agents might be inﬂuenced

by the degree of participation of entities in com-

munities, according to additional context information

that is supplied by the part of the model that man-

ages awareness promotion (on the basis of the above

mentioned awareness spaces and A-agents populating

them). This part of the model has been illustrated and

used in a previous work (Locatelli and Simone, 2006)

and will not be further described since the degree of

participation is not used in the considered scenario.

Instead, we give more details on the part of the ar-

chitecture that computes the awareness information

to be promoted, in a simpliﬁed way, to entities that

occupy isolated nodes of the awareness spaces (i.e.,

without using the space topology). From now on, we

will use entities without any further reference to their

internal structure since they support the semantically

based modular approach mentioned in the introduc-

tion.

Figure 1: Notation used to represent the entities.

Figure 2: The involved entities in the scenario.

3.1 The Woad Framework

Within the CASMAS architecture, the WOAD frame-

work is what we used to model community con-

ventions and mechanisms of awareness provision.

WOAD is a conceptual and design-oriented frame-

work that we proposed (Cabitza and Simone, 2007b;

Cabitza and Simone, 2007a) to provide a set of high-

level concepts – like those of documental artifact,

fact, fact space, and fact interpreter – that guide

the design of a rule-based reference architecture for

context-aware and coordination-oriented electronic

document systems. In the CASMAS architecture, the

community fulcrum can be seen as a fact space and

one of the agents can plays the role of fact interpreter.

This agent would be supposed to import into its pri-

vate fulcrum (i.e., its working memory) the WOAD

mechanisms of the related community of care and

then apply them to the content of the community ful-

crum so as to produce consistent awareness informa-

tion. In WOAD, two main abstract kinds of compo-

nents are distinguishable: a fact space, i.e., a com-

mon and shared repository where contextual informa-

tion – i.e., what we call facts – is stored; and a fact-

interpreter, i.e., an inference agent that is able to re-

act to the content of the fact space and produce new

contextual information, usually meta-data by which

situational awareness (Endsley, 1995) information is

associated to data. Situational awareness is any infor-

mation about either an event or new contextual condi-

tion which the system can conveyin any way (e.g., vi-

sual, aural, textual) to support the user become aware

of it, know what is going on and ﬁgure out what to do

consequently. The WOAD language is a high-level

programming interface by which to express mecha-

nisms of awareness provision and conventional pat-

terns of data production and routing. These mech-

anisms are intended to reﬂect the local conventions

that practitioners and patients can agree upon about

how to manage data and interventions within a given

community. WOAD mechanisms can be shared into

a fact space and be used by any fact-interpreter shar-

ing this space to (a) provide suitable awareness infor-

mation to support human actors in articulating their

activities of integrated care; and (b) to process the

content of a document according to locally deﬁned

and agreed patterns of coordination. WOAD encom-

passes a set of both static and dynamic constructs by

which the designer can express either contextual, or-

ganizational or procedural knowledge about a work

arrangement in a declarative manner, that is by fo-

cussing on the expression of what a system should do,

rather than worrying about how it really accomplishes

it. These static data structures and dynamic behaviors

are expressed by two speciﬁc constructs: facts and

mechanisms, respectively. In the WOAD language,

whatever is given the sufﬁx -fact (e.g., activity-fact,

relation-fact and awareness-fact) is a key-value data

structures, by which the programmer can character-

ize the relevant entities of a documental domain by

simply assigning a value to speciﬁc attributes. The

WOAD language provides designers with templates

(i.e., entity-facts) for the most generic categories of

articulation work (cf. (Simone and Divitini, 1997)),

like those of actor, activity and artifact; yet, by means

of its extends primitive, it also allows for the deﬁni-

tion of domain-speciﬁc entities (such as patient, doc-

tor and care activity) that inherit from and specialize

those general categories. Mechanisms can be seen

as simple conditional statements, like if-then rules:

they produce some output according to the actions ex-

pressed in their consequent (the then part) whenever

speciﬁc contextual conditions, which are expressed in

their antecedent (the if part), are evaluated true by

matching their patterns with the internal state of a fact

interpreter (i.e., usually but not necessarily, the work-

ing memory of the rule-based system). Mechanisms

are hence intended to make explicit the relationship

between some contextual conditions regarding either

the existence or the content of some facts within the

fact space and some behavior (i.e., functionality) that

the system should exhibit in that particular situation,

whenever it occurs. In our application domain, the

production of suitable awareness information is con-

veyed as attached to some contextual or documental

data. In the next section we will see two examples of

information ﬂows derived from the scenario depicted

in Section 2.

4 APPLICATION TO THE HM

SCENARIO

The scenario described in Section 2, identiﬁes

a community, called Patient Care Community

(PCC), that contains the following logical en-

tities interacting through the PCC fulcrum (see

Figure 2): Patient (we denote entities with

this typographical notation), Doctor, and

Relative i.e., entities managing the information

pertaining to each person involved; ADD, Agenda,

ABP, E-paper Form, and Mobile phone are

linked to Patient; Smart Frame, Mobile

phone, EPR, and Email gateway are linked

to Doctor; ﬁnally, Mobile phone is linked to

Relative. Moreover, there is a framework-speciﬁc

entity, FI-WOAD, that is the WOAD Fact Interpreter;

this entity perceives the facts published by the enti-

ties that take part to the patient care community and

infers on them. The patient care community provides

the involved entities with proper mechanisms to co-

ordinate and exchange information as illustrated in

the scenario. In the following, we give some exam-

ples of mechanisms involving Patient, FI-WOAD,

Doctor and Relative. Patient is in charge of

making available in the PCC’s fulcrum the fact rep-

resenting that the form has been signed (generated by

E-paper form), and the fact that a speciﬁc drug

is unavailable (generated by ADD): this transfer of in-

formation is realized by means of the

translation

mechanism, which accomplishes a mere copy of in-

formation from the source’s to the destination’s ful-

crum.

By using the same mechanism, Doctor (asso-

ciated to Dr Robert) can put into the PCC fulcrum

mechanisms expressing criteria to evaluate pressure

values for the patient at hand and identify “critical

values” accordingly. In this way, FI-WOAD can ac-

quire them to assess when pressure values are critical

for the patient at hand and publish both alerting and

reminding facts, in particular those on critical blood-

pressure valuesand, in a similar way, on newprescrip-

tions.

Let us now consider a more articulated situa-

tion. According to the conventions established be-

tween Dr Robert and Ms Dorothy, her Agenda pub-

lishes in the Patient’s fulcrum the events labeled

as “work overload” (see Figure 3.a, step 1a). When

Ms Dorothy takes her blood pressure using the ABP,

ABP publishes this information into the Patient’s

fulcrum (step 1b); E-paper form reacts to this in-

formation (step 2) and shows the form to Ms Dorothy

so that she can ﬁll in the pieces of information re-

quired by the EPF’s structure that is dynamically set

Figure 3: The step sequences for the three main cases depicted in the scenario.

by Dr Robert for her, such as her weight, and write

her remarks and questions. Ms Dorothy signs the

form to submit the information and E-paper form

publishes the form to the Patient’s fulcrum (step

3); then Patient publishes the signed form into

the PCC fulcrum (step 4). Once the signed form is

published into the community fulcrum, all the enti-

ties in charge of managing the form’s content can per-

ceive it; in our case, FI-WOAD perceives the form

(step 5) and, due to its mechanisms, it asserts an alert-

ing fact both for the critical pressure values and for

the message that contains the Ms Dorothy’s question

(step 6). Since Dr Robert must be warned of alerts,

Doctor reacts on these facts and

translates

the

information into its fulcrum (step 7) to make it avail-

able to the entities of its private community. The

alert about critical values is rendered only by the SF

that executes the HM awareness widget; the mes-

sage activates other three entities (step 8): Email

gateway

translates

the message into an email for

Dr Robert, Smart Frame providesawareness about

the received message, and Mobile phone notiﬁes

Dr Robert of the incoming message since he is not in

his ofﬁce.

Dr Robert evaluates the received information and

writes the new prescription in the EPR; once Dr

Robert is done, EPR asserts the new prescription

into the Doctor’s fulcrum (see Figure 3.b, step

1a); moreover, Dr Robert replies the question of Ms

Dorothy using his email client. This event is caught

by Email gateway that extracts the information

and asserts the corresponding message in Doctor’s

fulcrum (step 1b). Doctor

translates

both the

message and the new prescription into the PCC ful-

crum (step 2) to make them available to the com-

munity. Then Patient

translates

this infor-

mation into its fulcrum (step 3a) and, concurrently,

FI-WOAD reacts on the new prescription (step 3b)

and asserts an alert to the community (step 4). Now

Patient

translates

also the alert into its fulcrum

(step 5). E-paper form reacts to all this informa-

tion because it has to (a) convey Dr Robert’s reply,

(b) show Ms Dorothy the new prescription, and ob-

viously (c) alert her by providing awareness of the

changes occurred (step 4 and 6). Due to the impor-

tance of these changes, Ms Dorothy is also notiﬁed

by her mobile phone that a new prescription has been

made available. Also the ADD is programmed to re-

act on changes of prescription (step 6): it checks then

whether the drug is available in its tills or not. Conse-

quently, ADD detects that the new drug is not available

and asserts this information into the Patient’s ful-

crum (see Figure 3.c, step 1). Patient

translates

this information in the community fulcrum (step 2),

FI-WOAD perceives it (step 3) and asserts an alert

(step 4). In this situation, the relative selected by Ms

Dorothy is involved too: Relative perceives the

alert fact (step 5) and

translates

the corresponding

information into its fulcrum so that the relative’s de-

vices (such as her mobile phone) can warn her. The

same happens for Ms Dorothy when she is informed

by her mobile phone (step 5 and 6).

5 CONCLUSIONS

The paper presented the CASMAS architecture. This

architecture is aimed at the development of applica-

tions that take advantage from ubiquitous/pervasive

computing to support cooperation among the mem-

bers of a community. The paper also showed how

CASMAS could be used in the construction of mech-

anisms that are useful to enhance cooperationin a spe-

ciﬁc domain, namely within communities of care that

take patients as their “fulcrum”. Two are the main

features of the proposed approach. On the one hand,

the identiﬁcation of the components is guided by the

idea that they all have access to information (i.e., local

conventions and mutual awareness) that constitutes

the glue of the community but they are also left free

of using the shared information autonomously in or-

der to contribute to the community’s good functioning

and behavior. On the other hand, the mechanisms sup-

porting cooperation are deﬁned in terms of a modular

and declarative approach that deﬁnes them in an ab-

stract manner as reactive behaviors with respect to the

changes of the shared information mentioned above.

These two features implement the semantically in-

formed modular approach and support the application

ﬂexibility and adaptability to the context that we men-

tioned in Section 1: indeed, each behavior (from a

whole component up to the atomic constituents of a

single mechanism) is aimed at the goal of support-

ing cooperation and awareness provision between the

members of the community (of care). Hence, these

community-speciﬁc behaviors can be naturally exter-

nalized and appropriated by the members, also while

they are interacting with the community designers,

in order to adapt the application to the single con-

text of usage. This context is always locally char-

acterized by the kinds of patients and their diseases,

their family relationships, the local caring structure

and conventional practices and so on. In addition,

the abovementioned separation of concerns applies to

the devices too (seen as a special kind of community

“members”) so as to deﬁne a clear interface toward

any underlying layer that guarantees the general pur-

poses of the communicationinfrastructure. The future

work is aimed at making the integration between the

CASMAS architecture and WOAD framework more

transparent and at improving its usability from the de-

signer’s point of view. In doing so, we would provide

an integrated framework that responds to the basic

requirements of cooperation within communities (of

care) and that can be fully validated in the ﬁeld.

REFERENCES

Baker, C. R. et al. (2007). Wireless sensor networks for

home health care. In AINAW’07 proceedings, pages

832–837, Washington, DC, USA. IEEE Computer So-

ciety.

Bardram, J. E. (2005). The java context awareness frame-

work (jcaf) - a service infrastructure and programming

framework for context-aware applications. In Lecture

Notes in Computer Science, volume 3468, pages 98–

115. Springer.

Bardram, J. E. et al. (2005). Designing for transformations

in collaboration: a study of the deployment of home-

care technology. In GROUP ’05 proceedings, pages

294–303, New York, NY, USA. ACM Press.

Cabitza, F., Locatelli, M. P., and Simone, C. (2006). De-

signing computational places for communities within

organizations. In CollaborateCom’06 proceedings,

Atlanta, Georgia, USA, pages 1–10.

Cabitza, F. and Simone, C. (2007a). A language for the ex-

ecutable speciﬁcation of coordinative functionalities

for electronic document systems. In CHItaly’07 pro-

ceedings, Padova, Italy, June, 28–30.

Cabitza, F. and Simone, C. (2007b). “. ..and do it the

usual way”: fostering awareness of work conventions

in document-mediated collaboration. In ECSCW’07

proceedings, Limerick, Ireland, 24–28 September.

Consolvo, S. et al. (2004). Technology for care networks of

elders.

Dey, A. K. et al. (2001). A conceptual framework and a

toolkit for supporting the rapid prototyping of context-

aware applications. Human-Computer Interaction,

16(2–4):97–166.

Endsley, M. (1995). Toward a theory of situation awareness

in dynamic systems. Human Factors, 37(1):32–64.

Hoel, D. and Howard, R. (1997). Hypertension—stalking

the silent killer. Postgrad Med Journal, 101(116–121).

Locatelli, M. P. and Simone, C. (2006). Supporting care

networks through an ubiquitous collaborative environ-

ment. In Nugent, C. and Augusto, J., editors, Smart

Homes and Beyond, volume 19, pages 204–211. As-

sistive Technology Research, IOS Press.

Salber, D., et al. (1999). The context toolkit: Aiding the de-

velopment of context-enabled applications. In CHI’99

proceedings, pages 434–441.

Simone, C. and Divitini, M. (1997). Ariadne: Supporting

coordination through a ﬂexible use of the knowledge

on work processes. Journal of Universal Computer

Science, 3(8):865–898.

WHO/ISH (1999). Guidelines for the management of

hyper-tension, volume 1. Blood Press.