Towards Process-oriented Hospital Information Systems:
Some Insights into Requirements, Technical Challenges and Possible Solutions
Manfred Reichert, Peter Dadam
Abteilung Datenbanken und Informationssysteme
Universität Ulm
D-89069 Ulm
{reichert, dadam}@informatik.uni-ulm.de
1 Introduction
There is an increasing interest in changing hospital information systems (HIS) to support clinical processes
in a more direct way [1,2,3,4]. This means to actively deliver the tasks to be performed to the right persons
at the right point in time with the necessary information and the application functions needed. Workflow
(WF) technology is a very interesting candidate to realize process-oriented HIS. It allows modeling the
control and the data flow of a clinical process separately from the implementation of the application
components. By interpreting the process models during run-time, the workflow management system
(WfMS) actively co-ordinates, schedules, and monitors the execution of process steps. It supports the
controlled exchange of information between them, it provides worklists to users, and it invokes the appli-
cation components associated with work items from these lists.
Current WfMSs, however, are only applicable to the minority of (clinical) processes [5,6]. One of their
most severe weaknesses is the limited support of users to deviate from the pre-modeled process plan dur-
ing run-time. Also dynamically evolving patient processes are not sufficiently supported. Generally, a clinical
WF cannot be always modeled on a fine-grained level before its execution starts. If a physician, for ex-
ample, comes to the conclusion that for an on-going case an additional measure, which has not been
anticipated in the process plan becomes necessary the HIS must assist her or him in performing this task. It
would be unacceptable to bypass the system in such cases, since this may cause the problem of missing or
dual documentation. Finally, other functional limitations of current WF technology include the insufficient
support of temporal representations and the insufficient synchronization of different WF instances related to
the same patient. All these issues are extremely important for the computer-based support of clinical WFs,
and they cannot be treated reasonably well when considered in an isolated fashion only.
In the ADEPT research project [7,8] we are looking at the different aspects of process-oriented (hospital)
information systems in conjunction with each other. We have carefully analyzed application requirements
from the clinical domain and we are working on an adequate technological basis for supporting these re-
quirements. In this paper, we give an overview of some of the research activities followed in the ADEPT
project.
Appeared in: Proc. 43. Jahrestagung der GMDS (GMDS’98), Bremen, 1998, pp. 175-180
2 Methods
During the last years we elaborated a complete "process map" for the Women's Hospital of our University.
For process modeling and redesign the tools Bonapart and ARIS have been utilized [6]. The challenge on
the one side was to understand in-depth all characteristic types of processing, the organizational structures,
the kinds of exceptions and deviations which may occur in clinical processes, and the adequate reaction on
such events, to learn how computer support for clinical processes can be smoothly integrated in the daily
routine work, and how adequate man-machine interfaces have to look like. The challenge on the other side
was to find an adequate technological basis for supporting these requirements.
On the application side we have been working into two directions: "Smooth assistance" of routine work by
knowledge-based components on the one side [9], and business process reengineering and WF man-
agement (the larger activity) on the other side [1,5,7,8]. With "smooth assistance" we mean that in clinical
application environments the computer may only make suggestions but is never allowed to make final
decisions. In order to understand how such an assistance could look like, we have developed a component
to assist the physician in selecting tests and interventions based on medical guidelines. It suggests (further)
tests and treatments for a given indication and based on the outcomes obtained so far [9]. In a similar way
rules are used to describe inter-process dependencies on a logical level (e.g., constraints concerning the
order of two different examinations related to the same patient) and to generate the input for an inter-
workflow execution monitor. To gain concrete implementation and usability experience with WF technolo-
gy, we implemented processes of the division "day clinic" using the WfMS WorkParty [1].
Based on the experiences made and on the limitations identified we have developed the ADEPTworkflow
system. Its components have been implemented on top of JAVA, the RDBMS Oracle, and middleware
technology. The goal was to build a platform-independent, flexible WfMS, of which the clients (e.g., work-
list handlers) can be executed as an applet in JAVA-compatible browsers.
3 Results
The ADEPTworkflow system provides an integrated solution for implementing process-oriented (hospital) in-
formation systems. The system comprises components for process modeling and execution, the support of
dynamically changing and evolving processes, and the handling of temporal constraints, for example.
Process Modeling and Execution
We provide an ontology that allows modeling all relevant aspects of a clinical process. This includes, for
example, the graphical specification of the control and data flow of the process as well as of temporal con-
straints. ADEPT follows a block-structured modeling approach (see Fig. 1). A branching or a loop is
always modeled in a block-oriented fashion having exactly one entry and one exit node. Different kinds of
synchronization can be used to express different kinds of “wait-for” situations in concurrent executions.
Additionally, ADEPT provides high-level control structures to modelers allowing them to consider envi-
saged exceptions (e.g., forward or backward jumps in the flow) already at the design level (see Fig. 2).
Other structural components like the (patient) data model, organizational structures, resource descriptions,
or business rules (e.g., medical guidelines) are specified separately and may be re-used within different pro-
cess models. ADEPT provides a set of tools allowing the designer to correctly define WF templates for
order
medical
order
prepare
patient
make
appointment
medical
intervention
SHORTCUT
(clinical) processes. These templates are then used as input by the ADEPT WF engine. A template is
instantiated by creating a copy of it – the WF instance graph –, which is then interpreted by the WF engine.
In doing so, the engine co-ordinates the execution of steps, provides worklists to the users, invokes
application components when a user selects a work item from the worklist, and monitors task execution
and task deadlines.
check patient
record
collect
patient data
admit
patient
physical
examination
pre-order
medicament
calculate
the right dose
produce
medicament
validate
dose
perform
lab-test
take
specimen
validate
medical reports
patientId
weight
+ height
dose
give
medicament
provide
aftercare
discharge
patient
another
cycle?
no
yes
LOOP
data element
parallel split parallel join
fixed appointment
max. time
distance 3 h
DATA FLOW CONTROL FLOW
Fig. 1: Business Process Modeling in ADEPT
Fig. 2: Pre-modeling Exceptions (The user may jump forward to the task "medical intervention"
even if the tasks "make appointment" and "prepare patient" have not yet been completed.)
Changing In-progress Processes On The Fly
ADEPT supports dynamic changes of in-progress WF instances; i.e., the modification of the flow structure
and the flow state during run-time. This feature is of extreme importance for the flexible support of clinical
WFs, especially if the planning and the execution of tasks overlap. It allows, for example, to modify the
plan of a patient process during its execution. With this we mean that the execution of the WF instance
under consideration is (partially) interrupted, the modification of its plan is performed, and the execution is
continued based on the modified plan. Such changes may be predictable and therefore be pre-planned, or
they may be carried out in an ad-hoc manner.
In the former case the designer must define a “planning step” in the WF template. When this step is reached
during process execution, the process plan may be refined or extended by the user. Unlike these
predictable modifications, ad hoc changes of a process plan may become necessary due to unforeseen or
exceptional events (e.g., in the case of an acute emergency or when prerequisites for an intervention are
violated) or due to changes of a previous planning decision. ADEPT allows the user to deviate from the
pre-modeled plan during its execution. We offer simple to use interfaces for worklist handling and for
supporting ad-hoc deviations and run-time changes (see Fig. 3). A WF instance graph can be altered and
customized without affecting the definition of its original plan. This is possible, in principle, since the WF
engine sees the current plan (i.e., the WF instance graph) only as data and not as program code.
Depending on their privileges, users may add or delete tasks (or whole task blocks), may rearrange the or-
der of tasks (e.g., by skipping steps), may initiate a partial rollback of the WF, may temporarily suspend a
task or a process, or may only modify task attributes (e.g., role assignments, deadlines, or binding of
resources). Besides these basic change facilities, ADEPT offers methodological support and rules for the
dynamic planning and composition of (patient) processes making use of pre-defined procedures. The
resulting plan is then automatically mapped onto an operational WF instance graph. All changes are
properly integrated, especially with respect to authorization and documentation. ADEPT uses propagation
mechanisms to inform users about a change and to update their worklists accordingly. In addition – and this
is very important in conjunction with more complex processes – the system guarantees that the use of a
Fig. 3: Example of a Worklist Handler.
change operation does not violate the consistency of the WF instance graph; i.e., it does not cause data
inconsistencies or the violation of time constraints, for example. Internally, ADEPT is based on a proper
formal framework that allows arguing about the correctness of a dynamic WF change and that prevents in-
terpretation ambiguities of a WF model. For formal and technical details the interested reader is referred to
[7, 8].
Supporting Temporal Constraints
The support of temporal aspects is an important functional feature of a process-oriented HIS. It provides
the basis for scheduling tasks in time and for actively assisting the medical personnel in keeping track of
them. Although some functionality to support temporal representations has been incorporated into existing
WfMS, usually it has been limited making simplifying assumptions and failing to capture the complexity that
accompanies the support of real-world processes [10].
ADEPT allows users to associate temporal constraints with the execution of tasks (e.g., concerning their
starting or finishing time). In addition, users may specify qualitative as well as quantitative temporal
dependencies between them (e.g., task A must be completed 2 days before task B starts). We deal with
uncertainty and we provide support for handling delays in the execution of tasks and for handling temporal
inconsistencies (e.g., due to changes of a time schedule). The latter is very important in the context of run-
time changes of a process plan as described above. Internally, ADEPT applies techniques similar to those
used by network plans, which can also be found in calendar and in scheduling systems. At run-time the
ADEPT system monitors task deadlines and it actively reminds users when these deadlines are going to be
missed. In doing so, the system also infers the consequences for missing a deadline with respect to
subsequent steps.
System Architecture
The ADEPT architecture comprises multiple layers, which provide services for the (persistent) management
of WF data, the distributed execution of WFs, the transactional processing of WFs and of WF changes,
the management of WF objects (e.g., WF templates, WF instances, worklists, application services and
programs, or business rules), and the implementation of client applications (e.g., worklist handlers or
monitoring tools). An important component of the system is the time scheduler, which is responsible for the
handling of temporal constraints.
4 Conclusions
The need for supporting clinical WFs is widely recognized [2,3,4,10]. We have evaluated to which extent
current WF technology is able to meet the resulting requirements. Although, today's WfMSs are not yet
suited to support the whole spectrum of clinical processes, in the longer term they will provide an excellent
basis for implementing and maintaining advanced HIS. We are convinced that the approach we have taken
in the ADEPT project will contribute to the development of flexible WF technology in general and to the
realization of process-oriented HIS in particular. Looking at the total landscape, the support of temporal
issues and dynamic WF changes as well as their various side effects are understood best in the meantime.
Also the component-based development of WF applications, user-interface issues, and the support of
organizational structures (which is a nightmare in the clinical domain) have been considered in the ADEPT
system architecture.
References
(1) Reichert, M.; Schultheiß, B.; Dadam, P.: Erfahrungen bei der Entwicklung vorgangsorientierter,
klinischer Anwendungssysteme auf Basis prozeßorientierter Workflow-Technologie. Proc. 42.
Jahrestagung der GMDS, Ulm, 1997, 181-187.
(2) Scheer, A.-W.; Chen, R.; Zimmermann, V.: Geschäftsprozesse und integrierte Informationssysteme im
Krankenhaus, Institut für Wirtschaftsinformatik, IWI-Heft 130, Universität des Saarlandes, April 1996.
(3) Bonner, A.; Shrufi, A.; Rozen, S.: LabFlow-1: A Database Benchmark for High-Throughput Worklfow
Management. In: P. Apers et al. (eds.): Proc. EDBT'96, Avignon, März 1996, 463 - 478.
(4) Müller, R.; Heller, B.: A Petri Net-based Model for Knowledge-based Workflows in Distributed Cancer
Therapy. Proc. EDBT-Workshop on Workflow Management Systems, Valencia, März 1998 (to appear).
(5) Kuhn, K.; Reichert, M.; Dadam, P.: Unterstützung der klinischen Kooperation durch Workflow
Management Systeme. Proc. 40. Jahrestagung der GMDS, 1995, 437-41.
(6) Reichert, M.; Kuhn, K.; Dadam, P.: Optimierung und Unterstützung von Leistungsprozessen im
Krankenhaus – Perspektiven, Erfahrungen und Grenzen. Proc. 20. Dt. Krankenhaustag, Hannover, June
1997, 668-682.
(7) Reichert, M.; Dadam, P.: ADEPTflex - Supporting Dynamic Changes of Workflows Without Loosing
Control. Journal of Intelligent Information Systems (JIIS), Special Issue on Workflow Management. 10
(2), March 1998, S. 93-129.
(8) Reichert, M.; Hensinger, C.; Dadam, P.: Supporting Adaptive Workflows in Advanced Application
Environments. Proc. EDBT-Workshop on Workflow Management Systems, Valencia, 1998 (to appear).
(9) Heinlein, C.; Kuhn, K.; Dadam, P.: Representation of Medical Guidelines Using a Classification-Based
System. Proc. 3rd Int'l Conf. on Information and Knowledge Management, Gaithersburg, Maryland,
Dezember 1994, 415-422
(10) Haimowitz, I. et al.: Temporal Resoning for Automated Workflow in Health Care Enterprises. In: Adam,
N., Yesha, Y. (eds.): Electronic Commerce: Current Research Issues and Applications, Springer, Berlin,
LNCS 1028, 1996, 87-113
