Web based chemotherapy scheduling at St. James Hospital. Karl Baker Computer Science 2013/2014

Transcription

1 Web based chemotherapy scheduling at St. James Hospital. Karl Baker Computer Science 2013/2014 The candidate confirms that the work submitted is their own and the appropriate credit has been given where reference has been made to the work of others. I understand that failure to attribute material which is obtained from another source may be considered as plagiarism. (Signature of student)

2 Summary Scheduling chemotherapy appointments within a hospital ward is a complex problem, the task of assigning many patients to many nurses, and choosing the time to treat each patient presents many complications. Each nurse can handle a certain amount of patients and each patient must have treatment at a time that does not conflict with any other of the nurse s patients. The added complexity comes from a patient requiring treatment in not just one continuous block of time but rather, many small blocks of time that are fragmented across the day, separated by a strict amount of wait time. The challenge is then to try and interlace the treatment of patients so that during the wait time of one patient, the nurse is actively treating other patients to make the most efficient use of their time. The focus of the project is to try to help the oncology ward at St. James hospital in Leeds with their chemotherapy scheduling, which is presently done manually in a book. It is clear that if scheduling efficiency is improved, then it may be possible for the ward to treat more patients in the same amount of time, therefore reducing wait times for new patients and possibly improving patient outcomes. A review of previous approaches to the problem is conducted, and it is found that the majority of the literature focuses on deterministic algorithms such as integer linear programming and it s variants. It is then decided that an investigation into a stochastic approach, specifically genetic algorithms would highlight a new way of solving the problem. Previous work has also been largely theoretical, creating efficient algorithms but offering no way for a chemotherapy ward to easily use them in practice, or offering only very limited use. Therefore, the project also focuses on the creation of a software solution that allows the inputs and outputs to the algorithms to be easily manipulated. i

3 Acknowledgements I d like to thank my supervisor, Dr. Raymond Kwan for his guidance throughout the project, and my assessor, Dr. Haiko Muller, for his helpful comments in the progress meeting and mid-project report. I d also like to thank all staff at St. James who helped with the project, particularly Dr. Geoff Hall and Andy Shaw, who gave valuable advice and feedback. Credit goes to Owen Johnson for suggesting the initial idea for the project and providing guidance during the early stages. Finally, I d also like to thank my family and friends for their support whilst working on the project. ii

4 Contents 1 Problem description Overview Example Formal definition Inputs Objective Constraints Literature review Complexity analysis Previous approaches Project Aim Aim Objectives Minimum requirements Extensions Relevance to degree Methodology Web solution Algorithm development Project schedule 12 5 Investigating the problem Initial meeting Summary Meeting with the head nurse and IT project manager Process Model Requirements and constraints Prototype Web Solution Hardware and development environment The prototype Home Page Regimens Page Patients Page Multi-Day Page Intra-Day Page Prototype Algorithm Database structure Presentation User Review iii

5 7 Algorithm development Test data Lower bounding Lunch break Clash enumeration Local search Integer Linear Programming Genetic Procedure overview Non Overlapping Populations Overlapping Populations Increasing the amount of patients Mutation Rate Addition of random genomes Hybrid approach Summary Nurse Scheduling Web solution refinement Previous requirements Additional requirements User Evaluation Evaluation Research Web solution Requirements Methodology User Review Summary Algorithms Satisfaction of Objectives Comparison to previous work Extensions Appendix A: Personal Reflection Appendix B: Materials Used Appendix C: How Ethical Issues Have Been Addressed Appendix D: Screenshots and help text Screenshots Help text Regimens Page Patients Page Multi-Day Page Intra-Day Page iv

6 14 Appendix E: Charts and graphs 66 v

7 Chapter 1 Problem description 1.1 Overview Chemotherapy is a widely used treatment for cancer. It consists of a single drug, or combination of drugs that are given on a regular basis. The drug(s) given, in combination with the schedule on which they are given is called a regimen. Typically, a period of around three weeks is given after a chemotherapy appointment to allow the body to recover, although this can vary depending on the regimen and can be anywhere from one to four weeks. The pattern of appointments and rest spaces in between is called the multi-day schedule. On any given appointment day, a chemotherapy patient is administered chemotherapy drugs in a fixed order over a strict time pattern. This is called the intra-day schedule. Usually this involves a nurse setting the patient up with an intravenous line and preparing the drugs to be administered through the IV line. The same nurse must attend to the patient throughout the appointment. Once a drug has started flowing into the IV line, it will take between half an hour to a few hours to drain fully and the nurse is free to do other activities while this is happening but must stay on hand in case of complications. Once the drug has been administered there may be additional time to wait for it to take effect before the next drug can be administered or before the patient can finish and go home. The following diagram shows the relationships created by this scenario: Figure 1.1: A nurse can take care of many patients over a day. Each patient is prescribed only one regimen at a time, but could have had many regimens over their history of treatment. A regimen can have many appointments which follow a multi-day schedule, and each appointment can have many tasks which follow an intra-day schedule. Each task usually involves administering a drug or checking the patient s health. 1

8 1.2 Example For simplicity, we can assume that all tasks a nurse is assigned are rounded to 15 minute time slots. An intra-day schedule for a single patient will consist of active time slots where a nurse is needed to complete a task, and free time slots where a nurse is not needed. A nurse can attend to many patients by adjusting the start times of each patient such that no two active time slots clash. Ideally, the nurse should have no clashes in their timetable, but can deal with a small amount by speeding up their work during these times. Here is an example diagram of a single nurse s schedule: Figure 1.2: 5 patients with differing regimens assigned to one nurse. Each patient has a setup task at the beginning of their schedule which consists of setting up the IV line and a quick check up. The finish up task involves removing the IV line and checking that the patient is well enough to go home. There is one clash highlighted in yellow at 9:45. 2

9 1.3 Formal definition Following is a formal definition of the problem that will be used throughout the project Inputs The inputs to the problem are as follows: A set of patients P = {...} For each patient P (i): A start time P (i) S A list of integers P (i) T = {...} denoting the time of each task for that patient relative to the first The length of the working day in 15 minute time slots L Once a patient s first task has been performed, the subsequent tasks must follow in the strict time pattern given by the list of integers in P (i) T, therefore it is sensible to always assign the first task a value of 0, and the subsequent tasks the value of the amount of time slots after the first task that they should occur. The absolute time slot (which correlates to the time of day) that a task t should occur for a patient i can then be given by: P (i) S + P (i) T (t). All tasks for a patient can then be shifted within in a day by the same amount just by altering P (i) S Objective The main objective of this problem is to then adjust each patient s start time in such a way as to produce a schedule with the minimum number of clashes. We can find the jobs J occurring at a particular time slot k by: J(k) = i P, j P (i) T P (i) S + P (i) T (j) = k (1.1) Then the number of clashes at a particular slot k, referred to as the clash density by Clark [1] and Condotta [2], can be given by: C d (k) = max{0, J(k) 1} (1.2) Two jobs in the same slot will give one clash, three jobs at the same slot gives two clashes and so on. The number of clashes for the whole day can then be given by: L 1 C d (k) (1.3) k=0 The main focus of this project will be to minimise this value, although arguably, 4 clashes at different times across the day is better than 4 clashes all at once for example, so another potential objective would be to also minimise the maximum clash density given by: max{c d (k) k {0, 1,..., L 2, L 1}} (1.4) Previous research by Clark [1], and Condotta [2] also list correct placement of the nurse s lunch break at a time in the middle of the day as a third measure of schedule quality. 3

10 Although it has been decided in this project that to ensure a nurse s terms of employment are always fulfilled, an extra constraint will be added that will mean the lunch slot has to start at a suitable time, for example between 11am and 2pm. It is hoped that this will improve schedule quality and make the objective function simpler Constraints The first constraint is that all patient tasks must occur within the time frame of the day. Formally for a patient i: (P (i) S 0) (P (i) S + max{p (i) T } < L) (1.5) Each nurse must also have a lunch slot which is represented by a task minutes long that is scheduled along with the patients. The lunch slot is constrained to starting between 11am and 2pm. 1.4 Literature review The fact that there is a time lag between individual procedures during an appointment, and that the nurse is free to attend to other patients during the time lags creates an interesting scheduling problem similar to a well known problem called coupled operation scheduling. In coupled operation scheduling there are always two tasks with a fixed time lag in between. In general, optimisation of coupled operation scheduling has been shown to be NP-Hard [3],[4] although certain special cases have been shown to be polynomial, see section It is noted that chemotherapy scheduling is a superset of the coupled operation scheduling problem, since an intra-day schedule will always have two or more tasks: setting up and finishing, but possibly more if a multi-drug regimen is used Complexity analysis Coupled operation scheduling problems arise in many other fields, and much work has been devoted to the research of algorithms, heuristics and time complexity regarding them. In radar systems, pulses of radio waves are emitted and the system has to wait a specific amount of time for them to be reflected before they are received back and a result can be obtained. During this time, the radar system can work on other tasks. It is shown in [4] that for a coupled task i, with durations a i (task 1), b i (task 2) and L i (Lag duration) that by constraining the problem such that i a i = L i = p, or i a i = b i = p; L i = L, a polynomial solution can be applied. The case where i a i = a; b i = b; L i = L is polynomial in the cyclic case (where the schedule is infinitely repeated as in a radar system) but remains open in the finite case. In [5], Gabay, Finke and Brauner investigate the complexity of scheduling radar tasks for this open case, and show that it is likely to be NP-Hard but do not derive a formal proof. All other cases have been shown to be strongly NP-Hard. This shows us that, even in the simplified case where all regimens have two tasks, the problem of creating schedules will be NP-Hard, since the drug delivery time and waiting times can be of any length and are not constrained as in the polynomial cases above. Since the regimens can also have any number of drugs, this will be a superset of the coupled operation scheduling problem and thus remain NP-Hard. 4

11 1.4.2 Previous approaches The fact that problems similar to coupled operation scheduling are NP-Hard does not deter a lot of researchers. Many have found approximation algorithms or simplifications to the problem. In [6], Mancilla and Storer attempt to schedule operating room surgeries. In this type of problem there exists a collection of jobs (surgeries) to be performed each with their own duration and cost. Given a fixed budget, the decision problem asks whether a schedule exists that does not exceed the budget. Mancilla and Storer prove NP-Hardness by showing a reduction from the 3-partition problem. Later on in the paper they attempt to use heuristics such as waiting time, idle time and overtime to guide a stochastic integer programming approach. In [1], Calum Clark investigates chemotherapy appointment scheduling and also takes a heuristic approach. First discussed is a neighbourhood search, which is initialised with a few starting seed solutions that are generated by a simple method such as a greedy algorithm. It then performs different types of search strategies around the seed solutions using thresholds to mark certain solutions as useful. One search strategy is to follow steepest gradient descent to find local optimums. Another is simulated annealing, where solutions are accepted probabilistically, so solutions that are less optimal can still be accepted some of the time, which potentially allows the search to escape from local optimums. Tabu search is covered, which is similar to a neighbourhood search that, as well as marking certain solutions as useful, it also marks certain branches of the search as bad or tabu, based on certain thresholds. This is done to try and prune the search early and avoid wasting time in non productive areas of the tree. Genetic algorithms are also briefly mentioned and a simplified genetic type algorithm is implemented that uses crossover and selection, although only one method of applying crossover and selection is investigated, and no mutation is used. In the end, most of the work of the paper is devoted to using neighbourhood search and tabu methods, since Clark felt that there was already a lot of research in that area to build upon. In [2], Alessandro Condotta investigates many scheduling problems, including chemotherapy scheduling, using neighbourhood search, tabu search and integer linear programming. Condotta presents detailed statistics on the real life problem at St. James Hospital in Leeds, which will be very useful as a benchmark in this project. From 1st May 2008 to 1st September 2008, the chemotherapy outpatient clinic of St James Hospital had around 800 appointments scheduled every month. It is open 5 days a week, and during this time frame around 40 patients were treated by 8 nurses every day. There were 19 nurses employed in total that work different shifts. The average waiting time from diagnosis to treatment for a patient was 14 days. An average schedule for a day had about 20 nurse clashing activities, although nurses spent 47% of their time on average doing treatment activities in relation to their overall working hours. Since 2008 it is likely that volumes have increased. It is also noted that on a Monday, no tasks are scheduled before 11am since the pharmacy needs start up time after a weekend to prepare some drugs. Nurses also need a half hour lunch break some time between 11am and 2pm. Condotta runs integer linear programs in the commercial software CPLEX Solver and shows that the average value of 20 clashing activities per day can in most cases be reduced to around 1 or 0. In [7], Condotta and Shakhlevich build upon the work in [2] and perform a case study. Firstly, a large set of test data is generated with artificial patients assigned to realistic regimen schedules. Two integer linear programs are then presented. The first solves the problem of assigning patients their multi-day schedule. The second solves the problem of optimising an 5

12 intra-day schedule for each day given by the first program. The paper then focuses on the tasks of maintaining these schedules once they have been generated, by allowing rescheduling to take place in the event of complications, and by allowing the addition of new patients to the schedule. The paper then uses real historic data from St. James to evaluate the performance of these algorithms and finds that the oncology ward can theoretically handle a 20% increase in patients with negligible deterioration of schedule quality. In [8], Matthew Wall describes many scheduling algorithm techniques including, but not limited to: integer linear programming, simulated annealing, bounded enumeration, the critical path method and genetic algorithms. Most of the work of the paper is devoted to genetic algorithms. The general structure of the genetic algorithms used is to first start with an initial population of random solutions and a measure of each solution s fitness based on certain heuristics. The search applies recombination and mutation to the current population to create potential solutions for the next generation. Solutions are included in the next generation depending on their fitness. This runs for a set amount of time and an artificial evolution occurs where only the fittest solutions survive. Wall found that while computationally expensive, genetic algorithms usually create a high quality result, due to working on a population of solutions rather than just one. The types of scheduling problems investigated include job shop and project scheduling with tasks that have precedence constraints. From the literature reviewed, research into genetic algorithms applied to coupled operation type scheduling seems to be limited. Other types of scheduling problems have received a lot of attention from researchers using genetic algorithms, but chemotherapy scheduling in particular seems to have had little work devoted to this type of approach. This highlights a potential new area for this project to investigate. The algorithms and methods that have been developed are very useful and it is clear that by using these methods, a chemotherapy clinic would be able to schedule all of their appointments much more efficiently. Although despite Condotta and Clark both working with St James Hospital while doing their research, the Hospital still uses a manual method of scheduling appointments in a book and much of their work is not seeing real world use. Condotta s research is largely of a theoretical nature, and the algorithms developed are implemented in CPLEX Solver, which would be difficult for the hospital to use in practice due to the cost of the software and the effort required to integrate it into their system. Clark goes a step further, in that he writes his own software in python to implement his algorithms, and displays the output on a web page. Although this was not adopted for wide use in the hospital, assumedly because the interface is very basic. The software asks only for the regimen IDs of the patients being treated today and gives a choice of which algorithm to use to create a schedule. Regimens cannot be altered by the nurses, and when used in practice, it is required to be able to tailor the intra-day schedule of a regimen to a specific patient, due to certain allergies or other factors the patient may require slightly different drugs such as allergy inhibitors and hence different waiting times. The software would also have to be installed on each computer that it was designated to be used on, which makes it less accessible. In this project it is hoped that the requirements for a system that can be used in practice can be investigated. This project will differ from previous projects in that it will aim to create a software solution that is as feature complete as possible within the time frame allowed. It would be beyond the scope of this project to create a fully working system that could be used in practice due to the many intricacies of the problem. Although the investigation of the main 6

13 requirements and the development of a prototype system would be a helpful step in that direction. The aim would be to make scheduling algorithms and approaches to solving this problem more accessible to the people working in this field. A prototype system would enable the main inputs to the scheduling algorithms to be entered, and ideally be as simple to use as possible. Scheduling algorithms are also of great interest to the author and it is hoped that algorithm research and development can also take place during the project. A number of methods have already been applied by previous projects in this area, and it will be necessary to avoid repeating the same work. Condotta and Clark in their work have briefly mentioned genetic algorithms and have devoted limited research into solving the problem with this type of approach. From the literature reviewed, and the author s previous experience with genetic algorithms it seems that this would be a relevant approach to explore and hopefully bring to light a new way of tackling the problem. Insights may also be discovered that can be brought back and applied to genetic algorithms in general. 7

14 Chapter 2 Project Aim 2.1 Aim The aim of this project is to investigate the requirements needed in order to build a system that aids the scheduling of chemotherapy appointments at St. James hospital in Leeds. Previous work in this area has been largely theoretical, but this project aims to make a software solution that is easy to use, more accessible and a step towards something that is usable in practice. To enable this, a model will be built that describes the current method used to schedule appointments and the constraints of the problem. Based on the model, a prototype system will be developed that allows the inputs for scheduling algorithms to be easily entered, and the outputs visually displayed. Research into, and development of new types of scheduling algorithms will also take place. 2.2 Objectives The objectives of this project are: To research the current method that is used to schedule appointments in order to ease development of a software solution. To create a software solution that allows automatic scheduling of appointments to be more freely accessible to staff at St. James. To research existing algorithms that are applicable to the problem and pick a select few to be adapted and implemented in a software tool, or to formulate and implement new algorithms. To take into account staff terms of employment whilst building a schedule. Such as lunch breaks and shift durations. To make an attempt to assess schedule quality using metrics such as: amount of appointments fulfilled, amount of staff breaks allowed and number of appointment clashes. 2.3 Minimum requirements Creation of a model that captures the current method that is used to schedule appointments. Creation of a software solution that aids the scheduling of appointments. Investigation into and use of current scheduling algorithms applicable to the problem, or formulation of algorithm types previously unworked on. 8

15 2.4 Extensions Possible extensions would be to: Allow manual scheduling of tasks as well as automatic scheduling on the software system. Allow re-scheduling of appointments in case of complications or cancellations. Test algorithm performance in busier scenarios than average and adapt to perform well in these. 2.5 Relevance to degree The skills learnt in the third year modules Combinatorial Optimisation and Algorithms and Complexity will be highly relevant when it comes to working on the scheduling algorithms. Genetic algorithms in particular will draw on skills learned in the Artificial Intelligence module from year 2 and Biological and Bio-Inspired Computation from year 3. The development of the web solution will draw on skills learned from the year 2 module Software Engineering and first year module Computer Systems. Client interaction will also rely on skills learned in the first year module Professional Development. 9

16 Chapter 3 Methodology The project will be comprised of two different but related avenues of work. There will first be the web solution development which will involve gathering requirements from clients, working to fulfil these and then gathering feedback for review. Secondly, there will be the algorithm development which will involve background research on previous approaches taken, development of a genetic algorithm and an evaluation in comparison to the results obtained by previous researchers. The methodology for both avenues of work will be explained here. 3.1 Web solution The methodology used for this part of the project will follow principles similar to those used in agile software development [9], which will include iterative development, requirement gathering from clients, prioritisation of the requirements and time boxing to decide which requirements will be implemented at each iteration. Another commonly used development methodology is the waterfall method [10]. This method is more often implemented when many of the requirements are known beforehand, and a single sequential process of design, implementation and testing takes place. This method offers the advantage of being predictable and well planned. Although the method is more rigid, and provides less flexibility for dealing with new requirements that arise mid-way through the project. The agile method has been chosen for this project due to the advantages of facilitating fast delivery of prototype solutions for evaluation, and due to being adaptable towards new requirements. In the first stage, requirements will be collected and verified both by interviewing a handful of clients and cross checking their suggestions against each other, and comparing them to the information found in the literature research. The requirements gathered will then be prioritised using the MoSCoW method [11]. This will involve splitting the requirements into four priority levels. The Must group will contain high priority requirements that are essential for the system to function. The Should group will consist of medium priority requirements that are still important to satisfy, but not as time critical. The Could group will consist of low priority requirements that are not as important but can be considered nice to have. If appropriate, a fourth group of Won t requirements will contain speculative features that are either a large amount of work for little gain, or not as relevant to the project. Splitting the requirements into priority levels in this way provides a clear way to apply timeboxing in order to decide which requirements are to be implemented at each iteration. The development phase of the web solution will be comprised of at least two iterations depending on how many time allows. The objective for the first iteration will be to satisfy all of the high priority requirements, and then the system will be sent for review by the clients. The review will confirm whether the high priority requirements have been satisfied to an adequate degree and will serve to raise any further requirements that were missed at the first stage. The second iteration will aim to satisfy all of the medium priority requirements. A 10

17 second review will then take place, this time, aiming to gather responses targeted at the usability of the system rather than the functionality, as the main functionality of the website should have been satisfied in the first iteration. After this, more iterations will take place if time allows. Gathering and prioritising requirements in an iterative fashion like this will serve to make sure that the most important features are complete at every stage, and will enable the features to be verified by more than one review. The feedback from the users at each stage can serve not only to improve the system, but also to review it once it comes to the evaluation stage of the project. 3.2 Algorithm development The algorithm development stage of the project will utilise incremental delivery [12], which will focus on initially creating a working genetic algorithm with minimal effort, and then gradually improving the algorithm by considering the refinement of each genetic operator a milestone to be delivered. The process of fine tuning each operator will use throwaway prototyping [10], as a vast range of methods have been highlighted in the literature for employing genetic algorithms. Operators, such as crossover and mutation can be applied in many different ways, and can also take different parameter values, such as mutation rate. Using throwaway prototyping, different ways of applying each operator can be explored and only those that yield positive results will be further investigated. Once the best methods have been found for each operator the parameter values will be fine tuned. The algorithm development stage of the project will be preceded by the creation of a test database of schedules to run on. This will either need to be obtained from St. James, or randomly generated. All of the algorithms can then be evaluated at every stage by running against the database and this will mean that continual testing will be available for both performance and error checking. After the creation of a test database, the algorithm development stage will begin. There will first be a few simple methods that can be explored which have been highlighted in the literature reviewed. These will include simplified versions of local search and integer linear programming. Local search will serve to be a fast running algorithm that will provide a base score to improve against. Integer linear programming will be slower, but always finds the optimal solution. This will enable the optimal number of clashes for each schedule in the test data to be recorded, so that each algorithm can have it s results compared to the optimum. It will also allow an aspect of testing, for if an algorithm finds a solution better than the optimal, then it would be obvious that constraints are not being enforced and infeasible solutions are being generated. 11

18 Chapter 4 Project schedule In order to meet the objectives in the required time frame, following is a schedule for the project. Week Task 1 Investigation of the problem 2 Investigation of previous approaches and literature review 3 Meet with staff at St. James and analyse the current scheduling method 4 Formulate an initial model and prioritise requirements 5 Development of solution prototype 6 Finish prototype development and request feedback from staff 7 Mid project report 8 Generate test data and begin algorithm development 9 Implement a simple genetic algorithm 10 Refine the genetic algorithm using methods from the literature 11 Further algorithm refinement 12 Collect feedback from staff and perform second iteration of web solution development 13 Finish second iteration and request further feedback 14 Use feedback to evaluate the web solution 15 Evaluate the genetic algorithms by comparison to previous approaches 16 Proof read and finalise write up In the first and second week an overview of the problem will be put together. The literature will be extensively analysed and solutions that have been applied to this type of problem in the past will be reviewed. This will help to guide the direction of the project, avoid repetition of previous work, and provide a basis for evaluation of the product produced. The deliverables for this stage will be a collection and review of previous approaches to the problem. Some time around the third week it is hoped that meetings with staff at St. James Hospital can be arranged and the definition of the problem can be further expanded to include more details. The deliverables for week 4 will be to present a concise record of all details gathered, a list of requirements for the web solution, and a process model that describes a patient s treatment course starting from diagnosis. These three deliverables can be continually referenced to help streamline development. Weeks 5 and 6 will be spent working on the requirements gathered from the previous section to produce a prototype solution which will be the deliverable for this stage. From the background research conducted, a simple algorithm will also be selected and implemented that would best fit use in the solution. Once the prototype web solution has been developed, it will be put onto a live web server for hosting and the address will be sent to staff at St. James for review. The mid project report will then be worked on and will demonstrate the progress so far. 12

19 Whilst waiting for comments and feedback from users, algorithm development can take place. This will leave adequate time for staff to gather their comments and get back in touch. The first deliverable for this stage will be to generate a database of test data so that the algorithm performance can be consistently tested. The next stage will be to get a simple genetic algorithm working and giving results. The next two weeks after this will be spent refining and improving the genetic algorithm using methods reviewed in the literature. The deliverable for this stage will be an optimised and hopefully high performing genetic algorithm. After refining the genetic algorithm, the feedback can be reviewed and a second iteration of development on the web solution can begin. The algorithms worked on in the previous section can also be incorporated into the system. The deliverable for this phase will be to improve the main issues highlighted by the feedback. After the second iteration, another feedback request will be sent, this will aim for a different group of users than the first to gather a more rounded collection of opinions. Once this feedback has been collected, it can be used to perform another iteration of development if time allows. The final phase will be to evaluate the web solution from the feedback gathered and to evaluate the algorithms produced by comparison of their results to the results produced by previous approaches in the literature. The report will be worked on consistently throughout the project at a steady pace, although the last week is expected to be spent completing it and adding finishing touches. 13

20 Chapter 5 Investigating the problem 5.1 Initial meeting A meeting was arranged with Geoff Hall, the medical director for cancer services at St. James Hospital, to discuss the nature of the scheduling problem at St. James and to see how this project could help. Following is a summary of the main points discussed. Currently, scheduling is done in a book by the head nurse. Geoff expressed his concerns about the efficiency of the book based method, and also about the fact that when asked by a patient which time their appointment will be, he has no other way of telling them without going to the head nurse s office and looking in the book, which can be difficult if the head nurse is out of office or over the other side of the hospital. Geoff is very positive about the possibility of a software solution for scheduling chemotherapy appointments and believes it would be a large benefit to the hospital. He is happy to review prototype solutions and give guidance. There are hundreds of possible regimens, but the top 5 cover more than 90% of all prescribed regimens. It would be adequate for this project to focus on only the top 5, and if there is the need later on, more can easily be added to the system. Although the multi-day schedule is usually strictly fixed, a +/- 1 day deviation is acceptable if there are a large number of patients clashing on the same day. Anything more than a 1 day shift for a healthy patient is a compromise. Patients may also be delayed for a few days if they are extremely ill. When combined with no-shows and other unforeseen events, this all means that rescheduling has to be able to be done on the fly. It would be useful if the system took into account additional constraints imposed by the pharmacy. For example, they may only have a limited capacity for making a particular type of drug. Additionally, prescribing a multi drug regimen compared to a single drug regimen might cause slightly more work for the nurse, but a large increase for the pharmacy. As the project develops it will be considered how this could be implemented, but it may be beyond the scope of this project. A nurse timetable that is 100% full will seem very efficient from a theoretical point of view, but in reality they have jobs other than treatment to attend to and may feel overworked and stressed. We can see from Alessandro Condotta s data that on average, nurses spend 47% of their time on treatment activities. It is not known whether this is because they simply have a large amount of other tasks to do or because treatment activities cannot be scheduled efficiently enough at present to be able to occupy a larger percentage of the timetable. This would be a question to ask the head nurse. It will be necessary to find a balance between free time and efficiency by perhaps aiming for a 90% full schedule rather than 100%. Some cancers are very aggressive and need to be treated as soon as possible. Others are less 14

21 aggressive so can wait around 1-2 weeks to be treated with minimal ill effects. It will be necessary to take into account the urgency of the treatment when booking a new patient into the system. Some patients travel a long distance to receive their chemotherapy. It would be advantageous if the system can take this into account and schedule those patients an appointment later in the day to give them time to travel. Other travel based constraints may also apply, such as whether the patient can drive themselves, or needs to get a lift, or whether the patient is using hospital transport. This also may be beyond the scope of this project. It was also mentioned that Andy Shaw, IT Project Manager at the Leeds Cancer Centre would also be valuable to meet to discuss the problem and to provide feedback on the solution built Summary From the points discussed in the meeting, it is clear that a software solution would benefit the hospital. A web based system has been chosen to be the most appropriate due to the fact that it will be easy to access from across the hospital without requiring software to be installed on the machines, and will be accessible from many types of devices such as laptops, tablets and smart phones without being restricted by differences in operating systems. A login and password can be used for each member of staff to keep patient information secure. The meeting brings to light a number of requirements and constraints that apply to the system being built. These will all need to be taken into consideration and to follow the project methodology, it will be appropriate to prioritise these and split them into high, medium and low sets. A meeting with the head nurse will be arranged to gather further requirements and then the entire requirements list will be discussed in section Meeting with the head nurse and IT project manager A week later, Geoff Hall, the head nurse and Andy Shaw were available for further meetings. Following is a summary of the main points discussed. There is an existing system that stores information on chemotherapy patients called ChemoCare. In this system only the regimen and appointment date is set. The next appointment is only booked when a patient turns up for the current appointment, even though in theory it is known when all subsequent appointments should happen. This is done to avoid having to re-book every future appointment due to low blood counts or illness. Each nurse has around a 45 minute lunch in the middle of the day. The ward is open from 9:00 to 19:30 and the nurses will work approx. 7.5 hour shifts. Intra-day schedules are not planned. Each patient is assumed to take around one hour of nurse resources, but this hour can be split into chunks across the day. The nurses get used to which patients will take longer because of things like bad veins, or more complicated regimens, and plan slightly longer amounts of time for these patients up to around 1.5 hours. A nurse working 7.5 hours with a 45 minute lunch is then assumed to be able to treat around 6 patients in a day and decisions about which patient to treat and when are usually only made 15

22 on the day. There is about 10% free time accounted for in case of complications, so aiming for a 90% full schedule would be optimal. Some patients may require different types of pre-medication because of certain medical conditions or allergies. So the regimen intra day patterns stored in the system need to be templates which can be customised to each patient. Some patients will need a blood test at the start of the day which takes 2 hours to process. The patient can only start treatment once the results of the blood test are obtained. This can also be input by the use of customisable schedules. Some regimens will not be started after 17:30 to ensure they have enough time to finish. Further points raised by Geoff: Code names for regimens are slightly different across the country. It would help if alternative names for a regimen could be stored in the system to allow portability between different hospitals. Alessandro Condotta obtained test data from past events and then run his algorithms on this to see, in theory how much better things could have been made. Getting test data for this project may have ethical issues, but it would be acceptable to generate test data randomly as long as the regimen information and overall volumes such as numbers of nurses and amount of patients per day is accurate. Algorithms can then be run on this to check performance. 5.3 Process Model Based on the information gathered so far, here is a model that describes the process a patient goes through starting from diagnosis. This model will aid the development of the web solution. When a patient is diagnosed with cancer there will be a waiting time between their referral and the start of treatment. Government guidelines state that there should be no more than 2 months wait between an urgent GP referral for suspected cancer and starting treatment [13]. Alessandro Condotta shows in his data that the time from the decision to treat to the date of the first appointment is 14 days on average [2]. This waiting time gives a buffer to the changing volumes of incoming patients. It is likely that in any type of scheduling system for chemotherapy, all slots have been scheduled for days that are close such as within the current week, but days that are a few months forward may have no appointments scheduled for them yet. In the meeting with Geoff, it was explained that a new patient will usually have their first appointment assigned to the earliest free slot that is available. Although the first appointment fitting into a free slot may not necessarily mean that the appointments further down the line also fit into free slots. It is then a complex problem to try to fix the date of the first appointment. Although difficulties can usually be worked out by choosing the date that causes the least amount of clashes overall, but is still not too far in the future. For individual days the head nurse will assign each nurse a specific number of patients to handle. This is usually around 6 but varies based on the regimens that the patients are on and the relative workload that these regimens create. The individual starting times of each patient 16

23 will then be chosen based on personal experience. The patient will then receive their appointments in the pattern determined by the multi-day schedule of the regimen. Although sometimes there are complications to chemotherapy. One of the biggest risks is that the patient becomes neutropenic. This means they have a low number of neutrophils which are a type of white blood cell. Chemotherapy often suppresses neutrophil production and this can lead to opportunistic infections and septicaemia. If a patient becomes neutropenic they will have to have their future appointments pushed forwards until they recover, which means that the schedule has to be adjusted. Other things can cause schedule re-adjustments such as patient lateness, no shows, or conflicting commitments. 5.4 Requirements and constraints The evidence gathered so far highlights a number of requirements and constraints that any chemotherapy scheduling system must take into account. Most of these features directly relate to points raised in the meetings so far or on matters discussed in the literature that has been reviewed. For a system to be functional, it would be critical to take into account all of the high priority features presented below. The medium priority features focus mainly on ease of use and accessibility. The low priority features represent useful ideas that could be implemented in the future but are not essential to the system. High priority (Must): Store and display the multi-day and intra-day schedules of the top 5 regimens. Have the ability to add patients into the system and pick their regimen and start date. Display the intra-day schedule of all patients on a particular day. Attempt to arrange intra-day schedules using scheduling algorithms. Take into account a nurses lunch slot of 45 minutes. Allow patient s appointment dates to be modified to take delays into account. Medium priority (Should): Aim for a 90% full schedule when arranging appointments. Support most modern browsers and platforms to enable wide accessibility across the hospital. Have a help section on each page explaining how to use the system. Low priority (Could): Take into account pharmacy drug production constraints. Take into account patient travel times. Store alternate names on regimens. 17

24 Chapter 6 Prototype Web Solution 6.1 Hardware and development environment To host the website, the cloud platform Microsoft Azure has been chosen due to the low cost and flexibility of the hosting options offered [14]. It offers a choice of hardware specifications and can provide virtual machines with 1 to 8 cores and between 3 and 64 gigabytes of memory. The hosts are easy to connect to using remote desktop and can be pre-installed with a range of Microsoft operating systems. Microsoft Azure also features automatic scaling, so that as a larger amount of users begin to use the website, or as the system gradually begins to work on a bigger dataset, the amount of cores and memory available to the machine will automatically be increased. This is one of the main benefits to running in the cloud and means that the system will not gradually slow down if it s use starts to become more widespread across the hospital. A host running Windows Server 2012 was chosen with a modest initial hardware specification of 4 cores and 8 gigabytes of memory. This will ensure that the site can run the scheduling algorithms in a reasonable time frame. A free 90 day trial of Microsoft Azure is available with pre-loaded credits and it is likely that the system will not exceed the free usage since it will have a relatively small amount of users. To develop the back end server side of the website, the language C has been chosen due to the ease that Microsoft allows to connect it with a front end website and also a back end database. It is relatively high level but also not too slow due to being based on C. Lower level languages such as C/C++ or Fortran would likely be faster at running the scheduling algorithms but these are more difficult to hook up to a website and a back end database. To store the details of regimen and patient schedules, the database engine SQL has been chosen. This is due to the ease that it can connect with C and the front end website via the syntax linq to SQL. Complex data structures can also be stored and retrieved relatively quickly. 6.2 The prototype From the information gathered, a website was created that satisfies all of the high priority requirements to function as a first iteration prototype. Following is a walk through of the main pages. Screen shots have been included in Appendix D to avoid cluttering the main report Home Page The home page displays an introduction to the site and describes the main features of each page. The title WebCS has been chosen as the name of the web solution, which is short for Web tools for Chemotherapy Scheduling, or simply Web Chemotherapy Scheduling. A screen shot of this page is shown in figure

25 6.2.2 Regimens Page On the regimens page shown in figure 13.2, a regimen can be selected from the drop down list. It s multi-day schedule is then shown as highlighted numbers on a grid that is 7 days wide. The numbers are relative to the first day of treatment. On the right hand side, an individual day number can be picked, and it s intra-day schedule can be viewed. The individual drugs to be administered can be seen, and intra-day schedules may vary on different day numbers. Data on the top 5 current regimens at St. James was provided by Geoff Hall. Existing regimens can be edited and new ones added using the Edit Regimen or Add Regimen buttons, following is a walk through of this process. Shown in figure 13.3, on the first screen of the edit regimen dialog the name of the regimen and the appointment days can be changed. The appointment days are entered as a comma delimited list and then the next button is clicked to edit the intra-day schedules of each appointment day. Shown in figure 13.4, when editing the intra-day schedule of an appointment day, tasks can be added with a specific time and a short task name. The user clicks next to edit the next appointment day and this continues until all days have been edited and the entry is then saved to the database. The process for adding a new regimen uses exactly the same user interface. On the first screen of the dialog the name of the new regimen is entered along with the appointment days. On the following screens the intra-day tasks for the appointment days are filled in Patients Page On the patients page shown in figure 13.5, individual patients can be selected by their patient ID. For this prototype, all data is random and a random name generator has been used from [15]. When a patient is selected, their current regimen and regimen starting date is shown. On a calendar, their multi-day schedule is shown, and to the right, their intra-day schedule is displayed. It is possible to add patients into the system and pick their starting date and regimen. When a patient is added to the system the multi-day and intra-day schedule of their chosen regimen is copied to the patient s schedule. The multi-day and intra-day schedules of the patient can then be edited independent of the regimen in order to tailor a regimen to a patient s specific requirements. In this way, a regimen is only a template that can be applied to a patient s schedule which can then be further modified. Specific patient requirements may include extra drugs for example to inhibit allergies, extra time for blood tests, or simply to take into account that a patient has bad veins and requires a longer amount of time to set up with an IV line. On the add patient dialog shown in figure 13.6, the patient s name, regimen and start date can be entered. It is likely that if used in practice at St James then this system would link to ChemoCare and they would use the same database, so the patient s name and other details may not necessarily have to be entered. Although whilst the system is a prototype this is a useful way of entering test data. On the first screen of the edit patient dialog shown in figure 13.7, the patient s appointment days can be changed. If existing appointments have their date shifted then the the intra-day 19

26 tasks remain unaltered. When new appointments are added they start with a blank intra-day schedule and this can be filled in on the following screens. Editing the intra-day schedule of a patient shown in figure 13.8, is done in a similar way to editing the intra-day schedule of a regimen, although the times in the left column are an absolute time of day rather than being relative to the start of treatment as in a regimen Multi-Day Page On the multi-day page shown in figure 13.9 a date can be selected, and all patients with appointments in the next 30 days will be displayed. This allows estimation of the workload for the upcoming month Intra-Day Page On the intra-day page shown in section 13.10, a single day is selected, and the intra-day schedules for all patients that have an appointment on that day are displayed. At first the schedules all have a default starting time of 9am. The user can click arrange automatically which requests the server to run a scheduling algorithm on the data. 6.3 Prototype Algorithm The algorithm that implements automatic scheduling for the prototype is ideally a quick and simple one that converges to a local optimum. The algorithm may not give the best solution but should give a good result most of the time. The algorithm implemented has been inspired by Calum Clark s work on local search methods, but is an extremely simplified version. First, the algorithm creates a seed solution. For this prototype the seed solution is created by placing the start time of all patients at 9am. A different seed solution could be created by placing the patients at random times, or by placing the patients sequentially based on their first task. Both of these methods will be tried in the algorithm investigation part of the project. The main part of the search then iterates the following pseudo code procedure: Function LocalSearch() do P reviousclashes CurrentClashes() for i 0 to P - 1 do P (i) S 0 M inclashes CurrentClashes() BestP osition 0 for j = 1 to (L max{p (i) T }) 1 do P (i) S j if CurrentClashes() < M inclashes then M inclashes CurrentClashes() BestP osition j end if end for P (i) S BestP osition end for while CurrentClashes() < P reviousclashes 20

27 The CurrentClashes() function computes the current number of clashes in the schedule and will be discussed in section 7.4. For each patient, the algorithm tries all possible start times and finds the position that causes the least clashes. The patient is then assigned to that position and the algorithm processes the next patient. Once the last patient has been processed, the algorithm returns to the first patient if this iteration made an improvement. On each iteration the algorithm must either make an improvement, or no improvement and exit. After a few iterations it converges to a local minimum. 6.4 Database structure The database structure that is used to store the data on regimens and patients is shown below. Figure 6.1: The Database structure used in the prototype website. The Regimens table stores all of the regimens and their names. The RegimenMultiDay table stores the day numbers of all appointment days for each regimen and the RegimenIntraDay table stores the details of intra-day tasks for each regimen appointment day. The Patients table links to the PatientRegimens table to store which patients are prescribed which regimens. The Patients table also links to a Multi-Day and Intra-Day table so that a 21

28 patient can have their own schedule separate from their regimen. When the regimen is first assigned to the patient, the schedule data for that regimen from the RegimenMultiDay and RegimenIntraDay tables is copied to the PatientMultiDay and PatientIntraDay tables for that patient. The patient s schedule can then be edited independently. 6.5 Presentation At this stage, a small presentation was organised by the project group that included Dr. Raymond Kwan, Owen Johnson and the other final year project students supervised by Raymond. The prototype website was presented and a number of useful points were raised. On the Multi-Day page, the appointment days could be colour coded to enable you to easily see which days have the same intra-day schedule without having to actually view the schedule. It would be useful to display a timespan between the individual tasks on the intra-day schedule. On the Multi-Day page, a bar chart or histogram that is based on the amount of tasks in each regimen that each patient is on may be more useful so that the workload can be estimated more accurately. These points will be prioritised and incorporated into the second iteration of development. 6.6 User Review The website was then put onto the live Azure server and an account was made for staff at St. James to be able to access it. Staff were requested by for their comments and opinions on the site and their replies were recorded. Gathering responses took a reasonable amount of time as some staff were very busy. The next phase of the project, algorithm development was then worked on whilst waiting for responses. 22

29 Chapter 7 Algorithm development In this section a deeper investigation will take place into the advantages and disadvantages of the local search method and genetic algorithms applied to the problem of chemotherapy scheduling at St. James. The algorithm used in the prototype based on local search methods was intended to be a simple, fast running algorithm that still produced a reasonable solution. In Clark and Condotta s previous work, the local search method has been refined to a great extent and the implementation here is only intended to be a simplified version to provide a comparison towards developing a genetic algorithm. The investigation into local search methods will be relatively small to avoid repetition of previous work, whilst the genetic algorithm development is intended to be more extensive. 7.1 Test data To evaluate algorithm performance, a large test data set will be necessary to run the algorithms against. Ideally, this would be real data obtained from past events, although this is difficult to get due to the ethical issues surrounding the use of patient data. In order to get past these issues, a test data set will be randomly generated that matches the real world conditions as closely as possible. Data on the top 5 regimen schedules has been provided by Geoff Hall, meaning that intra-day schedules will be mostly accurate. The rest of the information will be based on average volumes and shift durations which have been verified by both Alessandro Condotta s figures, and meeting with the head nurse. A test data set of 1000 groups of patients was generated. Each group consists of a set of patients and the algorithms are given the task of assigning this group of patients to one nurse on one day. The data set can then be seen as 1000 days of schedules for one nurse and so a patient group will be referred to as a day from here on. To determine the performance of an algorithm, the algorithm will be run over all 1000 days and the results will be averaged. Each day of data contains 20 patients and the algorithms can be chosen to run on an arbitrary amount of patients. For example, if it is desired to run the algorithms on a realistic scenario, then 6 patients from each day will be chosen to include in the schedule. If we wish to see how the algorithm performs on easy situations where there are less patients or difficult situations where there are more patients we can adjust the amount selected. Above about 10 patients for one nurse the situation becomes extremely unrealistic and these figures have been included for pure interest alone. Each patient in the test data has been assigned one of the 5 regimens randomly with each having an equal chance. The 5 regimens contain 3 to 5 intra-day tasks with an average of 4. 23

30 7.2 Lower bounding In order to attempt to provide a constant measure of algorithm performance over schedules containing differing amounts of tasks, the number of clashes in the schedule generated by an algorithm, denoted C S, will be compared to the optimal number of clashes for the instance, denoted C O. The distance from optimality measure will be used to test all of the algorithms, given by C S C O. Each nurse works a 7.5 hour day giving a total of thirty 15 minute time slots. If we denote the number of slots in a day as N Slots, and define N Tasks to be the total number of tasks summed across all patients, then a trivial method for lower bounding would be: LB Trivial = max{0, N Tasks N Slots } (7.1) Since, if there are more tasks than available slots then the extra tasks must cause at least one clash each. Note that this is only a trivial lower bound and it may not be possible to achieve. The trivial lower bound cannot be less than 0 since a negative number of clashes is not possible, but from removing the <0 constraint, and switching the subtraction order, something that is not a lower bound, but a measure of slackness can be produced: N Slackness = N Slots N Tasks (7.2) If this measure is negative, then it is the same as -LB Trivial, but if it is positive then any schedule generated for these tasks that has 0 clashes will have N Slackness free slots. A tighter lower bounding method is discussed in [16], where the jobs are partitioned into two sets, the first contains the jobs that cannot interleave with any other jobs, and the second contains the remainder. The contribution of the jobs in the first set to the lower bound is the duration of the tasks and the wait times in between. The contribution of the jobs in the second set to the lower bound is only the duration of the tasks themselves. The method discussed is intended for coupled operation scheduling and to apply it to chemotherapy scheduling it would need to be extended to handle n jobs instead of just two. This would likely increase the time complexity and would be outside the scope of this project. Following is a table comparing the average results for these measures across all 1000 days of test data. 24

31 Patients LB Trivial C O N Slackness After around 9 patients, the value of C O increases linearly by about 4 with each patient added. This is due to reach regimen having an average of 4 intra-day tasks. The head nurse also mentioned that an hour was set aside for each patient on an appointment. From these results, it is clear that the trivial lower bounding method is quite accurate, giving a value equal or very close to the optimal solution. It is also easy to calculate and fast, running in polynomial time. For these reasons, all algorithms implemented in this project will calculate LB Trivial before running, and then can terminate immediately if they find a solution that satisfies C s = LB Trivial. It seems that by scheduling 6 patients for each day, a schedule with 0 clashes should be able to be found the vast majority of the time, and with little extra impact even days with 7 or 8 patients may be able to reasonably be scheduled. Schedules with a small number of clashes are not completely unworkable, and nurses will speed up their work to try and accommodate this. However, it was noted by the head nurse that a 90% full schedule is aimed for to provide a buffer for unforeseen events, so the primary focus for the scheduling algorithms should be to perform well on days with 6 patients. 7.3 Lunch break In Calum Clark and Alessandro Condotta s research, a nurse lunch break of 30 minutes was used. Although in the meeting with the head nurse, it was discussed that a break of around 45 minutes is more common, so 45 minutes will be used in this project. The lunch slot can be added as an extra task, occupying three time slots to be scheduled along with the other tasks for the current day. In [1], Calum Clark uses two approaches, one approach is to schedule all patients without the lunch slot and minimise clashes, then try to insert the lunch slot in a free space in the resulting schedule near the middle of the day. Another approach is to schedule the lunch slot along with the patients and assign solutions that end up with the lunch slot nearer the middle of the day a better score. In this project the lunch slot will be added with the patients at the start of the scheduling 25

32 algorithm like in Calum Clark s second method. Although in order to guarantee satisfaction of the nurses employment terms, the lunch slot will be constrained to starting between 11am and 2pm. The position of the lunch slot within this time frame will then not affect the solution s fitness as it will always be within reasonable bounds. 7.4 Clash enumeration The function that enumerates the number of clashes in the current schedule will be the most commonly called function from all of the algorithms, and so it is evident that it would be worthwhile to dedicate some time towards the optimisation of it, which will be briefly discussed here. An obvious implementation of this function that stems directly from the definition used in section is the following: Function CurrentClashes() Clashes 0 for i = 0 to L 1 do T asks 0 for j 0 to P 1 do for k 0 to P (j) T 1 do if P (j) S + P (j) T (k) = i then T asks T asks + 1 end if end for end for Clashes Clashes + min{0, T asks 1} end for Return Clashes Using this method, the clash density is summed across all time slots. Although a disadvantage is that checking every time slot is unnecessary. The efficiency can be greatly improved, and after some reconsideration the function was changed to the following: Function CurrentClashes() Clashes 0 T asks {} for i 0 to P 1 do for j 0 to P (i) T 1 do T asks T asks + (P (i) S + P (i) T (j)) end for end for QuickSort(T asks) for i 1 to T asks 1 do if T asks(i) = T asks(i 1) then Clashes Clashes + 1 end if end for Return Clashes 26

33 This method builds up a set T asks which contains a list of integers denoting the time of each task in the schedule. The list is then sorted by QuickSort and it is checked for duplicates. This results in a speed increase of around 10 times due to the removal of the unnecessary check against each time slot. For this reason, from here on all algorithms implemented in this project will use this optimised method of clash checking. 7.5 Local search The local search method described in section 6.3 was run on the test data set. In figure 14.1 the results are shown. Differing methods were tested to provide the initial seed solution. The first method was to place all patients at 9am. The second was to place patients at random start times, and the third was to place patients at sequential times so that each patient s first task starts when the previous patient s first task ends, although if this cannot be achieved due to arriving at the end of the day, the next patient starts from 9am. The seeding method seems to make little difference, with the random start method causing slightly more clashes on average. From here on, local search will use the 9am start method, as it is the least computationally expensive, and the other methods offer no gain. In the realistic case of 6 patients per day, an average of around 1.53 more clashes than the optimal is found, and 17% of the schedules produced are optimal. The distance from optimality peaks at 8 patients, and then tapers off, gradually reducing to 0. The problem seems easy to produce an optimal solution for when there are very few or very many patients and seems more difficult when the total number of tasks is close to being equal to the number of available time slots. This is logical, since if the total number of tasks is equal to the number of available time slots, then an optimal schedule requires a perfect interlacing of all patients, with no clashes and no free slots, which would likely only happen in a very small number of different arrangements. It is described in section 6.3 that the local search method tries every possible time slot for a patient before moving onto the next patient. This seems computationally expensive and it was assumed that a more efficient approach would be to move the patient s start time in small amounts and check whether this gives a benefit before moving further, using a hill climbing type method. An approach was tried that moved the start time up and down by one time slot to see whether either direction offered a benefit before carrying on in the most favourable direction. After testing against the dataset, this method turned out to be much worse and gave a distance from optimality of 7.48 for the 6 patient case. An explanation for this may be that the number of clashes does not gradually decrease as a patient is moved towards the optimal position but rather, suddenly jumps lower as the arrangement of intra-day tasks lines up with a series of gaps in the schedule. 7.6 Integer Linear Programming To provide another point of comparison, and to verify the number of clashes in the optimal solution for all instances of test data, an integer linear programming approach was investigated. It would start by taking two patients from the schedule and arranging them in all possible combinations of start positions. The combinations that resulted in a number of clashes equal to or less than the trivial lower bound would be kept and the rest would be 27

34 discarded. Then, using a recursive method, each patient from the schedule would be added in turn to the remaining combinations in all possible ways, producing a search tree. The search tree would again be pruned of all branches containing more clashes than the current lower bound. If all branches were eventually pruned from the tree and a dead end was reached, then this would prove no schedule exists with this many clashes, so the lower bound would have one added to it and the procedure would start from the beginning. Once the tree has reached it s deepest level, with all patients added to the schedule, and an example is found with the current lower bound number of clashes, the procedure exits. This method always finds an optimal solution to the problem by deterministic instead of stochastic methods. The ILP method takes around 2 seconds for each schedule to run for the 6 patient per day case. for the 8 patient per day case it takes around 60 seconds to run. 7.7 Genetic In order to run genetic algorithms on scheduling problems, the schedule must first be represented as a genome. The simplest way to do this is to store a list of integers, one for each patient representing their starting time, an additional integer is also added to store the start time of the lunch slot. In this way, there is no redundant information. All patients have a minimum start time of 9am and a maximum depending on how many tasks their intra-day schedule contains Procedure overview The general procedure for genetic algorithms below has been summarised from the detailed descriptions by Matthew Wall in [8] pp.31-32, Lawrence davis in [17] and David Goldberg in [18]. First, the population is initialised with a set amount of random genomes. If any duplicates are generated, they are removed to maintain genetic diversity. Each genome is then tested for fitness. In this project the amount of clashes serves as the most useful fitness measure. Genomes are then selected from the population for mating to produce child genomes for the next generation. There are many methods for selecting which individuals to mate, although all genetic algorithms rely on a higher chance of a genome being selected for mating if it has a higher fitness score. This project will use roulette wheel selection which is used in [8] and described in detail in [19]. The advantage of using this technique is that every genome has a chance of being selected, although genomes with a lower amount of clashes have a higher chance. A genetic crossover is then applied to the two parents to produce a child. The crossover can also be applied using different techniques, and the child genomes are usually mutated by a small amount after the crossover to reduce the chance of the population converging and getting stuck in a local optimum. This procedure is then repeated on each generation and if the operators are tuned well enough, the quality of the genomes in the population gradually improves. In [8], Matthew Wall also discusses the difference between non-overlapping and overlapping populations. Non-overlapping populations replace the entire population with new individuals 28

35 at each generation, whereas with overlapping populations, genomes from the current generation are copied to the next along with the child genomes resulting from crossover. Both methods will be tried here in order to evaluate the advantages and disadvantages of each Non Overlapping Populations The first test was run on a schedule of 6 patients per day with a population size of 100 genomes. Non-overlapping populations were used and crossover was used as the sole method for generating child genomes for the next generation. Two crossover methods seem most apparent. For each patient s start time in the child genome either the average of the two parent s start times can be taken, referred to as the averaging crossover method, or the start time for each patient can be randomly copied from one of the parents, referred to as the random choice crossover method. Both methods were tried. The results for using the averaging crossover method are shown in figure In the first few generations the average number of clashes in the population greatly increases. A limit then seems to be reached and the population is able to make a slight improvement before gradually worsening again. The random choice crossover method was then used and the results are shown in figure This method performs much better. The number of clashes in the population gradually decreases and the value of the best genome settles to an average of 0.93 clashes away from the optimal, with 56% of schedules being optimal. The distance between the best genome and the worst in the population still stays at around 3.4 clashes meaning that genetic diversity within the population has stayed quite high, which is an advantage of using non-overlapping populations. The averaging crossover method clearly produces much worse results than the random choice crossover method. In order to help understand why, a visualisation of the search space has been performed. The test data was searched for a day that the genetic algorithm so far could produce an optimal schedule for. The patients were then placed in the positions that gave an optimal solution. In figure 14.4, the effect of then moving the first patient s starting slot from 0 to 27 is shown. There are four places that the patient can be placed that will create an optimal schedule in relation to the position of the other patients, slot 14, 20, 24 and 27. It is then obvious that the averaging crossover method does not perform well because the average of two good slot numbers for placing a patient is not necessarily also a good slot. Another effect is that repeated application of the averaging crossover method will tend to move all patients towards the middle of the day, which is why the number of clashes seen in figure 14.2 generally increases. In figure 14.5 the search space in relation to two patients is shown and it is apparent that the search space has a high degree of unpredictability. Valleys and peaks seem to appear from nowhere meaning that this kind of problem does not lend well to hill climbing approaches where the algorithm tries to improve a solution by moving small amounts at a time within the solution space in the direction that improves the fitness the most. There is no gradual hill for the algorithm to climb. This would also add further evidence as to why the variation of local search that moved up or down by one slot at a time did not perform well Overlapping Populations The next approach that was tested was to use overlapping populations. This method again generates as many child genomes as the population size for the next generation. The parents 29

36 from the previous generation are also added to the next generation. This creates a population which is double the size that it should be. The population is then sorted by number of clashes and the worst half is discarded, maintaining the correct population size. This has the advantage that, once a good genome has been found, there is no risk of the algorithm discarding it unless a better one is found. The drawback of this approach is that the population may lose genetic diversity quicker and become stuck in a local optimum. The results for running this technique on the test data are shown in figure The population converges very quickly to an average best distance from optimality of The algorithm found a result matching the optimal for 81.1% of the schedules, 17.5% had 1 extra clash and 1.4% had 2 extra clashes. On a machine with an Intel i3 processor and 4GB of RAM this scheduling algorithm only takes around 0.7 seconds to run for each schedule. Therefore, increasing parameters such as the population size or the amount of generations would be acceptable as an effort to make the algorithm find an optimal solution on a greater proportion of the schedules. At a population size of 100, the algorithm seems to converge after around 200 generations and further generations offer no benefit, so the population size was increased to This gave a running time of around 1.1 seconds for each schedule and found a result matching the lower bound 99.8% of the time Increasing the amount of patients Since the genetic algorithm is almost optimal for the 6 patient case, it seems that this instance of the problem has been solved. Further improvements will not be apparent unless the algorithm is tested on a more difficult problem, and an extension to the project objectives was to test algorithm performance in busier scenarios than average and adapt to perform well in these. The time that the genetic algorithm takes to run is also very small and around the same as the ILP method. To provide a more difficult problem, the 8 patient case will now be tested. Optimal solutions contain on average 2.39 clashes for this problem, so the 8 patient case is also still realistic and it is likely that it will occur in practice every so often when there is a shortage of nurses or an abundance of patients. Therefore, it is believed that working on this instance of the problem will still be beneficial. The genetic algorithm was run on the test data for the 8 patient case with a population size of 100 and the results are shown in figure The average best distance from optimality is 1.10, with 21.5% of schedules optimal, 50% having 1 extra clash, and 26% 2 extra clashes. The running time is around 3 seconds Mutation Rate So far the mutation rate has been constant across all the genetic algorithms tested. There has been a 20% chance of every patient start time in a genome receiving an addition or subtraction of 1 time slot. Another method of mutating a genome would be to set a patient s start time to a completely random value within the feasible range. Both methods will be tested here. The former will be referred to as the 1 slot shift mutation method, and the latter as the random value mutation method. In [8] it is discussed that a too low mutation rate will cause the population to develop a low degree of diversity and possibly become stuck at a local optimum, whereas a too high mutation rate will cause the algorithm to only perform as well 30

37 as a random search. The effect of using different mutation rates and different mutation methods was tested and the results are shown in figure The method of setting a patient start time to a random value when mutating was able to give a better result than shifting by one slot, although this method seems to be very sensitive to the value of the mutation rate and gives a good result over a smaller range when compared to the one slot shift method. From here on the random mutation method will be used with a 12.5% mutation rate. With this improvement, the genetic algorithm produces an optimal schedule 27.9% of the time, 51.7% of schedules have 1 extra clash, and 19.4% 2 extra clashes Addition of random genomes At this point, an obvious way to improve the quality of the schedules produced by the genetic algorithm was to increase the population size from 100 to 1000 again. Although increasing the population size excessively can be seen as an artificial way to make up for the other operators of the algorithm being insufficient, and increases the running time. The fact that even a population size of 100 begins to stop improving after 100 generations would suggest that there is still not enough genetic diversity in the population, despite the improvements from increasing the mutation rate. A way of introducing fresh genetic material into the population is desired, and this can be given by inserting a small number of random genomes at each generation. The additional random genomes can be inserted at different stages of the algorithm. Recalling from section 7.7.1, there is a recombination stage, where child genomes are produced which are then added to the population along with their parents to create a population double the size, then a pruning stage to correct the population size. In the pruning stage the new children compete with the parents for inclusion in the next generation. The random genomes can be added directly before recombination, or they can be added after recombination but before the pruning stage. Both methods were tested and it was found that adding random genomes before the pruning stage offered little to no benefit. After a few generations it is likely that most of the genomes in the population have been optimised to some degree, and any new random additions have a low chance of achieving the same fitness level, so they are instantly out competed and removed by the pruning stage. Adding random genomes before the recombination stage produced better results, this gave them the chance to combine with genomes in the existing population that had been optimised. A graph is shown in figure 14.9 of the effect of adding different amounts. Only a small amount is needed, and adding too many is actually disadvantageous. The reason for this is that, to keep the population size constant, with each random genome added, a member of the current population has to be deleted, so adding a large amount of random genomes will cause useful genomes to be lost. Random genomes could be added without deleting members of the current population, but this would artificially inflate the population size. After setting the number of random genomes added per generation to 2, the genetic algorithm produces an optimal result 37.8% of the time, 50.3% of schedules have 1 extra clash, and 11.9% 2 extra clashes. 31

38 7.7.7 Hybrid approach In [17] chapter 4, hybrid genetic algorithms are discussed, where the genetic algorithm incorporates other well known algorithms to utilise the positive features of both. The genetic algorithm is usually combined with another algorithm that takes a seed solution and tries to improve it in some way, producing a solution that is better than or equal to the input. It is also desired that it is fast running. A few different methods of combining the two algorithms exist, one method would be to apply the genetic algorithm as normal, but randomly pick a few genomes per generation to be improved by the second algorithm and then re-inserted into the population. Other methods could include improving all random genomes that the genetic algorithm is seeded with at the first generation, improving the random genomes that are added to the population at each generation, or improving the child genomes resulting from crossover and mutation before re-inserting them into the population. For this project, a good algorithm to use would be the local search method described in section 6.3, as it generally produces a good quality result, and is quick to run so will not slow the genetic algorithm down when the two are hybridised. First tested was to run local search to improve a few genomes picked at random from the population at each generation. In the following table, the results of improving different amounts of genomes per generation are shown with respect to how often the hybrid algorithm produced an optimal result. Genomes improved Optimality % % % % % % % % This creates an obvious improvement and has little effect on the running time as only a few genomes are improved per generation. The benefits seem to decrease as the number of genomes improved per generation is raised above 5. The next approach tried was to also improve all random genomes that the genetic algorithm is seeded with at the first generation. This produced an optimal result 56.5% of the time. Improving all child genomes after crossover and mutation dramatically increases this to 87.8% optimal, and then improving all random additions increases this to 88.1% optimal. The running time is increased to around 5 seconds per schedule. 32

39 7.7.8 Summary The hybrid algorithm has been optimised to produce an optimal solution 88.1% the time for the 8 patient case. An analysis of the remaining 18.9% of schedules using ILP found that in most of these cases, only around 1 to 5 solutions yielded the optimal result out of tens of millions of possible combinations. So optimisation past this point may be extremely difficult and it was decided to use the remaining time of the project to work on further iterations of the web solution. Following is a concise description of the process that the most optimised genetic algorithm takes. Using a population size of P, and G generations: Calculate and record LB Trivial Generate an initial random population of P genomes Improve each genome by local search Record the number of clashes for each genome For each generation up to G: If the best genome has a number of clashes equal to LB Trivial, then terminate Generate P child genomes by the following process: Select two parents for crossover using roulette wheel selection Crossover the two parents using the random choice crossover method Mutate the child using the random value mutation method with a 12.5% mutation rate Improve the child using local search Add all children to the population Sort the population by number of clashes and discard the worst P + 2 genomes Generate two random genomes, improve them by local search and add them to the population Return the genome with the least clashes from the population When scheduling 6 patients per day, the local search optimisations can be removed at all stages. Scheduling more than 6 patients per day is more challenging and the local search optimisation is required. 7.8 Nurse Scheduling Up until this point, the algorithms have only ran on the problem of scheduling a small amount of patients to one nurse. In practice, the oncology ward of St. James will see around 60 patients per day that are scheduled to 10 nurses. In order to accommodate this, the problem of scheduling multiple nurses must now be considered. The test data set was extended to include 60 patients per day and the algorithms were modified to handle multiple nurses. 33

40 For the local search algorithm, an easy change can be made that divides the patients between nurses arbitrarily, giving 6 patients per nurse, and then improving each nurse s schedule individually as before. The results are around the same as seen in section 7.5, giving an average distance from optimality of around 1.5 clashes for each individual nurse. For the genetic algorithm, a change must be made to the way a genome is encoded, to include not only each patient s start time, but which patients are assigned to which nurse. At the beginning of the algorithm we can take the same approach as local search, in assigning 6 patients to each nurse arbitrarily. This is enough to achieve a good level of optimality with 99.1% of schedules produced being optimal. A further improvement is to add a section to the mutation stage of the algorithm that allows two nurses in a genome to randomly swap a pair of patients between them. This means that if a nurse has by chance received a group of 6 patients that do not interlace well, then there is a chance for this to be rectified. This increases the optimality to 99.8% and the algorithm takes around 10 seconds to schedule 60 patients. 34

41 Chapter 8 Web solution refinement At this stage, the genetic algorithm that had been optimised in the previous section was copied to the part of the website that scheduled the intra-day appointments so that more optimal schedules would be produced. This also required some user interface changes, particularly for the nurse scheduling aspect, the site needed to display which nurses were assigned to which patients, this will be shown in section 8.2 along with the other changes made to the intra-day page. Feedback on the prototype had also been received back from staff at St. James. The feedback was sufficient enough to perform a second iteration refinement of the solution. All high priority requirements were satisfied in the first iteration, so this iteration will mainly focus on medium priority requirements. Firstly, the medium priority requirements from the first iteration will be recalled, and these will be implemented. 8.1 Previous requirements From the medium priority requirements discussed, the first was to aim for a 90% full schedule when arranging appointments. This was satisfied during the algorithm development stage by demonstrating that an optimal solution can be found in most cases for the 6 patient per nurse per day case. Due to each patient taking on average an hour of nurse time, with a 7.5 hour day and a 45 minute lunch, the 6 patient case satisfies a 90% full schedule. The second medium priority requirement was to support most modern browsers and platforms. Staff at St. James have identified Internet Explorer as the main browser used within the hospital due to being pre installed on all Windows machines. When the site was sent to staff at the hospital for review, anonymous usage statistics were recorded that included the browser type and version. Internet Explorer was confirmed as the main browser, with Google Chrome and Firefox being second and third most used respectively. In order to ensure compatibility the website was tested in all three of these browsers for functional and visual aspects. The site performed well functionally in all browsers and no browser specific errors were found. There were some slight visual changes such as rendering of thicker borders and margins in Internet Explorer, an incorrect font applied by Firefox along with rendering of the font a few pixels further down than the other browsers. No problems were found in Google Chrome as this was used as the browser during development. The visual differences were able to be fully corrected by adding browser specific style sheet rules for the borders and margins, and by using a different font which was more widely recognised. The third medium priority requirement was to have a help section on each page explaining how to use the system. This was also satisfied at this stage by adding a pop up dialog to each page. The help text used can be found in section

42 8.2 Additional requirements The additional requirements discussed here have been gathered from staff at St. James and the presentation which was discussed in section 6.5, they will be presented here in medium and low priority. Medium priority The regimen list only contains a few regimens. In real life there would be hundreds. This means that a simple drop-down list is insufficient and a more complex method should be used. This should include an auto-complete feature. Display a time span between the individual tasks on the intra-day schedule so that the amount of time between jobs does not have to be manually calculated. With large numbers of patients, the intra-day page will be too cluttered. An option to display a compact view should be available. Allow schedules to be manually altered as well as automatically arranged. Low priority: On the Multi-Day page, the appointment days could be colour coded to enable you to easily see which days have the same intra-day schedule without having to actually view the schedule. When adding or editing a regimen, display a warning if the user clicks next without saving, so that their changes are not lost. Display a bar chart or histogram that is based on the amount of tasks in each regimen that each patient is on so that workload can be estimated more accurately. For the first medium priority requirement, the drop down list on the regimens page was converted to an auto-complete. Using this method, the user only has to enter the first two characters of the regimen name, and a list is then displayed showing the regimens that begin with the text entered. The user can then select a regimen in a faster way than before. Although this now means that the user cannot see a list of all regimens before entering their choice. A pop up dialog was added that would have a scrollable list of all regimens. Both of these functions are shown in figure 13.11, the dialog shown would remain the same size, and become scrollable if hundreds of regimens were present in the system. For the second medium priority requirement, a display of the time span was added between the intra-day tasks on the regimen, patient and intra-day pages. The intra-day page was also modified to show the option of choosing between a compact or detailed view to satisfy the third requirement. The algorithm for scheduling the patients can also be chosen as local search or genetic. The help section describes the advantages and disadvantages of using either algorithm. In figure the new intra-day page is displayed, and in figure the compact view is shown. At this stage, the intra-day page was also modified to show individual nurse schedules which were output by the scheduling algorithms. This is shown in figure The headers for each nurse appear after the user clicks Arrange automatically. Nurses on the ward can then decide between themselves which timetable to take. 36

43 Also added was a set of buttons that allowed the user to manually alter a schedule after automatic arrangement. This can also be seen in figure A plus or minus button appears below each patient to move them up or down, this allows a nurse to make modifications to a schedule to fine tune it to their needs. 8.3 User Evaluation At this stage, the website had had a second iteration of improvements made to it and most of the development was finished. In order to help evaluate the site, the feedback section was improved by adding the ability to rate each page depending on a range of criteria. A screen shot of the feedback page is shown in figure and The website was then sent to a larger audience for a second review. This included more staff from St. James and clinicians, software developers and graphic designers from the software development company X-Lab Ltd. which has in the past developed software for St. James. The feedback section contained several areas for the users to rate. One area was the usability which related to how easy the system was to use, whether it could be made less complicated and whether the speed of carrying out tasks can be reduced. Another area was feature completeness. The users were asked from their knowledge of chemotherapy, whether the site contained all features required to operate effectively in practical use. The third area for the users to rate was the design of the site, and whether the colour scheme, fonts or layout could be improved. The final area for users to comment on was whether there were any bugs or errors. The users were quicker to respond at this stage, assumedly because the feedback section meant that they were able to easily record their responses and quickly rank each page on a scale. As the responses came in, a third iteration of development was considered, but due to the amount of time remaining, it was decided that it would be more beneficial to begin working on the evaluation of the project, and to use the responses for this purpose. 37

44 Chapter 9 Evaluation In order to evaluate the work done during this project the evaluation will focus on how well each of the objectives and minimum requirements have been met that were outlined in section 2.2 and 2.3. The quality of the web solution will be evaluated by assessing how well the requirements were met, how well the selected methodology worked, and by using user feedback. The algorithms will be evaluated by comparison to each other and to methods used by past research. 9.1 Research The first objective was to research the current method used to schedule appointments in order to ease development of a software solution. 3 members of staff at St. James were interviewed to help meet this objective and their help was of great value to the project. Geoff Hall provided feedback from a clinical point of view. He helped to describe how scheduling is done at the moment, how different types of cancer and regimens affect the scheduling process and how a web solution could benefit the hospital. Andy Shaw provided points from a technical perspective, including the limitations and requirements that a web solution would be subjected to and existing software solutions in the hospital that would need integrating with the system. The head nurse provided information on nurse working methods, their terms of employment such as start times, finish times and lunch slots, and the volumes of patients and nurses that the ward generally sees. All important points from the meetings were noted in the project and used for requirement gathering. From the information gathered during the investigation stage, a process model was defined in section 5.3 that outlined the course of treatment a patient went through starting from diagnosis. This was a helpful tool to reference during building the web solution and made sure that no steps of the process were missed. Therefore, this objective has been satisfied. If more time was available, it would have been useful to interview more staff from St. James to get a broader range of opinions and different points of view. 9.2 Web solution The second objective highlighted was to create a software solution that allows automatic scheduling of appointments to be more freely accessible to staff at St. James. In order to make sure the solution was adequate, a number of requirements were collected from points highlighted in meetings and relevant literature. The requirements were separated into high, medium and low priority to ensure the most important were worked on first Requirements The high priority requirements were features that were essential for the system to function. All of these requirements were met in the first iteration and this was verified by the fact that the 38

45 user review highlighted no new high priority requirements. The site was also able to provide all inputs to the scheduling algorithms used, such as details of regimen and patient schedules. The medium priority requirements focused on ease of use and accessibility. These were all satisfied during the second iteration, and the process of adding regimens and scheduling patients became more streamlined and user friendly. One of the medium priority requirements raised was for the site to work well in most modern browsers and platforms. After this requirement was satisfied, the site was more freely accessible across the hospital and the accessibility part of the objective was fulfilled. The low priority requirements were useful ideas that could have been implemented but were not essential to the system. In the end, there was not enough time to implement all of these requirements but it was useful for the project to gather them. If the web solution is developed further after this project then they could be implemented at a later date. Other students or researchers working on a similar project may also find them helpful for their work. Two of the extensions to the project were also fulfilled by prioritising them appropriately in the requirements. The first was to allow manual scheduling of tasks as well as automatic scheduling. This allowed a nurse to modify a generated schedule to suit their specific needs. The second was to allow re-scheduling of appointments in case of complications or cancellations, this could be achieved by editing a patients schedule on the patient page and then switching to the intra-day page and clicking Arrange automatically to optimise the changed schedule Methodology The impact of using an agile development methodology with an iterative approach was mainly positive on the project. A disadvantage was that each iteration had to go through the phases of requirement collection, development and review, which slowed things down and meant that only two iterations were able to be completed. Although the advantage of using this methodology was that all requirements were prioritised and timeboxed, so that the high priority requirements were finished by the end of the first iteration and the medium priority requirements were finished by the second iteration, meaning that the most productive use of time was made and only low priority requirements were left out. In the best case scenario, a third iteration of development would have taken place after the user evaluation to refine issues raised by the feedback. Although once the feedback had been collected in, the project ran out of time and the feedback was only able to be used for evaluation purposes. As discussed previously, each iteration took more time than desired, but the effect of this was mitigated slightly by sending out feedback requests before working on algorithm development so that by the time this stage was finished, a reasonable amount of users had responded. Although the project could have gone more smoothly if feedback requests were sent earlier on and to more users. A problem that arose towards the end of the first iteration was that the individual nurse scheduling aspect began to take a prohibitively long time to complete. This was due to the fact that the changes required were to alter the scheduling algorithm to handle multiple nurses, and also to make changes to the intra-day page to display the results. It was then decided that the nurse scheduling aspect would be assigned medium priority and worked on in the second iteration. The reason for this was that the first iteration needed to be finished 39

46 quickly in order to send feedback requests out as soon as possible, and the nurse scheduling aspect was considered to not be as essential for this round of feedback. The agile methodology adopted helped here, as the flexibility of the method allowed this task to be easily shifted to the second iteration without interrupting the flow of work User Review The feedback collected from the users was generally positive, and on average it received high ratings on the scales included in the feedback page. Out of 23 responses, an average of 8.3 was recorded for usability, 9.2 for feature completeness, and 6.5 for design. The feature completeness would be considered the most important of these ratings for this project as this would enable the site to be used in practice with few extra modifications, so the high rating for this aspect is very positive. One comment received regarding feature completeness spoke about how patient details such as their name and regimen would not be entered in this system if used in practice, but instead the site would need to link to an existing system in the hospital called ChemoCare and retrieve the patient details from there. This would obviously be outside the scope of this project, but is an important point to consider if the system is developed further or if others work on a similar project. The usability also ranked well and it is believed that this rating was helped by the satisfaction of the medium priority requirements in the second iteration, which focused mainly on ease of use. The suggestions received for this aspect included using the autocomplete feature on more areas of the site, warning the user of unsaved changes when closing a dialog and the inclusion of more help text. The design of the site was ranked well, but not as highly as the first two aspects and it is believed that this was due to the simplistic layout and colour scheme. The project intentionally focused more on functionality than design, and this consequence was expected to a small degree. Some suggestions received were to make more use of colour, for example to colour code days on the multi-day schedule so that it was easy to spot which days have the same intra-day schedule. Other suggestions were aimed at trying to make the layout less cluttered and more aesthetic. If there were remaining time for a third iteration, then these comments would have been incorporated into the requirements for that iteration Summary Due to the satisfaction of most of the gathered requirements, and from the positive user feedback received, it is believed that the web system is a big step towards something that can be used in practice, and future work would possibly be able to take this further and integrate it with the existing systems in the hospital for real world use. To this extent it is believed that this objective has been met. The development of a web solution to provide the input and output mechanisms for the scheduling algorithms seems to have not been attempted before in the literature, and so it is believed that this project was a great help towards making scheduling algorithms more accessible to staff working in this field. In previous work the accessibility was restricted due to the reliance on commercial software [2], or due to the user interface being limited in functionality [1], which were both obstacles that were overcome by the implementation of a freely available web solution in this project. 40

47 9.3 Algorithms Satisfaction of Objectives The first objective relating to scheduling algorithms was to research existing algorithms that are applicable to the problem and pick a select few to be adapted and implemented in a software tool, or to formulate and implement new algorithms. A range of methods were highlighted in the literature that were applicable to the problem and an overview of the most common methods was given. A potential new area of research was highlighted in genetic algorithms. Firstly, two relevant methods discussed in the literature were applied to the problem, local search and integer linear programming. In previous work by Clark [1], and Condotta [2], these methods had been heavily optimised, and to avoid repetition of previous work a simplified approach was taken for both of these algorithms. Local search turned out to be a very quick algorithm that still produced a reasonably good result. Integer linear programming always found the optimal solution but became slower as the number of patients was increased. An investigation into genetic algorithms and the application of different genetic operators and parameter values then took place and resulted in a high quality algorithm that was able to produce an optimal solution in 99.8% of cases for the 6 patient per nurse case, and 88.1% for the 8 patient per nurse case. To this extent it is believed that this objective has been met, and a comparison of the algorithms to previous approaches will be made in section Another objective was to take into account staff terms of employment whilst building a schedule. Such as lunch breaks and shift durations. It was decided early on in the project that an extra constraint would be added to ensure that the lunch break was always placed between 11am and 2pm. The patient tasks were also constrained to occurring between 9am and 5:30pm. This ensured that the staff terms of employment were always fulfilled, and so this objective was met. The final objective relating to scheduling algorithms was to make an attempt to assess schedule quality using metrics such as amount of appointments fulfilled, amount of staff breaks allowed and number of appointment clashes. The scheduling algorithms produced performed very well in these regards, using the technique of splitting patients across nurses so that a large amount of patients could be handled meant that in the majority of cases all appointments could be fulfilled. If a situation where a large number of patients or a shortage of nurses occurs then the algorithm can be easily altered to assign 7 or 8 patients to each nurse and still perform very well. In this way, the chances of having to reschedule a patient s appointment due to ward business is reduced. As discussed previously, the lunch break has been constrained to be always present, and to occur at a reasonable time, so the conditions of staff breaks are always met. The genetic algorithm demonstrated also produces very good results in terms of number of clashes. In addition, an extension to the project was to test algorithm performance in busier scenarios than average and adapt to perform well in these. This was also fulfilled by working on the 8 patient per nurse case and ensured that the performance of the algorithm would not suffer to a significant degree in busy scenarios. 41

48 9.3.2 Comparison to previous work The results of applying the genetic algorithm developed to schedules with 6 patients per nurse produces an optimal solution the vast majority of the time (99.8%), and runs very quickly, finishing in just over a second. The 8 patient per nurse case is slightly less optimal at 88.1%, but this is still a high quality result, and a solution is produced in around 5 seconds. In comparison, Condotta in [2] produces a result in around 60 seconds on a machine with similar specifications for schedules with between 6 and 8 patients and Clark in [1] produces a result in around seconds. It then seems that the genetic algorithms applied are a relatively fast running method, that performs almost optimally in the most common case of 6 patients per day, and loses some accuracy as the number of patients is increased but still performs relatively well. In section 7.8 the method of scheduling a large group of patients to multiple nurses is discussed and modifications are made to the algorithms to handle this. Multiple nurse scheduling is investigated by Condotta in [2], but not by Clark in [1]. It is believed that the genetic algorithms in this project have an advantage over integer linear programming in this aspect, as their speed is not affected as drastically by the challenge of having to schedule many patients to many nurses. In comparison, deterministic methods would have to assign a group of patients to each nurse and then optimise each nurse s schedule individually, so the time taken rises linearly with the number of nurses. With the genetic algorithms used in this project, the entire group of patients and nurse assignments is represented in each genome, so once a good genome has been found, this will represent a solution to the whole problem instead of just one nurse. In the authors experience, finding a good genome does take longer when more nurses are added, but the increase in time is sub-linear. Early on in the project, it was decided that the lunch break would be constrained to always occur between 11am and 2pm, this approach is also taken by Condotta in [2], but not by Clark in [1]. Clark allows the nurse lunch break to be placed at any time of day, but assigns solutions a lower fitness the further away the lunch break is from midday. This could allow some solutions to have the lunch break placed at a time outside of the nurses terms of employment. A positive result of this project was that this constraint could be applied whilst still producing a high quality schedule. 9.4 Extensions At each stage of constructing the genetic algorithm, there were many techniques for applying each genetic operator and the project was only able to investigate a handful of these due to time constraints. A possible extension would be to investigate other techniques for applying each operator to see if these would be beneficial. In [20] the technique of crossing over more than two parents to produce one child is discussed and is referred to as Gene pool recombination. To investigate this, an easy change could be made to the crossover function that would cause it to pick n parents by roulette wheel selection, then the start time of each patient in the child genome would be randomly selected from the group of n parents. This would be interesting to investigate as clearly it would have an effect on the genetic diversity of the population. Another area to investigate would be to use a different method for selection of parents than roulette wheel selection, which was used throughout the project. Other methods that could be applied would be to only allow a small percentage (such as the top 10%) of genomes to 42

49 reproduce, or to select parents using a uniform random probability distribution, which may hinder the best genetic material from recombining as often but improve genetic diversity. For the 8 patient case, the genetic algorithm was 88.1% optimal and an analysis of the remaining 18.9% of solutions found that in most of these cases, only a handful of possible solutions yielded the optimal result out of tens of millions of possible combinations. So optimisation past this may be difficult, possibly requiring a much larger population size. But as highlighted, there are also a wide range of other methods for further research to explore. It is likely that the parameters of the genetic algorithm are only optimal in relation to each other, and could be fine tuned further. For example, different values for the mutation rate were tested, and it was found that 12.5% was optimal. The mutation rate was set to 12.5% and then other parameters were explored, such as adding differing amounts of random genomes to the population at each generation, changing the population size, and then improving a small amount of genomes by local search. After applying all of these changes, it is highly unlikely that the optimal mutation rate stayed at 12.5%. If the mutation rate were to be improved again, then the optimal value of another parameter would be likely to change. Investigating repeated tuning of the parameters would be an interesting extension to the project. A process of cycling over all parameters, improving each in turn and then returning to the first can be imagined, but would take an extremely long time, and would be likely to over fit the parameters to the test data. One can even imagine meta-genetic algorithms that fine tune the parameters of other genetic algorithms. This would of course be a whole project in itself but could yield very interesting results. 43

50 Bibliography [1] Clark, C Scheduling Chemotherapy Appointments: A Heuristic Approach. Final year project, University of Leeds. [2] Condotta, A Scheduling with due dates and time-lags: new theoretical results and applications. Phd thesis, University of Leeds. [3] Condotta, A. Shakhlevich, N. V Scheduling coupled-operation jobs with exact time-lags. Discrete Applied Mathematics 160 (16-17), [4] Orman, A.J. and Potts, C.N On the complexity of coupled task scheduling. Discrete applied mathematics. 72(1-2): [5] Gabay, M, Finke, G and Brauner, N Identical Coupled Task Scheduling Problem: The Finite Case. ISCO 2012, 2nd International Symposium on Combinatorial Optimization, Athens, Greece. [6] Mancilla, C and Storer, R Stochastic Sequencing and Scheduling of an Operating Room. Lehigh University, Department of Industrial and Systems Engineering. [7] Condotta, A. Shakhlevich, N. V Scheduling patient appointments via multilevel template: A case study in chemotherapy. School of computing, University of Leeds. [8] Wall, M. B A Genetic Algorithm for Resource-Constrained Scheduling. Ph.D. thesis, Massachusetts Institute of Technology. [9] Beck, Kent et al Manifesto for Agile Software Development. Agile Alliance. Available from: [accessed 1st March 2014] [10] Sommerville, I Software Engineering, 8th edition. Addison Wesley. [11] International Institute of Business Analysis A Guide to the Business Analysis Body of Knowledge. [12] Hughes, B. Cotterell, M Software Project Management, 5th edition. McGraw-Hill Education. [13] Cancer research UK [Online] [Accessed 6th March 2014]. Available from: [14] Watson, S. A Porting a High Performance Computing Application to an Elastic Cloud. Final year project, University of Leeds. [15] Random name generator [Online] [Accessed 20th March 2014]. Available from: [16] C. N. Potts and J. D. Whitehead Heuristics for a coupled-operation scheduling problem. Journal of the Operational Research Society, 58(10): [17] Davis, L Handbook of genetic algorithms. Van Nostrand Reinhold, New York 44

51 [18] Goldberg, D. E Genetic algorithms in search, optimization and machine learning. Addison Wesley Longman Inc. [19] A. Lipowski Roulette-wheel selection via stochastic acceptance (arxiv: ) [20] Winter, G. Periaux, J. Galan, M. et al Genetic algorithms in engineering and computer science. John Wiley & sons. 45

52 Chapter 10 Appendix A: Personal Reflection I felt that working on this project was a great experience in how different skill areas that I have learned during my degree can be brought together to solve a challenging practical problem. The project focused on two main avenues, the web solution and the algorithms. This meant I had to combine my knowledge of web development and user interface design with my theoretical skills of algorithm design and combinatorial optimisation. I also learned a few useful skills along the way such as how to extract clear requirements from an interview with clients, how to use a handful of new Javascript libraries that make the most of HTML5 and how to set up hosting for a website in the cloud with auto scaling. An hobby of mine many years ago was developing genetic algorithms that evolved creatures which could walk in a physics engine. It was interesting and enjoyable to return to using genetic algorithms again in a different scenario. A lot of methods that I had investigated previously were also applicable to this problem but sometimes gave different results. This meant that my expectations were constantly being challenged and I had to come up with new ways of thinking about the problem to explain why the techniques gave the results that they did. I would say to anyone conducting this kind of research in the future, that throwaway prototyping is very useful methodology to explore as many avenues as possible. A lot of the time there were many differing ways of applying a genetic operator, such as different ways to mutate a genome for example, and it was valuable for the project to investigate all of these, and pick the best one before continuing. Conducting a visualisation of the search space was also helpful, as then it was instantly apparent as to which techniques would work best with the problem such as hill climbing or non hill climbing methods. Dedicating time to the project every day for a whole semester requires a lot of will power. Although the fact that the project had a real world application, and could possibly help people facing cancer treatment was a big motivation and this encouraged me to put my full effort into the project. A recommendation to future students when choosing a project is to not only choose something that you are interested in, but choose something that you believe is a productive problem to solve, which will help to keep you motivated. A note to anyone undertaking work where interviews and user feedback are required, is that appointments and feedback requests should be made as early as possible. Staff at hospitals can be very busy, having their diary fully booked weeks in advance and it is difficult to organise meetings to be within the correct stage of the project. Of course, this does not just apply to hospital staff and is a lesson to learn for any client interaction. It was lucky that in this project, appointments were arranged early on to make sure that the requirements could be gathered with an adequate amount of time remaining to implement the solution. 46

53 Chapter 11 Appendix B: Materials Used In order to develop the web solution for this project, Microsoft Visual Studio Express 2013 and SQL Server Express 2012 were used. The express editions Microsoft provides are free to use for any purpose but have limited features. In the author s experience, these limitations are extremely minimal and did not impact the project in any way. A small number of open source Javascript libraries were used to ease the development of the website and to provide extra functionality. Moment.js was used to format dates for the calendar displays and is available at: Easel.js was used to draw the graphics for the calendars, multi-day and intra-day appointments and to provide animation. This is available from Finally, to enable use of the previous libraries, and to ease working with HTML elements, Jquery js was used which is available from Much appreciation goes to the developers of these libraries for making the web an easier place to write code for. 47

54 Chapter 12 Appendix C: How Ethical Issues Have Been Addressed When creating any systems that store patient information such as the web solution in this project, there is the concern about how the information is stored and who is able to access it. Using real patient data would have made the algorithm testing very accurate, but this would have been difficult to obtain and would have carried the risk of patient information being exposed. Therefore it was decided that the test data set for the algorithms would use random data, but with the regimen tasks and the volumes of patients and appointments per day being correct, so that the algorithms could be tested accurately. The website also uses test data, with a random name generator used for making fake patients. The website also has a feedback section for gathering comments and ratings to evaluate the site. There is a link to the project information sheet that describes the project, why feedback would be helpful, and how the feedback will be used. It is made clear to the users that they are free to answer as many or as few questions as they choose and that they are able to withdraw their feedback at any time. It is also made clear that the results are stored anonymously and the user will not be able to be identified from their responses. Consent is given by check boxes and the form will not submit unless all check boxes have been ticked. NHS staff were also interviewed during this project. Similar to above, it was explained to the staff that their participation was voluntary and they could withdraw at any time. Their written consent was obtained before they were named in the project. 48

55 Chapter 13 Appendix D: Screenshots and help text 13.1 Screenshots Figure 13.1: The Home page. 49

56 Figure 13.2: The Regimens page. 50

57 Figure 13.3: The first first screen of the edit regimen dialog. 51

58 Figure 13.4: Editing the intra-day schedule of an appointment day. 52

59 Figure 13.5: The patients page. 53

60 Figure 13.6: The add patient dialog. 54

61 Figure 13.7: The first screen of the edit patient dialog. 55

62 Figure 13.8: Editing the intra-day schedule of a patient. 56

63 Figure 13.9: The Multi-day page. 57

64 Figure 13.10: The Intra-day page. 58

65 Figure 13.11: A screen shot showing the auto complete feature of the regimen selector, and the list of all regimens. 59

66 The Intra-day page after improvements from user feedback in the second itera- Figure 13.12: tion. 60

67 Figure 13.13: The Intra-day page in compact view. 61

68 Figure 13.14: The intra-day page showing multiple nurses. 62

69 Figure 13.15: The beginning of the feedback page. 63

70 Figure 13.16: The end of the feedback page. 64

71 13.2 Help text Following is the help text that is included on each page of the web solution which helps to explain how to use the system Regimens Page To view a regimen, first select it from the drop down list. On the multi-day schedule, appointment days for the current regimen will be highlighted on a grid. Day numbers are relative to the first day of treatment. The intra-day schedule shows the individual tasks that are performed on a single day of treatment. Times are relative to the first task. The day number can be selected from the drop down to view the intra-day schedule for that day. When editing the current regimen, the name of the regimen and the appointment days can be changed. Enter the appointment days as a comma delimited list. You can then click next to step through the appointment days and add or delete intra-day tasks for each day. The same process applies for adding a regimen Patients Page The drop down list displays a list of patient IDs. When a patient is selected, their current regimen and start date is shown. Their appointment dates are also highlighted on a calendar. When adding a patient their regimen and start date can be chosen, the schedule of the chosen regimen is then copied to the patient, and the patient s schedule can be further edited independent of the regimen. When editing a patient their appointment dates and intra-day tasks can be changed Multi-Day Page To show appointments for a particular month, select a date from the calendar. Appointment dates for all patients are then shown on a grid Intra-Day Page When a date is selected, the intra-day schedules for all patients with an appointment on that day are displayed. Initially, all appointments start at 9am. To arrange the appointments into a more efficient order, click Arrange automatically. The server will run a scheduling algorithm to try and minimise the number of clashes. Once the results are obtained, the appointments will move to their designated positions and any clashes will be highlighted in yellow. Different scheduling algorithms can be chosen. Local search is very fast but might not always find the optimal schedule. Genetic takes longer but generally produces a better schedule with less clashes. 65

72 Chapter 14 Appendix E: Charts and graphs Following is a collection of charts and graphs that are referenced in the main body of the report. For all graphs, Distance from optimality is an average across all 1000 days of test data. When displaying charts for genetic algorithms, Best refers to the distance from optimality that the best genome in the population had at that particular generation, averaged across all 1000 days, Average refers to the average distance from optimality of all the genomes in the population, and worst refers to the worst genome in the population. Figure 14.1: Application of local search to differing amounts of patients per schedule with differing seed methods. 66

73 Figure 14.2: Application of a genetic algorithm using average crossover and non-overlapping populations. Patients = 6, Population size = 100 Figure 14.3: Application of a genetic algorithm using random crossover and non-overlapping populations. Patients = 6, Population size =

74 Figure 14.4: A bar chart showing the number of clashes in relation to the position of patient 1 within a sample schedule. Figure 14.5: A bar chart showing the number of clashes in relation to the position of patient 1 and patient 2 within a sample schedule. 68

75 Figure 14.6: Application of a genetic algorithm using overlapping populations. Patients = 6, population size = 100. Figure 14.7: Application of a genetic algorithm to the 8 patient per schedule case. Population size =

76 Figure 14.8: The effect of varying mutation rates on two different mutation methods. Best fitness after 250 generations, Population size = 100, patients = 8. Figure 14.9: The effect of adding differing amounts of random genomes to the population at each generation. Best fitness after 250 generations, Population size = 100, patients = 8. 70