Creating a blueprint for the implementation of an electronic patient database to measure cycle times in Head and Neck Oncology departments.

(1)

Creating a blueprint for the implementation of an

electronic patient database to measure cycle times in

Head and Neck Oncology departments.

Creating process models for the creation of an information system blueprint in head and neck oncology departments.

Dual supervision:

Professor Herman Blasters Professor Christian Hicks Faculty of Economics and Business

University of Groningen The Netherlands

Newcastle University Business School Newcastle University

United Kingdom

Technology and Operations Management Operations and Supply Chain Management

S2531070 B140629026

Alders, Thomas Word count: 14.899

Date of submission: December 7th, 2015

Abstract:

Healthcare costs are rising due to the increasing life expectancy and new developments in the number of treatable deceases. A specific healthcare specialism, which is subject to pressures for the ability to measure its quality of care, is oncology. SONCOS has set regulations on the maximum cycle time of the Head and Neck Oncology (HNO) care pathway. This project aimed to add to the existing literature by creating a generic architecture for diagnostic phases of HNO departments in the Netherlands. Furthermore, it created a generic method for the creation of BPMN models. Lastly, it created a generic method for the implementation of User Interface Mock-up (UIM) feedback to BPMN models, allowing the application of UIM as a validation method.

(2)

Preface

This research is the result of the final research project of the MSc Technology and Operations Management program at the University of Groningen and Operations and Supply Chain Management at the Newcastle University. I would like to thank professor Herman Balsters from the University of Groningen and professor Christian Hicks from the University of Newcastle for their feedback on this report. Furthermore, I would like to thank all the people at the Large Teaching Hospital in the Netherlands (LTHN) for their support in this project. Especially the information managers, process managers and project initiator for the frequent support meetings and the guidance in the complex organization. Without the input of the case managers, healthcare specialists and principle specialist this research would not be of the current standard.

(3)

Table of figures

Figure 2.1 BPMN elements (Chinosi & Trombetta 2012) ... 12

Figure 2.2, DCM patient ... 14

Figure 2.3, DCM container contact details ... 15

Figure 3.1 Regulative cycle (van Strien, 1997) ... 18

Figure 3.2, Regulative cycle by Wieringa (2009) ... 18

Figure 3.3, Cycle overarching project ... 19

Figure 3.4, Activity ... 20

Figure 3.5, Connecting objects ... 20

Figure 3.6, Gateways ... 20

Figure 3.7, Gateway example ... 20

Figure 3.8, Event types ... 21

Figure 3.9, Use of intermediate events ... 21

Figure 3.10, Event logos ... 22

Figure 3.11, Swimlane types ... 22

Figure 3.12, Example BPMN model ... 23

Figure 3.13, Gateway interview example ... 26

Figure 4.1, Black box ... 29

Figure 4.2, Happy flow ... 30

Figure 4.3, UIM title, stakeholder ... 33

Figure 4.4, UIM activity ... 34

Figure 4.5, UIM non-required question ... 34

Figure 4.6, UIM gateways ... 34

Figure 4.7, BPMN readability example ... 37

Figure 4.8, Version management ... 37

Figure 4.9, Deterministic ... 41

Figure 4.10, Gateways in ORM ... 42

Table of tables

Table 4.1, Individual cycle direct-stakeholders ... 31

Table 4.2, Individual cycle indirect-stakeholders ... 31

(5)

Acronyms

Abbreviation Explanation

BPMN Business Process Model and Notation. Method to create process models

CSF Critical Success Factors

DCM Detailed Clinical Models. Method to define the concept of data in a clinical context

EHR Electronic Health Record

eMeasure Method of measuring health quality performance with the use of DCM ENT Ear Nose and Throat. A medical specialism within HNO

HL7 Health Level Seven

HNO Head and Neck Oncology. The PCP investigated in this research

HQMF Health Quality Measure Format

Individual-artefact The BPMN methodology

IS Information System

ISB Information System Blueprint

LTHN Large Teaching Hospital in The Netherlands. Organization this research was conducted in

MDO Multidisciplinary consultation. Consultation with multiple caregivers MDS Multidisciplinary consultation. Consultation with multiple caregivers

and the patient

ORM Object Role Modelling. Method to create data models Overarching-artefact The BPMN-ORM-UIM methodology for creating the ISB

PCP Patient Care Pathway

SONCOS Foundation Oncology Cooperation (Stichting Oncologische Samenwerking)

(6)

1 Introduction

Healthcare costs are rising due to the increasing life expectancy and increases in the number of treatable deceases (Okma & Crivelli 2013). In order to cope with this increase in costs, governments and insurance organizations pressure hospitals to lower costs (Elg et al. 2011). Correspondingly, the Dutch government transformed the market to a consumer-driven healthcare market, enabling hospitals to compete against each other on quality and price (Okma & Crivelli 2013). Consequently, hospitals aim to standardize and digitize their processes by initiating IT projects (Van Ginneken 2002). However, Black et al. (2011, p.6) stated that “potential risks of these systems include increased time spent on computer-related activity and increased infrastructure costs, thereby decreasing overall organisational efficiency”. Hence, healthcare costs are rising, and although both hospitals and governments are trying to find ways to reduce the expenses, most projects fail resulting in even higher costs.

Several methods are used to decrease healthcare costs. A method of digitization is for instance an Electronic Health Record (EHR). An EHR “encompasses all health information in all media forms regarding an individual and is the primary source for recording and documenting client health data“ (Fetter 2009, p.345). It includes all information about patients’ physical and mental health in an electronic database, and has the capability support the provision of health care and related services (American Society for Testing and Materials 2004). Another method to decrease costs and increase quality is the use of Patient Care Pathways (PCP). PCP are “integrated management plans that display goals for patients, and provide the sequence and timing of actions necessary to achieve such goals with optimal efficiency” (Panella et al. 2003, p.509). Hence, they are structured care plans that provide detailed standardized descriptions of the care process, aiming to provide high quality care in a timely and cost effective manner (Olsson et al. 2009; Kinsman et al. 2010). Healthcare systems consist of a business process with a high variability due to, for example, the scarce use of medical evidence or professional uncertainties (Panella et al. 2003). Therefore, reducing variability in healthcare processes by means of PCP or EHR systems could be an effective way to improve quality and reduce costs (Zehr et al. 1998).

(7)

improving the performance first it has to be measured. Consequently, if the opportunity for quality improvements could be obtained with a minimum effect on organizational processes, this could form an interesting alternative starting point compared to the direct adoption of EHR systems designed form an IT point of view. Hence, the creation of a blueprint that guides a successful development of an IS which merely allows cycle time measurability would greatly enhance the quality of care.

A specific healthcare specialism, which is subject to pressures for the ability to measure its quality of care, is oncology. The treatment of cancer is a highly complex and variable process increasing the chance of error in both treatments and planning (Malicki 2012). In Europe over 1.7million people each year die of cancer and due to the aging of the European population, this number will only rise (Ferlay et al. 2007). In order to increase the quality of the oncology healthcare in the Netherlands, the Dutch Health Care Inspectorate (Inspectie voor de Gezondheidszorg, IGZ), the Dutch Healthcare Authority (Nederlandse zorg autoriteit, NZA) and several societies of medical specialists introduced the quality standards set by the Foundation Oncology Collaboration (SONCOS) in 2012. The quality standard aims to guarantee and improve the quality of Dutch hospitals (SONCOS 2014). This document contains instructions on the required experience of the doctors and norms on the maximum allowed cycle time for certain treatments (SONCOS 2014). For instance, one of these norms indicates that the cycle time of the diagnostic phase of the Head and Neck Oncology (HNO) pathway has to be within 28 days. Correspondingly, it requires hospitals to present data concerning cycle times to governing institutions (e.g. data on the time between the arrival of a patient at the hospital and the start of his/her first treatment). However, currently multiple Dutch hospitals are not yet able to accurately measure their performance according to the SONCOS requirements (SONCOS 2014).

(8)

ISB in the context of a HNO pathway to measure the cycle time eMeasure. This ISB consists of a combination of a process modelling method and a data modelling method, which will be further explained in the theoretical background. However, this ISB has not been validated yet. Therefore, the current study extended this research to validate the design principles for such a blueprint. Hence, this research differentiates in the fact that it focussed on the creation of a validated design which resulted in the following objective:

“In the context of the clinical pathway Head and Neck Oncology (HNO) to design and validate an information product to attain cycle time measurability of that clinical pathway

adhering to the SONCOS requirements”

Since this project seeks to “extend the boundaries of human and organizational capabilities by creating new and innovative artefacts” (Hevner et al. 2004, p.75), it can be defined as Design Science. Within Design Science, such an artefact is validated when it meets all its requirements identified by affected stakeholders. Hence, in order to create an ISB which guides the successful design of a pathway, it has to meet these requirements as optimally as possible. This is ensured by analysing the Design Science problem according to the regulative cycle of van Strien (1997). This regulative cycle follows the design stages of design problem, diagnosis/analysis, design solution, design validation and design implementation and is based on the understanding that the creation of a design can be difficult and error prone (Chinosi & Trombetta 2012). The cycle was executed several times to improve and test the validity of the design. Notably, in order to increase the flexibility and speed up the project concurrent engineering was applied. This entails that in order to fulfil the overall research objective identified above, the project was divided in small parts, which could be worked on simultaneously in Ten Holt (2016), Oldenburger (2016) and this individual research.

(9)

“by using natural language as well as intuitive diagrams that can be populated with examples and by examining the information in terms of simple or elementary facts” (Halpin 2007, p.1). It depicts the data in terms of entities or values, objects that play parts in relationships and roles (Halpin & Bloesch 1999).

This specific study focused on the design and validation of the process models of the ISB in the design solution phase. Therefore, a graphical method called Business Process Model and Notation (BPMN) was used. BPMN is “a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes” (White 2004, p.4). BPMN has found to be a suitable tool to model processes in the healthcare context (Müller & Rogge-Solti 2011; Rojo et al. 2008; Aguilar et al. 2008; Scheuerlein et al. 2012). Subsequently, both the improved BPMN and ORM models were validated in the design validation stage through the use of UIM. If errors were discovered, the cycle was repeated.

Correspondingly, in order to fulfil the objective of the overarching-project, from a process modelling perspective the following sub-questions were posted:

1. Who are the stakeholders affected by the information system blueprint and what are their requirements?

2. Is BPMN a flexible and appropriate tool in combination with Object Role Modelling (ORM) and User Interface Mock-ups (UIM)?

3. Are the results of the overarching-research generalizable to other hospitals?

(10)

a methodology for the creation of validated BPMN models in the context of a HNO department. Currently, there are generic methods available for the creation of BPMN models such as a high level 4 step guideline on the creation of BPMN models (Barros & Quezada 2014; Di Leva & Famiano 2011). However there does not yet exists a method for the creation of validated BPMN models. This research further elaborated on the high level methodology to create a more concrete method for the design of validated BPMN models. It started with a technical validation of the process models created by Meerman (2015) and then incorporated the feedback from Oldenburger (2016) to improve the BPMN process models. Furthermore, it assessed the appropriateness of BPMN in this context and the validation methods used in the former projects. New insights from the validation resulted in incorrect BPNM models which had to be amended and then validated again. Hence, the individual part of this research differentiates in the fact that it will focus on the creation of a validated design resulting in the following objective:

“In the context of the clinical pathway Head and Neck Oncology (HNO) to design and validate a process modelling method which can be used to create an information system

blueprint to attain cycle time measurability of that clinical pathway according to the SONCOS requirements”

In order to reach this objective the following questions were answered:

4. Who are the stakeholders affected by the process modelling method and what are their requirements?

5. What are existing process modelling methods available in literature?

6. Is Business Process Model and Notation (BPMN) a flexible and appropriate tool to model processes in the diagnostic phase of a Head and Neck Oncology (HNO) care pathway?

7. Are the results of the individual research generalizable to other hospitals?

(11)

2 Background

This section discusses the relevant literature for this research. Firstly, the method used to model the business processes, Business Process Model and Notation (BPMN) is discussed. Furthermore, the use of Data Clinical Models (DCM) will be explained. Despite the fact that the data models were created by Ten Holt (2016) the context of this project requires an understanding of DCM. Subsequently, the different types of validation relevant to this project are discussed. Lastly, user interface mock-ups (UIM), one of the validation methods of the process models will be addressed.

2.1 Process modelling

(12)

research will apply the method of BPMN to model the business processes. A BPMN chart consists of multiple elements namely; events, pools, activities, artefacts, gateways and connecting objects (Chinosi & Trombetta 2012; White 2004) shown in Figure 2.1. These elements are used to model the current or a future state of a process. More information on BPMN models can be found in the paragraph 3.1.3.

(13)

2.2 Detailed Clinical Models

A Detailed Clinical Model (DCM) was defined by Goossen et al. (2010, p.202) as “a relatively small, standalone information model designed to express a clinical concept in a standardized and reusable manner”. It enables both clinical experts and modellers to understand the clinical and data elements of a clinical concept. The idea of the DCM is that they are standardized, reusable building blocks which can be used in different applications and enable the programmer and clinical expert to make sure that the required data is available. DCM were developed concerning the HL7 standard which is a “standards developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services” (Health Level Seven 2015a). Hence, DCM are used to specify information needs in a general and unambiguous form (Parker et al. 2004). In addition due to the standardization of DCM it enables the transfer of information between organizations and thereby enables the implementation of an Electronic Health Record (EHR). A few examples of DCM are bodyweight, vaccinations, nationality and patient.

(14)

The rootconcept (the DCM) is displayed in the black edged box in the middle and shows the name of the DCM. A patient has several data elements like a birth date, gender and a patient identification number. Gender (Geslacht) has a list attached to it called gendercodelist (GeslachtCodelijst) which includes all possible values (Undifferentiated, Male, Female or Unknown) of the field gender. Next to these data elements there are containers which is a group data for instance the name details (Naamsgegevens), address details (Adresgegevens) or contact details (Contactgegeves). Figure 2.3 shows the container contact details and shows that this container holds two containers which are telephonenumber (Telefoonnummers) and emailadresses (EmailAdressen) which consist both out of two data elements. Due to the increased amount of interest in automation of the healthcare industry, an ISO standard is currently under development in order to standardize the use of DCM, CEN ISO/TS 13972 (CEN, 2015). In conclusion, a DCM is a collection of information for a certain clinical concept including the data specifications and relations, enabling the use, standardization and analysis of data elements throughout the whole organization and between organizations.

(15)

2.3 Validation

In order to make sure the proposed design is “correct”, it needs to be validated. Concerning Wieringa and Morah (2012), a validated design is a design which satisfies the criteria of the stakeholders in an optimum way. There are three aspects of validation in the context of design science, namely internal validity, trade-offs and external validity (Wieringa 2009). Where internal validity is the validation of the extent to which they satisfy the stakeholder criteria. Important stakeholders to validate the design are the end-users (Reijers 2006) since for instance the doctor is the one who has to use the system. Besides these end-users there also stakeholders which are not directly using the system but are affected by it. For instance the Principle specialist Oncology department is not directly using the system but is interested in the output of the system, the cycle time measurement since he has to report these cycle times. Concerning the ISO25010:2011 standard stakeholders can be split into direct-stakeholders which are the end-users and indirect-direct-stakeholders which are affected by the system but not directly using it. The validation of the overarching-artefact was be executed by Oldenburger (2016) using interface mock-ups in the form of forms which are discussed in the following paragraph and section 3.1.2. Another aspect of validation is trade-offs, which tries to validate the proposed design by analysing whether slightly different designs fulfil the criteria the same way. This could be including an additional activity in the design, which improves the fulfilment of the criteria of one stakeholder, but negatively influences the performance of

(16)

another stakeholder. Lastly, external validity aims to validate whether if the design would be implemented in a slightly different context, the stakeholders criteria would still be satisfied. Hence, it validates whether the design can be used in a different context like a HNO department of another Dutch hospital.

2.4 User interface

(17)

3 Methodology

This section will discuss the methods that were used to conduct this research. First, the specifics of Design Science and its execution in the form of the regulative cycle are addressed. Secondly, the applied method of Business Process Model and Notation (BPMN) in order to create the process model will be analysed. Subsequently, the data collection procedures for the project as a whole according to the strategy of concurrent engineering will be outlined, followed by the procedures for data collection and analysis for this specific research.

3.1 Methods and Research Strategy

The following paragraphs will discuss why the strategy of Design Science with the use of the Regulative Cycle is most suitable for the creation of a validated information system blueprint which allows cycle time measurability concerning the SONCOS norms. Subsequently, the application of BPMN in this research will be addressed.

3.1.1 Design science

Since the current situation of information storing and transferring in Head and Neck Oncology (HNO) pathways is often inefficient and not adhering to the SONCOS requirements, there exists an opportunity to significantly improve the quality. Until now no completely validated artefact exists. This unexplored situation represents a problem which can be best analysed through design science. Thereby this project aimed to resolve a practical issue by creating and validating an artefact, as opposed to building and testing theory of an existing phenomenon (Holmstrom et al. 2009). It aims to create innovative validated artefacts which provide understanding of a problem in order to improve both the quality of the artefact and the design process (Hevner et al. 2004). After creating a validated artefact it can be evaluated in order to get a better understanding of the problem which might improve future design processes (Hevner et al. 2004).

3.1.2 Regulative cycle

(18)

blueprint (ISB) due to resource limitations like the lack of knowledge of databases and the limited time available for this project. Wieringa (2009, p.5) stated that “what constitutes an implementation depends on what solution has been designed” and for this research the implementation was partially constituted by the User Interface Mock-ups (UIM). Although this research did not include the implementation phase the creation of the ISB, an artefact can be later used for the implementation of the Information System (IS).

This project consists out of two cycles, the individual-cycle which aims to create a method to create validated Business Process Model and Notation (BPMN) process models. This cycle was part of the overarching-cycle which aims to create the ISB allowing the implementation of an IS. The cycle started with the problem investigation phase, wherein the problem was described. In this phase the goals and Critical Success Factors (CSF) of the stakeholders were identified. This was done via, for instance, conducting interviews with the stakeholders (i.e. doctors and nurses). In the diagnosis/analysis phase the CSF and goals were analysed resulting in quality attributes the design had to comply to. In the design solution phase an artefact was designed to solve the problem, i.e. meet the goals and the CSF of the stakeholders as best as possible. For the individual-cycle this was the creation of validated BPMN models and a method to create them. For the overarching-cycle this artifact were the BPMN models along with the data models created by Ten Holt (2016).

Subsequently, the design was validated to identify whether it met the requirements of the stakeholders. In total there exist three types of validity relevant to a design science problem. Firstly, internal validity represents the extent to which the design meets the requirements of the stakeholders. In the individual-cycle the validation of the proposed BPMN model and

Figure 3.1 Regulative cycle (van Strien, 1997)

(19)

methodology were assessed. This was conducted by assessing whether the BPMN models and methodology met the stakeholder requirements. Secondly, trade-offs represent a type of validation wherein the proposed design is compared with alternative designs. Lastly, external validity assesses the scalability of the design. Hence, whether the proposed design can be used in a slightly different context. This is assessed using the expertise of domain experts.

Figure 3.3 shows the cycle of the overarching-research. The black arrows shows the standard flow of the project. First a process-model was created by this research. Then a database-model by ten Holt (2016). Then both models were validated by Oldenburger (2016) using UIM. Feedback gained from the validation was gained and used as input for the beginning of the cycle, starting the cycle again until there were no errors found in the validation. This model has similarities with the waterfall method “in which progress is seen as flowing steadily downwards (like a waterfall) through the phases” (Balaji 2012, p.26). Except that each step was not frozen before the next step and that it was a cycle (at the end of the waterfall it starts again at the beginning). Furthermore there red lines in the model show a more agile approach which is described in more detail in section 3.2.1 (concurrent engineering). This agile method allows the progress to also move upwards. Hence, if during the database-model cycle an error is found in the process model the cycle will not first go to the user interface mock-up-cycle but the models are edited in the process-model cycle.

3.1.3 Business Process Model and Notation (BPMN)

This section will outline how BPMN was used in this project to model the oncology Care Pathway. There are several software programs to create BPMN models like Oracle BPM,

(20)

TIBCO AMX BPM suite (Chinosi & Trombetta 2012) and Bizagi. Since the former researches (Beukeboom 2015; Meerman 2015) used the software of Bizagi, one of the supporting organizations of the BPMN standard (Object Management Group 2015) and their software is open source it will be used in this research to create BPMN models. Bizagi Modeler allows “business experts design, document and evolve their process model” concerning the BPMN standard (http://www.bizagi.com/en/products). In other words it allows the creation of a model which complies to the BPMN 2.0 standard.

In BPMN a process is shown as a graph of flow elements which consist out of activities, connecting objects, events and gateways. The flow elements used in this research are discussed in this section. A more comprehensive overview can be found in appendix A. An activity is “work that is performed within a Business Process” (Object Management Group 2015, p.149) and is shown as a box (Figure 3.4). An activity can for instance be the intake of a patient or the anamnesis of a patient or the conduction of a meeting. Activities and other flow elements are connected to each other using connecting objects which are displayed as three different types of arrows shown in Figure 3.5. A connecting object has only one source and only one target. Hence, it cannot divide or merge the flow. The sequence flow shows “the order in which activities are performed in a process” (Object Management Group 2015, p.502). Hence, it can be used to show that the patient arrives before the doctor starts the anamnesis. It can cross the boundaries between lanes but not between pools (described below). A message flow shows “the flow of messages between two participants“ (Object Management Group 2015, p.502). It can cross the boundaries between pools but cannot be used to connect objects within lanes (described below). A connecting object is used to “link information and artefacts with Flow Objects” (Object Management Group 2015, p.499).

Sequence flows can be directed using gateways (Figure 3.6) which are “used to control the divergence and convergence of sequence flow” (White 2004, p.2). Exclusive gateways are used for for yes/no questions hence, it divergences the sequence flow based on a yes no

Figure 3.4, Activity Figure 3.5, Connecting objects

Figure 3.6,

(21)

question. Furthermore, the parrallel gateway can be used to “synchronize (combine) parallel flows and to create parallel flows” (Object Management Group 2015, p.292). Figure 3.7 shows an example of a parallel gateway. In this example, after the first visit of a patient simultaneously the doctor welcomes the patient and the administration requests the patient information. The first gateway splits the flow and after which simultaneously both activities are conducted and the second gateway merges the the flow. After both activities are comleted the second gateway merges the flow. All process flows contain at least two Events which represent “something that happens or may happen during the course of a process and that affect its flow” (Brookshier 2015, p.2).

There are three types of events namely, a start, intermediate and end event (Figure 3.8). All process flows start with a start event which depicts the start of the process flow. These objects only have an output flow and no input flow. This for instance can be visit of the patient at the polyclinic which then results in the activity of anamnesis. An intermediate event indicates where something happens (an event) somewhere between the start and end of a process. It will “affect the flow of the process, but will not start or (directly) terminate the process” (Object Management Group 2015, p.248) and can be used to show where messages are sent or delays are expected within the process. Furthermore these intermediate events can be used in two ways, namely, they can be placed within the process or attached to the boundary as can be seen in Figure 3.9 (Object Management Group 2015). First they can be placed within the process flow to throw (e.g. send out a message) or to catch an event trigger (e.g. receive a message). Second they can be attached to the boundary of an activity to catch an event happening in that activity. This, for instance, can be a stakeholder which sends out an reminder in the activity. The event attached “catches” this message and therefore the flow continues through the arrow on the bottom right instead of the arrow on the upper right.

The process flow stops at an end event which can for instance be the creation of the care plan. There are several different event logos which say something about that event. Figure 3.10 shows the four event logos used in this research. The first logo shows the terminate event. When a “token reaches a terminate end event, the entire process is abnormally terminated” (Object Management Group 2015, p.462). The second logo shows the message throw event which

(22)

depicts a message being send. The third one, message catch shows a message being received and last logo is the error catch which depicts an error has happened and this activity catches that error and the flow continuous to after this activity. Activities can be divided using swimlanes which can be defined as “a graphical container for partitioning a set of activities from other activities” (Object Management Group 2015, p.502). There are two types of swimlanes namely pools and lanes (Figure 3.11). A pool represents a “participant in a collaboration. Graphically, a pool is a container for partitioning a process from other pools/participants” (Object Management Group 2015, p.501). It can for instance be the Head and Neck Oncology (HNO) intake which includes the stakeholders responsible for this intake. Or a black box (not containing any activities) like the external stakeholder. Furthermore, a pool can be split up in lanes which is “a partition that is used to organize and categorize activities within a pool” (Object Management Group 2015, p.501). A lane extends the entire length of the pool either vertically or horizontally. Lanes are often used for internal roles like for instance the case manager or the healthcare provider (Figure 3.11).

In order to create a better understanding of BPMN a simplified intake process is shown in Figure 3.12. The process is divided into two different pools namely the hospital and the external healthcare provider which is depicted as a black box. The hospital has two roles; healthcare provider and case manager which are shown in the lanes. The process flow starts with the start event “visit clinic” which shows the patient visit. After the visit the healthcare provider welcomes the patient and simultaneously the case manager requests information, which is shown by the sequence flow connecting the start event with the parallel gateway splitting the flow. The welcoming of the patient is shown by the activity “welcome patient” and is performed by the healthcare provider since it is located in his/her lane. After the case manager requests the information a message is send to the external healthcare provider which is shown as a message throw intermediate event. The message flow shows that the information request is send to the external healthcare provider. The message catch intermediate event shows that the flow waits until the information supply message flow supplies the information. After

(23)

the information is received the information is processed. The second parallel gateway mergers the flows together and shows that both the welcome patient and the process information activity have to be completed prior to the end event conduct analysis.

3.2 Data Collection and Analysis Procedures

This section will discuss the data collection strategy via the procedures of concurrent engineering. Following, the interview procedures and respondent selection are provided and the stakeholder analysis proceedings are outlined.

3.2.1 Concurrent engineering

In complex problems it is virtually impossible to anticipate the final choice at the start (Mihm et al. 2003). For instance, during the validation process an incorrect stakeholder requirement was identified which lead to amendments to the design. Hence, flexibility in projects is required to be able to identify these issues as soon as possible and react on them (Thomke 1997). For this project concurrent engineering was used in order to increase the flexibility and speed up the process by allowing multiple actors to work on the project simultaneously. The project was cut into different parts, which could be worked on simultaneously by the different project members. Mihm et al. (2003) identified six actions which can be used in order to increase flexibility:

 Limit System Size. The main goal of this action is to reduce the complexity of large complex design problems. In the case of this research, the scope is limited to an oncology department and the measurements are limited to cycle time measurements;  Modularization and Robust Design Methods. This method allows the reduction of the

(24)

The problem is tackled by splitting up the system in small subsystems, i.e. modules, allowing concurrent engineering. Detailed Clinical Models (DCM) are standardized and can be used in multiple locations. Hence, DCM facilitate the modularization of the design;

 Cut Interdependencies. Interdependencies are cut or ignored for the same reason as modularization. The problem is that when the wrong interdependencies are cut it can highly influence the performance of the end system. Especially in design science, where complex first-time problems are solved, it is hard to use prior experience to identify which links to cut. In this research the interdependencies are cut using DCMs;

 Immediate Broadcast of Design Updates. By continuously sharing information between the different actors designing the system it is prevented that decisions are based on obsolete information. In the case of this project, this is done by having regular project team meetings and work in a close proximity;

 Release Preliminary Information. Not only releasing final solutions but also intermediate results allows for intermediate validation of the system, preventing rework at the end of the design. Regular meetings with the stakeholders allows for the preliminary validation of the modules;

 Cooperate: Optimize Overarching Chunks As a System. While making decisions on a component of the system it is important to not only focus on that component but also its performance on the overall system. With the use of stakeholders goals and CSFs the effect of the components on the overall system are taken into account;

3.2.2 Interviews

(25)

exploratory meetings with the gatekeeper. For instance to discuss the stakeholder analysis created by the former group. Both techniques enabled the researcher to adapt the questions to answers given by the interviewee, resulting in a flexible interview. Furthermore, highly complex questions were explained and investigated by the interviewer since, when needed, questions could be reformulated and explained. The downside of using interviews is that it is a time consuming method for both the interviewee and interviewer (Karlsson 2009). However, despite this downside, the advantages of flexibility and exploration did make interviews the preferred method of data gathering in this research. The interviews were conducted with a minimal of two interviewees (tandem-interview) since this increases the data collection efficiency, validity and reliability (Kincaid & Bright 1957). Furthermore meeting minutes were written down and some of the meetings were recorded. Underneath the interview protocol for the semi-structures interviews is shown.

Interview protocol

1. First the scope of the project and the project goal were explained to the interviewee in order to provide information on the project and align the expectations of the interview. The goal of the project was explained with a basic description (in this case the SONCOS requirement to measure cycle times in the diagnostic phase of the Head and Neck Oncology (HNO) care pathway. The scope of the project was shown using the black box BPMN diagram shown in Figure 4.1. It was important that the black box model was kept on the table during the interview since it helped the interviewee to stay focussed on the scope of the project. Hence, it prevents loss in detail and irrelevant topics during the interview.

2. The happy flow (Figure 4.2) was then showed to the interviewee in order to again, show the scope of the project. Furthermore it enabled the interviewee quickly identify what has been modelled. It also functioned as a backbone to align which part of the process was discussed. Furthermore showing and explaining the happy flow also validated whether it was correct. This validation was done by showing the happy flow diagram to the interviewee and orally explain the activities, flows and gateways and ask for their feedback.

3. After the happy flow the detailed diagram was shown. First the stakeholders were introduced by addressing their names and explain their tasks. If concerning the interviewee stakeholders were missing or should not be included this was discussed. Then, the goals and CSF of the stakeholder were validated by reading them out and correct them when needed. 4. The detailed model was then validated by going through the model with the interviewee

(26)

activity the pre-condition, input, process, output and post-conditions. Whenever the sequence flow was directed by for instance a gateway both scenarios were explained separated. For instance in case of explaining the process model shown in Figure 3.13. In the first scenario (red line) the information was complete and to the interviewee was explained that after the anamnesis the MDS was conducted. In the second scenario (black line) the information was not complete and therefore after the anamnesis the information was requested. Both scenarios start with the anamnesis but afterwards have a different activity. Addressing anamnesis in both scenarios will improve the understanding of the context of the gateway and therefore improve validation.

5. Whenever an error in the modes was found the general event-identifying created by Meerman (2015) based on the general event-identifying questions created by Balsters (2013) were asked in order to model the event:

a. At what instance does the event happen? b. How can the event be identified?

c. Which entities are involved in the event as participants? d. What is the input for the event

e. What is the output of the event?

6. Then the interview finished by asking the validation questions based on Wieringa (2012) and Morah (2012) and Karlsson (2009).

a. Are all CSF’s met?

b. Is there a trade-off between the CSF’s

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

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

After the interview the minutes were analysed and discussed with the other interviewer(s). First possible implications on the design problem were analysed and thereafter the implications on the design solution. If implications were found possible contradictions were investigated.

1

2

(27)

Sometimes statements made during the interview were contradicting earlier statements by the stakeholder or another stakeholder. These were investigated which sometimes led to new intervieuws with the stakeholder or an alternative stakheholder. The possible implications were implemented and then the proposed design solution was validated again.

3.2.3 Respondents

During and after identification of the stakeholders, several respondents were selected together with the gatekeeper of the project. These were used as representatives for the stakeholder group and were used to identify the goals and CSFs, and as input for the creation and validation of the process diagrams. Since there were multiple stakeholders, at least one respondent per stakeholder was used to gather the information required resulting in multiple respondents. This is because due to the complexity of the processes in a hospital no single person has all the required knowledge to create the diagrams (Rojo et al. 2008). Furthermore, respondents might have different interpretations or viewpoints and by using multiple respondents as a representative for a stakeholder group it can improve the accuracy of the research (Karlsson 2009).

3.2.4 Stakeholder analysis

In order to create a validated design, the stakeholders had to be identified with the use of a stakeholder analysis. A stakeholder analysis aims to “evaluate and understand stakeholders from the perspective of an organization, or to determine their relevance to a project or policy” (Brugha & Varvasovszky 2000, p.239). Input for the stakeholder analysis was the stakeholder analysis of the former project, interviews with the gatekeeper and interviews with the stakeholders. Stakeholders can have a major impact on the outcome of this project since their participation is required for this research. Hence, it is important to keep them involved (Cawsey et al. 2015). Regular meetings were organized to provide the participants with updates on the progress. It also allowed them to validate the progress and give feedback. Since it is crucial to identify the stakeholders and their needs, a stakeholder analysis was constructed based on the steps of Bryson (2004):

 Analyse stakeholders of the former project;

 Brainstorm session with the gatekeeper to create a list of potential stakeholders;

 For each stakeholder list the critical success criteria the stakeholder would use to judge the performance and its goals;

(28)

 Identify and record longer-term issues with individual stakeholders and stakeholders as a group;

(29)

4 Results

This chapter discusses the results of this research. The result section is split up in two parts. The first part focusses on the individual regulative cycle and discusses the creation of the Business Process Model and Notation (BPMN) models. The second part discusses the process models in the context of the overarching-cycle.

4.1 Individual regulative cycle

This section discusses the creation of the BPMN process models using the steps of the regulative cycle as a guide. The individual cycle was conducted multiple times resulting in several amendments to the model. Interviews were held with the different stakeholders resulting in amendments to both the stakeholder analysis and the process diagrams.

4.1.1 Design problem

General process overviews

In order to create a high level view of the problem a black box was created. This black box view enabled the project members and stakeholders to align the scope of the project without losing focus when zooming into the process flow. In other words, which part of the patient care pathway had to be modelled for the focal project. The black box for the focal project is shown in Figure 4.1.

After creating the black box a high level overview, the happy flow shown in Figure 4.2 was drawn. During interviews the happy flow enabled the stakeholders together with the interviewees to make it more clear which part of the patient care pathway was discussed and the level of detail of the project. The happy flow has to be easily readable and should display as minimal detail as possible without compromising the unambiguity of the model. In order to improve the readability message flows were excluded from this model. Furthermore, the model is a process model i.e. it not taking into account different stakeholders which reduces the information richness of the model. A model with more information richness was created in the design solution phase. It included more activities and assigned each activity to a stakeholder which makes it a collaboration model.

(30)

Stakeholders

The stakeholder analysis was conducted using the former project, interviews and documents. Initially a stakeholder list was created using the former project (Meerman 2015; Schriever 2015; Lichtenberg 2015) and a meeting with the gatekeeper. During the interviews the stakeholder analysis was constantly reviewed resulting amendments to the stakeholders and their goals and Critical Success Factors (CSF). For instance the initial stakeholder analysis showed that the care administration had to be included in the BPMN diagram as a stakeholder. Later it was found that they their role is limited to an administrative role and thereby does not affect the process flow. Hence, they were excluded from the process diagram. Stakeholders were split into two different groups namely the direct-stakeholders and indirect-stakeholders as described in ISO25010:2011. The direct-stakeholders are participating in the modelled process and are affected by it. This for instance can be a healthcare provider or care administration. The indirect-stakeholders are not participating in the process but are affected by the design solution. Hence, they are affected by the methodology BPMN. This can be the process manager which has to create the BPMN models or the IT department which has to maintain the system. The goal and CSF of the stakeholders are limited to the part scope of this project. This result in goals which might appear different than the goal one would expect. For instance the healthcare provider his goal for the whole care pathway is to provide the best care possible to his patients but while limiting the goal to the scope of this project it was limited to the creation of a treatment plan for the patient as complete as possible. If the other parts of the care pathway outside of the scope of this project would be modelled all of the goals together would result in the overall goal, providing the best care possible to his patients. The direct stakeholders are shown in Table 4.1 and were included in the BPMN model as stakeholders. More comprehensive explanation on the stakeholders can be found in appendix 0.

(31)

Stakeholder Goal CSF MDS An as complete as possible

treatment plan for the patient

There should be sufficient information to construct the treatment plan

HHO workgroup An as complete as possible treatment plan for the patient

Healthcare provider

An as complete as possible treatment plan for the patient

Case manager Sufficient information for the treatment plan

There should be sufficient information at the right time to construct the treatment plan

Table 4.1, Individual cycle direct-stakeholders Furthermore there are some indirect-stakeholders which are affected by the design solution but not participating in the process shown in Table 4.2. These are not included in the BPMN model since they are not participating in the process.

Stakeholder Goal CSF

Research initiator at LTHN

A tool which can be used to support the implementation of DCM’s

The model must be easy to understand, unambiguous and support the

implementation of DCM’s

HH Oncology process managers

A tool which can be used to easily model the processes correctly

The model must be correct, easy to create, unambiguous and flexible.

Direct stakeholders

A model which correctly reflects the processes

The model must be correct, easy to understand and unambiguous

Table 4.2, Individual cycle indirect-stakeholders 4.1.2 Diagnosis/Analysis

After analysing the CSF of the stakeholders the following quality attributes were created which were again split up into the direct-stakeholders and the indirect-stakeholders. The direct stakeholders want to have sufficient information at the right time to construct the treatment plan. There were no trade-offs found of the direct-stakeholders. The indirect-stakeholders wanted to have a model that is correct, unambiguous, flexible and support Detail Clinical Models (DCM) implementation. A possible trade-off could be between the quality attribute unambiguous and flexibility. This because creating an unambiguous model might require additional action which limits the flexibility of the model.

4.1.3 Design solution

(32)

creating BPMN models and it will finish with a generic method to transform the feedback from User Interface Mock-ups (UIM) to BPMN models.

BPMN model

This paragraph discusses the created BPMN models. The Head and Neck Oncology (HNO) department can be split up into two major divisions together responsible for 90% of the patients, namely Ear Nose and Throat (ENT) and oral surgery. Initially both divisions where tried to be captured in one process diagram but due to different responsibilities of the stakeholder case manager in both divisions the care path had to be split into two flows. Nevertheless both, the black box and the happy flow were similar for both pathways. The BPMN models can be found in appendix C.

Generic method for the creation of BPMN models

This paragraph contains a generic step-by-step method for the creation of the BPMN models. It was continuously edited and updated throughout the project. The guide is not sequential. For instance the happy flow and the stakeholder analysis can be validated prior to the creation of the detailed flow.

1. The scope and the goal of the project should be defined. This has to done by creating the black box diagram shown in Figure 4.1. Especially the definition of the start and the end event are important since they indicate the scope of the project. In this case it was the SONCOS requirement to measure cycle times of the diagnostic phase of the HNO pathway. 2. Then the stakeholder analysis has to be conducted as described in section 4.1.1. For each

stakeholder the Goals and CSF has to be identified.

3. After the stakeholder analysis the happy flow has to be created. The generic architecture shown in Figure 4.2 can be used as a starting point. It can be quickly validated to see whether it is correct by validating it with for instance the project initiator.

(33)

5. Then the model is validated by showing the BPMN models to the stakeholder and the use of User Interface Mock-ups (UIM). The creation of the UIM was outside of the scope of this research but more information on the creation of UIM based on BPMN models can be found in Oldenburger (2016). A method to translate feedback obtained from the validation with UIM to the BPMN models can be found in the section below.

Method for creating BPMN models based on feedback user interface mock-ups.

In the validation phase the user interfaces were used to validate the BPMN models. This paragraph discusses a generic method to process this validation feedback to improve the BPMN process models. Appendix E shows the user interface mock-up of the anamnesis conduction created by Oldenburger (2016) which is used as an example below. The mock-up was edited by removing validation elements which validate the ORM data elements since they are not relevant for the validation of the process models.

1. First the title of the form and the stakeholder were validated. Figure 4.3 shows the relationship between on the left the user interface and on the right the BPMN model. Furthermore the stakeholder name, goal and CSF are shown in a text field and validated in the same screen. If during the validation errors emerged it led to a revision of the stakeholder analysis or the BPMN model.

2. The header of a page starts with the stakeholder conducting that activity which is represented by a swimlane in the BPMN model as shown in the Figure 4.4. Next to the stakeholder the activity name is written which corresponds to the activity name in BPMN. The pre-conditions, input, process, post-conditions and output of each activity are validated here. In case errors emerged it showed that the activity descriptions (appendix F), the activity name or the stakeholder performing the activity has to be assessed.

(34)

3. When an intermediate event is attached to the boundary of an activity it is shown in the user interfaces as a non-required question (not marked with a red asterisk after the

question) shown in Figure 4.5. In this case when the checkbox was checked the user goes to a page which says that he or she leaves the HNO clinical pathway.

4. Gateways are validated using required questions (marked with a red asterisk behind them) which show the options of the gateway and direct the flow of the UIM. For instance the information sufficiency check after the anamnesis shown in Figure 4.6. As can be seen in the BPMN diagram the information sufficiency check has four answers. Which UIM screen appears after pressing continue is based on the answer selected. This simulates the gateways directing the flow of activities of the BPMN diagram. Errors emerged result in an assessment of the gateway.

Figure 4.4, UIM activity

Figure 4.5, UIM non-required question

(35)

4.1.4 Validation

In this section is validated whether the artefact meets the requirements of the stakeholders. First the internal validity, the extent to which the proposed artefacts satisfy the stakeholder criteria and possible trade-offs is assessed. It finishes with the external validity which aims to validate whether if the design would be implemented in a slightly different context, the stakeholders criteria would still be satisfied.

Internal validity

The stakeholder analysis conducted in section 4.1.1 Design problem showed certain goals and CSF. The direct-stakeholders want to create a treatment plan and need sufficient information to do so. As can be seen in the model, the final end event depicts this goal. The gateways in the model display the CSF of the stakeholders. Multiple interviews were conducted with the stakeholders validating the models which showed that the models were meeting their requirements. In the following section the CSF of the indirect-stakeholder are transformed into paragraphs in which will be assessed whether and how these CSF are reached and it finishes an assessment of the trade-offs.

Unambiguous

(36)

performed (Object Management Group 2015; White 2004; Bizagi 2015b) and therefore input is transferred to output. The transformation of input to output is described by process of that activity. This is a description of the tasks performed during the activity which does not require to be modelled since it will result in a too detailed model but are described in order to clarify the context of the activity. The output of an activity shows what an activity makes available for the progress of the process. This for instance can be an indication which research has to be conducted after the MDO in order to be able to start with the treatment of the patient. Lastly, there can be post-conditions which refer to the characteristics of the result of an activity and can be described as “a logical assertion on the object base representing the software effort” (Kaiser et al. 1990, p.131). This for instance can be a patient concern type which can be changed after the MDO resulting in a modification in the database. After including the process descriptions next to the BPMN model validation with the stakeholders indicated that the models where ambiguous. The validation of the BPMN models showed that it is important that the input, process, output, pre-condition and post-condition are described as brief as possible using the stakeholders language. Hence, although merely the BPMN model is not unambiguous in combination with the process descriptions the model is unambiguous.

Easy to understand

(37)

Flexible

Due to new insight in the regulative cycle the process models had to be adjusted regularly. It is important that BPMN enables easy amendments to the diagram. Models are easy to modify due to the limited interconnections between the flow elements. These flow elements are connected using connecting objects which allow easy change of the sequence flow. For instance an extra gateway or an extra activity can be easily locally implemented with the inclusion of a connecting object and element without affecting other parts of the BPMN model. Furthermore, BPMN also allows version management. Version management is important since it enables access to older versions of the process models and to make sure that the data models and user interfaces were created with the latest process models. Especially when working with multiple team members in a concurrent project. First the file has to be named with a name which shows its contents, in this case HNO Ear Nose and Throat (ENT) diagnostic phase. Subsequently, a version number which is changed with each update. In this case after new insights from interviews or files were processed the version number was increased with 0.1 (0.5 to 0.6) and with minor updates like for instance an edit to the connecting objects improving the readability the version number was increased with 0.01 (0.6 to 0.61). After the version number some more information could be added to improve traceability. In this case the model was edited after an interview with the ENT case manager and therefore it was called ENT case manager. An example filename is shown in Figure 4.8.

Figure 4.7, BPMN readability example

(38)

Correct

It is important to the stakeholders that the model depicts their reality correctly. One way of making sure that the model (which was created after the interview) correctly displays the feedback given in the interview was to make sure that the feedback is recorded correctly. This was done by recording some of the interviews and by conducting the interview with minimal two interviewers of which one takes minutes. After the interview and the creation of the BPMN models the models were shown to the stakeholder and explained enabling the interviewee to give feedback on the model. Furthermore, using common sense possible errors in the design were addressed to the stakeholder. For instance, in a design it was modelled that whenever after the anamnesis information was requested the MDS was postponed until the information was requested. Since the MDS does not require the information as a precondition it was assumed to be incorrect. Although initially this error was not noticed by the interviewee but after addressing the possible error to the stakeholder the suspected error was confirmed and the model had to be remodelled. Furthermore the edited models sometimes led to new insights. Additionally, the validation questions described in section 3.2.2 also resulted in a validation of the models. Hence, the recording and conduction of the interviews with two people enabled the correct documentation of the feedback and in combination with a feedback session and validation questions it resulted in a correct model. Hence, the proposed model meets the goals and CSF of the stakeholders.

Trade-offs

There was one trade-off identified namely unambiguous and flexibility. In order for the models to become unambiguous the activity descriptions had to be included. When changing an activity name both the name in the BPMN and the name in the activity description has to change. When changing the location or sequence of an activity it has only effect on the BPMN model. Hence, the need to include the activity descriptions reduced the flexibility a little.

External validity

(39)

similar requirements. Also the goal of the project in other hospitals will be similar since they also have to comply to the SONCOS cycle time norm.

4.2 Overarching regulative cycle

The overarching regulative cycle has the same phases as the individual regulative cycle except that this research was only responsible for the first two phases (design problem, diagnosis/analysis) and together with Object Role Modelling (ORM) for the design solution. It will do so by first discussing the stakeholder analysis. The design problem will show the different stakeholders, their goals and Critical Success Factors (CSF). Thereafter their goals and CSF are analysed in the diagnosis/analysis phase. The design solution addresses the link between BPMN, ORM and User Interface Mock-ups (UIM).

4.2.1 Design problem

(40)

Stakeholder Goal CSF

D

ire

ct

Healthcare provider An ISB which allows cycle time measurability in a manner least affecting the current workflow

The ISB must correctly represent all relevant working processes and minimize the necessity for additional actions

Case manager An ISB which allows cycle time measurability in a manner least affecting the current workflow

The ISB must correctly represent all relevant working processes and minimize the necessity for additional actions Indi rec t HNO process manager

An ISB which can be applied in further projects for the creation of a monitoring system

The ISB must correctly represent all relevant working processes and be flexible

Principle specialist Oncology

department

An ISB which can be used to enable the measurability of cycle times

The ISB must be unambiguous on the start and end of the diagnostic phase and correctly represent all relevant working processes Information

manager

An ISB which allows the identification of necessary

improvements of the quality of- and validation of the country wide system of DCM and eMeasures

The ISB must be unambiguous on the start and end of the diagnostic phase and the relevant DCM must be identifiable

Table 4.3, Overarching cycle stakeholders 4.2.2 Diagnosis/Analysis

After analysing the CSF of the stakeholders the following quality attributes were derived. The ISB has to be unambiguous, correct, flexible, allow the identification of relevant Detailed Clinical Models (DCM), can be used for the country wide implementation of DCM and e-measures and minimize the necessity for additional actions.

4.2.3 Design solution

This report was only responsible for a limited part of the overarching-artefact and therefore not all the stakeholder criteria are met with the design solution. In this paragraph the quality attributes relevant to this research will be addressed as complete as possible.

Simple, clear, accurate, correct unambiguous and represent all relevant working processes

(41)

question. For instance after the activity anamnesis the doctor or the case manager can request information. There are no rules defined which stakeholder has to request the information. Furthermore there is no sequence or order in checking which actor is considered first. BPMN is able to deal with nondeterminism (Van Gorp & Dijkman 2013). This can be modelled using an inclusive Gateway (Inclusive Decision) which “can be used to create alternative but also parallel paths within a process flow” (Object Management Group 2015, p.291). Furthermore, “the true evaluation of one condition Expression does not exclude the evaluation of other condition Expressions.” (Object Management Group 2015, p.291).

Databases in ORM have to be deterministic in order to monitor the state of the database (Thomson & Abadi 2010; Balsters 2015). This means that the BPMN diagram has to be deterministic and should be sequential. If this would not be edited in the BPMN model the relationship between BPMN and ORM would weaken. In order to overcome this issue the BPMN model was modified to become deterministic and sequential. This resulted in the substitution of the inclusive gateway to multiple activities and exclusive gateways. This was also implemented in the user interfaces. Since the actual process at the Large Teaching Hospital in the Netherlands (LTHN) are not sequential the models differs from the actual process. An example of a change of a non-deterministic to a deterministic model is shown in Figure 4.9.

Furthermore, the model contains gateways with more than two exits. For instance, for oral surgery after the activity anamnesis there are 4 options for the flow namely; no information has to be requested, only patient data, only patient examination or both patient data and examination. These four options cannot be modelled in ORM and therefore are modelled in ORM as a three separate gateways with two exits each. A translation of this ORM model to BPMN is shown in Figure 4.10.

(42)

After validation with the end users it was found that splitting up this question into three different questions resulted in a difficult to understand UIM which stands far from the stakeholders world. Therefore it was decided to merge these three questions in the user interface into one question with 4 options. It was chosen to model this as a single gateway in BPMN with 4 exits since this is more understandable for the end-user and can still be unambiguously translated from the BPMN to the ORM models.

Allow cycle time measurement concerning SONCOS compatible with DCM and eMeasures

Furthermore, the BPMN method meets the stakeholders requirements concerning the creation of the ISB, allow cycle time measurement concerning the SONCOS norms and the countrywide implementation of DCM and eMeasures. Although the BPMN models does not completely meet these quality attributes it does facilitate reaching them. These models facilitate the creation of the ORM and UIM which in the end all together form the ISB. More information on the relation between BPMN and ORM models can be found in Ten Holt (2016) and information on the relation between BPMN models and UIM can be found in Oldenburger (2016).

Creating a blueprint for the implementation of an electronic patient database to measure cycle times in Head and Neck Oncology departments.