An automated system for record keeping, test reporting, and QC in gyn cytology.

In 1985 the need to automate record keeping, reporting, and quality control in our cytology laboratory led us to develop a system based on an IBM AT-compatible computer. Since the program's inception I have made many improvements in its form and function.

Our private laboratory is relatively small; cost versus benefit figured prominently. We process approximately 16,000 gyn cytology specimens each year. Our initial investigations found that most of the commercially available software had been designed for the large clinical laboratory and was very expensive. Our next step was to investigate the possibility of designing our own computer program with commercially available database software.

Early discussions ruled out the need to share information with our facility's billing department, which already had a computer system up and running. Our department had no need to access information such as patients' addresses, telephone numbers, or insurance companies. We decided not to attempt to include surgical pathology diagnoses because each of our five pathologists phrases them differently. Including all such diagnoses as free text would have made statistical analysis difficult.

* Software and hardware. The software we selected was DOS-based dBase III+ . This database software was an industry leader. We knew we could find many sources of additional support by way of books, tutorials, and magazines. Last month's Computer Dialog column described a program done on dBase IV + for abnormal morphology.[1] Many of the same principles apply in my program, which could also be implemented with the newer version of dBase or with any other database language that allows the user to write a set of instructions to accomplish a task-Paradox (Borland International, Scotts Valley, Calif.) or Foxbase (Fox Software, Perrysburg, Ohio), for example.

The hardware consisted of an 80286 CPU computer running at 12 MHz. We purchased a streaming tape backup device, an IBM-compatible color dot matrix printer, and a color monitor. The system became operational in October 1986; its cost, including software, was $5,865. The current availability of faster, less expensive computers only enhances the usefulness of this computer application.

We learned early that the microprocessor speed (measured in megahertz) was far less important in database applications than the hard disk access time (measured in milliseconds). Most data manipulation was to and from the hard disk. Consequently, when our first hard disk failed after three years, we upgraded to a larger and faster hard disk rather than to a faster CPU. In today's market, the purchase of at least a 80386 or 80486 computer and a very fast hard disk is within any laboratory's budget.

I worked closely with a local dBase programmer until I learned the basics. It was not difficult to learn, but it was extremely time-consuming. Over the course of a year, I spent about 75 hours learning database programming and an additional 125 hours writing, testing, and debugging the program.

Our cytology laboratory software system is completely menu driven. Each action--entering a new patient, printing a report, seeking a diagnosis--is simply selected from a menu (Figure 1). From that point, the user is prompted for the necessary information.

I made every effort to include extensive error checking in the program. For example, a user who enters a nonexistent client code number is so notified and given the opportunity to add a new client or reenter the information correctly.

The structure of a database is similar in format to that of a telephone book. A record is a group of items, called fields, that pertain to a specific patient. The field is a specific item within that record, such as the accession number (Figure 11). This information can then be quickly sorted and retrieved.

Our preliminary setup included the creation of diagnostic statements and associated three-digit code numbers, client data files, and input of any patient histories available from our existing paper files. These statements were coded and kept in a separate database to minimize the storage requirements of each specimen. For example, the code 303 signifies that Trichomonas organisms are present.

We began the design of our database files by determining what information was required to appear on the report and what questions should be asked on the requisition slip. Because we tend to accumulate many specimens on each patient over a period of years, we decided to make two separate computer files. The first file would contain information specific to each patient. The second file would contain information specific to each specimen. These files would be related to each other by a common field.

Initial data entry occurs after specimens and request slips are labeled and prepared for staining. Our lab assistant does the initial data input, which includes name, date of birth, Social Security number, and hospital or clinic file number. In creating this part of the program, I realized that we had a unique problem. I needed a fast way to search the database for previous specimens from the same patient--a unique identification that could be assigned immediately and used to search existing files for other specimens with the same ID.

Since the specimens were processed before the tests were billed, I could not use the billing account number as a reference. With the help of our dBase programmer, we chose to establish a cytology patient account number by combining the first four letters of the patient's last name with the full date of birth; for example, YORK012555. This account number could be assigned immediately to each patient entered and would also serve as the field for the relation between the patient file and the specimen file.

The plan has worked well; our database of approximately 40,000 patients has held only 0.01% duplicate account numbers. Nevertheless, we had to modify the system to accommodate two or more patients with the same date of birth and first four surname letters. I incorporated into the program the ability to add a new patient to the database even when another existed with the same account number.

With this information and a dBase index file, the computer instantly checks to see if that patient is in the system. If a record exists, a history report is printed and attached to the specimen requisition for the cytotechnologists to review before examining the specimen. The history report includes the previous accession number, date, diagnosis, technologist, and descriptive diagnostic comment for each specimen in our files.

A second input screen then prompts the user to provide information specific to the current specimen. This includes date of collection, primary physician, secondary physician, submitting facility, clinical history, patient's last menstrual period, and source of the specimen. The accession number is automatically assigned and displayed with each sequential entry.

Before implementing our system, we sent a letter to our physician clients stressing the importance of their providing accurate and complete patient information, with special emphasis on name and date of birth. On average, we call physicians' offices for one or two missing birth dates every day--not a bad record. (In the past, we often received the patient's age, not birth date, which was sufficient at the time.) Recently, partly in response to CLIA '88 regulations, we began to return unusable smears to the physicians' offices that sent them. In a rejection log, we list all smears that arrived lacking the patient's birth date, bearing an incomplete history, or incorrectly labeled.

When data entry is complete at the end of each day, a daily log sheet is printed. The log sheet, requisition slips, and patient histories are carried to the cytotechnologist's desk. On the first log sheet (bearing the accession number, patient name, and physician name, but no diagnosis), we indicate which of the randomly selected cases (I 0% in all each day) will be chosen for quality control review. Each technologist examines a batch of slides, recording diagnostic comments (in code) on the request slip.

The history printout has proved extremely beneficial for historical review of previous specimens as required by new state and Federal regulations. After screening, the cytotechnologist takes the slips to the computer and enters results sequentially--up to seven coded statements per specimen. Beyond that, comments can be added as free-form text using a dBase memo field.

If an abnormal diagnosis is entered, the computer beeps to notify the operator and asks for confirmation. The program was originally designed to accept Papanicolaou classifications I-V, unsatisfactory, and other. Since then I have updated the reporting system to include the Bethesda nomenclature. Abnormal reports held for review by the pathologist are skipped during data entry. The request forms, forwarded to the billing department, serve as a paper trail and ultimate backup.

Once Pap smear results have been entered, we can obtain the results at any time by accession number or patient's name. This capability saves us a great deal of time when retrieving patient reports. No longer do we spend 5 or 10 minutes searching paper files stored in imperfect alphabetical order. Another substantial time-saver is that we no longer manually sort and file such paper reports.

Immediately after entering a batch of reports, the cytotechnologist is prompted to print them. The range of accession numbers just entered is carried over to the printing program automatically. To insure that all reports are printed, we print each batch immediately after entry. Once the day's work has been completed, we print a second log sheet (which includes diagnoses) to confirm that all results have been entered.

Our reports are on single-part half-sheet letterhead (Figure 111). Each gyn report is printed in sentence format and consists of the statements corresponding to the three-digit codes that we created during initial setup. We can add to these statements as needed. Abnormal diagnoses stand out because they appear in bold red. To accommodate the few clients who want two or three copies, we programmed the computer to generate multiple copies for them routinely.

* Menu for updating. I created a separate menu choice for editing the gyn data files. Since the two files are related, both must be updated appropriately and automatically. For example, if we correct a date of birth in the patient file, thus altering the patient account number, the computer must automatically update the same person's account number wherever it appears in the specimen file. To minimize accidental alteration of other fields, I set up the editing program to permit access to only one field of information at a time.

Each menu choice that provides access to altering files is password protected. The password mechanism is not complex, since we were not especially concerned that our data were at risk from prying eyes. We merely wanted to avoid accidental data entry or alteration by a person unfamiliar with the system.

All records are saved permanently to the hard disk. The size of hard disk needed depends on the volume of tests performed and the length of time they are to be stored. HCFA requires that all cytology reports be kept for 10 years. In our database, each patient record occupies 80 bytes and each specimen record 161 bytes. A test volume of 16,000 per year would require about 4 Mb of hard disk storage capacity for each year to be saved. Additional storage is required for program files, ancillary data files, and temporary files used during statistical analysis.

In anticipating storage capacity, a rule of thumb is to calculate how much you need and double it. When our disk is full, we will archive all benign Pap smears. Abnormal histories will still be retrieved with history printouts. As storage media grow faster and larger, we may never have to do this.

One benefit of computerization is the speed and accuracy with which you can calculate and summarize. These reports are found under the statistics menu. A list of patients needing follow-up is printed for correlation with our surgical files. Follow-up letters are generated automatically to any client whose patient has had abnormal results on a Pap exam but no repeat smear or biopsy within a specified time. While surgical biopsy reports are not part of our program, we can enter surgical diagnoses for inclusion on patient history reports.

* Summary reports. Summary reports for a single client or all clients can be generated for any period specified. (We have found this procedure valuable in complying with CLIA '88 as well as with California state law.) The reports include the percentage of each Pap diagnosis among the patients of each physician and how that doctor's percentage compares with the laboratory experience as a whole (Figure IV). We send our physician clients a copy of this report quarterly so that they can compare such findings as their own percentages of unsatisfactory smears with the average.

A list of patient names can be optionally appended to this statistical report to aid the doctor in follow-up. From this statistical summary, a client volume report is compiled, primarily for internal use. It lists how many cases were received from each doctor or facility and what percentage of our lab's volume that client comprises. Output from any of these reports can be displayed on the computer screen or directed to the printer. A year ago, by some clients' request, we began to send each client a monthly patient recall report listing patients who had had a Pap smear 11 months before.

The utility menu enables us to carry out housekeeping functions and to maintain supplementary data files. Supplementary files include the client file, diagnostic statements, and patient history statements. From this menu we can reset the accession number, enter biopsy diagnoses, and prelabel requisition slips with the client name, phone number, and lab code number. Preprinting this information on request slips before distributing them helps speed data entry when these slips are returned to the laboratory for processing. We print mailing labels from our client database as well.

* Time spent, time saved. While retrieving, reporting, and summarizing our data take little time, it takes longer to enter patients into the computer than it did with handwritten logs. Although we now track more information than we did before, the primary problem was learning and entering the code numbers associated with the various statements. We minimized this problem by including preprinted code numbers for patient history, client, and physiologic source of specimen on request slips. I also added the ability to look up client code numbers alphabetically (that is, by keying in the first three letters of the client's name) while entering specimen information.

We have found that the ability to edit our own program and write small special-purpose programs ad lib is a tremendous benefit. It is also possible to go "back door" to find information that cannot be retrieved via routine menu choices; for example, we can look up how many patients are 40 years or older. Since special statistics must be derived from the command line of dBase, we go into the system for such purposes very carefully.

Teaching has not been a problem. Only one lab assistant, another cytotechnologist, and myself use the program routinely. I planned it to work relatively simply, offering sequential prompts for information. Secretaries can look up test results on a read-only basis--a system I programmed after a secretary accidentally entered erroneous data that we had to delete.

I do not mean to suggest that writing your own computer program is simple. I did most of the programming at home. I am very fortunate to have supportive directors and staff. I found the project challenging and rewarding, but it is certainly not for everyone. As we continue to refine and improve our software, we recommend this route to anyone with the time, energy, and knowledge to pursue it. [1.] Jackson, V.C.A database for abnormal morphology (Computer Dialog) MLO 24(4): 55 58 April 1992