Lightweight Interacting Patient Treatment Processes

Lightweight Interacting Patient Treatment Processes

Ronny Mans (Department of Mathematics and Computer Science, Eindhoven University of Technology, Eindhoven, The Netherlands), Wil van der Aalst (Department of Mathematics and Computer Science, Eindhoven University of Technology, Eindhoven, The Netherlands), Nick Russell (Carba-Tec Pty. Ltd., Wakerley, QLD, Australia), Piet Bakker (Department of Quality and Process Innovation, Academic Medical Center, University of Amsterdam, Amsterdam, The Netherlands) and Arnold Moleman (Department of ADICT, Academic Medical Center, University of Amsterdam, Amsterdam, The Netherlands)
Copyright: © 2012 |Pages: 19
DOI: 10.4018/ijkbo.2012100101

Abstract

Processes concerning the diagnosis and treatment of patients cannot be straightjacketed into traditional production-like workflows. They can be best characterized as weakly-connected interacting light-weight workflows where tasks reside at different levels of granularity, and for each individual patient a doctor proceeds in a step-by-step way deciding what next steps be taken. Classical workflow notations fall short in supporting these patient processes as they have been designed to support monolithic processes. Classical notations (WF-nets (work flow nets), BPMN (Business Process Model and Notation), EPCs (Electronic Prescriptions for Controlled Substances), etc.) assume that a workflow process can be modeled by specifying the life-cycle of a single case in isolation. To address these problems, the authors present an extension of the Proclets framework which allows for dividing complex entangled processes into simple autonomous fragments. Additionally, increased emphasis is placed on interaction related aspects such that fragment instances for individual patients can cooperate in any desired way. The authors describe an implementation of the Proclets framework. Proclets have been added to the open-source Workflow Management System YAWL to better support inter-workflow support functionalities.
Article Preview

Introduction

In healthcare organizations, such as hospitals, many complex processes are performed which are lengthy in duration. These are concerned with the diagnosis and treatment of patients. Workflow Management Systems (WfMSs) present an attractive vehicle in order to provide support and monitoring for patient processes. Based on process definitions, WfMSs are able to manage the flow of work in these processes such that individual work items are done at the right time by the proper person (van der Aalst & van Hee, 2002; Weske, 2007).

However, a number of difficulties commonly arise when hospitals attempt to automate patient processes. This is because the entire process for an individual patient typically consists of a number of workflow fragments that need to cope with different levels of granularity and that run at different speeds. Moreover, the doctor proceeds in a step-by-step way when deciding about the steps to be taken next. This can be illustrated by the example that is depicted in Figure 1.

Figure 1.

Interacting workflow fragments. The arcs show the interactions that need to take place between fragment instances.

Figure 1 shows two possible instances of a patient process. For patient ‘Sue’ the process is as follows. First, she visits the outpatient clinic (the process instance named ‘visit:Sue 25/01’). Here, a doctor decides during the ‘decide’ task about the next step(s) that need to be taken. As indicated by the outgoing arcs, a second visit is necessary (‘visit:Sue 10/02’), a lab test needs to be taken (‘lab:Sue 25/01’), and Sue's case needs to be discussed during a multidisciplinary meeting (MDM) (‘MDM:05/02’). For the lab test the resulting report is needed as input for the second visit. This is indicated by the arc leading from the ‘send report’ task to the ‘receive’ task of the second visit. At the multidisciplinary meeting, multiple patients are discussed individually. For this meeting, patients need to be registered via the ‘registration’ task. Finally, reports are sent out (task ‘send reports’). Note that Sue is registered for the meeting and that the resulting report is necessary as input for the second visit.

For patient ‘Anne’ a similar process is followed. However, note that Anne and Sue are discussed at the same multidisciplinary meeting. So, process instance ‘MDM 05/02’ operates at a different level of granularity (a group of patients rather than a single patient).

Clearly, the entire patient process should be seen as a cloud of standardized workflow fragments for which the ultimate selection of these fragments and the interactions between them is patient specific. Current workflow languages require that the complete workflow is described as one monolithic overarching workflow (van der Aalst, Mans, & Russell, 2009). Consequently, it is hard to describe such a cloud of loosely coupled workflow fragments and all the possible interactions between them.

For delivering the desired support, the Proclets framework (van der Aalst, Barthelmes, Ellis, & Wainer, 2000, 2001) provides an interesting means in order to model and execute patient processes. Proclets are lightweight interacting processes that can be used to divide complex entangled processes into simple fragments and, in doing so, place increased emphasis on interaction-related aspects of workflows. Moreover, fragments may reside at different levels of granularity.

Complete Article List

Search this Journal:
Reset
Open Access Articles: Forthcoming
Volume 9: 4 Issues (2019): Forthcoming, Available for Pre-Order
Volume 8: 4 Issues (2018)
Volume 7: 4 Issues (2017)
Volume 6: 4 Issues (2016)
Volume 5: 4 Issues (2015)
Volume 4: 4 Issues (2014)
Volume 3: 4 Issues (2013)
Volume 2: 4 Issues (2012)
Volume 1: 4 Issues (2011)
View Complete Journal Contents Listing