Design of RCSS

Abstract

The plans for Resource Coordination for Surgical Services system (RCSS) incorporate a distributed objectbase with a coordinating server. User-centered information screens are customized for each geographic location in surgical services. User interfaces are designed to mimic paper lists and worksheets used by health care providers. Patient-specific and site-specific data will be entered and maintained by providers at each geographic location, but also rebroadcast and displayed for all providers. Although RCSS is primarily a communications system, it will also support review of surgical utilization and operative scheduling.

Today, medical centers are subject to severe financial, social, academic, political, and organizational pressures resulting from increased demands on services and limitations in health care resources. Analysis performed on health care figures in 1981¹ estimated that charges for surgical patients in acute care hospitals account for almost 25% of the United States health care budget. Conservatively extrapolating to more current data,² we estimate that surgical services expenditures in the United States will soon reach $170 billion. Surgical services in a typical medical center comprise the following units: same day (outpatient) surgery unit; inpatient wards; preoperative patient holding areas; operating suites; anesthesia, surgery, and nursing personnel; postoperative care unit; surgical intensive care unit; laboratories; radiology, pathology, respiratory care; and support services. Inefficiencies in coordinating and delivering surgical services could be extremely costly to individual hospitals and to the nation. Likewise, the potential savings for hospitals that can operate more efficiently are enormous.

Research indicates that of the three major clinical components comprising the health care system (surgical, medical, and mental health), surgical services is the one most amenable to cost control by a systematic process of utilization review.³ The Resource Coordination System for Surgical Services (RCSS) optimizes communications and provides a rational, data-driven method for resource coordination and management in surgical services. We believe that throughput tracking methodologies and new, distributed communications systems can improve resource coordination, which is a rate-limiting step in the overall process of surgical patient care.

Many medical centers operate surgical services (excluding emergency patient care) at an estimated 50-60% utilization rate. The classic definition of operating suite (OR) utilization, encountered in the literature is the ratio of the total OR time used to the total OR time allocated or budgeted.^4,5 On the other hand, managers generally recognize that operating rooms could be at least 80% utilized in the care of elective surgical patients. They also agree that the additional 15-20% gain in operating room utilization will require a real-time communications and resource coordination system.

A review of the medical and industrial management literature, which emphasizes the need for operational effectiveness in surgical services, shows that existing systems do not offer satisfactory solutions.^6,7,8,9

Background

Statement of Problem: Patterns of Care on Surgical Systems

To allocate a specific starting time and duration for surgery, a surgeon's office typically contacts the admitting office and requests a reservation within an allotted time block. Requests are recorded in the admitting office, and together with information on surgical teams and operating room availability, are used to generate a prospective surgical schedule. The preliminary schedule is published and subsequently modified by the nursing and anesthesia departments. Patients are informed of their scheduled date of admission, and pre-operative consultation and laboratory studies are arranged. When the patient is admitted, patient-specific information stored in the admitting office is transferred on paper to the same day surgery suite where it is combined with new information generated at that location. Without a computer based communication system, patient-specific information needs to be recorded anew at subsequent geographic locations.

The major geographic locations through which patients traverse while receiving surgical services are illustrated with respect to a typical medical center in Figure 1.^* Efficient throughput depends on efficient movement from location to location. Most patients arrive early on the day of surgery, accompanied by their families. A nursing history is obtained, the laboratory data are checked, and the patient is dressed for the operating theater. When ready, patients are sent to a holding area near the operating theaters where they are interviewed by an anesthesiologist, and the consent for surgery is obtained by a member of the surgical team. Inpatients move directly to the holding area from the inpatient wards. In the holding area, patients often request to speak with their family or surgeons before entering surgery. Intravenous infusions are initiated, shave preps are performed, and, occasionally, casts are removed. If indicated, regional anesthesia is initiated in the holding area using special equipment and monitoring.

Figure 1.

A schematic plan of the traffic flow and specific geographic locations that patients traverse while receiving surgical services. Each site is a node on a local area network and owns and edits patient-specific data while the patient is located at that location. Although some patients may follow erratic paths through the surgical facility, most fall into the patterns illustrated.

When anesthesia, nursing, and surgery are ready, the patient is transported to the scheduled operating theater and is moved to the operating table, monitored, anesthetized, and undergoes surgery. After surgery, the patient is transported to the post-anesthesia care unit, where he/she recovers before being moved to a ward bed or being returned to the same day surgery unit. Patients who are moved to a ward stay until their recovery can be managed at home. Patients who return to same day surgery are reunited with their families, ambulated, instructed on follow-up care, and discharged home.

A small number of patients are sufficiently ill to require admission to an intensive care unit following surgery. The surgery and anesthesia teams make such admission decisions together, and are responsible for arranging reservations and admissions. The intensive care units are remote from the operating suite and communications are typically by phone. Anesthesia must notify the intensive care unit and arrange for beds, equipment, and personnel prior to the move. In some instances, the patient is taken to the post-anesthesia care unit and later moved to the intensive care unit.

Several problems may prevent the smooth progression of patients through the surgical services suites. These include, but are not limited to, late arrivals of patients or medical records, delays in support services, acute onset of abnormal medical conditions (infections, chest pain, etc.) requiring delay or cancellation, inaccurate or inappropriate reservations, lack of a mechanism to enable dynamic scheduling, and delays which result in lost professional time. These and other problems lead to peaks and troughs in the demand for services, adding to inefficiency and dissatisfaction among patients, their families, and health care providers.

Previous Surgical Resource Management Systems

Surgical services are expensive, and the need to operate efficiently and effectively is recognized internationally.^1,3,10,11,12 Two early systems are exemplary: the OTIS system¹³ developed at the Aberdeen Royal Infirmary, and the Johns Hopkins operating room management system.¹⁴ The OTIS system allows operating room staff to enter surgical scheduels and procedure durations using microcomputers and to review the durations of various procedures to predict future operating room utilization. Its goal was to direct the schedule of surgery so that each surgical session would regularly finish on time, saving costly personnel time. Operating room utilization was reviewed using bar graph displays. Utilization review was keyed to specific surgeons, a design feature requested by the surgeons.

The Johns Hopkins operating room management system supports block scheduling, utilization review analysis, and centralized decision making. It is written in the Massachusetts General Hospital Utility Multi-Programming System (MUMPS) language and runs on a mainframe computer. It is a valuable and effective tool for predictive scheduling, utilization review, and resource planning (see McColligan et al.¹⁴ for a system description, and Gordon et al.¹⁵ for the system's utilization review data collection and interpretation function). However, its architecture and implementation platform are not designed for distributed, real-time replanning and communication of adjustments. The system does not appear to perform real-time, reactive adjustment to schedule disruptions, or to consider hospital facilities outside the operating room.

To support predictive and reactive scheduling, it is necessary to gather utilization data to establish trends in surgical services demand. Hancock et al.¹⁶ proposed an algorithm for extracting statistically distinct subsets from a surgical database in order to accurately estimate the variance of surgical procedure times. This group argued that both the means and variances of procedure times are necessary to determine realistic starting times for cases to follow in the same operating room.

More recently, Hancock and Isken¹⁷ evaluated a custom admissions scheduling system, ASCS, which controls inpatient admissions and coordinates those admissions with surgical scheduling. The result was a higher hospital occupancy rate without an increase in staff anxiety levels. Their system considered both operating room scheduling and overall efficiency measures, rather than just operating room utilization, as an indicator of system value. It appears that a custom admissions scheduling system is used in centralized planning and is based on a hospital simulation model. The investigators defined a set of elements comprising a state-of-the-art operating room scheduling system. Nevertheless, a custom admission scheduling system was limited in scope and did not include networking capabilities. Although Hancock and Isken recognized the differences, the program that they developed did not incorporate a distinction between inpatient and outpatient admissions; in addition, it did not allow for reactive planning of emergency surgery.

A relevant resource scheduling and management example is the airlines' distributed communication systems for real-time distribution of gate information to passengers, managers, and support personnel¹⁸ at airports. Arrival and departure times, baggage area and gate assignments, destinations, and anticipated delays and scheduling changes are broadcast throughout the air terminal on monitors. Information dissemination allows passengers, crew, baggage handlers and others to manage their roles in a decentralized manner. In the case of surgical services, there is a similar need to disseminate information about patients, surgeons, anesthesia, support staff, and equipment to assist those affected in managing themselves. Gosling¹⁹ studied how airport gate assignments delay passengers, baggage, and cargo; Gosling also studied the impact of those delays on flight schedules, operational costs, and passenger satisfaction. He identified factors that increase the uncertainty of gate scheduling. Gosling recorded site-specific work process information and disseminated that information throughout a local area network to facilitate overall operations. Similar factors affect efficient scheduling of surgical services.

System Design

Objectives of RCSS

The goals for RCSS are as follows:

• Collect and make available site-specific information generated by the work process (e.g., the preoperative checklist from same day services) to other units of surgical services. As a result, patient management decisions can be based on an appreciation of the overall hospital situation, which should improve the reactive coordination of personnel, space, and equipment.

• Seek an unobtrusive, reliable, and accurate method of recording surgical services utilization data for analysis and subsequent predictive scheduling of hospital resources, including personnel, space, and equipment.

• Improve the quality and reliability of data by automating data collection.

• Empower health care providers by returning locally generated data to the health care providers who use it.

• Improve time management and operational efficiency of key health care professionals and administrators involved in the delivery of surgical services.

• Document surgical diagnosis and procedures perioperatively as an objective basis for total quality improvement procedures.

• Help explore the impact of improved communications on the evolution and maintenance of surgical culture.

System Architecture

The intent of RCSS is to provide intelligent communication support over a peer-to-peer network linking the facilities listed in Figure 1. System Status, the Scheduling Support System, and the Calendar are integrated using a graphical interface. Two other modules, the Report Writer and the Data Archive and Analyzer, may be accessed directly (Fig. 2).

Figure 2.

The architecture of RCSS consists of five modules; some are accessible through their own graphic interface.

The RCSS prototype design incorporates an objectbase distributed across independent workstations, all of which access a common coordinating server(s). Locally owned data are stored on both the local hard disc and on the network server(s). Any workstation or subset of workstations in the system may be designated as the server(s) either initially or if an existing server fails. Lost data can be reconstituted from peer workstations, or a back-up copy of the objectbase may be read into the system from a back-up copy of the server. As such, this design is more robust than configurations based on non-distributed centralized servers. All data originated at a failed workstation will still be available to all peers in the network. All read and edit transactions among other workstations will be preserved. Only editing privileges for data owned by the disabled workstation will be temporarily lost from the system.

The objectbase will contain two categories of data: patient-specific data (owned temporarily at the site where the patient is located) and site-specific data (owned at the site where the data are produced). Electronic ownership of patient-specific data will pass throughout the network as the patient moves from location to location. Site-specific data will be entered and maintained locally, and remain the property of a particular site even after the patient has moved on the new locations. Edit privileges for data will usually follow the electronic ownership, but, if indicated administratively, can be assigned to specific distant sites or users. View privileges will be unrestricted throughout the system, in order to facilitate information dissemination. Under specific circumstances (for example the family waiting area) view permissions might be encoded, restricted or denied based on passwords and permissions jointly agreed upon by the users and system administrators.

Certain computers in the network will not own data; they are repeaters, reading data from the distributed objectbase and then presenting information to the user. Those workstations will not be passive; each must actively configure the data to site and user-specific criteria governed by the user-interface design. Repeaters may be placed in areas where patients are not housed, such as the surgical and staff lounges, locker rooms, anesthesia offices, operating rooms, equipment rooms, central supplies, pharmacy, etc.

System Data Structures

The system is implemented using an object-oriented approach. Patients, personnel, and resources are instances of a hierarchy of classes. There are four primary classes in the hierarchy: patients; personnel (surgeons, anesthesiologists, CRNAs, nurses, and residents); locations (ORs, surgical intensive care unit beds, post-anesthesia care unit beds); and equipment.

The “patient” class includes slots that record the path of the patient through surgical services, the scheduled times for significant events along that path, the expected service time for each stop along the path, the actual path of the patient through surgical services, the actual times for significant events along that path, and the actual service times for each stop along the actual path. As each patient completes his/her residence in the system, RCSS will record both the planned and actual service record, along with patient demographics (age, address, contacts, insurance information, etc.), the procedure performed on the patient, and the names of the major health care providers who care for the patient.

The use of objects facilitates future implementation of a calendar from which the daily schedules will flow, and makes it possible to have multiple versions of a day's schedule while RCSS is doing its processing. This is useful when performing predictive scheduling.

System Status Module

Information about patients who are in the surgical services suites will be maintained by RCSS. The data are to be available for display and/or update in the following locations: admitting office, same day surgery suite, holding room, operating rooms, surgical intensive care units, post-anesthesia care unit, floor or other patient location, nurse anesthesia charting room, anesthesia offices, anesthesia workroom, surgeons' lounge, cleaning and maintenance areas, and locker and dressing rooms.

In the absence of an electronic system such as RCSS, medical centers typically rely on manually created printed paper schedules, an example of which is shown in Figure 3. While a paper schedule contains all the information necessary to administer the daily schedule, it does not convey scheduled interactions with respect to time and space. To better view and manipulate the schedule, RCSS will reorganize it as a single day Gantt chart, which may be displayed from a variety of views (by surgeon, by anesthesiologist, by patient, by operating room, etc.) of the underlying data. The Gantt chart (Fig. 4) illustrates the progress of surgery and rebroadcasts changes in the surgical status in real time.

Figure 3.

Operating room schedule in its classic configuration.

Figure 4.

Illustration of the operating room schedule reconfigured as a Gantt chart for reactive scheduling.

Scheduling Support System Module

The audit trails to be generated by RCSS are part of a prototype scheduling support system currently under development. The scheduling support system will use historical data from these audit trials to build a scheduling library specific for CPT code, anesthesia type, and surgeon.²⁰ Surgical duration estimates will be drawn from the library and used to create a surgical schedule by assigning patients to operating suites using a bin-packing algorithm.

Calender Module

Predictive scheduling requires a multi-month calendar display, because operating room reservations are often requested weeks in advance. Each day's schedule will be available as a Gantt chart. By allowing access to daily schedules weeks in advance, support personnel may examine future surgical demands and improve utilization of surgical resources in cooperation with the surgeons and other health care providers. This utility will provide the Predictive Schedular with the information necessary to schedule patients in advance. The calendar will be linked to admissions, and could be connected to other systems to download patient data and scheduling services. It will also function as an appointment book.

Report Writer

The Report Writer is intended to provide hard copy digests of performance, utilization, and exception reports on a scheduled and on-demand basis from a variety of perspectives. Users must provide a “boiler-plate” format for those reports; RCSS does not include natural language capabilities. These reports will be prepared with data retrieved using criteria-specific data searches and sorts. The data can then be written to text files for analysis outside RCSS. An example of such a report is given by the transaction register utility (Fig. 5).

Figure 5.

Transaction register with selection and sort buttons.

Data Archive and Analyzer Module

The Data Archive utility will store the records of surgical transactions. The analyzer will perform routine analyses for the Report Writer and real-time scheduler, and enable the user to extract raw data as desired. Case records and audit trails will be compressed and written to an archiver.

As patients move within the hospital, ownership of patient-specific data will travel electronically with the patients from location to location. Time stamps will be entered into the objectbase by bar code or direct keyboard entry as patients change locations, so that the length of stay in each location will be documented and an audit trail recorded. Patient-specific audit trials will be available on-line for utilization review and summarized for all patients by the real time through-put tracking Gantt chart (Fig. 6). The audit trails will be summarized statistically and procedure durations can be compared with local performance or national norms. After a sufficiently large historical base of patient movements has been collected, it will be possible to analyze institutional trends and to spot outliers statistically, so that opportunities for improvement may be identified.

Figure 6.

Illustration of the Real Time Throughput Tracking Gantt chart illustrating scheduled (open bar) and actual (filled bar) operating room residence times.

When sufficient institutional historical data are available, we expect to implement an on-line graphical utilization review module, customized for each location in surgical services. Reports will be initiated from a pull-down menu. Dialogue boxes will allow searches by time interval and text strings, and the data may be sorted by demographic fields. For operating room utilization data, for example, there will be both graphical (Fig. 7) and numeric (Fig. 8) utilization displays. Each display will summarize three operating room time categories: budgeted time (OR block time or staffed periods); scheduled time (patient surgery reservations); and used time (as recorded by bar code). In addition, utilization statistics will be summarized as the following ratios:

Figure 7.

A graphical utilization review screen showing a histogram summary of budgeted, scheduled, and used operating room utilization times for each operating room. Actual utilization, accuracy of the forecast, and forecast utilization are computed as grand means for all the operating rooms taken together.

Figure 8.

A numerical utilization review screen (the numerical counterpart of (Figure 7) consists of a matrix displaying three categories of time (budgeted, scheduled, used) and three summary utilization statistics (actual, accuracy of forecast, and forecast) for each operating theater. By highlighting each summary cell in the matrix and clicking on it, users may display details of the entire list of cases contributing to each cell in the matrix.

Pop-up boxes will detail case duration for used, scheduled and forecast times using graphical and numeric utilization screens (Fig. 9). Numerical and analytical on-line reports can be customized to accommodate specific users and on-line reports may be written to the screen, disk, or printer.

Figure 9.

Graphical utilization review screen pop-out feature giving access to details of case duration and starting times, both scheduled and actual.

The data provided by RCSS will provide four management benefits:

1. Procedure (CPT) and diagnostic (ICD-9) codes are assigned upon admission to categorize patients and may be modified appropriately by health care providers at the time of surgery. Comparing diagnoses before, during, and after surgery, or comparing similar diagnostic or therapeutic procedures, may indicate false positives, false negatives, and the relative prevalence of various medical conditions or procedures. Such data may be made available to health care providers and managers to assist with quality improvement.

2. The data display screens at each location are customized to match local preferences. Each group of health care workers will be responsible for a small, manageable data subset relevant to its own work (see screen for the intensive care unit, Fig. 10). Because data entry is automated (bar code entry of time stamps from network time servers), employees will find it easy to maintain accurate records. Also, because much of the patient identification data will be inherited, the data are not likely to be compromised by errors associated with repetitive reentry.

3. Statistical summary of time intervals selected by procedure, provider, location, or other patient characteristics will be utilized to indicate trends over time, which may be used to prospectively manage resources, based on experience in preceding time intervals. Individual health care providers may compare themselves with appropriately developed benchmarks for self-analysis and quality improvement. Similar analysis might be used to compare medical centers in other locations in the city, state, and country. Time series analysis of the same data may be used to establish analysis of process control, and for predictive scheduling of materials and personnel, to plan for peak and trough demand for surgical services

4. An audit trail will be established for each patient and may be recalled on demand to study the time course and geographic progression of patients through surgical services. Procedure and diagnostic codes, together with the names of important health care providers such as the surgeon, anesthesiologist, and discharge nurse, will be combined with residence and procedure times to produce a reconfigured audit trail known as a health care transaction receipt, as shown in Figure 11. The receipt will provide a patient with a written record detailing their hospital treatment and the main contact persons from whom they received care. The patient can use the receipt to reconcile hospital bills with a record of services delivered.

Figure 10.

Information screen for the surgical intensive care unit. Note that the screen provides access to the names and numbers of all persons responsible for patient care in the intensive care unit. Expected admissions and discharges are posted for the benefit of health care providers within the unit and without. Many providers have input into major decisions affecting the patients discharged from a unit.

Figure 11.

A health care transaction receipt analogous to that from an automated teller machine providing patients with an itemized record of surgical services delivered, including the names of appropriate contact individuals should the need for this information arise.

Discussion

This paper introduces the design and features of RCSS, a prototype of a computerized system for management of surgical services. RCSS is designed to improve operational efficiency in surgical services by addressing communications, resource coordination, surgical utilization, and scheduling needs. It is currently a research tool that has been alpha tested to determine the feasibility of its design.

Communications problems in surgical services include difficulties locating physicians, patients, family, and verifying the availability of personnel, equipment, and operating suites.²¹ These problems were analyzed using a systems approach,²² and the solutions were incorporated into RCSS design. Patient—provider relationships and patient satisfaction are expected to improve because better communications will reduce administrative overhead and telephone time for providers, leading to more time to care for patients.

The designers of RCSS have worked closely with multidisciplinary health care providers during its development cycle. We interviewed managers (seeking approval and empowerment) and actual care providers (seeking problem identification and resolution, and direct feedback on user-interface design). These interviews helped ensure that the software was easy to use and learn, satisfying to use, and provided valuable utility and functionality. This early provider contact also provided us confidence and ensured continued cooperation from providers during the development.

Because of its object-based design, RCSS can easily accommodate additional expansion. Modules for managing clinical studies, for scheduling laboratory tests, and for scheduling clinic visits enterprise-wide²³ are examples of additional modules that can easily be added to RCSS. Because RCSS is made from objects, not only in its coding but also in the design of its data structures, it is robust and easily adapted to additional geographical locations and functional applications.

When implemented, RCSS would automate acquisition of demographic and utilization data for surgical services. Similar data was previously unavailable or had to be entered manually.²⁴ Utilization data can be used to study operational efficiency²⁵ and also to model the duration of surgical procedures.²⁰ The former can be used to do capacity planning and the latter can be used for predictive scheduling of future surgeries.

Implementation of RCSS will likely change surgical culture in several important ways. First, management practices will become more horizontal because RCSS distributes information to health care providers in real-time and relieves managers from the burden of communicating details. Managers are currently detail oriented, frequently traveling the shop floor to deliver information to the workers and to inspect for quality. With implementation of RCSS, it is anticipated that managers will have more time to participate in quality control, strategic planning, and policy making. Data and decision-making responsibility can be returned to individual health care providers, who could be held accountable for their decisions and actions. This is compatible with the management philosophy and horizontal team advocated by Deming.^26,27

The very act of studying and computerizing surgical services is expected to change surgical culture. Preparations for implementation of the software and hardware focus attention on efficiency issues. Recording the duration of surgical procedures allows providers to focus attention on aggregate performance and on individual delays. Managers and providers can expect to uncover bottlenecks and to effect changes based on data. In other words, measuring performance and variability will alter the status quo in the surgical culture and will provide an important impetus for change.

The impact of RCSS on the efficiency of surgical services also should be evaluated in financial terms. Financial evaluations of the software must await not only full implementation but also development of the accounting and outcome measurement tools necessary to measure the financial bottom line. Time is integral to the cost of surgical services. The total cost of services is the hourly rate for labor and space multiplied by the utilization time and added to the fixed cost of durable goods. In combination with traditional accounting systems (payroll and inventory), RCSS could assist medical centers in moving from charge- to cost-based accounting procedures by helping to provide itemized billing based on utilization to both patients and the institution.

In summary, managed care imposes new economic realities on hospitals and their surgical services, which must become more efficient and cost-effective to survive. In a business sense, this requires that patient care delivery be quantitated and that variability be reduced without sacrificing quality. The promise of RCSS is to provide inexpensive, accurate data for improving scheduling, resource coordination, and communications while altering surgical culture and empowering health care providers to make better decisions.