Project Number: P18751
Total Page:16
File Type:pdf, Size:1020Kb
Multidisciplinary Senior Design Conference Kate Gleason College of Engineering Rochester Institute of Technology Rochester, New York 14623 Project Number: P18751 RESIDENCY ROTATIONAL SCHEDULING GRAPHICAL USER INTERFACE Taylor Blackwell Daniel Fox Liam Kalir Rochester Institute of Technology Rochester Institute of Technology Rochester Institute of Technology Rochester, NY, USA Rochester, NY, USA Rochester, NY, USA ABSTRACT Chief Residents spend weeks manually creating block schedules for the coming year. Operations research may be used to develop an integer programming model algorithm to solve for these schedules while optimizing some objective(s). Existing forms of this algorithm require commercial software licenses and coding knowledge to use. This paper describes the tools and methodology used to develop a graphical user interface and recode the algorithm using free and open source software. NOMENCLATURE AMPL Algebraic modeling language to describe and solve high-complexity problems for large-scale mathematical computing CPLEX Optimization solver software package from IBM Daemon A background, long-term process that performs some service for other processes Django Python framework for developing web applications GUI User interface that allows users to interact with software through graphical icons and visual indicators Pandas Software library written for Python for data manipulation and analysis Python High level programming language for general purpose computing Pyomo Collection of Python software packages for formulating optimization models Open Source Software for which the original source code is made freely available and may be redistributed and modified Optimization model A type of mathematical model that attempts to optimize (maximize or minimize) an objective function without violating resource constraints Residency Stage of graduate medical training Copyright © 2018 Rochester Institute of Technology Proceedings of the Multidisciplinary Senior Design Conference Page 2 INTRODUCTION Before being able to practice medicine as a doctor, medical students must participate in a medical rotational program for three years. Throughout the program, the students will rotate between the various medical units of a hospital to acquire hands-on experience with the various types of medicine and procedures involved in the field of medicine. This would be incredibly disorganized without some form of schedule to guide the whole process. The scheduling of where each of the residents are in a rotational program is currently done manually with Excel by a group of Chief Residents; this can take them upwards of six months to generate a schedule for the program. In 2016, Dr. Ruben Proaño and Akshit Agarwal wrote a paper detailing an algorithm to reduce the work [1] involved in generating the weekly (block) schedules for the residents in the program . An issue with their system was that the developed linear model was written using AMPL and solved using CPLEX which are expensive to license and not user friendly to interact with. Because of this, Dr. Proaño wants to create a system that Chief Residents actually want to use to reduce their scheduling workload for the year. This means that the system needs to be easy and not cost anything to use. The goals of this MSD project were to demonstrate that it is possible to translate the model to a free alternative, create an easy-to-use data entry method, and develop an interface that allows users to just press a few buttons to generate a schedule and then display the results. PROCESS After reviewing the information in the project readiness proposal, the team met with Dr. Proaño to discuss some of the fundamental expectations of the project and his vision for the system. The main takeaways from this meeting were that the system should be capable of handling unique user input rather than the specific set of data that the team was provided and there were concerns raised over whether or not the open source alternatives for CPLEX and AMPL, GLPK and Pyomo respectively, could actually handle the complexity of the problem in a reasonable amount of time. Dr. Proaño also pointed the team to resources the team could reach out to for assistance with the model and connecting with potential end users. The team had developed a list of five people to contact including Dan Ornt M.D. from RIT’s Institute of Health Sciences and Technology, and staff at the Strong Memorial Hospital and Rochester Regional Health. The team proceeded to reach out to these people and using their insights, the team was able to further develop customer requirements. These requirements are shown in Tables 1 and 2. Table 1. Engineering Requirements Engineering Requirement Metric Target Probability of Achieving Target Time to solve time (days) < 2 months High concurrent scheduling tasks boolean Capable of > 1 concurrent task High # of possible alternative schedules quantity 24 High list of supported Linux, MacOS, Windows, Cross platform interface systems Web?, Mobile? Unknown # of user errors while creating schedule quantity 1-2 High Server Uptime percent > 95% Unknown Capable of storing generated Store schedules boolean schedules High Time for user input Time (hours) < 2 months Unknown Cost $$$ $0 High Project P18751 Proceedings of the Multi-Disciplinary Senior Design Conference Page 3 Table 2. Customer requirements Customer Requirement Importance Interview Requirements 9 Open source 9 Easy to use with little training 9 Cross Platform 9 Easy to understand the meaning of inputs 9 Provides schedule(s) 9 Schedules are human readable 9 Collect data for research 3 Schedules are in common format 3 Improve model performance 3 Shift trading for unexpected changes 3 Interface with MedHub 3 Interface with amion/iCal/qgenda 3 Flexible enough to work with many residency programs 3 Ability to give schedule preference to certain residents 3 Ability to update schedule throughout the year 3 Capability to keep the schedule "skeleton" from year to year 1 Data analysis 1 Capability to rank electives 1 Identify where slack is built in the schedule for changes 1 The largest takeaways for the team were that our system needs to be open source and easy to use. DESIGN The majority of the design process was focused on determining which libraries and tools had the capabilities necessary to develop a prototype. There were three main types of libraries to focus on. The first was a web framework that could integrate with Python. The team decided to use Django since the team had the most experience with it, it is Python based and well documented. The Celery library was also included to expand Django’s functionality. Celery is a Python-based asynchronous tasking library that integrates with Django. This allows the website to perform the scheduling calculations without blocking normal operation of the website. For the linear programming language, the team used Pyomo because there were multiple resources for Pyomo help from students and faculty. One of the most influential areas of support was the expansive user guide written by Hart et al.[2] which the team used extensively throughout the development of the prototype. An optimization software package also needed to be selected. The optimization package differs from the programming language in that the programming language just describes the equations while the optimization package actually solves the linear program. Even being restricted to free and open-source solutions, there were several options considered. Ultimately, the team decided on GLPK (Gnu Linear Programming Kit), which is an industry standard library for linear and mixed-integer programming. The final area of focus was what library would be used to import the excel files and use them with Pyomo. The options that were available included: Pyomo’s built-in excel compatibility, SciPy, and Pandas. The team decided to use the Pandas library since it was based off of the R programming language that the team was familiar with. Copyright © 2018 Rochester Institute of Technology Proceedings of the Multidisciplinary Senior Design Conference Page 4 To maintain the code for the project, the team needed to use a version control software. A public Git repository was established on GitHub to host the project’s source code. GitHub is the most popular Git repository host in the world for free and open-source projects, and this project certainly fits the culture of the site. The final prototype consisted of three components: an algorithm model, a software library to manipulate and extract data from the model, and a Django website to serve as an interface between users, the library, and model. Each component interacts with and transfers data with the others. Figure 1 shows a simplified version of how the components interact with each other. Figure 1: High Level System Architecture The model contains the mathematics for the objectives and constraints that define the problem (scheduling a residency block schedule). In Pyomo, this is represented via an abstract model, which means that the mathematics are the same but the numbers that are fed in to the math are flexible, like substituting 1 in for X in Y = 2X2 + 3X + 4. All Pyomo models are constructed by adding objective functions, decision variables, sets, parameters, and constraints to a Python object that represents the model as a whole. Ultimately, the model has a binary decision variable for every combination of person, time, and location. Then the model decides which decision variables are turned “on” or “off.” These equations were based on the algorithm constructed by Dr. Proaño and Agarwal in their research paper. Asynchronous tasking was required to allow schedules to be developed without halting the website’s operation. Meaning that users will be incapable of performing actions while anyone else is currently using the system. While Python supports threading and multitasking natively, using a custom-made solution did not seem worth the effort. Celery is an Python-based asynchronous tasking library that also, conveniently, integrates with Django. Celery operates by creating a daemon process that interacts with a master program via a backend service called a “broker”.