Why Rigid Process Management Technology Hampers
Computerized Support of Healthcare Processes?
Lucin´
eia H. Thom1, Manfred Reichert2, Cirano Iochpe1, Jos´
e Palazzo M. de Oliveira1
1Institute of Informatics – Federal University of Rio Grande do Sul (UFRGS)
91.501-970 – Porto Alegre – Brazil
2Institute of Database and Information Systems –Ulm University,
James-Franck-Ring – 89069 – Ulm– Germany
{lucineia,ciochpe,palazzo}@inf.ufrgs.br, [email protected]
Abstract. Healthcare processes are characterized by frequent changes, numer-
ous exceptions and complex deviations from the norm. Despite the increasing
adoption of process-aware healthcare information systems (PAHIS), there still
exist numerous issues related to the handling of exceptions in clinical processes
that are not effectively supported in contemporary PAHIS. This paper presents
preliminary results of a research whose goal is to get a deeper understanding of
clinical work practices and to better understand how IT process support should
look like for them. Altogether, adequate handling of failure and exceptions in
PAHIS, while still enabling a certain level of control and assistance to clinical
staff.
1. Introduction
A Process-aware Information Systems (PAIS) can be defined as a software that man-
ages and executes operational processes involving people, applications, and information
sources on the basis of process models [Russell 2000]. Considering computers as la-
bor and time saving, exceptions occur frequently in PAIS affecting the possible savings.
These exceptional situations, in turn, might influence the process execution, requiring de-
viations from its normal behavior [Reichert et al. 2009]. Generally, PAIS need to cope
with different kinds of exceptions, which are usually classified into expected and unex-
pected exceptions [Reichert et al. 2009], [Mour˜
ao and Antunes 2007], [Luo et al. 2000].
In this context, exception handling in business process automation can be considered as a
very complex and expensive task [Sadiq and Orlowska 2000]. Managing adverse events
or deviations from the normal flow and at the same time to assure a certain level of flexi-
bility has been always a challenge in business process automation. Healthcare processes,
in particular, are very complex, with more than 50 different types of medical specialties
and subspecialties interacting with each other [Lenz and Reichert 2006].
As example, consider the process for ordering drugs at the pharmacy of a clinic
(cf. Fig.1). This process includes the following sequential activities: a) first, information
about the patient is obtained; b) then, the dosage of the drugs to be applied is calculated;
c) the doctor must fill the prescription; d) the prescription is sent to the pharmacy; e) a
physician verifies the dosage; and f) the drugs are produced. This simple process must
be able to cope with several exceptions. For example, if the order does not arrive in
the pharmacy before 11am, the latter will be not able to produce the drugs. In this case
the clinic itself must produce the drugs (see 1]). In case some difficulty happens when
transporting the drugs the process to produce the drugs must be aborted (see 2] and 3]
respectively). The same kind of exception procedure applies when the health state of the
patient changes (e.g., the patient feels better) (see 4]).
Drugs ordering at the Clinic Pharmacy
a] Get information
about the patient
b] Calculate
dose
c] Fill the
prescription
d] Send to
Pharmacy
f] Pharmacy
produces the drugs
e] Check
drugs
Order arrives at the
clinic pharmacy after
11am
Hospital produce
the drugs
Transportation
contingencies
Wrong material
or dose
State of the
patient changes
Abort drugs
ordering process
1] 2] 3]
4]
Figure 1. Process to order drugs at the clinic pharmacy
In dynamic environments like healthcare, processes need to be continuously
adapted, but without affecting the production of expected outcomes. Recently, huge
efforts have been undertaken to make process management systems more flexible and
different approaches for providing flexible process support have emerged (e.g., adaptative
process management, late modeling, case handling, declarative processes, and data-driven
workflows) [Weber et al. 2009]. All these approaches enable some kind of process flexi-
bility, but they have not been applied in the clinic context yet [Lenz and Reichert 2006],
[Becker and Janiesch 2007]. In order to effectively provide IT process support for deal-
ing with exceptions during process execution it is important to understand their nature
and the way they are handled in practice. Otherwise, physicians, nurses and staff would
not accept the PAHIS.
This paper reports on the results of an analysis of a set of real-world healthcare
process models from a Woman’s hospital in Germany. With our analysis we try to give
insights into the reasons that lead to process deviations from the norm, into how these
deviations look like, and into the way process participants (e.g., nurses, physicians) cope
with these exceptional situations in real hospital practice. We believe that this kind of
analysis is fundamental for better understanding how next generation PAHIS should be
designed in order to meet flexibility requirements in clinical practices.
The remainder of this paper is organized as follows: Section 2 characterizes work
practices of real healthcare environments. Section 3 describes exceptions and exception
handling in real-world clinical processes. In particular we characterize kinds of events
which can cause exceptions based on a literature study and on several case studies we per-
formed in cooperation with a Woman Hospital in Germany. This characterization helps us
to better understand the nature of the exceptions, i.e. their causes and how process partic-
ipants deal with them. In this Section we further discuss results from the performed case
studies were we investigated how clinical staff deal with exceptions in real-world. Sec-
tion 4gives background information on how clinical processes are supported by the current
generation of workflow systems. Section 5 discusses limitations of existing PAHIS and
first insides on how we expect to provide more effective IT process support to cope with
real-world clinical exceptions. We conclude with a summary and outlook in Section 6.
2. Clinical Work Practice
In hospitals, the work of physicians and nurses is hampered by numerous organizational
as well as medical tasks. Medical procedures must be planned and prepared, appoint-
ments be made, and results be obtained and evaluated [Dadam et al. 1997]. Usually, in
the treatment process of a patient various, organizationally more or less separate units
are involved. For a patient treated in a department of internal medicine, for example, tests
and procedures at the laboratory and the radiology department become necessary. In addi-
tion, biological sample or the patient herself have to be transported, physicians from other
units may need to come and evaluate the patient, and reports have to be written, sent, and
interpreted. Thus, the cooperation between organizational units as well as the medical
personnel is a vital task, with repetitive but nevertheless non-trivial character. Healthcare
processes of different complexity and duration (up to several months) can be identified.
One can find organizational processes, like order entry and result reporting for radiology,
but also complex and long-running patient treatment processes like chemotherapy for in
as well as out-patients.
Physicians have to decide which interventions are convenient, necessary or which
are not (under the perspective of information necessity, costs and invasiveness) or which
are even dangerous because of possible side-effects or interactions. Many procedures
need preparatory procedures of various complexity levels. Before a surgery can take
place, for example, a patient has to undergo numerous preliminary examinations, each of
them requiring additional preparations. While some of them are known in advance, others
may have to be scheduled dynamically, depending on the individual patient characteristics
and her state of health. All tasks may have to be performed in certain orders, sometimes
with a given minimal or maximal time interval between them [Dadam et al. 1997].
Usually, physicians have to coordinate the tasks related to their patients manually,
taking into account all the dependencies existing between them. Changing a schedule is
not trivial and requires time-consuming communication. For some procedures, physicians
from various departments have to work together. So, coherent series of appointments have
to be arranged, and for each step actual and adequate information has to be provided. The
interrelated roles of physicians and nurses complicate the problem. They are responsi-
ble for many patients and they should provide an optimal treatment process for each of
them. Medical tasks are critical to patient care and even minor errors may have disastrous
consequences. The working situation is further burdened by frequent context switches.
Physicians often work at various sites of a hospital in different roles [Dadam et al. 1997].
Medical personnel must be free to react and is trained to do so. In an emergency
case, for example, physicians may collect information about a patient by phone and pro-
ceed with the process, without waiting for the (electronic) report to be written; i.e., ac-
tivities of a workflow may have to be dynamically skipped or moved in order to avoid
a mismatch between workflow and real-world process. A medical procedure may have
to be aborted if the patient’s health state gets worse or one of its prerequisites is not met.
Such dynamic deviations from the pre-planned process are frequent and form a key part of
process flexibility in healthcare. Any PAHIS which is employed to assist physicians and
nurses in their daily work, therefore, must allow them to gain complete initiative when-
ever needed. The PAHIS must be easy to handle, self-explaining and most important its
use in exceptional situations should be not more cumbersome and time-consuming than
simply handling the exception by a telephone call to the right doctor or nurse; otherwise
the system will not be accepted by the medical personnel.
3. Exceptions and Exception-Handling in Healthcare Processes
Based on a literature study and an analysis of clinical processes from a Woman Hospital
in Germany (cf. Section 3.1) we verified that exceptions can be caused by different kinds
of events such as medical errors, changes in patient status, organizational guidelines and
technical contingencies. In the following we discuss these causes in details.
•Exceptions Related to Medical Errors: Errors in medicine can cause severe
harm [Blaser et al. 2004]. Quality problems in medical discharge letters, for
example often constitute a source of subsequent medical errors. Missing infor-
mation and inconsistent or even wrong data in such letters can lead to wrong
diagnosis and thus to wrong patient treatments.
•Exceptions Related to the Patient: This category comprises specific circum-
stances involving the patient which can lead to deviations from the norm. For
example, changes in the health status or non-compliant patients (e.g., in case a
patient refuses to start or continue a treatment) might result in the abortion of a
treatment or eventually the starting of an alternative one.
•Exceptions Related to Organizational Guidelines: Organizational processes
(e.g., patient admission and patient discharge) generally follow some protocol. In
emergency cases, however a certain level of flexibility is needed. Usually, during
the admission of a patient at a hospital, he must provide personal information and
sign certain consent forms before the medical treatment starts. If the respective
patient is critically ill, however this information will be obtained from a family
member and the medical examination will start in parallel to the admission. Other
situation is when time constraints of the hospital or pharmacy are not followed.
Typical example include a lab analysis which is normally performed during the
morning but in an exceptional situation is performed in the afternoon.
•Exceptions Related to Technical Contingencies: Another source of exceptions
are technical problems that happen during healthcare processes. For example, a
lab machine might stop while performing a lab test, then the machine must be
restarted and the test performed from the beginning.
3.1. How Clinical Staff Deal with Exceptions in Real-World?
To get insights into how process participants (e.g., physicians, nurses, administrative
staffs) deal with exceptions in practice we analyzed 10 healthcare process models. These
models were collected at a Woman Hospital in Germany and are related to chemotherapy
treatment. The process models comprise between 4 and 9 activities including subpro-
cesses (cf. Table 1). Respective process models include several deviations from the norm.
For example an allergy detection which can lead to the interruption of a medical treatment
or the requesting of wrong doses to be produced in the hospital pharmacy.
Initially, we looked at the 10 processes and designed a new model of each of
them including respective exceptions in their context. Finally, we related each exception
with the events introduced in this Section. Here we present an example of a real clinical
process that was subject of our analysis. This process model comprises the normal flow
and respective deviations from the norm (see dashed line and corresponding activities in
Fig. 2).
Process name # of
activities
# of
ANDSplit
# of
ANDJoin
# of
XOR
# of
Subprocesses
Patient involved
€ {yes, no}
#Exceptions
Drugs ordering 6 1 1 0 1 No 3
Patientadmission 5 1 0 0 1 No 1
Patient discharge 4 1 0 0 1 No 0
Lab test 7 1 0 0 1 Yes 6
Lab analyses 6 0 1 1 0 No 0
Medical examination 9 0 0 1 0 Yes 6
Physicians brainstorm 8 2 0 0 0 No 0
Discharge letter 6 1 1 1 0 No 0
Final medical report 5 0 1 1 0 Yes 0
History of a chemotherapy treatment 2 1 1 1 3 yes 6
Table 1. Characterizing the analyzed process models
b] Prepare and
split sample d] Perform examination
with machine
c] Choose Lab
automated machine
f] Send
results
to the ward e] Analyses
results at the
clinical lab
g] Validate
results
End
End
a] Start:
Get sample from
the patient
Get a new
sample from the
patient
Is there
sample?
no
available
sample
available
sample Machine
stops
Sample gets lots, destroyed
or without identification during
transportation
Wrong material
got from the
patient
1
3
4
Printer is not working
or without paper
Print
document
Doctor tries to
convince the patient to
provide a new sample
5
Patient refuses
to give a new
sample
6
Urgent case
flag not
included
Is the analyses
really needed?
Ask for a
fee
Perform
analyses in
the next day
yes
2
no
Figure 2. Lab Test
3.2. On the Nature of Exceptions in Real-World Healthcare Processes
In this Section we present examples of semantic exceptions caused by medical errors, pa-
tient related exceptions, organizational exceptions and technical exceptions (cf. Table 2).
Notice that these examples consider the described events, which might cause exceptions
and our observation concerning the analysis of the 10 healthcare process models.
Patient Related Exceptions
Exception Nature Possible Reactions (PR)
E1: Change in the
patient's health state
The health state of the patient improves or become worse
during a chemotherapy treatment.
PR1: Interrupt the treatment and cancel
appointments
PR2: In case there are drugs being
produced, abort the production
PR3: The patient must spend the night in
the clinic
E2: Patient refuses to
start or continue a
treatment
After being informed about the risks of a treatment or while
a treatment is being performed the patient refuses it.
PR4: Apply PR 1 and PR 2
E3: Patient is allergic to
a medical drug
During a treatment a patient shows an allergy to specific
drugs or he gets another unexpected illness (e.g., a cold).
PR5: Apply PR 1 and PR 2
E4: Patient refuses to
provide blood sample
The patient might not agree in providing blood sample. PR6: The doctor must try to convince the
patient in providing a new sample
E5: Patient not available Occasionally, the patient might be unavailable when an
examination is requested. E.g. the patient might stay with
another examination unit.
PR7: Recall the patient and postpone the
requested examination
Exceptions Resulted from Technical Problems in the Clinic or Lab
E6: Transportation
problem with the
drugs
Problems with the transportation of the drugs PR8: In case of any contingency with the
transportation of the drugs the clinic is
authorized to produce the drugs
internally.
E7: Printer does not work It can happen that the results of the lab analysis cannot be
printed because of technical problems with the printer or
because the printer is out of paper
PR9: The document must be sent again.
E8: Lab machine stops The lab machines, accidently stops while an examination
performed
PR10: Restart the machine and perform the
examination from the beginning. In
case there is no one from the patient,
get new sample. If E4 occurs, apply
EH 6
E9: The sample or its
identification are lost
A sample gets lost or destroyed during its transportation. It
can also happen that the identification of the sample gets lost
PR11: A new sample is obtained from the
patient. Apply PR 6 in case E4
happens
Exceptions caused by Organizational Guidelines
E10:
No observance of
organizational
guidelines
The sample is generally extracted from the patient during the
morning. In emergency cases, the analysis can also be
performed in the afternoon. For that, the analysis request
must be indicated as urgent. Otherwise, the analysis will not
be performed within the same day of the request.
PR12: A fee will be asked in case the
analysis is urgent and must be
performed at the same day it was
requested
E11:
Patient visits the
physician without an
appointment
Before visiting the doctor the patient must get an
appointment before. In emergency cases, however, it might
be necessary to arrange an ad-hoc appointment with the
physician
PR13: Set an urgent appointment with the
doctor
E12:
Urgent information
required
It can happens that the radiologist needs the images urgently
to continue the treatment
PR14: Obtain the results of the examination
by phone in order to continue the
treatment
E13:
Starting of a
treatment in parallel
with patient
admission in the
clinic
In ordinary cases first the patient is admitted in the hospital
and afterwards the doctor starts treatment. However, in
emergency cases the patient cannot wait for the admission
and the treatment must be started immediately
PR15: Start the treatment in parallel to
patient admission
E14:
Wrong tasks are
performed or skipped
Certain radiological examination specific lab values must be
obtained (e.g., level of keratin)
PR16: not start the radiological examination
in case specific lab values are missing
Exceptions Resulted from Medical Errors
E15:
Wrong material or
wrong doses
It can happen that the wrong material (e.g., blood instead of
urine) is obtained from the patient or wrong doses are
requested to be produced
PR17: In case of wrong material a new
sample must be taken from the
patient. Apply PR 6 in case E4
happens
PR18: In case of wrong doses, apply PR 8
Table 2. Exceptions Relying to the Analyzed Process Models
4. Exception and Exception Handling in Computerized Healthcare Proceses
For healthcare processes, it is nearly impossible to pre-model all possible task sequences
and all exceptions in advance. For example, if a physician comes to the conclusion that an
additional medical test, which has not been considered in the process template, becomes
necessary in a given situation, the PAHIS must not prevent him to add the respective
activity to the process. In addition, it would be very important that PAHIS could au-
tomatically obtain clinical data (e.g. on-line information on patient such as temperature,
pressure). Otherwise, he would have to bypass the PAHIS causing the problem of missing
coordination and documentation.
In order to develop more dynamic healthcare PAHIS it is important to understand
the nature of exceptions in real-world healthcare processes. In Section 3 we gave ex-
amples of real-world processes comprising several exceptions. We could observe that
exceptions are frequent in healthcare processes such as the ones we analysed and PAHIS
must be flexible enough to support them. Moreover, PAHIS are complex to be devel-
oped because they involve both clinical and administrative tasks, large volume of data,
and large number of clinical staff. Changes in healthcare treatments, drugs, and protocols
may invalidate running instances, requiring reparative actions [Anyanwu et al. 2003]. For
example, when a patient arrives at the clinic, the first procedure is to perform his adminis-
trative admission, then the doctor performs initial examinations; after the doctor starts the
treatments. In emergency cases, however (e.g., risk of death) the administrative admission
can be performed in parallel with the medical one.
Currently PAHIS have focused on the creation, management and delivery of med-
ical documentation (e.g., CareFlowNet [Careflow 2009]), clinical data management, pa-
tient information management, and document acquisition and storage (e.g., SoftMed
[SoftMed 2002]). The METEOR system has been used to prototype and deploy sev-
eral healthcare applications. In particular, the system has a layer that permits consistent
realization of the dynamic change of instances [Anyanwu et al. 2003].
5. Discussion
Research on exceptions in computerized processes and on workflow management systems
has been going on for more than ten years. One of the first insights for contributions was
given by [Strong and Miller 1995] who analysed the causes of exceptions in information
systems and classified them according to specific perspectives such as: random event, er-
ror, and political system. In the random event perspective, exceptions are low-probability
events that are unexpected, nonrepetitive, and infrequent. The error perspective includes
exceptions caused by operational errors (mistakes made by people) and process design
errors (wrong procedures executed by computers) and errors due to dynamic organiza-
tions. The later implies the development of routines for recognizing and handling cases
in the organizational environment that computers cannot process correctly. The political
system perspective explains the persistence of some exceptions, especially in information
processes that cross organizational boundaries, e.g., order fulfillment starts in sales and
continues into manufacturing.
[Klein et al. 2000] presents an approach to anticipate the ways a process may fail
and then to define how these failures can be detected or avoided. The process model is
compared against a taxonomy of elementary process elements and respective failures re-
lated to these elements (e.g. activities, resources, goals and assumptions). For diagnosing
exception causes an heuristic classification is used. Exception types (e.g. design error,
resource unavailability) are arranged into a taxonomy ranging from highly general failure
at the top to more specific ones at the bottom.
According to [Sadiq and Orlowska 2000] the majority of exceptions in business
processes can be anticipated. Though they are not exceptions in the real sense, they still
represent deviations from the normal process. The main characteristic that distinguishes
these exceptions from normal process logic is infrequency. In this context, exceptions are
driven by events including temporal events, resource violations, and external notification.
In [Russell et al. 2006] exceptions are grouped into classes which are related by
similarities that they possess in terms of the conditions under which they might occur.
Exception handlers are then programmatic procedures to resolve the effects of specific
events as they are detected. The authors investigate the issues that may lead to exceptions
during workflow execution and the various ways in which they can be addressed. This
provides the basis for a classification framework for workflow exception handling which
is subsequently defined in the form of patterns (e.g., work item failure, deadline expiry,
external trigger).
Mour˜
ao [Mour˜
ao and Antunes 2007] classify exceptions as expected and unex-
pected ones. Even though expected exceptions do not correspond to the normal process
behavior they can be foreseen at the process modeling phase. Normally, they are ex-
cluded from the process model to reduce complexity. Unexpected exceptions, however,
cannot be predicted during process modeling. They correspond to unstructured activities
and often require human intervention to be handled. The authors propose a framework
targeting at the support of the unstructured activities necessary to handle unexpected ex-
ceptions. They distinguish four functions in exception handling: 1) exception detection;
2) situation diagnosis; 3) exception recovery; and 4) monitoring actions.
Finally, an approach enabling automation of exception handling at a high level
of abstraction is presented in [Rinderle and Reichert 2006]. The approach includes a for-
mal framework for data-centered exception handling, i.e., process adaptations necessary
to deal with exceptional situations are carried out by modifying data structures (e.g., a
delivery list of goods). This data change is then propagated to the running process by
the concept of data-driven expansion, and not by directly applying changes on the control
flow schema of the concerned process instance. In order to automatically derive exception
handling strategies at a semantically high level the authors integrate and exploit process
information (e.g., data about physical objects).
In our approach we focus on exceptions in the context of healthcare processes.
Exceptions are considered as deviations from the normal flow and are mainly related to
the semantics of the process (e.g., the starting of a medical treatment in parallel with the
patient admission in the clinic). As this kind of exceptions are infrequent they are usually
not explicitly included in the process model. Moreover, in order to include them we need
more sophisticated and flexible systems. Therefore, our idea is to study these exceptions,
their nature and the way how user handle them. To investigate further ways to effectively
implement them in PAHIS.
6. Summary and outlook
This paper showed that it appears to be suitable to improve IT process support for health-
care processes by exploiting the features of next generation process management technol-
ogy. Recently, large efforts have been undertaken to make process management systems
more flexible and different approaches and paradigms for providing flexible process sup-
port have emerged. Examples include adaptive process management, late modeling, case
handling, declarative processes, and data-driven workflows. All these approaches enable
some kind of process flexibility, but have not yet been applied in the healthcare context.
The major contributions of this paper are the results from an empirical study per-
formed within a Woman Hospital in Germany. Basically we analyzed several process
models related to the chemotherapy treatment. These processes models comprise several
exceptions which were reported by physicians of the hospital during their design. We
investigated the nature of these exceptions and how users deal with them. Our goal is
to relate them to clinic exception handling patterns. In this context we presented exam-
ples of exceptions based on different aspects such as organizational guidelines, technical
contingencies and changes in the patient health state.
In the future work we plan to analyse additional process models in order to identify
more recurrent exceptions and to relate them with existent and new patterns. We also
intend to investigate deeper how to provide IT process support for these exceptions.
7. Acknowledgments
We are very grateful for the Brazilian Coordination for the Improvement of Graduated
Students (CAPES) and the Institute of Database and Information Systems (DBIS) of the
University of Ulm (Germany).
References
Anyanwu, K., Sheth, A. P., Cardoso, J., Miller, J. A., and Kochut, K. (2003). Healthcare
enterprise process development and integration. Journal of Research and Practice in
Information Technology, 35(2):83–98.
Becker, J. and Janiesch, C. (2007). Restrictions in process design: A case study on
workflows in healthcare. In ter Hofstede, A. H. M., Benatallah, B., and Paik, H.-
Y., editors, Business Process Management Workshops, volume 4928 of Lecture Notes
in Computer Science, pages 323–334. Springer.
Blaser, R., Schnabel, M., Mann, D., Jancke, P., Kuhn, K. A., and Lenz, R. (2004). Poten-
tial prevention of medical errors in casualty surgery by using information technology.
In SAC ’04: Proceedings of the 2004 ACM symposium on Applied computing, pages
285–290, New York, NY, USA. ACM.
Careflow (2009). Health care it integration. http://www.careflow.com/index.html.
Dadam, P., Reichert, M., and Kuhn, K. (1997). Clinical workflows - the killer applica-
tion for process-oriented information systems? In 4th International Conference on
Business Information Systems - BIS 2000, pages 36–59.
Klein, M., Dellarocas, C., Klein, D. M., and Dellarocas, P. C. (2000). A knowledge-based
approach to handling exceptions in workflow systems. Journal of Computer-Supported
Collaborative Work. Special Issue on Adaptive Workflow Systems, 2000:399–412.
Lenz, R. and Reichert, M. (2006). IT support for healthcare processes – premises, chal-
lenges, perspectives. Data and Knowledge Engineering, 61(01):39–58.
Luo, Z., Sheth, A., Kochut, K., and Miller, J. (2000). Exception handling in workflow
systems. Applied Intelligence, 13:125–147.
Mour˜
ao, H. and Antunes, P. (2007). Supporting effective unexpected exceptions handling
in workflow management systems. In Proceedings of the 2007 ACM symposium on
Applied computing, pages 1242–1249, New York. ACM.
Reichert, M., Rinderle-Ma, S., and Dadam, P. (2009). Flexibility in process-aware in-
formation systems. LNCS Transactions on Petri Nets and Other Models of Concur-
rency (ToPNoC), Special Issue on Concurrency in Process-aware Information Systems,
2:115–135. Springer.
Rinderle, S. and Reichert, M. (2006). Data-driven process control and exception handling
in process management systems. In Proc. CAiSE 2006, volume 4001 of Lecture Notes
in Computer Science, pages 273–287. Springer.
Russell, N. (2000). Using information technology to reduce rates of medication errors in
hospitals. BMJ, 320:788–791.
Russell, N., van der Aalst, W. M. P., and Arthur (2006). Exception handling patterns in
process-aware information systems. Technical report, BPMcenter.org.
Sadiq, S. W. and Orlowska, M. E. (2000). On capturing exceptions in workflow process
models. In Proceedings of the 4th International Conference on Business Information
Systems, pages 3–19, Great Britain. Springer.
SoftMed (2002). Softmed homepage. http://www.softmed.com.
Strong, D. M. and Miller, S. M. (1995). Exceptions and exception handling in computer-
ized information processes. ACM Transaction Information Systems, 13(2):206–233.
Weber, B., Sadiq, S. W., and Reichert, M. (2009). Beyond rigidity - dynamic process
lifecycle support. Computer Science - R&D, 23(2):47–65.
