Experiences with effects specifications

Transcription

1 Published in M. Hertzum and C. Jørgensen (eds.). (2011). Balancing Sourcing and Innovation in Information Systems Development, pp Tapir Academic Press, Trondheim, NO. Experiences with effects specifications Jesper Simonsen, Morten Hertzum, and Anders Barlach Roskilde University Abstract. We describe the effects-specification process from a project that was conducted during the fall 2010 and spring of 2011 in this chapter. The project configured and implemented an electronic patient record system at a maternity ward at a hospital located in a European region. The process comprised workshops with effects specification with management and end-users and an agile development process including prototypes configured from the effects specifications. We describe the project and the effects-specification process through which effects were related to the system design and instruments for measuring effects were designed. The project is analyzed and lessons learned are discussed. Keywords: partnership sourcing; effects-driven IT development, effects specification, effect means end hierarchy, management effect workshop, end-user effect workshop, electronic health record. 1 Introduction This chapter describes an information technology (IT) vendor s experiences with effects specifications used in a partnership-sourcing relationship with a client, a large hospital complex located in a European region (the Hospital for short). The IT vendor, CSC Scandihealth A/S (or CSC for short), has for years engaged in long-term relations with clients in the healthcare area using a partnership-sourcing approach. A partnership between the vendor and the client is especially relevant when the technical development and organizational implementation of large IT systems extend over considerable periods of time and when the systems continually need to be re-configured to fit changing and emerging client needs. This is possible when the system is not developed from scratch but based on a highly configurable standard system. The overall strategy of the Hospital is to use CSC s configurable standard system CSC Clinical Suite (CCS) as the Hospital s overall electronic health record (EHR) solution. CCS will be implemented in a step-by-step manner, and the Hospital should gradually be able to undertake a still larger part of the configuration and implementation. CSC has offered the Hospital an effects-driven IT development approach to support their partnership (see chapter 8 by Hertzum and Simonsen, 2011). Effects-driven IT development changes the focus from one of detailed specifications of IT functionality to a focus on measurable effects that can document the needed utility value of the EHR. The idea is to base the partnership sourcing on agreed goals, specified in terms of the effects to be achieved by using the EHR at the Hospital. The effects specification documents and mediates the client s needs for change during the process of configuring and implementing the EHR. The partnership is organized as an experimental, user-driven, and effect-driven process: experimental when the domain to be supported is complex and the IT solution has to be configured and evaluated through an agile and iterative process; user-driven when it is important that the involved clinicians contribute

2 to the development with their detailed insights into the clinical work; and effects-driven to specify, and subsequently measure, if and how the desired effects are attained. The effectsdriven IT developments approach is used as a project management instrument to guide and facilitate the partnership between CSC and the Hospital. In this chapter, we describe one of the initial effects-driven projects conducted by CSC and the Hospital. We focus on the effects-specification process and the associated project activities in which CSC and the Hospital meet and discuss key milestones during the project. Our empirical data have been collected using an action research approach (Avison et al., 1999; Simonsen, 2009). During the project, one of the authors was employed at CSC and participated in the project as a CSC consultant. His experiences as well as the project documentation have been analyzed by the authors. It should be noted that this chapter is based on CSC s perspective of the project and process. In the following section, we first present the general effects-specification process offered by CSC to the Hospital. Second, we outline the context of the project and the maternity ward involved in the effects specifications. Third, we describe the project process with a focus on the effects specifications and how these specifications guided the process. We conclude by discussing the lessons learned. 2 Effects specifications CSC Scandihealth A/S has since 2005 employed effects-driven IT development to support partnership sourcing with some of its clients in the healthcare sector. Effects-driven IT development supports the development process during the specification and evaluation of a design. When engaged with a client, the effects set forth by the management define the scope of the project and, thereby, guide the process with the client s end-users. The end-users are engaged in workshops throughout the process and the effects identified serve as documentation of the design. In parallel, CSC transforms the specified effects into mock-ups or prototypes, which demonstrate the system functionality, intended to support the client in achieving the effects. During the pilot use or later the effects from using the solution are assessed systematically by means of event logs and questionnaires. CSC organizes partnership sourcing as an agile effects-driven development process as depicted in Figure 1. Activities with the client are organized as a collaboration between management and clinical users from the client and configurators from CSC. The configurators have competencies in the clinical domain and are responsible for documenting the effects and for developing the mock-ups and prototypes. Technically, the prototypes are developed in CCS, which is a highly configurable framework tool based on the Oracle Healthcare Transaction Base (HTB). CCS can be configured by XML-based templates for overviews, clinical notes, results, standard plans, work situations, and the structure of the patients medical record. This makes it possible to configure a complete medical record in accordance with the clinicians requirements and, at the same time, remain open to changes in the configuration as new requirements emerge. The configurators collaborate with the CSC developers responsible for the CCS, especially regarding integration to other systems or if the effects specification requires changes in the next release of CCS.

3 Figure 1. CSC s effects-driven IT development process for projects that involve the configuration of systems supporting clinical pathways in the healthcare sector. During specification, the effects are used to identify management and end-user requirements related to the client s overall goals and to the daily work performed to fulfill the mission. The effects workshop with management and end-users results in an effects specification that forms the starting point for the development of prototypes. The effects specify how the solution must be evaluated to determine whether the design supports the needs of the management and the end-users. The prototypes are iteratively evaluated through a series of workshops with users from the client. CSC distinguishes between laboratory workshops and in-situ workshops. Early prototypes are evaluated through laboratory workshops where users are confronted with the prototype in a laboratory setting, that is, in a meeting room where the prototype is demonstrated and process models of the work supported by the prototype are drawn on an ad hoc basis to explain and discuss the prototype. The prototype is evaluated against the effects specification. The workshop identifies the requirements for implementing the new and revised functionality in the next version of the prototype, for elaborating the effects specification, and for discussing how the effects should be measured. As the prototype gets more mature, the laboratory workshops are replaced with in-situ workshops. In in-situ workshops the prototype is evaluated by end-users who should have up-to-date, first-hand experience of working with the clinical pathways that the prototype is to support. The workshop can take place in a meeting room or in the clinic where the system will be implemented. The prototype contains either relevant test data or actual patient data from the clinic, and the users evaluate the prototype by simulating or performing actual work using the system. In addition to revised functional requirements, the in-situ workshops might also involve an evaluation of the instruments designed to measure the effects of using the implemented system. Effect specifications are descriptions of the effects that the customer and the users would like to obtain when they start using the envisioned IT-system. CSC uses a generic template for effects specifications. This template has five parts: Effect (the effect to be obtained in a specified situation), agent (the user of the system in this situation), practice (a description of the clinical activity and intervention involved in the situation), outcome (the result of the activity), and evaluation (a description of how to assess the extent to which the effect has been achieved). The template indicates that an effect is the anticipated outcome generated by the user in a specific situation and when performing a given activity using the system.

4 The effects to be obtained from using the system can be assessed from multiple perspectives and at multiple levels of abstraction. Therefore, the effects are specified in a five-level hierarchy, as described in Figure 2 (see also Chapter 8, Figure 8, by Hertzum and Simonsen, 2011). This hierarchy shows that effects are related to each other, as one effect can serve as a means to achieve another more abstract effect. Effects describe ends or means depending on whether they are seen as explanations of how effects contribute or why they contribute. Arranging effects into a means ends hierarchy is inspired by cognitive work analysis (Rasmussen et al., 1994; Vicente, 1999) and the participatory design method known as the MUST method (Bødker et al., 2004). The properties represented in the effects means ends hierarchy are purposes and reasons at the top (high level of abstraction), general processes in the middle, and more specific information processes and the physical configuration of the IT system at the bottom. While IT has a direct influence on the lowest two levels, descriptions of IT functionality are typically absent at the three top levels. Figure2. Effects specification in five levels, ranging from strategic, through tactical, to operational effects. Each level is described in the following section (Rasmussen et al., 1994): 1. Purpose: This is the highest level of abstraction and represents the goals and purposes in relation to the organizational environment and the goal pursued through the lower levels. It is typically identified as policies, service goals etc. regarding quality and efficiency at the enterprise level of the client organization.

5 2. Abstract functions: This level addresses the prioritization and allocation of resources to the various generalized processes and activities on the level below. This second level describes the client s response, or strategy, to the environmental demands from level one and often relates to efficiency or the quality of service. 3. Generalized processes: This level represents business processes in terms of recurrent input output processes and overall activities which are general and well-known in the work domain. It is not a detailed specification of an activity but might be compared to the black box metaphor because sub-processes or sub-activities are not specified at this level. 4. Information processes: This level represents information-processing tasks that define the generalized processes, including the human activities as well as the use of equipment. Typically, these tasks precede or succeed a clinical intervention. Example: One of the tasks during the preparations for a consultation involves looking at the overview of past consultations to determine whether there are any topics or events of relevance to the upcoming consultation. At this level, it is possible to map activities to the forms and views in the prototype. 5. Physical configuration: This is the lowest level of abstraction and consists of tools or objects which are the sources of information for a given tasks. At this level, detailed descriptions of user interfaces are given as screen mock-ups or interactive prototypes. Figure 2 also shows the focus of the actors and stakeholders. Typically, the client s management is involved in specifying effects at levels one and two. These overall effects present a starting point for the end-users who specify the effects they want to obtain in their clinical practice, that is, in relation to general processes of managing and executing clinical pathways. The configurators then interpret the effects at level three and translate them into use patterns and system requirements at levels four and five. An effects means end hierarchy outlining client vendor context, effects specification examples, and typical stakeholders is presented in the appendix to this chapter. 3 Project context Prior to the project, a consultancy company made an overall business case for the Hospital. This business case concluded that the Hospital should implement an EHR for all clinical processes where the main parts of the patient records were still paper-based. Implementing a complete EHR system was intended to improve the quality of patient treatment along with ensuring more effective use of the available clinical resources. CSC was chosen as the vendor of the EHR system. The partnership between CSC and the Hospital began with the implementation of CCS as a common portal, a view-station, giving access to data from all existing systems at the Hospital, including patient administrative systems, medication systems, laboratory results systems, and so forth. While CSC was responsible for the technical integration with the existing systems, the Hospital and CSC collaborated in developing the view-station. Views in CCS that present data from various existing systems are configured by means of the so-called satellites. A satellite is a generic component for data selection and presentation; that is, a screen display consists of a number of satellites each retrieving it own information from the database and

6 presenting it in its part of the screen display. As more screens were configured, a library of satellites was developed and staff from the Hospital was trained in using this library to configure new screens. This way, the EHR was implemented first as a view-station introducing clinicians to the new system by viewing data from existing systems in the EHR. Simultaneously, the Hospital built competencies in configuring screen displays. A long-term ambition for the Hospital is to be able to configure new parts of the EHR themselves and to maintain and re-configure existing parts of the EHR to respond to changes in the clinical process or when new requirements emerge. When the EHR had been implemented as a view-station at several of the Hospital s wards, the plan was to start using CCS for configuring screens for data entry. This is also referred to as the clinical-process part of the EHR and it supports clinical decision making and the clinical staff s on-going documentation of the information on the medical patient. This clinical documentation was still mainly paper-based at the Hospital. The Hospital chose its three maternity wards for its first clinical-process project. The maternity wards were chosen because the midwifes constitute an independent group of relatively few clinicians and because pregnant women are a delimited group of patients. 4 The maternity ward During a woman's pregnancy, she will be in touch with different healthcare related organizations, mainly her general practitioner (primary healthcare sector) and the maternity ward (secondary healthcare sector), which consists of a pregnancy outpatient clinic (the midwife s clinic) and an inpatient maternity ward. The woman will visit the pregnancy outpatient clinic during her pregnancy for various inspections (e.g., ultrasound scanning) and for information meetings. When the actual delivery of the child is to take place, the woman will be hospitalized at the inpatient maternity ward. The overall clinical process during a pregnancy is recorded in four different types of patient records: At the general practitioner s clinic, the visits by the pregnant woman are recorded in the patient record maintained by the general practitioner. This record includes all visits to the general practitioner (not only those related to the pregnancy). The visits at the midwife s clinic are recorded in the so-called Midwife Record. This record comprises all control visits and measurements and includes data about such things as family, dispositions (heritable, allergies, etc.), foetal position, results from various blood samples and ultrasound scannings, signs of possible complications, and so forth. During her pregnancy, the woman regularly visits both her general practitioner and the pregnancy outpatient clinic. For this reason, an additional Pregnancy Record is maintained. This record is a paper pamphlet kept by the woman herself and it works as a coordination mechanism (Schmidt and Simone, 1996) between the general practitioner and the midwife s clinic. The record includes personal details and history together with BMI, blood pressure, and other information pertinent to diagnostic and treatment decisions. The woman brings the Pregnancy Record with her for all the appointments during her pregnancy.

7 When the woman is hospitalized at the maternity ward a new record is initiated: the Partogram Record. This record is used in managing the labour process and includes the continuous registration of data such as cervical dilatation, uterine contractions, foetal heart rate, descent of the head, state of membranes, blood pressure, pulse rate, drugs, and fluids. The project was to focus on the clinical pathway related to the Partogram Record, that is, the process that begins from the time the woman is hospitalized at the maternity ward and until the child has been born and the woman is discharged. Later, the Hospital decided to extend the project with the Midwife Record, that is, to include the process from the general practitioner s initial referral and the woman s first visit at the pregnancy outpatient clinic (a scanning offered 11 weeks into the pregnancy) and until she is hospitalized at the maternity ward (including regular visits in weeks 11, 13, 19, 21, and 35). 5 The project The initial aim of the project was to specify and develop an electronic Partogram Record for the Hospital s three maternity wards. The project was organized with participants from the Hospital as well as from CSC: Three midwifes one from each maternity ward took part in the project group as representatives for the clinicians. It was three very experienced midwifes who were also heads of department for each maternity ward; in addition, one of them was chief midwife for the Hospital. Three persons from the Hospital s IT department participated in the project group. They constituted the project manager and two staffs who were to be trained to work as configurators. All three of these persons had participated in the prior projects implementing the view-stations. CSC participated with an experienced configurator responsible for the technical configuration and a process consultant specialized in effects specifications. The project was planned as an agile process inspired by CSC s effects-driven IT development process outlined in Figure 1. The Hospital was responsible for the project while CSC was to configure the electronic Partogram Record, provide process support, and document the project. In the following sections, we describe the effects specification of the electronic Partogram Record. To provide a coherent description we include the workshops held to specify effects and associated system design at all five levels represented in figure 2. Effects at levels 1 and 2 were specified at a management workshop, effects at level 3 were specified at end-user workshops, and a system design corresponding to levels 4 and 5 was made by CSC s configurator and process consultant, who also designed the instruments for effects measurement. Figure 3 gives an overview of the project. The actual project process included other activities and events beyond those related to the effects specification.

8 Mgmt workshop, PR&MR End-user workshop, PR Lab workshop, PR End-user workshop, MR Lab workshop, PR&MR Lab workshop, PR&MR In-situ preparations In-situ workshop PR&MR Clinics merge Integrating PR&MR into one system June July 2010 August 2010 September 2010 November 2010 Dec January 2011 Spring 2011 Figure 3. Project timeline (PR Partogram Record, MR Midwife Record) In the beginning, the project focused on the clinical pathway related to the Partogram Record. However, after a couple of months the project scope was extended to include also the Midwife Record. The Hospital s decision to extend the scope was made after the end-user workshop and laboratory workshop for the Partogram Record. Especially, the discussions related to the effects of obtaining an overview of the work situation elucidated that information from the Midwife Record (covering the pregnancy up until the woman is hospitalized at the maternity ward to deliver the child) was important to a high-quality overview of the patient during the active management of the labour process. The laboratory workshop illuminated the need for re-entering data from the paper-based Midwife Record. Thus, to meet the effects prioritized at the management workshop, integration with the Midwife Record was needed to provide high-quality support for overviews in the Partogram Record. In January 2011, the in-situ workshop of both the Partogram Record and the Midwife Record including an initial evaluation of the questionnaires designed to measure the effects was conducted. Then, the system was in principle ready to be implemented. In parallel with the project, the Hospital was considering a major reorganization, and around the turn of the year , it was decided that the pregnancy outpatient clinics will be merged with the inpatient maternity wards and that all secondary healthcare services related to pregnancy will be consolidated. As an immediate implication for the project, the Partogram Record and the Midwife Record were to be integrated into one system. This organizational merger of the clinics and the corresponding integration of the two EHRs were well in line with the project discussions related to effects specifications, for example, level 1 effects specifying the purpose of giving better means of communication and collaboration, ensure continuity, increase information and communication between midwifes, as well as level 3 effects related to overview (including coordination of responsibility and tasks during a handover). The integration of the two systems and the organizational merger of the clinics took place during spring At the time of this writing, the implementation of the operational system and the effects measurements have been planned for May and June Management workshop: effects specification at levels 1 and 2 The first workshop was a management workshop (see Figure 1). The aim of this workshop was to specify effects at levels 1 and 2 (see Figure 2) and thereby produce an effects specification concerning the overall purpose and abstract functions of the electronic Partogram Record. Later, when the project was extended to include also the Midwife Record, the effects at this high level turned out to fully include an electronic Midwife Record. The workshop was held with the chief midwife, the Hospital s project manager, and the process consultant from CSC. This initial workshop also served as an introduction to the overall

9 project process and the effects specification. CSC s process consultant played a major role during this workshop. The consultant started by presenting statements from the Hospital s overall business case determining the high-level effects to be pursued, including: Electronic records must always be available, coherent, and complete. Data must be structured in ways so that it is easy to understand and easy to re-use. Patient trajectories and record content must be standardized. Patient treatment must be correctly recorded for further reporting to national directories and for the settlement of activity-based accounting. During the workshop, the business case was related to the electronic Partogram Record and the Hospital s strategy for implementing complete EHR solutions. According to the chief midwife, the main question to pursue was treatment quality, rather than resource load, to achieve better clinical practice and higher satisfaction from clinicians and patients. Thus, it was decided to prioritize quality related effects rather than efficiency. The level 1 effects reflecting the purpose of the electronic Partogram Record were defined as follows: To give better means of communication among midwifes and of collaboration between midwifes and physicians. To ensure the continuity of medical record-keeping for the individual midwife. To increase the information and communication between midwifes regarding the status and progress of the patients. Level 2 effects mirrored the above described effects from the business case with one additional effect: The record is always available at the point where the clinical work is carried out. 5.2 End-user workshop: effects specification at level 3 Following the management workshop an end-user workshop was held (see Figure 1). The aim of this workshop was to elaborate the effects into level 3 effects about the general processes performed by midwifes at the maternity wards. This workshop was held with all project participants: the three midwifes, the Hospital s project manager and two staffs, and the configurator and process consultant from CSC. The workshop served as an introduction to the overall project process for those who had not participated in the first workshop, and CSC s process consultant again played a key role during the workshop. At the workshop, the participants discussed and outlined the process of an uncomplicated delivery and the work situations involving the midwifes during this general process. This resulted in the identification of the following six generic work situations to be supported by the electronic Partogram Record: Overview (coordination of responsibility and tasks during a handover) Anamnesis recording (data gathering related to clinical interview) Clinical recording (data gathering related to clinical observation) Child investigation (data gathering related to clinical observation) Post partum recapitulation (administrative planning after delivery)

10 Reporting (administrative incident reporting) For each of the six work situations, the workshop participants specified the desired effects and discussed how to assess achievement of the effect. The effects were specified according to CSC s template for effect specifications. As an example, the Overview situation was specified as follows: Effect for the work situation Overview (coordination of responsibility and tasks during a handover) Effect: The new midwife who is responsible has an overview that makes her capable of acting correctly and be informed about the observations and interventions relevant for the patient in the nearest future. Agent: The new midwife taking over a patient during the handover. Practice: As part of the handover of tasks and responsibilities, the midwife gets information by looking up information available about the on-going delivery. Outcome: The midwife does not need to look for supplementary information and she can go on to the next patient of the handover or end the handover. Evaluation: After the information has been handed over (and possibly after the midwife has seen the woman) an evaluation can ascertain whether parts of the picture are missing. Is there a need for clarifying questions that might have been answered by the overview? Does the midwife feel ready to continue her work? How much time does the midwife need to read and/or search for information? Does the midwife get visual support regarding data that require intervention? 5.3 System design: effects specification at levels 4 and 5 Based on the specification of level 3 effects a first prototype, corresponding to the effects at level 4 (information process) and level 5 (physical layout of system), was designed. This was done jointly by CSC s configurator and process consultant and by the Hospital s two CCS staff. At level 4, the different screens were identified and related to the work processes specified at level 3. The screens were defined as either forms, which are used for recording and for looking up individual data fields, or views, which are used for bringing data together and presenting an overview (by means of satellites). In total, 15 screens were identified for the electronic Partogram Record. In addition, a table was made naming the 15 screens (but not specified and further divided into fields or satellites), their CCS type, and their relation to the level 3 situations, that is, which work situations and effects the different screens are designed to support. Level 5 consists of the different versions of the configured CCS prototype. For example, the 15 screens in the first prototype included four screens (three views and one form) that were designed to support the Overview situation described above. These screens included views showing the data registered when the woman has been hospitalized, the clinicians who have been allocated to the woman since her hospitalization, the interventions and clinical notes recorded, and an overview of the continual recording of labour-process data some of which were visualized in graphical satellites (see Figure 4).

11 Figure 4. Satellite visualizing the labour process regarding the number and level of uterine contractions, salt drain infused, and analgesia. 5.4 Effect measurement instruments As one of the activities of the effects-specification process the instruments for measuring effects were devised and later evaluated as part of an in-situ workshop held in January 2011, where the prototype was tested using real patient data. At this workshop, six additional clinicians participated: five midwifes and one social and health care assistant. Two types of instruments were designed based on (1) event logs and (2) questionnaires. Event logs basically record when a key is pressed to initiate an event in the system, for example, when a user presses a key to open a specific screen, enter a value into a field, or commit changes to a record. Event logs are made automatically by the system. All events are recorded with a timestamp and a user-id. For example, if a user enters a new value into a field in the electronic Partogram Record, a record of the event is made specifying the date and exact time of the event along with information about which screen the user was using, which field on the screen was changed, the value entered into the field, the old value of the field, and the id of the user. Event logs can be analyzed by data mining techniques (Fayyad and Uthurusamy, 2002) to investigate how the system is used (see Bøving and Simonsen, 2004). Statistics made from event logs can, for example, show the average degree of completion of a given part of the Partogram Record, the time spent completing a certain task using the system, which screens are used for a specified task, whether the users use screens other than those designed for a specific task, and the number of times the users hit the cancel button. The questionnaires are designed to measure how the clinicians perceive using the system. Questions about three different kinds of effects were included in the questionnaires: Quality-related effects were included in the questionnaires by adopting parts of the Technology Acceptance Model (TAM) (Davis, 1989), using questions directed at perceived usefulness and perceived ease-of-use. The clinician s mental workload when using the system for a specific task is measured by means of the Task Load Index (TLX) (Hart and Staveland, 1988), using questions rating mental demand, physical demand, temporal demand, performance, effort, and frustration.

12 Effects relating to overview and situation-specific issues were assessed by custom-made questions. This included questions such as your assessment of the status of the pregnancy for this patient, answered on a rating scale from clear to unclear. To assess the Overview situation, a combination of all three types of questions was designed for the midwifes to fill out after completing their hand-over. At the in-situ workshop, the questionnaire was used as part of the prototype test. Seven midwifes completed a total of 11 questionnaires after having tested the prototype. Some of the TAM-inspired questions from the questionnaires were: By using this overview [a screen presenting an overview of the patient] I can quickly get knowledge of the patient; improve the quality of the clinical work I will subsequently do; my clinical work becomes easier because I know enough about the patient; I increase the efficiency of my clinical work; I increase my productivity because I minimize the non-productive time; I become able to complete my preparation faster; I improve the performance of my clinical work; I experience the system as usable when preparing my clinical work. The evaluation of the prototype and the results from the preliminary effect measurement indicated that the system was almost ready to be pilot implemented at one or more of the maternity wards and the questionnaire worked well as part of the measurement instrument. 6 Conclusion: Lessons learned The Maternity Ward project is the fourth effects-driven IT development project undertaken by CSC since 2005(see chapter 8 by Hertzum and Simonsen, 2011), and the processes and tools developed to manage and perform these projects are gradually becoming more mature. CSC s standard process for effects-driven projects is depicted in Figure 1; tools to specify effects include the effects means ends hierarchy in Figure 2 and the template specifying level-three effects in five parts: effect, agent, practice, outcome, and evaluation. As a general lesson, these generic processes and tools are perceived by CSC as operational instruments for managing an agile effect-driven process. Effects specifications are described in the client s own language and form a usable means to mediate communication between different actors in partnership sourcing. Lessons from earlier projects led to the division of the effectspecification workshop into a management workshop, focusing on high-level effects (levels 1 and 2), and an end-user workshop, focusing on the effects related to the clinical processes performed by the end-users (level 3 effects). The primary focus of management, end-users, and configurators (on levels 1 and 2, level 3, and levels 4 and 5, respectively) has been observed in this project as well as in earlier projects. Effects specifications at levels 1 through 3 appears to be adequate as a basis for the design of prototypes provided that the configurator has a clinical background and prior experience in configuring healthcare systems using CCS. This includes an ability to model the processes supported by the system and knowledge of the clinical information and data needed. A prototype was designed for the first laboratory workshop based solely on the effects specifications and the discussions from the two management and end-user workshops. CSC is, however, considering to use non-interactive mock-ups (Ehn and Kyng, 1991) as a replacement for the early versions of the prototypes. This is intended to shorten the iterations and thereby allow for more workshops to be planned without compromising the progress of

13 the project. The first prototype was based on the configurator s interpretation of the effects specification. An evaluation of this interpretation might very well be conducted using mockups such as simple screen drawings that are much easier and quicker to make. This can provide for a fast mutual reinterpretation and eventual revision of the effects specification. Using mock-ups might also enable the client to participate more closely in the design since no technical competence is needed in configuring CCS. Effects specifications have in earlier projects appeared to require few revisions once they have initially been specified, and they thus constitute a reference point in the management of the subsequent workshops and prototype revisions (see chapter 8 by Hertzum and Simonsen, 2011). This characteristic was verified in this project. The high-level effects (levels 1 and 2), specified at the management workshop, remained unchanged during the project. Even the decision to extend the project with the Midwife Record, in addition to the Partogram Record, and to merge the two clinics did not lead to changes or supplements to the effects at levels 1 and 2. Possible reasons for this stability include that they represent a high level of abstraction and thereby unaffected by most changes in work processes. The project aimed at improving the quality in the midwifes work, while the clinical work as such was retained. The merger of the clinics had administrative and managerial consequences but entailed no changes to the practical management and organization of the clinical pathways. The effects specifications also reflected the management s loyalty to the Hospital s strategy for EHR solutions as the effects were tightly aligned with the effects specified in the Hospital s overall business case. Finally, it suggests that the effects were perceived as worth pursuing by management, which included experienced midwifes from the maternity wards and the outpatient clinics. Extending the project with the Midwife Record also had only minor consequences for the effects at levels 3 and 4. The six work situations specified for the general processes at level 3 for the Partogram Record could be re-used in the Midwife Record without modifications. Two additional generic work situations and associated effects were specified at level 3, while two views and two forms were added to the specification at level 4. At level 5, the re-design comprised that a single system had to be configured for both pathways and that a number of data-entry fields in the Partogram Record had to be changed to show data recorded by the new screens for the Midwife Record. Though the effects specifications were stable throughout the project, the in-situ workshop held in January 2011 resulted in a number of detailed comments and requests for changes. One lesson to be drawn from this is the importance of early involvement of experienced endusers with actual insight into current work practices. This is a general lesson, also referred to as the principle of first-hand experience of the work practice (Bødker et al., 2004). The three midwifes in the project group were very experienced and they were heads of department for the maternity wards. Having this management position also meant that they were mainly involved in midwife tasks when the ordinary midwifes required specialized assistance, that is, actually assisted a woman in giving birth. The in-situ workshop was attended by five additional midwifes with no managerial positions. These ordinary midwifes noted that some information was not represented in the records. In the Partogram Record it was, for example, noted that the midwifes must record whenever they request for anaesthesia a relatively new practice that the three managing midwifes had overlooked. The absence of end-users with actual first-hand experience during the end-user workshop and the laboratory workshops might suggest some incompleteness and imprecision in the effects specification. An approach

14 to having such knowledge included in the project could be to present the mock-ups or prototypes to a larger audience earlier in the process, as it is intended with the in-situ workshops. References Avison, D., Lau, F., Myers, M., & Nielsen, P. A. (1999). Action Research. Communications of the ACM, 42(1), Bødker, K., Kensing, F., & Simonsen, J. (2004). Participatory IT Design. Designing for Business and Workplace Realities. Cambridge, Massachusetts: MIT Press. Bøving, K. B., & Simonsen, J. (2004). Http Log Analysis: An Approach to Studying the Use of Web-Based Information Systems. Scandinavian Journal of Information Systems, 16, Davis, F. (1989). Perceived usefulness, perceived ease of use and user acceptance of information technology. MIS Quarterly, 13(3), Fayyad, U., & Uthurusamy, R. (2002). Evolving Data Mining into Solutions for insights. Communication of the ACM (Special issue on Data Mining), 45(8), Hart, S.G., & Staveland, L. E. (1988). Development of NASA-TLX (task load index): Results of empirical and theoretical research. In P. A. Hancock & N. Meshkati (Eds.), Human Mental Workload (pp ). Amsterdam: Elsevier. Hertzum, M., & Simonsen, J. (2011). Effects-Driven IT Development: Status In M. Hertzum & C. Jørgensen (Eds.), Balancing Sourcing and Innovation in Information Systems Development. Trondheim, NO: Tapir Academic Publishers. Ehn, P., & Kyng, M. (1991). Cardboard computers: Mocking-it up or hands-on the future. In J. Greenbaum & M. Kyng (Eds.), Design at Work: Cooperative Design of Computer Systems (pp ). Chichester, UK: Lawrence Erlbaum Associates. Rasmussen, J., Pejtersen, A. M., & Goodstein, L. P. (1994). Cognitive Systems Engineering. John Wiley and Sons, Inc. Schmidt, K., & Simone, C. (1996). Coordination mechanisms: Towards a Conceptual Foundation of CSCW Systems Design. Computer Supported Cooperative Work. The Journal of Collaborative Computing, 5(2-3), Simonsen, J. (2009). A Concern for Engaged Scholarship: The challenges for action research projects. Scandinavian Journal of Information Systems, 21(2), Vicente, K. J. (1999). Cognitive Work Analysis: Towards Safe, Productive, and Healthy Computer-based Work. London: Lawrence Erlbaum Associates.

15 Appendix. Effects means end hierarchy outlining client vendor context, effects specification examples, and typical stakeholders. Effect means end hierarchy Client context, clinical work Purpose Political objectives, programs, regulations, accreditation Abstract functions Generalized processes Information processes Physical configuration Quality requirements for clinical work, service goals for clinicians, workplace assessment Areas of clinical specialization, Nursing or treatment Treatment regimes, patient trajectories, interventions, nursing plans Specific elements within an intervention can be identified and described. Vendor context, IT product Product strategy Product suite; EHR, Paraclinical system, Patient Adm. System (PAS) laboratory inf.system (LIS) Specific IT systems CCS, LABKA, VITAE, OPUS Modules, templates, bookingschemas, testprofiles. Screens, forms, views, satellites, controls, fields Effects specification (examples from a CSC Scandihealth project with a client) Client: Contribute to increased patient motivation CSC Scandihealth: Products supporting the clients business strategy Client: Better overview of patient trajectory within 3 categories: Managing the patients state of health during evaluations (quality of life, well-being) Efficient recording by customizing documentation to work tasks (easy and efficient documentation) Homogeneous evaluation of patients (joint best practice) CSC Scandihealth: Priorities of functionality in accordance with other client requirements Client: Consultation coordination of responsibility/tasks during consultation. Therapist and patient can account for the distribution of responsibility. CSC Scandihealth: Providing a module supporting consultation and coordination between therapist and patient Client: Patient s responsibility regarding goals and actions can be described by the patient giving a clear indication of the patients own responsibility. CSC Scandihealth: To configure forms and views handling the recorded distribution of responsibility between the patient and the therapist. Client: Schemas, templates. CSC Scandihealth: Prototype IT supporting the intervention: A division of the screen/form when recording responsibility or a screen/view displaying the distribution of responsibility between healthcare provider/therapist and patient Dynamics and stakeholder representatives Politicians, Corporate CSC Senior Management, client and CSC Scandihealth Effects are stable Senior Management, client and CSC Scandihealth Middle manager, client Business architect, CSC Scandihealth Effects are stable Clinicians/end-users CSC Scandihealth process consultants Effects are stable Clinicians/end-users CSC Scandihealth process consultants, configurators, and developers. Effects are dynamic Clinicians/end-users CSC Scandihealth configurators and developers. Effects are dynamic and technically implemented