Dottorato di Ricerca in Informatica

Universita degli Studi di Milano-Bicocca

SCUOLA DI DOTTORATO DI RICERCA IN SCIENZE

Dottorato di Ricerca in InformaticaXIX ciclo

Coordinatore Prof. Giancarlo Mauri

COOPERATION THROUGH WEBS OF DOCUMENTAL

ARTIFACTS: A FRAMEWORK FOR THE PROVISION OF

AWARENESS INFORMATION.

FEDERICO CABITZA

Ph.D. Dissertation

Tutor: Prof. Stefania BandiniCotutor: Prof. Carla Simone

A.A. 2005/2006

To my parents,

to my Apollonean youth,

and beloved Dionisy

Acknowledgements

This dissertation, as well as the work I report through it, would not exist with-

out the useful indications and continuous support provided by my advisor,

Prof. Carla Simone. While any mistakes or inaccuracies are my own responsi-

bility, it is highly likely that Prof. Simone had a hand in most of the appreciable

points of this dissertation. For all the fruitful and enriching talks we have often

had during the last three years and for all the time she devoted to my cultural,

professional and academic growth, far beyond her institutional duties, I am

and will always be deeply grateful.

I am also grateful to Prof. Stefania Bandini, for having introduced me to

her colleague and friend Carla Simone, the time I knocked to her door to

try and see whether I could access academic research and teaching after my

preliminary experiences in the private IT sector.

I also wish to thank Prof. Carlo Batini, who was my mentor for six full and

interesting months, for having opened his office door too, and for having me

know and appreciate the Art of Fugue by Johann Sebastian Bach, although it

is still an unfinished work.

I would also like to express my gratefulness to Giovanni Mattera of CoST

srl for his genuine kindness and for giving me the opportunity to look within

the bowels of its challenging prototype for a user-centered electronic patient

record. Last but not least, I’d like to give a special thanks to all the personnel

of the Manzoni Hospital for showing great interest in my research and being

willing to answer my sometime trivial questions on their daily work and prob-

lems. In particular, Rossana Pezzotta, Daniela Colombo and Dr. Roberto Bellu

have always welcomed me kindly, and made me feel at ease in every situation

I had to work with them, even wearing a white coat.

iii

Besides the professional side of my life and turning to the most personal

and private side of it, I am also obliged to acknowledge who has either enabled

me to achieve such result or shared with me the harshnesses of the path.

For the former reason, I wish to thank from the deepest of my heart my

parents, Gisa and Paolo. They have always encouraged and supported me in

pursuing whatever objective I have deemed important in my life, each time

never leaving me without either a smile or a quip, respectively.

For the latter reason, I thank Den, my travelmate, who has often had to

bear my difficulties and relieve my downheartednesses on the path to the

achievement of the Doctorate degree. I met Den at the beginning of my doc-

toral studies and she has greatly contributed in making these years the most

significant of all my life so far.

I also wish to thank some close and a little farer friends of mine: Matteo,

who has lately spurred me as much as only a jockey would have done with

his horse winning by only half a length: I thank him for trying to have me

feel those 350 km shorter. And I thank Bernardo, for his invaluable help with

LATEX and for the great and cooperative work we engaged in when we wrote

our considerations on context-aware computing and distributed inference sys-

tems: with him I’ve always worked very hard (e.g., the Master Thesis) but I

think that he has greatly contributed in making that work lighter and even

more interesting.

A last word for my lab colleagues: especially Michele, whom I had a really

great time in working and talking with, and Marcello, with whom I have often

had fun in playing sketches a la Toto and Peppino. I also thank Marco, Gigi

and Marco P. for making the place where I’ve spent almost every day of my

doctoral period a pleasant place to work and stay.

Milan, the 15th of November, 2006

iv

Contents

Acknowledgments v

1 Introduction and Main Motivations 11.1 Documenting Work and its articulation . . . . . . . . . . . . . . 2

1.1.1 Cooperative work and articulation . . . . . . . . . . . . 31.2 The need to be aware . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.1 Defining what to be aware of . . . . . . . . . . . . . . . 51.3 Artifact mediated awareness . . . . . . . . . . . . . . . . . . . . 8

1.3.1 Awareness-related requirements for artifact design . . . 101.4 The need to share information . . . . . . . . . . . . . . . . . . . 12

1.4.1 The common information space . . . . . . . . . . . . . . 151.5 Focussing on mediated cooperation . . . . . . . . . . . . . . . . 18

1.5.1 Artifact mediated cooperation . . . . . . . . . . . . . . . 201.6 Toward a support of mediated cooperation . . . . . . . . . . . . 24

2 The documental domain 272.1 An operational definition of document . . . . . . . . . . . . . . 282.2 Documental systems and cooperative work . . . . . . . . . . . . 292.3 The manifoldness of documental systems . . . . . . . . . . . . . 312.4 The computational support to documental domains . . . . . . . 33

2.4.1 Supporting documental practice . . . . . . . . . . . . . . 352.5 The “virtuous circle”: outline of the thesis . . . . . . . . . . . . 39

3 The WOAD framework 433.1 Main aims and assumptions . . . . . . . . . . . . . . . . . . . . 433.2 Two contexts for one sense . . . . . . . . . . . . . . . . . . . . . 483.3 Conceptual view of the framework . . . . . . . . . . . . . . . . 53

3.3.1 The WOAD entities . . . . . . . . . . . . . . . . . . . . . 573.3.2 The WOAD relationships . . . . . . . . . . . . . . . . . . 593.3.3 Correlations between data . . . . . . . . . . . . . . . . . 623.3.4 Interdependencies among activities . . . . . . . . . . . . 65

3.4 Architectural view of the framework . . . . . . . . . . . . . . . 693.4.1 Actors and documental artifacts . . . . . . . . . . . . . . 703.4.2 The fact space . . . . . . . . . . . . . . . . . . . . . . . . 72

v

3.4.3 The transitors . . . . . . . . . . . . . . . . . . . . . . . . 763.4.4 Some terminological specification . . . . . . . . . . . . . 77

3.5 Software Architecture . . . . . . . . . . . . . . . . . . . . . . . 78

4 The Rule-based middleware implementing WOAD 834.1 The need to make access to context “ubiquitous” . . . . . . . . 84

4.1.1 Middlewares for the semantic interoperability . . . . . . 854.2 DJess-Based distributed inference systems . . . . . . . . . . . . 88

4.2.1 General terminology . . . . . . . . . . . . . . . . . . . . 894.2.2 Jess-based inference systems . . . . . . . . . . . . . . . 894.2.3 Distributing an inference system . . . . . . . . . . . . . 92

4.3 DJess architecture and implementation . . . . . . . . . . . . . . 934.3.1 Implementing the DJess shared memory . . . . . . . . . 954.3.2 The rule sharing mechanisms . . . . . . . . . . . . . . . 984.3.3 The management of the WoIS . . . . . . . . . . . . . . . 99

4.4 Related work on distributed inference systems . . . . . . . . . . 1004.5 Reconciling DJess and WOAD terms . . . . . . . . . . . . . . . 104

5 L*WOAD: The WOAD language 1055.1 L*WOAD Facts . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

5.1.1 Entity-fact . . . . . . . . . . . . . . . . . . . . . . . . . . 1095.1.2 Relation-facts . . . . . . . . . . . . . . . . . . . . . . . . 1185.1.3 Convention-facts . . . . . . . . . . . . . . . . . . . . . . 120

5.2 Inside the awareness-fact . . . . . . . . . . . . . . . . . . . . . 1215.2.1 WOAD awareness types . . . . . . . . . . . . . . . . . . 123

5.3 L*WOAD Primitives and Mechanisms . . . . . . . . . . . . . . . 1315.3.1 The generic mechanism template . . . . . . . . . . . . . 1325.3.2 Predefined mechanisms and WOAD Primitives . . . . . . 137

6 The reference domain: documenting the hospital ward 1436.1 Medical work at Hospital as Cooperative Work . . . . . . . . . 144

6.1.1 Hospital actors and venues . . . . . . . . . . . . . . . . 1456.1.2 Hospital artifacts . . . . . . . . . . . . . . . . . . . . . . 147

6.2 The hospital web of artifacts . . . . . . . . . . . . . . . . . . . . 1506.2.1 The case study setting . . . . . . . . . . . . . . . . . . . 1506.2.2 Two wards: two worlds, one record . . . . . . . . . . . . 1516.2.3 The nature of the study . . . . . . . . . . . . . . . . . . 1536.2.4 Documenting the documentation . . . . . . . . . . . . . 155

6.3 Composing the composite artefact . . . . . . . . . . . . . . . . . 1586.3.1 Patient Data Sheet . . . . . . . . . . . . . . . . . . . . . 1606.3.2 Admission Reason and Anamnestic Data . . . . . . . . . 1606.3.3 Preliminary Objective Examination . . . . . . . . . . . . 1616.3.4 Problem List . . . . . . . . . . . . . . . . . . . . . . . . . 1626.3.5 Diagnostic Hypotheses and First Care Planning . . . . . 1626.3.6 Physicians’ Notes . . . . . . . . . . . . . . . . . . . . . . 165

vi

6.3.7 Single Sheets . . . . . . . . . . . . . . . . . . . . . . . . 1656.3.8 The Need Assessment Sheet . . . . . . . . . . . . . . . . 1676.3.9 Nursing Care Plan . . . . . . . . . . . . . . . . . . . . . 1696.3.10 Nursing Notes . . . . . . . . . . . . . . . . . . . . . . . . 170

6.4 The overall picture of the web of documents . . . . . . . . . . . 1716.5 Communication Patterns and Artifact Use . . . . . . . . . . . . 172

7 Application of WOAD to the hospital domain 1777.1 Application of WOAD to the clinical domain . . . . . . . . . . . 177

7.1.1 The clinical information reference model . . . . . . . . . 1787.1.2 The clinical record model . . . . . . . . . . . . . . . . . 1797.1.3 Downscaling the CDA model . . . . . . . . . . . . . . . 182

7.2 Application of WOAD to the case study . . . . . . . . . . . . . . 1847.2.1 From practices to language constructs . . . . . . . . . . 1857.2.2 Supporting clinical coordination . . . . . . . . . . . . . 1897.2.3 A small step methodology . . . . . . . . . . . . . . . . . 1927.2.4 Structure-related L*WOAD Mechanisms . . . . . . . . . 1967.2.5 Content-related L*WOAD Mechanisms . . . . . . . . . . 2077.2.6 Applying L*WOAD to web-spanning correlations . . . . 210

8 Conclusive remarks 2158.1 Summarizing the main achievements . . . . . . . . . . . . . . . 2158.2 Confronting WOAD with similar approaches . . . . . . . . . . . 2188.3 Possible directions for future works . . . . . . . . . . . . . . . . 223

A The NICU survey questions 231

References 266

vii

List of Figures

3.1 A woad plant, Isatis tinctoria in the family Brassicaceae . . . . . 443.2 Two kinds of contexts that pertain to documents in cooperative

settings and correlations among contextual items. . . . . . . . . 503.3 The two main concepts within the WOAD framework . . . . . . 573.4 Activity levels for the documental domain. . . . . . . . . . . . . 573.5 The main concepts of the WOAD framework. . . . . . . . . . . 593.6 The involvement relationship cases. . . . . . . . . . . . . . . . . 613.7 The WOAD metaphor: web threads between documental arti-

facts are relationships stemming from the fact space and depict-ing a woad plant whose leafs are documents; transitors makethe plant change, evolve, flourish. . . . . . . . . . . . . . . . . . 69

3.8 A graphical representation of the main components of theWOAD architecture. . . . . . . . . . . . . . . . . . . . . . . . . 70

3.9 A graphical representation of the architecture of a WOAD-compliant software application. At the top, we depicted thedocumental applications that are made cooperation-aware andcontext-aware by the underlying tiers. . . . . . . . . . . . . . . 79

4.1 Dynamic representation of an inference system. . . . . . . . . . 904.2 Interactions between context, represented by facts, and IS’s sen-

sors and effectors. . . . . . . . . . . . . . . . . . . . . . . . . . 914.3 Distributed Inference System (DIS). . . . . . . . . . . . . . . . . 934.4 Jess-DJess relation . . . . . . . . . . . . . . . . . . . . . . . . . 954.5 DJess facts synchronization. . . . . . . . . . . . . . . . . . . . . 964.6 a) A graphical representation of the DJess Web of Inference Sys-

tems (WoIS); b) the two-step rule-sharing process: 1): sharingand 2) loading . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5.1 The most general WOAD fact structure. Self-explicative at-tributes types are indicated in the attribute column. The plusdenotes a multiplicity possibly other than one . . . . . . . . . . 109

5.2 The conceptual hierarchy between very general WOAD factsand their framework-specific extensions. . . . . . . . . . . . . . 109

ix

5.3 DJess syntax for the definition of the WOAD-fact template. Lan-guage properties are referred to template slots for the sake ofcomprehensibility. . . . . . . . . . . . . . . . . . . . . . . . . . 110

5.4 The general structure of an entity-fact. Possible extensions ofthe entity-fact structure into application-dependent templatesare just hinted specifying a generic designer-defined property. . 111

5.5 Above, an example of DJess syntax for the definition of theentity-fact template. Below that, an example of fact definition:the person fact is defined as extension of the generic entity-fact. 111

5.6 The general structure of a document-fact. Some properties in-herited by the entity-fact (e.g., description) are reported for thesake of comprehensibility. . . . . . . . . . . . . . . . . . . . . . 113

5.7 The general structure of a awareness-fact. . . . . . . . . . . . . 1135.8 a) The general structure of a work-activity-fact. b) The general

structure of a documental-activity-fact. Properties inherited byparent facts (e.g., name and description) are reported for sakeof completeness. . . . . . . . . . . . . . . . . . . . . . . . . . . 115

5.9 The awareness-provision oriented finite state automata forWOAD activities. . . . . . . . . . . . . . . . . . . . . . . . . . . 117

5.10 The general structure of a relation-fact. Extensions by withuser-defined properties are indicated as optional properties. . . 118

5.11 DJess syntax for the definition of a relation-fact template. . . . 1195.12 The general structure of a convention-fact. Attribute type

conventions are explained in the implementative passage onconvention-facts. . . . . . . . . . . . . . . . . . . . . . . . . . . 121

5.13 DJess syntax for the definition of a WOAD convention-fact tem-plate as extension of the shared-rule template (see Section 4.3.2).122

5.14 Aspects of document-based awareness and related questions.Adapted from [Gutwin and Greenberg, 1997]. . . . . . . . . . . 124

5.15 The general mechanisms enabling interactions among themodel’s components: from left to right, the generic actor, thegeneric document, the fact space and the generic transitor. . . . 131

5.16 Mechanisms can abstract contextual data from documents andvice-versa, can inform documents of contextual elements . . . . 132

5.17 The general structure of a WOAD mechanism. . . . . . . . . . . 1335.18 Summary of WOAD primitives and their parameters. . . . . . . 1395.19 Example of DJess syntax for the definition of a WOAD correla-

tion mechanism. . . . . . . . . . . . . . . . . . . . . . . . . . . 142

6.1 A snapshot of the problem list sheet from the medical record.From the left to the right, there are reported an ID field, the de-scription of the problem, date and signature for the beginningand the cessation of the problem at hand. . . . . . . . . . . . . 163

x

6.2 A snapshot of the diagnostic/therapy plan sheet from the med-ical record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

6.3 Routine information flows (thick arrows) and data correlations(dotted and thick arrows) among documents. The main docu-ments of the medical record (above) and nursing record (be-low) have been encircled by a dotted line. . . . . . . . . . . . . 168

6.4 A snapshot of the nursing need list. . . . . . . . . . . . . . . . . 1696.5 A snapshot of the Activity Plan form for care assistants. . . . . . 1706.6 The “use” and “usefulness” of documental artifacts in support

of hospital care. In slanted figures: frequency of use, on a 5values, symmetric Likert-scale. In bold figures: effectiveness ofuse, on a 5 values, symmetric Likert-scale. Median values first,mean values between brackets. . . . . . . . . . . . . . . . . . . 174

7.1 The reference information model (RIM) as the core piece ofHL7 modelling. . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

7.2 Some CDA relationships between act-related entries.From [Dolin et al., 2006]. . . . . . . . . . . . . . . . . . . . . . 181

7.3 A screenshot of the prototypical Neonatology Electronic PatientRecord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

7.4 A graphical representation of the entities and relationships in-volved in the illustrative example. . . . . . . . . . . . . . . . . . 196

7.5 A snapshot of the Laboratory Examinations Form (SLEF). Anarea for prescribing only three typologies twice (e1 and e2) isbrought into close-up, for room’s sake. . . . . . . . . . . . . . . 198

7.6 WOAD mechanism for a convention on the proper role. . . . . . 2017.7 WOAD mechanism for a convention on proper order. . . . . . . 2037.8 WOAD mechanism for a convention on proper timing. . . . . . 2047.9 WOAD mechanism for a convention on proper redundancy. . . . 2057.10 A snapshot of the Single Pharmacological Therapy Form

(SPTF). Dashed boxes indicate sections with a specific mean-ing within the clinical record. . . . . . . . . . . . . . . . . . . . 207

7.11 A snapshot of both the Single Diagnostic-Therapeutic ProcedureForm (SDTF) and the Nurses’ Fasting plan. In the latter the fourcolumns indicate, respectively, the bed-number, the name of thepatient, the examination type, and the scheduled time for theexamination. For the SDTF the six columns indicate: the order-ing doctor, the ordered exam, date of request, date of booking,(scheduled) date of execution and (scheduled) date of referralarrival. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

7.12 WOAD mechanism for a convention on web-spanning correla-tions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

xi

Chapter 1

Introduction and MainMotivations

The work that we present in this thesis is rooted in the research field known

as Computer Supported Cooperative Work (CSCW). CSCW emerged during

the 80s as a multi-disciplinary community trying to understand the use and

design of computer-based systems as supportive technologies for complex co-

operative work setting [Schmidt and Bannon, 1992]. By drawing on the uni-

fying interest for understanding “how collaborative activities and their coor-

dination can be supported by means of computer systems” [Carstensen and

Schmidt, 1999], the CSCW field has gathered complementary contributions

from related disciplines such as computer science, information systems re-

search, human-computer interaction and sociology. Such contributions have

been aimed at positively informing the design of application systems whose

primary requirements regard how to properly and unobtrusively support peo-

ple that are mutually dependent in their work and are therefore required to

cooperate in order to get their work done [Schmidt, 1991].

Within the CSCW field, the main aim of study has then been twofold,

summarized into the terse expression “to understand, so as to better sup-

port” [Bannon and Schmidt, 1991]. On the one hand, CSCW researchers have

focussed on how work practices unfold in real work settings and are accom-

plished in traditional manners, even without the functionalities of information

and communication technologies. On the other hand, CSCW has aimed at ap-

plying the evidences collected by such studies in order to conceive, design and

deploy proper computer-based solutions that could support practitioners in

1

CHAPTER 1. INTRODUCTION AND MAIN MOTIVATIONS

working together, without being disrupted in their working habits and con-

ventions. In this introductive chapter, we aim at providing the reader with the

conceptual and motivational background that has influenced our contribution

within such research field.

1.1 Documenting Work and its articulation

Documents are used extensively by practitioners in the execution of their own

work and as a means for sharing information with others [Hertzum, 1999].

For this reason, researchers from different disciplines have been studying for

a long time the ways and extent documents are used and managed within

professional practices.

As a result, several evidences have been collected from very different set-

tings of how documents, far from being mere subsidiary tools where bits of

information are passively stored, are rather woven into work activities and

part and parcel of those activities that characterize work in its purpose and

sense (e.g., [Malone, 1983].

With the advent of computer-based systems and digitization, and of the

new functionalities that the computational processing of information can pro-

vide its consumers with, an increasing number of organizations are consid-

ering digital documents as the main way to successfully manage the flow of

information throughout the enterprise [Berry and Goulde, 1994].

On the other hand, the transition from paper-based traditional documents

— and the correlated habitual practices — to their fully digital counterparts

and to practices intended to exploit such new functionalities, has proven to be

highly problematic (e.g., [Braa and Sandahl, 1998,Sellen and Harper, 2003]).

Consequently, the role of documents in work practices have become a cen-

tral point of interest [Lortal et al., 2005] in several and complementary re-

search fields, and its analysis from observational and ethnomethodologically

informed observations a way to inform a proper design of computer-based

documental systems.

Recent studies have considered that documents are not to be regarded

as isolated artifacts, but rather as artifacts intertwined in a heterogeneous

network of people, places and other tools used to support communication and

the articulation of work activities [Braa and Sandahl, 1998].

In the research we will report in the next sections, we contextualize such

2

1.1. DOCUMENTING WORK AND ITS ARTICULATION

consideration by adopting the analytical distinction proposed by Schmidt and

Bannon between cooperative work and articulation work [Schmidt and Ban-

non, 1992].

1.1.1 Cooperative work and articulation

The common sense definition of the attribute cooperative characterizes the

work that is said to be “cooperative work” as work that involves several actors

working together in a conscious way in order to jointly perform some shared

activities. By adopting the conceptualization that of this primarily human1

phenomenon is given within the CSCW field, we recall a couple of crucial

aspects that underpin this straightforward definition.

Working together implies some extent of interaction: in a typical coopera-

tive arrangement interaction involves multiple individuals, acting in multiple

work settings and situations and exhibiting different responsibilities, perspec-

tives and propensities towards the shared goal2. These differences can result

into incommensurate perspectives and discordant motives [Schmidt and Ban-

non, 1992] that, although they could also require to be someway managed

and reconciled, can also become important resources for any individual actor

to get her work properly and timely done. Interaction is then a concept that in

the domain of cooperative work is declinable in terms of mutual dependency,

so as to include much more than mere physical influence.

Moreover, cooperation is a conscious activity, where involved actors rely

positively on the quality and timeliness of each others work [Schmidt, 1991].

This means that cooperative work is at great extent influenced by the degree

smaller, individual activities — which are accomplished toward the general

aim calling workers for cooperation — are interdependent and by the extent

they are coordinated, scheduled, aligned, meshed and integrated into an or-derly work arrangement [Strauss, 1988].

As a consequence that people engaged in cooperative work are conscious

1Although the concept of “cooperation” has been applied to several other fields, e.g. thewhole animal reign [Wilson, 1975], ensembles of computational machines [Ferber, 1999] andmany other phenomena [Axelrod, 1997], we adopt the narrower and specialistic acceptationthat CSCW researchers conventionally give the term.

2We are speaking of shared goal, instead of common goal to hint that motives calling forsome form of cooperation can be even discordant and not aimed at the very same goal. Cooper-ative work can be justified even by the common goal of having one’s individual goal achieved,once some mutual interdependency within these individual tasks is detected and acknowledged(cf. [Bannon and Schmidt, 1991]).

3


of being mutually dependent in their work, they also feel the need to under-

take the additional activity of managing and controlling the overhead cost that

is connected with the dependencies implied in cooperative relationships. The

additional effort to articulate interdependent distributed activities in one co-

operative job is then called “articulation work”. From its simple definition, it is

pretty clear that articulation work is a distinct kind of work from cooperative

work, that conversely refers to the very ongoing activities in the field of work.

Realizing the distinct nature of these two classes of work corroborates the

argument that articulation work can be supported as an independent process

that manages the coordination of interdependent activities by abstracting from

the cooperative work setting they belong to. In that sense, the mission of the

CSCW can be declined in several complementary ways, all traceable back to

the two fundamental souls of “teamwork”: on the one hand, information tech-

nology and computational capabilities can be aimed either at augmenting the

information sharing capacities of actors (e.g., messaging, teleconferencing) or

at facilitating the exploitation of multiple work strategies and heuristics (e.g.,

project management, collaborative writing, knowledge management); on the

other hand, IT can be aimed at supporting the ordering (in the sense of or-

derly arrangement, cf. also [Schmidt and Wagner, 2004]) and the combination

of specialized and interdependent activities (e.g., work-flow like solutions);

or at fostering and reconciliating multiple perspectives and conceptions (cf.

e.g.,automatic reconcilers [Sarini and Simone, 2002] ).

In such wide range of possibilities and application domains, the two main

conceptual proposals that have influenced and inspired our research — both

in terms of design-framework and architecture — have been the concep-

tualizations of collaborative awareness [Lauwers and Lantz, 1990, Dourish

and Bellotti, 1992] and of common information space [Schmidt and Bannon,

1992, Bannon and Bødker, 1997]. Both contributions refer to two precise re-

quirements that can be considered as fundamental and indispensable in any

work arrangement: the need to be aware of what is going on within such ar-

rangement and the need to share information as a way to smoothly manage

mutual dependencies. In the following sections we treat how these two as-

pects of cooperative arrangements can inform the design of computer-based

applications that can support actors both in becoming aware and sharing rel-

evant information about their work and setting.

4

1.2. THE NEED TO BE AWARE

1.2 The need to be aware

Even in an informal context of casual observations, it is easy to recognize

that in a co-located cooperative setting, in order to interact effectively, actors

need to be aware of each other, e.g., to take heed to who is where, what is

doing, whether she can help us and so forth. In such situations, colleagues

in a given cooperative setting seem to exhibit several strategies to maintain

almost effortlessly — and sometimes even unconsciously — reciprocal aware-

ness: their ability to get a comprehensive (for their needs) picture on “what is

going on” in the surroundings is based on a number of sources like peripheral

sounds, quick glances and indirect clues, like “traces” left either voluntarily

or unwittingly in the common environment. Such environmental clues are

also the basis for the acquisition of awareness on “what went on” earlier, a

hindsight awareness that can be as useful as the mutual awareness [Benford

et al., 1994] in deciding what to do “now and next”, i.e., as a basis for asyn-

chronous coordination. We will come back to the way the environment can

provide cooperative workers with useful indications when we will explicitly

treat environment-mediated coordination and the concept of stigmergy (see

Section 1.5)

It is pretty obvious that, except these possibly meaningful traces left be-

hind by Tom Thumb co-workers sometime in the past, by moving towards

highly distributed and asynchronous work settings, the physical background

of mutual awareness would even completely lack, and with it the ability for

coworkers to keep aligned with each other and being constantly and properly

articulated towards the common goal achievement. In such contexts, informa-

tion and communication technologies have been seen either as what can be

applied to work settings in order to circumvent the shortcomings derived from

this lack of background (e.g., [Sengupta and Zhao, 1998]); or, conversely, as

those technologies that, having made these shortcomings possible, by mak-

ing at-distance work feasible, convenient and even necessary in many pro-

ductive sectors, must hence be properly tailored to fulfill the requirements of

computer-mediated cooperation [Galegher and Kraut, 1990].

1.2.1 Defining what to be aware of

Within CSCW, the role of collaboration awareness [Lauwers and Lantz, 1990]

in work settings has been highlighted by many authors presenting empiri-

5


cal studies of cooperative work, starting from Heath and Luff [Heath and

Luff, 1992]. As a consequence of the increasing importance of information

technology in preserving and enhancing such kind of information, it is from

the beginning of 1990s that the concept of awareness has become a key one

within the CSCW field, although its interpretation and application have al-

ways been pretty far from being clear-cut and univocal [Schmidt, 2002]. As

a matter of fact awareness is often preceded by a plethora of adjectives, like

passive, mutual or workplace awareness [Dourish and Bellotti, 1992,Schmidt,

1998, Gutwin and Greenberg, 2002], that denotes but the fact coordination

in real situations is achieved on the basis of different forms of awareness re-

garding the (often) “elusive practices of taking heed of what is going on in

the [work] setting” [Schmidt, 2002], and of getting a view of “who is around,

what activities are occurring, who is talking with whom” in the daily work

environments [Dourish and Bly, 1992]. From the point of view of the design

for supportive technologies to cooperative work, awareness regards a particu-

lar “mode of coordination” pertaining to different actors’ abilities, such as the

ability of identifying a relevant information from the background, to interpret

it in a given context [Simone and Bandini, 2002] and to properly react to it

on a voluntary basis [Simone and Schmidt, 2000].

Among the very first contributions to the matter, Dourish and Bellotti pro-

posed for the concept of awareness in cooperative work domains the defini-

tion of “an understanding of the activities of others, which provides a context

for your own activities” [Dourish and Bellotti, 1992]. The authors’ greatest

merit for this first contribution to the matter was twofold. On the one hand,

they consolidated a programmatic approach by which awareness could be

somehow related to some specific information (which can be rightly called,

awareness information), an information which is “always required to coordi-

nate group activities, whatever the task domain”. On the other hand, they also

shed light both on the ways in which such information could be (even algo-

rithmically) derived from the context in which competent actors work and on

the way such actors could be provided with such information by mechanisms

through which they can inform each other of their activities.

From that seminal contribution on, the research community has been ex-

ploring how people exploit awareness information in real working situations,

for at least two main purposes. On the one hand, researchers have focussed on

finding common and recurring elements toward a comprehensive though nec-

6

1.2. THE NEED TO BE AWARE

essarily abstract classification of how such information is produced and con-

sumed in traditional (i.e., not yet digitized) settings; on the other hand, they

have tried to understand how awareness information could be automatically

provided by applications that Lauwers and Lantz first called “collaboration-

aware” [Lauwers and Lantz, 1990] to help distributed collaborators in align-

ing with each other more smoothly.

Although pretty soon most of the authors involved in such research agreed

the concept of awareness could be used to denote “those practices through

which actors tacitly and seamlessly align and integrate their distributed and

yet interdependent activities” [Schmidt, 2002], what has always differed

among these various contributions was the way in which this rather simple

concept was operationalized or which particular aspect of the whole aware-

ness phenomenon had to.

Recent surveys, only within the CSCW community, has ended up by list-

ing and describing up to nineteen different types of awareness information

(e.g., [Jang et al., 2000]). In those listings, the focus is alternatively put ei-

ther on awareness about others’ activities (what are they doing and where

are they — cf. the concept of activity awareness in [Gutwin et al., 1996]);

about each other’s availability (when can I reach them and how [Tollmar et al.,

1996]); about process (where am I in the project and on whom do I depend);

about the surroundings (cf. the concept of environmental awareness [Fussell

et al., 1998]); or even about intentions and perspectives (what are others

thinking and why are they doing that [Boland et al., 1992]).

Since the plethora of definitions proposed lead almost necessarily to con-

notations that end up by overlapping, we have adopted the approach of others

researchers (e.g., [Jang et al., 2002]) in considering first what information

needs have been exhibit in a real work domain and then trying to formulate

a framework that focuses on the conceptualization of such needs and that

enables the deployment of computational means supporting awareness pro-

motion.

A general but yet quite distinctive and important point about awareness

is that regarding its passive or active nature. The practices actors apply to im-

prove the coordination of their activities are a combination of monitoring oth-

ers’ activities and, more generally, the surrounding context of the cooperative

arrangement. Studies have reported that actors improve their coordination by

also deliberately displaying aspects of their own activities so that coworkers

7


can be stimulated in taking heed of their activity [Heath and Luff, 1992].

Hence, awareness promotion is not always a “passive” practice but rather

could require the additional effort both in pointing out things others ought

to be aware and in personally coping with their perception. This argument

necessarily influences at great extent how to properly design technological so-

lutions supportive of both monitoring and displaying awareness information.

In our specific case, who produces content on documents is also committed

in linking data with other contextual information so that “a web of signifi-

cance” [Bossen, 2002] can be managed and used to produce awareness in the

ways we will outline in Chapter 7.

Once the preconditions to create awareness are fulfilled, two conclusive

and important issues must be considered regarding the extent awareness in-

formation can be useful and not obtrusive of the regular flow of cooperative

work. The first aspect concerns what awareness information has to be dis-

played and when. The second implication concerns how awareness informa-

tion has to be conveyed, and hence visualized. Both aspects have different but

deep implications on the design of supportive technologies.

As we will see in the course of this thesis, in our proposal we do not explic-

itly consider the second aspect, since we focus on the coordinative function of

artifacts, not their interactional one. The what and when awareness should

be provided are instead aspects that deeply characterize our proposal leading

to the concept of conventional mechanisms (or just conventions) for the provi-

sion of awareness information (see Section 5.2). The time when awareness is

to be displayed will be based on the specific conventions that within a spe-

cific domain are established on documental content and work context (see

Section 3.2). Which kind of awareness information has been derived from

the analysis of requirements collected from an observational study will be re-

ported in Section 5.2.

1.3 Artifact mediated awareness

According to a simple distinction proposed by Gutwin and Greenberg [Gutwin

and Greenberg, 1997], there are two primary mechanisms by which awareness

is maintained: communication and observation.

Communication can be either characterized along several dimensions: it

can be either direct or indirect; either verbal or nonverbal, i.e., through prox-

8

1.3. ARTIFACT MEDIATED AWARENESS

emic modalities like gestures and body language. What characterizes commu-

nicated awareness information is that actors emitting this kind of information

really mean to provide it, typically for some coordinative aim. To use an ex-

pression used by Simone and Bandini in [Simone and Bandini, 2002], com-

municated awareness is an add-on awareness, “something generated explicitly

by actors” [Gutwin et al., 1996,Heath et al., 2002] and the outcome of an ad-

ditional activity carried out on a voluntary basis by actors depending on their

evaluation of the contingent situation.

Also observation can be characterized in several ways, ranging from ca-

sual noticing to attentively watching. It can occur at any time and observed

awareness does not require actors to explicitly and consciously produce add-

on awareness: their very actions, as well as the effects of these actions can

inform their colleagues on what they have done, are doing, and even are go-

ing to do. Awareness by observation is what is also denoted as by-productawareness [Simone and Bandini, 2002] in that it “is generated in the course

of the activities actors must do in order to accomplish their cooperative tasks”

and not for sake of coordination. In this case, hence, conventions about the

intended use of space and artifacts — which include aspects concerning both

how, where, when and even why the latter are used — play an important role

in characterizing and “coloring” the articulation aspects conveyed by aware-

ness information. For instance, the classic example of inferring that someone

is going to cut something if she is seen holding some scissors [Gutwin and

Greenberg, 1997] would be groundless in a hospital context unless scissors are

conventionally associated with cutting bandages3; likewise, if a nurse knows

that scissors are used at the end of moulding a plaster cast, seeing an or-

thopaedist carrying a pair could mean to her she has to prepare the transfer

for the next patient to be plastered.

As part of the physical environment, material artifacts can be rich sources

of awareness information [Dix et al., 1993]. Whenever artifacts are used, they

‘give off information’ that indicates what is being done to and by means of

them [Hill and Gutwin, 2003], both to who uses them and to others. While

the information that an artifact gives off to its users is usually called feedback,

Dix refers to the term feedthrough to denote the particular channel of commu-

nication by which either by-product or add-on awareness information about

the artifact-mediated activities is conveyed also to others nearby and claims

3As a matter of fact, in the healthcare domain, like in the tailoring and hairdressing ones,there are a number of different scissors, each devoted to a specific task.

9


that such communication through the artifact is often more important than

direct communication [Dix, 1997].

1.3.1 Awareness-related requirements for artifact design

Differently from the case of material artifacts that produce awareness infor-

mation almost naturally in any cooperative work setting [Hill and Gutwin,

2003], in computer-based supportive artifacts, awareness information must

be explicitly gathered, transmitted, and redisplayed. The way this is accom-

plished depends to a great extent on the intended purpose why awareness

information is provided.

Within the controversial debate regarding structured versus unstructured

flow of work, procedures versus exceptions-handling, regularity and ad-

hocness in cooperation [Simone and Schmidt, 2000, Simone and Bandini,

2002], we also consider awareness information as a feasible means to support

as naturally as possible actors that have to employ some artifact to, among

other things, smoothly and seamlessly coordinate with each other.

The commonsense acceptation of the term smoothness hints the idea of

a delicate balance any coordinative technology must reach between the con-

trasting indications of both enabling and hindering action, enhancing and af-

fecting it, and between providing the right information at the right time and

providing useless or superfluous information when it is too late or anyway

out-of-the-context.

Supporting cooperative arrangements by means of the provision of aware-

ness information regards hence providing users with useful maps (cf. [Schmidt,

1997]) of the current surroundings and representations of the environment —

in its widest acceptation — that can be used to make sense of it and take the

right decisions on what to do next and how. As stated in [Divitini and Simone,

2000], awareness is the basic kind of information that can be used to complete

a reference map into a detailed script, and interpret a detailed script as a map,

according to the needs of the contingent situation, without loosing the ‘sense

of direction’.

Informing with such insights the design of an awareness-based supportive

technology to coordination requires first to consider awareness as a mode of

coordination and, more precisely, to recognize different types of actors’ ability

about that mode. Simone and Bandini in [Simone and Bandini, 2002] pro-

pose to distinguish between (a) the ability to perceive a stimulus that can

10

1.3. ARTIFACT MEDIATED AWARENESS

make them aware of something, e.g., as the sound of a fire alarm makes the

inhabitants of a building aware that a fire could have broken out. (b) The

ability to analyze it, e.g., to identify the room in which the fire broke out and

to head towards the closest exit that is safe from fire. And finally, (c) the abil-

ity to interpret the stimulus in the given context, e.g., whether the fire alarm

refers either to a drill, or a minor danger, or a massive threat. These abilities

characterize both the users — namely who is “aware of” the stimulus — and,

consequently, any technology addressed to enhancing those abilities.

According to this ability-oriented perspectives, promoting awareness can

be traced back to the promotion of (a) its production and perception, e.g., by

suggesting or reminding what to do to convey it, or by intensifying the stim-

ulus once it is emitted; (b) its analysis, for example by aptly “presenting” the

information pertaining to the the stimulus; and finally, (c) its interpretation,

e.g., including information about the context where the interpretation has to

be carried out [Simone and Bandini, 2002]. As quite obvious, “promoting”

awareness through some supportive technology at each of these three levels

raises different requirements, in terms of medium, mechanism and content, re-

spectively.

In a cooperative settings, communication and observation are usually me-

diated by a preferential medium — or even an organized set of mediums, that

is not likely to change very often. This is because the medium implies a whole

set of practices and conventions that rely on habit and “familiarity” to reach

and maintain effectiveness and leverage on acquired expertise. This does not

mean that the medium is always and firmly “fixed”. Actors can communicate

and interact in any situated way, but the process of conceiving and designing

a particular supportive technology needs to define a particular medium for its

deployment and concentrate on the requirements that can be fulfilled in spite

of its limitations.

Awareness-related mechanisms are to be intended as the ways by which

a computational system can decide both (a) when to solicit actors for some

add-on awareness act and (b) when to provide actors with either add-on or

by-product awareness on the basis of what is going on in the cooperative ar-

rangement.

Two general requirements for functionalities associated with mechanisms

supporting coordination have been provided about the design of coordination

mechanisms [Schmidt and Simone, 1996]. Following the work by Simone and

11


Bandini [Simone and Bandini, 2002], we also claim these requirements are

general enough to be applied to the design of functionalities for the provision

of awareness information. These requirements are malleability and linkability.

In our research we have interpreted the former in these terms: actors should beable to define conventional mechanisms to manage awareness as well as to mod-ify them according to the changing organizational normative context. This is a

requirement about how mechanisms are represented and made computable

and hence also regards the fact that any intended awareness-centered frame-

work must support a high level and abstracted (from implementation details)

representation4 of the logic by which awareness information should be pro-

moted, both at producer’s and consumer’s side.

Linkability, on the other hand, regards the possibility to link a mechanism

to other mechanisms acting in the same organizational context. The case we

have focussed on is that of awareness mechanisms that apply to a specific

artifact, like in the case of a certain document template that is used within

a greater set of documental artifacts in a cooperative arrangement. Linkabil-

ity refers to the possibility to compose individual document-specific mecha-

nisms 5 into more complex and arrangement-wide mechanisms, which repre-

sent a domain-dependent articulation of more document-wide conventions on

documental items (see Chapter 7 for some examples).

1.4 The need to share information

Borrowing a passage by Brehmer we can claim that “communication is the

cement of the organization, and the greater the need for coordination and

cooperation, the greater the necessity for communication.” [Brehmer, 1991].

Also Schmidt and Bannon pointed out that access to appropriate means of

communication is necessary for the proper articulation of the distributed activ-

ities of a cooperative work arrangement [Schmidt and Bannon, 1992]. These

two references — taken among myriads of similar ones — seem to corrobo-

rate the common-sense consideration that communication is a deeply rooted

and innate need of human beings and a fundamental factor in characterizing

their abilities to cope with ever different situations in the highly dynamic envi-

4Schmidt and Simone speak of perspicuousness of the mechanism, i.e., its accessibility andintelligibility to actors at the semantic level of articulation work.

5We will also denote those mechanisms as local, for their application is local to certainartifact.

12

1.4. THE NEED TO SHARE INFORMATION

ronment that shelters them. Even if we preventively acknowledge the ubiquity

and importance of the phenomenon of communication, envisioning really sup-

portive technologies can not leave out of consideration a reflection on the very

assumptions underlying the concept of communication.

To communicate definitely implies the exchange of thoughts, opinions, or

information irrespective of the ways such interchange is achieved, either by

speech, writing, signs, or —- as we have seen speaking of awareness —- just

by being a perceivable part of the common environment. As also the etymology

of the word seems to convincingly suggest, communication implies “to make

something common”6 and communality is indeed a ‘sine qua non’ condition

for any communication be possible, at at least two fundamental levels. In fact,

besides being common what is communicated, also what by which something

is communicated must be common: i.e., the very same system of symbols,

signs, or even behaviors that are employed to provide our interlocutors with

some information.

The sharing of proper signifiers so that also meaning can be conveyed is not

a trivial task, since sharing in this case must include also agreement, consent,

an even temporary and local conventions that are negotiated and established

by actors involved in some communicative effort. From this quite obvious but

yet important consideration, we can then see how communication enables

cooperation but also, quite surprisingly, that communication needs some will-

ingness to cooperate, some preliminary joint effort in putting something in

common and agreeing upon it. This consideration can affect the way design-

ers conceive of reliable and effective supports for cooperative arrangements.

In fact, it is much easier to facilitate, support and even foster the simple

sharing of data than the sharing of what could enable actors to make sense of

those data. The former kind of sharing is in fact where computer systems suc-

ceed more easily: file sharing, web publishing, emailing are all communication

facilities that in spite of distance have certainly changed how people interact

and work together in the recent years. That notwithstanding, providing the

mere bandwidth of the “transmission channel” is just one side of the coin and

it is still a debatable point how computer-based systems could provide their

users with a full support to communication.

The point is on the very conception of what communication is. Whereas

communication is considered akin to transmittance of information, computer-

6Communication derives from the Latin communis, literally “in common, public, general,shared by all or many”.

13


based support can be (and actually is) declined in terms of accuracy and speed.

This assumption is in the vein of Shannon and Weaver’s [Shannon and Weaver,

1949] classic communication model by which communication is seen as the

process of transmitting a message from a source to a receiver through a trans-

mission channel that can be affected by some noise. In this conceptualization,

noise is seen as an external agent that must be attenuated not to affect the ide-

ally pure relationship between sender and receiver. If noise were eliminated,

just sharing information over a neutral medium would be enough to preserve

the full intended communicative deed.

Quite recently the main assumptions of the classic communication model

have been explicitly questioned (cf. e.g., [Winograd and Flores, 1986, Serres

and Latour., 1995, Avgerou et al., 2004]). Hayles, for instance, argues that

to separate a message from the material in which it is embedded is impossi-

ble [Hayles, 1999]. A common point to several contributions from the con-

structionist research within science and technology studies is the conception

of communication as a process of translation and transformation (cf. e.g., [La-

tour, 1999]). Transformation does not merely regard the intrinsic nature of the

information content, but it especially regards changes in its relational nature.

An entity can change character as it enters into relations with different other

entities: its identity — in the sense of its ‘sameness’ — relies on whether refer-

ences can be made to other instances in its transmission trajectory [Winthereik

and Vikkelso, 2005].

In the light of these contributions, communication can be conceived as of

the twofold sharing of both the communicated entity — as it is necessarily

drawn out of its context of production — and of elements which the receiver

can rely upon to be supported in making use of that entity in her own context

of use. From the point of view of the designer of computer-based systems, this

conception can urge the claim to also enable the sharing of the relationships

that the communicated entity has with its context as well as of the conventions

that can make that entity be transformed — and hence understood — within

the context of use. These ideas found a substantial formulation within the

CSCW community with the introduction of the concept of common informationspace.

14


1.4.1 The common information space

The concept of common information space (CIS) was seminally envisioned by

Schmidt and Bannon in [Bannon and Schmidt, 1991] and then fully developed

by Bannon and Boedker in [Bannon and Bødker, 1997] to contribute to alter-

native mechanisms to workflow-type support to cooperative work [Schmidt

and Bannon, 1992] and to provide indications on why simply providing a

shared access to informational resources does not necessarily imply fruitful

collaboration and sharing of information as elsewhere claimed (e.g., [Rolland

et al., 2006]).

The first acceptation of the expression was about a “space” that comprises

data, personal beliefs, shared concepts, and professional heuristics that could

allow or help people to cooperate and act as a “group” even without direct

communication and without necessarily knowing each other. The main idea

is grounded on the observation that actors, when they jointly articulate their

activities in distributed work settings, tend to construct and manage a “central

archive of organizational information” that “encompasses artifacts that are

accessible to a cooperative ensemble as well as the meaning attributed to these

artifacts by the actors” [Schmidt and Bannon, 1992].

That notwithstanding, in the context of distributed and asynchronous co-

operative arrangements, the idea of a common information space is antithet-

ical to that of a common data base containing all the relevant data from dif-

ferent parts of the organization, a conceptualization that was also opposed by

Ciborra [Ciborra, 1985] as unattainable in practice. The main difference be-

tween a data base and an information space is that in conceiving and designing

the latter the emphasis is put on the ability for users to “actively construct” it,

even at run-time, and to share within and by means of it either simple data

or complex objects all together with their intended meanings and interpre-

tations, which are therein agreed, debated and resolved, at least locally and

temporarily [Schmidt and Bannon, 1992].

Common information spaces come into existence when users can make

sense of the data shared, i.e., can be informed by them, as a consequence of

the mutual effort made by both the producer and the consumer of certain data

to understand each other’s context and “putting in common” with each other.

The information “put in common” must be shared all together with “with some

level of ’shared’ agreement as to the meaning of this information” so that

possible “differences concerning the origin and context of these information

15


items” can be properly interpreted and consistently coped with.

“Shared agreement as to the meaning of information” are a central con-

cept of the CIS proposal: a common information space to be such can not be

constituted only by commonly available information and shared information

holding artifacts, like documents are, but rather also by interpretations of such

information. These interpretations would allow actors to use those artifacts

as a basis for mutual understanding and to really put information in common

(or at least ‘common enough’, despite the “different conceptualizations and

multiple decision making strategies”).

Bannon and Bødker [Bannon and Bødker, 1997] use the term packagingto denote the action of extending information items with some explanation

or rationale of their context and, the way round, unpacking the activity of

the reader to extract that additional information and recreate its intended

meaning.

Packaging and unpacking are not meant to denote a smooth, linear pro-

cess and can refer to a myriad of ways in which people make sense of each

other’s information, depending on the particular reference domain of coop-

erative work. Of particular interest for our research within the lively debate

concerning this concept (e.g. [Bannon, 2000, Randall, 2000]), the concept

of CIS has been also applied to the analysis of cooperative work mediated

by an official and institutionally-structured set of documents, as in criminal

courts [Elliott and King, 2005] and in healthcare settings, like hospital wards

and departments [Josefsson, 1999,Bossen, 2002,Tellioglu, 2003]. In such set-

tings, the pretty rigid structure of the organizational information that is shared

by means of the documental system and the constraints that are institutionally

imposed over its content limit to a great extent the “degrees of freedom” by

which interpretations can be conveyed in the same space of shared informa-

tion. In such contexts, the difficulties in packaging and unpacking context are

somehow exacerbated and can regard both the packer and the unpacker.

In fact, in the specific case of documents, as particular structured inscribed

artifacts [Schmidt and Wagner, 2002b], who is supposed to pack information

has inherently an incomplete sense of whether her documents will eventually

be of interest for someone else [Hertzum, 1999] and, if they will, to whom

and in what context. Moreover who packs an information has to force the full,

even manifold, correct interpretation of some data in something that is neces-

sarily univocal and narrow-intended and she has to accept even the straining

16


and forcing implied in simplifications and standardization. Also the task of the

unpacker is difficult. In fact, it is pretty common sense that one thing is to sym-

bolically represent some additional contextual information and quite another

is to make a full and operating sense of it, by adapting it to her context of use.

According to the conception of communication seen above, the unpacker is

rather an interpreter that has an active role in translating the message in her

own language and conventions, since no translation can be given in advance.

This consideration represents the staring point for our proposal, in which

we have investigated how to feasibly enable the creation of an “information

space” and how to make it “common”, by focussing on the conventional nature

of the interpretations that can be conveyed through such space.

For a simplification suggested by the need to make them computable and

processable by computer-based systems, we conceive of interpretations as

mere conventions, i.e. agreements on the production and use of information.

From the point of view of the designer of computer-based systems that are

informed by the concept of common information space, these conventions

can be seen as subjected to a three-step process: first they are established as

the result of a negotiation by the actors involved; then they are externalized

(cf. [Nonaka and Takeuchi, 1995]) in some appropriate description format;

and then made interpretable7 by computational machines so as to inform the

automatic provision of useful information where and when it needs. Each step

can present difficulties that are not trivial to solve in every context of appli-

cation. Even once conventions are actually observed in the field of work and

computer systems are deployed with some desired result, the externalization

of conventions necessarily implies the risk common to any decontextualiza-

tion into canonical forms [Brown and Duguid, 1991]. That notwithstanding,

the conception of communication as transformation rather than mere trans-

mission does not require externalized knowledge on conventions to be strictly

formal but, on the contrary, can advocate for it to be contextual, contain ambi-

guities — even deliberate — and require explicitly interpretation [Mulholland

et al., 2002].

7Obviously we are now using the term interpretation as the operation carried out by com-puter programs that executes other programs (i.e., interpreters).

17


1.5 Focussing on mediated cooperation

Let us now focus on those work settings where communication is often only

asynchronously achieved, and information sharing and articulation work oc-

cur in distributed cooperative arrangements involving a large and varying

number of actors.

From its earliest contributions, the CSCW community has been constantly

collecting evidences that this particular kind of work settings poses the most

demanding challenges to computer-based support design [Carstensen and

Schmidt, 1999]. In fact, claims are made that the various and consolidated

forms of everyday social interaction appear to be insufficient [Schmidt and

Bannon, 1992] and that the design needs thorough analyses to be conducted

toward a clearer comprehension of the role that artifacts play in objectifying

the various mechanisms of interaction that actors apply so as to reduce the

complexity of articulation work [Schmidt, 1991]. Quite recently, on the basis

of a survey of contributions spanning from the end of the 80s to some years

ago (e.g. [Harper et al., 1989, Sellen and Harper, 2003]), Schmidt and Wag-

ner did not hesitate in connoting such role of artifacts as crucial [Schmidt and

Wagner, 2004].

It is somehow self-evident that actors engaged in asynchronous and dis-

tributed work settings must rely also on “something else” than the here-and-

now — the contingency of a spoken utterance — to communicate, to put some-

thing in common, or just to take heed of what they are doing. This ‘something

else’ must necessarily be something ‘out-there’, the external world, i.e., the

environment sheltering both coworkers and their activities.

The interest for reaching a comprehensive understanding of the role of en-

vironment in the ambit of coordination-oriented research is common to many

disciplines, which are some times adjacent, some other times just complemen-

tary. In particular, within the wider field of computer science, environment-

mediated coordination is a programmatic research topic within the Multi-

Agent Systems (e.g. [Parunak et al., 2003, Omicini et al., 2004]), the Human

Computer Interaction and the CSCW fields. Within the latter field, in par-

ticular, several researchers have accomplished inclusive analyses of the way

the materiality of the work setting is exploited by involved actors to effort-

lessly and fluently coordinate their individual activities (cf. e.g., [Harper et al.,

1989,Heath and Luff, 80,Suchman, 1996,Schmidt and Wagner, 2002a]).

Some CSCW contributions, e.g. [Fjeld et al., 2002,Halverson, 2002], have

18

1.5. FOCUSSING ON MEDIATED COOPERATION

also recently focussed on cognitive and social theories which explicitly take

into account the role of environment and artifacts in coordination, such as Dis-

tributed Cognition [Hutchins, 1996] and Activity Theory [Kaptelinin, 1996]

and Situated Action [Lave, 1988].

As regards these three main theoretical frameworks and their comple-

mentary contribution to system design [Nardi, 1995], Susi and Ziemke have

claimed that in relation to how they describe the role of artifacts in collabora-

tive activity, their common denominator can be traced back to the concept of

stigmergy [Susi and Ziemke, 2001]. This concept comes from the studies re-

garding how even the simplest animals 8 are capable of reaching complex lev-

els of coordination through the signs they make and perceive within a shared

environment, a phenomenon for which the French entomologist Grasse coined

the term stigm-ergy9 right to capture the notion that when an agent acts it

also necessarily ends up by leaving signs, which itself, as well as other agents,

can perceive and determine their subsequent actions upon [Theraulaz and

Bonabeau, 1999,Parunak, 2003].

The concept of stigmergy can be even further characterized into either

sematectonic or sign-based stigmergy as a useful distinction that consider, re-

spectively, whether signs or, more generically, modifications to the environ-

ment, are the unintended effect, the by-product of some task-related activ-

ity, or, conversely, they are the results of a conscious and intentional act that

makes no further contribution to the task at hand but rather is accomplished

with the aim to influence and direct its activities [Wilson, 1975]10. This dis-

tinction can be useful in drawing a parallel with the human ambit of coopera-

tive work11 and indeed it is quite similar to the distinction between by-product

8The study of how simple animals like insects (e.g., ants, termites, bees) cope with theever-changing complexity of the surrounding environment in some brilliant ways have recentlyinfluenced the research in the fields of Artificial Intelligence and Robotics (e.g., [Brooks, 1991,Steels, 1994,Ferber and Mueller, 1996]).

9The term is formed from two Greek words, stigma and ergon, standing for “sign” and“action”, respectively.

10A popular example of sign-based stigmergy comes from the well known Tom Thumb taleby the Grimm brothers.

11With this we are not meaning that transferring lessons from the biology or entomologyfields to the social and human-centered research could be in any case either a feasible orconvenient process, although some inspiring and fecund passage can not be beforehand denied.Specifically, many reservations in adopting the concept of stigmergy as it is and considering itcentral in human coordination can be raised since, obviously, human beings are not prettysimple stimuli and response animals and can make an articulated and manifold sense of signs,according to their structure, their meaning and the culture in which they are left (cf. [Bourdieu,1977]).

19


or add-on awareness, respectively (see Section 1.3). In fact, besides the works

we have mentioned above, a number of other studies have showed how co-

operative actors even transform the physical environment [Kirsh, 1995] to

interact and represent tasks: notable examples are derived by observations

carried out in airline cockpits [Hutchins, 1995], control rooms [Heath and

Luff, 1992,MacKay, 1999] and hospital desks [Bang and Timpka, 2003].

1.5.1 Artifact mediated cooperation

In the following, we will limit our discussion on pretty well delimited, special-

ized and standardized portions of the environment, i.e., the physical artifactstherein used. According to the authoritative Oxford English Dictionary, the

word artifact entered the English language in the mid 1800s, and from then

on, it has indicated any material that has been shaped by humans through

some kind of practical skill or art12. Although Dobres has rightly noted that

the concept of artifact privileges the processes of tool creation over their actual

use [Dobres, 2000], we know from the fields of archaeology and anthropology

(e.g., [Miller, 2004]) that to recognize an “artifact” from an undifferentiated

object within the environment is akin to an interpretative act of its user, as a

member of a work arrangement where both the expectations on the artifact

and the actual use that people make of it are socially and culturally situated.

Among the very disparate purposes that can be implied by the use that

cooperative workers can make of almost any artifact at their disposal, some

contributions from the above referenced literature have concentrated on those

kinds of artifact that have been respectively denoted with the attributes cogni-tive, knowledge and coordinative.

Cognitive artifacts have been defined both with respect to their concep-

tion and their use: Norman defines them as artifacts “designed to maintain,

display, or operate upon information in order to serve a representational func-

tion” [Norman, 1991]; while Hutchins, on the utilization side, defines them

as those artifacts that are used by actors to aid, enhance, or improve their cog-nition [Hutchins, 1996]. Both these complementary characterizations stress

the function of cognitive artifacts of being supportive of the human abilities of

reflecting on things, remembering, solving problems and accomplishing com-

plex tasks, either within the personal and individual dimension where actors

interact directly with the artifact at hand, or within the collective dimension

12The word artifact is a combination of two Latin terms, ars (art) and facere (to make).

20


in which multiple actors work together and communicate also with the medi-

ation of their artifacts.

When artifacts are primarily used to objectify how people within an orga-

nization and community organize their “memories” about their experiences,

their work and the involved knowledge that allowed them to solve prob-

lems and make proper and timely decisions [Seiner, 2001, Bandini et al.,

2003], artifacts can be denoted as knowledge artifacts. Although the concept

of knowledge is one of those on which it is almost impossible to achieve

widespread agreement, Seiner defines knowledge artifact as any “defined

piece of recorded knowledge that exists in a format that can be retrieved to

be used by others” [Seiner, 2001]. Traditional examples of knowledge arti-

facts a la Seiner are dictionaries, thesauri, classification systems, encyclope-

dias (cf. [Headrick, 2000]) but also cooperative settings provide several ex-

amples since any manual, internal report, bulletin and circular can be consid-

ered a knowledge artifact, as long as it “incorporates” some core competencies

and “best practice” that members of a cooperative group can refer to to solve

problems and add value to their activities. Bandini et al., on the other hand,

stress on the way such externalized knowledge [Nonaka and Takeuchi, 1995]

is really shared within a certain community of practice and on the way such

artifacts are collectively defined as the result of a progressive stratification of

experiences and ad hoc practices of use [Bandini et al., 2003].

When such or similar artifacts are used for coordination purposes, the term

“coordinative artifact” was proposed in [Simone and Schmidt, 2000] to de-

note their capability to help actors in managing task interdependencies that

are too complex to be managed with ad hoc interaction and improvisation

based on mutual awareness. Coordinative artifacts can achieve such articulat-

ing capability in a number of ways (cf. e.g., [Heath and Luff, 1996a]) both

in a intra-setting dimension and in a inter-setting dimension. In the former

case, they are informational structures describing the current state of affairs

in terms of responsibilities, current activities, plans for future actions and the

like. In the latter case, they can be assimilated to the concept of boundary ob-jects [Star and Griesemer, 1989,Bowker et al., 1997], that is of objects used “at

the borderline” between different groups and communities of practice to sup-

port the articulation of activities occurring across their either physical or social

boundaries in virtue of their capability of adapting to different viewpoints and

maintaining their own identity across them.

21


The important point about coordinative artifacts is that they exert their co-

ordinative function both in virtue of their shape and structure and of the waysthey are put in use, i.e., for the correlated practices of use. The relationship

between artifacts and coordinative practices has been articulated in [Simone

and Schmidt, 2000] into three general use modalities: coordinative artifacts

can be used by competent actors either as (a) templates, when they specify

the properties of the result of cooperative work; (b) maps when they spec-

ify interdependencies of tasks or objects in a cooperative arrangement; or

as (c) scripts when they specify a protocol of interaction. Several examples

can be given for each of these categories as they can be drawn from sev-

eral studies (e.g., [Suchman, 1993, Haas, 1996, Heath et al., 2001, Schmidt

and Wagner, 2002b]): forms, drawings, manuals, list, spreadsheets, even MS

Word documents. The point of these reports is to shed light on the fact that

although different artifacts like product standards, organizational charts or

production schedules are used for different purposes according to the context,

that notwithstanding they all share the capability to assists actors in reducing

the complexity of coordinating their activities by either embedding, circum-

scribing or just referring to actions, in the same way as the physical and social

circumstances do [Suchman, 1987].

The conceptualization of the strict interdependency between coordinativeartifacts and cooperative practices has been further characterized by Schmidt

and Wagner when they introduced the concept of ordering system [Schmidt

and Wagner, 2004]. An ordering system is any complex cluster of interrelatedpractices and artifacts that due to their mutual entanglement do not limit

themselves in representing the material world (a function that can be exerted

also by simpler cognitive artifacts), but rather they “are in the service of im-

posing some order” on it. Ordering systems are then seen as particular sets of

inscribed coordinative artifacts13 that do not only play the mere role of repos-

itories where “actors express items of coordinative relevance in a durable and

yet mobile form” so that their colleagues can revisit such items at a later stage.

Such coordinative artifacts are rather capable of coordinating actors and ac-

tions in that they “concatenate and configure items in certain spatiographical

ways” [Schmidt and Wagner, 2004] and explicitly refer to the protocols and

13Here again, we stress on the fact that we limit our attention on inscribed coordinativeartifacts. In so doing we purposely choose not to consider as relevant for our purposes themyriads of handmade objects and tools that can be used to coordinate with each others. In thisway, moreover, we introduce our main domain of interest — the documental one.

22


conventions in which such orders make some sense to the intended actors.

Both artifacts, and the practices in which they are used, contribute in stipulat-

ing and mediating the articulation of distributed activities: artifacts in virtue

of their symbolic and standardized nature; and practices due to their conven-

tional and predictable nature.

Such two components are so tightly intertwined that Simone and Schmidt

coined the term coordination mechanism [Schmidt and Simone, 1996] to de-

note an artifact-practice dyad consisting of a coordinative protocol “imprinted

upon” a distinct artifact, which becomes a coordinative artifact in that it stipu-

lates and mediates the articulation of activities so as to reduce the complexity

of a certain cooperative work arrangement.

The idea that artifacts can be characterized by something “visible and exte-

rior” that is shaped and characterized by something that is therein “concealed

and interior” comes from an intuition by Norman in which he distinguishes be-

tween a ‘surface representation’ and an ‘internal representation’ of cognitive

artifacts. While the former regards displaying and interacting with inscrip-

tions, the latter can be ascribed to the protocol by which actors handle and

use the artifact in their work trajectories [Schmidt, 1994b]. The ‘surface rep-

resentation’ of a checklist, for instance, provides an adequate interface to the

‘internal representation’ in that the sequence of scheduled tasks that are pre-

scribed by the protocol is represented graphically in the tabular form of a list

and for each task there may be a check box that indicates the state of execution

of the protocol.

The seminal idea of making automatically change the ‘surface represen-

tation’ by executing the ‘internal representation’ expressed by the scripting

protocol and the requirement of making operational and computational the

concept of coordination mechanism led to the idea of embedding some com-

putational capability to coordinative artifacts, so as to make them also active.

The notion of active artifact was then proposed in [Divitini et al., 1996, Divi-

tini and Simone, 2000] to denote those artifacts that are capable of assuming

an active role in mediating information exchange and coordination among co-

operative actors. In the original proposal, active artifacts were intended to

incorporate aspects of the protocols and conventions by which information is

exchanged through the artifact itself. With such “scripting addition” artifacts

can automatically convey changes to their content that have been induced by

some actor to other actors and components of the system, in the appropriate

23


form stipulated by the protocol iteself. The active behavior embedded in the

artifact is intended to promote both task alignment and mutual awareness, by

materializing and making visible the state of the distributed procedures and

conventions holding in the current context of a given cooperative setting. This

is achieved by providing actors with appropriate information in presence of

particular conditions in terms of either voluntary (awareness) or compulsory

(coordination) indications to follow to have the work done as expected [Si-

mone and Schmidt, 1998].

1.6 Toward a support of mediated cooperation

The main underlying idea of our proposal is that of starting from the concept

of an active coordinative artifact that embeds in itself a number of conventionspertaining to its structure, content and use. As we have already mentioned

above, we have chosen the term convention to informally denote something

akin to a descriptive — rather than prescriptive — mechanism of interaction,

i.e. to the immaterial protocol component of a coordination mechanism that

regards the very “conventions” that actors have agreed upon to manage their

local cooperative work setting.

In order to understand the nature of the information such mechanisms

could convey, we undertook an observational field study to collect real in-

formation requirements of the cooperative actors involved in a domain that

for its characteristics and challenging complexities has been widely studied

within the CSCW literature: the hospital-based healthcare14. Within this ref-

erence domain, we have recognized the often amazing abilities that practi-

tioners articulating their tasks exhibit on-the-go by relying on verbal, prox-

emic interactions and often tacit and underspecified conducts [Coiera, 2000].

And — what has also surprised researchers from almost forty years ago (cf.

Harold Garfinkel and Anselm Strauss) — we observed that such ad-hocness

and informality are coupled and cohabit with strict demands for trust and

accountability mediated by a very composite and heterogeneous ensemble of

artifacts playing a multiplicity of roles and functions.

This posed us the tough challenge to envision a generic class of computa-

tional supports that could facilitate articulation work while being almost com-

14In the following we will often refer to such domain calling it clinical domain, for our focuson actual observation and treatment of disease in patients rather than hospital experimentationor teaching.

24

1.6. TOWARD A SUPPORT OF MEDIATED COOPERATION

patible to and least disrupting of the often situated practices by which prac-

titioners align their actions and delegate tasks to each other. Consequently,

we focussed on the phenomenon of awareness and were motivated to observe

how practitioners actually retrieve from that composite “web” of artifacts the

information they feel to need to be aware of.

Our proposal also considers to put each single digital counterpart of those

artifacts into a tightly interconnected ensemble of other similar coordinative

artifacts that share their content as well as their conventions and sensibilities

to contextual elements. We have denoted such integrated ensemble a web,

both to refer to the communication flows which are enabled by the computa-

tional capabilities of the artifacts involved and to hint at the set of relation-

ships that are defined and drawn among structural and content elements that

such artifacts carry on.

This idea of putting such active artifacts in common, both as regards their

content and their local conventions of use represents the endeavor to decline

the concept of active artifact that we have just mentioned in Section 1.5.1

in the wider application domain of common information spaces, recalled in

Section 1.4.1.

The idea of calling the ensemble of interconnected artifacts a web, has also

been inspired by the research that Bardram and Bossen accomplished about

clinical work [Bardram, 2000]. They introduced the concept of “web of coor-

dinative artifacts” [Bardram and Bossen, 2004, Bardram and Bossen, 2005b]

as creative analogy by which to analyze how coordination is achieved when

practitioners do not use just one artifact, like a schedule, but rely on “sev-

eral heterogenous artifacts, like schemas, charts, lists, whiteboards [which]

all play a multitude of different roles, but are at the same time highly inter-

woven” [Bardram and Bossen, 2004]. The entangled nature of this web refers

to the fact that they offer different views upon the same information while at

the same time peculiar functionalities are provided depending on the context

and the information.

In the rest of the thesis we will focus on a particular class of coordinative

artifacts, i.e., the class of standardized and institutional inscribed artifacts that

compound a documental system: i.e. documents.

Our motivation relies on two main considerations: the former has been

mentioned when we said that structured documents pose important challenges

in the concretization of a documental common information space (see Sec-

25


tion 1.4.1). The latter regards the evidences we collected from our obser-

vational studies that confirm other contributions from the specialist litera-

ture (e.g. [Luff et al., 1992, Berg, 1999]) reporting how documents, as flexi-

ble but yet task-constraining coordinative artifacts [Schmidt, 1997] (see Sec-

tion 1.5.1), play an essential role in coordinating work and enabling syn-

chronous as well as asynchronous collaboration [Strauss, 1985]. In addi-

tion to that, we observed how documents, as components of integrated yet

heterogeneous sets of documents (i.e., documental systems) play a whole

range of coordinative functions according to the practice they mediate [Berg,

1999,Bardram and Bossen, 2005b]; while — at the same time — they also play

the chief functionality they are used for: informing actors and providing them

archival memory for distributed and asynchronous knowledge sharing [Ban-

non and Bødker, 1997, Harper and Sellen, 1995, Star and Griesemer, 1989].

Maintaining this twofold functionality is of paramount importance when a

cooperative setting needs to transform its documental ordering systems from

paper-based traditional artifacts to their digitized counterparts.

In the following chapter, we will outline the main characteristics of the

documental domain and those aspects of the document-based practices in co-

operative work arrangement that we deemed of interest for a feasible and

unobtrusive deployment of a computational support to make sense and use of

what is recorded within official records and institutional documents.

26

Chapter 2

The documental domain

Among the myriads of artifacts that the human species has produced to shape

and tame its surrounding environment, documents are not the oldest, but cer-

tainly ones of the most versatile. A document can neither hone a lance nor

cook a fish but it can tell who reads it how to. Documents are the tools by

which the humankind reifies its voice and preserves it from the oblivious tran-

sitoriness of its verbal utterances.

Memory was only the first of the human faculties that documents were

intended to support and augment, since when the very first inhabitants of

permanent agrarian encampments began to need to count their property or

transfer that property to another individual, almost ten thousand years ago.

Across centuries, with the evolution of writing systems and the increase of the

number of people that could read them, documents have more and more ef-

fectively supported their users in generating and conveying meaning, building

and sharing knowledge, as well as in instructing and sharing information with

others in almost any sector where verbal and co-located communication is not

just enough.

Nowadays, it is very difficult to think of any productive sector of our soci-

ety, as well as of any other culture or human society, where documents are not

present in some form, and do not play the pervasive role of either silent wit-

nesses or passive support of our activities. It has been estimated that, in 2004,

white-collar workers have spent from 30 to 40 percent of their time in dis-

tributing, filing, and retrieving documents, while just seven years earlier they

spent a quarter of their time in managing documents; and that more than

85 percent of all business information exists in documental form1 [Gordon,1IN such estimates by Merrill Lynch & Co. Inc. documents are opposed to structured data

27

CHAPTER 2. THE DOCUMENTAL DOMAIN

1997,Blumberg and Atre, 2003].

Despite documents’ pervasiveness, and right because of their versatility, to

wonder “what a document is” (cf. [Buckland, 1997]) is not a futile question.

Indeed it is a fixed course toward speaking of documental systems — i.e.,

functionally integrated groups of interrelated documents — and to then be

able to propose some computational means to make such systems more and

more supportive of human work.

2.1 An operational definition of document

Contributions by researchers as Paul Otlet and Suzanne Briet — dating from

the very foundation of documental science at the beginning of last century —

proposed to consider as documents as any object (or even any expression of

human thought) that is functionally capable to inform its user by representing

a physical or conceptual phenomenon [Buckland, 1991b]. Among the several

definitions given in various domains and for different scopes, some stress the

textual dimension, while others the fact that documents are such if they fur-

nish evidence or official, first-hand information [Buckland, 1997]. In order to

avoid the risk of missing some relevant features of the documents our research

is about and of considering almost anything as a document2, we shall adopt a

narrower acceptation of document.

For our practical purposes, a document can be defined as “anything” hold-

ing some inscription that bears some relevant information. Information-as-thing, has been the suggestive definition of Buckland for documents, in that

they are particular artifacts having the specific function of imparting knowl-

edge or communicating information [Buckland, 1991a]. Materiality, indeed,

i.e., the quality of documents of being material, usually paper-based, is a re-

quirement that documents are increasingly relaxing in their ability to docu-

ment, probably as one of the many consequences of being in the so called

“digital age” where content — i.e., what only actually can be digitized — is

more relevant than medium. Accordingly nowadays, in an increasing number

of domains, a document is deemed as any “information container”, irrespec-

within databases and encompass “electronic” documents like e-mails, reports, letters, whitepapers, presentations and WEB pages.

2We note that the same risk has also been skimmed over by the term “artifact” in the variousspecialist literatures where it has been used, perhaps for their fundamental role in mouldingthe human existence.

28

2.2. DOCUMENTAL SYSTEMS AND COOPERATIVE WORK

tively of the media or format involved to convey its associated information

(e.g., audio, visual, on paper, in digital form)34 and Heath et al. rightly speak

of documents as “the artifacts, par excellence which has been transformed by

digital technology” [Heath et al., 2000].

Giving such a general definition leads us in making a preliminary but yet

important point. We acknowledge the vastness of the subject and hence waive

any claim of comprehensiveness: as said by Hughes and King, documents have

some generic properties as well as properties related to their use within par-

ticular domains [Hughes and King, 1993]. The former regard aspects that are

independent of any specific and particular context of use, like their generic

functionalities, and their interactional properties. These are properties that

account more about the work that has been done about documents, in their

design and construction, rather than about how they can reflect or record work,

i.e., how they can be of any use in a given work arrangement. Conversely, the

latter properties are socially-defined, even highly-situated and regard “gener-

alized descriptions of social practices and conventions” whose study requires a

detailed examination of the specific domains of use [Hughes and King, 1993].

2.2 Documental systems and cooperative work

Before surveying the main contributions that tried to characterize the main

generic properties that documents can have, almost irrespective of the do-

main in which they are used, we first circumscribe our discussion by explicitly

stating that we focus on documents from the peculiar perspective of CSCW,

i.e., that of documental systems that support cooperative work.

Even limiting our attention to work settings, the above mentioned defini-

tions for the term document imply considering documental work domains as

any work setting where informative artifacts like emails, textbook, manuals,

3cf. document. The American Heritage R© Dictionary of the English Language, Fourth Edition,Houghton Mifflin Company, 2004. http://www.answers.com/topic/document, accessed August30, 2006.

4To briefly indulge in terminological digression: originally (mid-1950s), the term documentreferred to only files created by a word processor application. After the introduction of theMacintosh by Apple in the mid-1980s, every data file was called a document, irrespective ofwhich software application created it, as long it was not an executable file. Microsoft adopted arather similar terminology and set in its worldwide operating system a ‘My Documents’ folder,where all personal data could be stored as a default (cf. Computer Desktop Encyclopedia,Computer Language Company Inc., 2006. http://www.answers.com/topic/document, accessedAugust 30, 2006.).

29


invoices, accounting files, word documents, electronic presentations and even

masks to databases do have something important in common: the ability to

provide someone with information useful for some action or activity and to

enable individuals to communicate and coordinate in any way but vis-a-vis,

across and within communities and organizations.

Our reference documents are those structured inscribed artifacts that sup-

port cooperative work where some not irrelevant degree of formality, official-

ity and reference to standards are predominant. This eliminates things like

sketches, maps, vignettes, ad-hoc memos, completely unstructured notes and

the like, which though we acknowledge can play an important role in mak-

ing actors understand how to articulate their activities (see e.g. [Schmidt and

Wagner, 2002b,Bardram and Bossen, 2005b]).

Structuring and standardization, yet, characterize institutional documen-

tal domains in disparate ways and with different degrees of formality. In some

work domains, for instance, the emphasis on the role of documents is stronger,

because they are used as instruments of control and power, within and betweenorganizations [Yates, 1993]. In the former case, upper management uses doc-

uments to convey and enact procedures and rules by which processes and

individuals at lower levels are monitored and evaluated; in the latter case

documents are employed to transact business (e.g.,trade) or make official

statements that must hold true for each stakeholder, unambiguously and for

definite time spans (e.g., manufacturing standards, formal contracts5). Other

documental systems, the majority indeed, are just considered set of support-

ive tools and information management technologies, embedded in practices

where their role is not as much clear-cut and is constantly remodulated by

practitioners according to the very situation and needs at hand.

Addressing documental systems from the CSCW perspective means to fo-

cus on the coordinative role of documents and to consider which technological

solutions can be conceived in order to enhance that particular role, without

being to the detriment of other roles. In fact, several authors (e.g., [Hughes

and King, 1993,Hertzum, 1999,Braa and Sandahl, 2000]) agree on that doc-

uments do play different roles in different work settings and even for different

practitioners in the same work setting: they can assume the function of be-

5Little wonder that the first written documents in human history are trade accounts fromthe Mesopotamic plain and that the first accounts of modern languages are usually notarialacts. For the Italian language, for example, the first written evidence is one act from calledplaciti cassinesi (ca. 960 a.d.), whose text is the following “Sao ko kelle terre, per kelle fini queki contene, trenta anni le possette parte sancti Benedicti”.

30

2.3. THE MANIFOLDNESS OF DOCUMENTAL SYSTEMS

ing either cognitive, knowledge or coordinative artifacts (see Section 1.5.1).

Moreover, what emerges from our and other similar and recent researches

(e.g. [Berg, 1999, Fitzpatrick, 2004, Winthereik and Vikkelso, 2005]) is that

documents are capable of exhibiting all those different natures in the same

work settings at the very same time. Likewise, Brown and Duguid speak of cen-tral and peripheral properties [Brown and Duguid, 1994], denoting with the

former expression the primary function, the main role a document can play

in a work setting, and with the latter all the secondary, extra roles that it can

anyway play even contextually. The main point is that what is recognized as

a central or peripheral property varies either within different communities of

practice, according to the stakeholder or even to the current purpose she is

accomplishing [Braa and Sandahl, 2000].

2.3 The manifoldness of documental systems

Levy claims that documents have both fixed and fluid properties, independent

of the media they are based on [Levy, 1994]. In fact, documents are the result

of the human need to rely on some stable, external, objective communicative

resource but, at the same time, their content must also be flexible6, i.e., able

to change over time (as trivial case just by mere accumulation of data) and

being updated — or tuned — according to the actual needs of their users7.

For their contrasting aspects, Hertzum speaks of multivoicedness of doc-

uments [Hertzum, 1999], and mentions the suggestive case of the clinical

record that according to Garfinkel contains at least two clear intertwined

voices: a voice reporting which clinician did what to the inpatients; and an-

other voice attesting that clinicians have honored claims for adequate medical

care [Garfinkel, 1967]. These two voices, which we also have clearly “heard”

during our field studies on clinical records, call clinicians for a delicate balance

between under-specification and rigor, between ambiguity and detail. They re-

spectively relate with the two categories of document values that Bikson and

Frinking call evidential and informational [Bikson and Frinking, 1993]. The

evidential value of a document is its value in providing evidence, e.g., about an

organization’s structure, its procedures, the therein undergone transactions

and the like [Hertzum, 1999]. The informational value of a document regards

6Cf. the concept of ecological flexibility given in [Luff et al., 1992].7Even if content did not change, in terms of wording, the very meaning it aims at conveying

could change according to the context.

31


its capability to properly instruct people, to show and tell them how certain

things are, in one word, to inform whom uses them8.

Evidence and information are two main categories of documental value that

also other authors have referred to, e.g., when speaking of the archival and ar-ticulative function of documents [Hertzum, 1993,Cabitza and Simone, 2006].

The former regards support for storage, for preserving the evidential value

of the documental content (and hence for leveraging on the fixed properties

of documents) while the articulative one regards support for action and for

enacting the informational value into a particular work setting.

The contraposition that, regarding documental systems, refers to

whether they are more passive “repositories of information” or rather

“tools at work” [Berg, 1999, Fitzpatrick, 2004] is common to other

ethnomethodologically-informed accounts from the CSCW literature [Luff

et al., 2000]. For instance, to limit on those contributions that focus on our

same reference domain — clinical work — researchers have reported how the

very same document can superimpose central and peripheral properties for

the different groups of people that work with and on it. On the one hand, in

fact, clinical records are a tool that is supportive of the everyday work of the

hospital practitioners and hence they can be at the same time very faithful and

meaningful for competent readers but also lacunose and inaccurate for peo-

ple interested in their evidential value [Berg and Goorman, 1999, Hardstone

et al., 2004, Winthereik and Vikkelso, 2005]. On the other hand, records are

also tools to depict the transaction undergone between the hospital and the

patient in accordance with agreed medico-legal practices and hence its read-

ers must be aware of what is conventionally claimed and what is omitted for

the sake of accountability.

Several evidences (e.g., [Heeks et al., 1999, Berg and Goorman, 1999,

Hartswood et al., 2003]) have been collected that reckless drives to make

the digitized version of the clinical record a better legal document and admin-

istrative tool, i.e., a better evidential tool, tend to jeopardize the articulation-

oriented role of the record for intra and inter ward communication, for hor-

izontal and vertical cooperation and for the achievement of an accountable

quality of care. This means that any process of digitization of documental sys-

tems that exhibit the same manifoldness of clinical records must be informed

by some general requirements so as to limit the risk of deploying and imposing

8The reader should note that the word document derives from latin docere causative ofdecere, that stands for ‘to properly teach, to instruct’.

32

2.4. THE COMPUTATIONAL SUPPORT TO DOCUMENTAL DOMAINS

unbalanced or partial solutions on the cooperative work setting.

Grounding on literature survey reported above and finding confirmation

in the analysis we conducted for our field studies, we propose a minimal set

of requirements that we will refer to when in the next section we will treat

in some more detail the issue of designing computationally-augmented docu-

mental systems at support of cooperative work in documental settings.

Among the main requirements, we focus our attention on the following

three:

1. the preservation of the documents’ ecological flexibility [Luff et al., 1992]

— i.e., the possibility for people to enrich and adapt documents on-the-

go to a range of situations and contingencies — so as not to determine

action causally, but rather to influence further interaction [Schmidt,

2000] by conveying suitable meanings to recorded items;

2. the preservation of the documents’ evidential value [Bikson and Frink-

ing, 1993], which, along with their informational value, can support

actors in articulating activities and not just record them for archival pur-

poses [Berg, 1999,Fitzpatrick, 2004].

3. The enhancement of the documents’ capability to support actors in ac-

cessing and reconstructing the context of production of a recorded item

as well as to facilitate the conventional expression of contextual infor-

mation for its later use; or, as it also has been formulated in [Bannon

and Bødker, 1997], the ability of computer-based documental systems

to positively mediate the process of packaging and unpacking context

and informational items together when both are put in common.

2.4 The computational support to documental do-

mains

This last consideration leads us to consider which kind of support could com-

putational systems provide to documental domains in the light of the contrast-

ing requirements exhibited by cooperative work settings.

From their very foundation in the 18th century [Beniger, 1986], modern

states and bureaucracies have made a massive use of more or less structured

documents as the basic information technology that enable them to control the

33


ever increasing — both in quantity and complexity — flow of information they

cope with to survive and thrive in their specific environment.

Consequently, the advent of data digitization and automatic data process-

ing has had an heavy impact on the ways documents are used (yet even con-ceived), stored and exchanged within and among human organizations and

communities: think of the role of, respectively, office automation, database

management and networking technologies (e.g., those devoted to the Elec-

tronic Data Interchange — EDI [Charalambos et al., 1995]) in changing how

people work and organizations “manufacture” and add value to their products,

whether goods or services.

This impact has not always been positive, or has always found the easy

acceptance of the final users involved. In the cooperative work domain, if a

comparison between effectiveness and suitability of traditional and computer-

mediated practices must be drawn, the goodness of results from the past thirty

years of work on providing effective computer support for document manage-

ment appears quite debatable, and in some cases reported in the specialist

literature even quite meagre [Hertzum, 1999,Berg, 2003].

An important point in the light of document digitization is that documents

employed in cooperative domains are intrinsically cooperative: they are sel-

dom written by a single person solely for her own use9 and this raises two

main caveats against simplistic rush for exploiting the recent office automa-

tion successful (or better yet remunerative) achievements.

On the one hand, technologies employed to make electronic documents

more flexible and practical tools in the context of personal computing seem

to lack proper ways to overcome the most important requirement in facilitat-

ing information exchange and retrieval in cooperative settings, i.e., to make

explicit context of production and correlated vocabularies [Clement and Wag-

ner, 1995,Hertzum, 1999,Mark et al., 2002b]. On the other hand, information

technologies are usually intended to improve and support documental prac-

tice according to some quality reference model [Keen, 1980]. Such models

of proper production and use of documental content, with all their intrinsic

rigidities and constraints, could be quite easily displaced within “private” doc-

uments in favor of some personal idiosyncrasies with almost no harm10 but the

9This could rather hold true for some sort of private memorandum, a case that can be harkedback to the concept of cognitive artifact that we can purposely leave out in the following.

10Just to give an example close to everyone’s experience, how many people do actually com-pile the header data of an electronic document they are authoring — such as title, author,

34


opposite usually does not hold for documents that are shared by members of a

cooperative setting. Indeed, in a domain where documents mediate collabora-

tion and communication, and must guarantee at the same time formality and

comprehensibility, trustfulness and accuracy — all quality dimensions that can

regard even conflicting strategies of use — their digitization does require par-

ticular care not to result in obtrusive practices and unfeasible requirements.

To evaluate the extent failures can be circumscribed or avoided in any pro-

cess redesign activity driven by information technology, the first step is to un-

derstand what can be effectively supported by computational means and what,instead, risk to be out-of-reach of even the most sophisticated (and expensive)

solutions. As said above, we are not interested in document management, i.e.,

in problems, solutions and methods addressing information retrieval and data

storing. We rather focus on how to conceive a design-oriented framework for

the deployment of systems that can help people in making sense of documents

within a certain cooperative effort, rather than in managing them.

This is a challenging and quite unexplored task since, as Hertzum pointed

out, “it seems that many efforts to emphasize documentation and document

management have seriously overestimated the ability of documents to con-

vey meaning” [Hertzum, 1999], while the amount of work required to make

the producer and the consumer of a document understand each other on its

informative content is generally underestimated.

Such approach allows us to consider documents as much more than mere

sets of data: data contained in a given document must actually convey a spe-

cific meaning, at least within the local document’s scope, and are bound to-

gether by at least one simple relationship, which binds them with the purposefor which the document holding them has been conceived or used. For this

reason, documents also necessarily relate with the not-ever-trivial ways and

practices by which people make sense of a text, trying to contextualize its con-

tent both in the original context of its production and in the peculiar context

of their own tasks (i.e., the context of use).

2.4.1 Supporting documental practice

Computation is intended to augment documents in several ways and enhance

the manifold functions they have had before the advent of digitization: a nec-

essarily partial account of documentary functionalities would include to sup-

keywords — even if these data are undoubtedly useful for later retrieval and cataloguing?

35


port people in recalling memories, getting informed, getting proof or evidence,

being instructed and learning and, last but not least, in communicating asyn-

chronously with their fellows, i.e., the conditio sine qua non of any collabora-

tive effort distributed in space and time.

To purposely limit ourselves to the very actions in which actors and doc-

uments interact, we can consider that actors cope with documents in creatingand using them to get informed. Along these two dimensions the proposal

we will outline in the rest of the dissertation has specifically focussed on two

very simple but effective kinds of enhancement that the electronic format has

brought to the documentary support11:

Support to making sensible documents (i.e., to writing)

Examples of the “support to composition” is generally provided by office appli-

cations, like spreadsheets and word processors, which in the last thirty years

have achieved a notable level of maturity. Spreadsheets augment the human

ability to arrange data in tabular ways and carry out even complex compu-

tations on them, while word processors can support writers in both properly

presenting and amending what they compose (even on the fly, as WYSIWYG12

editors and automatic spellcheckers can do). Support to composition does not

regard automatically imputed or corrected value without human supervision

and within an official authoring activity since this has revealed itself a very dif-

ficult task to automize for the current (and probably insurmountable) limits of

computer-based systems in text understanding and interpretation (cf. [Drey-

fus, 1978,Winograd and Flores, 1986]). That notwithstanding, faint successes

are reported in the field of knowledge management regarding automatic text

summarization (e.g., [Mani and Maybury, 1999]). Simpler but much more ef-

fective supports for writers regard, for instance, form-filling in: syntax check-

ers and type constraints can make writers understand which data on the form

are mandatory to be filled in and which is their proper format; again, in the

context of form compilation certain iconographic representations can be em-

ployed to make users understand how suitable or correct is a certain datum for

11Considering also “sharing documents” as elemental activity on documents can be usefulwherever the latter is an action that is explicitly accomplished by the actor. In our contextand for the following analysis we will accomplish on the documental domain, though, we candisregard such activity and hark it back to the activities of reading and writing according to thesetting at hand.

12This is the acronym for ‘What You See Is What You Get’ editors, that is systems in whichcontent during editing appears very similar to the final product.

36


the purposes intended (even indirectly) by the document (e.g., the soundness

of a password, the correctness of an address). This kind of basic support will

be also considered in our proposal, where active code exploiting knowledge

about the external state of the world will make forms become more “situa-

tionally aware” and “prompters” more sensitive to changes in their use and in

their compilers (cf. [LaMarca et al., 1999]).

Support to making sense of documents (i.e., to reading)

While the support to composition regards “who writes” a document, the sup-

port to information gathering and retrieval— i.e., in inquiring and being prop-

erly informed — is primarily intended for the reader. Who reads can in fact

be seen as the consumer of any documental system, i.e., as the person who

needs to have access to some information stored in documents in order to be

supported in some current tasks of hers. Hyperlinking and digital annotationare the most widely used — and simple, we would dare to say — technologies,

which has been applied to documents to facilitate readers in getting more in-

formation about a word, a concept, a topic, which the document in hand is on.

The former means, i.e., embedding cross-referencing a “hypertext document”

to other documents or other resources (e.g., pictures, videos, audio tracks), is

a way to suggest the reader a possible path linking data across different doc-

uments and to allow him to selectively go into information thoroughly. The

latter, i.e., annotation, is a way to add information to information or, in other

words, to provide data with metadata that can describe or better characterize

them. Although the term annotation is still a common and widely accepted

way to indicate the act of providing critical commentary or explanatory notes

to a certain passage or item within a document, such a term is also gaining a

slightly different acceptation within the specialist literature on web languages

and unstructured database management: in the former field, annotating is

conceived as a new form of communication in terms of added comments and

“marks up” overlayed on data that can be inserted by users/readers to ex-

change information with other peers (e.g., topic-posts, wikis, comments within

pdf, MS doc, web pages. . . ), while in the latter field annotation regards the at-

tachment or superimposition of particular metadata on pieces of view data to

track their provenance and hence to assess its quality and reliability (e.g., Biol-

37


ogy DBMSs) [Buneman and Steedman, 2002]13. Also annotation is considered

in our application proposal, where users have been asked to characterize what

they write in terms of either predefined or user-defined relationship to which

conventions and corresponding computational mechanism can apply. This is

obviously seen as a support for whom will access data later on, in her task

of reconstructing the intended meaning and hence the context the compiler

referred to in her notes.

Summing things up

As a matter of fact, it is a difficult, and probably fruitless task to define a clear-

cut distinction among the above just mentioned functionalities, even along the

two dimensions of composing and getting information, which for our practical

purposes can be considered exhaustive. Reading and writing and, in the com-

municative case, understanding each other, are very often tightly intertwined

activities, which it is not only vain but also misleading to consider orthogonal

or independent. The example of form filling is significant, since who is sup-

posed to fill in a form is also engaged in a writing activity where information

retrieving about which data are requested, about how properly fill in them

into the document and about what the composers of the form really intended

and needed to know from those data, is obviously a conditio sine qua non to

properly accomplish the main composing task.

As a final remark, it is also important to be aware of the contextual nature

of documental activities. In a cooperative work setting, either accessing to or

filling in documents are not ends in themselves, but rather meaningful and

intentional activities that are embedded in some other higher-level task and

work context. This consideration has also reflected in the way we addressed

the analysis of how documental systems interact and get molded within and

across multiple lines of work. In the model we will describe in the next chap-

ter, in fact, we propose to explicitly distinguish between documental activitiesand work activities. The former ones are activities that directly pertain and in-

volve documents, namely accessing them and writing on them. The latter ones

pertain to the tasks of cooperative or articulation work, which can include doc-

umental activities and actually give them their specific purpose.

13As regards annotation standards and applications are still at the early stage, but someinteresting proposals are under development and (e.g., Annotea [Kahan et al., 2001])

38

2.5. THE “VIRTUOUS CIRCLE”: OUTLINE OF THE THESIS

2.5 The “virtuous circle”: outline of the thesis

It is now time to introduce a brief outline of the following chapters of this

thesis. In the rest of our work, we will then describe our original contribution

to the design and implementation of technologies supportive of cooperative

work, where this is mainly mediated (or traditionally supported) by (even

complex and multi-layered) documental systems: the WOAD framework.

The main aim of the WOAD framework is to address and characterize some

relevant concepts that could guide the design of a reference architecture for

computer-based documental systems in which the above mentioned require-

ments — informed of traditional paper-based practices — are to be preserved

and possibly enhanced.

The main components of this reference architecture are (a) the documents

that actors use in the execution of their own work, (b) a common information

space, which is common as regards the documents’ content and the conven-

tional practices of making sense of it; and (c) the computational application

of conventional practices that make the state of documents and information

space change according to the context of work.

The development of the WOAD framework is based on a so called “virtuous

circle” [Schmidt and Simone, 1995]: (1) starting from a real case study, (2)

abstracting it and generalizing our findings into a more general framework for

documental domains, and then (3) applying it back to the case study at hand

in order to see whether the users’ requirements could be fulfilled according to

the analytic dimensions characterized at framework level14

As a first step we have then carried out an observational study of how tra-

ditional, long and well-established paper-based technologies accomplish quite

seamlessly and smoothly the twofold task of supporting actors in both accom-

plishing their individual work and in aligning it with all the other individual

works theirs relies upon. For the session of ethnographic studies we have cho-

sen a paradigmatic context-sensitive and often critical domain: the domain of

hospital care. This is usually a very complex and multilayered arrangement

of actors and resources where documents, as parts of an integrated and com-

posite clinical record, are conceived as institutional triggers of commencement

14Obviously this cycle, for its reflective nature and limited scope, is not intended to providean ever-valid and universal benchmark for the framework. Rather, such short cycle gave usethe possibility to verify with the same actors we observed the validity of the assumptions takenin generalizing the collected evidences and of the functionalities envisioned to fulfill their re-quirements as regards their cooperative needs.

39


of cooperative actions, and as legal repositories of their outcome. The ob-

servational studies have allowed us to detect which informational channels

and artifacts enable hospital ward practitioners to document and reconstruct

every time the complexity of illness cases that unfold over work trajectories

spanning over multiple work shifts, different professions, overlapping respon-

sibilities and distributed locations. We report on such observational studies in

Chapter 6.

The evidences collected in these empirical studies have then driven the

analysis of some relevant aspects of the way cooperative work and communi-

cation is mediated by standardized and structured documents. We have con-

fronted our observations with some recent studies that recognize the twofold

nature of documental system in providing their users both with an archival

and representational function of what happened in a given cooperative set-

ting and with an ordering and co-ordering function in virtue of the stigmergic

nature of records. Signs, marks, inscriptions, notes — left at different times on

different artifacts either unconsciously or purposely with the aim to commu-

nicate and inform next actions — refer to each other in a thick web of cross-

references that at analysis time we have characterized in its most general and

recurring patterns. Literature contributions on the nature of documents and

their role in cooperative work are reported in this chapter and in the previous

one.

Such analysis has informed a conceptualization of context that considers it

in terms of elements that, on the one hand, refer to the information structure

and content of documents and, on the other hand, refer to the events and con-

ditions occurring within the cooperative work settings. The conceptualization

of this twofold context is reported in Section 3.2.

Then, we defined a model of articulation in which the main entities and

relationships involved in document-mediated cooperative work are detected

and characterized in terms of a minimal set of attributes. This model, namely

the WOAD model is reported in Chapter 3, and more precisely in Section 3.3.

The model has then informed the proposal of a conceptual architecture

and of a multi-layered software architecture, in which the model entities are

mapped in proper components and their relationships are defined in terms of

constructs and functionalities of lower level, up to the physical level compo-

nents that implement the conceptual architecture. The architecture is reported

in Sections 3.4 and following ones.

40

2.5. THE “VIRTUOUS CIRCLE”: OUTLINE OF THE THESIS

Then we conceived a language (namely, the L*WOAD) encompassing static

constructs by which to express the model entities, and dynamic mechanisms

to represent the possible interactions occurring between such entities. Both

the WOAD model and notation have been developed in the light of the central

requirement of facilitating the putting in common of any information docu-

mental content refers to and of correlating that information with the context

of its production and use. L*WOAD is outlined in Chapter 5.

Then, our task has been to evaluate the descriptive power of the model and

the expressive power of the correlated language in both capturing the require-

ments raised from the field of work and in translating them in computational

mechanisms that a computer-based system could execute to support the artic-

ulation of cooperative activities. To this aim, we designed a still provisional

L*WOAD interpreter to have it encode into corresponding data structures and

implementation code the model templates we constructed at a more abstract

level of description.

Then, we have had a set of distributed and asynchronous rule-based en-

gines execute the L*WOAD compliant code by exploiting the functionalities

provided by a full-fledged middleware we brought to an advanced stage of

implementation during the research activity we have undertaken in the field

of ubiquitous and context-aware computing at the same time of our studies

within the documental domain [Cabitza and Dal Seno, 2005, Cabitza et al.,

2005c,Cabitza et al., 2005a]. Such middleware software, DJess, has been also

usefully employed by other researchers for their applications in the pervasiveand collaborative ubiquitous computing domains [Boselli et al., 2005, Cabitza

et al., 2006a,Cabitza et al., 2006b]. We report about the DJess communication

middleware for the deployment of context-aware and cooperative applications

in Chapter 4.

In order to assess the response of the involved clinicians in getting ac-

quainted with the awareness-provision functionalities that we implemented

in terms of computational mechanisms, we took the opportunity “to tweak”

a prototype application of electronic clinical record that a third-party IT firm

was commissioned to produce for the Neonatology ward of the hospital where

we took our observational studies. For administrative and interoperability con-

cerns, that prototype was never actually deployed but, quite surprisingly, for

that very reason it became a sort of sandbox where the designers of the IT

firm and the head physicians of the ward experimented with no claim of of-

41


ficiality or exactitude their innovative and peculiar ideas of deeply involved

stakeholders.

On the one hand, the prototype’s designers were highly motivated in re-

alizing by means of standard tools and low-cost software platforms “catchy”

and innovative tools that could allow them become solution providers into the

application domain of public and private healthcare: a market where poten-

tial buyers are countless (especially in the quite underdeveloped domain of

Italian healthcare) but no vendor (neither the main international corporate

companies) can claim to have the “perfect” and catch-all solution (and nei-

ther the “standard one”). On the other hand, the head physicians of the ward

at hand — likely for historical reasons regarding the extent technology has

always yielded many notable successes in the very field of neonatological in-

tensive care — were highly motivated in pursuing better and better tools to

effectively support clinical practice, get higher care-related outcomes and help

them in getting more qualitative records to base their research and audits on.

In this particular and highly motivating situation we proposed our

cooperation-oriented layer on top of the above mentioned prototype as ad-

ditional application at support of their informational requirements as regards

the cooperative dimension of their daily work. We report on the implemented

functionalities in Chapter 7.

Chapter 8 concludes the dissertation with a brief account of the main

achievements of our research, a comparison with other similar approaches in

the literature and an outline of the main directions in which we could develop

the WOAD framework.

42

Chapter 3

The WOAD framework

The core of our proposal results into the WOAD framework (an acronym from

Web Of Documental Artifacts and pronounced / woUd/ as the homonymous

plant – see Fig 3.1).

3.1 Main aims and assumptions

WOAD is a conceptual and design-oriented framework intended both to sup-

port (a) the analysis of the informational requirements that actors involved

in a collaborative documental domain can exhibit; (b) the development of a

document-based platform enabling “coordination-aware” and “context-aware”

applications for the use of digitally-augmented documents which, by putting

in common their content all together with the correlated meanings, could sup-

port their users in coordinating within distributed, asynchronous settings.

As such, the WOAD framework encompasses

• a model for the description of document-based articulation work that is

based on a formalization of the concepts of resource and activity. This

model has been used to be the basis of a design environment targeted to

the specific class of systems that are supportive to cooperative work by

means of awareness provision and support to work convention interior-ization [Nonaka and Takeuchi, 1995] (see below).

• a high-level and a software architecture describing the main components

of a distributed software system in which both contextual information

and conventional interpretations to such context can be shared and pro-

cessed. Such architectures have been inspired by the metaphor of web.

43

CHAPTER 3. THE WOAD FRAMEWORK

Figure 3.1: A woad plant, Isatis tinctoria in the family Brassicaceae

Accordingly, a documental system can be seen as an interconnected set

of resources (i.e., data or artifacts), where interconnections represent

relationships and flows between resources and web nodes represent the

resources themselves.

• a denotational language, denoted as L*WOAD, by which to represent

contextual information and manage specific mechanisms to provide

awareness information depending on such context.

• a set of general and application-independent requirements — like mod-

ularity, extensibility, reactivity, correlatability — which are related to the

properties of L*WOAD for the design of context-aware and awareness

providing computational systems. Such requirements are intended to in-

form the collection and analysis of application-level requirements, like

those we derived from an ethnographically-informed study of paper-

based routines in two non-computerized hospital wards.

As seen in Section 1.1.1, cooperative work is a human social phenomenon

that poses a number of partly unresolved challenges to computer science and

technology: specifically, the WOAD framework focuses on two of them, the dis-tributed and heterogeneous nature of cooperative domains. On the one hand,

collaborating actors and their interventions can be distributed, both in space

— over more settings — and time — e.g., across multiple non-overlapping

shifts — and this can lead to the impossibility to share some common con-

text and have the very context of action lost or inaccessible for any practical

44

3.1. MAIN AIMS AND ASSUMPTIONS

purpose. On the other hand, collaborating actors can be highly heterogeneous

as regards a number of aspects, like education, experience, motivation, re-

sponsibility, function and the like. This heterogeneity can lead to the need to

manage multiple perspectives within a single cooperative arrangement and

to even cope with incommensurate ones [Schmidt, 1994a]. Accordingly, the

main aim of the application of the WOAD framework to the process of design-

ing computer-based supportive tools is twofold.

On the one hand, computational systems that are conceived according to

the proposed framework would address the issue of how to support practi-

tioners and users of a complex documental system in making sense of what is

recorded within the documents. Understandability and exploitability of doc-

umental content obviously depend to a very high extent on the very content

and the very actors that use the documents at hand. That notwithstanding,

also the documental platform can play a relevant role, e.g., in its capability

to support content producers and consumers in, respectively, packaging and

unpacking context into and from data (cf. Section 1.4.1). With regard to this,

the WOAD framework puts some emphasis on correlations and provides some

explicit ways to represent and manage them by means of specific mechanisms.

In Section 3.3.3, we will see that WOAD correlations can be set both between

data either within the same or across different artifacts of the same web of

documents.

Conventions are another key concept within the WOAD framework, since

much of the meaning that producers can “package in’ and consumers “unpack”

from raw content relies on more or less officially established conventions and

agreed interpretations, the same kind of procedural “knowledge” that Wenger

says it defines any community of practice [Wenger, 1998]. Conventions can

then be defined as “rules or arrangements established in a group, common

and accessible to its members, that users need in order to cooperate effec-

tively with the system” [Mark et al., 1997]. Conventions are an important part

of articulation work, e.g., since they “enable people to keep track of, and pre-

dict processes, for example, of stages of document completion” [Mark, 2002].

They are also a valuable means to merge various perspectives and “for new

members to smoothly adapt to work, such as when a group’s membership is

dynamic”.

For all these reasons, the second main aim underlying the WOAD frame-

work proposal is to conceive and design systems that, by providing actors with

45


proper awareness information, could support them in understanding, learning

and progressively adopting the conventions that in a given community have

been established and constantly adjusted by its members in order to cope both

with documents and the working context. This would also help actors in recog-

nizing documents as coordinative artifacts that are able to link work practices

together [Braa and Sandahl, 2000], in virtue of the conventions by which doc-

uments within a physical environment and their data within the documents

themselves can “stigmergically” give useful cues about what to do next, how

and why. Under this point of view, awareness could right become “an active

learning device” [Mark, 2002] by which organizational conventions are pro-

gressively learned and aptly made ready-at-hand to counterbalance the risk of

breakdowns due to incommensurate perspectives.

The WOAD framework has also been conceived to shed some light on some

particular aspects of computer-based technologies supportive of human ar-

ticulation work. The latter is a very complex phenomenon encompassing a

myriad of different settings and situations, for which a number of approaches

have been proposed in the specialist literature. For this reason, the framework

only concentrates on some relevant aspects of the manifold coordinative role

documents play in real work settings, while it neglects many others either

unwittingly or purposely, for the sake of the uniformity and compactness of

the framework. In order to clearly circumscribe the main tenets underlying

and influencing the WOAD framework, we explicitly claim some of the main

assumptions and aims that have been born in mind during its definition.

Fist of all, the WOAD framework focusses on “traditional” artifacts and

how they support cooperative work. Let us briefly consider these two aspects

in the following.

• “Traditional documental artifacts” is a generic expression that can de-

note paper-based forms, working sheets, records, manuals, notes; but

also emails, doc files and web pages: in short, anything that documentsboth how work should be carried out and how it is really done. The

main point here is to positively inform the design of computationally-

augmented counterparts of traditional artifacts so that these new tools

would not disrupt habitual documental and coordinative practices too

much. In fact, provided that any artifact digitization — and consequent

redesign of the correlated use processes — can not do without perturb-

ing a balanced situation, we espouse one of the main points of the CSCW

46

3.1. MAIN AIMS AND ASSUMPTIONS

debate: such interventions must limit the extent habitual conventions of

use are changed or distorted in order to prevent the risk actors bypass or

misuse the digital system to get their work done [Grudin, 1988, Bowers

et al., 1995,Pollock, 2005].

• Focussing on the ways documental artifacts support coordination means

to focus on the evidential value of documents and on their capability to

be used by distributed and heterogeneous actors in aligning their work

activities [Strauss, 1988]. Obviously, also the informational value that

documents contain does play an important role in informing and influ-

encing the actions that actors perform and therefore it can not fully

disregarded when analyzing how effectively and efficiently actors suc-

ceed in combining information into some form or reusable and sharable

knowledge [Nonaka and Takeuchi, 1995]. That notwithstanding, the in-

formational value is also deeply affected by a number of factors that

just set coordination aside, like the very nature of the documented con-

tent, the content management and information retrieval capabilities of

the artifacts and, last but not least, the familiarity of the community of

their users. For all these reasons, the informational dimension of doc-

uments is just a background element of the WOAD framework which,

from the computational point of view, is addressed by researches from

other fields, like the Knowledge Management, Document Management

and Information Retrieval ones (just to mention a few). Conversely, the

first class concept within the WOAD framework is the coordinative capa-bility of documents and its main focus is on how to preserve and even

enhance it whenever documents are to be digitized or are already in

digital form.

As a second point to make about the WOAD main assumptions, we con-

sider a clear-cut distinction between interaction and articulation, in despite of

the fact that we acknowledge the way actors interact with their artifacts is

just one side of the coin of assessing how documents are used in real cooper-

ative work settings. Here we recall the point made in Section 1.2.1, in which

we claimed that the WOAD framework focusses on what kind of awareness

information to provide actors with, and when to, rather than on the multiple

ways such information can be provided through the very artifacts at hand.

Accordingly, within the framework, the capability of artifacts to conveniently

display awareness information according to their representational mediums is

47


assumed without further characterization, provided that such information has

been conveyed to the presentation layer of artifacts according to its type, the

information it refers to, and to the current context of use.

Context is the last key concept we discuss in these preliminary remarks

on the framework main tenets and assumptions. As hinted before, the WOAD

framework is about the context-aware provision of awareness information oncontext. This is far from being just a mere pun, once the context-awarenessconcept is rightly related to some “reactive capability” of the supporting dig-

ital applications to be sensitive to the situation in which they are used so as

to be capable to aptly and timely convey to their human users, the actors,

some awareness information on that context1. This is perfectly consequent to

the main WOAD aspects mentioned above: the emphasis on correlations to

reconstruct the context of work and the emphasis on the role of awareness in

the processes of convention sharing and agreeing on.

The WOAD framework calls for a sort of “enlarged” acceptation of the term

‘context’, i.e., an acceptation that gathers both what the documental content

is about and the overall situation in which that content is produced or con-

sumed. That twofold conceptualization has suggested us to refer to context

with a specific term, context2. In fact, depending on the setting’s peculiari-

ties, concerns about the definition, characterization and then management of

contextual items, must be separated. We also stress the importance of context

awareness as a means to augment the supportive abilities of regular docu-

ments in their digitized counterparts. In the following section, we then get into

some more details about what we conceive as context, context2, and context2-

awareness.

3.2 Two contexts for one sense

The common acceptation of context is suggestively twofold, and there can be

some benefit in making both these nuances more explicit, especially in a docu-

1We are then aware that the expression “context awareness” could lay itself open tosome misinterpretation. Such expression has become a standard way to refer to the context-sensitivity and context-adaptivity exhibited by a recent and still under development class ofcomputational systems, those filed under the category of Ubiquitous Computing and PervasiveComputing and other similar labels. Obviously, also human actors can be “aware of the con-text” surrounding them and contribute in richly and variously characterizing it. Our point is onfocussing on how context-aware applications can support actors in being even more and betteraware of (some elements of) their context.

48

3.2. TWO CONTEXTS FOR ONE SENSE

mental domain where text is the main resource to get or produce information.

On the one hand — as an easy etymology seems to suggest — context is the

part of a text that surrounds a particular word or passage and hence either

completely or partly determines its meaning. Obviously, documents abound

with context since any text comes with its context, literally. Within tightly con-

nected documental systems — what from Section 1.1.1 we have called “web of

documental artifacts” — the requirement of word-proximity can (or ought to)

be relaxed: a piece of information can assume its real meaning (i.e., convey

what its producer really meant it to) according to different narrative threads

or reading levels. The latter can span through sections, forms and documents,

just like a small shard can be recognized as part of a bigger shape only within

the “big picture” of the whole mosaic. We denote this kind of context as tex-tual, or in-document context, since it primarily pertains to documents and their

content.

Also another acceptation of context must be considered. This kind of con-

text pertains to the external environment where actors live, work and make

sense and use of things, among which of the documents of the documental sys-

tem they work with: to paraphrase Moran and Dourish [Moran and Dourish,

2001], we can refer to this context as “all the relevant information regarding

the physical and social situation” in which documents fulfill the needs they

have been conceived and are used for. Since this kind of context encompasses

all the relevant circumstances in which an event occurs or a certain activity

is accomplished, it can be denoted as activity context, or by a more general

and higher level term, work context. These two contexts are not disjointed:

they are gathered by the practices of reading and writing, by the acts of “pack-

aging” information with its sense-making context into written form and then

“unpacking” [Bannon and Bødker, 1997] it when that recorded piece of infor-

mation is accessed again time later.

Within the WOAD framework, hence, we denote as context2 (square-

context) (see Fig. 3.2) a set of conditions that pertain both to (a) a set of

documents and (b) the work environment where they are used. The former

dimension is that pertaining to the structure and content of documents. In the

case of “records”, this regards what happened in the work environment in the

past, was deemed relevant, interpreted and recorded in written form, as well

as the way it was recorded and, possibly, the purpose, the meaning intended

for the reader. Conversely, the latter dimension regards the current situation in

49


Figure 3.2: Two kinds of contexts that pertain to documents in cooperative settingsand correlations among contextual items.

which documents are produced, put at work and the time they are consumed

to have them “speak” and report about the past. Such set of contextual con-

ditions is compounded by conditions that have all in common the property to

enable, inhibit, influence either (a) how actors make sense of documents and

correlated actions or (b) how actors manage their work trajectories through

the use of such documents.

Although the textual context can be said inside documents and the workcontext is outside documents, these two kinds of contexts are not in any case

and always independent of each other: what a text really means within a certain

activity can be affected by conditions occurring in the external environment,

both when such text has been produced and whenever it is accessed (i.e., “con-

sumed”) to get information “here-and-now”. For instance, work accounts that

we know have been made in condition of time-criticality or emergency can in-

form us even if they look sparse and incomplete, since we know that only the

very essential data have been recorded and the rest would not deviate from

what can be given for granted and hence interpolated at reading time. Con-

versely, a procedure manual on earthquake safety conduct differently informs

its users depending on whether they are conducting a drill or managing a real

case.

The opposite can hold as well, since what documents tell to people work-

ing in the field can provide important keys or clues to making sense of what is

going on in that field. Accordingly, work context can include activities tightly

related to documents, such as those of reading, writing and sharing them.

50

3.2. TWO CONTEXTS FOR ONE SENSE

These activities, in their turn, are included in some wider trajectory encom-

passing other activities in which document-related ones have their motivations

and purposes.

The WOAD framework proposes to make explicit contextual correlations,

so that items compounding the texture of a particular category of context can

be related and connected to even multiple items of the other. In so doing,

two mutual affecting sets of contextual information can constitute a basis to

provide the functionalities considered within the framework. By means of par-

ticular WOAD relationships, which we will further characterize later, an aug-mented documental context can be produced, as resulting from all the sense-

making relationships that characterize both the documents’ content and the

activities in which such content is either produced or consumed.

For the sake of clarity, we have also to make a point about the fact that

what we denoted as work context is also the closer to what the so-called

context-aware software applications are sensitive to. In the futuristic — but

yet quite probable — scenarios of the ubiquitous computing, usually symbolic

— but in any case computable — representations of context are derived and

extracted from the environment in which some “agents” act (irrespective of

their being human, proxy of human or just non-human agents). These rep-

resentations can pertain to various levels of abstraction: some can refer to a

more physical dimension, e.g., “it’s eight o’clock!” or “John and Ellen are in the

room”; while others to a more logical or social dimension, e.g., “it’s breakfast-

time!” or “John and Ellen are husband and wife”.

According to the tenets of the context-aware computing, all these hetero-

geneous representations of context are processed so as to make computational

systems more proactive and apter in fulfilling the ever-changing needs of their

users [Weiser, 1991]. As a consequence of such a wide-ranging goal, the term

context has been used in many ways in different areas of computer science

and technology. Accordingly, in the context-aware computing field, various def-

initions of context have been given, with the aim to operatively circumscribe

what software applications must be “aware of” so as also to make their users

“aware of” it. In this multitude of definitions, a general aspect can emerge as

a common trait of several contributions from the specialist literature: the con-

text is seen as a relevant set of characteristics from the environment that can

determine the behavior of an application and have an active role in influenc-

51


ing its branches and outputs2 [Chen and Kotz, 2000]. That notwithstanding,

we can also add that contextual information can be relevant to an application,

but it is not necessarily always a critical information (this kind of information

would more likely pertain to the inputs of the application at hand). Accord-

ingly, contextual information is “information about the surrounding”, and does

not always regard a “necessity of adaptation”, but rather “an opportunity of

interest”. In other words, context can be used either within imperative scripts

that must be executed whenever something occurs; or also within maps of

events that can possibly affect the behavior of some agent, according to the

contingent nature of these occurrences [Schmidt, 1997].

The either prescriptive and descriptive nature of context well correlates

with what we said about awareness as a phenomenon occurring in coopera-

tive work settings. We conceive of applications as context-aware if their be-

havior is affected by context, even if the strong requirement of deterministic

and reactive adaptivity is relaxed in favor of more user-centered informational

needs. Accordingly, applications can also be said context2-aware if they are

supportive in providing users with cues on what is going on around them, as

well on all those documental pieces of information that could facilitate them

in becoming aware of the real meaning that is relevant at a certain level of

reading.

All that said, it is easy to see that correlations and relationships play an

important role in characterizing context. In fact, what both the considered ac-

ceptations of context do have in common is the concept of interconnection,

reciprocal influence, mutual linkage3 (see also our [Cabitza et al., 2005a]):

documents with documents, information with information, and, as it is ut-

terly important in any cooperative effort, actor with actor, the users of such

an interconnected system of artifacts and cross-references. Context can hence

be seen from the operational perspective of the so called collaborative aware-

ness [Lauwers and Lantz, 1990] in that its interconnections can be taken from

the countless things that are ready-at-hand (and actors are not aware of) to

become something that must become present-at-hand and require the users’

attention [Winograd and Flores, 1986], according to some unpredictable in-

2Consequent to that definition, some time that acceptation is denoted with the expressionof “active context”.

3In fact, the very term context derives from the Latin contextus “a joining together,” fromthe verb contexere “to weave together,” from com- “together” and textere “to weave”. Texture— a synonym for network — and context share then the same etymology (moreover, textura isLatin for web).

52

3.3. CONCEPTUAL VIEW OF THE FRAMEWORK

formational need. Accordingly, users of a documental system can be supported

in getting aware of their work as it can be perceived once mediated by doc-

uments and interpolated by the practices of reading and writing documents

(see Section 2.4).

In the following, we shall characterize the way in which within the WOAD

framework context is symbolically represented and made object of compu-

tation so as to become a transformable set of elements. We will also show

how these transformations, which are carried out at symbolic level by com-

putational machines independently of actors’ direct control, are then used to

make actors more aware of the physical context surrounding them, through

the very same affordances of the documents where the context is recorded

during multiple work trajectories. We will characterize which kinds of aware-

ness information actors can be provided with by a computationally augmented

documental system; and how such information can be modulated on the basis

of the global state of a web of documental artifacts.

3.3 Conceptual view of the framework

Models and theories concerning the nature of cooperative work have long

been recognized as an important aid in the development of Computer Sup-

ported Cooperative Work (CSCW) systems [Chen and Rada, 1996, de Farias

et al., 2000], notwithstanding a prudent acknowledgement about the limi-

tations of certain kinds of models [Bannon, 1993] and their applications. Al-

though the tension between models as formal representations of work settings

and modeled situated actions [Suchman, 1987] must be always taken into ac-

count [Robinson and Bannon, 1991], models and theories can be seen as op-

erative tools intended to help designers and developers of cooperative systems

in focussing on the most relevant issues at an as early a stage as possible and

in structuring the system in a coherent way. The result of modelling consti-

tutes conceptual frameworks in which allegedly relevant domain knowledge

is explicitly represented and some of the most important aspects that concern

both cooperative settings and supportive computer systems are consistently

captured.

We can see modelling activity be mainly based on either a top-down ap-

proach or a bottom-up one, although in many cases this generalization results

in a too course picture of how models are conceived within the CSCW commu-

53


nity (cf., e.g., [Prinz, 1994, Schmidt, 1997, Frank M. Shipman and Marshall,

1999, Simone and Sarini, 2001]). In the top-down approach, the main enti-

ties characterizing cooperative work settings are conceived having in mind no

particular domain. Concepts are rather derived by considering the work di-

mension from an as general perspective as possible and then specializing it

into domain-specific cases. In so doing, the general concept of actor can be

specialized into a less generic class of patient, to mention an example from

the healthcare domain.

Conversely, in the bottom-up approach, usually some ethnographical and

observational studies of some particular work settings are taken as source of

information to understand which aspects are to be therein highlighted and

considered for further generalization. The generalized concepts are then con-

veniently applied to different domains than the studied one wherever and to

the extent possible.

As said at the beginning of this section, the WOAD framework is intended

for the documental domain. The proposed characterization of such domain

has been strongly influenced both by a survey of theoretical models done in

the past years within the CSCW community and, especially, by the studies

we carried out in studying a particular documental system, the clinical record

system that have been conceived within a populated region of northern Italy

and applied in two wards of the same provincial teaching hospital. Lacking,

to our knowledge, a purely theoretical model related to document-mediated

cooperative work and awareness provision, we have considered what could be

taken from some of the main models proposed within the CSCW field, such

as the Coordination Mechanisms [Schmidt and Simone, 1996], Cooperation

theory [Malone and Crowston, 1990], Activity Theory [Kuutti, 1991] and Ac-

tion/interaction theory [Fitzpatrick et al., 1995]. Our task has been that of ex-

tracting from such general frameworks a minimal sets of concepts which could

better fit the requirements and peculiarities of the clinical domain we studied

and, for generalization, of cooperative documental systems having similar re-

quirements and constraints.

From the most general point of view, the WOAD framework encompasses

a way to consider cooperative documental domains both from the static point

of view, which concerns with the structural4 dimension of the model, and the

dynamic point of view, which regards how the static structures get transformed

4Some others could also say such dimension “ontological”, since it refers to the “explicitspecification of a conceptualization” [Gruber, 1993].

54


over time by computation. The framework considers the whole information

that is treated within and outside the documents as something that can change

as the result of two different main factors. These are called either exogenousor endogenous factors depending on whether changes are triggered by events

in the physical environment, i.e., outside the computational one, or inside the

latter.

As regards the main exogenous factor, documental content and correlated

context can change according to the document-mediated interactions occur-

ring between actors or when actors directly interacts with artifacts, i.e., when

actors act upon documents by producing or consuming some information. This

cause of transformation is denoted with the term exogenous, since actors are

modeled as first-class entities of the framework, but not further characterized

in terms of attributes or behaviors: actors interact with the system, but from

outside it, as black boxes, and provide the computational system with some

inputs to process.

As regards the endogenous factor, the information related with the

context2 can also change because of the computational application of conven-

tional practices and interpretations that someway relate to that information.

This application changes the internal status of the computational system and

provides its users with some output in terms of data or coordinative informa-

tion. For our practical purposes — and consistently with the notion of context2

as something that may influence the behavior of applications and their users —

we can conceive of conventions and interpretations related to the meaning of

a piece of contextual2 information as behaviors that can be tightly referred to

that information.

From this point on, hence, by the terms convention (and likewise con-ventional interpretation), we mean conditional relational structures that relate

in a cause-effect, or condition-action, relationship an antecedent and a con-

sequent. The former refers to some contextual2 condition — for example, a

certain datum exists, or it has got the value X —; the latter refers to some new

condition that necessarily follows the antecedent ones or some behavior, i.e.,

sets of simple actions. These actions can be either autonomously performed by

the computational system or suggested to the involved actors as alternatives

to perform on a voluntary basis.

For example, when someone refers to a “red code” within the admission

form used within an emergency consultation at a hospital triage, a WOAD

55


convention could be expressed in terms of an association between such piece

of information and the fact that some actions must be accomplished as soon

as possible, like moving the patient into an emergency room and applying her

proper resuscitation interventions. In fact, in such context, “red” means very

severe health conditions of a patient and need for immediate intervention.

Conversely, if the very same code is used in the context of a daily hospital ward

routine, a completely different, yet conventional as well, interpretation could

be associated. In fact, red codes denote that a fire has broken out somewhere

in the ward and that the first things to do are to rescue patients, activate

alarms and contain smoke. Here again, the meaning of the red code can be

operatively reduced to the very actions those color conventions refer to and as

such be conveniently managed by a computational system.

Summing things up, we can see the whole ensemble of actors, artifacts

and information resources that are managed between, within and by artifacts,

as a transition system. The global and observable state of such system can

be conceived as the union set of all the informational resources that refer

respectively to actors, artifacts and their context2, as all their instances are

rendered in symbolical structures and “documented” within the computational

system. Such state can change according to external stimuli (from the field of

work) and to the data-driven application of computable representations of

conventional interpretations to contextual2 data.

In the following, we will characterize the main concepts and entities that

are represented within the global state envisioned by the WOAD framework.

In our discussion, we will bear in mind a clear distinction between three main

levels of description:

the framework level , in which the most general and domain-independent

concepts are proposed, within the broad domain of documental systems

intended for cooperative settings.

the domain level , in which the framework level concepts are declined, char-

acterized and represented according to the particular domain of interest,

e.g., hospital care, legal offices, or organizational bureaucracy.

the application level , in which architectural solutions, implementation en-

vironments and specific applications are proposed, which could best fit

particular work settings, e.g., the ward X in the hospital Y. Within such

level, the usual distinction between schema and instance level are con-

56


veniently applied to indicate classes and objects from those classes, re-

spectively.

3.3.1 The WOAD entities

As regards the static, or structural, point of view, the framework considers

two main entities, which for their generality are also treated in almost each

theoretical model considered, although with some differences: the concepts of

resource and activity (see Fig. 3.3).

Figure 3.3: The two main concepts within the WOAD framework

Both the concepts can be defined by means of each other. As regards the

concept of resource, with such term we denote just everything that can be used

or employed within an activity. Conversely, the conceptualization of an activity

as an ‘entity’ reifies and includes the set of events that — at a certain level of

description — can be correlated with the actions in which one or more resourcesacts or are used.

Figure 3.4: Activity levels for the documental domain.

As anticipated in Section 2.4, the WOAD model distinguishes between doc-umental activities and work activities (see also Fig. 3.4): the former ones di-

rectly relate with documents, i.e., regard the very actions of either gaining

access to documents — or parts of them — or writing on them — filling in

their fields. The documental activity granularity, i.e., whether an activity re-

gards a portion of a document, even a single field, or rather a collection of

57


sheets pertaining to the same matter, is left at the domain specifications and

its requirements.

On the other hand, the term work activity denotes a task-related course of

action, i.e., aspects of a work process that are relevant to doing a specific piece

of cooperative work with the available resources and that can be gathered un-

der the same ‘operational intent’ [Andersen et al., 1990]. We then define workactivities as capable of “containing” a number of documental activities accord-

ing to the granularity level activities are modeled within a given domain5. The

distinction that within the WOAD model is made between these two levels of

description is rendered into two different constructs that are defined by the

WOAD language (see Section 5.1.1).

Also the general concept of resource is further specialized into those of

actor, information and artifact (see Fig. 3.5). An actor is just the human agent

that acts within a given activity, i.e., the cooperative worker; information is

just something6 that can inform an actor and influence her activity; artifacts

are just “tools” that are purposely used, produced or modified within an ac-

tivity. Although the term “artifact” has been applied to a number of different

things in different contexts, for our practical purposes, we can adopt the accep-

tation of something that concretely and interactively mediates the production or

exploitation of information by some actor. Moreover, within the WOAD frame-

work we further limit the scope of analysis about artifacts, limiting ourselves

in considering documental artifacts, or just documents.

As regards the general model, the WOAD framework purposely leaves un-

derspecified the involved entities in terms of attributes, i.e., of intrinsic char-

acteristics. For instance, we deem that which specific resources are better to

consider, how to properly characterize them, as well as the very nature of ar-

tifacts and documents would depend too heavily on the peculiarities of the

domain at hand and that a further detailing at framework level would have

hindered the general applicability of the model. A further characterization of

the resources involved must be then applied at domain-level and, obviously,

at the design time of the application. The same holds for activities: further

specialization of activities into sets of smaller actions or their generalization

5In Fig. 3.4 we have not represented a concept of strict inclusion, but rather a “belong-ing” relationship between a documental activity and the containing work activity. See alsoSection 5.1.2.

6Mind, we use the generic term “something” to hint that information is not necessarily a datavalue, in its habitual acceptation, but can also be some perceivable change in the environment,as long as that informs the thinking or action of somebody.

58


Figure 3.5: The main concepts of the WOAD framework.

into more general tasks is left at the domain level characterization.

In order to support the designers of a certain domain in such task of defin-

ing and characterizing the entities that their computational system must cope

with, the framework also encompasses an operational language by which de-

signers are provided with a minimal set of predefined entity attributes (see

Chapter 5). These have been selected for a basic characterization of documen-

tal domains and for the convenient definition of computational mechanisms

for awareness processing and provision. To guarantee modularity and flexibil-

ity, the WOAD language also provides designers with proper primitives and

mechanisms by which to define their own attributes according to the specific

requirements of the domain at hand.

3.3.2 The WOAD relationships

The pretty symmetric definition given to informally define the concepts of re-

source and activity hints a mutual logical dependency between such general

categories. This is reflected by the main relationship that is considered within

the WOAD model. The bidirectional relationship between the concepts of re-

source and activity is denoted as Involvement: each resource can be involved

in no, one or many activities at the same time. Likewise, each activity can

involve no, one or many resources.

The involvement relationship can be further specialized according to the

nature of the resources and activities involved (e.g., whether the former are

data or actors, or the latter are documental or work activities). We distinguish

between (see Fig. 3.6):

59


• “involvement as pre-condition”

• “involvement as input”

• “involvement as output”

• “involvement as effect”

A precondition involvement occurs whenever an activity needs as necessary

(but yet not sufficient condition) for its execution that a specific resource exists

and has a certain property true. An input involvement regards the necessity for

an activity that a certain informational resource (i.e., a datum) exists7. That re-

source is then “fed into” the activity as an input with some property — e.g.,, a

particular value, or structure — to be processed and used for its accomplish-

ment. An output involvement occurs when an activity provides others with,

or produces, some informational resource8 or causes a preexisting resource to

have some particular property (e.g., to be “lower than 5”) as a consequence

of its accomplishment and processing. An effect9 involvement occurs whenever

an activity causes a resource, other than informational, to exist and have some

property as a consequence of its accomplishment, besides the informational re-

sources it worked on. For this reason effects are also called side-effect, in that

they are concerned with the consequences the activity has had on the rest of

the context in which it was carried out (e.g., the surrounding environment).

This very general conceptualization about the dyad resource-activity

adopts the so called IOPE model. This approach dating from the first works

in computing semantics (e.g., [Hoare, 1969]) deliberately focusses on in-

puts, outputs, pre-conditions and effects and it has been recently adopted in

the definition of modelling languages and related standards for the Seman-

tic Web [Cabral et al., 2004] (e.g., OWL-S [Martin et al., 2005] and WSDL-

S [Akkiraju et al., 2005]), after its first proposals in the Computing Seman-

tics [Hoare, 1969] and the Artificial Intelligence Planning fields [Eiter et al.,

2004]. The IOPE model allows us to express interdependencies between activi-

ties as particular cases of resource-based relationships (see Section 3.3.4).

7For the generality of its definition, preconditions can be also applied to inputs, e.g., that aninformational resource, x, exists and “is not null” or “is bigger than 5”.

8Here again, we limit the concept of input and output to that of informational resource withsome value.

9Others prefer the term post-condition, to draw a symmetry with the pre-conditions (e.g.,cf. [Bock and Gruninger, 2004].)

60


Figure 3.6: The involvement relationship cases.

The involvement relationship encompasses all the relevant cases in which

resources and activities are mutually related, at framework level. This means

that, for our practical purposes, the WOAD framework does not need to spec-

ify whether an actor, as a resource, has an active role within an activity, i.e.,

if she accomplishes it, or if she just plays a passive role, like those played

by an archival document. As we will see in Chapter 7, these and other sim-

ilar relationships are characteristics that pertain to either the domain or the

application level and hence they must be specified according to the peculiar-

ities of the settings at hand. Therefore, besides the involvement relationship

that connects resources and activities, the WOAD framework also considers

the two generic classes of relationships that occur between resources and of

relationships that occur between activities.

relationships between data Obviously these also are to be characterized at

domain or application level, but the WOAD model explicitly encom-

passes a particular kind of inter-data relationships: what we call cor-relation. We will treat them in some details in Section 3.3.3.

relationships between activities Also this kind of relationships can be vari-

ously characterized according to the domain at hand but, at framework

level, we propose a construct expressing a generic relationship of belong-ing. This can be used either to express strict inclusion, i.e., an activity in

which — also, during the which — some other is accomplished, or just

to give the designer the possibility to distinguish into at least two differ-

ent levels of abstraction, i.e., to map actual actions and operations into

more abstract sets of activities that regard the tasks conceived within

a cooperative arrangement. In so doing, the designer can also map the

management of the context pertaining to either textual items and work

61


items into two different kinds of activities (see 5.1.2 for further details).

How we consider the relationships that indicate some kind of depen-

dency between activities, e.g., causal and temporal ones, will be treated

in Section 3.3.4, where we give such particular kind of relationships the

name “interdependencies” and show how these can be harked back to a

particular kind of relationship between resources and activities.

3.3.3 Correlations between data

Correlations are a means to attach more info on data. Within the WOAD

framework, we denote as correlation a set of relationships between data, that

users and designers can use to create annotations or particular references be-

tween data. An annotation is usually a note added to a text but also, more

generally speaking, some extra information associated with a particular point

in a document or other piece of information.

From our studies on real work settings situated in the hospital care do-

main, we have detected how, for actors coping with data from multiple and

heterogeneous sources, the capability to explicitly draw linkages and refer-

ences between them can be important10. In [Cabitza et al., 2005b], we have

denoted the additional effort that is oriented to enriching stand-alone data

with references to other data as a kind of positive redundancy of data, just

to distinguish it from the redundancy of data that is not explicitly requested

by the involved actors to support their either cognitive or coordinative tasks.

Such “negative redundancy” results in superfluous information character-

ized by verbosity or unnecessary repetition and it is often associated with

time-consuming practices that are usually perceived by clinical practitioners

as a waste of time, like filling in administrative data and other secretarial

tasks. Data redundancy, in its neutral acceptation, concerns information re-

sources used to accomplish tasks and characterizes those organizational set-

tings where either the same or similar11 data are repeated in different docu-

10This requirement can be also related to extraordinary spread of the hypertext technologyacross world-wide webs of loosely structured and digital documents, i.e., the WWW itself. Inthe web-based technology, hyperlinks are particular annotations used to connect single words,text passages or pictures with other information resources. These sort of internal connectionsamong documents are intended to give their readers the opportunity to move from one part ofa document to another or from one document to another so as to shape a particular “readingpath” among many others. Likewise, we have assimilated this need for further investigation tothe need of adding meta-information to information.

11With similar we here mean pertaining to the same information. See also next footnote onthis point.

62


ments.

Positive redundancy occurs whenever an information is someway enrichedby referring it to other information (that we say correlated), even if each infor-

mation singularly taken would have been sufficient to inform their intended

consumers. The main point here is that we do not necessarily associate the

term sufficiency with the efficiency-minded nuance that it does hold in the do-

main of information systems, where data redundancy is frequently associated

to waste of resources.

Indeed, we collected some evidences that positive redundancy of data de-

notes a particular need exhibited by actors for coordinative reasons, rather

than for informational reasons, e.g., to gain a comprehensive view of what has

gone on in a work setting to enable satisfactory handing over of tasks. Data re-

dundancy, i.e., the requirement that a phenomenon be described several times

or in several complementary ways within the same set of documents, can be

a condition that, depending on the actors’ needs, must be guaranteed to some

extent or maintained to allow a smooth alignment of actions and interven-

tions.

The WOAD framework encompasses four general kinds of correlations,

that can be seen either redundancy-generating or redundancy-maintaining ac-

cording to the setting’s context. This distinction has been first proposed by

Ellingsen and Monteiro [Ellingsen and Monteiro, 2003] in the information

system domain, by considering the data source or its content, and then we

adapted it to documental and artifact domains in [Cabitza et al., 2005b].

When information is identical in content but located in different sources,

data are correlated by duplication. Duplication may lead to different represen-

tations of the same information, especially if this information is represented

not only in different documents but also in different mediums, e.g., paper and

electronic forms. In this case, as in any other case of duplicated information,

the utility of redundancy is controversial. On the positive side, Hutchins ar-

gues that this kind of redundancy facilitates the robustness of work since if

“one [...] component fails for lack of knowledge, the whole system does not

grind to halt” [Hutchins, 1996]. With similar conclusions, it is stated that the

use of multiple representations of data increases the fault tolerance of the sys-

tem [Gorman et al., 2000]. On the negative side, other authors state that since

the same information is documented in different places, redundancy of infor-

mation is a latent risk: in fact, the information might become unsynchronized

63


Table 3.1: Kinds of correlations to redound information for coordination’s sake.

or inconsistent and lead to misconceptions or other human errors [Sorbya

et al., 2002].

An interesting case of redundant information mentioned by Ellingsen and

Monteiro concerns information that is not exactly the same in content, but is

still strongly related and located in different documental sources. The authors

call this case supplementary information and claim that it can be used for

different purposes, among which supporting “learning by intrusion” [Nonaka

and Takeuchi, 1995] and playing the role of boundary object [Star and Griese-

mer, 1989] across different communities. These considerations, corroborated

by the observations of our hospital ward setting, led us to articulate the notion

of correlation of data as shown in Table 3.1.

When the same data are reported in two (or more) different documents

we speak (following Ellingsen and Monteiro) of duplicated data12. However,

when the same data is reported in several points of the same artifact we pre-

fer speaking about replicated data, since they are like carbon copies made by

folding back a sheet on another13.

We speak of similar data when data refer to (usually two) different enti-

ties or concepts, which can be put in strict correspondence thanks to either

a causal, intentional or functional relationship between them14. In regards to

redundancy due to correlation of different data, then, we distinguish whether

this occurs between different artifacts or within the same one. In the latter

case, we speak of redundancy from derived data, that is of data that can be

drawn by others as, for instance, subtotals that are reported within the same

spreadsheet to make the final totals clearer. In the former case, when positive

12“Duplicare” means “to double” in Latin.13“Re-plicare” means “to fold back” in Latin.14The peculiar way to use the term similarity with such meaning should not wonder, since we

clearly refer to similarity between documental entries, i.e., words. Accordingly we adopt theacceptation of similarity between words as “expressing closely related meanings” (cf. WordNetr2.0, c©2003 Princeton University).

64


redundancy occurs across different documents, we draw on the concept of

supplementary data, in that correlated data are reported in different artifacts

in a slightly different shape to supplement each other according to contexts of

reporting and of consulting.

From Table 3.1, it is clear that correlations between identical and sim-

ilar data are a particular case of the more general case in which two data

are put in some relationship. We have focussed on this kind of relationship

(giving it the framework-specific name of correlation) because our observa-

tion of documental use for coordinative reasons have highlighted the utility

of making explicit these constructs and urged us for a dedicated kind of sup-

port (See section 7.2.1). Also other authors have recognized the validity of

positive redundancy of correlated data over different artifacts (e.g., [Bossen,

2002,Bardram and Bossen, 2004]).

The most interesting case is that of correlations between similar data, since

even small differences can reveal important cues to inform the smooth align-

ment of task and responsibilities. These differences between data and the ar-

tifacts in which they are recorded reflect different purposes and allow for a

different degree of mobility (e.g., in the hospital case, bolted whiteboards vs.

mobile work-schedules) and of concision (detailed work-schedules vs. suc-

cinct whiteboards). These different artifacts can be flexibly used to produce

overviews, to present different data differently, to reveal work status, to plan

cooperation and continuous coordination, and also to pass on messages and

notifications to provide individual work-spaces; and finally, to also facilitate

the location of people in the ward.

3.3.4 Interdependencies among activities

According to a wide scientific convention, we consider activities as units of

work that, at a certain level of abstraction, can be considered as atomic15.

Malone and Crowston [Malone and Crowston, 1994], within the so called

research area of Coordination Theory, proposed to conceive of coordination

as “managing dependencies”. We can say that between two activities there

is a dependency whenever the execution or accomplishment of an activity is

not an independent event of the execution or accomplishment of the other

activity. In the specialist literature, a number of taxonomies and analyses have

15For or practical purposes, the choice to consider activities as atomic, instead of, for instance,tasks (cf. Raposo and Fuks [Raposo and Fuks, 2002]) is purely conventional if not nominalistic.

65


been proposed for the characterization of activity dependencies within a wide

range of collaborative applications, since defining interdependencies among

activities is a way to define the set of conditions that determine the order in

which such activities are carried out, and hence to define their process.

Generally, domain-dependent dependencies between two16) activities, can

be traced back to three general cases: (a) causal, (b) temporal and (c)

resource-based dependencies.

The causal dimension regards representations that focus on the way activ-

ities follow each other and that make explicit their causal relationship (either

dependency or independency). Perhaps for the natural tendency of actors in

describing their activities in terms of reasons and motivations, the causal di-

mension turns to be very useful in representing a work arrangement since it

provides designers with the precise categories of cause, effect and concurrency

by which to conceive the unfolding of a certain work trajectory.

Accordingly, the causal dimension has gathered a lot of interest both within

the field of the theoretical computer science and within the field of business

engineering and organizational studies. The former field has contributed in

proposing a number of in-depth formalizations within the so called concur-

rency theory (e.g., petri nets and process calculi) that could be applied to

model, understand and analyze how processes are defined and applied in work

settings (e.g., [Milner, 1980,Nielsen et al., 1992,Roscoe et al., 1997]).

Some of those formalisms have also been to some extent applied to the

enactment of software application for managing business processes (the so-

called workflow management systems — WFMS), that is to have represen-

tations of the causal interdependencies between activity be object of auto-

matic computation by some machine or engine. In that case, the execution

flow between activities is articulated in terms of connectors and composite

patterns that have recently been explored by business process management

researchers and tested in several workflow applications (e.g., [van der Aalst

et al., 2000a,van der Aalst et al., 2000b,Aalst et al., 2003]).

The temporal dimension regards representations that consider time as the

discriminant element in characterizing the nature of the relationship between

two activities, e.g. whether A1 has necessarily to start before A2, or whether

A1’s duration is necessarily as long as A2’s one. Besides the extension to the

causal formalisms mentioned above (e.g., timed Petri nets [Zuberek, 1991]),

16For the sake of simplicity, we concentrate our attention on binary relationships.

66


one of the most notable contributions to the matter was by Allen [Allen,

1984]. He proposed a set of primitive and mutually exclusive relations that

could be applied over time intervals of unknown duration — i.e. over cou-

ples of events — and that could express temporal information considering

any pair of time intervals A and B. Other authors followed the work by Allen

on basic inter-interval relations and adapted them to the inter-task domain by

adding a couple of specialized relations [Raposo and Fuks, 2002]. In so doing,

a larger set of possibilities to create coordination mechanisms were given to

analysts and designers so that different cases of multi-workflow environments

and inter-task articulation could be handled [Raposo et al., 2000].

Obviously the causal and temporal approaches to the representation of

inter-activity dependencies can be tightly correlated: as trivial examples, the

cause must occur before the effect, and two strictly disjointed activities can

never occur at the same time. Yet, since this is not necessarily the case in every

circumstance, it is not always feasible to trace back one kind of dependency

to the other. Moreover, according to the very nature of the domain at hand, a

dimension can be left underspecified in favor of the others, or the specification

be tuned for a particular domain and result into a less than suitable one for

others. As an example, real-time control domains need fine-grained tempo-

ral specifications of the interdependencies between activities; while domains

where human work is substantially “left outside” and out-of-synch with the

computational system necessarily need coarser-grained causal specifications.

Resource-based dependencies regard whether two activities produce, use

or need some common resource17. The resource-based approach was concep-

tualized in the work by Crowston [Crowston, 1994, Crowston, 2003] within

the so called coordination theory. In such framework, two general cases are

declined in a number of more specific subcases: the case in which multiple

tasks use or produce some shared resources at the same time and the case in

which a task produces resources that are consumed by another [Malone and

Crowston, 1994].

The resource-based proposal is also influenced by the STRIPS (Stanford

Research Institute Problem Solver) model [Fikes and N.J.Nilsson, 1971], a

simple but effective18 model of action developed within the Artificial Intelli-

17We recall that, in the WOAD framework, the term resource refers not only to the actorperforming the task but it also includes anything produced or needed by a task (cf. the conceptof artifact).

18The STRIPS model, since its first proposal by Richard Fikes and Nils Nilsson in 1971, is the

67


gence and Automatic Problem Solving fields under some simplifying assump-

tions, like time atomicity and determinism of effects. In such a general model,

the atomic unit of work — in our case, the activity — can be seen as a sort

of function from a state of the world – before its execution – to another state

of the world – after its completion – and hence be fully characterized by its

preconditions and effects. The preconditions can be seen as either states of

the world or resources that must be true or available for an activity to be

carried out since they are required or consumed within that activity [Malone

and Crowston, 1994]. Likewise, effects (or post-conditions) is what is true or

available in the world after an activity has been carried out since it has been

consumed or created within that particular activity.

This brief survey of inter-activity relationships helped us in understanding

which aspects of the typical documental domain must be elicited within the

model of cooperative work expressed in the WOAD framework. The WOAD

concept of work activity closely relates to the situated work context. This

changes depending on the complexity and characteristics of the application

domain and can require the design phase to employ the most suitable model

and formalization.

In our observational studies, we could extract some recurring character-

istics of work activities that pertain to documental use: since the description

of such activities usually do not need a strictly formal approach for the ex-

pression of the abstract causal relationships within the work processes, nor

for a formal expression of time-related aspects (our aim is not to represent

real-time applications or to evaluate application performances), we found that

the resources-based approach is the more suitable for taking into account the

contextual pieces of information that can be represented into the fact space.

Moreover, since inputs and outputs considered within our framework can be

seen as particular conditions of existence over data for an activity to start and

be completely accomplished, the IOPE approach adopted within the WOAD

framework can be fully represented in terms of resource-based precondition

and effects. In Sections 5.1.1 and 5.1.2, we will see how such relationships are

rendered into corresponding constructs of the WOAD language.

base for most of the languages for expressing automated planning problem instances in usetoday.

68

3.4. ARCHITECTURAL VIEW OF THE FRAMEWORK

Figure 3.7: The WOAD metaphor: web threads between documental artifacts are re-lationships stemming from the fact space and depicting a woad plant whose leafs aredocuments; transitors make the plant change, evolve, flourish.

3.4 Architectural view of the framework

In order to describe how the WOAD conceptual tenets, entities, and relation-

ships can inform the design and implementation of real computational sys-

tems, we now characterize the so called architectural point of view of the

framework. In the following, we will first refer to a high-level architecture,

with the aim to use it as a way to introduce a software architecture (in Sec-

tion 3.5), i.e. a representation of how the framework entities and relationships

can be mapped into interfaces among the system’s software entities, and be-

tween the system and its environment.

Bearing both the high-level and software representations in mind, software

practitioners can comply with the general tenets of the framework and so be

facilitated in designing their system within a set of constraints that could steer

the implementation process in accordance with those tenets. In presenting a

WOAD-complaint architecture, we will provide a schematic representation of

a software system that (a) could reify the main entities discussed above and, at

the same time, (b) implement the idea of having documental and contextual

information as interrelated resources that compound a common information -

transition system. In such a system, the state represents a snapshot of the struc-

tures and values of all the information resources. These resources, although

pertaining to different documental artifacts, are put in common into a sort of

common repository or memory. This set of resources at a given state makes a

69


Figure 3.8: A graphical representation of the main components of the WOAD archi-tecture.

transition to a subsequent state for the intervention of either the exogenous

or endogenous factors we mentioned in section 3.3, that is either by the direct

interactions occurring between actors and artifacts or by the context-driven

computational application of conventional interpretations.

From the architectural point of view, the WOAD framework maps the first-

class concepts concerning the dynamic and static points of view into four spe-

cific components that can be considered a human, documental, informational

and computational resource, respectively (see Fig. 3.8). They are, namely:

• the actors

• the documental artifacts

• the fact space

• the transitors

3.4.1 Actors and documental artifacts

An actor is an instance of the intended users of the documental and computa-

tional systems. Documental artifacts represent the documental resources that

support actors in their work, both for their informational needs and for their

efforts to coordinate with each other.

Actors and documental artifacts share the same real, physical environment

of the work arrangement and setting where activities go on. That notwith-

standing, documental artifacts do not need to be necessarily “material”, that

70


is made up by some particular material, like sheets of paper or steel door-

knobs. For documental artifacts we assume two minimal and very general

characteristics: first of all, (a) that they are capable of providing actors with

some information about their work, e.g., by documenting either what actors

are supposed to do, or by recording what they have already done; and (b)

that some kind of physical interaction with actors is possible. From this point

of view, also web pages and screen interfaces can be seen as documental arti-

facts: the WOAD framework is neutral as regards the medium as long as actors

can be informed on the basis of either data or events.

Since some interactional capability is required, for WOAD documental arti-

facts can be employed the concept of affordance19. According to Norman [Nor-

man, 1988] an affordance is a physical property or design aspect of an object

which influences and suggests how the object can or should be used. In a doc-

umental context, an affordance can either include some physical properties of

the medium or item handled — e.g., the paper medium weight and flexibility

or the color and shape of a text box — or refer to some visual clue to their

function and use — e.g., a small arrow at the bottom of a page can hint the

user to consider the opposite side either. For our practical purposes, the term

affordance can generally indicate the representational capabilities of an item

within a document, i.e., some visual hint that enables users in understand-

ing both what that item can be useful for and what to do with it in terms of

documental practices.

With the term documental practices — or, better yet, activities — we mean

just the plain activities of reading and writing, i.e., what we have called docu-

mental activities to distinguish them from those pertaining to the higher level

task in which documents are just means to retrieve or document some in-

formation (see Section 3.3.1). Actors can then read content, compose con-

tent and refer20 content items to each other, across more documents. There-

fore, documents constitute the inputting and outputting interfaces between

the computational system and the human actors. More specifically, inputs are

textual pieces of information, i.e., informational resources, that actors pro-19Both the term and concept of affordance were coined by the perceptual psychologist James

J. Gibson in 1966 and then more thoroughly discussed in his seminal book “The EcologicalApproach to Visual Perception” [Gibson, 1979]. The concept has been also used in the fields ofcognitive psychology, environmental psychology, industrial design, and human-computer inter-action, where it was introduced by Donald Norman in his book “The Psychology of EverydayThings” from 1988 [Norman, 1988].

20Referring data to other data is a particular case of writing that within the framework isconsidered pivotal and hence differentiated by the general writing.

71


duce and maintain over the documental system; outputs can be both pieces

of information processed by some automatic procedure within the computa-

tional system, much alike the case of regular spreadsheets; or awareness in-

formation, which is conveyed to actors by documents’ (augmented) pages and

screens to make them aware of (a) conventional interpretations that can be

applied to what they are writing and reading and (b) the changing status of

the field of work over time.

3.4.2 The fact space

The fact space is the architectural component where all the informational re-

sources that are at disposal of actors in a given cooperative setting and that

are expressed in a computable manner in the memory structures of their sup-

portive computational system. This includes all the content that is recorded

into the documental artifacts, as well as any other piece of information that

has been previously rendered into symbolic form to be referred to that con-

tent so that actors could be supported in making sense of it (cf. the concept of

context2 in Section 3.2).

The fact space is termed space since it is an unstructured repository of in-

formation that does not have any corresponding entity in the physical environ-

ment. The fact space is also a common space21, in that it contains information

pertaining to all the documents compounding the web of artifacts; documen-

tal inputs are rendered into facts of the fact space and, conversely, the out-

put of the computational system can be properly conveyed in terms of proper

“surface representations”22 [Dan R. Olsen et al., 1998] over the documental

artifacts. Instead of information, we have chosen to adopt the term “fact” for

some reasons. First of all, according to a common sense acceptation, facts are

just something known to exist, to have happened, or to be true. They are true,

reliable information. Moreover, facts can include more pieces of information,

according to some specific and seldom arbitrary rationale. A fact can then re-

fer to a composite set of pieces of information and represent correlated data

into some sort of synthetic notation. Finally, we mean to make an explicit ref-

21With that, we are hinting an influence played by the concept of common information space,but not suggesting any further close functional resemblance between this “common memory”and what we have outlined in Section 1.4.1. See next paragraph for further comments on that.

22Some examples of such representations could be particular affordances or additional itemsor other iconographic means like images and icons that all adapt and change according to thecontext.

72


erence to the terminology that is historically used within the rule-based and

declarative programming paradigms to denote a statement that holds true in

a certain context.

Besides these nominalistic conventions, the concept of common informa-

tion space has influenced the conception of the fact space component about

more substantial features, among which, what kinds of information constitute

its content. Just to recall what we said about common information spaces, they

are “central archives of (organizational) information” “encompassing the ar-

tifacts that are accessible to a cooperative ensemble, their content [as well

as] the meaning attributed to that content by actors” [Schmidt and Bannon,

1992]. The shareability, and hence availability, of data all together with struc-

tures providing some interpretation to those data is a key tenet that deeply

characterizes common information spaces and differentiates them from mere

repository of shared data, as database are [Bannon and Bødker, 1997]. This

key feature is guaranteed by the fact space, but except for the property of com-

monality, the analogy does not have to be taken too literally. As a matter of

fact, we are aware of the metaphorical acceptation in which common informa-tion spaces are said to “contain” shared meaning and agreed interpretations to

data that actors put in common during some cooperative work.

The main tenet of common information spaces that we claim is preserved

within a fact space regards the fact that actors can rely on a resource, namely

the fact space, that is shared by all the members of a given community of users

through the use of documents compounding the same interconnected web.

Within such shared resource, data are stored and gathered by higher level

constructs, called facts, according to some logic by which data are extracted

from single documents and put in common into the fact space.

All together with facts, the fact space also contains some expression that

can be associated to conventional interpretations to data referred by facts. In

order to have some useful outputs be conveyed to actors, at the apt time, these

expressions are not to be just static expressions, like facts; they are rather to

be some code that executed by some computational machine can contribute

to the context-aware change and evolution of the fact space. In order to de-

cline the concept of meaning into computational terms, we then conceive of

a “meaning related to some content item”, as a set of conventional interpreta-tions that can be correlated to that item. As said in Section 3.3, conventional

interpretations, in their turn, are conceived of as relational structures repre-

73


senting conditional behaviors to be triggered or solicited for a given situation

on the basis of its association with the facts representing such situation. To

draw a parallel with a pivotal construct of rule-based programming, conven-

tions and conventional interpretations can be represented as simple rules, i.e.,

condition-driven structures that express some behavior to exhibit whenever

certain conditions occur. Also rules, in fact, associate a set of conditions to

particular behaviors. The latter can be intended either as the result of some

computation carried out by the software application to convey specific out-

puts through artifacts; or as conventional behaviors to conduct in a certain

cooperative arrangement that the computational system suggests to its users

or just make them aware of, according to the context. Accordingly, any fact

space characterizing a single web of artifacts contains:

Documental content Expressed in terms of set of facts, i.e., symbolic expres-

sions.

Information about context2 Expressed in terms of facts and relationships.

The latter ones, more specifically, in terms of correlations (particular

data-data relationships), involvements (particular data-activity relation-

ships) and interdependencies (particular activity-activity relationships).

Agreed and shared interpretations on content Expressed in terms of con-

ditional relational structures, i.e. rules, like that holding that “if a given

datum, namely X, exists, then it means that actors must be made aware

of something, or that something must occur, or be accomplished by

someone”; or also “if X is minor than 5 hours, then it means that. . . ”

and the like.

Cooperative work conventions Expressed in terms of rules, like that hold-

ing that “if someone playing the role A has written something like X, it

means that. . . ” or “if what an actor reads is denoted as provisional, it

means that it can be edited till definite emendation, and it must be rep-

resented differently than confirmed content, and the system has to track

who annotated what and when about it, and. . . ”.

Awareness provision mechanisms Expressed in terms of rules that, on the

basis of either data or events, contextually provide actors with the proper

awareness information on the documental content they manage. An ex-

ample is provided by one of the previously mentioned conventional rules

74


by which “provisional text” must be rendered differently from “definite

text”. In a real setting, this awareness information about the status of a

text would be naturally conveyed by pencil or ball-pen made jottings and

digitized ways to represent the same information are trivial to conceive.

The point about the fact that the fact space contains information about the

context2 (and hence also elements pertaining to the work context) urges us

to make a remark on the artifacts and devices that can feed information into

a fact space. As already stated, our framework concentrates on documental

artifacts. This means that documental data are the main pieces of information

compounding the fact space. That notwithstanding, the fact space can also con-

tain data that are not immediately referrable to documents, as in the case of

work context information. These data can come from other devices or applica-

tions than documents or documental applications (like word processors, web

browsers or email clients). These additional artifacts can be seen as further

“sensors” and “effectors”23 that fetch into the fact space data from the users’

environment and viceversa.

For instance, time information is a type of contextual information that can

be useful even in a fully document-based and document-intensive domain. In

a number of different situations, it can be useful to base some conventions

(and hence their computations) on the time of an agreed schedule. Time in-

formation can be used to provide both absolute and relative indications: e.g.,

“it is eight o’clock”, “it is five days since the data were entered”, respectively.

Its usefulness is clear especially with respect to the possibility to correlate time

information with other application-level information so as to derive context-

aware implications: e.g., “it is eight o’clock, hence it is breakfast time”; “it is

five days since the data were entered, hence it is time to update them”. Ob-

viously also many other pieces of information can be “extracted” about the

physical setting of a work arrangement, depending on the type and number of

the very devices that populate it and that are capable to “publish” what they

perceive and process to some network facility.

For its capability to encompass also these kinds of environmental informa-

tion, the WOAD framework can be considered suitable for the development

of context-aware applications, whereas contextual information is extracted

23We borrow these two terms from the field of robotics and domotics to indicate devicescapable of perceiving the environment and to produce an effect on it, respectively (cf. [Russelland Norvig, 1995]).

75


by several other sources, besides documents themselves. These can be made

context- and situationally-aware [LaMarca et al., 1999] by means of the “in-

ference capabilities”24 of the transitors.

3.4.3 The transitors

As said in section 3.3.1, the fact space space can only be changed by two

classes of agents. Human actors change the documents’ content as they use

documents along their cooperative work trajectories. These changes then are

“reflected” into the fact space, in those facts that are a sort of symbolical proxy

of what is read and written on the documents compounding the web of arti-

facts.

Transitors are the other entities that can make the fact space “transition” to

a new, consequent state, obviously asynchronously with respect to the human

activities. State transition is akin to a rewriting process, accomplished by dis-

tributed and asynchronous transitors. From a conceptual point of view, these

can be seen as functions δ that relate the global state at a given time, S′with a

consequent state S′′; S

′also includes the inputs coming from the documental

artifacts, while S′′

also includes the outputs that is conveyed to actors through

their artifacts.

Transitors can alternatively be seen as the computational machines (as

well as the corresponding hardware machines) that compute the δ function,

by applying rules, i.e., computable representations of conventions and agreed

meanings, to the data present within the fact space (S′). Therefore, these ma-

chines reify into the concept of controllers or computational machines the

“dynamic part” of the WOAD model, i.e., what has the capability to apply

conventional rules to the different levels of context related with documental

artifacts. In so doing, artifacts can aptly convey an up-to-date representation

of the context in which actors operate and make sense of their documents,

and hence become more supportive tools to the actors’ deeds and needs (cf.

the concept of active artifact in Section 1.5.1).

24We use such expression within the narrow acceptation of inference within the rule-basedprogramming paradigm. The term inference is therein harked back to the meaning that is givenin Logics of “process of deriving the strict logical consequences of assumed premises”, withouthinting to any particular cognitive capability of the human being.

76


3.4.4 Some terminological specification

For the sake of clarity, we provide some further terminological note about the

way the above mentioned concepts of the WOAD model have been rendered

into the specific constructs of the WOAD language that we will describe in

detail in Section 5 and into the current implementation middleware that we

will describe in Section 4. We will denote by the term convention both the

conventional and agreed interpretations on documental content and the co-

operative work conventions. As said above, they are just conditional relationalstructures between an antecedent, containing some conditions, and a conse-

quent, containing some set of actions that can be applied to the fact space.

Such conventions are shared among all artifacts and transitors within the fact

space. Conventions, to be applied to the fact space by some transitor, need

to inform some correlated mechanism, the term by which we denote the exe-

cutable (i.e., applicable) representation of a convention.

In the rule-based jargon, both conventions and mechanisms are denoted

with the simple term rule; we have so far used such term according to the

common acceptation and in a quite naively manner: in the following, we will

replace it with either convention or mechanism according to whether we are

speaking of rules that are shared within the fact space (i.e., conventions) or of

rules that can be executed by transitors and whose execution can change the

fact space (i.e., mechanisms). The reason why conventions and mechanisms

— i.e., sort of “static” knowledge on the conventions of a certain work arrange-

ment and “dynamic”25 knowledge that can produce some actual effect on the

common fact space, respectively — have been decoupled will be motivated in

Chapters 5 and 7. Here we can anticipate that conventions can be embeddedinto some mechanisms or be transformed into executable mechanisms accord-ing to the context. This gives a powerful tool to modulate which conventions

should be applied according to the very situation at hand and to also modulate

the distributed nature of their application across multiple transitors.

In fact, the conventions/mechanisms whose conditional elements are con-

tinuously matched with the fact space’s content can be a smaller partition of

the overall number of conventions available and put in common by artifacts

into the fact space26. These partitions are collected within the transitors, in

25Such terms are not to be intended in the acceptation that the former cannot change whilethe latter can. Rather, the former pertains to a static characterization of the model, while thelatter pertains to the dynamic characterization that is applied to the static one.

26In Chapter 5, we will see those conventions will be rendered by the construct of convention-

77


their so called rule-sets. Convention distribution into different transitors’ rule-

sets is accomplished even at run-time, according to some rationale that is not

known a-priori and depends on the actual way the framework is applied to

some specific application domain.

This opportunity for distribution can be achieved for the intrinsic dis-

tributed nature of the domain; for instance, it can be achieved either because

the artifacts involved in the domain in hand are autonomous computational

devices or because, within that domain, data are accessed by different settings

or facilities, and hence through physically different though correlated docu-

mental applications. The correlated opportunity for parallelism — i.e., the si-

multaneous application of different conventions by autonomous transitors —

can be achieved also for a matter of separation of concerns: conventions that

cope with the same aspect of the domain can be aggregated since their execu-

tion is semantically independent27 from other rule sets coping with different

aspects. In Chapter 4, we will see that distributed and autonomous access to

contextual data is an opportunity to get a richer picture of the overall context

as it is rendered into symbolic facts within the fact space.

3.5 Software Architecture

The high-level architecture (see Fig. 3.8) describes which entities are involved

and how they relate to each other in systems that are designed and deployed

using the WOAD framework (namely, its model and language). Such systems

are obviously much more complex with respect to this abstract representation.

In fact, real systems are embedded, on the one side, in their development

framework, i.e. in a specific programming environment and user interface

management; and, on the other one, in the real and physical field of work,

in terms of domain specific applications and their data structures.

As an intermediate representation between the model abstraction and the

layered structure of the implementation, we also depict a software architecture,

where the model entities are related to software components that compound

a generic implementation of a WOAD compliant web of documental artifacts.

fact.27In this context we are not talking of strong logical independency nor of any syntactic or

functional independency. Two rules could cope with very different aspects of the same situa-tion and still refer to some common facts. DJess, the underlying middleware for distributingrule-based inference systems (see Section 4) guarantees that internal inconsistencies due toexecution interference is properly prevented.

78

3.5. SOFTWARE ARCHITECTURE

Figure 3.9: A graphical representation of the architecture of a WOAD-compliant soft-ware application. At the top, we depicted the documental applications that are madecooperation-aware and context-aware by the underlying tiers.

79


With reference to Fig. 3.9, we describe the software architecture as a multi-

tiered stack. In such representation, we consider both actors and their artifacts

(possibly running in software documental applications) with the aim to en-

compass in the same vista both aspects of the physical environment where

actors work and the actual components of the software system they use28.

Actors interact with documents where they record their notes, keep trace

of the work going on in their setting and get informed by getting access to their

informational resources. At this description level, it is not important to spec-

ify whether these documents are either paper-augmented digital documents

(e.g., cf. [Guimbretiere, 2003,Bang et al., 2003]) or desktop-like applications

on either portable devices or personal computers, once that the content of

documents has been digitized in some way29.

Either “real” documents or word processing applications (i.e., anything the

human actors really interact with) interact with the WOAD-compliant applica-

tion. The actual “pages”, which actors read or fill in, are rendered in terms of

factual representations, all together with their related conventions. The spe-

cific application logic determines the exact structure of the facts representing

documents, other contextual and environmental aspects, as well as the nature

of conventions pertaining to how to cope with records and context. The doc-

umental cooperative application is then defined by all the application-specific

data structures that the designers have conceived to represent the WOAD

model entities and relationships. Document content, conventional knowledge

and contextual representations are all stored into a common memory that is

shared among all the artifacts (i.e., either devices or applications) and their

users. The management (e.g., access control, consistency check) and the basic

functionalities (e.g., updating operations) of such shared memory is provided

by the underlying tiers.

The content of the fact space changes according to the application of mech-

anisms that embed primitives expressing the model constructs. This applica-

tion is instantiated by a middleware software providing a framework specific

execution platform. We distinguish between the layer giving the operational28In that, such representation must not be intended as a strict ISO-OSI architectural struc-

ture.29For instance, if the domain at hand does not require a strong temporal characterization and

a highly dynamic response to environmental changes, documental content could be extracted atregular intervals by means of paper scanning and optical character recognition (OCR) services,while content-related outputs could be conveyed through public wallboards or other personalelectronic devices. For a proposal in the hospital domain, see a previous work of ours [Cabitzaet al., 2004].

80

3.5. SOFTWARE ARCHITECTURE

semantics of the WOAD language (i.e., to the primitives that act on the WOAD

structures) and the layer guaranteeing both data exchange between different

documental applications (or other devices) and code execution (i.e., pattern

matching between facts and rules and rule interpretation). We denote the for-

mer as WOAD middleware, while the latter is the middleware providing the

WOAD middleware with communication and rule execution capabilities: in

the current implementation this layer is instantiated by the DJess middleware

(see Chapter 4).

Possibly multiple different and distributed physical machines can join into

a web of documental artifacts and any physical machine can host one or mul-

tiple transitors. The communication middleware, in our case DJess, hides the

complexity of the virtual machine running on each physical machine (in our

case, a Java Virtual Machine). Virtual machines implement the functions of the

communication middleware in terms of service calls to the operating system

and their underlying physical machine; the latter is connected to the others

computational machines by means of a communication network facility.

In the following chapter we will outline the current implementation of the

middleware layer that permits (a) to define and maintain the fact space shared

among more physical machines; (b) to enable distributed transitors to asyn-

chronously access and transform that common memory; (c) to implement the

WOAD language constructs and primitives and make the related mechanisms

computable (i.e., the instantiation of the WOAD middleware – see Fig. 3.9).

This implementation has been conceived as a lightweight communication mid-

dleware for distributed inference systems deployed in a context-aware com-

puting domain: DJess.

81

Chapter 4

The Rule-based middlewareimplementing WOAD

During our research on software architectures and systems by which to sup-

port cooperative work, we also engaged a cooperative research effort with the

aim to focus on the way such systems could get advantage of getting a more

comprehensive access to the context of the cooperative arrangement and of

exhibiting some inference capability on that context so as to provide a more

aptly and adequate support to the involved human actors. We surveyed the

main contributions from the specialist literature of the ubiquitous computing

field we mentioned in Section 3.2 and tried to interpret its main tenets in the

light of reaching a better support to cooperative work settings. Our aim was

then to enable the development of collaboration-aware applications that could

be also context-aware while receding into the background and not requiring

direct human interaction to provide their support.

Our first explorations in the field led us in conceiving (a) an architecture to

harmonize innovative technologies — like digital pens, electronic-augmented

paper and smart wallboards — in support of human coordination in hospital

wards (the SWIRLS project [Cabitza et al., 2004]), (b) a methodological frame-

work for the high-level management of highly interconnected devices within

“intelligent environments” [Cabitza et al., 2005a], and (c) a model and archi-

tecture to design collaborative ubiquitous computing environments [Cabitza

et al., 2006b].

To be able to develop our prototypal applications and to apply our com-

petencies on rule-based programming in the fields of context-aware and

83

CHAPTER 4. THE RULE-BASED MIDDLEWARE IMPLEMENTING WOAD

ubiquitous computing we engaged in the development of a full-fledged, yet

lightweight, communication middleware and scripting environment that could

be deployed into any Java-enabled device. We intended this middleware to en-

able programmers and designers of a context-aware application in abstracting

from some low-level and technical details so as to feel free to concentrate on

the very logic of the application and its ways to adapt to the context and pro-

vide users with “situationally-aware” services. For this reason, we adopted the

declarative programming paradigm, which focuses on the expression of whata system should do, rather than on how it really accomplishes it and conceived

the DJess middleware.

By means of DJess, programmers can represent declaratively contextual

information at application level and conceive symbolic rules that bridge data

from the lower levels (i.e., the physical context as can be perceived by the

devices’ sensors) to the higher level information (i.e., the logical context per-

taining to the work settings, the cooperative conventions and the coordinative

protocols) so as to drive the behaviors of the overall system towards the ful-

fillment of the requirements of the particular application domain.

In the following sections, we will characterize the main motivations that

led us to design the DJess middleware as we did: to that aim, we will introduce

the themes of context sharing and semantic interoperability as a particular and

effective way to get an ensemble of devices more context-aware than any of its

single parts. The focus on these themes makes also clearer why we decided to

implement our first WOAD-compliant application using the DJess middleware:

to have a heterogeneous and disjointed assemblage of digitized documents,

documental applications and other personal devices become a context2-aware

and coordinated web of artifacts that are situated in a certain work setting and

are aligned toward the common goal of timely and aptly providing their users

with useful information for their smooth and “calm” coordination [Weiser and

Brown, 2005].

4.1 The need to make access to context “ubiquitous”

A context-aware computing environment can be defined as a tightly integrated

collection of computational devices that is able to aptly assist the user when-

ever and wherever she needs it. Such a collection is inherently distributed

and heterogeneous; in fact the computational systems that compose it can

84

4.1. THE NEED TO MAKE ACCESS TO CONTEXT “UBIQUITOUS”

be either mobile and embedded in any kind of everyday object or embedded

and hidden in the infrastructure surrounding the user: Weiser has accordingly

spoken of ubiquity [Weiser, 1993], in that computation must seem just every-

where — or better yet, just where it needs. To achieve this property in quite

an unobtrusive way, the integrated collection of devices must then succeeds

in augmenting the environment surrounding the user while receding into the

background of it. In other words this augmentation must be accomplished

transparently both as regards the user and, for the intrinsic heterogeneity

of the involved devices, also as regards the integration mechanisms that al-

low the tight interoperability required by the application domain. As Ark and

Seller pointed out, this transparency regards also communication made eas-

ier and more seamless, not only between users and things, but also between

things [Ark and Selker, 1999]. For this reason designers and developers of

context-aware applications need a set of tools able to provide abstraction and

functionalities above both the single devices and the network facility techni-

calities.

4.1.1 Middlewares for the semantic interoperability

The software layer that provides developers with a simpler programming envi-

ronment in order to manage the complexity and heterogeneity of distributed

infrastructures is usually referred to as middleware [Campbell et al., 1999].

Middleware systems may vary a lot in terms of the programming abstractions

they provide and of interface they give over network and hardware functional-

ities. One of the main requirements for middlewares in ubiquitous computing

environments is that they allow these autonomous and heterogeneous sys-

tems to seamlessly communicate and interact with one another so that they

are able to align with each other more aptly towards a coherent response to

user’s activities.

The underlying assumption regarding this capability is that by means of

communication, nodes of a ubiquitous computing network might augment

their access to context, i.e., any useful information about the users’ and the

devices’ state. Only in this way, an ubiquitous computing system, as a whole,

can reach a more comprehensive understanding of the user’s current needs

and get a broader choice of responses to answer them more timely and aptly:

in the Dey’s words “by improving the computer’s access to context, we increase

the richness of communication in human-computer interaction” [Dey, 2001].

85


We then may wonder if, by improving or just facilitating the applications’

access to context, we may increase the quality of interaction and the integra-

tion between different computational systems. Integration here means that

such devices and applications reach and maintain a low-level interoperability

as well as a high-level interoperability. The former regards the ability to share

data over a network facility and is guaranteed by any middleware employed

in ubiquitous domains by defining or supporting standard interfaces and pro-

tocols. The latter regards a tighter integration and the ability to share domain

and even situation-dependent representations, as well as with their “mean-

ing” in terms of local and global behavior according to those representations.

This interpretation derives from the definition of context we mentioned in

Section 3.2 that conceives context as a set of data regarding environmental

states that determines an application’s behavior [Chen and Kotz, 2000]. Here,

we emphasize the capability of the application to “understand” context and

react accordingly to it. The burden to gain both kinds of interoperability is

usually left to the application layer programmers, whose duty is to build ap-

plications that are both compliant with the data representation provided by

the middleware and able to understand what these data represent.

In several occasions researchers have pointed out that, once contextual

information is extracted from the environment and processed for a local re-

sponse, this can also be used afterwards by other devices [Fuentes et al.,

2004]. Separating the acquisition of contextual information from its use can

be also seen as an important requirement so that application designers can

concentrate on high-level and user-centered issues instead of worrying about

the details of a sensor and how to acquire context from it [Dey et al., 2001].

Yet when information is managed for local use, it can be in whatever format

and at whatever level of abstraction it happens to be; conversely, when infor-

mation is shared to be used by heterogenous and possibly remote applications,

high level interoperability issues arise inevitably, such as homogeneous in-

formation interchange, sound coordination mechanisms based on those data,

and high-level coordination among applications towards systemic goals. In

fact contextual information should be shared as contextualized as possible, in

that it should be enriched by high-level characteristics that make it really de-

vice independent. This bring us introducing the concept of the highest level of

interoperability, also called “semantic interoperability” [Howie et al., 1996].

In ubiquitous and context-aware computing domains semantic interoper-

86

4.1. THE NEED TO MAKE ACCESS TO CONTEXT “UBIQUITOUS”

ability can be considered as the capability of different computational systems

to understand and react to what has been previously perceived and processed

(inferred) by other computational systems, i.e., as the capability of a system

to operate on contextual data (i.e., to consume and rely on them) that are

provided by others as if they were perceived by itself, without such a medi-

ation. Semantic interoperability is then a feature characterizing a cooperativeensemble of heterogenous context-aware systems, where with cooperative we

intend that context — as a whole — is a set of data cooperatively gathered by

sub-systems that rely on each other to access context and its meaning in the

light of the shared goal of supplying an appreciated service to the user.

The fact that sharing information coupled with its interpretation is neces-

sary for an ensemble of generic “agents” to cooperate is an interesting exten-

sion into the world of computational machines of some of the tenets from the

CSCW field (cf., especially those underlying the concept of common informa-tion space given in Section 1.4.1 [Bannon and Bødker, 1997]). Such sharing

appears as a strong requirement in any domain where coordination is needed

and where simple sharing of raw data bases could not be enough to aptly

contextualize them.

To address the issue of semantic interoperability among context-aware de-

vices we developed DJess, a communication middleware by which inference

systems can represent context declaratively (facts) and programmers can con-

ceive behavior as a reactive (rule-based) activity to this context. This mid-

dleware allows heterogenous systems sharing a common inference paradigm

to share seamlessly and incrementally context representations — facts — as

well as declarative interpretations of those facts, in terms of reactive behav-

iors (rules) in response to those representations. By permitting transparent

rules sharing among inference systems, the DJess middleware enables pre-

processed perceptions to influence applications and hence to enrich their re-

sponse to context.

Such a middleware is intended to give an explicit support to application

layer programmers in achieving semantic interoperability in that it would pro-

vide the programmer at least two important features. On the one hand such

a middleware would provide the programmer with a higher-level and user-

friendly syntax that is more oriented to grasp the semantics of context repre-

sentations and more suited to couple these with the applications’ behavior. On

the other hand, it would provide the programmers of compliant applications

87


with the built-in capability to make their application share transparently and

seamlessly both raw context and code that can interpret it in terms either of

transforming it farther or responding aptly to it. To this regard, we intend to

show how inference systems could provide context-aware applications design-

ers with an useful abstraction level so that high-level semantic interoperability

could be reached among peer applications.

In section 4.2, we first introduce the concept of distributed inference sys-tem along with the main characteristics of the DJess architecture; this will be

further outlined in the section 4.3 along with some implementation details.

Section 4.4 contains the main motivations of the project in the light of some

related works that inspired our proposal and closes the chapter dedicated to

the current implementation of the software layers underlying the WOAD mid-

dleware.

4.2 DJess-Based distributed inference systems

DJess is a Java-based tool1 that allows to deploy distributed asynchronous in-

ference systems [Ishida, 1995] and that can serve as lightweight middleware

by which distributed inference systems can share both contextual information

and reactive behaviors. To illustrate its architecture and its main functional-

ities, we first give some general terminology on inference systems and then

describe two main concepts that underlay its conception and implementation.

We then start from focusing both on inference and distribution, with the aim

to make briefly clear the advantages that can come from making inference

distributed, especially in an ubiquitous computing domain.

At the beginning of Section 4.1, we said that context-aware systems must

feature ubiquity and transparency, indeed they must also exhibit some “intel-

ligent” behavior in terms of context processing and ability to recognize and

aptly react to user actions by reasoning on knowledge that was previously

acquired or possibly learned from past experience. For such an application

domain, the deployment of distributed inference systems is a feasible and ad-

equate solution once that coordination between the distributed components

can rely on a high level (i.e., semantic) interoperability provided by a suit-

able communication middleware. As such middleware, DJess offers both spa-

tial and temporal decoupling by allowing inference systems to be directly un-

1Cf. http://java.sun.com/

88

4.2. DJESS-BASED DISTRIBUTED INFERENCE SYSTEMS

aware of each other’s identities and to run their control flows asynchronously

and even within non-overlapping lifetimes; it enables information sharing and

communication among distributed agents through hidden remote object invo-

cations (i.e., RMI) according to a generative communication model [Gelernter,

1985] — that is through a shared global memory — so that no explicit com-

municative message is necessarily exchanged; furthermore, DJess provides a

common programming abstraction across a distributed system by turning a

collection of devices into a single integrated computational environment.

4.2.1 General terminology

As regards its name, “Distributed Jess” is intended to make distributed and

tightly interacting computational systems on which a Jess2 instance is run-

ning. Jess is an acronym for “Java Expert System Shell”: it is a Rule Engine

and scripting environment that is written in JavaTM and made quite tightly

integrated with the Java language.

DJess has been developed to add to the Jess inference functionalities a set

of mechanisms that allow to transparently create and manage an integrated

collection of Inference Systems (IS) that communicate by means of a virtuallycentralized global memory with the function of a blackboard enabling collab-

orative context processing [Hayes-Roth, 1985] (see Section 4.4 for a further

analysis on this concept).

We speak of “inference system” for simplicity, where with such term we

indicate any computational system (typically a device or an application) that

is able to reason about what it perceives, and hence is able to create and ma-

nipulate knowledge about the environment and itself. Although the reader

should not mistake the WOAD middleware — a cooperation-oriented middle-

ware for the sharing of context2 — with any of its possible implementation

(e.g., DJess), we make here explicit the association between DJess-based in-ference systems and WOAD transitors. Other terminological mappings will be

given in Section 4.5.

4.2.2 Jess-based inference systems

Jess is a Java program written by Ernest Friedman-Hill to deploy fast and

flexible Rule-Based Systems (RBS) [Friedman-Hill, 2003]. RBSs are programs2Jess - the Java Expert System Shell,

http://herzberg.ca.sandia.gov/jess/.

89


Figure 4.1: Dynamic representation of an inference system.

whose control flow can be said both event-driven and data-driven in that re-

spectively they perform some action only if some condition is true and they

are able to produce (infer) conclusions from a set of premises. Accordingly, in

the following of this chapter we use the terms rule-based systems, production

systems, and inference systems as synonyms.

As a scripting language (and an interpreter to that language) conceived to

implement RBSs, the core computational construct of Jess is the rule. In or-

dinary language a rule is (also) a set of instructions or directives that applies

in certain situations. Accordingly, computer scientists have called rules if-then

computational constructs expressing recommendation of action if some con-

dition occurs. More precisely put, a rule expressed in Jess language consists of

a conjunction of condition elements corresponding to the if-part statements of

the rule (also called the left-hand side or antecedent of the rule), and a set of

actions corresponding to the then-part of the rule (also called the right-hand

side or consequent of the rule), that are performed only if all the condition

elements of the antecedent are true according to the current context. All that

said, RBSs are but programs that select and execute available rules according

to the current context they perceive; this makes RBSs particularly suitable for

implementing reactive architectures that must be modular and easily extensi-

ble.

Like other systems implemented by similar rule-based languages (e.g.,

CLIPS, OPS5), each Jess inference system is composed of three main com-

ponents: a rule set, a Working Memory (WM), and a rule engine; in Figure 4.1

these are respectively indicated by RS, WM and E. The rule set is the collection

of all the rules that can be executed by the IS according to the current content

of the working memory. The working memory is the storage of the knowledge

nuggets; these nuggets represent the factual knowledge of the RBS and are

hence called facts: facts are like records with certain value fields called slots;the fields structure is specified by a template that defines types and default

values of the slots; for this purpose Jess uses the deftemplate construct. The

90

4.2. DJESS-BASED DISTRIBUTED INFERENCE SYSTEMS

Figure 4.2: Interactions between context, represented by facts, and IS’s sensors andeffectors.

rule engine applies rules on facts and executes their right-hand sides.

Conceptually, a RBS can quite easily be made a component of a context-

aware ensemble; practically speaking, the set of facts that constitutes a work-

ing memory can contain a symbolic and declarative description of a current sit-

uation and the rule set can be seen as the interpretable code of the IS by which

the programmer can put in relationship context conditions and devices’ behav-

ior and actions. For that to be accomplished, facts must also represent a possi-

ble connection between sensors/effectors and context producing/consuming.

As we will describe in Section 4.3, Jess allows to bind facts to Java objects:

this permits also to conceive Java programs that are sensitive to context either

thanks to an event-driven approach or by means of a reflective mechanism. In

the former case, context changes show up by means of the assertion of some

facts expressing those changes. In the latter, sensors’ and effectors’ states are

represented by some facts, whose modification corresponds respectively to

some sensed perception or some action to accomplish within the environment

(see Figure 4.2).

The inference process

The process of matching contextual instances and rules is carried out by the

rule engine — also called inference engine: a program (interpreter) that per-

forms iteratively the so-called Match-Resolve-Act (MRA) cycle over the rule set

and the working memory (as hinted in Figure 4.1 by the circling arrows inside

the engine). In a MRA cycle, at any given time, the rules of the rule set are first

selected and activated by matching them against the WM elements (Match

phase); then a rule among the activations is chosen for immediate execution

according to some selection strategy (Resolve phase) and finally executed (Act

91


or firing phase). In the Act phase, facts can be modified or deleted, and new

facts can be added to the working memory as well. In the Jess syntax, this is

respectively obtained through the modify, retract, and assert constructs.

In choosing the scripting environment to base the DJess distributed in-

ference systems on, the possibility to deploy them across different platforms

and to rely on a well documented architecture played a decisive role. There-

fore, our choice fell upon Jess: its source code is available and it is written

entirely in Java; moreover, its rule engine has been shown to be fast and effi-

cient especially for large data sets and it is widely used within a professional

programmers’ community.

4.2.3 Distributing an inference system

The concept of distribution in Ubiquitous Computing is a key one. If compu-

tation is to be “ubiquitous”, it must be embedded into the environment and

almost hidden to human perception. For this reason, ubiquitous and context-

aware devices and applications must be highly sensitive to environment and

not consider only information explicitly provided by users [Benerecetti et al.,

2001]. In other words, these devices must be able to react aptly to any infor-

mation might come from — and could be derived from — the environment.

As noted in Dey et al. [Dey et al., 2001] context (production) is inherently

distributed: in fact one of the most challenging aspects of handling context is

due to the necessarily distributed myriad of sensors and devices involved in

sensing it. But distribution can reveal itself to be also a resource to support de-

signers in coping with other three major challenges in ubiquitous computing:

(1) the need to gather directly precise and local data on relevant entities asclose as possible to where they are and act; (2) the need for a persistent stor-

age and constant access of context information; (3) and the need to interpret

the contextual data into useful abstractions [Moran and Dourish, 2001] so

that physical information could feed device-independent reasoning and then

context could include more conceptual and domain-dependent logics.

The latter point can certainly involve automatic inference, that is it can call

for a more active role by computational and autonomous devices scattered in

the environment in gathering and processing raw data in order to create a

coherent view and interpretation of the current context. Hence distributing

inference and giving designers a middleware to support them in distributing

the process of the direct and cooperative interpretation of context can be use-

92

4.3. DJESS ARCHITECTURE AND IMPLEMENTATION

Figure 4.3: Distributed Inference System (DIS).

ful.

Distributing an inference system means both to distribute in space the in-

ference engines and to parallelize in time the inference process made on the

same contextual data. In Figure 4.3, ISs are represented by their engines, while

rule sets are not indicated for simplicity. Working memories have an overlap-

ping region to indicate that some facts (white dots) are shared, whereas others

(black dots) are not.

Generally, distribution of an inference system can be useful for two main

reasons: making the inference process faster and getting physical separation.

The former allows better performances in terms of throughput and response

time; the latter supports robustness, resource sharing, agents cooperation, and

— for what we have just said — ubiquitousness of computation. Distributing

an inference systems implies to get all these things but which aspect to favor in

the actual implementation depends on the very purpose a distributed solution

is sought. In fact, any design must come to some compromises and no optimal

solution for every application domain can be given. In designing the distribu-

tion of Jess-based inference systems, we had to face design and implementa-

tion alternatives between performance and consistency guarantee. As DJess

has been conceived for a limited set of application domains — i.e., ubiqui-

tous, context-aware and pervasive computing environments (e.g., [Aarts et al.,

2002,Lindwer et al., 2003]) — where response time is not short, the focus has

been put more on consistency than performance.

4.3 DJess architecture and implementation

DJess is a middleware that allows inference systems (a) to infer on data col-

lected by other devices as they do on their own perceptions; (b) to share

93


transparently both physical data and refined data without need of a fixed

communicative process, since no designer could feasibly foresee any situation

in which this sharing must be done; and (c) to share, along with contextual

data also local interpretations, procedural rules, and abstract relationships by

means of which conclusions can be drawn from these contextual data and

from any possibly sensed data where necessary.

From the implementation point of view, DJess is mainly an extension of

Jess; its architecture is designed with the goal of keeping modifications of the

Jess code as few as possible, so as to cut down on development time and bugs,

and to avoid duplicate work being done on the same functionalities. DJess

adds a communication layer underneath Jess inference capabilities; Jess code

of the inference engine and the interpreter is essentially unchanged in DJess.

We take advantage of the mechanisms of inheritance and polymorphism so

that Jess unmodified code invokes DJess code whenever it operates on facts.

In this way the DJess communication layer intercepts every modification of

the working memory and propagates it to the other inference engines (see

Figure 4.4).

The WoIS and the SWM

In DJess the set of ISs that are connected together is called Web of InferenceSystems (WoIS) and is characterized by a space where facts are shared, the

Shared Working Memory (SWM). Facts in the SWM are directly manipulated

by the rules of the various ISs in the WoIS as if they were local. In effect there

is no physical common memory in DJess: every IS has a copy of each shared

fact in its own local WM and all ISs’ engines run independently of each other.

Therefore we say that the DJess WoIS is a distributed asynchronous inference

system [Ishida, 1995] where no centralized data repository is kept and facts

are transparently shared among the nodes of the network.

In a context-aware environment, DJess is used in two different ways at

the same time. For the device builder, DJess is mainly an inference engine

constituted by a set of Java classes. She develops a bridge between the infer-

ence application and the platform or device functionalities. For the distributed

application designer, DJess is mainly a rule interpreter that totally adopts the

Jess syntax, with the additional functions for creating, joining, leaving, and

destroying a WoIS, and for sharing rules across its ISs.

DJess main features are fact sharing and rule sharing. In the next sections

94


Figure 4.4: Jess-DJess relation

we describe in details how these are achieved, and then we take a look to the

setup of a WoIS.

4.3.1 Implementing the DJess shared memory

Generally a distributed system is said to be transparent when it is able to

ensure that “a collection of independent computers appear to its users as a

single coherent system” [Tanenbaum and van Steen, 2002]. DJess’ users are

programmers, and from their point of view DJess shared memory is transpar-

ent, as the same primitives, borrowed from Jess, are used to manipulate local

and shared facts.

A powerful Jess feature, shadow facts, is employed to build and synchro-

nize DJess shared memory. This feature allows to use Java beans (objects

whose attributes are accessible through set and get methods) as if they were

elements of the working memory; whenever an object is used in such a way,

Jess creates a fact — the shadow fact — that is dynamically linked with that

object: every modification made on the bean is mirrored on the “shadowed”

fact and vice versa. For every fact that is shared across the WoIS, a shadow

fact, and hence a shadowed java bean, is present in every node. This Java

bean is called proxy in the DJess terminology; all the proxies corresponding to

the same shared fact are linked together by means of a Java remote object that

we call ghost fact. The ghost fact has two purposes. First, it stores the state of

the shared fact, i.e., the slot values; through its proxies, modifications to its

slots are propagated to the related shadow facts in in the different working

memories. Second, it provides a single point of synchronization for the ISs,

as we explain shortly. Ghost facts could reside in any Java virtual machine,

95


Figure 4.5: DJess facts synchronization.

but for simplicity, they reside in the Java virtual machine of their asserting IS.

In Figure 4.5 a graphical representation of the DJess synchronization mecha-

nism is given: JVMi are Java Virtual Machines; SWMi are local copies of the

shared working memory; sfi are shadow facts, representing the same shared

fact; pi are their corresponding proxy objects; and g is the ghost fact used for

the shared fact synchronization. Although shared facts are replicated in each

IS’s working memory, the coordination achieved through ghost facts permits

to conceive of the SWM as one entity.

Programmers can decide whether a fact will be private or shared at the

assertion time, using modules. Modules in Jess are just namespaces for facts

and rules. In DJess, a special module, selected at join time, is designated to

hold all shared fact; every fact asserted in that module is shared.

The use of ghost facts for the shared memory permits to keep Jess’s imple-

mentation of the Rete algorithm unchanged. The same is true for the modify

primitive. In Jess (hence in DJess), whenever modify is invoked on a shadow

fact to change some slot values, the corresponding set methods of the shad-

owed Java bean are called. So in DJess, when a set method of a proxy is called

in response to a modify, no proxy internal variable is updated; the method

just calls the corresponding ghost fact set method. In so doing, the ghost fact

updates its attributes and notifies all its other proxies of the modification by

calling their set methods; consequently the modification is shadowed in all

ISs’ working memories through the native Jess mechanism.

Asserting and retracting shared facts involves some modifications of Jess

mechanisms. When the engine of an IS encounters a deftemplate that tries

to create a new template in the shared module, the Java code for two new

96


classes, namely the proxy and the ghost fact classes, is generated from the

parsing of the template, so that these classes have a bean property for each

slot in the original template. The code is then compiled and sent along with

the template to all the other WoIS members, that from then on are ready to

assert shared facts using the new template or accept shared facts asserted from

another IS.

When an engine calls an assert that refers a shared template, it instanti-

ates the ghost fact class associated with the template and initializes this new

object with the slot values of the fact; it then notifies all the other engines

in the WoIS, sending them a reference to the ghost fact. Each engine creates

a new proxy bound to the ghost fact and uses it to assert a shadow fact in

its working memory. Likewise, when an engine retracts a shared fact (via a

retract), it notifies all the WoIS members’ engines, which in turn remove the

corresponding shadow fact from their memory; finally also the ghost fact is

removed from the system.

Different ISs could access the same shared fact at same time by firing some

rules, and this may cause conflicts and inconsistencies. Two rules are said to

interfere if there is a dependency of some sort between them [Acharya, 1996].

A read-write dependency (or a true data dependency) occurs between two

engines if one of them fires a rule that writes (i.e., modifies or deletes) a fact

read (contained in the if-part) by the other and a write-write dependency (or

an output dependency) occurs if both of them write the same fact [Tata et al.,

1999].

In DJess, interfering rules are prevented to fire simultaneously, using locks

associated with ghost facts and acquired in the transition from the Resolve to

the Act phase. Rule firings are treated as single indivisible units, much like

transactions (consistency through serializability): the effects of two parallel

rule firings have to be the same of some serial sequence of those firings; more-

over changes made by a rule firing cannot trigger another rule firing until the

former is finished. It is not a surprise that the system used to control concur-

rency in DJess is a frequent solution in transaction systems, the two-phase lockprotocol. In a two-phase lock scheme no further lock can be acquired after

having released any lock [Gray and Reuter, 1994]. A major difference of DJess

from the common uses of the two-phase lock protocol is that DJess doesn’t

make use of rollback, as rollbacks would disrupt the Jess mechanisms that

prevent rules from firing two times on the same activation

97


All locks are acquired before the actual rule execution, so if the acquisition

of any lock fails, the firing can be postponed, after having released all acquired

locks, without any rollback. Rule firing execution is divided in three steps:

locks acquisition, statements execution, and locks release. In the first step, a

lock is acquired for every fact matched in the activation and for every fact

that has a binding (i.e., a variable referencing it). In the second step actions

are then performed according to the rule statements; new facts, created by

assert executions, are immediately locked, in order to prevent another engine

from firing a rule on a new fact before the asserting rule execution has been

completed. In the last step, all locks are released and if a rule has been blocked

by any of these locks, it is eventually fired.

In order to lessen the burden on performances, the default resolve strategy

of DJess is partially nondeterministic. Nondeterminism here means that if a

rule is prevented from firing due to lock contentions, the engine can choose

another rule to fire instead of blocking. Salience (a priority explicitly specified

by the programmer) is always honored.

We notice that DJess addresses only the consistency problems due to con-

currency; those possibly arising from knowledge bases integration are left to

IS designers.

4.3.2 The rule sharing mechanisms

DJess provides a load-rule function which enables to inject a rule into a re-

mote rule set; this makes DJess a (weak) mobile code environment [Fuggetta

et al., 1998] since it allows interpretable code to be transparently transferred

among different inference systems. An unload-rule function permits to re-

move rules previously sent.

Rules within a WoIS are shared in a two-step process (see Fig. 4.6, part

(b)): the actual rule sharing (1 in Fig. 4.6) and the rule loading (2 in Fig. 4.6).

In the first step, actual sharing, a sender IS embeds a rule in a special shared

fact, called shared-rule, and specifies the intended destinations for the rule,

using the corresponding slot of the shared-rule fact. A rule shared in this way

is somewhat a “dormant” rule, as it cannot fire until it is loaded in the (local)

rule base of an IS. In the second step, rule loading, the recipient ISs extract

the rule embedded in the shared fact and load it in their own rule bases. This

is accomplished by means of a special rule (i.e, a meta-rule, as it operates

on rules), which must be present in all recipient ISs, and which matches the

98


Figure 4.6: a) A graphical representation of the DJess Web of Inference Systems(WoIS); b) the two-step rule-sharing process: 1): sharing and 2) loading

destinations of the rule-embedding fact with the name of the IS on which it

is running; it then calls a special function, load-rule, to add the shared rule

to the local rule base. Meta-rules are nonetheless rules, and so they are under

complete control of the programmer and are not part of the DJess built-in

behavior. DJess provides just the mechanisms, i.e., the function load-rule and

the rule engine, for building arbitrarily complex policies for rule transferring,

and so an IS can filter incoming rules according to different criteria.

All rules behave in the same manner, whether they have been defined lo-

cally or have been sent from another IS; they are parsed and executed locally

by the engines, although they can act both on shared and private facts. In this

way, interpretations of shared facts can be encoded in rules, in terms of behav-

iors triggered by facts. Since DJess allows for rules to be spread throughout

the WoIS, this rule sharing mechanism facilitates the designer of the context-

aware and ubiquitous computing application in reaching and guaranteeing a

semantic uniformity across different devices.

4.3.3 The management of the WoIS

Every WoIS is supervised by a manager, which handles the registration and the

locating of ISs as they join or leave the WoIS. The use of a centralized WoIS

manager is the simplest solution for a name server, and it should not create

bottlenecks in the system, as we have assumed that in a typical ubiquitous

environment computation be mainly driven by user activity and that commu-

nication be based on broadband LANs, so the delays induced by a centralized

model are presumably not appreciable.

WoISs are distinguished by name, and a WoIS is created by launching the

WoIS manager specifying the WoIS name. The WoIS at this point is empty

99


and the manager waits for any IS to join; the manager maintains a list of the

members and one of the shared facts, both initially empty.

Every time an IS joins the WoIS, the manager adds the new member to the

members list, and sends it the current shared facts list. The new member then

asserts a special shared fact member which specifies the new member identity

and can be used by the other ISs to “sense” the presence of the new member.

When an IS leave a WoIS, it removes its member fact and the manager

remove the IS from the members list. Shared facts (apart from the member

fact) are not touched in the process, and if there are any ghost facts on the

leaving IS, they are migrated to another IS.

4.4 Related work on distributed inference systems

As regards the general data sharing functionality characterizing DJess, we

can relate our work to the Linda coordination model [Carriero and Gelern-

ter, 1989]; this represents one of the most relevant efforts to provide hetero-

geneous distributed components with data access and information exchange.

This is accomplished through what is called a tuple space, i.e., a common data

structure which allows agents to share and retrieve data (i.e., tuples) through

some simple pattern matching mechanisms.

In this case, the underlying model — to some extent similar to the black-

board model [Hayes-Roth, 1985, Nii, 1986] — conceives a global sharing of

any data visible by any agent accessing the tuple space. This idea, although

quite relevant for certain application domains, seems less than optimal when

it must be implemented in mobile and ubiquitous applications. In fact, in these

latter cases, devices (and data) are inherently distributed and realizing a cen-

tralized place where all data are perceived could be unfeasible; rather, it is

important to consider the concept of locality of information according to the

conceptual places where computation is needed and it is performed. In other

words, ubiquitous, context-aware and mobile applications require that not all

the information must be accessible by all agents, and that some mechanisms

be provided so that information production and access can be regulated by

taking into account chunks of information that is conceptually related. Ratio-

nales according to which information is to be separated and partitioned in lo-

cal and shared one can vary depending on the pertinent application scenario;

likewise, ways to modulate explicitly the perception of the shared information

100

4.4. RELATED WORK ON DISTRIBUTED INFERENCE SYSTEMS

have given rise to models and architectures that follow different paradigms.

The mechanisms that provide a separation of information may be accom-

plished by taking into account various approaches that may be best suited

according to the pertinent application scenario.

Some approaches are more topological oriented, that is, information is

shared not for all the agents populating the environment but only for some of

them according to either their physical or conceptual location. In Lime [Mur-

phy et al., 2001], for instance, each agent carries its own tuple space and

when agents reside on the same host, their tuples space are merged. In this

way, the information sharing is related to a specific place that is represented

by a node of the network where agents reside. Other approaches extend the

idea of topology-based information sharing to the concept of diffusion of infor-

mation through fields propagation. In particular, in TOTA middleware [Mamei

et al., 2003] the content of a tuple propagates through the nodes of a network

according to a rule that reflects the topological structure of the network of the

underlying physical infrastructure. In other cases, the propagation mechanism

is made richer by considering any topological layer that reflects meaningful

conceptual structures for the chosen application scenario (like in the MMASS

model [Bandini et al., 2002]). Some other approaches determine the access to

the shared information through a more organizational approach. In Agent Co-

ordination Context [Ricci et al., 2004], for instance, the access to the shared

information space is regulated by mechanisms of access control based on roles

and institutional policies of the organization.

On the other hand, the way DJess enables the modulation of how WoIS

members access and perceive the shared space is based on rules governing

code propagation. In this way, the designer does not have to adopt a spe-

cific policy beforehand but can define a multi-tiered tower of meta-rules that,

recursively, define the policy defining the composition of behaviors at each

inference system and how the behaviors propagate from IS to IS. Although

at a first glance DJess may seem similar to the Linda model — since both al-

low all agents to share a global common information space, the tuple space

and the shared working memory — there are some important difference. On

the one hand, in DJess no global memory structure really exists. The shared

working memory is a virtual space that is replicated in each system to make

inference efficiently local and the overall system more tolerant to temporary

or permanent faults of some member. On the other hand, in DJess it is possible

101


to provide each inference system with specific rules according to the specific

domain, without having to define beforehand a particular mechanism or ra-

tionale of modulation of the information access. This is made possible because

in DJess there is no real propagation of data, but rather data are shared and

available to all components that perceive and react to them differently accord-

ing to the rules they store in their rule base. Hence, the various mechanisms of

modulation of access to information are not imposed beforehand but depend

on how the application designers conceived the rules to be propagated in the

environment. This implements a form of flexibility because the programmer

of the context-aware application may choose one way of limiting information

access according to a specific context and accomplish it dynamically according

to the rules she decides to define for a specific device and to the way she de-

cides the rules should propagate within the web of inference systems. In other

words, data are shared and made potentially accessible to all the agents; but

the rules that each agent maintains in its knowledge base provide it with the

ability to access and process the information according to the specific applica-

tion needs.

Differently from the previously cited approaches, which mainly focus on

the sharing of data and leave application programmers to build the related

logics, in DJess the focus is on shaping the overall behavior of the ubiquitous

system starting from the shared data where the behavior of each component

is ruled according to the intentions of the designers of the overall system. For

this reason inference is a central concept in the DJess middleware and it could

not be otherwise since its core is one of the most wide-spread inference en-

gine to date. Although also other cited middlewares rely on quite powerful

forward-chaining inference capabilities (e.g., Lime), DJess permits also both

backward-chaining and pattern matching on negative conditions, both being

features quite valuable in a context-aware domain. Backward-chaining is quite

useful when there is a need to draw conclusions that are relevant to a cer-

tain goal and writing proper rules for each subgoal can be difficult [Russell

and Norvig, 1995]: when backward-chaining is employed, the programmer

does not have to explicitly write rules for all the subgoals and moreover she

does not have to worry about large amount of initial data (that is data given

from the outside, not inferred: a typical situation in ubiquitous domains) when

goals are quite well defined. Moreover, DJess — as an extension of Jess — has

the notion of negation as the non-existence of a fact called “negative condi-

102

4.4. RELATED WORK ON DISTRIBUTED INFERENCE SYSTEMS

tion”. A negative condition is an expression that succeeds if patterns in a rule

are not successfully matched. Through DJess, then, a programmer can express

non-monotonic reasoning rules [Apt and Bol, 1994] and in so doing she can

both be facilitated in expressing commonsense rules where these can grasp

more properly the user behavior and cope more flexibly with situations of in-

complete data, that is a condition that can be seen as structural of real open

systems like the ubiquitous ones.

Also other approaches encompass rule-based systems like in the Coopera-

tive Artefacts [Strohbach et al., 2004] and Sentient Object [Biegel and Cahill,

2004] model but there the focus is not on providing a general mechanism

to distribute dynamically behaviors (rules) to the agents spread in the envi-

ronment so that the agents may properly interpret the shared facts. Rather,

in these approaches rules have a scope of application to facts that is either

limited to the internal facts managed by each component or to facts which

are explicitly sent from one component to another or perceived by different

agents according to their proximity in the space. In other approaches, like the

previously cited Lime, the scope of the rules (reactions) of each agent in inter-

preting facts is limited to the facts (tuples) made shareable by all the agents

currently residing on the same host they moved to. In DJess, instead, the scope

of the rules of each inference system depends both on the antecedents of the

rules and on the facts that are available in the whole WoIS to which each IS

has joined. In this way, each agent behaves according to its internal logic as

well to the designer’s logics. These logics are conceptually modeled in terms

of rule propagation patterns within a WoIS, rather than only topologically.

In approach and aims, the closest works to DJess seem to be Dyna-

CLIPS [Cengeloglu et al., 1994] and DCLIPS [Amigoni et al., 1999]. They

are two different infrastructures for inferential code mobility and knowledge

exchange based on CLIPS [Giarratano, 1991] and used in multi-robot sys-

tems [Amigoni and Somalvico, 1998]. That notwithstanding, full and seam-

less integration with Java, the adoption of a pure generative communication

model, the transparent fact sharing and a more integrated rules propagation

mechanism make DJess quite different and more suitable for application do-

mains that must exhibit great openness and flexibility, like the ubiquitous com-

puting one.

103


4.5 Reconciling DJess and WOAD terms

At the end of this digression on the implementation details of the current

WOAD-compliant system that we have developed to evaluate the potentialities

of the WOAD framework, we briefly summarize the terminology mappings

that run between the DJess and the WOAD middleware layers of the software

architecture depicted in Fig. 3.9. In so doing, we can “raise” again the level of

abstraction and proceed to describe the WOAD language and its application

to a real work setting in Chapters 5 and 7, respectively, .

As short recapitulation, we then recall that a WoIS, namely a web of infer-ence systems (see Fig. 4.6, part (a)) is what currently implements the actual

deployment of a WOAD, namely a web of (electronic) documental artifacts.

As said in Section 4.2.1, WOAD transitors are implemented by DJess inferencesystems, while the fact space of a WOAD is implemented by an instance of

DJess shared working memory. The DJess functionality to share rules across

inference systems of the WoIS and through the shared working memory is ex-

ploited by the WOAD middleware to have conventions be transformed into

executable mechanisms. More specifically, WOAD convention-facts (see Chap-

ter 5) are rendered into DJess shared-rules, which the load-rule function can

transform in WOAD mechanisms, i.e., rules contained within the rule-sets of

transitors representing the code that can be executed during a MRA cycle (see

Section 4.2.2).

104

Chapter 5

L*WOAD: The WOAD language

The aim of the WOAD language (L*WOAD) is to provide the designer of a

web of coordinative documents with a means by which to express computable

mechanisms so that awareness information can be managed according to the

context. We also propose such language as a way to support designers in elicit-

ing and characterizing in a structured and sound manner the information that

within the WOAD framework is deemed relevant to support actors in using

their documents for coordinative aims.

L*WOAD can then be seen as a “notation” by which the designer1 can

construct the needed mechanisms that have to be executed by a technologi-

cal platform like that we have described in Chapter 4. In fact, L*WOAD acts

as “programming interface” that allows the designer to “program” awareness

provision mechanisms at a semantic level, without being concerned with the

peculiarities of a given programming language and corresponding virtual ma-

chine. Data and algorithmic structures that designers define at notational level

are rendered in executable constructs by an interpreter. This application ren-

ders the frame-like L*WOAD constructs [Nilsson, 1980] that we will see in

this Chapter into corresponding data structures and executable code that the

WOAD middleware (currently implemented on top of DJess) can manage and

execute (cf. Fig. 3.9).

As regards the main constructs, L*WOAD is derived by the model we out-

lined in Chapter 3 and by the basic choice to leave the set of constructs as

1In the sections regarding the language the ‘reference user’ is intended as a designer, i.e.,who is supposed to model the application domain at hand and conceives the mechanism andfunctionalities by which a computer-based system can support its intended “users”. This latteracceptation is used to refer to actors that use a documental system and a WOAD-compliantapplication to be supported in their cooperative activities.

105

CHAPTER 5. L*WOAD: THE WOAD LANGUAGE

minimal as possible: each L*WOAD construct contains parameters that endow

it with high expressive power and make it an atomic component that can be

flexibly combined into higher level components (e.g., macros).

The L*WOAD encompasses three basic constructs: facts, primitives and

mechanisms2. These are constructs to express data structures (facts), to de-

fine and manipulate them (primitives) and to either specify or characterize

the flow of execution (mechanisms).

In the following, we will outline the main characteristics of the language by

means of implementation-independent frame-like representation. The frame-

based level of description could be the only one a WOAD designer would

like to cope with. That notwithstanding, in order to give useful hints about

how such notational elements are rendered into actual data structures and

the operational semantics of an implemented middleware, we also express

the very same features in the current declarative and rule-based syntax.

By reading the passages in slanted italic type, the interested reader can get

some indications about the current implementation of the WOAD middleware

on top of the DJess platform. The reader not concerned with implementation

details can easily skip the DJess code written within boxes. Conversely, the

interested reader should also mind that the reported examples are almost for

every detail “running examples”, that is, their lines of code can also be man-

aged and executed by any WOAD transitor as they are, although they look

pretty “abstract” and human-readable.

5.1 L*WOAD Facts

The term fact is the historical name by which any kind of data is represented

in the declarative rule-based programming paradigm. Each fact represents a

single and coherent piece of information; moreover, since they can be struc-

tured at an arbitrary level of detail, they can also gather different pieces of

information that relate to a single phenomenon or concept to be represented

within a computational system. The whole information available within the

system can be hence seen as the ‘union set’ of all defined and instanced facts

within the system. L*WOAD facts are constructs used to express information

that must enjoy the following properties:

2These correspond to what in almost any rule-based language is called facts, functions andrules. Within our framework, we adopted slightly different names since they are associated toa specialized syntax and semantic.

106

5.1. L*WOAD FACTS

1. facts are expressive, i.e., capable of representing relevant aspects of both

contextual3 and relational information (i.e., “what” and “how-is-related-

to-what”), as well as conventional knowledge4. The latter is intended in

terms of symbolic and human-readable expressions representing “what-

does-it-mean-if. . . ” or “what-to-do-whenever. . . ” regarding the mean-

ings or the typical behaviors the users of a documental system intend ac-

cording to either the textual or environmental context (see Section 3.2).

Facts must therefore be capable of declaratively expressing both data a

program works with, and the algorithm this program applies to process

its data.

2. facts are sharable and manipulable within the fact space. The fact space

can be seen as a blackboard [Corkill, 1991]. Within this blackboard facts

have an independent existence of their sources (cf. the generative com-munication model [Gelernter, 1985, Carriero and Gelernter, 1989]) and

they are added, retracted and modified according both to correspond-

ing changes within either the documental system, or the environment in

which such system is deployed and used, and to the application of con-

ventions by which users make sense of these changes (cf. endogenous

and exogenous factors in Section 3.3)

3. facts are object of computational inference5 within the fact space. This

property refers to the possibility to draw new facts basing solely on what

is already represented in terms of facts.

The second and third properties will be outlined when we speak of prim-

itives and mechanisms, respectively (see Section 5.3). In the following, we

consider in more details the expressive power of facts.

L*WOAD facts are labeled and structured set of attribute-value couples (see

Fig. 5.1). A specific attribute-value couple is called a property of the fact. Prop-

erty attributes are unique within each fact and their values are usually typed.

The structure of a fact is expressed in terms of a template which represents

a generic category of the reference domain. Each template is uniquely identi-

fied, specifically by a label — i.e., its name — and the name of the fact space3For the sake of readableness from now on we use the terms ‘context’ and ‘contextual’ in the

twofold acceptation of context2 as characterized in Section 3.2.4In the following we use the terms data, information and knowledge pretty candidly, with

acceptations that, for our practical purposes, can be borrowed from the common sense.5The reader could refer to the footnote in Section 3.4.2 for the technical acceptation of such

term that we mean in this context.

107


it belongs to (web-name, in Fig. 5.1). The name of a fact template also denotes

the type of the information associated with any instance of the fact template.

When the attributes of these structures are assigned to some values, we speak

of instances of facts, or just facts. The difference between the class level and

the object level (i.e., between structures and instances) is straightforward also

at implementation level.

In our current implementation, WOAD-facts are rendered as DJess facts; theirstructures are syntactically rendered as DJess templates. The DJess middlewarerepresents facts in a LISP-like notation, i.e., as recursive list structures, whoseproperties are syntactically rendered as particular lists called slots, acting as la-beled fields. At slot definition, both types and default values can be specified:in particular, three value types are available: atoms (i.e., just sequences of sym-bols), integers and strings (i.e., sequences of alphanumeric symbols). Fact typesand properties can be defined through the deftemplate construct, by which tem-plates with an arbitrary number of slots can be created (see Fig. 5.3). Slots areused to access properties by their name, so that each fact is made analogous to amemory structure like records of traditional procedural programming languages.At instance time, when a fact of a certain type (i.e., with a certain template) isasserted, the middleware assigns the fact with a progressive number, acting asan ID that ensures uniqueness within a given fact space. Also the web-name andclassname slots are automatically filled in. The classname slot refers to the list ofall templates of which the asserted fact can be considered an extension. It hencerepresents the implementation of the Parent-fact property (discussed immediatelybelow), by which the full hierarchical chain that binds specific classes up to theirextended root is represented.

In the L*WOAD, the distinction between contextual, relational and con-

ventional information leads to a further WOAD-fact distinction into (a) entity-facts, (b) relation-facts and (c) convention-facts, (see Fig. 5.2). Each of these

kinds of fact can be seen as a specialization of the most general L*WOAD fact.

At definition time, the designer has to define a fact structure, i.e., a fact tem-plate, in terms of another one, so that the former inherits the structure of the

latter and this can be seen as the parent fact of the new one. This hierarchicalrelationship6 is explicitly represented by means of the Parent-Fact property.

This property allows designers to conceive mechanisms that recursively apply

6With the term ‘hierarchical relationship’ between classes of objects, we mean what is ex-pressed by an ‘is-a’ relationship, and hence something also equivalent to the concept of inheri-tance and generalization.

108

5.1. L*WOAD FACTS

Figure 5.1: The most general WOAD fact structure. Self-explicative attributes typesare indicated in the attribute column. The plus denotes a multiplicity possibly otherthan one

Figure 5.2: The conceptual hierarchy between very general WOAD facts and theirframework-specific extensions.

to facts, so as to implement relationship inheritance. By recursively applying

the ‘extension principle’, any domain-dependent fact can be defined as an ex-

tension of either entity-, relation- or convention-facts.

5.1.1 Entity-fact

Entity-facts are facts that express an attribute-value representation of an as-

pect of the state of the world in terms of the entities defined within the WOAD

model, i.e., namely resources and activities. As such, their most general rep-

resentation is still in terms of WOAD-fact, extending them with some domain

or application specific property (see Fig. 5.4).

For instance, in the current implementation of L*WOAD entity-facts are ren-dered as lists, i.e., as recursive structured sequences of characters delimited bybrackets. In Fig. 5.5 the interested reader can also see how fact templates aredefined by means of the deftemplate construct. Within such construct, theextends clause lets the designer define one deftemplate in terms of another.

109


Figure 5.3: DJess syntax for the definition of the WOAD-fact template. Language prop-erties are referred to template slots for the sake of comprehensibility.

For their generic definition, any resource and activity of a given domain

can be rendered as an entity-fact.

In the example in Fig. 5.5, the concept of ‘person’ has been associated tothe homonomous template that has been defined as specialization of the genericWOAD entity-fact template.

Besides all the templates that designers can define by themselves to rep-

resent any relevant aspect characterizing their application domain (e.g., per-

sons, cars, offices), the L*WOAD provides such designers with the templates of

three framework-specific and domain-independent entity-facts: the document-fact, the activity-fact and the awareness-fact, to render the concepts of docu-

mental artifact, activity and awareness information, respectively7.

Document-fact A document-fact is an entity-fact that represents both the

structure and the current content of a specific document. We will see in

Section 5.3 that the language provides a direct support both in defining

such templates and in keeping documents and corresponding document-

fact “synchronized” (by means of the share primitive). The WOAD

framework does not a-priori specify the structure of any document

possibly compounding the web: that would have limited the architec-

ture in its applicability to different documental domains. The document

structure can be detailed by a domain-dependent, or even application-

7The reader may note the correspondence with the specialization of the resource and activityconcepts introduced by the WOAD model. Document-fact represents the main kind of artifactsherein considered, i.e., documents; awareness-facts the main information; activity-facts justrepresent activities

110

5.1. L*WOAD FACTS

Figure 5.4: The general structure of an entity-fact. Possible extensions of the entity-fact structure into application-dependent templates are just hinted specifying ageneric designer-defined property.

Figure 5.5: Above, an example of DJess syntax for the definition of the entity-facttemplate. Below that, an example of fact definition: the person fact is defined asextension of the generic entity-fact.

dependent8, model that structures content as much as it needs for the

domain’s requirements9.

The WOAD document construct (see Fig. 5.6) encompasses (a) a name

8As said in Section 3.3, we distinguish between framework, domain and application level:e.g., between documental, hospital care and “ABC” Hospital, respectively.

9The current implementation requires such document model be specified by means of XMLfiles, that are fetched as input data by the sharing mechanisms (see Section 5.3.2).

111


property, (b) a description, (c) some access rights with reference to the

relationship between domain-specific roles and the activities of reading

and writing, (d) the kinds of WOAD-specific awareness information it

can provide, irrespective of the way it does it; (e) the content of the

document; and (f) a set of conventions of proper compilation and con-

sultation, expressed in terms of convention-facts (see Section 5.1.3). The

content attribute of the document-fact represents the informational con-

tent, i.e., the very data of the represented document: its inner structure

(e.g., tree-like, strictly hierarchical or just a body of symbols) depends

on the application domain.

In the current WOAD implementation the content of a document is rep-resented by a set of nested facts, so that also the very single fields of thedocument are rendered as fact slots that can be referred within the condi-tion elements of either some convention-fact or mechanisms.

The content attribute is updated by means of WOAD mechanisms in their

content partition (see Section 5.3.1 for details).

From the implementation point of view, the hierarchical structure in whicha documental system is conceived can be expressed by means of either spe-cific entity-facts reporting for each document its name and the list of itsparents, or specific relation-facts that put in part-of relationship binders,documents, their sections and so on, till the smallest kind of document thatis rendered by means of a document-fact. If a certain document can be seenas the “leaf” of a hierarchical tree structure, the classname property, whichis automatically filled in by the middleware, can represent its relationshipswith the rest of the structured documental system.

Awareness-fact An awareness-fact represents an awareness message that is

generated depending on some contextual condition and provided for ac-

tors’ consumption at artifact level. Each awareness-fact refers to a given

class of awareness information and can be seen as an instance of that

class (awareness types will be treated in Section 5.2). From the tem-

plate point of view, an awareness-fact is a entity-fact with three prop-

erties (see Fig. 5.7): a label termed awareness-type, which corresponds

to one type of awareness from a finite set of WOAD-specific awareness

types10, whose semantics will be outlined in Section 5.2.1; a content

10That set can be either extended or reduced according to some domain-dependent rationale

112

5.1. L*WOAD FACTS

Figure 5.6: The general structure of a document-fact. Some properties inherited bythe entity-fact (e.g., description) are reported for the sake of comprehensibility.

attribute, which, at instance level, corresponds to the piece of informa-

tion actors should be aware-of; and a source attribute that, at instance

level, encompasses all those facts that constitute the “reason” for their at-

tention, the source of the awareness information. Awareness provision,

i.e., assertion and modification of proper instances of awareness-facts,

is managed within a dedicated partition within the WOAD mechanisms

(see Section 5.3.1).

Figure 5.7: The general structure of a awareness-fact.

Activity-fact To reflect the distinction between documental and work ac-

113


tivities, also at language level we distinguish between a documental-

activity-fact (in the following d-Activity-fact) and a work-activity-fact

(in the following w-Activity-fact). An activity-fact represents those as-

pects of activities that is necessary to consider in the conception of a

web of documental artifacts. Like in the case of awareness information,

the framework encompasses a purposely paradigmatic set of aspects that

can be further extended or limited at design time if the domain complex-

ity requires it.

The WOAD activity construct (see Fig. 5.8) considers a work activity(and the corresponding data structure) as described by a set of prop-

erties expressing its name, its description, its internal state; the explicit

indication of who is responsible for its execution11; which is its priority12;

the list of its preconditions and its effects; and conventions regarding work

execution and state transition (see below).

Documental activities are described by a slightly different set of proper-

ties: besides a name and a description, they are also associated with the

explicit indication of who has executed them (the executor) and when(a time stamp, that is obviously significative only at instance level); and

with the lists of the informational resources involved either as input or

output. Also d-activity-facts are characterized in terms of related conven-tions of “right compilation”.

The assumptions underlying the simplifications of such way to represent

activities regard what we said of activities speaking of the WOAD model

(see Section 3.3.1): i.e., the fact that work activities are in some way in-

stitutionally conceived as task-oriented abstractions of the practices oc-

curring in the field of work; and that they can contain documental activ-

ities (in Section 5.1.2 a specific relationship is presented to express such

inclusion). For this reason, we deem necessary to associate each work

activity with a responsible actor and consider that inputs and outputs

(in any case, some documental information as defined in Section 3.3.2)

can be “inherited” from the “contained” document-activities.

On the other hand, documental activities are considered pretty atomic

11This information can be related either to institutional roles or specific actors working inthe cooperative arrangement. For this reason the L*WOAD does not explicitly encompass arole-fact, which can be defined at application-level if necessary.

12This information can even be as simple as a binary indication: routine, urgency.

114

5.1. L*WOAD FACTS

and strictly bound to the documents’ content: either a data is read

as input or written as output. For this reason, we do not consider

necessary to also describe them in terms of preconditions and post-

conditions, give them a priority, an above all, associate them with some

framework-specific internal state structure, which can be defined as

domain-dependent extension of the generic WOAD structure. When a

document (or even a single field of it, depending on what is considered

input/output for a certain transactional documental task) is either read

or written, the corresponding d-activity-fact is instantiated and the ex-

ecutor and time-stamp attributes completed by the software platform.

In order to alleviate the modelling task of the designer, in the current im-plementation d-activity-facts templates are automatically created as fromthe parsing of the document structure. In this way, the designer has onlyto conceive appropriate work-activity-facts for the application domain athand and then refer the latter with the d-activity-facts according to thedocumental use occurring within each work activity.

Figure 5.8: a) The general structure of a work-activity-fact. b) The general structureof a documental-activity-fact. Properties inherited by parent facts (e.g., name anddescription) are reported for sake of completeness.

For work activities, conversely, we propose a particular model of activity

115


internal state13 that is compatible with our requirements of awareness

provision within the documental domain (see Fig. 5.9). Our proposal is

indeed intended as a trade-off between the necessity to capture the rel-

evant aspects of activities in a given domain and still reflect the typical

loose extent the documental activities of reading and writing can be cor-

related to work activities. Our studies have given us some evidence that

where documents are compiled and accessed outside rigid work-flow

patterns of document use, to correlate too closely data-driven events

with activity transitions can be risky. Likewise, to conceive detailed state

automata for activities that are supported by documental artifacts could

paradoxically reveal itself just like relying on a too simplistic model of

the work practices at hand for the practical inapplicability of the corre-

sponding automata14. Moreover, the WOAD proposal is also tuned for

the provision of awareness information regarding, among other things,

what is happening, at least with regard to some specific documental

data. As a result of these compromises, the WOAD generic automata

encompasses five states:

1. ready, when a certain activity template has been defined for a given

domain but it has not been instantiated yet.

2. enabled, when all the activity’s preconditions are true.

3. inhibited, when at least one of its preconditions is false, e.g.,

that expressing that a conflicting dependency with another higher-

priority activity is still present.

4. executing, when it can be inferred that an instance of an activity

has been being executed from the content of the fact space and the

model of the domain activities.

5. completed, when all the effects (i.e.,post-conditions) hold true, af-

ter that an activity has been in execution.

6. idle, a sort of pause of “parking” state, that an activity assumes af-

ter some time (to be defined) that no event in the fact space can be

13The dynamic aspects pertaining to the state transitions are left at design time, as specifiedbelow.

14For example, the state of being interrupted, that could be modeled by means of well-timedtime-outs, is unsuitable in many situations for domains where conventions on tasks schedulingare usually loosely defined and the status of the work is usually only indirectly derived fromdata produced and consumed.

116

5.1. L*WOAD FACTS

associated to it. The idle state is also proposed for all those situa-

tions that make being in some other state inconsistent.

Figure 5.9: The awareness-provision oriented finite state automata for WOAD activi-ties.

The transition functions of the finite state automata regarding the activ-

ity at hand are expressed in terms of work-related conventions into the

corresponding attribute of the w-activity-fact. These conventions make

the activity transition from a state to another. Activity preconditions,

by their definition, characterize15 the convention that triggers the en-abling of the activity: when preconditions are all true, then the activity

goes into the enabled state. Likewise, effects characterize the conven-

tion making the activity switch into the completed state: when effects

are true, then the activity changes into the completed state. Other tran-

sitions are characterized by contextual conditions occurring and being

represented within the fact space. Specifically, the transition into the ex-ecuting state depends on the activation (in terms of mere instancing) of

the d-activity-facts that belong to the w-activity-fact (see Section 5.1.2).

According to the domain- or application-dependent requirements, the

designer can conceive activity models that encompass more complex fi-

nite state automata. Complexity can imply either more states or a sparser

flow relation implying less degrees of freedom. The definition of the

flow relation requires the designer, for each kind of activity, express an

explicit correlation between contextual events — either on document-

fact, other contextual entity-fact or on temporal events — and the state

transition function of that activity into a declarative and WOAD com-

pliant form (i.e., into convention-facts). In Section 5.3.2, we will see

that activity transitions are triggered by specific partitions of the WOAD

15As it will be clear in Section 5.1.3, they constitute the if-side part of the correspondingconvention-fact.

117


mechanisms.

5.1.2 Relation-facts

.

Relation-facts are WOAD-facts that represent some binary relationship be-

tween two facts. Besides the attributes that they inherit from the WOAD-fact

template (i.e., those attributes that are common to all WOAD facts), relation-

facts are also characterized by a source, a target and a level attribute (see

Fig. 5.10). The source attribute indicates the fact that is in some relationship

with the target fact. The relation-level specifies whether the relationship is ei-

ther between classes or instances.

Figure 5.10: The general structure of a relation-fact. Extensions by with user-definedproperties are indicated as optional properties.

The relation-fact can express three semantically different kinds of relation-

ships.

Relationships between data As said in Section 3.3.2, WOAD distinguishes

between relationships and correlations. As a reminder, correlations are

118

5.1. L*WOAD FACTS

Figure 5.11: DJess syntax for the definition of a relation-fact template.

framework-specific and domain-independent relationship between ei-

ther elements, sections or entire document-facts that pertain to the same

or correlated aspects of what is documented (see Section 3.3.3). With re-lationship, we refer to the most generic concept of “association between

different pieces of information”, that obviously is significant at either

domain or application level. At application level, these associations can

occur either at class-level or at instance level: these different levels are

denoted by the relation-level property.

An example of the former level is given by the domain-dependent rela-

tionship “caring” between physicians (sources of the relationship) and

“patients” (targets of the relationship). The instantiation of such caring

relationship could, for example, occur between Ms. Smith (a physician)

and Mr. Jones (a patient).

Relationships between data and activities In Section 3.3.1 and then also in

Section 5.1.1, we said data can be put in relationship with both documen-tal activities — which directly write or read them — and work activities,which “include” the former ones and are part and parcel of any other

activity characterizing the work domain at hand.

If the designer needs to have input and output relationships be explicitwithin the fact space since she needs to refer to this kind of relationship forthe awareness-provision’s sake, she can have automatically created a num-ber of corresponding relationships relating specific data and work-activity-facts. These are derived by the L*WOAD interpreter from the input andoutput properties of the d-activity-facts that belong to the work activitiesconsidered. The designer can moreover specify at which level of granularityshe needs the rendering process to be applied to, according to the inter-nal structure of the content attribute of the d-activity-facts (e.g., modules,sections, paragraphs, even single fields).

119


For the semantics of the input/output relationships that can be rendered

through the relation-fact construct, the reader can refer to Section 3.3.2.

Relationships between activities As seen in Section 3.3.4, in the literature,

there are a number of approaches to the specification of inter-activity

relationships, whose application to a specific domain depends on both

the degree of detail needed and the very characteristics of the domain at

hand. Between the two main levels of activity proposed in Section 3.3.1,

we also propose a predefined belongs-to relationship between work ac-

tivities and documental activities. This relationship can be used to in-

dicate whether a documental activities is part of a more general work

activity, i.e., whether the latter contains, both logically and temporally,

the former.

Likewise to the case of the input/output explicitation, also other attributesof activities can be explicitly rendered into relation-facts. In particular, re-lationships representing dependencies among work activities can be syntac-tically derived from the pre-condition and effect attributes that two activ-ities share on common resources if the designer needs these be representedas single relation-facts.

5.1.3 Convention-facts

Convention-facts represent conventions applied in a certain application do-

main (see Fig. 5.12). They are represented in terms of condition-driven (i.e.,

if-then) sets of actions that can be executed according to some symbolic ex-

pression of context. Any convention-fact is a WOAD-fact that is characterized

by the attributes condition and action. Conditions are conditional elements re-

garding either the existence of some facts within the fact space or, more specif-

ically, some condition over these facts’ values. Actions refer to a sequence of

WOAD primitives that are transactionally executed to change the fact space

content. Conventions are made computable (i.e., executable, applicable at the

fact space content) when their conditions and actions are embedded, respec-

tively, in the antecedent and consequent attribute of WOAD mechanisms (see

next section).

In the current implementation of the L*WOAD, the convention-fact templateencompasses action and condition slots, that contain the code that will be ren-dered in a regular and activatable rule that DJess-based transitors can select and

120

5.2. INSIDE THE AWARENESS-FACT

execute (see Fig. 5.13): the latter represent WOAD mechanisms. The conditionslots contain conditional elements: these are either patterns or logical expres-sions. The formers are partial descriptions of fact templates or entity-fact withsome unbound variables: patterns are said to be true (or verified) if they arematched by some WOAD-facts that have been asserted into the fact space. Withthe term logical expression, we mean an expression in propositional logic whereit is evaluated some mathematical relationship upon the variables bounded toentity-facts. Also a concerns slot (actually a multislot, since it can contain moreobjects) is encompassed in the convention-fact structure: this is automaticallyfilled by the middleware with a reference to all the facts that are referred towithin the rule, i.e. to all the entities the convention applies to or is about. Thisallows to have rules that can carry out inference also on other rules. In this way,the designer can also conceive and have applied sort of meta-rules, that treat exe-cutable rules as any other kind of fact and apply to them according to what theseare concerned with.

Figure 5.12: The general structure of a convention-fact. Attribute type conventionsare explained in the implementative passage on convention-facts.

5.2 Inside the awareness-fact

The WOAD framework is intended to support actors that use a documental

system in making sense of what they read for coordinative purposes and in

producing information, while being aware of the fact their data will also be

121


Figure 5.13: DJess syntax for the definition of a WOAD convention-fact template asextension of the shared-rule template (see Section 4.3.2).

used for coordinative reasons. The way this support is guaranteed is by means

of the provision of proper awareness information (see Section 1.2) about both

conventions on work practices and documental practices. Within the WOAD

framework, the designer of such a supportive system is provided with a model

and a language by which to compose mechanisms that express those conven-

tions and make them computable bunches of procedural knowledge whose ap-

plication is both data- and context-driven16. Another basic idea of the frame-

work is to consider that such awareness information could be provided by

means of the very same artifacts compounding the web of coordinative docu-

ments used by actors to cooperate with each other. For this reason, the WOAD

language also encompasses predefined mechanisms to create and maintain a

bound between documental artifacts and their factual representation.

In this brief summarization, we have so far followed the path envisioned

in [Gutwin and Greenberg, 1997] backwards: in fact we have considered (a)

how to present awareness information, i.e., by means of documental artifacts;

(b) how to get that information, i.e., from the context2; (c) when to present

it, i.e., by means of conventional mechanisms that are both malleable and

linkable (see Section 1.3.1). We have now to determine “what people need to

know about others in the [same documental] workspace” [Gutwin and Green-

berg, 1997]. That is, to determine, or at least circumscribe the content, the

what (cf. Section 1.2.1) of the awareness-fact construct.

In Section 1.2.1 we have reported that a number of classifications have

16We even saw in Section 3.2 that both aspects can be harked back to a more comprehensiveacceptation of the term “context”.

122


been provided to be applied in different settings with various degree of gen-

eralization. From the most generic point of view, awareness deals with tak-

ing heed of “what is happening with another person, and [. . . ] where it

is happening”, i.e., with the hic-et-nunc17 dimension of cooperative work

(cf.e.g., [Gutwin and Greenberg, 2002]). In addition to that, thanks to the

concepts of convention and of mechanism that make it computable, aware-

ness information can be provided to actors with an explicit reference to the

context2. We can therefore distinguish between awareness aspects that deal

with either textual context or working context, documents and activities.

That said, any generalizing approach can be useful to detect common fea-

tures and hence extract similar requirements but one should not overlook the

domain specificity of awareness information: much of what an actor needs toknow about others heavily depends on the application domain: we agree that

“the exact information requirements can only be determined by conducting a

task analysis” [Gutwin and Greenberg, 1997].

In accomplishing our case study, we have collected the awareness informa-

tion requirements of actors involved both by interpreting what they did and

said in the light of some selected awareness aspects and by explicitly probing

them during the interview with some “key questions” related to those aspects

(see Fig. 5.14).

The questions and answers that we tried to collect in observing as actors

coordinate with each other in the real cooperative arrangements of our stud-

ies, have led to draw up a list of “kinds of awareness”. This list is far from being

comprehensive of all the nuances that could be made explicit in a specific do-

main characterization, but rather it is the result of a comparison between a

literature survey and what we saw practitioners from our field studies have

explicitly claimed are their awareness needs.

5.2.1 WOAD awareness types

Before characterizing each WOAD awareness type — i.e., what can be re-

ported in the corresponding attribute of the awareness-facts the designer de-

fines for the application domain at hand — we refer them to the context2

characterization so as to give the reader the first flavor of our terminology.

Browsing, inquiring, explanatory and alerting awareness refer to textual con-

text, more precisely to documental content that has been previously written

17A Latin expression for “here and now”.

123


Figure 5.14: Aspects of document-based awareness and related questions. Adaptedfrom [Gutwin and Greenberg, 1997].

124


within some documental activity. Provisionality, inconsistency and amendingawareness refer to textual content that is being written. Accounting awareness

is about work accomplished in the past, while coordination, enabling, inhibi-tion and reminding awareness regard work that actors are to accomplish in the

future.

In the following enumeration, we have associated each kind of awareness

with a particular and informal semantics. We intend those typologies as a sort

of “suggestion” that the computational system could convey to actors in pro-

moting awareness, irrespective of the very way the presentation/interaction

layer of the software stack architecture reported in Fig. 3.9 renders such nu-

ances in terms of either particular affordances or representational means (e.g.,

colors, highlighting, pop-up boxes and the like).

• Textual Context (in the past)

Browsing awareness : “mind that you can follow some links from this”This kind of awareness can be provided when the relationships18

that have a certain textual item (e.g., a content entry, a whole pas-

sage) as either their source or target can trigger mechanisms whose

aim is to have the actor gaining access to the textual item at hand

become aware that she can follow some links from that textual item

to a correlated one. We notice that such kind of awareness type is

provided by all the web browser applications, usually just by chang-

ing the font type, color and style of the word or item that indicates

the access to the hyperlinked resource.

Inquiring awareness : “mind that you can know more about this (butdon’t know exactly how)” This kind of awareness can be provided

when current relationships can trigger mechanisms whose aim is

to have the actor become aware that she can know more about

a certain content entry or passage but no further particular hint

is provided, so as to stimulate some inquiry. This case is different

from the previous, the browsing awareness, since in that case also

some additional resource, in terms of one or more links to follow, is

provided. So, this is a sort of vaguer and underspecified awareness

18Such relationships, in this case and in the following ones, can be drawn either at definitiontime, i.e., at schema level, by the designer between items of the documental structure; or atrun-time, i.e., at instance level, by the application users, between content items, i.e. data onthe documental artifact. On this point, please refer to Section 7.2.

125


that can be conveyed whenever further details are lacking. This can

happen because the person who filled in the item first did not want

or just could not provide any linked entity, but that notwithstanding

she needed to call for the attention of who would read that item

later, e.g., by relying on some implicit and tacit convention on that

item.

Explanatory awareness : “mind that there is a reason for this informa-tion” This kind of awareness can be provided when the existing

relationships can trigger mechanisms whose aim is to make the ac-

tor aware that she can know about the reason for a certain textual

item: e.g., why it was written or for which aim. This kind of aware-

ness can be also provided as outcome of mechanisms whose aim

is to provide actors with some additional motivation for fostering

commitment to some assigned task.

Alerting awareness : “mind that you have to check something about this”This kind of awareness can be provided when the existing relation-

ships between data and some other contextual condition can trig-

ger mechanisms whose aim is to make the actor aware that there is

something (that can be purposely left underspecified) that must be

checked about what she is reading or writing. The difference with

the inquiring awareness is that in the previous case it is indicated

an “opportunity of further investigation”, especially pointed out by

the compiler. In this case, instead, it is indicated the need to check

something since things are not going as expected (obviously with

respect to some convention). The purposely underspecification of

this kind of alert is conceived to find application in domains char-

acterized by openness, ambiguity and unpredictability. To give two

simple instances: let us consider the case in which the convention

of a hospital ward states that whenever the temperature of a pa-

tient is higher than forty degrees, an alert should be raised to the

accountable nurse: this case is about alerting awareness for “ab-

solute conditions”. Conversely, let us consider a “subtler” conven-

tion about “relative conditions”: such convention would state that

an alert should be raised whenever a certain vital sign, which has

been previously inserted into the documental system without rais-

ing particular warning since under the contextual conditions it was

126


negligible, becomes serious under some other conditions. The doc-

tors we interviewed during our field studies gave us the example

of operated inpatients, whose low blood pressure is normal unlessand until also signs of an anaemia show up, when it could be an

indication of internal hemorrhage.

• Textual Context (present)

Provisionality awareness : “mind that what you are reading/writing isstill provisional” This kind of awareness can be provided accord-

ing to conventions by which, in a given cooperative arrangement,

either data are consolidated or committed to some official reposi-

tory. Or alternatively, according to conventions by which data are

purposely conveyed as still provisional and pertaining to an unfin-

ished job19. If data are written or read after the application of the

latter conventions or just before the committing conventions are

applied, then corresponding mechanisms can be triggered to make

the writing or reading actor aware that what he is working with is

still provisional. As regards this kind of awareness, the most signifi-

cant case is when committing conventions have been only partially

or unsoundly applied by actors that meant to make then consoli-

dated.

Inconsistency awareness “mind that you have to check this, somethingcan be wrong with it” This kind of awareness can be provided ac-

cording to either some formal data representation or more local

conventions by which data are considered lacking in consistency

with respect to their type or with respect to other data previously

recorded in the documental system, respectively. In the former case,

inconsistency awareness can regard body temperature data that are

higher than fifty degrees (i.e., an impossible physical condition), or

dates of scheduled examinations earlier than today’s date and sim-

ilar cases concerning all the definition of a data type in a given ap-

plication domain. In the latter case, inconsistency can regard more

abstract aspects of an application domain, like that between some

drug administration with some particular disease or allergy, or be-

tween a patient-centered and some work-related condition (e.g. a19On the requirement that data could be explicitly conveyed as still transitory or informal,

the interested reader can refer to [Hardstone et al., 2004].

127


pregnant woman scheduled for a C.A.T. examination, or a meat-

based meal ordered for a vegetarian inpatient). The point that dif-

ferentiates this kind of awareness and the following, is also that

inconsistency awareness does not necessarily require an amend-

ment, since actors can anyway find a reason to cope with a partial

inconsistent state of the world, or even to supersede the model by

which a sound situation is fallaciously considered inconsistent.

Amending awareness : “mind that you have to check this, and correct iteither” This kind of awareness can be provided according to either

some formal data model or more local conventions by which data

are considered mistakes with respect to their type or data represen-

tation. This case is slightly different from the former, in that data

that the actor is filling in result in syntactic mistakes, like a date

where it is supposed to be filled in a name, an e-mail address that

is filled in without the at sign (‘@’), or even a tax number field that

is empty (where a predefined ‘not available’ value is expected for

those cases in which such number cannot be timely filled in). Ac-

cording to a foundation tenet of the WOAD framework, we prefer

limit the direct amending intervention by means of the computa-

tional system itself and prefer speaking of proper “warning” mes-

sages that are raised by some awareness-providing mechanisms ac-

cording to the constraints that are imposed to data within a certain

documental system.

• Work Context (in the past)

Accounting awareness : “mind that person X did (wrote) this” This

awareness information is provided by mechanisms that access to

the data stored within the d-activity-facts, regarding both who did

something (or was responsible for, in the case of work activities)

and when she did it. The provision of such information can be ex-

plicitly requested by the actor currently consulting the documenta-

tion, e.g., by accessing a sort of history or log of updates for a cer-

tain data field; or automatically provided by mechanisms that are

triggered by some contextual condition. According to the degree of

granularity of the work context representation, such awareness in-

formation can be characterized also in terms of other contextual in-

128


formation besides merely accountability and time: e.g., which was

the activity that enabled or triggered the record, where it has been

accomplished, whether it is traceable back to some routinary task

or to some handling of an exception, and the like. This kind of

awareness thus relates to the requirement to facilitate the unpack-

ing of the context of production of a certain documental value. For

instance, a convention of a hospital ward could state that if a cer-

tain item has been recorded by a nurse far later than the scheduled

end of her work-shift, this could mean that it refers to a serious

emergency handling and also that recorded items should be taken

with some caution.

• Work Context (in the future)

Enabling awareness : “mind that you can do that” This awareness in-

formation can be provided whenever an activity-fact has all its pre-

conditions made true by the current context, i.e., the current con-

tent of the fact space, that is whenever some activity convention

has triggered an activity to switch to state “enabled”. Obviously,

in order to prevent a clear problem of information overload (see

e.g., Section 7.2.4), only those activities that are very specific to a

given situation could be suggested to actors for commencement,

i.e. activities that are fine-grainedly characterized in terms of pre-

conditions.

Inhibition awareness : “mind that you could not do that” This aware-

ness information is obviously the opposite of the previous one: it

can be provided whenever an activity-fact has at least one of its

preconditions made false by the current content of the fact space,

i.e., whenever some activity convention has triggered an activity

to switch to state “inhibited”. This can happen whenever a con-

flicting activity is in execution or for a number of other reasons we

have briefly outlined in Section 3.3.4. Also in this case, the designer

has to cope with possible nagging warnings about what the actor

can not do at a given time. In order to prevent those cases to hap-

pen, such awareness information could be provided to actors only

when they are actually providing the computational system with ev-

idences that they are executing an inhibited activity. In those cases,

129


in order to have actors get all the information necessary to decide

whether to “roll back” to other licit activities or to persist in the

inhibited one, the system could also make explicit the conditions

that are not satisfied and that made unapplicable the activity at

hand, by conveying the corresponding information defined in the

source and condition properties of the awareness-fact and its appliedconvention-fact, respectively.

Reminding awareness : “mind that you are supposed to do somethingabout this” This kind of awareness information can be provided

either to convey a slightly stronger indication on a to-do activity

than enabling awareness. In fact, reminding awareness can be con-

veyed to point out that some task should be executed, rather that

could be executed. Alternatively, such awareness information can

be used to, namely, remind some specific actor or role that it is due

time for the execution (or completion) of a previously scheduled

task. Since in the activity model proposed within the WOAD frame-

work there is not a strict characterization of the temporal aspects

(see Section 3.3.4 for details), mechanisms providing awareness on

things to be reminded must be based on some domain dependent

specification — e.g., the definition of concepts like “diagnostic ex-

amination” that are characterized in terms of scheduled time —

and some computational capability to feed temporal information

into the fact space.

Coordination awareness : “mind that others rely on the fact you dothat” This awareness information can be provided by mechanisms

aiming at making actors aware of some activity interdependency

and hence at prompting them to actively manage it. Such mecha-

nisms could be sensitive to conditions related to either sequential

activities that must “wait” until some other has been accomplished,

thus keeping resources underutilized and practitioners waste their

precious time. Or to some w-activity-fact whose internal state has

been set to “idle” after some time-out occurred. The corresponding

awareness could be conveyed in order to make the actors involved

in the “blocking” activities feel committed and determined in sup-

porting the dependent colleagues.

130

5.3. L*WOAD PRIMITIVES AND MECHANISMS

5.3 L*WOAD Primitives and Mechanisms

A mechanism specifies when some primitives are to be executed and how they

are to be combined together so that the latter can manipulate the fact space

according to the context, the user needs and the awareness provision require-

ments.

L*WOAD mechanisms realize the basic interactions occurring between the

model’s components (namely actors, documents, fact space and transitors):

(a) share (and unshare) a document within the fact space; (b) add an infor-

mation into the fact space (c) retract an information (d) modify an informa-

tion within the fact space (e) provide awareness information to actors (see

Fig. 5.15).

Figure 5.15: The general mechanisms enabling interactions among the model’s com-ponents: from left to right, the generic actor, the generic document, the fact spaceand the generic transitor.

L*WOAD mechanisms are conditional mechanisms that are applied only

when some conditions are verified, much like are rules within the rule-based

programming paradigm20. Consequently, all WOAD mechanisms are com-

posed of two parts: an antecedent (an if-side) and a consequent (a then-side),

bound together by a strict causal relationship like cause and effect. The an-

tecedent expresses all the conditions that must be true — i.e., occur in the en-

vironment, and be mirrored in proper representations within the fact space —

for the mechanism to be applied. Whenever all the conditional elements of a

mechanism are true, then the consequent side of the mechanism can be ap-

plied by some transitor.

The consequent side contains a number of primitives by which to act ei-

ther on the web of artifacts or the fact space. The execution of mechanisms

20L*WOAD mechanisms are rendered as activatable rules within the rule sets of transitors.This equivalence and the fact that mechanisms/rules are conditional executable constructs hasan important implication. In fact, the designer does not have to worry about the time — withinthe control flow of its application — in which those mechanisms are to apply, but she has onlyto define all the conditions that can trigger the mechanism computation at the right time.

131


Figure 5.16: Mechanisms can abstract contextual data from documents and vice-versa, can inform documents of contextual elements

makes the fact space (its content) transition from a state S1 to a new state S2

as a function of S1. Moreover, since the fact space also contains a declarative

representation of the context in which documents are used in a cooperative

setting, mechanisms can produce facts describing the context at a certain de-

scription level by “deductively” deriving the latter from facts that describe it

at a different level: for example, mechanisms can be used to derive a more

abstract and domain level representation of context (e.g., “it’s lunchtime”)

from a data- and document-dependent level one (e.g., “it’s twelve o’clock” or

“the lunch serving checkbox is ticked off on the schedule sheet”, respectively).

Obviously, also the opposite holds true (see Fig. 5.16).

The WOAD framework provides designers with a generic mechanism tem-

plate by which to create any domain-specific mechanism (see Fig. 5.17), as

well as with some predefined mechanisms that are associated each with a spe-

cific primitive .

5.3.1 The generic mechanism template

The generic mechanism is characterized by four attributes (see Fig. 5.17): a

name, a description, an antecedent side and a consequent side. Which condi-

tional elements are expressed within the antecedent side is up to the appli-

cation designer according to the domain requirement and to the application

logic. The consequent side is further structured into three partitions; parti-

tions can be seen as sets of primitives that can be empty, except one in every

mechanism.

Each mechanism encompasses (a) a content partition (b) a work context

132


Figure 5.17: The general structure of a WOAD mechanism.

partition (c) an awareness partition. In these partitions, content transforma-

tion, work context characterization and awareness provision are considered,

respectively. This template suggests designers how to structure the design of

a WOAD mechanism and suggests them to divide concerns regarding either

document, work context or awareness “management”, respectively, by prop-

erly gathering WOAD primitives. Once that the designer has defined some

convention-fact within the convention property of the document-facts and

activity-facts that describe the work arrangement at hand, she has already

got sets of conditions and actions (i.e., primitives) to reallocate in some ex-

ecutable mechanism: conditions will characterize the antecedent property of

the mechanism, while the actions will be allocated in the proper partition ac-

cording to the type of convention.

The WOAD middleware also provides a way to automatically generate a set ofmechanisms in which each gathers different conventions that have the same con-

ditions but differ for their action side. In this way, a document-, an activity- andan awareness-related convention that are sensitive to the same condition, e.g.,

133


“it’s noon”, would be rendered into an activatable mechanisms, whose antecedentwould only contain the condition “it’s noon” and whose consequent would gatherall the convention-facts’ actions, each allocated in the proper partition (the con-tent, work-context and awareness partitions, respectively. This is accomplished bymeans of the spread primitive described in Section 5.3.2.

Before going into the details of WOAD primitives and predefined mecha-

nisms that make their application context-aware, we spend some word about

some aspects designers should cope with about the three different partitions

of mechanism consequent.

Content partition Within the content partition, mechanism designers should

concern about the determination of new values for the properties of the

content structure of a document. Documents can be seen as the output

interfaces of the overall WOAD system21 and hence through documents

the system can either provide, suggest, or propose actors with values

that could be used within a document. These values are derived from the

evaluation of arbitrarily complex functions contained in the consequent

part of the mechanism and their insertion be triggered by arbitrarily lay-

ered contextual conditions (i.e., conditions pertaining to different levels

of context description).

Primitives (specifically, from modification mechanisms, see

Section5.3.222) can be used to process data in order to produce

other documental data with some degree of reliability. Examples of

“content transformation” managed within the content structure can be

taken from the production of ‘copy values’ replicated across multiple

documents when some correlation for replicated data exists or the

production of new data by mathematical derivation like data processed

within a spreadsheet.

When a document-data content is modified as consequence of an output ofa d-activity-fact, the middleware automatically insert a time-stamp in thecorresponding slot of the instance fact

Work Context partition The work context partition is where the mechanism

21In the following, with ‘WOAD system’ we intend any implemented WOAD-compliant com-putational system encompassing a set of transitors sharing the fact space as their commonworking memory.

22The reader should mind that new data to a document are not added to the fact spacethrough an assertion, but rather through the modification of document-facts.

134


designers can explicitly manage activities and hence define, assert and

modify activity-facts, both work and documental ones. In this partition

of the mechanism, the system tracks the status of the current context

into activity-facts and keeps those facts up-to-date accordingly. In the

work context partition, designers should gather primitives so as to fol-

low the current status of the work: this means to track both choices and

decisions made by actors in the field of work and to consequently up-

date the current status of the corresponding activity-facts, on the base

of data actors produce or access. The antecedent side of the mechanism

by which “work is followed” would be also sensitive to data regarding

agendas and work schedules, to data-activity and inter-activity relation-

ships, to entity-facts representing the past flow of work and possibly to

entity-fact acting as time-stamp.

The track of which activity is going on would be carried out, on the one

hand, on the basis of a sort of guessing from data produced and ac-

cessed and a more or less fine-grained process schema of work activities

correlated with documental ones: e.g., which data are input or output

of an activity, which precondition is currently true and which false. On

the other hand, work tracking can be done in virtue of an explicit dec-

laration of actors about what they are currently doing or what they will

do next, which they possibly state on artifacts that specifically employed

to track the status of the work (e.g., to-do lists, work schedules, shared

agendas).

The reader should also mind that work-following is not equivalent to

proposing a structured flow of work, but just to “interpreting” what is

going on within the cooperative arrangement. Only once the system has

“interpreted” the environment in which artifacts are used, it can also

provide document readers and writers with information of either work

awareness or coordination (see next item).

Awareness partition In the awareness partition, awareness-facts are either

defined, created (i.e., asserted), modified or retracted according to the

application requirements. Awareness information can be provided either

because of something occurred about the content (i.e., the document-

facts) or about the overall work context (among which the activity-

facts). From the former point of view, mechanisms can be used to pro-

vide some sort of fulfillment-awareness, in that they can be conceived to

135


support users both in filling in forms and in fulfilling the implied doc-

umental quality requirements of a given form. As an example of doc-

ument filling-in, we can mention a case from our field study, the so

called “formulation problem”. This problem regards the formulation of

a correct nourishment solution to provide premature newborns with by

intravenous feeding: such problem concerns the accurate computation

of the correct nutritional supplies with respect to a certain diet regi-

men and under the constraints of a correct fluid balance, the concur-

rent assimilation of compatible drug “cocktails” and the overall condi-

tions of the inpatient. It is this multi-layered and contextual nature of

the value processing that distinguishes the formulation problem from a

mere spreadsheet computation. For this reason, it could be safer not to

make the compilation of the corresponding infusional therapy form com-

pletely automatic, but rather to provide nurses with what we defined in

Section 5.2.1 either alerting, inconsistency or amending awareness if the

system detects (by mechanism triggering) that they have made some

mistake; or alternatively, to automatically insert “correct” values into

the form while also providing nurses with either provisional or inquiringawareness so as to urge them some further verification.

As an example for quality requirements fulfilling, we have considered

in a previous work [Cabitza and Simone, 2006] how awareness can

be provided after that the goodness quality of an information has been

checked. Mechanisms can check whether an information is sufficiently

complete or pertinent with the activities that are correlated with that of

production of the data at hand, depending on the very local context of

production (e.g., text area, section, documents) and consequently pro-

vide actors with inquiring, amending or coordination awareness23.

Likewise, also possible syntactic as well as semantic (relational) mistakes

can be checked and have users be aware of. For instance, a date can be

incorrect as regards either its format or its compatibility as attribute of a

particular entity. The former case is the case of a regular syntactic checks

and of mechanisms that provide amending awareness. The latter is about

the conventional semantics of certain properties that is associated with

23In [Cabitza and Simone, 2006] we focus on this latter case, when we consider the ad-ministrative and clerical personnel of the hospital management positively rely on the extentclinicians produce accurate and complete records as necessary precondition to have their jobfeasible.

136


inconsistency awareness: e.g., today’s date could be the only correct one

for some fields, while conversely a past date and a future one are the

only feasible for anamnestic data and scheduled activities, respectively.

Awareness-fact can be associated to any sort of alerts, reminders and

other “awareness affordances” that show up on the documental artifacts

that compound the web of artifacts so as to suggest actors about what

should be better do next.

By means of proper awareness-fact and correlated mechanisms, design-

ers can have transitors suggest the possible work activities that actors

can or should perform on the basis of the current status recorded within

activity-facts and other contextual facts. Let us consider, for instance,

the alerting and enabling awareness as could be provided in the clinical

domain that we will describe in more details in Chapter 6. As regards

the former type of awareness, let us just recall the example given in

Section 5.2.1 about the “absolute condition” convention on inpatients’

body temperature: the graphical vital parameters form where actual tem-

perature values are little by little recorded can be seen as a document

whose recorded values can alert clinicians and hence enable caring in-

terventions or processes according to local ward conventions or even

world-wide clinical pathways [Berg et al., 2005, Campbell et al., 1998]

(on this last point, see Section 8.3). As regards the enabling awareness

type, let us briefly anticipate the case of the exam request form that will

be extensively treated in Chapter 7: on that form, to jot either a capital U

(standing for Urgent) or a capital R (for Routine) can trigger correspond-

ing mechanisms that either create or modify the “to-do-list” of nurses, or

that someway highlight the form’s fields to be filled-in so as to either

enable some corresponding task (cf. enabling awareness), or to remind

nurses about its completion (cf. reminding awareness).

5.3.2 Predefined mechanisms and WOAD Primitives

Predefined mechanisms are mechanisms whose antecedent side is still generic,

but consequent hosts only a primitive. For this reason, primitives can be

introduced by the corresponding mechanisms that make their application

condition-driven. We distinguish between:

definition mechanisms by which fact templates can be defined within a cer-

137


tain fact space, according to some run-time condition as extensions of

other templates24.

assertion mechanisms by which new facts are added to the fact space.

deletion mechanisms by which facts are deleted from the fact space.

modification mechanisms by which facts are modified and the fact space

changed according to the context and the conventions that apply to the

context.

document-sharing mechanisms by which documents are shared within a cer-

tain web of documental artifacts and hence represented within the cor-

responding fact space as document-facts.

convention-spreading mechanisms by which conventions are published and

released within a certain web of documental artifacts and hence rep-

resented both within the corresponding fact space (as convention-fact)

and within the transitors’ rule sets (as executable mechanisms).

correlation mechanisms by which correlations and relationships between

entity-facts are created at run-time.

Each mechanism is then characterized by the primitive that is employed in

its consequent side (see Fig. 5.18).

The definition mechanisms employ the define primitive. This primitive

takes three arguments as input: (1) the name of the new fact template; (2)

the woad-fact the new fact is an extension of (see Section 5.1.1); (3) the

properties to extend it with.

The assertion, deletion and modification mechanisms in their consequent

sides employ the assert, delete and modify primitives, respectively. These

permit to accomplish the sharing of some specific information into the fact

space (by asserting it in such common repository), its deletion from and its

modification within the fact space, respectively. These three primitives allow

to produce changes within the fact space, but just from the content point of

view: no change to the fact structure — i.e., their templates — can be yielded,

unless some fact whose structure must change is retracted and then redefined

with a new structure and consequently re-asserted.

24In the most general case, as extension of some woad-fact template.

138


Figure 5.18: Summary of WOAD primitives and their parameters.

These three WOAD primitives take facts as input and overwrite the homony-mous functions provided by DJess to work with memories shared by distributedinference engines25. When a fact is asserted by means of the assert primitive, itis added (written) into the fact space. The middleware provides it with a uniqueID. If that fact is either a entity-fact or relation-fact the middleware fills in theclassname slot with all the fact templates this fact refers to by inheritance26. Ifthe fact is a convention-fact the middleware fills in the concerns slot with allthe fact templates the rules refer to, either as patterns in its antecedent or asprimitives parameters in the consequent side.The modify primitive takes a factas input27 and is used by transitors to change the values of a fact according tothe information the latter refers to. Whenever a modify primitive is applied to adocument-fact, the corresponding d-activity-fact in whose output attribute suchdocument-fact is reported is updated in its time-stamp attribute and consolidated.In this way, the middleware provides also a history mechanisms, that match allthe modifications to the documental content with corresponding outputs of dif-

25As a matter of fact, in DJess the delete is called retract.26This is accomplished by means of the get-templates function.27Here again, the implementation requires just its ID.

139


ferent instances of documental activities so as to report their executors and times.The document-sharing mechanisms employ the share primitive. This primi-

tive recalls the concept of “sharing”, since its task is to put in common a certain

documental artifact within a certain web of artifacts. This task is accomplished

by automatically carrying out four sub-tasks28: (1) it takes a document as in-

put; (2) it defines a template of document-fact (see Section 5.1.1) structured

according to the document structure; (3) it asserts an instance of document-

fact into the fact space, inserting values that correspond to the current content

of the document; (4) creates a bind between the documental artifact and its

fact-based representation (i.e., the document-fact) within the fact space. Un-

til the corresponding document-fact is retracted, this bond is such that any

modification the user performs on the “bound” document is mirrored into the

fact representation within the fact space and vice versa, any modification the

transitors perform on the documental fact is rendered — or better yet, shad-

owed — on the artifact in terms of output.

At completion of the description of the operations accomplished by the exe-cution of the share primitive we recall the automatic creation of d-activity-factsaccording to the structure of the document at hand mentioned in Section 5.1.1.

The convention-spreading mechanisms employ the spread primitive. This

primitive is used to make computable into one or more transitor the conven-

tions represented by means of corresponding convention-facts. Once conven-

tions are spread across the transitors of the web of artifacts, these can apply

the corresponding rules according to the context. The spread primitive takes

a set of convention-facts (at least one), as well as a set of transitors as in-

put and has the latter load a corresponding mechanism into the set of all the

mechanism (i.e., activatable rules) they can apply to the fact space content.

The spread primitive can then be also used to gather more conventions into

some encompassing behavior: this is accomplished by associating a cumulative

label to a set of conventions and to make them applicable by some computa-

tional machine (i.e., some transitor) so that they can contribute in making the

fact space evolve (i.e., change) over time and according to possibly additional

aspects of the context even at run-time.

From the implementation point of view, such primitive is composed by severalcalls — a call for each transitor that must load the rule into its rule-set — of theload-rule function. This function is provided by the communication middleware

28Designers that employ such primitive do not have to worry about how this is accomplished,since the share primitive does all the job transparently.

140


to add a shared rule to the local rule base of an inference system (in our case, atransitor). See Section 4.3.2

Correlation mechanisms employ the correlate primitive. In this regard,

however, a caveat should be raised. Obviously creating correlations among

data and categories is a creative task that involves for the most part human

actors. Conversely, the correlate is a primitive that can be executed by tran-

sitors to accomplish the task of contributing in inferring new correlations or

proposing them for human validation (cf., e.g., [Mark et al., 2002a, Cabitza

et al., 2006c]). Once the WOAD designers have expressed general relation-

ships holding between categories, they can call the correlate primitive on a

pair of facts that are in some relationship and see whether some other corre-

lation can be created.

To better explain this important point, we employ two examples. The first

one regards a correlating mechanism29 that accomplishes the inheritance of

relationships. In Fig. 5.19, we see the code of a mechanism that can be de-

scribed in this high-level way: if two entity-facts are put in relationship by

means of a class-level relation-fact, all the entity-facts that are defined as ex-

tensions of these two entity-facts can be put in the same relationship, but

at object level. The second example regards the WOAD-specific correlations

occurring with data that must be replicated or duplicated within the same

web of documents (see Section 3.3.3). If the designer sets a duplication re-

lationship between two fields in two different documents, she could conceive

a mechanism that detects the presence of a datum in one of these fields, and

consequently calls the modify primitive to copycat the datum into the second

field and then the correlate primitive to create a new correlation between

the two instances.

29The painstaking reader could notice that designers can indeed generate any correlatingmechanism from that herein provided just by defining the conditional element that make themechanism applicable in a certain domain and context.

141


Figure 5.19: Example of DJess syntax for the definition of a WOAD correlation mech-anism.

142

Chapter 6

The reference domain:documenting the hospital ward

We take the hospital ward domain as a paradigmatic example where inter-

connected sets of heterogeneous artifacts are proficiently deployed and used

for a clear and transparent purpose: the recovery of ill or injured people. The

interconnected set of documents that support clinicians1 is called with a num-

ber of different names according to the context of analysis. In our study we

will refer to it as the clinical record2. In this chapter we will report our obser-

vational field studies that we conducted with the aim of understanding how

clinical records are compounded by a number of artifacts that are heteroge-

neous in structure and function but that still result in a highly interconnected

and cross-referenced set of documents. In so doing, we aim at making clearer

how clinical documentation could be a good example of a web of coordinative

artifacts in which then to apply the WOAD model and language to provide the

involved actors with an awareness-oriented computational support.

1Since the term ‘clinic’ denotes both the group of people working in the same healthcarefacility, and the place itself, we have chosen to denote as ‘clinician’ any qualified person whois involved in the treatment and observation of living patients, i.e., physicians as well as nurseand the like. Cf. the Random House Unabridged Dictionary, Random House, Inc. 2006.

2What we call in the following clinical record is also widely known as patient record [Dicket al., 1997], especially in those domains where it is useful to stress its patient-centered nature.In order to dispel some possible misunderstandings regarding what could be alternatively de-fined patient record, health record, medical record or even hospital record, we chose the neutralterm clinical record to refer to the set of documents pertaining to a single stay of an inpatient insome hospital-like facility.

143

CHAPTER 6. THE REFERENCE DOMAIN: DOCUMENTING THE HOSPITALWARD

6.1 Medical work at Hospital as Cooperative Work

Hospital arrangements are strongly characterized by the need for tight coor-

dination of the therein involved actors: hospital and more specifically hospital

wards are settings where artifacts are used by several and heterogeneous ac-

tors, which work together in a conscious way in the same main process of care

providing, and whose job necessarily implies a big deal of cooperation and

mutual interdependency. The very same notion of articulation work has been

originally proposed by [Strauss et al., 1985] from observational studies in the

hospitalization domain as an analytical framework to understand and explore

the interwoven nature [Nurminen et al., 1997] of the modalities by which ac-

tors “divide, allocate, coordinate, schedule, mesh, interrelate” [Strauss, 1985]

their individual actions to achieve a common goal such as that of handling

the interrelationships involved in managing illness trajectories. With such term

Strauss et al. [Strauss et al., 1982] explicitly referred not only “to the physi-

ological unfolding of a patient’s disease but to the total organization of work

done over that course of illness” as well as to the impact involved with that

work and its organization”.

Besides providing the first settings where researchers studied the phe-

nomenon of cooperative and articulative work, hospitals still provide re-

searchers with a paradigmatic example where the dimensions pertaining to

the work of the involved practitioners are very complex and critical to cope

with, also because of their obvious and decisive influence on patients’ — and

their relatives’ — physical health and psychological comfort. Strauss again

warned against considering “the management of a course of illness [less than]

immensely difficult to rationalize” [Strauss et al., 1985]. Too many factors

play against the standardization of more than small “arcs” of trajectory and

even those standardized portions are continually subject to potential disrup-

tions. The mirage of ‘coordination of care’ — as Strauss call it — has to be

traced back to the complexities and hazards of working with and over people

but also to other aspects of hospital work that make the design and deploy-

ment of supportive technologies as interesting as much as challenging. In fact,

Strauss’s and others’ works have collected several evidences that work done

over and across patient trajectories is highly cooperative, specialized and dis-

tributed [Reiser, 1984, Strauss et al., 1985, Atkinson, 1995, Timmermans and

Berg, 2003].

144

6.1. MEDICAL WORK AT HOSPITAL AS COOPERATIVE WORK

6.1.1 Hospital actors and venues

In a hospital ward cohabit senior physicians with long-trained competencies,

younger physicians with strong ambitions, senior nurses with long-term expe-

riences, younger nurses with high professional expectations and various assis-

tants of different extractions. They are all actors that are different for a huge

number of aspects, like role — i.e., responsibility — education — i.e., com-

petencies — and experience — i.e., reliability — even aspirations and hence

motivations. Such differences in profiles and roles make this heterogeneous

group of coworkers difficult to characterize and even more difficult to for-

malize. Some authors claim that hospital ward actors have “only a limited

and superficial understanding of each other’s work” [Reddy et al., 2001]. That

notwithstanding, they still have constantly to assign, delegate and hand over

items of work to other colleagues [Berg, 1998,Berg, 1999,Engesmo and Tjora,

2006] and to rely on the fact that these colleagues do their own job well and,

not a minor detail, as they expect it to be done.

Moreover, hospital wards are teamwork settings where work trajectories

unfold across distributed locations [Bardram and Bossen, 2005a] and different

times [Reddy and Dourish, 2002] and where practitioners are consequently

and continuously moving from place to place [Luff and Heath, 1998] and take

advantage of the physical environment in different ways to articulate the dy-

namics of their activities [Gorman et al., 2000, Bang and Timpka, 2003]. As

such, these cooperative work arrangements can exhibit even divergent char-

acteristics: on the one hand, due to the complexity of overlapping work shifts

and workload variability, clinicians can end up by working together several

times in a week in some periods, but also see each other much more seldom in

other periods and cooperate either over distant shifts in time or distant wings

of the same hospital building. This is the case of, e.g., referring and consulting

physicians for the management of recurrent similar cases.

Clinicians can hence rely on verbal and proxemic communication to have

their work done as well as rely on the work accomplished and accounted by

distant colleagues in a coherent effort to contributing to the patient’s health

and recovery.

These domain characteristics also make difficult to draw a clear-cut line

between those clinicians that do share a number of conventions either on the

proper clinical conduct or on the agreed and seamless cooperative behaviors

and those clinicians that do not share these conventions. This can also be ac-

145


centuated by the fact that such conventions can have never been made explicit

or externalized [Nonaka and Takeuchi, 1995] in any written or verbal form.

The set of all possible users of a clinical documentation is much broader

than just the number of members of the ward community. In fact, the very

same documentation can be also handled by administrative clerks, secretaries,

external consultants, general practitioners, i.e., all the actors that can be in-

volved, to some extent, with the same clinical case, i.e., patient. In this case,

we adopt the term introduced in [Habing et al., 2001] where care-cluster de-

notes all actors responsible for delivering a specific type of care to a patient

and care-network the set of heterogeneous care-clusters involved in delivering

care for a specific patient.

Our point is that these two concepts can be easily mapped into our con-

ception of interconnected sets of documents. In fact, single wards are strongly

associated with a particular type of care. Consequently, the local webs of arti-

facts that are used within a specific ward also characterizes an associated care-

cluster: the cluster of practitioners that fully make sense of these documents,

as regards their structure, function and conventional practices of proper either

compiling or consulting them.

According to the extent these conventions are shared and known within

a care cluster, their members can be also considered a community of prac-

tice [Wenger, 1998], in that its members share all a concern for providing a

care of quality and for learning how to achieve a better quality of care3. In-

stead of community, we prefer speaking of clusters, networks and webs, since

such terms are more neutral with respect to the indication of either actors’ or

artifacts’ sets and also because they all exhibit the properties of scalability and

composability at any level of description and hence allows us to comprehend

also those cases in which either different communities need to collaborate, as

happens for any external referral (see Chapter 8.3), or in which members of

some subsets of the same community of practice are responsible for the man-

agement of smaller webs of documents, as in the case of nurses and doctors of

the same ward and their medical and nursing records (see next Section 6.3).

3In such a distributed and asynchronous setting as hospital wards are, moreover, this betterquality correlates to better ways of reporting and documenting the planning and performanceof care activities

146


6.1.2 Hospital artifacts

From the points made in the previous section, hospital wards can be assim-

ilated both to arrangements characterized by frantic, synchronous and co-

located collaboration, like control rooms (e.g., [Heath and Luff, 1992]); and

to settings where low intensity, asynchronous and distributed collaboration

occurs, as in waste-water plants (e.g. [Bertelsen and Bødker, 2001]). In such

settings, in order to cope with the ever arising contingencies that character-

ize clinical work, clinicians rely on well consolidated classifications, jargons

and pretty standardized procedures, as well as on a number of local con-

ventions and ad-hoc coordinative modalities that can also include occasional

workarounds and systematic trickery.

Classifications and high-level plans are reified into and supported by a

number of coordinative artifacts, such as whiteboards, forms, sheets, notes,

schemes, and documental templates [Bardram and Bossen, 2005b]. These ar-

tifacts are designed to provide order to and support the coordination of the

intertwining of multiple work trajectories.

This “web of artifacts” (cf. [Schmidt and Wagner, 2004, Bardram and

Bossen, 2005b]) guarantees the coordinative functionality through a delicate

balance between enabling and inhibiting, or also, promoting and constraining

action. Our point here is that this functionality is reached for the very inter-

connected nature of this web, which is compounded by loosely-linked tight-

structured documents and which is then characterized by a balance between

what we call fluid cross-referentiality and local rigidity, respectively.

In the expression “local rigidity”, the term local refers to the intra-

documental dimension while the term rigidity refers to the fact that doc-

uments consist of a predefined number of unmodifiable sections and that

these sections offer tabular structures that call for an ordered — and or-

dering (cf. [Schmidt and Wagner, 2004]) — compilation of data. Structur-

ing documents and their data is advocated as a necessary means to permit

interoperability among different facilities, statistical research and administra-

tive analysis [Gregory et al., 1995,Winthereik and Vikkelso, 2005]. Document

rigidity can also reflect some rationalized and standardized way to conceive

work planning and execution, which informs the design of document tem-

plates intended to support compliance and accordance to the clinical practices

proposed. Consequently, all clinical records to our knowledge are structured

in macro-sections that correspond to some general categories of some model

147


of medical work. These models constitute the basis for corresponding data and

document models.

For centuries, care notes were organized in chronological order, a prac-

tice dating to the Hippocratic school (fifth century B.C.) and its conception of

illness course as development [van Ginneken and Moorman, 1997]. From the

sixties on, also the problem-oriented approach to care recording [Weed, 1971]

began to spread in western hospitals [Tang and McDonald, 2000]. The note

structure proposed by Weed was laid out in the so called “SOAP structure”,

i.e., a structure aimed at facilitating the expression of any medical problem in

terms of “Subjective elements” (i.e., the complaint as phrased by the patient),

“Objective elements” (i.e., the findings of physicians and nurses), “Assessment”

(i.e., the test result and diagnosis); and a “Plan” for future actions and inter-

ventions on the patient [Mann and Williams, 2003]. Other models, like that

informing our case study, assume that hospitalization is a process composed

by an admission, a course and a discharge and call for clinical records with

three corresponding modules to fill in in this strict chronological order.

The local rigidity of clinical documents also allows clinicians to be sup-

ported in properly “moulding” the clinical information so that it can serve

both the informational and the coordinative function. We speak of moulding,

both from the representational and the conceptual point of view; on the one

hand, in fact, clinicians are guided in positioning data within fixed and rigid

tabular sections within which even very sparse stenography and concise data

can make sense in virtue of the schemas associated to those tables. On the

other hand, documents that are structured in ways that they either display

and request content, or request to be filled in with structured text (i.e., cod-

ified content [Henry et al., 1998]), limit the range of possible meanings a

datum can convey and, in so doing, the risk of ambiguity and misunderstand-

ing.

However, hospital domains also require a necessary flexibility to cope with

a kind of work that seldom can be considered just plain routine and that re-

quires tools that could leave practitioners with some room to handle break-

downs and make their deeds accountable and meaningful to other colleagues

in any unpredictable situation. Our point is that this degree of flexibility can

be achieved only by allowing data within documents structures to be properly

cross-referenced so as to acquire even temporary semantic connotations that

make perfectly sense only in a particular context or situation. We counter lo-

148


cal rigidity of documents with their capability to be more fluidly referenced

within a composite web of documents— i.e. at systemic level — a web where

linkages across structures and data therein stored are fluidly and dynamically

made out according to the current requirements.

Two important works on clinical practice separated by almost thirty years

[Garfinkel, 1967, Heath and Luff, 1996b] argue that medical documentation

provides flexibility because they do not carry precise descriptions but “rather

sketches, drawn through a few elements which provide a certain sense or

impression of an event” [Heath and Luff, 1996b] and which leave room for

correlation and interpolation. Interpolating a sketchy account and make sense

of succinct entries is made possible by the practice of fluid cross-referencing,

i.e., drawing either explicit or implicit linkages between data that enable at

the same time efficient and effective documental practice. According to these

studies, no single entry in a medical description can be understood on its own,

but rather the clinician has to piece together different entries in order to form

her interpretation and understanding of a given clinical fact. Heath and Luff

quote Gurwitch for the concept of Gestalt Contexture, when they claim that

medical records function as a whole and that only the relation of the parts

that constitute it define its unity, sense and its capability of being effectually

used irrespective of its intrinsic defeasibility4.

This cross-referentiality and distributed nature of medical documenta-

tion regard both the inter-documents dimension, where many documents con-

tribute together in constituting from complementary perspectives the overall

documentation pertaining to a single patient case; and the intra-document di-

mension, where many structured entries within the same note contribute by

virtue of their relationships in depicting a comprehensive picture of the evolu-

tion of a patient trajectory5.

4“The term [defeasibility] has been widely used in pragmatics and jurisprudence to describethe ways in which any rule or law, no matter how precise its formulation, will inevitable con-front circumstances, where despite their potential relevance, it is inappropriate”. (Heath andLuff, 1996, p.3)

5“By defeasing items across entries and assembling the text with regard to an impressionas to how this event is related to previous meetings concerning the particular illness, doctorsproduce careers or trajectories of illness.”(Heath and Luff, 1996, p.5)

149


6.2 The hospital web of artifacts

In order both to draw insights on real cooperative settings and to inform the

conception of the main tenets of the WOAD framework, we conducted a series

of field observations over a span of two years with different facilities of the

same hospital. Since the facilities at hand turned up with many peculiar as-

pects that to some extent appeared contradictory, we soon realized that gath-

ering a complete and detailed understanding of the setting at hand would have

been unfeasible. Therefore, we followed a “quick and dirty” approach [Hughes

et al., 1995] by which to quickly get a general picture of the setting and in-

form our further investigations on some selected aspects of its. In so doing, we

were able to recognize even pretty standardized care and coordinative activi-

ties as social actions embedded in a socially organized field of meanings and

references; from such a picture of cooperative arrangement we accordingly

selected those portions and aspects of particular importance in informing the

WOAD architecture and WOAD-compliant applications’ design.

6.2.1 The case study setting

The empirical data were chiefly collected via observations and interviews ac-

complished in two different wards of the same hospital: the Internal Medicine

and Neonatology wards of the Alessandro Manzoni Hospital. The Manzoni

Hospital is one of the largest (approximately 1000 beds and 2700 employ-

ees) and main teaching hospitals of the region at north of the city of Milan,

in Northern Italy. It is situated in Lecco, a city of 50,000 inhabitants, but it

serves a much wider provincial territory sheltering a population of more than

300,000 inhabitants. In 1995, the hospital ranked first in profitability and pro-

ductivity in Lombardy, the Italian region where one sixth of Italy’s population

lives and whose gross domestic product is the highest in the whole European

Union. In 2000, the hospital facilities moved to a brand new building where

both the clinical and administrative top managements could to some extent

partecipate in the design process to positively inform the rationalization of

space organization according to the main flows of resources within the hospi-

tal. In that new facility, we located our observational study.

150

6.2. THE HOSPITAL WEB OF ARTIFACTS

6.2.2 Two wards: two worlds, one record

The two wards were selected in order to collect and compare data and in-

dications from practitioners working in different specialties, but sharing and

using the same documental model and artifacts on a daily basis for the same

general purpose of care providing. Differences between the Internal Medicine

(IM) and the Neonatal Intensive Care Unit (NICU) are worthy of some consid-

eration since for many aspects they seem to be antithetic.

On the one hand, particular physicians, called internists, work in an IM

ward. These doctors specialize in the diagnosis and nonsurgical treatment of

a very wide range of adult diseases, and got a specific training in coping with

cases where several different illnesses may strike at the same time and it is

hence prevented a more specific hospitalization in some subspecialty ward,

like Cardiology or Nephrology.

Patients admitted to the IM ward are usually long-staying and acute ill

patients. Yet, since their average age is steadily increasing as the popula-

tion’s one, these patients tend to chronicize their disease and hence exhibit

a low level of autonomy but, at the same time, also medium/low critical-

ity needs. This kind of patients and illnesses has a peculiar impact both on

medical and nursing work. As regards the former, doctors have often to solve

puzzling diagnostic problems by evaluating and gathering symptoms that oc-

cur and change over time (the so-called “wait and see approach”) and have

hence to cooperatively share hypothesis over distant work shifts and agree on

even complex lines of probing and action across several shifts. On the nursing

side, IM patients require a lot of care work and also a big deal of sentimentalwork [Strauss et al., 1982] between care interventions.

Conversely, the Neonatal Intensive Care Unit (NICU) shelters premature

newborns with severe deficits and high criticality needs. Almost nine percent

of all newborn babies require to be admitted and be cared for in a NICU, also

because therein patients have a direct access to consultants, surgeons and an-

cillary services that allow treatment across a wide range of neonatal problems.

Stay lengths at the NICU vary depending on a number of unpredictable factors

and can range from a single day of observation to many months for the worst

complications. Since the Manzoni hospital serves a quite wide region, almost

two third of the admitted neonates come from external services and other hos-

pitals, for an approximate yearly intake of 400 critical newborns treated. All

these cases are managed by ten neonatologists and a 25-nurse staff that attend

151


premature infants by preparing and maintaining an intensive care regimen on

a 24-hour basis. This requires both physicians and nurses work hard together

and be ready to take decisions and intervene in reaction to severe and critical

events in the shortest time possible.

From the diagnostic point of view, the NICU, as any other intensive care

unit, is an example of setting where the subjective and verbal components

that physicians draw from the patient’s account of her sensations and feelings

lack completely. This component of the overall picture clinicians make of a

patient’s condition is usually compensated by an increase in collecting objec-tive facts which — although they are “objective” in that they are gathered by

precise sensors and specific machineries — must be anyway interpreted by

physicians and recognized within a number of guidelines or pathways that

the literature either substitute or consolidate from scientific evidences with

time. From the caring point of view, a NICU is a high technology-driven set-

ting where special machineries, digital equipments, sensors and incubators

support clinicians both in assessing the patients’ conditions and in providing

the needed care with increasing effectiveness over time.

These two wards are pretty different also as regards the extent artifacts’

use is distributed and communication is asynchronous. The IM ward occupies

an entire floor of the hospital building and it is divided into two symmetrical

wings of fifteen rooms each. The total capacity of the ward is 60 patients and

average stay is almost twelve days long. Each wing has its own nursing crew,

composed by twelve nurses and seven health assistants alternating in the space

of a couple of days over different work shifts. The nursing staff is coordinated

by a head nurse, whose role is mainly organizational and administrative. All

the ward activities are organized around two smaller teams composed each

by a nurse and a health assistant taking care of up to fifteen patients during

their duty shift. Teams alternate with each other over three shifts (morning,

afternoon and night) and hand over relevant information and scheduled tasks

during fifteen minute long hand-off conferences. Since wings are square blocks

of the hospital building and patients are sheltered by twos in rooms whose

beds are not easily visible from the outer aisle, nurses working in the same

shift can only occasionally see each other and have conversation only at the

admission desk, situated at the middle of each wing.

Conversely, the NICU is a single large room, divided in two smaller areas,

called “boxes”. Each box has enough room for approximately ten incubators,

152


i.e., very complex units attached to various types of monitors and devices that

continuously monitor the infant conditions and guarantee dim light, constant

temperature, feeding and respiratory support. Each box is attended by small

teams of two nurses each, assisted by an additional nurse on duty till 16:00

which for this reason is called “jolly nurse” and is supposed to relieve outbursts

of workload. Also in this case, a head nurse with primarily organizational and

administrative duties plans the activities within both the boxes. Nurses of the

same team often work at arm’s distance, within the same box, and share the

same setting with up to four neonatologists that work shuttling between one

box and the other during the morning shift. Boxes are divided by a large door

that is always left open so that nurses of different teams can hear the alarms

from the other room and be aware of current workload and sudden needs just

by taking quick glances inside.

While the IM ward is open all the time to the public — i.e., to the inpa-

tients’ relatives and acquaintances — so that at rush hour the ward corridors

can be pretty “crowded”, public access into the NICU is strictly limited: staff

and visitors are required to clean their hands before admittance, as well as

wear gowns, masks and in some cases also gloves to reduce infection trans-

mission. This also has some influence on the different modalities face-to-face

communication is exchanged: while in the IM ward practitioners speak in a

regular tone of voice and it can also happen that practitioners summon each

other at the end of a corridor, NICU practitioners tend to whisper (although

there would not be strict need to): the quiet background noise of monitoring

devices working in the ever dim-lightened ambience is often interrupted by

slightly louder alarms, which each conveys a very specific meaning accord-

ing to its pitch, intensity and rhythms, that only experienced practitioners can

easily make sense of [Randell, 2004].

These differences apart, the management of the hospital had all wards and

departments adopt a very similar clinical documentation, referring to the same

patient record model established at regional level. We will come back to this

model, later, when we will describe what constitutes the clinical documenta-

tion employed in the wards at hand.

6.2.3 The nature of the study

Documents used within both the wards and the correlated activities involving

those documents have been studied relying on data coming from five differ-

153


ent types of source: (a) direct but yet unobtrusive observations, (b) semi-

structured interviews, (c) informal discussions, (d) attitude surveys and (e)

cross-documents analysis. During our observations, practitioners did not seem

bothered by being observed and were often willing to spend some further

time in explaining clinical terms and their local jargon, especially regarding

idiomatic abbreviations and shorthand expressions. We also had often the pos-

sibility to pose contextualized questions for further clarification, especially re-

garding those behaviors that looked to our eyes to have the characteristics of

tacit and informal conventions.

We clearly declared that our mission was to focus on coordination dynam-

ics involved in the articulation of caring activities and the correlated artifact

use: for this reason, we witnessed some informal coordinative meeting oc-

curred at admission desk, attended some official shift handover and observed

how practitioners use the clinical documentation to be supported in such sit-

uations [Cabitza et al., 2005b].

Taking into account privacy concerns, we deliberately did not cover bed-

side caring and did our best to avoid any contact with patients and their rela-

tives. Likewise, in collecting and surveying official documents and other ward

artifacts like notes, forms and records, we deleted all patient identifying infor-

mation.

From our informal conversations and field observations, we took sparse

field notes that we also used as starting point for the artifact analysis and the

semi-structured interviews we held with some key actors. These interviews

were pretty long and frequent meetings with the head physician and the head

nurse of the wards at hand, while they were briefer and sparser talks with

other nurses indicated by the head nurse for qualification and proneness to

being interviewed.

We asked the practitioners questions regarding the typical work day, the

most frequent cases of interruptions and routine breakdowns and the use of

artifacts in both routine and exception handling. As regards document use

some typical questions were “how do you use this sheet?”, “how often do you

use it” and “why, in your opinion, is it important you use it, and that you do

in that way?” so as to address not only the conventional side of documen-

tal practices, but also, to some extent, the motivational side and the extent

practitioners are aware of underpinning purposes and rationales.

Besides a standard list of questions we designed with the collaboration of

154


an anthropologist, which also attended and leaded the first meetings, in each

interview we pretty soon let the conversation follow its own course and our

interlocutor touch her matters of concern regarding coordination within the

ward and the clinical record use (and misuse).

A thorough analysis of artifacts, and study of the correlated manuals and

operating procedures has followed the first round of preliminary interviews

and informed the next rounds. Interviews were conducted individually in ded-

icated rooms to guarantee privacy and confidentiality, so that participants

could feel free to say their personal opinions without worrying about what

their supervisor or other colleagues may think. Most of these interviews were

also recorded on tape. We asked permission to record the conversations, but

kept concealed the equipment so as not to condition the interlocutor’s natural-

ness. Recordings amounted to approximately twenty hours of selected talks.

6.2.4 Documenting the documentation

In line with the artifact-centered focus of our studies, in the following we re-

port the observations and studies accomplished over the documentation clin-

icians use to be supported in their daily work. As said above the clinical doc-

umentation is rather a scattered ensemble of loosely linked documental arti-

facts: for this reason, we will sketch the overall features of its whole first, and

then characterize its main components in some detail.

The two considered wards differ from each other in a lot of aspects, but

their staffs share an element that is of pivotal importance for the character-

ization of the WOAD framework: the same documentation. Obviously, it has

not always been so. A couple of years after the transfer of the main hospital

departments to the new location, and a couple of years before our studies, the

hospital management invested a lot of effort in defining a new organigram and

organization of the ward work. Specifically, the human resource and depart-

ment management area managed the transition from a set of unstructured and

informal artifacts to an articulated set of more structured documents, within

a more comprehensive rationalizing policy indicated by the regional health

administration.

This transition was conceived with the twofold aim to support ward work

more efficiently and to introduce unobtrusive quality verifying tools. The pro-

cess and artifact redesign activity was made with the involvement of sev-

eral ward practitioners’ representatives (including some representatives of the

155


nursing staffs) and led to new artifacts comprising the current patient record.

The sharing of the same core documents has allegedly facilitated a better in-

teroperability and articulation of activities between wards and departments

and a rationalization of service requests and provision.

As a matter of fact, we could not directly verify that the adoption of that

particular participatory approach in redesigning artifacts and practice has re-

ally facilitated the process of inclusion of these new artifacts into the everyday

caring and nursing tasks. Nevertheless we could notice that both physicians

and nurses were quite aware of the problem of being able to rely on well-

designed and structured clinical records: while it is not clear if this commit-

ment and awareness should be traced back to the preliminary involvement in

the adoption of the unified clinical record, we found that this critical ability

and good predisposition to the matter helped us both in making our goals

clearer to our interlocutors and in establishing a profitable collaboration.

Even if the core of the clinical documentation is the same in every ward,

ward-specific peculiarities and minor differences between patient records from

different wards do still exist. In fact, any medical specialty involves particular

recurrent procedures and needs, and this is reflected in the fact that the full

documentation in use in a given ward can differ from others in a bunch of doc-

uments that are added to the core set since they are specific for the treatment

and monitoring exigencies of a particular patient profile.

Besides extra-documents, we also detected differences in the very same

artifacts compounding the core set. That notwithstanding, these differences

are minor, easily circumscribable in the diagnostic and caring process (i.e.,

the phases of admission, discharge and service request are the same) and have

not hampered our task of getting a general and shared overview of the clinical

documentation employed within the Manzoni Hospital.

For instance, IM patients do not usually need to take drugs outside the

regular administration cycle, which is usually composed of four, five takes

per day. Those patients only seldom need also complex infusional therapies.

Consequently, the Single Pharmacological Therapy Form (SPTF see below)

used within the IM ward is organized according to a weekly schedule, which

is also appreciated by IM practitioners for its convenience of consultation and

updating therapies spanning across multiple days.

Conversely, NICU newborns require more complex therapy regimens,

dosages of medicines that can vary according to either laboratory exams or

156


unexpected variations, and the introduction of drugs into a vein in twenty-

four hour long infusions. For this reason, NICU practitioners prefer to adopt

a daily schedule for the SPT sheet, in which they can also check and update

the regular rate of infusing. From the point of view of content, function and

structure the two versions of the SPT sheet are equivalent: they only differ in

the scope of information they can store (either hours or days) and in the way

tables and text boxes are rendered within a single A46 sheet of paper.

As a last remark before surveying the documentation at hand, the reader

should also mind that the following account is neither comprehensive nor

ever-valid, for at least two reasons.

On the one hand, many other artifacts and forms — which we purposely

overlook for the sake of conciseness —- are used even within the same hospi-

tal in other wards than the observed ones; even in the very same wards of our

study, some informal and ad-hoc artifacts can occasionally be used along with

the official and institutional ones, although for limited purposes and scopes,

both in time and use. That notwithstanding, we purposely concentrate on

some key artifacts compounding the official clinical record that we selected

for their subjectively perceived importance and frequency of use by means of

a likert-scale questionnaire (see Section 6.5 and Appendix A).

Moreover, clinical documentation should, from the ideal point of view, be

the only source of information for any informational and coordinative exi-

gences within a ward; it is the only one that is stored and consulted for any

legal or research reason even months after a patient has been discharged;

and it is the first and probably only set of artifacts that will be digitized into

an Electronic Patient Record when the hospital decides to undertake such a

project.

On the other hand, even over a structurally fixed documentation, docu-

mental practices do change over time. This can be due to either some massive

modification implied with the introduction of some standard for interoper-

ability at hospital, regional or even national level; or rather to some slight but

important adjustments locally established within a limited group of users to

better fit their needs and idiosyncrasies.

6The ISO A4 standard for paper size is a rectangle of 210 x 297 mm

157


6.3 Composing the composite artefact

As said at the beginning of this chapter, the main documental artifact used in

healthcare as the composite repository for the information concerning a sin-

gle patient is usually called clinical record. The documents compounding the

clinical record constitute the legal documentation attesting the clinical case as

a whole and this general and patient-oriented scope makes them a correlated

set of scattered artifacts used in support of clinical work (see Fig. 6.3 for a

web-centered vision of this distributed and composite artifact).

As a matter of fact, yet, the clinical record itself can be further decomposed

in two parallel records, two partly disjointed sets of documents: the medicalrecord and the care (or nursing) record. The former record is a collection of

sheets, forms and documents that pertain to the medical dimension of care

and hence mainly to the work of physicians. In that part of the clinical record,

data are mainly managed — i.e., consulted and updated — by physicians,

which can also have exclusive access to some sections of some sheets, like

the sections for pharmacological prescription. The latter record, is a usually

leaner collection of documents that pertain to the caring dimension and the

daily treatment of each inpatient, and hence primarily to the work of nurses.

For the specificity of some of the documents compounding the care record,

nurses are the only practitioners that are supposed to consult and write the

nursing record.

Both the medical and the care record support the unambiguous identifica-

tion of the patient, the treatment planning and the recording of all relevant

events regarding the illness trajectory of a certain patient. Nevertheless these

records also constitute a complementary view on the whole complexity of a

clinical case and are conceived for different purposes and under assumptions

from different conceptual frameworks.

For instance, medical records are organized around the concept of “health

problem”, which physicians are supposed to diagnose and solve by ordering

proper therapeutic interventions; care records are instead organized around

the concept of “patient need”, which nurses are supposed to detect, evaluate

and fulfill.

Besides these conceptual differences, these two records are also physically

separated in that the medical ones are stored in ring binders, each dedicated to

a different patient. Conversely, a single big ring binder holds the care records

of all the ward inpatients and colored pages separate each patient’s record.

158

6.3. COMPOSING THE COMPOSITE ARTEFACT

This fact, which obviously depends on different information retrieval needs,

also reflects a general approach that physicians and nurses have towards their

job: physicians focus each time on a single patient, or better yet, even on

very narrow aspects of the patient status in order to trace back symptoms to

diagnosis. Nurses, instead, consider the work to execute in a ward as a whole,

that is each time declined and modulated in a particular manner depending

on the patient they address.

That said, medical and care records are not intended as watertight com-

partments, at all. Indeed, although what refers specifically the nurses’ duty

is to be found in the care record, nurses update also most of the reports and

sheets compounding the medical record. This can be done under the close and

direct supervision of the physician with whom nurses are taking the morning

round or more autonomously during the rest of the day when they are sup-

posed to update the record with clear and unambiguous indications of activity

progress and completion. During their daily routine work, nurses accumulate

information as regards the overall illness trajectory of the patient and coor-

dinate with physicians in terms of feedback and confirmation of prescribed

activities.

In the following, we provide a brief overview of the most frequently and

important documental artifacts compounding the clinical record. We will de-

scribe each document in terms of the content type they usually store, the roles

that are supposed to fill in and read them, the reason why they are used — i.e.,

their function — and briefly, the representational structure and the practices

of use that depend on such structure. We will not distinguish between the

way documental artifacts are intended to be used and the way their are actu-

ally used. In our studies we obviously got a picture of both: the former could

be drawn from the internal manual that from 2002 is progressively compiled

within the Manzoni Hospital for the proper documentation of clinical work, as

well as from the statements of the practitioners we interviewed. The latter as

it was pretty naively observed during our stays at the hospital with no partic-

ular preconceived ideas about which the right way of documenting ought to

be.

Differences detected between the so called “theory”, imposed “from above”

by the hospital management, and the actual “practice” as it is actually accom-

plished in the field of work were in some rare case significant, but usually

practitioners were well aware of them and justified them as necessary devia-

159


tions from indications that were conceived to fit all wards, specialties and situ-

ations and hence had to be adapted in some ways7. For our practical purposes

this distinction blurs into the actual “proper and virtuous” use of artifacts,

which we outline in the following, irrespective of the manifest and desultory

exceptions and mistakes we seldom and occasionally observed.

The reader can refer to Fig. 6.3, where we use the following abbreviations.

6.3.1 Patient Data Sheet

The Patient Data Sheet — PD is the document in which the admitting nurse

records both registry and personal data about the patient. These data refer

both to the stay (e.g., progressive id of patient record, type of hospitalization)

and to the admitted person herself (e.g., her tax number, date of birth, home

address, main phone number). All together these data allow clinicians and

hospital administration to uniquely identify the inpatient. The structure is not

dissimilar from any other registry form used to provide personal data into any

information system.

6.3.2 Admission Reason and Anamnestic Data

The Admission Reason and Anamnestic Data — R&A Sheet is the document

in which the so called “admitting doctor” specifies both the main reason for the

hospitalization in terms of clinical problems and the problem-oriented history

(anamnesis) of the patient at hand. These indications must be able to inform

who consults this document later about the following questions: “Which is

the main reason why the the patient has been hospitalized?” and “To which

extent the current hospitalization problem relates to the previous illnesses and

the history of the patient?”

The admitting physician can detail the admission reason along several di-

mensions, for example in terms of either subjective and objective symptoms:

the former ones are reported and subjectively characterized by the patient her-

self, while the latter ones are detected from a first survey by the doctor accord-

ing to some objective and perceivable signs. All together with the anamnestic

data, the admitting doctor must also report those pieces of information drawn7We recall that the process of design and deployment of the current clinical record has been

negotiated at length between representatives of all the main stakeholders’ categories. As a con-sequence of that, the institutional, “from above” component and the “grounded”, “practitioner-based” component of the clinical record have been already reconciled at some extent approxi-mately one year before our observational study.

160


from the patient’s life and habits that could constitute some risk factors in rela-

tion to the detected health problems (e.g., smoking, known allergies, adverse

drug reactions).

The document provides a set of checkboxes and wider sections with free-

text areas where the admitting physician can jot down the data she collects

by speaking either with the patient or her relatives (or both, whenever possi-

ble). This document well represents the tension between the need for coding

— necessary both to facilitate administrative processing and statistics and to

enable epidemiological and clinical research — and the need for the admitting

physician to use this document to communicate with her colleagues working in

the next shifts as many cues she deems relevant as possible to inform next di-

agnostic and therapeutic decisions. The same consideration holds, even more

notably, for the following document.

6.3.3 Preliminary Objective Examination

The Preliminary Objective Examination — Ex sheet is where the indications

from a first objective examination are reported by the admitting physician.

The objective examination is oriented to the clinical assessment of the current

status of the patient’s systems and apparatus so that sound diagnostic hypoth-

esis can be derived and an effective diagnostic and therapeutic programme

can be formulated. The extremely well consolidated classifications and tax-

onomies regarding human anatomy and physiology lead to a tabular structure

in which each apparatus has its own small free-text area (e.g., skin, heart, tho-

rax, abdomen) and some check-boxes. The physician is supposed to tick the

check-boxes off in order to explicitly indicate whether she actually assessed

the patient from that particular point of view or she has not; and if she has,

to indicate whether the drawn indications are relevant or not; if they are, the

physician is also supposed to describe her findings in the corresponding area.

Also in this case, structured coding and free-text noting coexist. While the for-

mer is intended as a way to provide both the examination with a synthetic

but systematic nature and the physician with a convenient to-do (or better

yet, a aspect-to-consider) list, the latter is the only necessary means for the

examining physician to provide her colleagues with possibly subtle and even

partly contradictory cues that could suggest uncertainty or trouble in tracing

the observed signs back to a merely true-or-false indication.

161


6.3.4 Problem List

The Problem List — PL is the artifact where clinicians describe the patient’s

problems, as they manifest themselves upon arrival. The problem list is in-

tended to document all those conditions and events that can be related to

some hypothesis and procedure. The term “problem” is purposely left vague

enough to comprise a number of factors like symptoms, any alterations to vital

signs, any difficulties encountered by the ward staff in their interventions on

the patient and all the concomitant pathologies that could affect the character-

istics or the evolution of either the current hospitalization reason or therapy

plan to comply with. This list is likely to change during the caring course:

physicians update its content with respect to the actual improvements or ag-

gravations exhibited by the patient but also with respect to the extent they

can consolidate some diagnostic hypothesis. We often observed how groups

of entries regarding signs that at admission’s time were quite unrelated or oc-

casional in nature were crossed out and substituted by an entry of diagnosis

comprising all those signs. This artifact plays a central role in the web of arti-

facts documenting the inpatient’ illness trajectory. In fact, it is not intended as

a mere recollection of things clinicians must care about, but rather as a tool

that support them in (a) making care and illness complexity manifest; (b) in

formulating diagnostic hypothesis that would be hard to consider without con-

fronting and matching together arbitrary groups of problems; (c) in adopting

therapeutic approaches that are more adequate to the individuality of each

considered case; (d) in detecting causal connections and association and (e)

in maintaining a watchful awareness about those problems that are solved and

those still persisting. From the structural point of view, the problem list is a

simple four-column table (see Fig. 6.1), where physicians are supposed to fill

in one single problem for each row, assign it a progressive number, append a

date of onset, eventually a close date, and finally to put their signature on the

entry.

6.3.5 Diagnostic Hypotheses and First Care Planning

The Diagnostic Hypotheses and First Care Planning — DTP sheet is where

the admitting physician is supposed to formulate, in order of reliability and

likelihood, at least three diagnostic hypothesis, which are pertinent to the

signs collected in the preliminary objective examination (see box a in Fig. 6.2).

162


Figure 6.1: A snapshot of the problem list sheet from the medical record. From theleft to the right, there are reported an ID field, the description of the problem, dateand signature for the beginning and the cessation of the problem at hand.

The ward convention to indicate anyway at least three hypotheses is aimed at

a threefold objective. On the one hand, such — to some extent — redundant

practice is aimed at limiting the risk of laying out a diagnostic and therapeu-

tic plan that is biased by an initial misunderstanding or misinterpretation of

symptoms. Rare diseases can be only detected if they represent possible —

tough improbable — hypothesis to investigate and eventually reject. On the

other hand, physicians using such artifact “a posteriori” are convinced that an

additional plausible hypothesis is not as much misleading as it can be reveal-

ing of the internal line of reasoning by which the physician formulates the

hypothesis in that particular order.

Diagnostic indications are reported within the same document where also

a first care plan is formulated and this is not chance (see box b and c in

Fig. 6.2). In fact, the first care planning sheet is where the admitting physician

indicates, in order of relevancy, the programme of all the preliminary diagnos-

tic (e.g., tests, exams) and therapeutic (e.g., drug administrations, treatments)

procedures that are deemed necessary and adequate for the patient. Diagnos-

tic hypothesis must be verified and verification can come from a number of ap-

proaches physicians can follow: diagnostic probing through either laboratory

examination or diagnostic imaging (e.g., C.A.T., M.R.I.), the so called “wait-

and-see” approach, or more proactive approaches encompassing preliminary

cautious drug administrations are all ways employed by physicians to progres-

sively exclude or corroborate hypotheses. The most frequent examinations are

displayed by means of checkboxes so that the physician does not have to point

them out in writing on the free-text area above (see box b in Fig. 6.2) In such

artifact, guidelines and clinical pathways reported in the specialist literature

or taken from internal documentation must be explicitly referenced, especially

whenever the plan diverges from those recommendations. Any modification to

the programme is explicitly reported in the Physician’s Notes (see next).

163


Figure 6.2: A snapshot of the diagnostic/therapy plan sheet from the medical record.

164


6.3.6 Physicians’ Notes

The Physicians’ Notes — PN is a collection of sheets that is also known by

similar expressions like ‘clinical diary’, ‘doctors notes’ or ‘progress notes’. All

these names suggest that this document is the central repository for any notes

physicians need to write down both to account for any decisions and inter-

ventions occurred so far and to make impressions, opinions, or just lines of

reasoning explicit either for themselves as memorandum or as written mes-

saging to other colleagues. Any sheet can contain a number of entries whose

basic elements are a progressive id, a date of compilation and a free-text box

of description. In this box, on a daily basis, physicians document any single

diagnostic and therapeutic decisions they take during the illness trajectory of

the patient at hand, as well as unexpected or anyway relevant consequences

of those decisions. In their notes, physicians are also supposed to record any

relevant event or condition variation occurred to the patient with respect to

either the preliminary examination (cf. the ‘R&A’ document) or previously doc-

umented portions of the stay, i.e., previous entries within the same document.

Also brief outlines about the significant outcomes of exams and treatment are

therein documented, since the Physicians Notes are intended to include any

piece of information should be known at a given point in the care process to

support next appropriate clinical decisions. Since even “no news” can be “good

news” on the way to recovery, a ward convention prescribes that at least one

entry per day is reported, even if in this note clinicians indicate that “all is

well”.

6.3.7 Single Sheets

The Single Sheets — S*S are a bunch of documents that can have different

names according to which aspect pertaining either to diagnosis or therapy they

cover. They are denoted as “single” (“unici”, in Italian) since they are sheets

conceived to integrate in one single sheet of paper sections that for their func-

tion should be parts of either the physicians’ or the nurses’ documentation.

These sheets are then the only documents within the medical record binder

that encompass specific sections to be compiled by either physicians or nurses

with a rigidly differentiated assignment of concerns and responsibilities. As

a general rule, such single sheets are used by physicians to order drugs, pre-

scribe treatments or referrals and establish particular therapeutic regimens:

165


in few words, to instruct nurses on the arc of intervention trajectory that the

on-duty physician deems at that time necessary to be accomplished about a

particular illness trajectory. Accordingly, for each of these task typology, al-

most any ward has a specific single sheet that has been purposely tailored to

fit the ward’s peculiar needs.

By means of these sheets physicians (a) refer patients to some external

facilities for some diagnostic or therapeutic procedure by compiling what is

called Single Diagnostic-Therapeutic Procedures Form (SDTF); (b) order

some laboratory examination on blood samples or biopsies by compiling the

Single Laboratory Examinations Form (SLEF); or (c) order drugs to be ad-

ministered to patients the next administering turn by compiling the Single

Pharmacological Therapy Form (SPTS). From the structural point of view

the above mentioned single sheets are quite similar: tabular sections encom-

passing one or more fields for the description of the order and the scheduled

and expected times for the order.

The Laboratory Examinations Form and the Diagnostic-Therapeutic

Procedures Form are structured check-box grids reporting a list of the most

common laboratory and diagnostic examinations (respectively) and represent-

ing the diagnostic and lab tests prescribed on a weekly basis.

The Pharmacological Therapy Form contains a large grid, divided in two

sections: drug prescriptions and drug administrations (the reader can refer to

Fig. 7.10). In the former physicians are supposed to fill in fields to indicate the

so called five rights of drug ordering: the right drug name (or active principle);

the right route, the right dose, the right time of administration8. In the latter

section, nurses are supposed to check scheduled administration turns and to

sign the corresponding boxes after completion.

Single sheets abound of places, fields and boxes where clinicians have to

affix their signature or initials. In fact, orders are officially issued (and wait-

ing to be executed by some nurse) only after the responsible physician affixes

her signature under the corresponding entry. Only then, these orders can (and

must) be addressed by nurses. They are supposed either to prepare and di-

rectly administer the prescribed drugs, or to take care of preparing the inpa-

tient for the prescribed treatments and examinations. In this latter case, al-

though nurses do not accomplish themselves the ordered treatments or tests,

they are responsible and accountable for such task “locally”, i.e., within the

8The fifth right, the right patient, is implied by the medical record at hand, since any patientis associated to one and only clinical record during all her stay at the hospital.

166


ward, and they are supposed to collect the medical reports coming from the

referred facilities or services. After completion of the task, nurses are supposed

to provide an explicit feedback to physicians (not necessarily the person who

ordered, but her accountable representative in some next work shift) by prop-

erly compiling specific sections of the single sheets.

For their very nature, then, single sheets are those artifacts that have been

institutionally conceived so that physicians can “communicate” in a coordi-

native manner with nurses the orders which the latter ones are supposed to

accomplish. Nurses, in their turn, use the single sheets to give physicians a

feedback for the correct execution of their orders. Single sheets, notwithstand-

ing the differences due to their focus on a particular medical discipline, are all

documents used to mediate formal communication between physicians and

nurses, make them leave a clear-cut trace of this communication and make

coordination and awareness patterns on the progress of the therapy trajectory

explicit and accountable.

6.3.8 The Need Assessment Sheet

The The Need Assessment Sheet or just Need List — NL is for nurses what

the problem list is for physicians. Within the first twenty-four hours of stay, an

on-duty nurse is supposed to collect data about the patient in terms of degree

of autonomy along nine typologies of needs and report them in a so called

“need list at admission” (see box a in Fig. 6.4). The same assessment task

will be accomplished at the end of the care process, as compendium of the

overall conditions the patient exhibits when she is discharged from hospital

(see box b in Fig. 6.4). These typologies can be traced back to several models

of nursing activities classification (cf. [Wesley, 1995]9, which all stress some

particular aspect of caring. The model underpinning the NL artifact considers

nursing interventions along the dimension of all the possible needs that pa-

tients can express, ranging from the critical ones like breathing and feeding,

needs implying high workloads for nurses like those concerning hygiene and

movement, up to those needs that involve lower workloads and pertaining to a

9In the Italian medical and surgical settings, the most used model of nursing is byCantarelli [Cantarelli, 1996], which is centered on the patient’s needs and correlated nursingactivities that are necessary to have them satisfied. In other countries, other models of nursingpractice are adopted, e.g., the Roper model in the United Kingdom [Roper et al., 1980]. Manyof these models (among which those herein mentioned) are loosely based upon the activitiesof daily living (ADLs) model, developed from the work of Virginia Henderson in the sixties.

167


Figure 6.3: Routine information flows (thick arrows) and data correlations (dottedand thick arrows) among documents. The main documents of the medical record(above) and nursing record (below) have been encircled by a dotted line.

168


Figure 6.4: A snapshot of the nursing need list.

wider acceptation of well-being, like making patients feeling safe, comfortable

and informed. Leveraging on this agreed and rational classification and on a

much more limited range of possibilities, the need list can be more structured

than the problem list (see Fig. 6.4)

After have collected such data, nurses then detect by assessment those

needs that the patient can satisfy without direct intervention of a nurse; those

needs that the patient is able to satisfy with the help of her family entourage

or other assistants; those needs that require the direct intervention of nurses

to be satisfied by the assisted inpatient. Then, nurses report such indications

on a dedicated section of the need list, where needs are ranked in terms of

these three general categories: autonomous patient (B, in Fig. 6.4); patient

to support (BA, in Fig. 6.4); patient to fully assist (BAI, in Fig. 6.4. The need

list, as the problem list, is not a static snapshot taken at admission time, but

changes accordingly with course of the illness.

6.3.9 Nursing Care Plan

In the Nursing Care Plan — NP, nurses formulate the caring objectives and

describe the outcome they aim at reaching for each caring need they previ-

ously identified and characterized in the NL document in terms of autonomy.

Each entry of plan is a scheduled activity that is explicitly referred to a need

169


Figure 6.5: A snapshot of the Activity Plan form for care assistants.

from the need list by means of a unique ID number.

Nurses are supposed to plan also the activities of their assistants. The Activ-

ity Plan sheet nurses compile for the daily job of assistants can be considered

part of the nursing care plan but its structure suggests us a marginal remark

(see Fig. 6.5). In such planning sheet, the free text areas are reduced to the

minimum and there is a number of check-boxes that assistants are supposed

to mark at task completion. This exemplifies as the extent information is struc-tured within the clinical record depends on the extent the phenomenon that

therein is described can vary or present margin of either decisional or interpre-

tational discretion. Assistants are supposed to accomplish a limited and quite

rigid number of activities, as a consequence of the limited responsibility they

can take upon themselves for legal reason. Accordingly, the corresponding

artifact can be more structured and reflect the coordinative and prescriptive

nature of communication between nurses and assistants.

As said before, also other artifacts than those stored within the clinical

record are used in the ward. Their main function is that of partial view that

join data represented elsewhere within the clinical record. One of these ar-

tifacts is the daily fasting list (see Section 7.2.5) that sometimes is added by

nurses to their official nursing documentation, according to the typology of

patient they attended.

6.3.10 Nursing Notes

The Nursing Notes — NN correspond to the Physicians’ Notes for the nursing

side of hospitalization. In fact, into these notes nurses record any observa-

tion regarding changes occurred in the patient’s state of health and any varia-

tions about the caring interventions planned within the NP artifact. Notes are

recorded in chronological order and each note is referred to a specific need as

it is expressed in the NL artifact. In each note entry nurses report an assess-

ment about the level of satisfaction of the nursing need and a comprehensive

170

6.4. THE OVERALL PICTURE OF THE WEB OF DOCUMENTS

description of those factors that eventually determine the necessity to refor-

mulate the nursing interventions.

6.4 The overall picture of the web of documents

In Fig. 6.3 the medical and nursing documents (smaller portions of the overall

web of documents at hand) have been distinguished by means of two dot-

ted ellipses. After have considered the documents compounding the clinical

record in terms of data contained, roles involved, functions, structure and cor-

related practices, we are interested in detecting and sketching the main flows

of information among the nodes of this web. In Fig. 6.3, the reader can detect

two main flows of information running in parallel, by following the counting

numbers on top of each arc. As a matter of fact, instead of flows, we should

rather speak of correlations, since we are not strictly interested in the “flow-

ing”, i.e., the physical moving and transmission of data between documents in

the IT-oriented common sense; we rather focus on the relationships between

data pertaining to similar or correlated pieces of information that belong to

different documents and thus contribute to the “holistic”, systemic nature of

the textual context (cf. Section 3.2 and 6.1.2 ).

Although it is possible to distinguish among several categories of mutual

relationships between data fields and data values, the actual existence of cor-

relations is not given a-priori, but they are rather dynamically established and

modified along with the content of documents within the web. Within this

web, data recording either follows or precedes tasks during the scheduled

routine of ward work. Although data can only follows unexpected events oc-

curred within the illness trajectories of inpatients, that notwithstanding they

do not usually appear in a totally arbitrary order. Data rather appear (i.e.,

are written) on documents according to some patterns that are influenced by

the care work models we mentioned above (see Sections 6.1.2 and 6.3.8 for

the medical and nursing practice respectively). It can be useful to represent

these chronological (although not necessarily sequential) patterns in order to

leverage on the tight relationship between data and correlated activities. This

temporal order heavily depends on the routine nature of events during the

admission and daily care of inpatients and is represented in Fig. 6.3 just as an

indication of sequentiality with cardinal numbers from zero on, as labels of

the flow arcs.

171


Drawing on evidences from our observational studies, we also make a

point that detecting, for designers, and being aware of, for practitioners, these

correlations and flows is of paramount importance within all the recovery tra-

jectory of each patient, since it is by making explicit these relationships be-

tween documents and their contents that users of a documental system can

really make sense of the latter and inform their actions accordingly.

6.5 Communication Patterns and Artifact Use

Once we got a general picture of the information flows and main cross-

references within the web of documents of the clinical record, our next aim

has been to understand what sources of patient information within that web

clinicians utilize in a typical ward of the Manzoni Hospital and which of these

sources they consider most reliable and supportive of their activities. To this

aim, we conducted a nonparticipatory and qualitative survey [Fitzpatrick and

Boulton, 1994,Mays and Pope, 1996] of clinicians’ self-report of their informa-

tion seeking behaviors in both the wards we studied at the Manzoni Hospital.

Our point was that by, even subjectively, assessing information-seeking be-

haviors, we could draw a picture of the typical communication patterns and

artifact use. We then designed a survey to assess the practitioners’ perception

of their utilization of written and verbal sources of patient information. In Au-

gust 2006, we administered to 56 clinicians from both the IM and NICU ward

a questionnaire of 41 questions (items). Respondents were asked to answer

each item of the questionnaire by using a five-point Likert scale, to rate both

frequency and dependability of the clinical record use within their ward, rang-

ing from ‘never’ to ‘always’ and ‘very low’ and ‘necessary’, respectively (see

Fig. 6.6).

This questionnaire (whose questions are reported in Appendix A) con-

tained five subscales: two subscales addressed the assessment of both the fre-

quency and relevancy of face-to-face, verbal communications (questions 1-

8); other two were conceived to assess frequency and relevancy of document-

mediated communication (questions 9-16); and a fifth one to assess how

frequently documents are actually compiled during care activities (in-care

compilation). This latter section of the questionnaire was also intended to

assess the extent clinicians indulge in the practice of updating and filling in

the legal documentation at once only at the end of the shift, rather than during

172

6.5. COMMUNICATION PATTERNS AND ARTIFACT USE

the actual caring activities (as they are supposed to). Indirectly, this was also

a way to assess how the coordinative role of documents could be jeopardized

by cumbersome or redundant documental practices.

The subscales addressing artifact-mediated communication were intended

to assess both the frequency and the extent clinicians rely on the consultation

of artifacts to retrieve the information they need on the go. The first two sub-

scales (questions 1-8) were conceived with the aim to assess how often and to

which extent clinicians think or — are aware of — to rely on communications

that, for either their very nature or some ward convention, are not mediated

by documents, and cannot either. In that, our research is not aimed at verifying

or confirming other previous studies that identify patterns of communication

behaviors in secondary healthcare [Coiera and Tombs, 1998], nor at measur-

ing communication loads on clinical staff [Coiera, 2002]. It also differ from

other studies proposed either to highlight how clinicians seem to prefer to

use verbal communication rather than documents [Alberdi et al., 2001,Brown

et al., 2004], or to collect evidences on the dynamics of communication be-

tween clinicians to improve the way information systems within health care

can be designed [Coiera, 2000]. But those works were taken as reference in

order to obtain results that could inform our following design activity (see

next Chapter).

The internal consistency and hence dependability of the survey was good,

since the alpha coefficient for the administration was 0.73 [Gliem and Gliem,

2003]. As regards artifact use and artifact usefulness, we outline the results

in Fig. 6.6: in that figure, the arrows pointing artifacts indicate compiling

(i.e., writing) practices and the arrows pointing the actors, i.e., physicians

and nurses respectively, indicate consultation (i.e., reading) practices. Median

values give a coarse and approximate indication of frequency and judgement

of use, while means (not to take too literally for the small number of respon-

dents, the 89% of administered questionnaires) give an idea of the opinion

tendencies among the surveyed clinicians. No significant difference were ob-

tained confronting peer roles and professional figures between the two wards.

Some differences were surveyed when confronting the nurses’ and physicians’

groups on some key questions, like those pertaining internal documents of the

medical and care records (P 0 0.05 using a Two-Sample Assuming Unequal

Variances t-Test).

The survey has helped us in identifying that single sheets and daily notes

173


Figure 6.6: The “use” and “usefulness” of documental artifacts in support of hospitalcare. In slanted figures: frequency of use, on a 5 values, symmetric Likert-scale. Inbold figures: effectiveness of use, on a 5 values, symmetric Likert-scale. Median valuesfirst, mean values between brackets.

174

6.5. COMMUNICATION PATTERNS AND ARTIFACT USE

are the main sources of information. An interesting finding regards the need

for clinicians (both physicians and nurses) to look information up in corre-

lated documents. The most evident example regards the nurses’ physicians’

notes: although these documents are concerned with the very same events and

conditions about the patient with the only difference they are recorded from

the nurses’ and physicians’ perspective, respectively10, usefulness for cross-

consultation is deemed useful both for nurses to consult the physician notes

(median 1, mean 0.8) and for physicians to consult the nursing notes (median

1, mean 0.9).

10In fact cross-compiling frequency scores the lowest values.

175

Chapter 7

Application of WOAD to thehospital domain

In this chapter, we will illustrate how to apply the WOAD model and language

to a real cooperative arrangement, basing on the experience we did within

two hospital ward settings that we reported in Chapter 6. We will treat the

topic from the perspective of the designer of a document-based cooperative

application layer (see Section 3.5) who needs to construct some mechanisms

by which to convey awareness information through a preexisting documental

application, in order to make it more supportive of document sense making,

task alignment, and clinical order committing. With reference to the three lev-

els mentioned in Section 3.3, in the next sections, we will decline the WOAD

framework both at domain level and at application level. First (in Section 7.1),

we will see how the WOAD model of document-based cooperative work can

be declined in a specific yet wide domain as the clinical one (see Section 7.1).

Then (in Section 7.2), we will see how the problems and informational re-

quirements raised by clinicians could be addressed at design and run-time by

means of a WOAD-compliant platform and a set of application-specific mech-

anisms conceived our observational studies (see Section 7.2).

7.1 Application of WOAD to the clinical domain

In order to evaluate the expressive power of the WOAD language and its abil-

ity to express relevant concepts and useful conventions in our reference do-

main, we first decided to refer it to existing and widespread standards used

177

CHAPTER 7. APPLICATION OF WOAD TO THE HOSPITAL DOMAIN

in the health care information management. In so doing, we could evaluate

the capability of the framework to facilitate the design and deployment of an

awareness-based application layer on top of some preexisting electronic docu-

ment management system in the architectural schema outlined in Section 3.5

so as to add to such third-party applications the capability to become more

context-aware and more supportive of the articulation dimension of coopera-

tive work.

The main models we have considered for the clinical domain are the so

called Reference Information Model (RIM) and the Clinical Document Archi-tecture (CDA) specification. Both models have been developed by the Health

Level Seven Inc. (HL7), a no-profit volunteer organization founded in 1987 to

develop feasible standards for the management and exchange of medical data

to support the delivery and evaluation of healthcare services. Since such or-

ganization includes international affiliates from several of the most populated

and industrialized countries1, HL7 is generally deemed as one of the most

authoritative institution for the development of healthcare standards aimed

at reaching both functional and semantic interoperability2 between different

facilities and organizations.

7.1.1 The clinical information reference model

The HL7 RIM is a consensus-based standard model by which to describe

and formalize the main concepts involved in health care, such as organiza-

tions, individuals, devices, places, but also documents, acts, their result and

their context. The underlying structure of the RIM (see Fig. 7.1) is based

on six “backbone” classes: Act, Participation, Entity, Role, ActRelationship, and

RoleLink [Dolin et al., 2006].

Act represents any intentional action that occurs — and is documented —

throughout the process of managing and providing health care services

(e.g., the patient encounter, an examination).

1The active affiliates include, among others, United States, Canada, Australia, Germany,United Kingdom, The Netherlands, India, China, Japan.

2Functional interoperability is the ability to exchange information, while semantic interop-erability regards the ability to use the exchanged information. Even assuming these prettystraightforward acceptations, it goes without saying that achieving interoperability betweenmachines is a completely different task than achieving it between their human users (cf.e.g. [Mark et al., 2002b]). But the former interoperability can be considered sort of a nec-essary condition for the latter or, at least, for the deployment of cooperative applications indistributed domains.

178

7.1. APPLICATION OF WOAD TO THE CLINICAL DOMAIN

Entity represents any physical thing or actor that can take part in or be con-

cerned with health care provision (e.g., a human actor, an organization,

an artifact).

Role expresses both the role that each entity can play as she participates in

health care acts and the competency of that entity irrespective of the act

in which she is involved (e.g., a patient, the physician, the nurse).

Participation defines how an entity, in a particular role, is involved in a par-

ticular act. It also expresses the context for an act such as who performed

it, for whom it was done, where it was done and the like.

Act Relationship represents a relationship between two Acts (e.g., causality,

indication).

Role Link represents a dependency between two Roles (e.g., one role has au-

thority over another role).

The RIM concepts can be easily mapped into corresponding concepts of

the WOAD model in virtue of the latter’s modularity and extensibility. RIM

entities and roles are equivalent to WOAD resources that are mapped into ex-

tensions of the corresponding entity-fact construct. The same holds for RIM

acts, that can be related to the WOAD construct of the work activity. For in-

stance, RIM Acts can exist in different ‘moods’, each. Moods can tell whether

the act refers to either a factual statement, a command, a possibility, or a goal,

i.e., whether the action actually occurred, was ordered or just serves as a crite-

rion for further acts, respectively. As regards the compatibility with the WOAD

constructs, the RIM moods can be either referred to a particular internal state

of a w-activity-fact (e.g., an ordered act corresponds to an enabled activity-

fact), they can be expressed in terms of relationships between entity-facts or,

as trivial but effective solution, they can be rendered as additional properties

of a corresponding RIM-compliant w-activity-fact.

7.1.2 The clinical record model

Based on the RIM, the CDA document markup standard defines how electronic

health care information can be consistently represented in structured docu-

ments for the purpose of exchanging information, both from the structural

and semantics point of view. CDA documents can consist of several sections,

which themselves consist of several information entries.

179


Figure 7.1: The reference information model (RIM) as the core piece of HL7 mod-elling.

The driving force behind the development of the CDA specification has

been the need to standardize the narrative flow of clinical statements that are

recorded within almost any clinical report. This would allegedly enable com-

parison of content from different documents created on information systems

of widely varying characteristics and hence foster medical and epidemiological

research as well as a more efficient hospital management and quality control.

Our aim has been that of taking this specification, which has been man-

ifestly devised for other purposes than the direct management of illness tra-

jectories3, and see whether such a model could harmonize with a framework

which has been conversely devised to make the coordinative nature of records

explicit and to support it by means of the very same documental artifacts.

The case of the CDA has provided us with an interesting example of how a

domain-dependent model can enrich4 the WOAD model by providing a set of

concepts and attributes that specify some specific aspect of the setting at hand.

To give a highly significant example, the CDA specification permits any act

reported in a compliant document to be related to any other act by using any

of the enumerated relationship types. In this way, clinical record entries can

be cross-referenced by their compiler so that data can act either as descriptiveor perspective information, i.e., to inform readers about both the causes for the

execution of some task and the intentions expressed by the record compiler.

Figure 7.2 shows a subset of the allowed relationship types, along with source

and target acts that might be reasonably put in relationship through them.

The way domain-specific relationships are mapped into WOAD relation-

facts is often a mere matter of taste, but some application-centered choices can

3In the literature such other purposes of the clinical record are also called ‘secondary’ [Mannand Williams, 2003]. The primary purpose is to support direct patient care both by aidingmedical decision-making and by “ensuring continuity of care by all providers” (cf. the JCAHOdefinitions at http://www.jointcommission.org). Secondary purposes pertain to the sphere ofthe archival functions of records.

4In the sense of specializing.

180


Figure 7.2: Some CDA relationships between act-related entries. From [Dolin et al.,2006].

also be affected by the description granularity and, above all, by the require-

ments that have been collected from the observational studies. In our case, for

instance, while some ActRelationship has been considered as WOAD relation-

ship between w-activity-facts (such as the SAS – starts after start, and

COMP – has component ones5), we preferred to represent some other CDA

relationships in terms of relation-facts between documental entries, i.e., be-

tween document-facts: namely, the CAUS – is etiology for, the MFST – is

manifestation of, the RSON – has reason) and the SPRT – has support

ones.

We have in fact questioned ward practitioners on the crucial point of data

correlations (see Section 3.3.3): we have asked them which kinds of relation-

ship they would more naturally employ to join two or more data that are not

explicitly correlated by the clinical record structure (or even implicitly, by dis-

playing them on the very same sheet). Then, we tried to understand which

CDA relationships semantics was more “easily” grasped by the average ward

practitioners, i.e., irrespectively of either their experience, profession or role.

The result was that practitioners found more natural to consider relationships

as occurring between data entries, either already recorded or still to record on

5Specifically the COMP relationship is natively supported by the belongs-to WOAD rela-tionship.

181


the clinical record. In the former case, they pointed out the usefulness to re-

late data over distributed and different artifacts; while in the latter case, they

referred to the capability to draw relationships between data values (and the

corresponding documental and work activities) and fields yet to fill in, hencewith the corresponding work activities still to carry out.

In other words, clinicians seemed to understand and accept the general

tenets behind the CDA relationships, but seemed more prone to consider

them applicable to outputs of acts (still data), rather than thinking in a

strictly process-oriented manner. For instance, an examination can certainly

give sound motivation for a drug administration but yet — by a pretty obvious

metonymy — physicians preferred relating the very result of the examination

as it was reported in the referral sheet with the very sign that on the Single

Pharmacological Therapy Form (see Section 6.3.7) denoted the prescription

order.

In all these cases the WOAD language exhibits the important characteris-

tic to be “neutral” with respect to the semantics of other models that extend

(i.e., employ) its formal constructs. In fact, the source and target attributes of

WOAD relation-facts have been purposely conceived as not typed, in the sense

that their value domain and abstract type are not formally explicit. This means

that once the designer has defined domain-specific relationships as extensions

of the WOAD relation-fact, it depends on the mechanisms definition whether

a relationship applies only to a class type or not. Neutrality is an important

requirement to claim the portability of our framework also into other docu-

mental domains than the clinical one, that is leveraged by the malleability of

WOAD mechanisms. This property has allowed us to tune some awareness

providing mechanisms depending on the use we observed on the choice of the

most appropriate CDA relationship.

7.1.3 Downscaling the CDA model

At the end of some working shifts, immediately after the handing-over confer-

ence, we asked different practitioners to try to relate the most relevant notes

and entries they recorded during their work with other entries pertaining to

other sections of the same clinical record, both past and expected entries. This

task was proposed to actors that for their formal duties were already supposed

to be prepared for reporting any relevant data on current inpatients. We ob-

served that subtle yet important differences between CDA relationships tended

182


to blur when they were applied into three main categories: causal, temporaland intentional correlations.

The generic semantics pertaining to the nature of relationship between

a source and a target information can be respectively rendered as (a) “the

source because of the target”, in the sense of strict causal relationship; (b) “the

source after the target”, not only in strict temporal sense, but also to hint a

very weak or just supposed causal relationship; (c) “the source for the target”,

in the sense of supporting evidence for a decision or making explicit an inten-

tion. We see those correlations as specifications (or, better yet, as extensions in

the sense so far considered) of what in Section 3.3.3 we called “correlations

between supplementary data”. In fact, each source and target information can

be seen as supplementing the other, i.e., as adding a semantic nuance that, in a

particular context, mutually completes or reinforces the meanings of the cor-

related data (cf. the concept of positive redundancy mentioned in Section 3.3.3

and in [Cabitza et al., 2005b]).

We collected several evidences that the intended use by doctors of such in-

dications on those supplementing correlations was to provide their colleagues

with accounts of occurred events as well to give them motivational and in-

tentional information, rather than strictly coordinative orders. The latter were

rather embedded in the rigid structure of forms and the prescriptive nature

of the conventions pertaining to their compilation. On the other hand, inten-

tional and motivational correlations regarded more descriptive conventions

by which clinicians used to commit colleagues on due next activities, and give

them rationales to adhere convinced to some clinical line of actions.

In that perspective, we provided the setting’s doctors with the domain-

specific relationships of the CDA specification as a “standard tool” that could

be used to make self-evident the interconnected nature of all clinical events

from the raw and isolated entries of the whole bunch of sheets pertaining to

the same inpatient’s stay. Since the CDA does not give a precise semantics of

their constructs and we could not rely on a formal reconciliation between the

ward jargon and the CDA lexicon, we often saw doctors to idiosyncratically as-

sign relationships a meaning according to the content which they applied the

relationships to. This situated practice could seriously hinder any application

that operationalizes relationship types according to their formal specification,

but yet, it is particularly well fit by the generality and parametric nature of

WOAD mechanisms. In fact, WOAD conventions — and their operationalized

183


mechanisms — are content-driven, both as regards the time of occurrence

(i.e., when they have to be executed) and their effects (i.e., relating to what

they have to produce). For instance, let us consider the case of the SPRT re-

lationship, “it has support”. The CDA specifies that such relationship should

be used to show that the target entity provides “supporting evidence” of the

source entity. Yet, for either a poor translation or little knowledge of think-

ing in terms of support, doctors indistinctly used it to indicate a correlation

between diagnostic hypothesis (when they did it right) as well as between

acts (in the acceptation of “serving”, “being of use”). A mechanism of inter-

action that would rely just on the “label” SPRT would probably fail to convey

the right awareness information, while mechanisms that are sensitive to even

generic relationships between, e.g., the documental entries regarding “patient

sedation” and “biopsy performance” would be less sensitive to linking errors

or misunderstandings.

7.2 Application of WOAD to the case study

As said in Section 6.1.2, what is written on a document of the clinical record

does not inform just by itself, but in virtue both of the local rigidity of the

document, and of the document’s property to cross-refer readers from one of

its parts or sections to other documents and their parts. We also said that

this cross-referencing capability is fluid, to refer both to the Levy’s contribu-

tion mentioned in Section 2.3 and to its capability (and requirement) to have

cross-references reconfigured according to the informational needs of the con-

tingent situation. Here, we also make a point about the fact that such cross-

references can be either implicit or explicit, they are not fixed in any ad-hoc

structure and are only drawn if ever and whenever needed.

In the case such correlations are implicit, practitioners give them for

granted as conventionally acting between fields, sections or even modules of

different documents compounding the same clinical record, irrespective of the

inscriptions that those documental portions can host in practice. Conversely,

we speak of explicit correlations whenever practitioners someway drew and

made explicit them, to relate either fields across different documents or actual

values, depending on situated needs and clinical contingencies. We purposely

used the vague adverb ‘someway’ since, for the illustrative purpose of showing

the potentiality of the WOAD notation, it does not really matter how these cor-

184

7.2. APPLICATION OF WOAD TO THE CASE STUDY

relations among clinical data are made explicit but that they are represented

in some symbolic structure.

7.2.1 From practices to language constructs

In our observation of the ward paper-based practices, we have seen clinicians

making correlations across documents explicit in a number of ways, depending

on either personal idiosyncrasies or incidental conveniences. Some clinicians

used to jot down brief annotations, beside the fields or inscriptions to cross-

refer, mentioning what to refer to and where it was. Others used to either draw

a line, an arrow, connecting the related pieces of information, especially when

they were on the same sheet. Or to mark a couple of asterisks on the fields or

inscriptions to relate. In many cases, also, nurses and physicians explicitly put

data in some relationship by writing dedicated entries on their daily notes.

Flanking a documental prototype

These observations as well as the related comments we collected during the

scheduled interviews were very useful in shaping the prototypal mechanisms

by which to illustrate the WOAD-based support within a real technological

domain. For our “experimental” sessions with some key actors of the ward

personnel6, the Neonatology ward management put at our disposal a web-

based electronic patient record that the head physician commissioned approx-

imately one year earlier to a small local IT firm that had been providing the

ward with a number of smaller and task-specific applications during the last

ten years. By leveraging on the long-time acquaintance and acquired familiar-

ity between the designers of the small firm and some of the physicians work-

ing at the ward, a full-fledged prototype of clinical record was built to allow

for incremental improvements and further validation by the hospital manage-

ment. For interoperability issues and other red-tape hindrances at the whole

hospital level, such prototype was never amended and failed to be fully de-

ployed at the ward but nevertheless it constituted an ideal platform on top of

which we could conceive and illustrate the awareness-providing mechanisms

6Actually those meetings with some selected members of the ward staff were more an oc-casion to exchange comments, criticisms and proposals while tweaking with a provisional andyet-to-deploy computer-based documental platform (see next). They were neither experimentsin the strict sense of the word nor validations of WOAD implemented features, but rather justoccasions to exchange opinions with the pretext of having some computer-based application totrifle with.

185


Figure 7.3: A screenshot of the prototypical Neonatology Electronic Patient Record

and data-structures to their intended beneficiaries in terms of “mocking up”

sessions.

In such computer-based practice sessions, we tried to evaluate how prop-

erly the conventions we observed in our field studies were rendered into

WOAD mechanisms that were calibrated on the prototype’s structured pages

and on the model of ward activities expressed in terms of L*WOAD constructs.

An interesting fact we observed during such sessions was exhibited by users

when they showed a clear interest in the capability of selecting fields and

inscriptions in any “screen” of the current patient record (see Fig. 7.3) and

of associating them with either some WOAD-predefined relationship or user-

defined ones. This informal and functional requirement led us in formalizing

the general and conceptual requirement of fluid cross-referencing mentioned

in Section 6.1.2 for the intended WOAD prototype.

When we enabled such functionality, actors found convenient to select the

most suitable predefined supplementary correlations from a cascading menu

(see Section 7.1.2 and 3.3.3). When they did not find any correlation precise

enough to denote the intended relationship that they wanted to draw between

record entries, they appreciated to be able to select a user-defined relationship,

that they were asked to characterize by filling a free text description field.

186


These observations led us to collect a number of interactional require-

ments that the full-fledged electronic documental platform should satisfy both

to make secretarial work by clinicians smoother (see Section 3.3.3), but also

and above all with respect to the WOAD requirements, to make the construc-

tion of conventional mechanisms on the clinicians’ cooperative needs easier

and more effective. These requirements are not to be intended as valid just

for the clinical application at hand or for the clinical ward we studied, but

they can also be made more general by correlating them to the main dimen-

sions of functionalities exerted by documents: archival and articulation (see

Section 2.3) and to the main WOAD awareness typologies that we have briefly

outlined in Section 5.2.

Such requirements can be summarized in the following enumeration:

• Function of alerting actors about data previously inserted by other ac-

tors, regarding either inconsitencies/errors or suggestions for their cor-

rection. This functionality can be harked back to the requirements per-

taining to the archival dimension of the record at hand (see Section 2.3)

and to the provision of either alerting, inconsistency or amending aware-

ness.

• Function of highlighting7 data values that could be useful for the users

to consider, so as to provide them with awareness information about

linkages with other data and well characterized relationships between

what they write (or are about to write) and other data written in the

past or by other people. This functionality pertains to the articulation

dimension of the record at hand. In fact, it is aimed at supporting the

task of making sense of what is recorded and is correlated by means

of the provision of explanatory, inquiring and provisionality awareness

information.

• Function of highlighting data fields that users must fill in during a given

documental activity (e.g. error-free form compilation); and the corre-

lated function of providing users with information about the reason and

way the form completion must be done. This functionality pertains both

to the archival and articulation dimension of the record: the former ben-

efits from a higher data quality (i.e., more complete records, more accu-7Highlighting seems an important requirement even in paper-based domains. As also Luff

et al. [Luff et al., 1992] report, doctors have been often observed underlining or marking textwith color pens in records to alert colleagues to irregularities in treatments.

187

fede

Note

forse anziché provisionality è "browsing"


rate data), while the latter benefits of a support to documental activities

that have some priority over others. This functionality also regards the

inconsistency and amending awareness types, as well as the, explanatory,

browsing and inquiring awareness ones.

• Function of highlighting data fields so that the activities associated with

those fields are suggested as possible choices; in addition, in the case

none of the suggested activities is selected by actors, then occasion for

justification would be prompted to them. This functionality clearly re-

gards articulation of tasks: in fact, by the proper highlighting of fields a

corresponding flow of work is suggested to actors — even within a de-

scriptive rather than prescriptive dimension. Moreover, even when the

“flow suggestion” is disregarded by actors, a justification is requested in

order both to increase the accountability of the accomplished deeds and

to provide colleagues with the rationale of the deviation from conven-

tional or purely routinary work trajectories. This functionality regards

the enabling and inhibition awareness.

In the following, we will leverage on these interactional requirements as

regards the outputs of the cooperative layer of the documental application

we take as reference, as well as on the capability to define and characterize

correlations among data at run-time and on-the-fly, as an additional input

capability of actors within the field of work besides the obvious capability of

writing data on the forms compounding the clinical record.

Once the front-end has been realized as capable of fulfilling these minimal

requirements, we can revert to the back-end side of the cooperative applica-

tion enabling the above mentioned documental application with awareness-

provision and task-alignment capabilities.

The task of the designer at definition time is then that of conceiving and

composing conditional context and data-driven mechanisms by which to ren-

der in computational manner some of the conventions applying in the coop-

erative arrangement within and about documental activities, so as to provide

actors with relevant information while they gain access to and write docu-

ments in their daily tasks.

Such mechanisms apply to data as these are recorded into the documen-

tal system through pattern matching. Designers can conceive them to support

actors in both properly compiling the forms and in becoming aware of partic-

ular conditions and contextual correlations that their colleagues have tried to

188


“package” all together with the data written. This relates hence to the premises

that such mechanisms are sensitive to, i.e., to their antecedent side. In the an-

tecedent side, patterns are matched with the current content and state of the

fact space. On the other hand, awareness provision capabilities, as well as the

capabilities dedicated to update the documental content and the work context

are managed in the consequent side of such mechanisms.

7.2.2 Supporting clinical coordination

In this section and the following ones, we will see how designers of the co-

operative layer depicted in Fig.3.9 can properly (1) model a document-based

work arrangement by means of the WOAD model and language and then (2)

build mechanisms that express awareness-related conventions.

Such awareness-related conventions will regard, in order of exposition:

• The locally rigid structure of documents, i.e., their structural relation-

ships and their data schema8). In the following we call them structure-

related conventions (and corresponding mechanisms).

• The documental content those documents can refer to. We call them

content-related mechanisms.

• The relationships that users either implicitly or explicitly consider be-

tween different documents’ sections and their data. We call them mech-

anisms on web-spanning correlations.

Each of these three cases, even the structured-related and the content-

related ones, concern the whole representation of the context2 rendered

within the fact space, and hence also the contextual information regarding

the work setting at hand. Indeed, the antecedent part of any mechanism can

be seen as a way to make explicit a tie between any otherwise uncorrelated

contextual element, and hence as a way to relate textual context and work

context (the reader can still refer to Fig. 3.2).

8With ‘schema’ we naively refer to what in the Data Base literature (e.g., [Batini et al.,1992]) is usually associated with such term: properties that regard attributes of entities (in ourcase, documents and their fields), the data types such attributes can contain and the formalconstraints on those data types, without any reference to the semantics of data therein repre-sented. In other words, we refer to conventions regarding both how data are organized withindocuments (structure) and which instances of the defined structure are allowed (syntactic in-tegrity).

189


For each of these cases, we will take our observations and field require-

ments as starting points for presenting the illustrative case in which a generic

designer has to apply the WOAD framework to a cooperative arrangement in

the light of the requirements she has previously collected from the intended

users of the documental application.

In order to illustrate how a generic designer could set up the process of im-

plementing a WOAD-compliant application, let us consider an aspect of clini-

cal work that both our observations and the spontaneous accounts we heard

from the interviewees have pointed out as the crucial aspect of document-

mediated ward coordination9: the so called “Physician Order Entry” (POE).

Order assignment and commitment

The POE denotes the general process in which doctors give orders about the

main interventions that a patient must undertake to recover and have her

health problems solved10. In the specialistic literature, many contributions are

investigating whether the introduction of Information Technology in the POE

brings more benefits than drawbacks, once that all stakeholders at hand have

been considered (e.g., [Ash et al., 2004,Aarts and Berg, 2004]). At the present

time, there is no general consensus on the best approaches to many of the

challenges that changing the traditional, paper-based order entry presents (cf.

e.g. [Kuperman and Gibson, 2003, Koppel et al., 2005, Beuscart-Zephir et al.,

2005]). Basically, computer-based POE (also acronymized to CPOE [Group,

2000]) supports physicians in preventing adverse drug events in hospitalized

patients by reducing errors related to handwriting or transcription and by au-

tomatically checking entries for duplicate, incorrect doses and incompatible

ways of administration. This picture can be even more complicated by verifi-

cation tools that match prescriptions with either clinical guidelines and proto-

cols or with the particular case that is represented within the rest of the clin-

ical record (e.g., by taking into account the current patient’s idiosyncrasies,

allergies and temporary impossibilities).

Generally, orders can be given about two main classes of interventions on

9The other main coordinative moment within ward work is represented by the handing-over conferences between shifts. As we have reported in [Cabitza et al., 2005b], clinicians thatare going off-duty do use the documentation to recollect relevant events and data to refer totheir colleagues going on duty but this task is not properly mediated by documents, since suchconferences are always vis-a-vis, co-located meetings where clinicians mainly rely on directconversation.

10Cf. the problem-oriented approach to clinical documentation mentioned in 6.1.2

190


patients: interventions directed either to (a) accomplishing diagnostic assess-

ments or (b) to steering therapeutic regimens (i.e., drug administration). For

the former class of interventions, orders usually regard a composite process in

which nurses or other clinicians have (1) to coordinate with an external ser-

vice (e.g., another hospital department or facility, the referred specialist) (2)

to prepare the patient both physiologically and psychologically (e.g., by having

her fast before the examination or by thoroughly informing her, respectively);

(3) to manage the return of the patient and the requested medical reports

so that the collected evidences can trigger further diagnostic and therapeutic

interventions.

For the class of therapeutic interventions the schema is pretty similar, com-

prising (a) the preparation of the drug and possibly of the patient (e.g., by giv-

ing her a gastroprotector) (b) the drug administration (c) the continuous mon-

itoring and management of any reaction to the administered therapy. From the

point of view of the supporting documents, ordering diagnostic interventions

is mediated by two specific sheets of the clinical record: the Single Laboratory

Examinations Form (SLEF) and the Single Diagnostic-Therapeutic Procedure

Form (SDTF); for the drug prescription, clinicians refer to the Single Pharma-

cological Therapy Form (SPTF) (see Section 6.3.7).

The POE, hence, encompasses two different “moments” within the official

interaction occurring between the two main roles acting in the ward, doc-

tors and nurses: namely a coordinative and an awareness time (cf. [Simone

and Bandini, 2002]). In the coordinative time, doctors commit and delegate

nurses to accomplish an intervention on the patient and nurses make them-

selves responsible for that intervention be executed as doctors expect to; in the

awareness time, nurses give doctors feedback on the completion of the related

task, thus enabling those activities that were waiting for the order execution.

In the following, we will outline how a designer could conceive proper

mechanisms to support both the above mentioned moments with the provi-

sion of context-driven awareness provision, basing our illustration on the con-

ventions we collected about the use of the single sheets, the problem list and

the physicians’ notes from the analyzed clinical record (see Section 6.3 for a

description of such artifacts).

191


7.2.3 A small step methodology

The preliminary step for the definition of all kinds of WOAD mechanisms re-

ferring to the clinical record is to define a data structure for each document

compounding the clinical record at hand and then to likewise characterize the

main resources that have to do with those documents and the activities in

which they do.

To do so, the designer calls the define primitive on the data structures

that specify how the single sheets are rendered by the documental application

on screen11. In so doing, she creates a document-fact whose content property

contains a nested frame structure in which each entry of the form is rendered

as a terminal element of an arbitrary deep tree-like structure. The general

case of CDA documents encompasses a three-level nested structure in which

a documental body is composed of multiple sections, each section is composed

of either multiple paragraphs, lists or tables and each of these of multiple en-tries. Since mechanisms must be sensitive to the value of single fields — since

so do conventions — it is important that the chosen data structure could be

referenced with the proper degree of granularity.

For example, the define primitive called upon the Single Laboratory Ex-

amination Form (see Fig. 7.5) would generate a template that the designer

has just to fill in when she will have defined the other entities involved. In the

following example, we see the document-fact template defined in Fig. 5.6, and

recall that the web-name attribute indicates the web of documents that the de-

signer is modelling and that the parent-fact attribute reflects the hierarchical

structure of the model regarding the entity at hand.

(Document-fact

(name SLEF)

(description "Laboratory Examinations

Form")

(web-name "Manzoni-Ward")

(parent-facts [entity-fact], [woad-fact])

11The data structures defining this representational aspect of the web-based clinical recordwe considered were XML files. According to the CDA specification and other HL7 standardsfor clinical interoperability all parts of the electronic patient record should be specified bysome XML files and this recommendation is generally followed by the majority of the domainvendors. This would also allow designers of the higher-level layers of a cooperative applicationto abstract from the back-end technicalities and even from the data representation details of thedatabase level, and therefore to focus on the structure and content that actors would directlyinteract with.

192


(access-rights <roles-to-define>)

(content <tree-structure>)

(conventions <rules-to-define>)

)

According to the internal structure of the content frame, the L*WOAD in-

terpreter would also create a number of d-activity-facts that correspond to the

leaf elements of the tree-structure. For example (with respect to Fig. 7.5):

(D-Activity-fact

(name SLEF-orders-filling)

(description "Action of writing in an exam row of the SLEF")


(parent-facts [Entity-fact],[woad-fact])

(input (SLEF (body (section prescription (table exams (entry ‘EMOCROMO’))))))

(output (SLEF (content (section prescription (table exams (entry ‘EMOCROMO’))))))

(time <time-stamp>)


)

Document-facts and corresponding d-activity-facts represent the structures

regarding the textual aspect of the WOAD context2 (see Section 3.2). The next

steps regard hence the characterization of the work context in terms of roles,

actors and work activities; the last step regards the definition of the relation-

facts that put in the belong-to relationship w-activity-facts and d-activity-facts

(see Section 5.1.2).

After have defined the documents on whose content the mechanisms will

apply, the designer has then to consider which actors can have something to

do with such forms during a typical hospital stay. Consequently, she creates an

entity-fact for each person that could sign and consult the forms at hand.

How to manage roles within the WOAD framework depends at greatest

extent on the peculiarities of the domain at hand. As a general rule, roles in

the acceptation of institutional functions and appointments — also, job titles,

i.e., what in the HL7 RIM is denoted by the Role construct — can be rendered

as entity-facts. For our illustrative purposes, just two roles could be factualizedinto the Doctor and Nurse entity-facts. By exploiting the extendibility of the

entity-fact construct, then, each employee working at the hospital ward could

be represented as an entity-fact that extends either the doctor entity-fact or

the nurse one.

193


In the following examples, we see the pay slot as an exemplification of

some administrative information that regards the role level and that hence

will be inherited by the actors that are assigned to that role, e.g., the personal

fact of Dr. Gregory House. Other actor-level attributes characterize personal

facts of the Manzoni ward employees.

(Entity-fact

(name doctor)

(description "Role of any doctor at the ward")


(parent-facts [person],[entity-fact],[woad-fact])

(pay "30 000 euro")

)

(Entity-fact

(name "Gregory House")

(description "Personal file for an actor")


(parent-facts [doctor],[person],[entity-fact],[woad-fact])

(address "S Broadway, Tarrytown, NY 10591")

(phone-number "914 302-4521 571" )

)

For roles that people can dynamically play according to the situation within

a certain task — what in the HL7 RIM is expressed by the participation class,

the designer can employ particular relation-facts, e.g. denoted by a “plays-

in-as” label, that relate an actor entity-fact with some w-activity-fact at in-

stance level. For instance, in a handing-over conference — which for some

application-level requirement could be rendered as a specific w-activity-fact —

the going-on-duty nurse and the going-off-duty nurse would play two different

and corresponding temporary roles, while they both keep being “nurses”12.

Once that also institutional roles have been defined, the designer has to

consider which tasks and activities each role can be responsible for. For each

activity, she defines a corresponding w-activity-fact and binds it to the role

entity-fact by means of the responsibility attribute.

12This kind of roles cannot be rendered as specialization of institutional roles. In fact, it isnot always feasible to establish all these roles at definition time but that notwithstanding singleactors need to be defined as extensions of roles so that conventions that apply to roles can alsobe propagated to the actors that play them.

194


In the following example we see the exam prescription activity that is as-

signed to the doctor role.

(W-Activity-fact

(name exam-prescription)

(description "Task in which some orders are given")



(responsibility doctor)

(internal-state <internal-state>)

(precondition (preliminary-examination (internal-state completed)))

(effect (exam ordered))


)

If the application domain requires to formally describe the articulation of

work activities, i.e., how such activities can follow each other, also the pre-condition and effect attributes of each w-activity-fact would be filled in with

conditions on the execution and enabling of the other peer activities. In the

example above, the designer has defined that the exam-prescription is enabled

only after that the preliminary examination has been carried out (see the

precondition slot). Likewise, by means of an work-related convention, she

could express that the activity of exam preparation would be enabled when-

ever an exam-prescription has been carried out. See the slot conventions in

the following example:

(W-Activity-fact

(name exam-preparation)

(description "Task in which the patient is prepared for some exam")



(responsibility nurse)

(precondition (exam-prescription (state completed)))

(effect (patient (ready true)))

(conventions

(convention-fact

(name transition-to-enabled)

(condition (w-activity-fact

(name exam-prescription)

(internal-state completed) ))

(action (w-activity-fact

195


(name exam-preparation)

(internal-state enabled) ))))

)

Then, for each definite piece of work represented by a w-activity-fact, the

designer considers which documents are supposed to be consulted and likely

to be also edited during that activity. For each document or documental por-

tion that is thus considered, she creates a belongs-to relation-fact that binds the

w-activity-fact with the corresponding d-activity-facts having those portions as

either input or output.

(relation-fact

(name belongs-to)

(description "inter-activity relationship")

(relation-level class)

(source-entity SLEF-orders-filling)

(target-entity exam-prescription)

)

In Fig. 7.4 we see what the designer has so far modeled of the ward domain

to represent by means of the WOAD static constructs.

Figure 7.4: A graphical representation of the entities and relationships involved in theillustrative example.

7.2.4 Structure-related L*WOAD Mechanisms

As mentioned in Section 6.3.7, all single sheets mediate clinicians’ interactions

by means of conventions related to particular areas of the documents that only

196


doctors and nurses are supposed to compile for, respectively, order entry and

task confirmation. We call this kind of conventions structure-related and will

be the first we will give some examples in terms of mechanisms. For example,

boxes d and e in Fig. 7.10 represent the prescription and the administration

sections, with exclusive access by doctors and nurses, respectively; while box

d and n in Fig. 7.5 represent where doctors and nurses compile laboratory

prescription entries and confirmations, respectively.

For the sake of illustration, let us suppose that the designer wants to con-

struct some mechanisms that follow the well-established conventions regard-

ing which checkboxes are filled in and in which order they are on the Labora-

tory Examinations Form13 (SLEF — see Fig. 7.5). This spatial and temporal

order does not regard an aesthetic or qualitative requirement but conveys a

clear coordinative meaning in that the proper form compilation triggers mul-

tiple tasks, from having a blood sample be taken, having it sent to the hospi-

tal laboratory and having a referral be sent back by the laboratory staff with

the needed results. Consequently, these mechanisms will be conceived to ex-

press in a computational way which are the entangled conventions of proper

compilation and cooperative use of the form; as well as to render awareness

information on to-do tasks and priorities that can be triggered by that form.

The reader can refer to Section 3.4.2 to be recalled on which kinds of con-

ventional knowledge the WOAD framework focuses on. In terms of L*WOAD

constructs in which such conventional knowledge is conveyed we have now to

consider which mechanisms regarding the “proper filling in” will be included

within the conventions attribute of the SLEF document-fact that the designer

has defined in the previous section. That attribute pertains to the conventions

that directly refer to the document at hand. The awareness-related mecha-

nisms will be rendered as convention-facts that in their antecedent side will

refer both to the SLEF document and some awareness-fact management (def-

inition, assertion or deletion).

The case

Let us now refer to Fig. 7.5, representing the actual form on whose structure

coordinative conventions apply. Each prescription is represented as the inter-

13The very same thing holds also for the other two single sheets above mentioned. Indeed,the steps that we outline in the following can constitute a pretty schematic methodology for thedeployment of a WOAD-compliant system with respect to all the observed documental artifactsreported in Chapter 6.

197


Figure 7.5: A snapshot of the Laboratory Examinations Form (SLEF). An area forprescribing only three typologies twice (e1 and e2) is brought into close-up, for room’ssake.

section between the rows denoting a particular examination and the couple of

columns (denoted with e1 and e2 in Fig. 7.5) indicating the main tasks regard-

ing examination according to the ward perspective: ordering and completing

them. The doctor that requires a laboratory examination for a patient is sup-

posed to put her initials on the corresponding field denoted as ‘RIC’ (request)

and to record date and time of the request (in the figure, ‘Data’ and ‘Ora’ fields,

respectively). Additionally, she is also supposed to indicate whether the exam-

ination is urgent (denoted with a capital U) or the blood sample can be taken

and sent to the laboratory with all the other routinary examinations, usually

the next day early in the morning. In this latter case the physician ought to

write a capital R (for ‘routine’) in the corresponding field. Obviously, the indi-

cation ‘routine’ is the conventional default value, and, accordingly, for routine

examinations the physician is usually exempted from marking the priority and

time fields (see box a in Fig. 7.5).

The coordinative convention here is that orders are officially committed as

soon as initials are signed in the field RIC of an exam row: in that moment,

nurses become in charge of preparing patients; take blood samples, book the

examinations to the laboratory facility; get from that facility an order ID; as-

sociate test tubes with correct stickers; have those material sent14 to the lab;

14Usually specific assistants are in charge of transporting blood samples to the laboratory at

198


and organize returned reports and results into a specific referral box at the ad-

mission desk of the ward. Nurses are supposed to give written confirmation of

order execution into the ESEG field (‘ESEG’ stands for ‘executed task’), as soon

as they know samples have been successfully received by the laboratory facil-

ity. In so doing, the on-duty doctor (not necessarily the same ordering doctor)

can15 consult the referral box, take the examination, consult it and afterward

file it in the correct patient record. The process is considered completed when

also the doctor acknowledges the test results putting his full signature in a

particular field; this is reproduced at the bottom of each RIC-ESEG pair of

columns of the SLEF with the function of encompassing the whole battery of

tests of a given day (N.B. that signature field is not represented in Fig. 7.5).

Mechanisms on proper compilation

From evidences collected in our field studies, we can exemplify the designing

of structure-related conventions by outlining three mechanisms for the proper

compilation of the SLEF: those regarding the conventions that (a) only doctors

can put their initials in the RIC field and only nurses can sign the ESEG field;

(b) the ESEG field can be compiled only after the corresponding RIC field has

been, and also after that the blood samples have been taken and sent to the

laboratory16; (c) when an examination is deemed urgent, the doctor should

also fill in the time field or, at least, warned to do so. Obviously, there are

no impediments to conceiving a single mechanism that encompasses all these

aspects, as well any other, regarding the proper compilation and coordinative

use of the form at hand but it is also good designing practice advocated by

the WOAD framework to separate work-related concerns and hence to design

smaller mechanisms addressing each a specific concern.

As regards the latter convention, making date and time mandatory fields

of the form in any single case would end up by nagging doctors, especially in

those cases that examinations are really urgent either to stabilize a patient or

begin as soon as possible a life-saving treatment. That notwithstanding, if an

examination is deemed as urgent, prescription time is a useful indication to

timely urge the laboratory in case of even slight delays on expected schedules.

predetermined hours in the morning.15Here again, we stress the different degree of prescriptiveness conveyed by the signs re-

ported on the SLEF: coordinative for nurses and awareness for doctors.16Provided that the dispatch information is made available in the hospital information system

and consequently factualized in a corresponding contextual information.

199


For this reason, a proper mechanism must be capable of distinguish these two

cases of priority, not only on the basis of the mere syntactic indication U or

R but also depending on the priorities of current work activities in execution

— i.e., the so called work context — and reminding the ordering doctor at

need.

An important point about the applicability of WOAD mechanisms to forms

is that they are parametric as regards the contextual conditions they are sen-

sitive to and that they apply to contextual elements by pattern-matching. This

means that the designer does not have to write a mechanism for all possible

blood examinations that are currently included within the SLEF, once that a

general pattern has been conceived that can match with any of them; it also

means that she does not have to worry about possible additions or modifica-

tions to the form, if the latter ones do not regard the very structures referred

within the mechanisms by means of the conceived patterns.

On the proper role

The basic mechanism that checks that the proper role has gained access and

updated the SLEF according to her access rights would have in its antecedent

patterns that (a) match the content attribute of the SLEF document-fact; (b)

match a d-activity-fact that has in its input (or output)17 the same instance

of document-fact (or part of it); (c) match an actor entity-fact that is an ex-

tension of the role entity-fact that is represented in the access-rights attribute

of the document-fact18 and whose name attribute corresponds to the executorattribute of the above mentioned d-activity-fact.

In the exemplification depicted in Fig. 7.6, we represent the patterns that

express the above mentioned “logic” and point out the parametric nature of

WOAD mechanisms: the reader should not consider it a digression to some

language technicality or particular syntax, but yet see it as a convenient way

to illustrate the pattern-matching rationale of WOAD mechanisms. Each pat-

tern is a partial data structure with unbound variables, which we indicate with

a letter preceded by a question mark (?); by matching the facts within the fact

space, variables bind themselves with each value that makes the pattern true;

in Fig. 7.6, bindings between patterns’ variables are indicated with small geo-

17We mean input or output according to whether the role has gained accessed or updatedthe form, respectively.

18The match would be between the access-rights property and document-fact and the parent-facts property of the entity-fact.

200


metric figures for clarity’s sake. The convention template is further commented

by interlinear comments preceded by a semi-colon (;) and intended to make

the mechanism’ internal logic clearer.

Figure 7.6: WOAD mechanism for a convention on the proper role.

As mechanisms’s antecedents can reflect different application-level re-

quirements and conventions with additions to the basic mechanisms we have

above outlined, likewise also to decide which kind of awareness information

the designer should define and assert in the awareness section of those mech-

anisms’ consequent is a pretty arbitrary task. In the case a mechanism has

detected either an inconsistent state (e.g., a request date that is in the future,

or an ESEG field filled in before a RIC one) or a situation that is convention-

ally deemed as faulty (e.g., an urgent request that is not processed within a

certain lapse of time), awareness information could range between a grinding

halt (e.g., alerts that require some amendment before further processing) or

mild reminders that summon for further, but voluntary, verification. To make

an explicit reference to the options provided by L*WOAD and surveyed in Sec-

tion 5.2, we correlate the mechanism depicted in Fig. 7.6 with the provision

of inhibition awareness.

201


On the proper order

The mechanism that checks whether fields are compiled in the correct order

(e.g., RIC first and then ESEG) is represented in Fig. 7.7: its antecedent part

contains a logic expression that evaluates that a RIC field has been previously

compiled (i.e., it is not empty) when the corresponding ESEG field is still to

be compiled. Obviously, even such a simple mechanism can contain further

conditional elements to represent conventions on the regular flow of tasks.

For instance, as we hinted above, some clinicians we interviewed drew our

attention on the necessity that all nurses follow the convention to compile the

ESEG field only after that they receive a dispatch receipt from the laboratory,

or at least, after having had really taken the blood sample from the patient.

Sometimes, conversely, nurses were used to fill in it at the time they prepared

the syringes for each patient, as a sort of to-do list. Unfortunately this practice

could eventually result in a number of misunderstanding and coordinative

breakdowns if for any reason the blood test could not be actually accomplished

(e.g., for indisposition of the patient). In this case, conventional mechanisms

can act as learning devices to instruct practitioner on the virtuous way to intend

the form structures and to grasp the intended meaning of the field ESEG (the

same argument was made at the beginning of Chapter 3).

In the following example, we see that this virtuous convention can be

represented by two w-activity-facts, expressing respectively the examination

booking and tube dispatch, triggering the corresponding mechanism when

their internal states are both completed. It is not necessary to explicitly express

the virtuous flow of work, in terms of preconditions and effects between those

activities and the work activity to which the compilation of the ESEG field be-

long. The mechanism triggering conditions emerge from the global state as it

is represented within the fact space so that next activities are enabled (their

facts being put in the enabled state) and proper awareness information pro-

vided to the involved actors accordingly19. The awareness information that the

consequent of such mechanism can provide actors with is a coordination one

since doctors rely on the ESEG marking to know when to access the referral

19In the example depicted in Fig. 7.7 and the following ones, we use a positional notationto indicate the elements of the documental content structure. The explicit, but yet conven-tional, reference is to the CDA specification, where the body of the document contain multiplesections, section can hold either rows in the case of tables, or fields and the latter a value. Ob-viously this way to express patterns is merely illustrative and purposely abstract: the very waycontent structure is represented in terms of processable data structure depends on the actualimplementation.

202


box and consult new arrivals.

Figure 7.7: WOAD mechanism for a convention on proper order.

On the proper timing

The same considerations can be made also for the virtuous convention of

proper compilation by the doctors, as in the case above mentioned in which

doctors are requested to indicate the precise time of prescription in the case

they deem the examination urgent. For this last case, we are not making the

syntax mechanisms explicit for its close similarity between this case and that

represented in Fig. 7.7. Rather we intend to show how different awareness

information could be provided according to the time spent since ordering. In

Fig. 7.8, we represent a mechanisms that after a hour reminds accountable

clinicians that an urgent examination is still to be processed20. The awareness

information provided in this case is of reminding type.

20As regards the temporal aspects, in the example depicted in Fig. 7.8 we have assumed somesimplifying assumptions. For example, time interval is calculated on actual time values as calcu-lated by the application, not on the basis of the value the doctor recorded in the artifact. Then,we do not check in which internal state subsequent related work activities are; we rather relyon other proper-compilation mechanisms to assume that the absence of signs in the ESEG fieldis significant and the related activity is actually not yet accomplished. Likewise, the mechanismdoes not provide a specific actor with awareness information just not to further complicate theexemplification of the case; we rather inform just a nurse role that is responsible for the orderexecution.

203


Figure 7.8: WOAD mechanism for a convention on proper timing.

On the proper redundancy

Structure-related mechanisms can also regard static relationships between

fields, i.e., schema-level relationships that always hold, irrespective of the in-

serted values. To give a significant example taken from our field study, let us

consider the correlations for replicated and duplicated data we treated in Sec-

tion 3.3.3. These correlations regard fields that must contain the same value,

either within the same form or across different documents, respectively. Clini-

cians pointed out that from a technological support they would (also) expect

to be relieved of additional secretarial efforts they had to undertake to com-

plete their work: e.g., when clinicians — usually nurses — are supposed to

merely copy data from a document to another without any further fruitful

elaboration.

A pretty trivial but ubiquitous example of this kind of conventions is given

by documents headers where identifying data are replicated in each form that

204


can be pulled out from the record binder for the sake of reference (for ex-

ample, see box a in Fig. 7.10, where personal data and stay-period data are

reported in headnote). The corresponding conventions of replication would

hence regard when and which data should be replicated and in which field of

which document. The corresponding mechanisms would contain antecedents

that are similar to those of the mechanisms checking the internal consistency

of documents: their antecedents would have patterns that match the content

of the correlated fields and trigger the execution of the mechanism’s conse-

quent whenever their values are different (see Fig. 7.9). The trivial case would

be the initial case, in which one of the fields bound by a correlation for repli-

cated data is still empty and the mechanism reminds the executor of the cor-

responding d-activity-fact to replicate the data for the convenience of the col-

leagues that will refer to either fields. Also in this case the type of awareness

that the mechanism could provide is of reminding type.

Figure 7.9: WOAD mechanism for a convention on proper redundancy.

The careful reader would have noted that to conceive such mechanisms

could be overly burdensome in any digitized documental platform where iden-

tifying and administrative data are replicated just at presentation layer in

virtue of the schema-level associations between the clinical record structures.

That notwithstanding, less automatic and trivial conventions about which data

are to be replicated and which can be easily “interpolated” from the context

can exert the specific and useful function to modulate the degree of the so

205


called “information overload”, i.e. the case of having too much information to

make a decision [Edmunds and Morris, 2000].

The fact that mechanisms operate upon the structure of the clinical record

“from the outside” and are not “hardcoded” in its schema could allow indi-

vidual wards to decide to deliberately create sections within their peculiar

version of the hospital-wide clinical records dedicated to conveying positive re-dundancy (see Section 3.3.3), by relying on specific mechanisms that in their

content section modify correlated documents so as to replicate information

where it needs.

Examples taken from our field studies and that we reported also in [Cab-

itza et al., 2005b] regard the single Pharmacological Therapy Form (SPTF)

(see Section 6.3.7), where according to the prescribing doctor and her neces-

sity to carry out simple calculations on the weight or age of the inpatient for

the dosing of a specific drug, she would appreciate that these values be re-

ported in any single SPTF (see the c box in Fig. 7.10) according to the very

drug/weight/age, while otherwise these data would be superfluous or even

misleading. Or, as another example clinicians considered important and still

pertaining to the conventional use of the documentation, the case of replicated

data regarding allergies and drug incompatibilities, in box b of Fig. 7.10: in

that case, data taken from the Anamnestic Data form — see Section 6.3.2 —

were reported into the single pharmacological therapy form for convenience’s

sake only in those cases that some amnestic data should be timely reminded to

the ordering physician with respect to the very prescription that she is filling

in the form.

Obviously the boundary between relevant data to replicate across the clin-

ical record and data that would constitute just a case of information overload

is very difficult to detect, especially by means of parametric and pattern-based

mechanisms. In many cases, whether a datum should be transcribed in parts

of the record where it is not supposed to be reported requires an interpreta-

tive intervention by the practitioner involved. This leads us to introduce the

two other classes of mechanisms, that involve either content characterization

or the direct human intervention in characterizing relationships between data

and structures.

206


Figure 7.10: A snapshot of the Single Pharmacological Therapy Form (SPTF). Dashedboxes indicate sections with a specific meaning within the clinical record.

7.2.5 Content-related L*WOAD Mechanisms

From the content perspective, WOAD mechanisms are a flexible way to cope

with the semantics of data stored within the clinical record, i.e., with what a

certain datum really means in cooperative and coordinative terms. Such mech-

anisms can act on single documents, or be applied to several distributed forms

so as to link information and practices together toward a more aligned un-

folding of clinical interventions. We denote this kind of mechanisms ‘content-

related’ since they do not depend on the structure of documents in which

content is conveyed but rather on the type of content, and on its intrinsic

properties.

Also in this case, we refer to the physician order entry, specifically per-

taining to drug prescription and administration as it is mediated by the Single

Pharmacological Therapy Form (SPTF — see Fig. 7.10).

For this kind of mechanism to properly work the assumption is that de-

tailed and reliable information on drug composition and drug features has

been represented in some digital document. Once this information has been

also “factualized” into the fact space, WOAD mechanisms can be easily config-

ured so that constraints and peculiarities of any single drug can be reflected

on proper and unambiguous prescriptions. In addition to these standardized

and worldwide instructions, WOAD mechanisms can also provide the single

ward application designer with a tool to configure local conventions on drug

207


prescription and administration.

For instance, physicians have presented us the requirement that clinicians

from a certain ward could have their own idiosyncrasies in having a certain

drug be administered in a particular way or physical form, or within partic-

ular therapeutic regimens that are considered appropriate for a certain ty-

pology of patient. In these cases, the mechanisms would reflect not only a

domain knowledge whose rationalization and standardization is currently be-

ing greatly undergone in the field of pharmacological applications, but would

also integrate that knowledge base with local conventions on proper ways

to interpret it within a specific cooperative arrangement. Since this aspect is

close to supports that lead toward the integration of clinical record with med-

ical knowledge or best practices as they are represented into clinical pathways

and care programs [Berg et al., 2005] we do not go into it further, leaving it

for the Section on future work (Section 8.3).

The ‘DURATA’ field case

As said at the beginning of this section, content-related conventions can apply

to several fields within the same form as well as to a number of forms within

the same clinical record. As an example of the former case, let us consider

the f and g arrows reported in Fig. 7.10. These lines relate the drug form

(namely, the “Forma Farm.” field in the same figure) to the administration

duration (“Durata”) and the frequency indication (“Freq.”) to the number of

administration turns per day, respectively, as they are reported in the rows of

the administration section (box e in the same figure).

According to a ward-specific convention, only infusions can have a “du-

ration”, while the other kinds of administration are considered one-shot (i.e.,

either the “pill” has been administered or not) even if their intra-venous assim-

ilation can take a long while. In other words, only a convention that was prob-

ably established by who designed the form — but on which all its intended

users have definitely agreed upon later — indicates whether the Italian term

“durata”, which means both duration and length, refers either to the length of

the very administering process or to the duration of the overall regimen for

a given drug, i.e. for how long nurses do have to compile the corresponding

administration section of the form. Although this can seem a trivial matter at

a superficial glance it is right the kind of semantics that would be too rigid

to embed into the form structure and that must be managed with more flex-

208


ible and context-dependent mechanisms. Indeed, one of the most vague and

equivocal convention we collected from our field study within the neonatology

ward was right that regarding when an infusional therapy should be treated

either with a daily form or with a weekly form: clinicians “just knew” when

to employ a form instead of the other and the boundary for the choice of the

form was approximately set to one-hour long infusions although it depended

to a great extent on which kind of drug was to be infused and to which kind of

inpatient (i.e., her critical conditions). Right in those cases in which the type

of drug matters, actors could be provided with an alerting awareness that calls

their attention on a possible deviation from the conventional use of the SPTF,

whenever predefined conventional associations between drugs and patterns

of documental use are not met.

The patient preparation case

As an example of the case in which conventions span across different docu-

ments within the clinical record, let us step back to the Laboratory Examina-

tions Form (LEF — see Section 6.3.7 and Fig. 7.5). In that case, the designer

could render into a proper mechanism the ward convention by which requests

for a particular examination are usually associated with a particular prepa-

ration of the examined patient by the nurses in charge. This also is a typical

case in which either drug handbooks or nursing manuals can enumerate lots

of “best practices” in preparing patients for examinations and even suggest

particular preparations for particular examination; but that notwithstanding,

patient preparation is also an aspect of the patient need management in which

nurses operate with a high degree of autonomy and often according to local,

ward-wide conventions that have become established and consolidated for

their function of guaranteeing seamless task alignment and coordination21.

In order to mention a often recurring convention, a content-related mech-

anism for preparations for endoscopic examinations22 could have patterns to

refer to a Single Diagnostic-Therapeutic Form (SDTF — see Section 6.3.7), aswell as of the form that nurses use to indicate the daily diet of inpatients in

their nursing record (i.e, the Fasting plan, FP, see Section 6.3.9). This form is

21The conventional nature of routinary task can be also harked back to the need to rely onbehaviors that are easily recallable according to the contextual ward exigencies.

22We denote this kind of mechanism ‘content-related’ since it depends not on the structureof the form by which examinations are ordered but just on the type of ordered examination,i.e., on the form content.

209


Figure 7.11: A snapshot of both the Single Diagnostic-Therapeutic Procedure Form(SDTF) and the Nurses’ Fasting plan. In the latter the four columns indicate, respec-tively, the bed-number, the name of the patient, the examination type, and the sched-uled time for the examination. For the SDTF the six columns indicate: the orderingdoctor, the ordered exam, date of request, date of booking, (scheduled) date of exe-cution and (scheduled) date of referral arrival.

used to indicate particular deviations from the regular meal that is daily served

by the ward catering service. In Fig. 7.11 a correlation for replicated data is

denoted with the letter a over the arrow relating the two ESAME fields (exam);

and with b a relationship between the scheduled time for the endoscopy (field

DATA ESECUZIONE on the SDTF, execution date) and the time the patient will

have to fast (field ORA on the FP).

In its consequent’ side, the mechanism would hence remind nurses that the

patient must follow a particular diet for the scheduled examination or, more

frequently, just fast until the next morning blood taking (reminding aware-

ness).

7.2.6 Applying L*WOAD to web-spanning correlations

The previous example leads us to consider the more frequent (and most in-

teresting) cases in which correlations are neither embedded in the inscribed

structure of documents, nor traceable back to the standardized content of doc-

uments — i.e., in our reference domain, drug and examination typologies. This

is the case in which the designer conceives mechanisms that are sensitive to

correlations that are explicitly drawn by clinicians during their daily activities.

We will outline three examples, taken from our observational study.

210


The Problem List case

The first two regard both the doctors’ Problem list23. As said in Section 6.3.4,

the problem list (PL) is more than a mere list of items, where the set of either

concomitant or sequential problems affecting the patient are reported. The PL

is also the document where the clinical case is objectified and separated into an

enumerable set of concerns and problems that must be solved for the complete

recovery of the inpatient. Moreover, problems can be also seen as diagnosis,and as such they do change over time. Changes that regard acuteness of a

previously stated problem are not represented explicitly into the PL; these are

rather represented in the Physicians’ Notes as evidence of the illness trajectory

unfolding (see Section 6.3.6). Rather, the PL only represents the main devi-

ations and swerves of such trajectory, and the results of the epicrises doctors

periodically accomplish in evolving and improving their diagnosis on a specific

case. Epicrises are critical summings up within a medical case history that usu-

ally are documented on the Physicians’ Notes; on the PL their outcomes can

result in previously unrelated symptoms that are crossed out with the stroke

of a pen and are substituted by a new comprehensive diagnostic item.

The physicians we interviewed called our attentions to the requirement of

having the possibility to relate past problems to new problems, as a way to

reconstruct or, better yet, make explicit the line of thought that has rational-

ized symptoms into problems and unrelated problems into precise diagnosis.

In this case, an awareness-provision mechanism could be designed just by

writing a couple of patterns: a pattern that is sensitive to problems that are

stricken out i.e., entries within the content attribute of the PL document-fact

that is “deleted”; and another pattern that is sensitive to the relation-fact that

puts the former problems in relationship with new problems (i.e., other en-

tries within the PL document-fact) and that would be asserted into the fact

space by the software platform whenever a doctor select the corresponding

relationship in the web-based application (see Section 7.2.1).

The prescription case

The same holds for a similar mechanism that the designer could conceive to

provide actors with awareness information about the relationship that doc-

tors draw between one or more problems reported in the PL and one or more

23The same argument can be symmetrically followed for the Need List of nurses.

211


prescriptions ordered by means of the Pharmacological Therapy Form (SPTF).

That mechanism would have an even simpler antecedent (see Fig. 7.12), since

it would contain just a pattern that is sensitive to a relation-fact that relates

some item in a PL document-fact and some other item in a SPTF document-fact

(no particular condition must be verified on either). This mechanism would

help the system call the doctors’ attention to the causal correlation that a col-

league has previously drawn between a problem and a step in the process

of its resolution (an item among the physician orders); or, alternatively but

less frequently, to the correlation that relates the onset or recrudescence of a

problem with the course of a treatment that the patient has not tolerated.

Figure 7.12: WOAD mechanism for a convention on web-spanning correlations.

The Physicians’ Notes case

A similar mechanism covers the third main case in which doctors have re-

ported to feel the need for correlating data when they record events on the

clinical record: correlations between SPTF entries and entries in the Physician

Notes (PN — see Section 6.3.6). In this case correlations could convey one

from a wide range of different meanings and express the need for the order-

ing doctor to share with her colleagues of the next shifts her hypothesis on a

number of topics: e.g., how a patient is reacting to a certain course of treat-

212


ment; why a certain dosage had to be changed; or which result the doctor

hopes to reach in the following hours by the ordered treatment. In this last

case that we consider, the type of awareness information provided is close to

either what we have defined either inquiring or alerting awareness, according

to the very situation at hand and the very way the clinicians interpret it and

the consequent informational need for their coworkers.

Sharing these thoughts, making explicit correlations and giving them one

of the “flavors” that field observations have disclosed in any specific domain

(e.g., the causal, temporal and intentional correlations we mentioned in Sec-

tion 7.1.3) allow clinicians to put in common reflections and remarks that

otherwise would be difficult to reconstruct or even discover at hindsight. This

capability has been detected as a crucial requirement for both physicians and

nurses as regards the electronic clinical record they would welcome for their

daily work. This requirement can be traced back to the need for coopera-

tive workers to share pieces of information, all together with contextual items

that can help them in making sense of what is shared (i.e., unpacking their in-

tended meaning and their conventional interpretations [Schmidt and Bannon,

1992]).

The paper-based clinical record has always been a common and shared

repository for distributed and asynchronous communication: accordingly, the

designer that wants to deploy computational systems capable of preserving

and even augmenting the coordinative function of shared documental bases

like the clinical record should take care of the extent she can design data

structure with the explicit aim to fluidly bind data together, at run time, by

means of flexible and even underspecified means.

213

Chapter 8

Conclusive remarks

8.1 Summarizing the main achievements

In this thesis, we have concentrated on the role that documental systems com-

pound by a highly interconnected network of documents — what we call websof documental artifacts, WOAD — play in mediating and supporting distributed

cooperative settings, especially those in which practitioners need to rely on

asynchronous communication to articulate their decisions and interventions

on multiple and complex trajectories of work.

We have taken inspiration from previous researches addressing the use

of documents for information sharing and articulation work (e.g., [Bannon

and Bødker, 1997,Harper and Sellen, 1995,Star and Griesemer, 1989,Simone

and Divitini, 1999]) and we have corroborated their main findings after have

had conducted a short ethnographical study of how physicians and nurses

coordinate each other in two hospital wards of the same regional teaching

hospital by means of their official documentation, the patient-centered clinicalrecord (see Chapter 6).

In such studies, we have observed the practices by which hospital practi-

tioners make sense of records so as to be supported in articulating their ac-

tions across distributed locations and time shifts as well as along different

work trajectories (any single patient’s case [Strauss, 1985]). The evidences

we collected observing their practices, a number of semi-structured interviews

with several key actors of the settings at hand, and a thorough analysis of

their documental system, have then informed our task of detecting and speci-

fying collaborative issues and informational requirements and those practical

solutions that practitioners applied relying on local conventions and ad-hoc

215

CHAPTER 8. CONCLUSIVE REMARKS

agreements.

Grounding on such specific ward observations, the consequent analysis of

artifacts and the literature survey, we have then collected a proper set of re-

quirements that can be suitably adopted for the design of a computationally-

augmented documental system at support of cooperative work in documental

settings. As regards the high-level and general requirements we have high-

lighted the importance to preserve and enhance (1) the informational value

of documents, in terms of their ecological flexibility [Luff et al., 1992]; (2)

their evidential value, in terms of facilitating actors in conveying either add-onand by-product awareness [Simone and Bandini, 2002] to their colleagues to

conveniently coordinate with each other; (3) their capability to support ac-

tors in accessing and reconstructing the context of production of a recorded

item [Bannon and Bødker, 1997,Berg and Goorman, 1999].

Following a bottom-up approach, we have then tried to generalize our

findings into a more general framework for documental domains, i.e., for co-

operative work domains where documents play the twofold important role

of information holders and communication mediators. The main aim of such

framework is to focus on and characterize some relevant concepts that could

guide the design of a reference architecture for computer-based documental

systems in which the above mentioned requirements, taken from traditional

paper-based systems, are to be preserved and possibly enhanced.

The main components of this reference architecture are (a) the documents

that actors use in the execution of their own work, (b) a computational coun-

terpart of a common information space [Schmidt and Bannon, 1992], which

contains elements taken from the work and environmental context and which

we say “common” as regards both the documents’ content and the conven-

tional practices of making sense of it; and (c) the computational application

of conventions, i.e., setting-related mechanisms of interaction and information

provision, by which to make the state of documents and information space

change as a context-driven state-transition systems (see Chapter 3).

In our framework, the information space, termed fact space, is a shared

documental memory where each piece of information recorded within a web

of documents is made accessible to its human users1, it is made interconnected

1At this level of discussion, we purposely neglect the issue of privacy and authorization ofsuch data. The a-priori (and application-independent) underlying idea is anyway to reproduceinto the computational artifacts as much as restricted access and management as it is in theirtraditional paper-based counterparts and no more than that.

216

8.1. SUMMARIZING THE MAIN ACHIEVEMENTS

to all the other textual and contextual information it can be usefully referred

to and it is made associated with additional information that is intended to

represent some possible conventional interpretations to such data.

Our proposal tries to give concreteness to the above mentioned require-

ments in three main ways:

1. First by having users rely on a context-sensitive support to documental

practices — and related higher-level tasks — on the basis of symbolic

and computable representations of conventional patterns that regard

content production, content use and the content interpretation aimed

at task articulation and coordination.

2. Then, by providing users with the capability to indicate, at any point of

their work trajectories, even underspecified relationships between con-

tent items across the whole documental systems and between content

items and document structures in order to hint either coordinative or

just proper and timely use of them.

3. Lastly, by leveraging on user-defined relationships — as well as on those

indicated at design time by the setting’s analysts — to support the sense

making process of involved actors in order to provide them with aware-ness information [Dourish and Bellotti, 1992] whose type depends on the

informational needs and conventions detected in the setting at hand.

These summarized functionalities can also be harked back to the require-

ment regarding common information spaces [Schmidt and Bannon, 1992] of

facilitating the “active construction [of a] space where meanings of the shared

objects are debated and resolved” and where “both the producer and the re-

ceiver [of some documental content] consciously make an effort to understand

each other’ context”. In fact, the WOAD framework encompasses two specific

times and kinds of support to facilitate this “active construction”.

1. First, at design time, WOAD provides designers with a reference modeland a language (L*WOAD, see Chapter 5) by which to express locally-

constructed and shared agreements about the meaning of common data.

Designers are requested to represent such agreements and conventional

interpretations in terms of condition-driven mechanisms, that the sys-

tem executes to convey proper context-driven awareness information to

217


the involved actors. Yet, the WOAD framework does not impose design-

ers to master some particular programming language or to worry about

other implementation technicalities. In fact, they can express relevant

concepts and conventions of a specific work setting and have a WOAD

interpreter render their frame-like representations into the specific data

structures and the executable code of the platform currently implement-

ing the framework. At the present moment this platform is DJess, a

lightweight communication middleware that we specifically conceived

and implemented to enable the deployment of context-aware and mo-

bile applications in distributed settings (see Chapter 4 and also [Cabitza

and Dal Seno, 2005,Cabitza et al., 2005c].

2. Then at run time, WOAD enables the actual users of a documental sys-

tem to make explicit either user-defined or domain-dependent relation-

ships between document’ content and their context, once that the rele-

vant aspects of the work context and proper relationships between the

involved classes have been symbolically represented at the former step

by properly extending the WOAD constructs (see Chapter 7).

8.2 Confronting WOAD with similar approaches

So far, we have summarized the main tenets and characteristics of the WOAD

framework and outlined in Chapter 7 how we applied it to a real setting,

providing for the sake of clarity exemplifications whose simplifications do not

compromise its trustworthiness. In so doing, it is now easier for us to compare

our proposal with other contributions and approaches that have some points

in common on how to conceive computer-based technologies supportive of

cooperative documental domains.

The main common point between most computer applications is informa-

tion processing: information is gathered from the user and her environment,

is stored, organized, managed (e.g., by controlling access rights), processed,

and finally provided as output to some other agent, either some other soft-

ware component or, more often, the user herself. As reported in Section 2, al-

most the 90 percent of that information is unstructured, i.e., expressed within

documents and managed by human actors quite effortlessly and much more

difficultly by computational machines. Actors employ documental content to

inform their thoughts, decisions and actions: in short, to manage their own

218

8.2. CONFRONTING WOAD WITH SIMILAR APPROACHES

work trajectory with respect to all other trajectories they are mutually inter-

dependent with. For their part, machines are successfully used to process fast,

cheaply and accurately content, as long as practices, conventions and work

trajectories involved with content are mainly adjusted by actors. For this rea-

son, the relationship between content and coordination support is a funda-

mental issue in the design of CSCW systems [LaMarca et al., 1999].

In CSCW-informed deployed systems and, more generally, in groupware,

coordination-enabling and coordination-facilitating functionalities either are

embedded in new more comprehensive tools or old tools are someway

wrapped up by some cooperative component so that they can become more

supportive of information sharing and collaboration between their users. The

former approach has been often observed problematic (e.g., [Grudin, 1988,Ol-

son and Teasley, 1996], since users are usually reluctant in changing their ha-

bitual ways to have things done, especially about aspects of their work that

they think to accomplish very well (like articulating each other on a daily

basis). Also the latter approach can lead to unsatisfactory results: it is true

that users are not forced to get acquainted with new tools but the fact that

these tools can not be changed hinders the benefits of augmenting them with

a cooperation-oriented semantics that is tailored to the specific domain needs.

In the following, we mention two main works that to our knowledge

are the closest to our proposal for some points, especially for their focus

on the documental domain and we compare them to the WOAD framework

in terms of similarities and differences: one has been chosen as represen-

tative of the approach that proposes the use of new systems to get more

coordination-oriented features; the other as representative of the approach

that advocates the augmenting of existing systems with a collaborative logic

layer (e.g., [Greenberg, 1990]).

Context-aware computing for the healthcare

Context-aware applications in health and hospital care mostly focus on spe-

cific concerns other than the actual interaction of clinicians with the elec-

tronic clinical records, such as privacy and security issues [Bardram et al.,

2003] and bedside support2, such as patient monitoring and context-aware

drug administration (cf. e.g., the context-aware pill container in [Bardram,

2Bedside support regards the delivery of services “at the point of care” (POC) (cf., e.g., [Fis-cher et al., 2003]).

219


2004]). This attention for making computing embedded and almost disap-

pear within the hospital environment3 and in medical appliances risks yet to

neglect the most serious complaints that have been collected regarding why

most of all computer-based clinical records fail (e.g., [Heeks et al., 1999,Ben-

son, 2002,Jones, 2003]): in most of the cases, clinicians show manifest reluc-

tancy and resistance due to the significant alteration of their traditional work

patterns to accommodate the workflow imposed by the system [Anderson and

Aydin, 1997,Berg, 2003], i.e., by the clinical documentation itself.

As a contribution against these shortcomings, Jahnke et al. proposed

the Context Management System (CMS) [Jahnke et al., 2004b, Jahnke et al.,

2004a]. CMS is a framework for the provision of clinical information that is

also intended to be applied to other documental domains where information

is mainly in web format. At the core of the CMS there are a context fact base,

a context pattern base, and a context inference engine. The context fact base

is a graph-based database storing facts about “situational parameters of user

interactions” with the electronic documental system. The context pattern base

stores rules that associate certain pages (or screens) of the documental sys-

tem with some formal definitions of predefined usage patterns. The context

inference engine is the computational interpreter that composes convenient

vistas of the overall documentation according to the predefined patterns of

documental practices and the current data in the context fact base.

The main similarities with the WOAD framework are two (besides the

peculiar reference domain of hospital care): the centralized representation

and management of context and the context-aware provision of information

through the documentation. As regards the former point, there is a clear simi-

larity between the context fact base and the WOAD fact space, although CMS

employs a graph-based representation of context implemented by the GRAS

database [Kiesel and Schuerr, 1995] while WOAD decouples the data repos-

itory management from the data presentation at artifact level, and directly

manages the latter. Also the idea to provide information to clinicians throughthe documentation they have got access to, according to an easily modifiable

number of lean rules, can be likened to the WOAD tenet to provide actors

with awareness information, especially with that information we have termed

“enabling” and “inquiring” awareness (see Section 5.2).

That notwithstanding, the original points in WOAD are (1) to have these

3Cf. the concept of disappearing computing [Weiser and Brown, 2005], as well as of ubiq-uitous and pervasive computing [Weiser, 1993].

220

8.2. CONFRONTING WOAD WITH SIMILAR APPROACHES

lean rules (i.e., what we called conventions) associated with documents and

their content besides that with the general characterization of the setting at

hand (i.e., context2); (2) to have these rules become part of the common

context of a particular setting; and then (3) to make rules executable across

distributed and autonomous inference engines according to some domain-

dependent rationale or the very situation at hand (i.e., transitors). Moreover,

while the CMS is aimed at rationalizing the access to the on-line clinical docu-

mentation by presenting practitioners with the “right” pages and sections they

should be concerned with in according to the context, the WOAD framework

is aimed at providing users with context-related information while they are

using the documentation on their own initiative and because of their current

and partly unfathomable information needs; such needs are considered by

WOAD solely on the basis of context-sensitive conventions on the use of arti-

facts and cooperative work in a given work setting and not as enactment of

any work-based document-routing.

Document-centered collaboration

More evident are the similarities between the WOAD framework and Place-less Document [Dourish et al., 2000a, Dourish et al., 2000b], the infrastruc-

ture that we take as representative of the approach that focusses on exten-

sibility and smooth integration with existing document management tools to

augment them with cooperation-oriented functionalities. The Placeless Docu-

ments project, based in the Computer Science Lab at PARC, has explored a new

approach to document management that aims to give documents the resources

to achieve application integrity and autonomous coordination functionalities:

accordingly, the researchers involved in such project have called the underly-

ing conceptual approach “document-centered collaboration” [LaMarca et al.,

1999]. As in WOAD, their approach is to focus on collaboration as a feature

of the document rather than of the application that manages them. Within

the placeless approach this means that all operations on a document, such as

reading, writing, moving, and deleting, can be executed by some active codeassociated with the document, which is called property. Properties character-

ize intrinsic features and control logic of documents independent of the place

it is stored (hence, the attribute Placeless). As in WOAD, the active code is

executed by a middleware layer that sits between ordinary applications and

existing document repositories such as file systems. As in WOAD, active prop-

221


erties can take appropriate action on the basis of context since the platform

makes documents “situationally aware” and be responsive to changes in their

use and in the context. Properties can either notify actors on the actions to

perform, perform the operation itself, or prohibit the operation.

This marks two important differences with our proposal: first, properties

have a local scope, i.e., they are applied to the content of the document to

which they are attached. WOAD conventions and more generally, mechanisms,

instead, leverage on the pattern matching capabilities of distributed transitors

and can hence be associated with the content entries of any document ren-

dered within the fact space. Active properties are intended to bring “workflow

logic to applications that work on documents, [so as to avoid to create] stand-

alone and monolithic applications to do workflow” [LaMarca et al., 1999].

Also WOAD mechanisms can change documental content and even inhibit

it from being changed by actors depending on how it is implemented the bondthat the define primitive creates between actual data and factual representa-

tion of the artifact. Moreover, convention-facts and corresponding mechanisms

can be as much prescriptive and constraining as the work setting conventions

they refer to are. Often, in the clinical work domain, we have seen conventions

whose prescriptive nature did not derive from a fully reconciled and agreed

practices among clinicians, but rather from precise and very strict Italian laws

which prescribe how records ought to be compiled and when. The trespassers

of such laws are prosecuted with the expulsion from the medical register and

with other serious penalties that are also inflicted to whom has failed to report

any violation of the law. In this very case, the advocates of the deployment of

“constraining” technology propose to see it as a preventive measure against

legal problems and law infringements rather than a tight rein on practition-

ers’ autonomy. The final evaluation on this delicate balance can not obviously

leave out of consideration the very requirements and demands of the domain

at hand.

The point then is not to consider if this functionality can be either feasibly

applied or useful, but rather if there is the real risk of falling in the serious

drawbacks pointed out within the CSCW literature in a number of contribu-

tions that cannot be neglected (e.g., [Grinter, 2000,van der Aalst and Jablon-

ski, 2000,Hayes, 2000]).

For these reasons, our framework is mostly aimed at providing awareness:although it is possible to automatically change documental content, we rather

222

8.3. POSSIBLE DIRECTIONS FOR FUTURE WORKS

propose to use L*WOAD for the provision of notifications4, i.e., awareness

information that could “hint” actors what to do and even explain them why5.

The case of activity inhibition is the clearest (see Section 5.2): for the reflective

nature of the fact space when some conditions would prevent some activity

from being executed, actors are just notified of it, but they can proceed the

same (although some justification should be explicitly requested depending on

the application domain). When actors change the content of some document

within that particular activity, the internal representation of the activity followstheir actions, rather than constraining them, and commutes to a state that is

consistent with the new state of the documental content (e.g., in execution6).

To summarize, Placeless documents is perhaps the closest related approach

to the WOAD framework, sharing with it the focus on documental artifacts,

coordination and content decoupling, context-awareness and active behaviors

associated to single documents and their content. The differences lie in the

different stress on awareness provision rather than in ‘workflow management’

and in the global sharing of documental content, so that local conventions

(in the sense of intra-document) and setting conventions (in the sense of per-

taining to the whole setting in which the documental system is deployed) can

be applied to any piece of content from different documents and any other

contextual information and react accordingly.

8.3 Possible directions for future works

We can envision the articulation of the next activities regarding the WOAD

framework along three main dimensions, summarizable as follows: (1) inten-

sive verification of the framework in the field and its generalization to cope

other application domains’ peculiarities; (2) application of the framework to

explicitly support standard and structured procedures (3) application of the

framework to the inter-organizational coordination domain.

• First of all, we need to get more evidences from the field of work that

4A possible exception to this requirement could be conceived for those trivial cases whenusers explicitly require ways to automatically cope with negative-redundancy and low-valuesecretarial practices (e.g., replicating administrative data)

5This is the case, for instance, in which the provision of inhibition awareness is coupled withthe indication that doing otherwise is against the law.

6The same holds whenever reaching a “consistent state of the work activities with the doc-umental activities” requires that an executing activity commutes into, e.g., the idle state andanother work-activity goes into the execution state without even passing by its formal enabling.

223


the WOAD model and language can be conveniently used to curtail the

burden of modeling a generic document-based cooperative setting, irre-

spective of the specific domain.

Even within the general domain of healthcare, we would need to get

a longer and more thorough evaluation of how effectively and ade-

quately local conventions regarding both articulation work and docu-

mental content use can be rendered in terms of WOAD convention-facts

and whether the strictly reactive model of condition-action mechanism

can adequately represent and follow the changes occurring within such

hectic and dynamic field of work.

It goes without saying that no model can be claimed to be able to en-

compass and properly manage any possible situation. The point indeed

is to understand whether — and to what extent — computational mech-

anisms based on an arbitrary symbolic representation of context, as ac-

tors and designers are able to externalize and formalize it into WOAD

constructs (cf. [Bannon, 1995]), can hinder the activities of the field of

work and jeopardize the effectiveness of the actors’ interventions, espe-

cially when they have to handle those exceptions that could not even be

defined in terms of symbolic constructs.

To this aim, the WOAD framework should be applied to a full-fledged

electronic clinical record that is routinely used by different practitioners

on a daily basis. Yet, the first big challenge regarding the proper and fea-

sible deployment of innovative IT applications in the healthcare domain

is to first understand the rationale of current healthcare practices, the

work culture in which they are structured in some transferable knowl-

edge, and the political policies they are subject to [Kensing, 2004]. In

Italy, where we live and work, the full deployment of integrated and,

mostly important, extensible and customizable clinical applications is still

very rare; real experimentations toward their deployment is still episodic

and very limited in time (e.g., [Ancona et al., 2000, Quaglini et al.,

2005]), not only for the obvious delicacy and sensitivity of the hospi-

tal care domain, but also for investment policies and political reasons

that make it difficult to foresee relevant developments and the direction

they will be steered towards.

Also for these reasons, we are planning to apply WOAD to a different

and purely administrative domain, like the domain of the institutional

224


and public management of the Italian university and research. Specif-

ically, we could detect the same multivoicedness [Hertzum, 1999] (see

Section 2.3) whose support is explicitly addressed by the WOAD frame-

work, in the very set of forms, manuals, circulars, memorandums and

other official documents which are used within a civil service depart-

ment in its ordinary business. A thick fabric of cross-references, emen-

dations, different versions and notes also makes this web of documental

artifacts pretty integrated and difficult to make fully sense and use of

in any situation. We are aware that the typical rigidities and demands

for formality and strictness of modern bureaucracies can pose signifi-

cant challenges to the application of a cooperation-aware layer on top

of legacy applications used in the civil service offices; that notwithstand-

ing, it is also true that these very applications usually pertain to the

domain of office automation where the deployment of innovative tools

can find in the clerical practitioners less reluctant adopters than people

that might even have never had a computer mouse in their hands (as in

the hospital ward case).

• With “explicit support to standard7 and structured procedures” we re-

fer to those cases in which particular documents are explicitly intended

to steer actions: two simple but pervasive examples from the clinical

everyday work are to-do lists — whenever they are mainly intended in

sequential order — and flow-charts — when they are intended as pre-

scriptive and schematic representation of a process, like in the case of

the graphical companions to clinical pathways (we define them next).

Notwithstanding and apart from the concerns that we have above men-

tioned about the limitations of workflow technology, we could indeed

experience a strong interest for the provision of inhibition and enablingawareness (see Section 5.2) during our observational studies at the

Neonatology Intensive Care Unit. At the end of our studies, in fact, the

NICU head physician proposed us to reflect with him and some other

interested colleagues about possible ways to integrate clinical pathwaysinto the clinical record; the same interest was also shared by the develop-

ers of the clinical record prototype for some evidences they could collect

that this kind of feature would be a distinctive plus for their electronic

7We use such attribute in the acceptation used in [Cabitza et al., 2006d], pertaining to“anything considered by either an authority or general consent as a basis of comparison”.

225


clinical record with respect to other competing solutions.

A clinical pathway can be considered a purposely schematic represen-

tation of some part of the overall care process to apply to a certain

illness trajectory and that pertains to some specific problem requiring

routinary solutions. The general and declared purpose of clinical path-

ways is to improve medical outcomes and quality of care by providing a

mechanism to coordinate care, reduce fragmentation and unmotivated

variability of intervention, and last but not least, cost [Pearson et al.,

1995, Panella et al., 2003, Berg et al., 2005]. Many contributions in the

specialist literature (e.g. [Ireson, 1997,Campbell et al., 1998,Ellershaw,

2002,Browne et al., 2001] consider the integration of standardized pro-

tocols into the clinical records, where work is both recorded and com-

missioned, as the mere enactment of “virtuous workflows”, which most

of the times are that simple that even simple flow-charts can represent

their steps, branches and synchronization points. The allegedly virtuos-

ity of the application of such protocols to clinical records consists in the

evidences that the above mentioned literature has been collecting in the

last ten years: such contributions report that the application of clinical

pathways to medical practice could result into less indulging in superflu-

ous and useless differentiations from standard medical practice, in the

significant reduction of the number of possible deviations from best prac-

tices (and their correlated negative consequences) and in the enabling

of clinical and epidemiological research for the introduced capability of

comparing outcomes and methods. Accordingly, applying clinical path-

ways is assimilated to applying evidence-based and up-to-date medical

knowledge to the illness trajectory of a patient in the only allegedly “vir-

tuous” way in which caring activities should follow each other, according

to the very progress of the trajectory at hand.

A future application of the WOAD framework could then be to investi-

gate whether the inclusion of such standard and allegedly virtuous flows

of care is compatible with the frantic, almost unpredictable and highly

dynamic real unfolding of an illness trajectory within the broader con-

text of all the other trajectories that are treated in the same facility in

the same period. Far from rehashing considerations about the most man-

ifest pitfalls related with rigid workflow enactment in highly dynamic

work arrangements, we could rather investigate the role of the WOAD

226


framework as a “learning device”8 for the sharing of medical “best prac-

tices” either embedded or related with the clinical pathway at hand. We

think that the awareness provision approach could be a feasible way

to smoothly pass from the “scripting” nature of the strict application of

a pathway to its educational value, when a pathway is used as a map

“flanking beside” the clinical practice and supporting it through the af-

fordances conveyed through the records where actual practice is docu-

mented. The point that could be further investigated could also regard

which kind of awareness information should be conveyed to make ex-

plicit the possible differences between “the theory and the practice” as

they occur in the field of work, and how to convey such information to

make actors aware of the possible ways such differences can be recon-

ciliated with the expected outcomes and with respect to the regardable

demands of accountability of the medical discipline.

• A third line of development would be applying WOAD to those cases in

which two or more documental systems end up by interacting as well as

the communities of their users.

We have treated elsewhere [Cabitza et al., 2006c] the case in which

patient trajectories must unfold across multiple wards and departments

within the same hospital as it can happen whenever a patient must be

referred to some specialist or must undertake some diagnostic exami-

nation that is provided by an external service unit (e.g., the radiology

ward). To limit our scope to artifact sharing and the exchange of the

correlated flows of information, inter-networks collaboration (see Sec-

tion 6.1.1) is usually achieved by putting some interface artifact [Cabitza

et al., 2006c] in common: a document — typically a pretty well struc-

tured form — that is shared by the care-cluster that provides the service

with the care-cluster that requests that service. Members of the “request-

ing” cluster are supposed to express their request into the terms either

reified in or referred by the interface artifact since only doing so mem-

bers of the “providing” cluster can understand what they mean, have a

clear picture of the patient and her needs, and provide the requested

service as expected. The interface artifact can be seen as a sort of “bridg-

ing” document between two different webs of documents, which our

point would be to enable as “carrier of” and “facilitator of sharing” the8Cf. [Mark, 2002] and Chapter 3

227


proper conventions of documental use among members of different clus-

ters/communities of practice.

The future widening and intensification of such line of research would

place itself within an increasing interest in the organization of health-

care work along individual patient cases rather than along the demar-

cation lines of healthcare organizations. This increasing interest arises

as a consequence of the need to distribute care over larger networks of

services and care providers that are located in different settings and that

are no longer centralized within the same all-inclusive facility such as

the hospital. This need is caused by two important current trends: the

increasing aging of world population and, quite surprisingly, the vertigi-

nous advance of medical science. The fact that people tend to live longer

compared to earlier ages is the main affecting factor in the increasing of

the chronicity of health problems; and, in its turn, the ever-growing spe-

cialization of medical branches leads to a number of very specific treat-

ments or monitoring practices that require investments that few facilities

can easily concentrate in the same location.

In order to address from the CSCW perspective the matter of how

clinical records could support inter-organizational communication and

coordination as well as they do within the in-ward dimension, some

recent studies have, for instance, focussed on the discharge letter(e.g., [Dougherty, 1999, Winthereik and Vikkelso, 2005]). On the one

hand, this last part of the regular clinical record is seen as the docu-

ment that mediates communication — beyond the mere administrative

accounting — between the discharged patient and the professionals that

had her in charge. On the other hand, it is also seen as the tool that me-

diates coordination — in terms of handing over — between the hospital

— a secondary sector facility — with other primary or tertiary facilities,

i.e., the general practitioner and the specialist, respectively, in all those

cases in which a patient must be followed up. Yet in this case, usually cor-

respondent entities are simpler than hospital facilities in their internal

structure and hence can eventually not encompass complex and com-

posite documental systems that need to integrate with each other and

overlap into the discharge letter.

The need for achieving semantic interoperability and maintain a seam-

less articulation across multiple organizations is a precise requirement

228


of the so-called domain of integrated care or shared care [Hampson et al.,

1996]. The expression “shared care” refers to the sharing of responsibil-

ities that is related to the provision of healthcare services by profession-

als or teams from different organizations, “or where substantial orga-nizational boundaries exist” [Pritchard and Hughes, 1995], and that is

aimed at reaching significant improvements in the quality of care and

life of all the stakeholders involved (especially, the care beneficiaries).

Since shared care necessarily involves information sharing about illness

trajectories that unfold over time and across organizational and pro-

fessional boundaries, the most crucial aspect to successful shared care

programs relies on achieving and maintaining a good functional and

semantic interoperability between all the care-clusters involved: an ob-

jective that recent research is showing as a long-term and non-linear

process [Mur-Veeman et al., 2001] and that the CSCW community has

always assimilated to overcoming the “knowledge boundaries” [Carlile,

2002].

Our research on the externalization and exploitation of conventions per-

taining to documental use can hence contribute in shedding some light

on which requirements to collect and how to substantialize them into

a feasible and adequate software platform aimed at maintaining and

enhancing the coordinative and informational values of documental re-

sources that end up by being shared between heterogeneous and dis-

tributed organizations. The work agenda would then concentrate on

having these sets of “bridging” documental artifacts (cf. [Rolland et al.,

2006]) better mediate such “boundary crossing” and actively limit the

related “ontological drift” (cf. [Robinson and Bannon, 1991]) occurring

when artifacts move or are used between semantic communities.

229

Appendix A

The NICU survey questions

• Score Key

– Frequency of use

-2 Never (occasionally, almost exceptionally)

-1 Sometimes (one or twice each work shift)

0 No opinion / No comment

+1 Often (one or twice each hour)

+2 Always (quite frequently each hour)

– Usefulness / efficaciousness

-2 Poor

-1 Quite low

0 No opinion / No comment

+1 Useful

+2 Fundamental

• Questions

1. What is your institutional role/job at the NICU?

– Senior Doctor

– Doctor

– Senior Nurse

– Nurse

– Assistant

– Student/Trainee

– Other

231

APPENDIX A. THE NICU SURVEY QUESTIONS

2. As regards the caring process within the NICU, would you please characterizethe following modalities by which you get useful information with respect tocare, in terms of frequency of use and usefulness/efficaciousness.

(a) Conversations with nurses (either senior or not) during the morninground.

(b) Conversations with senior nurses during the work shift (exceptround).

(c) Conversations with junior nurse during the work shift (except theround).

(d) Conversations with the doctors on-duty during the morning round.

(e) Conversations with the doctors on-duty (except the round)

(f) Conversations with the senior doctors on-duty (except the round)

(g) Conversations with the doctors (either senior or not) that are goingoff-duty (handing over time)

(h) Conversations with specialist consultants.

(a) Consultation of the Single Infusional Therapy Sheet

(b) Consultation of the Single Pharmacological Therapy Form

(c) Consultation of the Single Working Sheet

(d) Consultation of the Summary Sheet

(e) Consultation of the Physicians’ Notes (and Problem List)

(f) Consultation of the Preliminary Objective Examination and First CarePlanning sheets

(g) Consultation of the Nursing Notes

(h) Consultation of the medical reports

3. As regards the caring process within the NICU, would you please characterizehow often you compile (or just sign) the following documents, with respectto direct support to caring.

(a) Single Infusional Therapy Sheet

(b) Single Caring Procedures Sheet

(c) Single Laboratory Examinations Form

(d) Single Diagnostic-Therapeutic Procedures Form

(e) Single Pharmacological Therapy Form

(f) Single Working Sheet

(g) Summary Sheet

(h) Physicians’ Notes (including Problem List)

(i) Nursing Notes (including Need List)

232

Bibliography

[Aalst et al., 2003] Aalst, W. M. P. V. D., Hofstede, A. H. M. T., Kiepuszewski,

B., and Barros, A. P. (2003). Workflow patterns. Distrib. Parallel Databases,14(1):5–51.

[Aarts et al., 2002] Aarts, E., Harwig, R., and Schuurmans, M. (2002). Ambi-

ent intelligence. The invisible future: the seamless integration of technologyinto everyday life, pages 235–250.

[Aarts and Berg, 2004] Aarts, J. and Berg, M. (2004). Understanding imple-

mentation: The case of a computerized physician order entry system in a

large dutch university medical center. Journal of the American Medical In-formatics Association, 11:207–216.

[Acharya, 1996] Acharya, A. (1996). Eliminating redundant barrier synchro-

nizations in rule-based programs. In Proceedings of the 10th internationalconference on Supercomputing, pages 325–332. ACM Press.

[Akkiraju et al., 2005] Akkiraju, R., Farrell, J., J.Miller, Nagarajan, M.,

Schmidt, M., Sheth, A., and Verma, K. (2005). Web service semantics -

wsdl-s. Technical report, A joint UGA-IBM Technical Note.

[Alberdi et al., 2001] Alberdi, E., Becher, J., Gilhooly, K., and Hunter, J.

(2001). Expertise and the interpretation of computerized physiological

data: implications for the design of computerized monitoring in neonatal

intensive care. International Journal of Human-Computer Studies, 55:191–

216.

[Allen, 1984] Allen, J. F. (1984). Towards a general theory of action and time.

Artificial Intelligence, 23:123–154.

[Amigoni and Somalvico, 1998] Amigoni, F. and Somalvico, M. (1998). Dy-

namic agencies and multi-robot systems. In Lueth, T., Dillmann, R., Dario,

233

BIBLIOGRAPHY

P., and Worn, H., editors, Proceedings of the 4th International Symposium onDistributed Autonomous Robotic Systems, pages 215–224, Karlsruhe, Ger-

many. Springer-Verlag.

[Amigoni et al., 1999] Amigoni, F., Somalvico, M., and Zanisi, D. (1999). A

theoretical framework for the conception of agency. International Journalof Intelligent Systems, 14(5):449–474.

[Ancona et al., 2000] Ancona, M., Dodero, G., Gianuzzi, V., Minuto, F., and

Guida, M. (2000). Mobile computing in a hospital: the WARD-IN-HAND

project. In ACM SAC 2000, Como, Italy. ACM Press.

[Andersen et al., 1990] Andersen, N. E., Kensing, F., Lundin, J., Mathiassen,

L., Munk-Madsen, A., Rasbech, M., and Sørgaard, P. (1990). ProfessionalSystems Development — Experience, Ideas, and Action. Prentice-Hall, Engle-

wood Cliffs, New Jersey, USA.

[Anderson and Aydin, 1997] Anderson, J. and Aydin, C. (1997). Evaluating

the impact of health care information systems. Intern. J. Tech. ssess. inHealth Care, 13(2):380–393.

[Apt and Bol, 1994] Apt, K. and Bol, R. (1994). Logic programming and

negation: a survey. Technical report, Centrum voor Wiskunde en Infor-

matica (SMC) Netherlands.

[Ark and Selker, 1999] Ark, W. and Selker, T. (1999). A look at human in-

teraction with pervasive computers. IBM Systems Journal special HCI issuewith a focus on Pervasive Computing, 38(4):504–507.

[Ash et al., 2004] Ash, J. S., Berg, M., and Coiera, E. (2004). Some unin-

tended consequences of information technology in health care: The nature

of patient care information system-related errors. Journal of the AmericanMedical Informatics Association, 11:104–112.

[Atkinson, 1995] Atkinson, P. (1995). Medical talk and medical work. Sage

Publications.

[Avgerou et al., 2004] Avgerou, C., Ciborra, C., and Land, F., editors (2004).

The Social Study of Information and Communication Study. Oxford Univer-

sity Press.

234

BIBLIOGRAPHY

[Axelrod, 1997] Axelrod, R. (1997). The Complexity of Cooperation, chapter

Evolving New Strategies. Princeton University Press.

[Bandini et al., 2003] Bandini, S., Colombo, E., Colombo, G., Sartori, F., and

Simone, C. (2003). The role of knowledge artifacts in innovation manage-

ment: the case of a chemical compound designer cop. Communities andtechnologies, pages 327–345.

[Bandini et al., 2002] Bandini, S., Manzoni, S., and Simone, C. (2002). Deal-

ing with space in multi–agent systems: a model for situated mas. In AAMAS’02: Proceedings of the first international joint conference on Autonomousagents and multiagent systems, pages 1183–1190. ACM Press.

[Bang et al., 2003] Bang, M., Larsson, A., and Eriksson, H. (2003). NOSTOS:

A Paper-Based Ubiquitous Computing Healthcare Environment to Support

Data Capture and Collaboration. In 2003 AMIA Annual Symposium, pages

46–50, Washington DC.

[Bannon, 2000] Bannon, L. (2000). Understanding common information

spaces in CSCW. paper presented at the workshop on cooperative organisa-

tion of common information spaces. Technical report, Technical University

of Denmark. Available at http://dmm.cti.dtu.dk/position/bannon.pdf.

[Bannon and Bødker, 1997] Bannon, L. and Bødker, S. (1997). Constructing

Common Information Space. In Proceedings of the Fifth European Coop-erative Supported Cooperative Work, pages 81–96, Lancaster (UK). Kluwer

Academic Publishers, Netherlands.

[Bannon, 1993] Bannon, L. J. (1993). CSCW: An initial exploration. Scandi-navian Journal of Information Systems, 5:3–24.

[Bannon, 1995] Bannon, L. J. (1995). The politics of design – representing

work. Communications of the ACM, 38(9).

[Bannon and Schmidt, 1991] Bannon, L. J. and Schmidt, K. (1991). CSCW:

four characters in search of a context. Studies in computer supported coop-erative work: theory, practice and design, pages 3–16.

[Bardram and Bossen, 2005a] Bardram, J. and Bossen, C. (2005a). Mobil-

ity work: The spatial dimension of collaboration at a hospital. ComputerSupported Cooperative Work, 14(2):131–160.

235

BIBLIOGRAPHY

[Bardram, 2000] Bardram, J. E. (2000). Temporal coordination: On time

and coordination of collaborative activities at a surgical department. Com-puter Supported Cooperative Work, The Journal of Collaborative Computing,

9(2):157–187.

[Bardram, 2004] Bardram, J. E. (2004). Applications of context-aware com-

puting in hospital work: examples and design principles. In SAC ’04: Pro-ceedings of the 2004 ACM symposium on Applied computing, pages 1574–

1579, New York, NY, USA. ACM Press.

[Bardram and Bossen, 2004] Bardram, J. E. and Bossen, C. (2004). Inter-

woven Artifacts – Coordinating Distributed Collaboration in Medical Care.

Technical report, Centre for Pervasive Computing, Arhus, DENMARK.

[Bardram and Bossen, 2005b] Bardram, J. E. and Bossen, C. (2005b). A web

of coordinative artifacts: collaborative work at a hospital ward. In GROUP’05: Proceedings of the 2005 international ACM SIGGROUP conference onSupporting group work, pages 168–176, New York, NY, USA. ACM Press.

[Bardram et al., 2003] Bardram, J. E., Kjaer, K., and Nielsen, C. (2003).

Context-Aware User Authentication - Supporting Proximity-Based Login in

Pervasive Computing. In Ubicomp 2003: Proceedings of the InternationalConference on Ubiquitous Computing, pages 107–123, Seattle, WA. Springer

Verlag.

[Batini et al., 1992] Batini, C., Ceri, S., and Navathe, S. B. (1992). Concep-tual database design: an Entity-relationship approach. Benjamin-Cummings

Publishing Co., Inc., Redwood City, CA, USA.

[Benerecetti et al., 2001] Benerecetti, M., Bouquet, P., and Bonifacio, M.

(2001). Distributed context-aware systems. Human-Computer Interaction,

16(2, 3 & 4):213–228.

[Benford et al., 1994] Benford, S. D., Bowers, J. M., Fahlen, L. E., and Green-

halgh, C. (1994). Managing mutual awareness in collaborative virtual en-

vironments. In Singh, G., Feiner, S., and Thalmann, D., editors, VRST’94:Proceedings of the ACM SIGCHI Conference on Virtual Reality and Technology,

pages 223–236, Singapore. ACM Press, NY, USA.

[Beniger, 1986] Beniger, J. R. (1986). The Control Revolution: Technologicaland Economic Origins of the Information Society. Harvard University Press.

236

BIBLIOGRAPHY

[Benson, 2002] Benson, T. (2002). Why general practitioners use computers

and hospital doctors do not—part 1: Incentives. British Medical Journal,9(325):1086–1089.

[Berg, 1998] Berg, M. (1998). Medical work and the computer-based pa-

tient record: A sociological perspective. Methods of Information in Medicine,

37(294-301).

[Berg, 1999] Berg, M. (1999). Accumulating and Coordinating: Occasions for

Information Technologies in Medical Work. Computer Supported Coopera-tive Work, The Journal of Collaborative Computing, 8(4):373–401.

[Berg, 2003] Berg, M. (2003). Health Information Management. Routledge.

[Berg and Goorman, 1999] Berg, M. and Goorman, E. (1999). The contextual

nature of medical information. International Journal of Medical Informatics,56:51–60.

[Berg et al., 2005] Berg, M., Schellekens, W., and Bergen, C. (2005). Bridging

the quality chasm: integrating professional and organizational approaches

to quality. International Journal for Quality in Health Care, 17(1):75–82.

[Berry and Goulde, 1994] Berry, M. and Goulde, M. (1994). A new view of

documents. integrated information management in the ´90s. WorkgroupComputing Report, 17(8).

[Bertelsen and Bødker, 2001] Bertelsen, O. and Bødker, S. (2001). Coopera-

tion in massively distributed information space. In ECSCW´2001: Proceed-ings of the Seventh European Conference on Computer Supported CooperativeWork, pages 1–17. Kluwer.

[Beuscart-Zephir et al., 2005] Beuscart-Zephir, M. C., Pelayo, S., Anceaux, F.,

Meaux, J.-J., Degroisse, M., and Degoulet, P. (2005). Impact of cpoe on

doctor-nurse cooperation for the medication ordering and administration

process. International Journal of Medical Informatics, 74:629–641.

[Biegel and Cahill, 2004] Biegel, G. and Cahill, V. (2004). A framework for

developing mobile, context-aware applications. In Percom 2004: Proceed-ings of the 2nd IEEE Conference on Pervasive Computing and Communica-tions.

237

BIBLIOGRAPHY

[Bikson and Frinking, 1993] Bikson, T. K. and Frinking, E. J. (1993). Preserv-ing the present: toward viable electronic records. den Haag: Sdu Publishers.

[Blumberg and Atre, 2003] Blumberg, R. and Atre, S. (2003). The problem

with unstructured data. DM Review Magazine.

[Bang and Timpka, 2003] Bang, M. and Timpka, T. (2003). Cognitive tools in

medical teamwork: The spatial arrangement of patient records. Methods ofInformation in Medicine, 42:331–336.

[Bock and Gruninger, 2004] Bock, C. and Gruninger, M. (2004). Psl: A se-

mantic domain for flow models. Software and Systems Modeling Journal.

[Boland et al., 1992] Boland, R., Schwartz, D., and Tenkasi, R. (1992). Shar-

ing perspectives in distributed decision making. In CSCW ‘92: Proceedingsof the International Conference on Computer Supported Cooperative Work,

pages 306–313, Toronto, Canada. ACM Press.

[Boselli et al., 2005] Boselli, R., Cabitza, F., Paoli, F. D., and Loregian, M.

(2005). An adaptive middleware to support context-aware knowledge

sharing. In ICDCS Workshops, pages 352–358.

[Bossen, 2002] Bossen, C. (2002). The parameters of common information

spaces: the heterogeneity of cooperative work at a hospital ward. In

CSCW’02: Proceedings of the International Conference on Computer Sup-ported Cooperative Work,, New Orleans Louisiana USA. ACM Press.

[Bourdieu, 1977] Bourdieu, P. (1977). Outline of a Theory of Practice. Cam-

bridge University Press, Cambridge, MA, USA.

[Bowers et al., 1995] Bowers, J., Button, G., and Sharrock, W. (1995). Work-

flow from within and without: Technology and cooperative work on the

print industry shopfloor. In ECSCW’95: Proceedings of the Fourth EuropeanConference on Computer-Supported Cooperative Work, pages 51–66. Kluwer

Academic Publishers.

[Bowker et al., 1997] Bowker, G., Star, S. L., Turner, W., and Gasser, L. (1997).

Social Science, Technical Systems and Cooperative Work-Beyond the GreatDivide. Lawrence Erlbaum Associates, Publishers.

238

BIBLIOGRAPHY

[Braa and Sandahl, 2000] Braa, K. and Sandahl, T. (2000). Introducing dig-

ital documents in work practices - challenges and perspectives. Group De-cision And Negotiation, 9(3):189–203. Publisher Kluwer Academic Nether-

lands Isbn Issn 0926-2644.

[Braa and Sandahl, 1998] Braa, K. and Sandahl, T. I. (1998). Informationand Process Integration in Enterprises. Rethinking Documents, chapter Ap-

proaches to Standardization of Documents. Kluwer Academic Publishers.

[Brehmer, 1991] Brehmer, B. (1991). Distributed Decision Making: CognitiveModels in Cooperative Work, chapter Distributed Decision Making: Some

Notes on the Literature. Blackwell, NY: John Wiley.

[Brooks, 1991] Brooks, R. A. (1991). Intelligence without representation. Ar-tificial Intelligence, 47:139–159.

[Brown and Duguid, 1991] Brown, J. and Duguid, P. (1991). Organizational

learning and communities of practice: Towards a unifiedview of working,

learning, and innovation. Organization Science, 2:40–57.

[Brown and Duguid, 1994] Brown, J. S. and Duguid, P. (1994). Borderline

issues: Social and material aspects of design. Human-Computer Interaction,

9:3–36.

[Brown et al., 2004] Brown, P., Borowitz, S., and Novicoff, W. (2004). Infor-

mation exchange in the nicu: what sources of patient data do physicians

prefer to use? International Journal of Medical Informatics, 73(4):349–55.

[Browne et al., 2001] Browne, G. J., Giles, H., Mccaskill, M. E., Fasher, B. J.,

and Lam, L. T. (2001). The benefits of using clinical pathways for managing

acute paediatric illness in an emergency department. Journal of Quality inClinical Practice, 21(3):50.

[Buckland, 1991a] Buckland, M. (1991a). Information as thing. Journal ofthe American Society of Information Science, 42(5):351–360.

[Buckland, 1991b] Buckland, M. (1991b). Information retrieval of more than

text. Journal of the American Society for Information Science, 42:586–588.

[Buckland, 1997] Buckland, M. (1997). What is a “document”? Journal ofthe American Society of Information Science, 48(9):804–809.

239

BIBLIOGRAPHY

[Buneman and Steedman, 2002] Buneman, P. and Steedman, M. (2002). An-

notation – the new medium of communication. In UKCRC Grand Challengeworkshop, Edinburgh, UK.

[Cabitza and Dal Seno, 2005] Cabitza, F. and Dal Seno, B. (2005). Djess — a

knowledge-sharing middleware to deploy distributed inference systems. In

Proceedings of ENFORMATIKA’05 Joint Conferences, Istanbul, Turkey.

[Cabitza et al., 2005a] Cabitza, F., Dal Seno, B., Sarini, M., and Simone, C.

(2005a). Being at one with things: The interconnection metaphor for in-

telligent environments. In Proceedings of the IEE International Workshop onIntelligent Environments, Colchester, UK.

[Cabitza et al., 2006a] Cabitza, F., Locatelli, M., Sarini, M., and Simone, C.

(2006a). CASMAS: Supporting collaboration in pervasive environments.

In PerCom2006: Proceedings of the Fourth Annual IEEE International Confer-ence on Pervasive Computing and Communications, Pisa, Italy. IEEE.

[Cabitza et al., 2006b] Cabitza, F., Locatelli, M. P., and Simone, C. (2006b).

Cooperation and ubiquitous computing: an architecture towards their inte-

gration. In Hassanaly, P., Herrmann, T., Kunau, G., and Zacklad, M., editors,

Cooperative Systems Design - Seamless Integration of Artifacts and Conversa-tions – Enhanced Concepts of Infrastructure for Communication, pages 86–

101. IOS Press. ISBN 1-58603-604-1.

[Cabitza et al., 2004] Cabitza, F., Loregian, M., and Sarini, M. (2004). Sup-

porting wards with interactive resources and logic-based systems. In Ubi-health2004: Proceedings of the 3rd international workshop on ubiquitouscomputing for pervasive healthcare applications, Nottingham, UK.

[Cabitza et al., 2005b] Cabitza, F., Sarini, M., Simone, C., and Telaro, M.

(2005b). When once is not enough: The role of redundancy in a hospi-

tal ward setting. In Group’05: Proceedings of the International Conference,Sanibel Island, Florida, U.S.A. ACM.

[Cabitza et al., 2006c] Cabitza, F., Sarini, M., Simone, C., and Telaro, M.

(2006c). Torres, a conceptual framework for articulation work across

boundaries. In COOP’06: Proceedings of the 7th International Conferenceon the Design of Cooperative Systems, France, Provence.

240

BIBLIOGRAPHY

[Cabitza et al., 2006d] Cabitza, F., Sarini, M., and Viscusi, G. (2006d). Let a

standard be standard: reminding people of deviations from standards. In

COOP’06: Proceedings of the 7th International Conference on the Design ofCooperative systems (short paper session), Provence, F.

[Cabitza et al., 2005c] Cabitza, F., Seno, B. D., and Sarini, M. (2005c). Djess

– a context-sharing middleware to deploy distributed inference systems in

pervasive computing domains. In ICPS’05: Proceedings of the IEEE Interna-tional Conference on Pervasive Services 2005, Santorini, Greece.

[Cabitza and Simone, 2006] Cabitza, F. and Simone, C. (2006). “You Taste

Its Quality”: Making sense of quality standards on situated artifacts. In

MCIS’06: Proceedings of the First Mediterranean Conference on InformationSystems, Venice, Italy, EU.

[Cabral et al., 2004] Cabral, L., Domingue, J., Motta, E., Payne, T., and

Hakimpour, F. (2004). Approaches to semantic web services: An overview

and comparisons. In ESWS2004: Proceedings of the First European SemanticWeb Symposium, Heraklion, Greece, EU.

[Campbell et al., 1999] Campbell, A. T., Coulson, G., and Kounavis, M. E.

(1999). Managing complexity: Middleware explained. IT Professional,1(5):22–28.

[Campbell et al., 1998] Campbell, H., Hotchkiss, R., Bradshaw, N., and Por-

teous, M. (1998). Integrated care pathways. British Medical Journal,316(10):133–137.

[Cantarelli, 1996] Cantarelli, M. (1996). Il modello delle prestazioni infer-mieristiche. Masson.

[Carlile, 2002] Carlile, P. (2002). A pragmatic view of knowledge and bound-

aries: boundary objects in new product development. Organization Science,

13(4):442–455.

[Carriero and Gelernter, 1989] Carriero, N. and Gelernter, D. (1989). Linda

in context. Communications of the ACM, 32(4):444–458.

[Carstensen and Schmidt, 1999] Carstensen, P. and Schmidt, K. (1999).

Handbook of human factors, chapter Computer supported cooperative

241

BIBLIOGRAPHY

work: New challenges to systems design, pages 619–636. Asakura Pub-

lishing, Tokyo, JP. (English version).

[Cengeloglu et al., 1994] Cengeloglu, Y., Khajenoori, S., and Linton, D.

(1994). DynaCLIPS: A dynamic knowledge exchange tool for intelligent

agents. In Proceedings of the Third CLIPS Conference at NASA Johnson SpaceCenter, Houston, TX, USA, September.

[Charalambos et al., 1995] Charalambos, I., Benbasat, I., and Dexter, A. S.

(1995). Electronic data interchange and small organizations: Adoption

and impact of technology. MIS Quarterly, 19(4):465–485.

[Chen and Rada, 1996] Chen, C. and Rada, R. (1996). Modelling situated

actions in collaborative hypertext databases. Journal of Computer Mediated-Communication, 2(3).

[Chen and Kotz, 2000] Chen, G. and Kotz, D. (2000). A survey of context-

aware mobile computing research. Technical Report TR2000-381, Dept. of

Computer Science, Dartmouth College.

[Ciborra, 1985] Ciborra, C. (1985). Reframing the role of computers in orga-

nizations: The transaction costs approach. In Proceedings of Sixth Interna-tional Conference on Information Systems, pages 16–18, Indianapolis, USA.

[Clement and Wagner, 1995] Clement, A. and Wagner, I. (1995). Fragmented

exchange: Disarticulation and the need for regionalized communication

spaces. In ECSCW’05: Fourth European Conference on Computer SupportedCooperative Work, pages 33–49, Stockholm, Sweden.

[Coiera, 2000] Coiera, E. (2000). When Conversation is better than computa-

tion. Journal of American Medical Informatics Association (JAMIA), 7:277–

286.

[Coiera, 2002] Coiera, E. (2002). Communication loads on clinical staff. TheMedical Journal of Australia, 176(9):415–418.

[Coiera and Tombs, 1998] Coiera, E. and Tombs, V. (1998). Communication

behaviours in a hospital setting - an observational study. British MedicalJournal, 316:673–677.

[Corkill, 1991] Corkill, D. D. (1991). Blackboard systems. AI Expert, 6(9):40–

47.

242

BIBLIOGRAPHY

[Crowston, 1994] Crowston, K. (1994). A taxonomy of organizational de-

pendencies and coordination mechanisms (working paper no. 3718-94).

Technical report, Massachusetts Institute of Technology, Sloan School of

Management.

[Crowston, 2003] Crowston, K. (2003). The Process Handbook, chapter A

taxonomy of organizational dependencies and coordination mechanisms,

pages 85–108. MIT Press, Cambridge, USA.

[Dan R. Olsen et al., 1998] Dan R. Olsen, J., Hudson, S. E., Phelps, M.,

Heiner, J., and Verratti, T. (1998). Ubiquitous collaboration via surface

representations. In CSCW ’98: Proceedings of the 1998 ACM conference onComputer supported cooperative work, pages 129–138, New York, NY, USA.

ACM Press.

[de Farias et al., 2000] de Farias, G., Ferreira, C., and van Sinderen, P. (2000).

A conceptual model for the development of cscw systems. In COOP2000:Proceedings of the Fourth International Conference on the Design of Coopera-tive Systems.

[Dey, 2001] Dey, A. K. (2001). Understanding and using context. PersonalUbiquitous Comput., 5(1):4–7.

[Dey et al., 2001] Dey, A. K., Salber, D., and Abowd, G. D. (2001). A con-

ceptual framework and a toolkit for supporting the rapid prototyping of

context-aware applications. Human-Computer Interaction (HCI) Journal,16(2-4):97–166.

[Dick et al., 1997] Dick, R. S., Steen, E. B., and Detmer, D. E., editors (1997).

The Computer-Based Patient Record: An Essential Technology for Health Care,Revised Edition. National Academy Press.

[Divitini and Simone, 2000] Divitini, M. and Simone, C. (2000). Supporting

different dimensions of workflow adaptability. Computer Supported Coop-erative Work, The Journal of Collaborative Computing, 9(3):365–397.

[Divitini et al., 1996] Divitini, M., Simone, C., and Schmidt, K. (1996).

ABACO: Coordination mechanisms in a multi-agent perspective. In

COOP’96: Proceedings of the 2nd International Conference on the Design ofCooperative Systems, pages 103–122, Juan-les-Pins, France. INRIA Press.

243

BIBLIOGRAPHY

[Dix, 1997] Dix, A. (1997). Challenges for cooperative work on the web: An

analytical approach. Computer-Supported Cooperative Work: The Journal ofCollaborative Computing, 6:135–156.

[Dix et al., 1993] Dix, A., Finlay, J., Abowd, G., and Bealle, R. (1993).

Human-Computer Interaction. Prentice Hall.

[Dobres, 2000] Dobres, M. A. (2000). Technology and social agency : outlininga practice framework for archaeology. Blackwell Publishers, Oxford, UK.

[Dolin et al., 2006] Dolin, R. H., Alschuler, L., Boyer, S., Beebe, C., Behlen,

F. M., Biron, P. V., and Shabo, A. (2006). Hl7 clinical document architecture,

release 2. Journal of the American Medical Informatics Association, 13:30–

39.

[Dougherty, 1999] Dougherty, G. (1999). Conventional, dictated versus

database-generated discharge summaries: Timeliness, quality and com-

pleteness. Canadian Medical Association, 160(3):345–346.

[Dourish and Bellotti, 1992] Dourish, P. and Bellotti, V. (1992). Awareness

and coordination in shared workspaces. In CSCW’92: Proceedings of the1992 ACM conference on Computer-supported cooperative work, pages 107–


[Dourish and Bly, 1992] Dourish, P. and Bly, S. (1992). Portholes: support-

ing awareness in a distributed work group. In CHI ’92: Proceedings of theSIGCHI conference on Human factors in computing systems, pages 541–547,

New York, NY, USA. ACM Press.

[Dourish et al., 2000a] Dourish, P., Edwards, W. K., Howell, J., LaMarca, A.,

Lamping, J., Petersen, K., Salisbury, M., Terry, D., and Thornton, J. (2000a).

A programming model for active documents. In UIST2000: Proceedings ofthe ACM Symposium on User Interface Software and Technology, San Diego,

USA.

[Dourish et al., 2000b] Dourish, P., Edwards, W. K., LaMarca, A., Lamping, J.,

Petersen, K., Salisbury, M., Terry, D. B., and Thornton, J. (2000b). Ex-

tending document management systems with user-specific active proper-

ties. ACM Transactions on Information Systems, 18(2):140–170.

244

BIBLIOGRAPHY

[Dreyfus, 1978] Dreyfus, H. L. (1978). What Computers Can’t Do: The Limitsof Artificial Intelligence. Harpercollins.

[Edmunds and Morris, 2000] Edmunds, A. and Morris, A. (2000). The prob-

lem of information overload in business organisations: a review of the lit-

erature. International Journal of Information Management, 20(1):17–28.

[Eiter et al., 2004] Eiter, T., Faber, W., Leone, N., Pfeifer, G., and Polleres,

A. (2004). A logic programming approach to knowledge-state planning:

Semantics and complexity. ACM Transactions on Computational Logic,5(2):206–263.

[Ellershaw, 2002] Ellershaw, J. (2002). Clinical pathways for care of the dy-

ing: An innovation to disseminate clinical excellence. Journal of PalliativeMedicine, 5(4):617 –621.

[Ellingsen and Monteiro, 2003] Ellingsen, G. and Monteiro, E. (2003). A

patchwork planet integration and cooperation in hospitals. ComputerSupported Cooperative Work, The Journal of Collaborative Computing,

12(1):71–95.

[Elliott and King, 2005] Elliott, M. S. and King, J. L. (2005). A common in-

formation space in criminal courts: Computer-supported cooperative work

(cscw) case management systems. In HICSS ’05: Proceedings of the Proceed-ings of the 38th Annual Hawaii International Conference on System Sciences(HICSS’05) - Track 8, page 272.1, Washington, DC, USA. IEEE Computer

Society.

[Engesmo and Tjora, 2006] Engesmo, J. and Tjora, A. (2006). Documenting

for whom? a symbolic interactionist analysis of technologically induced

changes of nursing handovers. New Technology, Work and Employment,21(2):176–189.

[Ferber, 1999] Ferber, J. (1999). Multi-Agent Systems: An Introduction to Dis-tributed Artificial Intelligence. Addison-Wesley Longman Publishing Co.,

Inc., Boston, MA, USA.

[Ferber and Mueller, 1996] Ferber, J. and Mueller, J.-P. (1996). Influences and

reaction: a model of situated multiagent systems. In ICMAS’96: Proceedingsof International Conference on Multi-Agent Systems.

245

BIBLIOGRAPHY

[Fikes and N.J.Nilsson, 1971] Fikes, R. and N.J.Nilsson (1971). Strips: A new

approach to the application of theorem proving to problem solving. Artifi-cial Intelligence, 3-4(2):189–208.

[Fischer et al., 2003] Fischer, S., Stewart, T. E., Mehta, S., Wax, R., and Lapin-

sky, S. E. (2003). Handheld computing in medicine. Journal of the AmericanMedical Informatics Association, 10:139–149.

[Fitzpatrick, 2004] Fitzpatrick, G. (2004). Integrated care and the working

record. Health Informatics Journal, 10(4):291–302.

[Fitzpatrick et al., 1995] Fitzpatrick, G., Tolone, W., and Kaplan, S. (1995).

Work, locales and distributed social worlds. In ECSCW ’95: Proceedings ofthe 1995 European Conference on Computer Supported Cooperative Work,

pages 1–16.

[Fitzpatrick and Boulton, 1994] Fitzpatrick, R. and Boulton, M. (1994).

Qualitative methods for assessing health care. Quality in Health Care,

3(2):107–113.

[Fjeld et al., 2002] Fjeld, M., Lauche, K., Bichsel, M., Voorhorst, F., Krueger,

H., and Rauterberg, M. (2002). Physical and virtual tools: Activitytheory

applied to the design of groupware. Computer Supported Cooperative Work,The Journal of Collaborative Computing, 11(1-2):153–180.

[Frank M. Shipman and Marshall, 1999] Frank M. Shipman, I. and Marshall,

C. C. (1999). Formality considered harmful: Experiences, emergingthemes,

and directions on the use of formal representations ininteractive systems.

Computer Supported Cooperative Work, The Journal of Collaborative Com-puting, 8(4):333–352.

[Friedman-Hill, 2003] Friedman-Hill, E. (2003). Jess in Action – Java Rule-based Systems. Manning Publications Co.

[Fuentes et al., 2004] Fuentes, L., Jimenez, D., and Pinto, M. (2004). To-

wards the development of ambient intelligence environments using aspect-

oriented techniques. In Workshop at AOSD’04, The International Conferenceon Aspect-Oriented Software Development, Lancaster UK.

[Fuggetta et al., 1998] Fuggetta, A., Picco, G. P., and Vigna, G. (1998). Un-

derstanding code mobility. IEEE Transactions on Software Engineering,

24(5):342–361.

246

BIBLIOGRAPHY

[Fussell et al., 1998] Fussell, S. R., Kraut, R. E., Lerch, F. J., Scherlis, W. L.,

McNally, M. M., and Cadiz, J. J. (1998). Coordination, overload and team

performance: effects of team communication strategies. In CSCW ’98: Pro-ceedings of the 1998 ACM conference on Computer supported cooperativework, pages 275–284, New York, NY, USA. ACM Press.

[Galegher and Kraut, 1990] Galegher, J. and Kraut, R. E. (1990). Computer-

mediated communication for intellectual teamwork: a field experiment in

group writing. In CSCW ’90: Proceedings of the 1990 ACM conference onComputer-supported cooperative work, pages 65–78, New York, NY, USA.

ACM Press.

[Garfinkel, 1967] Garfinkel, H. (1967). Studies in Ethnomethodology, chapter

“Good” organizational reasons for “bad” clinic records, pages 186–2006.

Prentice-Hall, New Jersey, USA.

[Gelernter, 1985] Gelernter, D. (1985). Generative communication in Linda.

ACM Trans. Program. Lang. Syst., 7(1):80–112.

[Giarratano, 1991] Giarratano, J. (1991). CLIPS User’s Guide. Software Tech-

nology Branch, Lyndon B. Johnson Space Center, Houston, TX, USA, ver-

sion 5.0 edition.

[Gibson, 1979] Gibson, J. J. (1979). The Ecological Approach to Visual Percep-tion. Lawrence Erlbaum Associates, New Jersey, USA.

[Gliem and Gliem, 2003] Gliem, J. and Gliem, R. (2003). Calculating, inter-

preting, and reporting cronbach’s alpha reliability coefficient for likert-type

scales. In Proceedings of the Midwest Research to Practice Conference in Adult,Continuing, and Community Education,.

[Gordon, 1997] Gordon, M. D. (1997). ‘It’s 10 a.m. Do you know where your

documents are? the nature and scope of information retrieval problems in

business. Information Processing and Management, 33(1):107–121.

[Gorman et al., 2000] Gorman, P., Ash, J., Lavelle, M., Lyman, J., Delcambre,

L., Maier, D., Weaver, M., and Bowers, S. (2000). Bundles in the Wild:

Managing Information to Solve Problems and Maintain Situation Aware-

ness. Library Trends, 49(2).

247

BIBLIOGRAPHY

[Gray and Reuter, 1994] Gray, J. and Reuter, A. (1994). Transactions Process-ing: Techniques and Concepts. Morgan Kaufmann Publishers Inc., San Fran-

cisco, CA, USA.

[Greenberg, 1990] Greenberg, S. (1990). Sharing views and interactions with

single-user applications. In Proceedings of the ACM Conference on OfficeInformation Systems, pages 227–237.

[Gregory et al., 1995] Gregory, J., Mattison, J., and Linde, C. (1995). Naming

notes: transitions from free text to structured entry. Methods of Informationin Medicine, 34(1-2):57–67.

[Grinter, 2000] Grinter, R. E. (2000). Workflow systems: Occasions for suc-

cess and failure. Computer Supported Cooperative Work, The Journal ofCollaborative Computing, 9(2):189–214.

[Group, 2000] Group, F. C. (2000). A primer on physician order entry. Tech-

nical report, California HealthCare Foundation’s Quality Initiative.

[Gruber, 1993] Gruber, T. R. (1993). A translation approach to portable on-

tologies. Knowledge Acquisition, 5(2):199–220.

[Grudin, 1988] Grudin, J. (1988). Why CSCW Applications Fail: Problems In

The Design And Evalutation Of Organizational Interfaces. In CSCW ’88:Proceedings of the International Conference on Computer Supported Cooper-ative Work, pages 85–93, Portland, Oregon, USA. ACMPress.

[Guimbretiere, 2003] Guimbretiere, F. (2003). Paper augmented digital doc-

uments. In UIST ’03: Proceedings of the 16th annual ACM symposium onUser interface software and technology, pages 51–60, New York, NY, USA.

ACM Press.

[Gutwin and Greenberg, 1997] Gutwin, C. and Greenberg, S. (1997).

Workspace awarness. Position paper for the ACM CHI’97 Workshop on

Awareness in Collaborative Systems, organized by Susan E. McDaniel and

Tom Brinck, Atlanta, USA.

[Gutwin and Greenberg, 2002] Gutwin, C. and Greenberg, S. (2002). A de-

scriptive framework of workspace awareness for real-time groupware.

Computer Supported Cooperative Work, The Journal of Collaborative Com-puting, 11(3-4):411–446.

248

BIBLIOGRAPHY

[Gutwin et al., 1996] Gutwin, C., Roseman, M., and Greenberg, S. A. (1996).

A usability study of awareness widgets in a shared workspace groupware

system. In CSCW ‘96: Proceedings of the International Conference on Com-puter Supported Cooperative Work, pages 258–267, Cambridge MA, USA.

ACM Press.

[Haas, 1996] Haas, C. (1996). Writing Technology: Studies on the Materialityof Literacy. Lawrence Erlbaum.

[Habing et al., 2001] Habing, N., Dietz, J., and Zwetsloot-Schonk, B. (2001).

Activity patterns in health care: identifying building blocks for the CPR.

SIGGROUP Bulletin, 22(2):9–15.

[Halverson, 2002] Halverson, C. A. (2002). Activity theory and distributed

cognition: Or what does CSCW need to do with theories? Computer Sup-ported Cooperative Work, The Journal of Collaborative Computing, 11(1-

2):243–267.

[Hampson et al., 1996] Hampson, J., Roberts, R., and Morgan, D. (1996).

Shared care: A review of the literature. Family Practice, 13(3):264–279.

[Hardstone et al., 2004] Hardstone, G., Hartswood, M., Procter, R., Slack, R.,

Voss, A., and Rees, G. (2004). Supporting informality: team working and

integrated care records. In CSCW ’04: Proceedings of the 2004 ACM confer-ence on Computer supported cooperative work, pages 142–151, New York,

NY, USA. ACM Press.

[Harper and Sellen, 1995] Harper, R. and Sellen, A. (1995). Collaborative

tools and the practicalities of professional work at the international mon-

etary fund. In CHI ’95: Proceedings of the SIGCHI conference on Humanfactors in computing systems, pages 122–129, New York, NY, USA. ACM

Press/Addison-Wesley Publishing Co.

[Harper et al., 1989] Harper, R. H. R., Hughes, J. A., and Shapiro, D. Z.

(1989). Working in harmony: An examination of computer technology in

air traffic control. In ECSCW’89: Proceedings of the First European Confer-ence on Computer Supported Cooperative Work, pages 73–86, London, UK.

[Hartswood et al., 2003] Hartswood, M., Procter, R., Rouncefield, M., and

Slack, R. (2003). Making a case in medical work: Implications for the elec-

249

BIBLIOGRAPHY

tronic medical record. Computer Supported Cooperative Work, The Journalof Collaborative Computing, 12:241–266.

[Hayes, 2000] Hayes, N. (2000). Work-arounds and boundary crossing in a

high tech optronics company: The role of co-operative workflow technolo-

gies. Computer Supported Cooperative Work, The Journal of CollaborativeComputing, 9(3/4):435–455.

[Hayes-Roth, 1985] Hayes-Roth, B. (1985). A blackboard architecture for

control. Artificial Intelligence, 26:251–321.

[Hayles, 1999] Hayles, K. (1999). How We Became Posthuman: Virtual Bodiesin Cybernetics, Literature, and Informatics. The University of Chicago Press,

Chicago, USA.

[Headrick, 2000] Headrick, D. R. (2000). When information came of age :technologies of knowledge in the age of reason and revolution, 1700-1850.

Oxford University Press.

[Heath et al., 2000] Heath, C., Knoblauch, H., and Luff, P. (2000). Technology

and social interaction: the emergence of ’workplace studies’. British Journalof Sociology, 51(2):299–320.

[Heath and Luff, 1992] Heath, C. and Luff, P. (1992). Collaboration and con-

trol. crisis management and multimedia technology in london underground

control rooms. Computer Supported Cooperative Work, The Journal of Col-laborative Computing, 1(2):69–94.

[Heath and Luff, 1996a] Heath, C. and Luff, P. (1996a). Cognition and Com-munication at Work, chapter Convergent Activities: Line Control and Pas-

senger Information in the London Underground, pages 96–129. Cambridge

University Press.

[Heath and Luff, 1996b] Heath, C. and Luff, P. (1996b). Documents and Pro-

fessional Practice: ‘bad’ organisational reasons for ‘good’ clinical records. In

CSCW’96: Proceedings of the international conference on computer-supportedcooperative work, pages 354–363, Cambridge MA. ACM Press.

[Heath et al., 2002] Heath, C., Svensson, M. S., Hindmarsh, J., Luff, P., and

vom Lehn, D. (2002). Configuring awareness. Computer Supported Coop-erative Work, The Journal of Collaborative Computing, 11(3-4):317–347.

250

BIBLIOGRAPHY

[Heath and Luff, 80] Heath, C. C. and Luff, P. (65–80). Collaborative activ-

ity and technological design: Task coordination in london underground

control rooms. In Bannon, L. J., Robinson, M., and Schmidt, K., editors,

ECSCW’91: Proceedings of the Second European Conference on Computer-Supported Cooperative Work, pages 65–80, Amsterdam, NL. Kluwer Aca-

demic Publishers.

[Heath et al., 2001] Heath, C. C., Luff, P., Kuzuoka, H., and Yamazaki, K.

(2001). Creating coherent environments for collaboration. In ECSCW’01:Proceedings of the Seventh European Conference on Computer Supported Co-operative Work, Bonn, Germany. Kluwer Academic.

[Heeks et al., 1999] Heeks, R., Mundy, D., and Salazar, A. (1999). Why health

care information systems succeed or fail. Technical report, Institute for

Development Policy and Management (IDPM), Manchester, UK.

[Henry et al., 1998] Henry, S., Douglas, K., Galzagorry, G., Lahey, A., and

Holzemer, W. (1998). A template -based approach to support utilization

of clinical practice guidelines within an electronic health record. Journal ofthe American Medical Informatics Association, 5(3):237–244.

[Hertzum, 1993] Hertzum, M. (1993). ‘information retrieval in a work set-

ting: A case study of the documentation part of chemists’ work’. In Bansler,

J. P., Bødker, K., Kensing, F., Nørbjerg, J., and PriesHeje, J., editors, Proceed-ings of the 16th IRIS. Information Systems Research Seminar in Scandinavia,DIKU report 93/16, pages 786–798. University of Copenhagen,.

[Hertzum, 1999] Hertzum, M. (1999). Six roles of documents in profession-

als’ work. In ECSCW’99: Proceedings of the Sixth European conference onComputer supported cooperative work, pages 41–60, Norwell, MA, USA.

Kluwer Academic Publishers.

[Hill and Gutwin, 2003] Hill, J. and Gutwin, C. (2003). Awareness support

in a groupware widget toolkit. In GROUP ’03: Proceedings of the 2003 inter-national ACM SIGGROUP conference on Supporting group work, pages 258–


[Hoare, 1969] Hoare, C. A. R. (1969). An axiomatic basis for computer pro-

gramming. Communication of the ACM, 12(10):576–580.

251

BIBLIOGRAPHY

[Howie et al., 1996] Howie, C. T., Kunz, J. C., and Law, K. H. (1996). Soft-

ware interoperability. Technical report, Center for Integrated Facility Engi-

neering, Stanford University.

[Hughes and King, 1993] Hughes, J. and King, V. (1993). Requirements andMetaphors of Shared Interaction Part II: Shared Artifacts. COMIC Deliverable4.1, chapter Paperwork, pages 153–325. Lancaster, UK.

[Hughes et al., 1995] Hughes, J., King, V., Rodden, T., and Andersen, H.

(1995). The role of ethnography in interactive systems design. Interac-tions, 2(2):56–65.

[Hutchins, 1995] Hutchins, E. (1995). How a cockpit remembers its speed.

Cognitive Science, 19:265–288.

[Hutchins, 1996] Hutchins, E. (1996). Cognition in the Wild. The MIT Press,

Cambridge, MA.

[Ireson, 1997] Ireson, C. (1997). Critical pathways: Effectiveness in achiev-

ing patient outcomes. Journal of Nursing Administration, 27(6):16–23.

[Ishida, 1995] Ishida, T. (1995). Parallel, distributed and multi-agent pro-

duction systems – A research foundation for distributed artificial intelli-

gence. In Lesser, V., editor, Proceedings of the First International Conferenceon Multi-Agent Systems, pages 416–422, San Francisco, CA. MIT Press.

[Jahnke et al., 2004a] Jahnke, J. H., Bychkov, Y., Dahlem, D., and Kawasme,

L. (2004a). Context-aware information services for health care. In KI2004Workshop - Modeling and Retrieval of Context.

[Jahnke et al., 2004b] Jahnke, J. H., Bychkov, Y., Dahlem, D., and Kawasme,

L. (2004b). Implicit, context-aware computing for health care. In OOP-SLA’04 Workshop on Building Software for Pervasive Computing.

[Jang et al., 2000] Jang, C. Y., Steinfield, C., and Pfaff, B. (2000). Supporting

awareness among virtual teams in a web-based collaborative system: the

teamSCOPE system. SIGGROUP Bulletin, 21(3):28–34.

[Jang et al., 2002] Jang, C.-Y., Steinfield, C., and Pfaff, B. (2002). Virtual

team awareness and groupware support: an evaluation of the TeamSCOPE

system. Internation Journal of Human-Computer Studies, 56(1):109–126.

252

BIBLIOGRAPHY

[Jones, 2003] Jones, M. (2003). “Computers can land people on Mars, why

can’t they get them to work in a hospital?” Implementation of an Electronic

Patient Record system in a UK Hospital. Methods of Information in Medicine,

42:410–415.

[Josefsson, 1999] Josefsson, U. (1999). Aspects of awareness in constructing

a common information space. In IRIS 22: Proceedings of the 22nd Informa-tion Systems Research Seminar in Scandinavia “Enterprise Architectures forVirtual Organizations”, Keuruu, Finland.

[Kahan et al., 2001] Kahan, J., Koivunen, M.-R., Prud’Hommeaux, E., and

Swick, R. R. (2001). Annotea: An open rdf infrastructure for shared web

annotations. In Proceedings International WWW Conference, volume 10,

Hong-Kong.

[Kaptelinin, 1996] Kaptelinin, V. (1996). Context and Consciousness: ActivityTheory and Human-Computer Interaction, chapter Activity Theory: Implica-

tions for Human-Computer Interaction. MIT Press, Cambridge, MA (USA).

[Keen, 1980] Keen, P. (1980). MIS research: Reference traditions and a cu-

mulative tradition. In Proceedings of the first International Conference onInformation Systems, pages 9–18, Philadelphia, USA.

[Kensing, 2004] Kensing, F. (2004). It-augmented shared care. In CSCW’04:Proceedings of the Distributed Collective Practices Workshop at the ACM Con-ference on Computer Supported Cooperative Work, Chicago, USA. ACM Press.

[Kiesel and Schuerr, 1995] Kiesel, N. and Schuerr, A. (1995). GRAS, a graph-

oriented (software) engineering database system. Information Systems,20(1):21–52.

[Kirsh, 1995] Kirsh, D. (1995). The intelligent use of space. Artificial Intelli-gence, 73(1-2):31–68.

[Koppel et al., 2005] Koppel, R., Metlay, J. P., Cohen, A., Abaluck, B., Localio,

A. R., Kimmel, S. E., and Strom, B. L. (2005). Role of computerized physi-

cian order entry systems in facilitating medication errors. Journal of theAmerican Medical Association, 293:1197–1203.

[Kuperman and Gibson, 2003] Kuperman, G. J. and Gibson, R. F. (2003).

Computer physician order entry: Benefits, costs, and issues. Annals of In-ternal Medicine, 139:31–39.

253

BIBLIOGRAPHY

[Kuutti, 1991] Kuutti, K. (1991). The concept of activity as a basic unit of

analysis for cscw research. In CSCW’91: Proceedings of the Second Euro-pean Conference on Computer-Supported Cooperative Work, pages 249–264.

Kluwer Academic Publisher.

[LaMarca et al., 1999] LaMarca, A., Edwards, W. K., Dourish, P., Lamping, J.,

Smith, I., and Thornton, J. (1999). Taking the work out of workflow: Mech-

anisms for document-centered collaboration. In ECSCW’99: Proceedings ofthe Sixth European Conference on Computer-Supported Cooperative Work,

Copenhagen, Denmark.

[Latour, 1999] Latour, B. (1999). Pandora’s Hope: Essays on the Reality ofScience Studies. Harvard University Press, Cambridge, MA, USA.

[Lauwers and Lantz, 1990] Lauwers, C. J. and Lantz, K. A. (1990). Collabora-

tion awareness in support of collaboration transparency: Requirements for

the next generation of shared window systems. In CHI’90: Proceedings ofthe ACM SIGCHI Conference on Human Factors in Computing Systems, pages

303–311, Seattle, Washington, USA. ACM Press.

[Lave, 1988] Lave, J. (1988). Cognition in Practice. Cambridge University

Press.

[Levy, 1994] Levy, D. (1994). “fixed or fluid? document stability and new me-

dia”. In Proceedings of the European Conference on Hypermedia Technology,

New York, USA. ACM Press.

[Lindwer et al., 2003] Lindwer, M., Marculescu, D., Basten, T., Zimmermann,

R., Marculescu, R., Jung, S., and Cantatore, E. (2003). Ambient intelligence

visions and achievements: Linking abstract ideas to real-world concepts.

In Proceedings of the conference on Design, Automation and Test in Europe(DATE ’03), pages 10–15.

[Lortal et al., 2005] Lortal, G., Lewkowicz, M., and Todirascu, A. (2005).

Ant&cow, a tool supporting collective interpretation of documents through

annotation and indexation. In Proceedings of DIENG, MATTA, IJCAI - KMOMWorkshop, Edinburgh.

[Luff and Heath, 1998] Luff, P. and Heath, C. (1998). Mobility in collabora-

tion. In CSCW’98: Proceedings of the 1998 ACM conference on Computersupported cooperative work, pages 305–314. ACM Press.

254

BIBLIOGRAPHY

[Luff et al., 1992] Luff, P., Heath, C., and Greatbatch, D. (1992). Tasks-in-

interaction: paper and screen based documentation in collaborative activ-

ity. In CSCW ’92: Proceedings of the 1992 ACM conference on Computer-supported cooperative work, pages 163–170, New York, NY, USA. ACM

Press.

[Luff et al., 2000] Luff, P., Hindmarsh, J., and Heath, C., editors (2000).

Workplace Studies: Recovering Work Practices and Informing System Design.

Cambridge University Press, Cambridge, UK.

[MacKay, 1999] MacKay, W. E. (1999). Is paper safer? the role of paper flight

strips in air traffic control. ACM Trans. Comput.-Hum. Interact., 6(4):311–

340.

[Malone and Crowston, 1994] Malone, T. and Crowston, K. (1994). The in-

terdisciplinary study of coordination. Computing Surveys, 26(1):87–119.

[Malone, 1983] Malone, T. W. (1983). How do people organize their desks?:

Implications for the design of office information systems. ACM Transactionson Information Systems, 1(1):99–112.

[Malone and Crowston, 1990] Malone, T. W. and Crowston, K. (1990). What

is coordination theory and how can it help design cooperative work sys-

tems? In Computer Supported Cooperative Work, The Journal of Collabora-tive Computing, pages 357–370.

[Mamei et al., 2003] Mamei, M., Zambonelli, F., and Leonardi, L. (2003). Tu-

ples On The Air: A middleware for context-aware computing in dynamic

networks. In ICDCSW ’03: Proceedings of the 23rd International Conferenceon Distributed Computing Systems, page 342. IEEE Computer Society.

[Mani and Maybury, 1999] Mani, I. and Maybury, M. T., editors (1999). Ad-vances in Automatic Text Summarization. The MIT Press.

[Mann and Williams, 2003] Mann, R. and Williams, J. (2003). Standards in

medical record keeping. Clinical Medicine, Journal of the Royal College ofPhysicians, 3(4):329–332.

[Mark, 2002] Mark, G. (2002). Conventions and Commitments in Distributed

CSCW Groups. Computer Supported Cooperative Work, The Journal of Col-laborative Computing, 11(3-4):349–387.

255

BIBLIOGRAPHY

[Mark et al., 1997] Mark, G., Fuchs, L., and Sohlenkamp, M. (1997). Sup-

porting groupware conventions through contextual awareness. In Prinz,

W., Rodden, T., Hughes, J., and Schmidt, K., editors, ECSCW’97: Proceed-ings of The Fifth European Conference on Computer Supported Cooperative,pages 253–268, Lancaster, UK. Kluwer Academic Publisher.

[Mark et al., 2002a] Mark, G., Gonzalez, V., Sarini, M., and Simone, C.

(2002a). Supporting articulation with the reconciler. In CHI Extended Ab-stracts, pages 814–815.

[Mark et al., 2002b] Mark, G., Gonzalez, V. M., Sarini, M., and Simone, C.

(2002b). Reconciling different perspectives: An experiment on technology

support for articulation. In COOP’02: Proceedings of the International Con-ference on the Design of Cooperative systems, pages 23–37.

[Martin et al., 2005] Martin, D., Paolucci, M., McIlraith, S., Burstein, M., Mc-

Dermott, D., McGuinness, D., Parsia, B., Payne, T., Sabou, M., Solanki, M.,

Srinivasan, N., and Sycara, K. (2005). Bringing semantics to web services:

The owl-s approach. Lecture Notes in Computer Science, 3387:26–42.

[Mays and Pope, 1996] Mays, N. and Pope, C. (1996). Qualitative research inhealth care. British Medical Journal Books, London, UK.

[Miller, 2004] Miller, T. (2004). Researching work processes at the micro-

scale level. In Proceedings of the 9th Great Lakes Information Studies Con-ference, Toronto, CA.

[Milner, 1980] Milner, R. (1980). A calculus of Communicating systems, vol-

ume 92. Springer-Verlag, Berlin Heidelberg.

[Moran and Dourish, 2001] Moran, T. P. and Dourish, P. (2001). Introduction

to the special issue on context-aware computing. Human-Computer Inter-action, 16:2–4.

[Mulholland et al., 2002] Mulholland, P., Zdrahal, Z., Domingue, J., Hatala,

M., and Bernardi, A. (2002). A methodological approach to supporting

organizational learning. International Journal of Human-Computer Studies,56(3):337–367.

[Mur-Veeman et al., 2001] Mur-Veeman, I., Eijkelberg, I., and Spreeuwen-

berg, C. (2001). How to manage the implementation of shared care. Jour-nal of Management in Medicine, 15(2):142–155.

256

BIBLIOGRAPHY

[Murphy et al., 2001] Murphy, A. L., Picco, G. P., and Roman, G.-C. (2001).

Lime: A middleware for physical and logical mobility. In ICDCS-21: Proceed-ings of the 21st International Conference on Distributed Computing Systems,pages 524–533, Phoenix ( AZ, USA).

[Nardi, 1995] Nardi, B. A. (1995). Studying context: a comparison of activ-ity theory, situated action models, and distributed cognition, pages 69–102.

Massachusetts Institute of Technology, Cambridge, MA, USA.

[Nielsen et al., 1992] Nielsen, M., Rozenberg, G., and Thiagarajan, P. S.

(1992). Elementary transition systems. Theoretical Computer Science,

96(1):3–33.

[Nii, 1986] Nii, P. (1986). Blackboard systems: The blackboard model of prob-

lem solving and the evolution of blackboard architectures. AI Magazine,

7(2):38–53,82–106.

[Nilsson, 1980] Nilsson, N. (1980). Principles of Artificial Intelligence. Tioga

Publishing Co., Palo Alto, CA, USA.

[Nonaka and Takeuchi, 1995] Nonaka, I. and Takeuchi, H. (1995). TheKnowledge Creating Company. Oxford University Press, Oxford, UK.

[Norman, 1988] Norman, D. A. (1988). The Design of Everyday Things. Dou-

bleday, New York, USA.

[Norman, 1991] Norman, D. A. (1991). Designing interaction: psychology atthe human-computer interface, chapter Cognitive artifacts, pages 17–38.

Cambridge University Press.

[Nurminen et al., 1997] Nurminen, M. I., Fjuk, A., and Smordal, O. (1997).

Taking articulation work seriously - an activity theoretical approach. Tech-

nical report, Turku Centre for Computer Science.

[Olson and Teasley, 1996] Olson, J. and Teasley, S. (1996). Groupware in the

wild: Lessons learned from a year of virtual collocation. In CSCW’96: Pro-ceedings of the ACM Conference on Computer-Supported Cooperative Work,

Boston, USA. ACM Press.

[Omicini et al., 2004] Omicini, A., Ricci, A., Viroli, M., Castelfranchi, C., and

Tummolini, L. (2004). Coordination artifacts: Environment-based coordi-

nation for intelligent agents. In Jennings, N. R., Sierra, C., Sonenberg, L.,

257

BIBLIOGRAPHY

and Tambe, M., editors, Third International Joint Conference on AutonomousAgents and Multiagent Systems – AAMAS’04, volume 1, page 286–293, New

York, USA. ACM.

[Panella et al., 2003] Panella, M., Marchisio, S., and Stanislao, F. D. (2003).

Reducing clinical variations with clinical pathways: do pathways work? In-ternational Journal for Quality in Health Care, 15:509–521.

[Parunak, 2003] Parunak, H. D. (2003). Making swarming happen. In Pro-ceedings of the Conference on Swarming and Network Enabled Command,Control, Communications, Computers, Intelligence, Surveillance and Recon-naissance (C4ISR), McLean, Virginia, USA.

[Parunak et al., 2003] Parunak, H. V. D., Brueckner, S., Fleischer, M., and

Odell, J. (2003). A preliminary taxonomy of multi-agent interactions. In

Proceedings of the 2nd International Joint conference on Autonomous Agentsand Multiagent Systems (AAMAS 2002), pages 1090–1091. ACM Press.

[Pearson et al., 1995] Pearson, S., Goulart-Fisher, D., and Lee, T. (1995). Crit-

ical pathways as a strategy for improving care: problems and potential.

Annals of Internal Medicine, 12:941–948.

[Pollock, 2005] Pollock, N. (2005). When is a work-around? conflict and ne-

gotiation in computer systems development. Science, Technology & HumanValues, 30(4):496–514.

[Prinz, 1994] Prinz, W. (1994). Object-oriented organization modeling for

the support of cscw. System Sciences, Information Systems: Collabora-tion Technology Organizational Systems and Technology, Proceedings of theTwenty-Seventh Hawaii International Conference on, 4:797–806.

[Pritchard and Hughes, 1995] Pritchard, P. and Hughes, J. (1995). SharedCare. The Future Imperative. Royal Society of Medicine Press, London.

[Quaglini et al., 2005] Quaglini, S., Panzarasa, S., Cavallini, A., Micieli, G.,

Pernice, C., and Stefanelli, M. (2005). Smooth integration of decision sup-

port into an existing electronic patient record. In AIME, pages 89–93.

[Randall, 2000] Randall, S. (2000). What’s common about common informa-

tion spaces? paper presented at the workshop on cooperative organisation

258

BIBLIOGRAPHY

of common information spaces. Technical report, Technical University of

Denmark. Available at http://dmm.cti.dtu.dk/position/randall.pdf.

[Randell, 2004] Randell, R. (2004). Accountability in an alarming environ-

ment. In CSCW ’04: Proceedings of the 2004 ACM conference on Com-puter supported cooperative work, pages 125–131, New York, NY, USA. ACM

Press.

[Raposo and Fuks, 2002] Raposo, A. and Fuks, H. (2002). Cooperative Sys-tems Design. Frontiers in Artificial Intelligence and Applications, volume 74,

chapter Defining Task Interdependencies and Coordination Mechanisms for

Collaborative Systems, pages 88–103. IOS PRESS, Amsterdam, NL.

[Raposo et al., 2000] Raposo, A. B., Magalhaes, L. P., and Ricarte, I. L. M.

(2000). Petri nets based coordination mechanisms for multi-workflow en-

vironments. Computer Systems Science and Engineering, 15(5):315–326.

[Reddy and Dourish, 2002] Reddy, M. and Dourish, P. (2002). A Finger on

the Pulse: Temporal Rhythms and Information Seeking in Medical Work. In

CSCW’02: Proceedings of the international Conference of Computer SupportedCooperative Work. ACM Press.

[Reddy et al., 2001] Reddy, M., Dourish, P., and Pratt, W. (2001). Coordi-

nating Heterogeneous Work: Information and Representation in Medical

Care. In ECSCW’01; Proceedings of the European Conference on Computer-Supported Cooperative Work, Bonn.

[Reiser, 1984] Reiser, S. J. (1984). Transformation and tradition in the sci-ences: Essays in honor of I. Bernard Cohen, chapter Creating form out of

mass: The development of the medical record, pages 303–316. Cambridge

University Press, New York, USA.

[Ricci et al., 2004] Ricci, A., Viroli, M., and Omicini, A. (2004). Agent coor-

dination context: From theory to practice. In in Proc. of the Cybernetics andSystems 2004, 17th European Meeting on Cybernetics and Systems Research(EMCSR 2004), volume 2, Vienna, Austria. Austrian Society for Cybernetic

Studies.

[Robinson and Bannon, 1991] Robinson, M. and Bannon, L. (1991). Ques-

tioning representations. In ECSCW’91: Proceedings of the Second Euro-

259

BIBLIOGRAPHY

pean Conference on Computer-Supported Cooperative Work, Amsterdam, The

Netherlands.

[Rolland et al., 2006] Rolland, K., V.Hepsø, and Monteiro, E. (2006). Con-

ceptualizing common information spaces across heterogeneous contexts:

mutable mobiles and side-effects of integration. In CSCW ’06: Proceedingsof International conference on computer-supported cooperative work. ACM

Press.

[Roper et al., 1980] Roper, N., Logan, W., and Tierney, A. (1980). The Ele-ments of Nursing. Churchill Livingstone.

[Roscoe et al., 1997] Roscoe, A. W., Hoare, C. A. R., and Bird, R. (1997). TheTheory and Practice of Concurrency. Prentice Hall PTR, Upper Saddle River,

NJ, USA.

[Russell and Norvig, 1995] Russell, S. and Norvig, P. (1995). Artificial Intelli-gence: A Modern Approach. Prentice Hall.

[Sarini and Simone, 2002] Sarini, M. and Simone, C. (2002). Recursive Ar-

ticulation work in Ariadne: the alignment of meanings. In COOP’02: Pro-ceedings of International Conference on the Design of Cooperative Systems,pages 191–206, Saint Raphael, France.

[Schmidt, 1991] Schmidt, K. (1991). Riding a Tiger, or Computer Supported

Cooperative Work. In ECSCW ‘91: Proceedings of the Second European Con-ference on Computer-Supported Cooperative Work, pages 1–16, Amsterdam,

NL. Kluwer.

[Schmidt, 1994a] Schmidt, K. (1994a). Cooperative work and its articula-

tion: Requirements for computer support. Le Travail Collectif - Travail Hu-main, 57(4):345–366.

[Schmidt, 1994b] Schmidt, K. (1994b). Social Mechanisms of Interaction.COMIC Deliverable 3.2, chapter Mechanisms of interaction reconsidered,

pages 15–122. Lancaster University.

[Schmidt, 1997] Schmidt, K. (1997). Of maps and scripts: the status of formal

constructs in cooperative work. In GROUP’97: Proceedings of the GROUPConference, pages 138–147, Phoenix Arizona USA. ACM Press.

260

BIBLIOGRAPHY

[Schmidt, 1998] Schmidt, K. (1998). Some notes on mutual awareness -

cotcos-report. Technical report, Technical University of Denmark.

[Schmidt, 2000] Schmidt, K. (2000). Distributed collective practices: A cscw

perspective, invited talk. In Proceedings of the Conference on DistributedCollective Practices.

[Schmidt, 2002] Schmidt, K. (2002). The problem with ‘Awareness’: Intro-

ductory remarks on ‘Awareness in CSCW’. Computer Supported CooperativeWork, The Journal of Collaborative Computing, 11(3):285–298.

[Schmidt and Bannon, 1992] Schmidt, K. and Bannon, L. (1992). Taking

CSCW Seriously: supporting Articulation Work. Computer Supported Co-operative Work, The Journal of Collaborative Computing, 1(1):7–40.

[Schmidt and Simone, 1995] Schmidt, K. and Simone, C. (1995). Demonstra-tor prototypes of Computational Mechanisms of Interaction. COMIC Deliver-able 3.3, chapter Coordination mechanisms: An approach to CSCW systems

design, pages 15–122. Lancaster University.

[Schmidt and Simone, 1996] Schmidt, K. and Simone, C. (1996). Coordina-

tion Mechanisms: Towards a conceptual foundation for CSCW systems de-

sign. Computer Supported Cooperative Work, The Journal of CollaborativeComputing, 5(2-3):155–200.

[Schmidt and Wagner, 2002a] Schmidt, K. and Wagner, I. (2002a). Coordina-

tive artifacts in architectural practice. In at al., M. B.-F., editor, COOP 2002:Proceedings of the Fifth International Conference on the Design of CooperativeSystems, pages 257–274, Saint Raphal, France. IOS Press, Amsterdam.

[Schmidt and Wagner, 2002b] Schmidt, K. and Wagner, I. (2002b). Coordi-

native artifacts in architectural practise. In COOP’02: Proceedings of theInternational Conference on the Design of Cooperative Systems, pages 257–

274.

[Schmidt and Wagner, 2004] Schmidt, K. and Wagner, I. (2004). Ordering

Systems: Coordinative practices and artifacts in architectural design and

planning. Computer Supported Cooperative Work, The Journal of Collabora-tive Computing, 13(5-6):349–408.

261

BIBLIOGRAPHY

[Seiner, 2001] Seiner, R. (2001). Metadata as a knowledge management en-

abler. TDAN.com & KIK Consulting Services The Data Administration Newslet-ter (TDAN.com) ., 15. Available at www.tdan.com.

[Sellen and Harper, 2003] Sellen, A. J. and Harper, R. H. R. (2003). The Mythof the Paperless Office. MIT Press, Cambridge MA.

[Sengupta and Zhao, 1998] Sengupta, K. and Zhao, J. (1998). Improving the

communicationai effectiveness of virtual organizations through workflow

automation. International Journal of Electronic Commerce, 3(1):49–69.

[Serres and Latour., 1995] Serres, M. and Latour., B. (1995). Conversationson Science, Culture and Time. University of Michigan Press.

[Shannon and Weaver, 1949] Shannon, C. and Weaver, W. (1949). The Math-ematical Theory of Communication. University of Illinois Press, Urbana, Ill,

USA.

[Simone and Bandini, 2002] Simone, C. and Bandini, S. (2002). Integrat-

ing awareness in cooperative applications through the reaction-diffusion

metaphor. Computer Supported Cooperative Work, The Journal of Collabora-tive Computing, 11((3-4)):495–530.

[Simone and Divitini, 1999] Simone, C. and Divitini, M. (1999). Integrat-

ing Contexts to Supporting Coordination: The CHAOS Project. Com-puter Supported Cooperative Work, The Journal of Collaborative Computing,

8(3):239–283.

[Simone and Sarini, 2001] Simone, C. and Sarini, M. (2001). Adaptabil-

ity of classification schemes in cooperation: What does it mean? In EC-SCW’01: Proceedings of European Conference on Computer-Supported Coop-erative Work, pages 19–38. Kluwer Academic Publishers.

[Simone and Schmidt, 1998] Simone, C. and Schmidt, K. (1998). Taking the

distributed nature of cooperative work seriously. In Proceedings of the 6thEuromicro Workshop on Parallel and Distributed Processing, pages 295–301,

Madrid, Spain. IEEE Computer Society.

[Simone and Schmidt, 2000] Simone, C. and Schmidt, K. (2000). Mind the

gap! Towards a unified view of CSCW. In COOP2000: Proceedings of the

262

BIBLIOGRAPHY

fourth international conference on the design of cooperative systems, Sophia-

Antipolis (Fr).

[Sorbya et al., 2002] Sorbya, I. D., Melbyb, L., and Nytroa, O. (2002). Char-

acterising Cooperation In The Ward: A Framework for Producing Require-

ments to Mobile Electronic Healthcare Records. In Computer Science Grad-uate Student Conference 2002 - (CSGSC-2002).

[Star and Griesemer, 1989] Star, S. L. and Griesemer, J. R. (1989). Institu-

tional Ecology, ’Translations’ and Boundary Objects: Amateurs and Profes-

sionals in Berkeley’s Museum of Vertebrate Zoology, 1907-39. Social Studiesof Science, 19:387–420.

[Steels, 1994] Steels, L. (1994). The artificial life roots of artificial intelli-

gence. Artificial Life Journal, 1(1):89–125.

[Strauss, 1985] Strauss, A. (1985). Work and the division of labor. The Soci-ological Quarterly, 26(1):1–19.

[Strauss, 1988] Strauss, A. (1988). The articulation of project work: An or-

ganizational process. The Sociological Quarterly, 29(2):163–178.

[Strauss et al., 1982] Strauss, A., Fagerhaugh, S., Suczek, B., and Wiener, C.

(1982). Sentimental work in the technologized hospital. Sociology of Healthand Illness, 4(3):254–278.

[Strauss et al., 1985] Strauss, A., Fagerhaugh, S., Suczek, B., and Wiener, C.

(1985). The Social Organization of Medical Work. University of Chicago

Press.

[Strohbach et al., 2004] Strohbach, M., Gellersen, H.-W., Kortuem, G., and

Kray, C. (2004). Cooperative artefacts: Assessing real world situations with

embedded technology. In Ubicomp’04: Proceedings of the 6th InternationalConference on Ubiquitous Computing, pages 250–267.

[Suchman, 1993] Suchman, L. (1993). Technology in Working Order. Studiesof Work, Interaction, and Technology, chapter Technologies of Accountabil-

ity: On Lizards and Airplanes, pages 113–126. Routledge, London, UK.

[Suchman, 1987] Suchman, L. A. (1987). Plans and situated actions: Theproblem of human-machine communication. Cambridge University Press.

263

BIBLIOGRAPHY

[Suchman, 1996] Suchman, L. A. (1996). Cognition and Communication atWork, chapter Constituting shared workspaces, pages 35–60. Cambridge

University Press, Cambridge, UK.

[Susi and Ziemke, 2001] Susi, T. and Ziemke, T. (2001). Social cognition,

artefacts, and stigmergy: A comparative analysis of theoretical frameworks

for the understanding of artefact-mediated collaborative activity. CognitiveSystems Research, 2:273–290.

[Tanenbaum and van Steen, 2002] Tanenbaum, A. S. and van Steen, M.

(2002). Distributed Systems: Principles and Paradigms. Prentice Hall.

[Tang and McDonald, 2000] Tang, P. C. and McDonald, C. J. (2000). MedicalInformatics: Computer Applications in Health Care and Biometrics, chapter

Computer-based patient-record systems. Springer-Verlag.

[Tata et al., 1999] Tata, S., Canals, G., and Godart, C. (1999). Specifying in-

teractions in cooperative applications. In Proceedings of the Eleventh In-ternational Conference on Software Engineering and Knowledge Engineering,

Kaiserslautern, Germany.

[Tellioglu, 2003] Tellioglu, H. (2003). Modeling coordinated work: Definition

and application of the model “coordinated work environment”. Journal ofSupercomputing, 24(2):161–171.

[Theraulaz and Bonabeau, 1999] Theraulaz, G. and Bonabeau, E. (1999). A

brief history of stigmergy. Artificial Life, 5:97–116.

[Timmermans and Berg, 2003] Timmermans, S. and Berg, M. (2003). The

practice of medical technology. Sociology of health and illness, 25:97–114.

[Tollmar et al., 1996] Tollmar, K., Sandor, O., and Schemer, A. (1996). Sup-

porting social awareness @work: Design and experience. In CSCW ‘96:Proceedings of the International Conference on Computer Supported Cooper-ative Work, pages 298–307, Cambridge MA, USA. ACM Press.

[van der Aalst et al., 2000a] van der Aalst, W., Desel, J., and Oberweis, A.

(2000a). Business Process Management - Models, Techniques and EmpiricalStudies. Lecture Notes in Computer Science 1806. Springer Verlag, Berlin.

264

BIBLIOGRAPHY

[van der Aalst and Jablonski, 2000] van der Aalst, W. and Jablonski, S.

(2000). Dealing with workflow change: Identification of issues and solu-

tions. International Journal of Computer Systems, Science, and Engineering,

15(5):267–276.

[van der Aalst et al., 2000b] van der Aalst, W. M. P., Barros, A. P., ter Hofstede,

A. H. M., and Kiepuszewski, B. (2000b). Advanced workflow patterns. In

CooplS ’02: Proceedings of the 7th International Conference on CooperativeInformation Systems, pages 18–29, London, UK. Springer-Verlag.

[van Ginneken and Moorman, 1997] van Ginneken, A. and Moorman, P.

(1997). Handbook of Medical Informatics, chapter The patient record. Bohn

Stafleu Van Loghum.

[Weed, 1971] Weed, L. (1971). The problem oriented record as a basic tool in

medical education, patient care,and research. Annals of Clinical Research,

3(3).

[Weiser, 1991] Weiser, M. (1991). The computer for the twenty-first century.

Scientific American, pages 94–10.

[Weiser, 1993] Weiser, M. (1993). Some computer science issues in ubiqui-

tous computing. Communications of the ACM, 36(7):75–84.

[Weiser and Brown, 2005] Weiser, M. and Brown, J. S. (2005). The coming

age of calm technology. Technical report, The Institute for End User Com-

puting, Inc. as edited on Thursday, June 23, 2005.

[Wenger, 1998] Wenger, E. (1998). Communities of Practice: Learning, Mean-ing, and Identity. Cambridge University Press.

[Wesley, 1995] Wesley, R. L. (1995). Nursing theories and models. Spring-

house, PA: Springhouse Corporation.

[Wilson, 1975] Wilson, E. O. (1975). Sociobiology: The New Synthesis. Har-

vard.

[Winograd and Flores, 1986] Winograd, T. and Flores, F. (1986). Understand-ing Computers and Cognition: a new foundation for design. Addison Wesley,

Reading MA.

265

BIBLIOGRAPHY

[Winthereik and Vikkelso, 2005] Winthereik, B. R. and Vikkelso, S. (2005).

Ict and integrated care: Some dilemmas of standardising inter-

organisational communication. Computer Supported Cooperative Work, TheJournal of Collaborative Computing, 14(1):43–67.

[Yates, 1993] Yates, J. (1993). Control through Communication. The Rise ofSystem in American Management. The Johns Hopkins University Press, Bal-

timore and London.

[Zuberek, 1991] Zuberek, W. (1991). Timed petri nets - definitions, proper-

ties, and applications. Microelectronics and Reliability, 31(4):627–644.

266

Date post:	24-Feb-2022
Category:	Documents
Upload:	others
View:	6 times
Download:	0 times