Database management for a gynecologic oncology service

GYNECOLOGIC

38, 431-436 (1990)

ONCOLOGY

Database Management for a Gynecologic Oncology Service’ IVOR BENJAMIN, Division

M.D.,2 JOEL S. NOUMOFF, M.D., JOHN A. CARLSON, JR., M.D., ROBERT L. GIUNTOLI, M.D., MARK MORGAN, M.D., AND JOHN J. MIKUTA, M.D.

of Gynecologic

Oncology,

Department

of Ohsietrics

and Gynecology,

University

of Pennsylvania,

Philadelphia,

Pennsylvania

19104

Received January 26, 1990

With the ready availability of powerful desktop computers, the ability to manage large clinical databases has become practical. A computer can enhance the capability of a gynecologic oncology service to catalog, recall, and analyze data about patients, tumors, and therapies. While commercially available database packages can be used for this purpose, we have developed a custom database for tracking the clinical activity of a busy gynecologic oncology service. The system catalogs data about patients, admissions, tumors, and therapeutic modalities and uses this information to generate several useful reports. The reports are used for daily patient care, fellow and resident case statistics, and clinical research. What is unique about the system is that it is optimized for easeof use. The development of this tumor registry, its user friendliness, and advantages over a manual recordkeeping system are described. Unlike other tumor registries, our system is utilized on a daily basis for patient care. Therefore, the data being entered have an immediate usefulness in addition to being simultaneously added to the tumor register for retrospective clinical research. One may hypothesize that it would be useful if all gynecologic oncology services used a common computerized tumor registry that could allow for the sharing of information on 0 1990 Academic PB, or global SCak. a national

pability of a gynecologic oncology service to catalog, recall, and analyze data about patients, tumors, and therapies. While commercially available database packages can be used for this purpose, we have developed a custom database for tracking the clinical activity of a busy gynecologic oncology service. The system catalogs data about patients, admissions, tumors, and therapeutic modalities and uses this information to generate several useful reports. These reports are used for daily patient care, fellow and resident case statistics, and clinical research. Searching the database is uncomplicated and fast. The clinician or researcher is quickly able to identify cases of interest. What is unique about our approach is that the system is optimized for ease of use. Great effort was taken to develop a user interface that is intuitive, minimizing typing and redundant data entry. We feel that a clinical database should be equally accessible on a daily basis to both clinicians and tumor registrars.

IK.

MATERIALS AND METHODS The daily activity of a busy gynecologic oncology service generates a massive amount of useful data for the clinician and investigator. Accumulating, cataloging, and reporting this information manually would be an arduous, labor-intensive, and impractical task. However, with the ready availability of powerful desktop computers, the ability to manage large clinical databases has become practical. A computer can, therefore, enhance the caPresented at the annual meeting of the Society of Gynecologic Oncologists, San Francisco, CA, February 4-7, 1990. ’ All patient names and hospital identification numbers used in the text and figures of this publication are factitious. Any reference to persons living or dead is purely coincidental and unintentional. ’ To whom correspondence and reprint requests should be addressed at Department of Obstetrics and Gynecology, Hospital of the University of Pennsylvania, 3400 Spruce Street, Philadelphia, PA 19104.

Hardware

and Software

The database has been developed on a Macintosh 11x computer (Apple Computer, Inc.) using 4th Dimension (4D), a relational database from Acius, Inc. The computer is configured with 5 megabytes of random access memory (RAM), 140 megabytes of hard disk storage, and a 13-in. high resolution RGB color monitor. For printed output, an Apple LaserWriter IINT is used. This hardware platform has been chosen for its intuitive, graphical user interface which includes a pointing device (mouse). The software (4D) has been selected as our development environment because of its power and flexibility. The advantage of a relational database is that it avoids entering and saving redundant information. Aside

431 O@O-8258/90$1.50 Copyright 0 1990 by Academic Press, Inc. All rights of reproduction in any form reserved.

432

BENJAMIN

ET AL.

(prior surgery, prior chemotherapy, etc.). The vast majority of these individuals have had little or no previous experience with computer databases. For an average day, it takes a resident/fellow approximately 15 min to complete the data entry and printing of daily reports. For data security, a multiple-level password scheme is employed. There is a master password that allows complete access to the system and its programming structure. Only the developer and administrator of the system have this access level. Other passwords are more restrictive, allowing only limited access to the database. In addition, we perform backups several times per week to protect the data from theft, tampering, or computer crashes. The User Interface for Data Entry FIG. 1. The “Patients”

menu being selected by the mouse.

from being intuitive, this also saves time for people who will be entering data. For cataloging our patients, the same identification number that is employed by the medical records department is used. For ovarian, cervical, and uterine tumor staging the FIG0 classification is used. For vulvar tumors, TNM and FIG0 staging is used, and for Gestational Trophoblastic Neoplasia (GTN), the World Health Organization (WHO) scale and prognostic groups are used. All data entry is performed by fellows and/or residents in the Department of Obstetrics and Gynecology and a nurse-clinician in the Division of Gynecologic Oncology. Typically, a patient’s current data would be entered by the residents and fellows on the service. A retrospective chart review is then performed by the nurse-clinician who enters retrospective information

Obstetrics & Gynecology I

I

,/

/“1’S’,,////

FIG. 2. Selecting a patient for data entry or review.

Probably the best illustration of the user interface short of a live demonstration would be to describe the steps for entry of a sample patient. Fig. 1 shows the “Patients” menu. To enter a new patient or review a summary of all data for a patient the same command “Enter or Select Patient” is used. Next a dialog box appears requesting the last name of the patient. In this example, “Smith” is entered. The computer then searches the database for any references to “Smith” and presents a list of all “Smiths” (Fig. 2). At this point, the user may find the “Smith” that he/she was intending to enter in the list. This would indicate that this patient already has been entered into the system and has existing data. The existing data may be a prior admission for an unrelated problem, but nevertheless, at least her demographic information is already present in the system and does not need to be reentered. The options available at this point are to select one of the existing “Smiths” or create a new one. Clicking (i.e., pointing with the mouse) on “New patient ‘Smith’ ” will create a new record in the database and open the patient entry screen. In this example, let us assume that we are interested in reviewing or updating information on “Mary Smith.” The user would click on “Mary Smith” in the list in Fig. 2 and then click on the “Use Selected ‘Smith”’ button. This would open the patient entry screen for “Mary Smith” (Fig. 3). Information is entered into each field. The tab key or mouse may be used to navigate between fields. When entering or modifying data in a field, the computer performs data validation and postprocessing. For example, if a user forgets to capitalize the first letter in the patient’s last name, the computer will do it (postprocessing) or if the user enters an invalid telephone number, the computer will recognize this, alert the user with a beep and dialog box (on-screen message), and reject the invalid entry (data validation). Postprocessing and data validation are extensively employed throughout the

DATABASE

MANAGEMENT

FOR A GYNECOLOGIC

II

Primary Hirtololgy:

FIG. 3. Sample patient entry screen. The sample patient’s being selected from a pop-up menu by the mouse.

race is

database to help guide the user and to protect the integrity of the data. When data entry is complete the record is saved by clicking on the “Save Record” button with the mouse or hitting the “Enter” key. Al! data entry screens contain an on-screen control panel that is accessed by the mouse. The appearance of the control panel varies depending on the type of data being entered. In Fig. 3, the patient entry control panel contains a series of buttons for navigating to the various pages of the patient entry screen. Clicking on “Adm/Surg/Tumor” reveals a summary screen of all admissions, procedures, and tumors for a given patient (Fig. 4). The information displayed in any of these lists may be edited directly from this summary screen. Alternatively, the user may click with the mouse on the “view” button to see the

ONCOLOGY

Site:

SERVICE

433

E E

FIG. 5.

Sample tumor entry screen.

full page (i.e., details) about that record. For example, clicking on the ovarian tumor for patient “Mary Smith” in Fig. 4 and clicking on “view,” would open the screen illustrated in Fig. 5. If a user wishes to enter a new admission, procedure, or tumor, he/she would click on the add button in the on-screen control panel in Fig. 4. The “Tumor” entry screen (Fig. 5) demonstrates several other features of the user interface. The site, stage, histology, and tumor status fields are pop-up menus. A pop-up menu is an interface object that forces the user into a single mutually exclusive choice from a list of items. In this case, clicking and holding on the selected histology “Mutinous Adenocarcinoma” displays a list of available histologies for the ovarian tumor (Fig. 6). The available choices in these pop-up menu change, de-

1 Choriocarcinoma

C&inos&oms Borderline Tumor Mixed Mcrodermsl

FIG. 4. Admission, procedure. tumor summary screen control panel contains the add button (“+“).

screen. The on-

Sarcoma

FIG. 6. Sample tumor entry screen with the histology being selected by the mouse. Note that the displayed list of choices reflects the primary site.

434

BENJAMIN

FIG. 7. Sample admission entry screen.

pending upon the selected primary site. When the primary site is “ovary,” only the ovarian staging is available. However, if the site is “uterus” the appropriate staging system is presented and grading is available. This again illustrates data validation and guided data entry. At the bottom of the tumor entry screen is a “Patient Status” window. These data are calculated dynamically; i.e., when the staging date is entered, the survival will be calculated immediately by the computer. The radiotherapy information is entered as a pair of “check boxes.” This is a useful device for entering and viewing yes/no (boolean) data. In this case, “Mary Smith” has received neither “Tele” nor “Brachy” therapy. A click of the mouse toggles between a checked and unchecked box. Chemotherapy data are entered for each drug, again, by selecting from a pop-up menu of drugs. Admissions are entered via the screen in Fig. 7. This

ET AL.

screen introduces another interface device, the radio button. Radio buttons allow the user to select a mutually exclusive choice from a displayed list. In this case, “New” and “Repeat” are mutually exclusive and represented by a radio button pair. If the user clicks on “Repeat,” then “New’ is deselected and vice versa. Figure 8 is the “Procedure” entry screen. This allows the entry of surgical procedures. The user selects the surgeons who participated in the case from scrolling lists and pop-up menus of appropriate names. No typing is required. A level of management of the case (Attending, Complete, Operative, Surgical Assistant) as defined by the American Board of Obstetrics and Gynecology residents’ case list form is selected via on-screen buttons. A free-form field is provided for description of the case and an itemized list for resident/fellow/attending credit is selected from a scrolling list of modified ICD9 categories. RESULTS Thus far, our database contains information on over 2000 patients seen at the Hospital of the University of Pennsylvania between February 1989 and June 1990. Most of these patients are gynecologic oncology patients. However, the functions thus far described are a subset of the overall database. This database is a global one for the Department of Obstetrics and Gynecology at the University of Pennsylvania and contains admissions and procedures for the benign gynecology service and the endocrine and infertility service. Selected outpatient information is also captured. We use the database to track patients who are being ruled out for ectopic pregnancy with serial /3-hCG and utrasound. Currently, we are developing an outpatient colposcopy registry. It is important to emphasize that these additional functions in no way detract from tumor registry portion of this system. This global approach is, in fact, an advantage for the tumor registry functions of the database. For example, if a patient undergoes a laparotomy for an adnexal mass by the general gynecology service and the mass is malignant, most of her data is already in the registry. All that is needed to fully register her malignancy is to enter the diagnosis and staging. The residents rotate through all gynecology services in the department, and since all cases for all services should be entered into the database their case lists are complete. Reports

FIG. 8. Sample procedure entry screen.

The database generates several useful reports. Most of these are used for the daily management of inpatients. Each service (oncology, obstetrics, general gynecology, infertility) can print a daily inpatient census which lists

DATABASE hIday,

September

15,

MANAGEMENT

FOR A GYNECOLOGIC

ONCOLOGY

SERVICE

435

the patients by room number. Hospital number, date of birth, age, primary diagnosis, secondary diagnoses, prior surgical procedures, and registered tumors are included (Fig. 9). A sample physician case list is shown in Fig. 10. This is generated simply by specifying the name of the physician from a scrollable listing. Presently, we are working on developing the case list report to be in the exact format required by the American Board of Obstetrics and Gynecology for fellow and resident case statistics for board certification. We have developed a survival analysis module for the database that is able to plot survival curves for any subset of patients (i.e., by site, stage, grade, treatment, etc.). These curves may be printed but are not intended to be of publication quality.

Isas

Seurching the Dutabase An important function of any database is the ability to search and query. In a manual tumor registry, the desired searches usually have to be decided upon before data are accumulated. This often involves sorting information in ledgers according to some meaningful key (e.g., tumor site). If a manual record system lists all tumors by site in one ledger it is obviously easy to open the ledger and look at all tumors for that given site. However, to examine retrospectively all patients with ovarian cancer who had a postoperative complication and were hospitalized longer than 14 days, the investigator would have to page through the ledger manually to locate the relevant cases. Only if a separate ledger

FIG. 9. Sample daily census report.

Physician ffosdtal Ben~anrin.

Case List of the University lvoc All cases

of Pennsylvania -

FIG. 10. Sample physician’s case list.

436

BENJAMIN

had been kept prospectively referencing these cases, would this search be easy to perform. With a computer database, these complex searches are easily performed retrospectively without advanced knowledge or preparation. Furthermore, this type of search would typically take less than 90 set to perform by computer. The time that the computer takes to perform a search or prepare a report is dependent on many variables. The most important is whether or not the search is performed upon an indexed field. When constructing the database the developer has the option of creating indexes or fields. Our system can manage up to 32,000 separate indexed fields. However, we appropriately elected not to index every field. Internal indexes use hard disk space and are updated anytime data are entered or modified. Too many indexes can slow data entry and create overly large data files. A typical report contains several indexed searches and may take about 2-10 set to appear on the screen. The fields that we indexed are those that are used most frequently for searching (hospital number, last name, date of birth, date of surgery, primary site of tumor, site, stage, etc.). The computer is able to perform a search on nonindexed fields (or a combination of indexed and nonindexed fields). The only disadvantage is that it takes longer. For example, a complex, nonindexed search on our over 2000 patient database typically takes up to 90 sec. This is an acceptable level of performance for infrequently perfomed searches.

ET AL.

mor registry process. For example, the residents have a vested interest in seeing that all surgery is entered in a timely and accurate fashion so that their case lists will reflect these events. The benefit is that these entries are simultaneously adding to the physician’s case list, specifically, and to the tumor registry, in general. The implementation of this registry has allowed our Division of Gynecologic Oncology to accumulate information relatively easily. The housestaff consider the time investment of 15 min per day to be worthwhile for the daily census report and ongoing physician case lists. However, in addition to these reports for daily patient care, a complete and timely tumor registry is also emerging from these efforts. The registry is valuable as a research tool and as a means of following the clinical activity on a gynecologic oncology service. In the future, we intend to expand our system to be multiuser. We have placed network cabling throughout our department linking our oncology division and gynecology clinic so that several computers could simultaneously access the database from remote locations. One may hypothesize that it would be useful for all gynecologic oncology services to have a common computerized tumor registry that is capable of sharing data between centers. This could be the start of a national or even international gynecologic tumor registry network. The implementation of such a network would probably have to be in phases. At present, we are conducting a multicenter trial of this database with the approval of the Society of Gynecologic Oncologists. Ten university DISCUSSION centers in the United States and Canada are now testing Several computer databases are already in use for ac- the system in their gynecologic oncology divisions. From cruing clinical information. The importance and power this test we hope to (1) establish whether our database of a computerized gynecologic tumor registry has been is applicable at other centers, (2) identify and eliminate previously described at the Medical Center Hospital of bugs and inaccuracies, and (3) develop additional feaVermont [l]. The University of Texas Medical Branch tures that would be of general interest. Following the has implemented a hospitalwide computer-based tumor multicenter test, we will have a period of debugging, registry emphasizing that the system uses “commonly refinement, and feature enhancement. When the refineavailable, well-documented, readily maintained, and eas- ment process is completed, we will resubmit the database ily used data management resources” [2]. We feel that to the SGO for consideration. If approved, the system our system’s user friendliness is unique-the software is may be made available for general distribution to the accessible to computer novices and database experts membership of the SGO. It is hoped that the sharing of alike. The willingness of the many residents, fellows, data on such a large scale would lead to a better unand nurses to learn and use the system has exceeded derstanding of both common and rare malignancies of our expectations. Residents have, on average, taken be- the female reproductive tract. tween 1 and 3 days to become comfortable using the system. Comments have almost uniformly been positive. REFERENCES Many even consider data entry “fun.” In most institutions, the tumor registry is isolated from the day-to-day 1. Belinson, J. L., McClure, M. S., ad Deutsch, R. A. A new automated tumor registry and clinical research system and its application clinical management of patients. This registry is also to gynecologic oncology patients, Gynecol. Uncol. 27, 264-268 unique in providing daily census reports, case lists, and (1987). weekly statistics for the clinicians who are both caring 2. Hokanson, J. A., Costanzi, J. J., Smith, M. S., Richard, P., and for the patients and entering the data into the database. Dugat, P. S. Design considerations for a medical school hospital cancer patient data system, Cancer 51, 1556-1561 (1983). This makes the clinician an active participant in the tu-