Three months ago we started with an ambitious project plan to build the first version of the operation theater (OT) module. In this first release we focused on scheduling surgeries as it is one of the most important activities in managing an OT. We have succeeded in building the foundation for further development by implementing a scalable automatic scheduling solution that is easily extensible.
Final and midterm presentation videos both include a demonstration part that show the implemented features.
to be added soon...
This module introduces a new location tag “Operation Theater”. Locations that are tagged are used by this module and show up in the scheduling page
default start time and default end time: defines default available times for this location
Automatic scheduler will only plan ahead a limited number of days. This window length is specified with the "operationtheater.continuousPlanningWindow" parameter.
This is the main object that links to a patient, procedure, scheduling data and surgical team. Furthermore it stores the start end finish time of the surgery
This table holds all necessary information that describes a procedure (name, description, intervention duration, operation theater preparation duration and the number of days the patient has to stay in the hospital after the surgery (not yet used).
This table stores the solution that is calculated by the automatic scheduler (planned start and finish time as well as the planned operation theater and whether this surgery has been locked (a locked surgery can't be changed by the automatic scheduler)
This table is used to model the many-to-many relationship between surgeries and providers.
A continuous planning approach has been chosen to keep the scheduling optimal. Once the current master schedule has been invalidated by an event (e.g. a surgery takes longer than estimated) it is recalculated. The last timetable is used as input for the scheduler who tries to re-optimize it, based on all changes.
Optaplanner is the optimization library that is used to solve the scheduling problem. Detailed documentation about optaplanner can be found here. The goal is to determine an optimal timetable that is defined by a set of constraints, which can be divided into two groups:
Hard Rules - e.g. no overlapping surgeries in the same operation theater at the same time
Soft Rules - e.g. consider different priorities across procedures
The difference between them, is that hard rules must not be broken, while soft rules should not be broken. Based on this set of constraints a score is calculated and maximized by the solver. Broken rules reduce the score value.
used to calculate the score, but does not change during planning (e.g. Procedure)
In contrast to the problem fact, the value of this variable will be changed by the solver. (surgery start time, operation theater)
Changes its value just as the planning variable. The difference here is that its value is not directly modified by the solver, but calculated depending on a planning variable (surgery end time)
Planning entity ( = PlannedSurgery class)
It is a POJO that contains the planning variables and thus changes during solving
A wrapping class that implements the Solution interface, holds all problem facts and the planning entity.
Every initialized planning entity is part of an open-ended chain that begins from an anchor - see the following figure
Each planning chain needs an Anchor which is a planning fact
Constraints are defined using drools rule language. The basic syntax is as follows:
rule “This is the rule name”
In this module the action always reduces the score by some value.
Here you can find the implemented rules: scoreRules.drl
Optaplanners configuration is stored in an xml file: solverConfig.xml