Building an information product for cycle time analysis:

(1)

1

Master Thesis: Technology & Operations Management

Building an information product for

cycle time analysis:

Validating the blueprint of the information product for cycle time

analysis in the Head & Neck Oncology Clinical Pathway

MSc Technology & Operations Management

University of Groningen

Faculty of Economics and Business

Msc. Student:

Rèdjinald E. A. Lichtenberg

S1955101

Supervisor:

Dr. Herman Balsters

Co-assesor:

Msc. Nick Ziengs

July 3, 2015

Abstract

A Large teaching hospital in the Netherlands (LTHN) is pressured to reduce the cycle time of its Head & Neck Oncology clinical pathway (HNOCP). However it is still a challenge to develop an information product that can record and retrieve data concerning the cycle time performance. My colleagues and

I have been given the task to create and validate a blueprint of this information product for the HNOCP. In this research paper, UI mock-ups of registration forms are created based on the process

and data models created by my colleagues to serve as a validation tool for the usefulness of the blueprint of the information product. The process and data models form the base for the building blocks of validation test in this research: the registration forms. Also, a formulation is given for the

(2)

2

Preface

In this section I would like to express my gratitude to everyone who has helped me to complete this thesis.

First and foremost, I would like to extend my thanks to my supervisor, Dr. Herman Balsters, who has helped me at every crucial part in this research with his insightful expertise.

Secondly, I would like to give a special thanks to the client of this research and the staff of the LTHN who provided my colleagues and me with great support and cooperation. Even when it looked like the research was heading for a stop, the client and staff of the LTHN still made it possible for my colleagues and me to continue with our researches with no problems.

(5)

5

1. Introduction

1.1. Changes in the Dutch health care sector

In recent years there have been radical developments in the healthcare sector in the Netherlands. Hospitals are being pressured by the municipal to specialize in specific treatment(s), to deliver a more efficient national care. This brings a few major changes in the health care sector.

Clinical pathways

Clinical pathways are becoming more and more important in health care institutions. Clinical

pathways are structured, multidisciplinary care plans used by health services to detail essential steps in the care of patients with a specific clinical problem such as head or neck cancer.(Rotter, Kinsman, James, Machotta, Gothe, Willis, Snow & Kugler, 2010). Clinical pathways aim to link evidence to practice, and optimize clinical outcomes whilst maximizing the efficiency of clinical practice of a specific treatment (Rotter et. al, 2010).

New quality norms for time performance

Coupled with the implementation of clinical pathways, new quality norms are also being set for these clinical pathways within their respective health care department. For example new quality norms have been set for the oncology care departments by “Stichting Oncologische Samenwerking” (SONCOS). SONCOS is a foundation where the interdisciplinary counsel of the Dutch professional associations of Surgical Oncology, Medical Oncology, and Radiotherapy & Oncology takes place (SONCOS a, 2015). Each year they revise the performance of the national oncology care and set new quality norms and guidelines that health care institutions practicing oncology care in the Netherlands must comply with. For 2015 new norms and guidelines have been set for the coming year (2016) (SONCOS b, 2015), that makes only specific hospitals in the Netherlands authorized to perform oncology care in the coming year. A few of these norms are set for the average cycle times of patients with a positive head or neck cancer ailment throughout the head and neck oncology clinical pathway (HNOCP). The cycle time is considered as the time it takes for a patient to go through a clinical pathway. The new norms for the cycle time of a patient through the HNOCP state (SONCOS b, 2015):

 The waiting time for the first clinical visit of a patient with a potentially malignant head or neck cancer should be within one week.

 The cycle time for the diagnosis should be within 3 weeks.

 The length of time between first clinical visit and start of the therapy is maximum 6 weeks. New Volume criteria

Finally, in cooperation with the health care foundations (such as SONCOS), the government has also set volume criteria for the various clinical pathways. This entails that health care institutions that do not comply with the volume norm of a specific clinical pathway per year must cease to deliver care for that specific clinical pathway.

Thus in a nutshell, with the centralization of Dutch health care sector (also in the oncology

(6)

6 SONCOS need to be met. Health care institutions will soon have to meet these requirements within their region / province or else they will be confronted by the government and health care

foundations. And since there is a trade-off between the quality and the volume of care given, these changes in the health sector are expected brings new challenge for the Dutch health care institutions.

1.2. New challenges for the oncology department in a large teaching hospital in the Netherlands

Due to the changes in the Dutch health care sector, a large teaching hospital in the Netherlands (LTHN) is now faced with many challenges. One of the challenges they face is to determine whether they comply with the new norms set by the municipal and health care foundations. Many

departments in the LTHN have already started describing their clinical pathways and they already comply with the volume requirement prescribed by the municipal and the health care foundations. However, it is still a challenge to accurately measure the time performance of these clinical pathways within all departments from the departments’ information systems. First of all, most of the clinical pathways are not yet accurately described. And because the clinical pathways are not yet accurately described, the underlying data in the information systems regarding the cycle time of patients must often be derived or is just unavailable. This makes the results of the measured time performance of the clinical pathways unreliable. Secondly, it is also not clear which data are required to measure the time performance of the clinical pathways. There is no standard formulation on how to calculate the average cycle time duration of patients throughout a clinical pathway. Lastly, the current data registration does not meet the requirements for data retrieval concerning the time performance of the various clinical pathways. Data concerning the time performance of the HNOCP is registered and collected from various systems, which makes it difficult to retrieve this data. Only when the clinical pathways are accurately described with the precise time stamps, then can their time performance be accurately measured with the correctly registered underlying data.

1.3. Goals of the large teaching hospital in the Netherlands

With the current data registration and average cycle time calculation, the oncology department in the LTHN measured that they currently do not meet the time performance norms set by SONCOS for the HNOCP. Of course they know that this measurement is not reliable, but they still used it as an initial indicator. Due to this indication, they aim to conform themselves in 2016 and apply the generic time performance norms set by SONCOS (2015) in their HNOCP. A delay for the implementation of the SONCOS norm is possible if the LTHN has motivated arguments for exceptional cases as to why they were not able to conform themselves in 2016. But first a much accurate method to calculate the time performance of their HNOCP must be formulated.

(7)

7 2015).These eMeasures’ content and structure are electronically documented with standard formats (algorithms) such as the Health Quality Measure Format (HQMF) developed by Health Level Seven (HL7). HL7 is a non-profit organization that develops frameworks and standards for exchange, integration, sharing and retrieval of Electronic Health Information (EHI) which supports clinical practice and delivery and evaluation health services (HL7, 2015). For an expansive explanation of DCM’s, please refer to Goossen’s paper on DCM’s (2014). And for an expansive explanation on eMeasure, please refer to the joint work of Garrido, Kumar, Lekas, Lindberg, Kadiyala, Whippy, Crawford and Weissberg (2014)

Fig.1.1. Relationships of DCM’s, building blocks, and eMeasure (Beukeboom, 2015)

1.4. Previous research on this information product

Recently, three students of the University of Groningen (R. Beukeboom, P. Martena & P. v. d. Laar) conducted a research in the LTHN to develop a method for developing eMeasures. This method contains a combination of process and data models called the “BPMN-ORM methodologyology” (Martena (2015) that also serves as the blueprint for creating eMeasures for the Electronic Health Record (EHR). The students took a systematic approach for the development of these process and data models (Beukeboom, 2015). First, they mapped the (business) process steps it takes to develop DCM’s and eMeasures (v. d. Laar, 2015), translated these process models into ontologies, and then ultimately created database blueprints (data models) for the business processes (Martena, 2015). In their research, the business processes of the active users and developers of the EHR were the main drivers and source of input. As a result they delivered a blueprint for creating eMeasures for the EHR system at the LTHN. However this method has not been validated by end users of the HER; especially by the non-technical end users that make up for the biggest group of end users of the EHR.

1.5. Team research and scope of research

(8)

8 patients spend within the HNOCP and deliver an indicator of the average cycle time performance of the HNOCP through the use of DCM’s. The value of this eMeasure should also be the same if the same calculation is done at a later moment in time (i.e. 2 to 3 years) to ensure consistency. For the scope of this research, my colleagues (N. Schriever and J. Meerman) and I will focus on the generic process when a patient first enters the hospital (with the possibility of having a malignant head or neck cancer ailment), till his/her definitive diagnostic result as shown in Fig. 1.2 (T+7 – T+28) (SONCOS b, 2015).

Fig.1.2. SONCOS norms for the Head & Neck Oncology Clinical Pathway

Thus in short, this research will contribute with validating the proposed “BPMN-ORM” method in practice, and if successful, suggest implementation of the developed eMeasure in similar processes in other departments. With the findings and results, additional insight is also offered in the processes and time performances of a (general) oncology department. Furthermore, additional insight is offered in what information the various (end) users may require for the eMeasure formulation.

1.6. Setup of individual researches

The overarching research is divided in three researches. The first part (performed by Meerman (2015)) is to map the current medical processes that a patient undergoes within the HNCOP from the first clinical visit till determining a final diagnosis. These processes are described in a Business Process Model Notation model (BPMN model). This gives an insight in where the cycle time of the HNOCP starts and ends, which is necessary for the formulation of the eMeasure.

(9)

9 Last but not least, a validation test will be designed for the blueprint of the information product. It has been decided by the LTHN that the validation test of the blueprint of the information product should be presented as user interface (UI) mockups of registration forms. Non-technical end users throughout the HNOCP can use these registration forms to check if the required data concerning the average cycle time performance of the HNOCP are correctly modeled and registered. So it will be researched whether the designed BPMN and ORM models (created by Meerman (2015) and Schriever (2015)) can be validated by the non-technical end users with the use of UI-mockups of registration forms. These registration forms are expected to serve as clear and easy-to-read

representations of the highly technical BPMN and ORM models. The non-technical end users can use these registration forms to validate the developed BPMN and ORM models created by Meerman (2015) and Schriever (2015) respectively. These registration forms should address all the building blocks (DCM attributes) required for the formulation of the eMeasure of the cycle time performance of the HNOCP. They should also be approvable by the non-technical end users. If these registration forms get approved, this means that the non-technical end users can successfully validate the correctness of the building blocks (or DCM attributes) and the effectiveness of the formulated eMeasure without in-depth knowledge of BPMN and ORM models. This last part is performed in this research paper. And, from this research, feedback is generated for my colleagues for their parts of the overarching research, resulting in an integrated validation of the proposed method for the development of eMeasures and also the blueprint of the eMeasure for the average cycle time performance of the HNOCP at the LTHN.

1.7. Goals of this research

(10)

10

2. Research Questions

As mentioned before, this research is part of a bigger overarching research to develop the desired eMeasure. The focus of this research will be on the validation of the designed process (BPMN) and data (ORM) models of my colleagues. UI mock-ups of registration forms are created to validate these BPMN and ORM models regarding the average cycle time performance of the HNOCP. And they are presented to non-technical end users for approval. Ultimately, this will deliver a validation of proposed BPMN-ORM methodology to develop eMeasures; such as for the average cycle time performance of the HNOCP in this case.

Thus the main objective that follows for the overarching research is:

In the context of the clinical pathway Head and Neck Oncology at the LTHN, we design an information product to attain cycle time analysis of that clinical pathway

The main research question for this research paper is:

To what extent is the use of registration forms suitable as a validation tool for the blueprint of the information product for the Head and Neck Oncology Clinical Pathway?

And the sub questions are:

 Who are the stakeholders for the eMeasure?

 Who are the non-technical end users of the registration forms?

 How do patients and data flow through the HNOCP?

 What are the required data in order to build the forms to determine the cycle time?

 How should the eMeasure for the average cycle time calculation be formulated?

 Do the proposed forms meet the requirements of the various non-technical end users? If not, what is missing?

(11)

11

3. Methodology

3.1. Design Science

The field of the design science focuses on solving practical-knowledge problems with a utility goal (Balsters, 2014). Design Science focuses on creating artifacts in order to transform a current situation into a desired new situation (Hevner, March, Park & Pam, 2004). Thus it deals with

practical-knowledge problems to resolve the difference in the way stakeholders experience the world and the way they wish to experience it (Wieringa, 2007). The answer to the practical knowledge problem is not about whether it is right or wrong, but if it is useful or not. It is thus evaluated with problem-dependent criteria of multiple stakeholders; just as like a useful instrument to achieve a desired goal (Balsters, 2014). However to answer a design problem, a few pure knowledge questions must be answered when describing the problem, the goals and the applying critical success factors (CSF’s). Diagnostic questions must be asked to determine the causes of current failures. Also, the proposed solution must be validated, by testing whether it satisfies the CSF’s (Balsters, 2014). Once the

practical-knowledge problem has been defined, we can proceed with the question on “How to do X?” followed by building the artifact to reach the utility goal (Balsters, 2014).

Clearly this overarching research at the LTHN is aimed at answering a design science problem. The LTHN wants an instrument (the eMeasure) to improve its current situation where the registration and retrieval of the information concerning the average cycle time in the HNOCP is not standardized, into a desired situation where they are.

Next, it is important to also determine whether the design problem is a type 1 or type 2 kind of problem. Type 1 problems entail resolving a design problem that leads to a new theory of results within the research field of the topic, while type 2 problems focus on the experimentation of building a system and validating this system and its design principles with the technical and non-technical end users or experts in the field (Balsters, 2014). So, coming back from the description of the overarching research and this particular research paper, we can determine that this design problem is a type 2 problem.

3.2. The Regulative cycle

The standard methodology for executing such a problem is by using the regulative cycle of van Strien (1997) as shown in Fig. 3.1. The cycle consists of 5 phases that will now be further explained in successive expansions. In the “Design Problem phase”, the context of the situation will be explored to determine the actual problem/ research topic. In this phase the stakeholders, goals and CSF’s are explored to grasp the gravity and complexity of the situation. In the “Diagnosis / Analysis phase”, the possible causes for the failure to meet the CSF’s are explored and also the interdependencies / trade-offs between these CSF’s. In the “Design Solution phase”, available solution components are

(12)

12 researcher must begin the cycle anew and keep repeating it, until he designs a solution that finally most CSF’s taking into account the trade-off relationships between the CSF’s (if there are any).

Fig. 3.1. Regulative Cycle of van Strien 1997

3.3. Global Regulative cycle for the overarching research

For the overarching research however, there will not be an “Implementation phase” due to the time constraints for conducting the overarching research. For this reason an alternative version of the regulative cycle will be used and performed where the design solution gets directly validated as shown in Fig. 3.2. (van Strien, 1997).

Fig. 3.2. Alternative way of the regulative cycle where the design gets directly validated (van Strien, 1997)

Now, a step by step explanation will be given on what will be done in each phase of the regulative cycle in this overarching research and also who is responsible for each phase.

(13)

13 Feedback loops

Design an information product to attain the cycle time analysis of the HNOCP Meerman (2015) focuses on the “Diagnosis/ Analysis phase” by mapping the processes of the clinical pathway in a BPMN model with all the steps and information flows shown throughout the processes. Here he analyzes what the causes are that makes it difficult to resolve the CSF’s and testing them by checking quality attributes (Balsters, 2014). Also, Meerman (2015) analyzes the order-dependency of the CSF’s to determine if there is an order in which they have to be treated to achieve a solution. Schriever (2015) focuses in his part of the research on the “Design solution phase” by converting the BPMN models created by Meerman (2015) into data models (the design artifact) (Balsters, 2014). First Schriever (2015) has to determine what type of data model is best suited to map the BPMN models into data model by reviewing literature on the subject. Next, it is up to his creative use of previous design solutions and new inspirations to come up with a solution for the current design problem.

This research paper focuses on the “Validation phase”. In this phase, I will design test methods to check whether the solution satisfies the CSF’s of the stakeholder. Possible trade-offs between the CSF’s are examined, and also the scalability of the proposed solution. Ultimately the performance of the solution is analyzed and checked whether new CSF’s emerge which will serve as the source for feedback to improve my colleagues’ parts. The test method chosen to validate CSF’s is the

representation of the required information between each activity and processes in the HNOCP concerning cycle time on UI mock-ups of registration forms. At each process or activity a registration form will be presented to the end users. These end users must mention whether the data they see on the form meet their requirements regarding the cycle time calculation. Furthermore, the activities and processes within the HNOCP occur in a sequential order. This means that there is a connection flow between the forms; you need data of the previous registration forms for the next registration forms. This connection flow between the registration forms is called the “Form Flow” in this research paper.

Thus, the activities in the HNOCP are mapped in the process models that are created by my colleague Meerman (2015). And all the required data that need to be on the registration forms are put in the data models that my colleague Schriever (2015) will create. And the registration forms are then validated by end users through interviews.

Fig. 3.4. Feedback loops between individual researches

Design BPMN models Meerman

Design ORM models Schriever

Validation of both the BPMN and ORM models with the use of forms

(14)

14

3.4. Local Regulative cycle of individual research papers

Although the three individual researches of my colleagues and mine are focused at different phases in the global regulative cycle of the overarching research, they still have their own local regulative cycle that covers the whole cycle (Fig. 3.3.). This is due to the fact that each individual research paper has to diagnose the design problem from three different perspectives; business process, data

models, end user registration forms. And since the output of one colleague is the input for another colleague, each research paper must therefore repeat the regulative cycle on a local scale to generate feedback for the other research.

The UI mock-ups of the registration forms created in this research paper are repeatedly presented to the non-technical end users of the eMeasure. They are also repeatedly asked to give feedback until they all approve of the eMeasure. These mock-ups are translated and built from the results of my colleagues’ researches. And with each time that a mock up is presented to the technical and non-technical end users, feedback will be collected to deliver to my colleagues so that they can improve their own results in their own research (Fig.3.4). This way, we can deliver an integrated overarching research.

(15)

15

4. Theoretical background

4.1. Requirements engineering

Requirement engineering is an important topic within design science. It is a system engineering discipline that deals with the requirements of the various stakeholders for a proposed design solution (Selvakumar & Rajaram, 2011). Conflicting requirements are weighed against each other according to their trade-off dynamics between each other which are also critical to the success of a project (Selvakumar & Rajaram, 2011). In other words, requirements engineering is concerned with discovering the stakeholders of a system, determining the business needs and goals (CSF’s) of these stakeholders for a design solution for the system, and documenting these CSF’s in a manner that is amenable for analysis, communication and subsequent implementation of this design solution in the system (Young, 2004). The critical success factors are ultimately important for the validation of a proposed design solution. And the requirements that define these CSF’s can be divided into two categories: Functional and Non-functional requirements (Li, Eberlein & Far, 2004). Functional requirements are the requirements that affect the functionality of a design solution and non-funtional requirements are the requirements that affect the constraints of the design solution (Selvakumar & Rajaram, 2011). Functional requirements are specific business requirements that describe what the design solution should do (Selvakumar & Rajaram, 2011). And non-functional requirements identify user or solution constraints which are characterized by features such as user friendliness, response time, etc. So non-functional requirements describe how the design solution should work (Selvakumar & Rajaram, 2011).

4.2. Validation in design research

After determining the requirements for a design solution, and creating a blueprint of the design solution, this blueprint normally gets implemented according to the regulative circle. However, as explained in the methodology, this implementation phase is skipped and the validation of the blueprint will be performed instead. Validation of design solutions in Design Science entails checking whether a design solution satisfies the critical success factors set by stakeholders (Balsters, 2014). This is also described in the paper of a guru in the design research field, Alan Hevner (2004) in collaboration with March, Park & Pam. In his paper he describes this phase as the Justify / Evaluate phase. In this phase an artifact (design solution) is evaluated to see whether it solves the identified organizational problems. The evaluation of the artifact then provides feedback information and a better understanding of the problem for the “Design Problem” phase and “Diagnosis / Analysis” phases of the regulative cycle. This evaluation also provides feedback or the improvement of both quality of the product and the designing process in the “Design” phase of the regulative cycle (Hevner et. al, 2004). This build-and-evaluate loop is typically iterated a number of times before the final accepted design solution is created (Hevner et. al, 2004). During this creative process, the design-science researcher must be cognizant of evolving both the design process and the design solution as part of the research (Hevner et. al, 2004).

Questions that need to be answered during the validation phase are the following according to Balsters (2014):

(16)

16 4. How well does the solution perform?

5. Have we encountered new CSF’s in the result of the implementation?

4.3. Business Process Model and Notation (BPMN)

My colleague, Meerman (2015), will perform the translation of the HNOCP into a BPMN model as the first part of the research. BPMN is a language for process modeling, which makes it possible to map processes and increase the level of standardization in organizations. BPMN has become the standard for graphical process modeling and is now also an internationally accepted ISO standard for graphical modeling of business processes (Recker, 2010; Chinosi & Trombetta, 2012). BPMN is also widely used because it is easy for non-technical end users and IT’ers to understand a process modeling research. Basic elements of BPMN are flow objects, data, connection objects, pools, swim lanes and artifacts as seen in Fig.4.1. (Balsters, 2014; Object Management Group, 2011). Flow objects can be activities, gateways and events. They define the behavior of a business process (Chinosi & Trombetta, 2012). Data can function as either input or output of an activity and is expressed in four elements: Data Objects, Data input, Data Output and Data Stores (Object Management Group, 2014). Connection objects are used to connect the objects in the BPMN. There is a connection for Sequence Flows, Message Flows, Associations and Data Association (Object Management Group, 2014). Pools help to show a process where the stakeholders are represented in their designated Swim Lanes (Object Management Group, 2014). And artifacts (group and text annotations) can be used to provide additional information about the process (Chinosi & Trombetta, 2012). For more information about BPMN, please refer to the papers of Chinosi & Trombetta (2012) and Meerman (2015).

(17)

17

4.4. Object-Role Modeling (ORM) models

My colleague, Schriever (2015), will be performing the translation of the BPMN model developed by my colleague Meerman (2015) into data models. The BPMN models need to be converted into an ontology which will be used as a knowledge base to develop the database blueprint for the BPMN models. These ontologies will be used to model the business domain according to one of the three database modeling approaches Entity-Relationship Modeling (ERM), Object-Role Modeling (ORM), and Unified Modeling Language (UML) (Noy and McGuinnes, 2001). Since we are validating the BPMN-ORM methodology for this team research, we will ignore the Entity-relationship modeling and the Unified Modeling Language, and expand more on the Object-Role Modeling.

According to Halpin and Bloesch (1999), Object-Role Modeling (ORM) is the most popular fact-based approach to data modeling to date. It is a semantic modeling approach that views the world solely in terms of objects (things) playing roles (parts in relationships). A relationship is shown as a named sequence of one or more role boxes. Each of these relationships is connected to the object type whose instances play that role (Halpin & Morgan, 2008). An example of an ORM diagram is shown below in Fig. 4.2.

Fig. 4.2. Example of an ORM model about academics, in what department they work, what subject they teach, the degrees they were awarded with, in which year they got awarded, and at which university. Furthermore the credits for the subjects are also modeled.

Facts are expressed by objects playing roles and this can lead to large diagrams, and this happens often. But due to this attribute-free approach some advantages come along for conceptual analysis. This entails advantages such as simplicity, stability, and ease of validation (Halpin & Morgan, 2008). Another advantage that Halpin and Morgan (2008) note, is that because of the fact that ORM schemas are specified in unambiguous sentences backed up by illustrative examples, it is not

(18)

18 Another drawback of fact-based modeling (FBM) specified in ORM schemes is that it is it appears to be hard to communicate these ORM schemes to software engineers using UML. However, Balsters & Doesburg (2012) offer an easy translation from the fact-based modeling (FBM)-specifications to UML class diagrams. For more information regarding ORM modeling, please refer the literature mentioned in this section.

4.5. Cycle time calculation

Hopp & Spearman (2011) define cycle time as the average time from the release of a job at the beginning of a routing until it reaches an inventory point at the end of the routing. Of course this definition is used more for manufacturing processes. In this research it is considered as the length of time from the instant when the patient enters the hospital for a first consult till the determination of his / her diagnosis. Thus for the calculation of cycle time, we need either both the begin time of the first process and the end time of the last process, or the accumulation of the cycle times of all process steps together from the first process till the last process. If done correctly, both ways of calculation should deliver the same result. With this in mind, the easiest way to calculate the cycle time is by executing the first way. The only reason why the second way of calculation would be chosen is because it offers insight into the bottleneck of the process. Thus a more specific analysis of the time performance of the process can be done with the second way.

4.6. User Interface

A user interface design is a subset of the field of study “human-computer interaction” (HCI) (Galitz, 2007). It is the study of how people and computers work together so that a person’s needs are satisfied in the most effective way possible (Galitz, 2007). An HCI designers must consider a variety of factors such as what people may want and expect, what physical limitations and abilities they

possess, and how their perceptual and information processing systems work (Galitz, 2007). A user interface has generally two components: input and output. An input is how a person communicates his needs or desires to the computer. Output is how the computer conveys the results of its

computations and requirements to the user (Galitz, 2007). So it is clear that proper interface designs will provide a mix of well-designed input and output mechanisms that will satisfy the user’s needs, capabilities, and limitations in the most effective way possible.

There are many interaction styles of user interfaces. An interaction style is simply the methods by which the user and the computer communicate or interact with one another (Galitz, 2007). Currently there are several interaction styles that a designer can choose from to create a user interface. The choice of an interaction style is based on the product that has to be developed and the

characteristics of the input and output devices and methods to be used for the interface (Galitz, 2007). A brief description of these interaction styles will now follow and a summary of their advantages and disadvantages can be found at the end of the descriptions.

Command Line

(19)

19 command lines is that they must be remembered and they test the user’s power of recall. No clues about what commands are available exist on the screen (Galitz, 2007). Another problem is that command lines can be cryptic and obscure with complex syntax (Galitz, 2007). They are also very prone and intolerant of typing error that can lead to user frustration (Galitz, 2007).

Menu Selection

A menu is a set of options or choices from which a user must choose. The user selects a choice with a pointing device or keystroke on screen. Some kind of visual feedback is then typically provided to indicate the options selected (Galitz, 2007). Menu selection can also be provided by voice as exemplified by “Press 6 to confirm…” encountered after telephone calls to a business or an

organization. Screen menus are advantageous because they utilize a person’s much stronger power of recognition and not recall (Galitz, 2007). However, menu choice labels must be meaningful and understandable for the menu to be truly effective. Otherwise speed of use will be degraded and errors increase (Galitz, 2007). Menus can break a complex interaction into small steps to provide structure and aid the decision making process. This is helpful for infrequent users who are unfamiliar with the system. On the other hand, many small steps may slow the knowledgeable user (Galitz, 2007). Techniques however are available to overcome these problems for the expert.

Form Fill-in

The form fill-in style is very useful for collecting information (Galitz, 2007). Typical form-structured screen contains a series of controls or fields into which the user either types information or selects an option, or options, from a list of choices. An advantage of a form is its familiarity. If it is designed well, a form will aid the user in understanding its purpose and allow fast and easy entry of

information. Conversely, a poorly designed screen form can be inefficient and aggravating to complete (Galitz, 2007).

Direct Manipulation

A direct manipulation interface enables the user to directly interact with the elements presented on screen (Galitz, 2007). These elements are called objects and they replace the keyed entry of

commands and menus. Instead of keyboards, users typically select screen objects and actions by using pointing mechanisms, such as the mouse or joystick (Galitz, 2007). They navigate the screen and execute commands by using menu bars and pull down menus (Galitz, 2007). This mostly means that the users can only input features that are available on the system.

Anthropomorphic

(20)

20 In Table 4.1, on the next page, there is a summary of the advantages and disadvantages of each interaction style.

Table 4.1. Advantages and disadvantages of the different user interface interaction styles (Galitz, 2007)

4.6.1. Chosen interface interaction style for this research

(21)

21

interaction style that requires minimal training and offers simplified information entry.

These characteristics will definitely aid in the validation of the forms, which also assumes a

validation of the BPMN and ORM models.

4.7. Forms: framework for developing forms and the usage of forms as a validation tool

Literary searches were done on form design, and form creation and form development, but unfortunately no articles could have been found regarding this specific topic. There are academic papers about elements found on forms such as in the book of Galitz (2007) but yet nothing about a framework for developing one were found in them. This is also the case on the topic of forms being used as a validation tool. Apparently a validation of a design has never been done through the use of forms. So not only are there no academic paper about a framework on how to make forms, there is also no academic papers about using form as a validation tool. Maybe this due to the fact that “forms” is an ambiguous word, and unfortunately there is not another synonym for registration forms that could also be used. This might have made it hard to find articles about forms even if they exist. This means that the forms created in this research will be the result of pure creativity and improvisation. And the use of these forms as a validation tool may become a novel test method in the research field of validation tools

4.8. Software programs to develop form

(22)

22

5. Results

In this chapter, the local regulative cycle will be performed for this research. This means that first a design problem will be brought to light, followed by an analysis regarding the relevant information for this separate research. Then, an in-depth explanation on the process of creating the design solution is given, followed by the validation and the academic findings of this research and the overarching research.

5.1. Design Problem: Stakeholder analysis

As said before, registration forms will be created in this research to validate the work of my colleagues and thus also to validate the proposed method to develop the eMeasure for the calculation of the average cycle time in the HNOCP between T+7 –T+28. In order to do this, first an analysis of the stakeholders and their goals, and CSF’s for this research must be done. It is important to note that big part of this stakeholders’ analysis overlaps with the stakeholders’ analysis of my colleagues in their research. But, seeing how we are all individually focused on one specific part of the overarching research, other stakeholders, goals, and CSF’s may be implicated per stakeholders’ analysis. The stakeholders of this research and their goals are shown in Table 5.1. To gain insight in the stakeholders’ analysis of my colleagues, you can refer to their individual research papers (Meerman, 2015; Schriever, 2015).

Stakeholders Goals CSF’s: Functional Requirements CSF’s: Non-Functional Requirements Internal stakeholders DCM and eMeasure developers HNOCP process managers Healthcare providers at the LTHN Client (initiator of research) Validated method of developing eMeasures.

Verified modeling of the HNOCP process & formulation/ calculation of the cycle time

Verified modeling of the HNOCP process

Validated eMeasure for calculating cycle time performance of the HNOCP

The forms shall validate the BPMN-ORM methodology

The forms shall give overview in the processes and activities of the HNOCP regarding cycle time performance

The forms shall register the task accountability of cycle time performance throughout the HNOCP

The forms shall register the information to formulate the eMeasure Reliable, precise, clear and easy to understand, Precise, clear and easy to understand Clear, precise, easy to understand and easy to use Validated (and if possible approved) by end users External stakeholders SONCOS and government Patients

(Average) cycle time result

Accountability review of

The form shall register cycle time performance of the HNOCP

The forms shall register the

Precise

(23)

23 IT specialists

HL7

length of cycle time

Validated blueprint for the eMeasure

Validated method for developing eMeasures and a validated

eMeasure for

calculating cycle time performance of the HNOCP

accountability of cycle time performance

The forms should validate the blueprint of the eMeasure The forms shall register the information to formulate the eMeasure easy to understand Validated by end users Validated (and if possible approved) by end users

Table 5.1. Stakeholders’ Analysis

5.1.1. Description of internal stakeholders, their goals, and CSF’s

DCM and eMeasure developers: This is a group of people specially formed at the LTHN to develop DCM’s and eMeasures for specifically the Electronic Health Record. This is also the same group of people that has worked with the previous group of students from the University of Groningen in 2014. The goal of the DCM and eMeasure develops is to develop and implement a validated method on for creating DCM’s and eMeasure. In this research, the proposed BPMN-ORM methodology will be put under validation tests to prove whether it is effective for the goal of the DCM and eMeasure developers. This proposed BPMN-ORM methodology must thus be presented in such a way that it is friendly enough for the non-technical end users. With this is mind, the DCM and eMeasure

developers would like for the registration forms to be clear and easy to understand, reliable and precise.

HNOCP process managers: These are the employees at the LTHN that manage the HNOCP. They are tasked with aligning and organizing the processes throughout the HNOCP and they also keep an eye on how data and information are registered in the various systems currently still used in the HNOCP. The HNOCP process managers require that the regiistration forms give a clear overview of the processes and activities throughout the HNOCP affecting the cycle time performance of HNOCP. This means that the processes in the HNOCP must be well modeled in the BPMN models and the

information regarding the cycle time in the ORM models. For the non-technical end users to be able validate the BPMN and ORM models, the forms are required to precise, clear and easy to

understand.

(24)

24 Clients (initiator of research): This is the task employer for this research. He desires an accurate formulation for the eMeasure to accurately give a performance indicator to the government and SONCOS regarding the average cycle time of the HNOCP. For him the registration forms should register all the necessary information throughout the HNOCP to formulate the eMeasure for the cycle time performance. This is why, he requires that that registration forms must be validated by the non-technical end users and if possible also be approved. If approved this means that a validated eMeasure can be proposed in practice.

5.1.2. Description of external stakeholders, their goals, and CSF’s

The external stakeholders that are going to be described are not directly stakeholders of this research, however they will benefit from this research indirectly.

SONCOS and government: As mentioned before the government and SONCOS are not direct stakeholders of the forms or the whole overarching research. However, since the result of the

overarching research will serve as the tool to accurately report to the government and SONCOS, their requirements for a precise indication for the cycle time performance is incorporated in the

registration forms.

Patients: For the patients going through the HNOCP it is important that an accurate registration is done of the length of time they underwent at every process step. It is thus also important to register the health care providers involved at every process step. This way accountability could also be enforced if needed. Thus the forms must register the accountability and the cycle time performance of the HNOCP. For these reasons, the patients may require that the forms are precise, clear and easy to understand.

IT specialists: If the LTHN ever decide to outsource an IT-company to develop a system that incorporates the eMeasures and DCM’s, it might be useful for the IT-company to use a validated method to develop eMeasure and DCM’s with the BPMN-ORM methodology. This can lead to the higher chance that a system design created by the IT-company can be accepted by the LTHN. Since this has never happened before, the results of the overarching research might change this current situation.

HL7: As explained in the introduction, HL7 is a non-profit organization that develops frameworks and standards for exchange, integration, sharing and retrieval of Electronic Health Information (EHI) which supports clinical practice and delivery and evaluation health services (HL7, 2015). They try to give formulated eMeasures that health care institutions can use in their information systems. Seeing how the overarching research is focused on developing an eMeasure by validating a methodology of developing eMeasures, the HL7 can benefit from the knowledge accrued from the overarching research for future development of more eMeasures.

5.2. Design analysis/ Diagnosis

(25)

25 also briefly explained to gain basic understanding as preparation for the creation of the registration forms.

5.2.1. Determining the begin and end time of the cycle time

According to Hopp & Spearman (2011), the calculation of the cycle time is defined by the begin time of the first process and the end time of the last process. From the information gathered through interview with the process managers of the HNOCP and documents from SONCOS, we could assume that the begin time is (as expected) at the moment a patient checks in for his clinical appointment. In the BPMN model of Meerman (2015) (Fig 5.1 & Appendix A), this is shown by the green dot on the left. For the end time however, there are different definitions from the various stakeholders. In the document of SONCOS, the end time is said to be reached when the definitive diagnosis of a patient is finalized. However within the LTHN, the cycle time seems to be determined at the end of the

“diagnosis fase” (diagnosis phase), which is also at the beginning of the first treatment of the patient. It had been discussed with the LTHN that their definition entails more time than just the cycle time for determining the diagnosis; it also entails the preparation of the treatment plan and preparation of the first treatment. So be more consistent with the definition of SONCOS, it has been agreed with the LTHN that the final diagnosis of a patient is assumed to be determined during the MDO activity modeled in the BPMN of Meerman (2015) (Fig 5.1 & Appendix A); during the MDO activity multiple specialists discuss patients’ cases to determine their diagnosis. So the end time of the cycle time of the process is at the end of the MDO activity. Furthermore, it is specified in the document of SONCOS that only the patients with a positive diagnosis should have been diagnosed within three weeks.

Fig. 5.1. Cycle time indication of the HNOCP (Meerman, 2015).

5.2.2. Proposed way of calculating the cycle time

(26)

26

5.2.3. Results Schriever briefly explained

Next the results of Schriever (2015) are briefly explained how they were created. At every activity in the BPMN model of Meerman (2015), Schriever (2015) mentions the data required for the

calculation of the cycle time. These data were acquired from the interviews my colleagues and I held with the process managers of the HNOCP. There was no need for any interviews with the healthcare providers themselves; because these healthcare providers follow the policies created by the process managers of the HNOCP themselves. Within the results of Schriever (2015), the begin time and end time of each activity must be modeled in the ORM models. Also the people responsible for each activity should be modeled. These were all done according to the ORM method Schriever (2015) explained and followed throughout his research. The resulting ORM models of Schriever (2015) can be found in Appendix B and an example of one of them is shown in Fig. 5.2.

Fig. 5.2. Example of an ORM model (Schriever, 2015)

5.2.4. Design Solution: Creating the registration forms

In this section, the creation of the registration forms will be explained. It is highly important to take into account that the registration forms were made out of pure creativity and improvisation.

As the first step, I used the BPMN model of Meerman (2015), to get an overview of the activities that takes place within the HNOCP. Then I’ve decided to create a registration form for every flow object in the BPMN model of Meerman (2015). It seems logical to me that a registration form is used at every activity to register the cycle time performance. Just like in practice when a company gives clients surveys to review their satisfaction on the performance. Since it has been determined in paragraph 5.2.1 that the diagnosis of a patient is determined during the MDO meeting, this means that no forms will be created for the BPMN process “Construct Treatment Plan”. This falls outside of the scope and goal of this project.

Now it is important to determine what information question fields are needed to be on the

(27)

27 types (information) regarding the cycle time performance is modeled in these ORM models. These fact types are assembled on a registration form as a list of required fields an end user must fill in for the registration of the cycle time. So, in other words, the fields on the registration forms are a reflection of the fact types modeled in the ORM models.

Two types of registration forms will be created; static forms and dynamic forms. Static forms are the registration forms that end users have to fill in static (input) data regarding the cycle time

(28)

28

(29)

29

Fig. 5.4. Example of a dynamic form

5.3. Calculating the cycle time

(30)

30 the DCM and eMeasure developers at the LTHN they confirmed this flaw of the DCM’s but assured that there is no need for a DCM attribute to keep record of the begin time of the preliminary diagnosis or the link between the preliminary diagnosis and the MDO conduction. This is due to the fact that DCM’s are not databases. They are concepts that will be stored in a database after the information system has been completely developed. When this happens, the database will keep track of all of the number of preliminary diagnosis and MDO conduction automatically. And for this database, queries can be executed to calculate the average cycle time of the HNOCP. This is the reason why Schriever (2015) added the derived fact types “cycle time” and “accumulated cycle time” to his ORM models. Because, even though the eMeasures are formulated with DCM attributes, utimately the data in the database for these DCM’s will be used to execute the query. For this reason, it is stated in this research that the query formulation to calculate the cycle time is: For all the MDO conduction number with a positive diagnosis for a head or neck cancer, the accumulated cycle time calculated at the MDO conduction determines the length of the cycle time of that patient throughout the HNOCP. Interestingly enough, this is exactly the second way of calculating the cycle time as described in the theoretical background of cycle time in paragraph 5.4. So it is even possible now to determine the bottleneck activity of the whole process. For these positive MDO results a dynamic form has been created to show a clear overview of them. This registration form is called “Finalized Diagnosis (Derived)”.

5.4. Validation

Both of the results of my colleagues were validated with the use of the forms created in this research. Due to time constraint, it was not possible to validate the forms with the help of the intended end users (health care providers). So instead we used the eMeasure and DCM developers as substitute end users to validate the forms, based on their experience with developing eMeasures and DCM with the input of the health care providers and their non-familiarity with technical subjects. While creating the registration forms, a few mistakes have been found in the BPMN model and the ORM models of my colleagues.

5.4.1. Findings in BPMN model Meerman (2015)

Apparently, there is an activity (flow object) missing in the BPMN model of Meerman (2015) after the flow object “Request Additional Information”. Basically a request is sent, but there is no flow object afterwards to model that someone provided the information and send it back to the main health care provider for him to decide whether the information is sufficient or not. For this missing activity, a registration form “Supply of Additional Information” has been created to complete the BPMN model and form flow. This registration form can be found in the appendix with the same name. Secondly the last to decision gateways of the BPMN model is modeled in the wrong lane. According to the description of the process managers of the HNOCP, the final diagnosis of the patient takes place at the MDO. This means that the group of medical consultants at the MDO meeting is

responsible for determining the final diagnosis and not the main health care provider. Or the last two decision gateways should be in the “MDO” lane.

5.4.2. Findings in ORM model Schriever (2015)

(31)

31 providers that are also invited to the MDO meeting. Lastly, in the ORM model “Specialism

Allocation”, Schriever (2015) also did not model the needed specialism for the MDO meeting. All of these missing objects have been included in the forms for the completion of the ORM models and form flow.

5.5. Academic findings: Discovered general method / pattern of creating forms out of BPMN-ORM methodology

While making the registration forms, I have started realizing a pattern or emerging method in creating the registration forms. In this chapter, I will explain this method step by step and also give pointers and examples on how to perform this method the best way possible.

5.5.1. Step 1: Defining the title and subtitle/description

The title:

As mentioned before, at each BPMN flow object a registration form is created. The title of a registration form is the name or a reference to the name of the respective BPMN flow object. This reference should not be a big departure from the original BPMN flow object name, but it should give the title a more natural name if the BPMN flow object has an unclear name (i.e. “MDO application” instead of “Submit patient for MDO”). Sometimes, the ORM model of the flow object might also have a more natural name for the BPMN flow object that could be used as the title of the registration form.

For nested flow objects the title should reference the sub-flow object within the nested activity. This is done by mentioning the name of the nested flow object and the name of the sub-flow object with a hyphen (“-“) in between the names. The title is thus written as follows: “Name of the nested BPMN flow object – Name of the BPMN sub-object flow”. Take the process “Supply Data” as an example. It is the sub-flow object of the nested flow object “Conduct Preliminary Diagnosis”. The registration form for this BPMN flow object is called “Preliminary Diagnosis Conduction – Data Supply”. As you can see, both of the names of the flow objects have been referenced in a more natural way, and the name of the nested flow object is followed by a hyphen and then the sub-flow object.

The subtitle / description:

The subtitle can be used to give a clearer description of the purpose of the registration form than the title can give. This can be a description of the flow object or description of the goal for the

registration form. This way, an end user may have fewer questions why it is important to fill in the registration forms.

(32)

32

Fig. 5.5. Process of defining the title and subtitle / description. Orange lines mark the title and green line marks the subtitle/ description.

5.5.2. Step 2: Defining the fill-in question fields on the forms and their format.

Defining the question fields:

Defining the fill-in question fields on the registration forms is mostly done with the ORM models. The question fields on a registration form should reflect all the non-derived fact types linked to the fact type referenced to the BPMN flow object where the form will be used. The fact type referencing the BPMN flow object is also included on the form as an identifier. And again, same as by step 1, you can give the question fields a more natural and descriptive name. For example instead of naming the question field “Instant” (which is an ambiguous name),you can name the question field “Begin Time” or “End Time” which is much more clear and useful . How this looks in Google form is visualized in Fig. 5.6.

Fig. 5.6. Process of defining the question fields. Green line mark the question fields (to be) included on the form

(33)

33 Start events:

If the start event and the next BPMN flow object have no time difference between them, then the fact types linked to the start event can be included as question fields on the registration form of the next BPMN flow object. This was not done in this research at the BPMN process “Conduct

Preliminary Diagnosis”, because the fact types linked to the start event in the ORM model were not modeled in any ORM model regarding the conduction of the preliminary diagnosis. So only if the modeled fact types of the start event are also modeled in the ORM model of the subsequent BPMN flow object, then you can include the fact types of the start events as fields on the registration form for the subsequent BPMN flow object. This means that a registration form for start events might be redundant and should be avoided if this is the case.

End events:

An end event never adds new information as input for a next BPMN flow object and an end event is always the result of the previous BPMN flow object. For this reason, it is suggested that the

registration forms of the end events should always be dynamic and giving an overview of the relevant / desired information of the result. This has been done in this research for the dynamic forms “Stop Events” and “Finalized Diagnoses”. These two forms show the diagnosis result of a patient; either positive or negative with a description.

Decision gateways:

If a decision is taken during an activity, then the fact types regarding this decision can be included on the registration form of that activity. This has been done in this research on the registration form “MDO conduction”. If a decision is made after an activity, then that decision making process should be looked at as another BPMN flow object that requires time to be completed. And since the objective of this research is to determine the time performance of the HNOCP, this decision making process also needs to be reviewed as a flow object in the BPMN model. This is done for the

registration forms “Oncology check” and “Oncology and Information Check”. The registration form “Oncology and Information Check” represents the two decision gateways after the BPMN flow object “Conduct MDS”. Since they both occur at the same time, they can be included on the same form. With all of this, it means that a registration form for a decision making process might also be redundant, just like with start events. These registration forms can be found in Appendix C.

*For dynamic forms: The same previous steps are done for the dynamic forms as well, but with a few exceptions: The dynamic forms should only display the purposeful desired information. These are the fact types referring to the current BPMN flow object and the derived fact types in the ORM model of the current BPMN flow object. These registration forms can also be found in Appendix C.

Assigning format:

(34)

34 answer from a list and for Checkbox questions where you can choose from multiple options at one question. The checkbox question however, was not used on any forms in this research. For Single Entry Text and Number questions, a fixed sized “text box” format is assigned. These text boxes for Single Entry Text and Number questions are recognized as the text boxes that do not change size or provide a scroll bar if the text is longer that the text box itself. For these fixed sized text boxes, a designer can also assign a maximum of characters that an end user can use in the fill-in space of the question. More on how this is done will be explained later on. For Multiple Entry Text and Number questions, a “paragraph text box” format is used to register the long(er) answers of an end user on a question. In contrast with the fixed sized text boxes, these text boxes do grant a scroll bar or change size if the answer text is longer than the initial text box itself. Remaining formats are the “scale” format and the “grid” format. These are mostly used for Estimation questions. However, this type of question has also not been used in this research. How this is done in Google Forms is shown in Fig. 5.7.

Fig. 5.7. Assigning the format. Orange box shows format option on Google Forms.

5.5.3. Step 3: Assigning data validation and question requirements.

Data validation:

(35)

35 the end user can fill in names, codes, and even a description of the relevant subject. You can even assign the data validation that the text may or may not be an email address, URL, etc. You can also assign the data validation that the text may or may not contain specific words. And also you can assign the data validation that an expression may or may not match a specific expression. Thus, data validation for textual answers, include the acceptance of both text and number characters in the answer. But there might be questions where this is not desired and can be change dependent on the goal of the question.

For example, the questions regarding number of iteration for a business process can be assigned the data validation to only accept answers that are made completely out of number characters with no of text characters (i.e. “MDO Preparation Number 5273365” instead of “MDO Preparation Number H876R97”). You can also make sure that the numbers are higher than 0 by assigning this value also as a data validation. Number of iteration for a business process like this is usually higher than the number 0, because it is uncommon for an iteration of business process number lower than 0. However if this ever were to be the case you can assign the data validation that the answer does not have to be higher than any number. Where this can be done on Google Forms is visualized in Fig. 5.8.

(36)

36 Question requirements:

Sometimes registration forms may have some fill-in fields that do not require to be filled in. On the other hand, sometimes an end user is not allowed to continue with the following registration form if he did not answer the required questions on the current registration form. To make sure that this happens, a form designer can assign a requirement to the most important questions. On Google Forms, this is done simply by checking the “Required question” box below the editing window of a question next to the “Done” button. This is visualized in Fig. 5.9.

Fig. 5.8. Assigning requirement to questions. Orange line marks the box to assign the question requirement

5.5.4. Step 4: Defining the Form Flow.

(37)

37 definition step when all the forms have already undergone the previous three steps in the previous paragraphs. This step is visualized in Fig. 5.9.

Fig. 5.9. Defining the form flow. Orange lines marks where the form flow can be defined dependent on the multiple question options. And the green line mark where the form flow can be defined at the end of a page.

5.5.5. Step 5: Review, styling, validate

After completing the previous 4 steps, you need to review them for any mistakes by running a demo test run of the forms. Then you can assign the registration forms a form style to make the experience while using the registration forms pleasing for the end users. Afterwards you present these

(38)

38

6. Discussion

In this section, an expansive reflection will be done on the research and the BPMN-ORM methodology. And finally suggestions will be given for future research.

6.1. Reflection on research

The reflection on the research is divided in three parts. In each part, my experience, thoughts or opinions are given about the topic.

6.1.1. Research case

Initially, this research was meant for the Electronic Health Record (EHR). The idea was to develop an eMeasure for calculating the cycle time of a patient through a clinical pathway. The HNOCP was the clinical pathway that we got assigned to. If successful, the developed eMeasure was intended to serve as a basis for the calculation of the average cycle times of other clinical pathways in their own respective eMeasure. This kind of research has never been done before, so this means that the overarching research was primarily a pioneering project. This is evident in the amount of research there had to be done in the form of academic literature reviews, interviews, two-weekly meetings with internal stakeholders, frequent discussions with the internal stakeholders and most of all testing out a method that has never been used before. This method had to be explained into the smallest detail possible because of its novelty, especially at the validation phase. BPMN and ORM are amply explained in literature. But the usage of forms as validation test to represent the BPMN and ORM has not yet been introduced in literature until now.

6.1.2. Limitations

At the start of the overarching research, everything was set and ready for commencement, until the unexpected discontinuation of the EHR. This discontinuation brought several problems with it that had ultimately negatively affected the available time to conduct the whole research. With the discontinuation of the EHR, the availability of the team of experts became very low, because these workers were placed back into their old departments where the schedules rarely aligned with each other to allow an in-depth interview or meeting amongst us (as research team)and them (as stakeholders). With this in mind, it was no longer possible to fully perform the validation phase by letting the intended end users (the health care providers) validate the forms as explained in paragraph 5.4. Especially with the overarching research being a set of three individual researches that were mostly performed sequentially based on their input/output dependency of research data and information. We have however tried to perform the three researches simultaneously providing immediate feedback to each other concerning the creation of the BPMN and ORM models. But despite our best efforts, there were still a lot of time that went wasted on waiting for appointment with stakeholders to collect research information. Especially at the first stages of modeling the BPMN model. Also during the creation of the ORM models there were much time lost when more feedback were received regarding data requirement during the two-weekly meetings. The ORM models had to be completely renewed which also took time to be completed.

Building an information product for cycle time analysis:

Master Thesis: Technology & Operations Management