Hospital Task Scheduling using Constraint Programming

Transcription

1 Hspital Task Scheduling using Cnstraint Prgramming Authr: Chaman Chahal Supervisr: Dr. P. Bse, Schl f Cmputer Science Organizatin: Carletn University Curse: COMP4905 Date: Dec. 11,

2 Abstract Hspitals strive t minimize patient wait times and minimize the amunt f time patients spend in the hspital (thus freeing hspital beds), while ensuring that all patients receive the necessary treatments and attentin. Wrking twards these gals, this prject cnsists f a tl t help physicians schedule their tasks such that it minimizes the time that patients stay in the hspital, while taking int accunt cnstraints such as resurce cnflicts and travel time between tasks. This tl must slve an NP-Hard scheduling prblem, s it uses the cnstraint prgramming and scheduling features f IBM ILOG CPLEX Optimizer t find an apprximate slutin. By adjusting the CPLEX engine t have greater ptimality tlerances, this tl is capable f slving large scheduling prblems in shrt perids f time. Table f Cntents Gals and Methd Overview f Implementatin Small Examples and Use Cases Scaling Up t Larger Prblems Pssible Future Prjects Gals and Methd Gals The gal f this prject is t explre the pssibility f creating a new tl that will help hspitals and physicians ptimally schedule their tasks. This will help minimize the amunt f time patients need t stay in the hspital, thus freeing beds and lwering wait times fr ther patients. Hspitals are a cmplex envirnment, s there are many cnstraints that must be cnsidered when trying t find an ptimal schedule, including: Which physicians/wrkers are allwed t cmplete which tasks. (Fr example, a triage physician wuld be allwed t cmplete different tasks than a cardilgy specialist). Travel time between tasks. (Many hspitals are very large, s it takes a significant amunt f time t g frm ne end f the hspital t visit a patient n the ther end). Resurce cnflicts (Fr example, tw patients might bth need t get an x-ray when there is nly ne machine available, r physicians frm tw different specialties might bth need t check up n the same patient.) Task Precedences (Many hspitals fllw business prcesses that cnsist f series f tasks that physicians and wrkers must cmplete in a particular rder) 2

3 One ther imprtant factr that shuld be cnsidered in a real-life prblem that the tl created in this prject did nt cnsider (due t added cmplexity f the implementatin) is that tasks that directly lead t patients being discharged frm the hspital shuld be priritized ver ther tasks, as that wuld free hspital beds fr new patients t cme in. Here is a precise definitin f the hspital-scheduling prblem that the tl created in this prject slves: Methd Inputs: A list f lcatins and a matrix specifying travel times between lcatins A list f tasks including the lcatin and duratin f each task A list f task precedences (which tasks must be dne befre which thers) Lists f tasks with resurce cnflicts (which cannt be dne at the same time) Start times fr any tasks scheduled t start at a specific time Latest start times fr tasks with deadlines A list f wrkers, including their current lcatins Fr each task, a list f wrkers allwed t cmplete that task Output: Fr each wrker, an rdered list f tasks that minimizes the time it takes fr the last task t be finished (i.e. minimizes the makespan). All cnstraints specified in the inputs must be fllwed. The scheduling prblem this tl seeks t slve is NP-Hard. S, the prblem was mdeled as a cnstraint prgramming prblem and IBM ILOG CPLEX Optimizer (available frm the IBM Academic Initiative) was used t prduce apprximate slutins. Defining a cnstraint prgramming prblem in CPLEX is very similar t defining an integer prgramming prblem, but CPLEX allws yu t use a larger set f functins than wuld be allwed in an integer prgramming prblem, including sme functins specifically designed t help mdel scheduling prblems. Prf that the prblem is NP-Hard Cnsider the NP-Cmplete k-clr prblem: decide whether r nt the vertices f an undirected graph G can be clred with at mst k clrs such that n tw adjacent vertices share the same clr. Here is hw this prblem can be reduced t the hspital-scheduling prblem specified abve: Fr each nde in G, create a task with a duratin f 1. (Each nde crrespnds t a task). (Give all tasks the same lcatin, s there is zer travel time between tasks). (Any wrker may cmplete any task). (There are n task precedences, s they may be cmpleted in any rder). Fr each vertex in G, create a wrker. (All wrkers start at the same lcatin as the tasks). 3

4 Fr each edge {u,v} in G, create a resurce cnflict between the tw tasks that crrespnd t vertices u and v. Slve the abve hspital-scheduling prblem. Let t be the time it takes fr the last task t get finished. if ( t k ) then G can be clred with at mst k clrs such that n tw adjacent vertices share the same clr. (All vertices/tasks that are finished at time 1 can be given clr 1, thse finished at time 2 can be given clr 2, etc.) S, in the general case, this hspital scheduling prblem is NP-Hard. Overview f Implementatin There are three main cmpnents in this tl: The Scheduler itself, An Andrid app t allw a physician t view their rdered task list frm anywhere, A main methd allwing a tester t act as the external cmpnents that the system depends upn. Scheduler The Scheduler has tw subcmpnents: a Java cmpnent and the CPLEX mdel / CPLEX engine. The Java cmpnent is simply fr string the state f the hspital. It stres a list f wrkers, tasks, and all the cnstraints n the tasks. When its cmputeschedule() functin is called, it sends the state and cnstraint data t the CPLEX engine t slve the scheduling prblem, frmats the utput and sends the utput t any cnnected Andrid apps. The Java cmpnent als peridically updates the time remaining fr tasks that are in-prgress and tasks with deadlines. The cde fr this cmpnent is primarily in Scheduler.java. The CPLEX engine takes the data frm the Java cmpnent and utputs a slutin t the ptimizatin prblem based the CPLEX mdel. The CPLEX mdel fr the hspital scheduling prblem is fund in the file cplexmdel.md. The CPLEX mdel cntains an OPL (Optimizatin Prgramming Language) specificatin f the scheduling prblem that the CPLEX engine is t slve. It includes declaratins f variables that must cme frm the Java cmpnent (such as number f wrkers, task duratins, task precendences, etc), declaratins f decisin variables (variables that CPLEX must find ptimal values fr - in this case, a list f tasks fr each wrker), an bjective functin (in this case, the bjective is t minimize the makespan), and a generic specificatin f cnstraints that a slutin must adhere t. 4

5 Andrid App The Andrid app was created as a demnstratin f hw this tl wuld be used in real life. It simply displays the rdered task list fr a particular physician based n the utput frm the scheduler. In practice, physicians and ther hspital wrkers wuld carry a mbile device with them as they visit patients and cmplete their tasks, s that they can see which task they shuld cmplete next fr ptimal efficiency. The HnrsAndrid flder cntains the cde fr the Andrid app. Main Methd The Main methd acts as a test driver fr the scheduler. The scheduler depends n tw cmpnents that are utside f the scpe f this prject: a Business Prcess Management (BPM) server and a Real- Time Lcatin System (RTLS) server. The BPM server wuld keep track f the tasks that the hspital wrkers must cmplete (based n the hspital s business prcesses), and give this data t the scheduler. The RTLS server wuld prvide the scheduler with the current lcatins f the wrkers. Since the BPM and RTLS servers are utside the scpe f this prject, the Main methd initializes the scheduler with sme data abut tasks, wrkers, and wrker lcatins, and it prvides a cmmand-line interface fr viewing the state, re-cmputing the schedule, and ntifying the scheduler when a wrker has started r finished a task. Small Examples and Use Cases Here is a small example t demnstrate the functinality f the hspital-scheduling tl: Scheduling Situatin: There are 3 lcatins: ward_a, ward_b, and ward_c. The travel time frm ward_a t ward_b is 2, and the travel time frm ward_b t ward_c is 2. The travel time between ward_a and ward_c is 4. There are tw wrkers: Dc and Phil, and they bth start at ward_a. There are 5 tasks: Alice x-ray and Abe x-ray, at ward_a, which have a resurce cnflict (They cannt be dne at the same time). Bb surgery and Bb surgery preparatin, at ward_b. The preparatin must be dne befre the surgery. The surgery was scheduled t be started at exactly time 20. The surgery has a duratin f 20 (All ther tasks have a duratin f 10). Only Phil may perfrm these tw tasks. 5

6 Charles triage checkup, at ward_c, which must be started befre time 20 (due t a regulatin regarding maximum patient waiting time). Output: When yu press v, the applicatin lets yu view a summary f the scheduling state (Nte: the applicatin uses secnds as the unit f time fr testing and demnstratin): Wrkers:Dc at lcatin 0 ding nthing,phil at lcatin 0 ding nthing, Tasks:Alice x-ray at lcatin 0 fr 10 secnds t-d,abe x-ray at lcatin 0 fr 10 secnds t-d,bb surgery preparatin at lcatin 1 fr 10 secnds t-d,bb surgery at lcatin 1 fr 20 secnds t-d,charles triage checkup at lcatin 2 fr 10 secnds t-d, Lcatins:ward_A,ward_B,ward_C,ward_D, When yu press c, the applicatin cmputes a schedule that minimizes the makespan (minimizes the time until the last task is finished): Dc's Task List: Alice x-ray, starttime: 0, endtime: 10 Charles triage checkup, starttime: 14, endtime: 24 Abe x-ray, starttime: 28, endtime: 38 Phil's Task List: Bb surgery preparatin, starttime: 2, endtime: 12 Bb surgery, starttime: 20, endtime: 40 Ntice that the cmputed schedule adheres t all the cnstraints specified abve. Als, the Andrid app presents Dc with his task list, as cmputed by the scheduler: FIGURE 1: Screensht f Andrid app shwing Dc s task list 6

7 Finally, the applicatin lets yu specify when the wrkers start and finish tasks, and it updates the scheduling situatin t reflect this. It als updates the amunt f time remaining fr tasks that are in prgress, and tasks that must be started at r befre a certain time. Als nte that wrkers are nt required t cmplete tasks in the rder that the scheduler specifies. The scheduler will simply re-cmpute the schedule based n the new state. This leaves wrkers with the flexibility t respnd t emergencies r spend mre r less time n a task as needed. Fr example, if Dc begins Abe s x-ray, and Phil remains idle fr a few units f time, here is the new scheduling state summary prduced by the scheduler. Nte that Abe x-ray is nw in-prgress and has 5 secnds remaining instead f the riginal 10 secnds: Wrkers:Dc at lcatin 0 ding Abe x-ray,phil at lcatin 0 ding nthing, Tasks:Alice x-ray at lcatin 0 fr 10 secnds t-d,abe x-ray at lcatin 0 fr 5 secnds in-prgress,bb surgery preparatin at lcatin 1 fr 10 secnds t-d,bb surgery at lcatin 1 fr 20 secnds t-d,charles triage checkup at lcatin 2 fr 10 secnds t-d, Lcatins:ward_A,ward_B,ward_C,ward_D, And here is the new schedule that the scheduler cmputes. Nte that the rder f Dc s tasks has changed since he started Abe x-ray first instead f Alice x-ray. Als nte that the start time f Bb surgery is 15 instead f 20 nw, since 5 units f time have passed: Dc's Task List: Abe x-ray, starttime: 0, endtime: 5 Charles triage checkup, starttime: 9, endtime: 19 Alice x-ray, starttime: 23, endtime: 33 Phil's Task List: Bb surgery preparatin, starttime: 2, endtime: 12 Bb surgery, starttime: 15, endtime: 35 Scaling Up t Larger Prblems In rder t slve larger prblems, yu can increase the ptimality tlerance f the CPLEX engine. CPLEX uses tw parameters t decide whether a slutin is sufficiently ptimal: Optimality Tlerance: CPLEX will accept a slutin if the value f the bjective functin cannt be imprved by mre than the Optimality Tlerance. Relative Optimality Tlerance: CPLEX will accept a slutin if the value f the bjective functin cannt be imprved by mre than (Relative Optimality Tlerance times the current value f the bjective functin). 7

8 Only ne f the tw restrictins needs t be met fr CPLEX t accept a slutin. Fr testing, scheduling prblems were generated such that there were 10 wrkers, 10 lcatins, and a variable number f tasks with duratins between 10 and 19. Any wrker was allwed t perfrm any task. Every fifth task had tw ther tasks as prerequisites, and 3 f every 10 tasks used ne f 3 resurces (and thus had resurce cnflicts with each ther). The testing was dne n a laptp with a dual-cre 2.26GHz cpu and 2 GB f RAM. By default, CPLEX uses very strict ptimality tlerances: Optimality_Tlerance = 1.0E-9 and Relative_Optimalitly_Tlerance = 1.0E-4. Using these values, the scheduler culd slve prblems with 28 tasks r fewer in less than ne secnd, but prblems with mre than 28 tk mre than tw minutes. Belw is a table shwing the largest prblems that culd be slved fr different relative ptimality tlerances. Nte that it appears t be heavily influenced by the cnstraints n the tasks, since after every ten tasks, the next three that are added are given resurce cnflicts with ther tasks, and there was a sharp increase in the time taken after every ten tasks. Relative ptimality tlerance Largest prblem that can be slved in under six secnds 1.0E At a relative ptimality tlerance f 0.9 (which is getting extremely tlerant fr sub-ptimal slutins), it tk 6 secnds t slve a prblem with 210 tasks, and it prduced a slutin with a makespan f 600. Hwever, by ding ur wn calculatin, we find that the makespan f the slutin the CPLEX engine prvided is nly abut twice as large as a simple lwer bund n the makespan: 10 wrkers ding 210 tasks with an average duratin f 14.5 will take at least units f time (210*14.5/10 = 304.5). S, althugh the CPLEX engine was set t accept a slutin with a makespan f up t 10 times the ptimal value, it still prduced a slutin with a makespan that s nly duble f a lwer bund f the ptimal value. At a relative ptimality tlerance f 1 (which shuld accept any slutin that satisfies the cnstraints, regardless f the value f the bjective functin), it tk 7 secnds t slve a prblem with 500 tasks. In this test, it prduced a slutin with a makespan f A lwer bund n the ptimum slutin s makespan is 725 (500 tasks * 14.5 units f time per task / 10 wrkers), s nce again, althugh CPLEX was set with a high ptimality tlerance, it still prduced a slutin that s nt unreasnably far away frm an ptimal slutin. 8

9 (Nte: By lking mre clsely at hw I generated the tasks, I nticed that yu can get slightly higher lwer-bunds n the ptimal slutins. After every ten tasks, I generated a task with duratin 18 and with resurce cnflicts with all ther tasks with duratin 18. S fr the 210-task prblem, there are 21 such tasks that cannt be dne in parallel, s it takes a minimum f 21*18 = 378 units f time. Fr the 500-task prblem, it takes a minimum f 50*18 = 900 units f time). Pssible Future Prjects One bvius future prject wuld the practical wrk f integrating this scheduler with a Business Prcess Management system and a Real-Time Lcatin System, as it depends n these fr prviding the tasks t be cmpleted and the wrker lcatins. It wuld als be imprtant t examine the real-life usability f such a system and whether it wuld actually imprve prductivity. There are als many aspects f the scheduler itself that can be imprved r need t be examined further. Again related t imprving prductivity, the scheduler finds an ptimal schedule fr knwn tasks, but in practice, new tasks will be created as time passes. It is unclear whether there is a large time-savings prduced by fllwing the verall ptimal path befre these new tasks have appeared. Als, sme direct imprvements that culd be made t the scheduler include making it minimize smething mre useful than the makespan, such as minimizing time it takes t cmplete tasks that directly lead t patients being discharged frm the hspital, and having penalties fr missed deadlines instead f making the deadlines hard cnstraints. It wuld als be interesting t cmpare this cnstraint prgramming apprach t ther ptimizatin appraches (such as genetic algrithms and thers) t see which apprach has the best run-time fr large prblems. 9