Guideline-based careflow systems

Artificial Intelligence in Medicine 20 (2000) 5 – 22 www.elsevier.com/locate/artmed

Guideline-based careflow systems S. Quaglini a,*, M. Stefanelli a, A. Cavallini c, G. Micieli c, C. Fassino a, C. Mossa b a

Dipartimento di Informatica e Sistemistica, Uni6ersita` di Pa6ia, Via Ferrata 1, I-27100 Pa6ia, Italy b Consorzio di Bioingegneria e Informatica Medica, Via Ferrata 1, I-27100 Pa6ia, Italy c Stroke Unit, IRCCS Istituto Neurologico ‘C. Mondino’, Via Palestro, 11, I-27100 Pa6ia, Italy Received 1 December 1999; received in revised form 28 February 2000; accepted 27 March 2000

Abstract This paper describes a methodology for achieving an efficient implementation of clinical practice guidelines. Three main steps are illustrated: knowledge representation, model simulation and implementation within a health care organisation. The resulting system can be classified as a ‘guideline-based careflow management system’. It is based on computational formalisms representing both medical and health care organisational knowledge. This aggregation allows the implementation of a guideline, not only as a simple reminder, but also as an ‘organiser’ that facilitates health care processes. As a matter of fact, the system not only suggests the tasks to be performed, but also the resource allocation. The methodology initially comprehends a graphical editor, that allows an unambiguous representation of the guideline. Then the guideline is translated into a high-level Petri net. The resources, both human and technological necessary for performing guideline-based activities, are also represented by means of an organisational model. This allows the running of the Petri net for simulating the implementation of the guideline in the clinical setting. The purpose of the simulation is to validate the careflow model and to suggest the optimal resource allocation before the careflow system is installed. The final step is the careflow implementation. In this phase, we show that the ‘workflow management’ technology, widely used in business process automation, may be transferred to the health care setting. This requires augmenting the typical workflow management systems with the flexibility and the uncertainty management, typical of the health care processes. For illustrating the proposed methodology, we consider a guideline for the management of patients with acute ischemic stroke. © 2000 Elsevier Science B.V. All rights reserved. Keywords: Clinical practice guideline; Workflow management system; Petri net; Decision support system * Corresponding author. Tel.: +39-0382-505679; fax: +39-0382-505373. E-mail addresses: [email protected] (S. Quaglini), [email protected] (G. Micieli). 0933-3657/00/$ - see front matter © 2000 Elsevier Science B.V. All rights reserved. PII: S0933-3657(00)00050-6

6

S. Quaglini et al. / Artificial Intelligence in Medicine 20 (2000) 5–22

1. Introduction To exploit the great potential that clinical practice guidelines (GLs) [7] offer to improve health care outcomes, it is essential to develop methodologies allowing their effective and efficient implementation within the clinical routine. It has been shown that connection with the electronic patient record (EPR) improves the compliance with the GL and, as a consequence, the care delivery quality [15,23]. For this reason, we developed a framework for a formal computerised representation of GLs and their integration with the EPR [21]. But this is not sufficient. It has also been shown that implementation of GLs is often impaired by organisational constraints [9] and that a site-specification of the GL is almost always necessary. In addition, improving communication among professionals has been recognised as one of the most important goals of modern hospital information systems, lack of communication facilities is a major bottleneck in health care delivery. To face these problems it is clear that, as well as the medical knowledge, health care organisational knowledge must be modelled, too. Modelling medical knowledge allows establishing ‘what to do’, while modelling organisational knowledge allows establishing ‘how’ and ‘by whom’ to do. Eventually, we realised that a workflow management system (WFMS) [14] could be a suitable tool to fully implement a GL and to control both its execution and outcome. In fact, from the definition given by the Workflow Management Coalition [27], a workflow is ‘The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules’, and a WFMS is ‘a system that completely defines, manages, and executes workflow processes through execution of software whose order of execution is driven by a computer representation of the workflow process logic’. In the medical field, when the ‘workflow process logic’ is provided by a GL, we could refer to the system as a GL-based patient WFMS. But, from here on, we replace ‘patient workflow’ with ‘careflow’ and thus, we talk about CFMS. Such a system allows the following questions to be answered: Is there any bottleneck in the hospital structure that impairs the GL implementation? How much does it cost to implement the GL? Is any human or technological resource over- or under-loaded? Is the organisation performance within a standard range? etc. From the development point of view we took into consideration, to save time and resources, that WFMS are widely diffused in real world environments other than health care, such as commercial and industrial settings. Thus, we exploited results achieved in those contexts, by importing the sharable technology into the health care field. In other words, we propose a methodology for integrating research tools for knowledge representation, developed in our laboratories, with available commercial tools able to simulate and manage classical workflow models. The commercial tools are Income™ and Oracle Workflow™, used for careflow model simulation and careflow implementation, respectively.


7

2. The clinical test bench application The proposed methodology has been tested on the implementation of a GL for the management of acute ischemic stroke, formulated by a Special Writing Group of the Stroke Council of the American Heart Association [1]. The GL describes the eligibility criteria, the therapy plan during hospitalisation and the follow-up scheme. This problem is particularly challenging for testing our methodology, because it involves both the application of a validated medical guideline and the need for quick and efficient communication and collaboration among different operators, possibly located in different sites. Stroke is a serious and common illness. At the moment, there are several million people who have had a stroke and are still alive. The death rate is : 30% of all stroke victims. Survivors live with varying degrees of disability. In addition to not being able to do what they once did, these patients require help from their family and outside the home (day-hospital services, visiting nurses, etc.). Stroke is thus a very expensive disease, ranging from : $8000 (mild stroke) to $30 000 (severe haemorrhages). It has been shown [4] that early management (‘need for speed’) and procedure standardisation in evaluating and treating acute stroke patients, can greatly improve the stroke outcome, in terms of survival and quality of life, while saving cost. With this premise, the scenario that we devise, where stroke patients will benefit from the proposed methodology, embeds the following steps and defines the so-called chain of recovery: rapid on-scene identification of the problem; rapid evacuation and pre-hospital intervention; rapid pre-notification of appropriate receiving facilities; rapid diagnosis and specialised treatment and evaluation at those facilities; appropriate rehabilitation. Dissemination of GLs about stroke symptoms recognition and about rehabilitation, among both general practitioners and citizens, is important and may be sufficient for the first and last phase, while for the pre-hospital and hospital phases, we figure out a careflow management system. First, it will take care of the following tasks: to alert the emergency department about the patient arrival, to communicate personal data and preliminary examination results to the hospital database, to notify specialists for standard visits and to schedule standard examinations. In addition, and this is the focus of this paper, during the hospital stay, it will help the health care operators to be compliant with the American Hearth Association GL suggestions.

3. The proposed methodology Fig. 1 shows the main methodological steps to build a guideline-based careflow system. Medical knowledge contained in a GL is formalised through a user-friendly graphical editor, called GUIDE and described in Section 4. Then it is automatically

8


translated into the Petri net formalism (see Section 3.1 for some details on Petri nets). Petri net’s computational properties have been largely used for workflow simulation [2,3,6], and here they are exploited for performing simulations on the patients’ management. In principle, a GL could be represented immediately through a Petri net, but we propose the graphical editor for two reasons: 1. It is very difficult for non-expert users to build a correct and sound Petri net; 2. The representation obtained using GUIDE may be exploited for other kinds of applications: for example if a GL must be used for educational purposes, Petri net translation is not necessary and the GL representation obtained through GUIDE can be used stand-alone. Thus, GUIDE is an intermediate step, oriented to the medical experts, by means of which a textual GL may be easily formalised. When a CFMS is the target, a ‘user transparent’ translation into a Petri net is provided. From the Petri net objects, a translation into the workflow process definition language (WPDL) is obtained automatically too. As a matter of fact, we adopt a standard representation (WPDL is the language recommended by the Workflow Management Coalition), in order to be able to exploit different existing products for the subsequent phases of the GL-based careflow implementation. Actually, careflow simulations are performed using Income™ and careflow implementations are being experimented using Oracle Workflow™. But, before simulations and implementations may be carried out, it is necessary to represent the organisational knowledge. To this aim, we designed a computational organisation ontology, described in Section 5, that can be instantiated to represent the resources of a particular health care environment. Starting from the Petri net model and the resource description, simulations may run, with two purposes: (1) verifying and validating the workflow model, i.e. testing the model behaviour and checking for the model correctness; and (2) finding the optimal resource allocation, before the careflow system is implemented in the real setting.

Fig. 1. The steps of the proposed methodology for building a careflow management system. Medical and organisational knowledge are combined and used to build a computational model of the guideline implementation within a clinical environment. Model is used for simulations, whose results allow the finding of an optimal resource allocation. Eventually, the careflow system may be enacted on the field.


9

Fig. 2. A simple Petri net and the routing constructs that can be represented and managed through this formalism. The constructs are basically the same necessary for formalising clinical practice guidelines.

Fig. 1 shows different kinds of feedback: the optimal resource allocation is achieved by simulating different resource allocations, each time arranged according to the previous simulation results. Then, as long as real-world results and statistics are routinely collected using the CFMS, additional problems not previously considered, may be highlighted and possibly fixed.

3.1. Petri nets Very briefly, classical Petri nets are oriented graph representing processes and are made up of two types of nodes, places (circles) and transitions (squares), connected by directed arcs (Fig. 2a) [18]. Arcs cannot link nodes of the same type. Transitions may fire when ‘tokens’ (resources) are present in the corresponding input place(s). When a transition is fired, tokens are consumed from its input place(s) and produced for its output place(s). Token distribution in a certain time represents the state of the system. Classical Petri nets allow modelling states, events, conditions, synchronisation, parallelism, choice and iteration (Fig. 2b). To efficiently describe real processes these features are not sufficient, thus many extensions to classical Petri nets have been proposed. The so-called ‘high level’ Petri nets allows the addition of colours, hierarchy and time to the basic representation [10,13]. Adding colours, we can model data, adding time we can estimate the time spent in each transition, and adding hierarchies, we can structure large models by using nets and sub-nets. With these extensions, Petri nets can embed all the necessary knowledge to represent GLs and their implementation.

10


4. Capturing medical knowledge through guideline formalisation In the context of Fig. 1, ‘medical knowledge’ is mainly the set of clinical practice suggestions, contained in the GL prose. We provide a meta-knowledge too, represented by a taxonomy of the possible tasks that can be included into a GL. This guarantees a common terminology and task management among different GLs that possibly run in the same environment. The same conceptual model should be shared by the database storing the electronic patient record, to allow an easy integration with the GLs. The terminology has been drawn from unified medical language system (UMLS) [12], and more specifically from systematised nomenclature of medicine (SNOMED International). GUIDE, the GL graphical editor, developed in Java, is extensively described in Ref. [21], thus its characteristics will be only briefly summarised here. Fig. 3 shows the GUIDE formalisation of the main page of the guideline for the acute ischemic stroke. As shown in the picture, the GL is hierarchically structured in ‘pages’ representing different abstraction levels: shadowed rectangles represent non-atomic tasks, whose expansion will be described in an inner page. To give an idea of the

Fig. 3. The main page of the guideline for stroke management, represented by means of the graphical editor GUIDE. Shadowed blocks represent composite tasks: the rightmost part of the figure shows the expansion of the ‘acute phase’ task.


11

computerised GL complexity, let us say that it is composed of 25 pages. Top-left bullets on rectangles indicate the strength of the scientific evidence supporting the indication contained in the tasks (red=mandatory; green= recommended; yellow= suggested). A GL is internally represented by the following nine relational tables (bold attributes compose the key). GUIDELINE (gl – code, description, eligibility criteria, first – task – code, intention, source) HIERARCHICAL – STRUCTURE (gl – code, parent – in – the – page, child – in – the – page, condition) TYPES (gl – code, element – code, type, member – of – page) SYNCRONIZATIONS (gl – code, element – code, sync – type) TASK (gl – code, element – code, name, description, expandable – in – page, activation – condition, duration, duration – unit, persistence – time, persistence – unit, priority, snomed – cod) DECISION (gl – code, element – code, dec – type, dec – subtype, dec – end, decision – support) MONITOR (gl – code, element – code, name, description, expandable – in – page, activation – condition, monitor – module, active – module, monitor – condition, deadline, deadline – unit, waiting – time, waiting – time – unit, priority) WAIT (gl – code, element – code, waiting – time, waiting – time – unit) OUTPUTS (gl – code, element – code, output) While most parts of the tables and attributes are self-explanatory, some deserve a brief illustration. The table TYPES contains, for each GL element, the corresponding type, i.e. whether it is a task, a decision node or a monitor. In the table DECISION, ‘dec-type’ may be either ‘deterministic’ (i.e. rule-based) or ‘non-deterministic’ (i.e. choice left to the user), while dec-subtype may be either ‘OR’ or ‘ONE-OF’. In the case of a non-deterministic decision, the ‘decision – support’ attribute value is a hyper-link to a web site where the user can exploit a decision–theoretic model to obtain a suggestion [22]. The table OUTPUT establishes the correspondences between the patient record and the measures performed by executing a GL task: for example, if a task requires the measuring of the complete blood count (CBC), the table row will contain the name of the EPR table where CBC measures are stored. With respect to other formalisms for guideline representation [8,16,19,24], GUIDE shows some peculiarities, mainly for the links to the terminology server, to the EPR and to decision analytic models.

4.1. From the formalised guideline to the Petri net Starting from the relational database, a translator (written in C++) provides an object-based representation of the corresponding Petri net in terms of places and transitions. The same structure is also represented in WPDL. As an example, the WPDL code for the two first tasks of the stroke GL is the following:

12


WORKFLOW MT0 DESCRIPTION ‘Petri Net for Stroke – Eng’ ACTIVITY T2068 IMPLEMENTATION ATOMIC DESCRIPTION ‘Onset Modalities Deficit Duration Deficit Type’ EXTENDED – ATTRIBUTE NAME Anamnesis EXTENDED – ATTRIBUTE TIME – UNIT MINUTES EXTENDED – ATTRIBUTE PROC – TIME 10 END ACTIVITY ACTIVITY T4602 IMPLEMENTATION WORKFLOW ‘MT4602’ DESCRIPTION ‘Collection of the main signs and symptoms to assess a preliminary diagnosis’ EXTENDED – ATTRIBUTE NAME Objective and Neurological// examination EXTENDED – ATTRIBUTE TIME – UNIT MINUTES EXTENDED – ATTRIBUTE PROC – TIME 20 END ACTIVITY TRANSITION T1 FROM T2068 TO T4602 EXTENDED – ATTRIBUTE STORE – SHORT – NAME PT2068’ EXTENDED – ATTRIBUTE STORE – NAME ‘Anamnesis’ END TRANSITION TRANSITION T2 FROM T4602 TO E6394 EXTENDED – ATTRIBUTE STORE – SHORT – NAME ‘PT4602’ EXTENDED – ATTRIBUTE STORE – NAME ‘Objective and Neurological//examination’ END TRANSITION This description may be interpreted by Income™ and the corresponding Petri net is shown in Fig. 4. The Petri net is the so-called ‘behavioural model’ of the careflow because it represents the sequence of activities to be performed. The next step for building a CFMS is to allocate the resources necessary to perform these activities. Resources are represented in the organisational model, as explained in the following section.

5. Capturing organisational knowledge through an ontology-driven tool As already mentioned, we developed an ontology of the health care organisation. An ontology is a formal description of the entities and their relationships in a


13

Fig. 4. The Petri net corresponding to the main page of the guideline for stroke management (left) and the sub-net corresponding to the composite task ‘sub-acute phase’ (right). High-level Petri nets allow the managing of hierarchies of nets and to represent data about resources used and time spent in task execution.

certain domain [25]. For our purposes, an ontology should be able to provide concepts description in the domains of activities, time, products, resources, goals, etc. In addition, an ontology should be ‘operational’, i.e. suitable to be integrated with other tools of the system. Examples of organisation ontologies are Toronto Virtual Enterprise (TOVE) [11] and the Enterprise Ontology [26], and a review of computational models for simulating organisations can be found in Ref. [20]. The common concept shared by these models is that an organisation is a set of constraints on the activities carried on by the agents. It consists of operative units and sub-units, a set of organisation agents, a set of roles that the agents play within the organisation and a set of goals and sub-goals that roles try to achieve for the benefit of the organisation. An agent in the organisation may play one or more roles. Each role is defined by the set of goals that it must reach. Agents execute activities and consume resources. All these concepts are shown in Fig. 5. This ontology must be instantiated to represent a specific organisation, and this is done by means of an interface that, starting from the ontology structure, creates a relational database and allows users to fill the tables. In Fig. 6 the roles played by some agents are defined, while Fig. 7 shows, by means of an organisation chart, the hierarchy of the structures involved in the implementation of the GL for the stroke management.

14


Fig. 8 shows the Income™ visualisation of the details of an organisation unit, such as responsibilities and resources. The right-most part of the figure shows the resources assigned to the stroke unit: they are both human resources (six nurses, one responsible physician, two assistant physicians) and technical resources (six beds, instruments for rehabilitation, ECG, pressure and O2 monitoring instrumentation). The other necessary resources are external to the stroke unit: some instrumentation (CT, NMR) belong to other departments in the same hospital, while some consultants (cardiologists, language therapist, neurosurgeon) work in other hospitals (namely Clinica Citta’ di Pavia and Policlinico San Matteo).

6. Dynamic simulation and analysis of health care processes It is very important to verify the soundness of the careflow model before enacting the careflow itself. By using Petri nets this can be done by simulation runs. During simulations, concrete objects are added into the process model: in our context, the objects are the patients admitted to the stroke unit. In this phase, we created some views from a database of :350 patients that were admitted to the stroke-units involved in the project, in order to provide the simulator with realistic values for the most important inputs, such as patient arrival times, patients demographic characteristics, complication frequency and so on. The main purpose of simulation runs is to find time, amount and cost of the used resources. Some useful information that can be derived is:

Fig. 5. Part of the organisation ontology. Ovals represent entities and rectangles represent relationships among them. Dotted lines represent taxonomical relationships.


15

Fig. 6. Instantiating the organisation ontology: the relationship ‘play’ has been translated into the structure of a relational table and roles played by different agents in the specific organisation may be inserted.

Fig. 7. The organisation chart of the health care structures involved in the implementation of the GL for stroke management. This scenario refers to the Pavia neurological hospital stroke unit, that requires resources from other departments of the same hospital and other hospitals in the same town.

at which time (if any) certain resources have a high or low load. This should allow the re-allocation of both the number and the shifts of the operators and to plan for purchases; bottlenecks or ‘capacity reserves’ at certain times: each place in the Petri net has a predefined capacity (e.g. no more than six patients may be in the stroke units at the same time) in such a way that its ‘load’, i.e. the ratio between the capacity and the actual number of objects, may be computed;

16


time spent by patients in the different phases of their management. Execution time associated with each activity is sampled from a random distribution estimated either from real data or from the domain experts’ opinion; the costs for the different patients in the different phases. Each activity is associated with different kinds of costs (processing cost, lay cost, cost of materials etc.), in such a way that possible reasons for excessive observed costs may be highlighted. Also, cost distribution among patients may be analysed in order to find possible clusters of patients more or less ‘expensive’. The activities more frequently performed: this could be useful to find out some activity that, for some reason to be explained, is not performed as frequently as expected. Two exemplars of these reports are illustrated in Fig. 9a,b.

7. The workflow implementation Through Oracle Workflow™, we are evaluating a prototype of the careflow system in the clinical setting. The main modules of the system are: The Monitor, that allows viewing and administering the status of a specific instance of a careflow process (work-item). The status of any transition (shown as an arrow in Fig. 10a) that has been traversed appears with a thick green line, while an untraversed transition appears with a thin black line. By this tool, the administrator is able to control whether the careflow runs correctly. The Notification Mailer, which lets people receive notifications of work-items awaiting their attention via e-mail and acts based on their e-mail responses. Each

Fig. 8. The Income™ interface for visualising and modifying the details of an organisation unit. The resources for the unit are specified, together with their availability information.


17

Fig. 9. (a) The workload of human resources, namely the nurses and (b) a technological resource, namely an electrocardiograph. The simulation run is about the particular stroke unit of the Pavia neurological hospital, with six beds available and considered a rate of one admission request per day. The time axis is labelled with week-wide time intervals, within each month.

involved operator can inspect his/her own to-do list, including necessary support information to perform the task(s) (ex.: a hyper-link to a web page, as shown in Fig. 10b). The Workflow Builder, that allows the description of activities, that are the real-world tasks. Activities may be either manual, semi-automatic or automatic. For manual activities, workflow engine only provides notifications for the operator availability and then requires a confirmation for the activity completion. For semi-automatic activities, the engine offers support such as html forms and allows the fulfillment of the assigned tasks through a web browser (ex. data input in Fig. 10c). The automatic activities are transparent to the users and are completely executed by the computer. By these modules it is possible to check the careflow status and the resources availability, to assign tasks to people according to their roles, defined in the organisation model and to monitor the tasks execution. Information about the performed tasks are stored into the workflow database, in such a way that statistics can be performed on times, costs and workloads.

18


7.1. Managing the non-compliances Typical WFMS are installed in environments where tasks and task sequence are very well pre-defined. In contrast, medical processes may often be unpredictable because of the intrinsic uncertainty present in most of the patient management phases. As a matter of fact, even if a clinical practice guideline illustrates the steps to follow in pre-defined situations, it may happen either that a new, unpredictable situation arises, or the physician, that is the final decision-maker, is not compliant with the GL. Thus, CFMS must be flexible enough to tackle sudden modifications of the pre-defined plan. The problem of managing exceptions has recently been outlined in the literature [5,17]. To this concern, in our system: 1. there are ‘mandatory’ tasks, i.e. tasks that must be performed in any case and no reason can exist for bypassing them 2. if a task is not mandatory, the health care operator may decide to substitute the task with another one, or to skip the task

Fig. 10. The careflow implementation. (a) The monitor console (the arrow indicates the current task); (b) a message sent to a human resource (in this case a physician); and (c) the form for data input, automatically appearing to the physician when he accepts the task.


19

Fig. 11. Managing the non-compliance: when a health care operator does not accept the task proposed by the guideline and executes a different task, or simply skips the task, the system keeps track of that, as well as the motivation, that is mandatory and provided by the user.

3. when substituting a task, two situations are handled: the operator executes a task belonging to the GL (may be a task that should have been done later, or a task defined by the GL but for a situation different from the actual one) the operator executes a task outside the GL In both cases, SNOMED is used to allow the user to choose a task according to the pre-defined terminology. That is to say, SNOMED has been integrated both in the GL editor and the CFMS. When a task suggested by the GL is not performed, the operator must justify his/her behaviour (see Fig. 11). PL/SQL code has been developed for managing these situations within the Oracle Workflow™ engine. It must be stressed that ‘being non-compliant’ is different from ‘re-assigning’ a task. The re-assignment option is typical and is native in WFMS because it refers to the situation in which the agent notified by the system is not available, because he/she is not actually present or is involved in other activities and thus, another agent with the same role is looked for by the system itself. The non-compliance is much more complicated: not only does it cause skipping or substituting the planned task, but also may change the roles involved in a task execution and also may cause changing future plans. In addition, it has been necessary to create additional tables, to keep track of the non-compliances: this is fundamental to obtain very useful feedback for highlighting the weak points of a GL.

7.2. System e6aluation The careflow has not been fully implemented in the real clinical setting yet. More

20


precisely, while careflow simulator and GUIDE have been used in the field, the workflow management system has been implemented as a research prototype. However, we evaluated the effects of the GL implementation on the health care outcomes and hospital costs. The GL delivered by the American Heart Association, after a site-specification for adapting it to the Italian setting, has been implemented in four Italian centres managing stroke patients. These centres were provided with a common database, developed with MS-ACCESS; its schema was based on a pre-existing EPR and augmented with attributes necessary for storing the information about the GL implementation. Data on :350 patients have been collected, concerning both the hospital stay (12 days on average), and the follow up (6 months on average). While all patients, in principle, should have been treated according to the GL, the database analysis provided evidence of several non-compliances. At the moment, we did not find any particular patient characteristics that could justify difference in treatment. The number of non-compliances, NC, has been calculated for each patient, and its correlation with survival, quality of life and costs have been investigated. The Cox proportional hazard model showed a relative risk of about 2.6 (confidence interval 1.5–5) for patients with NC ] 10, with respect to the other ones. In addition, NC is inversely correlated with the improvement of the index of the patient recovery, measured by the Barthel score (r = −0.16, P= 0.04). Last but not least, complying with the GL seems to decrease costs because of a reduced hospital stay and reduced additional visits and hospital re-admissions during the follow-up. Despite the fact that these are only preliminary results and additional multivariate analysis is needed to refine them, we think that they are important to provide the user with feedback for a better implementation of the GL itself.

8. Conclusion In this paper we proposed a methodology for modelling and implementing clinical workflow processes, called careflows, where expertise in medical care is combined with expertise in organisational structure. However, from the representation point of view, these knowledge types are separated. This separation allows an easier maintenance of the system in the face of changes in either the medical knowledge or the resource allocation. The tools developed, integrated with commercial technological solutions, support: knowledge acquisition, in terms of medical knowledge (contained in clinical practice GLs) and in terms of site-specific working organisation; optimal resource allocation, through the simulation of a workflow model, based on the sound Petri net theory real-life patient workflow implementation, through a workflow engine. The peculiarity of the engine, that makes the difference with respect to the classical workflow systems, is the capability to handle non-compliances. We believe this methodology will improve health care delivery by solving problems due to lack of flexibility of computerised GLs (this is a crucial issue for


21

user acceptance of these systems) and to communication and co-operation difficulty among health care professionals. We showed that the strategic value of clinical knowledge represented through GLs can be incorporated into CFMS. This technology holds great promise to make GL-based practice a reality, leading to high-quality and efficient patient care. A major problem still to be solved concerns the integration of these systems with legacy systems. As matter of fact, we adopted an ‘ad hoc’ solution, by developing a database exploitable by the implemented GL. But what about if the GLs to be implemented are more than one and they are implemented incrementally in time? Answers to these questions are related to the research on the EPR issues, such as standards for terminology, communication, retrieval, etc. that is beyond the scope of this paper.

Acknowledgements This work is partially funded by the European Commission through the project PatMan (Patient Management) within the Health Care Telematics Applications Programme. The authors thank S.K. Andersen and the other partners of the Patman Project for their helpful comments. The authors are grateful to the hospital teams that provided data for evaluating the GL impact.

References [1] Adams HP, Brott TG, Crowell RM, Furln AJ, Gomez CR, Grotta J, Helgason CM, Marler JR, Woolson RF, Zivin JA, Feinberg W, Mayberg M. Guidelines for the management of patients with acute ischemic stroke. Special report. Stroke 1994;25(9):1901– 11. [2] van der Aalst WMP, van Hee KM, Houben GJ. Modelling and analysing workflow using a Petri-net based approach. Proceedings of the Second Workshop on Computer-Supported Cooperative Work, Petri-nets and Related Formalisms, 1994. p. 31 – 50. [3] van der Aalst WMP. The application of Petri nets to workflow management, J Circ Sys Comp 1998. [4] Bowen J, Yaste C. Effect of a stroke protocol on hospital cost of stroke patients. Neurology 1994;44(10):1691–4. [5] Casati F, Ceri S, Paraboschi S, Pozzi G. Specification and implementation of exceptions in workflow management systems, ACM ToDS, September, 1999. [6] Ellis CA, Nutt GJ. Modelling and enacting of workflow systems, application and theory of Petri nets, 1993. In: Ajmone-Marsan M, editor. Lecture Notes in Computer Science 691. Berlin: Springer–Verlag, 1993:1–16. [7] Field MJ, Lohr KN, editors. Institute of Medicine: Guidelines for Clinical Practice. From Development to Use. National Washington, DC: Academy Press, 1992. [8] Fox J, Johns N, Rahmanzadeh A. Disseminating medical knowledge: the PROforma approach. Art Intell Med 1998;14:157–81. [9] Fridsma DB, Gennari JH, Musen MA. Making generic guidelines site specific, In: Cimino JJ editor. J Am Med Inform Assoc. Proceedings of the 1996 AMIA Fall Symposium, Philadelphia: Hanley and Belfus, 1996. p. 597–601. [10] Genrich HJ, Lautenbach K. System modelling with high level Petri net. Theor Comp Sci 1981;13:109–36.

22


[11] Gruninger M, Fox MS. The logic of enterprise modelling. In: Brown J, Sullivan DO, editors. Reengineering the Enterprise. London: Chapman and Hall, 1995:83 – 98. [12] Humphreys BL, Lindberg DAB, Schoolman HM, Barnett GO. The unified medical language system: an informatics research collaboration. J Am Med Inform Assoc 1998;5:1 – 11. [13] Jensen K. Coloured Petri nets. Basic concepts, analysis methods and practical use. In: EATCS Monographs on Theoretical Computer Science. Berlin: Springer – Verlag, 1992. [14] Lawrence P, editor. Workflow Handbook 1997. Published in association with the Workflow Management Coalition. New York: Wiley, 1997. [15] Lobach DF, Hammond WE. Development and evaluation of a computer-assisted management protocol (CAMP): Improved compliance with care guidelines for diabetes mellitus. Proc Symp Comp Appl Med Care 1994;18:787– 91. [16] Miksch S, Shahar Y, Johnson P. ASBRU: A task-specific, intention-based, and time-oriented language for representing skeletal plans. In: Motta E, Harmelen FV, Pierret Golbreich C, Filby I, Wijngaards N, editors. Proceedings of the Seventh Workshop on Knowledge Engineering:Methods and Languages. Milton Keynes, UK: The Open University, 1997. p. 9.1 – 9.20. [17] Muller R, Rahm E. Rule-Based Dynamic Modification of Workflows in a Medical Domain. Proceedings of BTW99, Freiburg im Breisgau: Springer. 1999. p. 429 – 448. [18] Murata T. Petri nets: properties, analysis and applications. Proc IEEE 1989;77(4):541– 79. [19] Ohno-Machado L, Gennari JH, Murphy SN, et al. The guideline interchange format: a model for representing guidelines. J Am Med Inform Assoc 1998;5:357 – 72. [20] Prietula MJ, Carley KM, Gasser L, editors. Simulating organizations — computational models of institutions and groups. Menlo Park, CA: AAAI Press/The MIT Press. 1998. [21] Quaglini S, Dazzi L, Gatti L, Stefanelli M, Fassino C, Tondini C. Supporting tools for guideline development and dissemination. Art Intell Med 1998;14:119 – 37. [22] Quaglini S, Dazzi L, Stefanelli M, Barosi G, Marchetti M. Decision support systems in health economics. Topics Hlth Inform Manag 1999;20(1):16 – 30. [23] Shiffman RN, Liaw Y, Brandt CA, Corb GJ. Computer-based guideline implementation systems: a systematic review of functionality and effectiveness. J Am Med Inform Assoc 1999;6:104 – 14. [24] Tu SW, Musen MA. The EON model of intervention protocols and guidelines, In: Cimino JJ, editor. J Am Med Inform Assoc, Proceedings of the 1996 AMIA Annual Fall Symposium, Philadelphia: Hanley and Belfus. 1996. p. 587 – 591. [25] Uschold M, Gruninger M. Ontologies: principles, methods and applications. Know Engin Rev 1996;11(2):93–136. [26] Uschold M, King M, Moralee S, Zorgios Y. The Enterprise Ontology. The Knowledge Engineering Review 1998;13 Special issue on putting ontologies to use. Uschold M, Tate A, editors. [27] Workflow Management Coalition, http://www.aiim.org/wfmc.

.