• No results found

Operating Room Rescheduler

N/A
N/A
Protected

Academic year: 2021

Share "Operating Room Rescheduler"

Copied!
8
0
0

Loading.... (view fulltext now)

Full text

(1)

Operating Room Rescheduler

Dept. of CIS - Senior Design 2014-2015

Albert Shu

salbert@seas.upenn.edu

Univ. of Pennsylvania

Philadelphia, PA

Indu Subbaraj

subbindu@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 hospital’s 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 room’s 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 sinclud-ingle 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)

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

(2)

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 implementreschedul-ing an operatreschedul-ing 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 problem—addressing 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 SchedulOperat-ing

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: assignschedul-ing 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 surgery’s 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 optimizadistribu-tion 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

(3)

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 operatwait-ing 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 rescheduloperat-ing program by placoperat-ing 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 schedulshift-ing 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 scheduloperat-ing 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 problem—jobs translate to surgeries and machines translate to operating rooms. Modeling the operating room reschedul-ing problem with the job shop schedulreschedul-ing 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.

(4)

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 reschedulreschedul-ing 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 lengthst1 totn

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)

(5)

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.

(6)

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 roomˆa ˘Aˇ T-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 algoalgo-rithm 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

(7)

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

(8)

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 Beli ˜A´nn, 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. 143−150, 1990

[6] Anesth Analg. 2010 Jun 1;110(6):1698−710. 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. .

Figure

Figure 1: Logical flow diagram of model
Figure 2: Application Architecture
Figure 4: Change in surgery day length For change in surgery day length, our rescheduling  algo-rithm performed better than the baseline algoalgo-rithm for all values of alpha
Figure 5: Average delay

References

Related documents

29 The anomalies detected by the anomaly detector were used twice: first, the anomalies were removed from the image to calculate a robust mean vector and covariance matrix, and

(A) The Board of Directors shall adopt a written plan for acquiring and holding investments and for engaging in investment practices that specifies guidelines as to the

(2001) Quality of life for people with dementia living in residential and nursing home care: the impact of performance on.. activities of daily living, behavioral and

To attain an insight on the effect of slot geometry on the antenna performance, the proposed egg curved slot antennas are designed with different slot sizes as simulated in Fig.

All the title compounds were screened for their in vitro antibacterial and antifungal activity against B.coccus, S.aureus, Pseudomona, E.coli, A.niger, Ampicillin,

To make this language a general one that can be used across packages like GooFit, a new decay language parser was built in Python called DecayLanguage framework and released in

l Congress explicitly requires school districts to provide special education and related services designed to meet unique needs and prepare children with

Therefore this randomized controlled study compared the effectiveness of a semi-finished occlusal appliance (SB) with a laboratory-made occlusal appliance (SS) in myofascial