Building an information product for cycle time analysis

(1)

Building an information product for

cycle time analysis

Developing Process Models for the Ambulance Pathway for Stroke

Emergencies

Master Thesis

MSc Technology & Operations Management

University of Groningen, Faculty of Economic and Business

J. M. e Sousa Gonçalves

S2747138

Supervisor:

Dr. H. Balsters

Co-assessor

Dr. D.J. Van der Zee

(2)

2

Abstract

In the emergency services world, time is one of the most important features of all their process. When the focus is on the Stroke emergencies, this becomes even more evident due to the time constraints on the effectiveness medicines. Measuring the cycle times of these emergencies is then a process that can be fundamental in understanding where improvements are needed in the pathway. This research is part of an overarching project that focus building a blueprint for system that can measure and store the individual cycle times of the patients emergency pre-hospital pathway. This blueprint was requested by a Regional Ambulance Service of the North of The Nederland’s who wants to analyse the cycle times of their ambulance in order to, if needed, improve their processes.

The research was conducted by three elements in three individual research projects. The first research project analyses the stroke prehospital emergency pathway and designs the process in BPMN. The second research project translates this BPMN process to an ORM model to encapsulate the data requirements to generate patient cycle times. The last research project validates the research and designs forms for the actual end-user to serve as an input for the data request. The focus of this thesis is on analysing the stroke prehospital emergency pathway and designing the process in BPMN.

This individual research focus is then to validate a method that has been used previously in different researches, and lacks both validation and generalization. The method objective is to design the process models and make the stakeholder’s analysis of any given project. The results of the method allow to create design solutions that answer the problems raised by the stakeholders.

(3)

3

Preface

This thesis is part of a group research with two other students of the Master in Technology and Operations Management. When we as group started this project the first objective was to model a new pre-hospital pathway for stroke emergencies that would include the triage process by using a new equipped ambulance called the Mobile Stroke Unit. Some studies on the use of this new Ambulance have been already made but this project represented an interesting challenge to tackle as a master thesis.

This goal came from the Ambulancezorg in Tynaarlo, but after the research proposal had been delivered, we received the indication that the organization would rather start by analysing if the Mobile Stroke Unit was actually needed in the region. This lead to a change in the main objective comparing to the one that had been presented in this thesis in early December. It was a setback for the thesis but with the collaboration of our supervisor and the precious help of Mr. Jaap Hatenboer we were able to finish the proposed design which not being as appealing as the initial research, will still be really useful for the organization. This change of plans ended up as a good introduction to what might be asked from us in future jobs with objective changes on projects that may already be in advanced stages of development.

I would like first to thank my project colleagues Martin Rouby and Natalia Platon for all the help on my individual research as well as for the company and moral support during all the thesis process. For reviewing final draft and for giving precious feedback I would like to thank my brother Tiago Gonçalves and my colleague Nick Valastras.

I would also like to thank the Tynaarlo UMCG Ambulancezorg, in the person of Mr. Jaap Hatenboer for giving us the chance to participate in this project and for the help and all the time given to us. Also Mr. Stephan Hazekamp and Mr. Renco Porton for the time and moral support given to us during not only the meetings but also on the several emails exchanged.

(6)

6

1. Introduction

Strokes are one of the most problematic cases of medical emergency. They frequently cause the death of the patient or the permanent disability in adults (it’s actually the most frequent cause for disability (Rothwell, et all, 2005)) causing suffering to the patients and everyone involved. This is still a considerable problem, but with the different treatments available today, there are ways to reduce the effects of a stroke if applied within a short time period after its occurrence.

So why are there still so little improvements in the results?

According to medical experts, only 19-60% of the patients arrive to the hospital within 3 hours and, even worse, only 14-32% arrive within 2 hours (Katzan et al. 2004)(Arora et al. 2005). Such arrival times are problematic since the medicines that are currently in use need to be administrated within 60 minutes (The Golden Hour) to be maximize effectiveness (Fassbender et al. 2013). Moreover, the coordination of the different services needed for stroke care has proven to be difficult. This difficulty often leads to an inefficient use of resources (Schwamm et al. 2005) and other problems, such as the lack of recognition of symptoms by the patients (Fassbender et al. 2013).

One way to remedy the above is to understand if the pre-hospital pathway can be improved and how. There is already research on ways to improve it, for example by introducing Mobile Stroke Units (Rothwell & Buchan 2012) able to facilitate diagnose a stroke and the type of stroke in order to enable the immediate treatment of the patient prior to his/her arrival to the hospital. Solutions like this one however raise the issue (Liman et al. 2012; Dietrich et al. 2014; Gyrd-Hansen et al. 2015) of whether the costs involved exceed the benefits they produce on the door to needle time, (moment since the patient had the stroke until the treatment start) when compared with the current and other possible solutions.

(7)

7

1.1. The Case

For the past few years, the Tynaarlo UMCG Ambulancezorg (UMCGA), which belongs to the Regional Ambulance Service of Drenthe, has been developing a new strategy regarding all their operations. The focus of this new strategy is on the patient and on how they can improve the care provided (by preforming better triage, starting treatment on the ambulance, etc.) and still fulfil their objective of transporting patients to the destination.

They call this new strategy “The Big Picture”(Liman 2014), and in order to achieve this goal a new methodology (Hatenboer 2015) of work has been implemented within the organization called OODA-loop which stands for “Observe Orient Decide Act”. It is this methodology that helps them achieve “The big picture”. The first step of the method is to observe and the first revelation from observing their surroundings is that there are a lot of opportunities for Operations Research, from the big chunks of Data they can collect or already collect(Hatenboer 2015) which will help them improve their operation and logistic performance.

Following this revelation, the first focus on the process improvement by the UMCGA was on the acute care patient flow models. The stroke care is one of the most pertinent flow models that, like it was mentioned in the introduction, might have the biggest benefits from improving their operational performance. With this in mind, the UMCGA felt the need to create a database of the cycle times for the stroke patients’ ambulance pathway. The present study regards an overarching project with the objective to create:

“An information system blueprint that should be designed and validated in order to safeguard cycle time collection and monitoring, on individual patient level, in the prehospital stroke pathway.”

This project is handled by three students as a Design Science project using a method called the regulative cycle (van Strien 1997) with Process-fact driven approach to create the blueprint which will lead to the database system. The cycle used in it was divided in three parts, Process Modelling, Data Modelling and Validation.

(8)

8 The validation of the method for Process modelling and stakeholder analysis, is then the objective of this research which can be formulated as:

“How do we validate a Process modelling design method by applying it to an information system case on the stroke emergency pre-hospital pathway process?”

To provide an answer to the above, the following sub questions need to be examined:

1. How can we model the stroke emergency pre-hospital pathway process using a standard business process modelling language?

2. Who are the main stakeholders in this process?

3. What are the goals and Critical Success Factors (CSFs) for each stakeholder? 4. How do we validate the Process Models?

With this research it is expected by the UMCGA that a process model is created, and for that as mentioned in supra there are three phases, the model construction which will be elaborated in this thesis, the construction of a data model which will be handled by Martin Rouby (2016)and finally the validation of both models which will be done by Natalia Platon (2016).

1.2. Academic Relevance

The novelty of the approach that is being validated in this thesis comes from two different phases of the design.

The first phase is the use of the combination of a business process model which uses Business Process Model Notation (BPMN) language with an Object Role Model (ORM) map to create the blue print of the system. This approach has been advocated already in recent literature (Balsters 2013). However, it has been used in a limited amount of studies. Examples of these studies can be found in Hoekstra(2014) and Fischer’s(2014) work and Meerman’s(2015) and Schriever’s (2015) work. Therefore the combination of this thesis with the work of Rouby (2016) will be testing the robustness of this approach (Krätschmer et al. 2014) in additional contexts to those it has already been used in. Since it will show that it is/isn’t possible to use this methods outside the setting where they were first used and tested.

(9)

9 Therefore we will be validating the methodology and testing the strength of the procedure created by S. Hoekestra and help its validation. Even though this is not the objective of the thesis there is also the possibility that during this project some improvements or additions are made to the model to further improvement. Also, by changing the setting where the method is applied we also hope to generalize the model making it desirable to use by other fields of interest.

This complete project will also be adding a new method of validating a Design Science project. This new method uses a user interface (google forms) to validate the process models and the data models. This complete new way of validation and its successful implementation can lead to reduce the time that validation procedures take significantly. For a better understanding of this form of validation please refer to the work of Platon (2016).

The testing of this model also helps raising the awareness of Design Science as a useful solution for Business Modelling by using the regulative cycle from Van Strien (1997). Which despite being a relatively young field has been receiving more attention in the past few years (Denyer et al. 2008). The use of the Regulative cycle in this setting will also help assessing if it is a fitting solution for this type of research.

(10)

10

2. Methodology

In this chapter the methodology for the thesis will be described. First, the type of research (Design Science) will be addressed, then the focus will go to the methodology of the complete project (data models and validation phases) proceeded with the research framework of the individual thesis will be presented lastly the methodology for the interviews conducted during the study is presented. This is a very important part of the thesis since a flawed methodology could lead to not expected results or even worse, wrong results.

2.1. Design Science Type of Research

Being a Design Science project, a framework from Wieringa (2010) on how to conduct such work is used.

By constructing an innovative solution we expected to solve a complex problem that involves people, organizations and technology (Balsters 2015). The main goal of a Design Science project is for it to have utility. This will be achieved as the ultimate objective of this thesis is to support UMCGA on their own goals of improving their processes (H Balsters, 2014a).

It is important to first define what a process is. In Operations literature there is a significant amount of definitions of the term Process but it’s not the objective of this thesis to map them all. Davenport (1993) has a suitable definition for process which is the one used in this model. It is defined as “simply a structured, measured set of activities designed to produce a specified output for a particular customer or market”(Davenport 1993)

There was another factor that made this project a Design Science problem. The problem presented was a practical knowledge problem (as defined by Wieringa (2009)) and it was a project aimed at solving the difference between what the stakeholders know now and what they want to know (Wieringa 2009).

To answer a practical-knowledge problem, a pure-knowledge problem has to be solved first by following a four step approach(Balsters 2014a).

 The first step is to investigate the problem. This was achieved by exploring who the stakeholders are, what are their goals and which success criteria they apply to these goals. These are all pure knowledge problems as defined by Wieringa (2009).

 In the second step, an analysis was made. The main objective of this analysis was to underline what enables the failure of the desired success factors.

 In the third step a possible solution was created.

(11)

11 This steps were then included in the methodology used in this research and were presented further ahead. But first, an overview of the project and how it was tackled is important to be shown so that the reader can understand where this thesis fits into the overall research.

2.2. Overview of the Full Project

Just as presented in the Introduction, the project at hand was conducted by three persons in three different but interconnected researches. For the project to work out it was then necessary to clearly define the objectives of the three researches and how they would integrate. The figure 2.1 presents the results of that clarification identifying each research objective, the individual steps of each research and the moments where the researches would exchange information (or use concurrent engineering concept which will be explained in section 2.2.2).

(12)

12 After having a quick look at the conceptual framework for the overall project is then easily identifiable how the project works. In the first phase (this research) the process models of the process were created and an analysis of the stakeholders of the design and process was made. In the second step with the results of this research, Rouby (2016) created the Data Models for the information system (IS). Lastly, in the third step, the research of Platon (2016) validated the results from both previous steps with the stakeholders. This is a superficial understanding of the model, before going in a more detailed explanation (of each one of the three steps) there are two concepts that should be explained since they were fundamental for the overall project as well as the individual researches. They are the regulative cycle that concerns the blue arrows of the conceptual model, and the concurrent engineering that is demonstrated by the red/orange arrows.

2.2.1. Regulative Cycle

The Regulative Cycle developed by Van Strien (1997)was established due to the stretching gap between practice and theory in Design Science, creating an approach towards practice which is both scientific and realistic (van Strien 1997) .

The regulative cycle model has been extensively used and mapped, but the original model made by Van Strien in 1997 is the one shown in Figure 2.2 which is composed of five different phases.

Figure 2.2 Regulative cycle by Van Strien (1997)

(13)

13 Figure 2.3 Adapted Regulative cycle

As it can be seen the model displayed in figure 2.3 there are four phases in the regulative cycle and in figure 2.1 there are only three steps, which meant that one of the steps of the research covered two phases of the regulative cycle. Which is what happens in the first step (process modelling and stakeholder analysis) that covers the first two phases of the regulative cycle (Design Problem and Diagnosis/Analysis), the second step covers the third phase (Design Solution) of the regulative cycle, and the third step just as its name predicts covers the last phase of the regulative cycle (Validation). The figure 2.4 shows the conceptual model for the overall project in the regulative cycle view.

Figure 2.4 Conceptual Model Regulative cycle

(14)

14

2.2.2. Concurrent Engineering

Just as it can be seen in the conceptual model of the overall project, the three steps were connected within them. This means that information was shared between steps. And like the conceptual model of the regulative cycle shows each step built on the one before it. It is important to note that the majority of the time, they are not preformed consequently but concurrently. This is comparable to complex projects, where individual components are implemented separately but they influence each other (Loch et al. 2003a). Applying this method enabled the immediate correction of mistakes found when preforming different stages of the process (Thomke 1997). This is what was done in this project since the BPMN, the ORM and the validation are intimately connected. Therefore, for example, the party responsible for the validation provided feedback for improving the other parts and the others did the same regarding the validation.

Loch et al. (2003b) described some principles that must be followed so that the concurrent engineering can be effective. These are:

 Limit System Size – this principle assures that the complexity of large complex design problems is reduced.

 Modularization and Robust Design Methods – it allows the reduction of the facto system size cutting the system into smaller independent modules.

 Release Preliminary Information – releasing intermediate results that allow intermediate validation process preventing accumulating all the changes to the end.  Cut Interdependences – Cutting the interdependences has the same effect as

modularization, although it presents a higher risk since ending or ignoring the wrong interdependence can highly influence the performance of the system.

 Cooperate: Optimize Overarching Chunks As a System – In decision making moments it is important to not only pay attention to the components in focus but also on the entire system performance.

 Immediate Broadcast of Design Updates – With a continuous sharing of information between the different actors designing the system, decisions based on obsolete information can be prevented.

On our overarching project we will be then following these principles since our steps will require iterations that will forge the optimal solution in the end.

(15)

15

2.2.3. Process Modelling and Stakeholder analysis

The process modelling and stakeholder analysis (conducted in this thesis) demonstrates and describes how business activities interact with the organizations resources to achieve a goal (Rolón et al. 2015). They were used as the basics for the creation of the adequate IS to support business operations more about Process Modelling can be found in the section 3.1 of the Theoretical Background.

In this step the two first step of the regulative cycle for the overarching project were adressed. Started by defining the problem and finding what the stakeholders expected from the solution to be presented. After collecting all the information an analysis to possible conflicts and the trade-offs necessary to solve them was made. More information on how this was conducted can be found in the section 2.3.

In the end the expected result from this step were the list of requirements that the stakeholders expected from the IS, the map of the process and the intervenient stakeholder. The requirements included the critical success factors (CSF’s). Having all the necessary results they are then passed onto the responsible by the second step so that a solution can be found and to the responsible for the third step so that they could be validated (concurrent engineering).

2.2.4. Data Modelling

More than often databases do not fully integrate the business processes, this happens due to missing links between the processes and the data. This lack of integration may lead to faulty data (Balsters 2013). To answer this problem, a methodology of Fact-Based Business Data (FB-BPM) has been created by H. Balsters (2013) and successfully applied by Martena (2015).

In this project the notation used for the fact-based modelling was the Object Role Modelling (ORM). ORM was the chosen language since according with Halpin and Morgan (2010) it sees the world in terms of objects (things) playing roles (parts in relationships) and in ORM a role is a part played in a fact-type relationship. This goes accordingly with the idea that information should be examined in the smallest units possible when validating “one fact at a time” (Halpin & Morgan 2010). Therefore, ORM’s capability of putting facts into verbs made the validation with non-technical stakeholders easier.

(16)

16 To get a better understanding of how this step was conducted the reader is advised to read Rouby’s (2016) work.

2.2.5. Validation

The last step of the project was the validation of both steps previously presented. N. Platon (2016) used the two models (BPMN and ORM) to validate the blueprint.

The task of assessing if a specified design is the one that would bring the stakeholders closer to their goals (if implemented correctly) is called Design Validation (Wieringa 2009). This is the point when if the system is not in accordance with the end-user requirements the regulative cycle as to start over again.

This validation in a perfect world would always be made by first implementing the system and test it. However usually this is not possible since stakeholders usually need proof that the design implementation will solve the problem right away (Wieringa & Heerkens 2006).

When solving practical problems, the validation has to predict the effects of the unimplemented design (Wieringa 2009). In fact when validating the design a bridge between the design experts and the end users is being established which allows the feedback to be better fitted into the design process cycle.

Even though according to multiple studies the validation is a crucial point for a credible research, it is difficult to know what procedures to use in order to validate. Even more interesting is the fact that according to van Sambeek et al. (2010) after a systematic review of literature, he found that only 25% of the studies that developed models to optimize hospital related processes were validated. This leads to multiple designs not to be what was asking by the hospital, leading to high costs.

Therefor in this project validation was conducted by N. Platon (2016) by verbalizing, illustrating and explaining the designed models to the end-users. With the feedback collected and implemented in the designs, the designs could be assumed as valid.

For more information on how the validation was conducted the reader is advised to read the work of N. Platon (2016).

2.3. Individual Research

(17)

17 1. Develop a general overview of the process

From this first step, it became possible to understand which processes should be looked into and where to put the boundaries. Once it was concluded the stakeholders and the end-users could be identified. In order to collect this information, meetings with the personnel (staff and management) of the ambulancezorg and a medical specialist were held. These interviews focused on what happened in the process and what were the different reactions that followed small changes in the order of events. These meetings had to be held before and after the first designs of the process since there was a lot of information to collect.

To help with preparing for the interviews research on similar process in other places was made to have a better understanding of what to expect.

2. Stakeholder analysis

Identifying the stakeholders that are directly involved with the environment took place by answering the following set of questions.

 Who are the stakeholders?

 What are the goals for each of them?

 What are the critical success factors (CSF’s) for each goal?

 What problems may arise when solving a CSF? What are the quality attributes of CSF’s and what are their restrictions?

 What are the CSF interdependencies?

These questions will be answered with the gathering of the functional and non-functional requirements of the stakeholders. This step was conducted during the same interviews as the first step, but it needed to be separated since the information collected was of high importance for both the project and the thesis.

3. Develop the process models

The information gathered in step two was combined with interviews made to end-users of the process and end-users of the output. In these interviews five questions created by Balsters (2013), were made to create the model:

1. At what instance does the event happen? 2. How can the event be identified?

3. Which entities are involved as participants? 4. What is the input for the event?

(18)

18 On the first model made it was important that no exceptions are included in it. This is called a “Happy Flow” since it is based on a conscious simplification of the model, where only the desired behaviours and ideal movements are modelled (Beckers et al. 2007). The main reason for modelling it as a “Happy Flow” is to make the general outline of the process understandable. The models created after the “Happy Flow” is validated will then include the exceptions to the process. The software used to create the model is Bizagi due to its easiness and availability to the researcher.

4. Validating the model

Achieved by interviewing the same end-users as earlier, while developing the models, the unfinished models were shown and assessed for their validity according to a set of questions. In order to collect more information the questions that need to be answered were:

 Are all the CSF’s met?

 Are there any trade-offs between CSF’s?

 Is the method completely and correctly displayed in the process model?  Is there any data not correct?

The validation of the process models were made in two different ways according to the stage of the overarching project. For the first validations of the process models interviews with the end-users were conducted since there was a lot of information to collect. For the latest validations it was used an online validation form that allowed more concise and direct validations. This was made by Platon (2016) who made the third part of the overarching project. For more information on the online forms please refer to Platon’s (2016) work.

Answering all these questions will allow to verify the correctness of the model. If any of the answers is not positive the cycle should restart since this model is based on the regulative cycle.

5. Adapt results and method

If the end-users are still not satisfied with the process models and analysis, it means that some mistakes may have been made. Examples of potential mistakes include wrong sequence of processes and critical success factors not represented. The validation helped to identify and correct mistakes. When improving these mistakes, the model and subsequent processes had to be re-examined and generated. (Meerman 2015)

(19)

19

2.4. Interviewing

In order to understand who the stakeholders are and how the process is constructed there was a need to collect information. This is a very important phase to the success of this research since without all the proper information the model won’t be useful or even valid. To collect the required information we made use of interviews. Karlsson (2009) stated that with this process we are able to have flexibility in questions making them more complex or simple depending on the information and reaction provided by the interviewed, making details easier to get. Still there are some disadvantages, such as the time consumed and the possibility of resistance to answer by the interlocutor. Considering all points, interviews are still the best option to extract the information needed to construct the process. The types of interviews used in this research will be the Semi-structured interviews and the Unstructured interviews. These types of interviews allow the interviewer to make unexpected questions or to follow-up on other subjects that were considered not relevant in previous interview but turned out to be important. This structure (or lack of it) makes then a good match for our problem giving more room to the interviewer to make questions.

Having introduced the methodology of the thesis, the theory supporting these methods will now be introduced.

(20)

20

3. Theoretical Background

In this chapter we will describe the relevant theory behind this thesis. We will start by describing the literature on the theory and the Process Modelling (section 3.1) method used in this individual project since it is important to understand where the used method came from and the novelty it has. Then we move on to explain the Business Process Modelling Notation (BPMN) language (section 3.2) used in the designing of the process models which enables the reader to read and understand the process models and maps. To finish the notion of cycle time that was used to build this model is presented which is important so that there are no confusions with the others available in literature (section 3.3).

3.1. Business Process Modelling

The approach of solving a problem by modelling it was started by the Object Management Group (OMG) in the 1990’s with the so called “Model Driven Approach” (MDA). It was regarded as a great idea, but problems with the quality of the starting models made the results turn out as a huge failure since it generated bad code. After this initial failure some researches picked up the good intentions and practices from the MDA and instead of considering the data as the most important part of the model, they saw it as dependant of the context it was being used in. Therefore the perceived importance of the model to create a good solution increased. This created a necessity to have a high level process model that would then use tailor-made data models that could fit the process. Since they viewed the system as one coherent, integrated process and data model there was a possibility to succeed where the previous had failed.

This integration between the process and the data model was then only possible if three principals were respected. We will only explain the changes on the process modelling side given that the Data Models for this project will be elaborated by Rouby (2016).

For the models to be more precise, instead of using Unified Modelling Language (UML) diagrams to model the processes they started to use a kernel of BPMN. The second principle was to always validate the models created so that they were correct in the end-user view. The third Principle was to debug the models using a systematic circle or, as we call it, The Regulative Cycle. This was made so that the model could meet the end-user requirements since the errors detected when validating are looped back at the beginning of the cycle.

(21)

21 Netherlands. These studies were on processes which already existed but needed to be optimized, which is the similar case as the one studied in this research.

The model (Meerman 2015) is then a five step procedure that was detailed in the methodology (section 2.3):

1. Develop a general overview of the process 2. Stakeholder analysis

3. Develop the process models 4. Validating the model

5. Adapt results and method

3.2. Business Process Modelling Notation (BPMN)

A business process model describes events and the ordering of those events: What is performed and when it is preformed (Bridgeland & Zahavi 2009).

This definition could suit any of the various business notation processes. So what makes BPMN more special?

First, it is the standard language that is accepted internationally for business processes and business modelling(Balsters 2013). Second, it has helped to bridge the gap between business and IT (Balsters 2012).

BPMN is then developed to give a graphic notion that represents the business as a Business Process Diagram (BPD) which can be understandable by business users, from analysts who draft the first sketches of the processes to technical developers who actually implement them and to the business staff who has the responsibility to deploy and monitor the processes (Chinosi & Trombetta 2012).

These advantages make this language the most suitable for this work since the next step of the overarching project is to create data models that should fit with the process model, which is made by a different researcher who should be able to read it in order to model without much effort. After the data models are made, it is also necessary for the end user to understand the model in order to validate it / correct it which is only possible if the notation is sufficiently understandable.

(22)

22 The BPMN models contain five main categories of elements to build diagrams (Omg 2015) which are:

Flow Objects: Are the main graphical elements to define the behaviour of a business processes. There are three flow objects, Events, Activities and Gateways (Chinosi & Trombetta 2012)

Data: contains four elements: Data objects, Data inputs, Data outputs and data stores (Omg 2015)

Connection objects: offer ways of connecting various objects between them, and there are four of them: Message flows, Sequence flows, Associations and Data Associations (Omg 2015)

Swim-lanes: offer the possibility of grouping primary modelling elements. Two ways they can be distinguished: polls and lanes (Omg 2015)

Artefacts: used to provide additional information about processes that don’t affect the flow (Chinosi & Trombetta 2012). The set of artefacts available include group and text annotations (Omg 2015).

In these five categories we can fit a big number of elements but since in this thesis we want to keep our BPMN diagrams clear we will only stick to seven of them. Just like in the categories, the explanations will be based on BPMN 2.0 (Omg 2015).

The first basic element of BPMN, with which the building of the model starts, is the Pool which is represented by rectangles that set the boundaries of a business process. Within a pool there can be several participants that are usually subdivided in lanes. Pools can have lanes but the lanes cannot contain pools. All the entire business is made up with communicating pools subdivided in lanes. Figure 3.1 demonstrates a pool with two lanes, each lane usually represents one stakeholder.

(23)

23 Figure 3.1 – BPMN Pool and Lanes.

After making the lanes for each stakeholder the second basic elements used in the building of a model are the Start and Stop events, which as the name reveals are used to indicate the start and ending of events. There can only be one start for each process but there can be more than one stop. The symbols that represent the Start and Stop events are shown in Figure 3.2.

Figure 3.2 BPMN Start and Stop Events indicators.

The third basic element of the BPMN language is usually the main building block for a process. It can be called Activity and represents something that’s being done by someone at a stage of the process. This element is represented by the Figure 3.3

Figure 3.3 BPMN Activity

Some tasks usually may have more steps than the ones that need to be shown in the BPD, and when that happens (usually in the “Happy Flow” explained in section 2.3) these steps are modelled as a sub-process which can be represented as in Figure 3.4. Within a sub-process there can be two or more additional objects that are part of the process.

Figure 3.4 BPMN Sub-process

(24)

24 Figure 3.5 BPMN Task relationship.

Usually in every process there are decisions to be made, in BPMN those are represented with two elements called Gateways. Usually we use two types of Gateways. The XOR Gateway and the Parallel Gateway which are represented in Figure 3.6.

The XOR Gateway is used when the process decisions are exclusive this means that only one path can be followed after the decision is made. For example when a client asks for a receipt, the process is to print the receipt and give it to the client, and when a client doesn’t ask for the receipt it’s not printed and the transaction is over. This process would use a XOR Gateway since only one of the path can be used each time.

The Parallel Gateway is used when a decision results in two tasks that have to be done simultaneously. For example when a client buys a product two process occur at the same time, the product is taken out of the inventory and the cash flow from the sale is registered.

Figure 3.6 BPMN Gateways

(25)

25 Figure 3.8 BPMN Pool Communication

As an example we now present in Figure 3.9 a dummy process in BPMN with some of the elements previously explained.

Figure 3.9 BPMN Dummy process

3.3. Cycle Times

Last but not least, it is important that we define the term cycle time. As indicated in the introduction, the goal of the overarching project is to design a blueprint of a cycle time’s database Information System. In the book Factory Physics by Hoop & Spearman (2008), cycle time is defined as “the average time from release of a job at the beginning of a routing until it reaches an inventory point at the end of the routing”.

(26)

26 Figure 3.10. Part of the cycle times calculated in the model.

(27)

27

4. Results

Having the methodology set and the theoretical background explained we will now present the results from applying the methodology to our specific case. The results will be presented following the structure from Van de Laar (2015), step by step like it was presented before. We will divide this section in two different parts. First the results from applying the proposed methodology to its individual research will be presented. The second part will introduce the results of the first two stages of the regulative cycle of the overarching project (Design problem and Diagnosis/Analysis).

4.1. Individual Research

In this first part of the results section we will follow the regulative cycle for the individual research. Starting by defining the Design Problem, moving to its Diagnosis/Analysis, then understanding how the Design Solution was achieved and finalising with the validation of this cycle.(Balsters 2014a)

4.1.1. Design Problem

In the first step of the regulative cycle a general overview of the process is offered so that the Stakeholders can be more easily defined. After this their goals are described and lastly the Critical Success Factors (CSFs) are defined. This information was gathered through semi-structured interviews with different stakeholders in order to get a clear understanding of the problem at hand.

4.1.1.1. General Process Overview

Just as Van de Laar (2015) explains, an initial overview of the process has to be made. This overview, usually called as “Happy Flow”, gives us the system in a high level of aggregation so that the basics of the process are understood. The details of the “Happy Flow” are explained later in the process.

(28)

28 Figure 4.1 Black Box Model

From this model we retrieve not only the scope of the individual project, we also have the scope for the overarching project. The process input with the ambulance (the members) receiving the notification of a possible stroke emergency from the Dispatch Centre. Then the process that is being subject to analysis, which are all the activities that happen from the moment that the notification is received until the delivery of the patient at the hospital (output), is generated.

After getting this clear understanding of the scope of the model, the “Happy Flow” was modelled so that the general process overview could be obtained.

(29)

(30)

The process starts with a notification from the Dispatch Centre to the Ambulance members, that there is a possible stroke emergency at a specific location. The ambulance member then prepare themselves to leave to scene, after all the preparations are made the ambulance leaves to scene and travels and arrives to the scene. Time checks will made at the moment the ambulance leaves to the scene and when arrives at the scene.

After arriving at the scene, the ambulance crew preforms triage and the FAST protocol (specific protocol for stroke related emergencies). There is then a decision point on whether the tests are positive for a suspected stroke. In that case, the patient is loaded to the ambulance. After having the patient loaded in the ambulance, the travel to the nearest suitable hospital begins. During the travel three different processes take place without any defined order. The dispatch centre is updated with the condition of the patient and where is it being transported, the basic vital signs of the patient are checked and the Electronic patient records are updated. The ambulance eventually reaches the hospital where the patient is delivered at the hospital and the process finishes

A quick explanation of the “Happy Flow” was now presented but the reader is advised to visit the appendix for a more detailed explanation with examples of the process.

4.1.1.2. Stakeholder Analysis and Goals

After having the overview of the general process the next step needed to understand the design problem is to identify the Stakeholders of the process, the goals that these stakeholders look to attain and the factors they consider critical for a successful process. This information was attained through interviews. The Stakeholders were divided in two groups the internal stakeholders and the external stakeholders. The base for this distinction was that the internal stakeholders are the ones (in this case the one) who are show in the swim lanes of the BPMN model. The external stakeholders are the ones that are not represented on the BPMN model, but just as the name indicates, have goals and success factors for it.

Stakeholder Identification.

(31)

31

Internal Stakeholders Ambulance

External Stakeholders Patient

Dispatch Centre (DC’s) Hospital

Regional Ambulance Service (RAV)

National Dispatch Centre Organisation (LMO)

Ambulance Care Medical Manager (MMA)

Ambulancezorg Netherlands (AZN)

The Ministry of Healthcare (VWS)

Insurance Companies

Table 4.1 Stakeholders List

Having the list of the stakeholders of the process we now proceed to explain why they are considered stakeholders. Also the role of them in the process and their relevance and goals are explained.

Internal Stakeholders

Ambulance

The only internal stakeholder present in this process is the ambulance. This happens because the cycle times that must be recorded are only comprised by actions of the ambulance. Therefore we can see the Ambulance, or the centre responsible for it, as the owner of the problem (Mckay & Marshall 2001). The Ambulance has two members:

 A registered nurse who is responsible for the patient and the treatments administrated while being transported;

 A driver who is qualified to help the nurse while she/he treats the patient.

(32)

32 though this are valid arguments for this case the ambulance crew was modelled as one since modelling the activities they preform individually wouldn’t bring any different input to the calculation of the cycle times. Moreover, the BPMN models should be as simple as possible. By modelling them together, the model gets simpler.

The beginning of the process starts on the moment of the notification to the Dispatch Centre revealing that there is a possible stroke emergency. This is also the moment that the ambulance comes into the process and that the cycle times begin to be measured. From this moment until the end of the process there are several goals that the ambulance tries to accomplish, some that are general for every emergency they are called into, some more specific to each emergency.

For this situation there is a specific goal that is considered fundamental and has triggered this research. That goal is to deliver the patient to the hospital in less than 60 minutes after the first symptom on of a possible stroke has been detected. This goal comes from the fact that one of the types of strokes (clots) can only be successfully treated within a 4.5 hours window.

The general goals are:

 Time window limit of 1 minute during the day time and 2 minutes during the night time, between the notification from the dispatch centre and the exit of the emergency vehicle

 Time window limit of 12 minutes during day time and 11 minutes during night time, for the emergency vehicle to arrive at the emergency location

 Proceed according to the adopted protocols from the moment of arrival until the delivery of the patient

External Stakeholders

The external stakeholders can be divided in two groups, the group of external stakeholders who are interested in each single emergency, and the group of those that are interested in the emergencies as a whole.

The first one is interested on the run where they are included. These stakeholders are:

 the patient;  the hospital;

 the Dispatch Centre;

(33)

33 The second group of stakeholders are the stakeholders who look at the average numbers. This group is made up by the remaining external stakeholders, such as the Ambulance Care Medical Manager, the insurance companies and the rest of the stakeholders.

Patient

Concerning the External Stakeholders the patient is the one that might create more confusion on why is he not an internal stakeholder. Well, even though he is the one without whom the process would never occur, he doesn’t have a direct impact on the process being addressed. This is only (in Operations Management language) the product, therefore an external stakeholder. This does not mean that he doesn’t have goals for the process, because he does. The goals of the patient are:

 To be transported to the hospital as fast as possible  To be provided with the best care possible

Important not to forget is that as we said the patient is the “product” so without him the process cannot start.

Dispatch Centre

The Dispatch centre here depicted is the individual centre that “starts” the process by notifying the Ambulance that there is a possible stroke emergency. It then follows all the process helping the ambulance to communicate with the hospital. It could be argued that the Dispatch centre should be designed as an internal stakeholder. But as it was explained in the interviews to us, even though the dispatch centre actually participates in the process none of the activities it preforms affects the cycle time of the ambulance. Therefore as we want to keep the process simple none of the activities of the dispatch centre were modelled. The Dispatch also has goals, which are:

 Time window of two minutes from the emergency call until the ambulance is notified  Time window of 15 minutes between the notification and emergency vehicle arriving

at the Emergency location

 Establish connection between the Emergency Vehicle and the Hospital

Hospital

(34)

34 preforms influences the cycle times of the ambulance therefore the Hospital is not modelled in order to keep the model simple. The hospital is then an important stakeholder and the goal that they have for the process is:

 to receive the patient as soon as possible (in less than 4.5 hours after the first stroke symptom)

RAV

The RAV, or Regional Ambulance Services, are a hybrid stakeholder since (as mentioned before) they belong to both groups of external stakeholders. To explain why do they belong to both groups an explanation on what they are is needed. The RAV’s are the entities legally appointed to provide ambulance care and maintain the ambulance care dispatch centre. There are 25 of them in the Netherlands controlling more than 207 ambulance posts.

Therefore, they have goals for the single runs:

 The patients are provided with the adequate services

 Having the ambulances delivering the patients as fast as possible and also for the emergencies as a whole:

 Being able to cover their assigned area within the time limits defined by the Minister of Healthcare

Ambulance Care Medical Manager

The MMA is a licensed physician who has the final responsibility for the medical care given within a specific RAV. They are not directly involved on site, but can be consulted at a distance. Quality levels are safeguarded by means of protocols. The goals of the Ambulance Care Medical Manager are:

 To make sure that the ambulance nurse is qualified to treat the patients  The protocols are followed by the ambulance crews

National Dispatch Centre Organisation (LMO)

The LMO is the organization that supervises the dispatch centres and creates the protocols that are later followed by the latter. The objectives of the LMO are:

 To provide the call centres with the best equipment

(35)

35

Ambulancezorg Netherlands

Ambulancezorg Nederland is the number one sector organisation for ambulance care. The organisation offers various types of support to the Regional Ambulance Services (RAVs), ambulance organisations and the professionals who work there. It also promotes the collective interests of the sector. It’s a really important stakeholder for the project since it serves as an umbrella for other stakeholders. Their goal is:

 The RAV’s are provided with adequate support in order to operate efficiently

The Minister of Healthcare (VWS)

The VWS is an important stakeholder for the process since all the other stakeholders are governed by the laws created by the VWS. The laws that is of most importance for this process is the Interim Ambulance Care act (TWAS) that rules all the AZN (therefor the RAV’s) and the LMO. The TWAS is only an interim act that must be changed until 2018. The goal for the VWS is:

 The rules set for the ambulances are up to date with the latest needs and capacities of the ambulance centres, the patients, and hospitals.

The Health Insurance Companies

In the Netherlands, health insurers are responsible for financing ambulance care. The health insurers divide up the national macro budget for healthcare. The division takes place on the basis of policy rules adopted by the Dutch Healthcare Authority (NZa).

As a result of the agreement concluded in 2010 between the Minister of Health, Welfare and Sport and Ambulancezorg Nederland (AZN). The goals for the Health Insurance Companies are:

 Having a good and fast care at affordable prices

 Average time of all stroke emergencies are within previous defined times 4.1.1.3. Critical Success Factors and Business Requirements

(36)

36 like before we will present first the CSF’s for the internal stakeholders followed by the CSF’s for external stakeholders.

Critical Success Factors Internal Stakeholders

Ambulance

 The information shall be complete  The information must be correct  The process shall be fast

 The system must record the cycle times of the different tasks  The system must record the total cycle time

 The information must be available

Critical Success Factors External Stakeholders

Patient

 The process shall be fast

Dispatch Centre

 The process must record cycle times  The information shall be available  The Data should be traceable  The data is transferable

Hospital

 The process must record the cycle times  The information should be available  The Data is transferable

 The Data is traceable

Regional Ambulance Service

 The system shall record the cycle times  The information must be available  The Data should be traceable

(37)

37

Ambulance Care Medical Manager

 The information shall be available

 The process should be performed within the regulations

National Dispatch Centre Organisation

 The system must record the cycle times  The information should be available

Ambulancezorg Netherlands

 The information must be available  The system must record the cycle times  The data must be transferable

 The process shall not exceed the defined time windows

The Ministry of Healthcare

 The system shall comply with the regulations  The information shall be available

 The data should be traceable

Healthcare Insurance Companies

 The system shall record the cycle times  The information must be available

 The system shall create averages of the cycle times  The Data is transferable

 The Data is traceable

 The system shall comply with the regulations.

4.1.2. Diagnosis/Analysis

Having completed the mapping of the Design Problem which is the first step of the regulative cycle, it is now time to move to the step two, Diagnosis/ Analysis of the relations between the CSF’s of the stakeholders. This needs to be done to assure that there are no conflicting CSF’s and that for the ones that present conflicts the appropriated trade-offs are defined.

(38)

38 cycle times for this process (and for each activity) has been proven to be an important part of this process since in practice any improvement on these can lead to saving lives. Also no conflict between CSF’s has been found, the only place where a trade-off might be needed is between the complexity of the model and the need of understanding the system by several stakeholders. On that case the side which must be considered more is the stakeholders, therefore the model should only be as complex as it is able to collect the cycle times.

4.1.3. Design Solution

The third phase of the regulatory cycle is to design the solution. Like it was explained BPMN will be used to design the model due to its easiness of read, even for people not familiarized with it. To design the model we had to start from scratch since from the data that was available it was only possible to model the activities that the ambulance crew preformed on the patient. All the other necessary information (like how the work is divided between the ambulance crew) came from applying the methodology for developing the process models, in the meetings with the end-user. The biggest limitation we faced while constructing the first sketches of the model was the lack of interviewee knowledge on the process notation.

4.1.3.1. Develop the Process Models

Having conducted all the diagnosis and analysis phases we were now able to start

developing the process model. For this we guided ourselves by the methodology presented in Meerman’s (2015) and Van de Laar (2015). This methodology presents the guiding steps to develop the process models from the “Happy Flow”. This questions were conducted in interviews and validation forms as we are going to explain in more detail in the validation phase ahead. The questions are:

 At what instance does the event happen?  How can the event be identified?

 Which entities are involved in the event as participants?  What is the input for the event?

 What is the output for the event?

The way these questions were handled, and how they helped constructing the model will now be elaborated upon.

How can this event be identified?

(39)

39 where the information for the model was gathered, the first question asked, was how the events could be identified. Because it was important to know how each event should be modelled in BPMN to design an accurate blueprint for the database creation. To complete this process, some of the BPMN features had to be explained during the interview.

One process that raised questions was the exclusive gateway in the middle of the process that leads to the process to continue or to stop. It had to be explained that this gateway was necessary so that the cycle times for patients who didn’t actually have a stroke emergency, like it was defined on the emergency call, could be excluded from the database.

Other way that the events could have been modelled and raised some questions on why they weren’t modelled like that was the use of the nested events. These events could have been used in more than one event on our model. But that didn’t happen since all the activities that would have been described did not had a clear start and end. Therefore the events were modelled as one single event comprising all those activities. As an example, we have the first activity “Prepare and leave to scene” which obviously comprises more activities within it, activities which couldn’t be described since they can vary from emergency to emergency. At what instance does the event happen?

The stakeholders were asked where on the timeline of the pathway each event took place. This is, what process took place before that specific event and what process took place after. This question is of a major importance for the construction of the model since it is important for the process to be coherent with what is happening in reality.

One example from this model that reveals the importance of this question was when modelling the processes that occur in the ambulance. There was some confusion on which process was performed first, which is irrelevant since it varies from patient to patient. Only after having understood this information was it possible to model correctly with the help of inclusive gateway which defines that those processes have to be done before the end of the gateway, but without any predefined order.

Which entities are involved in the event as participants?

(40)

40 What is the input and output for an event?

The last questions were grouped together to make it easier during the interviews to understand the answers. Having in mind that the proposed system objective is to record the cycle times, most of the outputs and inputs were easily gathered during the interviews. The inputs and outputs are present on the Appendix B.

Now that the model has been developed, it needs to be validated.

4.1.4. Validation

Validation consists of the regulative cycle’s final stage. Again the guidelines from Meerman (2015) and Van de Laar (2015) were followed to validate the part of the design solution.

4.1.4.1. Validating the Process Model

The validation process was made in two different ways. The first validations were made with interviews with stakeholders. These interviews were, as said in the methodology, semi structured so that when the stakeholders saw any flaw on the model, follow up questions could be made on the moment. This allowed for the model to get easily updated and for us to understand better which aspects the respondents considered key in the model. The structured part of the interviews was based on the work of Balsters (2013) who defines four questions to proceed to an easier validation of process models. Those questions are:

 Are all Critical Success Factors met?

 Are there trade-offs between the Critical Success Factors?

 Is the method completely and correctly displayed in the process models? If not, should it be adapted?

 Is the data which is used at every event complete and correct? If not, how should it be adapted?

(41)

41 It is important to remember that the full validation of the project was made by Platon (2016). The detailed analysis on the validation and feedback on the overall handling of the project can be found in her work.

4.2. Overarching Research Project

Having presented the results for the individual regulative cycle, the contribution of this thesis for the regulative cycle of the overarching will be now be presented.

As explained in the methodology section, this thesis focuses on the first two (can be called one and a half) steps of the overarching project. It’s important to emphasize on the fact that the goal of the overarching project is different than the goal for this thesis. The objective of the present thesis paper is to develop a business process in BPMN and the goal for the overarching project of which this thesis paper is a part of, is to develop a blueprint of a system that can measure a pre-hospital path of a stroke related patient.

The contribution for the project from this thesis will be elaborated by following the steps from the regulative cycle. The results to the Design problem and the Diagnosis and analysis part of the regulative cycle, which were the steps assign to this thesis are shown here. The Design solution is then the combined results from both Rouby’s (2016) and this thesis result and the Validation is the result of Platon’s (2016) individual thesis, therefore none of these two steps is going to be presented next.

4.2.1. Design Problem

On the first step, as it was done in the section 4.1.1 of the individual research, the objective is to understand who the stakeholders are and what are their goals and CSF’s. On this project only one stakeholder was identified the UMCGA who represent the RAV for the region of Drenthe.

The goal from the UMCGA for this design is to:

 Have a system that calculates the complete ambulance path cycle times of patients who suffer from a stroke related emergency individually

This goal is similar to the RAV goals from the individual regulative cycle, therefore for all the CSFs please refer to the CSF of the RAV presented in the section 4.1.1.3.

This first step is then completed, we proceed now to the second step.

4.2.2. Diagnosis/Analysis

(42)

42 are no conflicts between the CSF’s for the UMCGA, but is clear that the system should register all the cycle times of the activities requested.

5. Discussion

In this section the outcome of this research project will be discussed. The discussion/reflection will be divided in three parts, firstly the way the results answer the sub questions will be presented (section 5.1), then the research objective will be reflected on (section 5.2), and in the end, final general remarks about the research will be addressed (section 5.3).

5.1. Reflection on the sub-questions

5.1.1. How can we model the stroke emergency pre-hospital pathway process using a standard business process modelling language?

In order to model the process the BPMN notation was used which originated the map presented in figure 4.2. Just as it is possible to see when observing the BPMN map, the language shows the process in clear and concise way. It allows the common reader to be able to go through it without having to have much experience with it. But there were some problems with the notation and the process. Firstly, having only one stakeholder active in the process made this map not to be a regular one, which might be a problem when using the notation in other designs since there are usually more than one stakeholders in the processes. Moreover, sometimes defining who’s got the responsibility for a determined situation may be complicated which can lead to maps that don’t properly represent the process.

Other problem was the fact that some sub processes include more tasks than the ones the name suggests, but due to a effort of keeping the model simple as possible (which is a requirement of the notation) the sub processes were combined in only one process which might not properly represent the pathway accurately if the map is used to other design that has a different objective than the current one.

5.1.2. Who are the main stakeholders in this process (Ambulance pathway)?

The main stakeholder in this process is one, the UMCGA it is the organization pushing for the implementation of the design and the only stakeholder that is represented in the BPMN map. This is not a regular feature in the design science field, which is a good thing for the objective of this individual thesis since it shows that the methodology used is valid even for unusual designs.

Building an information product for cycle time analysis