IT support for healthcare processes
– premises, challenges, perspectives
Richard Lenz
*
, Manfred Reichert
Institute for Medical Informatics, University of Marburg, Bunsenstrasse 3, D-35037 Marburg, Germany
Information Systems Group, University of Twente, The Netherlands
Received 11 April 2006; received in revised form 11 April 2006; accepted 11 April 2006
Available online 24 May 2006
Abstract
Healthcare processes require the cooperation of different organizational units and medical disciplines. In such an envi-
ronment optimal process support becomes crucial. Though healthcare processes frequently change, and therefore the sep-
aration of the flow logic from the application code seems to be promising, workflow technology has not yet been broadly
used in healthcare environments. In this paper we elaborate both the potential and the essential limitations of IT support
for healthcare processes. We identify different levels of process support in healthcare, and distinguish between organiza-
tional processes and the medical treatment process. To recognize the limitations of IT support we adopt a broad
socio-technical perspective based on scientific literature and personal experience. Despite of the limitations we identified,
undeniably, IT has a huge potential to improve healthcare quality which has not been explored by current IT solutions. In
particular, we indicate how advanced process management technology can improve IT support for healthcare processes.
Ó2006 Elsevier B.V. All rights reserved.
Keywords: Healthcare processes; Medical guidelines; Medical decision support; Workflow management; Adaptive information systems
1. Introduction
Process-oriented information systems have been demanded for more than 20 years [24] and terms like con-
tinuity of care have even been discussed for more than 50 years. Yet, healthcare organizations are still char-
acterized by an increasing number of medical disciplines and specialized departments. Healthcare processes
require interdisciplinary cooperation and coordination. The recent trend towards healthcare networks and
integrated care even increases the need to effectively support interdisciplinary cooperation along with the
patient treatment process.
Healthcare processes heavily depend on both information and knowledge. Thus, information management
plays an important role in this context. Numerous studies have demonstrated positive effects when using IT
0169-023X/$ - see front matter Ó2006 Elsevier B.V. All rights reserved.
doi:10.1016/j.datak.2006.04.007
*
Corresponding author. Tel.: +49 6421 28 66205; fax: +49 6421 286 63599.
Data & Knowledge Engineering 61 (2007) 39–58
www.elsevier.com/locate/datak
systems in healthcare. In particular the preventability of adverse events in medicine has been in the focus of
recent studies. Adverse events are defined as unintended injuries caused by medical management rather than
the disease process [83]. It turned out that insufficient communication and missing information are among the
major factors contributing to adverse events in medicine [7,13,14,34,87,88]. IT support for healthcare pro-
cesses therefore has the potential to significantly reduce the rate of adverse events by selectively providing
accurate and timely information at the point of care [45]. Yet, there is a discrepancy between the potential
and the actual usage of IT in healthcare. A recent IOM
1
report even states that there is an ‘‘absence of real
progress towards applying advances in information technology to improve administrative and clinical pro-
cesses’’ [53].
Why is it so difficult to build IT systems that support a seamless flow of information along healthcare pro-
cesses? To find appropriate answers to this question it is important to understand the characteristics of health-
care processes. In current literature, however, there is a lot of confusion in this context stemming from
different, inconsistent and incomplete perspectives on what healthcare processes are. To identify the core chal-
lenges for IT support as well as the shortcomings of current IT solutions we have to distinguish between orga-
nizational processes (e.g., medical order entry and result reporting) and the medical treatment process (e.g.,
diagnostic and therapeutic procedures to be carried out for a particular patient). While organizational process
patterns shall help to coordinate interoperating healthcare professionals and organizational units (e.g., han-
dling of a medical order and result reporting), treatment processes are linked to the patient. Different chal-
lenges arise in connection with these different levels.
As different organizational units often have their own specialized IT applications, one of the main chal-
lenges for the IT support of organizational processes concerns application integration. We summarize how
existing integration standards contribute to process support by providing stable generic process patterns
and why there is still a large potential for workflow technology.
The specific patient treatment process, in turn, depends on medical knowledge and case specific decisions.
Decisions are made by interpreting patient specific data according to medical knowledge. This decision pro-
cess is very complex, as medical knowledge includes medical guidelines of various kinds and evidence levels,
as well as individual experience of physicians. Moreover, medical knowledge continuously evolves over time.
It is generally agreed that medical decision making cannot be automated. Yet, the patient treatment process
can be improved by selectively providing medical knowledge in the context of this process. The problem is to
offer current knowledge, to only offer relevant knowledge according to the current context, to include the
underlying evidence, and to support all of this in a way which seamlessly integrates with the physicians work
practice. Current IT solutions are far away from this perspective for various reasons. One of these reasons is
the lack of flexibility of current solutions, which is needed to cope with the evolving nature of medical
knowledge. Thus it appears to be suitable to improve IT support for healthcare processes by exploiting
the features of adaptive process management systems. We discuss the potential offered by next generation
process management technology in this context. We sketch how it can contribute to provide full lifecycle
support for treatment processes, but we also show which challenges, problems and essential limitations
remain.
Section 2deals with organizational processes in healthcare. It describes how traditional healthcare informa-
tion systems support organizational process patterns, how standards contribute to integration, and why work-
flow-based support is still needed. By contrast Section 3focuses on the medical treatment process and its basic
characteristics. We show how treatment processes are influenced by medical knowledge and patient related
information, and how current achievements in medical decision support contribute to improve healthcare
quality. A practical example is given in Section 4. Section 5takes a more visionary approach. It discusses
implications for future process-oriented IT architectures in healthcare. In particular, we show how adaptive
process management technology may contribute to improve IT support for healthcare processes in the
long term, and which challenges still need to be addressed. The paper closes with a summary and outlook
in Section 6.
1
Institute of Medicine (IOM) of the National Academies (www.iom.edu).
40 R. Lenz, M. Reichert / Data & Knowledge Engineering 61 (2007) 39–58
2. Organizational processes in healthcare
In this section we focus on the support of organizational procedures in hospitals, and exclude issues related
to the patient treatment process and the medical knowledge influencing it. We motivate the need for organi-
zational process support in hospitals, give a typical example of a cross-departmental healthcare process, and
show how IT support for such cooperative processes is currently realized in practice. Due to the fragmentation
of application functions and medical data in hospitals we cannot deal with these issues without considering
application integration as well. In recent years, a number of integration and interoperability standards have
emerged in healthcare, which provide the basis for the IT-based support of organizational processes in health-
care. Based on these standards and on vendor-independent ‘‘reference workflows’’ several generic process pat-
terns (e.g., handling of an imaging encounter) have been suggested. We sketch characteristics of these generic
process patterns and discuss to which extent they enable organizational process support. We further look at
limitations of this concept which emerge when site-specific adaptations of process implementations become
necessary.
2.1. Why hospitals crave for IT support of organizational processes?
In hospitals the work of physicians, nurses, and technicians is significantly burdened by organizational
tasks. Medical procedures (e.g., lab tests, imaging encounters) have to be planned and prepared, appointments
with different service providers be scheduled, specimen or the patients themselves be transported, visits of phy-
sicians from other departments be arranged, and reports be written, transmitted, and evaluated. Thus, the
cooperation between people from different departments is a vital task with repetitive, but non-trivial character.
Usually, organizational tasks have to be coordinated manually by the clinical personnel necessitating, for
example, time-consuming phone calls and documentation steps. In clinical practice, this often leads to orga-
nizational problems and to a high administrative load of clinicians. As a consequence, many errors result and
unwanted effects occur. Patients may have to wait, because resources (e.g., physicians, rooms, technical equip-
ment) are not available (e.g., due to bad planning). Medical procedures may become impossible to perform if
information is missing, preparations are omitted, or a preparatory procedure has been postponed, canceled or
requires latency time. Subsequent appointments may then have to be re-scheduled, again resulting in numer-
ous phone-calls and time losses. For all these reasons hospital stays are often longer than required, and costs
or even invasiveness of patient treatment are unnecessary high. Clinical personnel is aware of these problems
and process-aware information systems coordinating organizational tasks and providing information at the
point of care would be highly welcome. In an increasing way it is being understood, that the correlation
between medicine, organization and information is high, and that today’s organizational structures and IT
systems offer only sub-optimal support.
2.2. Example of an organizational process
A typical organizational process for medical order entry and result reporting, which is used to coordinate
the inter-departmental communication between a ward (ambulatory setting) and the radiology unit, is illus-
trated in Fig. 1. The depicted process is not tailored to a specific medical pathway (cf. Section 3), but shows
an organizational procedure of the hospital. In our example an order is placed by a nurse or a physician at the
ward or at an ambulatory setting. In the most general case the indication is checked in the radiology depart-
ment and depending on the result the order placer is informed whether the request has been rejected or sched-
uled. The actual radiological examination and the corresponding documentation is done in the examination
room. The radiology report is generated afterwards. If necessary some iterations for corrections are passed
until the experienced radiologist can validate the report by his signature. The final report is sent back to
the order placer.
Procedures like the one described constitute a part of the fundamental processes of clinical practice and
mainly capture the organizational knowledge necessary to coordinate the healthcare process among different
people and organizational units; i.e., focus is on the support of core organizational processes. Though these
R. Lenz, M. Reichert / Data & Knowledge Engineering 61 (2007) 39–58 41
processes evolve over time, they remain basically the same for longer periods of time. As we will see in Section
3this constitutes a significant difference when compared to patient treatment processes.
2.3. IT support for organizational processes
How can organizational processes in healthcare be supported by IT? As indicated above the computerized
support of organizational processes is usually closely related to application integration. The reason is that the
architecture of typical hospital information systems is characterized by many different departmental systems,
which have usually been optimized for the support of different medical disciplines (e.g. radiology, cardiology,
or pathology), but not for cross-departmental processes. The need to consolidate the data produced by these
ancillary systems to a global patient-centered view and to support the cross-departmental processes has moti-
vated the development of standards for data and message interchange in healthcare. These standards also play
an important role when not only cross-departmental but also cross-organizational healthcare processes are to
be supported. Today, HL7 is the leading standard for systems integration in healthcare. The name ‘‘Health
Level 7’’ refers to the application layer in the OSI reference model [75].
HL7 is a message-based standard for the exchange of data among hospital applications. The standard
defines which data items are to be interchanged when certain clinical trigger events occur (e.g., related to
the admission, discharge, or transfer of a patient). Since Version 2.3 (1997) the standard has covered trigger
events for patient administration, patient accounting, order entry, medical information management, clinical
observation data, patient and resource scheduling, and others. The standard has been continuously extended
and newly arising topics, such as the integration of genomic data in Electronic Health Records, are handled in
special interest groups (SIGs). Yet, the HL7 trigger events are intended to support standard communication
patterns that will occur in any healthcare organization in basically the same way. Today’s commercially avail-
able healthcare software usually only covers a relatively small portion of HL7, implementing those commu-
nication patterns that are typically requested as essential basis for interconnecting disparate applications.
Besides HL7 numerous additional standards exist that need to be considered when integrating different kinds
of data in the medical domain. Most notably, the DICOM standard (Digital Imaging and Communications in
Medicine) has to be mentioned (cf. [46]), which is well accepted for the exchange of medical image data, and
partly overlaps in its data definitions with HL7.
order
preparation
order
entry
indication
check
acknowledge
reject
scheduling
check
order
transfer
patient
medical
examination
documentation reporting
validity
check validation
print
report
sign printed
report
order rejected
order accepted
order
rejected
else
WARD /
AMBULATORY SETTING
RADIOLOGY
revision
required else
START
EXIT
radiology entrance
radiology entrance
radiology entrance
examination
room
examination
room
phys, room
phys, room phys, room
radiology
entrance
timer
timer
medical order appointment ack /
reject ack
receive
report
report
Fig. 1. Example of an organizational process (order entry and result reporting).
42 R. Lenz, M. Reichert / Data & Knowledge Engineering 61 (2007) 39–58
Despite well accepted standards for data integration like HL7 and DICOM, healthcare applications are still
far from plug and play compatibility (which is essential for the realization of process-oriented healthcare infor-
mation systems). One reason for this is that existing standards do not address functional integration issues
sufficiently. By functional integration we refer to the meaningful cooperation of functions of different software
components. Uncontrolled data redundancy is often the result of an insufficient functional integration of dis-
parate systems. Autonomously developed systems often overlap in their functionality, partly providing the
same or only slightly differing functionality. This aggravates integration even if the systems are already based
on common ontologies [38]. In order to avoid these difficulties common application frameworks are required
which serve as a reference for programmers to create functionally compatible software components. Require-
ments for an application framework directed towards open systems in the healthcare domain are described in
[40]. In general such a framework must provide specifications of interfaces and interaction protocols which are
needed for embedding a software component into a system of cooperating components.
The best example for such a standard in the healthcare domain is the IHE initiative (‘‘Integrating the
Healthcare Enterprise’’) [82]. IHE does not develop new standards for data interchange but specifies so called
‘‘integration profiles’’ on the basis of HL7 and DICOM (see above). Thereby ‘‘actors’’ and ‘‘transactions’’ are
defined independently from any specific software product. An integration profile specifies how different actors
interact via IHE transactions in order to perform a special task. These integration profiles serve as a semantic
reference for application programmers, so that they can build software products that can be functionally inte-
grated into an IHE conformant application framework. IHE is based on HL7 Version 2 and it has already
been increasingly adopted by vendors. The core integration profile of IHE is called ‘‘Scheduled Workflow’’.
It establishes a seamless flow of information in a typical imaging encounter (e.g., to generate an X-ray for
a patient) by precisely specifying the actors and transactions involved in the process of image acquisition.
By fixing the required workflow steps and the corresponding transactions, IHE ensures the consistency of
patient information from registration through ordering, scheduling, imaging acquisition, storage, and viewing.
This consistency is also important for subsequent workflow steps, such as reporting. However, this kind of
process support has nothing to do with the traditional idea of workflow systems – to separate the flow of con-
trol from application logic in order to keep the workflow maintainable [17,21,42]. The idea of these standards
is to establish stable generic process patterns that help to integrate autonomously developed IT components.
Existing implementations are reduced to a minimum and do not provide process management functions (e.g.,
for process monitoring). Thus, this approach is only applicable to very few organizational procedures, whereas
in most cases we need facilities to adapt process implementation to the respective healthcare organization.
3. The medical treatment process
In this section we describe basic characteristics of the medical treatment process and explain how it is influ-
enced by medical knowledge and patient related information. We consider the understanding of the nature of
the medical treatment process and its parameters as fundamental for the ability to estimate the potential of IT
to improve process quality.
3.1. Medical decision making
The medical treatment process is often denoted as diagnostic–therapeutic cycle (cf. Fig. 2) comprising obser-
vation, reasoning, and action. Each pass of this cycle is aimed at decreasing the uncertainty about the patient’s
disease or the actual state of the disease process [77]. Thus, the observation stage always starts with the patient
history (if available) and proceeds with diagnostic procedures which are selected based on available informa-
tion. It is the job of an (Electronic)Patient Record to assist healthcare personnel in making informed decisions.
Consequently, the system should present relevant information at the time of data acquisition and at the time of
order entry. Thereby, an important question to be answered is how to determine what is relevant. Availability
of relevant information is a precondition for medical decisions – medical knowledge guides these decisions.
Medical knowledge, however, is not limited to what is found in medical textbooks. Moreover, medical
knowledge evolves over time. In some cases there are systematic literature reviews that describe evidence so
compelling that the right thing to do is clear. Such strong evidence, however, is rare in medicine. Even if
R. Lenz, M. Reichert / Data & Knowledge Engineering 61 (2007) 39–58 43
evidence is available, often enough it is hidden in the results of some clinical study and not readily applicable
in a clinical context. And even if the evidence has been considered in reviews and found the way into consented
guidelines, existing published recommendations for medical treatment need frequent revision as new evidence
occurs. Following the principles of Evidence based medicine (EBM) physicians are required to formulate ques-
tions based on patients’ problems, search the literature for answers, evaluate the evidence for its validity and
usefulness, and finally apply the information to patients [26,29]. Of course, clinicians will typically not have the
time to do such research while the patient is in the office; so, literature search will necessarily take place offline.
On this basis EBM is nearly impossible to practice in everyday clinical care [61,67]. This raises the question
whether medical knowledge can be provided in a more compact and applicable form and whether information
technology can improve the practice of EBM by using such condensed knowledge? Medical guidelines are
aimed at supporting clinicians in interpreting existing evidence by providing recommendations for decision
making based on literature reviews and existing evidence.
EBM and guidelines are not aimed at establishing a ‘‘cookbook medicine’’ as many fear [61,76]. Instead, it
means that physicians must know what they are doing as they have to individually estimate patients’ chances
and risks. Moreover, they have to ensure that their decisions are consistent with the patients’ values, which is
even more challenging [61]. Thus, physicians are not supposed to blindly follow some step by step treatment
plan. Consequently, IT support cannot mean to enforce predefined step by step treatment plans, instead pro-
cess support should contribute to provide the best available evidence to the physician in a readily understand-
able and applicable way. Such explicit medical knowledge is necessary but not sufficient for medical decision
making. A large part of medical knowledge is not explicit but tacit [89], and tacit knowledge heavily influences
information needs by care providers as well as the course of the care process [73,74].
According to Nonaka and Takeuchi [50] knowledge is created and expanded through social interaction
between tacit and explicit knowledge. This process, called ‘‘knowledge conversion’’, is a social process between
individuals, rather than a process within an individual. Stefanelli describes this process of knowledge creation
in the context of healthcare organizations [73]. In order to make medical knowledge broadly available, medical
experts need to externalize their tacit knowledge. Thus, improving healthcare processes has a lot to do with
stimulating and managing the knowledge conversion processes. As IT systems can only handle explicit medical
knowledge we subsequently concentrate on this part, knowing that we can never automate decision making,
because we will never be able to have the full picture at our hands.
3.2. Levels of explicit medical knowledge
Supporting the healthcare process by bringing explicit medical knowledge to the point of care is closely
related to developing and implementing medical practice guidelines. The MeSH
2
dictionary defines medical
diagnostic
treatment
(uncertain)
patient-related
information
decision
making
therapeutic
treatment
medical
knowledge
data data
interpretation interpretation
patient
diagnostic
cycle
therapeutic
cycle
Fig. 2. Diagnostic–therapeutic cycle.
2
MeSH: Medical Subject Headings. Thesaurus and controlled vocabulary used for indexing the MEDLINE database of medical
literature provided by the National Library of Medicine (NLM).
44 R. Lenz, M. Reichert / Data & Knowledge Engineering 61 (2007) 39–58
practice guidelines as ‘‘work consisting of a set of directions or principles to assist the health care practitioner
with patient care decisions about appropriate diagnostic, therapeutic, or other clinical procedures for specific
clinical circumstances’’. Guidelines are aimed at an evidence-based and economically reasonable medical treat-
ment process, and at improving outcomes and decreasing the undesired variation of healthcare quality [25].
Developing guidelines is essentially a consensus process among medical experts. Yet, there is a gap between
the information contained in published clinical guidelines and the knowledge and information that are neces-
sary to implement them [25,72]. Methods for closing this gap by using information technology have been in
the focus of medical informatics research for decades (e.g. [6,43,72]).
Medical pathways can be used as a basis for implementing guidelines [70] and sometimes they are confused
with guidelines. In contrast to guidelines, pathways are always related to a concrete setting and include a time
component: pathways are planned process patterns that are aimed at improving process quality and resource
usage. Since pathways are site-specific they do also not constitute standardized generic processes like those
described within the IHE integration profiles (cf. Section 2). Further, pathways need a consensus process.
They must be tailored to local and individual circumstances, which requires a cooperative initiative of clinical
experts, process participants, and managers. If restricted to a clinical setting we may also talk about clinical
pathways instead of medical pathways. Pathways can be used as a platform to implement guidelines, e.g. by
routinely collecting information required by a guideline. Selecting a guideline for implementation also
requires an agreement of healthcare professionals and patients, because there are different kinds of guidelines
with different origins and goals, and sometimes even conflicting recommendations. Likewise, to improve a
patient treatment process across organizational borders, consensus on common practices is required in the
first place.
Once this consensus is achieved, the next question is how to implement it in practice. To be effective, a
guideline must be easily accessible. Ideally, it should be embedded into the clinical work practice, and the phy-
sician should not need to explicitly look it up. Otherwise, there is always a risk of overlooking important infor-
mation while the patient is in the office. Previous work has primarily demonstrated a positive influence of
computer-generated alerts and reminders [22,31,71], which can be integrated into clinical work practice.
Recent research indicates that this is exactly the major difficulty with implementing more complex multi-step
guidelines: how to integrate them into the clinical workflow [43,71,90]?
The influence of different levels of explicit medical knowledge on the patient care process is illustrated in
Fig. 3. In this figure domain-specific medical knowledge (available in medical literature and consented in var-
ious kinds of guidelines) is distinguished from site-specific treatment plans. We use the term ‘‘treatment plan’’
as a synonym for clinical and medical pathways, in order to underline its site-specific character. Note that a
treatment plan may consider many different guidelines, and that a guideline may be considered within multiple
treatment plans. In addition, medical knowledge stemming from general guideline recommendations may also
be reflected in alerts and reminders, which are independent from treatment plans: an alert (e.g., ‘‘Lab alert’’ for
values that are out of bounds or for data values that are about to develop into dangerous areas) requires some
kind of notification system to inform the responsible physician. Reminders can be used to inform the person
who enters data instantaneously if data are entered which are not plausible or if expected data entries have not
been made.
A treatment plan comprises multiple diagnostic or therapeutic steps (procedures). Instances of a treatment
plan need to be adapted to the specific needs of an individual patient (individual treatment plan). The actual
treatment process may still deviate from the individual treatment plan. Consequently, an IT system supporting
the medical treatment process will have to take into account that treatment plans need to be handled in an
extremely flexible way. A simplified illustration of the different levels of deviation is shown in Fig. 4.
We illustrate the different levels of deviation indicated in Fig. 4 by the following example: consider a patient
with suspicion of proximal femoral fracture.
3
There is no guideline for femoral fracture diagnosis, as most
fractures of the proximal femur are easily diagnosed by conventional radiography. However, medical litera-
ture does suggest to use magnetic resonance imaging (MRI) to help reach a diagnosis when the images are
3
The femur is the bone between the hip and the knee. The proximal femur is the part near the hip. Proximal femoral fractures include a
broad group of common fractures of the femoral head and neck typically occurring in osteoporotic females.
R. Lenz, M. Reichert / Data & Knowledge Engineering 61 (2007) 39–58 45
judged to be negative or equivocal and a clinical suspicion of fracture persists [23]. A site-specific medical path-
way can only consider this recommendation if an MRI is actually available. Let us assume there is an MRI
and the site-specific treatment plan recommends MRI diagnosis if conventional radiography has left any
doubts; the individual treatment plan might still deviate from this recommendation because the patient might
have an implanted pacemaker (PM) which might be negatively influenced by the MRI. In addition, even if
treatment plans are individualized it must be possible to allow the actual treatment process to deviate from
this individual plan. For example, it might not have been recognized that there is a contraindication for
MRI when the plan was individually adapted.
Fig. 3. Influence of explicit medical knowledge on the healthcare process.
domain-specific
knowledge
site-specific
knowledge
individual patient treatment plan
actual patient treatment process
medical practice
guidelines
medical
pathways
require consensus
among medical experts
(and scientific evidence)
require consensus
among cooperating
healthcare professionals
may deviate from
medical pathway
may deviate from
individual treatment plan
Fig. 4. Deviation of individual treatment from guidelines and treatment plans.
46 R. Lenz, M. Reichert / Data & Knowledge Engineering 61 (2007) 39–58
So far we have primarily distinguished between organizational processes and the medical treatment process.
In addition we have to distinguish between general site independent recommendations and site-specific adap-
tations. Fig. 5 summarizes the resulting process categories according to these distinctions.
Supporting organizational processes by the use of IT is helpful, as organizational deficits are an important
cause for Adverse Events (e.g. [79,12]), but it is only a part of the potential of IT to improve healthcare pro-
cesses. Supporting the complex process of medical decision making is much more challenging. Subsequently
we briefly summarize what has been done so far in this context.
3.3. Achievements in decision support
Medical decision making must integrate best available evidence with personal experience and patients val-
ues. Information technology can support such decision making in various ways. Some documented examples
are:
(1) Computer systems can contribute to improve different aspects of data quality, e.g. completeness [28],
timeliness [78], etc. thereby improving the information basis for decision making.
(2) Computer systems can contribute to better monitor the current status of a patient, e.g. by presenting
patient data in a more coherent way, by providing optimized views to patient data for dedicated pur-
poses, or by generating alerts if some parameter or a combination of parameters is developing into dan-
gerous areas (e.g. [4]).
(3) Computer systems can detect mismatches between existing guidelines and the actual patient treatment
process, e.g. contraindications for some planned procedure.
(4) Computer Systems can generate reminders to ensure that planned actions are not forgotten [44].
4
(5) Computer systems can calculate drug doses from previously entered data (e.g. age, weight, gender),
check compatibility with other medications, and check compatibility with allergies [3,49]. Computerized
Physician Order Entry systems (CPOE) are estimated to reduce medication errors up to 81% [36].
(6) Computer systems can calculate disease probabilities [27].
All these techniques require the computer to be able to make use of the patient’s clinical data according to
current medical knowledge. The first obstacle to achieving this is to represent medical knowledge in a com-
puter-interpretable form, i.e., translating narrative guidelines into equivalent ones that use coded data. This
is cumbersome and also bares the risk of distorting the intent of the original guideline. The second obstacle
is to keep medical knowledge maintainable. Thus, separating this knowledge from computer applications is
desirable.
To overcome such problems numerous models have been developed to formally represent medical guide-
lines and medical knowledge (e.g., Arden Syntax [30],GLIF[52,54]). Recent surveys have compared these
approaches [18,55,19]. One of the central goals is to define standard representation formats for medical knowl-
edge in order to be able to share guidelines among different information systems in different organizations. In
practice, however, it turned out that the main obstacle to be solved here is – once again – an integration prob-
medical pathwaysorganization-specific
workflows
site-specific
adaptation
medical guidelinesgeneric process patterns
(e.g., IHE integration profiles)
site-
independent
patient
treatment process
organizational
processes
Fig. 5. Categorization of healthcare processes.
4
Note that computer systems should not be used to enforce some pre-planned action!
R. Lenz, M. Reichert / Data & Knowledge Engineering 61 (2007) 39–58 47
lem: the data definitions in pre-defined formal guidelines may not map to the data available in an existing elec-
tronic health record system [56]. Typically, operational systems have to be modified and extended in order to
acquire the necessary information needed for guideline implementation. Few guidelines have been successfully
implemented into real clinical settings by using these systems and predefined formally specified guidelines.
Recent research has recognized these difficulties and focuses on process models for transforming textbased
guidelines into clinical practice [72]. Standard formats for guideline representation do have their place in
guideline implementation, but the integration problems to be solved are a matter of semantics rather than
format.
Guideline implementation requires a high level of data integration, because computerized reminders typi-
cally refer to both type and instance level semantics. More complex guidelines also need to refer to a formally
established context comprising status information. The challenge to be solved for distributed healthcare net-
works is to establish a sufficient degree of integration as basis for guideline implementation, and to find prac-
tical solutions to cope with the continuously evolving healthcare domain. Thereby, it is important to keep in
mind that medical decision making is complex, and that simplified technical solutions might be counterpro-
ductive, as computer applications that are not well accepted or insufficiently integrated into clinical work prac-
tice are in danger of provoking dangerous workarounds [36,5].
So far, IT support for medical decision making is not so much ‘‘process-oriented’’. Implementing guidelines
by translating them into alerts and reminders has proven to be effective if certain preconditions are considered
[5], but it does not recognize the patient treatment process as a unit. Medical pathways, as introduced above,
are an attempt to actually provide some kind of process template. Thus, the next question is, how can we effec-
tively provide IT support for medical pathways. Subsequently we describe an example of a clinical pathway
that has been improved by an integrated IT application.
4. IT support for clinical pathways: example
In Section 3we already mentioned the example of proximal femoral fracture to illustrate the different levels
of deviation. This example is only one out of very many aspects which had to be considered when a clinical
pathway for patients with suspicion of proximal femoral fracture was successfully implemented at the Univer-
sity hospital in Marburg (cf. [8–10,69]). A simplified illustration of this pathway is shown as activity diagram
in Fig. 6. Implementing a pathway like this in practice requires to overcome many types of barriers in order to
actually improve the quality of patient care. It is important to analyze the current deficiencies and the barriers
to change prior to pathway implementation. As a typical barrier clinicians might not know about the best
available evidence or current guideline recommendations. Thus, teaching is very important in the context
of consenting a clinical pathway (‘‘academic detailing’’).
Once the pathway is consented we can think about how to improve pathway compliance by the use of IT. In
the case of the example mentioned above some critical steps have been selected for IT support. A core require-
ment for IT support was to reduce the necessary computer interaction as much as possible, because clinicians
typically act under time pressure and will not accept any computer application that takes too much time away
from patients.
One approach to reduce documentation overhead was to use checklists which are pre-filled to some degree
according to pathway recommendations. This allows to do pathway conformant documentation easily with a
few clicks; deviation from the pathway is not prohibited but has to be documented additionally. Structured
data stemming from the initial pathway documentation is used to parameterize and trigger generic interdisci-
plinary processes, like imaging diagnostics. This means: once the physician has entered suspicion of proximal
femoral fracture, a pathway conformant order set for radiography is automatically created. The clinician can
individually correct this order set before sending it to the radiology department.
The described example has been implemented at Marburg University Medical Center on the basis of an
extensible integrated hospital information system [39,41]. As mentioned before, integration is an important
precondition for process support, because data stemming from different departments needs to be readily avail-
able for reuse in order to be able to provide effective decision support. To achieve this integration, the Mar-
burg Hospital Information System is based on a commercially available holistic system. Extensibility is
achieved via a CASE tool, which can be used to implement adapted clinical applications on a rapid prototyp-
48 R. Lenz, M. Reichert / Data & Knowledge Engineering 61 (2007) 39–58
ing basis. Such newly developed clinical applications have the advantage of being integrated with the overall
system from the beginning. The disadvantage of the approach is that the implementation of workflow is lim-
ited to the capabilities of the proprietary CASE tool. Tool-generated adapted applications are mainly based
on workflow-enabled electronic forms which are integrated with the rest of the system via a common database.
A major precondition for placing reminders and alerts or for automatically parameterizing order sets is the
potential of a system to reuse structured coded data. In Marburg this was achieved by storing all coded data
in the central database. From here data can be automatically uploaded into dedicated electronic forms – such
as the form for order placement.
The implementation of the example has shown that improving clinical pathways by the use of IT is possible.
The pragmatic approach followed in Marburg has also shown, however, that there is still a huge potential to
improve IT architectures to better suit for supporting clinical processes. For example, due to restrictions of the
integrated CASE tool used, document flow had to be hard-coded into electronic forms. Certainly, a separation
of workflow specifications and form contents is desirable to improve maintainability of clinical applications.
In general, more flexible process support and easy adaptability to change are required in order to provide full
process lifecycle support [66].
5. Implications for process-oriented IT architectures
The support of healthcare processes raises a number of requirements and challenges for process-oriented IT
architectures. In particular, integrated process support, information management, and knowledge manage-
ment on different levels are needed. Current healthcare information systems have failed in meeting these
requirements. This, in turn, has led to pragmatic solutions and workarounds in order to reduce the overall
effort for integrating heterogeneous application components and to enable a requirements-driven system evo-
lution. In this section we take a more visionary viewpoint. We discuss basic issues related to the computerized
support of both organizational processes and patient treatment processes.
therapy depending on
diagnosis / symptom
prehospital
phase
patient
admission
anamnesis and
clinical examination
clinical suspicion
of proximal
femoral fracture?
proximal femoral fracture
& operation indicated?
clarification of
osteoporosis
discharge &
documentation
poststationary
treatment
imaging diagnostics
yes
no
no yes
ward / ICU and
operative treatment
initial treatment
(emergency area) and
operation planning
IT support in
routine use
Fig. 6. Clinical pathway for proximal femoral fracture (simplified) [9].
R. Lenz, M. Reichert / Data & Knowledge Engineering 61 (2007) 39–58 49
5.1. Support for organizational processes
Though current hospital information systems partially support (fragments of) clinical workflows the pro-
cess logic is more or less hard-coded in the application programs. This, in turn, has led to unsatisfactory pro-
cess support (e.g., no monitoring facilities), high maintainability costs, and low system flexibility. In order to
support organizational processes (cf. Section 2) and to provide the needed information at the point of care, IT
architectures in hospitals must consider the cross-departmental nature of clinical processes. To avoid media
breaks we either need highly integrated systems or semantically compatible application components. Semantic
compatibility, in turn, subsumes information and functional integration. Besides this, comprehensive system
support is needed for tasks related to organizational and administrative processes. Process support functions
should comprise standard system services (e.g., process enactment, process monitoring, worklist management)
as well as advanced features (e.g., ad hoc changes of single process instances during runtime [57] or manage-
ment of temporal constraints [17,68]).
Organizational processes in hospitals are part of the fundamental work procedures in clinical practice,
which basically show less variability and dynamics when compared to the patient treatment process. Therefore
workflow management systems (WfMS) [81] offer a promising approach for implementing site-specific, orga-
nizational processes. WfMS enable the definition, execution, and monitoring of well-structured processes [21].
In connection with Web service technology, in addition, the benefits of process automation and optimization
from within a single hospital can be transferred to cross-organizational processes as well [2]. By separating the
process flow logic from the application code (i.e., the application functions), in principle, organizational pro-
cesses can be quicker implemented and adapted when compared to conventional approaches (cf. Section 4).
The experiences we made when implementing workflow-based clinical applications have confirmed this [58].
Since site-specific customizations and adaptations frequently become necessary in healthcare, vendors of hos-
pital information systems more and more adopt process management technologies.
Though WfMS have shown promising perspectives when being applied to organizational processes in
healthcare [58], still a lot of features are missing. Integrated time and resource management, for example,
are urgently needed in healthcare, but have not been adequately addressed in existing WfMS [17]. The same
applies to more advanced system functions like, for example, the personalized visualization of process
instances [11] or the extension of the classical worklist paradigm (e.g., support of multi-actor tasks). WfMS
also lack adequate support for defining and maintaining process model configurations. Think of, for example,
a ward which has to accomplish numerous diagnostic and therapeutic procedures with different departments.
Though order handling and result reporting are similar in all these cases, there are smooth differences regard-
ing the concrete process logic and the involved application components. Altogether we may obtain a large
number of different configurations for the same basic organizational process. In current WfMS each of these
configurations has to be defined and maintained in a separate process template, and even simple organiza-
tional changes may require manual re-editing of a large number of such templates. Over time this leads to
a degeneration and divergence of the different process configurations. This, in turn, significantly aggravates
future adaptations, ultimately making a refactoring of the existing process configurations inescapable.
5.2. Support for patient treatment processes
The integrated support of medical pathways and their individual adaptation (cf. Fig. 4) constitute a funda-
mental task for process-aware information systems in healthcare. Such process awareness could be particu-
larly beneficial if it is aimed at a full process lifecycle support and meaningful feedback at the different
process levels (see below).
To support guideline dissemination and to improve the transfer of evidence into clinical routine reliable
sources of evidence must be provided in easily accessible repositories. Such repositories are beginning to
emerge (e.g. [16]) but still numerous sources with heterogeneous and partly contradictory contents exist. In
any case, site-specific process optimization can be improved by providing more transparency on existing evi-
dence. The medical pathways resulting from site-specific adaptations of existing evidence then provide the
basis for the computerized support of patient treatment processes. They also link patient treatment processes
to organizational process patterns as well as to operational systems (incl. access to electronic patient records).
50 R. Lenz, M. Reichert / Data & Knowledge Engineering 61 (2007) 39–58
Based on this, new process instances (representing concrete patient treatment cases) can be created and cor-
responding activities be coordinated., However, users must be able to adapt medical pathways to the specific
situation of their patients whenever needed.
No adequate system support for integrated pathway management has been provided so far. A major reason
for this deficiency is the rigidity of existing WfMS, which are unable to cope with the evolving nature and the
dynamics of patient treatment processes. However, problems are not only related to technology, but also deal
with knowledge acquisition, knowledge maintenance, and legal responsibilities. Finally, as we elaborated in
the previous sections, process alignment has to be seen as the core challenge: embedding IT support into clin-
ical routine. IT should always be seen as a supportive tool, but it should never hinder clinical processes, even in
the case of system failures.
5.2.1. General remarks
The handling of medical pathways requires an organization-specific consensus among medical staff. Before
we try to support medical processes by means of IT we must be aware that this can only work if IT support is
aligned with an overall organizational change management process, which includes consensus processes, aca-
demic detailing and training of healthcare professionals. Due to the evolving nature of medical knowledge, in
addition, process-oriented IT architectures must enable continuous adaptation. This should be accomplished
under control of the respective healthcare organization. Furthermore, patient treatment processes (and their
monitoring) as well as patient information must be linked to the defined pathways and the underlying sources
of evidence.
IT architectures, which support medical processes, should allow for the explicit definition of medical knowl-
edge and enable its combined use with patient-related information. This requires a minimum of semantic con-
trol. In order to avoid problems at the operational level (e.g., when linking pathways with patient
information), we need tools for defining pathways based on the medical concepts and the medical terminology
already used within the operational systems. This requires standardized ontologies and vocabularies, which
partially exist in medicine. Furthermore, we must consider the evolving nature of the healthcare domain itself;
i.e., we must support the evolution (and versioning) of the ontologies and controlled vocabularies to which
pathways refer.
5.2.2. Lifecycle support for guidelines and pathways
We sketch what we mean with full lifecycle support for treatment processes, and we discuss how it could be
supported with adaptive process management technology [32,57]. We do not focus on technical issues (which
have been extensively described in other papers), but simply want to illustrate a challenging application area
for process management technology. Our framework for integrated guideline and pathway support is depicted
in Fig. 7. We summarize basic characteristics of this framework referring to the numbers in Fig. 7.
Guideline formalization. To some extent guidelines are comparable to reference models in business process
management; however, they tend to be more complex and need to be adapted more frequently. Usually, guide-
lines are published by a scientific organization in narrative form, e.g., as text or hypertext document. A first
step towards computer-based process support therefore is the formalization of the guidelines and their repre-
sentation in a machine-understandable way (1). Ideally, this can be accomplished by the same organization
which has developed and delivered the guideline. We need tools for (graphically) specifying the guidelines
at a semantically high level and in a form understandable to domain experts. Basically, established process
description formalism (e.g., High-level Petri Nets [51,81] or Activity Diagrams [20]) can be applied in this con-
text. As mentioned, in addition, guideline definitions should be based on standardized medical concepts and
medical vocabularies.
Guideline dissemination. When a new version of a medical guideline is released it has to be published and
disseminated (2). Note that the goal cannot be to automate guideline dissemination, but to improve transpar-
ency concerning existing evidence. To support guideline discovery a process-oriented IT architecture should
have access to repositories at different levels (local, regional, national, international).
Deriving site-specific pathways. Site-specific adaptations of medical guidelines require a consensus among
the corresponding healthcare professionals. Based on this, engineers can design a site-specific medical pathway
schema P (3), i.e., a schema which describes the logic of a particular treatment process independent of concrete
R. Lenz, M. Reichert / Data & Knowledge Engineering 61 (2007) 39–58 51
treatment cases or patient situations. In particular, a pathway schema must be linked to the operational sys-
tems of the healthcare organization and to the electronic patient records it maintains.
Creating an individual patient treatment plan. Based on a medical pathway schema new instances of patient
treatment processes can be created (4). Before such a new process instance (i.e., treatment case) is started, the
used pathway schema P may have to be adapted to the specific situation of the patient (by applying a set of
change operations) (5). Due to such treatment- or patient-specific adaptations, an individual patient treatment
plan results, which deviates from the medical pathway it was derived from.
Executing and adapting patient treatment processes. Based on an individualized patient treatment plan, a
corresponding treatment case (i.e., process instance) can be started and executed (6). However, the resulting
process instance may be subject to change at a later point in time as well. Variations in the course of a patient
treatment process are deeply inherent to medicine, and the unforeseen event is to some degree a ‘‘normal’’
phenomenon. Medical personnel must be free to react and is trained to do so. Therefore, in addition to the
customization of a pathway schema at instance creation time, it must be possible to dynamically adapt in-pro-
gress treatment cases (i.e., process instances) during runtime. For example, authorized users should be allowed
to add, delete, or move process steps (5). As a consequence the actual patient treatment process may deviate
from the original treatment plan and the related medical pathway respectively. However, such deviations from
the pre-planned process must not lead to errors or inconsistencies. Tools enabling them must be easy to han-
dle, self-explaining and – most important – their use in exceptional situations should be not more cumbersome
and time-consuming than simply handling the exception by a telephone call to the right person.
Instance-specific deviations (introduced at instance creation time or during runtime) have to be recorded
(5). Thereby, not only syntactical information should be captured, but also semantic information about the
reasons and context of a change. On the one hand this enables process engineers to derive optimized pathway
schemes later on, on the other hand it allows for the reuse of changes. In healthcare any deviation from the
standard procedure has to be documented for legal reasons.
The pathway enactment system must assist clinicians in defining and performing the necessary process
changes at the different levels (and to accomplish them in a correct and consistent manner [57]). This neces-
sitates intelligent user interfaces. On the one hand it must be possible to define ad hoc changes at a semanti-
Fig. 7. Required lifecycle support for medical guidelines/pathways.
52 R. Lenz, M. Reichert / Data & Knowledge Engineering 61 (2007) 39–58
cally high level, on the other hand the system should support the reuse of knowledge about previous changes
and its application in similar situations (5); i.e., users should be able to draw on past experiences.
Organizational learning. A logical next step is to continuously monitor, analyze, and mine the change logs
and to ‘‘learn’’ from the applied changes. Doing so one may detect that certain adaptations have occurred
over and over again. In such cases, it is very likely that the respective changes are of interest for future pro-
cess instances as well. Therefore, process engineers receive a corresponding notification (7) in order to decide
whether the change shall be lifted up one level by changing an existing pathway schema (8) or by introduc-
ing a new one (9). Altogether this may result in optimized and locally tuned models for medical pathways.
Finally, site-specific experiences should be communicated to the guideline consensus groups as well in order
to indicate potential modifications of the original guideline (10) or to trigger new trials in order to gain more
evidence.
Pathway adaptation and change propagation. As discussed it must be possible to adapt pathway implemen-
tations to changes in the local environment or to new evidence. Ideally, in such cases it is possible to migrate
already running treatment processes to the changed pathway schema as well. The latter becomes necessary due
to the long-running nature of patient treatment processes (up to several weeks or months). In this context
pathway changes may also have to be propagated to individually modified treatment processes.
5.2.3. Enabling technology for lifecycle support
Taking commercial process management technology and WfMS the described framework could not be real-
ized due to the mentioned drawbacks. However, in recent years several approaches have emerged which allow
to (dynamically) adapt processes at different levels (e.g., the process type and the process instance level
[15,33,37,48,47,57,64,62,63,80,85,86]) and to learn from these changes [66,84]. Note that this is exactly what
we must expect from a process oriented IT platform, which can be used as the basis of a process aware infor-
mation system to support evolving healthcare processes.
In the ADEPT project, for example, we have been working on the design and implementation of a next
generation process management system (PMS) for several years (e.g., [57,59,64,60]). Though ADEPT provides
an application-independent approach, many of its advanced process support features (e.g., enabling ad hoc
change of single process instances or process schema evolution) have been motivated by requirements we iden-
tified in case studies conducted in the clinical domain (see [17,58]). More precisely, besides standard process
management functions (e.g., process monitoring, worklist management), the ADEPT system enables dynamic
changes of different process aspects (e.g., control and data flow) during runtime. Such process changes always
preserve correctness properties and semantic constraints, and can be performed at two different levels – the
process type and the process instance level [64,65].
Ad hoc changes of single process instances. ADEPT supports different kinds of ad hoc process instance
changes (e.g., to insert, delete, or shift activities) [57]. This is exactly the functionality we need to derive
patient-specific treatment processes from a pre-defined clinical pathway schema and to further adapt them
at execution time if needed. In ADEPT, such ad hoc changes do not lead to an unstable system behavior,
i.e., none of the guarantees (e.g., regarding the absence of deadlocks) achieved by formal checks at buildtime
are violated due to the dynamic change. This kind of robustness is essential for any process-aware healthcare
information system. ADEPT offers a complete set of operators for defining instance changes at a high seman-
tic level and it ensures correctness by introducing pre-/post-conditions for these operations. All complexity
associated with the adaptation of instance states, the remapping of activity parameters, or the problem of
missing data (e.g., due to activity deletions) is hidden to a large degree from users. Finally, all ad hoc devia-
tions are documented and stored in change logs. In healthcare, for example, this documentation is needed for
legal reasons.
In order to support change reuse in the ADEPT framework we have adopted concepts and techniques from
case-based reasoning (CBR), which is a contemporary approach to problem solving and learning [35]. New
problems are dealt with by drawing on past experiences – described in cases – and by adapting their solutions
to the new problem situation. In our scenario this means that users can retrieve the context of and the actions
related to previous ad hoc changes, and can reuse this knowledge when defining new ad hoc deviations [66].
Generally, reasoning based on past experiences is a powerful and frequently applied way to solve problems by
humans [1]. Particularly, in healthcare this is essential to adequately assist non-experienced clinicians. Obvi-
R. Lenz, M. Reichert / Data & Knowledge Engineering 61 (2007) 39–58 53
ously, such an advanced approach requires the formalization of problem descriptions as well as of the corre-
sponding actions. In future, we additionally aim at the semantic annotation of change logs and the mining of
these logs to discover process model optimizations. This will enable organizational learning as described
before.
Process type changes and change propagation. In order to deal with business process changes (e.g., the adap-
tation of a medical pathway to organizational changes) ADEPT enables quick and efficient schema adapta-
tions at the process type level (process schema evolution). In this context it is also possible to propagate
process type changes to running process instances (of this type) [62]. This is particularly important for
long-running processes as in the case of patient treatment. ADEPT guarantees that only those process
instances can be migrated to the new process schema version, which are compliant with this schema [62]. Fur-
ther, the states of compliant instances are automatically adapted when migrating these instances to the chan-
ged process schema. ADEPT is able to efficiently handle a large number of concurrently running process
instances. It is also possible to propagate process type changes to unbiased as well biased process instances.
We denote process instances as unbiased if they are running according to the original process type schema they
were derived from, whereas process instances are denoted as biased if they have been individually modified
(e.g., due to an ad hoc change) [65]. Note that actual patient treatment processes often represent biased pro-
cess instances when compared to the original pathway schema.
6. Summary
The potential of IT to prevent medical errors and thereby improve healthcare quality is undeniably attrac-
tive. Yet, to adequately support healthcare processes it is important to understand their characteristics. To
identify the core challenges as well as the shortcomings of current IT approaches we distinguished organiza-
tional processes from the medical treatment process. While organizational processes are based on more or less
stable generic process patterns the patient treatment process depends on medical knowledge which rapidly
evolves. Appropriate IT support for the latter is difficult to achieve, because medical decision making is based
on both tacit and explicit knowledge and cannot be automated. Evidence Based Medicine (EBM) is supported
by guidelines which contain general recommendations based on current evidence and expert consensus. Med-
ical pathways require a consensus among process participants in a particular healthcare setting in order to
adapt existing guidelines to local circumstances and preferences. Before IT can effectively support such path-
ways physicians should be aware of the underlying evidence. Once these preconditions are fulfilled, IT can
contribute to improve pathway compliance if it is carefully embedded into routine work practice. The goal
of IT support for healthcare processes is not to control the course of the process, but to assist healthcare pro-
fessionals by reducing cognitive overload and improving the basis for their decisions.
Current IT solutions support organizational process patterns to some degree, as standards like HL7 and
IHE help to integrate heterogeneous system components. Yet, continuously adapting systems to site-specific
requirements and ever changing needs for decision support is an open challenge. We demonstrated that one
precondition for such an evolutionary approach is a high degree of flexibility. The ADEPT PMS does provide
such flexibility, thus it appears to be suitable to improve IT support for healthcare processes. However,
ADEPT is not a healthcare application. It rather has to be seen as a powerful workflow engine supporting
healthcare applications on top of it. These applications must enable healthcare professionals to easily specify
and maintain the medical knowledge contained in medical pathways, alerts, and reminders. In addition, dif-
ferent kinds and degrees of decision support are required, as experienced healthcare professionals will certainly
need another kind of support as an inexperienced newcomer. Numerous challenges still exist which must be
carefully understood and which require basic research before we can come to a complete solution approach.
We believe that realizing process-oriented IT architectures in healthcare is a great challenge for the business
process management community – if not even the ‘‘killer application’’ for this type of technology. In any case
different levels of process support have to be distinguished and a high degree of variability and dynamics has
to be achieved.
Future healthcare information systems must also support patient treatment and information management
in distributed healthcare networks. Healthcare is more and more changing from isolated patient treatment epi-
sodes towards continuous treatment involving multiple healthcare professionals and institutions. Therefore
54 R. Lenz, M. Reichert / Data & Knowledge Engineering 61 (2007) 39–58
hospitals need to be linked with other healthcare organizations and general practitioners, but also with insur-
ance companies and governmental organizations, over wide area networks transporting sensitive patient data.
The adequate support of distributed healthcare networks will result in novel process scenarios raising a num-
ber of challenging issues. A sufficient degree of process and information integration and the semantic interop-
erability of the different healthcare systems are crucial in this context. The same applies to privacy and security
issues in connection with the exchange of patient data.
References
[1] A. Aamodt, E. Plaza, Case-based reasoning: foundational issues, methodological variations and system approaches, AI Commun.
7 (2) (1994) 39–59.
[2] G. Alonso, F. Casati, H. Kuno, V. Machiraju, Web Services – Concepts, Architectures and Applications, Springer, 2004.
[3] T.D. Ambrisko, T. Nemeth, A computer program for calculation of doses and prices of injectable medications based on body weight
or body surface area, Can. J. Vet. Res. 68 (1) (2004) 62–65.
[4] D.W. Bates, M. Cohen, L.L. Leape, J.M. Overhage, M.M. Shabot, T. Sheridan, Reducing the frequency of errors in medicine using
information technology, J. Am. Med. Inform. Assoc. 8 (4) (2001) 299–308.
[5] D.W. Bates, G.J. Kuperman, S. Wang, T. Gandhi, A. Kittler, L. Volk, et al., Ten commandments for effective clinical decision
support: making the practice of evidence-based medicine a reality, J. Am. Med. Inform. Assoc. 10 (6) (2003) 523–530.
[6] D.W. Bates et al., Ten commandments for effective clinical decision support: making the practice of evidence-based medicine a
reality, J. Am. Med. Inform. Assoc. 10 (6) (2003) 523–530.
[7] A.L. Bhasale, G.C. Miller, S.E. Reid, H.C. Britt, Analysing potential harm in Australian general practice: an incident-monitoring
study, Med. J. Aust. 169 (2) (1998) 73–76.
[8] R. Blaser, O. Heger, M. Beyer, M. Schnabel, C. Biber, M. BSumlein, R. Lenz, Erfolgsfaktoren zur umsetzung klinischer pfade, in:
Proc. GMDS’05, 2005.
[9] R. Blaser, M. Schnabel, O. Heger, E. Opitz, R. Lenz, K.A. Kuhn, Improving pathway compliance and clinician performance by using
information technology, Stud. Health Technol. Inform. 116 (2005) 199–204.
[10] R. Blaser, M. Schnabel, D. Mann, P. Jancke, K.A. Kuhn, R. Lenz, Using information technology to prevent medical errors in
casualty surgery, in: Proc. ACM Symp. on Applied Computing (SAC’04), 2004, pp. 285–290.
[11] R. Bobrik, M. Reichert, T. Bauer, Requirements for the visualization of system-spanning business processes, in: Proc. 16th Int’l.
Workshop on Database and Expert Systems Applications, Copenhagen, 2005, pp. 948–954.
[12] D.T. Bomba, R. Prakash, A description of handover processes in an Australian public hospital, Aust. Health Rev. 29 (1) (2005) 68–
79.
[13] T.A. Brennan, L.L. Leape, Adverse events, negligence in hospitalized patients: results from the harvard medical practice study,
Perspect. Healthc. Risk Manage. 11 (2) (1991) 2–8.
[14] T.A. Brennan et al., Incidence of adverse events and negligence in hospitalized patients. results of the harvard medical practice study
i, N. Engl. J. Med. 324 (6) (1991) 370–376.
[15] F. Casati, S. Ceri, B. Pernici, G. Pozzi, Workflow evolution, Data Knowledge Eng. 24 (3) (1998) 211–238.
[16] E. Coiera, M. Walther, K. Nguyen, N.H. Lovell, Architecture for knowledge-based and federated search of online clinical evidence,
J. Med. Internet. Res. 7 (5) (2005).
[17] P. Dadam, M. Reichert, K. Kuhn, Clinical workflows – the killer application for process-oriented information systems? in: Proc. 4th
Int. Conf. on Business Information Systems, 2000, pp. 36–59.
[18] P.A. de Clercq, J.A. Blom, H.H. Korsten, A. Hasman, Approaches for creating computer-interpretable guidelines that facilitate
decision support, Artif. Intell. Med. 31 (1) (2004) 1–27.
[19] R. Van de Velde, P. Degoulet, Clinical Information Systems, Springer-Verlag, New York, 2003.
[20] M. Dumas, A.H.M. ter Hofstede, UML activity diagrams as a workflow specification language, in: Proc. UML’01, Toronto, Canada,
2001.
[21] M. Dumas, W. van der Aalst, A. ter Hofstede, Process-aware Information Systems, Wiley, 2005.
[22] R.B. Elson, D.P. Connelly, Computerized decision support systems in primary care, Prim. Care 22 (2) (1995) 365–384.
[23] F. Frihagen, L. Nordsletten, R. Tariq, J.E. Madsen, Mri diagnosis of occult hip fractures, Acta Orthop. 76 (4) (2005)
524–530.
[24] M. Gaitanides, Prozessorganisation – Entwicklung, AnsStze und Programme prozessorientierter Organisationsgestaltung, Vahlen,
1983.
[25] P.A. Gross et al., Optimal methods for guideline implementation: conclusions from Leeds castle meeting, Med. Care 39 (8 Suppl 2)
(2001) II85–II92.
[26] R.C. Hawkins, The evidence based medicine approach to diagnostic testing: practicalities and limitations, Clin. Biochem. Rev. 26 (2)
(2005) 7–18.
[27] O.K. Hejlesen, K.G. Olesen, R. Dessau, I. Beltoft, M. Trangeled, Decision support for diagnosis of lyme disease, Stud. Health
Technol. Inform. 116 (2005) 205–210.
[28] W.R. Hogan, M.M. Wagner, Accuracy of data in computer-based patient records, J. Am. Med. Inform. Assoc. 4 (5) (1997)
342–354.
R. Lenz, M. Reichert / Data & Knowledge Engineering 61 (2007) 39–58 55
[29] R. Ismach, Teaching evidence based medicine to medical students. Available from: <www.saem.org/download/Hand-6.pdf>,
November 2005.
[30] R.A. Jenders, et al., Medical decision support: experience with implementing the arden syntax at the Columbia-Presbyterian Medical
Center, in: Proc. Ann. Symp. Comput. Appl. Med. Care, 1995, pp. 169–173.
[31] M.E. Johnston, K.B. Langton, R.B. Haynes, A. Mathieu, Effects of computer-based clinical decision support systems on clinician
performance and patient outcome, Ann. Intern. Med. 120 (2) (1994) 135–142.
[32] M. Klein, C. Dellaroca, A. Bernstein, Towards adaptive workflow systems, in: Proc. CSCW’98 Workshop, Seattle, Nov. 1998.
[33] K. Kochut, J. Arnold, A. Sheth, J. Miller, E. Kraemer, B. Arpinar, J. Cardoso, IntelliGEN: A distributed workflow system for
discovering protein-protein interactions, Distrib. Parallel Databases 13 (1) (2003) 43–72.
[34] L.T. Kohn, J.M. Corrigan, M.S. Donaldson, To Err Is Human. Building a Safer Health System, Nat. Acad. Press, Washington DC,
2000, 0 AD/11/2.
[35] J.L. Kolodner, Case-Based Reasoning, Morgan Kaufman, 1993.
[36] R. Koppel, J.P. Metlay, A. Cohen, B. Abaluck, A.R. Localio, S.E. Kimmel, B.L. Strom, Role of computerized physician order entry
systems in facilitating medication errors, JAMA 293 (10) (2005) 1197–1203.
[37] M. Kradolfer, A. Geppert, Dynamic workflow schema evolution based on workflow type versioning and workflow migration,
Technical Report 98.02, University of Zurich, Department of Computer Science, 1998.
[38] R. Lenz, M. Beyer, K.A. Kuhn, Semantic integration in healthcare networks, in: Proc. Medical Informatics Europe, IOS Press, 2005,
pp. 385–390.
[39] R. Lenz, T. Elstner, H. Siegele, K.A. Kuhn, A practical approach to process support in health information systems, J. Am. Med.
Inform. Assoc. 9 (6) (2002) 571–585.
[40] R. Lenz, S. Huff, A. Geissbuehler, Report of conference track 2: pathways to open architectures, Int. J. Med. Inform. 69 (2–3) (2003)
297–299.
[41] R. Lenz, K.A. Kuhn, A strategic approach for business-IT alignment in health information systems, in: Proc. CoopIS’03, 2003, pp.
178–195.
[42] F. Leymann, D. Roller, Production Workflow, Prentice-Hall, 2000.
[43] S.M. Maviglia, R.D. Zielstorff, M. Paterno, J.M. Teich, D.W. Bates, G.J. Kuperman, Automating complex guidelines for chronic
disease: lessons learned, J. Am. Med. Inform. Assoc. 10 (2) (2003) 154–165.
[44] C.J. McDonald, Protocol-based computer reminders, the quality of care and the non-perfectability of man, N. Engl. J. Med. 295 (24)
(1976) 1351–1355.
[45] C.J. McDonald et al., Ann. Intern. Med. 100 (1) (1984) 130–138.
[46] P. Mildenberger, M. Eichelberg, E. Martin, Introduction to the DICOM standard, Eur. Radiol. 12 (4) (2002) 920–927.
[47] R. Mu
¨ller, Event-oriented dynamic adaptation of workflows, Ph.D. thesis, University of Leipzig, Germany, 2002.
[48] R. Mu
¨ller, U. Greiner, E. Rahm, AGENTWORK: a workflow system supporting rule-based workflow adaptation, DKE 51 (2) (2004)
223–256.
[49] T. Muller, Typical medication errors in oncology: analysis and prevention strategies, Onkologie 26 (6) (2003) 539–544.
[50] I. Nonaka, H. Takeuchi, The Knowledge Creating Company, Oxford University Press, Oxford, UK, 1995.
[51] A. Oberweis, Modeling and Execution of Workflows with Petri Nets, Teubner, 1996 (in German).
[52] L. Ohno-Machado et al., The guideline interchange format: a model for representing guidelines, J. Am. Med. Inform. Assoc. 5 (4)
(1998) 357–372.
[53] Committee on Quality of Health Care in America IOM, Crossing the Quality Chasm: A New Health System for the 21st Century,
IOM, 2001.
[54] M. Peleg, A.A. Boxwala, O. Ogunyemi, Q. Zeng, S. Tu, R. Lacson, Glif3: the evolution of a guideline representation format, in: Proc.
Amia. Symp., 2000, pp. 645–649.
[55] M. Peleg et al., Comparing computer-interpretable guideline models: a case-study approach, J. Am. Med. Inform. Assoc. 10 (1)
(2003) 52–68.
[56] T.A. Pryor, G. Hripcsak, Sharing mlm’s: an experiment between Columbia-Presbyterian and LDS hospital, in: Proc. Annu. Symp.
Comput. Appl. Med Care, 1993, pp. 399–403.
[57] M. Reichert, P. Dadam, ADEPT
flex
– supporting dynamic changes of workflows without losing control, JIIS 10 (2) (1998) 93–
129.
[58] M. Reichert, P. Dadam, R. Mangold, R. Kreienberg, Computer-based support of clinical work processes – concepts, technologies,
and their application, Zentralbl Gynakol 122 (1) (2000) 56–70 (in German).
[59] M. Reichert, S. Rinderle, P. Dadam, ADEPT workflow management system: flexible support for enterprise-wide business processes,
in: Proc. Int’l. Conf. on Business Process Management (BPM’03), 2003, pp. 370–379.
[60] M. Reichert, S. Rinderle, P. Dadam, On the common support of workflow type and instance changes under correctness constraints,
in: Proc. CoopIS’03, Catania, Italy, November 2003, pp. 407–425.
[61] B.M. Reilly, The essence of ebm, BMJ 329 (2004) 991–992.
[62] S. Rinderle, M. Reichert, P. Dadam, Correctness criteria for dynamic changes in workflow systems – a survey, DKE 50 (1) (2004)
9–34.
[63] S. Rinderle, M. Reichert, P. Dadam, Disjoint and overlapping process changes: challenges, solutions, applications, in: Proc.
CoopIS’04, Agia Napa,Cyprus, 2004, pp. 101–120.
56 R. Lenz, M. Reichert / Data & Knowledge Engineering 61 (2007) 39–58
[64] S. Rinderle, M. Reichert, P. Dadam, Flexible support of team processes by adaptive workflow systems, Distrib. Parallel Databases
16 (1) (2004) 91–116.
[65] S. Rinderle, M. Reichert, P. Dadam, On dealing with structural conflicts between process type and instance changes, in: Proc.
BPM’04, Potsdam, June 2004, pp. 274–289.
[66] S. Rinderle, B. Weber, M. Reichert, W. Wild, Integrating process learning and process evolution – a semantics based approach, in:
Proc. BPM’05, 2005, pp. 252–267.
[67] D.L. Sackett, W.M. Rosenberg, J.A. Gray, R.B. Haynes, W.S. Richardson, Evidence based medicine: what it is and what it isn’t,
BMJ 312 (7023) (1996) 71–72.
[68] S. Sadiq, O. Marjanovic, M. Orlowska, Managing change and time in dynamic workflow processes, IJCIS 9 (1&2) (2000) 93–116.
[69] M. Schnabel, D. Mann, M. SchSg, I. Kopp, K. Kuhn, Klinische behandlungspfade auf dem weg ins krankenhausinformationssystem,
in: Proc. GMDS’04, Innsbruck, Austria, 2004.
[70] J. Schriefer, The synergy of pathways and algorithms: two tools work better than one, Jt. Comm. J Qual. Improv. 20 (9) (1994) 485–
499.
[71] R.N. Shiffman, Y. Liaw, C.A. Brandt, G.J. Corb, Computer-based guideline implementation systems: a systematic review of
functionality and effectiveness, J. Am. Med. Inform. Assoc. 6 (2) (1999) 104–114.
[72] R.N. Shiffman, G. Michel, A. Essaihi, E. Thornquist, Bridging the guideline implementation gap: a systematic, document-centered
approach to guideline implementation, J Am. Med Inform. Assoc. 11 (5) (2004) 418–426.
[73] M. Stefanelli, The socio-organizational age of artificial intelligence in medicine, Artif. Intell. Med. 23 (1) (2001) 25–47.
[74] M. Stefanelli, Knowledge and process management in health care organizations, Methods Inform. Med. 43 (5) (2004) 525–535.
[75] Andrew S. Tanenbaum, Computer Networks, second ed., Prentice-Hall, Englewood Cliffs, NJ, 1988.
[76] S. Timmermans, A. Mauck, The promises and pitfalls of evidence-based medicine, Health Aff. (Millwood.) 24 (1) (2005) 18–28.
[77] J.H. van Bemmel, M. Musen (Eds.), Handbook of Medical Informatics, Springer, 1997.
[78] C. van Walraven, R. Seth, P.C. Austin, A. Laupacis, Effect of discharge summary availability during post-discharge visits on hospital
readmission, J. Gen. Intern. Med. 17 (3) (2002) 186–192.
[79] C. van Walraven, R. Seth, A. Laupacis, Dissemination of discharge summaries. Not reaching follow-up physicians, Can. Fam.
Physician 48 (2002) 737–742.
[80] W.M.P.v.d. Aalst, How to handle dynamic change and capture management information: an approach based on generic workflow
models, Int. J. Comput. Syst., Sci. Eng. 6 (5) (2001) 295–318.
[81] W.M.P.v.d. Aalst, K. van Hee, Workflow Management, MIT Press, 2002.
[82] P. Vegoda, Introducing the IHE (integrating the healthcare enterprise) concept, J. Healthc. Inform. Manage. 16 (1) (2002) 22–24.
[83] C. Vincent, G. Neale, M. Woloshynowych, Adverse events in British hospitals: preliminary retrospective record review, BMJ 322
(7285) (2001) 517–519.
[84] B. Weber, S. Rinderle, W. Wild, M. Reichert, CCBR-driven business process evolution, in: Proc. Int’l. Conf. on Case-Based
Reasoning (ICCBR’05), Chicago, 2005, pp. 610–624.
[85] M. Weske, Workflow management systems: formal foundation, conceptual design, implementation aspects, Habilitation Thesis,
University of Mu
¨nster, Germany, 2000.
[86] M. Weske, Formal foundation and conceptual design of dynamic adaptations in a workflow management system, in: Proc. Hawaii
Int’l. Conf. on System Sciences (HICSS-34), 2001.
[87] R.M. Wilson, B.T. Harrison, R.W. Gibberd, J.D. Hamilton, An analysis of the causes of adverse events from the quality in Australian
health care study, Med. J. Aust. 170 (9) (1999) 411–415.
[88] R.M. Wilson, W.B. Runciman, R.W. Gibberd, B.T. Harrison, L. Newby, J.D. Hamilton, The quality in Australian health care study,
Med. J. Aust. 163 (9) (1995) 458–471.
[89] J.C. Wyatt, Management of explicit and tacit knowledge, J. R. Soc. Med. 94 (1) (2001) 6–9.
[90] R.D. Zielstorff, Online practice guidelines: issues, obstacles, and future prospects, J. Am. Med. Inform. Assoc. 5 (3) (1998) 227–236.
Richard Lenz holds a Ph.D. in Computer Science and is currently temporary Director of the Institute of Medical
Informatics at the University of Marburg, Germany. He is both lecturer for distributed information systems and
medical informatics, and he heads an interdisciplinary project group for process optimization at the University-
Hospital in Marburg. In 2005 he finished his habilitation thesis on ‘‘Evolutionary Information Systems’’, where he
presents a generally applicable reference model for layered system architectures as well as an adapted strategic
approach for the Hospital Information System in Marburg. Richard has studied Computer Science in Kaisers-
lautern and Erlangen, where he also was a member of the Database Research staff. In 1997 he earned his Ph.D.
from the University of Erlangen with his thesis on ‘‘Adaptive Data Replication in Distributed Systems’’.
R. Lenz, M. Reichert / Data & Knowledge Engineering 61 (2007) 39–58 57
Manfred Reichert holds a Ph.D. in computer science and is currently Associate Professor in the Information
Systems Group at the University of Twente (UT), The Netherlands. At UT he is also coordinator of the E-health
SRO (Strategic Research Orientation) and a member of the Management Team of the Centre for Telematics and
Information Technology (CTIT), which is the largest ICT research institute in the Netherlands (with more than
300 researchers). Before he joined UT in January 2005, he was assistant professor in the Department of Databases
and Information Systems at the University of Ulm, Germany. There, he also finished his Ph.D thesis on adaptive
process management in July 2000 (with honours). Manfred received several awards for his outstanding work on
the ADEPT process management technology. He is an expert in the field of business process management (BPM)
and has gained deep insights into BPM requirements in different application domains (e.g., healthcare and
automotive industry).
58 R. Lenz, M. Reichert / Data & Knowledge Engineering 61 (2007) 39–58
