a generic simulation-based perioperative decision support tool for tactical decisions by daphne

A Generic Simulation-based Perioperative Decision SupportTool for Tactical Decisions

by

Daphne Sniekers

A thesis submitted in conformity with the requirementsfor the degree of Doctor of Philosophy

Graduate Department of Mechanical and Industrial EngineeringUniversity of Toronto

Copyright c© 2013 by Daphne Sniekers

Abstract

A Generic Simulation-based Perioperative Decision Support Tool for Tactical Decisions

Daphne Sniekers

Doctor of Philosophy

Graduate Department of Mechanical and Industrial Engineering

University of Toronto

2013

In Canada and around the world, there has been an increased focus on the efficiency,

cost and access to health care services. One area of particular focus is surgical procedures,

often with government funding and policies focused on reducing wait times through pay

for performance and volume target initiatives. In Ontario, an expert panel was assem-

bled to evaluate the current state of surgical processes and provide recommendations to

improve access, efficiency and quality. This thesis addresses the panel’s recommendation

for a simulation-based decision tool to help hospitals inform decisions that can lead to

improved access and efficiency.

A generalised, simulation based perioperative decision tool is presented that can be

used to test a variety of tactical decisions. The generic model has been applied to six

hospitals of varying sizes, ranging from large academic centres to small rural community

hospitals. The model remains in use at some of the hospitals to regularly inform decisions.

The model is also being applied to additional hospital sites.

During application of the generic model, challenges in design decisions and validation

were encountered. As a result, a series of principles are proposed to guide future generic

modelling design and achieving user acceptance. These principles add to the generic

simulation modelling and healthcare modelling research fields by laying some groundwork

for a formalised approach to designing effective generic simulation models and achieving

confidence in results.

ii

Finally, the research demonstrates two uses of the generic model: as decision tool

and as a demonstrative tool. As a decision tool the model is used to compare numerous

potential tactical decision options under consideration. As a demonstrative tool, the

model is used to quantify the effect of poor practices on hospital performance. The design

of the generic model only considers efficient processes and best practices. When model

results are compared to historical performance, decision makers are able to quantify the

effect of existing poor practices on their performance and decision making. The tool

enables users to base their tactical level decisions on the assumption that good practices

and procedures are followed.

iii

Dedication

To my husband Sal Stranges, my parents Ghislaine Cleiren and Jan Sniekers and my

sister Karen Sniekers for supporting me through this journey.

iv

Acknowledgements

First, I would like to thank my supervisor Professor Michael Carter for his encour-

agement and support throughout this research endeavor. He has been a great mentor in

my academic and industry pursuits. I would also like to thank him for his patience when

I chose to pursue an industry career while completing my PhD. Prof. Carter’s dedication

and enthusiasm for improving Canada’s healthcare system using operation research is

inspiring.

I would also like to thank my doctoral committee members, Professors Chris Beck

and Daniel Frances for their insights into improving the academic rigor of this research.

Further, I would like to acknowledge Erwin W. Hans who acted as the external reviewer;

his comments and appraisal lead to important improvements in the final thesis prod-

uct. Finally, I would like to extend my gratitude to the final member of the doctoral

examination committee Professor Dionne Aleman for her participation and review.

To the granting agencies (HTX and CIHR), hospitals (St. Michael’s, Hamilton Health

Sciences, Mount Sinai Hospital, and William Osler Health System), and industry partner

(Visual8) who contributed both financially and by providing valuable information, data

and feedback for this research program and resulting generic simulation model. I am

indebted to your generosity, without which this research would never have been possible.

Finally, I would like to thank my family and friends who have supported and guided

me to pursue my doctorate. Specifically, I would like to thank my parents, Jan Sniekers

and Ghislaine Cleiren, for their support throughout my academic and personal pursuits,

including many much needed pushes along the way to stretch myself to reach higher

goals.

Finally, a big thank you to my husband, Sal Stranges, for his uplifting and continued

counsel, words of encouragement and love.

v

Contents

1 Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Research Contributions and Objectives . . . . . . . . . . . . . . . . . . . 5

1.4 Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Project Overview and Organisation 7

2.1 Project Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Initial Pilot Model . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.2 Development of the Proposed Generic Model . . . . . . . . . . . . 10

2.1.3 Application to Multiple Sites . . . . . . . . . . . . . . . . . . . . 11

2.1.4 Current and Future Application . . . . . . . . . . . . . . . . . . . 12

2.2 Descriptions of the Hospitals Studied . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Hamilton HS Juravinski Hospital . . . . . . . . . . . . . . . . . . 14

2.2.2 St. Michael’s Hospital . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.3 Mount Sinai Hospital . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.4 William Osler HS Brampton Civic and Etobicoke General Hospitals 16

3 Background and Literature Review 18

3.1 The Perioperative Process . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.1 Patient Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

vi

3.1.2 Pre-Operative Activities . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.3 Operative Activities . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.4 Post-Operative Activities . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Perioperative Decision Making . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 Strategic Perioperative Decisions . . . . . . . . . . . . . . . . . . 22

3.2.2 Tactical Perioperative Decisions . . . . . . . . . . . . . . . . . . . 22

3.2.3 Operational Perioperative Decisions . . . . . . . . . . . . . . . . . 23

3.3 Review of Models on Perioperative Planning and Scheduling . . . . . . . 23

3.3.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.4 Review of Existing Scheduling Tools and Software . . . . . . . . . . . . . 35

3.5 Review of Generalised Models and Frameworks . . . . . . . . . . . . . . 36

3.5.1 Defining a Generalised Model . . . . . . . . . . . . . . . . . . . . 36

3.5.2 Generalised Models and Frameworks within Healthcare . . . . . . 38

3.5.3 Generalised Models and Frameworks outside of Healthcare . . . . 43

3.5.4 Design Concepts for Generic Models . . . . . . . . . . . . . . . . 44

3.5.5 Validation and Verification of Generic Models . . . . . . . . . . . 47

3.5.6 Cost-Benefit Analysis of Generic Models . . . . . . . . . . . . . . 48

4 The Proposed General Model 51

4.1 The Generic Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.1.1 Model Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.1.2 Model Scope, Level of Detail, Assumptions and Simplifications . . 52

4.1.3 Model Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.1.4 Model Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.2 Application of the Generic Model . . . . . . . . . . . . . . . . . . . . . . 66

4.2.1 Use of the Model at Multiple Sites . . . . . . . . . . . . . . . . . 66

4.2.2 Issues Experienced and Changes Required while Implementing . . 70

4.2.3 Limitations Noted . . . . . . . . . . . . . . . . . . . . . . . . . . 73

vii

4.3 Cost Effectiveness of the Generic Model . . . . . . . . . . . . . . . . . . . 75

4.3.1 Cost analysis at six hospitals . . . . . . . . . . . . . . . . . . . . . 79

4.4 Proposed Guidelines for Designing Generic Models . . . . . . . . . . . . . 82

4.4.1 Clearly Define the Problem Description, Scope, Objectives, etc. . 82

4.4.2 Study Multiple Sites Prior to Design . . . . . . . . . . . . . . . . 83

4.4.3 Keep it Simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.4.4 Collaborate with End Users . . . . . . . . . . . . . . . . . . . . . 85

5 Generic Model Validation 86

5.1 Validation at the Test Sites . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.1.1 Achieving Validity and User Acceptance at Brampton Civic Hospital100

5.2 Challenges of Achieving User Acceptance . . . . . . . . . . . . . . . . . . 110

5.3 Compared to a Specific Model . . . . . . . . . . . . . . . . . . . . . . . . 113

5.3.1 Validity of the Specific Model . . . . . . . . . . . . . . . . . . . . 114

5.3.2 Comparing the Specific and Generic Models . . . . . . . . . . . . 115

5.3.3 Differences in Model Design . . . . . . . . . . . . . . . . . . . . . 117

5.3.4 Challenges Compared to a Specific Model . . . . . . . . . . . . . 117

5.4 Guidelines for Achieving User Acceptance . . . . . . . . . . . . . . . . . 120

5.4.1 Step 1: Assemble an Engaged Working Group . . . . . . . . . . . 121

5.4.2 Step 2: Review of the Generic Conceptual Model . . . . . . . . . 121

5.4.3 Step 3: Calibrate Model . . . . . . . . . . . . . . . . . . . . . . . 122

5.4.4 Step 4: Reconcile Model Results . . . . . . . . . . . . . . . . . . . 123

5.4.5 Step 5: Repeat and Re-evaluate . . . . . . . . . . . . . . . . . . . 124

5.4.6 Step 6: Accept the Model as Correct . . . . . . . . . . . . . . . . 124

5.4.7 Final Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

6 A Decision and Demonstrative Tool: Case Studies 126

6.1 As a Decision Tool at the Juravinski Hospital . . . . . . . . . . . . . . . 127

viii

6.1.1 Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . 127

6.1.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

6.1.3 Application of the Generic Model . . . . . . . . . . . . . . . . . . 131

6.1.4 Results from the Generic Model . . . . . . . . . . . . . . . . . . . 132

6.1.5 Implementation of the Decision . . . . . . . . . . . . . . . . . . . 138

6.1.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

6.2 As a Demonstrative and Decision Tool at William Osler Health Sciences 144

6.2.1 Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . 144

6.2.2 Application of the Generic Model . . . . . . . . . . . . . . . . . . 146

6.2.3 The Generic Model - Results as a Demonstrative Tool . . . . . . . 147

6.2.4 The Generic Model - Results as a Decision Tool . . . . . . . . . . 154

6.2.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

7 Conclusions and Future Work 165

7.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

7.1.1 Additional Functionality and Addressing Limitations . . . . . . . 169

7.1.2 Development of a Commercial Product . . . . . . . . . . . . . . . 169

7.1.3 Additional Uses of the Model . . . . . . . . . . . . . . . . . . . . 171

Bibliography 174

Appendices 186

A Conceptual Model Tables 186

B Change Database 208

C Generic Model Detailed Description 214

C.1 Introduction to the Proposed Framework . . . . . . . . . . . . . . . . . . 214

C.2 Overall Framework Structure . . . . . . . . . . . . . . . . . . . . . . . . 214

ix

C.2.1 Flow of Patients and Information . . . . . . . . . . . . . . . . . . 216

C.2.2 Modelled Patients . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

C.3 General Model Set Up Information . . . . . . . . . . . . . . . . . . . . . 221

C.4 Pre-surgical Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

C.4.1 Pre-Surgery Module . . . . . . . . . . . . . . . . . . . . . . . . . 223

C.5 The Surgical Day Processes . . . . . . . . . . . . . . . . . . . . . . . . . 233

C.5.1 Surgical Day Module . . . . . . . . . . . . . . . . . . . . . . . . . 233

C.6 Post Surgical Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

C.6.1 Post-surgery Module . . . . . . . . . . . . . . . . . . . . . . . . . 236

C.7 Hospital Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

C.7.1 The Operating Room Resource . . . . . . . . . . . . . . . . . . . 243

C.7.2 Bed Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

C.8 Start of the Day Module . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

C.8.1 Step 1: Generate the OR schedule . . . . . . . . . . . . . . . . . . 250

C.8.2 Step 2: Schedule patients . . . . . . . . . . . . . . . . . . . . . . . 250

C.8.3 Step 3: Bed Management . . . . . . . . . . . . . . . . . . . . . . 250

C.9 Scheduling Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

C.9.1 Schedule Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

C.9.2 Scheduling Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

C.9.3 Daily Schedule Creation . . . . . . . . . . . . . . . . . . . . . . . 268

C.9.4 Elective Patient Scheduling Algorithm . . . . . . . . . . . . . . . 268

C.10 Additional Framework Details . . . . . . . . . . . . . . . . . . . . . . . . 270

C.10.1 Determine next OR Activity Decision Tree . . . . . . . . . . . . . 270

C.10.2 Further Information about Cancellations . . . . . . . . . . . . . . 273

C.11 Framework Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

C.11.1 Wait List Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

C.11.2 Cancellation Report . . . . . . . . . . . . . . . . . . . . . . . . . 277

x

C.11.3 OR Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

C.11.4 PACU Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

C.11.5 Ward, ICU and SDU Reports . . . . . . . . . . . . . . . . . . . . 281

C.11.6 Throughput Report . . . . . . . . . . . . . . . . . . . . . . . . . . 282

C.11.7 Census Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

D Generic Model Implemented in Simul8 284

D.1 Screen Shots of the Generic Model Implemented in Simul8 . . . . . . . . 284

E Juravinski Process Map 288

F St. Mike’s Process Map 292

G Mt. Sinai Process Map 297

H William Osler Process Map 302

xi

List of Tables

2.1 Key characteristics of the hospitals studied. . . . . . . . . . . . . . . . . 13

4.1 Costs (in terms of time spent) of the specific model applied to the Juravin-

ski orthopaedic service and the generic model applied to seven instances

at six hospital sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.1 Validation results from the Juravinski Hospital’s all services generic model

application. Bold type indicated when the confidence interval from the

model results does not include the historical value. . . . . . . . . . . . . . 90

5.2 Validation results from St. Mike’s Hospital all services generic model ap-

plication - Throughput. Bold type indicated when the confidence interval

from the model results does not include the historical value. . . . . . . . 91

5.3 Validation results from St. Mike’s Hospital all services generic model ap-

plication - Cancellations. Bold type indicated when the confidence interval


5.4 Validation results from Mt. Sinai Hospital general surgical service generic

model application. Bold type indicated when the confidence interval from

the model results does not include the historical value. . . . . . . . . . . 93

5.5 Validation results from Prince Albert Hospital generic model application.

Bold type indicated when the confidence interval from the model results

does not include the historical value. . . . . . . . . . . . . . . . . . . . . 94

xii

5.6 Validation results from Brampton Hospital generic model application -

Throughput. Bold type indicated when the confidence interval from the


5.7 Validation results from Brampton Hospital generic model application -

Cancellations. Bold type indicated when the confidence interval from the


5.8 Validation results from Etobicoke Hospital generic model application -

Throughput. Bold type indicated when the confidence interval from the


5.9 Validation results from Etobicoke Hospital generic model application -

Cancellations. Bold type indicated when the confidence interval from the


5.10 First attempt at validating at Brampton Hospital using the Fall 2009 MSS

schedule as planned. Bold type indicated when the confidence interval


5.11 First attempt at validating at Brampton Hospital using the Fall 2009 MSS

schedule as planned - Cancellations. Bold type indicated when the confi-

dence interval from the model results does not include the historical value. 102

5.12 Second round at validating at Brampton Hospital using the November

2009 MSS schedule as a representative schedule for Fall 2009. Bold type

indicated when the confidence interval from the model results does not

include the historical value. . . . . . . . . . . . . . . . . . . . . . . . . . 107

5.13 Second round at validating at Brampton Hospital using the November 2009

MSS schedule as a representative schedule for Fall 2009 - Cancellations.

Bold type indicated when the confidence interval from the model results

does not include the historical value. . . . . . . . . . . . . . . . . . . . . 108

xiii

5.14 Comparing validation results of the specific model to the generic model for

the Juravinski Hospital’s orthopaedic service application. Bold faced types

is used to indicate when the historical value is outside of the confidence

interval produced by the model. . . . . . . . . . . . . . . . . . . . . . . . 116

5.15 Comparing the challenges faced when modelling perioperative services,

using the proposed generic model and to using a specific, custom made

model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

6.1 The percent change compared to the base case for three of the scenarios

considered by the Juravinski - Throughput . . . . . . . . . . . . . . . . . 135

6.2 The percent change compared to the base case for three of the scenarios

considered by the Juravinski - Cancellations . . . . . . . . . . . . . . . . 136

6.3 Demonstrative Tool Report - Illustrating the effect of poor practices on

throughput volumes at Brampton. . . . . . . . . . . . . . . . . . . . . . . 149

6.4 Differences in elective OR time by service from the MSS to actual in April-

May 2010. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

6.5 The proposed base MSS for Brampton based on the demonstrative results

from the generic model. . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

6.6 The predicted throughput and cancellation rates achievable from the pro-

posed base MSS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

6.7 Model throughput results from short term MSS changes. . . . . . . . . . 156

6.8 Model cancellation rate results from short term MSS changes. . . . . . . 157

6.9 Results from comparing orthopaedic scenarios varying the number of TJR

reserved blocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

A.1 Model scope: components identified within the boundary of the study. . . 186

A.2 Level of detail: detail included for each component included in the model. 190

A.3 Model Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

xiv

A.4 Model Simplifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

B.1 Change data base. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

C.1 I: Wait List Expiry Information - Elective/ Urgent/ Inpatient . . . . . . 218

C.2 I: Patient Input File - Elective/Inpatient/Urgent . . . . . . . . . . . . . . 220

C.3 I: Wait List Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

C.4 I: General Simulation Information . . . . . . . . . . . . . . . . . . . . . . 222

C.5 I: Model Initialisation - Wait List Sizes . . . . . . . . . . . . . . . . . . . 222

C.6 I: Arrival Patterns - Elective/Inpatient . . . . . . . . . . . . . . . . . . . 224

C.7 M: Current Patient File . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

C.8 I: Urgent Patient Scheduling Rules . . . . . . . . . . . . . . . . . . . . . 230

C.9 I: Inpatient Scheduling Rules . . . . . . . . . . . . . . . . . . . . . . . . . 232

C.10 I: Off-Servicing Nurse Ratios . . . . . . . . . . . . . . . . . . . . . . . . . 235

C.11 I: Turnover Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

C.12 I: Post OR Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

C.13 I: Allowable Wait for PACU . . . . . . . . . . . . . . . . . . . . . . . . . 240

C.14 I: Off-servicing Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

C.15 I: Resources to Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

C.16 I: Resource PACU - weekday/weekend . . . . . . . . . . . . . . . . . . . 246

C.17 I: PACU on call flag - weekday/weekend . . . . . . . . . . . . . . . . . . 246

C.18 I: Bed Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

C.19 I: Non-surgical Patient Bed Occupancy - Ward/SDU/ICU . . . . . . . . 249

C.20 I: Urgent Patient Arrival Information . . . . . . . . . . . . . . . . . . . . 252

C.21 M: Beds Available Today - Ward/ICU/SDU . . . . . . . . . . . . . . . . 253

C.22 I: Schedule - Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

C.23 I: Schedule - Function and Service . . . . . . . . . . . . . . . . . . . . . . 256

C.24 I: Schedule - Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

xv

C.25 I: Schedule - Surgeons . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

C.26 I: Schedule - Surgeons # ORs . . . . . . . . . . . . . . . . . . . . . . . . 259

C.27 M: Schedule - Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

C.28 M: Schedule - Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

C.29 M: Schedule - Surgeon . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

C.30 M: Schedule - Time Remaining . . . . . . . . . . . . . . . . . . . . . . . 262

C.31 M: Schedule - Patients . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

C.32 I: Scheduling Rules List . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

C.33 I: Scheduling Rules Schedule . . . . . . . . . . . . . . . . . . . . . . . . . 265

C.34 M: Schedule Rules Tracking . . . . . . . . . . . . . . . . . . . . . . . . . 265

C.35 I: Scheduling Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

C.36 I: Overtime Allowance - Elective/Urgent/Inpatient . . . . . . . . . . . . 272

C.37 I: Other Cancellations - Elective/Inpatient/Urgent . . . . . . . . . . . . . 274

C.38 M: Wait List Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

C.39 O: Wait List Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

C.40 O: Cancellation Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

C.41 O: OR Report - Utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 279

C.42 O: OR Report -Over and Under Time . . . . . . . . . . . . . . . . . . . . 280

C.43 O: OR Delay Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

C.44 O: PACU Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

C.45 O: PACU Report - Diverts . . . . . . . . . . . . . . . . . . . . . . . . . . 281

C.46 O: Ward/ICU/SDU Report . . . . . . . . . . . . . . . . . . . . . . . . . 282

C.47 O: Throughput Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

C.48 O: Census Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

xvi

List of Figures

1.1 Top nine reasons for cancellations in the NHS. . . . . . . . . . . . . . . 4

1.2 Reasons for delay throughout perioperative patient flow according findings

from the SPAI report. (Zellermeyer, 2005) . . . . . . . . . . . . . . . . . 5

3.1 The three stages of perioperative activity. . . . . . . . . . . . . . . . . . . 19

4.1 High level surgical patient flow and generic model boundary shown. . . . 53

4.2 Pictorial summary of perioperative processes included and excluded in the

proposed generic model. . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.3 A more detailed pictorial summary of components included and excluded

in the proposed generic model. . . . . . . . . . . . . . . . . . . . . . . . . 56

4.4 Summary of model inputs of the proposed generic perioperative simulation

model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.5 Definitions of variables for cost analysis. . . . . . . . . . . . . . . . . . . 76

5.1 Example of a report provided for validation analysis comparing the amount

of time booked by surgeon versus the amount of time actually used during

elective block time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

5.2 Example of a report provided for validation analysis comparing the per-

centage of patients by surgeon historically and within the input patient

file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

xvii

5.3 Comparing the specific and generic model in terms of areas included and

key assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

6.1 Daily midnight census results from selected scenarios presented to Juravin-

ski Hospital. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

6.2 Comparing average daily unit census of the simulation model and the

seven-week trial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

6.3 Emergency Department length of stay during the trial compared to the

previous year. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

6.4 Model average census results from short term MSS changes. . . . . . . . 157

6.5 Total average census by service as predicted from the Monte Carlo bed

model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

6.6 Difference in average census results from long term orthopaedic MSS changes.162

C.1 The overall view of the framework, showing the three modules’ patient flows.215

C.2 Legend of shapes used in the pictorial framework. . . . . . . . . . . . . . 216

C.3 The pre-surgery module. . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

C.4 The elective patient management sub-module. . . . . . . . . . . . . . . . 227

C.5 The urgent patient management sub-module. . . . . . . . . . . . . . . . . 229

C.6 The inpatient management sub-module. . . . . . . . . . . . . . . . . . . . 232

C.7 The surgical day module. . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

C.8 The OR Activities sub-module. . . . . . . . . . . . . . . . . . . . . . . . 234

C.9 The post-surgery module. . . . . . . . . . . . . . . . . . . . . . . . . . . 237

C.10 The determine next location decision tree. . . . . . . . . . . . . . . . . . 239

C.11 The Determine Next Activity Process. . . . . . . . . . . . . . . . . . . . 271

D.1 Screen shot of generic model in Simul8. . . . . . . . . . . . . . . . . . . . 285

D.2 Screen shot of generic model in Simul8 - focused in on arrival processes

and waiting lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

xviii

D.3 Screen shot of generic model in Simul8 - focused in on post-surgical units

(ICU, SDU, ward and flex beds) . . . . . . . . . . . . . . . . . . . . . . . 286

D.4 Screen shot of generic model in Simul8 - focused in on operative day pro-

cesses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

E.1 The pre surgical patient flow at Juravinski. . . . . . . . . . . . . . . . . . 288

E.2 The scheduling details at Juravinski. . . . . . . . . . . . . . . . . . . . . 289

E.3 The pre-op clinic details at Juravinski. . . . . . . . . . . . . . . . . . . . 289

E.4 The surgical day patient flow at Juravinski. . . . . . . . . . . . . . . . . 289

E.5 The decision tree on whether to proceed with a case, at Juravinski. . . . 290

E.6 The patient flow and decisions made during the procedure at Juravinski. 290

E.7 The post surgical patient flow at Juravinski. . . . . . . . . . . . . . . . . 291

F.1 The pre surgical patient flow at St. Mike’s. . . . . . . . . . . . . . . . . . 292

F.2 The elective patient scheduling process map at St. Mike’s. . . . . . . . . 293

F.3 The inpatient patient scheduling process map at St. Mike’s. . . . . . . . 293

F.4 The urgent patient scheduling process map at St. Mike’s. . . . . . . . . . 294

F.5 The surgical day process map at St. Mike’s. . . . . . . . . . . . . . . . . 294

F.6 The decisions made the morning of surgery at St. Mike’s. . . . . . . . . . 295

F.7 The process map within the OR at St. Mike’s. . . . . . . . . . . . . . . . 295

F.8 The decision tree to determine the next OR activity at St. Mike’s. . . . . 296

F.9 The post-surgical day patient flow at St. Mike’s. . . . . . . . . . . . . . . 296

G.1 The process flow map for DS patients at Mt. Sinai. . . . . . . . . . . . . 298

G.2 The process flow map for SDA patients at Mt. Sinai. . . . . . . . . . . . 299

G.3 The process flow map for inpatients at Mt. Sinai. . . . . . . . . . . . . . 300

G.4 The process flow map for urgent patients at Mt. Sinai. . . . . . . . . . . 301

H.1 The pre-operative process flow map for elective patients at William Osler. 303

xix

H.2 The pre-operative process flow map for urgent and inpatients at William

Osler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

H.3 The operative (day of surgery) process flow map for patients at William

Osler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

H.4 The post-operative process flow map for patients at William Osler. . . . 305

xx

Chapter 1

Introduction

To aid in perioperative tactical decision making, a generic simulation model of peri-

operative patient flow is proposed. The value of the model is demonstrated through

application to multiple sites to inform decisions and demonstrate possible best practice

performance. Being a generic model does not significantly impact the value, validity or

cost effectiveness of the model compared to a specific model.

1.1 Motivation

Over the last decade many countries, including Canada, have been concerned with the

amount of time their citizens wait for medical procedures and diagnostics such as surg-

eries, emergency department visits, and MRI and CT scans. Countless improvement

initiatives, money and time have been dedicated to reducing the amount of time patients

must wait.

Beginning in 2004 the Ontario provincial government chose to focus on five key wait-

ing lists: joint replacements, cardiac procedures, cancer procedures, cataract procedures

and MRI diagnostics. The government set up the Wait Time Initiative, which involved

contracting hospitals to meet specified volumes often with financial incentives attached

to meeting the target. If the hospital failed to meet the target, they could face potential

1

Chapter 1. Introduction 2

claw-back of the money received, and a reduced funded target the following year. If the

hospital exceeded their target, they could receive additional money and a higher tar-

get the following year. The initiative also included the development of a province-wide

Wait Time Information System (WTIS) that was later expanded to include all surgical

procedures (MacLeod et al., 2009).

Additionally, Ontario formed expert panels on a number of key areas within the health

care system to provide recommendations and to identify further areas of improvement.

One such panel was the Surgical Process Analysis and Improvement Expert Panel (SPAI).

In 2005, SPAI reported on 22 recommendations; recommendation 12, which is part of

the motivation of this thesis, reads as follows:

The Ministry of Health and Long-Term Care develop a request for pro-

posals to support the development of a Peri-Operative Simulation System

that would be accessible to all Ontario hospitals, and could be used by Local

Health Integration Networks for planning purposes. Hospitals should use this

system to simulate the impact peri-operative decisions after they have mapped

and clearly understand their peri-operative processes (see Recommendation

3). (Zellermeyer, 2005, p. 35)

This recommendation proposes that a patient-level model be created that will allow

hospitals to review and test changes to their processes and procedures in order to improve

the flow of surgical patients. The panel identified that the advantage of simulation is that

it allows one to run a number of different improvement ideas quickly and analyse outputs

without affecting patient care until a good choice is made. For example, the hospital

“can identify the impact of ten additional total joint cases per week on a hospital’s peri-

operative services (e.g. on pre-assessment services, operations, recovery room resources,

post-surgical bed utilisation, and wait times for other types of patients). (Zellermeyer,

2005, p. 34)” The model would serve as a decision making tool for managers to become

proactive instead of reactive about resource planning and reaching volume and wait time


targets.

SPAI further identified in recommendation three that in order to properly understand

their processes and issues, hospitals should map out their current processes in order to

analyse the results and “systematically identify areas for improvement” (Zellermeyer,

2005, p. 22). This ties in with the simulation model, as a detailed understanding of the

processes and issues is needed in order to accurately simulate patient flow.

SPAI identified that many hospitals do not have the capability to design and imple-

ment their own simulation model. Hence, the panel recommended that the Ministry of

Health and Long Term Care (MOHLTC) fund the development of a generic simulation

model that can be easily implemented at any Ontario hospital.

It is within this spirit that this research endeavour began; with the overreaching idea

to develop a generic model that could be commercialised to support hospitals in their

surgical patient flow planning. Moreover, partnering with hospitals, grant agencies and

a local simulation software consultancy group to encourage potential future commercial-

isation of the generic model.

1.2 Background

The peri-operative process refers to all the activities that occur from the time the decision

to perform surgery has been made up to and including any immediate post-operative

recovery. It can be sub-divided into three processes (Zellermeyer, 2005):

• Pre-Operative: diagnostics, routine testing, patient education, preparation for surgery

and preparation for discharge from the OR and hospital;

• Operative: the surgical day;

• Immediate Post-Operative: recovery room/post-aesthetic care unit (PACU).


Formally, the perioperative process does not include critical care, general ward units,

and discharge to home care, long-term care and rehabilitation. Many surgical models and

discussions find access to these beds out of scope when considering solutions to improving

perioperative patient flow. However, there is a significant amount of interrelatedness and

influence that these resources impart on perioperative flow. For example, many hospitals

experience a high surgical cancellation rate due to the lack of availability of ward or

critical care beds.

Due to the complexity of surgical care and the numerous players and resources re-

quired to complete a case, many bottlenecks exist; impeding flow through delays, cancel-

lations and inefficiencies. An NHS study found that more than 50% of surgical cancel-

lations were due to non-clinical reasons (Modernisation, 2001). Figure 1.1 lists the top

nine reasons for same-day cancellations found by the NHS. Five of the reasons are within

control of the hospital and physicians, accounting for 44% of cancellations. These five

can be reduced through improved co-ordination and planning.

0.00% 5.00% 10.00% 15.00% 20.00% 25.00%

inconvenient appointment

emergency/trauma case

equipment failure/unavailable

surgeon unavailable

no longer required

list overruns

unfit

no shows

no ward bed

Top Reasons for Surgical Case Cancella3ons in the UK

Figure 1.1: Top nine reasons for cancellations in the NHS.


The SPAI report identified many reasons that can cause procedures to be delayed or

cancelled throughout the perioperative flow, as demonstrated in figure 1.2 (Zellermeyer,

2005). These delays can all be considered under the control of the hospital and are

symptoms of underlying processes and procedures. Effort to reduce the occurrence and

severity of these delays is key to improving surgical patient flow. However, caution is

required to avoid reducing one delay at the expense of increasing the occurrence of another

type of delay somewhere else along the process. Further background on the perioperative

process is provided in chapter 3.Section C: The Context For Surgical Process Analysis and Improvements

!""#$%&'#(

)*+',-.#/&'%0#(

((-.#/&'%0#(()/#,-.#/&'%0#( )*+',-.(

1#2*0#/3(

! Patient does not show up

! Patient not screened

appropriately to ensure

readiness for surgery

! Patient and family not

educated to understand

procedure and participate in

care

! Incomplete diagnostic tests

! Paperwork incomplete

! Chart incomplete/not

reviewed

! Discharge process not begun

for in-patients

! Home care not arranged for

out-patients

)*'#4'%&5(65*27&8#+(95*48(':#()#/%,-.#/&'%0#(;'&8#((

! Surgeon not available

! Anesthesia not available

! Other members of surgical

team not available

! OR not prepared (supplies,

instruments, case carts)

! Insufficient time scheduled for

the surgeries

! Inaccurate scheduling or

booking

! Cases not sequenced into

blocks

! Number of cases capped

! Equipment failure

! Insufficient capacity (staff,

supplies, instruments, blood)

! Instrument tray inaccurate

! No flex for emergency cases

! Poor communications

! Post-anesthetic care unit or

critical care bed unavailable

! Insufficient nursing and post-

op staff

! Patient not discharged in a

timely fashion

! Transport delays

! Inappropriate utilisation of

post-op resources

! No ward bed

! Non-surgical

patients in

surgical beds

! No home

care

! No rehab

bed/service

! No long-

term care

bed

<=! 9>(->?-!>?(@-AB;(->()9C!D>C(;9@DCE((

International research indicates that the rate of potentially avoidable adverse events in

hospitals ranges from 7.5% to 17% of all hospital admissions.8 The recent Canadian

study of adverse events reported that 43% of adverse events among hospital patients were

related to surgery.9

Preventing and controlling infections is critical for patient safety. According to the

Institute for Healthcare Improvement (IHI), 40 to 60 percent of clean case infections are

preventable.10

Surgical site infections are the second most common adverse event in

hospitalised patients,11

and are known to increase mortality, readmissions, length of stay

8 Baker GR, Norton PG et al. “The Canadian Adverse Events Study: the incidence of adverse events among

hospital patients in Canada” CMAJ 2004; 25 May 170 (11): 1678-1686. Carthey J “Institutional Resilience

in Healthcare Systems” Quality in Health Care 2001; 10: 29-32. Leape LL, Berwick DM “Safe Health

Care: Are We Up to It?” British Medical Journal 2000; 320: 725-726. Vincent C et al. “How to Investigate

and Analyse Clinical Incidents: Clinical Risk Unit and Association of Litigation and Risk Management

Protocol” British Medical Journal 2000; 320: 777-781. 9 Baker GR, Norton PG et al., Ibid. 10 Institute for Healthcare Improvement. Getting Started Kit: Prevent Surgical Site Infections How-to

Guide. 100,000 Lives Campaign. www.ihi.org/IHI/Programs/Campaign/ 11 Brennan, New England Journal of Medicine 1991; 324: 370-376.

17

Figure 1.2: Reasons for delay throughout perioperative patient flow according findings

from the SPAI report. (Zellermeyer, 2005)

1.3 Research Contributions and Objectives

The work proposed herein contributes to healthcare modelling research in the following

three ways:

1. The model itself: The proposed generic model contributes to the healthcare oper-


ational research field by demonstrating that a generic model of a complex healthcare

system process is feasible. Moreover, a generic model can be meaningfully applied

to multiple sites to influence and inform decisions.

2. A validation process for generic modelling of large, complex real world

systems: A validation and reconciliation schema is proposed to provide guidance

on how to convince end-users (decision makers) that results are reasonable and

trustworthy, even if statistical prediction error remains.

3. An effective decision and demonstrative tool applied successfully to mul-

tiple sites: The generic model has been proven to support decision makers as a

decision and negotiation tool by allowing comparisons of decision options against

multiple selected key performance indicators. In addition, the generic model has

proven useful as a tool to quantify inefficiencies in current practices by demonstrat-

ing possible performance if those practices were improved.

1.4 Layout

The purpose of this document is to provide details into the contributions of this research.

Chapters 4, 5 and 6 will provide these details and relevant discussion. Before delving

into these discussions, an overview of the research project and participating hospitals is

provided in chapter 2. Next, a background on perioperative process and a review of the

relevant literature is provided in chapter 3. Limitations and future work are discussed in

the final chapter (chapter 7).

Chapter 2

Project Overview and Organisation

The purpose of this chapter is twofold. First it offers a brief history of the research

project in terms of what tasks were performed, their sequence and which research team

member(s) completed the tasks. Afterwards, a short description of the key characteristics

of each hospital involved in the study is provided.

2.1 Project Organisation

The research project began in the fall of 2005 when the idea to design a generic model

was formed based on one of the recommendations from the Surgical Process Analysis

and Improvement (SPAI) Expert Panel Report. The research began with an extensive

literature search for existing generic models of surgical processes and other healthcare

systems. A search of existing software was also conducted. The purpose of the literature

and software investigation was threefold. First, to determine if such a model already

existed or could be created based on an already existing tool. Second, to gather insight

on the complexities, lessons learned, etc. of modelling perioperative systems. Finally, to

learn about typical perioperative processes, procedures and best practices.

In 2006, three initial hospitals were recruited as pilot sites for the generic model: the

Juravinski Hospital of Hamilton Health Sciences, St. Michael’s Hospital in Toronto, and

7

Chapter 2. Project Overview and Organisation 8

Mount Sinai Hospital in Toronto. Together with the simulation consulting firm Visual8,

an industry partner research grant was awarded for the development of a prototype

model. Furthermore, the intent of this development is that the industry partner, Visual8,

would work towards commercialisation of the resulting prototype model. This allowed

for considerable resources to aid the study in terms of funding to recruit research team

members, including a simulation model programmer, research students to conduct data

collection and analysis, and technical and programming support for the chosen simulation

model platform, Simul8.

2.1.1 Initial Pilot Model

At Juravinski, this research project was part of a larger hospital-wide process improve-

ment initiative called the Innovation and Learning initiative (I&L). Accordingly, a large

working group was assembled to support the project and make changes to processes and

policies to improve surgical patient flow. The scope of the working group also included

other operational process improvement initiatives within surgical care. The working team

included administrators and nursing leaders from the surgical and inpatient areas; physi-

cians, including surgeons and anaesthesiologists; decision support (data) department

staff; and quality and patient safety department staff. The advantage of this working

group was that much of the information and data was available through the members of

the group, plus the team had the authority to make decisions. Unfortunately a similar

working group was not available at the other two sites and therefore a full impact analysis

could not be performed at St. Michael’s and Mount Sinai Hospitals.

For each hospital, the first step was to create a process map of their surgical patient

flow. This was done through an intensive information collection endeavour including

interviews with hospital staff (front line staff, managers, surgeons, etc.); observation of

processes and patients through their stay; and analysis of patient level data. Process maps

were reviewed with and approved by key stakeholders for accuracy and completeness.


In addition, a needs/wants assessment was conducted with the key stakeholders at

each hospital. The purpose of this assessment was to determine what type of questions

they would like to “ask” the model, what measures are important in their decision making

and what type of decision options they would like to input into the model.

At this time, inquiry into electronic data sets at each hospital was made to determine

what data was stored. This included not only what fields but also the format of each

field and the accuracy of the data. This information was used to guide the input data

requirements of the simulation model.

The next step was to build a model of the patient flow at Juravinski as an initial

pilot to gain understanding of what is entailed in modelling perioperative patient flow

for tactical decisions. In order to contain the scope and complexity of the pilot model,

only orthopaedic surgical patient flow was considered. The pilot model was created based

on the process map and the results of the needs/wants assessment. The pilot model was

largely coded by the simulation modeller, Carolyn Busby, with guidance based on a draft

conceptual model, the process map and notes, and model requirements.

Based on the objectives and goals of the Juravinski working group, three sets of out-

come measures were chosen: throughput, cancellation rates and ward census. Due to the

MOHLTC wait times initiative that provided additional funding for specific procedures,

Juravinski was particularly interested in the throughput (volume) of total joint replace-

ments (TJR) and the number of urgent fractured hip repair cases completed. Therefore,

these two numbers were provided along with the overall throughput and by patient type

(elective, urgent, inpatient). A second chief concern at Juravinski was the number of

cancellations as a result of no available ward or ICU bed for the patient following their

surgery. To monitor this concern, cancellation rates were provided for the following five

reasons: no ward bed, no ICU bed, bumped due to more urgent case, not enough elective

time, and other reasons. Finally, Juravinski was concerned with the number of inpa-

tient beds required to achieve the throughput and cancellation rates desired. The model


provides the average daily midnight census in each ward and ICU to evaluate decision

options.

The orthopaedic pilot model at Juravinski was validated against historical perfor-

mance of throughput and cancellation rates. The validation work with support from

the modeller, Carolyn Busby. Moreover, the validation effort was done with significant

participation from Juravinski stakeholders and the working group in order to understand

and adjust for discrepancies between the model and historical results.

In collaboration with the working group, the resulting validated model was manipu-

lated to test and compare numerous decision options including various schedule changes

and changes to ward capacity. The resulting simulation model continued to be adjusted,

updated and used to influence decisions from when it was first validated in 2007 until

2010.

2.1.2 Development of the Proposed Generic Model

Based on the experience from building the pilot model at Juravinski (see section 5.3),

along with the results of the process mapping, needs/wants assessments, data inquiries

at all three sites, literature review of existing models, and perioperative patient flow

alternatives, an initial conceptual model of the proposed generic model was designed.

This conceptual model was reviewed with the doctoral supervisor, as well as with some

stakeholders at the three hospitals to ensure that it appeared to be sufficiently inclusive

of differing hospital and patient characteristics and that simplifications and assumptions

were reasonable. Details on the proposed generic model are provided in Chapter 4 and

Appendix C.

In 2009, a management consulting company working with William Osler Health Sys-

tem approached the research team for help as they faced many inefficient practices and

poor performance. It was proposed that their two hospitals with surgical sites join the

research study. Funding was provided to re-hire Carolyn Busby to code the generic model


in Simul8. While Carolyn coded the generic model, work with William Osler HS to un-

derstand and map out their processes, analyse the data and create the input files, and

build credibility and trust in the model that was being performed.

In 2010, the generic model was successfully applied to both William Osler HS hospi-

tals: the Brampton Civic Hospital and Etobicoke General Hospital. During the validation

stage, it became clear that the inefficient practices at William Osler HS were making val-

idation challenging. This led to the discovery of a secondary use for the generic model:

to demonstrate the level of performance that can be achieved if practices were improved.

Validation challenges and the use of the model as both a decision and a demonstrative

tool are outlined in Chapters 5 and 6.

2.1.3 Application to Multiple Sites

After application at the two William Osler HS hospitals, the generic model was applied

to the three initial hospitals.

At Juravinski, the working group continued to be involved as they were interested in

understanding interactions between surgical services. They also wanted to update the

model to incorporate changes to their processes and patient mix. Application of the

generic model was performed while working closely with the working group. In addition,

support was provided for testing, creating reports and providing other support. In early

2012, the working group at Juravinski successfully proposed to test one of the decision

options that according to results from the generic model, produced favourable outcomes.

As described in chapter 6, the pilot study proved successful and the changes are still

in effect. At the time of writing, an industrial engineer at HSS was in the process of

updating the data in the model to test new decision options for Juravinski, and also

working to apply the model to the General Hospital of Hamilton HS. They are being

supported by the Centre for Research in Healthcare Engineering (CRHE) and Visual8.

The generic model was also applied to St. Mike’s and Mt. Sinai. However, at these


sites, interest and continued support in the model had dwindled. As a result, the data

and information provided by the hospitals during the initial phase of the research project

was used as model inputs and validation parameters. Testing of decision options or

implementation of any proposed solutions did not occur at these sites.

2.1.4 Current and Future Application

In addition to the five hospitals that were included in the doctoral portion of this research,

the generic model has been applied by CRHE research members to an additional three

sites including Prince Albert Hospital, a small rural hospital in Saskatchewan consisting

of only four ORs.

Finally, Visual8 continues to be interested in creating a commercial version of the

generic model to allow for more widespread application. They are currently working

with CRHE (including the modeller and others who have used the model) and Hamilton

HS to further test and refine the model. The vision is to produce a model with a user

interface that allows for end users to interact more directly with the model to test decision

options.

2.2 Descriptions of the Hospitals Studied

At the time of publication, the generic model proposed herein has been applied to data

at eight hospitals in Canada. The hospitals studied vary widely in size, type, services

provided and population served. Of the eight hospitals studied, this thesis considers the

first five implementations. The other hospitals studied were completed by a researcher

within the CRHE team, with guidance. Table 2.1 provides the different hospital char-

acteristics of the first six hospitals studied. Further detail on each of the hospitals is

provided in the subsections below.


HospitalHospital

Type

Number of

Surgical

Services

Number

of ORs

Number of

Surgical

Inpatient

Beds

Hamilton HS Juravinski

HospitalAcademic 5 8 98

St. Michael’s Hospital Academic 11 22 223

Mount Sinai Hospital Academic 1* 10 112

William Osler HS

Brampton Civic HospitalCommunity 9 16 80

William Osler HS

Etobicoke General HospitalCommunity 7 7 46

Prince Albert Hospital Rural 7 4 30

*Only the General Surgery service at Mount Sinai was studied.

Table 2.1: Key characteristics of the hospitals studied.


2.2.1 Hamilton HS Juravinski Hospital

The Juravinski Hospital is one of three acute hospitals belonging to Hamilton Health

Sciences. Hamilton Health Sciences is an academic research centre affiliated with Mc-

Master University and serves more than 2.2 million people in the Hamilton and Central

South and Central West Ontario area. The Juravinski has a strong orthopaedic program

and is linked with the Juravinski Cancer Centre. The Juravinski is composed of 228

beds with about 9000 admissions and nearly 30,000 emergency department visits per

year (Hamilton Health Sciences, 2011).

The perioperative service is composed of eight operating rooms (ORs), 23 post-

anaesthesia care unit (PACU) beds, as well as 169 budgeted surgical postoperative re-

covery beds in various wards. The Juravinski has two critical care units for a total of 18

critical care beds: an intensive care unit (ICU) with 12 beds and cardiovascular care unit

(CCU) with 6 beds. In addition, Juravinski provides 23 mobile telemetry units available

for patients staying in ward beds who require additional monitoring. These monitoring

units are meant for patients who require some additional care, but at a lower observation

level than intensive and cardiovascular care patients require. This helps reduce the de-

mand on ICU and CCU beds within Juravinski while still allowing access to monitoring

units when required. The perioperative service is composed of seven surgical specialities

who share the resources.

2.2.2 St. Michael’s Hospital

St. Michael’s hospital is located in the downtown core of Toronto and is one of University

of Toronto’s teaching hospitals. St. Mike’s has over 480 adult inpatient beds, includ-

ing around 60 intensive care beds, which together discharge almost 25,000 patients a

year. Additionally, St. Mike’s emergency department sees over 700,000 ambulatory and

emergency cases a year, including more than 500 trauma cases (St. Michael’s Hospital,


2011).

In order to facilitate the over 30,000 surgical procedures each year, St. Mike’s runs

two sets of operating rooms. The core OR consists of sixteen operating suites and is

linked directly to 20 PACU beds and 13 same day surgery beds. The ambulatory OR

consists of six suites, nine PACU beds and 20 same day surgery beds. The ambulatory

OR is normally meant for patients who are to be discharged on the same day as their

procedure (i.e. Same Day Home patients), patients with shorter, less invasive procedures

and patients not requiring anaesthetics. Generally, a patient who is scheduled in one of

the ambulatory ORs will visit the ambulatory PACU. However, in high occupancy times,

patients may be placed in the first bed available, regardless of the OR unit. St. Mike’s

wards are not specifically for surgical patients, but rather programs, such as cardiology,

gynaecology, etc. In general, surgical patients will go to one of eight wards that total

223 beds. Surgical patients who require critical care are sent to one of four critical care

areas, depending on their surgical service and their need for critical care. There are 64

budgeted critical care beds across the four areas.

St. Mike’s uses a regional block room and allows for planned extended stay in the

PACU. The five regional block rooms are used for patients who have their anaesthesia

induced prior to entering the OR in a separate room. This decreases the time between

surgical procedures as the patient enters the room already induced, only needing to be

positioned before the procedure can begin. This affects the flow of these patients as they

are called directly to the regional block room from the waiting area, and proceed to the

OR when it is ready.

Some of St. Mike’s orthopaedic surgeons are scheduled into parallel OR rooms, where

the surgeon is provided two ORs and OR teams. This allows running two case lists, where

the surgeon is able to move between the two OR rooms to perform surgery and supervise

the residents and interns. Since the surgeon is provided two staffed ORs and the residents

can perform cases under his guidance, it allows a surgeon to effectively double his daily


patient throughput.

2.2.3 Mount Sinai Hospital

Mount Sinai Hospital is a University of Toronto affiliated hospitals, also located in down-

town Toronto. Mt. Sinai has 472 beds that serve over 25,000 admissions a year. Mt.

Sinai also runs an ambulatory and emergency service, that sees more than 700,000 visits

per year (Mount Sinai Hospital, 2011). Within the surgical service, Mt. Sinai performs

more than 19,000 operations per year in ten operating rooms. However, for the purpose

of this study, Mt. Sinai asked to only concentrate on their general surgery patient popu-

lation, thus, the focus is on the five operating rooms assigned to general surgery and the

downstream inpatient bed resources. General surgery patients have access to a pool of

ICU beds, SDU beds, PACU and PACU holding beds and day surgery unit beds that are

shared with the other surgical and medical services. There is also an inpatient general

surgical unit of 15 beds.

2.2.4 William Osler HS Brampton Civic and Etobicoke General

Hospitals

William Osler Health System services part of the Greater Toronto Area (GTA) and

surrounding areas and is one of the largest hospital organisations in Ontario. William

Osler HS is composed of three community hospitals: Brampton Civic Hospital, Etobicoke

General Hospital and Peel Memorial Hospital. Surgical services are available at both the

Brampton and Etobicoke sites.

Brampton opened in 2007 to meet the increasing demand in the fast growing city of

Brampton (William Osler Health System, 2012). The perioperative service at Brampton

is composed of 22 ORs, 13 of which were staffed and running during the study. The

perioperative service includes four inpatient areas: the general surgery ward composed


of 28 beds, a surgical observation unit of four beds, 16 short stay unit beds and a 32 bed

orthopaedic surgical ward. For patients requiring critical care, the service has access to

the ICU that consists of 24 beds.

Etobicoke is an older hospital that is currently undergoing extensive renovations

(William Osler Health System, 2012). At Etobicoke, there are seven ORs currently

in operation, one of which is a highly specialised cystology room. The perioperative ser-

vice at Etobicoke operates two inpatient units, a general surgery ward of 26 beds and an

orthopaedic surgical ward of 20 beds. Patients also have access to an ICU and a Cardiac

Care Unit (CCU) of 12 and 6 beds, respectively.

Chapter 3

Background and Literature Review

Before going into detail into the contributions of this dissertation, this chapter serves to

provide a brief description of perioperative processes and decision making, and a review

of the pertinent research related to this work.

The purpose of this literature review is two-fold. First, it aims to give an overview

of recent work in modelling patient flow through perioperative processes for the purpose

of aiding tactical and strategic level decisions. Second, a review of generalised models

and frameworks is provided, focusing on the methodology of designing, validating, and

implementing such models both within and outside of healthcare applications.

3.1 The Perioperative Process

As mentioned previously, the perioperative process can be divided into three different

sets of activity, as described in figure 3.1. Each of these will be discussed in the sections

that follow after an introduction to the typical patient types within perioperative flow.

18

Chapter 3. Background and Literature Review 19

!"#$%&'"()&

*$+#&,-+$%&

.#$+)$(/0&

1$2-+3#$(3%&

4-+5%&

,+67/-8&,-+$%&

$3/9&

1$/6:6"(&3"&

"2$+-3$&

;+$<

=2$+-7>$&

;":3<

=2$+-7>$&

?$/">$+0&

@##$56-3$&

;":3<

=2$+-7>$&

=2$+-7>$&

16:/A-+)$&3"&

A"#$%&8"()&

3$+#&/-+$%&

+$A-B6863-7"(%&

$3/9&

;$+6"2$+-7>$&C3-)$&

Figure 3.1: The three stages of perioperative activity.

3.1.1 Patient Types

Typically, there are three different types of patients within perioperative flow: elective,

urgent/emergent and inpatient.

Elective patients are scheduled for surgery during regular operating room hours.

These patients generally first visit a surgeon at a clinic, where the surgeon determines

that they require surgery. Elective patients remain at home prior to their procedure and

arrive at the hospital a few hours prior to their scheduled procedure start time. They

are also often referred to as same day patients, as they arrive at the hospital the same

day as their procedure.

The second group of patients is emergent and urgent patients. These patients often

present at the emergency department and require surgery within a few hours to a few

days. These patients may require a procedure on a life-or-death basis, while others are

stable enough to wait a day or two. These patients are often admitted to the hospital

prior to their procedure. Their level of urgency determines how long they can wait

before their procedure must begin. Urgent/emergent patients procedures are typically

performed by a surgeon who is working that day or who is on call. For the remainder

of this document, urgent and emergent patients will be collectively referred to as urgent

patients.

Finally, inpatients are those patients who have already been admitted to the hospital


and require surgery, but are not considered urgent. These patients often have been

admitted for some other reason and now require surgery to progress their care. Some

hospitals treat inpatients as part of the urgent population, in their least urgent level, as

they can wait up to a week for their procedure. Other hospitals treat them more like an

elective patient who must be done within a week or so, but should be scheduled within

elective time whenever possible. Regardless of how the patients are scheduled, inpatients

often have a surgeon assigned prior to scheduling, thus cannot simply be grouped with

the urgent patients to be performed by the next available surgeon.

3.1.2 Pre-Operative Activities

Pre-operative patient flow begins when the decision to treat surgically has been made by

the surgeon and patient. This phase of the perioperative service involves all activities up

until the surgical day, including wait list management, scheduling the patient for surgery,

scheduling of and attendance at any pre-operative clinic visits, diagnostic tests, patient

education, and any other preparation required for the surgical procedure or post-surgical

recovery and eventual discharge.

For elective patients, this stage may last several months waiting for their scheduled

date. For urgent patients and inpatients, this stage will last between a few hours to a

week or so, depending on urgency, and the scheduling policies of the hospital.

3.1.3 Operative Activities

The day of surgery includes a number of activities, including registration, patient prepa-

ration, patient positioning, anaesthesia, the procedure itself, and post-surgical recovery.

Co-ordination of the activities on the day of surgery is important to patient flow.

Elective patients arrive on the day of their surgery, generally two or more hours ahead

of their scheduled procedure time to ensure that all pre-surgical activities are complete.

Urgent and inpatients are already registered and in the hospital. They most often stay in


their current hospital location until near the time of their procedure. Delays in patient

flow due to activities done before the patient is in the OR are generally due to poor

co-ordination and/or communication. These problems are generally operational, and can

be reduced through improved co-ordination and communication of staff, equipment and

patients.

Conversely, processes that occur post-procedure can often impede patient flow. For

example, OR delays can occur when the PACU or ICU is full, blocking the OR with a

patient waiting to get into the PACU, ICU or another bed. As mentioned in Chapter 1,

one of the most common reasons for cancellations is due to no bed. Resource capacity

decisions and co-ordination of resources through scheduling policies are made through

tactical level planning.

3.1.4 Post-Operative Activities

In the true sense of perioperative service, post-operative activities only include recovery

immediately following surgery. Typically, this includes the post-anaesthesia care unit

(PACU), the same day surgical area, and perhaps the intensive or cardiac care units

(ICU and CCU).

One of the main bottlenecks to perioperative patient flow however, includes non-

immediate recovery activity, such as step-down units, wards and critical care. To address

this, some hospitals have identified the importance of surgical inpatient units to peri-

operative flow, and have reflected this through their organisational chart and program

structures.

3.2 Perioperative Decision Making

There are three types of decisions that organisations make: strategic, tactical and op-

erational. These three types vary in terms of the types of decisions that are made, and


the frequency of which they are made, and the time horizon of the decision. Naturally,

within perioperative decision making, these same three types apply. This section will

review the types of decisions that are made at each type in terms of the perioperative

processes of a hospital.

3.2.1 Strategic Perioperative Decisions

Strategic decisions are long term decisions, typically made once every few years but

no more than once a year. Strategic decisions have great effect on the perioperative

service’s direction and function as they determine the capacity of resources and the

types of care provided (Wachtel and Dexter, 2008). Perioperative strategic decisions are

“mainly a resource allocation problem” (Guerriero and Guido, 2011, pg. 94) as they

involve decisions regarding the number and types of surgery provided (case mix) or the

amount of resources available. Resource decisions can include procurement or building

of new capacity or equipment, such as MRI, new operating rooms or inpatient beds, or

the availability of existing resources, such as the number of staffed elective OR hours.

3.2.2 Tactical Perioperative Decisions

Tactical decisions are made a few times per year to address “the organisation of the

operations/execution of the health care delivery process (i.e. the ‘what, where, how,

when and who’)” (Hans et al., 2012, pg. 310)’. Tactical decisions include calibrating

OR capacity through the Master Surgical Schedule (MSS) by adjusting the hours/blocks

available for elective cases and the assignment of OR capacity to patient types, services,

and surgeons. Tactical decisions also consider resource capacity adjustments of inpatient

units and ancillary services such as medical imaging and lab (Blake and Carter, 1997;

Hans et al., 2012; Wachtel and Dexter, 2008; VanBerkel et al., 2011b). Tactical capacity

decisions typically involve determining if the resource will be staffed, whereas strategic

capacity decisions determine how many beds/machines/ORs are physically available. In


other words, deciding to build a new OR suite or ward is a strategic decision, whereas

determining when and how much that resource will be staffed, and thus available to be

used, is a tactical decision.

3.2.3 Operational Perioperative Decisions

Finally, operational decisions are made frequently and directly affect the day-to-day

operation of the perioperative service. Operational decisions can be further broken down

into online and offline decisions (Hans et al., 2012, pg. 310).Offline decisions are made in

advance and involve the co-ordination of activities. Scheduling and sequencing of elective

and other planned cases are the main activities of offline decision making. On the other

hand, online decisions are reactive in nature, and involve “monitoring the process and

reacting to unforeseen or unanticipated events”. Examples of online decisions include

scheduling emergency surgeries, cancellation decisions, and use of overtime to complete

cases.

3.3 Review of Models on Perioperative Planning and

Scheduling

The focus of this section of the literature review is on surgical planning and schedul-

ing models within the operational research field. Specifically, surgical planning refers

to matching supply of resources such as operating room time, inpatient beds, equip-

ment, diagnostic imaging tests, etc., with demand. Whereas surgical scheduling seeks

to determine the time and sequence of cases in the operating room (Cardoen et al.,

2010; Guerriero and Guido, 2011). As a result, this review will exclude work on process

improvement, the impact of new medical technologies, estimation of surgical procedure

duration, staff scheduling and facility design. Furthermore, based on the scope of the

research, the review will focus on addressing tactical decisions. If the reader is interested


in strategic and operational decision models, a number of literature reviews have been

published recently (e.g. Guerriero and Guido, 2011; Cardoen et al., 2010)

A significant amount of interest, especially in the past ten years, has been focused on

addressing perioperative tactical planning and scheduling decisions (Guerriero and Guido,

2011). Within the operational research literature, many papers were found that look

solely at the ORs and the effect of changes to the MSS on OR efficiency measures such as

utilisation, over time, or the number of ORs required. Many of these use mathematical

programming to try to find an optimal MSS based on the objective and constraints

considered (e.g. Blake and Donald, 2002; Kharraja et al., 2006; Kuo et al., 2003; Testi

and Tanfani, 2008; Belien and Demeulemeester, 2008; Blake et al., 1995). The effect of

case sequencing guidelines on OR performance has also been considered by some authors

(e.g. Dexter and Traub, 2002; Lebowitz, 2003). These models are interesting in terms of

their choice of variables, objectives, constraints, assumptions, etc., however, they are not

explored further within this literature review as they do not directly consider resources

beyond the operating rooms themselves, which a key goal of this research.

While it may be easier and less complex to limit one’s study to the surgical depart-

ment, or specifically the operating rooms, conclusions may be suboptimal since effects

on other areas are not accounted for (VanBerkel et al., 2010). Studying up and down-

stream resources, in other words a holistic approach, is essential to understanding and

improving surgical patient flow (VanBerkel et al., 2011b; Sobolev et al., 2008). Opera-

tional research papers that consider a holistic view of surgical planning vary in breadth of

inclusion. Some consider a limited breadth by only including immediate downstream re-

sources such as the post-anaesthesia care unit (PACU). Meanwhile, there are some papers

that consider a broader set of resources by not only including immediate post-surgical

recovery but also inpatient resources such as ward and ICU beds.

As noted in a recent review by Guerriero and Guido (2011), the aim of most tactical

decision models is to produce a MSS. Further, various studies note that “an efficient MSS


is obtained when not only demand of [surgical specialities], equipment restrictions, staff

(surgeon-nurse) availability, surgeons preferences but also other resources, such as ICU

and ward capacity are considered.” (Guerriero and Guido, 2011, p.109)’

Many of the perioperative tactical decision models proposed in the literature use

combinatorial optimisation models (i.e. Integer Programming (IP), Mixed Integer Pro-

gramming (MIP), Integer Quadratic Programming (IQP)) to find an optimal or near-

optimal solution (Guerriero and Guido, 2011). The activities, constraints, objectives and

resources included in these models vary widely.

Some models found do not directly include resources outside of the OR, for example

(Zhang et al., 2009) presented a MIP model to set the MSS, taking into consideration the

cost of an inpatient’s length of stay (LOS) by minimising the inpatient’s LOS prior to

surgery, i.e. the patient’s waiting time. Belien and Demeulemeester (2008) proposes an

IP to set the MSS and the inpatient nurse schedule by taking into account the workload

of various surgery types and the requirements from the nurses’ collective agreement.

As noted by Cardoen et al. (2010) and Guerriero and Guido (2011), most models

found in the literature are deterministic, and do not take into account the uncertainty and

variability in demand, LOS, arrival time, no show rate, etc.. For example, three different

models are proposed in Gupta (2007) for perioperative decision making based on three

common problems: allocating time to surgical specialities, managing elective bookings

and sequencing cases. Gupta (2007) proposes to manage elective bookings utilising a

model to determine the amount of downstream resources to reserve for future high-

priority cases, taking into account urgent patient demand and maximum wait allowable

for elective patients before requiring use of overtime in the ward. None of the three

models were applied using real or generated data to test for solvability and usability.

Due to the high cost of hospital resources, such as inpatient beds and the ORs,

utilisation is often considered an important measure to hospital decision makers. Vissers

et al. (2005) formulated a Mixed Integer Linear Programming (MILP) model to determine


the MSS for the cardiothorasic speciality in terms of the number of patients and case

mix to allocate during each OR block. The model takes into consideration the amount

of OR time available, the capacity of the intensive and intermediate care units and the

staffing levels in the ICU. The objective of the model is to minimise the maximum over

and under utilisation of the four resources considered.

Levelling the demand for beds over the days of the week is often considered as an

objective when adjusting the MSS. Belien et al. (2009) proposed a multi-objective MIP

model that assigns the blocks to surgical specialities while minimising the weighted sum

of peaks and variance of bed occupancy of the wards. The goal of this study was to

build an MSS that assigns blocks in a simple and repetitive fashion, assigning OR blocks

to a single surgical service (no sharing a block) and to level the demand for ward beds.

The MIP was applied using real data of a Belgian hospital. The real power of this work

however is not the MIP model proposed, but rather a GUI created to visualise various

proposed MSS and their effect on bed occupancy levels. Belien et al. (2009) propose

that there is no optimal solution as no mathematical program can account for all the

complexities and restrictions of reality, and that the value lies in a decision support tool

that helps compare various MSS options.

The last interesting deterministic model found in the literature is a MIP developed

to consider the system wide trade-offs between OR availability, bed capacity, surgical

booking privileges and wait lists (Santibanez et al., 2007). This model purports to set

the MSS for twelve hospitals within a health authority. The model considers which

surgical speciality can be accommodated in the ORs available, the number of blocks

to assign to each speciality, throughput targets and the capacity of the wards and step

down units. The objective of the model can be to either maximise throughput or level

bed occupancy. This model is also considers the demand for resources of emergency cases

when setting the MSS.

The stochastic models found vary not only in terms of the objective, constraints and


activities considered, but also in what stochastic elements are included. Most models

considered the stochasticity of the inpatient length of stay (Belien and Demeulemeester,

2007; Adan et al., 2009; Calichman, 2005), while one model found considered the stochas-

ticity of the procedure length (van Oostrum et al., 2008b).

Clearly, incorporating stochasticity in the model should improve performance and

provide robust solutions, especially considering the uncertainty in healthcare. When

compared to a deterministic model proposed by Vissers et al. (2005), Adan et al. (2009)

found that incorporating variation into the decision model resulted in better resource

utilisation.

In his paper, Calichman (2005) presents a set of guidelines and sample spreadsheets

for a simple MSS optimisation model that can be adjusted based on the needs and

goals of the hospital . The basic model structure presented includes inpatient LOS

probabilities. Little detail is provided on the formulation behind the model’s spreadsheets

as the purpose is to simply present general guidelines for hospital consultation.

A MIP model and metaheuristic is presented by Belien and Demeulemeester (2007)

that includes stochastic inpatient length of stay with the aim of levelling inpatient oc-

cupancy. The objective of the proposed model is to produce a MSS that minimises the

total expected bed shortage. This model consists of only two sets of constraints: the

surgical service or surgeon block requirements and the total number of blocks available.

Alternatively, accounting for the variability of the procedure length allows for planned

slack in the OR schedule, reducing the need for costly overtime. A two phase mathemat-

ical model using a IP and a MIP to produce a cyclical MSS that levels ICU and ward

workload and minimises the OR capacity required is proposed by van Oostrum et al.

(2008b). This model allocated OR time to the identified elective patient types such that

there is a planned amount of slack in each OR day to account for the uncertainty in case

duration. The objective is to minimise both the amount of OR time required and the

maximum demand of bed resources. Moreover, the model is presented as a case study


at a Dutch hospital that considered levelling the demand for ICU beds (Houdenhoven

et al., 2008).

Another consideration is the welfare or the societal implications of setting a MSS. Testi

and Tanfani (2008), Tanfani and Testi (2010) and Testi et al. (2007) present mathemati-

cal programming models that aim to improve the welfare of the patient by considering the

effect on the patient’s waiting time and access to their surgical procedure. The models

presented propose both the assignment of surgical specialities to blocks of OR time, and

scheduled specific patients to the time, resulting in a tactical and operational decision

making model. The assumption of these models is that an open scheduling method is

employed that allows for flexibility in the speciality assignment each week as based on

realised elective case demand.

Simulation is another popular method and is typically proposed as a decision aid to

compare multiple decision options on a number of different performance indicators. This

method allows for the decision making to remain in the hand of the decision maker who

must weigh the results from the different options and make the final decision. As with

the mathematical programming models proposed, the objectives and considerations in

perioperative simulation models vary widely.

In both simulation and mathematical programming models found, most consider re-

sources downstream from the OR and use statistical distributions to represent upstream

effects (VanBerkel et al., 2010). Only one model was found that included activities that

occur prior to the day of surgery. Vasilakis et al. (2007) studied the effect of scheduling

methods at the surgical clinic on the number of patients waiting for an appointment and

the patients’ waiting time to their first appointment and to their scheduled procedure.

The simulation model included elective, urgent and emergent patient flow for the cardiac

surgical speciality. The model considers a high level view of the operations as it does not

consider detailed processes at the clinic or OR, but rather considers only the schedule

and capacity of the two resources.


A number of the simulation models found focused on tactical resource capacity deci-

sions, such as the number of staffed inpatient beds. For example, several Monte Carlo

simulation models developed studied the relationship between the operating rooms and

recovery rooms. The models were used to determine the number of ORs and recovery

rooms were required to meet increased volumes (Kuzdrall et al., 1981), and how admis-

sion policies and case sequencing could affect volumes and utilisation measures (Kuzdrall

et al., 1981; Kwak et al., 1976).

Another resource decision option considered is the use of a quota system to control

the occupancy of resources by surgical patients. In Kim and Horowitz (2002), a Discrete

Event Simulation (DES) model was built to examine the use of a quota system on the

performance of the ICU. The model also considers the effect of employing a scheduling

window where patients must receive surgery within a specified time from when initially

referred. To evaluate ICU performance the simulation model considers a number of

different outputs including the utilisation, time patients spend in the system, cancellation

rate and volumes. This model was applied and discussed in more detail in a case study

(Kim et al., 2000).

Surgical case sequencing and configuration options for the pre- and post-recovery

areas of an ambulatory surgical centre were evaluated using simulation (Ramis et al.,

2001). The goal of the study was to determine the best process and layout to maximise

throughput of the centre with a fixed number of total beds. Similarly, Marcon and Dexter

(2006) used a DES model to evaluate the effect of sequencing cases on OR utilisation

and overtime and PACU staffing (represented by the number of patients in the PACU

per hour).

In addition to including the PACU, Marcon et al. (2003) and McAleer et al. (1995)

include the porters as a resource in their simulation models. The question posed to

the model by McAleer et al. (1995) was whether surgical throughput could be increased

without additional recovery room (PACU) beds. The model found portering was not


in fact a bottleneck of the system, and instead improvements in throughput could be

achieved through better scheduling practices and process improvement initiatives. On

the other hand, the purpose of the simulation model by Marcon et al. (2003) was to

determine the number of PACU beds and porters required to achieve desired OR and

PACU performance.

A final model found that studied resource capacity and sequencing decisions was

the application of a general hospital simulation framework, PROMPT, to the general

surgery service in the UK (Harper, 2002). The simulation model includes the ORs,

recovery area and inpatient units. The author was interested in the OR and bed capacities

required, cancellation rates and the forecasted patient mix (i.e. type and number of cases

and inpatient versus day patient). Decision options studied included case sequencing

and scheduling rules such as performing admitted cases early in the week. The general

framework applied allows for a high level simulation model where patients are classified

into a number of groups based on characteristics including procedure length, inpatient

length of stay, route and resource requirements.

In addition to resource and sequencing decisions, some simulation models study the

effect of the MSS on performance. One work found compared the OR utilisation, through-

put and number of overruns of the current MSS and a MSS suggested from a previous

study using an IP model (Sciomachen et al., 2005). The simulation model was also used

to study the effect of introducing pre- and post-recovery room areas and case sequencing

in the OR. The decision options were evaluated based on volume, wait list size, number

of delayed cases, the number of OR overruns and OR utilisation.

Alternatively, Lowery (1992) was concerned with both the ORs and the critical care

units of a hospital. The simulation model considered the ORs, PACU, and seven different

types of critical care units. The primary question of this study was to determine the

number of critical care beds required. Since the surgical service has a high demand for

these beds, patient flow from the service was a key input. The model included both


elective and urgent/emergent patient flows from the surgical service as well as other

sources. The surgical elective patient flow was modelled as a function of the MSS and

historical scheduling patterns. The model logic was coded such that when no beds were

available, off servicing patients to another critical care area or discharging patients from

their current level of care early were considered in order to place the patient. Scenarios

of changes to the MSS, other patient flow patterns and number of beds in the units

were evaluated based on unit utilisation, the number of emergent patient turn aways,

the number of patients bumped from the units and the number of patients off serviced.

Unfortunately though the model was useful to hospital decision makers in terms of gaining

understanding of the trade-off between unit occupancy and turn away rates, a decision

on the number of critical care beds based on simulation results had not been made at

the time of publication.

As part of a health district’s cost reduction strategy, the number of beds available

for general and urology surgical services was to be reduced (Wright, 1987). A simulation

model was employed to determine how the reduction in beds and other changes would

effect performance at the hospitals and the district overall. The chief concerns were the

average, minimum and maximum bed occupancy by day of week, the number of admitted

patients per bed, the number of patients off serviced to other units and the number of

rejected cases due to no beds. A number of scenarios were considered in the study

including various reductions in the number of beds within the district, improvement in

LOS, smoothing admissions by performing elective cases on the weekend, changes to the

patient mix and changes to the emergency arrival rate. The model was used by the health

district to help inform decisions on how to implement their bed reduction initiative. The

district plans to continue using the model for future decision making.

Four models were found that included multiple downstream resources and the MSS

within their scope, each using a different solution methodology. First, a discrete event

simulation model was built to evaluate changes to the MSS, surgeon case mix, number


of inpatient beds, and number of nurses scheduled (Blake et al., 1995; Carter and Blake,

2005). The simulation model tracked patients from when they entered the waiting list,

were scheduled for surgery, the procedure itself and recovery afterwards. It also included

a nursing workload model in order to estimate the nurse staffing requirements. The model

included logic to cancel patients if not enough beds or nursing staff were available to care

for them post operatively. In order to make portability and validation easier, the authors

chose to generate patient characteristics such as LOS and route based on a sample of real

patients instead of attempting to fit statistical distributions. During validation of the

model at the sites, it was found that the model helped identify some inefficient practices.

For instance, at one site it was found that the ENT service regularly did not use all the

time assigned to them in the MSS; time which general surgery would often book. This

resulted in the model producing higher than historical throughput values for ENT, and

lower volume of general surgery cases. The model helped not only uncover this practice,

but also quantify the effect on system performance. Finally, the intention of the authors

was to design a generic model that could be applied easily to all four sites under study.

However, they found that the differences in process and model needs between the sites

required significant changes and adjustments to the model. As a result, building a generic

model was not possible in this case.

A software program was developed in Belien et al. (2006) to visually demonstrate

the impact of changes to the MSS on resource utilisation. The deterministic tool was

intended for hospital decision makers to understand the effect of their tactical decisions

on the utilisation patterns of various resources. A user friendly GUI was built that allows

easy changes to the MSS by dragging and dropping OR blocks into the schedule. Users

can view the resulting resource consumption patterns by surgeon, surgical group, day of

week, and OR block. The software was designed with feedback from one of the hospital’s

decision makers, however, has not yet been used on site to help inform decisions.

Another article presented an analytical model of the ORs and inpatient units based


on queueing theory concepts (VanBerkel et al., 2011b). The authors chose an analytical

model as they felt that it could be more precise and be developed faster than a simulation

or other type of model. The arrival rate is based on the inputted MSS and the scheduling

trends of the surgical specialities. The inpatient wards are modelled as infinite servers,

i.e. they can accommodate any number of patients. One of the key objectives of this

model was to understand the effect of changes to the MSS on nursing workload. As

a result, the outputs of the model were chosen in order to predict workload. These

outputs included the number of patients in the system per day in the MSS schedule,

daily occupancy levels in the wards, the daily number of admissions and discharges and

the number of patients in each post-operative recovery day. Working with the decision

makers at the hospital, a new MSS was derived based on the outputs of the model and

the resulting MSS was implemented. In VanBerkel et al. (2011a), the authors compare

the results of the analytical model to 33 weeks of data collected after the new schedule

was enacted. This is one of the only models found that not only reported that a decision

was implemented based on results from the model, but also evaluated the model results

compared to results from implementing the solution.

The final model found considering multiple inpatient units was a Monte Carlo simu-

lation and MIP model to examine the relationship between the MSS and inpatient bed

requirements (Saremi et al., 2013). The purpose of the simulation model is to predict

the bed requirements in the various inpatient units, including ward, step down units and

critical care units. Since the purpose is to determine the demand for beds the simulation

model does not restrain the capacity of the units. Similar to the model engineered by

(Blake et al., 1995), the simulation model randomly selects patients from a patient file of

historical patient records, instead of using a set of statistical distributions to determine

the patient’s characteristics. On the other hand, the purpose of the MIP is to build

a MSS in terms of assigning blocks to surgeons and patient types with the objective

to reduce the peak occupancy levels of the inpatient units. The intention is that the


MIP model is used initially to suggest an optimal schedule, then the simulation model

is used iteratively to test both the MIP-suggested schedule as well as other proposed

schedules to compare performance and ultimately select a schedule to implement. The

two models have been applied to a number of hospitals within a health region. As part of

the application, it was determined that since hospital decision makers are not experts in

mathematical programming, a set of guidelines be presented in place of running the MIP.

These guidelines help identify possible MSS to test in the simulation model. The paper

reports that the two models were successful in demonstrating to decision makers the

effect of MSS decisions on inpatient unit utilisation. A final note, the aim of the model

design was to be transparent and portable which lead to a simple design of both models.

However, during application to the site described in the case study, a few changes to the

models were required.

3.3.1 Summary

In conclusion, a search of the operational research literature found that though there

exists significant demand and focus on improving surgical planning and scheduling deci-

sions, much of the focus has been limited in the breadth of perioperative flow considered.

In other words, very few works consider a holistic approach to surgical decision making

by including perioperative and other hospital resources beyond the OR. In addition, little

attention has been given to creating generalised models that can be applied easily and

cost-effectively to many sites. Finally, only a handful of solutions proposed have been

successfully implemented at the sites under study, indicating the need to ensure solutions

produced are considered credible and useful by hospital decision makers.

One of the challenges faced in healthcare operational research is that many of the

recommendations are not implemented into the decision making and processes of the

hospital. For example, VanBerkel et al. (2011a) found that many studies on improved

MSS were never actually implemented. A key of strategy that has shown to encourage


more implementation in future studies is frequent and meaningful involvement of the

stakeholders and decision makers. Unfortunately, many of the research studies do not

closely involve them. In a review of simulation models of surgical patient flow, Sobolev

et al. (2011) noted that out of the 34 papers reviewed, only 19 were made to meet the

needs of decision makers, and only 9 of those 19 reported that the decision makers were

actually involved in the study. (van Oostrum et al., 2008a, p. 2) also made note of this

phenomenon:

“the influence of various stakeholders, with varying degrees of autonomy,

is often substantial. In the case of OR scheduling, surgical services (with

surgeons, surgery and anaesthesia assistants, and anaesthesiologists), all have

a considerable influence on OR management. Intelligent OR planning and

scheduling approaches proposed in the literature often fail to account for

this, which explains their relatively marginal impact in practice and the small

number of successful implementations in the literature.”

Implementation of a model is futile if the people who they are intended to help are not

considered or involved in the creation of the tool.

3.4 Review of Existing Scheduling Tools and Soft-

ware

A survey of existing commercial products and literature did not produce any commer-

cially available tools that aid in tactical or strategic operating room scheduling decisions.

The search for tactical planning and scheduling decision tools, as described above, has

demonstrated the need for further study into these decisions. There is a noted need

for the development of commercially available products to help inform hospital admin-

istration of policies and methods to determine strategic and tactical policy decisions of


OR scheduling that work towards achieving the overall strategic goals and objectives of

the organisation. In the era of an ageing population and constrained healthcare bud-

gets, improved planning and coordination of operating room scheduling and resources

in conjunction with alignment to the strategic goals of the organisation is imperative to

the financial and operational health of an organisation and of the healthcare system in

general.

3.5 Review of Generalised Models and Frameworks

The theme of this section is two-fold; firstly to briefly describe the work to date in the

field of general simulation models. Secondly, to demonstrate that though many models

exist that claim genericity, there is little done in the way of proposing methods around the

process itself, abstraction decisions and model verification and validation. The discussion

will start with defining generic modelling.

3.5.1 Defining a Generalised Model

A generic simulation model can be broadly defined as a model that is “designed to apply

to a range of systems which have structural similarities (Pidd, 1992, p. 238)”. Lowery

(1998) states that generic models should be “general, flexible, intuitive and simple, and

include default values for system parameters (qtd. in Fletcher and Worthington, 2009,

p. 376)”. Related to generic models is model or code reuse. Reuse can vary from small

portions of code, to entire models (Robinson et al., 2004).

Sinreich and Marmor (2004) use three levels to classify models. The most generic

type, generic activities, is flexible enough for any system and scenario, and requires

the highest level of abstraction. At the other end, models requiring the lowest level of

abstraction are referred to as fixed process. These models can only be used to analyse

the system it was designed for. In the middle are generic process models, which can be


used to model and analyse any system that uses similar processes.

More recently, Fletcher and Worthington (2009) propose a spectrum of genericity

based on previous works in classification of generic models, survey results from experts

and a literature review of generic models. While their research focused largely on simula-

tion within healthcare, the classification system of generic modelling can easily be applied

to simulation modelling as a whole. The authors propose four levels of genericity:

1. A broad generic principle model - This level describes models that are not setting or

industry specific, and are often used to demonstrate general principles. An example

of a level one model is a generalised theoretical queuing model that demonstrates

that as server utilisation increases above 80%, wait times will greatly increase as

well.

2. A generic framework - Level two describes models that have grouped together com-

mon issues within a toolkit. These types of models can be used in combination with

local data and knowledge to build understanding of system issues. The model can

also be used as a base to create a locally specific model, or to demonstrate general

principles similar to level one models. For example, the tool kit can contain a model

of a generic OR that the user can customise with hospital data and information.

The resulting model can be used to demonstrate the effect of OR utilisation on the

number of inpatient beds required.

3. A setting-specific generic model - These are intended to provide general insights

into the issues faced in delivering specific services, such as surgical care. Input data

can be adjusted such that these models can be used multiple times, by multiple

providers of the same service, without changing the model structure. An example

would be a model of a typical emergency department. Users would input data

specific to their hospital, such as the number of physicians, beds, etc. The model

can then be used to gain insights into the processes of the site under study.


4. A setting-specific specific model - Level four models largely differ from level three

models by the objective of transportability. Level four models are created to repre-

sent the particular system under study, with no intent to use it for another system

or provider.

The intention of this research is to design and test a level three generic model of

perioperative patient flow, processes and decisions. For the remainder of this review,

attention will be given to generic models within level three, specifically those intended

for use at a local site level (as opposed for central use by health planning authorities for

example).

3.5.2 Generalised Models and Frameworks within Healthcare

The purpose of this review is first to understand how this research adds to current

literature on generic modelling in healthcare, specifically in perioperative tactical decision

making. Secondly, to gather techniques on generic model design, implementation and

validation.

Generalised Models Focusing on Perioperative Flow

During the review, only one paper was found that set out purposely to create a general

surgical model in collaboration with multiple hospitals. Blake et al. (1995) set out to

create a simulation based decision support tool that modelled the effects on inpatient

bed usage and nursing resources of changes in the operating room block schedule. Based

on their needs, they chose to use the model from Wright (1987) as a base, and add func-

tionality as required. The resulting model followed surgical patient flow from admission

to discharge. The model made use of a GUI that linked a database and a scheduling

model into an animated simulation model. The database populates the model with ac-

tual patient discharge records, the OR schedule and hospital resources levels, including


beds and available nursing staff on each of the surgical wards modelled. The data can

be altered to represent alternative designs of hospitals studied and of possible solutions.

The scheduling model randomly schedules patients into the block schedule and pa-

tients flow through the various departments and areas based on the flow rules and patient

characteristics.

Outputs of this model include admission rates, bed utilisation and staff workload. The

model was validated at the pilot hospital based on the historical admission rate and case

load, by service. The authors note that validation efforts of the model at each site faced

challenges typical to validation of complex, real world systems. Through involvement

with hospital decision makers and thorough analysis of the model, data and processes,

it was determined that the outputted results were credible and realistic. The model was

used at all four sites to propose improved surgical block schedules. Unfortunately, there

was significant resistance from some of the users. As a result, none of the results were

implemented.

The focus of this model was for strategic decisions around surgical scheduling and

resource levels. The paper does not provide any insight into the level of detail modelled

in terms of scheduling and processes. However, based on the information given and its

strategic intention, the model appears to use a simplistic scheduling method and high

level process mapping. Also of note, the model’s structure was used as a base that was

customised to each site, thus was not entirely generic.

Another model found that purported to be general was developed by Saremi et al.

(2013) who presented three simulation-optimisation formulations. While the author’s

intention was to develop a generic model, the paper did not mention any significant

collaboration with hospital decision makers during design. Furthermore, the paper only

mentioned application to a single hospital site.


Generalised Models Focusing on Perioperative Flow or Hospital-wide

Two generic models were found that encompass multiple areas of a hospital. Harper

(2002) created a generic framework to model hospital resources including beds, operating

rooms and workforce needs. This level two model used patient groupings to describe the

different patient groups with similar characteristics and care paths; each with its own

distribution parameters to describe patient characteristics such as length of stay.

The paper claims that any healthcare system, or sub-system can be modelled, from

ORs and inpatient beds, to the complex care pathways of critical care patients, by in-

putting the flow diagram. The resulting model collects resource usage statistics at the

resource and patient level for output statistics and graphs. The paper gives the example

of modelling a high level strategic model of the operating rooms to evaluate the oper-

ating hours, patient mix and scheduling rules of the OR. The model was used to test

various schedule ordering rules (i.e. FCFS, LTF, etc.) in order to smooth daily demand

of inpatient beds. The model is also able to adjust the case mix each day based on the

three patient groups of major, intermediate and minor.

Similar to Blake et al. (1995), this general framework is unable to capture some of

the details required for tactical decisions including cancellations, emergent patients and

detailed scheduling rules. The model is mostly focused on resource usage. Furthermore,

the use of patient groupings result in a loss of some detail as they have been grouped in

high level categories of minor, intermediate and major, loosing service and surgeon level

detail. This model is appropriate for broad, strategic decision making.

The second generic model (Moreno et al., 1999) is of a whole-hospital view and is

intended to be used for high level management decisions such as the number of beds, lab

capacity, etc. The generic simulation model is based on patient flow and data inputs. It

does not include any details such as scheduling rules. The model entities include patients,

resources, workforce and processes (related to their pathology and tests). This generic

model was tested on a single hospital to identify bottlenecks and under-utilised resources


and to test scenarios altering the availability of those resources identified in an effort to

keep waiting times for services within an acceptable range.

Generic Models of Other Healthcare Processes

A number of generic models were found that represented other healthcare processes. For

example:

• Bed capacity decisions: Costa et al. (2003); Pitt (1997); Nguyen et al. (2005)

• Laboratory and outpatient clinics: Berchtold et al. (1994); Ramis et al. (2002);

Paul and Kuljis (1995)

• Emergency department: Fletcher et al. (2007); Miller et al. (2004); Sinreich and

Marmor (2004); Centeno et al. (2003)

The design and implementation approach taken by each varied widely. A common

design feature of these generic models is that they are data-driven; where parameters

are determined based on inputs as opposed to hard coded into the model (e.g. Costa

et al., 2003; Pitt, 1997). Users are able to specify such things as the number of resources

available or whether to use a specific rule or not. This feature not only allows for easy and

wide application across numerous sites, but also for flexibility in the possible scenarios

to be tested.

A subset of generic models found included the objective to design models that were

easy to use and understand by the end user, empowering the decision makers to gener-

ate scenarios and evaluate model outputs to inform decisions (Pitt, 1997; Sinreich and

Marmor, 2004).

Validation of simulation models of real world processes is often difficult and generic

modelling is not immune. The validation approaches documented for generic models vary

widely. Some were only tested on a single site (e.g. Costa et al., 2003), while others were

validated at multiple sites (e.g. Pitt, 1997; Paul and Kuljis, 1995).


Implementation of simulation models to aid decisions and the continued use of models

is often faced with many challenges, resulting in many solutions never being used. There

are many possible reasons for this including user buy-in and perceived model credibility,

the feasibility of the solution, and the ease of understanding and use of the model. This

problem is not unique to generic models. Of the generic models found, few document

successful implementation and ongoing use. One notable generic model is the generic

emergency department model created by Fletcher et al. (2007). The model was initially

intended to be used by the UK department of health to inform, at a national level,

barriers to reaching ED targets and to evaluate polices and solutions that address these

barriers (level three generic model). The success of the model at the national level lead

to a secondary study to apply the model locally at ten hospitals. With some changes

to the model structure, data from the local hospitals was inputted and the model was

validated at each site. The models were then used to test a number of possible solutions.

Implementation at each site varied, however. Only five of the sites tested scenarios,

and of those sites, only three implemented any of the changes suggested. The authors

noted a number of barriers to implementation of the generic model; the key barrier being

when hospital processes differed significantly from model assumptions. Though this issue

was often resolved through flexible use of data and data interpretation, small changes

to model structure and additional off-line analysis of model outputs. Other obstacles

faced were not related to the generic model itself. These obstacles included data quality,

‘organisational disfunction’, and motivation of the site.

The authors conclude that generic modelling of a ‘typical’ department and of a spe-

cific department are both valuable undertakings. At the local level, generic models are

especially valuable to “generate interest and facilitate debate of alternative methods.

(Fletcher et al., 2007, p. 1562)” However, for the purpose of studying the impact of

local decisions more work is required to calibrate, validate, and modify the model to the

specific site.


3.5.3 Generalised Models and Frameworks outside of Health-

care

Outside of healthcare there exists a large body of research in generic modelling across

all levels of genericity. However, within the area of domain-specific generic models (level

three) as described by Fletcher and Worthington (2009), there is a small body of research.

Similar techniques for design, validation and implementation were found.

Many of the generic models found purported to create a generic model of a specific

domain, often with the objective to produce an easy to use simulation model that can

either be used many times by the same company for different products, or to be used

by different companies for the same type of process. Though it is likely that specific

models have been created prior for similar processes at the same company or another,

most works found did not use these as a basis for their generic model, nor did they

compare results from the specific and generic models. A few papers were found that

specifically mention a previously created specific model, whether as a base for a generic

model, or as a comparator (Brown and Powers, 2000; Drake and Smith, 1996; Steele

et al., 2002). For instance, Drake and Smith (1996) found that compared to a previously

created specific model, the generic model proposed separated the model from the end-

user’s needs. As a result, end users who are not necessarily familiar with simulation

are able to run and compare alternate scenarios. Further, the authors found that their

generic model provided more flexibility and ease of use for testing a wider variety of ‘what

if’ scenarios.

No work was found that directly compared the results of a generic model to a specific

model.

For some works the objective of creating a generic model was a secondary goal, thus

a specific model was first built, then adjusted to be more generic. For example, Brown

and Powers (2000) proposed generic reusable maintenance model was first created as a


specific model in order to better understand the processes and appropriate scope of the

model. As understanding of the problem situation increased, the model was adjusted to

increase functionality and to be more generic in nature. In addition, Schroer et al. (1996)

set out to create a generic model for the apparel manufacturing industry, however, noted

and subsequently tested that the same model could be applied to other manufacturing

industries including electronics and electromechanical. Centeno et al. (2003) is an exam-

ple of a model within healthcare that was initially designed for a specific site, that can

easily be adopted to other sites because of its data-driven nature.

3.5.4 Design Concepts for Generic Models

The literature survey found two reoccurring themes for generic model design: data-

driven and component-based. Data-driven implies that the specifics of the model, in

terms of the layout, quantity, rule selection, etc., should be done using input variables

allowing for quick and easy changes based on the particular process under study, and the

‘what-if’ tests under consideration. Jain (2008) defined data-driven simulators as models

that are completely parameterised through data. This can be done through the use

of forms, tables, spreadsheets or templates. Jain further notes that the key advantage

to data-driven models is that they are quick and easy to develop and use. However,

disadvantages include some inflexibility in the model if an option was not modelled, and

that the user interface cannot always be easily customised to meet the specific needs of

the system under study.

Component-based design, also referred to as modular design or object-orientated de-

sign refers to the structures of the model. Using components allows for flexibility in the

design of the model to suit the system under study. It allows for changes in process

order, number of components used, etc. Modular design can also allow for incremental

enhancements to the model (Pidd, 1992).

Pidd (1992) further describes a number of other features that are important to con-


sider when designing generic simulation models. He defines the key features to any

data-driven model including:

• The model should be suited for a range of applications.

• There should be no programming required by the user.

• The user provides data to the model that can be numerical, logical or text-based.

• The model contains logic for all anticipated instances of the domain.

A number of other papers found commented briefly on design steps to create generic

models. Kaylani et al. (2008) laid out four steps to generic model building. First, key

performance measures are identified. Then system boundaries and level of detail are

defined. Third, the typical instance that is required to be captured for the initial design

is identified. Finally, typical scenarios are iteratively generalised to accommodate all

instances in the domain.

Steele et al. (2002) present a higher level set of steps: First, the domain of interest

is selected. In other words, the problem and domain that address the objectives of the

study. This step helps to make the appropriate abstraction decisions. Here, the authors

caution to keep a narrow domain, as broad domains can lead to overly large models that

are difficult to understand and maintain. The second step proposed is to map out the

conceptual level diagram of the system processes and the interrelations between those

processes. Finally, Steele et al suggest to garner information from many different experts

in the system to ensure that different options are considered. To promote usability, Steele

et al also advocate to allow users to enter input in their own system-specific terminology,

and that outputs reflect their terminology as opposed to the terminology chosen by the

designer of the generic modeller.

Additionally, Brown and Powers (2000) offer a series of questions to help define the

scope and structure of generic models: What’s important to the model? What has crit-

ical impact on operations and what is touched by key functions? In what way should


the model be flexible and how much flexibility should the model allow? What is more

important, fidelity or speed? What inputs and outputs are required? In addition to an-

swering these questions when designing their generic model, the authors first determined

the components and processes required, then defined the overall structure and bounds of

the model.

Another method used to design generic models is to first build a specific model based

on a single site, then expanding it to be generic. This method was used for the generic

lab model by Berchtold et al. (1994), and a maintenance model by Brown and Powers

(2000). For example, the model of a generic laboratory was developed in two stages

(Berchtold et al., 1994). First, a feasibility model was created based on a single site.

Once it was known that the model was possible and valid, a generalised model was

created that could be used at any laboratory based on the learnings from the first step.

The conceptualisation of the generic framework is based on a set of work cells, each of

which has an input, output and data flow, and can be controlled by outside sources.

When faced with multiple different flows, some models began by mapping the generic

flows of the main flow groups. The flow maps are then used as a basis to build the generic

model. For example, Fletcher et al. (2007) mapped the three main patient types: major,

minor and admitted. Similarly, a generic manufacturing model for the apparel industry

found that it could also model other manufacturing industries such as electronics and

electromechanical (Schroer et al., 1996).

To design their surgical model, Blake et al. (1995) conducted interviews with staff at

four hospitals, then consolidated and validated the patient flow into a set of flow charts.

A DES model was created from the flow charts. To overcome challenges in portability

and ease of use, the authors chose to create a flexible base model that can be quickly

and easily customised for each site. Based on their scope and goals, this was better than

attempting to create a completely general model.


3.5.5 Validation and Verification of Generic Models

Though some articles describing generic models mention that their model was validated

and verified for at least one instance, few discussed issues encountered with verification

and validation of their generic model. Specifically, issues related to the nature of building

a generic model.

A generic model created for reusable launch vehicles was able to compare results to a

previously built specific model (Steele et al., 2002). Steele et al. found that the generic

model yielded the same results as the specific model. While the authors do not specify

how they came to this conclusion, they do mention that this statement is based on a

single test situation. Additionally, analysis of the generic lab model found that when

compared to a fixed-configuration model, that there was no difference in terms of results

and validation (Berchtold et al., 1994).

Few generic models stated that they had been verified and validated across multiple

systems. A generic model for manufacturing processes stated it had been validated in five

different situations, showing that the model can be portable while also being significant

(Nelson, 1983).

The national-level generic ED model (Fletcher et al., 2007) was validated by both

open- and black-box methods. For open box validation, the model’s assumptions, flow

and decisions were confirmed by clinical experts. Data representing the ‘average’ hospital

was used for black box validation to ensure model calibration. When applied locally the

emergency department model by Fletcher et al also validated to multiple sites with some

customisation (Fletcher et al., 2007). Other models that validated at multiple sites were

Paul and Kuljis (1995); Sinreich and Marmor (2004, 2005); Pitt (1997).

Ozdemirel (1991) created a verification tool for a generic manufacturing system model

that could easily be adjusted and applied to other generic models. The purpose of the

verification tool is to measure user acceptance of the model structure and assumptions.

Through testing this system on users with a variety of experience with the system, the


author was able to determine that the generic model proposed had a high acceptance

rating. Further, the author concluded that this helps prove that generic modelling is

“feasible, and its implementation has potential use for simulation modelling in manufac-

turing” (Ozdemirel, 1991, p. 426).

3.5.6 Cost-Benefit Analysis of Generic Models

Many researchers propose creation of generic models to reduce model development time,

reduce expertise required to develop and run models, improve model consistency and

quality, and reduce programming when used multiple times. These are often also touted

as the advantages of a generic simulation model.

There are however some disadvantages to generic simulation modelling. Jain (2008)

noted that generic modelling can lead to a reduction in the flexibility of scope compared

to general purpose simulation languages, object class libraries, etc. Nelson (1983) noted

that the flexibility required of a generic model leads to slower run times. Steele et al.

(2002) noted that in generic simulation modelling, as with most modelling, there can

be a tendency for ‘requirements creep’, leading to increasing costs and complexity. The

authors note that it can be avoided by strictly enforcing that only the requisite level of

detail be included, maintaining scope at a manageable size, and focusing on the important

factors only. Steele et al further conclude that the longer development time required to

initially design and build the generic model is outweighed by the benefit of using the

model across many systems and the shortened time for application and experimentation

on different systems. Moreover, Cope et al. (2007) note that generic models can be

complicated in design and set up, as well as require large amounts of inputs and knowledge

in order to run.

Finally, Jain (2008) discusses a number of trade-offs experienced with generic mod-

elling that should be considered when deciding whether a generic model is worthwhile

over a specific model.


Designing Generic Models

Little work was found suggesting specific principles, guidelines, tools or methods to de-

veloping generic simulation models both during the conceptual modelling and modelling

stages. In a paper speaking to decision support systems and operational research within

the realm of healthcare, Boldy (1987) states that a decision support tool should be

thought of and developed in the mind set that it will be used as a personal tool for

decision makers. He further outlines three features of a decision support system that are

key to the success and use of the tool:

• Emphasis on flexibility and adaptability,

• Ease of use and understanding by non-computer people, and

• Models linked with data sources.

When Brown and Powers (2000) set out out to create a generic model for maintenance

they used a series of questions to help define the structure and bounds of the model.

Examples of questions include ‘what is important to the model?’ and ‘how should it be

flexible, and how flexible?’. The series of questions helped the authors determine model

boundaries, scope, elements to include and exclude and the level of detail. They also

noted that consideration should be given to how the generic model will handle inputs

that can vary in size, and how can it be structured so that inputs can easily be replaced

or connected to the database. The authors also recommend the guidelines proposed by

Law and Kelton (2000): to be as flexible as possible, but to also keep the model within a

reasonable size and scope. When designing simulation models, especially generic model,

a key challenge is making these various design decisions.

Within their study of conceptual modelling of generic simulation studies of security

systems Guru and Savory noted that generic or template-based simulation models often

involve applying a set of “pre-built, ready to use, modelling objectives, modules, or model


of common simulation situations. (Guru and Savory, 2004, p.g 867)” The authors suggest

to develop generic models using switches to turn on or off specific parameters in order to

fit the model to the current system under study.

The authors further noted that there is little in existing literature in the area of generic

or template-based simulations. As such, Guru and Savory set out to develop a framework

to assist a simulation modeller with conceptual model development of physical security

systems. While created specifically for security systems model design, their strategies

can be used in generating frameworks for other generic simulation conceptual models.

Their structure encourages reusability through use of modular and reusable components

and an expandable architecture.

In summary, when building generic simulation models much focus and time should

be dedicated to the design stage. Generic models need to be designed so that they

can be applied to specific real systems that were not known or considered during the

development of the model. Generic model conceptualisation requires the modeller to not

only consider the real system and client needs that he is currently working with, but

he must also look ahead and predict what other clients and systems may look like and

require from the same generic model. Chapter 4 of this thesis reviews in detail the work

and decisions made during the design stage of the proposed generic model.

Chapter 4

The Proposed General Model

This chapter will review the evidence supporting the first contribution of this research

to the fields of healthcare operations research and generic simulation modelling: The

proposed generic model demonstrates that a generic model of a complex healthcare system

process is feasible. Moreover, a generic model can be meaningfully applied to multiple

sites to influence and inform decisions. More specifically, the contribution herein is

the presentation of a generic model that has been successfully applied to multiple sites.

Successful application of the generic model includes implementation of decision options

tested by the model. In addition, the model continues to be applied at the sites and

to new sites, and work is underway to create a commercial version of the generic model

for wider distribution and use. The chapter concludes with providing some tips and

suggested guidelines for generic model based on this research experience.

This chapter will first provide a review of the generic model. Then, the contribution

is demonstrated through discussion of the application of the model at multiple hospitals

of varying sizes and characteristics.

51

Chapter 4. The Proposed General Model 52

4.1 The Generic Model

4.1.1 Model Objective

The literature review demonstrated that there is a need for a decision support tool to

help guide decision makers in tactical decision making. Due to the significant interactions

that occur within the areas within the perioperative process as well as with other areas

of the hospital, it is important that the model considers a holistic view by including more

than just the OR. Thus, the generic model includes the perioperative processes as well

as the post-operative inpatient recovery resources, as depicted in figure 4.1.

The review also indicated a need for generic simulation model solutions to reduce

duplication of effort and cost of creating and applying models. In order to be a generic

model, it must also be flexible to allow for application to numerous hospitals’ periop-

erative service and to be able to consider many different possible decision options that

stakeholders may be interested in evaluating. This flexibility and adaptability will allow

not only application at multiple sites, but also multiple applications at a site over time.

In particular, this generic model is to address tactical decisions affecting the surgical

patient flow of the hospital. These decisions include the availability and scheduling of

the OR resource using the block scheduling method; wait list decisions including order

and length of wait; and the availability of other resources required such as the PACU,

wards, etc.

4.1.2 Model Scope, Level of Detail, Assumptions and Simplifi-

cations

The challenge with designing any model, especially a generic simulation model, is de-

termining the model scope and level of detail - specifically what elements and details to

include and exclude.

Decisions on scope and level of detail, also referred to as simplification and abstraction,


!"#$%&'"()&*$+#&,-+$%&.#$+)$(/0&1$2-+3#$(3%&

4-+5%&,+67/-8&,-+$%&

$3/9&

1$/6:6"(&3"&"2$+-3$&

;+$<=2$+-7>$&

;":3<=2$+-7>$&?$/">$+0&

@##$56-3$&;":3<

=2$+-7>$&=2$+-7>$&

16:/A-+)$&3"&A"#$%&8"()&3$+#&/-+$%&

+$A-B6863-7"(%&$3/9&

;$+6"2$+-7>$&C3-)$&

D"5$8&E"F(5-+0&

Figure 4.1: High level surgical patient flow and generic model boundary shown.

are often a difficult part of conceptual modelling. In modelling, it is not desirable to model

all that is known of the real world, even if it is relevant to the objectives or the problem

situation of the system understudy (Kotiadis and Robinson, 2008).

There are a number of authors who have contributed through anecdotes, methodolo-

gies and rules to help make these decisions. For instance, Robinson (2004, 2007b) suggest

that if the component under consideration is important to the validity, credibility, utility

or feasibility of the model it should be included. When determining what to include and

exclude, the effect of excluding a component on the model’s validity, credibility, utility

and feasibility were considered. Would excluding the component reduce the accuracy of

the model (validity)? Would excluding the component decrease the confidence in the

model’s results in the eyes of the end users (credibility)? Would the exclusion signifi-

cantly increase the complexity of the model or run time (utility)? Is the data required

for the component easily available at most hospitals (feasibility)?

“Perfection is achieved, not when there is nothing more to add, but when

there is nothing left to take away.” Antoine de Saint-Exupery

Numerous authors have proposed principles or guidelines on model development based

on the idea of evolutionary development, meaning to start small and simple, and add as


needed. For example, Pidd (1999) presents six modelling principles that can help guide

conceptual modelling:

• Model simple, think complicated,

• Start small and add,

• Divide and conquer, avoid megamodels,

• Use metaphors, analogies and similarities,

• Do not fall in love with data, and

• Modelling may feel like muddling through

Other authors have also provided insights into abstraction and simplification. For

instance various authors suggest repeatedly removing detail and scope, simplifying com-

ponents, using constants instead of variables or eliminating variables entirely, using linear

relations where possible, strengthening assumptions and restrictions, reducing random-

ness, dropping unimportant components, using a random variable to depict a component

and grouping components. (Robinson, 2007a)

It was with these principles and guidelines in mind that the model scope, detail,

assumptions and simplifications were designed. Figures 4.2 and 4.3 demonstrate which

components are included and excluded in the proposed generic model.

To demonstrate the key scope, detail, assumptions and simplification decisions, a brief

description of the model follows - including notes and discussion on these decisions.

Overview of the Generic Model

The model overview provided herein serves to provide a brief description of the model’s

scope, level of detail, assumptions and simplifications. A detailed description of the

model design is provided in appendix C. A thorough conceptual model description is


•!!"#$%&'()*+,(+-,.-/$0+#,

•!1(/",2(3,14'#"'3,.'"(,

•!.+("%&5"%$(,$+-46)*+,!**/,

•!7!,5*8-$+#,.'"(,

9!:($&,8$%&,/(+(#"/"+&,

9!14'#$6(8,%65"-48$+#,

;'"<7="'()>",

9!7="'()+#,'**/%,

9!?(+6"88()*+%,7="'()>",

9!;*%&<(+"(%&5"%$(,?('",@+$&,

9!?'$)6(8,6('",(+-,%&"=,-*A+,4+$&%,

9! B+=()"+&,A('-%,

;*%&<7="'()>",

•!;'"<*=,68$+$6,%65"-48$+#,(+-,

>$%$&,

•!1(/",-(3,%4'#"'3,

•!C*+<%4'#$6(8,4+$&%,

D8"/"+&%,B+684-"-, D8"/"+&%,DE684-"-,

Figure 4.2: Pictorial summary of perioperative processes included and excluded in the

proposed generic model.


!"#$%"&'()*+',

-..'/0)$',&"#$%"&'()*+',('1"+'(2, !"#$%"&'()*+',('1"+'(2,

3&'()*+',!)*'4$,)((0+)56,('70#$()*"4,)4/,

)/.0##0"4,

89(#0476,:4)'#$;'#0)6,<9(7'"4,

)##'##.'4$#,

=04)5,$'#$#6,/0)74"#*1#6,0.)7047,

!('&)(',&)*'4$,>"(,#9(7'(2,

=04)5,('#"9(1',1;'1?, <9(7'(2,

!('%"&'()*+',

@)0$,50#$,.)4)7'.'4$, <1;'/95',&)*'4$,>"(,&("1'/9(',

<1;'/95',('#"9(1'#,>"(,&("1'/9(',AB'/#6,'C90&.'4$6,'$1DE,

<1;'/95',&)*'4$,>"(,&('%&("1'/9(',+0#0$#,

!('%"&'()*+',150401#6,$'#$#6,/0)74"#*1#6,'$1,

Figure 4.3: A more detailed pictorial summary of components included and excluded in

the proposed generic model.


provided in appendix A. In addition, documentation of decisions regarding level of detail,

assumptions and simplifications are provided in appendices A.3 and A.4.

Patient Types

There are three main types of surgical patients included in the proposed generic

model: elective, urgent/emergent and inpatient. The model allows elective patients to

be further classified by a priority level. This priority allows for further stratification of

elective patients for wait list ordering and priority over elective time. For instance, the

maximum wait time of an elective patient on the wait list can vary by their priority level.

In addition, the model allows for the elective wait lists to be either by surgeon or by

service, to reflect whether wait lists are pooled among surgeons, or as surgeon managed

wait lists.

For urgent/emergent patients, the model allows for the specification of the number

of urgency levels and their maximum allowable waits.

Finally, the model has two options for inpatient flow. One option is to manage these

patients separately using their own waiting lists, with priority levels, maximum allowable

wait times, surgeon scheduling, etc. This option is best suited for hospitals that schedule

an inpatient like an elective patient who must be done within the next week or so by the

surgeon who ordered the procedure. The second option does not categorise any patients

as inpatients. This option is intended for hospitals that consider inpatients as part of the

urgent patient population and follow the same scheduling rules as urgent patients.

Pre-Operative Section

The pre-operative stage of the generic model is concerned with scheduling patients

for surgery and wait list management. The generic model considers block scheduling

schemes and has been designed such that a variety of scheduling rules and procedures

can be considered within the block scheduling practices.

Within the block scheduling scheme, the generic model can place elective patients

on wait lists based on the surgeon assigned or on the service assigned. When wait lists


are surgeon based, the elective patient must be scheduled to OR time assigned to their

surgeon. Alternatively, when wait lists are according to service, patients are scheduled

into time that has been assigned to their service, regardless of which surgeon is assigned.

In this case, the patient is scheduled into the first time slot available within the surgical

service, regardless of the surgeon assigned. The procedure is performed by the surgeon

assigned to that block, not necessarily the surgeon who ordered the procedure. This

second scheduling method can be considered a type of pooled wait list strategy, where

patients are seen by the first available surgeon.

The generic model allows for scheduling rules such as restricting case mix within an

OR block, or the number of a type of case that can be performed across all ORs in a

day. For example, some hospitals choose to restrict the number of admitted procedures

scheduled in a day, or dictate that a certain number of a particular case type must occur

in some ORs in order to meet volume targets. More detail on these rules and how they

can be used can be found in Appendix C.9.

Scheduling the patient for the pre-operative clinic, patient education sessions and di-

agnostic tests can cause delays in the patient’s procedure, especially for elective patients.

However, the reason for these types of delays is largely due to lack of co-ordination rather

than lack of resources. Typically, the pre-operative clinic and patient education sessions

are run by the perioperative department. Often, these visits require access to other hos-

pital resources such as diagnostic imaging and lab. Delays are often due to test results or

consultations not being completed prior to the scheduled surgery date. Better planning

and co-ordination of these activities would help reduce many of the resulting delays and

cancellations.

The activity and processes of these pre-operative activities are not considered by the

generic model. The reasoning for this simplification was twofold. First, it is believed that

the impact of pre-operative activities on the tactical planning and scheduling decisions is

small. As a result, excluding these activities should not change the results of the model


and decisions proposed. The reason for this is because these areas are not the bottleneck

of the system. Often, issues arising from these areas that impact patient flow are due

to poor coordination and planning of resources. For example, a patient is scheduled for

their pre-operative clinic visit only 4 days prior to surgery. Test results conducted at

the visit suggest that a consultation with an internal medicine doctor be performed prior

to being cleared for surgery. Unfortunately there is not enough time to schedule the

visit, and the case is rescheduled for a later date. If, however, the patient’s visit was

scheduled two weeks prior to their scheduled surgery, there would have been sufficient

time to schedule the follow up appointment. Modelling and decision making of these pre-

operative activities can be performed with key information such as the master surgical

schedule as an input rather than a variable.

Second, some of these resources are used by many other hospital departments. For

example, the diagnostic imaging machines are typically a shared resource for both in-

patients and outpatients. The perioperative demand requirements for these resources

represent only a fraction of the total demand. Modelling these resources accurately

would require making assumptions on the capacity available for perioperative, which is

difficult to ascertain. Access is further difficult to quantify as emergent patient access

is often prioritised over elective and scheduled care. Thus, overall, it was determined

that these areas could not be accurately modelled based on the information available

and nature of the resources and their management.

However, development of decision support tools to help these areas better co-ordinate

and plan their demand and capacity would be beneficial.

In order to reflect the fact that some cases are cancelled due to these issues, the model

does include an inputted cancellation rate that can include these cancellations, as well

as other reasons such as medical, or anaesthesia unavailable.

Operative Section

The key resource considered by the model in this stage is the OR. As part of the


operative stage, patients may also spend time at patient registration, same day surgery

beds, OR holding bays and anaesthesia induction rooms prior to going to the OR. The

model does not however consider flow through these pre-OR areas such as admitting,

registration, or same day surgery. Much of the time spent in these areas is simply waiting

for their procedure. Hospitals typically ask elective patients to arrive more than two

hours prior to their procedure, even though there are only typically a few short activities

required such as nurse assessment, surgical site preparation, etc. Better co-ordination

and planning should minimise OR delays and reduce patient waiting. Surgical tactical

decision making assumes that co-ordination and planning of these activities does not

significantly affect overall patient flow.

During this stage of the model, numerous cancellation decisions are made. Reasons

for cancellations include no ICU, ward or SDU bed, not enough scheduled time remaining

to complete a case, and cases bumped due to a more urgent case. The model also allows

for an inputted percentage of cases to be cancelled for other reasons out of its control

such as medical reasons, required tests/clinic visits not completed, etc.

Post-Operative Section

The perioperative process includes immediate post-surgical recovery, typically in the

PACU and other recovery areas such as the day surgery unit.

The patient’s recovery requirement is indicated in the model input and can include

a stay in the PACU. However, the day surgery unit, where patients may continue to

recover post-surgery prior to being discharged the same day, is not included. The reason

for this exclusion is similar to those above for the pre-operative activities and some

operative activities, they have little impact on the intended decisions and results of

tactical planning and scheduling decisions.

Patients who do not require an inpatient recovery post-operatively are discharged

from the model at this stage.

Post-Operative Inpatient Recovery Section


Patients who require admission to the hospital for an extended recovery will enter this

section of the model. The model considers three types of units and allows for multiple

units of each type. Intensive care units (ICU) are intended to represent the most acute

level of care. The lowest level of acuity beds are represented by ward units. The model

also allows for care between the ICU and ward levels through the inclusion of step down

units (SDU). The particular route and length of stay (LOS) each patient takes through

the recovery stage is inputted in the patient file.

When patients complete their stay in these units, the patient is discharged from the

model. Discharge locations, such as rehabilitation and long-term care are not modelled

as they are often separate institutions outside of the acute care setting. The different

types of facilities within discharge locations are numerous and complex, accepting pa-

tients from many different institutions. Modelling this spectrum of care is difficult and

complex within itself. However, this element of the patient’s flow is modelled indirectly

by including the time patients spent in acute hospital beds waiting for access to these

downstream resources.

Two key assumptions were made regarding patient flow though this section. Firstly,

patients can only flow from higher acuity units to lower acuity units, but not the other

way. For example, a patient can go from the ICU to a ward, but not from a ward unit

to the ICU or SDU. This assumption was made to simplify the flow descriptions in the

model and input files. If a patient did actually flow from low acuity to higher acuity

unit, the total length of stay for each unit is inputted into the model. In reality, patients

moving from lower acuity to higher acuity does occur. However, from the experience

of experts at the hospitals tested it is not common in the surgical patient population,

especially for the elective patients, which represent the large majority. By using the total

length of stay for each acuity level, the impact of this simplification is minimised as the

only difference is when during their entire stay the patient spent those days on each unit.

The outputted occupancy of each unit should be fairly representative when the model is


run multiple times for many weeks.

The second assumption is regarding the discharge time of admitted patients. To

facilitate the co-ordination and decisions within the model, patients are discharged at

midnight on the morning of their day of discharge. For instance, if based on the patient’s

inputted length of stay (LOS), they would be ready for discharge at 14:00 on day five,

the model would discharge him at midnight on day five, (the start of day five). This

was done to simplify the flow and co-ordination of new admissions and patients moving

between units. This assumption allows all patient transfers to occur at midnight. This in

turn allows for simplified management of patients to be admitted each day as the exact

number of beds available for the day is known. This simplification does affect outcome

measures concerning transfer delays which will be discussed as a model limitation in

section 4.2.3.

4.1.3 Model Outputs

In order to be meaningful to the decision maker, the outputs of the model must include

the performance indicators that they consider important. The outputs selected were

chosen based on discussions with decision makers at the initial three sites, as well as

common indicators found in the literature. In addition, more detailed drill down of

some outputs is useful to have available when calibrating the model to identify reasons

for variation between model outputs and expected results (i.e. historical values during

validation, or expected results during decision option testing).

• Wait lists - by service, by surgeon, by patient type and by priority within each

patient type

– Average # waiting

– Average waiting time

• Operating Rooms:


– Utilisation as a percentage of time marked as elective used for elective cases

– Utilisation as a percentage of time OR used over 24 hours

– Overtime

– Undertime

• Resources:

– Census at midnight for each ICU, SDU, Ward by day of week

– Census for each PACU by day of week

– Off service rates into each resource unit - the number of surgical patients on

the unit that belong on a unit of a different surgical service

– Off service rates out of each resource unit - the number of surgical patients

that should be on the unit that are on another unit because there wasn’t

enough beds on this unit when needed.

– Hold over in PACU - number of days required to use on-call or closed time for

one or more patients

• Cancellations - by service, by patient type and by reason:

– No ICU bed

– No SDU bed

– No ward bed

– Not enough OR time

– Bumped for more urgent case

– “other” reason

• Throughput -by service, by patient type, and by surgeon

Further detail on the outputs, including definition and how they are collected, are

provided in Appendix C.


4.1.4 Model Inputs

The generic model inputs can be subdivided into three types: hospital structure, schedul-

ing and patient information and flow. Data within the hospital structure group gives spe-

cific information on the resources available at the hospital. The inputs within the schedul-

ing group provide details on the master surgical schedule (MSS) and other scheduling

parameters. Finally, the patient information and flow group provides information on the

characteristics of the hospital’s patients and how they should flow through the system.

A visual summary of the generic model inputs is presented in figure 4.4.

!"#$%&'()*&+,-&,+.)

/ 0)+.#",+-.#1)234)56784)7784)*784)9'+:#)

/ 0)#,+;."<#)/ 0)#.+=%-.#)

*->.:,(%<;)

/ ?("-@)#->.:,(.)/ *.+=%-.)'(("-'A"<)/ *,+;."<)'(("-'A"<)

/ *->.:,(%<;)+,(.#)/ 7'#.)"+:.+%<;)

5'A.<&)B<C"+D'A"<)'<:)E("9)

/ 6++%='()$'F.+<#)/ 5'A.<&):.&'%(#)/ 5'A.<&)$'&>#)/ 2GH#.+=%-%<;)/ I'%&)(%#&)"+;'<%#'A"<)'<:)"+:.+%<;)

Figure 4.4: Summary of model inputs of the proposed generic perioperative simulation

model.

These inputs allows the generic model the capability to test a variety of different

possible decisions (experimental factors):

• Master surgical schedule:

– Elective block lengths (i.e. 8 hr vs. 10 hr, etc)

– Service assignments (i.e. which service has which days)

– Surgeon assignments (i.e. which surgeon has which days)


– Reserved time for urgent/emergent cases (i.e. an OR reserved all day, or for

a few hours within the elective schedule)

– On-call OR time

• Patient demographics:

– Length of stay in any of the post-surgical beds

– Length of the procedure in the OR

– Post-surgical routes i.e. some cases no longer require ICU for a procedure

type

• Scheduling rules:

– Case mix rules within an OR day: dictating the types of cases that can occur

in an elective block

– Case mix rules within a service’s time: specifying the types of cases that can

occur across all ORs of a service in an elective day

– Case mix rules across all ORs: dictating the types of cases that can occur

across all ORs during an elective day

• Schedule ordering:

– Ordering policies

– Anaesthesia type

– Type of case by some category (i.e. joints first)

– Admitted vs. day cases first

– Booked time

– Etc.

• Resources:


– Number of beds in various units

• Emergent/Urgent cases:

– Use of reserved time in elective schedule

– Rules around how and when to schedule

• Inpatient cases:

– Rules around how and when to schedule

• Off-servicing rules (i.e. where can they go if the bed they require is off service):

• Strategic:

– Moving services/surgeons from one site to another

4.2 Application of the Generic Model

The purpose of this section is twofold. First, to review evidence that demonstrates how

the generic model contributes to the generic modelling field through its successful appli-

cation and use at multiple sites. Second, this section reviews the issues faced applying a

generic model to real sites.

4.2.1 Use of the Model at Multiple Sites

To date, the generic model has been applied to six different hospitals and interest for

further application continues. At four of the six applications, results from the model have

been used by decision makers to inform tactical decisions and influence stakeholders. This

is a significant aspect of this model’s contribution to research as much of the literature

in operational research was not able to actually demonstrate that the model was used by

decision makers to inform and influence their decisions. Few proposed generic models,


both in healthcare and other industries, have been successfully applied to multiple sites.

Furthermore, the model has been successfully used by simulation experts not part of the

initial design and applications, demonstrating transportability of the generic model. This

is another feature described in generic modelling research, but has rarely been achieved.

A brief discussion of the implementation at each site is provided below. The applica-

tion at the remaining two hospitals, St. Mike’s and Mt. Sinai, was limited to validation

to historical data only as there was a loss of engagement and interest by the decision

makers at these sites. Thus, full application was not possible.

Application at the Juravinski Hospital

Application of the generic model at the Juravinski Hospital was the most successful of

all sites studied. The generic model was not only used by decision makers to evaluate

tactical decisions, but was also used as a negotiation tool with various stakeholders

including surgeons, unit managers and the medicine department. In January 2012, one

of the options considered by the model was piloted for seven weeks. After analysis of

the pilot period, the changes were implemented permanently. The decision implemented

included changes to the MSS, available ward unit capacity and off servicing policies.

Work is currently underway at Juravinski to update the data in the model to pre-

pare for an upcoming round of tactical decision making. In addition, Hamilton Health

Sciences, has begun to apply the model at their General Hospital site.

The application at Juravinski demonstrates that not only can the generic model be

successfully applied to a hospital, but that the model’s results are considered accurate

for the purposes of influencing stakeholders and making decisions. Furthermore, the use

of the model proved so valuable to the hospital administration that future application at

Juravinski and other sites are underway.


Application to two William Osler Hospitals: Brampton and Etobicoke

As part of a large scale perioperative improvement initiative at William Osler Health

Service, the generic model was applied to both their surgical sites: Brampton Civic

Hospital and Etobicoke General Hospital. Numerous inefficient practices existed at both

sites including late start times for scheduled procedures, underbooking and overbooking

of OR blocks, inaccurate booking times, OR block over runs and lengthy waits for target

cases. The generic model was used as one of the improvement initiatives, with the focus

on adjusting the MSS to co-ordinate resources, accommodate new surgeons hired, increase

volumes and plan for urgent and emergent patients.

Due to the many current inefficient practices at the two hospitals, the generic model

was used to demonstrate what resources, in terms of OR blocks, were required to deliver

their current volumes once their inefficient practices were addressed. The model demon-

strated that OR capacity existed without a need to increase the number of staffed ORs

or the operating hours of the OR. The model was subsequently used to determine how

best to allocate the found OR capacity. Options considered included giving time to the

new surgeons hired, reserving time for urgent patients, and providing additional time to

services to achieve volume targets.

This application of the model contributes to the research field in several ways. Firstly,

the generic model was designed without knowledge of William Osler’s processes and

characteristics, which shows that the generic model is in fact generic. Secondly, the initial

three test hospitals were all academic institutions; application at these two community

hospitals further strengthens claims of the model’s genericity.

Finally, the experience at the two William Osler hospitals revealed a secondary but

important use of the model as a tool that demonstrates what performance could look

like if inefficient and poor practices are resolved. This demonstrative use of a simulation

model is not typically explored. Further detail into this aspect is explored in Chapter 6.


Application at Prince Albert

The Saskatchewan Ministry of Health was concerned with the productivity of the Prince

Albert Hospital, and whether the hospital would be able to achieve the ministry’s imposed

wait time targets. The hospital believed an additional OR and beds would be required.

The ministry wanted to see if efficiencies could be found in lieu of capital expansion.

The generic model was applied to this hospital by a simulation expert who was not

previous involved in the design and research of the generic model. However, support to

the modeller was provided by Daphne Sniekers and Carolyn Busby, the original model

coder.

Similarly to William Osler, validation of the generic model was somewhat challeng-

ing due to existing inefficient processes. The analysis resulting from the generic model

suggested that in order for Prince Albert to reach wait time targets and accommodate

increasing demand, commissioning an additional OR would be required. However, if 17

of the existing 32 beds were reserved for surgical patients (aka ring fenced), no additional

surgical beds would be required. At the end of CRHE’s commitment to the project,

the hospital was addressing their inefficient practices to improve their performance. The

hospital was also in negotiation with the Ministry to implement the proposed capital

expansion.

Future Planned Applications

Besides the planned application at the General Hospital site of Hamilton and the reuse at

Juravinski previously mentioned, the generic model has recently been applied by another

simulation modeller to two other sites in Saskatchewan.

In addition, Visual8 is keen to work with Hamilton, the research team of CRHE to

continue to improve the generic model by improving upon the genericity of the model

based on experience of applying the model to the various hospitals to date, and developing

a user interface that will allow for easier import of hospital data and direct interaction


with the model by end users (hospital decision makers).

4.2.2 Issues Experienced and Changes Required while Imple-

menting

Throughout the implementation of the generic model, notes were made of any changes

and additions required to the generic model, and any issues and limitations faced. The

charges and additions documented can be classified into three categories. First, the

changes that were made during the coding phase to facilitate implementation using the

selected simulation software. Second, those changes and additions required to accurately

portray patient flow in order to make informed tactical decisions within the scope set

out in the generic model. These changes were made not only for the implementation of

the model at a particular hospital, but also to the model’s design. These are considered

changes required for the genericity of the model. Finally, the third type of changes were

made to answer very specific questions posed by hospital decision makers that were not

considered within the scope of the generic model. These changes were made specifically

for the study at a particular hospital and were not made to the generic model framework.

These can be considered as custom, post production charges and additions. A change

database listing all changes made and the reason for the change is included in Appendix

B.

Changes for Implementation into Simul8

These changes were made to simplify coding in the software package Simul8 based on the

characteristics and functionality of the software. These changes do not affect the overall

flow or results of the generic model.

The conceptual model of the proposed generic model includes allowance for an elec-

tive OR block to be shared between two surgeons of either the same surgical speciality,

or different specialities. For the sake of ease of coding when programming the simula-


tion model an assumption was made that an elective OR block would only be shared

between surgeons of the same service. Based on experience to date at the initial three

academic hospitals and large urban community hospitals (i.e. Juravinski, Mt. Sinai, St.

Mike’s, Brampton and Etobicoke), this assumption was thought to be valid as it was

accepted best practice to avoid OR block sharing between services. However, at Prince

Albert, a small rural community hospital, shared OR blocks between services was a real-

ity in their master surgical schedule planning. In order to accommodate their practice, a

workaround was employed by scheduling another unassigned OR for the second service.

This workaround allows for the two services to run, but does not account for any delays

the second service may experience if the first service runs late. This unfortunately re-

duced the credibility of the model in the eyes of the decision makers at Prince Albert. It

is recommended that this coding simplification be addressed in future work. The code

adjustment would not require a significant amount of time or effort to complete.

Changes Required for Model Genericity

There were no changes needed to the generic model itself in order to maintain the gener-

icity of the model, within the scope and objectives laid out.

One limitation found in the generic model was around the assumption that when a

surgeon runs more than one OR, the ORs run parallel with two surgical teams. However,

at William Osler Health Sciences, a non-teaching hospital, the surgeon has neither a team

of residents nor a second OR team to operate parallel ORs. Here they use a second OR to

reduce surgeon idle time between cases for OR cleaning and set up, patient positioning,

etc. Accordingly, activity between the two ORs needs to be better co-ordinated and

scheduled. At William Osler, the only surgeons who were given “swing rooms” were three

orthopaedic surgeons who performed high volumes of total joint replacements (TJR).

These swing rooms allowed these surgeons to perform six TJR cases in a day using a

single OR team, versus four if the surgeon only had a single OR to use.


Since the swing room used here was for a very specific purpose, the existing model

capabilities were used to work around this scheduling method. Scheduling rules were

created to represent these swing rooms. On days when a swing room was scheduled, a

set of scheduling rules was used to dictate how patients should be scheduled. The generic

model would then run the two ORs independently.

As part of any future effort to improve and expand the proposed generic model, it

is recommended that various swing room scheduling schemes be studied further and

functionality added where needed to be more inclusive of swing room scheduling config-

urations.

Changes and Additions for Client Customisation

During the validation at William Osler, the working group identified that the proposed

generic model did not accommodate their specific urgent patient scheduling procedures.

At William Osler, patients were scheduled into available urgent OR block time based

on a reversed priority scheme, giving highest priority to the least urgent patients. The

generic model on the other hand assumes that the most urgent patients will always be

prioritised over less urgent patients. William Osler adopted this scheduling procedure

in order to ensure that wait time targets of their least urgent patients would be met.

Poor planning and scheduling practices in place at the hospitals were causing significant

delays in providing timely care to urgent patients who were not emergent (highly urgent).

In response, they allocated time for the least urgent patients, instead of addressing the

overall issue of urgent patient mismanagement.

This urgent scheduling process mismatch was identified early on in the validation

stage of the modelling, when many working group members were still very sceptical of the

model’s ability accurately model and guide decision making (see Chapter 5). Moreover,

it came to light prior to the development of the idea that the model should be used to

demonstrate potential performance of potential tactical decision options; as opposed to


exactly modelling a hospital’s current processes, good or bad. In an attempt to strengthen

user acceptance at the time, the proposed generic model was customised to their specific

processes.

However, upon reflection and in light of the proposed positioning of the generic model

as a decision and demonstrative tool for tactical decisions (see Chapter 6), this customi-

sation should not have been performed. Customisation of the model to include strange,

poor or inefficient practices detracts from the generic model’s purpose to demonstrate

potential performance of tactical decision options.

4.2.3 Limitations Noted

As a result of the chosen scope, level of detail, assumptions and simplifications of the

generic model, as well as the fact that the proposed model is intended to be generic and

applicable to many hospitals, a number of limitations exist.

First, the generic model assumes that the OR schedule is allocated based on a master

surgical schedule, or OR block schedule. The master surgical scheduling method was

chosen as it is the most commonly used scheduling method for surgical services.

Second, the model does not allow for more than one service to be scheduled into an

elective block. This assumption was made during coding of the model in order to simplify

the scheduling algorithm. Based on experience up to that time, it was assumed that most

hospitals do not schedule more than one service in an OR. A work-around is possible

without changing the code where the shared OR block is entered into the MSS as two half

blocks in two different ORs. This was done at Prince Albert, and the decision makers

agreed that it was an acceptable change. Since this practice appears to be more common

than originally thought, it is suggested that the coded model be adjusted accordingly.

Third, it was found that the assumption regarding how to schedule cases, when a

surgeon is allocated two ORs on the same day, is not reflective of some hospital’s pro-

cesses. The generic model design assumed that scheduling a surgeon in two rooms on


the same day typically occurred in hospitals where residents and surgical assistants are

used to run the ORs in parallel. However, some hospitals will use the second OR as a

“swing room”, that allows the surgeon and the OR team to use the second OR for a

case while the first is being cleaned, effectively reducing the turnaround time for that

surgeon’s schedule to zero. This practice was found at Brampton where some orthopaedic

surgeons are given swing rooms to complete a higher volume of TJR cases. In this case,

the inputted schedule and scheduling rules were adjusted such that the swing rooms were

scheduled appropriately. The adjustment was possible because the swing room was for

a very specific use. However, it may not be possible to use existing inputs to reflect

another hospital’s use of swing rooms. In the future, it would be prudent to adjust this

assumption such that scheduling of the swing room is more reflective of practices found

at hospitals.

The fourth limitation takes note that, based on the model’s design, simplifications

and assumptions, delays within the surgical day are not included nor measured. For

instance, delays experienced from the PACU to the inpatient units or from the OR to

the PACU when a bed is not yet available. Delays often occur when the downstream

resource, the inpatient beds, are not available when needed because the previous patient

has not yet been discharged/left from the bed. As a result, the next patient must wait

in the PACU for their bed to be ready, which may delay another patient in the OR

who requires that PACU bed. On the other hand, the proposed generic assumes that

coordination of admissions and discharges occurs smoothly by performing all discharges

and unit transfers from inpatient beds at midnight, reducing the bottleneck. Based on

the premise of this generic model to demonstrate potential performance, this assumption

was accepted as it should not affect end results and tactical decisions.

Finally, the model is somewhat limited in what type of scheduling rules it can ac-

commodate, even though the idea was to be as flexible as possible. The model is not

able to accommodate a scheduling rule such as “schedule a minimum of four total joint


replacements” when there is an identifier in the patient file for hip replacements and

knee replacements, respectively. For example, say in the same schedule, one wants to

test scheduling rules where on some days only hip replacements are permitted, while on

other days only knee replacements are allowed, and on other days at least four cases must

be completed that are either hips or knees. This type of rule would require an identifier

for cases that are hips and one for knees to handle the first two rules, however, the model

subsequently is unable to quantify the third rule which is a combination.

4.3 Cost Effectiveness of the Generic Model

The costs and benefits of model reuse and generic models are often debated in literature.

Many argue that model reuse and generic modelling often tend to be more work than it

is worth.

In the panel discussion presented in Robinson et al. (2004), Pidd provides a financial

model for cost-benefit analysis of reuse. His model states that if the average cost per

use (KN) is less than the cost of developing the code from scratch (C), then reuse is

worthwhile. Pidd defines the average cost of the N th reuse as the cost of developing the

code the first time plus the cost to adopt the code each of (N − 1) times it has been

reused: KN = C+A(N−1)N

. Pidd’s financial model assumes that the cost of building the

code is shared by all instances of reuse. An alternative would be where the initial cost of

building is paid by the initial developer. Each instance of reuse benefits from the savings

of modifying the code to suit their needs, but do not share in the initial costs.

In the case of a generic model, the entire model is applied to more than one instance.

The hope of a generic model is that after some number of applications, the cost of

creating, modifying and applying the generic model is less than the cost of a specific

model. For the purposes of the analysis here, four costs are considered:

• The cost to create the initial model, whether generic or specific (C)


• Adoption Costs:

– The cost to input the data (I)

– The cost to validate and debug the model (V )

– The cost to add functionality after the initial model creation (F )

TCGn Total cost of the (n)th application of the generic model

TCSn Total cost of the (n)th application of the specific model

CG Cost to build the initial generic model

CSn Cost to build a specific model for the (n)th application

Ijn Cost to input data into model type j for the (n)th application of the generic model

V jn Cost to validate model type j for the (n)th application of the generic model

F jn Cost to add functionality after original build for model type j for the (n + 1)th

application of the generic model

LGn Cost to buy license of existing generic model

j Model type =

G generic model

S specific model

n The number of times the model has been applied

Figure 4.5: Definitions of variables for cost analysis.

To begin, assume that the cost to develop the initial generic model is shared by all

instances of the application of the generic model. The total cost of applying the generic

model n times is the sum of the costs of adoption for each instance, plus the cost of the

initial build, see equation 4.1. Figure 4.5 defines all variables used in the cost analysis

within this section.

TCG(n) = CG +n∑

i=1

(IGi + V G

i + FGi

)(4.1)


The cost of creating a specific model for n instances would simply be the sum of the

costs of the initial model build, plus any other costs of adoption for each instance, as

demonstrated in equation 4.2.

TCS(n) =n∑

i=1

(CS

i + ISi + V S

i + F Si

)(4.2)

In order to justify the cost of a generic model, after some number of applications k,

its total cost should be less than the cost of creating specific models for each application

(equation 4.3).

TCG(n = k) < TCS(n = k)

CG +k∑

i=1

(IGi + V G

i + FGi

)<

k∑i=1

(CS

i + ISi + V S

i + F Si

)(4.3)

For simplicity, assume that for each instance, the costs are the same for the particular

type of model. In other words, the costs to input data, validate and add functionality

are the same for each instance the generic model is applied, and the costs to build, input,

validate and add functionality for each specific model are the same (equations 4.4.

CS1 = CS

2 = . . . = CSn = CS (4.4)

IS1 = IS

2 = . . . = ISn = IS (4.5)

V S1 = V S

2 = . . . = V Sn = V S (4.6)

F S1 = F S

2 = . . . = F Sn = F S (4.7)

Equations 4.1 and 4.2 simplify to equations 4.8 and 4.9. The cost savings of applying

the generic model comes after k applications, when the average cost of applying the

generic model is less than the cost of creating a specific model for the kth instance

(equation 4.10). This result is similar to that of model reuse in Robinson et al. (2004),

except for application of a generic model, in its entirety.


TCG(n) = CG + n(IG + V G + FG

)(4.8)

TCS(n) = n(CS

n + IS + V S + F S)

(4.9)

CG

k+(IGk + V G

k + FGk

)< CS + IS + V S + F S

TCGk < TCS

k (4.10)

In the case of this particular generic model, the initial conceptual design and build

was funded through a research grant. As a result, the initial costs of building the model

CG is not shared by all instances of application. The initial test hospitals, Juravinski,

St. Mike’s, Mt. Sinai, and William Osler contributed to the initial build costs. However,

Prince Albert, and any future tests sites, pay for the application of the generic model to

their site (IGi , V G

i , FGi . In addition, a consultancy type fee may be charged for future

applications: LGi . As a result, the total cost for application to an additional site can be

defined as 4.11.

TCG(c)n = LG

n +(IGn + V G

n + FGn

)(4.11)

Assuming the costs to input data, validate and add functionality are the same in this

instance as prior analysis, then the use of the generic model becomes economical when

for any instance n, the cost of purchasing and applying the generic model is less than

custom building a specific model (equation 4.12).

TCG(c)n < TCS

n (4.12)


4.3.1 Cost analysis at six hospitals

In an attempt to demonstrate the value of using a generic model in terms of cost, the

following section quantifies the costs of designing and using the model at the first six

hospitals in terms of time required (hours). Time is used as a proxy for cost as none of

the hospitals paid for hours worked, but rather provided research stipends or fixed fees

for the research.

Moreover, the actual cost of creating and applying the generic model include more

than time spent. Depending on the situation, costs could also include the cost of pur-

chasing any required software, such as Simul8, the cost of training one or more people

on the software chosen and simulation, consultant firm fees, etc.

The breakdown of the cost (in terms of hours of time) is provided in table 4.1. The

cost of building and using the specific model at Juravinski’s orthopaedic service was 694

hours, which is more than 200 hours greater than the cost to implement the generic

model at any of the six hospitals when the initial cost of creating the generic simulation

model is shared equally.

Assuming that the cost of creating the specific model of orthopaedics at Juravinski

would be about the same as creating a specific model at any of the other instances, the

analysis shows that the cost to apply the generic model is less than the cost of a specific

model. This applies both when the cost to create the generic model was shared among

sites and when a site paid a licensing fee for the model.

A specific model was not built for each individual application. Since each specific

model would have been created by the same person, the cost to build each model would

decrease at each application as code reuse would have occurred. Whereas, if each individ-

ual hospital would have independently created their own specific model, the opportunity

for reuse would not have arisen. Thus, a fair comparison of specific versus generic would

have been possible if these conditions were mimicked using multiple model developers.

Note that the time spent for data input tasks decreased over the course of the study


Tab

le4.

1:C

osts

(in

term

sof

tim

esp

ent)

ofth

esp

ecifi

cm

odel

applied

toth

eJura

vin

ski

orth

opae

dic

serv

ice

and

the

gener

ic

model

applied

tose

ven

inst

ance

sat

six

hos

pit

alsi

tes.

Sp

ecifi

c

Model

Gen

eric

Model

Cos

tJura

vin

ski

orth

o

Bra

mpto

n/

Eto

bic

oke1

Jura

vin

ski

all

serv

ices

St.

Mik

e’s

Mt.

Sin

aiJura

vin

ski

orth

o

Pri

nce

Alb

ert

To

crea

te:

Ci n

174

324

0

Lic

ense

Fee

:L

G(c

)n

n/a

n/a

0

To

input

dat

a:I

i n15

060

7540

4010

2

2103

To

Val

idat

e:V

i n25

019

080

9035

15

To

add

funct

ional

ity:

Fi n

120

510

00

00

Tot

alC

ost4

:T

Ci n

694

409

209

184

129

7921

0

1W

ork

atB

ram

pto

nan

dE

tobic

oke

was

don

esi

mult

aneo

usl

y,th

us

much

ofth

ew

ork

and

cost

sco

uld

not

be

dis

tingu

ished

by

site

.

2N

ote

much

ofth

edat

acl

eanin

gan

dw

ork

was

per

form

edth

rough

the

spec

ific

model

wor

k,

and

was

only

man

ipula

ted

for

the

purp

ose

ofth

ege

ner

icm

odel

.

3A

lot

ofbac

kan

dfo

rth

bet

wee

nad

just

ing

inputs

,ca

libra

tion

and

gain

ing

cred

ibilit

yof

the

dec

isio

nm

aker

sw

asre

quir

ed,

whic

hm

ade

itdiffi

cult

tose

par

ate

tim

esp

ent

toin

put

dat

ave

rsus

validat

ing

the

model

.

4A

ssum

esco

stto

crea

tege

ner

icm

odel

was

shar

edev

enly

bet

wee

nth

efirs

tsi

xap

plica

tion

s.


across the sites. This was due to a learning curve effect from a single person performed

the data analysis, input and generic model validation for multiple sites. With each

implementation, familiarity with hospital data and the model increased, reducing the

time required to complete tasks.

This effect demonstrates additional value of a generic model in two ways. First, reuse

of the generic model can reduce turnaround time for results. As familiarity increases, the

time to implement, validate and test decreases. This benefits the hospitals as they often

require a solution in a short time period and do not want to wait many months for an

answer.

Secondly, it is assumed that since the generic model has been tested many times,

it is likely more robust and bug free than a specific model. As a result, when model

issues arise during future implementations, such as the model producing error messages,

crashing, etc., it is more likely due to an error in the inputs rather than of the model

itself.

These added benefits would be most pronounced if the generic model is provided to

hospitals as part of a consultancy package, or as a standalone, highly automated software

package. The setup, validation, testing and perhaps the first round of decisions would be

performed by an outside group who are experts in the generic model. Once set up, a user

friendly version of the model would remain at the disposal of hospital decision makers to

use to help inform future decisions.

In conclusion, the economic model demonstrates that the development and spread of

this proposed generic model is worthwhile and cost effective.


4.4 Proposed Guidelines for Designing Generic Mod-

els

The purpose of this section is to compile the lessons learned through this research experi-

ence into a set of suggested guidelines for designing generic models. These guidelines can

be used in future generic modelling research projects to help reduce the time required to

design a generic model, and to improve upon the genericity and usability of the model.

The current generic modelling research space is relatively small, particularly in the area

of design methodology. This portion of the research adds to this field by providing some

additional guidelines for designing a generic model.

4.4.1 Clearly Define the Problem Description, Scope, Objec-

tives, etc.

In simulation modelling it is important to begin with understanding the problem, and

defining the scope and objectives of the study (Robinson et al., 2010). When designing

a generic model, this step is a vital step to ensure the successful application to multiple

sites. Having a very clearly laid out set of objectives, scope and problem description

will prove invaluable when making design, level of detail, simplification and assumption

decisions (Steele et al., 2002, e.g.). Furthermore, it will help when applying the model

to different sites as it will help set the scene, manage expectations, and limit the need

for customising or changing the generic model to fit the specific idiosyncrasies of the

particular site.

Upon reflection of this research work, more time and effort should have been spent

defining the problem description, scope and objectives prior to design. Additional time

and effort spent prior to design would likely have saved a significant amount of time

revising and adjusting the conceptual model during the designing phase. In addition,

it would have proved valuable during application at multiple sites when challenges with


achieving validity were faced or when clients made customisation requests.

4.4.2 Study Multiple Sites Prior to Design

When designing a generic model it is obviously essential to have a good understanding

how processes can vary across sites. It is suggested here that in order to ensure the

genericity of the model, numerous sites should be studied prior to design. Moreover,

the sites should represent a wide variety of the types of sites where the model could be

applied. Gaining knowledge and experience of the processes and procedures at a number

of sites helps to ensure that most instances of a process are included in the model.

In addition, if information is available regarding best practices or popular improve-

ments ideas, they should be noted and included in the model.

When studying multiple sites, best practice and the other sources, take some time

to compare processes and look critically at differences that exist. Determine if these

differences are common processes that you are likely to see at other future sites, or if

they are a single case of one site. If they are of the later, you will need to determine it

is a practice that should be included in the generic model, or if it is a poor or inefficient

practice that should be discontinued, or something that should not be considered when

planning and making decisions. For example, William Osler was struggling with starting

their elective OR blocks on time each morning. Though this is somewhat common at

many hospitals, since the goal of the generic model was for tactical level decisions, it was

assumed that they will always start on time. This was appropriate, as at the tactical

level, one should not plan for inefficient practices such as late starts.

4.4.3 Keep it Simple

“Everything should be as simple as possible, but not simpler” Albert

Einstein


As stated in many guidelines on building simulation models, it is best to keep the

model as simple as possible (Pidd, 1999; Robinson, 2007a; Kotiadis and Robinson, 2008,

e.g.). When designing a generic model, simplifications and assumptions play an even

more important role. It s important to document any assumptions and simplifications

made, including the reasoning. In generic modelling, simplifications and assumptions

are necessary to build the model because not every possible instance is known, nor is

it feasible to include a large number of variations. Furthermore, it is important to user

acceptance of the model that decision makers understand where and why simplifications

and assumptions were made, particularly when they are different than their current

processes.

Based on the experience gained in designing a generic model, it is suggested to start

by designing the simplest model possible; adding details only when needed to fulfil the

requirements set out in the problem description, scope and objectives. It is at this stage

where the preliminary work on the model’s objectives, scope and problem description

pays off by guiding modelling decisions. When in doubt, ask whether excluding this

detail would change the decision? If the answer is no, then that detail can be excluded.

Many authors, such as those referred to above, offer useful tips on how to make and justify

simplification and assumption decisions. For example, in the generic model presented, it

was decided early on to exclude the day of surgery activities and resource activity that

occur before the surgery itself, including the same day surgery unit, waiting areas, etc.

“It is not necessary to have a one-to-one mapping between the model and

the real system. Only the essence of the real system is needed.” (Banks and

Carson (1995) as cited in (Lowery, 1998, p. 33))

This rule also applies when applying the model to a site. The nature of generic

modelling entails that not all specific processes and procedures of a site will match the

options available in the model. This can lead to challenges in achieving user acceptance


and statistical validation (discussed in the next chapter). It is important that when im-

plementing the model at a site, to continuously keep in mind the generic model’s intended

scope and objective when considering any differences between the model’s processes and

those found at the site. Before considering changing or adding to the generic model to

appease stakeholders, consider whether it is within the scope and objectives, whether it

would affect any decision outcomes.

4.4.4 Collaborate with End Users

Though in generic modelling, you will never be able to work with every decision maker

during the design phase, it is recommended to work in close collaboration with a number

of decision makers from various initial sites, or if a variety of sites are not available, other

subject matter experts. Allow the decision makers to review the model’s problem de-

scription, scope, objectives, model design, and simplification and assumptions decisions,

and provide valuable insights and feedback.

Chapter 5

Generic Model Validation

Achieving statistical validity in simulation of complex real-world systems is challenging;

convincing end-users that model outputs are reasonable and can be trusted when making

decisions is even more difficult. This section contributes to the large, complex system,

real world model validation literature by providing guidance on how to convince end-

users that results are reasonable and trustworthy, even when statistical prediction error

remains.

In order to demonstrate this contribution, this chapter is composed of three sections.

First, the validation procedures carried out at the test sites are described along with

outcomes achieved. Second, in order to show that use of a generic model did not sig-

nificantly contribute to the validation challenges encountered, the validation efforts are

compared to those of a specific model. The final section provides procedures and tools

recommended for validation of complex, large, real world systems.

5.1 Validation at the Test Sites

The purpose of this section is to describe the steps required to validate the proposed

generic model at the six test sites. The challenges encountered when validating a simula-

tion model of a large, real world, complex system are described. Particular focus is given

86

Chapter 5. Generic Model Validation 87

to reconciling model results to historical values when statistical validation is not achiev-

able, and how to convince decision makers to accept the model’s outputs as acceptable

and reliable for decision making.

Validation of real world simulation models is often considered “an art and a science”

(Martis, 2006) because it can be a long, challenging journey. Classical statistical methods,

including confidence intervals and hypothesis tests, often fail since the model is only

an approximation of the real world, and since these statistical methods assume output

measures are independent and identically distributed (IID), which is often not the case

(Law, 2005).

As a result, (Law, 2005, p. 29) states “it is more useful to ask whether or not

the differences between the model and the system are significant enough to affect any

conclusions derived from the model.” In order for any simulation model, and in particular

a generic simulation model, to be trusted and used for decision making, the end users

must believe that the differences will not affect their decisions. In order to achieve this,

validation must be performed in both a subjective and objective frame. The subjective

frame focuses largely on the use of confidence intervals and prediction error to compare

simulation output results to real results. The objective frame uses face validity, model

behaviour and subject matter experts to determine if the model’s outputs are acceptable.

Each application of the generic model has been validated objectively compared to

historical performance. For those sites with engaged decision makers and stakeholders,

the generic model was also subjectively validated, based on face validity and model

behaviour. The six sites are listed below; those where subjective validity testing occurred

are denoted with an asterisk (*).

1. Hamilton Health Sciences - Juravinski Hospital - all surgical services *

2. St. Michael’s Hospital

3. Mount Sinai Hospital - General surgical service


4. William Osler Health Sciences - Brampton Civic Hospital *

5. William Osler Health Sciences - Etobicoke General Hospital *

6. Prince Albert Hospital *

At each site, models were validated on throughput by case type and service and

cancellation rates by reason.

In the objective validity tests, each individual measure was validated against a 95%

confidence interval of the average simulation output over ten replications. This was

chosen because, in initial validation of the pilot specific model, the working group felt

that an error of ±50 patients on the total yearly orthopaedic throughput was acceptable.

The historical throughput was 1442, so an error or ±50 patients is only a 3.5% error

rate. The specific model only required ten runs to be within this error limit set. A

lower number of runs was desired as the specific model had a lengthy run time: ten

runs of one year duration of the orthopaedic service took on average of 40 minutes. The

improved design and coding of the generic model resulted in shorter run times; the all

services generic model of Juravinski run for a year had an average run time around 25

minutes. As a result, the number of runs could have easily been increased; however, total

throughput results from each site produced confidence interval widths of less than 50

cases, an error rate that decision makers at each site were comfortable with. So for the

purposes of comparing results across all models, the number of runs was kept at ten.

Objective validation efforts performed at three of the six hospitals was relatively easy

and straight forward. The Juravinski, St Mike’s and Mt. Sinai are all high volume

teaching hospitals. A summary of the results from these hospitals are shown in tables

5.1, 5.2, 5.3 and 5.4. However, even at these high volume sites, the validation results

presented include some noteworthy discrepancies where the 95% confidence interval of a

measure from the model’s output does not include the historical value. For example, at

Juravinski, the model’s 95% confidence interval for average throughput for both gynaecol-


ogy/obstetrics (OBGY) and plastic surgery services fall above the historical throughput.

Simultaneously, the number of cases cancelled due to not enough elective time available,

no ward bed and bumped for a more urgent case are also higher than the historical value

(table 5.1). An analysis of the historical data did not reveal significant variation from

the inputs that could explain the difference. Within the three over predicted cancelation

rates, two (not enough time and bumped for a more urgent case) were not significantly

higher than the historical values. Cancellations due to no ward bed however had a much

larger error difference. It was known that there were some patient flow issues at this site,

where medicine patients were regularly off serviced in to the surgical wards. This causes

a high variability in the number of surgical ward beds available for surgical patients. To

help avoid many more cancellations due to no ward beds, the hospital chose to reduce

some off service admissions and open over capacity surgical beds. These operational de-

cisions are not reflected in the generic model. Thus, since the generic model produced

results that were within range or above historical throughput volumes, while simulta-

neously reporting higher than historical cancellation results, it was determined that the

model was accurate.

At the other hospitals (Brampton, Etobicoke and Prince Albert), objective valida-

tion proved to be more challenging. The main challenge was significant differences in

throughput numbers from the simulation model compared to historical, which affects

other measures such as cancellation numbers, OR utilisation and unit census. In some

cases the model would significantly over predict throughput for one or more services,

while under predicting others. Final validated results are provided in tables 5.5 to 5.9

for Brampton, Etobicoke and Prince Albert.

Demonstrating accuracy of large, complex, real systems, such as the perioperative

patient flow, is bound to be challenging if not impossible (Blake et al., 1995). The

experience and results of validating this generic model is no exception. As shown above,

full validation, in the statistical sense, was not achieved at any of the sites. Model results


MeasureHistorical

Value

Model

Result

+/- 95%

CIError

Throughput by Patient Type

Elective 443 453.2 6.8 10.2

Urgent 126 125.0 9.3 -1.0

Throughput by Service

GENL 161 162.0 3.9 1.0

OBGY 38 44.3 4.0 6.3

ORTH 251 254.7 7.9 3.7

PLAS 12 15.8 1.3 3.8

UROL 107 101.4 7.8 -5.6

Cancellations by Reason

No ICU Bed Cancellations 0.0 1.0 1.4 1.0

No Ward Bed Cancellations 1.0 11.4 8.6 10.4

Not Enough OR Time Cancel-

lations10.0 13.2 1.8 3.2

Bumped for More Urgent Case

Cancellations1.0 2.6 0.5 1.6

Other Cancellations 12.0 13.0 2.7 1.0

Table 5.1: Validation results from the Juravinski Hospital’s all services generic model

application. Bold type indicated when the confidence interval from the model results

does not include the historical value.


MeasureHistorical

Value

Model

Result

+/- 95%

CIError


All Elective 1763 1748 15.4 -15

All Emergent 625 634.8 16.3 9.8


CAR 57 60.1 5.8 3.1

CVS 203 201.1 5.2 -1.9

ENT 146 149 3.2 3

EYE 389 394.5 6.6 5.5

GYN 245 241.3 6.2 -3.7

NS 240 233.8 8.8 -6.2

ORT 495 493.7 8.9 -1.3

PLA 106 102.1 6 -3.9

SUR 331 322.9 9.4 -8.1

URO 72 77.8 4 5.8

VAS 104 106.5 4.7 2.5

Table 5.2: Validation results from St. Mike’s Hospital all services generic model appli-

cation - Throughput. Bold type indicated when the confidence interval from the model

results does not include the historical value.


MeasureHistorical

Value

Model

Result

+/- 95%

CIError


No ICU Bed Cancellations 1 0.6 1 -0.4

No SDU Bed Cancellations 0 0 0 0

No Ward Bed Cancellations 7 7 6.2 0


lations27 63.9 5.3 36.9


Cancellations40 36.4 6.7 -3.6

Other Cancellations 240 234.7 13.4 -5.3

Table 5.3: Validation results from St. Mike’s Hospital all services generic model appli-

cation - Cancellations. Bold type indicated when the confidence interval from the model



MeasureHistorical

Value

Model

Result

+/- 95%

CIError


Elective 388 380.3 8.3 -7.7

Urgent 85 85.0 8.4 0.0


GENL 473 465.3 11.1 -7.7


No ICU Bed Cancellations 1.0 0.0 0.0 -1.0

No SDU Bed Cancellations 0.0 0.0 0.0 0.0



lations28.0 27.9 4.3 -0.1


Cancellations5.0 1.3 1.1 -3.7

Other Cancellations 30.0 31.3 4.0 1.3

Table 5.4: Validation results from Mt. Sinai Hospital general surgical service generic

model application. Bold type indicated when the confidence interval from the model



MeasureHistorical

Value

Model

Result

+/- 95%

CIError


General Surgery 412.1 407.6 13.4 -4.4

Obstetrics and Gynaecology 278.0 272.9 8.2 -5.1

Ophthalmology 285.9 299.6 17.4 13.7

Oral Maxillofacial/Dental 25.7 35.6 5.3 10.0

Orthopaedic Surgery 271.8 320.4 8.9 48.6

Otolaryngology 106.8 124.7 3.9 17.9

Urology 119.1 119.9 4.7 0.8


No ICU Bed Cancellations N/A 0.0 0.0 N/A

No Ward Bed Cancellations N/A 0.0 0.0 N/A


lationsN/A 37.6 3.7 N/A


CancellationsN/A 11.6 2.7 N/A

Other Cancellations N/A 0.0 0.0 N/A

Table 5.5: Validation results from Prince Albert Hospital generic model application. Bold

type indicated when the confidence interval from the model results does not include the

historical value.


were within the 95% confidence interval range for many of the output measures at most

sites, especially in the first three (Juravinski, Mt. Sinai and St. Mike’s). Despite the

gaps in statistical validity, there is confidence that the generic model is accurate and is

acceptable as a decision tool.

Tactical planning and decisions are made in consideration of the policies and proce-

dures in place or to be amended. Decisions should not be made based on the assumption

that these existing policies and procedures will not be adhered to. For instance, it is

considered inefficient to operate with a low elective OR utilisation rate. However, if a

hospital does not ensure that time is fully and effectively booked, significant under util-

isation will result. Under booking could occur for a number of reasons such as under

filled OR blocks, over estimation of procedure length, and not reassigning part or full

blocks released by a surgeons. It is not practical to make tactical planning decisions such

as the MSS or resource availability assuming under utilisation of an expensive resource.

Tactical decisions should be made on the basis of how processes “should work”; then

operationally, decisions may need to be made to accommodate deviations from proce-

dures and practices. As a result of this notion simulation model results are affected as

the design does not include these poor practices. This does not make the model inac-

curate or meaningless. It is argued here that this property in fact makes the tactical

decision model more powerful as it demonstrates the outcomes of having good practices

and decisions in place, the ideal conditions in which to base tactical decisions.

It is here where an important contribution to the field of validating large, real world

complex system simulation models and specifically generic models, is proposed: how can

one achieve user acceptance when statistical validation is not possible, such that decision

makers are willing to base important decisions on model results. The remainder of this

section will review how user acceptance was achieved at Brampton where initial attempts

at statistical validity met with significant difficulty.


MeasureHistorical

Value

Model

Result

+/- 95%

CIError


Elective 2304 2387.1 50.6 83.1

Urgent 447 492.2 14.4 45.2


Dentistry 73 70.9 2.5 -2.1

Ear Nose and Throat 223 220 8.9 -3

General 546 595.8 13.1 49.8

Gynaecology 240 246.7 10.3 6.7

Ophthalmology 877 922.1 10.3 45.1

Oral Surgery 40 45 3.9 5

Orthopaedics 428 439.7 11.9 11.7

Plastics 70 75.5 5.1 5.5

Urology 254 274.7 16.8 20.7

Table 5.6: Validation results from Brampton Hospital generic model application -

Throughput. Bold type indicated when the confidence interval from the model results



MeasureHistorical

Value

Model

Result

+/- 95%

CIError



No SDU Bed Cancellations 0 7.1 8.17 7.1



lations23.08 173.8 11.73 150.72


Cancellations4.62 15.8 3.32 11.18

Other Cancellations 498.75 282.1 12.77 -216.65

Table 5.7: Validation results from Brampton Hospital generic model application - Can-

cellations. Bold type indicated when the confidence interval from the model results does

not include the historical value.


MeasureHistorical

Value

Model

Result

+/- 95%

CIError


Elective 1036.0 1022.0 16.6 -14.0

Urgent 227.0 231.9 9.9 4.9


Ear Nose and Throat 170.0 162.5 5.6 -7.5

General 279.0 272.3 9.0 -6.7

Gynaecology 267.0 278.4 4.6 11.4

Oral Surgery 38.0 34.2 2.5 -3.8

Orthopaedics 326.0 334.5 16.2 8.5

Plastics 121.0 115.5 6.0 -5.5

Urology 67.0 86.5 6.1 19.5

Table 5.8: Validation results from Etobicoke Hospital generic model application -

Throughput. Bold type indicated when the confidence interval from the model results



MeasureHistorical

Value

Model

Result

+/- 95%

CIError


No ICU Bed Cancellations 0.0 0.0 0.0 0.0




lations3.2 17.3 2.7 14.1


Cancellations0.5 7.6 2.8 7.1


Table 5.9: Validation results from Etobicoke Hospital generic model application - Can-

cellations. Bold type indicated when the confidence interval from the model results does

not include the historical value.


5.1.1 Achieving Validity and User Acceptance at Brampton

Civic Hospital

A large working group was assembled at Brampton that included the director of pe-

rioperative services, various perioperative and inpatient unit managers, physician and

surgeon leaders and the consulting firm members. Initially, one calendar year of data

was provided for model analysis and implementation. Over the course of the data, three

different master surgical schedules (MSS) were used at Brampton: spring, summer and

fall. Additionally, some new surgeons joined and others left the hospital during this

time. Together, these factors resulted in significant variability over the year of data. In

consultation with the working group, it was determined that the fall schedule would be

used for model validation as it was most current.

The first validation attempt, used the fall MMS as planned. The model outputs (ta-

bles 5.10 and 5.11) contained significant prediction error: the initial schedule significantly

over predicted elective volumes for all services, while under predicting urgent volumes.

These results were brought to the working group for discussion where it was revealed

that the MSS schedule realised is not always reflective of the month’s planned MSS. For

each month, a monthly MSS was produced that took into account holidays and other OR

closures, and any planned days released by surgeons who gave up time due to vacation or

other reasons, and those surgeons who picked up the open slots. The resulting monthly

MSS schedules included a significant number of ORs that were closed because no surgeon

picked up the released time of other surgeons, reducing the total number of elective OR

hours.

As such, the schedule of the month of November was selected by the working group as

a month representative of the fall schedule. When the November schedule was tested in

the model, discrepancies still remained but throughput for some services were predicted at

rates close to the historical values. However, other services’ throughput were predicted at


MeasureHistorical

Value

Model

Result

+/- 95%

CIError


Elective 4055.0 4007.1 47.6 -47.9

Urgent 940.0 844.7 19.5 -95.3


Dentistry 147.0 147.7 6.0 0.7

Ear Nose and Throat 416.0 447.1 8.6 31.1

General 1051.0 1038.4 19.2 -12.6

Gynaecology 444.0 410.2 20.0 -33.8

Ophthalmology 1430.0 1429.0 31.9 -1.0

Oral Surgery 65.0 66.8 5.3 1.8

Orthopaedics 768.0 638.8 9.0 -129.2

Plastics 182.0 181.1 4.6 -0.9

Urology 519.0 517.2 7.5 -1.8

Table 5.10: First attempt at validating at Brampton Hospital using the Fall 2009 MSS

schedule as planned. Bold type indicated when the confidence interval from the model



MeasureHistorical

Value

Model

Result

+/- 95%

CIError






lations23.1 12.2 4.0 -10.9


Cancellations4.6 3.5 1.3 -1.1


Table 5.11: First attempt at validating at Brampton Hospital using the Fall 2009 MSS

schedule as planned - Cancellations. Bold type indicated when the confidence interval

from the model results does not include the historical value.


levels significantly higher or lower than historical. Further analysis of the data and model

results as well as consultation with the working group were performed. This yielded a

number of observations of the current system/process that when inputted improved model

results.

The input changes performed included adjustments to the time booked for surgery,

the composition of the patient input file and the MSS. The data analysis, working group

insight and result model changes are provided.

Booked Time Adjustment: Based on an observation of working group members that

over- and under-booking practices were present and significant, surgical data was analysed

to examine any trends. A report (figure 5.1) was compiled comparing the amount of time

booked to the amount of time used by the surgeon.

It was found that some surgeons and some services consistently under book the time

required for an elective case; allowing surgeons to book more cases in a day. Whereas

in actuality, surgeons were often allowed to run into overtime, despite hospital rules.

The model is not as flexible and forgiving in regards to allowing elective cases to run

into overtime, thus reducing throughput because of a high a number of overtime can-

cellations. The data demonstrated that the under booking was mostly due to surgeons

not accounting for the turnaround time required between cases. To account for this in

the model when scheduling these services and surgeons, the average turnover time was

added to the booked time when scheduling patients to better fill the day, reducing the

cancellation rate. This of course does not help with the fact that the hospital may allow

overtime for surgeons with this practice, hence throughput for some services was still

low, though the cancellation rate was more accurate.

Patient File Adjustments: As described in the previous chapter, the model is sensitive

to the proportion of patients in the patient file compared to validation numbers. The

working group noted that over the course of the year of historical data, the case loads

of surgeons changed significantly due to surgeons joining the hospital, and/or increasing


Figure 5.1: Example of a report provided for validation analysis comparing the amount

of time booked by surgeon versus the amount of time actually used during elective block

time.


their practices, while others were reducing their practices. This can be quantitatively seen

in figure 5.2. The report includes the proportion of patients belonging to each surgeon

within the input patient file used by the generic model to generate patient characteristics;

and the proportion of throughput belonging to each surgeon during the time frame for

validation. The final column highlights the difference in these two proportions. The

patient records were increased for surgeons whose caseloads were higher in the validation

period of fall 2009 than in the historical patient file to be more representative of current

mix.

Further MSS adjustments: Even after the above adjustments, throughput numbers

were still not as close as desired. Analysis showed that even the November MSS was

not entirely reflective of the actual schedule. Moreover, elective OR time was frequently

released or exchanged after the month’s MSS was published, resulting in further changes

to the schedule, including reduction in the elective OR time used. The inputted MSS

was modified to reflect these differences.

In addition, it came to light that some orthopaedic OR blocks were being run as swing

rooms, where the same surgeon and surgical team would have access to two ORs. When

one case was complete in the first OR the team would move immediately to the other

OR and perform another surgery, instead of waiting for the first OR to turnover. These

swing rooms were used to complete total joint replacements. Using a single OR, a high

total joint case surgeon could perform four procedures; using a swing room, the same

surgeon could perform two additional cases. The planned MSS did not clearly indicate

that swing rooms were in use, so were not included in the first round of validation.

After incorporating these changes to the model, the validation results produced

showed improvement on prediction error, as demonstrated in tables 5.12 and 5.13.

At this point, the working group felt that the model was a reasonably good repre-

sentation of their practices, at least in terms of the model design and assumptions. Un-

fortunately, statistical validation was still not achieved on most measures. They noted


Figure 5.2: Example of a report provided for validation analysis comparing the percentage

of patients by surgeon historically and within the input patient file.


that in the last five or so months, many of the issues around the MSS and scheduled

time had improved. Additionally, further changes to the surgeons currently practising at

Brampton, and their proportion of cases within each service had changed. Consequently,

the working group felt that better validity and credibility would be gained if more current

schedules and data were used. The most recent two months (April and May 2010) of OR

data was pulled for another round of validation.

MeasureHistorical

Value

Model

Result

+/- 95%

CIError


Elective 4055.0 4394.1 23.6 339.1

Urgent 940.0 923.2 9.5 -16.8


Dentistry 147.0 144.5 1.5 -2.5

Ear Nose and Throat 416.0 420.2 4.9 4.2

General 1051.0 1078.4 9.5 27.4

Gynaecology 444.0 483.0 5.3 39.0

Ophthalmology 1430.0 1671.1 12.1 241.1

Oral Surgery 65.0 67.2 1.7 2.2

Orthopaedics 768.0 734.1 9.4 -33.9

Plastics 182.0 218.4 2.2 36.4

Urology 519.0 522.4 4.6 3.4

Table 5.12: Second round at validating at Brampton Hospital using the November 2009

MSS schedule as a representative schedule for Fall 2009. Bold type indicated when the

confidence interval from the model results does not include the historical value.

In order to avoid some of the issues encountered with the MSS in previous validation


MeasureHistorical

Value

Model

Result

+/- 95%

CIError


No ICU Bed 0.6 0.7 0.4 0.1

No SDU Bed 0.0 11.9 5.0 11.9

No Ward Bed 0.9 57.7 25.4 56.8

Not Enough OR Time 23.1 300.7 13.4 277.6

Bumped for More Urgent Case 4.6 17.1 1.6 12.5

Other 498.8 487.2 7.7 -11.6

Table 5.13: Second round at validating at Brampton Hospital using the November 2009

MSS schedule as a representative schedule for Fall 2009 - Cancellations. Bold type indi-

cated when the confidence interval from the model results does not include the historical

value.


efforts, an eight week MSS was created based on the two new months of data. The

patient file remained the same - based on the original year of data provided. Using the

actual schedule as the MSS helped make initial results significantly closer to historical.

Based on data analysis and expert opinion from the working group only a few additional

minor adjustments were required to further calibrate the model:

• It was observed in the data that many services were running over their elective

blocks. To represent this, OR blocks were extended by 30 minutes for all services

except ophthalmology and plastics.

• Some surgeons were found to consistently under book their OR blocks. These

surgeons were assigned only half days in the model to reflect this trend.

These adjustments brought calibration to a reasonably close level. Overall, the up-

dated analysis on utilisation of elective blocks, including under and over booking, and

trends in booked time compared to actual time demonstrated that though there was some

improvement in these practices since the analysis done on Fall data, there is still room

for improvement. These areas of improvement were part of the overall plan that William

Osler and the consulting firm were implementing to improve perioperative performance.

As a result, the working group felt that the current model at Brampton was sufficiently

accurate and credible. Differences between the model’s results and historical data were

likely due to the variance in practice from what is generally considered best practice as

assumed in the model, and the current practices at William Osler. Therefore, the model

results based on the actual schedule for April-May 2010 as demonstrated in tables 5.6

and 5.7 represented what likely would have been done if practices at Brampton better

conformed to best practices. The working group felt confident that the model’s outputs

were now reflective of their hospital if the identified poor and inefficient practices were

not present at the time. This allowed the application of the model to progress as a

demonstrative and decision tool as outlined in Chapter 6.


5.2 Challenges of Achieving User Acceptance

An important feature when evaluating the value of a generic model is that the use of a

generic model does not induce significant additional challenges. Use of a generic model

should not require significantly more effort to set up, validate and use the model when

compared to a specific model.

This section will discuss the challenges encountered when applying the generic model

to six hospitals. Many of the challenges experienced implementing the generic model

were similarly encountered when a specific model was built for the initial test site, the

orthopaedics service at Juravinski. This will be demonstrated in the next section.

Master schedule vs. actual schedule - During validation at several sites it was dis-

covered that the planned master surgical schedule was not followed in actuality. While

any hospital will have some minor adjustments to the block schedule over time due to

planned and unplanned OR closures, changes to service or surgeon assignment, etc., sev-

eral hospitals’ actual block schedule differed significantly from planned. If the schedule

inputted in the model was based on the master schedule, and the actual schedule dif-

fered significantly, validation was not successful. In these cases, if the data was used to

generate a schedule based on the actual schedule instead of the master schedule, then

validation was more likely to be achievable.

Arrival rates and waiting list sizes - An important input to any simulation model is

the arrival rate. Unfortunately at the time of data collection, the hospitals studied did

not collect accurate or reliable information on the waiting lists for all surgeons and cases;

arrival rates and waiting list sizes were unavailable. As a result, initial waiting list sizes

and arrival rates were estimated.

Arrival rates were initially estimated based on the actual number of cases performed

during the time period studied. During validation, it was found that these estimates

would generally lead to throughput values being under predicted. This result is intuitive

as the initial estimated arrival rate was based on realised throughput, which ignores


cancellations and other factors that increase the actual arrival rate.

In order to achieve model results within an acceptable range of accuracy compared to

historical values, the arrival rates and initial waiting list sizes were increased incremen-

tally.

Surgeon booking practices - In reality, when surgeons book cases into their OR blocks,

they may adjust the booking time in order to fit cases within the length of the block. For

instance, a surgeon has two hours of time remaining, but the next patient on his waiting

list is usually booked for two and a half hours. If the surgeon feels he can likely speed up

the day’s cases in order to finish on time, he will book that patient for two hours. The

model, however, does not account for this behaviour. Thus it was found that in some

cases throughput and OR utilisation were lower than expected. In these cases, increasing

the OR blocks by 30 minutes resolved the issue.

Overtime allowance - Most hospitals encountered in this study allowed little tolerance

for running past the end of the scheduled block because of staff overtime costs. Usually,

less than 30 minutes of predicted overtime was tolerated by the hospitals studied. The

model has been set up to allow up to a fixed inputted number of minutes of overtime,

based on the remaining time in the block and the time booked for the case. What the

model does not include is the effect of a surgeon who is likely to speed up when faced

with possibly having a case cancelled due to overtime. Additionally, other factors are

often considered in allowing overtime that vary widely by hospital and are difficult to

model. For instance, some will allow overtime if the OR team is willing to stay. Another

example is that they will allow it if they can still do any urgent cases within the time

frame based on the number of ORs that remain open to handle urgent cases.

Since these effects are not considered in the model it sometimes becomes a challenge to

validate the number of cancellations due to overtime. When the rate was predicted by the

model it was significantly higher than actual instances, increasing the inputted allowable

overtime helped decrease the cancellation rate towards a more accurate prediction.


Patient file composition - Another challenge identified during validation at multiple

sites concerned the inputted patient file. If the proportion of patients in the file did

not closely match the proportion of patients seen during the time frame of validation,

the simulation results would not validate well with historical values. For example, at

Juravinski, patient level data for two years was available and inputted into the patient

file. Over the span of these two years, several surgeons joined the program. During the

chosen validation time period, these surgeons had built up their practices. The data

however did not include the current proportion of patients the surgeons see since it is

over a longer time period than the validation figures. This reduced the probability that

a patient of that surgeon would be selected on arrival, which in turn resulted in lower

than expected throughput for these surgeons.

As a demonstration, imagine that within two years of patient records, surgeon A joined

the hospital after the first year of data. When surgeon A first joined, it took six months

to build up his practice, during which time he only performed 10% of cases. In the last

six months of data surgeon A was performing 25% of all cases within his service. Prior to

surgeon A joining, the service’s cases were performed evenly between the other three sur-

geons. Thus, over the two years of data, the proportion of patients belonging to surgeon

A is only [14(6months2years)+ 1

10(6months/2years)+0(1year/2years)] ≤ 25% of patients.

There are two options to overcome this challenge. First, the patient file can be reduced

to only include patients from the time period studied. This ensures that the proportions

are closely related to the throughputs being validated. In the example, the patient file

would be reduced to only include patients operated on in the last six months of the

data pull; thus excluding the first year and a half of data available. This option is fairly

easy to implement, but reduces the variation of possible types of patients in the model.

This in turn may reduce the robustness and reality of the model for scenario testing and

continued use.

A second option is to manipulate the current patient file such that the proportions


better match the current mix. This can be done by duplicating patient records of the case

type that needs to be increased. In our example, one would copy the patients of surgeon

A in the patient file in order to increase the percentage of cases within his service. This

option does not reduce the variability of cases available overall.

Significant deviation from “best” practice - The final challenge faced with demon-

strating the accuracy and validity of the generic model was with hospitals that signifi-

cantly deviated from “best practice”. Hospitals that allowed blocks to regularly be under

booked, or that allowed surgeons to poorly estimate the time required to complete a case,

became especially challenging as the model assumes that best practices are generally ad-

hered to. Despite attempting various calibration techniques, including those described

here, the model was unable to predict historical throughput. Analysis of the data, and

interviews with decision makers and perioperative subject matter experts within the

hospital revealed that poor practices were allowed.

In these cases, a key value of the generic model is not only to be used as a decision tool

for hospitals to explore changes, but also as a demonstrative tool to identify these poor

practices, quantify their effects on outcome measures, and demonstrate what is possible

if these best practices were better followed. More on the value of the generic model as a

decision and as a demonstrative tool is reserved for Chapter 6.

5.3 Compared to a Specific Model

Prior to conceptualising the generic model, the orthopaedic surgical service at Juravinski

was modelled as a specific model; created from scratch, for the sole purpose of being used

for orthopaedic surgery at Juravinski and to gain preliminary insights into modelling

perioperative patient flow for tactical decisions. It is rare to find a generic model in

the literature that is compared to a specific model. In this section, a comparison of the

specific and generic models is made. In conjunction with an engaged working group at


this hospital, this specific model was validated and used a number of times as a decision

tool. The focus here is to demonstrate that a model created specifically for the hospital

studied can experience the same challenges as when applying a generic model. The

accuracy of the generic model is compared to the specific model in terms of the same

four facets: validity, credibility, utility and feasibility.

5.3.1 Validity of the Specific Model

In conjunction with the engaged working group at Juravinski, the process of validation

and achieving model credibility followed a typical reiterative approach. The process

began through a series of onsite interviews and real time observation of the current

processes. Based on the information gathered, detailed process map was created and

verified by the stake-holders. The process map subsequently informed the conceptual

design of the specific model. The model design was also agreed upon by the stake-

holders, including assumptions and simplification decisions. The specific model was then

coded. Any changes to the design made when building and validating the model were

also discussed and approved by the working group.

The validation process, also took an iterative approach by presenting current model

results on a regular basis in order to discuss any results whose 95th percentile confidence

interval did not include the historical value. Together, the team would discuss possible

reasons for any discrepancies, and suggest reasonable and appropriate changes to the

input data and assumptions. This iterative process towards designing, building and

calibrating the model resulted in high credibility of the specific model’s outputs when

conducting scenario tests. The final validated results to the historical data as approved

by the working group is provided in table 5.14.

The model was successfully implemented and used as an interim decision tool for the

orthopaedic service at Juravinski, further demonstrating its validity and credibility in

the eyes of the end users who trusted the model’s results for decision making.


5.3.2 Comparing the Specific and Generic Models

The intention of this section is to demonstrate that use of a generic model does not

necessarily mean one has to sacrifice validity and credibility.

In order to demonstrate that the generic model can produce similarly reliable results

as a specific model, the inputs of the validated specific Juravinski orthopaedic model

were inputted into the generic model. The generic model inputs were then calibrated to

achieve statistically validated results. A comparison of the outputs of the generic and

specific models based on the same inputs are provided in table 5.14.

With the same input values as the specific model, the generic model appears to pro-

duce higher throughput values compared to the specific model. In both applications, the

number of completed urgent cases is significantly higher than historical values. Valida-

tion of the specific model required increasing arrival rates and initial waiting list sizes

in order to achieve desired throughput values. Reducing these input values in the vali-

dated generic model increased the predictive accuracy of the generic model compared to

historical data. For example, the urgent arrival rate was reduced to achieve a confidence

interval range within the historical results. The calibrated generic model however still

results in a lower than historical range of other orthopaedic cases, as well as fewer can-

cellations. The ICU cancellation rate discrepancy is likely due to the fact that in both

models, the full ICU is not modelled as it also services medical patients. Thus, the num-

ber of available beds for surgery is not constant as modelled. A lower cancellation rate

due to more urgent cases is likely a result of modelling assumptions and simplifications.

Cancellations due to no ward bed is higher than expected, likely a result of the fact that

the real life decision to use over capacity beds and push out off-service patients is not

modelled.

Similarly to the successful implementation of the generic models at other sites, the

key factor to the credibility of the specific model is the high and consistent involvement

of decision makers during the entire life cycle of the study. The high involvement of the


Mea

sure

His

tori

cal

Val

ue

Sp

ecifi

cM

odel

Gen

eric

Model

Gen

eric

Model

Cal

ibra

ted

Thro

ugh

put

by

Pat

ient

Typ

e

Ele

ctiv

e14

421418.8±

11.2

1490.3±

12.9

1439

.5±

13.9

Urg

ent

82164.5±

7.8

157.6±

11.3

87.5±

6.4

Thro

ugh

put

by

Pro

cedure

Typ

e

Fra

cture

dhip

s31

66.6±

5.3

60±

7.5

31.1±

2.3

TJR

991

993.

5±13

.1909.1±

11.1

978.

9±

14.9

Oth

er54

5525.1±

13.3

709.8±

11.9

529.4±

15.5

Can

cellat

ions

by

Rea

son

No

ICU

Bed

40.2±

0.30

160±

00±

0

No

War

dB

ed3

3.5±

2.7

16.9±

614.2±

5.1

Not

Enou

ghO

RT

ime

1920

.2±

3.8

28.5±

3.9

21.9±

5

Bum

ped

for

Mor

eU

rgen

tC

ase

21±

0.7

0.3±

0.3

0±

0

Oth

er37

34.8±

4.1

37.8±

3.7

36.3±

3.1

Tab

le5.

14:

Com

par

ing

validat

ion

resu

lts

ofth

esp

ecifi

cm

odel

toth

ege

ner

icm

odel

for

the

Jura

vin

ski

Hos

pit

al’s

orth

opae

dic

serv

ice

applica

tion

.B

old

face

dty

pes

isuse

dto

indic

ate

when

the

his

tori

cal

valu

eis

outs

ide

ofth

eco

nfiden

cein

terv

alpro

duce

d

by

the

model

.


hospital’s decision makers leads to high credibility of the specific model and multiple

rounds of scenario testing. Evaluation of the scenario tests then leads to implementation

of suggested elective block schedules and scheduling rules over the course of three years.

A side benefit noted was that the confidence in the specific model increased the

confidence and credibility of the generic model when it was introduced later to model all

surgical services at the same hospital.

Overall, the generic model can be considered an accurate representation of the peri-

operative process, when compared to historical data and a specific model.

5.3.3 Differences in Model Design

It is important to note that there are some differences between the functionality and

design of the specific model to that of the generic. Figure 5.3 compares the two models

in terms of what is and is not included, and some key assumptions.

Based on the level of detail, scope and objectives chosen during the conceptual mod-

elling of the generic model, a number of patient holding areas were not included: patient

registration, same day surgery waiting area and patient rooms, and anaesthesia induction

rooms. However, the specific model included these areas with the exception of anaesthesia

induction rooms, which Juravinski does not have.

5.3.4 Challenges Compared to a Specific Model

Validating the specific model for the orthopaedic surgical service at Juravinski faced

several challenges, many similar in nature to those faced with validating the generic

model. Table 5.15 compares the challenges faced during validation of the generic and

specific models.

Similar to instances in the generic model, achieving historical volumes in the specific

model required increasing the arrival rates of patients in order to fill the wait lists with

a wide variety of patients to schedule.


Specific Model Generic Model

Pre-Operative Processes

Waiting List ! !

Organisation and Ordering ! !

Waiting time and length ! !

Scheduling ! !

Block and surgeon schedules ! !

Elective patient scheduling rules ! !

Urgent and Emergent patient scheduling rules ! !

Inpatient scheduling rules ! !

Priority/Urgency considerations ! !

Maximum wait time on list ! !

Reserved time for Fractured hips ! !

Sequencing ! !

Pre-Operative Clinic " "

Operative Processes

Registration ! "

Same Day Surgery Unit waiting area and rooms ! "

Anaesthesia Rooms n/a "

Pre-Operative Waiting Area ! "

Check for post-operative recovery bed ! !

Cancellation due to "other" reasons ! !

Cancellation due to overtime or urgent case bump ! !

Procedure ! !

Length of procedure ! !

OR block due to resource unavailable ! !

Turnaround time ! !

Post-Operative

Post-Anaesthesia Care Unit ! !

Nurse and Bed availability ! !

Intensive Care Unit ! !

Step Down Unit ! !

Wards ! !

Off-servicing due to bed unavailability ! !

Bed blocking due to bed unavailability ! !

Process

Figure 5.3: Comparing the specific and generic model in terms of areas included and key

assumptions.


Challenge Specific Generic

Volumes - increased arrival rates and initial waiting list num-

bers to achieve throughput volumes

Y Y

Patient File - Adjustment of proportion of cases to reflect

current reality/validation period

Y Y

Overtime Cancellation - increase fixed rule amount to reduce

model cancellation rate

Y Y

Surgeon booking practices - increase elective block time to

calibrate OR utilisation and throughput

Y Y

Master Schedule vs. actual schedule - ensure inputted sched-

ule reflect practice for validation purposes

Y Y

Deviation from “best practice” N/A Y

Decision Options - Unable to test options under consideration

without changes to model code

Y N

Table 5.15: Comparing the challenges faced when modelling perioperative services, using

the proposed generic model and to using a specific, custom made model.


The specific model also had similar issues in achieving throughput of total joint cases

because the patient file inputted originally had a lower proportion of total joint replace-

ment (TJR) cases compared to current case mix. The patient file was adjusted to reflect

current TJR rates by duplicating a random number of TJR cases to increase the propor-

tion, which yielded better results.

In summary, the specific model experienced similar challenges, demonstrating that

the challenges faced when using the generic model were not due specifically to the use of

a generic model, but rather the nature of the system under study and the data available.

There was one challenge experienced during the implementation of the specific model,

which was not experienced in the generic model. During scenario testing with the specific

model, it was discovered that some desired scenarios were not easily tested because of

hard coded information or processes. This meant that changes to the code itself were

required for some scenarios. The generic model was built on the principle of data-driven

simulation modelling, limiting the number of processes or data that are hard coded into

the model, thus reducing the likelihood that scenario tests will require changes to model

code or structure.

5.4 Guidelines for Achieving User Acceptance

As discussed in this chapter, achieving confidence in this generic model has been fraught

with challenges. Through the successful application of this generic model to numerous

hospitals, a better understanding of how to establish user acceptance, both in terms of the

accuracy of and confidence in the results, as been gained. Herein, steps have been outlined

to calibrate a generic model such that it provides reasonably accurate results and to

convince end users that the model can be trusted to support important tactical decisions.

The guidelines are presented such that they are applicable to simulation modelling in any

industry. They are geared towards generic models of tactical decisions, however can be


adapted for specific models.

The end goal of validation should be when the decision makers and users of the

simulation “accept the model as correct” (Law, 2005).

5.4.1 Step 1: Assemble an Engaged Working Group

As many modellers have noted, including Law (2005), having an engaged group of deci-

sion makers and users involved throughout the phases of a simulation project is key to

achieving model acceptance.

Working closely with the hospitals’ decision makers and subject matter experts was a

key factor in obtaining subjective validity of the generic model. At sites where a working

group was assembled to work with the simulation modelling team on the project, model

validation was able to go beyond objective techniques, building trust in the model such

that decision makers were confident to base decisions on results.

Membership of the working group should be wide and encompass the whole system.

The working group should not be limited only to decision makers, but should also include

subject matter experts, and stakeholders that would be affected by any decision resulting

from the model. In the case of the proposed perioperative generic model, working group

members should include managers, surgeons, and front line staff such as nurses. Mem-

bership should also cover the entire perioperative system, from the OR, to the PACU,

pre-admission clinic, as well as the surgical inpatient units, including stakeholders from

the emergency department and medical inpatient care.

5.4.2 Step 2: Review of the Generic Conceptual Model

One of the disadvantages of using a generic model is that the model design, assumptions,

simplifications, etc., were previously determined without the input or involvement of the

current decision maker. Whereas in the typical specific simulation model study, one of

the first steps to achieving model credibility is to review the conceptual model design with


the decision makers to seek approval and acceptance (Robinson et al., 2010). Typically,

when building a specific model, user input into the conceptual design of the model helps

gain credibility as users are part of the process; take part in decisions about abstractions,

simplifications, scope and level of detail. This needs to be recreated for decision makers

when using a generic model. In order to do so, this paper recommends that a thorough

and purposeful review be conducted of the generic model with the working group of

decision makers and stakeholders.

To begin, it is suggested that a detailed understanding of the site’s processes is gar-

nered by interviewing process owners, including managers and front line staff, and con-

ducting observations of the processes within model scope. This will also aid in getting

buy-in from the decision makers through on-going contact and demonstrating knowledge

of their processes.

Next, a review of the generic conceptual model in terms of its objective, scope, level

of detail, assumptions and limitations should be conducted with the working group.

This is to ensure that model processes, assumptions and behaviours are comparable

to the real system. This review should include comparing the generic model’s design

with the processes and procedures of the hospital, with particular focus on where model

simplifications and assumptions may differ. Where there are differences, it is important

to include a plan of how it would likely affect the model results, and how, if needed the

model will be adjusted to reflect these differences.

5.4.3 Step 3: Calibrate Model

This step can be considered your typical attempt at objective validation: making adjust-

ments to model inputs and design in an attempt to reduce prediction error.

During the validation stage, regular updates on progress, including demonstrating

interim results, will prove invaluable in garnering model credibility. Discussions on re-

sults, inputs and assumptions, and discussion on reasons for validation challenges will


help to include the decision makers and increases their knowledge and understanding of

the generic model, leading to increased credibility.

During this validation step it is recommended to review the current validation re-

sults with the working group, and try to identify likely reasons for difference between

model outputs and historical results. In order to help uncover likely reasons, create var-

ious reports that can help verify model assumptions, and compare model and historical

processes and values.

For example, as described earlier at Brampton, three reports were used to help iden-

tify how inputs could be adjusted to improve variability: analysis on historical booking

practices by surgeon (figure 5.1 on page 104), comparing the surgeon’s case load in the

input file compared to historical performance (figure 5.2 on page 106) and comparing the

realised elective schedule to the planned MSS.

In addition, review again the assumptions and inputs of the model to actual processes.

Determine if there are any notable differences that could be affecting the results. If there

are, determine if the model inputs can be adjusted to reduce the effect of the difference.

5.4.4 Step 4: Reconcile Model Results

When model outputs are “close” to actual, and no reasonable model input adjustments

can be made, focus on explaining the prediction error. This step should be done with

significant involvement with the working group. After all, it is the working group at

the end of the day that must feel that the model’s results can be trusted when making

decisions. Reports, such as those generated in Step 3 should be produced to guide this

reconciliation process.

For example, in the case of Brampton, after the second round of validation, discrep-

ancies still remained. Reports, including surgeon booking practices, late OR block starts,

realised block schedule vs. planned MSS, etc., were all used to demonstrate that current

poor practices in place at Brampton were affecting performance. In this step, the work-


ing group realised that the model’s outputs are based on the assumption that these poor

practices identified are resolved.

5.4.5 Step 5: Repeat and Re-evaluate

As with all validation exercises, it is a reiterative approach. Repeat steps three and four

until model credibility is achieved.

At this step, it would be prudent to re-review model design, assumptions, simplifica-

tions, etc. compared to the processes of the hospital. Any discrepancies identified should

be evaluated to determine their effect on achieving validity and credibility. Explore the

need to make changes to the model’s design to achieve acceptance. However, a well

planned and designed generic model (following the guidelines provided in the previous

chapter) should not require further coding. Changes to the actual design of the generic

model should only be done after careful consideration of the suggested change, and only

if it fits within the model’s problem description, scope and objectives and is common to

multiple potential sites.

5.4.6 Step 6: Accept the Model as Correct

After a series of iterations of steps three to five, the working group should come to

the consensus that the generic model is correct and can be used to guide their decision

making.

5.4.7 Final Notes

The greatest proof of acceptance of a generic model, or any model for that matter, is

the use of its results by the hospital to inform decisions. At the four highly involved and

engaged hospitals, the generic model has been used to inform decisions. For example, at

Brampton and Etobicoke, the model has been used to demonstrate the potential of the


current OR resources when elective booking policies, including accurate booking practices

and high OR utilisation are followed. In addition, the model was used to determine how to

assign elective blocks to accommodate new surgeons and achieve various volume targets.

At Prince Albert, the model was used to justify a request to the Ministry of Health for

commissioning (opening) a fifth OR in order to accommodate increasing demand and to

achieve aggressive provincial wait time targets. Further discussion on using the generic

model as a demonstrative and decision tool is reserved for the following chapter.

Chapter 6

A Decision and Demonstrative Tool:

Case Studies

The generic model has been proven to support decision makers as a decision and ne-

gotiation tool by allowing comparisons of decision options against multiple selected key

performance indicators. In addition, the generic model has proven useful as a tool to

quantify inefficiencies in current practices by demonstrating possible performance if those

practices were improved.

As a decision tool, the generic model was initially intended to answer tactical decisions

such as: “what is the effect of changing the block schedule on the orthopaedic ward?”,

“if we schedule three TJR per orthopaedic OR block, will the throughput of non-TJR

patients be adversely affected?”, and “how can we increase cardiac throughput to meet

our yearly targets?”.

However, during application of the model at various sites, it proved valuable as a tool

to demonstrate the effect of poor practices on a hospital’s performance. This gave rise to

a second use, as a demonstrative tool. The model can be used to answer such questions

as:

• A hospital currently performs poorly in on time starts - what is the effect of this

126

Chapter 6. A Decision and Demonstrative Tool: Case Studies 127

on their productivity?

• Blocks from the MSS are regularly left unfilled or partly unfilled - What is the

effect on volumes?

• What is the effect of the many OR block switches that occur on downstream re-

sources and outcome performance? Ex. Cancelations.

Through two case studies, this chapter will demonstrate the value of the proposed

generic model in terms of these two uses.

6.1 As a Decision Tool at the Juravinski Hospital

6.1.1 Problem Description

The Juravinski Hospital faced significant patient flow issues for both their surgical pa-

tients and medical patients. These issues resulted in elective, non-urgent surgical patients

regularly being delayed or cancelled when no inpatient bed was available, urgent surgical

patients not receiving care in a timely manner, patients being placed in off-program beds,

and medical patients being held in the emergency department as there was no appropriate

bed available.

In addition, the Ontario Ministry of Health and Long-term care (MOHLTC) recently

imposed funded volume targets for key surgical procedures in order to improve access

to care and reduce wait times in the province. The program provided additional fund-

ing to hospitals in exchange for increased volume commitments for specified procedures

including total joint replacements (TJR), cataracts, oncology and cardiology. If, at the

end of the funding year, the hospital was unable to achieve the agreed upon targets, the

hospital would face penalties including returning part or all of the funding provided, and

reduced target volumes and thus funding for future years. The hospital was challenged

to meet their target volumes.


Hospital decision makers were concerned about achieving their target volumes with-

out significantly affecting other procedures, and improving patient flow for all surgical

patients. As a result, they were interested in measuring throughput of cases by service

and for specific targeted procedures (total joint replacements and fractured hip repairs),

the number of cancellations caused by poor patient flow, and the bed resources required.

In addition, the hospital wanted to know what changes in tactical decisions could

be made to their block schedule, scheduling rules, and bed capacities in order to achieve

their targets. The administration was interested in an operations research tool that could

help inform their decisions by enabling them to test different possible solutions virtually

and compare outcomes. The tool would also be used to aid in negotiations with other

hospital stakeholders, including surgeons and the medical program administration, who

were concerned about the consequences of these perioperative decisions on their processes

and work.

They were also concerned with two key patient flow indicators: cancellations and in-

patient unit occupancy levels (census). In terms of cancellations, the administration and

surgeons felt that they were experiencing an unacceptably high number of cancellations

related to poor flow. Reasons for cancellations due to poor flow include cancellations

due to no ICU (Intensive Care Unit) or ward bed, cases cancelled because of block time

overrun, and scheduled elective patients bumped for more urgent patients.

In addition, the hospital regularly maintained a census above budget in order to

maintain procedure volumes and avoid cancellations. One of the reasons for the high

census was that medical patients frequently overflowed into surgical inpatient beds when

there were not enough medical beds available (referred to as off-service or off-program).

Surgical patient census also experienced variability over the week, with the highest census

mid-week, and lowest on Sundays.

As a result, hospital administrators were looking for help in making tough decisions

on how best to allocate limited hospital resources in order to meet their volume targets


and improve surgical patient flow, while not significantly impacting other patients and

services.

6.1.2 Solution

Due to the possible widespread impact of decisions from this project, it had a high profile

within the organisation, including interest from the most senior levels of the administra-

tion. A working team was assembled of key players at the hospital. The team included

the director of perioperative services, the managers of the operating room and the two

orthopaedic inpatient wards, the chief of orthopaedic surgery, the manager of the quality

department, and a decision support (data) expert.

The first task of the working team was to determine the scope and goals of the project,

including key performance indicators. As mentioned previously, the goal was to improve

tactical decisions of their perioperative service. The working group, in consultation with

stakeholders and the administration, defined the following objectives for this improvement

project:

• Achieve their yearly funded target volumes for total joint replacement procedures,

while maintaining current volumes of other procedures

• Complete urgent hip fracture repair procedures within the 48 hour target

• Reduce the daily peak number of beds required to achieve volumes, and if possible

level out the number of beds required over the week

• Reduce, or preferably eliminate, the number of cancellations due to no bed

• Improve the relationship between the hospital and surgeons by working with them

in promoting equitable access to services for patients

Based on these objectives, and the scope of the tactical decisions under consideration,

the working group wanted to focus on three key decision areas:


• The operating room block schedule: including the number and length of blocks

available, and the services and surgeons assigned to the blocks;

• Scheduling rules: such as the type of cases to be scheduled in a block, and how

to schedule emergent and urgent cases;

• Resource availability of post-operative bed resources: such as capacity of

recovery room capacity and inpatient beds, degree of bed blocking due to patients

from other programs occupying surgical beds, and the number of patients waiting

for alternate levels of care in acute beds.

The working group further identified three key outcome measures of interest for eval-

uating possible solutions based on their objectives:

• Throughput by service, and specifically for total joint replacements (TJR) and hip

fracture repairs;

• Number of cancelations by reason, with a focus on cancellations due to no bed;

• Daily midnight census of the inpatient units.

Based on the scope and goals laid out by the working group, it was determined

that the proposed generic, tactical decision simulation model of patient flow through

the perioperative service would meet their needs. The simulation model would allow

for the working team to review numerous possible decision options with stakeholders,

weighing the effects of different the solutions on the identified outcome measures. The

advantage of simulation modelling for decision-making is that decision makers can see

and understand the effect of different solutions on their outcome measures. Furthermore,

it keeps the decision making in the hands of the decision makers, as opposed to an

optimisation model that outputs a solution. Comparing possible solutions based on a

variety of outcomes using simulation allows for consideration of the qualitative objectives


of the stakeholders that cannot be quantitatively defined or measured meaningfully, and

a shared decision-making process.

6.1.3 Application of the Generic Model

The first step was to understand the processes and patient flow specifics of the hospital.

Through process observation and interviews with staff and management from various ar-

eas, a process map of their perioperative patient flow processes was drafted and reviewed

by the working group.

The information was also used to demonstrate to the working group how the generic

model would represent their specific processes and what assumptions and simplifications

were required. This exercise was key in gaining trust and credibility of the generic model

from the working group. Without their trust in the model, successful implementation

of solutions provided would not have been possible. This also helped the working group

understand how the generic model functioned, what it was able to do, and how it could

help them make better decisions.

The next step was to apply the generic model to the site by inputting their specific

information. The input files were based on the information from the process map as well

as one year of historical data. The data consisted of surgical patient records including:

procedure type, length of stay, care path, historical inpatient census data, off-service

rates, and cancellation rates by reason.

The model was validated against two months of actual historical performance. The

results of the validation were reviewed with the working team in order to ensure that

those who would be making decisions based on the results believed that the model was

able to accurately represent their hospital patient flow and patient population. The

validation process was an iterative effort with high involvement from the working team.

The team met regularly to review validation results; discussing the results in terms of

whether the predictive error of the model was acceptable, and how the inputs could be


adjusted in order to improve the models performance.

Once the model was deemed valid and credible by the working team, numerous de-

cision options were run. Options tested varied from small changes to the OR block

schedule, to dramatic and controversial changes to the policies of the hospital around

off-servicing patients and weekend elective blocks. Options were generated from a vari-

ety of sources including ideas from the working team and other hospital staff, literature

and best practice, a bed resource planning model (Liu, 2012) and various combinations

of these. Results were systematically reviewed by the working team, which generated

additional options based on results.

The Juravinski was the third application of the generic model to a hospital, following

the two William Osler sites Brampton and Etobicoke. As detailed in section 4.3, the time

required for data input and validation decreased as some expertise was gained through

multiple applications of the model. In addition, the challenges faced with validation at

the William Osler sites were not present at Juravinski. Testing, evaluating and presenting

numerous decision options was on going over the course of six months, an average a few

hours of work each week. Juravinski benefited from the existing generic model in terms of

time and cost of implementation by not having to design and build a model from scratch.

This allowed for quicker turn around of the project to allow for timely decision making.

6.1.4 Results from the Generic Model

After extensive and iterative testing of numerous possible decision options, the working

team presented a set of seven options to the stakeholders. The stakeholder group included

physicians, unit managers including medicine and hospital administrators. The seven

options were composed of a variety of solutions ranging from some minor adjustments to

the OR block schedule to significant changes to hospital policies that would also affect

medical patient flow.

• TJR LOS Improvement: The current base schedule is unchanged. The length


of stay of total joint replacement patients is adjusted to benchmarked levels.

• Reduce Peak Demand*: This scenario was based on the proposed MSS provided

by a bed resource model optimisation model applied to the hospital (Liu, 2012).

The objective of the model was to reduce the maximum number of inpatient beds

required by making changes to the assignment of OR blocks to surgeons.

• High Volume TJR Surgeons:The MSS is changed such that the orthopaedic

surgeons who perform high volumes of total joint replacements are spread evenly

over the week, as opposed to concentrated earlier in the week.

• Prescribe Case Types: The types of cases (hip replacement, knee replacement,

other orthopaedic cases) that can be performed in each scheduled OR block is

prescribed to manage flow to ward beds.

• Ring Fencing*: This more drastic scenario considers the effect of reducing the

number of surgical beds and changing the off-servicing policy of the hospital by not

allowing medicine patients to use surgical beds.

• Orthopaedic Surgeon Assignment Changes with Ring Fencing: Changes

to the assignment of OR blocks to orthopaedic surgeons is performed to spread case

types over the week based on historical surgeon patterns. The changes are done in

addition to the ring fencing policy.

• Weekend Elective Scheduling with Ring Fencing*: In an attempt to smooth

demand for beds more evenly across the week, it was thought that moving two total

joint replacement (TJR) OR blocks to Saturdays would help increase weekend cen-

sus and reduce weekday peak demand. This scenario was tested with and without

a ring fencing policy in place, the results presented here are with ring fencing.

In order to illustrate the decision making processes that occurred at Juravinski, three

of the seven options are used and are indicated above with an *. The three options were


chosen based on demonstrating the range of decision options considered, and options

that the decision makers found interesting based on the model’s outputted results. For

example, the Director of Perioperative believed that running weekend elective cases (the

seventh option) would significantly improve access to ward beds, reduce cancelations and

improve throughput. Model results, however, indicated that the level of improvement

was not as significant as hoped.

All the options were compared to a base case which was composed of some minor

changes to the current MSS and increases to the minimum number of TJR cases each

surgeon must schedule in their OR blocks. With the adjustment to the scheduling rule,

the base case was able to meet the hospitals yearly TJR volume target. The results from

the three options are presented below in Tables 6.1 and 6.2 and Figure 6.1.

The output analysis shows that reducing peak bed demand resulted in a small increase

in the overall elective throughput. Most of the increase was due to increases in the TJR

and urology volumes. However, this was at the expense of reduced volumes of the plastics

service. These changes were due to the fact that alterations to the schedule opened up

beds on days when urology and orthopaedics were able to take advantage of the available

beds, reducing cancellations. However, plastics was disadvantaged slightly as they lost

some access to beds. Furthermore, the resulting MSS did not significantly reduce the

cancellation rates due to no beds. The graph in Figure 6.1 explains these results; there is

little change to the number of beds required, as any savings in beds were taken advantage

of by other services.

Restricting medicine (off-service) patient access to surgical beds had a noticeable

effect on the average number of beds required in the TJR and general surgery wards. This

indicates that when medicine patients are not occupying surgical beds, the orthopaedic

service can complete a similar number of cases, compared to the base case, using fewer

beds. In fact, there is a total average savings of more than 10 beds over the week that

could be transferred to the medicine service to fund additional beds needed to better meet


Measure - % change com-

pared to Base Schedule

Reduce Bed

DemandRing Fencing

Weekend

Elective

Scheduling with

Ring Fencing


Elective 4.9% 1.2% 3.1%

Urgent 0.0% -0.1% -0.1%


GENL 1.8% 0.8% 1.5%

OBGY 2.8% 2.1% 2.5%

ORTH 1.8% 0.8% 3.6%

Fract. hip 0.4% -0.4% -2.6%

TJR 3.8% 0.7% 4.4%

PLAS -6.4% 0.6% 0.3%

UROL 13.8% 0.8% 1.2%

Table 6.1: The percent change compared to the base case for three of the scenarios

considered by the Juravinski - Throughput


Measure - % change com-

pared to Base Schedule

Reduce Bed

DemandRing Fencing

Weekend

Elective

Scheduling with

Ring Fencing


No ICU Bed Cancellations 4.8% -19.4% -26.9%

No Ward Bed Cancellations -4.3% -32.9% -60.4%

Not Enough OR Time Can-

cellations7.3% 0.6% 4.8%

Bumped for More Urgent

Case Cancellations4.6% -2.2% 7.9%

Other Cancellations 8.0% 0.5% 1.5%

Table 6.2: The percent change compared to the base case for three of the scenarios

considered by the Juravinski - Cancellations


!"

#!"

$!"

%!"

&!"

'!"

(!"

)*+" ,-." /.0" ,1-" 234" 567" 5-+"

!"#$%&#'(#)*+*',-'.%/#)0*1'

!"#$%&#'2%345'(#)*+*'6''

7%*#'(%*#'

!"

#!"

$!"

%!"

&!"

'!"

(!"

)*+" ,-." /.0" ,1-" 234" 567" 5-+"

!"#$%&#'2%345'(#)*+*'6'8%098:)'74;<=*'>30?'@3)&'A#)<3)&'

89:" ,;<"=630" >371*"/630" ?.+"5-3@"/630"

!"

#!"

$!"

%!"

&!"

'!"

(!"

)*+" ,-." /.0" ,1-" 234" 567" 5-+"

!"#$%&#'(#)*+*',-'.%/#)0*1'

!"#$%&#'2%345'(#)*+*'6''

@#B+<#B'C#%='2#D%)B'

!"

'"

#!"

#'"

$!"

$'"

%!"

%'"

&!"

&'"

'!"

)*+" ,-." /.0" ,1-" 234" 567" 5-+"

!"#$%&#'(#)*+*',-'.%/#)0*1'

!"#$%&#'2%345'(#)*+*'6''

@3)&'A#)<3)&'

!"

#!"

$!"

%!"

&!"

'!"

(!"

)*+" ,-." /.0" ,1-" 234" 567" 5-+"

!"#$%&#'(#)*+*',-'.%/#)0*1'

!"#$%&#'2%345'(#)*+*'6''

8%098+)'74;<=*'>30?'@3)&'A#)<3)&'

Figure 6.1: Daily midnight census results from selected scenarios presented to Juravinski

Hospital.


their demand. Additionally, there is a significant reduction in the number of cancellations

due to no bed. This was a big selling point to surgeons, who felt it was unfair for their

patients to be cancelled due to no bed, when the beds that should be available are

occupied by non-surgical patients.

Results from the option that considers ring fencing and weekend elective blocks also

showed promising results in terms of bed savings and reduced cancellations. A slight

increase in volumes was experienced in this scenario, particularly the TJR procedures.

However, much of the improvement was due to the ring fencing policy and not the

weekend elective blocks. This result was of particular interest to the director of surgery,

who thought that weekend elective cases would help smooth demand of beds better over

the week. It is possible that if more blocks were moved to the weekends that a more

significant change would be seen. However, running too many weekend elective cases is

not feasible due to the additional cost of paying staff weekend premiums and surgeons

not willing to work weekends.

6.1.5 Implementation of the Decision

Based on the results presented to the stakeholder group at the hospital, the working

group decided to trial the ring fencing scenario in January 2012. The trial was composed

of a number of changes:

• Adjustment of the Master Surgical Schedule as recommended by the working group

based on the ring fencing scenario;

• Instituting a ring fencing policy for surgical beds, thereby restricting non-surgical

patients access to surgical beds (i.e. off-service);

• Closure of ten surgical beds;

• Addition of three inpatient medicine beds;


• Additional funding towards an alternate level of care (ALC) unit that cares for pa-

tients waiting for further care at other facilities in an appropriate and cost effective

care setting.

After seven weeks, the working group evaluated the results of the implemented trial.

The evaluation focused on two measures: daily average census and cancellations due to

no bed.

During the trial period, not a single cancellation occurred due to no bed. While

the simulation model predicted there would still be some cancellations due to no bed,

the working group conceded that in the few times that a cancellation would have been

required, the hospital ensured that every measure possible was taken to avoid the cancel-

lation. This extra effort was done as part of the selling point of the trial to the surgeons.

As part of the trial, some surgical beds were given to medicine as the model predicted that

they would not require them with ring fencing in place. The administration promised

the surgeons that the bed reduction would not cause cancellations. Thus, they needed

to ensure that this was the case. Though it is not possible to measure quantitatively,

the working group agreed that during the trial, the number of times they faced possi-

ble cancellations due to no bed was less frequent than before, as the simulation model

predicted.

In the case of unit census, the model results did differ somewhat to those of the trial.

Figure 6.2 compares the daily average predicted census to the actual average census

during the trial for the three surgical units. As part of the trials evaluation report to

the hospitals administration, the working team analysed the data used for the simulation

and the trial period in order to explain the differences. The team found that they were

reasonably able to explain the causes for the differences.

For instance, despite the small sample size of the trial, the TJR ward census is fairly

similar to that seen in the simulation. Here the working group noted that compared to

the time period of the data used to populate the simulation model, the length of stay of


!"!#

$"!#

%!"!#

%$"!#

&!"!#

&$"!#

'!"!#

'$"!#

()*# +,-# .-/# +0,# 123# 456# 4,*#

78-259-#:-*;,;#<=#>5?-*6;@#

+AB#.52/#:-*;,;#

!"!#

$"!#

%!"!#

%$"!#

&!"!#

&$"!#

()*# +,-# .-/# +0,# 123# 456# 4,*#

78-259-#:-*;,;#<=#>5?-*6;@#

C260)##.52/#:-*;,;#

!"!#$"!#%!"!#%$"!#&!"!#&$"!#'!"!#'$"!#

()*#

+,-#

.-/#

+0,#123#456#4,*#

(-5*#

D2-/3E6-/#78-259-#:-*;,;# FG#.--H#D3I)6#78-259-#J-/#KL,385I-*6;#

!"!#

%!"!#

&!"!#

'!"!#

M!"!#

$!"!#

N!"!#

()*# +,-# .-/# +0,# 123# 456# 4,*#

78-259-#:-*;,;#<=#>5?-*6;@#

O-*#4,29#.52/#:-*;,;#

Figure 6.2: Comparing average daily unit census of the simulation model and the seven-

week trial.

TJR patients had decreased slightly, reducing the demand on beds.

Conversely, the simulation model predicted a lower census than realised during the

trial in the orthopaedic ward, which cares for other orthopaedic patients including frac-

tured hip patients. The working group found that this was due to the fact that the

volume of urgent fractured hip patients experienced was higher than the arrival rate

used in the model; thus, requiring more beds post-surgery. Additionally, the length of

stay of fractured hip patients has been on the rise due to longer waits for alternative level

of care spaces in rehabilitation and other post-acute facilities.

Finally, the working group believed that the key reasons for the higher than expected

census in the surgery ward was owing to three factors. First, the volume of gynaecological

oncology patients has increased compared to what was seen previously in the data used

in the simulation model. Additionally, the hospital recently had the city’s hepatobiliary

surgeons join their team from another hospital. The predicted case volumes from these

surgeons were inputted into the simulation model; however, these volume predictions were

lower than what was realised. Finally, the working group also noted that the waiting

time for surgical patients waiting for alternative level of care, specifically palliative care,

was higher during the trial period than what was considered by the simulation model.


Based on the positive results from the seven week trial, the working group recom-

mended to the hospital administration that the MSS and ring fencing policy be adopted.

The administration agreed and has approved the ring fencing policy.

During the seven-week pilot, the hospital also observed a reduction in the lengths of

stay of emergency patients waiting for inpatient beds. As demonstrated in Figure 6.3,

the average emergency department (ED) length of stay of admitted patients from all

services saw a reduction in wait time for an inpatient bed. The reduction was especially

significant for medicine patients, who constitute the majority of patients waiting in the

ED; their length of stay was reduced to about half in comparison to the same seven weeks

the previous year.

!"!!#

$"!!#

%!"!!#

%$"!!#

&!"!!#

'()*+*,(# -./0123()*+4# 56.7(.8# 9::#23;(,/4#

!"#$%&#'()%*'+,-.$/0'

9<(.37(#=>(.7(,+8#?(23./>(,/#

@(,7/0#1A#5/38B#

C#D((E4#*,#2.(<*164#8(3.# CFD((E#/.*3:#

BG.1>#3)>*44*1,#)(+*4*1,#/1#)(23./6.(#A.1>#/0(#=?#

Figure 6.3: Emergency Department length of stay during the trial compared to the

previous year.


The reduction in ED LOS can be attributed to the addition of the three medicine

and ALC beds. These additional beds created more capacity where needed. The beds

allow the hospital to care for their patients in the most appropriate setting; in units that

are designed for the particular patient care needs and are staffed with knowledgeable

staff. For example, medicine patients are cared for by nurses and other staff trained

specifically in caring for medical diseases, instead of by surgical nurses who specialise in

wound care and surgical recovery. Additionally, the patients are staying in a unit with

the appropriate equipment to manage their care.

The ED data demonstrates that the reduction of surgical beds had a positive effect

on the throughput and cancellation rates of elective surgical patients, but also shows that

emergency surgical patients continued to have access to appropriate care without having

to wait longer in the ED. This was important to Juravinski administrators as they do

not want decisions and changes to improve perioperative care to negatively affect other

patients and areas of the hospital. With any change made in healthcare, it is important

to be monitor the effects on other areas of the healthcare system to ensure that issues

are not simply shifted to another area. The Juravinski should continue to monitor the

impact of these changes to performance across the hospital. Furthermore, it would be

prudent to work closely with up- and downstream partners to monitor possible effects,

both negative and positive to external processes and resources.

6.1.6 Discussion

The working team used the results from the scenarios as a negotiating tool with the

stakeholders of the hospital, including physicians and surgeons, the medicine department

and administration. Based on the results, they were able to convince surgeons to accept

the changes to their MSS schedule on the promise that cancellations due to no bed would

decrease and that medicine would no longer have access to surgical beds. In exchange

for ring fencing surgical beds, surgery agreed to transfer some beds to medicine to help


accommodate their demand. This exchange was part of the negotiation needed to bring

the medicine program on board with the ring fencing policy. They were concerned that

without the bed transfer, their patients would experience further limited access to care

and experience longer waits in the emergency department.

The successful application of the generic simulation model at this hospital can be

largely attributed to the highly engaged and motivated working team. The working

team was composed of a number of key stakeholder representatives, including surgical

program management and the chief of surgery. Having members of the stakeholder groups

in the working group is advantageous as they act as champions of the project and the

proposed solutions, which helps in gaining acceptance from the stakeholders.

In addition, representation from the quality department further contributed to the

successful application of the model. The quality department has had previous experi-

ence in working with operational research tools, including simulation, through previous

graduate student work, as well as a couple of on-staff industrial engineers. Moreover, the

quality team served as the project management and reporting function of the working

team, translating simulation results into presentations geared towards the stakeholders.

Their knowledge and experience with operational research, and with dealing with the

various stakeholders, brought tremendous negotiation power to the project, especially

when implementing the controversial ring fencing policy.

Another success factor was the close tie and involvement of the decision support

department throughout the project. The department provided the electronic data files

required to populate the simulation model and aided in the analysis of the data from the

trial. The decision support department not only had an in depth understanding of the

hospitals data, but also of the current trends, such as higher ALC wait times and shorter

orthopaedic lengths of stay, that were influencing the trial results.

The hospitals corporate initiative structure further helped ensure the success of the

project. For large corporate initiatives, the hospital has implemented a standard plan-


ning and reporting structure that includes quarterly updates on milestones up through

administration, including the CEO, site presidents, vice-presidents and board of direc-

tors. This reporting structure ensures that the working team was accountable to meet

their project goals in a timely manner. Furthermore, when the working team experienced

any challenges or barriers, there was executive support to help address them in order to

keep the project moving forward.

Six months after the trial, the hospital continues to use the proposed MSS and ring

fencing policy. In addition, the working group has re-convened and is using the generic

simulation model for additional tests to determine how they can meet their revised volume

targets, taking into consideration recent changes to the perioperative service such as case

mix, length of stay and ALC waiting times.

6.2 As a Demonstrative and Decision Tool at William

Osler Health Sciences

6.2.1 Problem Description

The perioperative service at William Osler Health Sciences is composed of the surgical

resources available at the Brampton Civic Hospital and the Etobicoke General Hospital.

Based on internal analysis and benchmarking, it was determined that the perioperative

service was significantly under performing in efficiency measures including OR utilisation

and throughput. In addition, William Osler was unable to achieve any of their Ministry

waiting time surgical volume targets, including orthopaedic total joint replacements and

some oncology surgical procedures.

Though William Osler experienced few cancellations due to no bed, the perioperative

service was challenged with balancing the need for timely access to surgical care for urgent

patients with the needs of the elective case load. This resulted in expensive overtime costs


in the OR, lengthy case delays, and dissatisfaction among staff and surgeons.

Other issues identified in the analysis and benchmarking study included:

• Poor on time start performance: Elective OR block times were often not started as

scheduled due to delays in equipment, OR staff (including surgeons and anaesthe-

siologists), and patient readiness.

• Inaccurate booking times: The amount of time a surgeon scheduled for a proce-

dure often differed significantly from the time the case actually took, resulting in

requiring overtime to complete cases if under-predicted, or under-utilisation of the

OR if over-predicted.

• Master Surgical Schedule: William Osler was struggling to meet demand for OR

block time for current volumes, targeted volumes and planned predicted increases

without additional funding to run additional or longer OR blocks.

• Policies and their adherence: Many policies were not well adhered to, while other

policies typically found in perioperative services were out of date or non-existent.

In response, William Osler hired a consulting firm to develop solutions and imple-

mentation plans to address these issues. As part of their work, it was determined that

changes to the surgical schedule and resources were needed.

The generic model was proposed as a tool to help inform v on tactical decisions,

specifically:

• The planned master surgical schedule (MSS)

• Scheduling rules

• Resource capacity available

• Consolidation of a surgical speciality to a single site


The two key objectives set out by the William Osler administration for this project

was to determine how to achieve the targets set by the Ministry of Health and how

to increase their service provision to meet the demands of their growing and ageing

populations.

6.2.2 Application of the Generic Model

A working group of key decision makers and stakeholders was assembled for this sub-

project. This working group reported to the larger perioperative improvement initiative.

The working group included the director of perioperative services at William Osler, the

OR managers at both sites, the chief of surgery, and members from the consulting team.

The first step in this project was to introduce the generic model to the working

group. Once the working group agreed that the generic model would satisfy their needs,

interviews were conducted with managers and nursing leaders of the perioperative and

surgical inpatient areas to gain an understanding of the specifics of surgical patient flow

at the two William Osler sites. The information gathered was compared to the design

and assumptions of the generic model in order to determine if the model would be able

to adequately describe William Osler patient flow. This was presented to the working

group for discussion. The resulting diagrams are provided in Appendix H.

Since the generic model had been originally designed based on a set of academic

teaching hospitals, attention to any differences was important. Furthermore, this process

of studying and documenting their processes and demonstrating that the conceptual

model was able to capture their processes not only helped prove that the model was

generic, but also helped gain credibility and trust from the decision makers and users of

the tool at William Osler.

Along with one year of patient record data, the information on patient flow at William

Osler was inputted into the generic model. Two models were populated, one for each

hospital, Brampton and Etobicoke. The work at both sites was being done in tandem in


a single working group. The remainder of this case study will focus on the application of

the model at the Brampton site; a similar experience occurred at Etobicoke.

6.2.3 The Generic Model - Results as a Demonstrative Tool

As described in Chapter 5, the validation process at Brampton was met with many

challenges. Statistical (objective) validation was not possible due to numerous poor

practices at Brampton. However, through detailed analysis of the data and the model and

a close working relationship with the working group, the model was validated subjectively

through a reconciliation of the model outputs to historical results.

It was within this validation effort that a second use of the generic model as a demon-

strative tool was revealed. As a demonstrative tool, the generic model illustrated what

performance Brampton could have expected if:

• Surgeons’ booked time estimates were more in line with the actual time to complete

a case and turnover the OR. Methods for more accurate prediction based on statis-

tical analysis were being implemented concurrently as part of the overall William

Osler perioperative plan.

• Surgeons efficiently used the elective block time assigned by booking the entire time

available, or releasing unused time in a timely manner such that it could be used

by another surgeon or service.

• William Osler more strictly followed elective overtime tolerances by not allowing

surgeons to overbook their ORs and by cancelling cases when elective time would

be exceeded, as per policy.

• Elective OR blocks were started on time.

These findings were consistent with an efficiency analysis and observations performed by

the consulting firm as part of their diagnostics and recommendations. The benefit of the


generic model as a demonstrative tool was that it quantified the effect of poor practices

on perioperative performance.

To demonstrate the effect of their poor practices on their throughput performance,

a report was used to compare the number of OR blocks used to achieve their current

volumes to the number of blocks the model required to achieve the same level of service

(table 6.3). Columns A and C show the difference in the planned MSS (column A) and the

actual realised block schedule (column C). The outputted volumes of the model, based on

the realised block schedule are provided in column D. Compared to the historical volumes

in column B, there are some notable differences in the outcomes. Column F calculates,

based on the simulation model results, the number of blocks that would be required

by each service to achieve their current volumes if inefficient practices were addressed.

Column G is the difference between the number of OR blocks each service was assigned

in the MSS (column A) and the number required (column F).

From this report, a number of conclusions were derived. First, nine of the eleven

services at Brampton could have achieved their volumes as performed in the eight week

period with fewer elective OR blocks than assigned in the original MSS schedule. This

conclusion is based on comparing the throughputs from the model to actual as well as

the originally planned MSS compared to the actual block schedule. Table 6.4 compares

the MSS as planned to the actual elective schedule for eight weeks in April-May 2010.

The table also demonstrates that not all of these changes were planned ahead of time as

the number of planned block releases and pick ups from the MSS does not account for

all the differences between the MSS and the actual schedule.

On the other hand, the two other services, oral and orthopaedics, require more time

than originally allocated in the MSS to achieve their current volumes. Both these services

picked up released time from other services during the two month study period.

As a demonstrative tool, the generic model was used to substantiate not only what

would have been achieved based on the actual elective schedule (as discussed above) but


A:

B:

C:

D:

E:

F:

G:

Ser

vic

eB

lock

Sch

edule

Act

ual

Cas

es

Rea

lise

d

Blo

ck

Sch

edule

Sim

ula

tion

Res

ult

Cas

es

Sim

ula

ted

Cas

es/b

lock

Blo

cks

Req

uir

edto

do

Act

ual

Vol

um

e

Blo

cks

Ove

r

i.e.

Req

uir

ed

vs.

Ass

igned

(=D

/C

)(=

B/

E)

(=A

-F

)

Den

tist

ry24

7317

70.9

4.17

17.5

-6.5

EN

T40

223

3822

05.

7938

.52

-1.4

8

Gen

eral

118

546

111

595.

85.

3710

1.72

-16.

28

Gynae

colo

gy36

240

3224

6.7

7.71

31.1

3-4

.87

Ophth

alm

olog

y60

877

6192

2.1

15.1

258

.02

-1.9

8

Ora

l6

4010

454.

58.

892.

89

Ort

hop

aedic

s92

428

104

439.

74.

2310

1.23

9.23

Pla

stic

s28

7018

75.5

4.19

16.6

9-1

1.31

Uro

logy

5225

456

274.

74.

9151

.78

-0.2

2

Tot

alB

lock

s45

644

742

5.48

Tab

le6.

3:D

emon

stra

tive

Tool

Rep

ort

-Il

lust

rati

ng

the

effec

tof

poor

pra

ctic

eson

thro

ugh

put

volu

mes

atB

ram

pto

n.


Service

Planned

Block

Schedule

Picked up* Released*Actual

Schedule

Difference

to planned

Dentistry 24 3 0 25.5 1.5

ENT 40 4 3 39.5 -0.5

General 118 1 9.5 105.5 -12.5

Gynaecology 36 1 2.5 35 -1

Ophthalmology 60 1 0 61 1

Oral Surgery 6 4 2 10 4

Orthopaedics 92 2 0 87.5 -4.5

Plastics 28 1 5 21 -7

Urology 52 0 4 42 -10

*Changes according to utilisation sheet (planned and known in advance). It

was found that not all changes were reflected in the utilisation sheet).

Table 6.4: Differences in elective OR time by service from the MSS to actual in April-May

2010.


also what the MSS would need to look like to achieve exactly what they had achieved

over the period of study. The results in tables 5.6 and 5.7 are based on the actual elective

schedule. However, the model based on that schedule was able to complete more cases

than required for general, ophthalmology, plastics and urology. This indicates that a

further reduction in OR blocks assigned should result in the same throughput, if these

services were to follow better booking practices as previously described. Conversely, the

model was unable to complete the same volume of dentistry and ear, nose and throat

(ENT) cases as completed historically based on the current actual block schedule. This

demonstrates that these two services, if following better booking practices would require

more OR time than currently allocated to maintain current volumes. Finally, gynaecology

and orthopaedics can, according to the model, maintain current volumes based on the

block schedule as carried out.

Note that oral surgery was excluded from the lists above. During the time period

studied, oral surgery was the only service to have used more block time slots than origi-

nally assigned in the MSS. At the time of this analysis, the decision makers at William

Osler did not place emphasis on increasing volumes for oral surgery, as it was not a cur-

rent priority. Even though the model shows that oral surgery could complete more cases

than actually completed in the same number of blocks, the decision was made not to

increase the service above the current allocation according to the MSS. As a result, the

volume of cases for oral surgery will be less for any schedule proposed from this analysis.

This was known and understood by the decision makers and working group at William

Osler, and accepted based on their priorities and objectives.

Based on this analysis, a proposed base MSS was provided to William Osler for

Brampton. The proposed MSS assumes that the objective is to maintain current volumes

for all services, except oral surgery as discussed above. The proposed base MSS assumes

that the perioperative service achieves its goal of following best practices for scheduling

and operating the ORs. The proposed base MSS is presented in table 6.5. Expected


volumes from the base MSS are provided in table 6.6 as generated from the generic

model. Notice that the base MSS uses only 208 out of the total 228 OR blocks available

in the four week MSS. This gives decision makers 20 OR blocks to reassign based on

priority areas as needed.

ServiceMaster Schedule

Allocation

Proposed 4

week schedule

with 1 stat day

Difference

Dentistry 12 9 -3

Ear Nose and Throat 20 19 -1

General 58 51 -7

Gynaecology 17 15 -2

Ophthalmology 30 30 0

Oral Surgery 3 3 0

Orthopaedics 46 46* 0

Plastics 12 9 -3

Urology 26 26 0

Total Assigned 224 208 -16

Total Available 228 228

Unassigned Blocks 4 20

*Includes two swing rooms per week

Table 6.5: The proposed base MSS for Brampton based on the demonstrative results

from the generic model.

Based on the results of using the generic model as a demonstrative tool, the working

group was ready to move forward with the model and the base MSS to study future

scenarios using the generic model as a decision tool.


Measure Average95% CI

Range


Elective 2511.9 23.5

Urgent 489.9 15.7


Dentistry 77.2 2.2

Ear Nose and Throat 258.2 9.3

General 596.4 14.8

Gynaecology 249.0 9.3

Ophthalmology 979.0 12.2

Oral Surgery 29.5 2.9

Orthopaedics 474.2 10.0

TJR 127.7 4.6

Plastics 75.2 3.4

Urology 274.3 23.6


No ICU Bed Cancellations 0.0 0.0

No SDU Bed Cancellations 2.2 1.8

No Ward Bed Cancellations 27.8 12.7

Not Enough OR Time Cancellations 156.7 24.0

Bumped for More Urgent Case Cancellations 16.0 2.9

Other Cancellations 274.7 16.6

Table 6.6: The predicted throughput and cancellation rates achievable from the proposed

base MSS.


6.2.4 The Generic Model - Results as a Decision Tool

A new base schedule centred on results from the application of the generic as a demon-

strative tool could then be used to help support William Osler in making short and long

term decisions. In the short term, decisions on how best to allocate some emergent time

to general surgery and accommodate a new gynaecological surgeon were needed. These

short term decisions were required immediately based on various existing agreements. In

the long term, William Osler decision makers wanted to determine how to create capac-

ity and an OR block schedule to achieve their volume targets in total joint replacements

(TJR), cataracts and oncology.

Short Term Decisions

Decision makers chose to focus on two key changes in the short term. First was to carry

out their plans for allocating emergent time for general surgery and accommodating the

arrival of a new gynaecological surgeon at Brampton. Secondly, they were interested in

exploring how to reduce the peak demand of surgical ward beds through changes in the

MSS assignment.

In negotiation with the surgical services, the hospital had agreed to assign general

surgery two half-day blocks a week for emergent cases. This time would be reserved

out of the elective schedule for general surgery to perform emergent cases in order to

reduce wait times of these patients and reduce the use of after hour OR time to complete

these cases. Prior to the results above, William Osler believed that in order to do this,

the emergent time would be taken from existing elective time assigned, reducing general

surgery elective throughput at the expense of emergent wait times. However, the process

produced a base MSS with unassigned budgeted OR blocks. As a result, decision makers

chose to evaluate the result of assigning the two emergent half blocks per week, plus an

additional OR block per week for general surgery to replace the elective time taken to

open the emergent blocks. The total amount of elective time for general surgery remains


the same.

Additionally, in response to increasing demand for gynaecological cases, William Osler

had hired a new surgeon. The question unanswered prior to this analysis was how to

accommodate the additional surgeon within the MSS schedule and downstream inpatient

resources, without increasing resource availability of the OR or inpatient units. Fortu-

nately, the demonstrative analysis performed above revealed that there was enough unas-

signed budgeted OR block time at Brampton to accommodate the new surgeon, without

reducing time assigned to other surgeons. Accordingly, the only remaining question was

if the current inpatient resources would be able to absorb the extra volume.

Based on these two needs identified by the hospital, the first scenario tested by the

generic model was to determine if the emergent time for general surgery and the new

gynaecology surgeon could be accommodated within the current perioperative resources.

The outputs of the generic model demonstrate that the proposed adjustments to the

base MSS could be accommodated. Throughput results in table 6.7 demonstrate that

the changes do not significantly affect the predicted volumes of other services. The

addition of the general service emergent time and additional elective block maintains

current elective volumes. The additional gynaecological surgeon increases gynaecological

throughput, but not at the expense of another service. Average census of the units

increases slightly due to increased gynaecological volumes, as demonstrated in figure 6.4.

The impact of this scenario can also be seen in table 6.8, showing that there is little

effect on cancellation rates; notably, cancellation due to no ward bed is not impacted

significantly more than expected from the changes.

William Osler was also interested in reducing the peak demand for beds required

across the organisation, including surgical beds. A Monte Carlo simulation model (Liu,

2012) that was being used for this analysis at the hospital level was leveraged to determine

if any changes to the proposed short term MSS, could be made to reduce the peak number

of surgical beds required. Based on the proposed MSS with the short term changes,


Measure - % change to Base Schedule Short Term

Short Term

with Urology

Adjustment


Elective 1.4% 2.2%

Urgent 0.5% 0.3%


Dentistry 0.6% -3.2%

Ear Nose and Throat 0.8% 0.4%

General 1.4% 2.0%

Gynaecology 13.2% 18.2%

Ophthalmology 0.0% -0.3%

Oral Surgery 2.4% -1.4%

Orthopaedics -0.6% -1.2%

TJR 0.1% -0.7%

Plastics 0.8% 2.0%

Urology -2.3% 3.0%

Table 6.7: Model throughput results from short term MSS changes.


!"

#"

$!"

$#"

%!"

%#"

&!"

&#"

'!"

'#"

()*" +,-" .-/" +0," 123" 456" 4,*"

78-259-":-*;,;"<=">5?-*6;@"

!"#$%&#'(#)*+*','-%*#'(%*#'

!"

#"

$!"

$#"

%!"

%#"

&!"

&#"

'!"

'#"

()*" +,-" .-/" +0," 123" 456" 4,*"

78-259-":-*;,;"<=">5?-*6;@"

!"#$%&#'(#)*+*','./0$1'2#$3'

!"

#"

$!"

$#"

%!"

%#"

&!"

&#"

'!"

'#"

()*" +,-" .-/" +0," 123" 456" 4,*"78-259-":-*;,;"<=">5?-*6;@"

!"#$%&#'(#)*+*','./0$1'2#$3'451/'

6$070&8'!9:+*13#)1'

!"

#"

$!"

$#"

%!"

%#"

&!"

&#"

'!"

'#"

()*" +,-" .-/" +0," 123" 456" 4,*"

A:B" 4CB" 4,293D5E"5*/"40)26"465F" C260)>-/3D;"

Figure 6.4: Model average census results from short term MSS changes.

Measure - % change to Base Schedule Short Term

Short Term

with Urology

Adjustment


No ICU Bed Cancellations N/A N/A

No SDU Bed Cancellations 63.6% 154.5%

No Ward Bed Cancellations 115.8% 39.9%

Not Enough OR Time Cancellations 8.2% -4.8%

Bumped for More Urgent Case Cancellations 8.7% 0.0%

Other Cancellations 2.9% 3.0%

Table 6.8: Model cancellation rate results from short term MSS changes.


the Monte Carlo bed model recommended that the current urology block assignment of

Mondays, Wednesdays and Thursdays, is a main contributor to the peak bed demand level

on Thursdays. However, if urology blocks are changed to be on Mondays, Tuesdays and

Fridays, the peak demand in beds will be reduced. Figure 6.5 demonstrates the predicted

reduction in peak bed demand according to the bed model. This recommended change

to the MSS was tested in the generic model for more detailed analysis of the effect on

throughput, census and cancellation rates.

The results from the generic model in tables 6.7 and 6.8 and figure 6.4 show the effect

on throughput, cancellation rates and census. These results show that this additional

short term change to the MSS does not significantly affect throughput, but does smooth

ward census better over the weekdays, as well as slightly reduce cancellations due to no

ward bed.

!"#$#%&'()*#"+(,&"-(.))( !"#$#%&'()*#"+(,&"-(.))(/0+*(1"#2#34(5*673&(

Figure 6.5: Total average census by service as predicted from the Monte Carlo bed model.


Long Term Scenarios

In addition to the short term solutions outlined, William Osler wanted to explore schedule

changes that would help achieve their yearly volume targets in total joint replacements,

cataracts and oncology procedures. For each of these three procedure categories, William

Osler is accountable to reach these targets or face reduction in funding and future targets.

In previous years, William Osler struggled to achieve all of these targets. At the time,

current projections were indicating that William Osler would likely fail to achieve volumes

in TJR, but exceed in volume of cataract. Oncology targets overall were projected to be

met, but not when stratified by disease site. As a result, there was a desire at William

Osler to develop a plan that will achieve their targets the following year.

In order to achieve targets, the working group was willing to consider a number of

options if warranted, including:

• Assigning additional time to services to achieve volumes,

• Reserving time within the MSS specifically for targeted cases,

• Increasing ward beds available for targeted cases.

In order to evaluate these various solutions, the generic model was used as a decision

tool to compare possible solutions, and provide a recommendation to William Osler

executive to implement for the following year. For each of the targets, the model was

used in tandem with data analysis to determine the recommended course of action.

Total Joint Replacement Target: To achieve the TJR target, William Osler was willing

to consider any combination of the following options:

• TJR swing rooms: Three of the surgeons at Brampton were able to perform up

to six TJR cases a day if given access to two OR rooms. With a single OR team,

the surgeon and team would switch between the two OR rooms to maximise their

time, by not experiencing idle time due to room turnover.


• TJR dedicated rooms: A single OR dedicated to TJR, where a high volume surgeon

could perform four TJR cases in an elective day.

• Non-TJR rooms: An OR where cases other than TJR can be performed. These

would be used in tandem with swing rooms and TJR dedicated rooms to complete

other orthopaedic cases.

• Open orthopaedic rooms: Where surgeons can perform cases without restrictions.

Table 6.9 and figure 6.6 provide an example of some of the scenario results provided to

the working group for determining how to achieve the TJR targets. The table compares

the simulation results from the MSS schedule, as proposed from the short term solutions,

to results from running two swing rooms per week plus one, two or three TJR dedicated

rooms per week. As the number of TJR dedicated rooms increase, the number of com-

pleted TJR cases increases, at the expense of a reduction of total number of orthopaedic

cases completed. This decrease occurs because the increase volume of TJR cases reduces

access to ward beds for other orthopaedic cases, increasing their cancellation rate. In-

creasing the number of orthopaedic ward beds available was found to help reduce this

impact (not shown).

Based on the yearly target, and planned summer OR slowdowns and OR closures

throughout the year, it was determined that between 17 and 19 TJR cases per week were

required to achieve their yearly target. Over the eight week simulated time in the results

in table 6.9, a target of 125 cases would meet their yearly goal. The scenario with two

TJR reserved blocks achieves this volume with less effect on other orthopaedic cases than

reserving three ORs.

Cataract Target: The William Osler working group was also interested in knowing

how many ophthalmology blocks to reserve in order to achieve the cataract volume target.

Reserving five blocks per week for cataracts achieves the yearly target by completing 752

cases over the eight week simulation run.


MeasureOne TJR

Room

Two TJR

Rooms

Three TJR

Rooms


Elective 0.93% 0.26% -0.22%

Urgent 2.98% 3.2% 3.07%


Dentistry 7.46% 5.89% 2.9%

Ear Nose and Throat 2.28% 1.93% 2.32%

General 2.38% 0.71% -0.76%

Gynaecology 5.08% 4.19% 7.24%

Ophthalmology 2.09% 2.38% 1.58%

Oral Surgery 8.05% 10.72% 5.93%

Orthopaedics -0.12% -0.55% -4.12%

TJR -11.95% 3.95% 13.17%

Plastics 5% 3.2% 3.44%

Urology 11.19% 5.21% 4.03%

Table 6.9: Results from comparing orthopaedic scenarios varying the number of TJR

reserved blocks.


!"

#"

$!"

$#"

%!"

%#"

&!"

&#"

'!"

'#"

()*" +,-" .-/" +0," 123" 456" 4,*"

!"#$%&#'(#)*+*',-'.%/#)0*1'

!"#$%&#'(#)*+*'2'345$0'6#$7'

!"

#"

$!"

$#"

%!"

%#"

&!"

&#"

'!"

'#"

()*" +,-" .-/" +0," 123" 456" 4,*"

789" 4:9" 4,2;3<5="5*/"40)26"465>" :260)?-/3<@"

!"

#"

$!"

$#"

%!"

%#"

&!"

&#"

'!"

'#"

()*" +,-" .-/" +0," 123" 456" 4,*"

!"#$%&#'(#)*+*',-'.%/#)0*1'

!"#$%&#'(#)*+*'2'8'69:':557'

!"

#"

$!"

$#"

%!"

%#"

&!"

&#"

'!"

'#"

()*" +,-" .-/" +0," 123" 456" 4,*"

!"#$%&#'(#)*+*',-'.%/#)0*1'

!"#$%&#'(#)*+*'2';'69:':557*'

!"

#"

$!"

$#"

%!"

%#"

&!"

&#"

'!"

'#"

()*" +,-" .-/" +0," 123" 456" 4,*"

!"#$%&#'(#)*+*',-'.%/#)0*1'

!"#$%&#'(#)*+*'2'<'69:':557*'

Figure 6.6: Difference in average census results from long term orthopaedic MSS changes.


Long Term Plan Selected: The following schedule changes were accepted by the

working group:

• Base MSS schedule: Including short term changes in general emergent time, an

additional gynaecological surgeon and adjustments to urology assignment based on

the bed model.

• Orthopaedic TJR Swing Rooms: Schedule two swing rooms per week to be shared

between the three surgeons who manage these swing rooms.

• Orthopaedic TJR Reserved Rooms: Reserve two orthopaedic blocks per week for

TJR cases.

• Cataract Reserved Rooms: Reserve five ophthalmology blocks per week for cataract

cases.

• Oncology: Current performance indicates that the capacity to achieve target exists,

but there is a need to focus on the mix of cases to better align with targets.

Monitoring the mix of oncology cases across all services to ensure meet all targets

within oncology was recommended. Remaining unassigned OR block time can be

assigned as needed to increase volumes of specific oncology procedures.

6.2.5 Discussion

At William Osler the generic model served two purposes: as a demonstrative tool and as

a decision tool.

As a demonstrative tool, the model illustrated that there was an opportunity for

William Osler to improve their scheduling and booking practices and other poor practices

which would release OR time for other priority activities. Practices to be improved

included fully booking allotted OR block time and accurately booking procedure times.


As a decision tool, the model was able to help decision makers determine how best to

use the unassigned blocks to achieve short term and long term objectives. In the short

term, the model was able to help determine how best to schedule the new gynaecological

surgeon and when to allocate general emergent time. In conjunction with a Monte Carlo

simulation model of bed use, a small schedule change for urology helped reduce the peak

number of surgical beds required and smooth average census over the week.

The model was used for longer term planning to determine how William Osler could

achieve yearly volumes of targeted cases. The model determined that a combination of

TJR swing rooms and reserved OR blocks for TJR and cataract cases was a realistic

solution to achieving their targets.

The recommendations were presented to the larger perioperative improvement initia-

tive team for final decision making. Since the proposed MSS require significant improve-

ments to their current practices, the implementation of the proposed MSS was delayed

until after headway was made on improving their numerous poor practices.

Chapter 7

Conclusions and Future Work

Perioperative patient flow is a high priority in many hospitals in Ontario and around the

world because of the drive to reduce waiting time for elective and urgent patients, and the

effect it has on the flow of the entire hospital. Furthermore, operating rooms are one of

the most expensive services in the hospital due to the staff, space and equipment required.

Despite this, tactical perioperative decision making is typically based on aggregate data,

historical performance and decision maker intuition. Basing these important decisions

on statistical rigour through simulation modelling will help improve performance of the

perioperative service and other areas of the hospital.

The research presented herein proposes a generic simulation model of perioperative

patient flow to inform tactical decision making for improved performance. The model is

successfully applied to six hospitals; demonstrating that not only is the model generic

but also that it can be a valuable and cost effective tool in decision making. This research

is characterised by three contributions summarised below.

A Generic Perioperative Simulation Model for Tactical Decisions

First, the design, development and implementation of the generic model itself is pre-

sented. As demonstrated in the literature review (chapter 3) a significant amount of

165

Chapter 7. Conclusions and Future Work 166

work has been done in regards to improving surgical patient flow using operational re-

search methodology. However, no generic tool was found that addressed the needs for

tactical decision making, specifically for developing the master surgical schedule (MSS)

and resource availability while taking into account multiple key performance indicators.

Further, the literature pointed to a need for a generic tactical decision tool that could

help inform these decisions. The need for a generic tool versus a specific tool is based on

constrained hospital budgets, lack of in-house expertise at many hospitals, and the need

to have a tool that is robust, flexible and user friendly.

The first contribution presents a generic model that was created based on typical pe-

rioperative flow processes and best practices. The generic model is data-driven, allowing

for a significant amount of flexibility to accommodate specific characteristics of a hospital

and their patients.

The proposed model was successfully tested at six different hospitals of various sizes

and processes. At four of the hospitals application of the model was successful as not only

was the model validated against historical performance, but testing of various possible

decision alternatives was performed and decision recommendations were made based on

their analysis. Furthermore, the recommendation was applied to real operations to at

least one of the sites, Juravinski.

To further strengthen the first contribution, the generic model continues to be used

by simulation modellers who were not part of the design - demonstrating that the model

has potential for wide spread use.

Finally, based on the experience of designing and implementing a generic simulation

model, a series of guidelines are provided. Based on simulation conference programs, the

interest and research in the field of generic simulation modelling is growing. However,

to date, little has been written on how to successfully design a generic model. These

guidelines add to this area of research by providing counsel to future endeavours in

hopes that a clear and concise standard methodology for generic simulation design be


developed.

A Process forAchieving User Acceptance

Secondly, the research provides valuable insight into achieving user acceptance of generic

tactical decision model. As is typical in large system modelling, validation of the model

to a hospital’s historical performance was fraught with challenges. These challenges

were most frequently experienced when a hospital’s processes were counter to model

assumptions based on best practice guidelines. As a result of the challenges experienced,

a method is proposed to help guide the validation process with the end users (decision

makers) in order to achieve user model acceptance and trust for decision implementation.

In a classical simulation modelling application, the current processes are modelled

as is. Then various solution options are tested to help decision makers choose. It is

proposed here that when considering a tactical decisions and generic models, exact details

of processes do not need to be modelled. In contrast, it is proposed that tactical decisions

should be made assuming that efficient and effective processes and procedures are in place

and followed. This however complicates user acceptance as the model does not exactly

reflect their current reality, both in model outputs and processes. In response, a set

of guidelines are provided to help achieve user acceptance of generic tactical decision

models.

In an era where demand for improved healthcare system planning and shrinking bud-

gets, generic tactical simulation provides a cost effective solution for decision support.

As discussed in the literature review, successful application and use of simulation models

in healthcare, yet alone generic models, is limited. The guidelines proposed are intended

to help improve the success rate of simulation models in affecting actual decisions by

achieving user acceptance through validation and building credibility.


A Decision and Demonstrative Tool

The third contribution demonstrates that the proposed generic model is a useful applica-

tion as a decision and demonstrative tool - to tease out inefficiencies in current processes

and to compare and evaluate various possible new processes, schedules and resources.

The primary intent of the generic model was as a decision tool such that comparisons

of different decision options on a number of performance indicators can be made for

improved decision making. However, during application at the sites a second use of the

generic model was found: as a demonstrative tool. When current practices at a hospital

are counter to best practice assumptions, the model can be used to present decision

makers and stakeholders the effect of these practices on performance. Model output

reporting can be used to demonstrate what performance could be achieved if practices

were improved. Similarly, it can be used to illustrate the effect on utilisation of resources

of these poor practices by reporting what resource capacity is required to achieve current

volumes. This typically results in freeing current capacity for additional volume.

The use of this generic model as a demonstrative tool adds to the simulation research

field by proposing and successfully applying an alternative use for simulation modelling.

Healthcare processes and systems are complicated by variation in practice. Furthermore,

the complex and interrelatedness of processes makes it difficult for decision makers to un-

derstand and quantify the effect of poor or varying practice on outcome measures. Using

simulation as a tool to demonstrate and quantify these effects has not been previously

done successfully. The case study presented demonstrates that not only can simulation

be used for this demonstrative purpose, but can also be used as a catalyst to help decision

makers account for improvements in these processes when making important mid and

long term decisions. The concept of simulation as a demonstrative tool can and should be

applied to other areas within the healthcare system, and other industries where inefficient

and poor practices are affecting outcomes.


7.1 Future Work

Based on the overreaching goal of the research and the limitations noted, some future

work is proposed below.

7.1.1 Additional Functionality and Addressing Limitations

From the limitations noted in section 4.2.3 some changes to the model may be required

to allow for additional flexibility. However, these should only be addressed if it is found

that the limitations are hindering model credibility at future hospitals.

Additional functionality can be added to the model to develop its use as a demon-

strative tool and to further improve user acceptance testing. Various reports based on

historical data and model outputs should be standardised and automated to facilitate

discussions regarding the effects of poor practices at the hospital. These reports should

provide data at various levels of detail down to the surgeon or operating room where

applicable.

7.1.2 Development of a Commercial Product

One of the aspirations of this research was to develop a generic model that could be

transformed into a commercial product, which can be easily applied to many hospitals in

Ontario and around the globe. A key requirement for this is to improve the usability of

the model in the hands of other hospitals and decision makers. This involves two aspects;

one to improve the ease of data entry and updating such that data from other hospitals

can be easily entered. The second involves the design of a user interface that allows

non-simulation experts to “play” with the model, observe outcomes of various options

and make informed decisions. Some further detail into these two aspects is provided in

the following subsections.


Improved Data Entry and Robustness of the Model

The current simulation model requires that the inputs be formatted in a very specific

way. The spread sheet used is adopted for each instance to incorporate the number of

ORs, surgeons, resources, etc. of the current hospital under study. This is currently a

manual process, requiring time and attention to detail to ensure that the file is updated

properly and completely. This manual process often leads to errors in the input file, which

translates to errors in the simulation model, leading to time wasted on debugging the

model and input file to find the error. Through implementation at six hospitals, many of

the possible data errors are now known, and thus easier to either check before importing

or identification when model errors occur. However, this knowledge and expertise is only

known to those who have experience with implementing the model.

To improve this process, a more automated generation of the spread sheets, including

a user interface and error checks, would reduce the number of mistakes as well as the

time to import and test data sets and scenarios.

Improved data entry and error checking will help improve the robustness of the cur-

rent model as implemented in Simul8. This would lead to decreased implementation

time for each subsequent implementation. It will also help bring the model towards a

commercialised product that can be used by hospitals with little support.

Design of a User Interface

Designing a user interface would be invaluable to the usability of the model across hospi-

tals. Most perioperative decision makers do not have strong data analysis or simulation

skills. Thus, for the generic model to be truly usable, it must cater to the typical skill

set and interest of a hospital decision maker.

The user interface should include the ability to make some changes to model param-

eters in an easy and visual fashion. This would allow the decision maker to “play” with

the model on their own to see the effect of different ideas for change.


Further, the user interface should include a set of default reports that display the key

outputs of the model that are understandable and usable to the decision maker. The

reports should display data using summary statistics, charts and graphs to allow for easy

analysis and comparison of decision options.

Overall, the user interface would allow limited ability for the decision maker to analyse

and compare scenarios on their own through simplified input parameter screens and a

set of easy to understand and analyse reports. A second layer of the user interface would

be for the simulation expert to make more complicated input changes and to set up and

calibrate the model.

There has been on-going discussion with Visual8, a research partner and simulation

consulting firm, around these future work topics. In collaboration with the Centre for

Research in Healthcare Engineering and test hospitals, Visual8 plans to further test the

generic simulation model and move the model towards a commercial product.

7.1.3 Additional Uses of the Model

With some minor adjustments the proposed generic model can provide a number of

additional uses, as discussed below.

As a Teaching Tool

The generic model would be a valuable teaching aid in healthcare systems and manage-

ment courses to demonstrate the effect of tactical perioperative decisions on key perfor-

mance indicators. The model could be presented as part of a case study of a hospital.

Students would study the case study information and propose one or more possible de-

cision options. The model would be used to study the effect of their proposed ideas and

guide their final recommendation. Alternatively, the model can be used as part of a

game, where teams of students compete against each other to make the best decisions

for the case study hospital.


A user interface would be required that allows students to adjust input parameters

according to their proposed solutions. One or more case studies would also be required,

including data sets, for use with the model.

As a Research Tool

A second potential use for the model would be as a research tool. The model can

be used by operational researchers to test out proposed decision options derived from

other mathematical models such as alternative scheduling algorithms, optimal MSS and

resource capacity levels. For example, a researcher may have a developed a scheduling

algorithm that he believes will improve the hospital’s throughput. The researcher can

code the algorithm into the model and input hospital specific data to test whether the

algorithm results in any unforeseen consequences on aspects of the perioperative system.

This additional use has in fact already been done during the application at Brampton

and Juravinski as described in chapter 6. At each site, a simulation optimisation bed

resource model proposed a MSS that would reduce the peak demand for inpatient beds

(Liu, 2012). The proposed MSS was inputted into the generic model to determine how

it compared to other options under consideration in terms of throughput, cancellation

rates and inpatient census.

As an Operational Decision Tool

The intent of the generic model presented was to help inform tactical decisions. However,

every day hospitals face difficult online operational decisions such as whether to cancel

an elective case when no bed is available. Typically, this decision is made the day the

case is scheduled, resulting in unused elective OR time, as either the time is used for

urgent cases or the OR is closed early. The cancellation is also an inconvenience for the

patient who is likely already at the hospital ready for surgery. The patient will have to

reschedule their procedure and re-experience the mental and physical duress of preparing


for surgery. If the hospital was able to better forecast bed availability, then cancellation

decisions can be made one or more days ahead of time. This would allow the hospital to

adjust the surgical schedule such that the elective time does not go unused and patients

would be less inconvenienced.

It is proposed that the generic model formulation could be used as a base to develop an

operational decision model. The model would allow hospital decision makers to predict

bed and other perioperative resource availability based on patients currently admitted,

the current elective patient schedule and predicted urgent cases. Decision makers would

interact with the model to determine if cancellations can be avoided and/or inpatient bed

census can be smoothed by adjusting the elective schedule. For instance, if the model

predicts that inpatient census will be high on Thursday likely resulting in cancellations,

decision makers can reschedule some patients who require admission in advance. Further,

the newly available elective OR time could be used to schedule upcoming cases that do

not require admission. Alliteratively, the decision makers may decide to temporarily

increase the capacity of a ward to allow for the scheduled cases to proceed as scheduled.

In this case, the decision makers can use the model to determine how long the additional

beds would likely be required.

Bibliography

Adan, Ivo J.B.F, Jos A Bekkers, Nico Dellaert, Jos Vissers, Xiaoting Yu. 2009. Patient

mix optimisation and stochastic resource requirements: A case study in cardiothoracic

surgery planning. Health Care Management Science 12 129–141.

Banks, J, John S Carson. 1995. Descrete-event system simulation. Englewood Cliffs, NJ:

Prentice-Hall, Inc. .

Belien, Jeroen, Erik Demeulemeester. 2007. Building cyclic master surgery schedules

with leveled resulting bed occupancy. European Journal of Operational Research 176

1185–1204.

Belien, Jeroen, Erik Demeulemeester. 2008. A branch-and-price approach for integrating

nurse and surgery scheduling. European Journal of Operational Research 189 652–668.

Belien, Jeroen, Erik Demeulemeester, Brecht Cardoen. 2006. Visualizing the demand for

various resources as a function of the master surgery schedule: A case study. Journal

of Medical Systems 30 343–350.

Belien, Jeroen, Erik Demeulemeester, Brecht Cardoen. 2009. A decision support system

for cyclic master surgery scheduling with multiple objectives. Journal of Scheduling

12 147–161.

Berchtold, Gunter, Helga Blaschke, Friedrich Hanssmann, Franz Liebl. 1994. Simula-

174

BIBLIOGRAPHY 175

tion modeling as a tool to evaluate alternative configurations of clinical laboratories.

Simulation 63(2) 108–120.

Blake, John T, Michael W Carter. 1997. Surgical process scheduling: a structured review.

Journal of the Society for Health Systems 5(3) 17–30.

Blake, John T, Michael W Carter, Linda O’Brien-Pallas, Linda McGillis-Hall. 1995. A

surgical process management tool. Medinfo 8(1) 527–31.

Blake, John T, Joan Donald. 2002. Mount sinai hospital uses integer programming to

allocate operating room time. Interfaces 32(2) 63–73.

Boldy, Duncan. 1987. The relationship between decision support systems and operational

research: Health care examples. European Journal of Operational Research 29 128–134.

Brown, Nancy, S Powers. 2000. Simulation in a box: a generic reusable maintenance

model. Proceedings of the 2000 Winter Simulation Conference 1056.

Calichman, Murray V. 2005. Creating an optimal operating room schedule. AORN

journal 81(3) 580–588.

Cardoen, Brecht, Erik Demeulemeester, Jeroen Belien. 2010. Operating room planning

and scheduling: A literature review. European Journal of Operational Research 201(3)

921–932.

Carter, Michael W, John T Blake. 2005. Using simulation in an acute-care hospital:

easier said than done. Operations Research and Health Care 70 191–215.

Centeno, Martha A, Ronald Giachetti, Richard Linn, A Ismail. 2003. A simulation-ilp

based tool for scheduling er staff. Proceedings of the 2003 Winter Simulation Confer-

ence 1930–1937.

BIBLIOGRAPHY 176

Cope, Dayana, Mohamed Sam Fayez, Mansooreh Mollaghasemi, Assem Kaylani. 2007.

Supply chain simulation modeling made easy: an innovative approach. Proceedings of

the 2007 Winter Simulation Conference 1887–1896.

Costa, A.X, S.A Ridley, A.K Shahani, Paul R Harper, V De Senna, M.S Nielson. 2003.

Mathematical modelling and simulation for planning critical care capacity. Anaesthesia

58 320–327.

Dexter, Franklin, Rodney D Traub. 2002. How to schedule elective surgical cases into

specific operating rooms to maximize the efficiency of use of operating room time.

Anesthesia & Analgesia 94 933–42.

Drake, Glenn R, Jeffrey S Smith. 1996. Simulation system for real-time planning, schedul-

ing, and control. Proceedings of the 1996 Winter Simulation Conference 1083–1090.

Fletcher, Adrian, D Halsall, S Huxham, Dave Worthington. 2007. The dh accident and

emergency department model: a national generic model used locally. Journal of the

Operational Research Society 58 1554–1562.

Fletcher, Adrian, Dave Worthington. 2009. What is a ‘generic’ hospital model?—a com-

parison of ‘generic’ and ‘specific’ hospital models of emergency patient flows. Health

Care Management Science 12(4) 374–391.

Guerriero, Francesca, Rosita Guido. 2011. Operational research in the management of

the operating theatre: a survey. Health Care Management Science 14(1) 89–114.

Gupta, Diwakar. 2007. Surgical suites’ operations management. Production and Opera-

tions Management 16(6) 689–700.

Guru, Ashu, Paul Savory. 2004. A template-based conceptual modeling infrastructure

for simulation of physical security systems. Proceedings of the 2004 Winter Simulation

Conference 866–873.

BIBLIOGRAPHY 177

Hamilton Health Sciences. 2011. Juravinski hospital. URL

http://www.hamiltonhealthsciences.ca/body.cfm?ID=229. Retrieved July

26, 2011.

Hans, Erwin W, Mark Van Houdenhoven, Peter J.H Hulshof. 2012. A framework for

healthcare planning and control. Handbook of Healthcare System Scheduling Springer

internaltional Series in Operations Research and Management Science 168 301–320.

Harper, Paul R. 2002. A framework for operational modelling of hospital resources.

Health Care Management Science 5(3) 165–173.

Houdenhoven, Mark Van, Jeroen M van Oostrum, Gerhard Wullink, Erwin W Hans,

Johann L Hurink, Jan Bakker, Geert Kazemier. 2008. Fewer intensive care unit refusals

and a higher capacity utilization by using a cyclic surgical case schedule. Journal of

Critical Care 23(2) 222–226.

Jain, Sanjay. 2008. Tradeoffs in building a generic supply chain simulation capability.

Proceedings of the 2008 Winter Simulation Conference 1873–1881.

Kaylani, Assem, Mansooreh Mollaghasemi, Dayana Cope, Mohamed Sam Fayez, Ghaith

Rabadi, Martin J Steele. 2008. A generic environment for modelling future launch

operations—gem-flo: a success story in generic modelling. Journal of the Operational

Research Society 59 1312–1320.

Kharraja, Said, Pascal Albert, Sondes Chaabane. 2006. Block scheduling: Toward a mas-

ter surgical schedule. 2006 International Conference on Service Systems and Service

Management 429–435.

Kim, Seung-Chul, Ira Horowitz. 2002. Scheduling hospital services: the efficacy of

elective-surgery quotas. Omega 30 335–346.

BIBLIOGRAPHY 178

Kim, Seung-Chul, Ira Horowitz, Karl K Young, Thomas A Buckley. 2000. Flexible

bed allocation and performance in the intensive care unit. Journal of Operations

Management 18(4) 427–443.

Kotiadis, Kathy, Stewart Robinson. 2008. Conceptual modelling: knowledge acquisition

and model abstraction. Proceedings of the 2008 Winter Simulation Conference 951–

958.

Kuo, Paul C, Rebecca A Schroeder, Samuel Mahaffey, R. Randall Bollinger. 2003. Opti-

mization of operating room allocation using linear programming techniques. Journal

of the American College of Surgeons 197(6) 889–895.

Kuzdrall, Paul J, N.K Kwak, Homer H Schmitz. 1981. Simulating space requirements

and scheduling policies in a hospital surgical suite. Simulation 36 163.

Kwak, N.K, Paul J Kuzdrall, Homer H Schmitz. 1976. The gpss simulation of scheduling

policies for surgical patients. Management Science 22(9) 982–989.

Law, Averill M. 2005. How to build valid and credible simulation models. Proceedings of

the 37th conference on Winter simulation 24–32.

Law, Averill M, W. David Kelton. 2000. Simulation modeling and analysis. McGraw-Hill

Third Edition.

Lebowitz, Philip. 2003. Schedule the short procedure first to improve or efficiency. AORN

78(4) 651–659.

Liu, Tian Mu. 2012. A generic bed planning model. Masters Thesis - Department of

Mechanical and Industrial Engineering, Univeristy of Toronto .

Lowery, Julie C. 1992. Simulation of a hospital’s surgical suite and critical care area.

Proceedings of the 24th conference on Winter simulation 1071–1078.

BIBLIOGRAPHY 179

Lowery, Julie C. 1996. Introduction to simulation in health care. Proceedings of the 1996

Winter Simulation Conference 78–84.

Lowery, Julie C. 1998. Getting started in simulation in healthcare. Proceedings of the

1998 Winter Simulation Conference 31–35.

MacLeod, Hugh, Alan Hudson, Sarah Kramer, Murray Martin. 2009. The times they

are a-changing: What worked and what we learned in deploying ontario’s wait time

information system. Healthcare Quarterly 12(Special Issue) 8–15.

Marcon, Eric, Franklin Dexter. 2006. Impact of surgical sequencing on post anesthesia

care unit staffing. Health Care Management Science 9 87–98.

Marcon, Eric, Said Kharraja, Nicole Smolski, Brigitte Luquet, Jean Paul Viale. 2003.

Determining the number of beds in the postanesthesia care unit: a computer simulation

flow approach. Anesthesia & Analgesia 96 1415–23.

Martis, Morvin Savio. 2006. Validation of simulation based models: a theoretical outlook.

The Electronic Journal of Business Research Methods 4(1) 39–46.

McAleer, W.E, J.A Turner, D Lismore, I.A Naqvi. 1995. Simulation of a hospital’s theatre

suite. Journal of Management in Medicine 9(5) 14–26.

Miller, Martin J, David M Ferrin, Marcia G Messer. 2004. Fixing the emergency de-

partment: a transformational journey with edsim. Proceedings of the 2004 Winter

Simulation Conference .

Modernisation, NHS. 2001. Tackling cancelled operations: iterim guidance from the nsh

modernisation agency theatre project. NHS Modernisation London .

Moreno, L, R.M Aguilar, C.A Martın, J.D Pineiro, J.I Estevez, J.F Sigut, J.L Sanchez,

V.I Jimenez. 1999. Patient-centered simulation tool for aiding in hospital management.

Simulation Practice and Theory 7 373–393.

BIBLIOGRAPHY 180

Mount Sinai Hospital. 2011. Fast facts. URL http://www.mountsinai.on.ca. Retrieved

July 26, 2011.

Nelson, Elaine A. 1983. The use of a generic simulation model in evaluating manufac-

turing processes. Computers & Industrial Engineering 7(3) 217–224.

Nguyen, J.M, P Six, D Antonioli, P Glemain, G Potel, P Lombrail, P Le Beux. 2005.

A simple method to optimize hospital beds capacity. International Journal of Medical

Informatics 74 39–49.

Ozdemirel, Nur E. 1991. Measuring the user accepatance of generic manufacturing sim-

ulation models by review of modeling assumptions. Proceedings of the 23rd conference

on Winter simulation 419–427.

Paul, Ray J, Jasna Kuljis. 1995. A generic simulation package for organising outpatient

clinics. Proceedings of the 1995 Winter Simulation Conference 1043–1047.

Pidd, Michael. 1992. Guidelines for the design of data driven generic simulators for

specific domains. Simulation 59 237–243.

Pidd, Michael. 1999. Just modeling through: A rough guide to modeling. Interfaces 29

118–132.

Pitt, Martin A. 1997. A generalised simulation system to support strategic resource

planning in healthcare. Proceedings of the 1997 Winter Simulation Conference 1155–

1162.

Ramis, Francisco J, Jorge L Palma, Felipe F Baesler. 2001. The use of simulation for pro-

cess improvement at an ambulatory surgery center. Proceedings of the 33nd conference

on Winter simulation 1401–1404.

Ramis, Francisco J, Jorge L Palma, Vıctor F Estrada, Gloria Coscolla. 2002. A simulator

BIBLIOGRAPHY 181

to improve patient’s service in a network of clinic laboratories. Proceedings of the 2002

Winter Simulation Conference 1444–1447.

Robinson, Stewart. 2004. Simulation: The practice of model development and use. John

Wiley & Sons .

Robinson, Stewart. 2007a. Conceptual modelling for simulation part i: definition and

requirements. Journal of the Operational Research Society 59 278–290.

Robinson, Stewart. 2007b. Conceptual modelling for simulation part ii: a framework for

conceptual modelling. Journal of the Operational Research Society 59 291–304.

Robinson, Stewart, Roger Brooks, Kathy Kotiadis, Durk-Jourke van der Zee. 2010. Con-

ceptual modeling for discrete-event simulation. CRC Press .

Robinson, Stewart, Richard E Nance, Ray J Paul, Michael Pidd. 2004. Simulation model

reuse: definitions, benefits and obstacles. Simulation modelling practice and theory 12

479–494.

Santibanez, Pablo, Mehmet Begen, Derek Atkins. 2007. Surgical block scheduling in a

system of hospitals: an application to resource and wait list management in a british

columbia health authority. Health Care Management Science 10 269–282.

Saremi, Alireza, Payman Jula, Tarek ElMekkawy, G Gary Wang. 2013. Appointment

scheduling of outpatient surgical services in a multistage operating room department.

International Journal of Production Economics 141(2) 646–658.

Schroer, Bernard J, Phillip A Farrington, James J Swain, Dawn R Utley. 1996. A generic

simulator for modeling manufacturing modules. Proceedings of the 1996 Winter Sim-

ulation Conference 1155–1160.

Sciomachen, Anna, Elena Tanfani, Angela Testi. 2005. Simulation models for optimal

schedules of operating theatres. International Journal of Simulation 6(12-13).

BIBLIOGRAPHY 182

Sinreich, David, Yariv Marmor. 2004. A simple and intuitive simulation tool for ana-

lyzing emergency department operations. Proceedings of the 2004 Winter Simulation

Conference .

Sinreich, David, Yariv Marmor. 2005. Emergency department operations: the basis for

developing a simulation tool. IIE Transactions 37(3) 233–245.

Sobolev, Boris G, David Harel, Christos Vasilakis, Adrian Levy. 2008. Using the state-

charts paradigm for simulation of patient flow in surgical care. Health Care Manage-

ment Science 11 79–86.

Sobolev, Boris G, V Sanchez, Christos Vasilakis. 2011. Systematic review of the use

of computer simulation modeling of patient flow in surgical care. Journal of Medical

Systems 35 1–16.

St. Michael’s Hospital. 2011. Programs and focus areas - emergency department. URL

http://www.stmichaelshospital.com/programs/emergency/index.php. Retrieved

July 26, 2011.

Steele, Martin J, Mansooreh Mollaghasemi, Ghaith Rabadi, Grant Cates. 2002. Generic

simulation models of reusable launch vehicles. Proceedings of the 2002 Winter Simu-

lation Conference 747–753.

Tanfani, Elena, Angela Testi. 2010. A pre-assignment heuristic algorithm for the master

surgical schedule problem (mssp). Annals of Operations Research 178(1) 105–119.

Testi, Angela, Elena Tanfani. 2008. Tactical and operational decisions for operating room

planning: Efficiency and welfare implications. Health Care Management Science 12(4)

363–373.

Testi, Angela, Elena Tanfani, Giancarlo Torre. 2007. A three-phase approach for oper-

ating theatre schedules. Health Care Management Science 10 163–172.

BIBLIOGRAPHY 183

van Oostrum, Jeroen M, Eelco Bredenhoff, Erwin W Hans. 2008a. Managerial impli-

cations and suitability of a master surgical scheduling approach. Erasmus School of

Economics (ESE) 1–22.

van Oostrum, Jeroen M, Mark Van Houdenhoven, Johann L Hurink, Erwin W Hans,

Gerhard Wullink, Geert Kazemier. 2008b. A master surgical scheduling approach for

cyclic scheduling in operating room departments. OR spectrum 30(2) 355–374.

VanBerkel, Peter T, Richard J Boucherie, Erwin W Hans, Johann L Hurink, Nelly Lit-

vak. 2010. A survey of health care models that encompass multiple departments.

International Journal of Health Management and Information 1(1) 37–69.

VanBerkel, Peter T, Richard J Boucherie, Erwin W Hans, Johann L Hurink, Wineke

A. M van Lent, Wim H van Harten. 2011a. Accounting for inpatient wards when

developing master surgical schedules. Anesthesia & Analgesia 112(6) 1472–1479.

VanBerkel, Peter T, Richard J Boucherie, Erwin W Hans, Johann L Hurink, Wineke

A. M van Lent, Wim H van Harten. 2011b. An exact approach for relating recovering

surgical patient workload to the master surgical schedule. Journal of the Operation

Research Society 62(3) 1851–1860.

Vasilakis, Christos, Boris G Sobolev, L Kuramoto, Adrian Levy. 2007. A simulation

study of scheduling clinic appointments in surgical care: individual surgeon versus

pooled lists. Journal of the Operational Research Society 58(2) 202–211.

Vissers, Jos, Ivo J.B.F Adan, Jos A Bekkers. 2005. Patient mix optimization in tactical

cardiothoracic surgery planning: a case study. IMA Journal of Management Mathe-

matics 16(3) 281–304.

Wachtel, Ruth E, Franklin Dexter. 2008. Tactical increases in operating room block time

for capacity planning should not be based on utilization. Anesthesia & Analgesia 106

215–26.

BIBLIOGRAPHY 184

William Osler Health System. 2012. Hospitals. URL

http://www.williamoslerhc.on.ca/body.cfm?id=8. Retrieved December 22,

2012.

Wright, M.B. 1987. The application of a surgical bed simulation model. European Journal

of Operational Research 32 26–32.

Zellermeyer, Valerie. 2005. Report of the surgical process analysis and improvement

expert panel. health.gov.on.ca 1–72.

Zhang, B, P Murali, M Dessouky, D Belson. 2009. A mixed integer programming approach

for allocating operating room capacity. Journal of the Operational Research Society

60 663–673.

Appendices

185

Appendix A

Conceptual Model Tables

Table A.1: Model scope: components identified within

the boundary of the study.

Component Include/

Exclude

Justification

Pre-Operative

Wait list man-

agement

List ordering Include Experimental factor, required for

evaluating scheduling rules.

Schedule proce-

dure

Include Experimental factor, required for

evaluating scheduling rules.

Pre-op clinic and

other visits

Scheduling Exclude Clinic visit scheduling is done

independently of OR schedul-

ing, though coordinated with the

scheduled OR date.

Continued on next page . . .

186

Appendix A. Conceptual Model Tables 187

Table A.1 – Continued

Component Include/

Exclude

Justification

Clinic visit Exclude Clinic visit is independent of OR

schedule. Though there is a

chance of cancellation of OR date,

the cancellation is incorporated in

the model elsewhere. Data on vis-

its/tests completed and times not

usually available.

Operative

Before Entering

the OR

Registration and

Admitting

Exclude Does not impact patient flow at

tactical level. Data for time and

flow not usually available.

Patient Prepara-

tion




Tests and Diag-

nostics




Nurse Assess-

ment




Anaesthesia As-

sessment







Component Include/

Exclude

Justification

Surgeon Assess-

ment




Anaesthesia

Room

Exclude With proper coordination and

planning, the anaesthesia room

should not greatly affect flow at

the tactical level. Including this

component would also lead to

increased and unnecessary com-

plexity. Data is also not always

available.

Operating Room Include Required component to overall

flow of patients. Experimental

Factor.

Post-Operative

Immediate

Post-Operative

Recovery

Post-

Anaesthesia

Care Unit

Include Required component to overall


Factor.

Same Day

Surgery Recov-

ery Unit


tactical level. Only used by pa-

tients discharging home same day.




Component Include/

Exclude

Justification

Post-Operative

Recovery

Critical Care

Units



Factor.

Step Down

Units



Factor.

Inpatient Ward

Units



Factor.


Tab

leA

.2:

Lev

elof

det

ail:

det

ail

incl

uded

for

each

com

-

pon

ent

incl

uded

inth

em

odel

.

Com

pon

ent

Det

ail

Incl

ude/

Excl

ude

Com

men

tJust

ifica

tion

Pre

-Op

erat

ive

Pat

ient

Arr

ival

Incl

ude

Model

led

asan

ex-

pon

enti

aldis

trib

uti

on.

Eac

hse

rvic

ean

dpa-

tien

tty

pe

(ele

ctiv

e,

inpat

ient,

urg

ent)

has

it’s

own

arri

val

rate

.

Exp

onen

tial

isea

syto

under

stan

dan

dca

lcu-

late

bas

edon

aver

age.

Dat

aon

actu

alar

riva

l

pat

tern

sis

usu

ally

not

avai

lable

todet

erm

ine

dis

trib

uti

on.

Con

tinued

onnex

tpag

e..

.


Tab

leA

.2–

Con

tinued

Com

pon

ent

Det

ail

Incl

ude/

Excl

ude

Com

men

tJust

ifica

tion

Wai

tlist

man

-

agem

ent

Ele

ctiv

ew

ait

list

sor

ganis

a-

tion

By

serv

ice

orby

surg

eon

Incl

ude

Model

allo

ws

choi

ceto

model

wai

tlist

by

ser-

vic

e(p

ool

ed)

orby

surg

eon.

Sch

eduling

and

pa-

tien

tflow

are

affec

ted

by

the

orga

nis

atio

nof

the

wai

tlist

.In

par

-

ticu

lar

wai

ting

tim

e

and

the

elec

tive

sched

-

ule

.

Lis

tor

der

ing

Ele

ctiv

ew

ait

list

order

ing

Incl

ude

Model

led

assi

mple

or-

der

ing

rule

s(F

IFO

,

pri

orit

y,dea

dline)

.

Sim

ple

tom

odel

and

under

stan

d.

Indiv

id-

ual

surg

eon

wai

tlist

pra

ctic

esar

eva

ried

and

diffi

cult

tode-

scri

be.

Con

tinued

onnex

tpag

e..

.


Tab

leA

.2–

Con

tinued

Com

pon

ent

Det

ail

Incl

ude/

Excl

ude

Com

men

tJust

ifica

tion

Inpat

ient

wai

t

list

order

ing

Incl

ude

Model

led

assi

mple

or-

der

ing

rule

s(F

IFO

,

pri

orit

y,dea

dline)

.

Sim

ple

tom

odel

and

under

stan

d.

Urg

ent

wai

tlist

order

ing

Incl

ude

Model

led

assi

mple

or-

der

ing

rule

s(F

IFO

,

pri

orit

y,dea

dline)

.

Sim

ple

tom

odel

and

under

stan

d.

Sch

edule

pro

ce-

dure

Mas

ter

OR

Sch

edule

Incl

ude

OR

sched

ule

,in

dic

at-

ing

oper

atin

gti

mes

ofO

R,

and

funct

ion

(ele

ctiv

eblo

ck,

ur-

gent,

emer

gent,

on

call).

Key

com

pon

ent

ofpa-

tien

tflow

isth

eop

er-

atin

gsc

hed

ule

.

Con

tinued

onnex

tpag

e..

.


Tab

leA

.2–

Con

tinued

Com

pon

ent

Det

ail

Incl

ude/

Excl

ude

Com

men

tJust

ifica

tion

Ele

ctiv

esc

hed

ul-

ing

rule

s

Incl

ude

Sch

eduling

rule

sin

-

cludin

gty

pe

ofca

ses

tob

esc

hed

ule

din

OR

sched

ule

,bas

ed

onca

sety

pe,

pro

ce-

dure

typ

e,ad

mis

sion

,

oran

aest

hes

iaty

pe.

Key

com

pon

ent

ofpa-

tien

tflow

isth

eop

er-

atin

gsc

hed

ule

.

Inpat

ient

sched

uling

pro

cedure

s

Incl

ude

Rule

onhow

tohan

-

dle

inpat

ient

sched

ul-

ing

-as

par

tof

urg

ent

sched

ule

orel

ecti

ve.

Key

com

pon

ent

ofpa-

tien

tflow

isth

eop

er-

atin

gsc

hed

ule

.

Con

tinued

onnex

tpag

e..

.


Tab

leA

.2–

Con

tinued

Com

pon

ent

Det

ail

Incl

ude/

Excl

ude

Com

men

tJust

ifica

tion

Urg

ent

sched

ul-

ing

pro

cedure

s

Incl

ude

Rule

son

how

tom

an-

age

urg

ent/

emer

gent

pat

ient

list

and

how

tosc

hed

ule

pro

cedure

s

wit

hin

the

OR

sched

-

ule

.

Key

com

pon

ent

ofpa-

tien

tflow

isth

eop

er-

atin

gsc

hed

ule

.

Pro

cedure

Ord

erIn

clude

Sim

ple

order

ing

rule

s

bas

edon

pro

cedure

lengt

h,an

dad

mis

sion

,

anae

sthes

iaan

dpre

vi-

ousl

yca

nce

lled

flag

s.

Key

com

pon

ent

ofpa-

tien

tflow

isth

eop

er-

atin

gsc

hed

ule

and

the

order

itis

per

form

ed.

Op

erat

ive

Con

tinued

onnex

tpag

e..

.


Tab

leA

.2–

Con

tinued

Com

pon

ent

Det

ail

Incl

ude/

Excl

ude

Com

men

tJust

ifica

tion

Can

cellat

ion

Dec

isio

ns

Due

tono

bed

Incl

ude

Can

cel

pat

ients

on

day

ofsc

hed

ule

d

pro

cedure

ifno

pos

t-

oper

ativ

eb

edis

avai

lable

.D

ecis

ion

det

erm

ined

onin

-

putt

edru

les

bas

edon

pat

ient

typ

ean

dif

pre

vio

usl

yca

nce

lled

.

Key

com

pon

ent

of

pat

ient

flow

and

thro

ugh

put.

Model

outp

ut.

Con

tinued

onnex

tpag

e..

.


Tab

leA

.2–

Con

tinued

Com

pon

ent

Det

ail

Incl

ude/

Excl

ude

Com

men

tJust

ifica

tion

Due

toO

Rblo

ck

tim

eov

erru

n

Incl

ude

Can

cel

pat

ients

on

day

ofsc

hed

ule

dpro

-

cedure

ifco

mple

ting

the

case

will

mea

n

exce

edin

gal

low

able

over

tim

eof

the

OR

blo

ck.

Dec

isio

nde-

term

ine

onin

putt

ed

rule

sbas

edon

pat

ient

typ

e.

Key

com

pon

ent

of

pat

ient

flow

and

thro

ugh

put.

Model

outp

ut.

Due

tom

ore

ur-

gent

case

Incl

ude

Can

cel

pat

ients

on

day

ofsc

hed

ule

d

pro

cedure

ifa

mor

e

urg

ent

case

requir

es

the

OR

tim

e.

Key

com

pon

ent

of

pat

ient

flow

and

thro

ugh

put.

Model

outp

ut.

Con

tinued

onnex

tpag

e..

.


Tab

leA

.2–

Con

tinued

Com

pon

ent

Det

ail

Incl

ude/

Excl

ude

Com

men

tJust

ifica

tion

Due

toot

her

rea-

sons

Incl

ude

Can

cel

pat

ients

on

day

ofsc

hed

ule

dpro

-

cedure

bas

edon

the

inputt

edpro

bab

ilit

y

ofa

pat

ient

bei

ng

can-

celled

for

are

ason

not

list

edab

ove.

Rea

sons

can

incl

ude

pat

ient

not

read

yfo

rsu

rger

y,

staff

/surg

eon/a

nae

sthes

ia

not

avai

lable

,et

c.

Key

com

pon

ent

ofpa-

tien

tth

rough

put

and

flow

.

Con

tinued

onnex

tpag

e..

.


Tab

leA

.2–

Con

tinued

Com

pon

ent

Det

ail

Incl

ude/

Excl

ude

Com

men

tJust

ifica

tion

Op

erat

ing

Room

Pro

cedure

tim

eIn

clude

Tot

alti

me

pat

ient

inO

Rfo

rpro

cedure

,

from

pat

ient

ente

red

room

unti

lpat

ient

read

yto

be

tran

s-

ferr

ed.

Does

not

incl

ude

del

ayti

me.

Key

com

pon

ent

ofpa-

tien

tflow

.

Del

ayIn

clude

Del

ayof

pat

ient

tran

s-

fer

top

ost-

oper

ativ

e

unit

sdue

toca

pac

ity.

Key

com

pon

ent

ofpa-

tien

tflow

.

Turn

arou

nd

tim

e

Incl

ude

Ave

rage

turn

arou

nd

tim

eby

serv

ice

be-

twee

nca

ses.

Key

com

pon

ent

ofpa-

tien

tflow

.

Pos

t-O

per

ativ

e

Con

tinued

onnex

tpag

e..

.


Tab

leA

.2–

Con

tinued

Com

pon

ent

Det

ail

Incl

ude/

Excl

ude

Com

men

tJust

ifica

tion

Pos

t-O

per

ativ

e

Rec

over

y

Cri

tica

lC

are

Unit

s

Rec

over

yti

me

Incl

ude

Med

ical

lynec

essa

ry

reco

very

tim

e.

Key

com

pon

ent

of

pat

ient

flow

asaf

-

fect

sav

aila

bilit

yof

reso

urc

es.

Ste

pD

own

Unit

s

Rec

over

yti

me

Incl

ude

Med

ical

lynec

essa

ry

lengt

hof

stay

.

Key

com

pon

ent

of

pat

ient

flow

asaf

-

fect

sav

aila

bilit

yof

reso

urc

es.

Inpat

ient

War

d

Unit

s

Rec

over

yti

me

Incl

ude

Med

ical

lynec

essa

ry

lengt

hof

stay

.

Key

com

pon

ent

of

pat

ient

flow

asaf

-

fect

sav

aila

bilit

yof

reso

urc

es.

Con

tinued

onnex

tpag

e..

.


Tab

leA

.2–

Con

tinued

Com

pon

ent

Det

ail

Incl

ude/

Excl

ude

Com

men

tJust

ifica

tion

Del

ayfo

rot

her

leve

lsof

care

outs

ide

ofm

odel

scop

e

Wai

tti

me

in

bed

for

other

reso

urc

es(A

LC

)

Incl

ude

Tim

epat

ient

must

wai

tin

am

odel

led

bed

for

adow

nst

ream

reso

urc

eth

atis

not

incl

uded

inth

em

odel

.

Key

com

pon

ent

of

pat

ient

flow

asaf

-

fect

sav

aila

bilit

yof

reso

urc

es.

Bed

Man

agem

ent

Rec

over

yti

me

Incl

ude

Med

ical

lynec

essa

ry

lengt

hof

stay

.

Key

com

pon

ent

of

pat

ient

flow

asaf

-

fect

sav

aila

bilit

yof

reso

urc

es.

Off

serv

icin

gIn

clude

Model

offse

rvic

ing

of

pat

ients

toot

her

unit

s

ifb

edin

unav

aila

ble

.

Bas

edon

inputt

edoff

serv

icin

gru

les.

Key

com

pon

ent

of

pat

ient

flow

asaf

-

fect

sav

aila

bilit

yof

reso

urc

es.

Con

tinued

onnex

tpag

e..

.


Tab

leA

.2–

Con

tinued

Com

pon

ent

Det

ail

Incl

ude/

Excl

ude

Com

men

tJust

ifica

tion

Nurs

ing

rati

oIn

clude

Model

will

adju

st

nurs

ing

rati

ow

hen

pat

ient

isoff

serv

iced

tore

flec

tdiff

eren

t

leve

lof

care

requir

ed

when

offse

rvic

ed.

Key

com

pon

ent

of

pat

ient

flow

asaf

-

fect

sav

aila

bilit

yof

reso

urc

es.

Del

ayIn

clude

Del

ayof

pat

ient

tran

s-

fer

tonex

tunit

due

to

capac

ity.

Key

com

pon

ent

of

pat

ient

flow

asaf

-

fect

sav

aila

bilit

yof

reso

urc

es.


Table A.3: Model Assumptions.

Assumption Description Reason

Pre-

operative

Activities

Activities that occur before the

day of surgery, such as the pre-

operative clinic appointment, is

not included

Activities may often cause an op-

erational issue, in terms of coordi-

nation with OR schedule, and run

largely independent of the periop-

erative patient flow.

Day of pre-

operative

activities

Activities that occur on the day

of surgery, prior to entering the

OR are not included. Activi-

ties and areas include registra-

tion/admission, same day surgery

area, OR holding, etc.

Activities may often cause an op-

erational issue, in terms of coor-

dination with OR schedule.

Elective

patient

waiting

lists

Simple wait listing included al-

lows for ordering by FCFS, pri-

ority and deadline. Does not at-

tempt to capture details of indi-

vidual surgeon practices.

Eery surgeon manages his/her

wait list in a very specific manner,

which they can not often quantify

in a meaningful way for the pur-

poses and ease of modelling.

Length of

Stay in

long stay

units

LOS in long stay units (ward,

ICU, SDU) are rounded down to

the nearest day such that dis-

charges occur at midnight of the

day of discharge. LOS less than

one day are rounded up to mid-

night.

Ease of modelling and handling

patient flow and bed decisions.





Anaesthesia

Induction

Room

Anaesthesia induction Room, as

seen at SMH) is not included.

Coordination of activity through

the anaesthesia induction rooms

is an operational problem, and

does not affect patient flow at the

tactical level of detail.

Surgeons

running

more than

one OR at

once

Surgeons who are assigned to

more than one OR at one time are

assumed to use residents and in-

terns to run both ORs at once,

and thus largely independently.

Rather than using the OR as a

swing room to save turn around

time.

Simplification in scheduling pa-

tients and coordinating day of ac-

tivity.

Number

of non-

modelled

patients

inputted

by month

The inputted number of non-

modelled patients per unit can

vary by month only. Variability

by day of week is not considered.

Simplification to reduce input re-

quirements and coding. Rate

of non-modelled patients is often

not well documented nor under-

stood to provide valuable input

data.

Scheduling

Functions

Urgent and emergent time - can

not interrupt an elective block,

but can be scheduled immediately

before or after elective time, or in

an OR on its own

To simplify model coding logic.





On Call time will be used before

closed OR time to schedule emer-

gent patients.

For the purposes of results collec-

tion in terms of OR utilisation.

Surgeon

assignment

Surgeons only assigned to elective

time blocks.

Reflective of usual practice.

Model assumes that ur-

gent/emergent patients are

not assigned a particular sur-

geon, as they are performed by

the on-call surgeon.

Up to two surgeons can split an

elective block.

To simplify model coding and re-

flective of usual practice.

Surgeon can not be assigned to

two half blocks in two different

ORs. Surgeons can be assigned

to both halves of the same OR if

probability allows.

To simplify coding. Considered

to not occur regularly unless sur-

geon picks up time released by

other surgeons.

Service as-

signment

No more than one service per

elective block.

Simplify model coding.

Elective time must be assigned a

service. Other OR functions do

not require assignment, though

inpatient and emergent time can

be assigned, or left open to all ser-

vices.

Assumed to be common practice

in hospitals.


Table A.4: Model Simplifications.


SimplificationDescription Reason

Single OR

and PACU

group

Model allows only a single set of

ORs and PACU. If a hospital,

such as SMH has more than one

set of OR suites or PACU units,

they should be modelled together

in a single set. Scheduling rules

can be used to control the types

of patients allowed in each set of

ORs.

Simplification in terms of patient

routing though the model.

Patient

flow

though

post-

operative

beds oc-

curs only

in ”down-

ward”

direction

Flow occurs from higher levels of

care to lower. i.e. ICU to SDU.

Never from ward to SDU or to

ICU.

Reduction of allowable patient

flow routes, and reduces num-

ber of bed resource checks re-

quired. If patient did move back

and forth, length of stay in each

unit should be equal to the total

amount of time spent in the unit.





Inpatient

unit capac-

ity

Inpatient unit (wards, SDU, ICU)

capacity can be adjusted between

weekdays and weekends, but not

by each day of the week nor by

time of day.

Unit capacity at hospitals at the

inpatient level is usually budgeted

based on weekend and weekday

levels, and does not vary by time

of day or day of week.

OR Equip-

ment (e.g..

Scopes)

OR equipment is not included. Reserving, use and availability of

OR equipment is excluded as de-

lays related to equipment avail-

ability is an operational issue that

can be evaluated independently.

If some consideration is needed

when scheduling cases, a schedul-

ing rule can be used to limit the

number of cases that requires a

particular piece of equipment.





Inpatient

equipment

Equipment used during the hos-

pital stay in not included. Eg.

Therapeutic beds, monitors.

Equipment is often used across

man units and patients. An inde-

pendent study on use and avail-

ability, that included all services

and patient types is sufficient and

useful. Historical cancellation

rates due to equipment can be in-

cluded in the “other cancellation”

rate to reflect equipment avail-

ability.

Appendix B

Change Database

The following table (B.1) is the change database of changes made to the initial generic

conceptual model during coding in Visual8 and implementing at the test sites. Client

Request refers to changes made to the generic model to customise for a specific client

to achieve credibility at the particular site. Implementation refers to changes made to

simplify coding and implementation within the Visual8 coding environment.

208

Appendix B. Change Database 209

Tab

leB

.1:

Chan

gedat

abas

e.

Chan

geT

yp

eT

he

chan

geW

hat

itw

asR

easo

n

Clien

tR

eques

tU

rgen

tblo

ckti

me

-al

low

to

spec

ify

order

ofpri

orit

ypat

ients

tofill

tim

e.

Sea

rched

thro

ugh

urg

ent

wai

t

list

inor

der

asdefi

ned

inin

put

file

.

Cust

omis

atio

nfo

rW

illiam

Osl

er.

Imple

men

tati

onA

singl

epat

ient

input

file

in-

stea

dof

one

per

pat

ient

typ

e

Thre

eI:

Pat

ient

Input

file

,on

e

for

each

pat

ient

typ

e(e

lect

ive,

urg

ent,

inpat

ient)

Eas

ier

toco

de

and

man

age

in

Sim

ul8

Imple

men

tati

onA

dd

anin

put

for

the

min

imum

OR

LO

S

n/a

For

ease

ofco

din

gof

sched

uling

funct

ion.

Imple

men

tati

onU

rgen

tar

riva

lra

teby

serv

ice

only

,not

serv

ice

and

pri

orit

y.

Was

by

bot

hse

rvic

ean

dpri

or-

ity.

Eas

eof

codin

gan

db

ecau

sear

-

riva

lra

tew

hen

by

serv

ice

and

pri

orit

yis

ofte

nlo

w.

Imple

men

tati

onSep

arat

equeu

efo

rurg

ent

pa-

tien

tsw

ho

are

tob

edon

enex

t

from

other

pat

ients

wai

ting

to

be

called

.

Sin

gle

wai

ting

list

.Sim

plify

codin

gin

model

.

Con

tinued

onnex

tpag

e..

.


Tab

leB

.1–

Con

tinued

Chan

geT

yp

eT

he

chan

geW

hat

itw

asR

easo

n

Imple

men

tati

onR

esou

rce

shif

ts-

up

tofo

ur

avai

lable

ina

day

.M

ust

be

order

edfr

omm

idnig

ht

tom

id-

nig

ht,

wit

hou

tcr

ossi

ng

over

nig

ht.

On-c

all

shif

tsar

ein

di-

cate

din

ase

par

ate

input

table

.

Allow

edfo

rth

ree

shif

ts,

plu

san

on-a

lsh

ift,

but

assu

med

tim

e

could

cros

sov

erm

idnig

ht.

Eas

eof

codin

gan

dunder

stan

d-

ing.

Imple

men

tati

onT

ime

rese

rved

for

urg

ent

and

emer

gent

pat

ients

isas

sum

edto

occ

ur

bef

ore

oraf

ter

anel

ecti

ve

blo

ck,

but

will

not

cut

anel

ec-

tive

blo

ckin

two.

Allow

edfo

rurg

ent/

emer

gent

tim

eto

cut

into

anel

ecti

ve

blo

ck.

Eas

eof

codin

g.

Imple

men

tati

onIn

put

requir

edfo

rto

tal

num

-

ber

ofsc

hed

uling

rule

cate

gori

es

tohel

pm

odel

det

erm

ine

outp

ut

file

.

Not

incl

uded

.E

ase

ofco

din

g.

Con

tinued

onnex

tpag

e..

.


Tab

leB

.1–

Con

tinued

Chan

geT

yp

eT

he

chan

geW

hat

itw

asR

easo

n

Imple

men

tati

onA

dded

ata

ble

for:

Gen

eral

Char

acte

rist

ics

ofSurg

ical

Pop

-

ula

tion

.(t

otal

num

ber

ofse

r-

vic

es,

max

imum

pri

orit

yle

vels

for

each

pat

ient

typ

e).

n/a

Eas

eof

codin

g.

Imple

men

tati

onA

dded

pat

ient

file

index

shee

t

tosh

oww

hat

line

each

serv

ice

star

tsan

den

ds

at.

n/a

Eas

eof

codin

g.

Imple

men

tati

onA

dded

Tot

alnum

ber

ofR

ule

sto

I:Sch

eduling

Rule

sL

ist

n/a

Eas

eof

codin

g.

Imple

men

tati

onA

dded

anIn

put

for

min

imum

OR

LO

Sfo

rea

chse

rvic

e.

n/a

So

that

model

willnot

try

tofill

rem

ainin

gti

me

that

isle

ssth

en

this

amou

nt

Con

tinued

onnex

tpag

e..

.


Tab

leB

.1–

Con

tinued

Chan

geT

yp

eT

he

chan

geW

hat

itw

asR

easo

n

Imple

men

tati

onA

dded

asp

read

shee

tto

trac

k

star

tan

den

dti

me

ofea

chfu

nc-

tion

inea

chO

Rfo

rth

atday

-so

that

we

know

when

toca

llth

e

firs

tpat

ient

and

when

over

tim

e

beg

ins

n/a

Eas

eof

codin

g.

Imple

men

tati

onA

dded

M:

Pos

tO

pR

esou

rces

whic

htr

acks

star

ting

row

inP

a-

tien

tE

xit

spre

adsh

eet

for

each

pos

tO

punit

and

poi

nts

toap

-

pro

pri

ate

LO

Slo

cati

ons

inP

a-

tien

tF

ile

(bas

edon

the

typ

eof

unit

)

n/a

Eas

eof

codin

g.

Con

tinued

onnex

tpag

e..

.


Tab

leB

.1–

Con

tinued

Chan

geT

yp

eT

he

chan

geW

hat

itw

asR

easo

n

Imple

men

tati

onA

dded

M:O

Rsp

lit

tim

esto

reco

rdw

hen

OR

mov

esfr

om

one

surg

eon

toth

eot

her

ona

split

OR

day

.

n/a

Eas

eof

codin

g.

Imple

men

tati

onA

dded

M:P

ost

Op

Pat

ient

Exit

Tim

esto

trac

kw

hic

hb

eds

are

take

nby

who,

unti

lw

hen

,an

d

how

man

yre

sourc

es(b

eds)

are

requir

ed.

n/a

Eas

eof

codin

g.

Appendix C

Generic Model Detailed Description

C.1 Introduction to the Proposed Framework

The purpose of this appendix is to describe in detail the structure and components of the

proposed generalised framework for a perioperative simulation model. The perioperative

process can be sub-divided into three main processes: pre-surgical day, the surgical day

and post-surgical. Consequently, the proposed framework has been subdivided into the

same three sub-processes. The following three chapters will describe the framework’s

structure and components regarding each of the main sub-processes. Before the sub-

process can be addressed, the general set-up of the framework is addressed below.

C.2 Overall Framework Structure

The perioperative process is a complex system of numerous possible routes, decisions,

and interactions, all which can significantly affect a patient’s path through the system.

In order to capture this complexity in a manner that will be intuitive to the user, and

also take advantage of concepts from existing framework methodologies, the framework is

built on a “module” like basis, where processes can be further broken down into smaller,

more detailed sub-modules.

214

Appendix C. Generic Model Detailed Description 215

Based on the three sub-processes of the perioperative patient flow, the framework

is divided into three modules. Each of these three modules contains a number of sub-

modules, processes and decisions. For the purpose of this framework, any module that

is a component of a larger module will be called a sub-module. Sub-modules can also be

composed of other processes and sub-modules.

Pre-Operative

Module

Post-

Operative

Module

Surgical Day

Module

Start of the

Day Module

framework Aug 24 2009.vsd Overall View

Friday, August 28, 2009 2 of 10

Figure C.1: The overall view of the framework, showing the three modules’ patient flows.

Figure C.1 is the overall view of the framework, including the three modules, and

the patient flow (solid arcs) between the three modules. There are three types of shapes

used for the pictorial framework views, as shown in figure C.2. The rectangles are used

to show a single process, where only a single activity occurs. The rectangles with double

vertical lines represent modules and sub-modules that can be further broken into a set of

processes and decisions. These sub-modules will either have an accompanying diagram,

showing it’s internal processes, or will have a set of decisions, represented by a decision

tree or algorithm. The cylindrical shape represents queues where patients wait for the

next process. The solid arcs represent patient flow between processes. The dashed arcs

represent the modules that the Start of the Day Module communicates with, and affects,

other processes when run.


Process

(Sub-)Module

Patient

Flow

Wait – Queue

or delay

Affects

Patient Flow

framework Aug 24 2009.vsd legend


Figure C.2: Legend of shapes used in the pictorial framework.

C.2.1 Flow of Patients and Information

In order to allow for flexibility of the model and its processes, the flow of information and

patients are handled differently. The main flow element of the framework is the patients.

When two modules are connected by a flow, it is by the flow of patients moving from one

process to the other. Throughout this presentation, this type of flow will be represented

by solid arrows connecting two points.

Information is passed to and from processes to specified data elements. The flow of

information can be a result of a number of factors:

• A model process requires a piece of input information, such as a scheduling rule,

resource capacity, etc.

• A model process requires information about a patient in the system, such as the

time that is required to perform surgery, or where the patient is to go to next.

• A model process has made an adjustment to a resource measure, or a patient’s

information, such as the current location of a patient, and needs to update the

value in the data.

There are three types of data files that are used in the framework:


1. Input Data Files: These sheets are used to input data into the model. They are

used to initially build the model specifics, as well as input variables into processes,

etc.

2. Intermediate Data Files: These sheets are used by the model while running to store

pertinent information about the patients, resources, etc.

3. Output Data Files: These sheets collect various outputs of the model, and are used

to create the final model report.

For the remainder of this discussion, when referencing a specific data file, it will first

indicate what type of data file through a capital letter (I for input, M for intermediate,

and O for output), followed with a colon and the name of the data file. For example,

I: File Name refers to the input data file called filename. If a specified field of the

file needs to be referred to, it will follow the file name within square brackets, ex. I:

File Name[Field Name]. The structure and content of the data files are also described

throughout this document.

Further, each patient in the model is assigned a unique identifying number that can

be used in reference to that patient throughout the model. For the remainder of the

discussion, this will be referred to as the patient ID.

C.2.2 Modelled Patients

There are three main types of surgical patients whose journeys through the system differ

significantly. The first type of patient is scheduled for surgery during the regular operating

room hours, and is often referred to as an elective patient. These patients generally visit

a surgeon at a clinic, where the surgeon determines that they require surgery. These

patients can often wait several weeks to months for their procedure. Depending on the

patient’s health, health policies, and other influences, these patients can wait indefinitely

for their procedure, or up to a specified amount of time, such as 180 days (6 months); the


model allows for either case as indicated in I: Wait List Expiry Information - Elective

(see table C.1). For example, SMH currently has no specific rules on how long an elective

patient can wait before being scheduled, thus he could wait a long time on the elective

waiting list. Urgent patients, however, require surgery within a specified amount of

time, depending on their urgency level. Priority 1-A patients must have surgery within

two hours, while priority 1-B patients can wait up to eight hours. Thus, 1-B patients

can wait six hours (the difference between eight hours and two hours) before he would

require surgery in the same timeline as patients of priority 1-A. Inpatients at SMH are

to be scheduled within seven days, if they are not, they must be added to the surgeon’s

elective list. Thus, in this case, elective patients would have infinite waiting times,

regardless of priority. Urgent patients would have maximum wait times of two, six, 46

and 126 hours, for priority 1-A, 1-B, 1-C and 1-D respectively. Inpatients would have an

inputted wait of seven days.

Table C.1: I: Wait List Expiry Information - Elective/ Urgent/ Inpatient. Details when

each patient will need to be taken off the wait list and scheduled immediately, or as

another type of patient. One file for each patient type. Urgent is given in hours, while

elective and inpatient is given in days.

Number of Priority Levels

Maximum Time on list Priority level

Service Level 1 . . . level n

Service 1

. . .

Service n

Further, elective patients remain at home prior to their procedure, and arrive at the

hospital a few hours prior to their scheduled procedure start time. They are also often


referred to as same day patients, as they arrive at the hospital the same day as their

procedure. Some hospitals further classify elective patients into various priority levels,

which may indicate their place on the wait list, their priority, or the maximum time they

can wait for their scheduled procedure. The model allows for priority among elective

patients, and to stipulate how they should be ordered in the wait list (I: Patient Input

File[Priority Level], and I: Wait List Rules [Wait List Ordering] shown in tables C.2 and

C.3 respectively). The elective patient wait list can be by surgeon or service, to reflect

whether wait lists are pooled among surgeons, or no. The choice is noted in I: Wait List

Rules[wait list organisation] in table C.3.

The second group of patients are emergent and urgent patients. These patients often

present themselves at the emergency department, and require surgery within a few hours

to a few days. These patients often require a procedure on a life-or-death basis, while

others are stable enough to wait a day or two. These patients are often already admitted

to the hospital through the emergency department. Their level of urgency determines

how long they can wait before their procedure must begin. How many levels of urgency,

and their times can vary by hospital, thus the framework allows for the specification of

the number of urgency levels and their maximum allowable waits (I: Wait List Expiry

Information - Urgent as shown in table C.1).

A third common patient type is often referred to as inpatients. These patients have

already been admitted to the hospital, and require surgery, but are not considered ur-

gent. These patients often have been admitted for some other reason, and now require

additional care.

Some hospitals treat inpatients as part of the urgent population, but in their least

urgent level, as they can wait up to a week or so for their procedure. In this case, these

patients would follow similar scheduling rules as the urgent patient population, including

the use of after elective time OR time, etc. Other hospitals treat them more like an

elective patient who must be done within the next week or so, but should be scheduled


Table C.2: I: Patient Input File - Elective/Inpatient/Urgent

Column Details

Service ID

Surgeon ID #

Patient type code Elective, urgent, inpatient

Priority level For wait list management (all case types)

Booking time Time to book in OR

OR LOS In minutes

PACU LOS In minutes

ICU LOS In days

Ward LOS In days, includes ALC days

Step Down Unit LOS in days

SDS post Op LOS

ICU flag Indicates if the ICU visit is planned or unplanned

ICU divert flag Indicates if the patient can be diverted to the PACU

Post surgical route code

Scheduling rule category

Arrival time of day Only for the urgent patient input file

On service ward

Anaesthesia flag

Admit or non-admit flag


Table C.3: I: Wait List Rules

Wait List Organisation Choices: by surgeon or by

service

Service Wait List Ordering: (Select

one option: by priority, by

FIFO, by time until waited

too long)

Priority when returning to

wait list after being can-

celled: (Select one option:

to front of list, same as

original, emergent of lowest

level)

Service 1

. . .

Service n

within elective time whenever possible.

Regardless of how the patients are scheduled, inpatients most often have a surgeon

assigned prior to scheduling, thus cannot simply be lumped in with the urgent patients.

In order to accommodate both methods of scheduling inpatients, and allowing for a pre-

assigned surgeon, the framework employs a third patient group, with its own scheduling

algorithm and rules. As with the two other patient types, the details of any priority

levels and maximum waiting times within the inpatient group is details in I: Wait List

Expiry Information - Inpatient as shown in C.1.

C.3 General Model Set Up Information

There are a number of general input parameters required by the model for set up:

• Run time of the simulation - the length of time, in days to run the model. This


should usually be several months to a year or more. This time does not include

the warm up period. (I: General Simulation Information[Run time of simulation],

table C.4)

• Length of warm up period - the length of time, in minutes, to run the model before

collecting any output results. I: General Simulation Information[Length of Warm

up period])

• Initial waiting list sizes - here the user can specify the starting number of patients on

each waiting list, whether by surgeon or pooled by service. (I: Model Initialisation

Wait List Sizes, table C.5

.

Table C.4: I: General Simulation Information

Run time of simulation (in

minutes)

Length of Warm up period

(In minutes)

Table C.5: I: Model Initialisation - Wait List Sizes

Surgeon/Service ID # on Wait List

1

. . .

n


C.4 Pre-surgical Processes

Pre-surgical processes include all activities prior to a patient’s arrival in the perioperative

unit on the day of their surgical procedure. This generally includes wait list management

processes, scheduling processes, and pre-surgical clinic scheduling and visits.

C.4.1 Pre-Surgery Module

The Pre-Surgery module captures the patient flow, information and decision making

that occur prior to the day of surgery. The key function of the pre-surgery module is to

manage the wait lists and schedule patients for surgery. This module’s discussion will

start with a detailed, step-by-step look into the processes within the module, focusing

on the flow of patients, and the module’s interaction with the information files. Figure

C.3 shows the processes and sub-modules of the pre-surgery module.

Decision to

Perform Surgery is

made

Assign Patient

Characteristics

Elective

Patient

Management

Sub-module

Urgent

Patient

Management

Sub-module

Urgent/Emergent

Patients

Elective Patients

Elective Patients who have Waited too long

Inpatient

Patient

Management

Sub-module

Inpatients

Decision to

Perform Surgery is

made

Assign Patient

Characteristics

Urgent patients for

day are created

Wait for Time

of Arrival

Assign Patient

Characteristics

framework Aug 24 2009.vsd Patient Arrives in Queue


Figure C.3: The pre-surgery module.


For both elective and inpatients, the module begins with the decision to perform

surgery process. Here, patients are generated based on a specified arrival process distri-

bution for each service (I: Arrival Patterns, as shown in table C.6). The arrival pattern

is assumed to follow an exponential distribution. Thus for each service, the user needs

to specify the average number of patients that enter the list per day. Using the exponen-

tial distribution is easy for hospital users to understand, and to quantify for the input,

without having extensive knowledge of statistical distributions, or when arrival patterns

are difficult to determine as the data is not available. Further, the use of an exponential

arrival pattern has been shown to be realistic in many cases within health care (Lowery,

1996).

Table C.6: I: Arrival Patterns - Elective/Inpatient

Service # Arrival Rate (# per day)

1

2

. . .

# services

Each service has its own arrival pattern process. This allows hospitals to measure

the effect of changing demand volumes of specific services. The hospital can also adjust

volumes of specific procedure types, surgeons, etc. or other characteristics through the

inputted patient characteristics as described below.

Each patient is assigned a unique identification number as his patient ID. The elective

or inpatient then moves to the assign patient characteristics process, where the charac-

teristics of the patient, such as procedure length, patient type, length of stay in ward, etc.

(see I: Patient Input File - Elective/Inpatient/Urgent table C.2 on page 220) are deter-

mined. The characteristics chosen for a patient are based on the set of characteristics of


an actual patient. Each service has its own set of patient characteristics. As opposed to

other models, this model does not sample from distributions to determine characteristics

such as procedure length. Creating a realistic set of characteristics of a patient based on

a number of distributions would be difficult to guarantee. Further, to help ensure that at

least some realism is maintained when using distributions, a large number of conditional

probabilities and distributions would likely be required. This would not only be difficult

to determine, but would also make the model difficult to use, update and understood by

the targeted users, hospital administrators.

As such, the framework uses an inputted set of possible patients and their character-

istics, which is easy for the targeted end users to work with and understand. This input

file can be based on historic patient records, but also allows decision makers to adjust

specific characteristics of the file to represent changes to methodology, surgeons, patient

mix, etc. For instance, if the hospital would like to implement a new technology that

will reduce some procedures’ length by 10%, the data file can be adjusted to reflect this

improvement. Alternatively, if the hospital would like to increase the incoming volume

of a type of procedure, the file can be adjusted such that there are more cases of that

type to randomly select. A further discussion of the use and possibilities of this patient

file is discussed later in the model development and testing sections as performed at the

three test sites.

The assign patient characteristics process randomly selects one of the rows of the

patient input file for the specified service (I: Patient Input File). This process will then

copy over data of the selected patient row to the intermediate data file M: Current

Patient File (as shown in table C.7), along with the patent ID. This intermediate file

will be accessed often throughout the remainder of the model whenever information is

required about a specific patient.


Table C.7: M: Current Patient File

Column Details

Patient ID #

Input file ID #

Time Entered WL (for first time)

Scheduled date (blank if none yet)

# times cancelled

Current location

Route code

Step # in route

Next Location assigned

Router

Three Patient Streams

Elective patients are managed within the elective patient management sub-module. Here,

patients wait until their scheduled day of surgery, or until they have waited too long and

require surgery immediately, changing their status to an urgent patient. When elective

patients enter, they are slotted into their appropriate wait list, are scheduled and then

wait for the scheduled procedure date to arrive. For further detail of this sub-module

please see section C.4.1.

Urgent and emergent patients enter the Urgent patient scheduling sub-module, which

manages the urgent wait list based on how long the patient can wait. The sub-module

also attempts to schedule the patients according to their urgency and various scheduling

and decision rules. See section C.4.1 for more details.

Finally, the inpatient management sub-module attempts to schedule inpatients for

surgery based on the specified scheduling rules. Please refer to section C.4.1 for further


details.

Elective Patient Management Sub-Module

The elective patient management sub-module manages the wait lists as shown in figure

C.4. When a patient first enters this module, the process set queue characteristics de-

termines the patient’s priority in the queue, and the maximum time that the patient

can wait to be scheduled, according to the patient’s characteristics (M: Current Patient

File) and the inputted queuing rules (I: Wait List Rules [Wait List Ordering], as shown

in table C.3 on page 221).

Set queue

characteristics

Waited too long

Move to Surgical Day Module

Wait list

Queues (By

surgeon or

service)

...

Elective Patient Management Sub-Module

Route to Urgent Patient Management

framework Aug 24 2009.vsd Elective Patient Queue Management


Figure C.4: The elective patient management sub-module.

The maximum time a patient can wait to be scheduled is based on his priority level

and service. The maximum time for each type and priority is provided in the input data

file I: Wait List Expiry Info (table C.1 on page 218). The process will determine where

in the queue the patient is to go, based on the inputted wait list ordering rules (I: Wait

List Rules [Wait List Ordering]) and the characteristics of the patients already in queue.

There are three wait list ordering schemes that hospitals can select from:


• First In First Out (FIFO): Patients are simply ordered in the order in which

they arrived.

• Priority: Patients are ordered strictly on their priority (from their patient charac-

teristics). If a patient of a higher priority enters the wait list, patients with lower

priority will be pushed further back in the queue to accommodate this patient.

• By deadline: Patients are ordered based on the amount of time they have left

before they are declared to have waited to long. Thus the patient who is nearing

the end of their maximum wait will be near the front of the wait list. Thus a lower

priority patient would be ahead of a higher priority if the former has been waiting

for long enough that he must be completed in less time than the newly arriving

patient of a higher priority.

Patients are placed in their respective queues, and wait until they are scheduled,

or until they have waited too long, whichever comes first. If a hospital wants to test a

pooled waiting list system, this can be done by using a single surgeon for each service, and

adjusting the patient input files accordingly. Scheduling of elective patients is performed

by the Start of the New Day module, details to follow in section C.9.

The process waited too long will remove a patient from his queue when he has reached

his maximum waiting time without being scheduled, according to I: Wait List Expiry

Information - Elective (table C.1, page 218). This process will move the patient to the

urgent patient queue, as an urgent patient of the least urgent priority level.

Urgent Patient Management Sub-Module

Due to the nature of urgent patients, there are many different ways a hospital can manage

their urgent patients, and many different decisions to be made. The how and what

decisions can also differ within a hospital depending on the urgency of the case, the time

of day, and the availability of ORs and staff. Independent of the hospital, the general


objectives are the same:

1. Minimise disruptions to the elective patient schedule.

2. Minimise the time used overnight, on weekends and of the on-call staff.

3. Perform the case within a reasonable amount of time and /or achieve wait time

targets.

When an urgent patient enters the Urgent Patient Management sub-module, the

patient is routed to either the Urgent Patient Waiting List queue or the Schedule Im-

mediately process. This route decision is based on the patient’s level of urgency and the

inputted rule from I: Urgent Patient Scheduling Rules (table C.8).

Urgent Patient

Waiting List

Waited too long

Urgent Patient Management Sub-Module

Route -based on

urgent scheduling

rules



Schedule

Immediately

framework Aug 24 2009.vsd Urgent Patient Queue Management


Figure C.5: The urgent patient management sub-module.

Patients placed in the Urgent Patient Waiting List wait there until they are scheduled

through the Determine next OR Activity Algorithm (see section C.10.1). When scheduled,


Table C.8: I: Urgent Patient Scheduling Rules

Maximum urgency level where patient must be scheduled immedi-

ately, without waiting for another option

Urgent patient waiting list ordering preference (choose from FIFO,

Strict Priority or By Deadline)

For urgent patients who need to be scheduled immediately, order the following

options in order of preference:

Schedule to an OR dedicated to emergent and urgent cases.

Schedule to an OR that has time reserved for urgent cases within

its elective schedule, where the service is currently running.

Schedule to an OR that has time reserved for urgent cases within

its elective schedule, regardless of service.

Schedule to an OR that has time remaining at the end of the elective

OR time that was not filed by elective patients, service specific.

Schedule to an OR that has time remaining at the end of the elective

OR time that was not filed by elective patients, regardless of service.

Schedule to an OR that has finished their elective case list, service

specific.

Schedule to an OR that has finished their elective case list, regard-

less of service.

Schedule to an OR that is currently closed, service specific (i.e.

the service does operate in that room sometime during the regular

elective schedule).

Schedule to an OR that is currently closed, regardless of service.


the patient is moved to the Surgical Day module. Similar to the elective patients queues,

this queue is ordered based on one of the three ordering criteria as inputted in I: Urgent

Patient Scheduling Rules.

If a patient has been waiting on the urgent patient waiting list for too long, and is

close to reaching the maximum time he can wait for surgery based on his priority and

maximum allowed wait time as indicated in I: Wait List Expiry Information - urgent

(table C.1), the process waited too long will take the patient off the list and into the

Schedule Immediately.

Patients who enter the Schedule Immediately process will be scheduled into the next

available OR, with consideration of the preferences indicated in I: Urgent Patient Schedul-

ing Rules. When the patient is scheduled, he will move to the Surgical Day Module to

wait for his procedure. Patients scheduled by this process do not require a bed resource

check as it is assumed that the patient must have surgery immediately, and the hospital

will find a bed as he can not wait any longer.

Inpatient Management Sub-module

As mentioned previously, inpatients are patients who have already been admitted but

are not part of the emergent/urgent patient group. Since they are already in the hospital

using resources, hospitals do not lump them with elective patients who wait at home.

Inpatients are also unique because unlike urgent patients, they have already been assigned

a surgeon, thus can not be treated as an urgent patient, whose surgeon is unassigned.

When an inpatient enters the Inpatient Management sub-module, he is placed on

the Inpatient Waiting List queue. This queue is ordered based on the same choices

for criteria as urgent patients and is inputted in I: Inpatient Patient Scheduling Rules

(table C.9). Normally, the inpatient waits here until the Determine next OR Activity

Algorithm schedules him. However, if the patient has not been scheduled within the

allowable maximum wait time for the patient, the patient will be moved to the Move


Inatient Waiting

List

Waited too long

Inpatient Management Sub-module


Move to

Appropriate

Queue

framework Aug 24 2009.vsd Inpatient Queue Management


Figure C.6: The inpatient management sub-module.

to Appropriate Queue process. This process will route the patient to either the Urgent

Patient Management sub-module, or to the Elective Patient Management sub-module,

as indicated in I: Inpatient Scheduling Rules (table C.9). If the patient is moved to the

Urgent Patient Management sub-module, he will be placed as an urgent patient with the

least urgent level, and will wait to be scheduled by any surgeon. If, on the other hand,

the patient is moved to the Elective Patient Management sub-module, he will be placed

at the front of his assigned surgeon’s queue, so that he will be scheduled the next time

the surgeon is given elective OR time.

Table C.9: I: Inpatient Scheduling Rules

Inpatient waiting list ordering preference

(choose from FIFO, Strict Prioirty or By

Deadline)

When waited too long, move to Urgent or

Elective queue?


C.5 The Surgical Day Processes

Day of surgery processes include all activities that occur on the day of surgery, from

arrival into the perioperative area transfers to a hospital bed, home, or some other level

of care. This includes any day-of decisions such as cancellation decisions, use of overtime,

etc.

C.5.1 Surgical Day Module

This module follows patients through their surgical day, and is represented in figure C.7.

The module tracks patients through the day of surgery processes, specifically their flow

through the OR. It does not however, follow in detail the patient flow through the various

waiting and preparation rooms, such as the same day surgery area, anaesthesia room,

and registration. The module makes decisions, as needed, such as cancelling due to bed

availabilities or use of OR overtime, urgent patient scheduling, etc.

Surgical Day Module

OR LOS

Determine

Next OR

Activity

OR Activities

Called by OR OR ActivitiesWait until called

Hold Until

Route Clear

Determine First

actual route

Route Cleared –

Proceed to Post-

surgical module

Cancel

Patient

framework Aug 24 2009.vsd Surgical Day


Figure C.7: The surgical day module.

Any patient scheduled for their procedure on the current day, whether elective, urgent

or inpatient, will wait in the wait until called queue. When called, the patient will move

into another queue, Called by OR, where he will wait until the OR is cleared and ready

to accept the patient.


Surgical Activities

The patient enters the OR when it is ready to accept the next patient. Within the OR

Activities sub-module, the first process is the procedure, for the inputted length of time

from M: Current Patient File[OR LOS]. Once the procedure is completed, Determine

Next OR Activity Algorithm determines what to do next in the OR and call the next

patient to proceed. The details of this decision are described later in section C.10.1.Surgical Day Module

OR LOS

Determine

Next OR

Activity

OR Activities

Called by OR OR ActivitiesWait until called

Hold Until

Route Clear

Determine First

actual route

Route Cleared –

Proceed to Post-

surgical module

Cancel

Patient

framework Aug 24 2009.vsd Surgical Day


Figure C.8: The OR Activities sub-module.

The model then determines in Determine first actual route if the first location of the

route is clear for the patient to proceed based on their post-operative route (M: Current

Patient File[Post Surgical Route]).

If the patient is to go to the PACU, where LOS is less than a day, but no bed is

currently available, the model determines how long until the first PACU bed should

become available. If the wait for a PACU bed is less than the allowable wait inputted in

I: Allowable wait for PACU bed (table C.13), the patient will block the OR until the bed

is available.

If the patient is to go directly to an inpatient bed (ICU, SDU, ward) the model will

check if an on service bed is available. If so the patient can be routed immediately. IF

the on service bed is not available, the model will find an available off-service bed based

on the off-servicing rules (I: Off-servicing Rules table C.14). Since the model does bed

checks at midnight, and cancels any scheduled cases if an on or off service bed will not be

available, there should be a bed available for each patient who undergoes surgery. The

only exception is urgent and emergent patients with high priority who must be done that


day in order to meet the maximum wait time set. If no bed is available on or off service,

these patients will use a “flex bed”. These beds can be thought of as those beds the

hospital must find for the emergent patient, whether it is off-serviced to a non-surgical

bed, or the hospital opens another bed over budget (planned).

If the bed and nursing resources are available in the off-servicing unit, the model ad-

justs the actual route choice to go to the PACU. The model will also note that the patient

is to have a different nurse-to-patient ratio based on the inputted information found in I:

Off-Servicing Nurse Ratios (table C.10). When the bed and the nurse resources are both

available, the patient will leave the OR. If a patient is to be off-serviced, the off-service

bed must become available before the on-service bed, otherwise the patient should go to

the on-service bed.

Table C.10: I: Off-Servicing Nurse Ratios

Sent to:

Where supposed to be: Resource 1 . . .

Resource 1 -

. . . -

-

The Route Clear - proceed to post-surgical module process routes the patient to the

post-surgery module, updates the patient’s data file to mark the actual location he will

be going (M: Current Patient File[router]), and marks the step in recovery route to zero

(M: Current Patient File[step #]).

The process then turns over the OR, before accepting the next patient, or closing for

the day. As a simplifying assumption, the turnover time is dependent only on the patient’s

service as described in I: Turnover Time (table C.11). Actual turnover can depend on

many factors including the preceding and following procedures, the availability of cleaning


staff and the timeliness of the patient and surgical staff. Due to the tactical purpose of

this framework, this simplification was found acceptable based on the validation of the

models created for this study.

Table C.11: I: Turnover Times

Service # Turnover Time (in minutes)

1

2

. . .

# services

C.6 Post Surgical Processes

After completing their procedure patients will enter the post-surgical modules for any

post-surgical recovery, i.e. PACU, ward, ICU stays.

C.6.1 Post-surgery Module

The post-surgery module is designed using a flexible flow pattern to allow for the various

routes that a patient can take through his post-surgical recovery, as shown in figure C.9.

When a patient enters the router - by route and step # process, the router will increase

the step number in M: Current Patient File[step #] by one to indicate that the patient

is entering into the next step of his post-surgery route. The router will then route the

patient to the appropriate area. To note, the patient will only ever enter this router if

the location he is to go to is free. The patient will never wait at the router for the bed

to become available.


Router – by

lbl_route and

step#

PACU LOSHold Until

Route Clear

ICU LOS

SDU LOS

Ward LOS

SDS LOS

Discharge

Determine

Next Location

Determine

Next Location

Determine

Next Location

Determine

Next Location

Determine

Next Location

framework Aug 24 2009.vsd Post-Op Activities


Figure C.9: The post-surgery module.


In terms of the framework construction, the recovery areas are all organised in a sim-

ilar fashion. The first process is the medically necessary length of stay for that patient,

which is read from the patient’s information (M: Current Patient File). Medically nec-

essary length of time refers to the recovery time that is required medically, excluding

any delays due to downstream resource availability, etc. When the LOS has elapsed, the

model then determines the next location based on the patient’s route and the current

step within the route (M: Current Patient File[Post Surgical Route] and [step #]). This

process is organised as a decision tree to determine where to send the patient next, based

on bed availability and off servicing rules. These decisions are represented by the diagram

in figure C.10.

First, the decision tree determines what the next step should be based on the patient’s

recovery route (M: Current Patient File[Post Surgical Route]), his current step in that

route (M: Current Patient File[step #], see table C.7 on page 226) and his next assigned

location (I: Post OR Routes, table C.12). The decision tree then determines if there is

a bed available in that area for the patient. If there is, the patient will be routed there

immediately through the router.

For patients requiring a PACU bed, if a bed is not available, the model then determines

when the next available bed becomes available. If the bed will become available within

the allowable amount of time (I: Allowable Wait For PACU, see table C.13), the patient

will still be routed next to the PACU, but will wait in his current location (likely the

OR) until the bed becomes available.

If an on-service bed is not available, the model will then determine if it can off-

service the patient to another area. This is done by systematically looking at the bed

availability in the areas where the patient is allowed to be off-serviced (I: Off-Servicing

Rules, as shown in table C.14), beginning with the most preferred. If a bed is found in

one of these areas, the patient will to go to that area. If no suitable bed is found, the

model will keep the patient where he is and try again to move him to his next destination


Determine where

supposed to go

next

Is a bed

available

there?

Route patient to

go immediately

Determine when a

bed will be

available

Will there be a bed

available within time

allowed?

Route patient, but

hold until clear

Off service check

i = 1

Bed available in ith

preferred location?Route patient here

Will it be available

within allowed wait?

Route patient

here, but hold until

clear

Increment i

i !!"!#$$%&'(!%))!

*'+,-.'!#+'#*

Hold for 24 hours

and try again

Yes

No

Yes

No

Yes

No

Yes

No

No

Yes

Determine Next Location

framework Aug 24 2009.vsd Determine Next Location


Figure C.10: The determine next location decision tree.


Table C.12: I: Post OR Routes

Number of Different Routes

Max number of steps in any route

* Do not specify specific Ward or Step Down Unit or ICU

Route Code Description (for ref) # Steps 1st Step 2nd Step . . .

1 SDH with PACU 3 OR PACU

2 SDA to ward 3 OR PACU Ward

3 SDA ICU-SDU-ward 5 OR PACU ICU SDU Ward

. . .

# of Routes

Table C.13: I: Allowable Wait for PACU

Next location:

Current location Resource 1 . . .

Resource 1 -

. . . -

-


the following day. This is because the model knows that no suitable bed will become

available that day, so the patient must try tomorrow, when the next day’s discharges are

accounted for.

Table C.14: I: Off-servicing Rule

Send to:

Where supposed to be: Resource 1 . . .

Resource 1 -

. . . -

-

Determining the Patient’s Length of Stay

When a patient enters a ward, ICU or SDU bed, the framework determines his medically

necessary length of stay (LOS) based on his inputted time, his route information and the

inputted discharge information. The framework makes a simplifying assumption when

determining LOS: patients will have a LOS that will discharge him from his current unit

at midnight on the day of his inputted LOS (M: Current Patient File).

This simplification is done for a number of reasons. For transferring patients, the

framework uses midnight in order to give priority for beds to patients already admitted

over incoming surgical patients. This simplifying assumption does pose a minor limitation

as some delay results may be underestimated by patients who don’t have to wait for the

bed as the patient preceding him was already transferred at midnight. Due to this

simplification, transfer delays are not considered within the outputs. Additionally, the

model assumes that the LOS of patients in ICU, SDU and ward should be a multiple

of days. The least amount of time a patient spends will be until midnight the day he

entered. I.e. if a patient enters the ICU after surgery at 10AM, a one day LOs will


discharge him 14 hours later at midnight. If the patient has a two day LOS, he will

discharge the next day at midnight, after 38 hours.

As for discharging patients, there are many factors affecting their actual discharge

time, including the hospital’s discharge policy, the timeliness of the patient’s pickup

(whether family or a service), the timeliness of the surgeon’s rounds, the timeliness and

availability of hospital staff, etc. Since the objective of this decision support tool is

for tactical decisions, and not the day of decision around how to juggle incoming and

discharging patients, this assumption is acceptable.

Within the wards, the inputted LOS can also include the patient’s LOS waiting for

alternative care, which is due to external, post-acute wait for resources within the surgical

resources. This wait time should be included in the patients ward LOS value.

C.7 Hospital Resources

The framework allows for a number of resources to be included in the perioperative

patient flow:

• Operating Rooms

• Bed Resources

– Post-Operative Care Units (PACU) beds

– Intensive Care Unit (ICU) beds

– Ward Beds

– Step Down Unit (SDU) beds

– Flex beds

• Equipment


For each of these resources, a number of input values are required to populate the

model. For each resource type, this chapter will cover what information the framework

requires, and how the framework uses the data.

C.7.1 The Operating Room Resource

Depending on the size and organisation of the hospital, there may be a single set of

ORs (such as JH and MSH) or multiple units (such as the main and ambulatory ORs

at SMH). However, as a simplification, the model assumes only one OR unit that can

have any number of OR rooms. The number of rooms is indicated in I: Resources to

Model [Operating Rooms], table C.15.

For example, SMH would indicate in I: Resources to Model [Operating Rooms] that

they run 22 OR rooms, to account for their 16 main ORs and six ambulatory ORs. JH

would indicate that they run eight ORs.

C.7.2 Bed Resources

For each type of bed resource (ICU, SDU, ward) considered by the framework, the user

can specify the number of units and the number of beds in that unit. The number of

units is inputted into I: Resources to Model (table C.15). For each unit the user is able

to specify the number of beds available based on the resource’s shift patterns. They can

also specify if the bed resource is affected by the type of patient that is occupying it.

The model is also able to consider the fact that there are non-surgical patients who may

also occupy the same bed resources. These three aspects of bed resources are described

in detail in the following sections.

For PACU, the same simplification as the ORs is made to simplify the flow from

the OR to the PACU, thus only a single PACU unit is modelled. In I: Resources to

Model[PACU] indicates whether to model a PACU or not (if no PACU LOS data is

available, then there is no need to model the PACU). The number of bed available by


Table C.15: I: Resources to Model

Resource Name Number of OR Rooms

Operating

Rooms

Resource Name Number of PACU Beds

PACU

Resource Name

Number of Units to model

(not number of beds)

ICU

Ward

Step Down

Units

Regional Block

Units

Flex Beds


shift is considered in I:Resource PACU-weekday/weekend as explained in the following

section.

Resource Availability Affected by Time

The PACU is most often scheduled to be open and staffed only during specific times of

the day. However, it may have the option of running past its operating hours in special

circumstances using on-call staff. The framework allows for this change of availability

through the use of shift-based resources. The user can stipulate up to four different

shift-associated times (I: Resource PACU - weekday/weekend, table C.16). in order to

accommodate different shifts on the weekends versus the weekdays, the user can specify

weekday and weekend resource shifts.

1. First shifts - their regular, fully operational/staffed times.

2. Second shift - if a second shift is used with a different resource level than the regular

shift.

3. Third shift - if a third shift is required to reflect another change in the resource

level.

4. Forth shift - if for some period of time, the resource is only available on an on-call

basis.

The PACU can change its resource level up to three times each day. For instance, the

PACU on weekdays, runs at full capacity of ten beds from 8 AM to 5 PM, then two beds

remain available until midnight for urgent cases. After midnight no beds are available.

This configuration would use the first shift to indicate that from midnight to 8AM, there

are no beds available. The second shift indicates the operating hours of 8AM to 5PM of

the fully operational time with ten beds available. From 5 PM to midnight, only 2 beds

would be available using the third shift.


Table C.16: I: Resource PACU - weekday/weekend

Shift Details PACU

First Shift Start time (HH:MM)

End Time

Number available

Second Shift Start time (HH:MM)

End Time

Number available

Third Shift Start time (HH:MM)

End Time

Number available

On-call Shift Start time (HH:MM)

End Time

Number available

Table C.17: I: PACU on call flag - weekday/weekend

Table C.18: I: Bed Resources

Number of Beds Unit 1 . . . Unit n

On weekdays

On weekends


In some hospitals the PACU is not open 24 hours a day, however, if a patient still

waiting in the PACU for a downstream bed, the PACU will remain staffed until that

patient can be moved to the next location. A specialised marker is used here so that the

model knows that it is not normally available. The model can then access the results

from this resource to measure the use of overtime of the resource. For example, for the

same PACU example as above, if during the first and third shift, when it is closed, the

PACU will actually remain open if required, the on-call shift marker would be used in

I: PACU on call flag - weekday/weekend (table C.17), to indicate that from 12 AM to 8

AM, on-call staff is available if required.

To simplify resource checks for longer stay units, the framework assumes that ward,

ICU, and SDU units (i.e. those with stays f one or more days) only change the number of

resources available on weekdays and weekends, and cannot change mid-week or mid-day.

The capacity of each of these units is indicated in the table I: Bed Resources (table C.18.

Resource Availability Affected by Type of Patient

In some cases the type of patient occupying a bed will affect the resource availability in

terms of nurses. For example, patients who require more critical care require a smaller

nurse-to-patient ratio than less critical patients. This often occurs when a patient is

staying in a unit not usually meant to care for his type. A common example is when a

patient requiring an ICU bed is held in the PACU until an ICU bed becomes available.

In this example, the patient requires a ratio of 1:1 vs. a PACU patient who requires

1:2. This ICU patient would require a fully dedicated PACU nurse, leaving one PACU

bed, that the nurse would normally care for her second patient, open during his stay. To

reflect this nurse level change, the framework allows for patients to dictate how many

resources they require in the location they are being off-serviced to, through the inputted

table I: Off-Servicing Nurse Ratios (table C.10). This is only required when a patient

is off-serviced, as the model assumes that the patient requires only one nurse resource


(some fraction of a nurse) in the area where he is meant to go. For example, if the PACU

usually uses a 1:2 ratio, the PACU nurse resource would represent half a nurse. When

an ICU patient is in a PACU bed, it would require two half nurses in order to meet his

care ratio of 1:1.

Non-surgical (medical) Patients

Units are often shared between medical and surgical patients, or in times of bed shortages,

medical patients who usually belong in another ward will be off-serviced into a surgical

patient ward. Additionally, there are patients who are admitted under a surgeon, often

for diagnosis likely requiring surgery, who never end up having surgery. These patients

are often referred to as “non-surgical surgical” patients.

In order to accurately reflect the number of available beds in wards, SDU and ICU,

the model must account for these non-surgical (medical) patients. Since the number

of these patients occupying surgical beds can vary day to day, with seasonality effects,

etc., the model tries to emulate some of this variability without explicitly modelling these

patients. To do this, the model creates the number of non-surgical patients to occupy beds

on a daily basis, based on inputted monthly average occupancy rates of these patients

by ward, SDU and ICU assuming a normal distribution (I: Non-surgical Patient Bed

Occupancy, table C.19). These non-surgical patients are modelled to occupy the bed

until midnight the following night, when a new set is created (for more information on

the timing of creating non-surgical patients, see section C.8). Thus, the model does not

have to attempt to predict arrival rates and length of stays of non-surgical patients, but

can still show the effect of them on the availability of surgical beds.


Table C.19: I: Non-surgical Patient Bed Occupancy - Ward/SDU/ICU

Average number of non-

surgical patients.

Month #

Resource 1 (Jan.) . . . 12 (Dec.)

1

. . .

Resource n

C.8 Start of the Day Module

The Start of the Day module serves to update various data files. These processes are set

to occur every day at midnight, and perform a variety of tasks ranging from determining

the day’s schedule, the number of beds available in each ward, SDU and ICU, etc. This

is done through the following series of steps:

1. Generate the OR schedule - assigns services and surgeons based on schedule related

inputs.

2. Schedule patients.

3. Bed Management:

(a) Discharge patients.

(b) Perform any inter-unit transfers.

(c) Generate day’s non-surgical patients.

(d) Count number of beds available in each area.

(e) Generate day’s urgent patients.

(f) Perform bed resource checks.


C.8.1 Step 1: Generate the OR schedule

Based on the schedule information given, and the current day in the simulation run, the

model will assign the day’s services and surgeons to the ORs. For details on the creation

of the schedule, see section C.9 on scheduling.

C.8.2 Step 2: Schedule patients

Here, the scheduling algorithm is performed to schedule the day’s patients as per the

inputted scheduling rules. Please refer to the section on scheduling for further details,

section C.9.

C.8.3 Step 3: Bed Management

Step 3.1: Discharge all patients who are discharging today

The time element discharges patients from the wards, SDU and ICU. Recall that any

surgical patient scheduled to be discharged from the hospital today will discharge at

midnight. This is a simplifying assumption as patients actually discharge during the day,

after physician rounds, and other formalities. However, since this model is not concerned

with the day-to-day operational decisions of patients moving in and out of beds at specific

times, the framework model clears these patients at midnight so that the bed is available

when needed.

Step 3.2: Perform any inter-unit transfers

The model then allows any inter-unit transfers to occur, i.e. from ICU to SDU bed, ICU

to ward, etc. If there is no bed available in the destination resource area, the framework

will try to off-service the patient to another area, as per the off-service information.

However, on-service patients will get priority over beds, so the off-service decision will

be done after all on-service transfers are complete. If there is no on- or off-service bed


available, the patient will have to wait in the area where he currently holds a bed until

the next day at midnight.

Any patients who are off services in the PACU will also be transferred to an on-service

bed if available to complete their stay. Patients who were off-serviced to any other unit

will remain off-service for the duration of that step in their route.

Step 3.3: Generate day’s medical patients

Next, the model generates a new set of non-surgical patients to occupy some of the beds

for the day, in each bed resource area. There is a chance that there will be no beds

available for some of these patients, as the number generated may exceed the number of

beds available. In this case, the patient will be removed from the model.

Step 3.4: Count number of beds available in each area

The model counts the number of beds that are available for new patients to occupy in

each ward, ICU and SDU unit. The model stores this information in M: Beds Available

Today [# Available Start] (see table C.21 on page 253). This is the number of beds

available for the day for all incoming surgical patients.

Step 3.5: Generate day’s urgent patients

This step will first generate, according to the inputted distribution information I: Urgent

Patient Arrival Information (table C.20), the number of urgent patients of service, based

on a Poisson arrival process. For each generated patient, the model will also randomly

choose their characteristics from I: Patient Input File - Urgent (table C.2 on page 220,

which lists the same information as did I: Patient Input File - elective/Inpatient for

elective and inpatients. However, the I: Patient Input File - urgent also includes a column

indicating the arrival time of the patient, i.e. the time of the day that the decision to

perform surgery was made.


Table C.20: I: Urgent Patient Arrival Information

Service # Arrival Rate (# per day)

1

2

. . .

# services

For any urgent patient created, or already waiting, who requires surgery within 24

hours and requires a post-surgical bed, the framework will increment the count of these

patients arriving to the on-service bed area in M: Beds Available Today [# Incoming -

Urgent]. Urgent patients that can wait more than one day for surgery will be accounted

for bed-wise once scheduled, when the model knows which day the surgery will occur.

All urgent patients are then placed in the Urgent Patient Wait Until Arrival queue in

the Pre-Surgical module, where they will wait until their decision to perform surgery

has been made, at which time they will proceed through the Pre-Surgical module to be

scheduled.

Step 3.6: Perform bed resource checks

The model now determines which available beds to assign to which incoming patients

using the following steps:

• Assign beds (on or off-service) to all urgent patients who are arriving today with an

urgency that requires surgery within 24 hours. Also, include any urgent patients

who arrived previously who are still waiting to be scheduled, that have waited

enough time, based on their urgency, that they now must have surgery today.

Additionally, include any urgent patients who are scheduled for surgery today.


• Assign beds (on or off service) to all scheduled inpatients.

• If there are not enough beds for the above urgent and inpatients, their cases will

not be cancelled, but rather a “flex bed” will be used.

• For each unit, if there are enough beds remaining for all the incoming on-service

electives, assign accordingly.

• For units that have more incoming elective patients than beds, assign the available

beds to the patients based on their scheduled start time.

• Assign any remaining incoming elective patients to any remaining beds, maintaining

off-servicing rules.

• Any incoming elective patient who did not have a bed assigned, will be cancelled

due to no bed.

Table C.21: M: Beds Available Today - Ward/ICU/SDU

Resource # available # in-

coming -

Urgent

# in-

coming -

inpatient

# in-

coming -

elective

Resource 1

. . .

Resource n

C.9 Scheduling Details

This section focuses on the scheduling aspects of the model. It includes the set up of

the schedule based on a number of input files, as well as the scheduling algorithms for


elective, urgent and inpatients.

C.9.1 Schedule Inputs

The schedule inputs can be considered as two sets of input files. The first set details

the actual schedule, such as service and surgeon assignments and OR availabilities. The

second set of input files describe the various scheduling rules that need to be considered.

Schedule Details

There are five input files that together describe the actual OR schedule, each of which

will be described below.

• Schedule - Details

• Schedule - Function

• Schedule - Service

• Schedule - Surgeons

• Schedule - Surgeon # ORs

This first input file describes a number of scheduling input parameters for the model

(I: Schedule - Details, table C.22.

• Schedule length: The number of days in the inputted schedule (i.e. if a schedule is

on a two week rotation, thus is the same every other week, it would be 14 days).

• Min/Max Scheduling Rules used: To indicate whether there are any min/max rules

to be used while scheduling. More details to come in the scheduling rules section

below.


• Scheduling Preferences: The user is to rank in order of preference what to do with

any remaining elective time that is not booked by the surgeon. Further details are

given below in the section on the elective scheduling algorithm.

Table C.22: I: Scheduling Details - various input parameters about scheduling.

Schedule length (including weekends) in days

Combination scheduling? (0 = No, 1 = Yes)

Scheduling Preferences -

Rank the following five options in order of preference:

Open unscheduled elective time to other surgeon’s

within the service

Open unscheduled elective time to other services

Open unscheduled elective time to inpatient scheduling

Open unscheduled elective time to urgent patient

scheduling

Close the OR to further scheduling

The next two input files allow the user to enter the rotating OR schedule in terms of

its function and service. Both files are laid out for every OR for every day of the schedule

length. For each day, in each OR, the user enters the function and service assigned in

30 minute time intervals. The I: Schedule - Function (table C.23) allows the hospital to

assign time in the ORs as one of the following:

• Elective - time allocated for elective patient scheduling.

• Urgent - time allocated to scheduling urgent patients. This time can be scheduled

prior to the day of.


• Emergent - time allocated to urgent and emergent patients that is only to be

scheduled on the day of, based on the urgent and emergent list.

• On-call - similar to emergent, except it is only staffed if required to complete

urgent/emergent patients in a timely manner, using on-call staff.

• Closed - if the OR is to be closed to any patient scheduling.

Table C.23: I: Schedule - Function and Service

Day and OR

Day 1 Day 2 . . . Day n

OR 1 OR 2 . . . OR n OR 1 . . . OR n

00:00 On Call

00:30 On Call

01:00 On Call

. . .

08:00 Elective

08:30 Elective

. . .

17:00:00 Emergent

. . .

23:30:00 Emergent

The service input schedule (I: Schedule - service, table C.24) allows the user to assign

specific services to the ORs. The user can either specify a service to a time block, or keep

it unassigned. If left unassigned, this indicates that no preference is given to a particular

service for the use of the OR during that time. This is only appropriate when the OR’s


function is not elective. The framework assumes that during an elective block, only one

service is assigned, i.e. an OR block is not split between two services on the same day.

Table C.24: I: Schedule - Service

Day and OR


OR 1 OR 2 . . . OR n OR 1 . . . OR n

00:00 0

00:30 0

01:00 0

. . .

08:00 ORTH

08:30 ORTH

. . .

17:00:00 ORTH

. . .

23:30:00 ORTH

As an example, the two tables shown here stipulate that on day 1 of the schedule OR

1 is assigned as follows:

• From midnight to 8 a.m. the OR is on-call for all patients.

• From 8 a.m. to 5 p.m., the OR is for orthopaedic elective patient scheduling.

• From 5 p.m. to midnight, the OR is open for emergent cases of the orthopaedic

service.

There are two input files for the OR schedule in the surgeon’s schedule (I: Schedule

- Surgeons and I: Schedule - Surgeons # ORs, see tables C.25 and C.26 respectively).


Surgeon assignment is often done by each service, and depends on the preferences of the

surgeons, holidays, time off, surgeon-patient load, etc. In order to simulate this assign-

ment, the framework assigns surgeons to OR time according to the inputted probability

of a surgeon being assigned on a particular day in a particular OR (I: Schedule - Sur-

geons). If a particular surgeon is always assigned a specific day and OR, then the user

simply gives that surgeon a probability of one for that day and OR.

The framework determines a day’s surgeon assignment by selecting a surgeon for each

OR, based on these inputted probabilities. The framework assumes that surgeons are

only assigned elective time. The other functions are not assigned for a specific surgeon’s

list, but rather a surgeon is assigned to perform any cases required during that time. For

example, during an Urgent assigned slot, the surgeon will perform any cases assigned to

the OR within his specialty during that time.

Some hospitals schedule more than one surgeon during an elective block of time in

the same OR. Thus, the normal eight to ten hour elective block is split between two

surgeons. To allow for this, the input sheet is composed of two probability assignment

matrices. One for the first assignment, and the other for the second. The second matrix

will have a zero for any surgeon-OR-day combination where a second surgeon is not to

be assigned. Probabilities greater than zero are assigned to any combination where a

second surgeon has a chance of being assigned as the second surgeon on the same day in

the same OR. The framework assumes that a split OR is split into two blocks of equal

time, i.e. a morning and an afternoon block, each with a single surgeon assigned.

The final surgeon scheduling input is to accommodate hospitals that allow surgeons

to run two operating rooms at the same time. This is sometimes used to increase the

utilisation of the surgeon as it decreases his downtime between surgeries, and also gives

more time for his interns to perform part or all of some procedures.

The framework assumes that the surgeons schedule ORs independently, instead of

staggering such that the ORs do not have the actual procedure for both patients at the


Table C.25: I: Schedule - Surgeons

First Slot

Day and OR


OR 1 OR 2 . . . OR n OR 1 . . . OR n

Surgeon 1 0

Surgeon 2 0 0.5 0.2

. . . 0.7

Surgeon n 0.3 0.2

Second Slot

Day and OR


OR 1 OR 2 . . . OR n OR 1 . . . OR n

Surgeon 1 0

Surgeon 2 0 0 0 0.6 0/8

. . . 0.7

Surgeon n 0 0

Table C.26: I: Schedule - Surgeons # ORs


Surgeon 1 1 1 . . . 1

Surgeon 2 1 2 . . . 2

. . . . . . . . . . . . . . .

Surgeon m 2 1 . . . 2


same time. Essentially it assumes a system where the surgeon uses his interns, as opposed

to the possibility of parallel ORs, where the surgeon’s idle time is reduced.

The input file I: Schedule - Surgeons # ORs allows the user to enter for each surgeon,

for each day of the rotating schedule, if he is to run a single or two ORs simultaneously.

When assigning surgeons, the model will ensure that the surgeon is not already scheduled

the maximum number of ORs he may run a day, as inputted in I: Schedule - Surgeons #

ORs (table C.26). Further, if a surgeon is assigned a half block in one OR, this counts

as one OR, thus a surgeon restricted to one OR a day, will not be assigned two half day

blocks in two different ORs. The surgeon can however be scheduled in the morning and

afternoon slot of the same OR if the surgeon assignment probability allows.

When the framework creates the schedule, it uses these four files to build each day.

The framework uses a set of intermediate files to build the schedule information and to

schedule procedures. Each intermediate file a contains scheduling information for the

current day. The current schedule’s assigned functions, by time are maintained in M:

Schedule - Function (table C.27), which may be updated after the elective scheduling

process. For example, after the scheduling algorithm has scheduled the day’s elective

patients, the intermediate file will adjust that day’s function to reflect the fact that the

time can no longer be used for elective patient scheduling or to close the OR.

There is also an intermediate file used to track the current day’s service and surgeon

assignments (M: Schedule - Service and M: Schedule - Surgeon, tables C.28 and C.29

respectfully). Both of these files track for each 30 minute time interval through each OR

the service and surgeon assigned.

Additionally, for the purposes of scheduling patients, an intermediate file is used

to track the amount of time remaining on any particular day in an OR that is still

unscheduled, for elective, and urgent function scheduling (M: Schedule - Time Remaining,

table C.30). As patients are scheduled during an elective or urgent time slot, the model

updates the amount of time remaining that can be scheduled according to the schedule


Table C.27: M: Schedule - Function

OR 1 OR 2 . . . OR n

00:00 On Call

00:30 On Call

01:00 On Call

. . .

08:00 Elective

08:30 Elective

. . .

17:00:00 Emergent

. . .

23:30:00 Emergent

Table C.28: M: Schedule - Service

OR 1 OR 2 . . . OR n

00:00 0

00:30 0

01:00 0

. . .

08:00 ORTH

08:30 ORTH

. . .

17:00:00 ORTH

. . .

23:30:00 ORTH


Table C.29: M: Schedule - Surgeon

OR 1 OR 2 . . . OR n

00:00 0

00:30 0

01:00 0

. . .

08:00 Surgeon 1 Surgeon 16

08:30 Surgeon 1 Surgeon 16

. . .

17:00:00

. . .

23:30:00

M: Schedule - Function.

Table C.30: M: Schedule - Time Remaining

Time Remaining OR 1 OR 2 . . . OR n

Elective

Urgent

The final intermediate file used for scheduling is the list of patients scheduled for each

OR, in order. The file is simply an ordered list of patient IDs for each OR, as seen in M:

Schedule - Patients (table C.31).


Table C.31: M: Schedule - Patients

OR 1 OR 2 . . . OR n

1234 5493 590

5940 5435 657

. . .

C.9.2 Scheduling Rules

The rules involved in scheduling patients varies widely across hospitals. The framework

uses two sets of scheduling rules for elective patients: rules for the types of patients to

be scheduled, and patient ordering rules.

Patient Related Scheduling Rules

These rules are used to allow hospitals to implement rules such as “no more than two

planned elective ICU admissions per day” and “at least three total joint procedures per

orthopaedic OR per day”. These rules are all structured in a similar way, by specifying a

maximum or minimum number of patients by a specified patient classifier. The patient

classifier used for a rule can either be the ICU flag, the Scheduling Rule category, the

anaesthesia type flag or admit/non-admit flag. These rules are inputted into the I:

Scheduling Rules List (table C.32).

The I: Scheduling Rules List table shows an example of each type of rule allowed:

• Rule # 1 states that in an orthopaedic room, at least three total joint replacement

patients must be scheduled.

• Rule # 2 states that across all ORs and services within the elective day, no more

than two planned admissions to the ICU can be scheduled.

• Rule # 3 states that across all the general surgery OR rooms scheduled in the

elective day, only three patients of category type 4, say some scope procedure are


Table C.32: I: Scheduling Rules List

Rule

ID

Rule Scope Service Classifier Classifier

Value

Min

/

Max

Number Relax

(Y/N)?

1 OR ORTH Scheduling rule category 1 Min 3 Y

2 Day N/A ICU Flag planned Max 2 N

3 Service GEN Scheduling rule category 4 Max 3 N

. . .

allowed. This rule should be used for example when there is limited equipment,

such as a scope, and scheduling more than 3 procedures a day for this instrument

would be impossible as there would not be enough time to clean and sterilise it

between procedures.

The framework also allows for different rules to be applied on different days of the

schedule. For each day and OR of the schedule, the user may indicate which set of rules

must be followed, and which set of rules must have at least one obeyed. This is indicated

in I: Scheduling Rules Schedule (table C.33). For example, the table shows that for day

1 of the rotating schedule, in OR 1, rules one and two must be followed. Thus, for this

particular day in this OR, there must be at least three total joints scheduled, as well

across all ORs, no more than two ICU patients can be scheduled. Note that rule two

would need to be included in the first row for all ORs for that day to ensure it is followed.

In OR 2, rules two and three must be followed, meaning that no more than three general

patients of category four can be scheduled across any of the ORs assigned to the general

service that day. As with all ORs for this day, no more than two planned ICU cases can

be scheduled. Additionally, OR 2 has two rules listed in the “must obey at least one of”


row. This row allows for either-or type rules to be set up. For instance, perhaps rule

five states that at at least five cases of category seven must be scheduled, while rule six

states that at least five cases of category six must be scheduled. Thus, for day one of the

schedule in OR 2 either at least five cases of type seven, or five cases of type six must be

scheduled.

Table C.33: I: Scheduling Rules Schedule


OR 1 OR 2 . . . OR n OR 1 . . . OR n

Must obey all of 1, 2 2, 3 2

Must obey at least one of 5, 6

While scheduling elective patients, the framework tracks these rules through the M:

Schedule Rules Tracking sheet as shown in table C.34. Here, each time a patient is going

to be scheduled, the algorithm will refer to the sheet to check if any rules will be helped

or violated based on the patients that have already been scheduled. If a patient scheduled

the algorithm will update this sheet accordingly. More details on how this is taken into

account within the scheduling algorithm to follow in the section C.9.4

Table C.34: M: Schedule Rules Tracking

Rule ID Day Service OR 1 . . . OR n

1

2

3


Patient Ordering Rules

In order to schedule patients according to the ordering preferences of the hospital, the

input file I: Scheduling Ordering (table C.35) is used to rank the following schedule

ordering options:

• Longest procedures first (LPF).

• Shortest procedures first (SPF).

• Admitting patients first.

• Admitting patients last.

• Non-admitting patients first.

• Non-admitting patients last.

• No anaesthesia patients first.

• No anaesthesia patients last.

• Previously cancelled patients first.

• ICU patients first.

• ICU patients last.

The user ranks the above choices in order of importance. Any ordering option not used

by the hospital should be left unranked, indicating to the model that it does not need to

consider that ordering rule. At midnight on the day of, the Start of New Day Element

logic will order the day’s patients according to the inputted ranked order preferences.


Table C.35: I: Scheduling Ordering

Ordering Method Rank

Longest procedures first (LPF).

Shortest procedures first (SPF).

Admitting patients first.

Admitting patients last.

Non-admitting patients first.

Non-admitting patients last.

No anaesthesia patients first.

No anaesthesia patients last.

Previously cancelled patients first.

ICU patients first.

ICU patients last.


C.9.3 Daily Schedule Creation

Within the Start of the Day module, the day’s schedule is generated based on the inputs,

and the various intermediate files are updated accordingly. This is done by the four steps,

as described below.

1. Update the variables for tracking the day of the week, and what day within the

inputted schedule. As an example, if the inputted schedule is two weeks long, the

day within the inputted schedule is the day of the two week cycle that we are

currently on, expressed as a number between one and 14.

2. Read in the day’s function and service schedules from the input files (I: Schedule

- Function and I: Schedule - Service) into the respective intermediate files, M:

Schedule - Function and Schedule - Service.

3. Generate the surgeon assignments for the day’s elective slots based on the proba-

bility of a surgeon being assigned to a specific OR on that day, as inputted in I:

Schedule - Surgeon. Allow for a surgeon running multiple ORs if indicated in I:

Schedule - Surgeon # ORs. Mark the assigned surgeons as appropriate into the

intermediate file M: Schedule - Surgeon.

4. Update the other intermediate files as appropriate, M: Schedule - Time Remaining,

and M: Schedule Rules Tracking.

C.9.4 Elective Patient Scheduling Algorithm

For each OR assigned elective time today, the Elective Patient Scheduling Algorithm will

attempt to schedule elective patients from the assigned waiting list using the following

algorithm. When the chosen wait list organisation is by surgeon, patients are scheduled

into OR time assigned to that surgeon. When organised by service, patients are scheduled

into OR time assigned to the service, regardless of the surgeon assigned. Whenever a


patient is booked during this algorithm, the M: Schedule - Patients, M: Schedule - Time

Remaining, and M: Schedule - Rule Tracker are updated appropriately.

Step 1: Schedule any inpatients who are at the front of the elective wait-

ing list : This step will schedule, regardless of rules, any inpatients who are at the front

of an elective waiting list. This is done because inpatients are only placed at the front of

the queue if they are to be scheduled in the surgeon’s/service’s elective time.

Step 2: Schedule patients who fulfil at least one of the minimum rules :

This step will search through the surgeon’s/service’s elective waiting list in an attempt to

find patients to schedule within the remaining elective time available that will contribute

to meeting at least one of the “minimum” scheduling rules required. The algorithm will

only schedule a patient whose booking time (I: Current Patient File[Booking Time])

fits within the remaining elective time, as tracked in M: Schedule - Time Remaining.

Additionally, the algorithm will only schedule a patient at this stage if he has at least

one characteristic of one of the inputted scheduling rules that are “minimum” rules. The

patient must not break any of the “maximum” rules.

Step 3: Schedule patients, without breaking any of the maximum rules :

This time algorithm will schedule any patient whose booking time fits within the remain-

ing unscheduled time, and does not break any of the “maximum” rules.

Step 4: Schedule patients, relaxing allowed rules : In this step, the algorithm

searches a final time through the surgeon’s/service’s elective waiting list to schedule

patients into the remaining unscheduled time. This time however, the algorithm will

allow some rules to be broken, if they have been flagged as relaxable, i.e. I: Schedule -

Rules [Relax (Y/N)?] is set to “Y”.

Step 5: Order patients according to inputted ordering rules : Now that the

surgeon’s/service’s elective list has been set for the day, the patients are ordered based

on the inputted ordering preference as indicated in I: Scheduling Ordering (table C.35).

When an OR is split between two surgeons, each surgeon’s list is ordered as per the rules,


independent of the other.

Step 6: Schedule elective patients from other surgeons, services, and

urgent and inpatients as per inputted preferences: This final step attempts to fill

any remaining unscheduled time at the end of the elective day according to the inputted

preferences in I: Schedule - Details (table C.22). Here, any “maximum” rules that are

not allowed to be relaxed must be upheld for patients to be scheduled. These cases will

be performed in the order booked after the end of the assigned surgeon’s elective list.

When an OR is shared by two surgeons, additional patients are scheduled at the end of

the day into unbooked time, after both surgeons have completed their scheduled lists.

Step 7: Cancel elective patients due to non-modelled reasons : Some pa-

tients are cancelled on the day of surgery because they are not cleared medically, do not

show up, etc. that is out of the control of the framework model. This type of cancel-

lation will be referred to “non-modelled” or “other” reason within the context of this

framework. The final step of the algorithm determines if any scheduled patient is to be

cancelled due to a non-modelled reason. See section C.10.2 for more details on this type

of cancellation.

Patients that are flagged as cancelled are routed to the Cancelled Patient Management

sub-module, where their status is updated, and they are returned to the appropriate

waiting list as per the rules indicated in I: Wait List Rules (table C.3 on page 221).

C.10 Additional Framework Details

C.10.1 Determine next OR Activity Decision Tree

When a procedure in the OR is close to completion, a number of decisions are made

by the hospital staff concerning the operating room. They must determine, based on

the amount of regular time remaining, whether to continue with the elective schedule,

perform an urgent case, or to close the OR. The following decision tree represents the


generalised decision making process to determine what should occur after the current

procedure is complete (figure C.11).

Is there a next

case waiting?Yes

No

Can it be completed with

less than X Overtime?

Call Patient to OR

HoldingYes

Cancel

Patient – due

to OT

No

Check

Additional List

Determine Next OR Activity

framework Aug 24 2009.vsd Closeup and reversal


Figure C.11: The Determine Next Activity Process.

First, the model checks if there is another patient scheduled for that operating room

(which includes the elective patients of the day and any urgent or inpatients who have

been scheduled). If there is a patient scheduled, the model determines if there is enough

time remaining in the scheduled time for his booked procedure length. The model de-

termines the estimated time for completion of that next case based on the current time,

the turnover time, and the booked length of the waiting case less turnover time. If the

case would require to run past the scheduled current function’s end time, the amount

of overtime required must be less than the inputted overtime decision in I: Overtime

Allowance (table C.36) based on the patient’s type and priority.

If the model determines that the patient passes the overtime rule, the process moves

the patient from the Wait until called queue to the called by OR queue. If the model


Table C.36: I: Overtime Allowance - Elective/Urgent/Inpatient

Priority level

Service 1 . . . Priority

level n

1

. . .

Service n

determines that the patient must be cancelled due to not enough time, the process

moves the patient into the Cancel Patient process to be cancelled and returned to the

appropriate waiting list. The process will then start this decision tree again to see if

another patient can be completed.

If there is no patient currently waiting for that OR, the model will then enter the check

additional list sub-module, to determine if there is an unscheduled urgent or inpatient

who can be done.

Check Additional List Algorithm

This algorithm determines if there is an urgent or inpatient waiting who is eligible to be

scheduled in the current operating room. If it is during elective time, the algorithm will

first search through the Inpatient Waiting List for a patient to be scheduled. Preference

is given to a patient who is of the same surgeon, then same service, then any service. In

order to be scheduled, the patient must also fit within the allowed overtime amount as

inputted.

If no inpatient is found, or the OR is currently assigned as an Urgent or Emergent

OR, the algorithm will search the Urgent Patient Waiting List. Here, preference is given

to a patient who is of the same service first. The patient selected must also meet the


maximum overtime allowance.

If the patient being scheduled is of an urgency level where he can wait more than 24

hours to be scheduled, a check for bed availability of any post-operative admitting bed

must be performed prior to scheduling the patient. If a bed is not available, the patient

can not be scheduled.

C.10.2 Further Information about Cancellations

Cancel for other reasons

There are many reasons why a patient can be cancelled on the day of surgery. Some

of these reasons are within the control of the model, such as no bed available, out of

regular time, more urgent patient, etc. However, there are a number of reasons that are

not specifically controlled by the model, such as patient no show, incomplete test results,

etc. To account for these types of reasons, the model will randomly select patients to

be cancelled for “other” reasons, based on an inputted service-specific probability of this

occurring (I: Other Cancellations, table C.37). Patients that are cancelled for an “other”

reason are routed through the cancel patient process (see section C.10.2 for details on

this process).

Cancelled Patient Process

This section describes the processes that occur in the cancelled patient sub-module.

First, the patient information is updated to reflect that he has been cancelled. This

is done by increasing the number of times the patient has been cancelled by one in M:

Current Patient File[# times Cancelled]. Similarly, the cancellation report data file is

also updated for this patient’s cancellation, by reason (O: Cancellation Report).

The model then routes that patient to the appropriate wait list to be rescheduled.

If the patient is an elective patient, he will return to his surgeon’s wait list. His place


Table C.37: I: Other Cancellations - Elective/Inpatient/Urgent

Percentage of patients

who cancel due to other

reasons

Priority level

Service ID 1 . . . priority n

1

. . .

Service n

in the wait list is determined based on the inputted rules in I: Wait List Rules [Priority

When Returning] (table C.3 on page 221).

On the other hand, if the patient is an inpatient, the patient will be placed on the

least urgent wait list, as this patient already has a bed, and needs to be cleared as soon

as possible. Urgent patients are returned to the urgent queue using the same ordering

rules as when they first entered, with consideration for how long the patient has already

waited.

This sub-module then conducts administrative tasks to update the files, specifically

removing the patient from the current day’s schedule (M: Schedule - Patients) so that

the patient is not chosen later as the next patient in the schedule.

Since these cancellations occur on the day of, the hospital does not have a chance to

adjust the elective schedule. Thus no new elective patients can be added on such short

notice.


C.11 Framework Output Files

This section will go over the various output files that are used by the framework to track

andreport and a number of measures of interest for perioperative services. For each file,

an explanation of it’s purpose and its updating procedures will be covered. The output

files are:

• Wait list Report

• Cancellation Report

• OR Reports

– OR Utilisation

– Over and under time

– Delays

• PACU Report

• Ward Report

• ICU Report

• SDU Report

• Throughput Report

• Census Report

Additionally, there are also a number of other measures that a hospital may be in-

terested in that the framework assumes can be collected through automatic functions

within the simulation model. These measures include:

• Queue Statistics - including average size, average wait, etc. for urgent and emergent

patients only.


• Bed Resource Utilisation - including average number of patients in each area.

C.11.1 Wait List Report

The M: Wait List Tracking (table C.38 tracks all patients waiting list details. For each

patient, the file records as they enter the wait list, their service, patient type and service-

based category type, and the time entered. When a patient successfully begins his pro-

cedure, the file is updated to reflect the time he has left the waiting list and the number

of times he was cancelled before surgery.

Table C.38: M: Wait List Tracking

Patient

ID

Service

ID

Patient

Type

Category

ID

Surgeon

ID

Time

entered

list

Time

left

list

#

times

Can-

celled

. . . . . . . . . . . . . . . . . . . . . . . .

At the end of the simulation, the framework then aggregates the data from the M:

Wait List Tracking table and summarises the waiting information by service, patient

type, category and surgeon. The O: Wait List Report (table C.39) gives the following

output measures:

• Average time patients spent on the waiting list.

• Average time patients currently on the waiting list have waited.

• Average number of patients on the list.

• Average number of times patients are cancelled before receiving surgery.

The M: Wait List Tracking can also be analysed to find the maximum, minimum and

percentiles of the various measurers stated.


Table C.39: O: Wait List Report

Service

ID

Patient

Type

Category

ID

Surgeon

ID

Ave

Wait-

ing

time

Current

Ave

waiting

time

Ave.

size

Ave.

times

can-

celled

1 1 1 1

1 1 1 1

. . . . . . . . . . . .

C.11.2 Cancellation Report

The O: Cancellation Report (table C.40) tracks the cancellation statistics. Each time a

patient is cancelled, this output report is updated accordingly. It tracks by service and

patient type, the number of cancellations that occur for the following reasons:

• Cancelled due to no available ICU bed.

• Cancelled due to no available Ward bed.

• Cancelled due to no available SDU bed.

• Cancelled due to no available ward resource.

• Cancelled due to OR overtime.

• Cancelled due to being bumped for a more urgent case.

• Cancelled due to an “other” reason.


Table C.40: O: Cancellation Report

Reason

Service

ID

Patient

Type

# No

ICU

# No

Ward

# No

SDU

# No

Re-

source

# Over-

time

#

Bumped

for more

Urgent

# Other

1 1 1

1 1 1

. . .

C.11.3 OR Reports

There are a number of reports to track the various key measures around the OR. The

first report tracks the utilisation of the various time designations (elective, urgent, on-call,

emergent, and closed). At the completion of each surgery, the O: OR Report - Utilisation

(table C.41) report is updated to reflect the time used for that procedure during the

assigned OR function, based on I: Schedule - Function from table C.23. Additionally,

the time assigned for each service is updated at the start of each day to be used as the

denominator of the utilisation calculation. At the end of the simulation run, a utilisation

ratio can be calculated and reported. Turnover time is not considered in the utilisation

calculation. If a procedure spanned across more than one assigned OR function, the

utilisation will be divide accordingly to the different assigned functions.

The O: OR Report -Over and Under Time (table C.42) tracks for each OR and as-

signed function the amount of time and the number of times it experiences either overtime

(runs past the assigned end time of the function) or under-time (the last procedure of the

function is completed before the end of the assigned time). If at the end of a procedure,


Table C.41: O: OR Report - Utilisation

OR

ID

Elective

Time

Used

Elective

Given

Urgent

Time

Used

Urgent

Time

Given

OnCall

Time

Used

OnCall

Time

Given

Emergent

Time

Used

Emergent

Time

Given

Close

Time

Used

Close

Time

Given

1

1

. . .

OR

n

the case ran past the assigned function the amount of overage is updated in the report.

If at the end of a procedure, there are no more cases to follow, the amount of under time

is calculated and entered in to the report. At the end of the simulation run, the average

over- and under-time for each OR and each function can be computed.

Each time a patient is held in the OR past their procedure LOS, the information is

recorded in the O: OR Delay Report (table C.43). At the end of the simulation, the

average delay time can be reported.

C.11.4 PACU Report

For each PACU unit, O: PACU Report (table C.44) tracks the number of patients who

used the PACU, as well as the length of time they spent in the PACU. The report also

tracks the number and length of stay of any patients that are off-serviced to the PACU.

The number of patients delayed in the PACU waiting past their LOS to transfer to

another area is also recorded along with the amount of time they were delayed. At the

end of the simulation run, the average LOS, average off-service LOS and average delay


Table C.42: O: OR Report -Over and Under Time

OR ID OR function # times in OT Total OT time # times in UT Total UT Time

1 Elective

1 Urgent

. . .

2 Elective

. . .

OR n Closed

Table C.43: O: OR Delay Report

OR Unit # Patients de-

layed waiting in

OR

Total Delay

Time

1

2

. . .


time are reported.

Table C.44: O: PACU Report

PACU

Unit

# Patients Total LOS # off-

service

Total Off-

service

LOS

# Delayed Total De-

lay Time

1

2

. . .

The O: PACU Report - Diverts (table C.45) file tracks in more detail the number of

times there is a patient diverted from another area into the PACU. The report records

each time a patient who is supposed to go to either an ICU, ward or SDU bed is diverted

into the PACU because no bed is available when needed.

Table C.45: O: PACU Report - Diverts

PACU

Unit

Total #

Off-service

# ICU Di-

verts

# Ward

Diverts

# SDU Di-

verts

1

2

. . .

C.11.5 Ward, ICU and SDU Reports

Similar to the O: PACU Report, the O: Ward/ICU/SDU Report (table C.46) tracks

the LOS of patients in the wards/SDU/ICU units, including off-serviced and delayed


patients.

Table C.46: O: Ward/ICU/SDU Report

Ward

Unit

# Pa-

tients

Total

LOS

Total

Off-

service

LOS

Total

ALC

LOS

# De-

layed

Total

Delay

Time

Total

# Off-

service

1

2

. . .

C.11.6 Throughput Report

The O: Throughput Report, as shown in table C.47, counts the number of completed

cased by service, patient type, category and surgeon. The report is updated each time a

patient leaves the system after post-surgical recovery.

Table C.47: O: Throughput Report

Service ID Patient Type Category Surgeon ID Throughput

1 1 1 1

1 2 1 1

. . .

C.11.7 Census Report

Daily unit census is calculated based on the O: Census Report. At midnight each day,

this report counts the number of patients in each unit (ICU, SDU, ward). The census


count is done prior to patients being discharged or transferred. The template of this

report is presented in C.48.

Table C.48: O: Census Report

Unit ID Sunday Monday Tuesday Wednesday Thursday Friday Saturday

ICU 1

ICU 2

. . .

ICU n

SDU 1

. . .

SDU n

Ward 1

. . .

Ward n

Appendix D

Generic Model Implemented in

Simul8

D.1 Screen Shots of the Generic Model Implemented

in Simul8

284

Appendix D. Generic Model Implemented in Simul8 285

Figure D.1: Screen shot of generic model in Simul8.


Figure D.2: Screen shot of generic model in Simul8 - focused in on arrival processes and

waiting lists.

Figure D.3: Screen shot of generic model in Simul8 - focused in on post-surgical units

(ICU, SDU, ward and flex beds)


Figure D.4: Screen shot of generic model in Simul8 - focused in on operative day processes.

Appendix E

Juravinski Process Map

!"#$#%&'()*+&)#

,)-'&)#./0#'-#1+&2)&0#

Decision to

perform surgery Wait for day

of surgery

Schedule Patient

- OR +pre_Op

Wait for pre-

op Clinic

Appt

Wait to be

schedule Pre-Op Clinic

Wait for

surgery

Decision to

perform surgery Enter Hospital

Wait for

surgery

Decision to

perform surgery

Already Admitted

to Hospital

./0#'-#1+&2)&0#

Patient Reports

to Same Day

desk

Patient Registers

at Admitting SDS Waiting

area Enter SDS room Wait in SDS

until called SDS activities

Called to OR

holding

OR Holidng

activites

Wait in OR

Holding until

called

Called to OR

holding

OR Holidng

activites

Wait in OR

Holding until

called

Called to OR

holding

OR Holidng

activites

Wait in OR

Holding until

called

%&'()*)#3456#(/7)#

Figure E.1: The pre surgical patient flow at Juravinski.

288

Appendix E. Juravinski Process Map 289

!"#$%&'()*+

OR Booking

Office:

- inputs info

Surgeon selects

date and sends

request to

Booking office

Check resource

availability (staff,

rooms,

equipment)

Make Change

and confer with

surgeon

No

Pre-OP Clinic Booking

Office:

- schedules pre-op visit

(1 -4 wks prior)

Yes

Notify ICU Need ICU bed? Yes

If patient

cancelled due to

bed shortage (2

times for ICU or

1 time for ward)

then try to book

as first case of

day

No

,-./01+"23435+

Surgery confirmed Pre-Op Clinic :

ready for

surgery?

Return to Surgeon's

Office for further consult

No

Yes

PRE_OP VISIT

Patient Reports

to Pre-Op Desk

Nurse gets info,

height, weight,

bloodwork

Anaesthesia

consult (if

necessary)

Internal consult (if

necessary) Figure E.2: The scheduling details at Juravinski.

!"#$%&'()*+

OR Booking

Office:

- inputs info

Surgeon selects

date and sends

request to

Booking office

Check resource

availability (staff,

rooms,

equipment)

Make Change

and confer with

surgeon

No

Pre-OP Clinic Booking

Office:

- schedules pre-op visit

(1 -4 wks prior)

Yes

Notify ICU Need ICU bed? Yes

If patient

cancelled due to

bed shortage (2

times for ICU or

1 time for ward)

then try to book

as first case of

day

No

,-./01+"23435+

Surgery confirmed Pre-Op Clinic :

ready for

surgery?

Return to Surgeon's

Office for further consult

No

Yes

PRE_OP VISIT

Patient Reports

to Pre-Op Desk

Nurse gets info,

height, weight,

bloodwork

Anaesthesia

consult (if

necessary)

Internal consult (if

necessary)

Figure E.3: The pre-op clinic details at Juravinski.

!"#$#%&'()*+&)#

,)-'&)#./0#'-#1+&2)&0#

Decision to

perform surgery Wait for day

of surgery

Schedule Patient

- OR +pre_Op

Wait for pre-

op Clinic

Appt

Wait to be

schedule Pre-Op Clinic

Wait for

surgery

Decision to

perform surgery Enter Hospital

Wait for

surgery

Decision to

perform surgery

Already Admitted

to Hospital

./0#'-#1+&2)&0#

Patient Reports

to Same Day

desk

Patient Registers

at Admitting SDS Waiting

area Enter SDS room Wait in SDS

until called SDS activities

Called to OR

holding

OR Holidng

activites

Wait in OR

Holding until

called

Called to OR

holding

OR Holidng

activites

Wait in OR

Holding until

called

Called to OR

holding

OR Holidng

activites

Wait in OR

Holding until

called

%&'()*)#3456#(/7)#

Figure E.4: The surgical day patient flow at Juravinski.


!"#$%&'()*#"%%+#,-./(.01#232#"%%+#,-./(.01#

30-('0#(4#56%-0'#7(89#-:10#;#(<0<#601%=6-0#-90->#

Yes

Ward bed

available (if

required)?

If cancelled due to bed

shortage 2 times prior

(ICU) or 1 time prior

(Inpatient), procede?

Cancel and re-

book

Yes

No

Wait until next Bed

meeting to re-

evaluate.

HOLD

First case of

day?

No

ICU bed

available (if

required)?

No

Yes

Yes

Procede with case

Nurse checks

chart, NPO,

alergies

Patient brought to

holding room

Final meeting with

surgeon and

anaesthesiologist

Surgeon IDs site

and side of surgery,

marks limb Figure E.5: The decision tree on whether to proceed with a case, at Juravinski.

!"#$#%&'('))#*+,#,'(-)-.+)#

Emergency

Elective

Enter OR

7 (8) Patient Prep and Anaesthesia

Close up and

reversal of

aneasthesia

Surgery

Room

Changeover

Call to Prep

patient

Patient taken to

OR - by nurse

Is there

enough time

to complete?

Add surgery to

next day's

additional list

Is there a

procedure

following? List re-

evaluation.

Yes

Yes

No No

Is there a procedure on

the additional or

emergency lsits that can

be performed? Yes

OR closed for day

No

Emergency or

Elective Status?

Run OR

into OT?

Cancel

Yes

No

Can

procedure

can wait?

No Yes

Figure E.6: The patient flow and decisions made during the procedure at Juravinski.


!"#$%&'%'()"*(+,%

Admit to ward

bed

Discharge

Block OR until

bed ready

ICU or PACU

or SDS?

Go to PACU bed (13

bays)

ICU bed

ready?

PACU bed

ready?

Can they stay in

PACU until

ready?

PACU stay

Is ward bed

ready?

Wait in PACU/

ICU until ready

Return to

Sameday

surgery Room

Go to ICU

bed ICU stay

Goto PACU bed

until ICU bed

ready

Inpatient

Outpatient

Yes

No

Yes PACU

Yes

No ICU

No

Yes

No

Block OR until

PACU/ICU

bed ready

Ward stay

Go to SDS room (??)

SDS

SDS stay

If telemetry is

required, is it

available?

Yes

No

Figure E.7: The post surgical patient flow at Juravinski.

Appendix F

St. Mike’s Process Map

Decision to

Perform Surgery

Surgeon – Set

Surgical date

Schedule PAF

(1 to 35 days prior

to surgery date)

Wait for PAF PAF visitPAF – ready

for Surgery?

Return to Surgeon

for cosult

No

Elective

Wait

Schedule with

Booking

office (min 7

days prior)

Urgent (P1-A/B/CWait to be

scheduled

Wait for

scheduled time

Yes

Urgent P1-D and Inpatients

Wait to be

booked by

booking office

Scheduled by

booking office

Wait for

scheduled time

Wait for

scheduled time

OR Desk to

Schedule

Urgent Pt

St. Michael's Hospital pre surgical

Thursday, June 11, 2009 1 of 7

Figure F.1: The pre surgical patient flow at St. Mike’s.

292

Appendix F. St. Mike’s Process Map 293

Booking Office - Elective

Receive request

Resources

avaialble (staff,

equipment, rooms)

Make change and

confer with

surgeon

Surgery confirmedYes

No

OR Desk – Urgent 1A,B,C Scheduling

1- If P1-C: try to book into next day’s Scheduled Urgent room if possible.

2- Try to schedule in unscheduled urgent OR if time and resources permitted.

3- Bump into scheduled list. If P1A, into first OR avaiable, but preference to service

given if possible.

4- can book into overnight if need to based on urgency (P1-A/B only)

Booking Office – Urgent 1D/Inpatients

1- Attempt ot book into unused/released scheduled time of service, or any OR.

2- P1-C, attempt to schedule into next day’s scheduled urgent room.

3- Send patient ot service to schedule within scheduled time by adjusting schedule.

St. Michael's Hospital Booking Office


Figure F.2: The elective patient scheduling process map at St. Mike’s.


Receive request

Resources

avaialble (staff,

equipment, rooms)

Make change and

confer with

surgeon


No





given if possible.








Figure F.3: The inpatient patient scheduling process map at St. Mike’s.



Receive request

Resources

avaialble (staff,

equipment, rooms)

Make change and

confer with

surgeon


No





given if possible.








Figure F.4: The urgent patient scheduling process map at St. Mike’s.

Elective Patients

Morning of

Surgical Day

- Decisions

Patient Arrives

Register at

Surgical Desk

Amb Pod (20)

FDS Pod (13)

Nurse ActivitiesWait to be

called

Final Check and

Anaesthetist visit

Amb OR

Activities

Nurse ActivitiesWait to be

called

Pre-Op Room

(6 stretchers + 8

chairs)

Pre-Op

Assessments

Wait to be

called to OR

CORE OR

Activities

Wait for

Regional Block

procedure

Regional Block

Procedure

Wait to be

called by OR

Reg’l block

admisnistered

within time limit?

CORE OR

Activities

Cancel (rare)

No

Yes

St. Michael's Hospital Day of -elective


Figure F.5: The surgical day process map at St. Mike’s.


Scheduled ICU or

Ward – is there a bed

available?

Continue with

ProcedureYes

Are the patients

who can be

discharged?

No

Discharge PtYes

Cancel or

Delay?

Cancel – return

booking office to

schedule for next

day

Cancel

Hold Pt.

Check next pt

Delay

Try again

No

First Pt of day?Require Ward

bed?Yes Yes

Continue whether

bed avaialble or

not.

No

St. Michael's Hospital Morning of Decisions


Figure F.6: The decisions made the morning of surgery at St. Mike’s.

Pt Prep

Anaesthesia

induction (If

required)

Procedure

Close patient and

initial post-

anaesthesia

Hold Pt until

route clear

Patient moves to

next stage

Determine

next OR

activity

Turnover

St. Michael's Hospital OR Activities


Figure F.7: The process map within the OR at St. Mike’s.


Is there another

procedure

waiting?

EnterIs there enough

time to complete?Yes

Check Additional and

Emerg List for a patient

No

Can the

procedure

wait?

NoElective or

UrgentYes

Return to

additional listUrgent/inpt

Cancel – return to

surgeon wait list

Elective

Call patient

Yes

Run OR into

OT?

No No

Yes

Yes

Close OR

No

Return to start with

next in line

St. Michael's Hospital Determine Next OR Activity


Figure F.8: The decision tree to determine the next OR activity at St. Mike’s.

ICU, PACU or

Pod?

PACU bed

avialable?PACU PACU stayYes

Hold in OR

until bed

avialable

No

ICU

ICU bed

available?

No

Can the patient

stay in PACU until

ICU is ready?

Hold in OR

until bed

avialable

No

ICU StayYes

Wait in PACU

(1:1 Nurse

Ratio)

Yes

Pod Stay (Amb or

CORE)Pod

outpatient

Ward bed

ready?Admitted

Discharge

Wait in current

bed

No

Ward StayYes

St. Michael's Hospital Post-Op Activiites


Figure F.9: The post-surgical day patient flow at St. Mike’s.

Appendix G

Mt. Sinai Process Map

297

Appendix G. Mt. Sinai Process Map 298

!"#$%&#'(%%('

()*+%,&

-)*+%,&'

.%#%*/$&%('

()*+%*0'*%1)$*%.

-)*+%,&'

.%#%*/$&%('2"(%'

#03%'45-6

!"#$%&#'"**$7%('8,*'

!9:'"33#;

9((%((/%&#'.,&%<('<=:>-5:'

?%.'*%1)$*%.@A%(

B,

B,#$80'CD'

?,,E$&+('"&.'

()*+%,&F(',88$2%',8'

2G"&+%

!"#$%&#'+,%('#,'

!9=:'G,H.$&+'

"*%"

!"#$%&#F('2G"*#'$&8,'

*%7$%I%.'?0'&)*(%

!9=:'&)*(%'

2G%2E('3"#$%&#'$&

9*%'#G%*%'"&0'

$(()%(@

B,

A%(

JG%&'CD'*%".0K'

3"#$%&#'?*,)+G#'

$&#,'CD'?0'CD'

&)*(%

B)*(%'2"HH('

()*+%,&>"&%(;

B)*(%'.,%('8$&"H'

2G%2E(

9&"%(;'5,%('

$&.)2#$,&

9&"%(;'2)%('

()*+%,&

-)*+%,&'?%+$&('

()*+%*0K'$&2$($,&'

/".%

-)*+%*0'$('

2,/3H%#%K'$&2$($,&'

2H,(%.

!"#$%&#'*%7$7%.

!"#$%&#'#"E%&'#,'

!9=:'"&.'

*%2,7%*%.

A%(!"#$%&#'.$(2G"*+%.'

L,/%

5-'M NO;PN;PQ

-%%'-59'8H,I

5,%('*%2,7%*0'

+,'I%HH@

="&'3*,?H%/'

?%'8$R%.@A%(

-)*+%*0'

*%(2G%.)H%.

B,

!*,?H%/'8$R%.

!"#$%&#'"./$##%.

B,

-)*+%*0'(2G%.)H%.

!9:'"33#;'

(2G%.)H%.'I$#G$&'O'

/,&#G',8'()*+%*0

!"#$%&#'I"$#('8,*'

3*,2;'."#%

5"0',8'3*,2;'

!"#$%&#'*%+$(#%*('$&'

"./$##$&+

Figure G.1: The process flow map for DS patients at Mt. Sinai.


!"#$%&#'(%%('

()*+%,&

-)*+%,&'

.%#%*/$&%('

()*+%*0'*%1)$*%.

-)*+%,&'

.%#%*/$&%('2"(%'

#03%'4-567

-)*+%*0'(28%.)9%.

!6:'"33#;'

(28%.)9%.'<$#8$&'='

/,&#8',>'()*+%*0

!"#$%&#'"./$##%.'#,'

)&$#?@%.'4=ABC'

==B7

6*%'#8%*%'"&0'

$(()%(D

E,

F%(

G8%&'3*%2%.$&+'

()*+%*0'@%$&+'

29,(%.')3C'HI'

&,#$>$%(')&$#

-%*J$2%'"(($(#"&#'

,*'8,)(%K%%3$&+'

+,%('#,'2,99%2#'

!"#$%&#

!"#$%&#'#"K%&'#,'

HI'

6&"%(;'L%+$&('

$&.)2#$,&

6&"%(;'2)%('

()*+%,&

5,%('3"#$%&#'

&%%.'MN:'@%.D

E,

6&%(;'6&.'HI'

E)*(%',*'3,*#%*'

#*"&(3,*#('3"#$%&#'

#,'MN:

!"#$%&#'*%2,J%*(

F%(

E,

!"#$%&#'

#*"&(3,*#%.'#,'

!6N:'"&.'

*%2,J%*%.

-)*+%,&'@%+$&('

()*+%*0C'$&2$($,&'

/".%

-)*+%*0'$('

2,/39%#%C'$&2$($,&'

29,(%.

!"#$%&#'<,K%&')3

!"#$%&#'#"K%&'#,'

!6N:'"&.'

*%2,J%*.

F%(

5,%('3"#$%&#'

&%%.'-5:'

@%.D

!"#$%&#'#*"&(>%**%.'

#,'G"*.

!"#$%&#'

#*"&(3,*#%.'#,'

-5:

!"#$%&#'.$(28"*+%.'

<8%&'*%".0

-56'O P=;QP;QR

!"#$%&#'@*,)+8#'#,'

S#8'>9,,*'3*%T,3'

<"$#$&+'*,,/',*'

8,9.$&+'"*%"

HI'&)*(%'"&.'

"&%(;'.,'3*%T,3'

28%2K

5"0',>'()*+%*0C'

3"#$%&#'"./$##%.'

M('@%.'

"J"$9"@9%DE,

F%(

5,%('3"#$%&#'

&%%.'-5:D

E,

F%(

M('@%.'*%".0D

F%(E,

N"&'3*,@9%/'

@%'>$U%.D

!*,@9%/'>$U%.;

F%(

E)*(%'2"99('

()*+%,&?"&%(;I%(28%.)9%. E,

!"#$%&#'8"('!6:'

"33#;

-)*+$2"9'#%"/'

&,#$>$%.

N"&'"'@%.'@%'

/".%'*%".0D

-)*+%*0'

*%(28%.)9%.'@0'

()*+%,&

E,

F%(

N"&'!6N:'

#"K%'3"#$%&#D

E,

F%(

Figure G.2: The process flow map for SDA patients at Mt. Sinai.


!"#$%&#'(%%('

()*+%,&

-)*+%,&'

.%#%*/$&%('

()*+%*0'*%1)$*%.

-)*+%,&'

.%#%*/$&%('2"(%'

#03%'4522)#%6

-)*+%*0'(27%.)8%.!"#$%&#'"**$9%(':,*'

!5;'"33#<

=('"&'=>;?-#%3@

.,A&'B%.'*%1)$*%.'

3,(#',3C

D%(

E,

E,#$:0'()*+%,&F('

,::$2%'"&.'GH'

B,,I$&+(

J"0',:'"./$(($,&K'

3"#$%&#'"./$##%.'#,'

)&$#?B%.'4LMNK'

LLN6

=&3"#$%&#'O PL<QP<QR

E)*(%'"&.'

"&%(#7%#$(#'.,%('

3*%@,3'27%2I

5*%'#7%*%'"&0'

$(()%(C

E,

D%(

-%*9$2%'"(($(#"&#'

+,%('#,'2,88%2#'

!"#$%&#

!"#$%&#'#"I%&'#,'

GH'

5&"%(<'S%+$&('

$&.)2#$,&

5&"%(<'2)%('

()*+%,&

J,%('3"#$%&#'

&%%.'=>;'B%.C

E,

5&%(<'5&.'GH'

E)*(%',*'3,*#%*'

#*"&(3,*#('3"#$%&#'

#,'=>;

!"#$%&#'*%2,9%*(

D%(

E,

!"#$%&#'

#*"&(3,*#%.'#,'

!5>;'"&.'

*%2,9%*%.

-)*+%,&'B%+$&('

()*+%*0K'$&2$($,&'

/".%

-)*+%*0'$('

2,/38%#%K'$&2$($,&'

28,(%.

!"#$%&#'A,I%&')3

!"#$%&#'#"I%&'#,'

!5>;'"&.'

*%2,9%*.

D%(

J,%('3"#$%&#'

&%%.'-J;'

B%.C

!"#$%&#'#*"&(:%**%.'

#,'T"*.

!"#$%&#'

#*"&(3,*#%.'#,'

-J;

!"#$%&#'.$(27"*+%.'

A7%&'*%".0

!"#$%&#'B*,)+7#'#,'

U#7':8,,*'3*%@,3'

A"$#$&+'*,,/',*'

7,8.$&+'"*%"

GH'&)*(%'"&.'

"&%(<'.,'3*%@,3'

27%2I

J,%('3"#$%&#'

&%%.'-J;C

E,

D%(

=('B%.'*%".0C

D%(E,

>"&'3*,B8%/'

B%':$V%.C

!*,B8%/':$V%.<

D%(

E)*(%'2"88('

()*+%,&?"&%(<

H%(27%.)8%.

E,

T7%&'3*%2%.$&+'

()*+%*0'B%$&+'

28,(%.')3K'GH'

&,#$:$%(')&$#

Figure G.3: The process flow map for inpatients at Mt. Sinai.


!"#$%&#'$('

")*$##%)+',-'$('

&.#$/$%)

!"#$%&#'"00$1%('$&'

2*%03

40%'#5%0%'"&6'

$((7%(8

9.

:%(

;5%&',-'0%")6+'

<"#$%&#'=0.735#'

$&#.',-'=6',-'

&70(%

970(%'>"??('

(703%.&@"&%(A

970(%').%('/$&"?'

>5%>B(

4&"%(A'C.%('

$&)7>#$.&

4&"%(A'>7%('

(703%.&

D703%.&'=%3$&('

(703%06+'$&>$($.&'

*")%

D703%06'$('

>.*<?%#%+'$&>$($.&'

>?.(%)

!"#$%&#'0%1$1%)

:%( !"#$%&#')$(>5"03%)C.%('0%>.1%06'

3.'E%??8

F"&'<0.=?%*'

=%'/$G%)8

:%(

D703%06'

<.(#<.&%)

9.

!0.=?%*'/$G%)

!"#$%&#'")*$##%) 9.

H('=%)'

0%I7$0%)8:%(

9.

H('=%)'

"1"$?"=?%8

:%(

9.

4((%((*%&#').&%

2*%03%&>6'J KLAMNAMO

C.%('<"#$%&#'

0%I7$0%'

(703%068

!"#$%&#'#0%"#%)'$&'

2*%03

9.

:%(

!"#$%&#'E"$#('/.0'

=%)'#.'/0%%'7<

H('(703%06'

0%I7$0%)'E$#5$&'

K'5.70(8

:%(

9.

!"#$%&#P('

%*%03%&>6'?%1%?'

)%#%0*$&%)'Q!R'4'

J'!R'CS'

!"#$%&#'#0"&(/%00%)'

#.'=%)'$&'"1"$?"=?%'

&70($&3'7&$#

!"#$%&#'E"$#('/.0'

(703%06'QE"$#'#$*%'

)%<%&)('.&'!R'

?%1%?S

C.%('<"#$%&#'

&%%)'HFT'=%)8

4&%(A'4&)',-'

970(%'.0'<.0#%0'

#0"&(<.0#('<"#$%&#'

#.'HFT

!"#$%&#'0%>.1%0(

:%(

!"#$%&#'

#0"&(<.0#%)'#.'

!4FT'"&)'

0%>.1%0%)

!"#$%&#'#"B%&'#.'

!4FT'"&)'

0%>.1%0)

C.%('<"#$%&#'

&%%)'DCT'

=%)8

!"#$%&#'

#0"&(<.0#%)'#.'

DCT

C.%('<"#$%&#'

&%%)'DCT8

:%( H('=%)'0%")68 :%(

9.

9.

:%(

9.!"#"$%&'(&)*+,"-+&./"01"-23

)4&56&%701"03&0"87,0"9&,-&:&;<

)4&=6&%701"03&0"87,0"9&,-&;>?<

)4&@6&%701"03&0"87,0"9&?>A?<

)4&B6&%701"03&0"87,0"9&,-&;>C&9*3%

!"#$%&#'$('

")*$##%)+',-'$('

&.#$/$%)

Figure G.4: The process flow map for urgent patients at Mt. Sinai.

Appendix H

William Osler Process Map

302

Appendix H. William Osler Process Map 303

!"#$%&#'()%#*+','(-#,./#-)%&#'0".1

!"#$%&#','

2#$343.*'+.'

/#-5.-6

'47-8#-9'

:7-8#.*'

:$;#<7"#4'

:7-8#.*':#*<4'

=..>3*8'+.'?@'

A..>3*8'?B$#'

A..>3*8'?B$#'

<#+#-6

3*4-#4.7-$#4'

)&)3")=3"#C')*<'5."".14'

=..>3*8'-7"#4'

@#+7-*'+.'

47-8#.*D4'

.B$#'+.'=#'

-#4$;#<7"#<'

A..>3*8'

E//-.&#<'

:$;#<7"#'(-#,

E<63443.*'F343+'

G)3+'7*%"'(-#,

E<63443.*'

F343+'

(-#,

E<63443.*'

F343+'

G)3+'7*%"'

=..>#<'

/-.$#<7-#'

<)+#'

2)9'=#5.-#'4$;#<7"#<'$)4#'

G3""'+;#-#'"3>#"9'=#'

#*.78;'=#<4'5.-'

*#H+'<)9D4'$)4#4I'

@#&3#1'$)4#4'

13+;'47-8#.*4'

E-#'+;#-#'

/)%#*+4'1;.'

$)*'=#'2J'

5-.6'7*3+I'

E-#'+;#-#'$)4#4+;)+'$)*'

=#'6

)<#'2)9':7-8#-9''

3*4+#<'.5')<63K#<I'L.-'

1)-<'&4'MJNC'.-'1)-<'&4O'

:?NP'

J)*$#"'$)4#L4P'

)4'*##<#<'

Q.'13+;'

4$;#<7"#'

@#+7-*'+.'

47-8#.*D4'

.B$#'+.'=#'

-#4$;#<7"#<'

R)>#'$;)*8#4'

+.'/)%#*+L4P'

=..>3*8'

G-3+#'2J'

.-<#-4'

:$;#<7"3*8'!"#$%&#'/)%#*+4'

,'!)$;'47-8#.*'4$;#<7#"4'+;#3-'.1*'/)%#*+4')$$.-<3*8'+.+';#'G

SM:'/-3.-3+9'

"#&"#'83&#*O'

,':7-8#.*4'=..>'13+;3*'+;#3-')"".+#<'%6#'.*'+;#'?@'=".$>'4$;#<7"#'=)4#<'.*'

+;#'=..>#<'%6#'L=)4#<'.*';34+.-3$)"T#H/#-3#*$#P'

?-<#-'.5'$)4#4U'

,'V.*8#-'/-.$#<7-#4'+.'=#'4$;#<7"#<'W-4+'

,'$)4#4'/-#&3.74"9'$)*$#""#<'+.'=#'4$;#<7"#<'W-4+'

,'/-#5#-)="9'=..>'*.*,)<63K#<'/)%#*+4'W-4+'

,'$;3"<-#*'W-4+'X'

,')"#-83#4')*<'$.6/"3$)%.*4','W-4+X'

,'3*5#$%.*'$.*+-."'/)%#*+4','")4+'X'

X'*.+')&)3")="#'3*'6

.<#"'

Figure H.1: The pre-operative process flow map for elective patients at William Osler.


!"#$%#&'()*+#&'(,()$#,-.#$*+/#(01-2

3&.*+#&'(,()$#,-.#$*+/#(01-2

!"#$%#&'()*+#&'(,(

4#5676-&('-(.#$8-$"(

79$%#$:(

;9$%#-&(5*117(

<=(>#7?('-(

*>>('-(167'(

@*6'(9&+1(

;5A#>91#>(

@*6'(9&+1(

;5A#>91#>(

+"#(

;5A#>91#(

#"#$%#&'(

.*+#&'(

3&.*+#&'(,(4#5676-&('-(

.#$8-$"(79$%#$:(

;9$%#-&(5*117(

<=(>#7?('-(*>>(

'-(167'(

@*6'(9&+1(

;5A#>91#>(

@*6'(9&+1(

;5A#>91#>(

+"#(

;5A#>91#(

6&.*+#&'(

;5A#>91#(#"#$%#&'(.*+#&'(

,(38(1#/#1(BC(,(D--?(6&'-(E$7'(*/*6*1D1#($--"(F.$#8#$*D1:(-8('A*'(7#$/65#G(

,(68(1#/#1(BH(,(A-1>(9&+1('A#(#&>(-8('A#(#1#5+/#(>*:I((

,(68(1#/#1(BJ(,(A-1>(9&+1('A#(#&>(-KA#(#1#5+/#(>*:L(5*&(2*6'(9&+1(&#M'(>*:(68(&-'(

#&-9%A(+"#(

,(68(1#/#1(B4(,(75A#>91#(6&'-('-(<=(+"#(>#76%&*'#>(*7('$*9"*($--"(

,(<&(2##?#&>7(,(*11(#"#$%#&'(5*7#7(FBC,JG(*$#(D--?#>(D*7#>(-&(9$%#&5:(*&>(

'A#(*"-9&'(-8(+"#($#"*6&6&%(D#8-$#('A#6$('*$%#'I(

;5A#>91#(6&.*+#&'(

,(7A-91>(D#(75A#>91#>(>9$6&%(#1#5+/#(+"#L(68(&-&,#"#$%#&'I(

Figure H.2: The pre-operative process flow map for urgent and inpatients at William

Osler.

!"#$%&'())*+$,'

*%'-"./,0)1$).'

!"#$%&'2"33$4'

&5'67'8"*&'95)'

67'

!"#$%&'$%&$),'

67'!)5:$40)$'

!"#$%&'3$"+$,'

67'8"*&'95)'

;$4'

<,'<2='5)'!(2='

;$4')$"4.>'

<2='?"#$%&,':"%'@"*&'

*%'!(2='95)';$4''*9'%5'

<2=';$4'*,'"+"*3";3$A'

6+$)#B$'2"%:$33"#5%C'

/'<9'$3$:#+$'@",';0B?$4'

;$:"0,$'59'DB$)1$%&':",$'/'45'

%5&':"%:$3'

/'E"+$',&"F%1'0?'&5'G'67,'0%#3'

HIJJ'95)'6K'$3$:#+$'"%4'0)1$%&A'

D3$:#+$',:L$403$C'JMJJ'/'HNOJ'

6KP=)1$%&C''

''''''HNGJ'/''HQJJC'G'67'RSET'OUGV'DSE'

'''''''HQJJ'/'OGJJC'H'67'RSE'

'''''''HQ//'/'OGGJC'H'67'DSE'

6%'2"33'"W$)'L50),''H'67'

8$$X$%4,C'H'67'RSET''H'67'5%:"33'DSE'

Figure H.3: The operative (day of surgery) process flow map for patients at William

Osler.


!"#$%&'(%

)#$%&'(%

('$%&'(%

*+,-%&'(%

(./,0%(0+1%

$230%&'(%

)#$%45-%

+6+37+475%

!+8520%2/0%,5+-1%

0/%9/,%:#%/2%

(+0;,-+1%<.52%

;230%=7/>5>?%

:#%

@/7-%;287%

25A0%45-%

9,55%

BC@D%

%%%%%%C52%(;,E%*+,-%F%GH%

%%%%%%%',0.%(;,E%<+,-%F%GI%

JC@D%

%%%%%%%C52%(;,E%*+,-%F%GK%

%%%%%%%%('$%F%L%

%%%%%%%(./,0%(0+1%%F%MH%

%%%%%%%%%%%%%%%%NOIKIIF(MGIIP%

%%%%%%%',0./%(;,E%<+,-%F%QG%

BC@D%IRQIFGQQID%MI%NSQP%%

%%%%%%%%%%%TGQQI%U<V52->%;W0/%L%

JC@DIKIIFGLIID%MX%NSLP%

%%%%%%%%%%TGLII%U%<V52->%;W0/%L%

BC@D%O+A%M%4//V5-%W5,%-+1%

%%%%%%%%%%MG%)#$%S%H%##$%Y%MK%

JC@D%O+A%G%4//V5-%W5,%-+1%

%%%%%%%%%%GL%)#$%

(+Z5%:+1%&'(%

Figure H.4: The post-operative process flow map for patients at William Osler.

a generic simulation-based perioperative decision support tool for tactical decisions by daphne

Documents