 TWikiAdminGroup  14 Nov 2010
General medicine (GM) regristrars at Auckland Hospital are currently rostered to 'on call' shifts by a 12 week rotating roster. This roster has grown organically over the years and is subject to union rules. The GM registrars on call admit patients to their GM ward from the emergency department and the Acute and Planning Unit (APU). There are 4 GM wards, with 3 registrars attatched to each ward. The types of shifts that are allocated to registrars include 'long day' admitting shifts (08002230), and normal admitting shifts (08001600). If a registrar is not allocated to an admitting shift then they complete a 'Normal Day' (08001600).
The current roster requires development as currently there are high fluctuations in patient numbers across registrars. These flucations result in some registrars being overworked on some days while other registrars have a low number of patients. This affects the standard of care for patients and the quality of life for registrars. Also of importance to consider is 'continuation of care', that is where the same registrar is looking after a patient for the duration of the patient's stay.
The purpose of this project is to investigate how the current roster for General Medicine registrar. The main goal is to implement a working model of an "Idealized roster". The timeline of this project is 10 weeks and as such is not expected to produce a full working roster but to provide the basis for further investigation, possibly as a 4th year project.
The desired outcomes of the summer project are:
Initial meeting held 25th November with Andrew Peterson, Tim Denison, Rupert Handy, Nicolas Szecket, Mike O'Sullivan and Amelia White.
From the initial meeting it seems that the main issues is variation in patient numbers across the teams which results in registrars being overworked and can compromise continuation of care for patients. This variation means that on some days a registrar may have to see upwards of 15 patients whereas on other days they may have 2 or 3. This means that on a given day one sub team may be extremely busy whereas another team may be quiet. The important aspect at this stage to address appears to be "smoothing" out the number of patients admitted across the week for each team to reduce variability.
A and B call each take approximately 1/3 of the new patients each day, C and D call take the remaining 1/3. As of December 13th 2010 this will change so each admitting team will take 1/4 of the incoming patients each. Patients admitted by the night cover registrar are split evenly across all wards.
Patients stay on average 3.5 days, however this is a long tailed distribution with around 50% of the patients being discharged within 24 hours. 40% of the time there are not enough GM beds.
Workload of registrars tends to peak later in the day and thus their shifts are not currently allocated around the peak work demand periods.
Admissions are 1020% lower on weekends and there is a cap of 30 maximum admissions to the GM wards.
More Postacute shifts would be beneficial in the weekend if possible.
Current Roster Rules
Shift Rules
Objective: Produce a schedule
Constraints:
Addition constraints to add from meeting held 03/12/2010
To gain further understanding to exactly how things currently run at Auckland hospital, I shadowed several of the staff in General Medicine. I shadowed Dr Janar Sathanathan for several hours around the APU. Patients can be admitted directly to the APU from their GP to avoid double handing by the ED. One thing that I found surprising was the amount of time paper work took compared to the time actually needed to be spent with the patient.
Dr Anthony Jordan Showed me around the APU and Emergency Department (ED) and discussed several of the current issues. One issue brought up is that not all team positions are actually filled and there is currently noone allocated to the relief roster. This means that that if a ward is short of a registrar, that ward has to stretch to cover the absent registrars workload. He also mentioned that it may be useful to talk to Sarah Tracey at ARRMOS who currently develop the rosters based on templates in Excel. Apparently usually the first time the rosters come out, there is usually a problem with it not meeting some of the rules such as working two weekends in a row.
The Doctors that are on call admit from the ED and APU. In addition to this they can be allocated the Emergency pager which means they have to respond immediately to any critical cases. They can also be allocated the GP phone, which is the line GP's call in on if they are sending a patient to hospital. It appears having this phone can be highly disruptive to the doctors schedule.
I followed around a locum registrar in the ED for a couple of hours in the evening. The late afternoon to early evening is usually the busiest but the night I was there it was quite quiet. I discovered the next morning that some of the patients he admitted went to the team I was following the next morning. This meant that that noone on the team that they were admitted to had the next day had seen the patient before morning rounds. In the ED each patient is assessed based on priority and can either be dispatched or, if they are expected to only be in for a short time, admitted to the APU or finally they can be admitted to the wards.
The morning following the evening I was in ED, I attended the GM morning meeting. This meeting occurs at 8am every weekday morning. The purpose is to review patients that have come in overnight and which wards and teams they have been allocated to. Ideally patients are allocated to the ward belonging to the team they have been assigned too. This unfortunately doesn't always happen and part of the meeting is spent 'finding' 'lost' patients. I shadowed Dr Rupert Handy, we first visited the new patients who had been kept in the APU overnight and then saw the new patients who had been allocated to the wards.
The below tables detail patient allocation before and after patients were moved between teams at the 8am meeting. The reason patients have to be moved between teams is when they have been sent to the wrong ward from ED or the APU.
Before reallocation  After reallocation  

Team  Call  New  Total  Total Ward  Team  Call  New  Total  Total Ward  
B1  5  11  29  B1  8  14  32  
B2  1  10  B2  1  10  
B3  Yes  1  8  B3  Yes  1  8  
W1  Yes  4  24  W1  Yes  4  24  
w2  1  10  w2  1  10  
w3  5  10  w3  5  10  
R1  11  16  33  R1  8  13  31  
R2  10  R2  11  
R3  Yes  7  R3  Yes  7  
G1  5  24  G1  5  23  
G2  4  G2  4  
G3  5  15  G3  4  14 
An initial mathematical model was developed in Python. This model simply allocates one shift to every registrar and ensures that the correct number of admitting shifts are allocated each day. Python outputs this as a colorcoded schedule into HTML format. This initial model has been set up to generate a schedule for one individual registrar for the 12 weeks. This roster can then be allocated to different teams so that it roatates. For example Team 2 starts the roster in week 2, team 3 in week 3 ect. This incorporates very basic constraints and just allocates the shifts so that the required shifts will be allocated each day.
The above image shows part of the generated schedule. This schedule currently is not practical, for example it does not match up night shifts with days off. This model has been set up to generate a schedule for each individual registrar and to develop a schedule for one registrar which is rotated through by each of the registrars. The advantage of the rotating schedule is that it is a smaller problem to solve and thus should solve faster (hopefully). The rotating roster also means that the work load on all registrars is equal as over the 12 weeks they all do the same roster just in different weeks
It is useful to obtain an estimate of number of patients per ward, each day based on the roster. Code was developed to do this based on the assumptions listed below.
Assumptions:
Above: Estimate of patient numbers per ward based on first 3 weeks of current roster.
Below: Estimate of patient numbers per ward based on initial rotating roster.
Future things to think about
This section to keep track of tasks and progress as it is made  area for my general thought dump.
Task  Description  Date Completed 

Comment Code  This really needs to be kept uptodate and requires full descriptions of each functions. This will ensure that it is easy for people to continur working on in the future  
List of what is currently included in schedule and what to include next  define where we are at now for and what to include next in the formulation  
Patient number estimation 
 
Analyse previous data

Whats in:
What to add next:
The roster below was produced by adding an additional constraint that a team can do no more than 2 'long days' in any 7 day period
Wonderful holiday worked on tan. result great tan!
The stage we are at now is that the LP is producing a roster with the constraints of ensuring the union rules are met and that there is a maximum number of 35 patients per ward. This appears to be better than the current roster in regards to patient numbers.
Analyse data from ADHB. To do this I need to write some VBA to match up the number of patients admitted to each ward and compare this with our method of predicting the number of patients in each ward. We then want to compare our roster with the current roster using the number of patients from the data using our current assumptions. Following on from this we want to compare our assumptions regarding how the patients are allocated and amount discharged.
Goal of completing these by end of January. Following on into February we will review what has been done so far and read union documents to check for additional rules. Also should probably look at removing fractional number of patients in calculation or may need to look at impact of this assumption.
In the period 14/06/201012/12/2010 for the data given there were 3100 patients admitted and 6070 discharged. This is clearly inconsistent and so I used the admitting numbers which seemed o.k as it was an average of 17 patients admitted per day. When I visited the hospital the number of patients was between 182 and the wards have around 20 bed this seemed a reasonable figure. I used the discharge assumption that 1/3 of patients were discharged on Monday to Friday and 1/5 on Saturday and Sunday. These rates can be easily adjusted when we obtain more reliable data. Each ward starts the period with 18 patients in where previously there were between 1823. This enables a lower maximum number of patients in the formulation and thus should spread the patient load more evenly. The maximum number of patient from the formulation is 19. Interestingly this formulation one 'on call' shift to each ward each day as was with the previous roster for June to December 2010. I'm not sure why this was changed for the roster from 13th December onwards.
Feedback from ADHB regarding the data that was supplied didn't include the number transfered into GM. Rupert supplied a summary of data from 2010 broken of patient admissions / discharges which included transfers. This data balances and hopefully we will be able to source similar data broken into a day by day format.
From the graphs of patient numbers from the current rosters there is still quite a big gap between patient numbers. There is the option of doing a two step optimization process, where first minimize the maximum number of patients, set this minimum as a constraint and then rerun maximizing the minimum number of patients in the ward. The better option is likely to be minimize the difference between these two numbers.
Using the data given averages were calculate for each day of the week. Admitting seems constant through the week with about 10 patients per day. This is not including internal transfer. Discharges are higher on Fridays and lower on the weekends. Average patient stay is 1 day 7 hours.
Day  Admitting  Discharge 
Monday  10.21  39.31 
Tuesday  10.60  39.08 
Wednesday  9.50  38.19 
Thursday  10.62  36.50 
Friday  10.02  44.81 
Saturday  4.73  21.19 
Sunday  3.94  14.38 
Trying to solve with objective seems smallest gap it can get is around 25 patients which seems quite big, although this is a smaller gap than when solving before. It seems to be definitely problem with only one oncall person being on weekends or could be assumptions regarding patient data. The current assumption is 28 admitted on Saturday and Sunday. This seems way too high when compared with the data above. I modified the input data to 20 admissions on weekdays and 10 on Saturday and 8 on Sunday. I have doubled these numbers from the admitting numbers above to model the transfers as well.
I tried to solve with the changes to the data and it is struggling. With running to a 0.05 and 0.1 tolerance between integer solution and best solution, Pulp crashes. I removed this tolerance and have tried to solve it again. After 1429.35 seconds (about 23 minutes) the integer solution is 10.6798 and the best possible is 7.8805, this is about what it was getting to before it crashed.
Image of patient numbers and roster:
solution_table_rotate_full.html
I added a constraint to say that the difference between the maximum and minimum number of patients must be >=10 to try and get it to solve as it seems that the best gap must be about 10.
I am also considering that we are only 'smoothing' out patient numbers across wards and not across registrars in the wards. Adding these in as variables I suspect will increase the solve time but it could be something to investigate.
I  Attachment  History  Action  Size  Date  Who  Comment 

ADT23_ArtN_Summary_data.pdf  r1  manage  24.1 K  20110121  01:16  AmeliaWhite  2010 summary data by team  
rtf  ADT23_ArtN_Summary_data.rtf  r2 r1  manage  24.1 K  20110121  01:14  AmeliaWhite  Summary data from 2010 broken down by team 
jpg  MinGap1.JPG  r1  manage  129.9 K  20110126  22:14  AmeliaWhite  Graph from minimising the gap between maximum and minimum number of patients. Stopped solver at 1736.60 seconds 
docx  Patient_number_estimate.docx  r1  manage  191.5 K  20101215  04:47  AmeliaWhite  Graphs of estimate of patient numbers to show to ADHB at meeting 
xlsx  Shedule.xlsx  r1  manage  26.8 K  20101206  01:46  AmeliaWhite  Example schedule handed to ADHB as example of initial model implementation 
jpg  comparing_old_with_new_schedule_graphs.JPG  r1  manage  60.2 K  20110113  21:11  AmeliaWhite  JPEG comparing predicted numbers of patients for current and developed schedule 
bmp  comparing_old_with_new_schedule_graphs.bmp  r2 r1  manage  60.2 K  20110113  03:50  AmeliaWhite  Graphs comparing predicted patient numbers between new and old rosters 
png  current_scedule_predicted_nums.png  r2 r1  manage  90.4 K  20101215  04:47  AmeliaWhite  3 weeks of current roster using 28 patient admitted per day and 1/3 discharged per day. Weekend loading is not quite correct 
data_analysis.pdf  r3 r2 r1  manage  477.9 K  20110121  01:18  AmeliaWhite  Compares patient numbers for previous roster and generated roster with historical data  
bmp  example_roster.bmp  r1  manage  736.3 K  20101214  00:29  AmeliaWhite  First rortating roster developed 
png  max_35_nor_more_than_2_long.png  r1  manage  142.1 K  20110112  22:32  AmeliaWhite  Predicted patient numbers with no more than 2 long shifts in a 7 day period. Maximum number of patients = 35 
png  patient_loading.png  r2 r1  manage  88.4 K  20101215  04:47  AmeliaWhite  Example patient loading based on rotating roster developed. 28 patients admitted per day and 1/3 discharged 
txt  roster.py.txt  r1  manage  4.7 K  20101206  01:47  AmeliaWhite  Initial model formulation which generates a full roster 
txt  roster_functions.py.txt  r1  manage  11.1 K  20110113  22:09  AmeliaWhite  Uploaded before significant changes made 
bmp  roster_max_35.bmp  r1  manage  1679.1 K  20110112  22:37  AmeliaWhite  Roster created by maximum of 35 patients and no more than 2 long shifts in a 7 day period 
txt  roster_rotate_1_4.py.txt  r1  manage  6.9 K  20101212  20:54  AmeliaWhite  latest update with nice comments and displaying schedule in correct order 
txt  roster_rotate_1_5.py.txt  r1  manage  7.6 K  20110113  22:08  AmeliaWhite  Python file for producing roster. I uploaded this before making quite a few changes for looking at analyzing the data from ADHB 
txt  roster_solution_rotate.txt  r1  manage  0.7 K  20101206  01:48  AmeliaWhite  Initial model formulation which generates one roster which is then rotated through the registrars 
html  solution_table_rotate_full.html  r1  manage  22.4 K  20110126  22:18  AmeliaWhite  Roster Generated from Minimizing the gap between max and min patients 