1 Introduction

Healthcare systems are among the most complex and challenging organizational environments [1]. Healthcare organizations are becoming more and more fragmented into specialized and integrated functional units, which cooperate and exchange information to provide primary, secondary, and specialist care [2]. Healthcare organizations operate by enacting a wide range of processes with different characteristics and requirements, spanning from those capturing clinical procedures, such as diagnosis and treatment, to those representing organizational and administrative tasks, such as examination planning and patient transfer [3]. Yet, clinical and organizational processes are not independent, but rather complementary and intertwined.

Among the many kinds of healthcare processes, care pathways received increasing attention in the last years, as they consider both organizational requirements and clinical tasks. Care pathways have been defined in slightly different ways, according to different perspectives. Here we consider two widely acknowledged definitions. The first one specifies that “A care pathway is a complex intervention for the mutual decision-making and organization of care processes for a well-defined group of patients during a well-defined period” [4], while in [5] integrated care pathways are defined as “structured multidisciplinary care plans which detail essential steps in the care of patients with a specific clinical problem.” Both definitions contain some common elements that characterize care pathways. Among them, we underline here the relevance related to the definition of care processes/plans, to the multidisciplinarity of such plans, the focus on specific groups of patients, and the decision-making aspects related to such processes.

Thus, the computer-based design and management of care pathways needs to be supported by methodologies and technologies, where all the considered aspects are suitably addressed. In this context, the need to design and enact standard and reliable healthcare processes, able to reduce the occurrence of exceptional events that would compromise the quality and the efficiency of organizational and clinical outcomes, is not new to the domain of healthcare process management [1, 3, 6].

Among existing technologies, business process systems emerged as a leading technology also in the healthcare domain [3, 7,8,9,10,11].

According to recent reports, the global business process management (BPM) market is accounted for $5.51 billion in 2015 and is expected to reach $ 17.96 billion by 2022 [12], and $ 23.04 billion by 2024 [13].

Healthcare is among the main application domains (verticals, in the report terminology) of BPM technology, while process modeling (per se) is one of the main focuses of BPM tools [13]. Moreover, patient monitoring in hospitals is underlined as one of the leading applications of BPM solutions in the healthcare industry. The widely increasing healthcare-based regulations are indicated as one of the leverages to increase the business process management market growth in the healthcare industry [13]. To complete the picture, among the key players in this market we find Oracle, Microsoft, IBM, SAP, and many others [12].

Among the plethora of existing business process languages [14], the business process model and notation (BPMN 2.0) is currently the leading standard for process design, developed by the object management group (OMG) [15]. BPMN provides a consolidated graphical notation used to outline process activities, their logical and temporal ordering, and the resources responsible for their execution. BPMN diagrams are suitable to design, visualize, and document processes at different levels of abstraction and according to different perspectives (process structure, interaction between processes, and so on), thus meeting the needs of various categories of users and fostering both process implementation and re-engineering. BPMN is currently supported by numerous process engines [16,17,18] that allow stakeholders to actively monitor executable process at run-time and support the interaction with knowledge workers through domain-specific client and invoked applications.

Indeed, BPM systems provide rich development environments that integrate design with process simulation, which encompasses techniques used to walk through a process in a step-by-step manner in order to check whether the process actually behaves as desired [19]. In BPM, simulation is the most commonly used approach for quantitative process analysis [20], as it enables the identification of shortcomings and procedural bottlenecks, thus allowing process managers to assess quality, check conformance, and to progressively tune organizational outcomes.

Recently, the OMG proposed the decision model and notation (DMN 1.1) standard [21] to complement BPMN for supporting decision design, management and implementation, according to the well-known separation of concerns principle [22]. DMN diagrams are meant to model decisions by representing input information, the used knowledge models, and their requirements for decision logic. Such explanatory diagrams portray the structure of one or more decisions and can be linked to one or more processes or activities, depending on the scope of decision-making. Thus, coupling BPMN processes and DMN diagrams could be beneficial to support the integrated design of decision-intensive care pathways, where complex clinical and organizational knowledge for decision-making needs to be represented.

Despite the presence of such advanced models and software tools, at the best of our knowledge, only few attempts have been made to manage care pathways through the integrated use of BPMN and DMN and, even more important, no attention has been paid to propose/extend development methodologies for the specific context of care pathways. Thus, according to the depicted scenario, in this paper we propose a new methodological framework to support the integrated design, implementation, and enactment of decision-intensive care pathways under an organization standpoint in order to foster the modeling and re-engineering of care pathways and related decision-making through proper information management and data re-use. The methodology defines both the main phases of process development, which are based on BPM best practices [19], and the widely known and adopted modeling languages and tools to be used. In detail, we show how the DMN notation can be used to complement BPMN with the goal of increasing support toward decision-making, hence improving its suitability for healthcare process modeling and enactment. For each phase, relevant information sources are also highlighted. Within the proposed methodology, we will mainly focus on the design phase.

The main novelties, specific for the management of care pathways, of the proposed methodological approach are:

  • Supporting the integrated design of care pathways and decisions, based on conjunct use of the standard BPMN and DMN languages;

  • Strongly integrating care pathway simulation within the design phase, to support agile development;

  • Proposing a classification of the main kinds of information involved in different phases of process and decision development, and investigating the role of data-based indicators;

  • Using and possibly extending BPMN modeling constructs to represent complex temporal behaviors/ constraints in care pathways;

  • Illustrating meaningful aspects of clinical decision-making and evaluating their scope and impact on the overall care pathway.

Moreover, as a further added value, we show a real-world application of the proposed approach to the design of care pathways for chronic obstructive pulmonary disease (COPD), within a regional context.

The presented methodological framework extends the approach introduced in [10] and tackles several new original issues. This paper illustrates a more general methodology that encompasses all the phases of a typical business process life-cycle, thus considering also process implementation and enactment. Moreover, the role of simulation within the design phase is explicitly discussed. In addition, connection points with existing formalisms are highlighted, as the methodology aims to provide a main standard core that can be extended and integrated with context-specific decision support systems and tools, suitable for dealing with complex clinical aspects. Information management is now included in the methodological approach and a classification of data that are relevant for process execution is presented. As for the application to the clinical domain of COPD, the goal of this paper is to illustrate process and decision design for care pathway development, thus covering all the aspects related to requirements analysis, modeling, and simulation. In detail, primary, specialist, and secondary care of COPD have been studied and modeled exhaustively, with the help of stakeholders. Specifically, the presented BPMN and DMN diagrams describe not only diagnosis and assessment of COPD patients, but also ordinary and extraordinary care. Finally, real data have been obtained from currently enacted healthcare processes and they have been used for process simulation in order to analyze as-is organizational procedures from a re-engineering perspective.

The remainder of the paper is organized as follows. Section 2 introduces the fundamentals of the BPMN and DMN standards, elaborating on their integration. Section 3 discusses the proposed methodological framework. Section 4 explains important aspects of COPD treatment and management and illustrates how the introduced methodology is applied to the design and management of care pathways for COPD in the region of Veneto, in northern Italy. Section 5 discusses related work, considering proposals belonging to the domains of BPM and clinical guidelines development. Finally, Section 6 sketches some conclusions and presents future work.

2 Background: Modeling Processes and Related Decisions

In this section, the business process model and notation [15] and the decision model and notation [21] standards are introduced, in turn. Then, the integration of decision and process management is discussed, with particular focus on the new insights provided by the combined use of BPMN and DMN.

2.1 Business Process Model and Notation

In general, a business process (BP) is defined as “a set of activities that are performed in coordination in an organizational and technical environment” [19].

The business process model and notation (BPMN 2.0) was developed under the OMG umbrella as a standard language for graphically representing business processes [15]. Born as a general purpose language, the notation is suitable for modeling processes in multiple application domains and at different levels of abstraction, thanks to its extensible meta-model organized in layers. BPMN provides a set of basic elements meant to be understood by both process designers and practitioners, without extensive training. Yet, the notation includes more advanced constructs and multiple kinds of diagrams that allow expert users to express complex concepts, such as message-based communication, event-processing, and exception handling.

In BPMN, a process is represented by means of a graphical diagram, which is mainly composed of activities, sub-processes, and events. These are connected by a sequence flow that denotes the causal relations between them and is routed by gateways [15]. The basic elements of a process diagram are activities, events, and gateways. Besides, swimlanes are used to represent organizational aspects and process participants, whereas data artifacts outline process-related information.

  • Activities represent work that is carried out during process execution. BPMN provides two main elements for describing activities, namely, tasks and sub-processes. Tasks are atomic units of work that cannot be broken down to a finer level of abstraction. Graphically, they are depicted as rectangles with rounded corners, enclosing the name of the activity. A marker can be added to detail the type of task, which is associated to a well-defined behavior (e.g., “user tasks” denote that work is assigned to a human performer). Conversely, sub-processes represent compound activities, whose internal detail may (expanded sub-process) or may not (collapsed sub-process) be shown. Collapsed sub-processes are represented as tasks decorated with a “+” maker. Expanded sub-processes consist of an enlarged border that contains all the sub-process elements.

  • Events represent facts that occur instantaneously during process execution. Graphically, they are depicted as circles and may contain a marker that diversifies the kind of event trigger (e.g., message, timer, signal, etc.). Depending on their behavior, events can either throw a trigger or catch a result. BPMN defines three kinds of events, based on their position in the process. Start events (single border) initiate a process instance, end events (single thick border) conclude it, and intermediate events (double border) are located at any point between the process start and end. Intermediate events can be attached to the boundary of an activity and they can either be interrupting or non-interrupting. Interrupting boundary events interrupt the activity they are attached to, whereas non-interrupting boundary events initiate a parallel process path.

  • Gateways control the divergence and convergence of the sequence flow, according to data-based conditions or event occurrence. Graphically, they are depicted as diamonds with an internal marker that differentiates their routing behavior. The “ + ” marker is used for parallel branching, while a “ ×” identifies an exclusive gateway, i.e., a point in the process where a condition must be evaluated in order to choose one path out of more.

  • Swimlanes are containers identifying organizational aspects, such as the organization structure (departments, roles) and resources (process participants). Pools are used to represent resource classes or roles, such as, for instance, “Pharmaceutical supplier”. In BPMN, roles are used to classify process participants according to their skills, knowledge, and responsibilities within the process. Lanes are used to sub-partition an organization into functional units or individual process participants, and can be arbitrarily nested to denote role hierarchy.

  • Data artifacts represent information that is produced or consumed during process execution. In particular, volatile data are represented through data objects, which can be exchanged between activities. Graphically, they are depicted as paper documents, with a bent corner. Persistent data sources are modeled as data stores, which are associated to activities and can be referenced from different parts of the same process.

Other specific BPMN elements used in this paper will be explained later, when needed.

To introduce the BPMN notation, we employ a simple example taken from the clinical domain of COPD [23]. In particular, let us consider the 6-min walk test (6MWT), one of the clinical tests used to objectively evaluate the functional exercise capacity in COPD patients [24]. 6MWT is a practical test that “measures the distance that a patient can quickly walk on a flat, hard surface in a period of 6 minutes” [24]. The goal for the patient is to walk as far as possible in the given time frame, assisted by a trained technician. This test is typically used to evaluate exercise tolerance in chronic respiratory disease and heart failure, and it allows physicians to monitor pulmonary and cardiovascular functions, among others. 6MWT is typically performed in a dedicated hospital hallway, as timely and appropriate emergency measures must be enacted in case of complications. 6MWT must be immediately stopped if the patient shows signs of chest pain, intolerable dyspnea, leg cramps, staggering, diaphoresis, and pale or ashen appearance [24]. In this scenario, the trained technician must take blood pressure, pulse rate, and oxygen saturation. Oxygen should be given when needed.

A simplified version of the the main steps of 6MWT is depicted in the BPMN process diagram of Fig. 1.

Fig. 1
figure 1

BPMN diagram summarizing some preliminary stages for the 6-min walk test, simplified and adapted from [24]

Full size image

The goal of Fig. 1 is to exemplify how BPMN can be used for providing a standard representation of clinical procedures and of resources allocated to activities.

After being approved by a physician, the test is conducted in a respiratory diseases unit, represented as a BPMN pool and it is carried out by a trained technician, depicted as a lane. First of all, the technician should Allow the patient to sit on a chair to rest for at least 10 min before the test starts. This temporal span is represented by an intermediate timer event. A couple of parallel gateways is employed to denote that, during this time frame, the technician must check patient clothing and evaluate relative contraindications. The evaluation of contraindications is a decision about the conduct of the test, based on the current values of the patient vital parameters. The output of the decision is used by the following exclusive gateway Can the test be performed? If the test is not believed to put the patient at risk, pulse oximetry can optionally be performed. Exclusive gateway Perform pulse oximetry? is used to represent this option. If it is performed, the physician must measure oxygen saturation; otherwise, this task is skipped. If measured, the value of oxygen saturation is recorded in the patient medical record, portrayed as a data store. Finally, 6MWT is performed. This is represented by means of a collapsed process, as individual steps are not detailed.

However, if the patient experiences dyspnea, chest pain, leg cramps, staggering, diaphoresis, or pale appearance, the 6MWT must be immediately interrupted [24]. In Fig. 1, this is captured by boundary interrupting conditional event stop test, which encodes the aforementioned conditions and generates an exception flow that leads to task assist patient.

Then, the depicted process is concluded by a simple end event.

In general, BPMN can be used in various organization domain for documentation, analysis, and standardization purposes. In healthcare working environments, resources are often having complementary expertise and are loaded with heterogeneous tasks and responsibilities. In this setting, process modeling techniques are useful to improve coordination among different functional units, support communication between participants, and provide overall activity standardization, especially in terms of organization aspects.

BPMN is supported by several (open-source) process modeling tools and customizable engines [16,17,18] and it is widely used in the context of business management. The main advantage of using BPMN for healthcare process modeling is the fact that it is a well-maintained consolidated standard, complemented by other standard notations for decision modeling [21], case management [25], and process exchange [26]. Moreover, as healthcare processes are often monitored by administrative staff and information technology (IT) experts, it is likely that these users are already familiar with the notation.

Being a graph-oriented process modeling language, BPMN allows combining flow objects almost arbitrarily, thus leading to the definition of hardly readable and complex process diagrams [27]. Large and articulated models are difficult to be used and understood by less trained users and they have proven to be more error-prone. Nevertheless, structural restrictions and modeling guidelines can be applied to increase readability and prevent undesired execution deadlocks [28]. A BPMN process is said to be well-structured if for every split node, i.e., a node with multiple outgoing edges, there is a corresponding merge node, i.e., a node with multiple incoming edges, such that the set of nodes delimited by the split and the join nodes form a single-entry-single-exit (SESE) region, and these regions within the process are properly nested [29]. The previously discussed process of Fig. 1 is an example of well-structured diagram. Structured processes have also proven to enhance modularity, which is the ability to decompose the process into smaller reusable components. These often correspond to process sub-regions having specific properties defined over them, which is desirable under a re-engineering standpoint.

In addition, comprehensible diagrams can be used for documentation purposes and as a starting point for communicating with clinicians, during interviews or re-engineering interventions.

2.2 Decision Model and Notation

In business process design, decision-making covers a crucial role. Process gateways and conditional events often encode data-based operational decisions, whereas decision activities encompass more complex non-operative decision-making. Decisions affect the process flow and, consequently, they impact both the performance of the process and the quality of its (business) outcomes. However, important decisions often remain hidden within process diagrams and BPMN is misused for decision modeling, despite data-based preconditions of BPMN elements are hard to understand [30, 31]. For these reasons, business process modeling must be properly complemented with decision design.

To respond to this need, the OMG recently developed the standard decision model and notation (DMN 1.1) [21]. DMN has been proposed as a standard notation to bridge the gap between the high level business logic, represented in processes, and decision implementation, typically specified in terms of decision logic. The notation supports the design of both human and automated decision-making, capturing both decision requirements and decision logic. Together, these two levels provide a complete decision model, which complements a process diagram by detailing the decision-making carried out in process tasks [21].

The decision requirements level is modeled by means of a decision requirement graph (DRG), which may be linked to one or more tasks belonging to one or multiple business processes. A DRG represents the main elements involved in a decision-making domain and the dependencies between them. As DRGs may be large and complex, they can split into one or more decision requirements diagrams (DRDs). DRDs may be used to show partial views of the whole decision domain, focusing on areas of interest for a specific user or goal. These diagrams define which decisions are made in process tasks, which are their interrelationships, and their requirements for decision logic.

The main elements forming a DRD are introduced in the following list.

  • Decisions portray the act of determining an output from a number of inputs, using logic defining how the output is retrieved from the inputs. Decisions may reference one or more knowledge models. Graphically, a decision is depicted as a rectangle, labeled with the decision name.

  • Business knowledge models denote functions that encapsulate business knowledge, such as business rules, decision tables, or analytic models. They are illustrated as rectangles with clipped corners.

  • Input data represent information used as an input by one or more decisions. When enclosed within a knowledge model, input data represent the parameters to the knowledge model. Graphically, they are depicted as ovals.

  • Knowledge sources identify an authority for a business knowledge model or a decision, such as a person responsible for managing the represented knowledge, or a published document enclosing it. They are depicted as a shape having three straight sides and a wavy one.

Three kind of dependencies are defined between the presented elements, in the form of requirements. An information requirement, depicted as a simple arrow, represents any input data (or decision output) that is used as input to a decision. Graphically, an information requirement is depicted as a solid-line arrow with a filled arrowhead. A knowledge requirement denotes the invocation of a business knowledge model by a decision or by another knowledge model. Graphically, it is a dashed-line arrow, having an open arrowhead. Finally, an authority requirement depicts the dependence of a DRD element on another DRD element that acts as a source of guidance or knowledge. This may denote the fact that a business knowledge model is consistent with a published document, or that a a specific person is responsible for a certain decision. Graphically, it is represented by a dashed line with a filled circular head.

Decision logic completes the (executable) description of decisions, by allowing one to define them in sufficient detail to support validation and/or automation. In general, decision logic can be modeled in several ways, which translate business expertise into business rules, analytic models, or other formalisms. DMN defines different kinds of value expressions to associate decision logic with elements of a DRG.

A literal expression represents decision logic as text that describes how an output value is derived from a set of inputs. Literal expressions may be represented with a formal, and possibly executable language, or they can be written in plain English. Formal expressions can be specified with the friendly enough expression language (FEEL) [21], which translates if/then/else data structures and calculations into executable expressions.

A decision table is a tabular representation of a set of input and output values, organized into rules that describe how a given input relates to one or more corresponding outputs [21]. The simplified FEEL (S-FEEL) is a subset of FEEL, used for defining expressions in decision tables.

An invocation is a tabular representation of how decision logic, represented by a business knowledge model is invoked by a decision, or by another business knowledge model.

Tabular representations of decision logic are called boxed expressions.

As an example, let us consider the 6-min walk test, introduced in Section 2.1. In some clinical situations, this test may be contraindicated for patients considered at risk. Relative contraindications are evaluated by a trained technician right before test execution. These are a resting heart rate of more than 120 bpm, a systolic blood pressure of more than 180 mmHg, and a diastolic blood pressure of more than 100 mmHg [24]. The technician performing the test must measure the patient vital parameters and decide whether the test can be conducted safely.

A simple DRD representing the decision about the conduct of the 6MWT is shown in Fig. 2.

Fig. 2
figure 2

Decision requirement diagram representing the decision for the conduct of the 6-min walking test, with related input data and invoked business knowledge model Relative Contraindications

Full size image

The main decision regarding the Conduct of 6MWT is based on the assessment of Relative Contraindications, which are encoded as rules within a business knowledge model. This model is invoked by the main decision, which passes input data Arterial Blood Pressure and Heart rate as parameters for the model. Finally, the trained technician is indicated as a knowledge source, to represent the authority responsible for deciding about the conduct of 6MWT. The described DRD of Fig. 2 is linked to task evaluate relative contraindications of the BPMN process of Fig. 1. In general, there may be a one-to-one correspondence between a BPMN process task and a DMN decision. Yet, this is not mandatory, as the same decision can refer to multiple tasks and can be used across processes.

Figure 3 depicts the decision logic corresponding to business knowledge model Relative Contraindications, by using a decision table. In Fig. 3, input and output values are arranged into columns, while rules correspond to rows. At the top left corner of a decision table, a couple of attributes can be present, one to denote the kind of hit policy for the table, the other to indicate its completeness. A hit policy specifies how overlapping rules are handled, that is, how output values must be returned in case more than one rule match input data. In the presented case, character U is used to denote a unique hit policy for the table, meaning that no overlapping rule is allowed, that is, all rules are disjoint and only a single rule can be matched [21]. A completeness indicator can be optionally used to specify whether at least one rule in the table matches a possible input configuration. Symbol C denotes a complete table (DMN default), whereas I is used for incomplete ones. Finally, symbol “-” is used to denote that the value of a certain input is irrelevant for the final decision, that is, the decision can be made even if that input value is unknown.

Fig. 3
figure 3

Labeled decision table portraying the decision logic underlying decision conduct of 6MWT of Fig. 2

Full size image

2.3 On Linking BPMN and DMN Diagrams

Whereas operational processes have received plentiful attention, decision modeling in business process management has been scarcely addressed to date. However, decision-making constitutes an important aspect of knowledge representation in business processes.

BPMN and DMN standards address decision-making from different and complementary perspectives. On the one hand, business process diagrams allow one to identify specific decision activities, which are usually captured as user or business rule tasks.

User tasks are defined as typical workflow activities, which are assigned to a human performer through the use of worklists and are executed with the assistance of a software application. Instead, business rule tasks provide a mechanism for the process to interact with a business rule engine for decision management [15]. On the other hand, DMN defines which are the decisions made in process tasks, which are their inter-relationships and their requirements for decision logic. DMN can be used independently from BPMN to model a domain of decision-making without any reference to business processes. The two standards are intended to be used according to the separation of concerns paradigm [22, 32], that is, by allowing designers to keep decision logic in a dedicated decision model and process logic in a process diagram. Decoupling process and decision diagrams can also be advantageous in contexts where process and decision managers have different roles and expertise. Indeed, despite allowing the use of gateways for drawing multi-criteria decisions, BPMN is not suitable for decision-design for many reasons. First of all, a process gateway is not entitled to properly “decide,” but it rather specifies which path is taken by a process instance, based on existing process data or event occurrence. Secondly, decisions in BPMN are often drowned into complex and hardly-readable diagrams and their formalization can become quite cumbersome [30]. Last but not least, slight changes of decision logic may have a strong impact on the whole process diagram, thus requiring substantial re-design.

DMN compensates BPMN by supporting the design of both operational decisions, which are made in day-to-day business processes, and strategic decisions, which are typically more complex and harder to represent. The easiest way to connect a DMN model to one or more BPMN processes is by allocating different kinds of decision-making to separate process tasks [21]. According to its level of automation, a decision can be discerned into human or automated. Human decisions are performed by organization personnel and are usually described informally at a high level, using natural language rather than decision logic. Conversely, automated decisions require that decision logic is formally specified. For these decisions, it should also be possible to validate that a process uses the results of decisions only in tasks or gateways following a decision activity [21]. In healthcare, partial automation is more common, since, despite being formalizable into automatic rules, most decisions are reviewed or validated by personnel.

A typical example of partially automated decision is drug dosing based on a patient’s age and weight. This is performed by a physician, who takes into account some fixed thresholds suggested by clinical indications. According to [21], human decision-making can be enclosed in BPMN user tasks, whereas (partially) automated decision making can be allocated to business rule tasks.

3 The Methodological Framework

In this section, we present a new methodological framework for supporting the seamless design, implementation, and enactment of healthcare processes and decisions. We also tackle a few crucial aspects related to the management of information relevant for the execution of both processes and decisions. In particular, the methodology provides both a classification of the disparate facets of process-related decision-making and a qualitative analysis of the kinds of data involved in the various phases of process development.

3.1 Overview

The proposed methodological framework, which extends the methodology introduced in [10], is a general-purpose approach grounded on standard BPM models and tools, but it is presented with special attention to the requirements related to the management of care pathways. In particular, we present a structured approach to delineate the main phases of care pathway development and, for each phase, we define which are the techniques and tools to be used and how. In addition, we provide the reader with an overview of which are the most important challenges that can be encountered in each phase. Finally, we suggest possible connection points with existing formalisms suitable to be used in the healthcare domain.

The viewpoint of the methodology is intentionally process-oriented, as the macro-steps portrayed in the central part of Fig. 4 correspond to specific phases of the business process life-cycle. Namely, we considered DESIGN, IMPLEMENTATION, and ENACTMENT, the latter one encompassing also performance analysis [19]. These phases constitute the core of the approach and are connected to process-related information, which is outlined at the top of Fig. 4. The mentioned life-cycle phases are framed by a dashed line to highlight that there is an open interaction and a continuous exchange of knowledge and information between the phases of process development and the organizational environment. The advancement from one phase to the next one is shown in Fig. 4 by small light-blue triangles.

Fig. 4
figure 4

Main steps of the proposed methodological framework. The Design phase has been exhaustively applied to the COPD case study, as detailed in Section 4

Full size image

In real application environments, it is common to deal with incremental process development, followed by iterative refinements and often with agile approaches, i.e., non-completely planned and heavily involving final users, in the related software development [33]. For this reason, the depicted life-cycle has to be considered to be continuous. That is, the output of the enactment phase is re-used as an input for the design phase. This iterative re-thinking and organizational change of both the structure and the outcomes of a process is often referred to as process re-engineering. Business process re-engineering is commonly defined as the “radical re-design of one or more aspects of a business process,” aimed to improve process performance and to implement organizational changes [34]. In Fig. 4, the RE-ENGINEERING of both processes and decision-making is represented by thick curved light-blue arrows. A big re-engineering arrow links the enactment and design phases, denoting the need for process and decision re-design, based on information retrieved from process execution and analysis. Similarly, two smaller curved arrows are used to represent local re-engineering steps, aimed at refining the design of process and decision diagrams, based either on insights provided by simulation or on new requirements. In healthcare, process change is often needed to improve compliance to standards statements or to integrate health information systems [35].

Here, we will show how the presented methodological approach for care pathways design and enactment, even if applied partially, allows IT experts and care providers to interact and address some complex challenges [1, 6, 36]. The methodology is directed to expert process modelers, that is, we assume that a team of process and IT experts, actively interacts with care providers and clinicians to deeply understand and analyze the healthcare context. Indeed, as process development is a time-consuming task that requires IT expertise, we do not expect clinicians to directly model and maintain the given care pathway.

Table 1 summarizes some important questions whose answers need to be collected by process experts when applying the introduced methodology for developing healthcare processes.

Table 1 Summary of important questions that may be answered during each phase of the methodology shown in Fig. 4
Full size table

3.2 Design: Modeling Processes and Decisions

Reasonably, the development of decision-intensive healthcare processes begins with a DESIGN phase. This is organized into three main steps: REQUIREMENTS ENGINEERING, MODELING, and SIMULATION, depicted in Fig. 4. With respect to process and decision design, during Requirements Analysis a specific organizational problem is studied, and process participants, final objectives, and performance goals are defined. The latter ones are usually determined with help of indicators, established by teams of clinicians and healthcare managers who meet regularly to assess process performance. Among the indicators to consider in care pathways, in recent years, health care quality indicators (HCQIs) have been proposed by Organization for Economic Cooperation and Development (OECD) state members, as a way to assess, monitor, and compare the quality of healthcare systems both at regional and national level [40]. As an example, cancer mortality rates and the number admissions for asthma are quite traditional quality indicators, to consider in related pathways. Requirements engineering usually comprehends feasibility studies and the analysis, definition, and specification of requirements, aimed at understanding the studied domain and the role of the modeled pathway in the organizational context. In the healthcare domain, process and decision requirements related to care pathways stem either from organizational documents, medical literature, clinical guidelines, and local care policies, or they are collected by process modelers through direct interaction with both medical professionals and care managers. Usually, interviews with participants are conducted and modelers are invited to observe how the organization operates.

MODELING embraces both processes, data and decisions, based on the previously identified requirements. Process modeling allows one to filter out the irrelevant complexities of a real scenario, while providing a picture of the considered healthcare environment, tailored to spot improvements needed for re-engineering. Process modeling begins with Process identification, aimed at establishing the main process activities, their execution order, and the chosen modeling granularity. During process identification, the modeler decides which and how many processes should be outlined, considering final objectives and possible implementation requirements. Besides, it is crucial to ensure that the outlined processes do not overlap and that the interactions between resources correspond to reality. To this end, BPMN choreography and collaboration diagrams can be employed to explicitly represent message-based communication between multiple processes and resources [15]. Usually, at this point, process elements are still defined at a quite abstract level.

Conversely, step BPMN diagram deals with the design of a more detailed process diagram, by making use of process elements defined in the business process model and notation standard. BPMN diagrams are suitable to represent the process control flow with sufficient detail and expressiveness, at different degrees of structural complexity and support for automation [19]. In addition, BPMN partially tackles other aspects of process modeling, such as the exchange of data produced and consumed during process execution and the management of process roles and their interactions. In particular, BPMN allows the designer to specify different roles within a healthcare organization and to specify which activities have to be performed by different roles, through pools and swimlanes.

During this phase, process designers adapt the process model to better suit the final design goals and to meet the local requirements of the application context. Designers can exploit existing patterns for modeling control flow [37], data [38], and time [39], to capture complex process aspects.

Similarly, decisions play a crucial role in process development and enactment, and, thus, it is important to understand how they affect both the process flow and the organizational environment. Hence, decision modeling is carried out in parallel or in conjunction with process modeling. Decision identification deals with the discovery of which are the decisions that affect the process and its organizational landscape: During this phase, modelers need to understand which are the relationships between decision-making and the process flow, and which are the repercussions of decision outputs on the process flow.

A decision can be modeled by means of a DMN diagram, which addresses different aspects of decision-making. In particular, decision requirement diagrams represent the internal structure of a decision and its relationships with other decisional steps. When needed, decision logic can also be specified, by using boxed expressions or decision tables. Whenever decisions are explicitly represented in a BPMN model, a DMN diagram can be associated to those process activities that encompass decision-making. In Fig. 4, this connection is represented through a simple double-headed arrow that links BPMN diagram to DMN diagram. However, according to the principle of separation of concerns [22, 41], it is beneficial to keep process and decision logics separate, as these are usually supported by different stakeholders, having distinct goals and expertise. We distinguish two main types of decision:

  • Operational decisions are usually expressed quantitatively, in terms of process variables that are used by process gateways to determine which path has to be chosen. Usually, operational decisions are represented in BPMN as decision tasks (i.e., a task of type user or business rule), whose result is used by a following gateway [30]. In the healthcare domain, operational decisions concern daily activities, such as drug dosing, identification of a specific vital parameter to measure, and scheduling of examinations.

  • Non-operational decisions include more complex and strategic decision-making, usually affecting high level process objectives [42]. In healthcare, such decisions are often expressed in the form of natural language statements, based on medical evidence or professionals’ knowledge, and rely on qualitative assessment. In a BPMN diagram, such decisions can be represented by a single decisional task, or they can span over more process activities. Examples of complex non-operational decision-making are clinical diagnosis and therapy planning, taking into account different kinds of knowledge and, possibly, sub-decisions.

Usually, DMN is used for supporting operational decisions, and patterns have been proposed to ease the extraction of such decisions from the process control-flow [30]. As for decision logic, DMN supports the representation of decision tables and logic formalisms that can be easily mapped to the friendly enough expression language (FEEL). Decision tables can be constructed by using almost any principle, for instance by using the approach presented in [43] when decisions need to be extracted from textual guidelines. In addition, algorithms for analyzing the completeness, consistency and non-redundancy of DMN decision tables have been proposed in [44], and tools such as Signavio currently support the verification of completeness for decision tables containing numerical entries. Moreover, DRDs can be useful to provide a compact and explanatory representation of non-operational decisions. In detail, DRDs can be used for decision compliance and management, as they allow managers to understand which data must be used for decision-making, which are the required sub-decisions to be made, and who is responsible for them.

As third and final step of the design phase, in Fig. 4 process and decision simulation is connected to process and decision modeling by means of dashed arrows, meaning that, despite being specific for the design of care pathways (as discussed in detail in Section 3.4), useful, and cost-saving, it does not constitute a mandatory design step.

3.3 Dealing with Process-Related Information and Knowledge

Process-related information is represented at the top of Fig. 4, and the relationships with the introduced phases of process and decision development are highlighted by solid lines, depicted with a rounded arrowhead. During requirements engineering and modeling, Domain knowledge is used to provide a clear description of the relevant aspects of the modeled reality, by considering peculiarities, critical aspects, and goals of a specific healthcare organization. For instance, a care pathway for treating patients affected by pneumonia must deal with medical knowledge related to the management and treatment of pulmonary diseases, bearing in mind that we are interested in data regarding the organizational aspects of the treatment rather than in clinical knowledge. Similarly, Reference data help to delineate the requirements for process compliance. Examples of such data are reference values for medical parameters, input values for medical instrumentation, as well as administrative data regarding personnel salaries and skills, required duration of certain procedures, and quality standards. Reference data are strongly related to domain knowledge and local organization policies.

Then, Operational data regarding process activities, roles, and the organizational structure are also gathered during requirements analysis. During process and decision modeling, input and output data for process activities and decisions must be identified, and their structure, usage, and availability must be defined. In general, operational data produced, consumed, and exchanged by process activities must be considered during the design of a BPMN diagram, either to set activity attributes or to define data artifacts. During process design, data-related aspects are usually expressed through data stores and data objects. As BPMN is closely related to UML, some extensions can be adopted to enrich the graphical representation of data objects and data stores, by adding to process representation the direct reference to the UML database attributes that are touched by readings and inserts/updates required by each task. By adopting this solution, it is possible to represent the direct connection that exists between the conceptual model of the process and the conceptual schema of the accessed database [45].

In healthcare, operational data are typically stored within health information systems. Similarly, Operational decisions are used in day-to-day operations and must be defined to ensure that their input and output data are used properly within the process. Process and decision modeling deals also with non-operational data that are used for decision support. This information, often referred to as Aggregated data, can be used to measure the performance of the process within a specific application context and to make strategic decisions during process execution. In healthcare, aggregated data are extracted from data warehouses or decision support systems, to be used during process modeling and re-engineering. A subset of both operational and non-operational data, used to identify which are the aspects of a process model that are interesting to be analyzed during process execution, is represented by Conformance data.

Finally, Process metrics and KPIs are used to quantify process and decision quality and productivity. Data-based key performance indicators (KPIs) are measurable values that assess the progress of care pathways toward the achievement of the organizational objectives.

In BPM, KPIs are defined to monitor process execution, evaluate the quality of process and decision outcomes, and quantify the overall progress toward organizational goal achievement [20].

In this work, depending on their scope, we discerned two kinds of pathway KPIs. Local KPIs correspond to process and decision metrics and are mostly used to measure activity execution times, costs, and resource consumption. We refer to such indicators as “local,” as they are extracted/used directly from/by multiple instances of one process model. As an example, the expected mean time duration to complete a care pathway related to the management of patients with breast cancer requiring a following chemotherapy is a local KPI, as it is related to the specific pathways and to possible “local” features of patients, reacting in different ways to the given chemotherapies.

Conversely, global KPIs are used to evaluate the strategic value of the performed (decision) activities both quantitatively and qualitatively. Global KPIs can be directly re-used in clinical decision modeling, to improve decision quality, patient prognosis, and predictive analytics. Usually, global KPIs rely on aggregated data and their impact can affect several activities and processes. In addition, they can be used for organizational and re-engineering purposes that go beyond the scope of the defined processes. These indicators are rather based on clinical and healthcare data, and provide a summarized and focused overview of the modeled domain. Global KPIs can have both a clinical or organizational character. Continuing with the example related to the oncological pathway, a global KPI could be the ratio between the number of patients concluding in a succesfull way the pathway and those who stopped the pathway for some health related issue. Such kind of global KPI could be possibly used inside the pathway to finely tune chemotherapy cycles as well as outside the pathway to activate, for example, suitable prevention actions.

As already underlined, pathway KPIs are strictly related to healthcare quality indicators, as we will show in the application of the proposed methodology to COPD patient management. Indeed, HCQIs may correspond to some measure used to structure and evaluate the considered pathway. As an example, the outcome indicator coded as 13a “The proportion of patients with estrogen receptor negative invasive carcinoma who received adjuvant chemotherapy, out of the total number of patients with the same diagnosis” is an acknowledged quality measure of the process related to breast cancer treatment [46]. This value could be both a result of a general care pathway representing the overall management of patients with breast cancer and an indicator used inside a more specific pathway for managing chemotherapies, to estimate the percentage of patients that have to be considered for the given pathway.

Although care pathway KPIs are used during process analysis or simulation, they are defined during requirements analysis and process identification, in order to better tailor the process model to the final goals.

3.4 Integrating Simulation in the Design of Care Pathways

Process simulation is one of the most popular and widely used technique for quantitatively analyzing process models [20]. Simulation encompasses both the execution of a model under hypothetical conditions in a defined simulation environment and the analysis of the execution output [47].

During process design, Simulation can be used to support the quantitative analysis of pathway models. Specifically, Process and decision simulation promotes the study of the execution of modeled pathways and decisions in a realistic or ideal scenario, without resorting to pathway and decision implementation. Being faster and more flexible than process enactment, simulation tools and techniques foster pathway validation and provide reliable estimates of resource consumption and execution times. Indeed, process configuration and enactment may be highly demanding, while stakeholders are interested in obtaining prompt and reliable estimates of process behavior, associated costs, required resources, and quality of outcomes. Simulation allows one to validate a process behavior, by spotting bottlenecks, and by evaluating resources costs and consumption. Besides, the duration of the overall process and of single activities can be estimated and ideal or worst-case scenarios can be studied. Decision simulation is often used to reproduce the outcomes of decision tables given an arbitrary set of input values and to verify table completeness. As previously mentioned, simulation results can be re-used to promote process adaptation to expected performance requirements. Moreover, simulation can be used for what-if analysis to explore alternatives, eliminate inadequate re-engineering proposals, and refine current as-is procedures.

Beside the continuous support to designers during care pathway modeling, in the proposed methodology, we underline the importance of simulation for stakeholders who are responsible for decision-making within the healthcare organization. Indeed, simulation support healthcare decision makers in resource allocation and management. Through simulation, decision makers can verify whether the resources associated to a care pathway have been suitably considered, with respect to the estimated number of patients and with respect to the specified goals for the pathway (e.g., reach the end of the treatment within 30 days since the admission of the patient).

Both local and global pathway KPIs could be considered together with HCQIs to see their mutual interactions in a “what-if” analysis context. As an example, in the chemotherapy domain, the previously defined indicator 13a is expected to be at least 80% [46]. This value could be used to distinguish the percentage of patients following a path of activities related to chemotherapies from other patients receiving different treatments. When simulating the same care pathway, one could change the value of 13a to the target value of 90% in order to monitor the effects of such change on the local KPIs of the pathway, such as its overall cost or its average duration.

Moreover, simulation can provide healthcare decision makers with some evaluation of HCQIs related to the considered pathway. As an example, in the design of a care pathways for patients with acute stroke, we could consider whether the HCQI Acute stroke mortality rate is maintained low, according to the expected features of patients, the expected results of the designed activities, and so on. In this direction, simulation can be used to estimate, as a kind of decision-support what-if analysis how HCQIs change with respect to different scenarios. Finally, simulation results can also feed some indicators that either are employed in external processes or support strategic decision making, or are used to obtain more complex HCQIs.

3.5 Implementation and Enactment

Following design, the methodological framework deals with Implementation, which can be realized in different ways, depending on which IT infrastructures are already available in the organizational environment. Implementation is realized in different steps, usually starting from the automation of single processes and, then, by realizing the coordination between them. When starting from a single process, Automation is usually the first step that is applied for implementation. Automation focuses on the selection of software and services for process execution, encompassing both implementation and deployment aspects. In Fig. 4, by Process implementation we intend mostly process configuration, that is, the integration of a process model with technical information that facilitates enactment. Then, the enriched BPMN diagram is mapped into a formalism suitable for execution. Processes are executed by engines, which link client applications, supports the distribution of work among different process actors, and coordinates activities [2]. Most existing process engines support the direct deployment of standard XML process descriptions, generated by modeling tools, without the need of further mappings.

Process automation is closely related to Testing and deployment. Traditional testing techniques from software engineering can be used to test the automated process, to see if it behaves as expected. During this phase, integration and performance are tested for detecting potential run-time problems. Finally, the system is deployed in its target environment and complementary actions, such as data migration and user-training may be executed. In general, one advantage of using standard modeling languages is that process engines can easily interpret them and, within healthcare organizations, such systems may already be used by the administrative staff.

The final phase of the introduced methodological framework deals with Enactment, which consists of Execution and Performance analysis.

In detail, Process and decision execution encompasses the actual run time of a decision-intensive process. This is usually the result of the process engine interacting with client applications. Execution constraints must be observed, and execution exceptions arising from unexpected occurrences must be properly handled. In this methodology, we do not explicitly deal with exception-handling, as this topic depends on the kind of system used for implementation and solutions have already been proposed in the BPM community [48].

During and/or following process execution, performance analysis may be carried out to monitor enactment or to analyze how well the process is performing, compared to desired performance goals. In Fig. 4, the relationship between process execution and performance analysis is depicted by a double-headed dashed arrow, meaning that the latter may be optionally performed during or after process execution. Monitoring allows one visualizing the current status of process and activity execution, in order to be able to enact corrective measures if the process is not behaving as expected. During process monitoring, bottlenecks can also be detected.

Analysis tools and algorithms can also be used to verify specific properties, such as done for the satisfaction of temporal constraints in [49].

Conformance analysis is employed to verify the fitness and appropriateness of a process with a given pattern or organizational model, in order to check whether the process is well-incorporated the organizational practice. Both structural and behavioral aspects can be analyzed and the results of the analysis can be used for re-aligning the process model to reality. In general, multiple cycles of monitoring and conformance analysis are executed. In addition, formal methods, such as Petri nets, can be applied for analyzing process behavior [50].

During process enactment, conformance data and process metrics and KPIs are used to monitor the status of the running process and to analyze different executions. Usually, valuable execution data are gathered in the form of Execution logs, that is, long files that contain information about events that have occurred during process enactment. Examples of such data are starting and ending times of activities, task duration, role assignments, and message exchanges. Execution logs are analyzed for process re-engineering and alignment, or for discovery and mining purposes.

3.6 Managing Temporalities of Care Pathways

Even though a deep discussion related to the management of temporal issues in care pathways is out of scope with respect to the content of this paper, in the following we will discuss the main temporal issues related to care pathways. Besides, we will show how the proposed methodology can be used to easily embed a suitable management of such time aspects.

Temporal aspects of care pathways are usually complex and need to be suitably modeled, both in Requirement, and Modeling phases. As an example, in modeling preliminary stages for the 6-min walk test in Section 2, we need to represent that the patient as to rest for at least 10 min before executing the test. Further temporal constraints among different activities may also need to be represented. For instance, it could be interesting to show that the efficacy of a therapy must be evaluated 2 weeks after the treatment has been prescribed, as in the management of COPD that will be later discussed. Furthermore, periodicities need to be considered, since some care-related activities are inherently periodic, as, for example, the assessment of some chronic pathology or the administration of a given drug.

The representation of temporal constraints in BPM systems have been considered in literature, also considering clinical processes [9, 51,52,53,54]. In general, the focus of such proposals is both (i) to design temporal constraints in BP models and (ii) to verify some basic properties of temporal BP models. In particular, the concept of dynamic controllability has been introduced and extensively studied. Suitable algorithms have been proposed to verify at design time whether a process model can be executed while satisfying all the given temporal constraints and allowing activities performers to take any possible duration within the range of the allowed ones [9, 53]. The proposed solutions can be applied also to suitably extended BPMN models, as they use the most common BP constructs, as activity, subprocess, gateways, and so on. Thus, from this point of view, the proposed methodology is well suited to embed tools and models for checking temporal features of BP models.

Recently, modular BPMN-based temporal patterns have also been proposed in [55, 56], explicitly focusing on clinical tasks. The advantage of these BPMN patterns is that temporal aspects are suitably represented and embedded within a sub-process that can be edited by modelers and executed directly on a process engine. Thus, such patterns can be seamlessly and directly specified within BPMN care pathways and suitably dealt with in the proposed methodology.

Moving to the Simulation and Execution of time-aware care pathways, two different aspects arise: The first one is related to updating temporal constraints according to previously executed process tasks; the second one deals with the runtime management of possible constraint violations and of the related reaction policies. As shown in [11, 55] for some basic patterns, designers can leverage exception handling of BPMN 2.0 to specify suitable patterns for supporting different kinds of reactions to constraints violation. As an example, if a therapy duration exceeds its maximum duration, the model designer could specify either that such therapy must be immediately interrupted (strong policy) and some other compensation actions could be enacted or that the therapy will continue (weak policy), but some other actions have to be done (sending a warning to the physician) [11].

As a final comment, it is worth noting that powerful solutions to support time-related aspects of care pathways through BPMN are mainly based on the expressive power provided by the use of events, event-related activities, and exception-handling mechanisms. As an example, timer events can be used to specify either a specific delay from their activation or a certain time-date or a specific period of time within the process model, to trigger some specific clinical activity or some conditional path in the control flow.

4 Design and Simulation of Decision-Intensive Care Pathways for Chronic Obstructive Pulmonary Disease

In this section, we apply the introduced methodology to a real healthcare scenario, in order to discuss modeling choices and design challenges, and share the benefits brought by the proposed approach in a real clinical context.

The methodology discussed in the previous section has been applied to support the design of diagnostic-therapeutic care pathways for the management of chronic obstructive pulmonary disease in the region of Veneto, in northern Italy. The process and decision diagrams have been designed to provide a compact representation of healthcare procedures aimed at easing the understanding and improvement of as-is healthcare pathways and of their organizational aspects. One of the main modeling goals was the detection of pathway flaws that led to undesired, yet reducible healthcare expenses. Healthcare pathway implementation and enactment are out of the scope of this paper that mostly focuses on care pathway design and simulation. Hence, here we will consider in detail the design of COPD-related care pathways.

Requirements have been collected by analyzing textual documents authored by the Regional Healthcare System of Veneto, including both regulatory standards and organizational plans, and clinical practice references. In addition, we directly interacted with the regional board, composed of care managers and clinicians responsible for the actuation of the care pathways, and we were directly observing how care interventions have been carried out in a few regional hospitals. Finally, standard American and European guidelines for COPD management have been studied and used for process compliance [23, 57].

Among existing tools for process design and management, we chose the Signavio Business Transformation Platform, which integrates process modeling, decision design, and simulation features for cost analysis [18]. The web-based Signavio Process Editor has been used for process design and simulation, as it guarantees full adherence to the BPMN standard and supports different kinds of process simulation and cost management on several user-defined scenarios. In addition, it provides several functionalities that ease collaborative design, diagram reviewing, and commenting. The Signavio Decision Manager has been chosen to model DMN diagrams and to simulate decision table execution.

In the remainder of this section, we introduce the modeled clinical domain in Section 4.1 and we explain the design of both processes and decisions with BPMN and DMN in Sections 4.2 and 4.3. Then, we discuss the re-use of information through indicators in Section 4.4 and present simulation results in Section 4.5.

4.1 Chronic Obstructive Pulmonary Disease

The World’s Health Organization defines COPD as “a life-threatening lung disease characterized by chronic and not fully reversible obstruction of lung airflow, which interferes with normal breathing” [58]. Despite being both preventable and treatable, COPD global prevalence and socioeconomic impact remain significantly high [59], thus making the disease one of the leading causes of disability and death in developed countries.

Whereas COPD is often underdiagnosed in younger patients, as respiratory abnormalities become noticeable only when internal organ damage is already advanced [60], current diagnostic criteria may lead to over-diagnosis in the elderly [61]. A major proportion of COPD burden is represented by exacerbations, i.e., acute and unexpected worsening of respiratory symptoms that require a change in management.

In order to improve the management of COPD, integrated diagnostic and therapeutic care pathways have been proposed at a regional scale, with the intent of improving the effectiveness of COPD treatment, the prevention of exacerbations, and the coordination between different care providers. The development of such care plans aims to standardize the critical steps of long-term patient treatment and the overall decision process. In particular, it is crucial to clarify which is the role of each involved resource, which are the responsibilities, and which is the optimal timing for intervention. Besides, clinical, social, educational, and organizational objectives are set by considering economical expenses and resource availability.

The main goal of COPD diagnostic and therapeutic care pathways is the improvement of primary care quality mostly by reducing costs, intended both as patient lives and economical burden, related to misdiagnosis and to the prescription of unnecessary medical exams and treatments. The definition of such plans also encompasses a set of indicators that are defined to evaluate disparate aspects of the healthcare process, such as its structure, clinical and organizational efficiency, performance, progress toward the set final objectives, and overall economic impact. Prevention measures, educational programs, and counseling services are also included in the care plan, with the aim of training patients to recognize symptoms worsening and to improve the self-management of the disease in home care settings.

The proposed methodology supported regional care stakeholders to design COPD-related decision-intensive care pathways. Data used for the design and simulation are based on official regional reports [62, 63] and on other bibliographic resources provided by healthcare stakeholders [64,65,66]. Previous research on the burden of COPD in Italy has been presented in [64]. Data regarding COPD expenses have been considered with respect to those obtained by the interviews with regional healthcare stakeholders, although the number of patients affected by COPD in Veneto is increased from 6.2% of 2003 to 8.5% 2015. The major sources of expenses are hospitalization and oxygen therapy. The problems highlighted in [64] are similar to those highlighted by the experts that worked on the care pathways: poor results of smoking cessation programs, limited use and access of spirometers in primary care, underdiagnosis of COPD.

Such design phase is an initial step that should allow to reach the definition of a region-wide standard management of COPD patients, after a deep re-engineering phase. Healthcare stakeholders have been involved in design phase of the methodology, with an agile approach. Healthcare stakeholders participated to the design together with BPMN designers, who asked questions highlighted in Table 1 to them during the design meetings and collected answers in working and informal documents. BPMN and DMN documents, integrated with comments, together with simulation descriptions, are the formal and final results of this iterative design phase.

The modeled BPMN processes have provided healthcare professionals with a comprehensive and accurate overview of the COPD care pathways. After applying the proposed methodology, improvements in common understanding and cooperation have been noticed. In earlier times, each resource used to work independently and this fragmentation resulted in longer waiting times for patients, miscommunication, and information overload. The standard definition of the care processes has served to delineate everybody’s responsibility, while improving information exchange, cooperation between resources, and coordination between several processes. Besides, from a technical point of view, the process model has been used for validating the consistency and efficiency of the proposed solutions, thus constituting a sound trace for implementation.

4.2 Modeling COPD Pathways with BPMN

In the assessment and management of patients with COPD, three main intervention steps have been discerned, namely (i) COPD diagnosis and assessment, (ii) ordinary management of stable COPD, and (iii) management of COPD exacerbations. These steps are described in medical literature [23, 57], and are also be identified in the as-is processes that are currently applied in Veneto. For each one of the aforementioned steps, a BPMN process diagram has been designed, following the principles of well-structured process design to lower diagram complexity and reduce the probability of committing modeling errors [28, 29].

The three phases included in the studied care pathways for the management of COPD are depicted in the BPMN process diagram of Fig. 5, each instance of which represents the treatment of a single patient. Each one of these aspects of COPD management is represented as a collapsed sub-process, which relates to the other process elements as described in the following paragraph.

Fig. 5
figure 5

BPMN diagram outlining the three main steps of the studied COPD care pathway, each one represented as a sub-process. Sub-process COPD diagnosis and assessment is always executed first, followed by Management of stable COPD, which is performed periodically, according to the assessed stage. Ordinary examinations can be rescheduled whenever the COPD stage assigned to the patient changes due to the progressive worsening of the disease or following an exacerbation episode, the latter handled by sub-process Management of COPD exacerbations

Full size image

The overall care process begins in primary care with the COPD diagnosis and assessment, during which practitioners, organized in primary care units (PCUs), have to detect the disease and classify the patient according to the most pertinent severity level. This assessment phase is carried out only once and, then, any patient diagnosed with COPD enters a multidisciplinary program for monitoring and managing the disease, which is enacted periodically, based on the assessed COPD stage. The studied healthcare context of Veneto provides a staging system based on three main levels of severity, which is slightly different from the one presented in [23]. In particular, all patients having a spirometry-related value FEV 1 ≤ 50% are considered at high risk and belong to stage 3 (i.e., there is no stage 4). The general practitioner is in charge of COPD diagnosis and of monitoring and validating the decisions made by pulmonary specialists.

General and pulmonary examinations considered in the Management of stable COPD are scheduled based on the severity of the disease. For this reason, the sub-process representing the ordinary management of COPD is executed periodically. In BPMN, this periodicity is expressed by setting a looping condition for the whole Management of Stable COPD sub-process. In Fig. 5, this is highlighted by a standard loop marker [15], depicted at the bottom of the sub-process.

However, during ordinary COPD management, exacerbations can occur. In the BPMN process of Fig. 5, the occurrence of an exacerbation is represented by means of non-interrupting boundary conditional event Exacerbation episode, which is triggered when an exacerbation occurs.

Non-interrupting boundary events allow the activity to which they are attached to remain active and a new a token is generated to drive a new flow, parallel to the continuing execution of the activity.

Therefore, as event Exacerbation episode is non-interrupting, Management of COPD exacerbations starts while ordinary Management of stable COPD is still being performed. Exacerbations must be promptly treated in order to reduce the impact of the current worsening and prevent the development of future episodes. In general, the treatment of exacerbations does not affect the intervention planned for the ordinary management of COPD.

However, ordinary medical inspections must be re-scheduled whenever the stage of the disease changes, either due to the progression of the disease or to an exacerbation episode. In Fig. 5, this is represented by boundary interrupting signal event Re-schedule, which is triggered by a corresponding signal event thrown either within sub-process Management of stable COPD or following conditional event Stage changed, which captures a change of stage due to an exacerbation. Signal events are used for broadcast communication and, in the depicted process, they represent the interaction between the two sub-processes Management of stable COPD and Management of COPD exacerbations. Throwing signal events are characterized by a filled triangle marker, whereas catching signal events have a unfilled maker of the same sort. Whenever signal event Re-schedule is caught, sub-process Management of stable COPD is interrupted and restarted, according to the periodicity defined for the newly assessed stage. The end of the described macro-process is reached once all interventions for COPD management and exacerbations are concluded.

Figures 6, 7, and 8 show the BPMN diagrams representing the structure of the three introduced sub-processes. The detailed discussion on the structure of such sub-processes and of the related clinical activities is reported in Appendix Appendix: A: Modeling COPD Subprocesses. In these process diagrams, different tasks types are used to denote decision tasks, i.e., process activities incorporating decision-making, which can be represented through a linked DMN decision model, at different levels of detail. As described in Section 2.3, we employ user tasks to denote activities that encompass human-decision making, whereas business rule tasks are used to highlight partially automated decision-making [21].

Fig. 6
figure 6

BPMN process diagram for COPD diagnosis and assessment. The main decision activities identified with the help of experts are case history and working diagnosis, which is a preliminary step of decision Diagnosis of COPD, and COPD staging

Full size image
Fig. 7
figure 7

BPMN process diagram for the ordinary management of stable COPD

Full size image
Fig. 8
figure 8

BPMN process diagram for the extraordinary management of COPD exacerbations

Full size image

All the other process activities are represented as abstract tasks or sub-processes, that is, generic activities whose behavior is not further specified [15].

In the BPMN diagrams, the recording of data to persistent databases is represented through data stores. For readability reasons, we used data objects to show only the exchange of information between different resources, while omitting details related to data flowing through activities executed by the same resource.

In particular, the presented processes need to communicate with the following information systems: The primary care information system, represented by data store PCU db, is the system used by general practitioner to store patient data – This system is usually shared among the practitioners that belong to the same PCU; The hospital information system, represented by data store Hospital db, stores different patient medical records; Finally, the health district authority information system, represented by data store HC district db is mostly used to record data regarding vaccinations and related campaigns. Nowadays, the three information systems are only partially connected, since data about drug prescriptions and examination scheduling are shared between PCUs and hospitals, but most data are still exchanged between professionals through reporting documents. The region of Veneto is currently working on developing a unified electronic health record that will allow practitioners, hospital personnel, health district authorities, and pharmacies to access the same data repositories.

4.3 Modeling Clinical Decisions with DMN

Process-related decisions have been modeled in detail by using DMN diagrams and, sometimes, by specifying more detailed decision logic. A few decision models corresponding to the COPD diagnosis and assessment process had already been introduced in [10]. In this paragraph, we focus on describing the decision modeling for the previously described management of COPD exacerbations process.

In the management of COPD exacerbations, a crucial step is represented by the diagnosis and assessment of an exacerbation, which is evaluated by combining physical findings with the clinical history of the patient [57, 67]. In general, clinical diagnosis is probably the most important example of complex, decision-intensive medical task. Indeed, diagnosis encompasses aspects of human decision-making that rely on medical knowledge, professional experience, and sound sources of clinical information. For this reason, modeling clinical diagnosis by means of formal approaches can become quite cumbersome, as it involves complex (temporal) reasoning and uncertain and incomplete knowledge [68]. Nevertheless, the representation of structure of a decision and of its meaning is interesting for the organization and can be realized by using DMN decision requirement diagrams, which allow one to describe decision-making at quite a high level.

As an example, consider the DMN diagram representing the diagnosis of a COPD exacerbation, depicted in Fig. 9. The diagnosis of an exacerbation relies on the clinical presentation of the patient, who consults the general practitioner complaining of substantial symptomatic and physiologic deterioration [23].

Fig. 9
figure 9

Decision requirement diagram representing the main decision Diagnosis of COPD exacerbation, together with the input data needed for making the decision, the used business knowledge, and the sources responsible for the decision. The decision is linked to task Diagnosis of exacerbation of Fig. 8

Full size image

In the DRD of Fig. 9, Diagnosis of COPD exacerbation is portrayed as the main decision, which ideally responds to the question “Is the patient experiencing an exacerbation of COPD?”. The decision is made by a general practitioner, represented as a knowledge source, who is responsible for assessing the degree of symptom worsening and for evaluating if the exacerbation is life-threatening. Several clinical findings have to be considered when assessing an exacerbation. During a physical examination, pulse oximetry is performed to assess the need for supplementary oxygen therapy. Besides, hemodynamic stability, use of accessory respiratory muscles, andresponse to treatment are evaluated. The general practitioner must also consider the number of previous exacerbation episodes and the presence of comorbidities, which are combined with information about COPD severity to predict the patient risk of exacerbations. COPD severity corresponds to the output of sub-decision Evaluate severity of COPD, which is based on spirometric assessment. Results of previously administered CAT, spirometric assessment, and history of exacerbations are retrieved from the PCU db, depicted as knowledge source. Probability of comorbidities is a business knowledge model that describes the kind of comorbidities that are commonly found during an exacerbation and the probability of finding more of them. Business knowledge models describe a reusable fragment of decision logic or know-how, which can be retrieved by guidelines or by local organizational knowledge. In the presented context, the knowledge is based on data collected in the region, since the probability of comorbidities changes according to the distribution of the population in the territory. Similarly, business knowledge model Assess risk of exacerbations encloses the knowledge required for assessing exacerbation risk, based on the combination of COPD severity, symptomatic assessment and history of previous exacerbations [23].

The diagram of Fig. 9 is linked to the user task Diagnosis of exacerbation of the process shown in Fig. 8. The result of the decision is used by gateway Is exacerbation life threatening to determine if the patient must be treated in outpatient settings or hospitalized.

The DRD introduced in Fig. 9 encompasses both human decision-making and partially automated decisions, the latter ones reviewed and validated by the general practitioner. For the main decision Diagnosis of exacerbation, we decided not to specify decision logic, as the presented DRD suffices in explaining the expected structure and input data needed to make this human decision. However, a few elements in the considered diagram have a decision logic specified at different levels of abstraction, by using the various expressions provided by the DMN standard [21]. In detail, decision logic for business knowledge model Probability of comorbidities is represented by a boxed a literal expression, shown in Fig. 10, written as plain English text and, thus, not suitable for automation. Conversely, sub-decision Evaluate severity of COPD is based on well-defined rules that determine how the amount airflow limitation should be associated to a specific COPD stage. Hence, decision logic can be easily represented by means of a decision table that relates spirometric values FEV1 and FEV1/FVC to the corresponding COPD stage. Figure 11 shows the decision logic of decision Evaluate severity of COPD, which invokes decision table Evaluate severity of COPD table, passing Spirometric assessment.FEV1 as FEV1 parameter and Spirometric assessment.FEV1/FVC as FEV1/FVC parameter. Decision evaluate COPD severity, invokes the corresponding decision table. The presented table has been verified with Signavio and, as expected, it is not complete as no rule exist for (≤ 70%,a n y). However, this omission was intentional, since this latter case is not considered in COPD treatment.

Fig. 10
figure 10

Boxed literal expression, written in plain English, and representing the decision logic of the Probability of comorbidities business knowledge model

Full size image
Fig. 11
figure 11

Decision table representing the decision logic for decision Evaluate severity of COPD, based on spirometric data

Full size image

Finally, as an example of formal expression allowed in DMN, consider the decision logic for business knowledge model Assess risk of exacerbations, represented in Fig. 12 through a boxed FEEL expression which describes how an output value is derived from its input values. The presented formal expression is used for combined COPD assessment in order to understand which is the impact of COPD on an individual patient, in terms of future exacerbations, based on current symptoms, spirometric assessment, and exacerbation history [23]. Patients are classified into four main categories, which summarize the risk of exacerbations and expected health status. For instance, a patient with a CAT score of 16, assessed with “Moderate” COPD, and a history of three exacerbations within the last 12 months has a risk of exacerbations corresponding to “High, more symptoms”.

Fig. 12
figure 12

Decision logic for the Assess risk of exacerbations business knowledge model, adapted from guidelines on combined COPD assessment [23]

Full size image

4.4 Dealing with Information and Process Indicators

The modeling of the described COPD processes and decisions underlined the strong connection that exists between processes and related clinical and organizational information, throughout all the design phase. On the one hand, data needed for process and decision execution must be identified during process design to define which is the information needed during process enactment. On the other hand, new informational value generated during process simulation and execution must be properly managed and used for re-engineering as-is processes and decisions. In the management of chronic diseases, most clinical knowledge and conformance data stem from standard guidelines, whereas operational data are retrieved from process execution logs or health information systems [69]. However, health information systems are usually meant to serve multiple and disparate care processes and, thus, data availability, standardization, and maintainability may become a complex issue.

In the studied context, a first step toward the identification of a minimum set of data that are relevant for process execution and audit is represented by the definition of process indicators, used to assess the quality of the provided care from different viewpoints and levels of abstraction.

The definition of indicators is part of the care process specification and is done by a “focus group” of clinical experts, who identify clinical, organizational, and social criteria for evaluating process outcomes [70]. Indicators are used to validate the structure of the process and to evaluate the organization potential in terms of resource distribution and consumption. In addition, they are useful to estimate process compliance with respect to both clinical and organizational outcomes, and cost sustainability.

4.4.1 Local KPIs

An example of local KPI related to process metrics is the average total cost spent by the regional healthcare system for treating COPD patients assessed with stage 3. Local KPIs allow one to quantify the probability that a process execution path is preferred over another, within the context of a data-based process gateway. For instance, the percentage of smoking patients determines how many times the care providers involved in the process of COPD treatment have to deal with smoke cessation. In the region of Veneto, it has been estimated that the probability of contracting COPD for smokers are 25% higher than for non-smoking patients, and can increase up to 30% in patients that smoke more than 30 cigarettes per day. In the process of Fig. 6, this probability value influences the execution of all tasks that concern the administration of smoking questionnaires, as Mondor and Fagerstörm tests can be skipped if the patient is not a smoker. Local KPIs can also be derived and evaluated with process simulation techniques, as explained in Section 4.5.

4.4.2 Global KPIs

The indicators defined by the regional healthcare system of Veneto are global KPIs used to give a high level estimate of the impact of care standardization in terms of costs, patients involvement, and medical personnel competence. Such indicators have been highlighted as text annotations in the process diagrams of Section 4.2. Indicators were provided by clinicians and they have been defined by the regional care stakeholders. Our goal was not to define them directly, but rather to show where in the process they are calculated.

For instance, Indicator 5: Performed vaccinations is defined to quantify the number of performed influenza vaccinations, in order to assess the quality of secondary prevention of COPD. In the documents provided by the Veneto region, it is defined as follows.

Definition 1 (Indicator 5—Performed vaccinations (Fig. 7))

Description: :

Secondary prevention of patients diagnosed with COPD.

Numerator: :

Number of people aged ≥ 40 diagnosed with COPD (i.e., ICD9-CM 491.2x and 496.x) and having received a vaccination against influenza in the last 12 months.

Denominator: :

Totality of patients aged ≥ 40 diagnosed with COPD (i.e., ICD9-CM 491.2x and 496.x).

Needed Data: :

Patient ID, diagnosis of COPD (ICD9-CM 491.2x and 496.x), influenza vaccination, date of last vaccination.

Indicator 5 is associated to task Verify administered vaccinations of the process shown in Fig. 7 and experts expect the value of this indicator to remain greater than the 40% of all the patients diagnosed with COPD (and quantified by Indicator 2A). Any value lower than the expected threshold should be considered an index of poor process performance, to be further investigated by considering re-engineering. With process management tools, Indicator 5 can be calculated by counting how many times the process branch labeled with YES is followed after each exclusive gateway Vaccination administrated? As for data requirements, this indicator suggests that the following data need to be collected during the care process: A patient identifying code, the diagnosis of COPD registered according to the ICD-9-CM coding systems, the influenza vaccination, and the date of the vaccination. As for the global scope of the indicator, data about the performed vaccinations gathered during the management of stable COPD in Veneto, are combined with data collected at a national level to evaluate the efficacy of routine vaccination programs. In the years 2002–2009, 32% of Italian population received vaccination against influenza, whereas in the years 2010–2016, the same value dropped to 18%. Among patients with COPD, around 75% of them received a vaccination against influenza in the same time-span. This drop in the number of vaccinations, highlighted by Indicator 5, can be explained by the recent spread of several anti-vaccination movements that developed in the considered territory in the last years. As a consequence, new vaccination programs were introduced, patients were actively informed about the risks of non-vaccination, and a service for delivering vaccinations at home was provided. This latter intervention was directed not only to COPD patients, but to all those considered at risk by the National Healthcare System, whence the global scope.

As a further example, here we report the definition of Indicator 7, translated in English from Regional documents related to the care pathway.

Definition 2 (Indicator 7—Appropriateness of therapy (Fig. 7))

Description: :

Appropriate therapeutic use of only bronchodilators in people diagnosed with COPD in stage 2.

Numerator: :

Number of people diagnosed with COPD (i.e., ICD9-CM 491.2x and 496.x) and assessed with stage 2 and receiving only bronchodilator therapy.

Denominator: :

Totality of patients diagnosed with COPD (i.e., ICD9-CM 491.2x and 496.x) and assessed with stage 2.

Needed Data: :

Patient ID, prescription data regarding short and long term bronchodilators (prescription code ATC R03).

The remaining indicators defined within the processes can be used as Indicator 5 and Indicator 7 to define (clinical) data requirements and measure clinical and organizational outcomes.

As for relationships between local and global KPIs and HQCIs in the specific case of COPD care, we mention here the quality indicator PQI 05 - Chronic obstructive pulmonary disease (COPD) or asthma in older adults admission rate [71], which is closely related to the definition of COPD patients, adopted by the Veneto Region and related to Indicator 1—prevalence of patients with suspected COPD. Indeed, the identification of patients with COPD is based on the following criteria from hospital and drug prescriptions:

  • Admissions with a principal/secondary diagnosis of COPD (codes ICD-9-CM: 490-492, 494, 496), ages 45 years and older, or

  • Sound and continuous drug prescriptions related to respiratory treatments (the detailed specification is done with respect to the overall duration of the therapy in the last two years, the number of prescriptions, and the ATC therapeutic class of drugs).

A further example of HQCI that could rely on the modeled COPD process is the Indicator NQMC:010510 defined as Use of spirometry testing in the assessment and diagnosis of COPD: percentage of members 40 years of age and older with a new diagnosis of COPD or newly active COPD, who received appropriate spirometry testing to confirm the diagnosis [72]. Indeed, such indicator is enforced to be 100% for patients treated according to the given pathways (without considering some small differences with respect to the age of patients), as all patients undergo spirometry either in PCUs or at the hospital.

4.5 Simulation of COPD Processes

In the application of the proposed methodology, we used simulation for validating the behavior of the modeled COPD processes by spotting pitfalls related to erroneous control flow. Then, we evaluated the performance of the processes based on current data collected from the Regional Healthcare System, and we studied the behavior of the processes when dealing with hypothetical scenarios. The latter ones have been defined according to the indications of experts, who were interested in gathering insights regarding both the quality of the interactions between process resources and the performance in case of increased amount of patients in severe conditions.

We exploited the simulation functionalities provided by the Signavio Process Editor [18], which allows one to directly open the process model in the simulation environment, without the need for further configuration. Decision logic has been simulated with the Camunda DMN Simulator [73], which allows one to verify the output of a decision table, given custom input values.

Signavio supports three kinds of simulation of syntactically sound BPMN processes (verification of the syntax is done by the tool prior to simulation), namely step-by-step, one-case, and multiple case simulation. Step-by-step simulation is guided by the modeler, who chooses which process flows are enabled, and it is mainly used for verifying that the process captures all the possible desired execution behaviors. This is fine for representing and observing the process flow and, therefore, it can be used when interacting with clinicians for improving common understanding. One-case simulation allows one to interactively reproduce the execution of a single process instance, according to specific conditions defined on process execution. Conversely, multiple-case simulation supports the run of multiple instances of the same process model, thus allowing one to aggregate results and analyze the overall workload of the process. In all circumstances, Signavio allows flow-related tokens to be graphically visualized, so that partial results can be visually monitored by process modelers and stakeholders.

The simulation tool requires the following information in input:

  1. 1.

    The probability associated to each outcome of an exclusive gateway (e.g., the proportion of COPD patients in stage 3 for gateway stage 3? in Fig. 6);

  2. 2.

    The fixed costs associated with each activity (e.g., spirometry performed in hospital costs around 25⋹);

  3. 3.

    The probability distribution that describes the duration for each activity (e.g., arterial blood gas analysis lasts 10 min, on average);

  4. 4.

    The hourly cost of each resource and the corresponding working schedule.

Data regarding the costs and duration of examinations have been collected by regional hospitals, by analyzing scheduled events and medical reports. On the contrary, the number of primary and hospital care resources involved in the management of COPD is managed directly by the regional healthcare system. According to regional data and experts’ knowledge, 185,000 patients are diagnosed every year in the Veneto region. To obtain a reliable estimate of the amount of time that each resource devotes to COPD care, we considered that COPD patients in Veneto correspond to the 7,9% of the overall regional population. Accordingly, we assumed that the same proportion of patients is assigned to each practitioner, as in Italy each general doctor is responsible for the same amount of patients. Of course, we had to take territorial variance into account, as the percentage of ill people increases up to 11,8% in polluted areas. The same strategy has been adopted for estimating the time that pulmonary specialists working in hospitals dedicate to COPD patients. Thus, we considered having 3000 pulmonary specialists, working 15,000 hours per week with COPD patients, and 3500 general practitioners, working 58,000 hours per week with COPD patients (i.e., on average 1 h and 20 min of work for each general practitioners).

We created multiple simulation scenarios, starting from those that reproduce current reality to interesting what-if scenarios, suggested by experts. More particularly, we discuss here some simulations related to processes COPD Diagnosis and Assessment and Management of COPD Exacerbations, considering different aspects as (i) the proportion of spirometry test executed in PCUs with respect to those executed in hospitals and (ii) the increase in the number of patients diagnosed with COPD during winter, for process COPD Diagnosis and Assessment, while focusing on (iii) longer hospitalization following exacerbations episodes for process Management of COPD Exacerbations.

4.5.1 Simulating Process COPD Diagnosis and Assessment

The first multiple case simulation focuses on the overall yearly cost of the process, depending whether spirometry tests are executed either in hospitals or in PCUs. To perform such simulation, we changed the proportion of patients following different paths according to gateway Spirometry prescription or direct request? in Fig. 6, which specifies whether the spirometry has to be done at the hospital or by PCUs. In Fig. 13, the difference between the costs associated to the performance of spirometry are shown. As discussed in [10], spirometry should be preferably performed in PCUs, as the costs of hospital spirometers is higher and waiting lists should be taken into account. Indeed, spirometry tests in PCUs are administered through cheaper devices, while in hospitals spirometry tests are done with more expensive devices, that should be reserved for severe respiratory complications.

Fig. 13
figure 13

Costs of the process COPD diagnosis and assessment based on changing proportions of spirometry examinations carried out in PCUs or in hospital

Full size image

A second simulation deals with the non-homogeneous distribution of COPD diagnoses during the year. Indeed, conditions of patients tend to worsen due to the cold weather and evidence suggests that in Veneto there are 15% more cases of COPD diagnosed in winter than on average during the year. According to these observations coming from regional data and experts’ knowledge, physicians and healthcare stakeholders were interested in having an estimate of resources and costs during such season. Thus, we simulated the process COPD diagnosis and assessment for 120 days, corresponding to the average period of cold weather, considering that 68,800 patients are diagnosed in the given period. Such amount of patients is derived by considering that there are five working days per week (i.e., 86 days in 120 day frame), and 800 patients are managed every working day, thus considering an increase of about 15% with respect to the average number of daily patients.

The Signavio simulation interface, shown in Fig. 14, suggests a bottleneck in correspondence of the general practitioner, who is overloaded with the first diagnostic assessment. Figure 14 depicts in the blue bar at the right of activity Case history and working diagnosis the value of 67,300 (lower than the total number of patients—68,800), which is the number of patients who can be managed in the given period according to the actual number of available physicians. To complete the results of simulation and to allow the comparison of different scenarios, the part on the right of Fig. 14 reports quantitative results from the simulation of the winter scenario and from the simulation of the standard one. In particular, the report depicts costs, total cycle time, which is the overall amount of durations needed to complete all the process instances, and resource consumption, that is the amount of time resources need to execute the process. All these results can be expanded and visualized in detail. For instance, when clicking on the highlighted red box related to Bottlenecks in Fig. 14, we are able to see that the workload for each general practitioner is estimated to be around 184 days full-time, which is an excessive amount compared to the considered working schedule for 120 days.

Fig. 14
figure 14

Simulation results shown in Signavio for scenario Winter, run on 68,800 instances over 120 days. The tool highlights a bottleneck corresponding to the general practitioner, who is responsible for diagnosing COPD

Full size image

4.5.2 Simulating Process Management of COPD Exacerbations

Simulation results of process Management of COPD Exacerbations, depicted in Fig. 8, obtained for different lengths of hospitalization, are outlined in Fig. 15. Costs shown in the histogram are calculated by summing the fixed costs of hospitalization with the costs associated to the resources. In detail, we simulated the case of having 72,000 patients experiencing COPD exacerbation and considered that the 34% of them is hospitalized. Moreover, we evaluated different average hospitalization lengths, ranging from 3 to 20 days. As expected, the costs of the process increases drastically when patients are hospitalized for a longer time. The distribution of the total cost of process Management of COPD exacerbations considering the most relevant tasks for expense calculation is shown in the pie chart of Fig. 16. The depicted results correspond to the execution of the process by setting an average hospitalization length of 15 days.

Fig. 15
figure 15

Simulation results of process Management of COPD exacerbations considering different hospitalization lengths, run on 72,000 instances over 100 days, with 23,800 patients hospitalized

Full size image
Fig. 16
figure 16

Distribution of the total cost of executing process Management of COPD exacerbations, considering a hospitalization length of 15 days

Full size image

5 Related Work

In this section, we discuss related work by focusing on different approaches for healthcare process design. We begin with presenting work proposed by the community of BPM and information systems. Then, we focus on research efforts conducted in the field of medical informatics, oriented to the development of CIGs systems. Finally, we discuss and compare our contribution with the introduced approaches.

5.1 Healthcare Process Modeling in BPM

Process management approaches have been employed in healthcare to support the modeling and enactment of organizational interdisciplinary processes [6]. However, applications of process modeling approaches in healthcare are still modest, despite the suitability of BPM techniques for representing complex and multidisciplinary organizational procedures. In addition, existing approaches tend to target specific clinical domains rather than proposing general methodologies, as exhaustively surveyed in [3].

Healthcare is considered a challenging domain for BPM approaches, as flexibility is often required and processes heavily depend on both information and knowledge [1, 6]. According to [36], a knowledge-intensive process is a workflow whose conduct and execution are heavily dependent on knowledge workers performing various interconnected and knowledge-intensive decision-making tasks, whose management and execution requires specific support. The role of human knowledge is considered central in such processes and, due to the variability in their structure, they cannot be directly mapped to business process diagrams.

However, organizational aspects of knowledge-intensive processes can be captured by BPM techniques [3, 6], whereas clinical or medical treatment processes can suitably handled by case management or artifact-based approaches [25, 74,75,76]. For instance, the ADEPT framework [75] allows one to revise running process instances and schemata in order to support the management of clinical guidelines. Among the interesting features of ADEPT, modularity, ease of use, and management of temporal aspects stand out. In the context of case management, a clinical pathway for living donor liver transplantation was firstly modeled using BPMN in [76]. Then, in order to facilitate transferability of the modeled pathway to other hospitals and to include flexibility caused by differences in treatments due to local policies, the processes have been modeled by using the OMG standard Case Management Model and Notation (CMMN)[25]. This standard can be used to model specific cases, together with the data that drive their execution, in order to simulate the decisions taken by a knowledge worker during process run-time.

However, traditional BPM approaches are activity-centric, that is, they focus on representing the process control flow, by supporting structured and repetitive organizational processes. As for BPMN-based approaches, BPMN is used for modeling surgical pathology processes in [7]. According to the authors, the notation was chosen because it is widely accepted and recognized in industry, due to the easiness provided for the design of simple or high level processes. Indeed, they advocate that the obtained models have be as simple, transparent, and understandable by care providers.

Most research proposals focus on extending the core of the BPMN notation to improve its expressiveness with respect to the design of healthcare processes, often introducing new elements that are tailored for modeling specific clinical circumstances. In [77], the authors propose a conservative extension of BPMN for the healthcare domain, with the aim of incorporating role information and facilitate the assignment of tasks to performing resources. A major extension to BPMN, proposed to systematically support the design of clinical pathways, is developed in [78]. This extension, named BPMN4CP, incorporates concepts retrieved from the context of clinical pathways, with the aim of enhancing evidence-based decision activities related to the considered domain. New tasks types are added to model medical diagnosis and therapies, while different data objects types are used for representing documents related to both medical and administrative procedures.

Conceptual modeling of care pathways is addressed under different viewpoints in [79] and [80]. Specifically, in [79], a novel methodology for connecting processes and data belonging to a healthcare information system is proposed, based on the concept of task view, which represents the information that can be accessed by a process task and that is relevant for its execution. In [80], a data-aware representation of BPMN processes is presented as a means to support clinicians working in ICU to understand their responsibilities in the care process, how therapies are temporally constrained and which are the critical decisions that affect the quality of the provided care.

The processes designed in [80] have been further refined and used in [81, 82] as a blueprint for guiding the development of a rule-based decision-support system for antibiotic stewardship.

Finally, in [83], two clinical pathways for colon and rectum carcinoma are designed as part of a pilot project, with the aim of evaluating the benefits of using BPMN for modeling structured medical procedures.

A general methodology for the design of medical processes was recently presented in [84]. The authors present an approach based on three main phases for healthcare process modeling, starting from context analysis and addressing the design of conceptual and logical process models. UML activity diagrams are chosen to represent processes, in order to ease integration with other UML diagrams, such as class diagrams, suitable for representing other aspects of the clinical domain. Despite the motivations described in [84] are similar to those addressed in this paper, the two methodologies have different focuses. In [84], the integration of medical processes and health information systems plays a central role, whereas the modeling and management of decisions is not specifically addresses. Moreover, authors provide a mapping toward logical formalisms, while we focused mostly on conceptual design, yet completing it with organizational analysis based on KPIs and process simulation.

In general, all the presented approaches are directed to expert modelers and aim at improving understanding and, in some cases, standardization of care procedures under an organizational standpoint.

However, as processes are becoming more and more decision-intensive, the need for a more appropriate language to support the modeling of process-related decision has recently been recognized within the BPM community. In healthcare, user decisions and unpredictable events contribute to the continuous generation of new clinical knowledge, thus making the structure of the processes less rigid. The previously introduced BPMN-based approaches, do not explicitly deal with the design of process-related decisions, as these either tend to remain hidden within other process elements or are managed by dedicated decision support systems. In general, clinical decision support is often directed to medical personnel, whereas decision management is useful to serve organizational purposes.

DMN has been proposed to model different aspects of decision-making and to complement BPMN to this end. The recently proposed notation allows one to model decision requirements and decision logic following the well-known “separation of concerns” paradigm [22]. This latter principle allows designers to keep process and decision modeling separate, which is desirable to reduce complexity and improve model maintainability and scalability [30]. DMN has been used for decision-making design in the context of collaborative networks in [41]. An approach to derive DMN decision models from BPMN process models is discussed in [85]. Upon having identified important decision steps in the process, decision logic is extracted from process logs, in the form of decision tables, and a compound DMN model is constructed with the aim of re-adapting the process diagram to fit the modeled decision logic. A logic-based formalization of DMN decision tables has recently been provided in [86], in order to unambiguously define a semantics for such constructs and introduce several analysis tasks, focused on correctness checking. However, at the best of our knowledge, DMN has not yet been applied for modeling clinical decisions, despite the suitability of decision requirement diagrams for the design and sharing of human decision-making. Indeed, decisions in healthcare are complex, shared among different professionals, and often rely on medical evidence and expertise. Despite the formalization of these aspects is quite complex, explanatory decision requirements diagrams can be used for compliance, standardization, and training and educational purposes.

Finally, business process re-engineering (BPR) requires a clear understanding and a radical re-design of organizational procedures, in order to overcome critical steps and to improve process performance, flexibility and adaptability to change. Most re-engineering approaches focus on re-thinking the process control flow, in order to allow parallel execution of activities and resource re-allocation with the aim of reducing execution times and costs. In this scenario, data and decisions are often managed and re-engineered independently and only information related to process metrics is employed for this scope. Examples of canonical applications of process and knowledge re-engineering in healthcare are discussed in [8, 87, 88]. In detail, in [8] a framework based on event driven process chains, the entity-relationship model, and discrete event simulation is introduced in order to define and analyze the current state of a surgical ward and design an improved system. A more general study addressing the identification of those business process re-engineering principles that can improve the application of E-Health technologies within a healthcare environment is conducted in [87].

5.2 Clinical and Healthcare Process Modeling: Clinical Interpretable Guideline Approaches

Despite the complexity of medical and clinical processes, the community of medical informatics has been actively investigating and developing systems for the modeling and management of clinical practice guidelines [3].

Computer-interpretable guidelines (CIGs) are formalizations of clinical practice guidelines aimed at fostering the development of guideline-based decision support systems [89]. In general, the implementation of guideline-based support systems requires timely data sharing, to ensure communication between care providers, data completeness, and correct formalization of guideline rules and statements [90]. In addition, proper clinical knowledge and decision management features must be provided for dealing with knowledge-intensive care processes.

According to [91], the following areas of development must be considered when modeling clinical guidelines: (i) modeling and representation, (ii) acquisition, (iii) verification and testing, and (iv) execution and monitoring. The most relevant CIGs formalisms are exhaustively reviewed in [89]. Here, we focus on discussing workflow-based approaches and task-network models, as the structure of the latter ones can be compared to the concept of process control flow.

Workflow and process modeling techniques have been applied for specifying, designing, and implementing procedural aspects of clinical guidelines. One of the most complete projects addressing the integration of clinical guidelines into organizational workflows is the GUIDE project, developed within the Careflow framework [92]. GUIDE is a multi-level architecture designed to integrate a formalized model of the medical knowledge retrieved from clinical guidelines with workflow management systems. The presented approach is based on computational formalisms that facilitate the work of healthcare stakeholders by suggesting them the medical task to execute and the resources to allocate.

In [51], the authors introduce a temporal model for fostering the conceptual design of clinical workflows for stroke prevention and management, by addressing activity duration, delays, periodic and absolute constraints, and inter-activity constraints.

As for CIGs formalisms, several languages for clinical guideline modeling have been proposed, such as GLIF [93], Asbru [94], PROforma [95], and SAGE [96].

The guideline interchange format (GLIF) was proposed to ease guideline sharing [93]. The core language includes several ontological entities that allow the representation of guidelines as multi-step flowcharts that support branching logic. The current core, GLIF3, supports the modeling of guidelines at different abstraction levels, namely conceptual, computable, and implementable. An interesting aspect of GLIF3 is the hierarchical modeling of decisions, which distinguishes between automated decision steps and those that are made by a health worker. Asbru [94] enables designers to represent clinical guidelines, by considering continuous prescribed actions, and by supporting the parallel, in sequence, or ordered execution of care plans. Sub-plans and their outcomes can also be specified. PROforma [95] allows one to represent guidelines as directed graphs of tasks, which can be either plans, decisions, actions, and enquiries. Scheduling and temporal constraints define task ordering, and task execution is based on the triggering of pre-/post-conditions. Finally, SAGE [96] builds upon previously introduced work [93,94,95] and incorporates workflow representation, information, and terminology standards, and control flow standards. Likewise GUIDE [92], it fosters the definition of an organizational model, with resources and roles. Such model and the guideline model are kept separate, to ease the adaptation of the guideline to local organizational realities.

A recent architectural framework for promoting the design, implementation, and evaluation of continuous guideline-based decision support is presented in [97]. A decision support engine, called PICARD, interacts with a guideline knowledge library and a temporal reasoning service in order to apply medical knowledge to patient data during the execution of clinical tasks. This framework provides alerts and recommendations at the point of care to health workers, patients, and knowledge engineers. In detail, patients treated in home-care settings can connect via a mobile client application to obtain personalized recommendations. Care providers such as physicians or nurses receive alerts, or therapy recommendations based on telemedicine data. Knowledge engineers can perform simulations on different guideline-related scenarios. In addition, the architecture allows accesses for the retrieval of procedural knowledge, usually expressed in terms of workflows. Currently, PICARD is the backbone for MobiGuide [98], an intelligent decision-support system for patients affected by chronic diseases. Briefly, patients are provided with sensors, which collect real-time information that is integrated with clinical history data and medical knowledge in order for supporting better decision-making. Alerts and personalized guideline-based recommendations are sent to patients, through their mobile phones.

A further contribution from the MobiGuide project is described in [99], where the authors consider different strategies for integrating CIGs with business processes (organizational workflows, in the authors’ terminology) and propose the implementation of some use cases in the domain of atrial fibrillation. Such implementation is based on a loosely-coupled integration of CIG and BP engines, mediated through the health record database system. With respect to our proposal, which focuses on methodological issues, in [99] the authors pay attention to more implementation-related issues, with the use of several healthcare-related standards as IHE, HL7, and other XML-based general standards. From this point of view, no attention is paid to consider the expressivity of BPMN advanced constructs, as events, exceptions, complex gateways, and so on with respect to the specification of care pathways. Moreover, no methodological issues are discussed with regard to the design of care pathways. As for more implementation-oriented issues, standards such as HL7 [100], ICD9-CM [101], or SNOMED CT [102] can be used to encode knowledge in DMN requirement diagrams. In addition, they could be used as values for FEEL expressions, as FEEL supports several kinds of data structures and its semantics draws inspiration from Java, JavaScript, XPath, SQL, PMML, Lisp, and many others [21]. In particular, FEEL is thought to be tool-independent, executable, and expressive enough to support all kinds of decision logic.

Among the first studies that considered both medical records, workflows, and HL7 standard to deal with the derivation of quality indicators, we mention here [103], where authors underline that workflow aspects must be considered and modeled to evaluate quality indicators. Such kind of results may be considered as a motivation of our methodological proposal as it confirms that process-related aspects need to be considered together with clinical data.

Generally speaking, despite both CIGs and BPM approaches aim to improve healthcare processes and decision-making, a few crucial differences can be discerned. CIGs are meant to be used by clinicians and, thus, they focus on clinical decision support and on the development of solutions tailored for dealing with a specific clinical guideline, enacted in a well-defined context. On the contrary, BPM approaches in healthcare aim to foster standard-based tools for supporting broader organizational as well clinical aspects in healthcare, handled by physicians, healthcare professionals, and IT and organization experts.

5.3 Discussion

In this paper, we provide an agile design methodology, based on the well-known OMG standards BPMN and DMN, that addresses the integrated yet complimentary design, implementation, and enactment of care processes and related decisions, considering the viewpoint of an expert modeler. The introduced step-wise approach promotes the iterative and agile design of organizational aspects of care pathways, mainly by focusing on the standardization of processes and decisions. The methodology supports incremental refinements, as the modeler can choose how and how many steps to apply, depending on the final objectives. Procedural, decisional, and informational aspects of care pathways are represented in an integrated and scalable format, thus supporting the re-use of clinical data and knowledge for process and decision re-engineering. To our knowledge, this is the first time a structured approach based on the joint use of BPMN and DMN has been applied to the healthcare domain.

Compared to the discussed contributions belonging to the BPM community, the methodological approach introduced in this paper utilizes conceptual modeling techniques for purposes that go beyond clinical process documentation and information sharing. Indeed, simulation and indicator-based process analysis are discussed, and the role of information in process management is promoted to first citizen in the methodology. The integration of standard process modeling techniques with systematic decision and information design, possibly used for re-engineering purposes, is a novelty of the introduced methodological framework. In addition, the methodology is presented at a quite high level, thus allowing the integration of other approaches, suitable to meet specific requirements. For instance, having used the OMG notations BPMN and DMN, facilitates the integration of CMMN models, in case there is the need to deal with more flexible clinical aspects. Similarly, standard ontologies and terminologies can be integrated in the BPMN and DMN processes, for defining domain-specific concepts.

Whereas traditional process management techniques are suitable for representing organizational aspects and procedural process knowledge, computer-interpretable guidelines approaches aim to support and facilitate appropriate decision-making at the point of care. Usually, the main goal of such systems is to provide direct decision support to clinicians, by fostering clinical knowledge representation. For this reason, CIGs are suitable to capture complex knowledge-based aspects of clinical and medical treatment processes. However, the main drawback of CIGs approaches is their lack of standardization [3, 89], which motivated the introduction of workflow-based approaches for better modeling organizational aspects [92, 96]. Indeed, despite the abundance of language proposals, no specific proposal emerges over the others, and each approach focuses on a selected set of modeling aspects.

The goal of the proposed methodology is to start from a standard, modular, and extensible core, that allows one to exploit existing standard tools for healthcare process modeling. The benefits of using standard tools are manifold. First of all, process and decision modeling are based on graphical and understandable notations, that can be conservatively extended and integrated with other (standard) approaches to suit the need for flexibility required in the healthcare domain. For instance, new types of tasks can be created in conformance to the standard, as done in [78], and process cases can be added to handle run-time variability [76]. Secondly, process exchange, deployment, and verification are supported by several tools, which may already be used by the administrative counterpart of healthcare organizations. Besides, modelers are facilitated by the existence of numerous control-flow, data, temporal, and resource design patterns [38, 39, 55, 104].

In general, BPMN is a powerful language for capturing various procedural aspects, as it provides a wide range of constructs suitable for advanced event and exception handling. Especially in the context of temporal constraints, researchers are actively proposing approaches for the verification of a process temporal properties and for the resolution of related violations. Motivated by processes taken from the domain of emergency medicine, in [49] the authors propose an approach for representing and verifying temporal constraints. These are expressed by extending a basic BPM modeling notation and suitable algorithms have been proposed to verify dynamic properties of temporally-enhanced business processes. TNest is a structured and modular workflow modeling language providing full support of temporal constraint specification during process design, presented in [9]. In particular, TNest allows one to define two main kinds of temporal constraints, that is, activity duration and relative constraints. Finally, in [53] temporal constraints in the context of modularized processes are investigated. In this setting, the re-use of process knowledge must be enabled and, thus, authors consider the issue of representing the overall temporal behavior of a sub-process. This way, temporally enhanced sub-processes can be used within other processes, hiding the internal temporal features of such subprocesses.

Yet, born to capture process control-flow, BPMN does not fully support other perspectives, such as the representation of domain knowledge and the integration of complex, structured data [6, 105]. Despite research efforts are devoted in this direction considering clinical domains [11, 56, 75, 76], the expressiveness of CIGs remains more suitable for dealing with complex clinical aspects, especially when developing tools that require clinical knowledge and data representation and the direct involvement of physicians and patients [98].

6 Conclusions

In this paper, we introduced a methodological framework for supporting the design, implementation, and enactment of decision-intensive healthcare process, by exploiting advanced process design techniques and by integrating them with proper decision modeling. We advocate that combining the advantages derived from the design of process and decision models, each one stressing on a different care perspective, increases the overall value that such a synergistic design approach can bring to care pathways development. In addition, the proposed methodology provides a preliminary classification of the kinds of data involved during the different phases of process development. Proper information and knowledge management allows stakeholders to better support iterative process design, execution, and re-engineering, thus leading to more flexible and information-aware care pathways.

The advantages brought by the proposed methodology for care pathways design have been compared to those achieved by computer-interpretable guidelines for clinical process modeling. We concluded that, whereas CIGs are suitable to build for decision support systems directed to clinicians, the use of BPM approaches fosters the definition of a standard-based core of care pathways and related information, able to address crucial aspects of healthcare organizations. Given the technological and market-related scenario discussed for BPM in the Introduction, we could easily compare the current situation for BPM systems and healthcare to the situation of database management systems (DBMSs) and medicine in the late 80s and in the early 90s. At that times, many research efforts were related to how to use and extend such database methods and tools to manage (even complex) clinical data. Now, it is completely obvious that any software system managing large amounts of clinical data must rely on the design and realization of a suitable database managed by a DBMS. Similarly, it is becoming evident that any software system for the management of care pathways will rely and will have to consider BPM methodologies and technologies. According to this observation, our proposal may be considered as a first attempt to highlight specific issues we have to consider when designing decision-intensive care pathways.

For future work, we intend to further investigate the relationships between processes and healthcare data models, in order be able to detail relevant data at a sufficient level of abstraction, suitable for implementation and integration within existing healthcare systems.