The Patient Scheduler was developed during the SAIK project5. From a research perspective, the Patient Scheduler has primarily served three purposes:
1. Its design is the experimental and empirical foundation for the theo-retical discussion on design, following this chapter.
2. As a concrete illustration of how cooperation and coordination within a hospital can be supported by computer technology, it has been an important vehicle for discussing new ways of organizing hospital work.
The Patient Scheduler has thus been an important instrument in the experimental research approach taken in this research project 3. It has been an evolving crystallization of the design results obtained
during the Participatory Design process at the hospitals, illustrating design solutions to some of the more difficult aspects of cooperation across departmental boundaries. Some of the design principles and rationales embodied in the prototype are now being applied in other projects at KMD.
Basically, the Patient Scheduler helps to plan patient treatment across professional and departmental boundaries through requesting, scheduling, and booking appointments for some action in the treatment of a patient.
The Patient Scheduler is divided into 4 modules: (i) an organizational module, (ii) a module handlingcommunication, (iii) a module handling plan-ning and scheduzing, and (iv) a sharing module. Numbers in brackets refer to the numbers i figure 2.2 and names incourier font are the core analysis patterns in the OOA model.
5The Patient Scheduleris programmed in MS Visual Basic, runs under Windows 95/NT using a ODBC compliant database (either MS Access or MS SQL Server) as per-sistent store. It contains 31 forms (windows) and 9385 lines of source-code.
Figure 2.2: The Patient Scheduler. Typical workspace for a clinical (surgical) department (K).
The organizational module contains a hierarchy of organizational units (1), each of which “owns” a set of resources, and has employees and patients(2). Employees and patients are considered resources as well (they inherit the generic resource class). Resources are organized in hierarchical resource groups, and can either be a temporal resource, or a consumable resource. An organizational unit can perform certain services, each po-tentially linked to one or more resources needed to perform this particular service.
The communication module supports sending a request (termed aproposal) for a patient appointment from one organizational unit to another (3).
Depending upon the recipient, different services can be chosen. The sender can ask for different notifications, such as “Tell me if this appointment has not been scheduled before 12-03-98”, and/or a suggested time for the appointment can be stated on the request. An appointment has three main stages: (i) proposed, (ii) implemented (or scheduled), and (iii) completed.
Furthermore, a note, as an ordinary email message can be send between organizational units, or can be attached to appointments or other objects.
In- and out-going appointments, notes, and notifications are handled in a communication center(4), with the ability to create a hierarchy offolders and to set up different kinds of filters – similar to many ordinary email systems.
Figure 2.3: The Patient Scheduler. Typical workspace for a service (radiology) department (“Røntgen”).
The scheduling and planning module helps the different departments to plan their work by scheduling in-coming and their own appointments on different resource calendars (5) made up of different timeslots. An appointment can be scheduled on several resources, and a semi-automatic scheduling mechanismhelps the user to find a timeslot, where all selected resources are available (6). Each temporal resource has a calendar designed to support easy drag-and-drop scheduling and re-scheduling, and to support different kinds of overviews; day, week, month, Gantt charts. Treating the patient as a resource means that the patient has such a calendar as well, termed a patient calendar (7). Such a patient calendar turned out to be of big importance in the attempt to support the PFH ideas. Several resources can be compared and juxtaposed in a resource overview (8). The plan-ning module also supports saving “best practices” through the creation of appointment templates (9) and programs (10). If a certain appointment has a recurrent pattern, a template can be made. For example, requesting an X-ray examination of the chest (Thorax) occurs frequently at any hospital, and a template containing all the details for this examination can be made and used whenever a Thorax examination is needed. These templates can be combined into a program, which is a list of appointment templates needed for a certain treatment. For example, an unraveling program for a diabetes patient is a list of X-ray examinations and laboratory tests that have to be made in order for the physician to diagnose the degree of diabetes.
The sharing mechanism of PSlets the owner of a certain object (resource, timeslot, note, appointment, folder, etc.) specify the level of access (none, view, read, write, delete) for different users and/or organizational units.
Three important types of objects are shared in PS: (i) resources, (ii) folders, and (iii) templates and programs.
If a department owning aresource has granted a user (or the user’s organi-zational unit) read-access to it, the user can look into the resource’s calendar and pick a spare timeslot, and send a proposal to have this slot. If the user has write-access, (s)he can schedule the appointment on his/her own. This kind of “directly booking” on other department’s resources turned out to be an extremely efficient way of coordinating work across departments, but also a form of cooperation which touched upon deeply-rooted political issues
within hospitals in Denmark (c.f. [2, 6])6.
Sharing folders in the communication center enables an efficient coopera-tion within a department, resembling much the way cooperacoopera-tion is achieved without computers. Placing appointments and notes in a specific folder, is a message for someone to take over the case.
Sharing of templates and programs enables a department to ‘publish’ tem-plates and programs to be used by other departments. Hence, instead of having each department within a hospital creating their own Thorax tem-plate, they can use the Thorax template published and shared by the radi-ology department. This has the positive effect that the template is made and maintained by the ones that have to attend to the proposals made by applying the template, thereby enabling them to specify how an examina-tion should be requested. However, in order for other departments to use a template provided by e.g. the radiology department, they cannot ‘take’ or copy the template and use it in their programs – then it would not reflect the changes made to the original template, and the benefit just described would vanish. Therefore, they need to refer to the template. Thus, a program is actually not made up by templates but is made up bytemplate references to templates. Similar, programs can be shared, and a template reference can point to another program. Hence, programs are hierarchical and can contain programs within programs, some of the programs belonging to your own department, others to other departments.
6Danish healthcare authorities and IT vendors have, however, an increasing aware-ness of the benefits of using systems for electronic booking within hospitals, and in the healthcare sector in general (Sundhedsministeriet, 1998).
Chapter 3
Activity Theory and Design
The aim of this thesis is to provide a theory about computer support for cooperative work as a part of a theory of human work activities. For this purpose activity theory is especially well suited. Firstly, because activity the-ory provides an philosophical framework for understanding collective human work activities as embedded within a social practice (e.g. an organization), and mediated by artifacts, including computer-based artifacts. Secondly, by building on a dialectical notion between doing and developing work, activity theory provides a foundation for understanding both the dynamics of co-operative work changing over time, and for understanding changes in work caused by employing new technology. Thirdly, because extensive work within understanding design of computer artifacts from an activity theoretical per-spective has already been done, the present framework for CSCW fits into, and builds upon, this existing work. From a design perspective I find this latter argument for using activity theory especially important. By using ac-tivity theory in the design of collaborative computer systems, shifts between reflecting upon issues of the user interface, issues concerning the support for cooperative work activities, or issues concerning the design process can use the same conceptual basis. This in turn enables the design practitioner to overcome the artificial segregation of design in different research fields and to work with the same conceptual basis whether addressing collaboration support or user-interface design.
This chapter starts with a short review of the existing work using activity theory for conceptualizing the design of computer artifacts. This review
fo-cus on pointing out where my work extends this previous work. This section is followed by a section that provides a basic introduction to activity theory in general, which is again followed by a section describing the activity theo-retical understanding of cooperative activities. This last section introduces parts of activity theory that have not been introduced nor used within design of computer artifacts before. Finally, the presented activity theoretical ap-proach to CSCW is related to relevant other scientific foundations suggested within CSCW.
3.1 Activity Theoretical Approaches to De-sign of Computer Artifacts
In a philosophical investigation into the nature of computer systems and human activity, Raeithel (1992) argues that the design of real-world software needs to incorporate a knowledge of how working communities regulate their joint activity, and that activity theory, as a social psychological theory on human self-regulation, is a well suited epistemological foundation for design.
Applying activity theory to understand the activity of design itself has been made by Bisgaard et al. (1989), and Bødker (1991) has used activity theory to describe the design activity as an anthropological phenomenon. Bertelsen (1998) has applied activity theory to understand design artifacts, i.e. artifacts that mediate the design activity. The purpose of this thesis is, however, not to describe the design process as an activity as such, but to use activity theory as a theoretical basis for understanding the cooperative work activities, which we intend to support by computers.
The first step in providing an activity theoretical approach to computer de-sign was taken by Bødker in her Ph.D. thesis from 1987 (published 1991). The focus of Bødker’s work is on designing the user interface, and she provides a conceptual basis for understanding individual activity directed towards com-puter artifacts on the operational level, and for design of userinterfaces. This theoretical foundation for human computer interaction has been extended and refined by numerous other authors (c.f. Nardi, 1996a), including myself (Bardram & Bertelsen, 1995). This work, however, only focus on human-computer interaction as the operational part of an activity and is hence not sufficient to understand cooperative work activities supported by computers.
Kuutti has in his Ph.D. thesis (1994) provided an activity theoretical per-spective on Information Systems (IS) and cooperative work. Kuutti provides 10 arguments why activity theory is a good foundation for understanding CSCW – “the concept of work activity fulfills nicely most of the demand stated for the basic unit of analysis, [ . . . which is] needed in order to ana-lyze a cooperative work situation for design purposes” (Kuutti, 1994; p. 50, 56). I shall not reiterate these arguments here, but kindly refer the reader to Kuutti’s thesis. Unfortunately, however, Kuutti’s work seems to reach an end before it gets really interesting in terms of providing a conceptual basis for the design of CSCW technologies. First, Kuutti argues himself (ibid., p. 57) that although activity theory obviously is a promising starting point when an analysis of new work situations is considered, it leaves much to be desired when it comes to detailed analysis of practical work situations. Ku-utti mentions, for example, that activity theory has no description of the flow of work processes, no description of the resources available and the sharing of them, or no description of the division of work among actors as related to the object of the work. This limitation is, however, not completely true – it is only a limitation in the work of Kuutti because he relies solely on the work of the Finish activity theorist Yrj¨o Engestr¨om and his work, especially his dissertation from 1987. In this thesis, I shall extend the work of Kuutti to provide a conceptual basis for a detailed understanding of collaborative work processes. Second, Kuutti’s focus is purely to “analyze a cooperative work situation for design purposes” (ibid., p. 50; my emphasis). Hence, he provides no conceptual understanding of the benefits of computer artifacts in cooperative activity, nor does he provide any conceptual basis for designing such collaborative computer artifacts.
In summary, this thesis provides a theoretical framework for the design of computer support for cooperative work based on activity theory. In com-parison to the work already done within activity theory and the design of computer applications this work is new and unique by providing a conceptual foundation for:
• analyzing cooperative work activities in detail, describing the different types of cooperation and the dynamic transition between these types (this chapter)
• understanding how collaborative work is interdependent, coordinated, and mediated by artifacts (chapter 4)
• a framework for understanding collaboration artifacts supporting col-laborative work (chapter 4)
• how collaborative computer artifacts can be designed to mediate col-laborative work activities (chapter 5)
This conceptual basis can be used toanalyze how collaboration artifacts in general, and computer based artifacts in particular, mediate a collaborative activity, as it is done in [4] and [6]. It can be used to understand how to design collaborative computer systems, which transgress current limitation in conceptualizations on cooperative work and coordination, as it is done in [3] and [6]. And it can be used to developmethods for designing collaborative computer artifacts, as it is done in [1], [2], and [5].