Operating Room Rescheduler
Dept. of CIS - Senior Design 2014-2015
Albert Shu
salbert@seas.upenn.edu
Univ. of Pennsylvania
Philadelphia, PA
ABSTRACT
Many hospitals, including the Pennsylvania Hospital, suf-
fer from inefficiencies in operating room scheduling. Often
times, these inefficiencies arise because it can be difficult for
nurses to manually adjust operating room schedules in re-
sponse to unanticipated events. Our goal was to develop a
software prototype, in the form of a web application, that au-
tomates the operating room rescheduling process. Given an
initial operating room schedule, this software prototype sys-
tematically generates efficient schedule adjustments based on
the current state of a hospitals operating room system. The
schedule adjustments are generated with the goal of minimiz-
ing the length of the surgery day and with the constraint of
avoiding delays in surgery start times. This software pro-
totype serves as a proof of concept that automation of the
operating room rescheduling process is feasible and is worth
pursuing in real hospital systems.
1. INTRODUCTION
1.1 Background
The operating room is often referred to as the heart of
a hospital. It accounts for about 60-70% of hospital ad-
missions, and its operating costs can account for more than
40% of total hospital expenses [1]. In light of these costs
and the operating rooms central role in a hospital, increas-
ing the efficiency of resource utilization and patient flow in
the operating room is crucial. One way this problem can be
addressed is by optimizing operating room scheduling. Op-
erating room scheduling is the assignment of surgical cases
and surgical teams to specific dates and times in the oper-
ating room schedule.
The inefficiencies of operating room scheduling arise from
the unpredictability of resources used in operations, includ-
ing time, space, and personnel [2]. A single operation re-
quires the coordination of a surgeon, an operating room
nurse team to prep the patient and aid the surgeon dur-
ing the surgery, an anesthesia team to administer anesthe-
sia and monitor the patient during the surgery, specialized
equipment to perform the surgery, and the allocation of a
block of time and an operating room for the surgery. A
simple miscalculation or unforeseen complication can lead
to the surgery running longer than expected, delaying all
following surgeries that require resources being used by the
prolonged surgery. The complications that arise from oper-
Advisor: Linh Thi Xuan Phan (linhphan@cis.upenn.edu),
Ari Brooks (ari.brooks@uphs.upenn.edu)
Indu Subbaraj
subbindu@seas.upenn.edu
Univ. of Pennsylvania
Philadelphia, PA
ations running over time or surgeons being delayed on cases
are a huge source of monetary loss for the hospital as well
as inconvenience for surgeons, nurses, and patients. These
inefficiencies in resource utilization and allocation can be im-
proved by optimizing the reshuffling of the operating room
schedule in response to unanticipated events.
The current scheduling approach the majority of hospi-
tals adopt is block scheduling [1]. In this form of schedul-
ing, blocks of time over a time period (anywhere from a
week to a year) are assigned to surgeons or surgical depart-
ments. Surgeons fill their assigned time blocks with their
cases as they see fit. This scheduling approach requires two
steps: (1) the creation of a cyclic timetable, also called a
master surgical schedule (MSS), that determines the time
blocks and assigns them to different surgeons and (2) the
population of the MSS with specific cases [1]. The problem
of operating room scheduling can be broken down into two
segments: production of an initial schedule for a given time
unit (day, week, or month) and generation of altered sched-
ules based on complications or conflicts that require changes
in the initial schedule.
There are several current implementations of the first seg-
ment, generation of an initial operating room schedule, for
hospitals to use. A quick online search of the topic reveals
that there are a significant number of companies that offer
applications to produce operating room schedules. Many of
these focus on providing a GUI that makes manual schedul-
ing, for example by a nurse, easier. The system used at
the Pennsylvania Hospital is a mostly manual form of block
scheduling; surgeons choose which cases they will be per-
forming given blocks of time they can operate in [3].
Most of the implementations that create an initial sched-
ule are not optimized and require tedious work by nurses or
surgeons. Even the applications that claim optimization do
not offer details on their method of optimization. Although
there have been advances in development of theoretical op-
timization algorithms, there remains a need for an efficient
and practical implementation of these algorithms that re-
tains the context of the operating room.
The second segment of operating room scheduling, op-
timally accounting for unexpected changes to produce an
altered schedule, has not yet been successfully addressed in
a clinical setting. There are few, if any, companies that
offer satisfactory software services to address this problem
[3]. It is, however, an immensely important one. Current
hospitals rely on nurses to deal with cancellations or delays
and rearrange the schedule manually. However, the already
busy workload of the nurses and complicated nature of the
task renders manual rescheduling inefficient. This results in
many wasteful gaps in the schedule as well as unnecessary
overtime operations.
1.2 Contributions
We have addressed the problem of inefficient reschedul-
ing upon unexpected events by implementing an operating
room rescheduling system that consists of a rescheduling al-
gorithm, a web application that provides an easy-to-use user
interface, and a backend database. The rescheduling system
allows users to input an initial surgery schedule, monitor
the schedule and trigger the rescheduling algorithm when
a surgery is prolonged or finishes early, and accept or re-
ject the suggested schedule changes that are output by the
algorithm.
The purpose of our product is two-fold: to increase ef-
ficient use of operation room resources by automating dy-
namic scheduling and to do so by delivering a product that
emphasizes ease of utility. The latter aspect is important
because hospitals are large systems and slow to change; the
clients of our product, operating room nurses and surgeons,
are busy people who will not accept a steep learning curve.
2. RELATED WORK
The majority of research on operating room scheduling
has focused on developing algorithms to create optimized,
initial operating room schedules. That is, these algorithms
are designed with the goal of producing an operating room
schedule that optimally utilizes the resources that the algo-
rithm accepts as input parameters. We focus on a slightly
different problemaddressing the dynamic nature of the
operating room, which often results in inevitable changes
to the initially generated operating room schedule. Even
though our focus is to implement an algorithm that gener-
ates efficient schedule adjustments, the modeling methods
of algorithms for both initial operating room scheduling and
dynamic scheduling can serve as a basis for our algorithm.
2.1 Algorithms that Optimize Initial Operat-
ing Room Scheduling
The algorithmic approaches to generating optimized, ini-
tial operating room schedules can be divided into the fol-
lowing three categories: strategic, tactical, and operational.
These categories represent the three main decision levels in
operating room scheduling; they are interdependent but due
to the complexity of the problem, most approaches primar-
ily address one of these levels. The strategic level deals with
the assignment of time blocks in block scheduling to different
surgical departments. The tactical level focuses on develop-
ment of the master surgical schedule. The operational level
involves assignment of surgical cases to the schedule [1].
Algorithms focusing on the strategic level analyze factors
that determine the distribution of time blocks to surgical de-
partments. These factors include the frequency of different
surgeries to be performed in the time period, the number of
staff available in each department, and cost analysis. Plan-
ning at this level is primarily a resource allocation problem
and research addressing it has focused on the similarity to
manufacturing systems. Linear programming models based
on economic analysis to maximize profits and minimize costs
and optimization models to maximize the number of cases
have been developed [1].
Algorithms based on the tactical level focus on develop-
ment of the master surgical schedule. Different linear pro-
gramming models have been developed to optimize genera-
tion of this schedule. Some algorithms focus on minimizing
difference between requests and allocations while others aim
to minimize hospital costs [1].
Algorithms based on the operational level focus on schedul-
ing surgeries and can be divided into two steps: assigning pa-
tients to operating rooms (advanced scheduling) and gener-
ating a sequence of cases (allocation scheduling). Algorithms
generally attempt to optimize one of the two steps presented.
The problem is modeled as a resource constraint scheduling
model that distinguishes between renewable resources (per-
sonnel) and nonrenewable resources (equipment). These al-
gorithms account for the variability of the operating room,
a characteristic modeled by stochastic models, which are de-
scribed further below in the dynamic scheduling section [1].
2.2 Algorithms that Optimize Dynamic Oper-
ating Room Schedule
An early approach to the scheduling problem was appli-
cation of the newsvendor theory to the clinical context [4,5].
The initial translation was performed in the context of a sin-
gle operating room serving two surgeries [5]. The newsven-
dor model is a mathematical model used in operations man-
agement and economics to produce optimal product levels
for a product with variable demand and limited lifespan [6].
In the context of the operating room, the product is surgery
and the uncertainty of the product is the variable amount of
time required for different surgeries. In the initial analysis
of the scheduling problem modeled by the newsvendor the-
ory, the optimal scheduling was solved by convex ordering,
a type of stochastic ordering, which is a type of probabilistic
ordering of random variables [5].
A later group, Denton et al. [7], expanded the prob-
lem to accommodate the multiple-patient case by assuming
each surgerys length was independent and identically dis-
tributed. They created a two-stage stochastic linear model
that accounts for costs of waiting time for resources, idle
time when no surgeries are being performed, and delays in
surgeries [7]. The algorithm derived by Denton et al. was
later expanded by Denton et al. [8] by removing the require-
ment for sequences of cases to be known before optimization.
Denton et al. provide a two-stage stochastic integer model
as well as multiple heuristics, the best of which was found
to be ordering cases by smallest variance first [8].
The algorithm derived by Denton et al. was later ex-
panded by Denton et al. [8] by removing the requirement for
sequences of cases to be known before optimization. The up-
dated system of computing optimal sequence and schedule of
surgeries is a combinatorial stochastic optimization problem.
Denton et al. provide a two-stage stochastic mixed integer
model as well as multiple heuristics to estimate the optimal
solution. The heuristics proposed are based on mean and
standard deviation of surgery duration from historical data,
an improvement on the independent and identical distribu-
tion used in Denton et al. [7]. The maximum optimization
was found by ordering cases by smallest variance first [8].
The results are logically sound because schedule disruptions
due to early cases exceeding their allotted times are more se-
vere and require more extensive rescheduling than schedule
disruptions from later cases exceeding their allot- ted times.
Mancilla et al. [9] improved the algorithm further by de-
veloping a two-stage stochastic integer programming (2-SIP)
approximation that optimized sequencing of surgeries and
arrival times. The model allowed for a revision of future
surgeries given the need. The 2-SIP model was extended
to the problem of dynamic scheduling in a single-operating
room system, in which surgery cancellations were accounted
for [9].
Dynamic scheduling in a multiple-operating room system
was also modeled with a 2-SIP model given information
about the bounds on surgery durations [4,9]. A problem
encountered was optimization of both the scheduling and
rescheduling, but the L-shaped algorithm and hedging-based
heuristics allowed an ideal case of reassignment to be solved
[9].
The most recent work, by Zhang et al. [4] develops a
multistage stochastic program to model the dynamic prob-
lem of operating room scheduling. The system proposed
performs a rescheduling decision at each surgery comple-
tion event. To simplify the large state set and complexity
of the problem, a two-stage stochastic integer programming
approximation is used to optimize the costs for the given
state of the dynamic scheduling problem. The first stage
cost of the 2-SIP approach is calculated as the sum of wait-
ing time of the surgeon and idle time of the operating room
released at a given surgery completion event. The remaining
cost, or cost of all other rescheduling decisions, is estimated
by two distinct heuristic models. The first, one-period look
ahead heuristic (OPLA), estimates the remaining cost as
the cost observed at the next stage. The second, rule-based
multiperiod look ahead heurisitc (MPLA), calculates the re-
maining cost as the total cost, as opposed to the cost at the
next stage as in OPLA. MPLA approximates the total cost
by arranging the surgeries in a nondecreasing order of pre-
defined surgery start times. Simulations comparing static
scheduling, dynamic scheduling with OPLA, and dynamic
scheduling with MPLA indicate that dynamic scheduling,
especially dynamic scheduling with MPLA, is a substantial
improvement on static surgery scheduling [4].
Essen et al. [10] take a distinct approach to the operat-
ing room rescheduling program by placing an emphasis on
stake- holder preferences. The authors define stakeholders
as the following: surgeons, patients, anesthesiologist, nurses,
and multiple departments in the hospital, including recovery
department and radiology department. The key stakeholder
in the paper is the patient and his availability preference
is weighted the most in the model. The authors modeled
the system as an integer linear program (ILP). Constraints
representing the different preferences of stakeholders were
imposed on the model and optimization was performed to
minimize the deviation of these preferences. Simulating the
model produced two primary schedule adjustments: shift-
ing a surgery and scheduling a break between two surgeries.
The model and optimization method led to fewer cancelled
surgeries and a perceived reduction in workload for each of
the stakeholders involved. The ILP model is developed im-
proves the operating room schedule for only one operating
room at a time, which renders it inefficient for larger, real
world systems. Another limitation is that due to changing
priorities of stakeholders, the constraints and decision rules
extracted as optimal also change [10].
While these theoretical approaches to optimizing operat-
ing room scheduling are well defined mathematically, many
are too complicated to solve without simplifications and are
very difficult to implement. Consequently, there is lack of
transition from proposed theoretical solutions to results in
the real world. This is particularly evident at Pennsylvania
Hospital, where the scheduling software fails to address even
basic inefficiencies [3]. We attempt to address this gap by
proposing a more practical schedule adjustment tool that
has the potential to be used in a real clinical setting.
After considering these limitations of mathematical mod-
els of the rescheduling problem, we decided to approach
the problem in a different manner. We identified that the
operating room environment is analogous to the job shop
problemjobs translate to surgeries and machines translate
to operating rooms. Modeling the operating room reschedul-
ing problem with the job shop scheduling problem is not
an approach that has been attempted previously. We de-
cided to follow this approach because it yields an algorithm
that is implementable without simplifications and matches
our model and specific assumptions, detailed in the system
model section of this paper. This approach also clearly ful-
fills the goal of shortening schedules by more efficient usage
of operating rooms, while also allowing for customization
with other metrics (see evaluation section for more details).
The background required to understand our algorithm is
presented below.
2.3 Job Shop Scheduling Problem
The job shop scheduling problem is an optimization prob-
lem in computer science that attempts to assign ideal jobs to
machines in such a way that the time required to complete
the jobs in minimized [11]. The problem has been presented
in many forms, but we present in this paper the form most
relevant to our rescheduling algorithm.
Assume there are n atomic jobs and m identical machines.
A job is considered atomic if it is not divided into multiple
operations. Each machine can only process a single job at a
time and all the jobs can be processed on any machine. The
goal of the job shop scheduling problem is to assign the n
jobs to the m machines in an order such that the total time
required for all the jobs to complete is minimized. One al-
gorithm designed to solve this problem, the least processing
time algorithm, is the basis for our rescheduling algorithm
and is described in detail below.
2.4 Least Processing Time Algorithm
The least processing time (LPT) algorithm is designed
to solve the job shop scheduling problem presented above.
The first step of the algorithm assigns to each job a weight
equal to the length of the job. Next, the jobs are sorted in
descending order by weight. Each machine m is initialized
to have a load of 0, and then jobs are sequentially removed
from the sorted queue and placed in the machine with the
shortest load. As a job is added to a machine, the length of
the job is added to the machine load.
This algorithm guarantees a schedule that completes all
the jobs in the shortest time possible. It is a 4/3 approx-
imation algorithm. We have used the LPT algorithm as a
basis for our rescheduling algorithm, with appropriate mod-
ifications to address our specific problem.
3. SYSTEM MODEL
3.1 Overview
Our system consists of a software prototype that will gen-
erate operating room schedule adjustments in response to
unanticipated events in the operating room system. In par-
ticular, the software handles cases in which a surgery is un-
expectedly prolonged and cases in which a surgery finishes
early. Users of the software can input an initial operating
room schedule and update the schedule when an unantici-
pated event occurs. When such an event occurs, the software
will systematically generate schedule adjustment recommen-
dations for the user to evaluate. The user can then choose to
accept or reject the schedule adjustment recommendations
and continue to update the schedule accordingly. A block
diagram of this system workflow is depicted in Figure 1.
Figure 1: Logical flow diagram of model
3.2 Assumptions
In our system model, the following assumptions are made
about the operating room environment. All of the assump-
tions were confirmed by our medical advisor as acceptable
and reasonable for our goals.
All operating rooms are relatively similar and can ac-
commodate all kinds of surgeries
Surgeries can be grouped into classes and handled ap-
propriately by class
Surgeons are always available during the surgery day
except when they are scheduled to perform surgeries
Nurse teams and anesthesiologist teams are versatile
and can perform any type of surgery
Nurse teams and anesthesiologist teams are assigned
to a single operating room for the duration of their
shift
3.3 Rescheduling Algorithm
One of the key components of the operating room reschedul-
ing software is the rescheduling algorithm. The goal of the
algorithm is to schedule the remaining surgeries to the op-
erating rooms in such a way that the total time required to
execute the remaining surgeries is minimized. While trying
to achieve this goal, the algorithm is restricted by the con-
straint that it should avoid avoid delaying surgeries. The
extent to which the algorithm avoids delaying surgeries is
specified by user input for each class of surgeries (specified
as alpha, as mentioned in the Web Application section).
The rescheduling algorithm used in the operating room
rescheduling software is an extension of an already existing
algorithm, called the Longest Processing Time (LPT) algo-
rithm. The LPT algorithm is used to solve the atomic job
shop scheduling problem. In this problem, the inputs are
n jobs with varying processing times and m machines. The
goal is to assign the jobs to the machines in such a way that
the total time required to process the jobs is minimized (see
Related Works for more details).
Our rescheduling algorithm results from adapting the LPT
algorithm to the operating room environment. The jobs
in the atomic job shop scheduling problem naturally trans-
late to surgeries, and the machines in the atomic job shop
scheduling problem naturally translate to operating rooms.
However, a few crucial adjustments were also necessary to
fully adapt the LPT algorithm to the operating room reschedul-
ing problem. First, in our rescheduling algorithm, each
surgery is assigned a weight corresponding to its surgery
length and its original start time before the rescheduling oc-
curs. The user input parameter alpha, which specifies the
importance of avoiding surgery delays, is also incorporated
when assigning each surgery its weight. In our algorithm,
the surgeries are now sorted in descending order of weight
instead of descending order of processing time. Another
crucial adjustment that had to be made was that our algo-
rithm must ensure that surgeries involving the same surgeon
are not scheduled to be performed concurrently. Therefore,
if the surgery that is currently being scheduled involves a
surgeon that is currently performing another surgery, the
surgery being scheduled must be placed in a delayed queue
to be scheduled later. The general steps of our rescheduling
algorithm are as follows:
Let there be n surgeries with lengths t1 to tn
Let there be m identical operating rooms
Let W[i] be the weight assigned to surgery i
Let L[i] be the current load on room i
Let J[i] be the set of jobs assigned to room i
Let be the parameter that specifies the importance of
avoiding surgery delays (user input)
1. For each surgery i = 1 to n
W[i] = ti - (start time of surgery i prior to current
rescheduling - current time)
2. Sort the surgeries in descending order of weight (using
 priority queue)
3. For each room i = 1 to m
L[i] = sum of the lengths of surgeries that have
already started in room i
J[i] = {}
For each surgery j = 1 to n (in sorted order)
Ensure that surgeon associated with surgery j is
not scheduled to perform another surgery at the
same time
if (surgeon associated with surgery j is currently
performing a surgery)
Set current surgery j to be scheduled after surgery
j+1
Continue
Let i = operating room with smallest load
J[i] = J[i] U j
i = L[i] + tj
3.4 Web Application
The operating room rescheduling software is in the form
of a web application. The application will initially take in as
user input the initially planned operating room schedule for
a given surgery day along with basic information about the
operating rooms in the operating room system. When in-
putting the initially planned schedule, the user will have the
option to assign surgeries to different classes. Each class of
surgeries can, in turn, be assigned a different priority level.
Surgeries belonging to classes with higher priority levels will
be less likely to be delayed when the web application gen-
erates schedule adjustments. This feature of assigning surg-
eries to different classes was included to account for the fact
that, in reality, surgeries have different priorities and that
some surgeries should not be delayed if possible.
After the web application is initialized with the initially
planned schedule, it will continue to receive as user input
information regarding the current status of the operating
room system. When an unanticipated event has occurred,
the user can update the schedule and generate schedule ad-
justment suggestions. When generating the schedule adjust-
ment suggestions, the user can input a value for alpha for
each class of surgeries. A surgery class alpha indicates the
importance of avoiding surgery delays for the surgeries in
that class. Then, based on the alpha values input by the
user, the web application will generate schedule adjustment
suggestions and display them to the user. The user will be
able to evaluate the schedule adjustment suggestions and
determine whether he/she would like to accept them.
3.5 Technical Challenges
Many technical challenges were encountered throughout
the process of creating the rescheduling software. In par-
ticular, the most difficult challenges were related to making
the software practical in a real hospital setting.
One of the primary challenges was yielding schedule ad-
justment recommendations that would be reasonable for the
surgeons and patients. It is necessary for the rescheduling
algorithm to output results that are not only mathemati-
cally efficient, but also useable by the parties involved. In
order for the schedule recommendations to be meaningful, it
was necessary to incorporate two considerations into our al-
gorithm. First, we had to ensure that the algorithm avoided
surgery delays, perhaps even at the cost of a longer surgery
schedule. This was especially important because surgery de-
lays significantly inconvenience both surgeons and patients.
Second, we had to ensure that surgeons were not being
scheduled to perform concurrently occurring surgeries. For
clear reasons, this was also very necessary.
Another challenge was improving the usability of the soft-
ware itself. Since the hospitals are very hectic environments
and nurses are very busy, it was important to ensure that the
application is easy to use. This included creating a simple
and clear user interface, and ensuring that all of the user in-
puts would be easily available to the nurses. Furthermore, it
was crucial to ensure that that the runtime of the scheduling
algorithm was efficient.
4. SYSTEM IMPLEMENTATION
The operating room rescheduling software was implemented
as a web application using the client/server model. The pri-
mary components of the web application are the database,
the server-side functionality, and the user interface.
4.1 Server-Side Functionality
The web application backend was implemented using a
request-response programming model using Java servlets.
Each URL in the application is mapped to a servlet, and
the servlets send the appropriate response back to the client.
The Java servlets interact directly with the database and the
rescheduling algorithm.
The operating room rescheduling algorithm was imple-
mented in Java.
The web application was hosted on a Jetty server. This
was done by packing the source code into a WAR file and
placing the it in the appropriate directory on the Jetty server.
4.2 Database
The database was implemented using Oracle Berkeley DB,
Java Edition. The primary database entities stored were the
surgeries and operating rooms.
Figure 2: Application Architecture
4.3 User Interface
The user interface was implemented using HTML and
CSS. The web application has four primary pages. The first
page allows the user to initialize the operating rooms and in-
put an initial schedule. The second page allows the user to
monitor the schedule and indicate an unanticipated event.
The third page allows the user to update the schedule and
specify the alpha parameters for the rescheduling algorithm.

Figure 3: Screenshot of home page
The fourth page displays the schedule adjustment recom-
mendations for the user to evaluate, and it gives the user
the option to accept or reject the recommendations.
5. RESULTS
5.1 Evaluation Metrics
Evaluation of system performance is based on two primary
metrics. The first metric is the change in the length of the
surgery day, calculated by subtracting the end time of the
last surgery in the original schedule from the end time of the
last surgery in the rescheduled schedule. By this calculation,
a negative value indicates a shortening of the length of the
surgery day while a positive value indicates a longer surgery
day.
The second metric is the average delay between resched-
uled start times and original start times for all surgeries
rescheduled by our system in a given day. This metric is
calculated by summing the time differences between resched-
uled and original start times for all surgeries and dividing by
the total number of surgeries in a given day. If the surgery
is rescheduled to start later, it contributes a positive value
to the metric. A surgery rescheduled to start earlier con-
tributes a negative value, or decrease in average delay, to
the metric, and a surgery rescheduled to start at the same
time contributes a value of zero.
5.2 Methodology
We evaluated our algorithm using both of the described
metrics at six different values of alpha, ranging from 0 to
15. The performance of our rescheduling algorithm at these
different alpha values was compared to the performance of
a baseline rescheduling algorithm. We designed the base-
line rescheduling algorithm to simulate the process currently
used by nurses to reschedule surgeries upon unexpected events,
as described by our medical advisor Dr. Brooks.
The baseline algorithm takes in as input the surgery that
is prolonged or cancelled as well as the new end time. The
baseline algorithm extends the appropriate surgery and pushes
back all other surgeries in the same operating room that fol-
low. After pushing back the surgeries, the algorithm checks
to see if moving the last surgery to the end of the operating
room with the smallest load, or the room whose last surgery
ends the earliest, would result in the surgery ending earlier.
If so, the move is made. This algorithm reflects the typical
response to unexpected events in the operating roomaAT-
surgeries are pushed back and occasionally moved to another
room.
We randomly generated different schedules that are rep-
resentative of a typical hospital operating room schedule,
based on input from Dr. Brooks. We generated schedules
instead of using actual hospital schedules, because HIPPA
privacy issues made it difficult to obtain complete surgery
schedules.
The characteristics of our schedules are as follows:
The surgery day of our schedules extends from 7 am
to 5 pm
There are 10 operating rooms
Surgeries were on average 1 hour long
About 50-65 surgeries were scheduled initially
The operating room loads are all approximately equal
to each other
Operating rooms were filled almost completely, with at
most 2 hours between the end time of the last surgery
in the room and the end of the surgery day
Approximately 7% of surgeries were delayed an average
of 1 hour in each schedule
Our rescheduling algorithm, at each value of alpha, and
the baseline algorithm were run on each of the schedules and
the metrics were averaged to obtain the single data points
displayed on the graphs below.
5.3 Aggregate Results
Refer to the two graphs on this page summarizing our
evaluation results.
Figure 4: Change in surgery day length
For change in surgery day length, our rescheduling algo-
rithm performed better than the baseline algorithm for all
values of alpha. Our algorithm decreased the length of the
surgery day for all values of alpha, but as the alpha value
increased, the amount of shortening of the surgery day de-
creased. The baseline always increased the length of the
surgery day, as is expected by a simple push-back process.
For low values of alpha, high average delays are observed,
as expected because the algorithm does not prioritize schedul-
ing algorithms close to their initial start time. As the value

Figure 5: Average delay
of alpha is increased, the average delay drops to be similar
to the value of the baseline algorithm.
We observed a trade-off between the amount the surgery
day can be shortened and the average delay of surgeries.
This observation makes sense intuitively because higher al-
phas give importance to preventing surgery delays as much
as possible, but at the expense of flexibility in shuffling surg-
eries around. However, despite this trade-off we found that
even at high alphas where average delay was low, there was
still a decrease in the total length of the surgery day.
6. FUTURE WORK
Since our application is a prototype, there are many po-
tential improvements that can be made.
One such improvement is addition of a notification system
that informs hospital staff, including surgeons, nurses, and
anesthesiology teams, of their new surgery schedules. Such
a system could be implemented through text messaging or
email and would increase the usability of our application.
This notification system could be extended further by re-
laxing our assumption that surgeons are always available un-
less they are performing another surgery. Instead of using a
messaging system just to inform surgeons of their changed
surgery, it could be used to ask surgeons if they are avail-
able during the new suggested surgery time. The surgeons
responses could then be used to output the final reschedul-
ing. This would increase the usability of our application
tremendously.
Further, more of our assumptions can be relaxed to cre-
ate an environment more similar to the real world. For ex-
ample, not all operating rooms are actually identical in a
real hospital setting. Accounting for this in our application
would allow assignment of special surgeries to those operat-
ing rooms. Another improvement would be to account for
emergency surgeries, as well as the prescheduled surgeries
we currently allow.
The long-term goal is to integrate our application with the
hospital system. This would allow easier access and usage of
hospital data, including the initial schedule, available hos-
pital staff, and patient information. Integration would also
ensure that our application is as secure as the rest of the
hospital system, guaranteeing a higher level of compliance
with HIPPA.
7. ETHICS
The operating room rescheduler faces some potential eth-
ical issues. The primary concern is that the system must be
extremely secure because of the sensitive nature of its data.
Since it works with patient and hospital records, the resched-
uler must follow the federal Health Insurance Portability and
Accountability Act of 1996 (HIPPA). This act was formed
to ensure that the confidentiality and security of healthcare
information would be protected. If the reschedule system
were somehow compromised, sensitive patient and hospital
records would be compromised, which is unacceptable. The
repercussions would be multifold, including legal and mon-
etary trouble for the hospital and emotional stress for all
hospital staff and patients involved.
Another concern is the potential for our system to crash in
the middle of an operating day. If our system were the pri-
mary source of information about the surgery schedule, this
would result in a halt or significant delay in the surgery day
until the system could be rebooted, resulting in monetary
loss for the hospital and emotional distress for the hospital
staff and patients dealing with the uncertainty. Our system
would also have to ensure that data is stored in a persistent
state that can be recovered upon rebooting.
Incorporating our rescheduler with currently used systems
in hospitals can mitigate both concerns about HIPPA poli-
cies and fault tolerance. Integration with the hospital would
involve removing the application from the internet, reducing
its vulnerability. The data would also be stored on secure
hospital servers and backups could easily be maintained in
case of crashes. It would also ensure we follow the same
security protocols to honor HIPPA as the rest of the hos-
pital system. This would involve, on a high level, secure
authentication to limit access to only appropriate person-
nel as well as strong encryption. We faced the implications
of HIPPA when attempting to acquire real hospital data
for our evaluation. The patient identifying information had
to be removed from the surgery schedules before delivered
to us and because there was no automation to process the
records, the amount of hospital data we were able to acquire
was limited.
8. CONCLUSIONS
Operating room rescheduling is not a problem that has
been addressed extensively. Most of the research that has
been done on it is purely theoretical, with no focus on prac-
tical implementations that can be used in a clinical setting.
However, the inefficiencies of the current manual method of
rescheduling surgeries signal that such a tool is very neces-
sary.
We have designed a prototype of such an application. Our
system has a rescheduling algorithm based off of the job shop
least processing time algorithm, a web application user in-
terface, and a back end that stores the necessary data about
surgeries and operating rooms. Upon a surgery prolongation
or cancellation, a user can run the rescheduling algorithm
and accept or reject its suggested changes. We also allowed
users to dictate how important it was to schedule surgeries
as close to their initial start time as possible.
Our evaluation of the application showed a decrease in
the total length of surgery day with our algorithm as com-
pared to a baseline algorithm. We also observed a trade-off
between the decrease in surgery day length and the average
delay time of surgeries. Overall, our application is a good
proof-of-concept prototype that illustrates that automated
rescheduling is possible and beneficial for use in a clinical
setting.

9. REFERENCES
[1] Guerriero F and Guido R. (2011).Operational research
in the management of the operating theatre: a survey. Health
Care Management Science 14(1), 89114.
[2] Cardoen, B., Demeulemeester, E., and BeliAnn, J.
(2010). Operating room planning and scheduling: A lit-
erature review. European Journal of Operational Research,
201, 921932.
[3] Ari Brooks, MD (Advisor)
[4] Zheng Zhang; Xiaolan Xie; Na Geng. Dynamic Surgery
Assignment of Multiple Operating Rooms With Planned
Surgeon Arrival Times. Automation Science and Engineer-
ing, IEEE Transactions on , vol.11, no.3, pp.680,691, July
2014. doi: 10.1109/TASE.2013.2267273.
[5] E. N. Weiss. Models for determining the estimated
start times and case orderings. IIE Trans., vol. 22, pp.
143150, 1990
[6] Anesth Analg. 2010 Jun 1;110(6):1698710. Epub
2010 May 6.
[7] B. Denton and D. Gupta. A sequential bounding ap-
proach for optimal appointment scheduling. IIE Trans., vol.
35, no. 11, pp. 10031016, 2003.
[8] B. Denton, J. Viapiano, and A. Vogl. Optimization of
surgery se-quencing and scheduling decisions under uncer-
tainty. Health CareManage. Sci., vol. 10, pp. 1324, 2007.
[9] C.MancillaandR.Storer.A sample average approxima-
tion approach to stochastic appointment sequencing and schedul-
ing. IIE Trans., vol.44, no. 8, pp. 655670, 2012.
[10] van Essen, J. T., J. L. Hurink, W. Hartholt, and B.
J. van den Akker. 2012. Operating Room Rescheduling.
Working paper, Beta Research School for Operations Man-
agement and Logistics, University of Twente. Accessed July
26, 2014.
[11] Jones, A., Rabelo, L. C. and Sharawi, A. T. 1999.
Survey of Job Shop Scheduling Techniques. Wiley Encyclo-
pedia of Electrical and Electronics Engineering. .