Computer simulation of patient flow through an operating suite

1. Computer simulation of patient flow through an operating suite David E. Clark, MD FACS Department of Surgery, Maine Medical Center, Portland ME Stata Conference 2014

2. The problem • Operating Rooms (ORs) may generate up to 40% of hospital revenue – efficiency is financially important • Delays and rescheduling are frustrating and demoralizing for patients and staff • In extreme cases, patient safety may suffer if vital resources are unavailable due to suboptimal management

3. Model of an operating suite P1 Preop OR1 RR P2 P3 OR2 P4

4. Simulation Software • Special-purpose simulation programs (e.g., Arena, Flexsim, Simulink) take care of “housekeeping” and displays, but may be expensive, restrict flexibility, and be more difficult to learn and debug • General-purpose programming languages (including Stata) easily available, familiar, and flexible, but require the user to construct “housekeeping” and displays

5. Tools available in Stata • Basic structure a matrix with rows (observations) and columns (up to 32,767 variables) • Loops (“forvalues”, “foreach”) • Replication (“expand”, “expandcl”) • Reshaping (“wide”, “long”) • Summarization (“egen”) • Subroutines (“program”, “.do” files) • Time-to-event modeling (“streg”, etc.) • Reporting (“list”, “save”, “append”, “replace”)

6. Available hospital data • Patients: Day, procedure, surgeon, scheduled OR/times (in/out etc.), actual OR/times, destination from OR (RR vs ICU), RR times, etc. • Rooms: Availability for different types of procedures, at different times of day • Policies: Staffing, scheduling, priority rules, “bumping”

7. Data Structure • Must allow for transfer of information between patients and rooms • Must allow for change in status over time • Must allow for replication with different random variables • Must allow for visualization of status, reporting of summary statistics, and modification of structural assumptions

8. Input distributions • Time to event, bounded on (0,∞) • Fit a parametric distribution (many possibilities) • Model covariates using regression • Derive transition probabilities (hazards)

9. Methods: Derive distributions • Patient data in normal (“long”) format • Estimate two-parameter log-logistic distributions for procedure duration, recovery room duration, turnaround time • Parametric time-to-event regression (“streg”) using predicted procedure duration, procedure type, surgeon, following self, first case, add-on case

10. Methods: Initialize patients/rooms • For a given day, convert patient data to “wide” format – that is, all variables are in the same row • Add room data on same row For example, at 0600…

11. Methods: Use replicants to create output distributions • After initialization, “expand” 30 to 3000 • Run program and periodically “egen mvar = mean(var)” “egen sdvar = sd(var)” etc. to accumulate statistics of interest • Display one realization of simulation

12. Methods: Step through entire day at 5-minute intervals • Loop using “forvalues” • Determine patient status at new time t, and whether status should change either deterministically (scheduled or actual) or probabilistically (simulated with random variables). • Update room status depending on which patient is now in room and/or scheduled to be in room

13. Methods: Sequence of procedures at each time step • Identify patients arriving in preop status • Move next priority patient to OR when patient ready and room available • Move OR patient to RR if procedure finished (random number exceeds hazard function at time t); restrict room for “turnaround time” • Move RR patient out of RR if required time complete

14. Example: Patient/room dataAt 0745, 0845, 0945

15. Methods: Periodic adjustments • Determine time remaining for current case in each room, total time remaining to complete all cases, free time remaining • Reprioritize patients scheduled in each room, including new emergency cases • Identify next case scheduled in room with greatest anticipated overtime, and reassign that case to room with greatest anticipated free time

16. Results: Output for a typical day

17. Results • Runtime about 10 minutes to simulate a 24-hour day with 300 replications – not affected much by number of replications • Most time-consuming for computer (and most difficult to code) is reassignment of cases from overbooked rooms • Limited by incomplete data on patient destination after Recovery Room

18. Validation: Cumulative statistics

19. Expand and modify • Started small, now allow for 50-100 patients in 24 rooms • Summarize multiple days with same structure (day of week, block schedule) • Add information about RR destinations • Verify assumptions about OR staffing RR staffing, scheduling policies, etc. • Predict effects of changing staffing/policies

20. Conclusions • Stata has some useful features for simulation and enables a working model • Stata would be even better if commands could reference variable names, e.g., replace st_R7=3 if st_P3=7 • Plan to post improved version of this program on ideas.repec.org • StataCorp and/or developers should take note of “SAS Simulation Studio”