FROM MEDICAL PROCESSES TO WORKFLOWS
Modeling of Clinical Pathways with the Unified Modeling Language
Christian Mauro, Tobias Happle, Ali Sunyaev, Helmut Krcmar
Information Systems, Technische Universitaet Muenchen, Boltzmannstr. 3, 85748 Garching, Germany
Jan Marco Leimeister
Information Systems, Universitaet Kassel, Nora-Platiel-Strasse 4, 34127 Kassel, Germany
Keywords: Clinical Pathways, Workflows, UML, Workflow Management Systems, Process Modeling.
Abstract: Clinical pathways describe treatment processes within a hospital. They can be used as process models,
which can be controlled by implemented workflow models in information systems. This enables (semi-)
automated processes, and they are therefore high potential for an improved quality management and
seamless IT support. Surprisingly, there are no published process models that describe the implementation
of clinical pathways in an information system while taking into account the characteristics of health care
specifics. We bridge this gap by proposing a process model using UML as modeling language.
1 INTRODUCTION
Clinical pathways specify concrete treatment
activities for patients with identical diagnoses or for
patients diagnosed differently but treated by
employing the same therapy (Engemann and Strobel,
2005). This standardization of the activities serves as
a cost saving factor because of its short delay time as
well as its quality assurance. Process descriptions
can be populated in hospital information systems or
in autonomous workflow management systems
(WfMS) (Allen and zur Mühlen, 2000) through
editors for effective information technology (IT)
support of the pathways. Hereby, essential parts of
the necessary communication and coordination
between the actors can be automated and the
effectiveness, as well as the efficiency of the
processes, can be improved.
Despite the advantages of this process control,
there is no process model published that describes
the implementation of clinical pathways in
information systems, considering the characteristics
of the clinical environment, such as the robust
clinical pathway structure in treatment phases. This
paper bridges this gap by introducing a process
model using the Unified Modeling Language (UML)
2.0, which is suitable for the implementation of
clinical processes (Becker, 2006), (Lang et al., 2006)
and is a widespread official standard of the Object
Management Group.
2 PROCESS MODEL
Models serve as a simplified description of reality.
In order to reduce complexity or to increase the
comprehensibility of the figures, one should employ
different views and modeling layers in the
representation of these systems (Gadatsch, 2005).
One is able to distinguish three modeling layers:
business process, functional workflow and technical
workflow, which are differentiated by their
proximity to the IT (Wittges, 2005). In contrast to
the business process which describes the activities to
be executed in a pure functional manner, the
functional workflow layer concentrates on the
description of work processes with regard to the
requirements that result from the technical support
of the execution of workflows by an information
system (Gadatsch, 2005), (Jablonski et al., 1997).
Due to the different focus of both modeling layers
(functional process vs. implementation supported by
IT), the use of successive modeling of a real process
is recommendable: first within the business process
layer and then in the workflow layer. In the end, the
functional and producer-independent workflow-
388
Mauro C., Happle T., Sunyaev A., Krcmar H. and Leimeister J. (2010).
FROM MEDICAL PROCESSES TO WORKFLOWS - Modeling of Clinical Pathways with the Unified Modeling Language.
In Proceedings of the Third International Conference on Health Informatics, pages 388-391
DOI: 10.5220/0002695103880391
Copyright
c
SciTePress
model is transformed by a workflow-editor into a
producer-specific model which can be automatically
executed (technical workflow layer). For the sake of
clarity, the process model for transformation of
clinical pathways will be divided hereafter into
modeling layers.
2.1 Modeling of Clinical Pathways in
the Business Process Layer
The modeling of clinical pathways in the business
process layer is organized in phases which will be
explained in the next sections.
2.1.1 Pathway Selection and Process
Analysis
The IT implementation of clinical pathways is, in
contrast to payment in kind processes, not always
accomplishable because of the high variation in the
process input factors (Gadatsch, 2005),
(Schneeweiß, 2002). The high variation of process
relevant properties, such as age, sex, or diverse
previous diseases, hinders the prediction and the
adherence of particular treatment processes and
treatment outcomes. In order to implement clinical
pathways in information systems, taking into
consideration the costs resulting from it, one can
employ only pathways with patients which promise
cost saving potentials because of their frequent
appearance and/or the corresponding treatment costs
or because of adequate homogenous patient groups,
whose processes differ insignificantly (Fischbach
and Engemann, 2006), (Thun, 2006).
One-person interviews with selected
professionals involved in the process (from nursing,
medical or administrative departments) are
documented in order to collect information about the
current treatment processes. Organizational delays
often cause at least a two-day duration of the
interviews. Both rounds of talks should be at least
three working days away from each other since
during this time period the start of the modeling
should be planned. Thus, knowledge gaps in the
process execution can be identified and prompted in
the following interviews. The interviews must be
recorded on audio tapes because the complexity of
the processes makes written documentation difficult
during long talks. Documents relevant for the
process execution should also be provided to be
analyzed.
2.1.2 Cases – Preliminary Design
Since with a single clinical pathway different disease
patterns can possibly be treated and these variations
can be demanded during the process execution,
different alternatives of the pathway must be
distinguished and modeled separately. Therefore,
one can discern cases which summarize patient
groups of one pathway, for whom an identical
treatment process is obligatory. Business partners
(for instance, general practitioners or medical
specialists) initiate the cases which, in order,
determine to a greater extent, the starting point of
the model. Activity diagrams and standard elements
in UML 2.0 are used for modeling of the various
cases.
Treatment processes in the clinical field exhibit
robust structure of the activities to be executed into
treatment phases; especially in post-operative
treatment processes, the activities are also structured
into treatment days. The treatment phase in which a
process is being executed has an impact on the
concrete execution of some diagnostic processes too.
Therefore, the activity diagrams necessary for the
modeling are, at first, divided into treatment days
and phases in order to ease the further matching.
Since UML 2.0 provides no suitable elements for
visualization of time spans within an activity
diagram, and isolated modeling of the days and
phases (for example in separate activity diagrams) is
usually not possible because of the large number of
interdependencies, day and phase changes are
presented as a Fork/Join element. The naming of the
activities and the actions are expressed from a
clinical institution's point of view (Oestereich et al.,
2003). For instance, “dispense medicaments” would
be used instead of “receive medicaments.”
In the context of examination and approval
processes, information flows are presented as
Send/Receive UML objects. When using
Send/Receive objects, one must note from which
organizational unit the signal originates and for
which one it is intended. Both objects are connected
through an information flow. Because of the acute
cases of emergency and the chronic overload of the
clinical personnel, an important condition for the
composition of clinical treatment processes is their
flexible and appropriate adaptation. Thus, the
workload of the necessary resources determines, to a
greater extent, the time for the execution of activities
that are not critical (especially in post-operative
phases). In order to achieve the necessary flexibility
in the form of a modeling paradigm, one would
better use parallelization of actions and activities
instead of sequential arrangement if the latter is not
compulsory because of the corresponding
interdependencies.
Knowledge gaps in the process execution are
FROM MEDICAL PROCESSES TO WORKFLOWS - Modeling of Clinical Pathways with the Unified Modeling
Language
389
noted during the modeling as notices in the activity
diagram and in a notice list. These gaps are handled
as checklists during the talks that follow.
2.1.3 Final Case Design and the Role Model
During the modeling of the case preliminary design,
organizational and role models are produced
simultaneously, for which the relevant
organizational units within a class diagram are
modeled by using an organigram. After all
interviews are completed, an actor model is
developed within a use case diagram. The model
contains all identified roles and additional features
for which an assignment from activities to people is
required. The modeled organizational units are
detailed by the identified actors.
Subsequently, the pathway on the business
process level is completed after the modeling of the
case final design. For that purpose, activities are
consolidated, the process logic is specified, and the
roles and functions contained in the process are
displayed by Swimlanes, which represent the
schedule of responsibilities. In case different actors
can process activities or decisions about the process
sequence, they are placed on the strip line of the
Swimlanes, or if there are more than two different
actors, tags are intended to represent them. Tags can
also serve, for instance, as containers for additional
information describing the content of the activities.
In addition, the creation of specific stereotypes,
which change the visualization of the activities,
depending on the tags, might be reasonable. Finally,
a glossary of the used technical terms is created.
2.2 Modeling of Clinical Pathways on
Workflow Level
After the pathway has been modeled on the business
process level, its modeling on technical workflow
layer follows. The modeling of single cases is
implemented in separate activity diagrams, whereas
the modeling is focused on the organizational,
operative, and data-oriented content (Lang et al.,
2006). Organizational aspects are very significant
because of the highly specialized job descriptions in
health care (Ziegenbein, 2001). The important
meaning of the data-oriented aspects results mainly
from extensive documentation requirements and the
generally high information requirements of patients'
treatment processes.
2.2.1 Representation Elements
A central element of the representation within the
technical workflow layer is the work item – a
stereotype of the UML class Action that
encapsulates the interaction of a system with human
actors in a black box. The element work item can be
interpreted as an IT representative of an activity to
be processed in a work list handler, and it enables
the interaction between a user and the information
system. The work item conceals the concrete
technical implementation of the communication, but
despite that, allows a simple representation of
interactions which control the execution of the
pathway. Generally, three basic use cases of an
interaction are possible: a notification about the
present tasks without additional presentation and/or
documentation of data, the optional, and the required
presentation and/or documentation of information.
The actors, who process the work item, are modeled
explicitly and attached to it. Moreover, for each of
them the corresponding organizational unit is
indicated.
2.2.2 Modeling in the Technical Workflow
Layer
The modeling in the technical workflow layer is
basically divided into three phases. In the first one,
the sub-processes which are to be implemented on
the system are selected and holistically modeled.
Very suitable for implementation on this layer are
diagnostic methods, periodic or recurrent processes
(such as measurement and documentation of vital
parameters) and common administrative processes,
in whose execution a multitude of actors participates
and which possesses a sufficiently high grade of
structuring of the work processes.
During the implementation of multiple pathways,
these sub-processes are separated and categorized
into delimitable use cases and specific variants in
order to develop standardized processes that can be
reused in a variety of pathways. However, these
process libraries that originate from them are not the
subject of this brief paper. If, however, only one
pathway is transferred into an information system,
then the development of standards and variants is
not urgently required but still reasonable because
such complex pathways can be structured
systematically.
After the creation of a domain model or a state
model, the complete pathway including the
necessary process logic is modeled into an activity
diagram. Thereby, the subdivision into phases
should be kept because this structure is used, for
example, for the assignment of success factors, and
the following treatment steps are activated partly on
presentation of particular success factors, whereby
this structure is exceptionally suitable for control of
HEALTHINF 2010 - International Conference on Health Informatics
390
the treatment progress or for regulation and enabling
the following treatment phases.
3 SUMMARY AND OUTLOOK
A process model was presented which describes the
implementation of developed (paper-based)
pathways in an information system. Unified
Modeling Language 2.0 was used as a modeling
language. Initially, clinical pathways were modeled
in their functional sequence (business process layer),
afterwards selected subsequences were implemented
in the second modeling layer in regard to IT
requirements (functional workflow layer).
The effort during the implementation of numerous
pathways in an information system can be
considerably reduced by the employment of patterns
for subsequences and for the sequential structure of
the whole pathway. Due to space restrictions, the
approach for the identification and systematization
of clinical processes in a process library is not part
of this paper. The efforts implied by the
implementation of clinical pathways can be
considerably reduced by the procedure model and
the approach for development of a process library.
In the present research paper, problems with
respect to the implementation of clinical pathways in
an information system have been examined but not
the technical capabilities of such implementation.
Therefore, further research must clarify which
requirements need to be met by such an information
system and especially by a workflow editor within
the information system, i.e., which technology
solutions are suitable for the implementation of
process control in the clinical field. This research
paper has shed light on the significance of
comprehensive pathway templates; however, it must
be clarified in further research how such pathway
templates can be identified and delimited. The
verification of the approach methodology described
here on other clinical pathways is also a goal of
further research.
REFERENCES
Allen, R. & zur Mühlen, M. (2000) Embedded vs.
Autonomous Workflow – Putting Paradigms into
Perspective. IN Fischer, L. (Ed.) Excellence in
Practice IV - Innovation and Excellence in Workflow
and Knowledge Management. Lighthouse Point.
Becker, K. (2006) Prozessanalyse zur Entwicklung
integrierter Behandlungspfade. IN Eckardt, J. & Sens,
B. (Eds.) Praxishandbuch integrierte
Behandlungspfade – Intersektorale und sektorale
Prozesse professionell gestalten. Heidelberg,
Economica Verlag.
Eckardt, J. (2006) Was sind integrierte Behandlungspfade.
IN Eckardt, J. & Sens, B. (Eds.) Praxishandbuch
integrierte Behandlungspfade – Intersektorale und
sektorale Prozesse professionell gestalten. Heidelberg,
Economica Verlag.
Engemann, R. & Strobel, U. (2005) Behandlungspfade zur
Unterstützung der ambulanten und kurzstationären
sowie der fast-track-Chirugie. Viszeralchirugie, 40,
95-103.
Fischbach, W. & Engemann, R. (2006) Interdisziplinärer
Behandlungspfad bei kolorektalem Karzinom. Der
Internist, 47, 720-728.
Gadatsch, A. (2005) Grundkurs Geschäftsprozess-
Management, Wiesbaden, Vieweg Verlag.
Greiffenberg, S. (2004) Methodenentwicklung in
Wirtschaft und Verwaltung, Hamburg Verlag Dr.
Kovač.
Jablonski, S., Böhm, M. & Schulze, W. (1997) Workflow
Management – Entwicklung von Anwendungen und
Systemen, Heidelberg, dpunkt.verlag.
Kazmeier, J. (1998) Modellierung soziotechnischer
Systeme im Requirements Engineering bei
betrieblicher Software. Institut für Informatik.
München, Technische Universität München.
Lang, M., Bürkle, T., Laumann, S., Bauer, J. & Prokosch,
H.-U. (2006) Modeling the Radiology Workflow: A
hands-on Comparison on established Process
Modeling Languages. 51. Jahrestagung der GMDS
Leipzig. German Medical Science.
Oestereich, B., Weiss, C., Schröder, C., Weilkiens, T. &
Lenhard, A. (2003) Objektorientierte Geschäfts-
prozessmodellierung mit der UML, Heidelberg,
dpunkt.verlag.
Schneeweiß, C. (2002) Einführung in die
Produktionswirtschaft, Berlin, Springer Verlag.
Thun, S. (2006) Projektmanagement zur praktischen
Umsetzung von integrierten Behandlungspfaden. IN
Eckardt, J. & Sens, B. (Eds.) Praxishandbuch
integrierte Behandlungspfade – Intersektorale und
sektorale Prozesse professionell gestalten. Heidelberg,
Economica Verlag.
Wittges, H. (2005) Verbindung von
Geschäftsprozessmodellierung und Workflow-
Implementierung, Universität Hohenheim.
Ziegenbein, R. (2001) Klinisches Prozessmanagement –
Implikationen, Konzepte und Instrumente einer
ablauforientierten Krankenhausführung, Münster.
FROM MEDICAL PROCESSES TO WORKFLOWS - Modeling of Clinical Pathways with the Unified Modeling
Language
391