System and Method for Optimal Operating Room Scheduling and Booking
Technical Field
This invention relates to optimal scheduling systems and booking systems, and more particularly to optimal scheduling systems especially suited for hospitals and clinics.
As pressures mount to reduce health care expenses, hospitals are searching for ways to reduce their expenditures in order not only to become more profitable, but also merely to survive. In order to accomplish this, hospitals must address the expenses in those areas where spending is the greatest in order to effect a significant savings. One of the areas in which hospitals invest a major portion of their budget is the OR (operating room) suites. It has been discovered that if the OR suites were to be used in an optimal way, a significant savings in the hospital's cost could be obtained. In the present application, the term OR is intended to include specialized areas in the hospital such as PACU and ICU where significant resources are also consumed.
There are several products on the market which provide computerized booking of surgical cases. These products offer many different features which help surgery schedulers do their job better, but none of these systems is able to examine the data which it holds and reorganize it so that it is both efficient and optimal. In addition, it is known that true optimization of a system as complex as this is a computationally prohibitive operation.
An example of prior art surgical booking systems is shown in U.S.
Patent 4,937,743 to Rassman et al. The Rassman system is basically a booking system which notifies the human user of scheduling conflicts, but it appears to make no effort to find a schedule which is optimal in a mathematically provable sense.
Prior art systems could also be improved in other ways. For example, a human user ultimately makes all the final decisions about the schedule with prior art systems. As a result, a surgeon may unduly influence the schedule in
ways which benefit the surgeon but increase the costs to the hospital by influencing the scheduler. The result is a schedule which not only is not optimal, but which in fact may be deliberately uneconomic. In addition to the direct costs associated with such an approach, the hospital suffers indirect costs such as the inconvenience and dissatisfaction of the other surgeons.
Moreover, prior art systems are not well equipped to handle unexpected events such as emergencies, case delays, case overruns, add-on cases and case cancellations. The prior art approach to such events is typically ad hoc, and makes no attempt to optimize the revised schedule resulting from such events . Prior art scheduling systems typically have only one function: booking a schedule. They are not designed to accomplish the related function of improving the policies which govern scheduling. Although scheduling can have a significant effect on the costs incurred by the hospital, present booking systems are not designed as an information gathering tool to explain to hospital administrators why their operating room costs are so high.
Since prior art systems are not designed to optimize the scheduling process, they are not equipped to take into account (other than in the most rudimentary way) the ultimate goals of the hospital, such as maximizing the number of procedures performed or minimizing the resources required to perform the procedures. Prior art booking systems simply take the procedures they are given and attempt to provide an acceptable (as opposed to optimal) schedule. Background Art
Among the various objects and features of the present invention is the provision of a method of scheduling hospital operating room usage which is optimized.
Another object is the provision of such a method which allows the hospital administrators to determine optimality criteria for operating room usage.
A third object is the provision of such a method which provides an optimization of the schedule which is completely transparent to the user.
A fourth object is the provision of such a method which prevents the scheduler from changing the schedule merely to accommodate an assertive surgeon while at the same time allowing authorized management personnel to change the optimal schedule.
A fifth object is the provision of such a method which provides the user with a choice of optimal schedules when more than one optimal schedule is available. A sixth object is the provision of such a method which, to the maximum possible extent, restructures schedules to provide the lowest cost while keeping everyone involved pleased.
A seventh object is the provision of such a method which is capable of generating revised optimal schedules in response to unexpected events such as emergencies, case delays, case overruns, add-on cases and case cancellations.
An eighth object is the provision of such a method which provides intelligent and useful infoπnation to hospital administrators concerning ways to improve the operation of their operating rooms.
A ninth object is the provision of such a method which explicitly uses the optimality goals of the hospital, and allows authorized hospital personnel to change those goals as needed.
A tenth object is the provision of such a method which provides optimality of scheduling as well as optimality of resource allocation as desired. An eleventh object is the provision of such a method which identifies operational patterns and collects historical data to allow simulation of operating room operations for the purpose of management and administration.
A twelfth object is the provision of such a method which is usable as a tool for planning, organization, budgeting and policy making.
A thirteenth object is the provision of such a method which is applicable for all different kinds and sizes of hospitals (such as community hospitals,
teaching hospitals, private hospitals and government hospitals), with widely varying policies and considerations.
A fourteenth object is the provision of such a method which creates more regular and consistent work day schedules. Other objects and features will be in part apparent and in part pointed out hereinafter.
Briefly, in a first aspect of the present invention, a computer implemented method of optimal scheduling of a plurality of medical procedures by a plurality of surgeons in a set of operating rooms includes the steps of identifying the resources required for performing each of said plurality of medical procedures and determining every feasible schedule for the plurality of medical procedures, taking into account predetermined resource and scheduling preferences and availability. A cost function is assigned to every feasible schedule and a total cost associated with each feasible schedule is determined from said cost functions. The scheduling of the plurality of medical procedures is then optimized, in a mathematically provable sense, taking into account the total cost associated with each feasible schedule and preset optimality criteria.
In a second aspect of the present invention, the computer implemented optimal scheduling method involves "fuzzy scheduling" in that it includes determining preferred starting intervals for each of the plurality of medical procedures. The scheduling of the plurality of medical procedures is optimized in accordance with preset optimality criteria such that to the extent possible each medical procedure is assigned a starting time which falls within its prefeιτed starting interval. In a third aspect of the present invention, the computer implemented optimal scheduling method includes the steps of determining preferred ending times for each of the plurality of medical procedures and optimizing the scheduling of the plurality of medical procedures in accordance with preset optimality criteria such that to the extent possible each medical procedure is assigned to end no later than its associated preferred ending time.
In a fourth aspect of the present invention, the computer implemented optimal scheduling method includes the steps of determining, by using an Al methodology, a complete set of feasible schedules for the plurality of medical procedures, taking into account predetermined resource and scheduling preferences, assigning a cost function to every feasible schedule of the set, and applying a predetermined procedure to all of the feasible schedules, using the assigned cost functions to obtain a reduced set of schedules. In addition, another predetermined procedure is applied to optimize the reduced set of schedules in accordance with preset optimality criteria. In a fifth aspect of the present invention, the computer implemented optimal scheduling method includes the steps of, for each procedure to be scheduled on a given day, performing a feasibility check to determine if it is possible to schedule the procedure on said day, and subsequent to the feasibility check, optimizing the scheduling of the plurality of medical procedures in accordance with preset optimality criteria.
In a sixth aspect of the present invention, the computer implemented optimal scheduling method includes the steps of optimizing the scheduling of the plurality of medical procedures for a given day in accordance with preset optimality criteria to obtain at least one optimal schedule for that day, obtaining data representative of variations between the optimal schedule and actual conditions in the operating rooms during the day, and optimizing a revised schedule for the medical procedures during the day, the revised schedule taking into account the variations between the actual conditions and the initial optimal schedule. In an seventh aspect of the present invention, the computer implemented optimal scheduling method includes the steps of optimizing the scheduling of the plurality of medical procedures for a given day in accordance with preset optimality criteria to obtain, if possible, a plurality of optimal schedules for said day, displaying to a user visual representations of the plurality of optimal
schedules, said computer being responsive to the selection of one of the plurality of optimal schedules by a user to utilize the selected optimal schedule. In a eighth aspect of the present invention, the computer implemented optimal scheduling method includes the steps of determining preferences relating to at least some of the plurality of medical procedures, optimizing the scheduling of the plurality of medical procedures for a given day in accordance with the preferences and preset optimality criteria to obtain at least one optimal schedule for that day, and identifying any preferences which make it impossible to optimize the scheduling of the plurality of medical procedures. In a ninth aspect of the present invention, the computer implemented optimal scheduling method includes the steps of assigning priorities to the surgeons and to the medical procedures and optimizing the scheduling oi' the plurality of medical procedures for a given day in accordance with the priorities and preset optimality criteria to obtain at least one optimal schedule for that day. In an tenth aspect of the present invention, the computer implemented optimal scheduling method includes the steps of optimizing the scheduling of the plurality of medical procedures in accordance with preset optimality criteria such that the resources required to perform said plurality of medical procedures are minimized. In an eleventh aspect of the present invention, the computer implemented optimal scheduling method includes the steps of optimizing the scheduling of the plurality of medical procedures in accordance with preset optimality criteria such that the number of medical procedures performed using the resources are maximized. Brief Description of the Drawings
Fig. 1 is a hospital preference screen used in the system of the present invention;
Fig. 2 is a patient input screen used in the system of the present invention;
Fig. 3 is a patient listing screen used in the system of the present invention;
Fig. 4 is an operating room input screen used in the system of the present invention; Fig. 5 is an operating room listing screen used in the system of the present invention;
Fig. 6 is a procedure input screen used in the system of the present invention;
Fig. 7 is a procedures listing screen used in the system of the present invention;
Fig. 8 is a staff input screen used in the system of the present invention;
Fig. 9 is a staff listing screen used in the system of the present invention;
Fig. 10 is a surgeon's preference card screen used in the system of the present invention; Fig. 11 is a case input screen used in the system of the present invention;
Fig. 12 is a case listing screen used in the system of the present invention;
Fig. 13 is a flowchart illustrating the operation of the system of the present invention; and Figs. 14A and 14B are diagrams illustrating the improvement in operation room utilization using the system of the present invention.
Similar reference characters indicate similar parts throughout the several views of the drawings. Best Mode for Carrying Out the Invention The system of the present invention is a combination booking system and optimization engine. Specifically, the system is a dedicated management and operational software for the OR suites (including PACU, ICU, etc.) that adaptively and intelligently schedules and optimizes the utilization of the OR suite resources (including resource time, operating rooms, staff, inventory, etc.) and minimizes the costs involved in running the OR suites. In the OR suite, the
present system is all-encompassing. It not only optimally schedules surgeries, but also may be used as a key tool for the hospital administrators. The present system provides the kind of clear data which can be used for extensive planning, organization, budgeting and policy making. This information is a direct result of the system's ability to provide optimal operating room scheduling, staff scheduling (anesthesiologists, CRNAs RNs, Techs, LPRN, SAs in ORs and RNs in PACU/ICU) and optimal inventory control and equipment maintenance. Functional Performance
The present system is capable of considering and handling all sorts of rules and constraints found in operating rooms and achieves various "best" objectives. These objectives can be predefined or (preferably) specified by individual hospitals. The computational time for the present system ranges from several seconds to several minutes, depending on the size and structure of the hospital. To illustrate the size of the problem being handled, for a typical hospital with 15 ORs and 40 surgical groups, there are hundreds of millions of variables. This problem would be computationally prohibitive, so the present systems significantly reduces the scope of the problem by assigning procedures to a relatively small number of predetermined starting intervals, rather than to predetermined starting times. With this unique approach, the task becomes manageable, and the software is able to identify the feasible schedules (roughly 60,000 or so for the hospital size discussed above), and then to choose among them in order find the optimal one(s) and restructure (in the booking system | the data. For even the largest hospital in the world, the completed optimization time using this unique approach is not expected to exceed 15 minutes. Other Requirements
The present system is designed to be both easy to use and a very powerful tool. GUI interfaces (described in detail below) make the present system easy for anyone to operate, whether they are familiar with it or not. This means that the learning curve to make the present system work for a hospilal is very shallow.
Most of the input data typically comes from the schedulers themselves, while patient and staff information have the option of being accessed through an HIS (hospital information system) or an OR MIS. It is preferred that the data handled by the present system be in a form which complies with the most up-to- date standards, such as the HL7 standard, to facilitate data transfer and interchange. HL7 is at present the new standard for HIS and OR MIS communication. It involves the integration of all information related to the delivery of healthcare to a patient over his or her lifetime (i.e., an electronic medical record). This standard allows all or parts of this electronic medical record to be communicated electronically anywhere else as needed.
The term "Level 7" refers to the highest level of the Open System Interconnection (OSI) model of the International Standards Organization (OSI) model of the International Standards Organization (ISO). In the OSI conceptual model, the functions of both communications software and hardware are separated into seven layers, or levels. The HL7 Standard is primarily focused on the issues that occur within the seventh, or application, level. These are the definitions of the data to be exchanged, the timing of the exchanges, and the communication of certain application specific errors between the applications. HL7 was selected as the standard to adopt for the present system because of its flexibility, its growing acceptance world wide and its capacity to addresses most of the problems faced by systems integration in the healthcare industry today. The HL7 standard currently addresses the interfaces among various systems that send or receive patient admissions/registration, discharge or transfer (ADT) data, queries, orders, results, clinical observations, billing, and master file update information. It does not try to assume a particular architecture with respect to the placement of data within applications but is designed to support a central patient care system as well as more distributed environment where data resides in departmental systems. Later versions of this standard are expected to address topics such as scheduling, medical records, and patient care, all of which are relevant to systems such as the present invention.
The data that is output from the present system is of two types. The first type is reports which are generated by the system. Some examples of these reports are: schedules for different days, (both optimal and merely feasible), staff assigned to different cases, utilization of equipment, staff and rooms, etc. The second type of data which is output from the system is the optimal schedule for a day. The criteria for this optimal schedule can be changed by authorized personal, such as a hospital system administrator.
Once data exists in the present system and is optimized for a given day (the optimization is completely transparent to the user), a schedule which minimizes the hospital's cost for that day in the OR suites exists. If this schedule is followed, then the hospital has saved money. If the cases in the schedule deviate from their estimated lengths or resource usage, a less optimal solution is the result, yet the hospital still saves money over present ad hoc approaches to scheduling. As is described in more detail below, the present system is designed such that it dictates what the best schedule is for everyone while taking into account everyone's personal preferences and availability of resources.
The system is further designed to categorize users into groups which have different access levels to the system. This means that depending on a user's group, certain features of the system may or may not be available. Functional Implementation
Each hospital has policies concerning the operation and management of the OR suites. For the present system, these policies are made explicit and given relative weights reflecting their importance. This information is stored in the system parameters of the system and is customizable by users with the proper access privileges. Surgical request information is taken and preprocessed together with other information, such as surgeon's profile, patient's health, etc. Once this consolidated surgical request information exasts, it is fed into the optimization engine. The optimization engine conducts a two- phase optimal scheduling. The first phase is a feasibility check which allows
for an immediate confirmation that each surgeon's cases are booked and all relevant preferences are met successfully. The second phase is an optimal global optimization which is activated 48 hours or 72 hours (depending on the hospital's policy) before the day of surgery. The optimal global optimization is done by associating a cost function to every feasible schedule and then trying to find a schedule with minimal cost. The result of the global optimization is a bona fide, mathematically provable optimal schedule(s) according to the chosen criteria of the hospital. At first, the resulting schedules produced drive the staff scheduling and inventory control modules of the system. However, at a later stage in a hospital's use of the system, the optimization can be done by taking all of the above factors into account simultaneously.
The optimization factors and constraints considered and handled by the present system include:
Interaction Factor interactions among surgeons, patients, MD Anesthesiologists, CRNAs, RNs, Techs, SA, etc.
Fluctuation Factor fluctuations of case load and case mix. Time Regulation
Rules, OR regular resource time, various shifts, Block release time, over time permitted, etc.
Priority Factor surgeons and cases have priorities, assignable by an authorized administrator.
Preference Factor surgeon's or hospital's preference as to ORs, staff, etc.
Stochasticity Factor variability of procedure time, emergencies, case changes, add-ons and cancellations.
Start Time Constraints e.g., a given time, a given time interval, -either or- tomorrow type, waiting list, etc.
Finish Time Constraints a given time.
Compatibility Constraints certain surgeries can be performed in certain Ors; certain CRNAs, RNs can work on certain cases, etc.
Precedence Constraints cases have to follow an order or sequence, either soft follow, hard follow, or parallel follow.
Block Constraints by services or by surgeons.
Human Resource Constraints staff capacity.
Equipment Resource Constraints availability of equipment.
The objectives that need be achieved with any scheduling system can be expressed in both qualitative measurement and quantitative terms. Qualitative factors include making everyone happy (satisfaction of surgeons, patient and staff and administrators), minimizing the chaotic impact due to unexpected events, and handling of emergency cases in an orderly and efficient manner. Quantitative factors include making the most efficient use of the operating rooms and making the most efficient use of other resource (e.g., staff, equipment, etc.). Note that the factors and constraints which need to be enforced and the objective which needs to be achieved can be specified and set by the hospital administrators with the system of the present invention.
The system is designed to allow priorities to be computed based on the surgeon's credentials, patient needs, acuity level and other factors. When a time or equipment conflict occurs, cases with lower priorities will yield to those with higher ones. If the constraints are violated, the present system identifies the surgical requests that cause the violation. The system then suggests to the scheduler/administrator a possible modification of the surgical requests or the system parameters set by the hospital to resolve the conflict. In addition, the present system collects comprehensive statistics, identifies operational patterns, conducts cost analysis benchmarking and case load mix projection. It also subsequently activates a simulation process with optimization to suggest to the hospital administration any necessary policy changes and adapts itself to changes in the surgical environment.
It is preferred that the present system be usable on a variety of different computer platforms. By way of example, it is implemented in a Macintosh version. The hardware required a stand-alone version of for the Macintosh end of the software is: • Power Macintosh with a PowerPC 601, 603 or 604 processor.
32 MB of RAM,
1 GB hard drive, 3.5 floppy diskette drive, 17" color monitor, keyboard and a mouse, UPS (uninterrupted power supply).
Similarly, it may also be implemented in a two part (client and server) Intel-based computer system. For the client machine, the minimum requirements are: • 75 MHz Pentium Processor, 16 MB of RAM, 500 MB hard drive, 3.5 floppy diskette drive, 17" color monitor, • networking adapter, keyboard and a mouse,
UPS (uninterruptible power supply).
The minimum requirements for the Server are: 100 MHz Pentium Processor. • 32 MB RAM,
2 GB hard disk space (2 physical disks), 3.5 floppy drive, backup device, 17" color monitor, • networking adapter, 28.8 data fax modem, 2 serial, 1 parallel ports, standard keyboard, and a mouse, Uninterruptible Power Supply (UPS).
There are a few hardware considerations which are common to both platforms:
• an ink jet or laser printer
• a bar code reader (if data entry is to be done using bar code scanning), • the appropriate paging software and hardware (if autopaging of personnel is desired)
A key distinction between the present invention and prior art systems is the use of fuzzy scheduling. This means that instead of allowing surgeons the current practice of specifying exact desired starting (or indeed ending) times, the present system divides the day into a small number of multi-hour periods (early morning, morning, late afternoon, etc.) and allows requests to be made only in terms of these periods. The length, and indeed the definition of these periods are governed by a decision of the hospital administration. This philosophy allows for very efficient optimization, and makes up a significant aspect of the present optimization engine. Part of the process of the optimization is a decision by the hospital administrators as to the length of an "inconvenience period" to be allowed. That period is the time difference between the exact request by the physician and the final disposition of this request. Larger inconvenience periods allow for more efficient optimization, but a smaller degree of satisfaction.
In connection with the optimization, it is prefeπed that a priority index is first obtained through the prioritization scheme as described above. If no conflicts exist, the priority will not be used. If a conflict does exist, then cases with lower priorities yield to those with higher ones. Adjustments to variables and preferences are modifiable to those users with the appropriate access privileges. This task is greatly simplified due to the GUI interface, also described below. The present system automatically converts these values into system parameters, coefficients and/or constraints which are handled by the optimization engine. The process, of course, is transparent to the users. The optimization objective function includes considerations for overrun time, idle
time, fixed OR costs, staff costs, etc. The optimization is achieved through a judicious combination of classical mathematical methodologies (for example, mathematical programming, control theory, stochastic approaches, etc.) together with artificial intelligence paradigms such as Fuzzy System Theory, Neural Networks, Rule Based Systems, and Logic Programming.
Some key features of the user interface include: intuitive and simple Graphical User Interface, support for mouse and/or keyboard, Drag and Drop functionality, look and feel consistency with the environment (customizable), Internationalization support (including DBCS), user authentication, several levels of security access (reflected by the interface), help bar on all the screens (fly-by help), quick help option (expanded fly-by help), Hypertext on line reference and a multimedia tutorial.
More specifically, and referring now to the Figures, the graphical user interface includes a system preferences screen such as is shown in Fig. 1. This screen allows an authorized user (system administrator) to change the system preferences such as the time interval (time slot) names and the times associated therewith, the anesthesia types used by the hospital, the service codes and roles of staff members at the hospital, and case display defaults. Other system preferences could also be included if desired. Note, as discussed above, that the present system provides for time slots or time intervals, rather than specific starting times. This allows a surgeon to select a time interval (as described below) for starting a medical procedure, while providing the scheduling system sufficient latitude to optimize the resulting schedule. Without this feature, mathematically provable optimization of the resulting schedules would be computationally prohibitive.
Turning to Fig. 2, there is shown a patient input screen. This screen shows the user (scheduler) an individual patient record, and allows the user to define or modify the record of a patient who is the subject of a case (a proposed medical procedure). A patient record can contain a MRID (medical records
identification number), a name, a social security number, a birth date, a gender, a home and work telephone number, and (if desired) general comments.
The graphical user interface of the present system further includes, see Fig. 3. a patient listing screen, which shows a listing of patients in consecutive rows. Individual records on this screen may be accessed by double-clicking on the row which represents the record of the patient whose record is to be modified or viewed. New patient records can be added and existing records can be deleted using this screen by clicking on the appropriate boxes on the screen.
Turning to Fig. 4, the graphical user interface also includes operating room input screens such as that shown, which allow the user to define or modify a record of a room used by the hospital. An operating room may be given an ID, a name and a number using this screen. Furthermore, the user may through this screen set minimum operation times for an operating room, as well as default setup, cleanup and roundup times. Fig. 5 is a graphical user interface screen illustrating a listing of operating rooms. The OR listing screen shown operating rooms listed in consecutive rows. Individual operating room records may be accessed by the user by double-clicking on the row which represents the OR to the modified or viewed. New OR records can be added and existing records deleted from this screen by clicking on the coπesponding screen buttons shown.
Fig. 6 illustrates a procedure input screen used in the present system. The procedure input screen allows the user to define or modify a record of a procedure which is used by surgeons in the hospital which has the system installed. A procedure can be given an ID, a name and a service category using this screen. Average times for all surgeons to perform this procedure are calculated by the system and stored in the average procedure time field displayed on this screen. Average setup and cleanup times for procedures are calculated and stored as well. The screen of Fig. 6 is also linked to a procedure/equipment screen (not shown) which allows the hospital to set default equipment for the various procedures.
The graphical user interface also includes a procedures listing screen (Fig. 7), which shows a listing of procedures in consecutive rows. Individual procedure records may be accessed by double-clicking on the row which represents the procedure to be modified or viewed. New procedure records can be added to the system and existing records deleted by clicking on the corresponding screen buttons of Fig. 7.
Fig. 8 shows a staff input screen used in the present system. This screen allows the user to define or modify a record of a staff member (surgeon, anesthesiologist, RN, CRNA, etc.) in the hospital. A staff member can be given an ID, a first and last name, a staff title and a service title using this screen. Various telephone numbers where each staff member can be reached are stored as well. If the current record displayed in this screen is a surgeon, then the surgeon's preference card screen (Fig. 10) can be accessed directly (by clicking on the "Procedures Performed" button on the screen) and updated. The staff listing screen is shown in Fig. 9. This screen displays a listing of staff members in consecutive rows. Individual records can be accessed by the user by double-clicking on the row which represents the staff member whose record is to be modified or viewed. New staff member records can be added and existing records can be deleted by clicking on the coπesponding buttons on this screen.
Fig. 10 shows a surgeon preference card screen used in the present system. This card screen is used to create, modify and delete preference cards for surgeons. A preference card shows the equipment, materials and supplies which a surgeon selects (prefers) for a particular procedure. All definitions, modifications and deletions on this screen are done by dragging and dropping, which significantly reduces the possibility for error.
The graphical user interface of the present invention also includes a case input screen as shown in Fig. 11. The case input screen allows the user to add or modify a record of a case in the hospital. A case can be assigned a patient, staff members, procedures, etc., and can hold all relevant information related to
a case. The lower half of this screen is divided into four different sections: scheduling, pre-op information, peri-op information, and post-op information. Within the scheduling section of the screen, four fields are significant: requested OR, preferred start time, preferred end time, and estimated length. The requested OR field is filled in automatically by the system whenever a surgeon and a procedure are selected for a case. Based on these two pieces of information, the system determines which operating rooms can be used and which cannot be used, and supplies the user with a listing of those rooms in the requested OR field. The prefeπed start time field is directly related to the "system preference' time slot names and times. By selecting a prefeπed start interval, the scheduler can guarantee the surgeon that his case will start some time in that interval. The prefeπed end time field can be used if a case should not run any later than the time specified in that field. The estimated length field gives an averaged approximation of how long it will take a surgeon to perform a particular procedure.
Fig. 12 illustrates the case listing screen of the present system. This screen shows a listing of cases in consecutive rows. Individual records can be accessed by double-clicking on the row which represents the case to be modified or viewed. New case records can be added and existing records can be deleted from this screen by clicking on the appropriate buttons. The system displays a utilization graph in the top left corner of this screen and shows room utilization for the day selected on the calendar in the top right corner ol" the screen. A block diagram of room usage for a day can also be reached from this screen by clicking on the button labeled "Graph." Cases which already exist for a particular day can easily be rescheduled by dragging the line in which the case appears onto a different date on the calendar.
The overall operation of the present system is summarized in the flowchart of Fig. 13. The top line represents various requests, goals, and constraints, such as surgical requests (surgeon's requests, requested time intervals, prefeπed finish time, etc.), OR availability, OR releasing and
allocation policy, optimality criteria (either preset or as set by the hospital, as discussed above), and hospital policies such as proactive and reactive emergency policies. The next line of Fig. 13 represents various categories of input data such as whether block booking (procedure or surgeon) or first come/first served booking is desired (leftmost block); whether the system is performing its initial feasibility check (next block); whether the system is performing long term optimization (which takes into account such things as OR availability, surgical requests, and preferences of room and time); whether the system is performing short term optimization (reflecting short term changes in OR availability); and real time input data (rightmost block).
Once the relevant data is input, it is preprocessed to, for example, detect contradictory requests, case grouping, case prioritizing, and OR grouping. Then each feasible schedule is determined by the system. Thereafter, the data is further processed to eliminate special equipment conflicts and the like. If the number of feasible schedules is too large, at this point more formal optimization could also be used.
At this stage in the process, the system and constraints are modeled as follows:
Given this model, the scheduling problem may be solved using various mathematical programming paradigms, utilizing in part commercially available linear or nonlinear programming software, such as LINDO or CPLEX, in addition to the special methodology used to obtain a sufficiently tractable set of feasible schedules, which are the target objects for optimization.
If the optimization is successful, the user is notified. If more than one schedule is optimal, the user is given a choice, which then becomes the schedule for that particular day. In the event the schedule cannot be successfully optimized, the user is informed not only that the process has failed to find an optimal schedule but also identifies what caused the problem. If the problem can be solved simply by adjusting times or dates, the system informs the user of that fact and provides alternatives. If the changed times or dates are acceptable,
the user restarts the process with the new time or date. If not, the procedure which caused the optimization failure is turned away.
It has been found that the present system results in greatly improved efficiency in the utilization of operating rooms. This is indicated in Figs. 14A and 14B for a hospital having fifteen operating rooms. Using conventional methods, the OR utilization rate in Fig. 14A is 65.6%. Using the present system, that utilization rate is increased to 84.4% and many of the operating rooms are not used at all. Over a period of a week, the average increase in utilization rate was twenty-four per cent and substantial savings in surgeon time and nurse time.
In view of the above, it will be seen that all the objects and features of the present invention are achieved, and other advantageous results obtained. The description of the invention contained herein is illustrative only, and is not intended in a limiting sense.