decisions about appropriate health actions for specific clinical circumstance. We ... Patients are referred to the clinics with a diagnosis of cancer. By the first visit in .... Only the actor currently possessing the flowchart knows its state. Much time.
From Paper Based Clinical Practice Guidelines to Declarative Workflow Management Karen Marie Lyng,1 Thomas Hildebrandt1 and Raghava Rao Mukkamala1 1
IT university of Copenhagen, Rued Langgaardsvej 7, 2300 Copenhagen S, Denmark {lyng, hilde, rao}@itu.dk,
Abstract. We present a field study of oncology workflow, involving doctors, nurses and pharmacists at Danish hospitals and discuss the obstacles, enablers and challenges for the use of computer based clinical practice guidelines. Related to the CIGDec approach of Pesic and van der Aalst we then describe how a sub workflow can be described in a declarative workflow management system: the Resultmaker Online Consultant (ROC). The example demonstrates that declarative primitives allow to naturally extend the paper based flowchart to an executable model without introducing a complex cyclic control flow graph. Keywords: Process modelling in healthcare, Process oriented system architectures in healthcare, IT support for guideline implementation and decision support, Requirements for medical guideline and medical pathway support, integrating healthcare processes with electronic medical records.
1
Introduction
It has been known for quite a while that there is a need for making clinical working practices safer, as too many errors happen causing suffering or even death of patients [1]. Due to the complexity, the high mobility and ephemerality of the daily clinical work [2,3] safer working practises will require better coordination, efficient collaboration and not least fulfilment of up to date clinical practice guidelines (CPG) [4-6]. One way of supporting this is by the use of of IT based clinical decision support and better linkages in and among IT-systems [7]. Indeed, according to [8,9] on of the best options for improvement in clinical work seems to be IT supported clinical processes based on CPG’s. However, the use of IT based CPG’s is challenging in several ways. Firstly, due to continuous development of new knowledge within the medical domain the mean survival time of clinical guidelines is short, approximately 2 years [10]. Secondly, there is a need for guidelines to be flexible and adaptable to the individual patient [11].Thirdly, no coherent theoretical framework of health professional and organizational behaviour and behaviour change has yet been established [12]. Finally, it is a serious challenge that health professionals currently tend not to follow clinical guidelines [5]. One of the reasons for this could be that clinical guidelines are not
embedded in the clinical work processes and the technology available in the clinical setting today. Oncology is an example of a clinical speciality for which it is known that there do exists a high number of CPGs that are followed to a certain degree by the health professionals [13]. For this reason we found it of interest to perform a series of field studies in oncology clinics, to examine enablers and obstacles for use of IT-supported clinical guidelines. The field studies are presented in Section 2 below. Based on the field studies, we then proceeded in Section 3 to investigate how the current paper based workflows could be supported using a commercial declarative workflow management system, which relates to the CIGDec approach of Pesic and van der Aalst [14]. We believe that the resulting model rather naturally extends the paper based flowchart table used at the hospitals, and in particular avoids the introduction of complex cyclic control flow graphs and over specification as also pointed out in [14]
2 2.1
Field study - usage of CPGs in Danish oncology clinics Method
Observations were made on three Danish oncology clinics by two observers (the first author and an assistant). Four days of observation were made at each clinic. Besides observations, access to all clinical guidance material was granted. All the clinics were specialized within oncology; two of them were university clinics. The focus of the observation study was on the use of CPG’s as defined by Field and Lohr[14]: Clinical practice guidelines are systematically developed statements to assist practitioner decisions about appropriate health actions for specific clinical circumstance. We especially looked at the work of nurses, doctors and pharmacists in relation to chemotherapeutical treatment of patients. 2.2
Overall treatment processes and guidance documents
Patients are referred to the clinics with a diagnosis of cancer. By the first visit in the outpatient clinic the patient is informed about pros and cons of chemotherapy by a doctor, and an overall patient plan for oncological treatment is outlined. In subsequent visits chemotherapy is given, in between visits to the outpatient clinic monitoring of side effects to chemotherapy are done by laboratory tests. The chemotherapeutic treatment is based on a number of different types of guidance documents and diagrams depicted in Figure 1. The basis of the treatment is given in a standard treatment protocol or a research protocol, which constitute the CPG for the diagnosis in case. The protocols are written in a narrative form with a description of the current knowledge of treatment of the diagnosis as well as a thorough description of the drugs to be used. The size of a research protocol is app. 60-80 pages and a standard treatment protocol is app. 30-40 pages. Protocols are generally developed in cooperation between several oncology departments, frequently
with a pharmaceutical company as a main sponsor and actor. Research protocols are often multinational. Based on the protocols local practice guidelines (also referred to as standard treatment plans) are made as well as a treatment overview, in daily speech referred to as the “noughts and crosses” diagram. The noughts and crosses diagram describes the planned medical treatment as well as examinations during the patient trajectory. There will often be deviations from the original plan due to side effects to treatment, other medical problems or resource problems in the hospital. Each department has some 6080 standard treatment plans in use plus several hundreds general CPG’s, some of which are specific to the oncology department, e.g. treatment of side effects to chemotherapy and some that are shared by several departments e.g. treatment of diabetes. The flow of each chemotherapeutic treatment session is guided by the so-called patient flowchart, which also records the state of the treatment session. Below we will describe the workflow resulting from the flowchart in more detail; this will be the focus of the remaining part of the paper. Research or Standard Treatment Protocol(CPG) General General Guidelines Guidelines
-1 Activity
Local Practice Guideline
Activity
0
7
13
17
O
30
O
O
Activity
O
O O
Activity Activity
3
O
Activity
O O
O
O
O
Noughts & crosses
O
session
session
session
Lab res.
session
Flowchart
Dosage D sign P sign N sign N adm
Figure 1 overview of the relation between research protocols/standard treatment plans, local practice guidelines (standard plans) and flow charts. General guidelines are the general guidelines in use at the hospital, containing issues like the treatment of diabetes. 2.3
Current workflow for chemotherapy treatment sessions.
Figure 2 shows an overview of the workflow, which is reiterated in every chemotherapeutic treatment session. In the flowchart the basic information about the patient is registered, including the latest lab results as well as height and weight of the patient. Based on these informations and the patient history of any major adverse effects, the doctor calculates the therapeutic doses of chemotherapy, documents it on
the flowchart and signs it. The flowchart is transferred from the doctor to the controlling pharmacist (who can be situated near by in the clinic or far away in the pharmacy) where it functions as a prescription from the doctor. The controlling pharmacist controls the doctors dosage calculation and writes the information in a working slip that is used for the pharmacy assistant who is doing the preparation of the drug(s) in case. During preparation the quantity of all products as well as batch numbers are registered in the working slip, finally the working slip is signed by the pharmacy assistant, and the product - usually a drip bottle or a pump with a content and patient information label stuck to it – is referred to the controlling pharmacist for check out. When the controlling pharmacist has checked that the produced drug and patient information label matches the flowchart and the working slip, the pharmacist put small green ticks on each item in the flowchart and finally signs it. Subsequently the flowchart and the product is referred to the treatment rooms, where the responsible nurse together with another authorised person (nurse or doctor) checks that the product and flowchart matches, both regarding content and patient information. The responsible nurse then signs the flowchart and the medicine is administered to the patient. In parallel to this the nurse will administer adjuvant medicine like anti-emetics, cortisol and other drugs that are prescribed in the local practice guidelines. The nurse registers the medication in the Medicine Order and Administration (MOA) IT system that currently is being implemented in all the oncology departments. Ward Patient
Patient +
flowchart
+
flowchart
+
+
Doctor
Pharmacy +
Pt. A drug X
Nurse/ Nurse doctor +
flowchart
flowchart
+ Pharmacist
pharmacist
Work sheed
+
pharmacist assistent
Work sheed
+
Pt. A drug X
Pt. A drug X
Figure 2 Oncologic workflow in relation to chemotherapeutic treatment of patient 2.4
Preliminary conclusion to the case study
Several characteristics of the work were elucidated in the case study:
There are several professional actors involved in even rather simple workflows like the ones we studied (they are all involved in more than one workflow at the same time). The flow is guided by the flowchart, which is simply a table with a column to which the doctor and pharmacist add information and/or a signature, thereby capturing the state of the session. The workflow is distributed: the doctor and nurse, pharmacist, and pharmacy assistant are physically located in different places at the hospital and the current paper used for controlling the workflow is physically transferred by a porter or nurse (or faxed) between the different actors. Only the actor currently possessing the flowchart knows its state. Much time was used waiting for and controlling the status of the former process step, to be able to plan own work. There are a number of check-points. If a check fails (e.g. the pharmacist or nurse doubts the validity of the current state, the previous actors are asked to verify the state and possibly redo a calculation. Exceptional events like the medicine getting too old (e.g. if it is not transferred to the treatment rooms and approved within 24 hours) also led to recurrence of activities. Only the state (information) and the actors are explicit in the flowchart. The ordering of events (i.e. transfer of the flow chart between actors), handling of exceptions and recurrence/validation of calculations are implicit.
In our observations we found several potential enablers and obstacles to digitalization of the process support, which have been collected in Figure 3 below. Enablers
Obstacles
•
Easy access to workflow status, could avoid a lot of walking between treatment rooms and pharmaceutical preparation rooms for the nurses.
•
Many patients had to follow more than one • CPG, due to co-morbidity or adverse effects of treatment. An It system could present concurrent CPG’s • Meeting legal demands: In the current situation, the pharmacist is lacking a copy of the prescription, which is a legal demand. This could be saved automatic using IT.
•
•
•
•
It was clear from our observations that CPG’s and standard treatment plans was more vividly used if they were embedded in the work processes. This could be in the form of documentation templates, automated order forms or decision algorithms. New-commers are more active users of CPG’s. In departments with a high turn around of employees process support will be more sought for.
•
Feeling of competence. ” I have been here for a hundred years, so I know what to do, and I know the procedures” – guidance are not sought for. Oral culture – problems are preferably discussed with peers, even rather fact based ones No clinical managerial pressure – It is not expected that professionals look things up in the existing sources (Paper or IT-based). There is no control (no count on hits)
•
Reluctancy to change from paper based workflows
•
Lack of integration between process support and all the clinical information systems, among which some are still not digitalised.
•
Lack of access to computers, with low response time and single sign on to (all) the clinical IT-systems
Experience among clinicians that relevant guidelines are hard to find in current systems
Figure 3 Enablers and obstacles for digitalized clinical process support
In the present paper we concentrate on how the workflow of a single chemotherapeutic treatment session may be supported by a workflow management system, and in particular how the workflow can be described as an executable process. A central issue is how to make the implicit ordering of events (and the additional verifications and possibly recurrences of events) explicit. One option is to use an imperative flow graph based notation such as Petri Net or BPMN. However, it would include arrows for capturing the control flow (including cycles for the verification and recurrence of events), which would differ radically from the notation used in the current paper based setting. As suggested by van der Aalst and Pesic in [15] one can avoid introducing the explicit control flow as a complex flow graph by instead using a declarative notation such as the CIGDec model. Following this idea, we will investigate below how to specify the treatment session in a commercial declarative workflow management system, the Resultmaker Online Consultant.
3
Resultmaker Online Consultant Model of Treatment Workflow
The Resultmaker Online Consultant (ROC) is a user-centric declarative workflow management system based on a shared data store. It uses so-called eForms as its principal activities and allows one to declare the sequential constraints and dynamically included verification steps (and implied recurrences of activities) as found in the oncology treatment workflow using so-called sequential and logical predecessor constraints and a notion of activity conditions. There is yet no formal graphical notation for the ROC processes, but there is a guideline for how consultants jointly with domain experts can identify and specify activities, roles/actors and constraints in a table of a specific form. This table is referred to as the Process Matrix (PM). In Table 1 below shows an example of a PM (simplified to preserve space) for the Oncology workflow presented in the previous section. Each row of the matrix represents an activity of the Oncology workflow. The columns are separated in 3 parts: The first set of columns describes the access rights for the different roles: Doctor (D), Nurse-I (N1), Nurse-II (N2), Controlling Pharmacist (CP), Pharmacist assistant (PA). The next set of columns describes (sequential and logical) predecessor constraints. The last set of columns describes activity conditions. Below we describe the PM for the Oncology workflow and the primitives of the ROC in more detail. Activities and execution. The notion of an activity in ROC is like in any other workflow language, which means an activity is atomic and corresponds to a logical unit of work. Activities are executed in parallel by default and they can be executed any number of times, unless constrained as described below. The state of the ROC records whether an activity has been executed or not. If an activity has been executed, then that activity will have status executed. Its state can be reset under certain circumstances explained in Control Flow Primitives sub section. We say that the flow
has state complete at any point where all activities (currently included in the flow, see Activity Conditions below) have state executed. S No
Activities
1.1 BASIC_INFO 1.1.1 Basic info registration*
Roles
PredeActivity Remarks on data and cessors Condition activity condition D N1 N2 CP PA Seq Log W W R R N
1.1.2 lab. Results * W 1.1.3 Patient history* W 1.2 ORDINATION 1.2.1 Calculate the W therapeutic doses of chemo-therapy* 1.2.2 Sign W 1.2.3 Verify ordination W 1.3 CONTROL 1.3.1 Control calculation R 1.4 PREPARE 1.4.1 Quantity and batch D nr of products are registered* 1.4.2 Sign R 1.4.3 Check out drip R bottle 1.4.4 Sign R 1.4.5 Verify preparation R 1.5 MEDICIN ADM. 1.5.1 Check that R preparation, order and patient match 1.5.2 Check that W preparation, order and patient match Sign R 1.5.3 1.5.4 Admin preparation R to patient*
W R R N R R R N R R R N R R R N R R R N
patient information like height, weight and surface area Check lab results Interview of patient 1.1 1.2.2 digitally signs data of 1.2.1 and sets TrustO true. 1.2.3 either sets TrustO true or resets 1.2.1 1.2.2 Not TrustO 1.2.1
R R W R
1.2.2
Set TrustO false if ordination not trusted
D D R W
1.3.1
This is internal pharmacy work
R R R W R R W R
1.4.1 1.4.2
R R W R R W W R R W WR W W
1.4.3 resets 1.4.1 if preparation does not match ordination & 1.4.3 1.4.4 Not TrustP patient. 1.4.5 resets 1.3.1 or sets TrustP 1.4 The responsible nurse checks together with another nurse or doctor. If it is not trusted either TrustO or TrustP is set to false (forcing the 1.5.1 doctor or pharmacist 1.5.2 to verify) 1.5.3
Table 1 Information marked with * could be transferred from or registered automatically in another hospital information system (HIS) W= write, R = read, N = denied access The following pre-defined activity types are used in our case:
eForm Activity: eForms are web questionnaires that have graphical user interface elements displayable in a web browser. The fields on the eForms are mapped to variables in the shared data store and the data filled in by the users will be available to all activities of the workflow instance. eForms are appended to ROC activities in process definitions and at run-time when an eForm activity is executed, the corresponding eForm will be displayed to the user for human interaction. All activities in the example, except signing activities, are eForm activities. Signing Activity: The user data on eForms will be digitally signed by using XML digital signatures syntax and user’s digital identity certificates. A single signing activity supports signing of data from multiple eForms. In the example all the activities named Sign are signing activities. Resources/Roles. The ROC supports a simple resource model using Role-based access rights to define permissions on the activities to different users of the system. The possible access rights are Read (R), Write (W), Denied (N) and the default access right on activities is Read access. The Read access right allows a user with the particular role to see the data of an activity, where as Write access right allows the user to execute an activity and also to input and submit data for that activity. A Denied access right is the same as making an activity invisible to the user, i.e. the user does not see it as part of the flow. In the example we have used the denied access right to shield the Pharmacist assistant from the rest of the workflow. Control Flow Primitives. The control flow primitives define the constraints that control the activity execution at runtime. Activity Condition: Every activity in the ROC has a logical activity condition. An activity condition is a Boolean expression that can reference the variables from the shared data store. If an activity condition is evaluated to be true, the activity is included in the workflow, otherwise the activity will be skipped. Activity Conditions in ROC workflow model are re-evaluated whenever necessary, so the inclusion of an activity can be changed during the lifetime of the workflow instance. If the activity condition changes to false during the execution of an activity (e.g. when a user is filling in an eForm), the user will be informed that the activity is no longer part of the flow and no data will be changed. This guarantees atomicity of activities. In the example we use two Boolean variables TrustO and TrustP to control the inclusion of the verification actions 1.2.3 and 1.4.5 respectively. When the doctor signs the ordination in activity 1.2.2, TrustO is also set to false, thereby excluding the verification from the flow. However, it may be set to true during activity 1.3.1, 1.51 or 1.5.2. This will force the verification step to be executed and all activities having it as logical predecessor to be reset (see below). Sequential Predecessors: If activity A is declared to be a sequential predecessor of activity B, then activity B can only be executed if activity A has state “executed”. However, the sequential predecessor has only effect if the predecessor activity A is included in the workflow instance: This means, that if the activity condition of activity A at a given point of time is false, then the execution of B will not depend on
whether the state of activity A is executed or reset. Sequential predecessor constraints are marked in the Predecessor (Seq) column in the example. For instance, Activity 1.2.2 is a sequential predecessor of activity 1.2.3 (Verify), capturing that it does not make sense to verify an ordination if it has not been signed. Also, every activity in the group 1.1 is sequential predecessors of every activity in group 1.2 Logical Predecessors: If activity A is declared to be a logical predecessor of activity B, then activity A is a sequential predecessor of activity B with additional constraints: Whenever activity A is re-executed, then activity B is reset. Also, if the state of activity A is reset (as described below), then activity B cannot execute again until activity A has been executed again. Like for the sequential predecessor, the logical predecessor constraint between activities A and B has only effect at the point of times where activity A is part of the workflow instance. However, if a logical predecessor activity A becomes part of the workflow instance after activity B has been executed due to the state changes, then the state of activity B will be reset and hence the activity B must be executed once again. In the example, the verification action 1.2.3 may reset activity 1.2.1 (if the doctor finds out during verification that he needs to recalculate the ordination). This again causes activity 1.2.2 to be reset, since it has activity 1.2.1 as a logical predecessor. To allow for more fine-grained constraints, the ROC workflow model also includes an additional advanced feature called dependency expressions. Dependency expressions are a set of expressions attached to an activity. Like activity conditions, dependency expressions can also contain references to variables from the shared data store. However, an Activity Condition evaluates to Boolean values, dependency expression can evaluate to any value. Any change in the value of the dependency expression will change the activity status to reset to indicate that the activity must be executed (at least) one more time (unless it is excluded by the workflow). We have not used dependency expressions in our example.
4
Discussion
It is well known that healthcare processes are complex [17] and although much time is used on coordination [18] errors happens too frequently [1]. CPG’s can support healthcare employees in the process of following best practice consistently [6,19], but it is also well known that impediments to access relevant guidelines is an obstacle for use [20] [21] Thus it seems obvious to embed CPG’s in clinical IT- process support, although the success of such projects has not yet been convincing [9,22]. In our case study of a rather simple clinical work process we found that the process had an extension in both time and location and several actors was included. Although the process was frequently repeated there were also frequent alterations and recurrences due to returns to previous steps in the workflow. These challenges could be supported in a natural way by the declarative primitives in the ROC workflow management system. As well as the activity conditions allow smooth combination of several sub-workflows. This could be a way of implementing the “noughts & crosses” diagram. Though one have to be aware that IT based business support will lay the
grounds for new work processes, so one should not just automate existing paper based work processes [23]. It was also clear from our observation study that the descriptions in a CPG and the daily work practice are not congruent, this discongruence have to be managed while designing and implementing work process support. Health professionals are a heterogeneous group, some with little and some with immense experience within a field. Although experience may not totally protect a clinician from committing errors the risk is less and the source of annoyance from detailed guidance by the IT system will be huge. In the ROC focus is on the overall clinical managerial process, for the inexperienced there are links to CPG’s outside the ROC. Nevertheless it will be a cultural challenge for clinicians to have a clinical process system directing the road ahead [24], as well as it will have impact on the training and socialisation of new comers to the field [25]. The communication culture in the healthcare sector is profoundly oral [26]. We observed several examples of clinicians discussing factual topics to which the reply only would be a few clicks away. The cultural element will always be a challenge when implementing new technology, especially when it fundamentally changes the work processes [27]
5
Conclusion and Future Work
We believe that IT based process support has a potential in relation to chemotherapeutic treatment of cancer patients. It is though important to be aware that such a change in the clinical work is not just a question of giving access to the right applications. Access to the right equipment as well as integrations of it-systems is mandatory. Also the organisational workflows have to be analysed further and maybe changed [28]. This demands managerial support. More work has to be done to understand the work processes in healthcare and the organisational and social implications of introducing IT support. To obtain knowledge about organisational and social implications it is important to establish carefully planned experiments with process support in clinical settings. The restricted use of IT in the places we visited can be due to several reasons, it was although clear that the current IT support was incoherent and did not support the clinical way of working. A more thorough unravelling of the clinical processes and the need for information or opportunity to document is a precondition for succeeding with process support [28]. Even a rather simple workflow as the one we have examined unveiled the need for a business process support application to be integrated to several other of the hospital information systems [9,28]. Such an integration provides several challenges, both in relation to access control [29] and in relation to semantics [30,31]. The mapping of the chemotherapy workflow into the Resultmaker Online Consultant demonstrates the use of a commercial workflow model based on declarative process primitives as advocated by Pekic and van der Aalst. The resulting model rather naturally extends the paper based flowchart table used currently at the hospitals, in particular one avoids introduction of cyclic graphs. As future work we plan to present the actors at the hospitals for the ROC model and compare it to other approaches, in
particular the CIGDec language and imperative languages such as BPMN [32]. We also plan to experiment with prototypes of pervasive user interfaces to the ROC. References 1. 2. 3.
4.
5. 6. 7. 8. 9. 10. 11. 12.
13. 14. 15.
Kohn LT, Corrigan JM, Donaldson MS: To Err is Human. Building a Safer Health System. Washington DC, National Academic Press, 2000. Bardram JE, Bossen C: Mobility Work: The Spatial Dimension of Collaboration at a Hospital. Comput. Supported Coop. Work 2005;14:131160. Bødker S, Christiansen E: Designing for ephemerality and prototypicality. In Proceedings of the 5th conference on Designing interactive systems: processes, practices, methods, and techniques. Cambridge, MA, USA, ACM, 2004. Davis DA, Taylor-Vaisey A: Translating guidelines into practice. A systematic review of theoretic concepts, practical experience and research evidence in the adoption of clinical practice guidelines. Can Med Assoc J 1997;157:408-416. Cabana MD, Rand CS, Powe NR, Wu AW, Wilson MH, Abboud PA, Rubin HR: Why don't physicians follow clinical practice guidelines? A framework for improvement. Jama 1999;282:1458-1465. Grol R, Grimshaw J: From best evidence to best practice: effective implementation of change in patients' care. The Lancet 2003;362:1225-1230. Bates DW, Cohen M, Leape LL, Overhage JM, Shabot MM, Sheridan T: Reducing the frequency of errors in medicine using information technology. J Am Med Inform Assoc 2001;8:299-308. Mulyar N, Pesic M, van der Aalst WM, Peleg M: Towards the Flexibility in Clinical Guideline Modelling Languages. 2008. Lenz R, Reichert M: IT support for healthcare processes - premises, challenges, perspectives. Data Knowl. Eng. 2007;61:39-58. Shojania KG, Sampson M, Ansari MT, Ji J, Doucette S, Moher D: How quickly do systematic reviews go out of date? A survival analysis. Ann Intern Med 2007;147:224-233. Quaglini S, Stefanelli M, Lanzola G, Caporusso V, Panzarasa S: Flexible guideline-based patient careflow systems. Artif Intell Med 2001;22:65-80. Grimshaw JM, Thomas RE, MacLennan G, Fraser C, Ramsay CR, Vale L, Whitty P, Eccles MP, Matowe L, Shirran L, Wensing M, Dijkstra R, Donaldson C: Effectiveness and efficiency of guideline dissemination and implementation strategies. Health Technol Assess 2004;8:iii-iv, 1-72. Goffin JR, Savage C, Tu D, Shepherd L, Whelan TJ, Olivotto IA: The difference between study recommendations, stated policy, and actual practice in a clinical trial. Ann Oncol 2004;15:1267-1273. Field MJ, Lohr KN: Guidelines for Clinical Practice: From Development to Use. Washington DC, Institute of Medicine, 1992. van der Aalst W, Pesic M: DecSerFlow: Towards a Truly Declarative Service Flow Language in Web Services and Formal Methods. Lecture
17. 18.
19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32.
Notes in Computer Science. Springer Berlin / Heidelberg, 2006, vol 4184/2006, 1-23. Drucker PF: The New Realities. New York, Harper & Row, 1993. Reddy MC, Dourish P, Pratt W: Coordinating heterogeneous work: information and representation in medical care. In Proceedings of the seventh conference on European Conference on Computer Supported Cooperative Work. Bonn, Germany, Kluwer Academic Publishers, 2001. Sim I, Gorman P, Greenes RA, Haynes RB, Kaplan B, Lehmann H, Tang PC: Clinical decision support systems for the practice of evidence-based medicine. J Am Med Inform Assoc 2001;8:527-534. Thorsen T, Mäkelä Me: Changing Professional Practice. DSI - Danish Institute for Health Services Research and Development, 1999. Feder G, Eccles M, Grol R, Griffiths C, Grimshaw J: Clinical guidelines: using clinical guidelines. Bmj 1999;318:728-730. Ash JS, Berg M, Coiera E: Some unintended consequences of information technology in health care: the nature of patient care information systemrelated errors. J Am Med Inform Assoc 2004;11:104-112. Berg M, Toussaint P: The mantra of modeling and the forgotten powers of paper: A sociotechnical view on the development of process-oriented ICT in health care. Int J Med Inform 2003;69:223-234. Berg M, Horstman K, Plass S, van Heusden M: Guidelines, professionals and the production of objectivity: standardisation and the professionalism of insurance medicine. Sociology of Health & Illness 2000;22:765-791. Mimnagh C, Murphy M: Junior doctors working patterns: application of knowledge management theory to junior doctors training. Healthcare Computing 2004. Coiera E: Communication systems in healthcare. Clin Biochem Rev 2006;27:89-98. Orlikowski WJ, Gash DC: Technological frames: making sense of information technology in organizations. ACM Trans. Inf. Syst. 1994;12:174-207. Berg M: The search for synergy: interrelating medical work and patient care information systems. Methods Inf Med 2003;42:337-344. Bassil S, U.Reichert M, Bobrik R, Bauer T: Access Control for Monitoring System-Spanning Business Processes. InEnschede, Centre for Telematics and Information Technology, University of Twente, 2007:15. Rinderle S, Weber B, Reichert M, Wild W: Integrating Process Learning and Process Evolution - A Semantics Based Approach .Book Series Lecture Notes in Computer Science 2005;Volume 3649/2005 252-267 Bernstein K, Bruun-Rasmussen M, Vingtoft S, Andersen SK, Nohr C: Modelling and implementing electronic health records in Denmark. Stud Health Technol Inform 2003;95:245-250. Mulyar N, Pesic M, van der Aalst WMP, Peleg M: Declarative and Procedural Approaches for Modelling Clinical Guidelines: Addressing Flexibility Issues .Book Series Lecture Notes in Computer Science 2008 4928: 335-346.
