Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Current »

Introduction

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.

Features

Final and midterm presentation videos both include a demonstration part that show the implemented features.

Installation

to be added soon...

Configuration

  • Location Tag
    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

  • Location attributes
    default start time and default end time: defines default available times for this location

  • System property
    Automatic scheduler will only plan ahead a limited number of days. This window length is specified with the "operationtheater.continuousPlanningWindow" parameter.

Data Model

 

  • Surgery table
    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

  • Procedure
    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).

  • Scheduling data
    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)

  • Surgical team
    This table is used to model the many-to-many relationship between surgeries and providers.

Automatic scheduler

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.

Term definitions:

  • Problem fact
    used to calculate the score, but does not change during planning (e.g. Procedure)

  • Planning variable
    In contrast to the problem fact, the value of this variable will be changed by the solver. (surgery start time, operation theater)

  • Shadow variable
    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

  • Planning solution
    A wrapping class that implements the Solution interface, holds all problem facts and the planning entity.

  • Chained planning
    Every initialized planning entity is part of an open-ended chain that begins from an anchor - see the following figure

  • Anchor
    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”
when
   #conditions
then
   #actions
end


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

  • No labels