MEDINFO 2001 V. Patel et al. (Eds) Amsterdam: IOS Press © 2001 IMIA. All rights reserved
Simulation of a Stroke Unit Careflow Silvana Quaglinia, Ezio Caffib, Anna Cavallinic, Giuseppe Micielic, Mario Stefanellia a
Dipartimento di Informatica e Sistemistica, Università di Pavia, Italy b Consorzio di Bioingegneria e Informatica Medica, Pavia, Italy c IRCCS Istituto Neurologico “C. Mondino”, Stroke Unit, Pavia, Italy
integrating the guideline decision support into the clinical routine by means of a workflow management system (WfMS)[2]. As a matter of fact, a workflow is a collection of activities which support a specific process, and a WfMS is defined as “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” [3]. In a simplified view, a WfMS can be figured out as a knowledge-based system that assigns the right task to the right operator at the right time. When the process logic is provided by a clinical CGL, we refer to the system as a CGL-based patient WfMS or, alternatively, CareFlow Management System (CfMS). Differently from the installation of a WfMS within an administrative department or an industrial production line, the implementation of a new CGL may deeply affect the healthcare organisation, because it may introduce new tasks and/or the need for additional professionals, with respect to the “conventional” way of care delivery. This justifies the need of simulating the impact of these changes before the enactment of the careflow system on the field. Modelling and analysing workflows using a Petri-net based approach has been proposed by some authors [4] as a means for providing a semantic of workflows and WfMS, for analysing the model structure, and for estimating the system performance under different resource allocations. We agree on this arguments, the benefits in our case being the possibility of detecting rare/frequent patient patterns, estimating over/under-loading of healthcare professionals, need for additional technological resources, need for different communication modalities among professionals, and costs.
Abstract This paper describes the development and use of a simulation model representing part of the medical practice within a Stroke Unit. In particular, we modelled the medical activities as described in a guideline for the ischemic stroke treatment, adopted by the Stroke Unit of our hospital. The Petri net formalism has been chosen for the model representation. The numerical parameters have been estimated both using a database of about 100 patients collected during the last two years, and eliciting knowledge from the neurologists. A commercial tool was used for performing simulations, while ad-hoc routines were written for tailoring the result presentation to the specific context. We consider simulation a very useful preliminary step for the subsequent implementation of a patient workflow (careflow) management system. In fact, simulation is based on the process model (the clinical practice guideline) and on the organisation model (human and technological resources), so allowing to detect bottlenecks in the care delivery organisation and to find the optimal resource allocation. For example, we show that simulation has been able to find some of the causes of the delay in the patients treatment, and accordingly, to suggest changes in the organisation. Keywords: workflow, clinical practice guideline, simulation, Petri Net, stroke
Introduction
We had previously designed a graphical editor for representing CGLs with a user-friendly interface [5], and we are also experimenting the careflow enactment by using Oracle WorkflowTM [2], but the focus of this paper is on the simulation phase, i.e. the intermediate phase between the CGL representation and the careflow enactment. The clinical problem chosen for testing our proposed methodology is the treatment of patients with acute ischemic stroke within a Stroke Unit.
Problems arising when implementing clinical practice guidelines (CGLs) in healthcare environments are widely described in literature [1]. They mainly concern lack of compliance due to different opinion of the physicians and more practical issues such as 1) availability of all the resources necessary for the guideline implementation and 2) communication problems among different professionals that are required to collaborate in order to perform the tasks suggested by the CGL in the due time. To tackle these issues, the authors recently proposed a methodology for
1190
Chapter 13: Evaluation
arcs (Figure 1) [4]. Arcs can not link nodes of the same type. Transitions may fire when tokens (resources) are present in the corresponding input place(s) (tokens are
Previous work on the same application field has been carried out by Heinrichs et al [6] that also simulated the activities in a Stroke Unit for estimating its capacity, but only considering the probabilistic distribution of patient arrival and hospital stay. Our purpose is to use a more detailed simulation model, comprehending all the tasks suggested by the CGLs, in such a way to detect bottlenecks or describe resource need at the level of the single task.
s ta rtt in p u t
Materials and methods
f in is h o u tp u t
Figure 1- The basic schema of a classical Petri Net represented as bullets inside the node). 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. To efficiently describe real processes, many extensions to classical Petri nets have been proposed. The so-called “high level” Petri nets allow to add colours, time and hierarchy to the basic representation. This allows to model data, to estimate the time spent in each transition, and to structure large models by using nets and sub-nets. With these extensions, Petri nets and CGLs elements, as represented with our graphical editor, have a one-to-one correspondence. The types of basic routing constructs that can be represented with the graphical editor are the 1) sequential, 2) parallel, 3) conditional and 4) iterative, and all of them can be mapped into a Petri net, in terms of positions and transitions. Thus, we developed a translator that, starting from the internal CGL representation (a relational database describing the tasks and their sequence), provides a Petri-net written in WPDL, the workflow process definition language recommended by the Workflow Management Coalition. Such a representation is given as input to IncomeTM (Promatis Informatik, Germany), the Petri-net based tool used for performing simulations.
The pathology and the clinical setting In 1994 the Ad Hoc Committee of the Stroke Council of the American Heart Association proposed guidelines for the management of patients with acute ischemic stroke [7] and with transient ischemic attacks. The nature of these recommendations highlights the need of a co-ordinated multidisciplinary team, comprehending neurologists, trained nurses, physical-, occupational-, and speech therapists, psychologists, and specialist consultants (e.g. cardiologists). Only in rare settings these professionals are available within the same department. In our case, most of therapists and consultants belong to other hospitals, and this must be taken into account when modelling their interventions. Before the introduction of the CfMS, we performed a pilot study, and the CGLs were made available to the healthcare professionals of the Stroke Unit: 102 consecutive subjects with a confirmed diagnosis of first-ever ischemic stroke were treated accordingly. CGLs were represented as browsable flow-charts and integrated with the electronic patient record (EPR), in such a way that it was possible to obtain suggestion about the next step to perform for the specific patient. At this stage, only the medical knowledge was represented, while nothing was taken into account about organisational issues (this will be instead a peculiarity of the CfMS). The EPR, implemented with the MSACCESS relational database management system, stored the data concerning the past medical history of the patient, the hospital admission modality, all the interventions carried out for each patient (including drug dosages and timing), diagnostic test results, assessment scales’ scores, complications, and follow-up information. Data from this very detailed EPR were used for the quantification of the simulation model, as will be shown in next sections.
The model As mentioned, the Stroke Unit of our hospital adopted the CGLs delivered by the American Heart Association. Their graphical representation consists of 15 pages showing tasks at different levels of abstraction. The first page is shown in Figure 2a. Figure 2b shows the corresponding Petri net. The part of the net representing the medical tasks is obtained automatically as explained above. But the so-obtained skeleton is not sufficient to perform simulations, because this requires to represent in addition:
Petri Nets As mentioned, the Petri Net formalism has been adopted for simulation purposes. Classical Petri nets are oriented graphs representing processes, with two types of nodes, places (circles) and transitions (squares), connected by directed
1.
1191
the patients arrival and their admittance to the stroke unit
Chapter 13: Evaluation
b) No admittance
Re-direction
a)
Figure 2 - a) the main page of the guideline for the treatment of a stroke patient; b) the portion of the Petri net representing the same tasks (dashed tasks in part a are composite tasks) and, in addition, the recruitment task 2.
the type and number of resources necessary for performing each CGL task
3.
the recruitment modality of these resources (an instrument may be always present on-site, while a human resource may need a telephone call)
4.
a probability distribution at each CGL decision node, where the subsequent tasks depend on a causal variable value (e.g. a test result)
In Figure 2b the first two nodes represent the patient recruitment to the Stroke Unit. Of course the CGL does not mind about the bed availability, the patient type (some haemorrhagic stroke patient must be re-directed immediately to the neurosurgery department), and the time of patient arrival, but these are essential features for the simulation. Using real data from our pilot study, we estimated the parameter of a Poisson distribution for the patient arrival (λ=0.9 days), and the proportion of the different stroke types (20% haemorrhagic, 80% ischemic). According to the observed distribution of these and other variables, such as age, sex, and ischemic stroke classification, we generated a table of simulated patients, containing all the data necessary for the CGL task execution. How to embed and exploit this information into the model? In Income each activity can be detailed by writing Macros in PROLOG. By means of a
Each of these requirements has been modelled by exploiting both the native representation capabilities of the coloured Petri Net, and the possibility of programming ad-hoc routines for controlling a transition firing. Next sections illustrate some examples related to the issues listed above. The patient arrival
1192
Chapter 13: Evaluation
The information stored while describing the different resource types is the default used by the system for a standard allocation task, i.e. a resource is recruited if it is not involved in other ongoing activities yet, and if the current time is within its “working time”. Sometimes, this is not sufficient. As a matter of fact, in addition to the Stroke
Macro, one can control the information contained in the objects “circulating” throughout the net, perform calculations and take decisions about subsequent paths. One can also create and manage tables in the Income database, for facilitating subsequent analysis of the simulation result. To this aim, a table has been created containing the following information: Patient Code; Date/Time of the patient arrival; Date/Time of the patient discharge; Output state. At the end of a simulation, statistics on this table allows for example to calculate the proportion of patients that have not been accepted due to lack of beds. We exploit the bed management issue to illustrate the use of Macros. The “bed” is a particular resource, that needs to be controlled apart from the standard Petri Net functionality, because the “bed” is not continuously recruited/released at the start/end of a certain activity type, as it happens for example for a CT scanner. The bed must be occupied from the patient admittance until the patient discharge. For this reason we defined a global variable for the number of occupied beds. The following code, embedded into an activity of the task “recruitment”, controls for bed availability at the patient arrival. /* Activity : NO BEDS Sta_ou=S1_in, /* Controlling for a free bed (at each patient arrival the number of beds is incremented by one) */ Name = 'beds', read_global(Name,Value),
Figure 3 – Specification of resources /* If number of beds > 6 the patient cannot be accepted */ (Value @> 6)-> S1_in=[patient_record([admissiondate(Ad) , aux(_), code(Cd), dayoftherapy(_), onsetofsymptoms(_)])], now(Dd), number_to_string(Cd,Cod), m_insert('PATIENTS',['CODE','ARRIVAL','O UTPUT','STATE'],[Cod,Ad,Dd,'No beds']),
Unit team, consultants belonging to other departments or to different hospitals are required. This has been considered by introducing a random number generation for simulating their arrival time. We used a normal distribution whose parameters have been suggested by the stroke team. The activity duration was generated in a similar way. The following macro illustrates this functionality: /* the physician belong to an external department, and, once called for, he arrives within about 30 min */
/* The number of occupied beds is decremented by one */ add(Value,-1,Val), change_global(Name,Val), write_file('d:\\Users\\Ezio\\Income\\bed s.dat',Val,'a'), write_nl('d:\\Users\\Income\\beds.dat').
((Hour @< 8; Hour @>= 18), Elem @=< 1)-> random_normal(20,40,30,5,Real1), add_transport_time(Real1,'MINUTE');
Probability distribution of the different patterns
Resource description Figure 3 illustrates the interface for specifying the resources needed for a certain task. In a preliminary step, all the possible resource types are declared and, during the phase shown in the figure, the resource characteristics (basically type, number, and availability) are provided. The management of particular resources, such as the bed, has been described in the previous section.
The CGL embeds a number of decision steps, i.e. conditional statements that determine the next tasks according to the patient clinical conditions or some diagnostic test result. Concerning patient data, they are read from the simulated records, while for a test result, it is randomly generated, according to the disease (when it is known) or to the disease prevalence and the sensibility and specificity of the test.
Resource recruitment modality
Results Several types of results can be obtained analysing the
1193
Chapter 13: Evaluation
number of nurses (actually five) is too high, and at least one nurse is always unemployed.
simulation data. Among them: - at which time, if any, a resource has a high/low load (this allows to re-allocate both the number and the shifts of the operators or to plan instrumentation purchase); - time spent by patients in the different phases of their management (some bottlenecks should be detected, impairing the patient regular treatment); - the costs for the different patients in the different phases (each activity is associated with different kinds of cost, such as processing cost, lay cost, consumable cost, etc)
Conclusions Our study showed the potential of a simulation model in providing insight into the careflow of patients within a Stroke Unit, particularly when activities have to be performed according to a clinical practice guideline. We also illustrated challenging problems in modelling the careflow with a coloured Petri Net. Additional effort is required to compare the simulation results with the observed patterns of patients, in such a way to fully validate the model.
Number of occupied psychologists
Acknowledgments The authors thank the Promatis Informatik for the technical support. This work has been partially funded by the European Commission through the PatMan project.
Simulation time (days of the month)
References
Figure 4- The psychologist workload
[1] Zielstroff RD. Online Practice guidelines: Issues, obstacles, and future prospects. J Am Med Inform Assoc 1998: 5 (3) pp. 227-236.
Here, we focus on professional workload and activities with a high waiting time and we show results after
[2] Quaglini S, Stefanelli M, Lanzola G, Caporusso V, Panzarasa S. Flexible guideline-based patient careflow systems, Art Intell Med, 22 (1) (2001) pp. 65-80
Hours of overtime
[3] Lawrence P (Ed.), Workflow Handbook 1997, Published in association with the Workflow Management Coalition (J Wiley & Sons, 1997).
Electrocardiograph
[4] van der Aalst WMP, The Application of Petri Nets to Workflow Management, The Journal of Circuits, Systems and Computers 1998: 8, 1, pp. 21-66.
Physician
[5] Quaglini S, Dazzi L, Gatti L, Stefanelli M, Fassino C, Tondini C, Supporting tools for guideline development and dissemination, Art Intell Med 1998:14, pp. 119-137
Figure 5- The hour overtime, i.e. time that activities wait for to be executed due to the lack of a certain resource
[6] Heinrichs M, Beekman R, Limburg M. Simulation to Estimate the Capacity of a Stroke Unit. Medical Infobahn for Europe, A. Hasman et al. (Eds.) IOS Press, 2000
simulating patients admitted to the Stroke Unit during a 2months simulation time. Figure 4 shows the psychologists workload (first month). The picture suggests that one of such professionals is sufficient and, since his engagement is not continuous, he could be a consultant, instead of a Stroke Unit member. Figure 5 shows that lack of availability for electrocardiographs and physicians caused some activities to be delayed, but of a reasonable amount of time (minutes). This was not the case when the physician was only partially available during the night (i.e. a telephone call was needed to alert him): in this case simulations showed an overtime up to 2 hours for the task “history taking”, that is obviously unacceptable. Other reports, not shown for lack of space, indicate that the
[7] Adams HP, Brott TG, Crowell RM, Furln AJ, Gomez, J Grotta CR, 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 25, 9 (1994) 1901-1911 Address for correspondence Silvana Quaglini (
[email protected]) Dept. Informatica e Sistemistica, University of Pavia Via Ferrata, 1 – 27100 Pavia, Italy
1194
