Keywords

1 Introduction

The clinical and administrative processes in today’s healthcare environments are becoming increasingly complex and intertwined and the provision of clinical care involves a complex series of physical and cognitive activities. A multitude of stakeholders and healthcare providers with the need for rapid decision-making, communication and coordination, together with the steadily growing amount of medical information, all contribute to the view of healthcare as a complex cognitive work domain. The healthcare environment can also be characterized as very dynamic, in which clinicians rapidly switch between tasks. The process is partially planned, but at the same time driven by events and emergencies [4, 6].

To be able to cope with the dynamism and complexities in their environments, many organizations have been forced to restructure their operations and integrate complex business processes across functional units and across organizational boundaries [9]. This has in many cases led to the adoption of process-oriented approaches and enterprise process modeling to manage organizational activities. Process modeling is used within organizations as a method to increase the focus on and knowledge of organizational processes, and function as a key instrument to organize activities and to improve the understanding of their interrelationships [24]. Today, there is a large number of modeling languages available. The first process modelling language was described as early as 1921 [11], and process modeling has been performed in earnest relative to IT and organizational development at least since the 70ties. Lately, with the proliferation of BPM (Business Process Management), interest and use of process modeling has increased even further.

A lot of research has been done in the field of enterprise process modelling, as well as on the subject of how to judge the appropriateness of the models and modeling languages [18, 20, 21, 23]. Much work is done on a theoretical level, but in order to better understand the mechanisms at work in the application of enterprise process models, real-life cases can provide interesting insights [12].

This paper presents experience from a case study on the use of process models in the healthcare sector. An overview of categories of process models are found in Sect. 2. How the interplay in particular between as-is, ought-to-be and to-be models can be exploited is presented in Sect. 3. In Sect. 4 we illustrate the approach in more through a case study in the healthcare sector. Discussion of lessons learned is found in Sect. 5 before conclusion and ideas on further work follow in Sect. 6.

2 Modeling of Business Processes in Enterprise Development

A model is not just a representation of something else; it is a conscious construction to achieve a certain goal. Based on the goals that the modeling is meant to support the achievement of and existing resources, persons gathers (physically or virtually, synchronously or asynchronously) to represent some area of interest using some modelling languages. The modeling activity is supported by tools resulting in models that are meant to help addressing the goals of modelling. In Table 1, we list relevant modeling situations, along the temporal and purpose axes:

Table 1. Categories of models according to temporal aspects and purpose [10]
Full size table

Models can be of past situations, the present, or a potential future situation. We look here primarily at models of the present and future. Models can at all temporal stages be looked upon as being:

  • Ideal: A model of a situation perceived to be ideal for an area, ignoring contextual restrictions such as current legacy systems and organizational practices.

  • Simulated: A model that differs in some way to the actual state-of-things, e.g. to be able to play what-if analysis and other simulations.

  • Model espoused: The official model of an area.

  • Model in use: How the situation actually is (or was). This should ideally not be so different from the model espoused, but in practice these often differ.

  • Motivational model: A simulation which depicts a defensive approach i.e. what happens if nothing is done. Also known as a burning platform scenario [5].

In total this gives 15 model types. It is important to realize that the to-be situation (both ideal and actual) is a moving target. When one implement a new solution (turning the to-be model into an (espoused) as-is model) both the ought-to-be and to-be have moved further. We will below look in particular on the interplay between the actual as-is model, the ought-to-be ideal future model, and the to-be model where contextual constraints are taken into account.

An organization is in a state including the existing processes, organization and IT-systems, and one often perceive future improved organizational states. The state of the organization is perceived (differently) by different persons through explicit or implicit models. This opens up for different goals for the use of models. This is an extension of the overview found in e.g. [18] as depicted in Fig. 1:

Fig. 1.
figure 1

Application of enterprise process modelling

Full size image
  1. 0.

    Model mapping: Representation of the current situation in a model.

  2. 1.

    Human sense-making [29]: The development and use of a model of the current state can be useful for people to make sense of and learn about the current situation.

  3. 2.

    Communication to establishing agreement between people in the organization [3].

  4. 3.

    Model analysis: To gain knowledge about the organization through simulation or deduction.

  5. 4.

    Quality assurance, ensuring e.g. that the organization acts in compliance to a certified process typically represented as an espoused model.

  6. 5.

    Model deployment and activation: To integrate the model of the future state in an information system directly. Models can be activated in essentially three ways:

    1. a.

      Through people guided by manual process ‘maps’ [12].

    2. b.

      Automatically, e.g. through a workflow systems [30].

    3. c.

      Interactively, where the computer and the users co-operate [19].

  7. 6.

    To give the context for a traditional system development project.

  8. 7.

    Model implementation. In both usage area 5 and 6, it is the purpose to change the situation in the organization. In addition one often has to do other tasks (e.g. training) to have people work according to the new processes.

  9. 8.

    Standardization, influencing reference models external to the organization that others might need to relate to at a later stage.

3 Combining Top-Down and Bottom-up Modeling

Process modeling often starts with the company vision and business value to be achieved. It is important to develop both corporate future goals and target architecture in the form of a “Future Operating Model” (from hereon called the ought-to-be model), as well as detailed workflows with both as-is and to-be activities. To achieve this, one needs a combined top-down and bottom-up approaches. The ought-to-be model is best developed top-down describing how the organization ideally wants to operate, based on the Situated Best Practise.

The workflow model is often developed bottom-up model showing how the enterprise is operating with todays (as-is) and tomorrows (to-be) systems and organization. The main reason to have both the bottom-up and top-down approach, is because there is often a large gap between the long-term ambitions of the organization and what current installed base, technology and methods can deliver. To achieve value through process modeling, it is necessary to have a long-term perspective [12, 16].

The ought-to-be model describes the Situated Best Practice which are derived from previous experience, technological development and regulatory constraints etc., and shows the ambitions and plans - on a general level, how the enterprise is going to be operated in the future. The model is a generic model (cf the TOGAF continuum [27]). Together with an as-is model it can be used for basic analyses and help answer questions like: “What are our enterprise doing?”, “Are we doing the right things?”, “How are our main processes being performed?”, “Could we redesign our basic processes?”

This is analysis that should be done before going into the details like: “Who / what does what?” (Human/machine), and “Which IT systems are used for what?”

Once these basic analyzes and decisions have been made, one can proceed with detailed workflow diagrams of the to-be situation.

We see in many cases that the business has little influence on the IT and often has to accept what the IT-systems have to offer, and adjust the processes to the IT-systems, even when it is not good practice. An Ought-to-be model will contribute to a common understanding of the business requirement to the systems and organization.

Process models are often structured in an hierarchical decomposition structure. The process hierarchy provides a full overview of the enterprise and what is agreed as situated best practice. Experience shows that it is in the transitions between activities in the value chain that it often slips, and this becomes explicitly in an overall end-to-end model. In this model it is also important to set the customer/client in focus and ensure that the customer interaction with the company is explicitly modeled.

As illustrated in Fig. 2, the top-down planning model shows the value-chains, but also value-shop and value-networks if relevant [26]. The to-be workflow model is a bottom-up implementation model, that contain the detailed workflow for defined parts of the value-chain. Further in Fig. 2 we see:

Fig. 2.
figure 2

Illustrating the interplay between top-down and bottom-up modeling

Full size image

  • On the left side a top-down process breakdown structure, from an “Overall view” detailed in several levels down to “Processes/Activities” layed out in swimlanes.

  • The right side show a bottom-up workflow model which is built up from applications and roles, IT services and procedures for implementation (orchestration), up to a similar swimlane view.

Modeling a top-down generic architecture model [27], can be done with different notations, but we recommend using IDEF0 [15], which is regarded as best practice for generic process models with a process breakdown structure. IDEF0 also can be used to model all variants of value-chains, value-shops and value-networks. IDEF0 is a process modeling language and a method to model the decisions, actions, and activities of an organization or system. IDEF0 was derived from the Structured Analysis and Design Technique (SADT) and standardized by NIST in 1993. IDEF0 makes it possible to represent the functions that are performed and what is needed to perform those functions.

The Process interactions in IDEF0 are usually known as ICOMs

  • Input: Can be a trigger and is an input that is transformed to output in the process.

  • Control: Guide or regulating activity. A main distinction between input and control is that inputs are transformed by the activity, whereas controls remain unchanged.

  • Outputs: Results (products) of performing the process/activity.

  • Mechanism: Resources needed to perform the activity. These can be people or roles, equipment, IT-systems or financial resources

As illustrated in Fig. 3, this top-down model shows not only the process-breakdown, but also the hierarchical breakdown of information (input/output), the logical applications and role/organizational and control structure.

Fig. 3.
figure 3

Generic conceptual model of IDEF0

Full size image

The bottom-up workflow-model in Fig. 2 is a specific architecture model using the TOGAF-vocabulary [27], describing detailed activities for each role and how the IT-systems are used for each activity. This gives a detailed overview of which roles, information objects and application functions that are used (as-is and to-be).

3.1 Combining Ought-to-be Models with as-is and to-be Models

Since process modelling combining IDEF0 and BPMN (Business Process Model and Notation [25]) can capture both an ought-to-be supply chain, as well as detailed workflow diagrams, it makes the process of going from as-is to to-be, easier, more structured and efficient. By linking ought-to-be models with as-is and to-be models, it will be possible to analyse how close (or far) the current practice is from situated best practice (Fig. 4) (For detailed model-levels in the top-down and bottom-up models, see Fig. 2).

Fig. 4.
figure 4

The interplay between as-is, ought-to-be, and to-be models

Full size image

The ought-to-be model is the result of the enterprise common understanding of the best practice of the ideal future state. It is a continuous updated “living” model, based on experience from current as-is, taking into account restrictions from laws and regulations beyond the control of the organization, but also including result from research and development. When to-be is fully implemented, it will be the new as-is.

As illustrated in Fig. 4, this imply that the analysis necessary to go from as-is to to-be, will be based on the common agreed best practice within the enterprise, unlike today, where the to-be often are controlled by the IT-professionals. A generic best practice model like this will give the business management and business architects more influence and control, and provide a better and more effective way of specifing how the IT systems should support the business processes.

When we get to a detailed level we often find common processes that are used in several value-chains. To avoid redundancy, we model these standard processes separate as stereotypes and make a link (relationship) from the value-chain process to the stereotype processes as illustrated in Fig. 5. The stereotypes can be aligned with a service catalog and might be seen as a specification for the services.

Fig. 5.
figure 5

Process states from generic future to specific implementation states

Full size image

4 Case Study

To illustrate the approach, we use the experiences from a case in the healthcare sector. Parts of this case have earlier been presented in [10], but the experiences from the case have not been discussed in the same level of detail before.

Fig. 6.
figure 6

Healthcare delivery reference model (from [8])

Full size image

Health South East (HSØ) in Norway has been working with Clinical Pathway Processes (how patients are passed through the diagnose/treatment activities in the hospital) for many years, using different methods and notations and are developing a Citizen Centric Healthcare Delivery Reference Model [8], the top-level found in Fig. 6.

The modeling was done in three phases during the project of building a new hospital in Østfold Norway, replacing three existing old hospitals:

  1. 1.

    First an as-is model of current processes and systems was developed.

  2. 2.

    Second an ought-to-be model based on the existing reference model was built.

  3. 3.

    Third, a to-be model for the first installations necessary before opening the new hospital was made.

The research question for this paper is how the combination of top-down and bottom-up approach described in the previous section is experienced to be appropriate in the case setting. The experiences are primarily based on the work of one of the authors, working as a modeler and modeling facilitator through the project.

In the case we combined the use of IDEF0 and BPMN.

  • The ought-to-be model is a generic planning model (in IDEF0) that represents value-chains, as well as value-shop and value-networks.

  • The workflow models (as-is and to-be) are implementation models (in BPMN), that shows the detailed workflow for defined parts of the value-chain

Whereas the type of modelling that is described in this paper can be supported in a number of different tools, we used Troux Architect [28], based on a call for tender and procurement of tool and modelling services from HSØ. Troux Architect is a desktop visual modeling environment used to create models and analytical tools for communication and analysis of an enterprise. The content of Troux Architect visual models can be saved in the Troux repository being available for query, reporting, and alternative visualizations e.g. in web-based process navigators more familiar for users not being modeling experts. Likewise, repository-based content coming from other sources such as internal databases can be queried and incorporated into visual models.

The process modeling project for the new hospital was adjusted to the reference model and below we present some examples from this model. The models are in Norwegian, but we describe aspects specifically relevant for this paper in English below.

A top-level IDEF0 model from the case study is depicted in Fig. 7. This shows the sick patient as input and a cured patient as output. As controls on top the laws and regulations are modeled and as mechanisms at the bottom the main roles/skills and logical application systems are represented. Note that we do not need to represent a strict sequence-flow in IDEF0 (which you would mandate in e.g. a BPMN-model) since this would at this level be too restrictive to capture the variety of possible process patterns.

Fig. 7.
figure 7

Top-level IDEF0 model in case study

Full size image

On lower levels one models the sub-processes in the pathway with more detailed inputs, controls, outputs and mechanisms. The processes and ICOM’s are numbered according to the process breakdown structure. This top down generic model can be broken down in several levels. It is also important to include the patient’s own processes in the model in order to put the patient in focus.

From this main process structure it is possible to make many different model views for various purposes and audiences. The processes can e.g. be presented in swimlanes representing main hospital units. A more detailed view is shown in Fig. 8. (In this figure the role-names are the most important, thus please ignore the activity names in Norwegian). This includes the patient processes with focus on the interactions between the healthcare organizations and the patient, highlighting the Line of Visibility (LoV) between the enterprise (hospital) and the customer (patient). In this view the ICOM’s can be hidden.

These views can be made on several process levels, helping people from different professions with varying skills to get a common understanding of the enterprise processes.

Fig. 8.
figure 8

Inclusion of both hospital and patient processes

Full size image

We wanted to standardize the processes, and to make this more explicit, we made process definitions as stereotype-processes or standard reference processes (such as ‘take blood sample’) that can be used several places in the value-chain or in several value-chains (illustrated in Figs. 5 and 9). These process definitions represent the “layer” of common terms where the business meets IT, i.e. where it is agreed upon what names to use and define which stereotypes/workflows to be used.

Fig. 9.
figure 9

Stereotypes as reusable process definitions

Full size image

This generic, conceptual process can also be applied and be valid outside a hospital unit. There will be several similar clinical pathways in the municipal health service (local doctor), emergency units (prehospital), and ambulance. It is important to see these similarities to be able to synchronize medical records information, supporting a situation of BPM-in-the-large [13, 14].

When we come to the implementation models (as-is or to-be) we did go bottom up from implemented systems (applications, application functions, information model) up to activities in a workflow diagram using e.g. BPMN as illustrated in Fig. 10, linking the implemented workflow activities to data model and application model.

Fig. 10.
figure 10

Example of bottom-up implementation models

Full size image

This is a specific architecture model referring to specific activities, applications and information. (Ref TOGAF Continuum).

Going from as-is to to-be, guided by the best practice ought-to-be model will over time close the gap between the long-term ambitions and current technical and organizational capabilities. The as-is and to-be will be different states of the implementation model. A more long-term roadmap can be envisaged with a number of to-be models that are expected to evolve into the ought-to-be model through reaching successive plateaus [27].

4.1 Model Management and Use

The model(s) are created in Troux Architect and the diagrams can be stored in a shared network drive or file solutions like Project place, SharePoint, or Dropbox.

The main architecture is illustrated in Fig. 11. The contents of the diagrams e.g.. the BPMN objects like activities, data, events, gateways etc., are synchronized in a common repository (TrouxSource) where they are maintained and reused and updated via a process portal (Process Navigator). The updates can then be synced back to the graphical diagrams.

Fig. 11.
figure 11

Parts of the Troux Architecture solution

Full size image

5 Discussion, Conclusion and Further Work

We have in this paper looked upon how to enhance the traditional practice with as-is and to-be models with an ought-to-be model representing the situated best practice – expressing the long-term ambitions for the enterprise. We describe the main lessons learned below:

BPMN has become the de facto standard for process modelling, but has also received much criticism for it’s appropriateness as a general process modeling language [1]. BPMN is good for detailed bottom-up workflow-modeling, but less suited for top-down modeling of value-chain, -shop, -network processes. The purpose of this top-down modeling is often to get overview of the core business processes, and to make a process breakdown structure that is consistent through the different levels of details. Often it is desirable at this stage to leave open details about which roles can perform a task or process. i.e. a nurse can perform some tasks previously done by physicists or specialists. We see a similar division of notations in enterprise process models in other organizations [12].

Using BPMN will often result in cementing a specific way of implementing the process. In the hospital sector in Norway, it is clear that the wanted state and available technology is ten year or more ahead of current practice. In such a situation it is very important to be able to represent the ideal (ought-to-be) solution, although it will not be reached in a long time. The long-term ambitions have to give way in the short term for the constraints in technical/IT systems. Since the ambitions will also evolve as the current support and procedures evolve, this is clearly a moving target that need to be represented independently of the traditional as-is and to-be models.

The enterprise architects have not so far been using a method and notation that is suited for specifying an overall top-down process-model. For this purpose the IDEF0 notation, used in this case, is found superior to BPMN, in modelling a generic top-down model with process-breakdown structure, including a conceptual information model, logical organization model and logical system structure. This gives the expert professionals and the enterprise architects a good tool to specify the requirements at a level of detail that is in turn suitable for IT/System architects that is modeling bottom-up workflows used for implementing systems according to the current business needs.

Combined with a middle level of stereotype process definitions (the common understanding of a process between both enterprise and IT architects), this gives freedom for both professions to express their model in notations suitable for their needs.

This results in three different representations of processes.

  1. 1.

    Top-down (ought-to-be) process-structure for value-chain, - shop, -network modeled by enterprise architects.

  2. 2.

    Middle-out (agreed-to-be) stereotype process definitions representing the common understanding of a process.

  3. 3.

    Bottom-up (as-is, to-be) workflow activity models of implementation of the common agreed process for IT-, System- architects and operation managers.

Each of these types of models has their own lifecycles. A unifying overall process model like the ought-to-be model, makes it possible for people with various backgrounds, coming from different organizational units and disciplines, and who has worked in different ways in the past - to agree on common work processes and value chains. This contributes to developing a common terminology for processes, concepts and information objects. A generic overall model also contributes to the standardization of process modelling so that the work processes are described the same way in the different departments and disciplines, which is important for communication and reuse.

6 Conclusion and Further Work

Working with this approach hopefully will make it easier for the enterprise management and enterprise architects to express in more detail their ambitions, before the CIO and IT-architects come with their systems and limitations from current technology. A main learning from the case is that the ought-to-be models developed top-down, due to that they are not to be immediately implemented makes it possible to describe ideas and ambitions on a generic level, avoiding both ‘accidental’ organizational and technical limitations, but also terminological constraints making it easier to be innovative and learn from others without this being experienced as threatening to current practice.

As a case study this work is limited to a certain phase of the specification and building of a new hospital in HSØ, threating external validity (i.e. generalization of results). It is also primarily based on the experiences from one of the main modelers, threating the internal validity of the results since other stakeholders might have different perceptions. In further work we will be able to follow the use of the models over time through several iterations of updates. We also hope to be able to use this approach on other cases in other domains, potentially also supported by other tools, investigating what is particular for this case and what is to a larger degree generalizable.

In the investigation of the approach so far, we have used traditional process modelling languages such as IDEF0 and BPMN for the top-down and bottom-up modeling. We note that it is often needed to combine languages also from other perspectives [17]. In future work we will experiment with combining this with the use of approaches such as AKM [13], DEMO [7] and ArchiMate [22]. AKM for instance is believed to be better for supporting the agile use and evolution of the enterprise process knowledge captured in the model, in particularly when capturing knowledge bottom-up directly from work practice.