1
“Polibak revisited: a collaborative process redesign”
Master thesis, MScBA, specialization Business & ICT
University of Groningen, Faculty of Economics and Business
Date: 03-01-2012 Mark Bruinsma Student number 1849727 Zonnebloemstraat 53 8441 CS Heerenveen m.bruinsma@student.rug.nl Supervisor/ university Prof. Dr. H.G. Sol Supervisor/ field of study
Dr. J.S. van Os
2
Abstract
The goal of this research was to redesign the process of the digital polibak in order to avoid the problems that occurred. Like a lack of overview and confidence regarding patient data, when the first version of the digital polibak was introduced together with the implementation of the EPR at the policlinic Cardiology. Without any proper research the hospital copied the old working processes into a digital format. A few weeks after the introduction of the digital polibak the staff noticed flaws in the system with patient data not being presented properly, critical data for the treatment of the patients were missed. It resulted in the reintroduction of the old paper based polibak. To avoid similar
problems a collaborative business engineering process redesign techniques was used to reintroduce the digital polibak without the former introduction problems. The current (AS-IS) situation was observed and a process diagram was made of the polibak workflow. During a collaborative session at the data-lab of the RUG a multidisciplinary team, with representatives from the major stakeholder groups at and around the policlinic, problems were described and their possible solutions were discussed. The proposed solutions were entered in a TO-BE process diagram and using iGrafx simulation software it was shown that a statistically significant reduction of time needed to handle the polibak could be achieved. Problems regarding the ‗trigger function‘ of the old paper files were described and solutions were proposed during the collaborative process. The collaborative business engineering is an efficient way to solve problems at the policlinic while at the same time support for the solutions is created.
Keywords: EPR, healthcare, collaborative business engineering, back office
Acknowledgement: I would like to thank all the workers at ‗de Tjongerschans‘ hospital that
3
Contents
1. Introduction ... 5 1.1. Initial motive ... 5 1.2. Problem statement ... 6 1.3. Research question ... 7 1.4. Sub-Questions ... 7 2. Literature review ... 82.1 Process redesign literature ... 8
2.2 Simulation literature ... 15
3. Analysis ... 16
3.1 Approach ... 16
3.2 Data collection for analysis ... 20
3.3 Simulation ... 21
4. Analysis ... 23
4.1 Process & problem description ... 23
4.2 Collaboration session (GSS) ... 34
4.3 Solutions to the problems ... 40
5. Simulation ... 44
5.1 AS-IS model validation ... 44
4
Abbreviations and terminology
AS-IS Current situation BE Business Engineering
CBE Collaborative Business Engineering ECG Electro Cardiogram
Echopac® An application where echo results and images are stored. EPR Electronic Patient Record
EZIS The EPR and hospital information system software used by hospital De Tjongerschans GSS Group support systems
HRM Human Resource Management
Holter Long term (24 hours) mobile ECG recording iGrafx Program to create simulations
Medical viewer
Scanned documents are being stored using this program. Accessible at the patient level of EZIS
5
1. Introduction
1.1. Initial motive
The use of Information Communication Technologies (ICT) is growing in the last decade. More recently, ICT is becoming integrated in healthcare organizations (Cruz-Correia et al. 2005). One example of this development is the implementation of the Electronic Patient Record (EPR) in hospitals in the Netherlands. The benefits of the EPR can be categorized as better accessibility, higher quality and up-to-date patient information (Gillette, Bill. 2006). As a side effect, the possibilities for downgrading staff are mentioned.
Research has been performed on the adoption of the EPR, mostly using case studies (Oborn, E et al. 2011 & Blegind J.T, Aanestad, M. 2007). Integrating the back office in the EPR environment and its business implications within a healthcare organization has hardly been researched and is the main focus of this thesis. One study shows that investments in back-office ICT infrastructure and
automation could reduce costs for hospitals and could improve efficiency (McDowell, J et al. 2010). To gain an understanding of the consequences for the back office in the medical sector after the implementation of ICT solutions, lessons can be learned from other sectors. In the banking and finance sector research has been performed on optimizing their back office using ICT solutions (Webb, C. 2005.). Cost reduction, efficiency and outsourcing are the three main topics this research focuses on. Standardizing back-office procedures in order to reduce duplications, cutting costs and enabling speedier and more responsive interaction with customers are other topics. The expectation is that those former topics are just as important and applicable for healthcare organizations. There is however a big difference between the ICT implementation motives in health care compared to other sectors. Where cost reduction and efficiency in the back office may be the primary force that drives ICT solutions in other sectors, in healthcare it is mainly a secondary result after introduction of the EPR in the primary process (the treatment of patients).
6 redesign will be performed in close collaboration with the different working groups at the policlinic to fit their new electronic and paperless environment. This thesis contains a redesign of the back office of the policlinic.
Several authors (Davenport, T. 1990, Harmon, P. 2007 and Tarantino, D. 2003) have researched the concept of process redesign and created several steps to be followed in the process. An approach developed at the Delft University of Technology is dynamic modeling. This approach focuses on evaluating possible organizational changes and IT applications (Vreede, G.J et al. 1996) and has been used and refined in several research projects (Sol, H.G. 1992).
1.2. Problem statement
After the introduction of the EPR (Electronic Patient Record) at the Cardiology department of ‗de Tjongerschans‘ Hospital in Heerenveen in April 2011 unexpected problems occurred. The
implementation of a total paperless environment created a resistance among several workers. An ICT solution by which the staff could monitor the status of pending examinations or results (polibak) was simultaneously introduced with the EPR (Digital Polibak). This introduction resulted in some unexpected problems. The digital polibak system was designed to monitor the status of pending examinations. When all examinations were done the patient name would be sent to a working list of the cardiologist. No names appeared there however. Patient safety was at risk and it was decided to stop the digital polibak. The old paper based polibak and files were re-introduced. Furthermore it became clear that the old paper files had a communication and ‗triggering function‘ that was not taken into account when the EPR and digital polibak was introduced.
7
1.3. Research question
How can the digital polibak be redesigned in order to avoid lack of overview and confidence regarding patient data among workers and medical errors in the treatment of patients while maintaining the workflow, quality and safety of the patient treatment.
1.4. Sub-Questions
1. What solutions can be found regarding the various problems that occurred before and after the implementation of the digital polibak?
2. How will the disappearance of the ‗trigger function‘ of the paper files influence the various stages of the policlinic processes and how can the problems associated by the disappearance of the paper files be resolved?
8
2. Literature review
2.1 Process redesign literature
What is process redesign?
“Business process redesign, also known as reengineering or process innovation, is offered as an enabler of organizational transformation.” (Stoddard, D. B., Jarvenpaa, S. L. 1995)
―Business process redesign is a pervasive but challenging tool for transforming organization‖ (Broadbent, M. et al. 1999)
According to the two definitions above process redesign is a tool used for organizations wishing to transform. This thesis deals with a process redesign at the policlinic Cardiology in ‗de Tjongerschans‘. Various methodologies of process redesign are researched; five were taken into consideration for this project. Some of them focus on several major steps in the redesign process and others are very detailed using a considerable number of small steps in the process.
What is collaboration?
―When two or more people work together to create or achieve the same thing‖ (Cambridge dictionary, 2011)
―We define collaboration as joint effort toward a group goal‖ (Vreede, G.J, et al, 2009)
“In the knowledge economy, organizations frequently face problems of such complexity that no
9 implementation as they require that users have extensive knowledge about how to use technology to invoke, sustain, and change useful patterns of collaboration.‖ (Vreede, G.J, et al, 2009).
Redesign approaches: BPTrends
A methodology often used is BPTrends Process Redesign Methodology, which is designed for new process change practitioners (Harmon, P. 2007). It is a basic method using the various resources of a company using observations and the views of the researcher. There is however one shortcoming with the BPTrends Process Redesign Methodology. It does not take into account the formation of a multi-disciplinary team and deals with possible resistances in the final phase (Harmon, P. 2007).
Collaborative problem solving
This is a method where both internal and external stakeholders benefit from improvements in service and quality when team members work together to solve problems. Furthermore, team members have the opportunity to perform meaningful work and to make a difference in their organizations' success. Of course, those organizations gain the tangible and intangible advantages associated with the teams' work —cost savings, improved customer satisfaction, improved product and/or service quality, and so on, but perhaps more important, they begin to tap into the enormous potential of empowered and enabled teams (Journal for Quality & Participation. 2008). The chances for resistance after
implementation are virtually reduced to zero. Previous research has demonstrated the value of taking a broader organizational approach to redesign and shows that the involvement of a wide range of stakeholders during evaluation can result in some very creative, practical and productive solutions (Brooke, C. 2000). A six-step model is created by Casalini (Casalini, M.C et al. 2005). The
involvement of the whole multidisciplinary team during all phases may be time consuming and is seen as a downside of this approach.
Dynamic modeling approach:
10 strategy. Here, a design project is seen as an adaptive process of learning for both the consultants and the stakeholders of the client organization. In a design project, stakeholders often have much (tacit) knowledge of organizational business processes, bottlenecks in current functioning and possible improvements. Consultants bring in knowledge about design methodologies, techniques and tools and can suggest possible overlooked alternatives, both organizational and technical. Stakeholders can learn from consultants and vice versa. For effective learning, a close corporation between stakeholders and consultants is needed in all phases of the design process. The dynamic modeling effort is not an aim in itself but should be linked to actual organizational problems; the current way of working is grounded in the problem solving approach. Sol, H.G. (1982) argues that problem solving can be seen as a model cycle, consisting of a number of steps and products, as shown on figure 1 (Meel, J.W. 1994).
Figure 1 The process of problem solving
11 experimental model. Comparing the effects of the various experimental models results in a final solution, which can be implemented in the problem area (Meel, J.W. 1994). In this way, the effectiveness of the various solutions can be evaluated without the need to implement them in the complex reality (Meel, J.W, Sol, H.G. 1996). The fifth activity is ―Consistency check‖. In order to prevent the alternatives from going beyond the scope of the problem, they are checked on their consistency with the conceptual model. The last activity in the problem-solving cycle is ―Implementation‖ of the solutions chosen (Babeliowsky, M. 1997).
The ―hard‖ dynamic model is used as a substitute for complex reality. One can experiment with these alternatives without implementing results in the real problem domain, by translating alternative solutions in the model of the current situation. Dynamic modeling also results in ―soft‖ learning and feedback. Tacit knowledge vital to the functioning of an organization is made explicit during the modeling process and can be viewed from various perspectives. Representation schemes and models are recognizable and comprehensible for non-experts within the organization, and thus enhance participation (Meel, J.W. 1994).
Business engineering:
In the nineties the environment changes to a globally networked society, boundaries are no longer fixed but subject to change in type and geography due to global transitions. The organizational
environment was no longer stable but truly dynamic. The environment was characterized by increasing complexity, hostility and turbulence. IT in particular has developed very fast in this period and offered organizations all kind of new possibilities. Organizations became more depended on IT but it became clear that providing more and better information does not automatically resulted in better
organizational performance. The business world became more dynamic and organizations needed to transform their business to survive. The latest word in the nineties around organizational
transformation was business engineering (BE) (Meel, J.W, Sol, H.G. 1996).
BE became popular in business and information technology literature to denote organizational transformation focusing on integral design of both IT and organizational processes and structures. Engineering can be seen as designing solutions to real-life organizational problems. Depending on the perspective and the domain of application, three different forms can be distinguished (Meel, J.W, Sol, H.G. 1996).
1. Infrastructure engineering: deals with strategic choices about partners, markets and products. 2. Process engineering: concentrates on changing both technology and the user environment in
an integral way.
12 BE combines infrastructure, process and task engineering, looking at organizations from multiple perspectives, but hinges on the process dimension. Processes are seldom structured with the possibilities of new information technologies in mind. Most business structures and processes in the nineties were not designed but emerged over time. Figure 2 is a graphical representation of business engineering (Meel, J.W, Sol, H.G. 1996).
Figure 2 graphical representation of Business Engineering
Despite the potential of BE has to improve business performance, many projects turned out unsuccessful with failure rates as high as 70 percent. Several reasons for this high failure rate are: resistance to change, poor stakeholder involvement, poor risk assessment, poor analysis of current and future business processes and organizational reluctance to invest in large reengineering projects (Hengst, M. Den., Vreede, G.J. 2004).
Collaborative Business Engineering:
13 CBE follows a collaborative dynamic modeling approach to support business engineering. The CBE approach makes use of discrete event simulation and a Group Support System (GSS). The CBE approach can have two starting points. It can start with a problem that has to be solved.
1. It can start with a problem that has to be solved. A conceptual model is made of the situation followed by an empirical model (in many cases a discrete event simulation model). This empirical model supports the evaluation of previously generated alternative solutions for the problem (Maghnouji, R. et al. 2001).
2. It can start with an opportunity that has to be explored and transformed into a design. In this case a different approach is followed. Characteristics are that alternatives of the opportunity are generated and visualized at the beginning. The interesting alternatives are then modeled for testing and evaluation purposes (Maghnouji, R. et al. 2001).
Previous studies in the field of CBE have shown that participation is important for various reasons. It leads to creating commitment from the participants, gaining better understanding of the participants‘ work and creating shared understanding. Furthermore, model development time and design time can be cut as information is gathered in a shorter time than in the case of bilateral information gathering (Maghnouji, R. et al. 2001).
An efficient structuring of the process is desired due to the limited time of the participants. Requirements on collaborative design sessions are:
Fast modeling: stakeholders do not have time to sit through lengthy modeling sessions.
Interactive design supported by models: participants are brought together for interacting with each other, this interactivity has to be supported by the models used. This may mean that some models have to be prepared beforehand, or that it has to be possible to build and/or modify models on the spot.
Effective modeling: stakeholders must understand the situation they depict without too much effort.
The CBE process consists of several basic design activities. The order and extensiveness of the
activities depend on the type of project. The basic design activities, which are not necessarily executed in chronological order, are (Maghnouji, R. et al. 2001):
Delineate the problem or opportunity.
Define project boundaries.
Gather data (both conceptual and empirical)
14
Generate alternative solutions or designs.
Build and validate discrete event simulation model.
Evaluate results.
Converge from several alternatives to a few.
Several tools can support these activities: Discrete event simulation and animation tools. GGS to support group discussion during model building and model use activities. And sketching, where models and animation are used to visualize the situation, and to create a shared space for group interaction (Maghnouji, R. et al. 2001).
The focus of the CBE approach is not on finding the single optimal new organizational design but on facilitating a diagnosis and design process that will yield a satisfying and acceptable solution. The CBE approach assumes that actors in an organizational process hold essential information that is required for the effective completion of the redesign effort. Therefore, these actors (stakeholders) need to be involved in the redesign activities. Stakeholders‘ involvement is also required to recognize and accommodate their goals (Hengst, M. den., Vreede, G.J. 2004).
The CBE approach follows the dynamic modeling process as described earlier. This process outlines five major design activities that are executed: 1) Conceptualization. 2) Specification. 3) Construct alternative models and conduct experiments. 4) Choose most preferred solution and 5)
Implementation. These five activities do not have to be followed in chronological order. Depending on the problem at hand, the CBE approach allows for iteration and incrementation. Case studies have proven that analysts and stakeholders often iterated back and forth between conceptual and empirical modeling, building and extending the relevant models (Hengst, M. den., Vreede, G.J. 2004).
CBE does not employ a single modeling technique. A single best modeling technique does not exist. It should be chosen according to the situation at hand. In choosing a modeling technique, several aspects should be considered. The modeling technique should be relatively easy to understand and accepted by stakeholders and it should enable the construction of a comprehensive model of the problem situation (Hengst, M. den., Vreede, G.J. 2004).
15 screens of other users. Published studies from the laboratory and from the field have shown that group support systems (GSS) have the potential to provide great benefit to teams and organizations (Briggs, R.O et al. 2003).
Redesign process for the digital polibak
The implementation of the EPR and its effects on the back-office require a quick solution to all problems that may occur with the least possible chance for the occurrence of unexpected resistances. A quick method that takes all these aspects into account is the collaborative business engineering (CBE) approach and is chosen for the redesign process of the digital polibak. The BPtrends approach lacks the collaboration aspect and is therefore less suitable to solve the problems at the policlinic. Other approaches mentioned above are suitable but the CBE approach incorporates aspects of the other approaches while keeping flexibility and efficiency.
2.2 Simulation literature
16
3. Analysis
3.1 Approach
To analyze the processes and problems regarding the digital polibak at the department of Cardiology the CBE approach was chosen.
This approach was used at the policlinic for the following reasons:
1. Low failure rate. According to literature the failure rate of BE is 70% compared to 22% with CBE approach (Hengst, M. den., Vreede, G.J. 2004).
2. Involvement of all stakeholders. As many as possible workers at the policlinic can be involved in this collaborative redesign process. The acceptance of the outcome will increase if more workers are involved resulting in a reduction of the occurrence of resistances to the new situation (Litwin, A.S. 2011).
3. GSS session. The decision makers of the hospital and the department ICT are involved in a GSS session held at the data-lab of the RUG. They can make their supportive decisions after having heard the opinions of many workers and their proposed solutions. The CBE approach supports using tools like GSS.
4. Familiarity. The method fits the kind of practical problem solving that the workers at the policlinic are familiar with. Most problems at the department are solved during meetings where all working groups are present.
17
Activity: Executed by:
1) Conceptualization
Gather conceptual data
Define problem boundaries
Identify relevant object classes
Define relevant object classes
Construct conceptual model
Analyst & stakeholders Analyst & stakeholders Analyst
Analyst
Analyst & stakeholders 2) Specification
Formulate organizational requirements
Construct simulation model
Gather empirical data
Validate and verify simulation model
Formulate solution directions
Analyst & stakeholders Analyst & stakeholders Analyst & stakeholders Analyst & stakeholders Analyst & stakeholders 3) Construct alternative models and conduct experiments
Identify possible solutions
Select solution to elaborate
Conceptualize solution
Construct simulation model of solution
Evaluate solution
Analyst & stakeholders Analyst & stakeholders Analyst
Analyst
Analyst & stakeholders 4) Choose most preferred solution
Compare evaluation results
Determine alternative to implement
Analyst & stakeholders Analyst & stakeholders 5) Implementation
Write policy document
Introduce changes
Perform post-evaluation
Analyst Analyst -
18 Some activities will be performed collaborative in a GSS setting. Vreede, G.J, et al, (2009) provided literature that includes guidelines how to set up a GSS session (Vreede, G.J, et al, 2009).
Collaboration engineering is an approach for the design and deployment of collaborative technologies and collaborative processes to support mission-critical tasks. A fundamental goal of collaboration engineering is to minimize cognitive load for practitioners while transferring to them relevant facilitation skills and knowledge about GSS and group dynamics. Collaboration engineering seeks to package facilitation skills and GSS experience. This is not an easy challenge. To execute successful collaboration engineering efforts, at least the following three requirements must be met (Briggs, R.O et al. 2003):
1) GSS-related facilitation skills must be packaged in such a way that the conceptual load for practitioners is reduced significantly. This implies that the GSS functionality and facilitation techniques must be mapped to the steps of the practitioners' own processes. This way,
practitioners, unlike facilitators, only need to learn the functionality and operation of the GSS that is required for each step in their own process rather than every nuance of a GSS to be prepared for any eventuality.
2) GSS-related facilitation skills need to be packaged in such a way that different practitioners using the same packaging will get similar, predictable results from their groups. They must find ways to make proven, successful interpretations readily available to practitioners at run time.
3) Collaboration engineers must find ways to package GSS-related facilitation skills in such a way that the packages can be reused to enable short development times for new processes. In order to create sustained success with GSS, collaboration engineers must seek to minimize the need to train practitioners to execute mission-critical collaborative processes by packaging facilitation skills as reusable units and mapping those building blocks into methods that yield predictable, repeatable results when applied by different groups. Such building blocks are called ―thinkLets‖. A thinkLet is a named, scripted technique for predictably and repeatedly invoking known effects among people working together toward a goal (Vreede, G.J, et al, 2009). We elaborate on them below (Briggs, R.O et al. 2003).
19 elementary group process from a leader's point of view by providing explicit, scripted prompts for the group, and by guiding the practitioner through the decisions that must be made based on the group's behavior. In addition, a thinkLet defines which GSS tool(s) to use and how to configure each of them. A thinkLet encapsulates a facilitator's best-practice regarding establishing a certain pattern of
collaboration (Briggs, R.O. et al. 2003).
There are five general patterns identified of collaboration that constitute five broad categories for thinkLets. These are defined below (Briggs, R.O. et al. 2003):
1) Generate: To move from a state of having fewer concepts to a state of having more concepts. The goal of a ―generate‖ thinkLet is for a group to create concepts that have not yet been considered. Brainstorming is an example of a ―generate‖ thinkLet. A special class of ―generate‖ thinkLets concerns elaboration, or adding detail around "seed" concepts that are already in place. During an elaboration process, a group may start with a set of previously generated concepts as an inspiration to come up with more concepts. Groups may also start with previously generated concepts to analyze them or increase comprehensiveness by adding more information.
2) Reduce & clarify: To move from a state of having many concepts to a state of having a focus on and understanding of the few worthy of further attention. The goal of a "reduce & clarify" thinkLet is for a group to reduce their cognitive load by reducing the number of concepts they must address.
3) Organize: To move from less to more understanding of the relationships among concepts. For example, organize a mixed list of ideas into a number of categories, or arrange them into a tree. An "'organize" thinkLet is typically not executed as a goal in itself; its purpose is usually to facilitate the subsequent (team) activity, for example, a distribution of categories of action items over a number of subgroups for further elaboration (divergence).
4) Evaluate: To move from less to more understanding of the possible consequences of concepts. The goal of an "evaluate" thinkLet is to focus a group's discussion or inform a group's choice based on a judgment of the worth of a set of concepts with respect to a set of task-relevant criteria. The discussion may be focused or the choice may be informed by either the estimated value of the concepts or the group's consensus of that value or both. For example, an
"evaluate" thinkLet may involve having a team use a one-to-ten scale to rate the merits of a set of alternatives. An ―evaluate‖ thinkLet is frequently followed by a ―generate‖ thinkLet. If people need to understand the assumptions and information underlying their patterns of polling, or a "build commitment" thinkLet if they must take a joint decision.
20 A thinkLet has a name, and at least three other components. In order to create a specific pattern of collaboration, thinkLets must be defined at least in terms of the tool used, the configuration of this tool, and the facilitation script (Briggs, R.O et al. 2003):
Tool: the specific version of the specific hardware and software technology used to create a pattern of collaboration.
Configuration: The specifics of how the hardware and software were configured to create of pattern of collaboration.
Script: the sequence of events and instruction given to the group to create the pattern of collaboration
Although thinkLets represent a means for allowing less-experienced GSS users to wield the technology on their own behalf, they do not represent a repeatable process. A thinkLet is a way to create a pattern of collaboration; a repeatable process is a step by- step way to accomplish a mission-critical collaborative task like strategic planning or requirements negotiation. A thinkLet captures the required tool choice, tool configuration, and facilitation script to re-create a pattern of collaboration among a group of GSS users (Briggs, R.O et al. 2003).
3.2 Data collection for analysis
Data were collected from both quantitative and qualitative sources:
Documents. Annual reports of the department of Cardiology provided data on the annual number of patients and examinations performed.
Interviews. Data on the AS-IS situation were obtained by interviewing workers at the policlinic.
Direct observations. The processes at the policlinic were observed and described. During 20 working days data (times and percentages) of individual steps (exogenous variables) in the polibak process were timed. The total daily handling time of the polibak (endogenous variable) was measured every day during the observation period.
GSS session. The results of each step of the GSS session was stored and led to an inventory of existing problems and possible solutions.
The combined data led to the development of a proposed TO-BE situation as explained in the next part.
21
3.3 Simulation
The current problem in the AS-IS situation at the department Cardiology is that while they want to work in a digital environment with the EPR, they still rely on paper based files regarding the handling of the polibak. As mentioned before, an attempt to transform the polibak process to a digital
environment has been tried and failed mainly due to not analyzing and redesigning the processes. The CBE approach will be used to redesign the polibak process. To compare the proposed TO-BE process to the existing AS-IS situation a simulation of the TO-BE situation will be used. The effects on time needed for administrative staff to handle the polibak (endogenous variable) in the AS-IS and TO-BE is compared.
During the conceptualization phase of the redesign process a model for the TO-BE situation is made containing all the different variables (figure 3).
Figure 3 Conceptual model of the TO-BE polibak
The polibak contains a number of files that wait for results of examinations.
Input: Each day a new number of files are added to the polibak when the specialist places orders for exams
Output: The daily check results in releasing files from the polibak when all the examination results are in
22
Endogenous variables:
Total time needed for the daily polibak check
Exogenous variables:
Number of files in the polibak (Σ (IN – OUT))
Binary point percentages (the percentage of files that wait for an echo, bike, lab or other result)
Overdue check window (the wait time for results before the system decides that a manual check is needed)
Manual check (dependent on skills of the person that checks and the availability of examination results)
The daily check of all the files in the polibak is the basis for the simulation.
The simulation flow chart that is used in iGrafx 2006 can be found in APPENDIX A. Different sources of data are used to construct this simulation model. Interviews were held to gain an
understanding of the entire process. Annual reports from 2010 of the department Cardiology contained data about the number of examinations. Direct observations are used to time process steps.
Before we can run the simulation the following parameters need to be defined:
Start up time. In this simulation the process is non-ending. It starts in a certain state where it will probably never return. This means that after day one an average amount of examination results end up in the polibak and it will never go back to zero. After several weeks the amount of results will stabilize and the model will present a reliable output. The model is then in a so-called ―steady state‖. The time needed for the model to enter this steady state is the start-up time.
Run length. The run length will be determined using a rule of thumb. The rule length should be three times the highest cycle time (Sol,H.G. et al. 1999).
23
4.
Analysis
The CBE approach is used for this research. During the first phase (conceptualization) using interviews and observations a better understanding of the polibak process and its problems was obtained. Problems and process steps were used as a basis for the GSS session.
4.1
Process & problem description
In this first step (conceptualization) of the CBE approach was data is gathered during 20 working days and a conceptual model of the polibak process is formed.
There are four working groups directly involved with patient care at the department of cardiology, specialists, secretaries, receptionists and physician assistants. Indirectly ICT and management can also be considered as working groups at the department. The last two groups are important stakeholders in the transition process leading to the digital polibak and also join the data-lab session.
The main focus of this study is the redesign of the polibak using problems and solutions. Resolving those problems is impossible without taking the problems of supplying departments into account. The Polibak process receives starting input from the specialists who place digital Orders during patient consultation in the EZIS order handling system. The orders are selected and entered into the
Polibak process by the receptionists. Other processes supply triggering input into the polibak that is
checked every day by secretaries and receptionists. The Echo process and the Bike process are part of the working processes at the policlinic cardiology and described in more detail. Problems regarding those processes are integrated into the problems of the polibak. External input into the polibak from
Mail and Other results (laboratory, nuclear testing and radiology) cannot be influenced and change
24
Figure 4: General polibak conceptual model
Polibak process:
The second step in CBE is specification. The goal of this step is to make a detailed specification of the problem situation to obtain an empirical model of the TO-BE solution.
AS-IS process description:
The receptionist sorts the placed orders from the specialists. She makes appointments for the exams and gives a general explanation to the patient. An appointment schedule is printed out and delivered to the patient.
A paper course note is made and appointment types and dates are added. This note is placed into the polibak of the specialist sorted by birth date of the patient. The receptionists end their day sorting out the polibak. They first check for examination results (Echocardiography, Bike / treadmill tests, Laboratory results and other results) of patients scheduled for next day consultations. After this check they file the incoming examination results of that day into the polibak files of the patients. They check the course notes on overdue examination results and if they find any, they search for the results or call the patients when they missed an examination date. Those patients are rescheduled and the course note is adjusted. When all examinations on the course note are finished and when all the results are in the file of the patient, the file leaves the polibak and is presented to the specialist either in the appointment stack of the next day or in the dictate stack. (APPENDIX A)
25 Problems Polibak
Problem list
Process step Problem Who experience the problem
Spec Recep Secr PA
E1 :Echo – check temporary/final result
Time consuming X X
E2 :Echo – trigger function of paper result
The paper result put on the desk of the specialist attends him that the patient can be called from the waiting room
X X
E3 :Echo – scanning final report Time consuming, seems to be unnecessary
X
E4 :Echo – visibility of temporary results
Only specialists and physician assistants can view temporary results in Echopac®
X X X X
E5 :Echo –printing final results Time and money consuming X X
E6 :Echo – Echopac® Only specialists and physician assistants can view temporary results in Echopac®
X X
B1 :Bike – paper result (ECG) Results are printed for review and digitally stored at the bike computer.
26 B2 :Bike – paper result (data form) The data form is not stored and needs
to be scanned, is time consuming.
X X
P1 :Polibak – preparation Each day checking for results that are needed the next day is time
consuming.
X
P2 :Polibak – piling up of results Not all results arrive evenly
distributed and daily time is limited. This sometimes results in back-up checking for results.
X
P3 :Polibak – printing results Many examination results are available in the EZIS-EPR. For the paper file they were printed. In the EPR environment many results are printed unneeded.
X X
P4 :Polibak – scanning Results not available in EZIS are presented on paper. Scanning the results into a pdf document or medical viewer is saving paper and less time consuming.
X X
O1 :Other results :Internal mail Letters from other specialists in the hospital are all available in EZIS, they can be destroyed or even better not sent at all.
X X
O2 :Other results :External mail Visible in medical viewer, there is no trigger for the specialist that a new
27 item is scanned into medical viewer.
O3 :Other results – Holter A large number of ECG pages that are not digitally available.
X X X
O4 :Other results – KCL Some lab results come from a central lab and are not available in EZIS, they need to be scanned in medical viewer.
X X
M1 :nuclear medicine results Unavailable in EZIS, need to be scanned as PDF in EZIS
X X
D1 :Digital polibak – accumulation All orders are entered into the digital polibak. Also orders that will be performed over 2 years. Those names have to be checked every day and has the potential to clutter the polibak.
X X
D2 :Digital polibak – introduction Not all specialists want to work digitally, this results in manual order handling, printing, scanning and manual checking.
X X
D3 :Digital polibak – medical viewer There is no trigger that alerts specialists that there is a new entry into the medical viewer system.
X X
28 Problems polibak:
29 Echo process:
The process starts with the specialist creating an order for an echo. The physician assistant at the function department of the policlinic performs the echo and creates a preliminary result. When the patient is not going to the consultation room of the specialist directly, the preliminary result will be placed in the polibak until there is final result (Figure 5).
30 If the patient goes directly to the specialist, the preliminary result will be given to the receptionist after the consultation with the specialist and will be put in the file of the patient for further handling by the specialist. This file is kept until a final result of the exam is printed and checked with the preliminary result. The specialist will check the preliminary results of all echo‘s made that day. Sometimes a result is changed. All results are authorized after this check. Final results are printed. This authorization is performed on a separate system called Echopac®. Only the specialist and physician assistants can see the results in Echopac®. This makes printing of temporary and final results of the echo exams necessary.
Problems echo:
There are some problems mentioned by the workers in this process. The first one is that the digital results of the examinations performed by the physician assistants are not visible for all workers at the policlinic. Not all workers are authorized to use Echopac®. The second problem may be generated by the first. To solve the lack of visibility of results, all results are printed and entered into the polibak or presented to the specialist. The third problem is that every preliminary result is compared to the final result. If there is a change all letters containing preliminary data are changed. The fourth problem is that all final results are scanned into the medical viewer. This is needed to make echo results visible to secretaries and receptionist for use in the future. The final problem is that the preliminary printed result is placed on the desk of the specialist when the patient will receive the result directly after the examination. This paper triggers the specialist that he can call the patient from the waiting room. (Table 2, problems E1 to E6)
Bike process
31
Figure 6: bike process diagram
Problems Bike
The main problems mentioned by the workers for the bike results are that some data are stored on the bike system and not accessible within the EPR. Each time when a specialist needs the ECG‘s, they have to be printed from the bike system. Other data from the bike tests are not digitally available and need to be scanned into medical viewer. (table 2; problem B1-B2)
32 Other results processes
Other results are generated at other departments in the hospital. Some results are viewable in EZIS (Laboratory results, radiology results and microbiology results). Other results come in a paper format. They will be scanned into Medical Viewer or as a PDF file as a document attached to the patient. Currently the latter is hardly ever done while the technology is available (Figure 7).
Figure 7: other results process diagram
Problems Other results
There is a lot of work involved with the handling of all the various results according to the
receptionists. The fact that most results are not digitally available makes scanning necessary. There is a resistance among workers to scan, it takes a lot of time and they know that the results are digitally generated at the other place where the examinations are performed.
33 Mail processes
Other mail that arrives will be scanned and attached to the EPR as a PDF file. Currently this work is done once a day. There is scanning software that makes it possible to select the file of the patient and to attach the scanned document to the file. Although seemingly a perfect solution for scanning, the workers find the process unclear (Figure 8).
Figure 8: mail process diagram
Problems Mail
It is unclear to the secretaries which documents should be scanned into medical viewer, which into the documents section and which documents can be destroyed, as they will become available in EZIS. The place in medical viewer where to scan the documents to is also unclear. There is only a choice to put it in archive, central or de-central maps. There is no clear document that can be used as a guide for scanning.
34
4.2 Collaboration session (GSS)
To help perform steps 3 (Construct alternative model and conduct experiments) and step 4 (choose most preferred solution) of the CBE approach a GSS session was held at the data-lab at the RUG. During this session problems were collected to see if any were missed, they were ranked regarding importance and possible solution for these problems were discussed. The process of brainstorming about possible solution was the third step ―Construct alternative models and conduct experiments‖ in CBE. To give some guidelines to this GGS session figure 9 represents the model that is used during this GGS. Below are all the thinkLets that are used during the GSS session explained. As mentioned in the literature a thinkLet has three components (tool, configuration and script) that need to be defined. The following thinkLets are displayed: FreeBrainstorming, FastFocus, PopcornSort, StrawPoll and MoodRing.
1. FreeBrainstorming:
a. Overview: FreeBrainstorming is about creating as many possible solutions to a certain topic. Each participant starts with the topics set up by the facilitator. Each topic links to a comment field where participants can enter their ideas on what they think are the problems. Each participant hops true the topics until they run out of ideas.
b. Tool & configuration: The GSS session is held in the data-lab at the RUG. Participants can contribute under each topic. Participants cannot create new topics but are able to delete their own posts. All contributions will be anonymous.
c. Script: The facilitator explains all the topics so there will be no confusing what the different topics mean. Examples of ideas are shared so the group knows how they can contribute. An explanation is given on how to comment.
2. FastFocus:
a. Overview: FastFocus is about extracting a key list of problems. Problems from the previous brainstorm session are discussed. When all problems are discussed a final list is created.
35 c. Script: The first step is to run through all the problems and if anything is unclear or
not within the scope it will be cleared or deleted. 3. PopcornSort:
a. Overview: PopcornSort is about categorizing different problems in main groups. Participants browse through the list of problems and try to find items related to each other. The group formulates a new name for the combined item.
b. Tool & configuration: The GSS session is held in the data-lab at the RUG. Categories are created and problems are dragged into the category by the facilitator.
c. Script: Participants have some time to run through all the different problems. The facilitator starts a discussion on what problems are related to each other and combines the problems together.
4. StrawPoll:
a. Overview: StrawPoll is for ranking all the different problems on importance. It allows finding out in a quick way what priorities the group has.
b. Tool & configuration: The GSS session is held in the data-lab at the RUG. A ranking between 1 and 7 (1 = least important and 7 is most important) will be given to all the different problems.
c. Script: The facilitator asks the participants to rank the problems between 1 and 7 (1 = least important and 7 is most important). When participants are finished, the button ―Cast votes‖ is pushed.
5. MoodRing:
a. Overview: MoodRing is to continuously track the level of consensus within the group and if necessary make needed last minute changes.
b. Tool & configuration: The GSS session is held in the data-lab at the RUG. Make sure the group understands all the different issues.
36
37 A multidisciplinary team was formed consisting of representatives from all stakeholder groups at and around the policlinic cardiology involved with the introduction of the digital polibak. Members of the team were: from the policlinic one specialist, one secretary, one physician assistant and one
receptionist, from outside the policlinic the supervising manager of the policlinic and the EPR manager from the ICT department.
The GSS session was performed with the multidisciplinary team at the data-lab of the RUG. The multidisciplinary team using the collaborative group decision making process of the data-lab first decided on breaking down the polibak process into seven steps;
1. Order handling 2. Echocardiography 3. Bike testing
4. Laboratory and radiology results 5. Present to specialist (communication) 6. Process end result
7. Other problems
The members of the team discussed the problems already known and were given the opportunity to add new problems to every of the 7 groups (FreeBrainstorming thinkLet). This problem investigation also generated a check for the first problem list. Problems from groups outside the policlinic
(management and ICT) were included to the problem list. (APPENDIX C). Additional added problems
- Emergency procedures are missing.
1. In case of a power failure treatment of patients will become impossible due to not having the patient data in the EPR. Computers are not connected to the emergency power grid of the hospital.
2. When an alarming result for the patient‘s health is found by another department
communication currently is performed by written messages. There is no emergency reporting procedure in the digital environment.
38 -The location of the patient at the policlinic is unknown when there is no paper where the nurse can write the patient location on. There is no digital system installed that shows in what examination or waiting room the patient actually is.
Categorization of problems:
This step at the data-lab showed the problems to the members of the multidisciplinary team. They discussed the various problems, rephrased them and deleted double or similar problems (PopcornSort thinkLet). The problems were sorted into seven categories that the team agreed upon. The end product is the final problem list within the seven categories (APPENDIX D).
1. Patient selection and filtering 2. Emergency procedures 3. Process and working descriptions 4. Authorisation problems 5. Alarm and ―trigger functions‖ 6. Scanning and printing problems 7. Changes in EZIS
This list was the basis for the next step and presented to the members of the multidisciplinary team. Ranking of problems:
By using a voting system within the decision making data-lab all members prioritized the problems and their solution (StrawPoll thinkLet). The voting system gave a number from 1 to 7 (1=least important and 7 is most important) to each proposed solution. The problems were grouped into three categories; 1: very important 2: important and 3: least important. In figure 10 the priority is
39 Summary of brainstorming:
The basis for the discussion is the initial problem list placed in seven clusters. The multidisciplinary team used the data-lab to give possible solutions to all problems. Not only for their own problems but also for the problems of others. The results varied, a secretary gave very practical solutions while the ICT representative gave technical solutions. The variety of possible solutions made it possible for all to hear their problems and proposed solutions. Out of the box thinking by all was stimulated by the data-lab approach and was evaluated by all to be an inspiring method. The end result is shown in figure 10.
40
4.3 Solutions to the problems
Solution of specific echo problems
The solutions of the echo problems start at the cardiac department. Instead of printing the preliminary results onto a piece of paper, it should be stored digitally in EZIS / Echopac®. The specialist then needs access the examination result so he can check the result on his own computer at his desk, possibly double checking the written result with the echo images in Echopac®. This check would make the status of the echo result final. Scanning and printing will become obsolete. Access to authorizing software from every working place of the specialist is a mandatory condition.
However these changes alone do not speed up the process because the secretariatstill relies on paper based information. For them it is important that they gain access to the EZIS / Echopac containing the final results. The receptionists and secretaries do not have to check the preliminary and final results of the echo as the specialist performs this function.
Finally the secretariatdoes not have to scan into medical viewer any final results anymore. These are now available digitally in EZIS / Echopac® and most importantly viewable to all that need to see the results outside the department of Cardiology.
The input of the ICT department at the session was that Echopac® licenses are free, the secretaries and receptionist only have to be authorized for the use of Echopac®.
Description of procedures
41 Printing and scanning
Printing should be reduced to an absolute minimum in a paperless office. Only reports that have to be sent outside of the hospital or to a department that still does not work with the EZIS EPR should be printed.
The place where a scanned document ends in the file is critical.
When a document is scanned for archiving it should end up in Medical Viewer. A recognizable map structure in medical viewer could help finding documents more easily. The hospital has chosen not to implement a map structure due to the high costs for scanning all the old paper files.
When the document is needed for the actual treatment of the patient another place, for example the documents section, should be found to store the scanned document more easily accessible.
Documents that are available from other departments in EZIS should not be printed or scanned. Back-up systems
Some computers should be placed on the back-up power grid of the hospital. Patient care must continue when power is lost.
“trigger functions”
There are several ―trigger functions‖ of the old paper files found in the process surrounding the handling of the polibak.
1. The orders in the digital order system are not viewable in the EPR. The specialist has no idea what examinations are performed as he misses the paper results. The solution is that the specialist places an X in the examination field of the EPR to warn him next time that he ordered that examination when the patient returns or when the letter will be made to the family doctor. A second place where this information can be stored is at the alert line within the EZIS scheduling program. This line is visible to the specialist during consultation hours. When the patient doesn‘t return for the results than a field can be added to the digital working list of the specialist containing codes for the various examinations that were performed (E for Echo, F for Bike, L for lab, R for radiology etc.).
2. Stickers on the patient file and the ECG warned the specialist that the patient is ready to be examined in examination room indicated by a number or ready to be called from the waiting room. This ―trigger function‖ disappears after the introduction of the fully digital
42 where the patient is was considered to be a bad solution. The ICT department came with the idea to add a column in the EZIS appointment list where the receptionist can add a number or place to the appointment of the patient indicating to the specialist where he can find the patient when the patient is ready.
3. The old paper files were put in various stacks and were a sort of memory for various workers at the cardiology department. Virtual stacks called working lists can be made within EZIS where names of patients can be placed in and after handling transferred to the next persons working list that needs to handle the digital file of the patients. A good waterproof linked system should be set up. Uniform working instructions surrounding the placement of patients in different working lists should be agreed on and described in written procedures.
4. Sometimes results from other departments contain alarming information regarding the health of the patient, for example a tumor found on a routine chest X-ray. All results are sent to the secretariat on paper and they check all papers for alarming problems. With the disappearance of all papers a potential hazard for the patients is created. This can be solved at the source of the problem. The specialist that reviews an exam must be able to put the patients name on an alert list viewable in EZIS by all specialists of the department. In the procedures a daily check of this list by the specialists should be added.
5. Less alarming are questions asked by other departments. They come either on paper or digitally. The papers are scanned and there is no trigger to look at the letter containing a question. At the cardiology department less than 1 % of all letters contain questions. The secretaries should be able to put the patient names on another working list of the specialist in EZIS. Those procedures should also be described.
6. Finally when all examinations are done and all results are in the patient should be placed on a general working list of the specialist. He can produce a letter with his findings. While creating this letter a two-way communication between specialist and secretary is needed.
7. The specialist places not only orders for examinations to be performed on his patients. Sometimes he needs to communicate with others during special themed meetings, with other specialists or his secretary. Various paper file stacks now remind all that those patients should be presented at a meeting. In the digital environment multidisciplinary working lists can perform this function. Communication fields with others like the secretaries can be added in EZIS.
43 Proposed TO-BE situation
Using the proposed solutions and changes mentioned above a possible TO-BE process diagram of the digital polibak can be created. The process diagram of the digital polibak seems more complex compared to the AS-IS diagram, but most steps in the digital polibak are automated and cost no time (APPENDIX B).
The receptionist makes a selection of the orders from the specialist to be put in the digital polibak. Not all orders have to be put in the digital polibak (next appointment dates and appointments at other departments. The receptionist adds a date to the order on which day, from her own experience, an examination result usually returns. The system is to check several times a day on the status of all the patients in the digital polibak. It checks whether results are in and whether the results are final. When all results are in, the name and registration number of the patient is transferred to the digital working list of the specialist. An exception is made for patients that attend the policlinic the same or next day. For this process there is no need for human involvement. There are however a few human
interventions that are needed. Scanning results into Medical Viewer still needs to be done.
When the digital polibak was first introduced an important issue regarding patient safety arose. When a patient didn‘t complete one part of all the orders placed or when the status of the echo examination remained ‗temporary‘ (because the specialist forgot to authorize the result), the patient results
44
5. Simulation
In the third step ―Construct alternative models and conduct experiments‖ we came up with different solutions to overcome the problems. These solutions led to a new process diagram of the TO-BE situation. This process diagram can be found in APPENDIX B.
The fourth step in the CBE approach is ―Choose most preferred solution‖. In this step, solutions were compared using a simulation. Before any steps can be performed we need to make sure that the AS-IS model is validated. The AS-IS model should be a good representation of the reality. To validate this model we used a ―replicative‖ validation method.
Before the simulation three aspects need to be defined (start-up time, run length and amount of replications). The start-up time is at least three weeks (3 times the longest wait time of the holter examination, being 1 week), the steady state of 214 patient files being in the polibak will be reached after those three weeks. After this period the polibak gets a daily input that matches the average output and never returns to zero. The run length that will be simulated will be three times the longest cycle time plus the start-up time plus one day. In this case six weeks plus one day (31 days working days) is used. This simulation will be replicated 10 times. After these simulations are run, the two simulations (AS-IS and TO-BE) will be compared to each other.
5.1 AS-IS model validation
Validation is the process by which it is determined whether the simulation model is a valid
representation of reality (Law, A.M., Kelton, W.M. 2000). A replicative validation of the AS-IS model was performed by comparing the average daily check time of the polibak (endogenous variable) from 10 replicative runs of the AS-IS model with the average daily check time of the polibak during 20 observation days.
The hypothesis tested is:
H0 = There is no difference regarding total handling time of the polibak between the AS-IS
reality and the AS-IS simulated times
H1 = There is a difference regarding total handling time of the polibak between the AS-IS
reality and the AS-IS simulated times
This is a test in two steps. First the variances will be tested. When they are equal another testing formula for t is used than when they are not equal.
45 2. The t-test for the difference in μ with the above mentioned hypothesis.
F test
The inference about the ratio of two variances was tested for the AS-IS and TO-BE results. (Keller, 2005, 8E : page 476-478) 1 = AS-IS reality 2 = AS-IS model variance 1 = 181,05 variance 2 = 89,90 H0 =: s 2 1/s 2 2 = 1 H1 =: s 2 1/s 2 2 > 1
The rejection region is F > F α,10,20 = 3,85 (Keller, 2005,8E: appendix 8, B14) In this test F = 181,05 / 89,90 = 2,01
There is not enough evidence to infer that the variance of the AS-IS observed times are different from the variance of the AS-IS times obtained from the model in iGrafx. This result means that the t-test for the inference about the difference between two means with independent samples with equal variances can be used (Keller, 2005, 8E: page 441)
T test
From the data in APPENDIX J we calculate the following statistics:
46
The test statistic is: T = ((x1 – x2) - (μ1 – μ2)) / √(sp2((1/n1) + (1/n2)) = ((103,00 – 108,63) – 0 / √(111,82((1/20) + (1/10)) = -1,38
The number of degrees of freedom of the test statistic = n1 + n2 -2 = 28 The rejection region is: t < -t0,025,28 and t > t0,025,28 = t < - 2,05 and t > 2,05 The test statistic is -1,38 and outside the rejection region.
There is enough evidence to accept the hypothesis that there is no difference in time needed for the daily polibak check in the AS-IS observed and AS-IS simulated model using iGrafx.
This validates the time needed for the daily check of the polibak using AS-IS model compared to the current daily check in reality.
5.2 Determinant variables
Three groups of exogenous variables are determined in the simulation model (figure 3). - Binary point percentages
- Overdue check window - Activities times
The values for each of the variables will be determined before running the simulation. Binary point percentages
Data regarding the percentages at the binary points as mentioned in table 3 were drawn from the annual report 2010 of the department of cardiology.
The values (percentages) from table 3 are entered as constant variables in the simulation. The variables are considered to be constant. To check this assumption we conducted a comparison of these
percentages drawn from the annual report with the calculated percentages during a 20 days observation period. The inference about the difference between two independent population
47
Type of investigation Number of
patients (2010) Percentage of total patients Total patients 26037 Echo in polibak 4001 30,7 % Bike in polibak 2407 9,2 %
Other investigations in polibak 400 3,1 %
Lab testing in polibak 3603 13,8 %
Table 3: data from annual report cardiology 2010 with percentages of total patients
Overdue check window
An important decision regarding the digital polibak is the date when to expect exams to be finished. The computer will start checking the results of the patient when the expected examination date is reached. This however is not always the date on which the examinations are finalized. For example, it takes almost one week for a Holter report to arrive back at the policlinic after the actual Holter examination date. In the digital polibak flow chart manually checking for results on the day the examination was performed will result in a high percentage of patients that will have to be manually checked. This costs time.
To help ‗de Tjongerschans‘ in making the decision when to start checking results manually the consequences of the decision are simulated.
1. Expected result date = examination date
2. Expected result date = examination date plus 1 working day (correction for weekends) 3. Expected result date = examination date plus 2 working days
This results in the following handling percentages for one day. 1. 95 % manual check = 157,58 hours
2. 10 % manual check = 63,03 hours 3. 3 % manual check = 42,22 hours
48 The old polibak process took an average of 56,13 hours handling time. The result of this what-if simulation shows the critical value of the decision on what date to check the polibak. Doing this on the same day as the examinations an increase in handling time compared to the AS-IS situation is reached. The reduction in total handling time anticipated will be reached when the total number of patients to check falls below 5 %.
It is strongly advised to start checking the polibak manually 2 days after the examination date and focus on completion of all digital processes to avoid as much as possible manual checks. In the simulation model the 3 % manual check percentage is entered as variable, assuming a 2 day overdue check window.
Figure 11 Effect of manual checking percentage on total handling time
Times at activities
49
5.3 Statistical analysis
The difference between two means in an independent samples experiment (Keller, 8E, 2008, page 439-442) is used for the statistical analysis of the AS-IS and TO-BE simulation results. In this analysis n=the number of simulations (in this experiment n=10 simulations for a run length of 31 days). The hypothesis will be tested as a 1-sided experiment with an α of 0,05. Data for this test can be found in APPENDIX K and L. The average total times of 10 independent simulation runs for 31 days is used for testing.
The hypothesis tested is:
H0 = There is no difference regarding total handling time of the polibak (AS-IS) compared to
the digital polibak (TO-BE).
H1 = There is more total handling time of the polibak (AS-IS) compared to the
digital polibak (TO-BE).
This is a test in two steps. First the variances will be tested. When they are equal another testing formula for t is used than when they are not equal.
1. Test the variance using the F test with α of 0,05 and 10,10 degrees of freedom. 2. The t-test for the difference in μ with the above mentioned hypothesis.
F test
The inference about the ratio of two variances was tested for the AS-IS and TO-BE results. (Keller, 2005, 8E : page 476-478) 1 = AS-IS 2 = TO-BE variance 1 = 24,00 variance 2 = 21,72 H0 =: s 2 1/s 2 2 = 1 H1 =: s 2 1/s 2 2 > 1
