Guarded Process Spaces (GPS): A Navigation System
towards Creation and Dynamic Change of Healthcare
Processes from the End-user’s Perspective
Claudia Reuter1, Peter Dadam2, Stephan Rudolph3, Wolfgang Deiters3,
Simon Trillsch4
1 Zühlke Management Consultants AG, Wiesenstr. 10a,
8952 Schlieren, Switzerland
claudia.reuter@zuehlke.com
2 Ulm University, Albert-Einstein-Allee 11, 89081 Ulm, Germany
3Fraunhofer Institute for Software and Systems Engineering, Emil-Figge-Str. 91,
44227 Dortmund, Germany
{stephan.rudolph, wolfgang.deiters}@isst.fraunhofer.de
4University Hospital of Giessen and Marburg, Baldingerstr., 35033 Marburg, Germany
Abstract. Efficient process management becomes increasingly crucial for
hospitals to survive on a competitive market. Process management in this
domain must comply with individual conditions of patients and quickly react to
changing requirements and organizational parameters. With Guarded Process
Spaces (GPS) we developed a formally based concept that makes it possible to
enable end-users to create and flexibly change processes themselves. Our
approach makes use of existing BPM technology while abstracting from
technical interfaces and system-specific modeling paradigms. In this way, it
provides the basis to gain user acceptance and to achieve technological
independence.
Keywords: Healthcare process, clinical pathway, process flexibility, domain
specific languages
1 Motivation
Today, healthcare providers are facing the challenge of delivering high-quality
services while coping with increasing costs due to demographic change and medical
progress. In response to this, hospitals start with the introduction and deployment of
standard processes (so called “clinical pathways”) to organize the treatment of
patients according to a common set of symptoms, a diagnosis, or a therapy. In
principle, modern BPMSs (Business Process Management Systems) could help to
support clinical pathways in practice and to reduce administrative workload by
instantiating pathway templates for patients, documenting and monitoring their
progress, and managing work lists for doctors and nurses. However, in spite of their
potential benefit, BPMSs are barely in use in healthcare environments until now.
Originally, BPMSs have been developed to support production processes in
industry. In such settings processes typically shall be executed exactly as preplanned
to ensure that the goals in terms of quality and cost are met for all the products. In
clinical pathways, however, the focus must be put on the patient as individual being.
Therefore, in order to support clinical pathways using BPMSs one must be able to
solve the conflict between standardization of treatment processes on the one hand and
flexible deviation from standards due to case-based considerations on the other hand.
The fact that healthcare processes pose challenges to traditional BPMSs is not new
to the scientific community; frequently, they even serve as motivation for researchers
to investigate new approaches [1, 2]. In fact, flexibility and adaptivity during process
execution are broadly addressed in BPMS related research in the meanwhile [3].
Therefore, in the near future, we can expect that BPMSs come onto the market, which
allow for more process flexibility at runtime. However, supporting flexibility at the
BPM system level and making this feature usable by end-users are two different
stories. A direct interaction with a BPMS, e. g., to insert or to postpone a task requires
profound technical skills, which the medical staff is not able and not willing to
acquire. This means, one must find a solution, which enables end-users to flexibly
adjust clinical pathways according to the individual demands of a patient, but does not
force them to acquire deep system near skills in order to perform this task.
In context of the SPOT project (Service-based and Process-oriented Orchestration
Technology)1 we developed a concept and a prototype demonstrating that such kind
of system can be realized. The concept is based on the notion of “Guarded Process
Spaces” (GPS). The analogy to GPS navigation devices is intentional, because like
such devices, which can answer the question “Which roads are available to me now?”,
Guarded Process Spaces provide maps of possible directions a process can take and
guide the user’s decision making as to which paths they can follow to reach a valid
goal.
In this paper, we will focus on the benefit of GPS from the end-user’s perspective.
After a discussion of related work in chapter 2, we will introduce a novel navigation
paradigm towards process modeling, which is realized based on GPS in section 3. In
chapter 4 we will explain the technical implementation of GPS by way of a practical
example from the healthcare domain. After that, we will discuss requirements on
BPMSs in terms of process flexibility and show how these demands can be fulfilled
by GPS in combination with existing approaches from chapter 2. Finally, we will give
a short summary and an outlook on our future work.
2 Related Work
Process modeling languages used by process experts are usually too complicated for
end-users to model processes themselves. Therefore, domain specific languages
(DSL) are developed to facilitate process modeling for end-users in their application
1 See http://www.spot.fraunhofer.de
domain, like, e. g., public administration [4], workflow-based web applications [5],
integrated care [6], or medical guidelines [7]. Another example is the feature
modeling approach for modeling variability in product families [8], which has already
been applied to process management as well [9]. However, the provision of DSLs
alone is not sufficient without ensuring that the technical process templates which are
derived from such DSLs can be correctly executed by a BPMS. This means, that
DSLs without a proper and suitable formal basis are not very helpful to achieve this
goal. Due to the lack of formality of DSLs, they are often transformed into formal
languages, like e. g. Petri Nets [10], to perform correctness checks. However, this
doesn’t prevent the creation of erroneous process templates, which have to be
corrected afterwards which, in turn, delays the whole development process, decreases
user acceptance, and is certainly not acceptable in case of ad-hoc changes. Instead,
one has to provide a modeling environment which guides the user in such a way that
“technical” modeling errors (like deadlocks, incorrect or incomplete data flows, etc.)
are excluded as far as possible; and the same must hold for ad-hoc deviations at
runtime. The “correctness by construction” approach developed in the ADEPT project
[11-12] proved to be the best suited one for that purpose and, therefore, was very
influential for the development of respective concepts in GPS.
Assumed, we have a DSL with an adequate formal basis, the question remains how
to offer the required flexibility to an end-user (e.g., a physician) such that she herself
is able to adjust a clinical pathway according to the individual demands of her patient.
In recent years, the scientific community has made great technical advances
especially with regard to dynamic process management. [13], e.g., deals with shifting
existing tasks within a process instance under correctness constraints. Other authors
suggest maintaining the standard way of proceeding together with its variations within
the same process template [14-16]. Using respective workflow patterns, placeholder
activities (like, e.g., Proclets [17]) or variation points, it is possible to indicate the
positions, where alternative routes may be chosen or even created at runtime. The
advantage of these approaches is that end-users don’t have to comprehend the process
template and the usage of change operations to deviate from the standard proceeding.
The disadvantage is that such approaches require that the positions where alternative
routes may be chosen have to be fixed in advance, which does not reflect the reality in
healthcare. E. g., certain conditions, such as infections, can occur at any point in time.
Therefore, these simple solutions are falling short of covering these demands. End-
users must be able to flexibly change the process structure at runtime.
In [11-12] it is illustrated how an end-user interface to perform an ad-hoc change
could be implemented using the application programming interface of the ADEPT2
system. In this example the user wants to insert a new task into the process. After
having selected the desired task, the system shows him a simplified process graph
within which he can select a process step. This selection informs the system that the
new task shall become executable after this task. Then the system allows him to
choose another process step, before which the new task must be completed. Based on
this information the system determines where and how the new task is inserted (as
serial or parallel step) and performs the necessary transformations of the process
graph. Although this approach does not require system-near knowledge to perform
such a task, it confronts the user with a different and rather “technical view” of the
clinical pathway compared to the GPS approach for process modeling. The goal of
GPS is to apply the same user-oriented metaphors for ad-hoc deviations as in case of
process modeling.
3 Guarded Process Spaces: Applying the Navigation Paradigm to
Process Modeling
Our investigations during the SPOT project were driven by the following objectives:
Firstly, it must be possible for end-users to design process templates from their
business point of view and to automatically execute them using a chosen BPM
system. Secondly, end-users must be enabled to change processes both at modeling
time and at runtime on a case by case basis.
As already mentioned, we apply a navigation paradigm to process modeling which we
call Guarded Process Spaces (GPS). Due to lack of space, we cannot describe this
approach in detail in this paper. Instead, we will introduce GPS informally and point
out their usage by the clinical staff. A detailed and formal description can be found in
[18, 19] (where GPS correspond to so called “SPF-type graphs”). From a user's point
of view a GPS acts like a navigation system, which uses a given set of streets to offer
routes and alternative routes from the current location to the desired destination. At
technical level a GPS consists of a set of nodes and has a tree-like structure. The
nodes represent navigation points, which are used to implement rules on the selection
of process activities. The root of the GPS represents the starting point, from where
"travels" can be planned. Like a navigation system, the Guarded Process Space
indicates all potential traveling options. By selecting an option, a user is travelling to
the next navigation point within the coordinate network; there, further traveling
options are available. With every step that a user takes, the amount of traveling
options to approach the final destination decreases. The selected route from the
starting point to the destination defines an executable clinical pathway.
We illustrate process modeling from the user’s perspective by means of a practical
example. During their inpatient stay, some patients experience shortness of breath, the
reason for which can be a bacterial pneumonia or a left heart failure. The clinical staff
shall develop clinical pathways that coordinate the diagnostics of one of these
diseases as well as both of them together. Fig. 1 illustrates how this is done.
According to the GPS, the pathway for all clinical diagnostics is divided into different
categories, such as “Radiology” or “Laboratory”. These categories represent the
navigation points within the GPS and may contain further specialized navigation
points. E. g., the navigation point “Radiology” comprises a chest X-ray examination
and encapsulates further radiological activities within navigation point “Additional
radiology”. Now, the modeler team can decide whether or not additional examinations
should be scheduled within the clinical pathway by default.
The pathway modeler team navigates through the GPS in order to develop a
clinical pathway for the diagnostics of bacterial pneumonia. All tasks they select will
be included in the pathway. After having made all these choices, the clinical pathway
is determined and an executable process template can be generated. As we will see
later, this does not mean that the resulting clinical pathway is now completely
inflexible.
Fig. 1. Modeling clinical pathways from the end-users’ perspective.
If needed, the end-user (e.g., the ward physician) can repeat tasks or can “reactivate”
deselected tasks in the context of ad-hoc deviations at runtime to adjust the clinical
pathway to the individual needs of a specific patient.) By performing process
modeling this way, the end-users can mentally completely stay in their “world” and
just select the tasks to be performed. All the other aspects like setting up the resulting
control flow, the data flow, deadlock avoidance, and other things are handled at GPS
system level and do not bother him. In addition, the GPS also “knows” which tasks
depend on each other or, just the opposite, exclude each other. This means that certain
kinds of mistakes are automatically avoided.
4 Implementation of Guarded Process Spaces
Fig. 2 illustrates how the support for this navigation and decision process is
implemented at the technical level. The graph on the left side corresponds to the GPS
and the graph on the right side represents the currently developed clinical pathway.
The nodes in the GPS graph represent either tasks or logical operators like, e.g., AND,
XOR, OR, and OPT (for optional). In Fig. 2, the root node “Clinical diagnostics” is
connected with an AND-operator, i. e., all child nodes have to be selected. According
to the OPT-operator at “Additional radiology”, it is possible to choose an arbitrary
number of child nodes or none at all.
Since AND-operators don’t leave many options, a big part of the clinical pathway
can be automatically derived from the GPS in this case. E. g., a chest X-ray always
includes some laboratory examinations and reporting to the ward physician. With
regard to the possible variations “Additional radiology” and “Additional laboratory”
the modeler have to decide which ones (if any) shall occur in the clinical pathway.
Fig. 2. Modeling of a clinical pathway for diagnostics of bacterial pneumonia based on GPS.
For diagnostics of pneumonia a throat swab is required. Therefore, the modeler team
selects “Throat swab” from the navigation point “Microbiology”. After that, the
clinical pathway for bacterial pneumonia is complete. In order to obtain the pathway
for diagnostics of left heart failure, the modelers must only take a slightly different
route with respect to some navigation points.
As indicated above, the GPS can also contain constraints determining the
execution order of process activities within the clinical pathway. Constraints are
defined as edges connecting GPS nodes on a horizontal axis. E. g., it can be
expressed, that the activity “Reporting of radiological results” must not be scheduled
as long as “Chest X-ray” and optionally “Additional radiology” are not finished. One
could also state that some nodes may require or exclude other nodes. In addition, one
can specify constraints for node cardinalities. A node cardinality defines the
maximum number of times that a clinical pathway may contain a set of process
activities. This feature can be used to model cyclic treatments. In [18, 19] formal
correctness criteria are defined to ensure that constraints cannot contradict each other
and are in conformance with the GPS structure and its logical operators. Due to
flexibility options, kind and amount of data objects the system has to deal with at
runtime may vary. This means, the application components that implement process
activities must cope with variable data input and output. In [19], an interface
specification of process activities is defined, which among others specifies both
mandatory and optional data input and output. Moreover, it is described how data
dependencies can be considered at GPS level. Further aspects, like e. g. data storage
and versioning, must be handled at technical level and are out of scope of the GPS
approach.
In general, the more process knowledge a GPS captures, the easier the creation of
clinical pathways and – finally – executable process templates becomes for the
clinical staff. To make the creation of clinical pathways by end-users as easy as
described above, the GPS graph must comprise all potential tasks, choices, and
relevant constraints of the considered application area. The range of applicability, the
acceptance of the GPS based modeling environment, and the resulting executable
clinical pathways depend on the degree to which this graph covers the application
area. The clinical staff can (and must) help to develop the initial hierarchical structure
of a GPS and to identify relevant process activities. The implementation of the GPS
itself, the implementation of activities by executable application components, user
interfaces, and task-specific control and data flow aspects will require IT-specialists.
To decrease the complexity of this task one can take a stepwise refinement approach
by first modeling the GPS graph rather coarsely and re-examine it with end-users
using the modeling environment. Then one refines one or several nodes and checks it
again, etc.
5 Enabling Process Change from the End-user’s Perspective
With GPS, end-users are now in the position to create various clinical pathways using
the offered navigation paradigm. However, in healthcare it is often not possible to
plan the complete treatment process in advance. Instead, the treatment process
develops depending on further insights gained during the execution of the process.
Under certain circumstances, it may even become necessary to abandon the original
plan, to return to a specific point, and to choose a different option. Therefore, in this
chapter we describe healthcare-specific requirements on process flexibility and
discuss how they can be addressed using GPS in combination with existing BPMSs.
Flexible extension of pathway instances. Although, the modelers of clinical
pathways determine medical treatment to a large extent, some decisions can only be
made by the doctor in charge of the patient. With regard to our pathway example,
each patient who is suspected to suffer from bacterial pneumonia will undergo a
throat swab. After that, the further proceeding depends on whether the finding is
positive or negative. Assuming, the finding is positive, then the GPS specifies the
available options; i. e., to carry out a bronchoalveolar lavage (cf. Fig. 2). When
selecting this choice, the GPS may enforce an application constraint, e.g., that a
bronchoalveolar lavage is only possible if the patient has been transferred to the
isolation ward first in order to prevent the spreading of the disease. If this case is not
rare to occur, the pathway modelers will have anticipated this additional examination
along with the associated tasks and may offer it in terms of conditional branches,
placeholder activities or variation points.
Minor deviations from clinical pathways. Clinical pathways specify the standard
way of proceeding. Accordingly, the pathway for diagnostics of bacterial pneumonia
only schedules a chest X-ray in the course of radiological examinations. However, in
certain cases, it can become necessary to perform additional procedures. For example,
the ward physician examines the chest X-ray and the lab results of her patient. As it is
not possible to confirm the diagnosis on the basis of these findings, she decides on
scheduling a computed tomography. This examination is not part of the clinical
pathway by default. Therefore, in the context of radiology a deviation from the
pathway occurs. After changing the configuration of the navigation point “Additional
radiology”, the new task is added to the work list of the responsible radiologist. Fig. 3
indicates how end-users can handle minor deviations from clinical pathways using the
GPS approach.
Fig. 3. Ad-hoc change of pathway instances from the end-user’s perspective.
First, one has to signal the need for deviation from the process standard by clicking
the button “deviate from pathway” within the user interface. Then, the end-user can
choose additional radiological examinations, which are available in the context of the
navigation node “Additional radiology” of the GPS. By selecting one or more
examinations, the end-user changes the pathway schedule in an ad-hoc manner.
Provided that the position where such a deviation may happen is known in advance, it
is sufficient to use conditional branches, placeholder activities, or variation points in
order to technically realize this ad-hoc change. Frequently, it is not so clear at which
point of time a variance arises, however. Regarding the GPS, it is not important when
the physician decides to deviate from the pathway. The GPS may define constraints
that determine the position where a computed tomography should be performed at
best. However, if the execution flow has already passed this position, the examination
may be scheduled at the next possible place.
Complex deviations from clinical pathways. The detection of second diagnoses or
complications may result in more complex deviations from clinical pathways. E. g., a
physician chose the pathway for diagnostics of bacterial pneumonia for her patient.
During the treatment she discovers symptoms that indicate a left heart failure. She
decides to modify the process in a way that it also covers the procedures for this
second diagnosis. So, changes can not only occur at isolated spots, but may affect
several regions of a process. In our example the doctor would have to insert the
activities “Analysis of cardiac parameters” within “Laboratory” and
“Echocardiography” within “Additional radiology”. Such complex deviations may
significantly increase the effort of physicians to perform the change of the pathway
and thus raise the probability of errors. Therefore, if the pathway modelers have
anticipated such a situation, they could have provided process variants, which
encapsulate all the changes that have to be made to perform a pathway modification
of this kind. In this way, it is even feasible to specify standard ways of proceedings in
case of deviations from clinical pathways [19].
Since process variants automate the execution of change operations, it must be
ensured that they are in conformance with the medical treatment and the procedures,
which have been undertaken so far. As a GPS already determines all the routes that
processes may take, possible variations, and relations between certain activities, it can
also be used to verify that changes in the context of a process variant do not contradict
previous treatment.
6 From GPS-based Clinical Pathways to Executable Processes
The clinical pathway conforms to the tree-like structure of the GPS graph, but
contains only those process activities, which have been selected for the pathway under
consideration (cf. Fig. 2). To obtain independence from a specific BPMS, the GPS
graph as well as this “clinical pathway graph” serve as a neutral representation which
is mapped to process templates of the chosen BPMS to achieve executable processes.
To support the full spectrum of possibilities as well as to make this mapping simple,
the ideal target BPMS should support the full spectrum of ad-hoc deviations as
provided by ADEPT2 [1, 11-12], for example, late binding of dynamically composed
complex activities like those described in [15] or as provided by YAWL’s proclet
approach [17], as well as process variants like those described in [16].
Among these desirable BPMS features, the requirement for the full spectrum of
supported ad-hoc deviations is the most relevant one. If this feature is present,
concepts like late binding and process variants can be handled by the mapping layer
which acts as a broker between the GPS runtime for the “clinical pathway graph” and
the underlying BPMS. If this feature is missing or available only in a rather limited
fashion then the mapping will result in complex process graphs, because now the
most relevant choices and variants have to be incorporated in the process graph from
the very beginning. Besides complexity aspects, incorporation of all choices and
variants does not only contradict the concept of clinical pathways that must define
standards of medical treatment instead of all possible variations; it also cannot
provide the full spectrum of flexibility, which is needed in the clinical domain, as we
will show in fig. 4.
Among the available BPMS ADEPT2 [1, 11-12] resp. its commercial version, the
AristaFlow® BPM Suite2 was closest to the “ideal” BPMS sketched above. It,
therefore, was selected as the target BPMS for the proof of concept prototype. In [19]
one can find the formally defined transformation rules according to which the
compilation to GPS-based clinical pathways to the ADEPT2 process model takes
place. Fig. 4 shows in which way the process activities within the context of
“Radiology” (cf. Fig. 2) can be mapped to executable ADEPT2 process templates. As
radiology comprises both default and optional activities, there are two mapping
alternatives in ADEPT2: Either conditional branches are used or the additional
activities can be inserted into the process instance on demand.
2 See http://www.AristaFlow.com
Fig. 4. Mapping the “clinical pathway graph” to ADEPT2 process templates.
According to the constraints of the GPS, the reporting activity should follow the
examinations, whereby the chest X-ray has to be performed first. As several or none
of the additional examinations can be selected, in alternative 1 we have to insert a
complex construct consisting of a parallel as well as three conditional branches. In
alternative 2, we only schedule the default activities and perform ad-hoc insertions on
demand depending on the current state of the execution. In Fig. 4.a, the reporting
activity has already started as a deviation occurs. Thus, it is not possible to insert the
computed tomography directly after the chest X-ray, anymore. Instead, it can be
added in parallel to the running activity as illustrated in Fig. 4.b. This example shows
that the mapping between pathway graph and process template is much simpler and
more flexibly than realizing complex workflow patterns. Furthermore, one can clearly
distinguish the process standard from its variations. Consequently, BPMSs providing
comprehensive support for ad-hoc changes at the API level like, e.g., ADEPT2, are
ideal candidates for this approach. As indicated above, other BPMSs can be supported
as well, but one is faced with limited flexibility and with more complex
implementations of the mapping and runtime layer to compensate the missing
functionality.
7 Summary
In spite of their potential benefits, BPMSs are not broadly used in healthcare settings
yet. In order to be accepted by end-users, the technology has to fulfill the following
requirements: Clinical staff must be enabled to model executable process templates by
themselves. Moreover, end-users must have the possibility to flexibly adapt running
process instances according to the individual demands of their patient. With Guarded
Process Spaces (GPS), we presented an approach which uses a “navigation paradigm”
to guide end-users in modeling clinical pathways as well as to assist them to perform
ad-hoc deviations at runtime for a patient with specific needs. We showed how this
approach supports users to select the necessary tasks in the right order and how tasks
can be automatically inserted when required in the given context. We also gave some
insights how this guidance is reflected in the underlying implementation. The
approach is based on a sound formal concept which could only be sketched here due
to lack of space, however. A comprehensive description can be found in [19]. Another
goal of the SPOT project was to base creation and change of clinical pathways on a
system-neutral, conceptional layer, which is independent from specific process
modeling languages and BPMSs. We provide mapping functions to transform clinical
pathways derived from GPS into executable process templates of the chosen target
engine and verified this approach by a proof of concept implementation using
ADEPT2. In this way, the user interfaces for process modeling and adaptation can
remain the same, even if the underlying BPM-technology changes.
In the context of the current project “eBusiness Platform for Healthcare”3, we are
planning to use the GPS approach to develop medical processes crossing the border of
individual healthcare provider institutions. By doing so, GPS are leveraging execution
of integrated workflows based on collective knowledge and in spite of heterogeneous
system environments.
Acknowledgements
We want to thank the AristaFlow team, especially Kevin Göser, for the support during
the development of the proof of concept prototype.
References
1. Reichert, M., Dadam, P.: ADEPTflex – Supporting Dynamic Changes of Workflows
Without Losing Control. In: Journal of Intelligent Information Systems 10, pp. 93—128
(1998)
2. Dadam, P., Reichert, M., Kuhn, K.: Clinical Workflows - The Killer Application for
Process-oriented Information Systems?. Proc. Int'l Conf. on Business Information Systems,
BIS 2000, 4th Int'l Conf., Poznan, Poland, April 2000, Springer-Verlag, pp. 36—59 (2000)
3. Weber, B., Sadiq, S., Reichert, M.: Beyond Rigidity - Dynamic Process Lifecycle Support -
A Survey on Dynamic Changes in Process-aware Information Systems. Computer Science -
Research & Development, Vol. 23, No. 2, 2009, special issue on "Flexible Process-aware
Information Systems", pp. 47—66 (2009)
4. Becker, J., Pfeiffer, D., Räckers, M.: Domain Specific Process Modelling in Public
Administrations – The PICTURE-Approach. In: Electronic Government, Lecture Notes in
Computer Science 4656, pp. 68—79 (2007)
5. Freudenstein, P., Buck, J., Nussbaumer, M., Gaedke, M.: Model-driven Construction of
Workflow-based Web Applications with Domain-specific Languages. Proc. of the 3rd Int’l
Workshop on Model-driven Web Engineering (MDWE’07), Como, Italy, 2007
6. Neuhaus, J., Houta, S., Reuter, C.: Ansätze bei der Umsetzung von Behandlungsplanpfaden
– Flexibilisierungskonzepte am Beispiel der Behandlung von Wirbelsäulenerkrankungen.
In: Hellmann, W., Eble, S. (eds): Ambulante und Sektoren übergreifende
Behandlungspfade, pp. 79-97, Medizinisch Wissenschaftliche Verlagsgesellschaft Berlin
(2010)
3 See http://www.ebpg-nrw.de/
7. De Clercq, P., Kaiser, K., Hasman, A. : Computer-interpretable Guideline Formalisms. Ten
Teije, A. et al. (eds.): Computer-based Medical Guidelines and Protocols: A Primer and
Current Trends, IOS Press, pp. 22—43, 2008
8. Kant, K., Cohen, S., Hess, J., Nowak, W., Peterson, S.: Feature-oriented domain analysis
(FODA) feasibility study. Technical report CMU/SEI-90-TR-21, Software Engineering
Institute, Carnegie Mellon University, Pittsburgh, USA, 1990
9. Puhlmann, F., Schnieders, A., Weiland, J., Weske, M.: Variability Mechniasms for Process
Models. PESOA-Report TR 17/2005, Process Family Engineering in Service-Oriented
Applications (PESOA), 2005
10. Beccuti, M., Bottrighi, A., Franceschinis, G., Montani, S., Terenziani, P.: Modeling
Clinical Guidelines through Petri Nets. Combi, C., Shahar, Y., Abu-Hanna, A. (eds.): Proc.
of the 12th Conf. on Artificial Intelligence in Medicine (AIME’09), pp. 61—70, Springer-
Verlag Berlin, Heidelberg, 2009
11. Dadam, P., Reichert, M.: The ADEPT Project: A Decade of Research and Development for
Robust and Flexible Process Support. Computer Science - Research & Development, Vol.
23, No. 2, special issue on "Flexible Process-aware Information Systems", pp. 81-98 (2009)
12. Reichert, M., Dadam, P.: Enabling Adaptive Processes with ADEPT2. In: Cardoso, J.; van
der Aalst, W.M.P. (Eds.): Handbook of Research in Business Process Modeling.
Information Science Reference (an imprint of IGI Global), pp. 173-203 (2009)
13. Igler, M. Moura, P. Faerber, M. Zeising, M. Jablonski, S.: Modeling and planning
collaboration using organizational constraints. Proc. Collaborative Computing: Networking,
Applications and Worksharing (CollaborateCom 2010), Chicago, Ill., Oct. 2010
14. Russell, N., ter Hofstede, A.H.M., van der Aalst, W.M.P., Mulyar, N.: Workflow Control-
Flow Patterns: A Revised View. BPM Center Report BPM-06-29, BPMcenter.org, 2006
15. Sadiq, S., Sadiq, W., Orlowska, M.: Pockets of Flexibility in Workflow Specification. In:
Proc. of the 20th Int’l Conf. on Conceptional Modeling, LNCS, vol. 2224, pp. 513—526,
Springer, Berlin Heidelberg (2001)
16. Hallerbach, A., Bauer, T., Reichert, M.: Configuration and Management of Process
Variants. In: vom Brocke, J., Rosemann, M. (eds.): Handbook of Business Process
Management (2009)
17. R.S. Mans, N.C. Russell, W.M.P. van der Aalst, A.J. Moleman, and P.J.M. Bakker:
Proclets in Healthcare. BPM Center Report BPM-09-05, BPMcenter.org, 2009
18. Reuter, C.: Composition of Semantic Process Fragments to Domain-related Process
Families. In: van Bommel, P., Hoppenbrouwers, S., Overbeek, S., Proper, E., Barjis, J.
(eds.): The Practice of Enterprise Modeling (PoEM 2010), LNBIP 68, pp. 61—75, Springer
Berlin-Heidelberg (2010)
19. Reuter, C.: Modellierung und dynamische Adaption klinischer Pfade auf Basis
Semantischer Prozessfragmente (SPF). PhD thesis, Technical University of Dortmund,
Germany, Computer Science Faculty, 2011
