Sara J. Perkel,1 Gloria Stewart, Lisa Lattal, Linda M. Arenth, Catherine Kelleher,

Anne Kammer, Bruce I. Blum, Gary L. Kinsey, Farideh Momeni, and Alan W. Sacker The administrative component of the Oncology Center has been a major advocate of the OCIS since its inception. Although the initial funding mechanism for OCIS was from a grant, central core funds procured by the oncology administration have provided the majority of developmental and maintenance activities for the past decade. In fact, the Hospital components of OCIS are a direct responsibility of the Center’s central administration. As described in Chapter 1, during the planning stages of the Oncology Center building in 1975, it was recognized that computer-managed medical data would be of major benefit in providing high-quality care for cancer patients. OCIS was established with that as its fundamental mission.

As the OCIS began to take shape, it became apparent that the data that were being collected and used for patient care had secondary or “spin-off” uses. Generally, these secondary uses of the OCIS database were in the areas of general administration and research. Two of these secondary uses have been described in detail in Chapters 6 and 7, that is, the pharmacy and blood products systems. These two functions have become integral components of OCIS from both an administrative and clinical care perspective.

A wide variety of other administrative functions, which play a varied role in primary clinical care activities, have been directly integrated into OCIS. However, all of these functions are an essential ingredient in the primary purpose of the Oncology Center, that is, to provide the highest quality care possible to its patients. There is a natural relationship between administrative, clinical, and research activities in a setting such as the Oncology Center, which OCIS has helped to facilitate.

These secondary functions of OCIS include monitoring the patient load of the Center through patient census data and patient mix trends. The inpatient census

‘Sara Perkel, M.B. A., joined the Center in 1983 as the assistant administrator of Oncology. In 1987 she assumed the position of Administrator of Oncology and became fiscally responsible for OCIS operations.

provides an instantaneous picture of bed occupancy, the units that are at highest occupancy, the potential supply needs, and an understanding of the personnel needs for a particular day. On the more demanding and turbulent OPD facility, the projected visits allow administration to be aware of an overload situation and alert other associated areas to potential problems.

Another function is to provide data for personnel and other resource-forecasting activities. As discussed later in this chapter, it is extremely important from an administrative perspective to have the ability to project future needs. Such projection capabilities allow facilities to gear up to meet future demands before they occur. One example of forecasting is based on the fact that the primary treatment of cancer patients is increasingly being provided as an outpatient service. The percentage of outpatient to inpatient facilities will have to be adjusted for in the near future. Another trend noted is that inpatients have become increasingly acute over the past several years. Thus, the nurse-to-patient ratio must be adjusted accordingly.

Data routinely collected by OCIS also allow central administration to respond quickly to data and statistical requests made by the Hospital’s central administration and various federal agencies. Additionally, as most procedures and patient charges are captured directly by OCIS, there is an accurate means of documenting services to auditors from both third-party payors and various federal agencies, such as NCI and FDA.

In the following sections of this chapter, examples of these secondary uses in individual functional areas are provided. The authors of the following sections in this chapter are the individuals who have developed and/or are the primary users of these functions. Information on these authors is provided at the beginning of each section. It should be pointed out that there are numerous additional spin-off functions of OCIS that have not been described in detail.

Inpatient Admission, Discharge, Transfer (ADT) Scheduling2

The Johns Hopkins Oncology Center (JHOC) contains 70 beds in four inpatient nursing units. There also is a 14-bed Pediatric Oncology Unit residing in the Children’s Center of the hospital. OCIS is used to schedule the admissions and discharges for these units. The formal admission process, however, is managed by the central hospital ADT system. In this section we describe how OCIS is used to schedule JHOC inpatient resources and how inpatients are entered into the OCIS database.

The Inpatient Scheduling System OCIS maintains an on-line scheduling system for oncology inpatient admissions. A physician schedules an admission for a patient with the Oncology Admitting Office, and the admissions officer enters the data into OCIS. This schedule is available on-line to all users. This allows physicians, nurses and administrative personnel to view expected admissions for each unit. Figure 1 shows a schedule of expected admissions. It is sorted by date of admission and displays patient history number, name, inpatient unit, and reason for admission.

The use of the OCIS inpatient scheduling function is restricted to the Department of Oncology Admissions and OCIS clinical data coordinators. New patients can be scheduled for admission without a medical record number by the automatic generation of a unique temporary “dummy number” through OCIS. When the patient is actually admitted to an inpatient unit, OCIS will insist that a valid medical record number be entered before the admission can be completed.

OCIS Admission/Discharge Function Each inpatient admission in the Oncology Center and Pediatric Oncology is entered into the OCIS census. These entries are maintained by the clinical data coordinators assigned to the inpatient units. When a patient is physically admitted to a bed on an inpatient unit, the data coordinator enters the admission into OCIS. If the patient is listed on the OCIS scheduled admit list, the coordinator transfers the name from the schedule to the inpatient census, making any corrections to the date, reason for admission, or the location displayed on the scheduled admission list. The coordinator will also enter the expected length of stay (LOS), which is based on documentation from the physician. Long stays are entered as 15 days and are modified when the estimated LOS reaches 14 days or less; OCIS automatically subtracts days for an estimated LOS of 14 or less. This listing of LOS assists the physicians in planning bed utilization. Naturally, the coordinator can modify the estimated LOS at any time should the discharge planning data change.

As noted in Chapter 6, the OCIS pharmacy applications are tied to the OCIS census. Because no orders can be entered into the system if the patient is not on the OCIS census, oncology pharmacists have been provided with admissions capabilities as well. However, the data coordinator is responsible for seeing that the census entry is correct.

Upon patient discharge, the coordinator enters the date of discharge, as well as the patient status (discharge, transfer, expired). It should be noted that, although the census/pharmacy admission is tied, the census discharge does not result in a pharmacy discharge, since this would stop active pharmacy orders currently running. Instead, the pharmacy receives an electronic message that a census discharge has occurred. Pharmacy verifies that this information is correct and then initiates a pharmacy discharge that stops the active pharmacy orders. This is an important quality control measure to ensure that critical medications are not interrupted in the event of a discharge error by the clinical data coordinator. In addition, no census discharge is processed until the patient has physically left the inpatient unit.

As stated earlier, the main Admissions Department of the hospital maintains a separate system that also records all admissions and discharges for the entire hospital

Figure 1. Schedule of expected admissions.

. There are several reasons for this duplication. All inpatient billing is the responsibility of the central hospital systems; naturally, they need the admission and discharge data to support this function. From the JHOC perspective, the inpatient census establishes a central link for many of the internal operations of the Center. We have seen that a patient must be entered into the OCIS census before any pharmacy orders can be entered into the system. A unit-specific online census is available to all users throughout the Oncology Center. This serves as a patient locator; a physician can access any terminal in the Center and view the number of patients on a given unit at that time (or their clinical data). Finally, the OCIS census provides a mechanism for recording the dates of all admissions and discharges for a historical review by patient, unit, diagnosis, protocol, etc.

The standard format for the unit census is the inpatient OCIS home screen shown in Chapter 4. This menu sorts the patients’ names alphabetically and displays medical record number, date of admission, and estimated LOS. In addition to the on-line census, there are a number of census reports generated on a daily basis.

The admitting census is generated at 11:30 p.m. each day. It is a snapshot of the census for the Center at that time. More than 60 copies of this report are produced for use by health care professionals throughout the Center. The admitting census is sorted by inpatient location and displays history number, name, diagnosis, admission date, and estimated length of stay for the current inpatients. In addition, the report lists scheduled admissions for each unit sorted by date. A sample is shown in Figure 2.

As discussed in Chapter 4, the OCIS inpatient census serves a number of other important functions. The admission data are kept on line for a historical perspective. Because the data are patient specific and on line, the census allows a physician to review immediately the data of the last admission for his patient, as well as the number of days of hospitalization. The census also contains other helpful information, such as outpatient visits and protocol history.

To illustrate how the clinical and administrative functions are linked, consider this example. It is common JHOC practice to administer chemotherapy in an outpatient setting and delay admission until such time as a toxic reaction develops. This approach improves the patient’s comfort and also reduces the cost of treatment. Naturally, the technique requires planning. The on-line census is one tool that aids the physician in this planning process. If a patient is hospitalized for low blood counts following an earlier course of chemotherapy, the physician can review the census to determine the number of days following chemotherapy that the admission occurred and the length of stay. This information can be used when planning another course of the same chemotherapy. The patient’s response can be anticipated, and an admission can be scheduled to reserve a bed.

Support to the Outpatient Department (OPD)3

The Outpatient Department (OPD) is a significant and growing component of patient care at the Oncology Center. During its early development it became obvious that in order for OCIS to be effective, it was essential to incorporate functions for the OPD. The close links between the inpatient units and the OPD have grown over time as a result of the increasing importance of ambulatory care in the treatment of cancer.

Structure and Flow The basic functions of the Center’s OPD are similar to those of other ambulatory areas. Patients come to the OPD to see their physicians, to get treatment, and to have blood or radiology tests. Like many ambulatory care areas, there is a great deal of diversity in its functions and in the duties of its staff. The diversity of activity, combined with a patient load that approaches capacity, creates an obvious need for automation wherever possible. Additionally, there is a need for each of the automated functions to be integrated and to run in real time, which is essential for the OPD environment. As with any OPD, communication between providers is a critical element in effective and efficient patient care.

The Johns Hopkins Oncology Center OPD is a busy clinical area with two practice sites. The consultation service is located in a geographically separate office building and serves new patient consultations and breast cancer programs. OPD

3This section was written by Lisa Lattal, J.D., who joined the Oncology Center in 1986 as the Ambulatory Services Manager. She has over 10 years experience in ambulatory health care facility management. She has participated in the ongoing development of the outpatient functions of OCIS over the past several years.

Figure 2. Scheduled admissions for each unit sorted by date.

provides examination rooms for physician and nurse visits, and includes a large infusion area for the administration of intravenous treatments and the carrying out of nonsurgical procedures. Both locations together see approximately 26,000 patient visits annually and service 50 physicians.

The primary administrative functions of the OPD include patient registration, appointment scheduling, flow tracking and control, charge capture, resource utilization monitoring, and forecasting future requirements. The OCIS serves to automate and integrate these functions. By doing so, it provides an essential component in the efficient operation of an OPD—communication.

The Johns Hopkins Oncology Center OPD depends heavily on OCIS for the administrative and medical components of patient care. OCIS terminals have been located in strategic places to facilitate the retrieval of this information. All clerical employees have OCIS terminals at their workstations. Several are spread throughout the physician/nurse work space, which is the staffs base of operations while they see patients. Terminals are also located throughout nursing areas and in ancillary departments. The general availability of data services throughout the OPD helps improve staff members’ efficiency.

All patients are preregistered in OCIS prior to their first encounter with the OPD. Demographics, insurance information, and preliminary clinical data are collected in the preregistration function. Patients are registered into OCIS at each visit. The scheduling function is the master patient and physician tracking system. Patient visits to physicians and other providers, laboratory tests, radiology tests, and outpatient procedures are all integrated in the OCIS schedule system.

The schedule and registration information is used as a guide to track and control patient flow. Patient flow-tracking forms are printed and appointment history records are maintained. The collected data are used for charge capture, and statistical and documentation purposes. Charge capture is the process whereby a day’s activity is translated into billing information. Charges are collected on a patient-specific basis and are distributed to all appropriate billing offices. The collection of all these data provides a substantial database that can be used for monitoring resources and forecasting future needs.

Patient Registration The OCIS allows for two types of registration. The first of these is a new patient preregistration. This is done by the new patient referral coordinator for every patient who is new to the OPD. The second type of registration is a return registration. This is the routine registration that occurs every time a patient comes to visit the OPD and is checked in by a registrar.

New Patient Pre-registration. All patients referred to the OPD for the first time are screened by the referral coordinator, who reviews the patient’s basic referral data and schedules a preliminary appointment for physician consultation. After the referral coordinator has determined that a patient is eligible to be seen at the JHOC and will be scheduled for an appointment, the pre-registration is then begun.

Because the time between appointment scheduling and when the appointment takes place is relatively short, pre-registration information is collected by telephone and directly entered into the database. The availability of pre-registration information avoids a protracted on-site interview at the time of the first visit. It also allows the referral coordinator to assign a hospital history number prior to the visit. The basic demographic, insurance, and referral information collected is also used in clinical decisions, billing functions, and research concerning the patient population.

Insurance information and primary diagnosis and histology information are routinely collected for new patients as part of pre-registration. The referral coordinator also obtains the reason for the consultation in the patient’s or the referring physician’s own words. Data on referring physicians are collected including the physician’s name, hospital number if any, and mailing address to which copies of medical records should be sent.

Specific diagnosis-related data may be requested of the patient. Such items are identified in a “Diagnosis Data Requested” section. Examples include a referring physician

Figure 3. On-line New Patient Referral Form.

letter, treatment records, hospital medical records, pathology slides, x-ray film, scan films, Johns Hopkins Hospital chart if any, and Johns Hopkins Hospital x-ray if any. This section allows the referral coordinator to keep track of when this particular information was requested and when it was received. It also provides control so that the Center knows when or if it has received items belonging to a patient for review by the physicians.

Finally, the pre-registration includes the date and time of the patient’s first appointment and the name of the physician the patient is scheduled to see. This is done through OCIS using the scheduling system.

Pre-registration data are retrievable on line and in hard copy. The on-line function is called the “New Patient Referral Form.” The data collected can be viewed in its entirety on an OCIS screen. In the hard-copy format, the information is printed on a single page (Figure 3). The form can be used by the referral coordinator to document the receipt of requested data and is also included in the new patient’s medical record. In this way the consulting physician has the benefit of all of the information gathered previously by the referral office.

Return Registration. The second type of registration is performed when the patient comes to the OPD. Each registrar receives a daily hard-copy schedule, produced by OCIS. The schedule shows those patients expected for appointments on that particular day, and which provider the patient is scheduled to see. The registrar verifies that the demographics and insurance information are correct, and updates any changes. The registrar completes the process by filling out any necessary forms, indicating in OCIS that the appointment has been kept.

Automated Scheduling System The OCIS provides an automated scheduling system that allows multiple users to schedule appointments and multiple viewers to view these schedules simultaneously. It permits on-line scheduling and instantaneous changing.

Scheduled Items. Every time a patient has an appointment to see a physician, and every time the patient is scheduled to come to the OPD to see a nurse, have a procedure done, receive chemotherapy, or have another test, the patient’s encounter is scheduled into OCIS.

Schedules are created in a variety of ways. The registrar or referral coordinator enters into OCIS the patient’s name, who he or she is to see, and the date and time of the appointment. The registrar also schedules any anticipated laboratory tests and x-rays or other radiology services that the physician has ordered for this patient.

By using this system, the registration staff can anticipate the patient’s arrival and paper work can be prepared prior to the patient’s visit. When the patient comes to check in, the registrar can view the list of tests that have been ordered for that patient, compare it with the completed forms, give the paperwork to the patient, and direct the patient to the next stop.

A registrar who wants to make an appointment for the given patient will, upon selecting the appointment function, be given a choice of the site at which the patient is to be seen. These choices include each of the ambulatory care delivery sites. A registrar in one delivery site can schedule a return appointment for the same or a different service location within the Oncology Center. This prevents the patient from having to walk to the area where the next appointment will be, and it also reduces the amount of interdepartmental telephone activity that would be required to schedule appointments in multiple sites.

Within each department, appointments are organized by clinics. A “clinic” is a way of classifying patient appointments on the basis of the service to be received or the type of provider. For example, a clinic may include only those patients who are scheduled to see a physician during their visit, or only patients who are scheduled to see a nurse or a physician assistant. This allows an administrative segregation of visit types, which is useful as a base for statistical reporting and resource use analysis.

Scheduling Authority. Input to an automated scheduling system is carefully controlled. In contrast to viewing the automated scheduling system, the input function has a higher possibility of error. Input of patient appointments into the scheduling system is limited to specially trained and supervised members of the registration and referral staff. Although nurses and physicians can view the appointment system in any one of a number of ways, they are not permitted to enter appointment data into OCIS.

Patient convenience may be enhanced by having a registrar schedule all appointments and ancillary tests. During the encounter, the follow-up actions are recorded. This includes the time of the next visit plus any tests to be completed prior to the time the patient returns. The registrar coordinates the scheduling of these activities in a way that is most convenient for the patient. For example, if the patient prefers, all tests and appointments can be scheduled on the same day. After an appointment is scheduled, OCIS lets the registrar select a printed appointment reminder slip. This slip is usually generated so that the patient will have a written record of the date and time of the next appointment.

Schedule Framework. OCIS allows the user to create a framework in which to schedule by entering certain parameters into the system, including the physician baseline schedule, vacations, and holidays. The registrar can enter a physician’s preformatted schedule preferences, which will be retained for all future scheduling until they are changed. (Quite often the physician’s other commit-

Figure 4. Automated scheduling system appointment entry screen.


Figure 5. Automated scheduling system schedule view by clinic for specific day.

ments leave a very limited number of time slots in which to see patients.) OCIS allows the permanent recording of these baseline schedules and then permits the registrars to make adjustments for changes as needed. Data entered into the baseline schedule include the days and time blocks on which the provider is available, and the amount of time he or she wants to allocate for each type of visit (Figure 4).

If a provider intends to take a vacation, that fact is entered into his or her OCIS schedule. The supervisor responsible for dictionary maintenance can block out all the appointments previously open for that provider during the time of absence. A registrar cannot schedule a patient to see the physician because the days of absence are already blocked off on the computer. The use of this approach avoids a situation in which one registrar is aware that a provider will be gone on a certain day but forgets to pass that information on to other co-workers.

The ability to format a schedule also allows the registrars to close off available appointments because of a hospital holiday. The supervisor enters into OCIS that a particular day is an OPD holiday. The system will automatically close out appointments for all providers for that day. This feature prevents the need to close out individually appointments for each of 40 or 50 available providers.

Use of Schedule. All OPD users of OCIS have access to viewing the scheduling system. Users have the option of viewing the schedule by physician, patient, or clinic. Within these categories, viewers can examine the schedule for a particular day, a particular period of time, or from the beginning of the patient’s history at the center. There is also an option for a print function in case a hard copy of the schedule is needed.

In viewing the schedule by clinic, the user is given a choice of ambulatory area to be viewed and is then asked to input the name of the desired clinic schedule. Then, in response to prompts, the user would tell OCIS to display those patients scheduled for the selected clinic on the selected date. The screen will show a list of the patients with an appointment in that clinic for the particular day selected (Figure 5). As can be seen, the screen shows the patient’s name, history number, time of appointment, clinic, and provider.

This option also allows the user to determine whether a patient kept any scheduled appointment. A “kept” appointment is designated by a “K” before the patient’s name. A “no show” is designated by the absence of the “K.” Schedules are maintained on OCIS permanently in an interactive mode. A viewer can search back several years to see whether a particular patient kept a particular appointment (Figure 6).

The schedule view option also allows users to examine schedules by provider. To see a list of patients scheduled for a provider on a particular date, the user would look in the scheduling system under the provider’s name for the date in question. The OCIS screen will show a listing of scheduled appointments, including the time and the patient’s name and history number (Figure 7).

OCIS also permits viewing of a patient’s past and future schedules. This can be selected as a full list of all of the appointments the patient has ever had in the OPD, or as a short schedule beginning from whatever day the user specifies. This option provides a history of the patient’s ambulatory activity at the center.

Links of Schedules with Other Areas. An important feature of the scheduling system is its ability to link with other parts of OCIS. Two primary linkages are those with charge capture and medical records.

Figure 7. Automated scheduling system search by”physician appointments.

The linkage with charge capture allows the registrars to process patient charges accurately. The day after a patient’s visit, OCIS will automatically transfer to charge capture the data on all patients who have kept their appointments. The charge capture registrar then edits this information and adds any additional data in order to complete the charge capture process.

Likewise, the Medical Records Department is sent information from the scheduling system. Medical Records will receive a daily list of those patients scheduled for visits. This serves as the basis for their chart-retrieval function. OCIS also prints a sign out slip which Medical Records can use to inform the medical records clerk which provider has the chart and when it was requested.

These linkages help to expedite communications within the center. The automatic flow of information eliminates the need for a staff member to remember how to communicate these data. Since both functions are of a relatively detailed nature, the automated transfer feature helps to reduce the incidence of error by eliminating the chance of transfer mistakes.

Routine Reports The OCIS produces a number of routine statistical reports. These allow administration to have accurate information on the volume and distribution of patients within the department. They allow a knowledgeable viewer to look at the distribution of patients and appointments, and determine whether there are any irregularities, and they provide an archival database from which future budgets, volumes, and financial projections can be determined.

Clinic Statistics. The OCIS system produces a clinic statistics report on a daily, monthly, and cumulative fiscal year-to-date basis (Figure 8). This report shows the

Figure 8. Outpatient daily statistics report by patient by clinic.

number of patients who have visited the OPD during the period of time covered in the report, and categorizes these visits by clinic, by new and return patients, and by scheduled or walk-in patients.

The clinic statistics report also breaks down visits by charge category and enumerates procedures. This again is separated by clinic. Procedures and visits are categorized by hospital revenue and procedure code. In this way department activity can be expressed in terms of billable procedures. This is useful in examining volume and revenue potential. It is also valuable in spotting charge capture problems or changes in practice that may not be evident in any other form.

Outpatient Daily Statistics. This report is also produced on a monthly basis. It shows a breakdown of patients by clinic, and by new and return patients for each day of the month. From this report, the manager can see on one page and in one place a comparison of the new and return patients by day. This allows the manager to look for trends on new and return patients and also allows trends in the clinic population to be determined.

Daily Scheduled Show/No Show Report. The daily scheduled show/no show report gives information by day on the percentage of patients who did not keep their appointments. The report is broken down by clinic and further by new and return patients. The report gives the percentage of kept appointments for both new and return patients, and also the number of unscheduled visits. It totals the number of patients scheduled in clinic on a particular day and those who actually arrived for their appointments, and gives the percentage of patients who kept appointments. This report is issued daily and is also aggregated at the end of each month. It is a valuable tool for tracking problem areas or aberrations on the basis of type of patient visit.

New Patient Report. The new patient report is issued daily and shows the names of new patients who are scheduled for OPD appointments. These new patients are grouped by consulting physician. Appointment times and Hopkins history numbers are also shown. This report is a communication device that informs the physician, medical records, and administrative personnel what patients are new to the department and are scheduled for an appointment on a given day. This report is derived from input to OCIS by the new patient referral coordinator.

Clinic Summary Report. The clinic summary report is used primarily by the registration supervisor and the registration staff to assess the distribution of patient appointments for a particular day (Figure 9). It is printed by clinic, and shows the number of patients who are appointed during particular time slots. The registration supervisor can use this report to determine patient load for staff scheduling and to see when there may be periods of high or low registrar utilization. This report is also useful as a double check on the registrars to be sure that there are not more patients scheduled than the number of exam rooms available. By reviewing this report several days in advance, the registration supervisor can ensure an appropriate distribution of appointments throughout the day and correct any problems before they impact that day’s operations.

Patient Flow Control Tracking The OCIS produces or works with a series of patient-specific forms that aid in patient flow control, tracking, and documentation. These forms are the routing form, the encounter form, the charge voucher, and the documentation label.

Figure 9. Outpatient clinic summary report by day.

The routing form is used as the source document for billing. One routing form is generated by OCIS for each scheduled patient visit (Figure 10). Basic demographic information is printed at the top of the form, including the patient’s JHH hospital number, date of birth, and date of visit. At the bottom of the form is the patient’s diagnosis. The rest of the routing form consists of a list of procedures and visit types. These are categorized and labeled by hospital revenue and procedure code, and include a text description. If a patient is a walk-in, a blank routing form is used, and the patient identifiers are hand entered.

The Routing Form follows the patient through his or her entire visit in the OPD. Each provider who transacts a billable encounter with the patient indicates this on the routing form by placing a check next to the service provided. At the completion

Figure 10. Outpatient routing form for scheduled patient visits.

of the patient’s visit, the physician signs the routing form to signify that the services indicated have indeed been performed. Routing forms are gathered at the end of the day for input into OCIS charge capture.

Encounter forms are clinical documentation forms that are not generated by OCIS but instead are preprinted. They are used as a source document for the capture of clinical information to be input into OCIS. An encounter form is prepared for each patient visit. It is used by the clinical providers to record clinical data such as medication, chemotherapy orders, and vital signs. At the completion of a patient’s visit, the encounter forms are gathered for input into OCIS by a data coordinator. After these data are input, the encounter form becomes a part of the patient’s medical record.

The OCIS will print patient billing information onto hospital charge vouchers. Billing information is processed through OCIS by the charge capture system. One type of hard-copy output from charge capture is a printout of billable charges on a standard Hopkins hospital charge voucher. In this way the OCIS-generated output can be integrated directly into an existing hospital system for processing by the Outpatient Billing Department. The printing of charge vouchers also introduces another check into the accuracy of patient bills. After charge vouchers are printed, the registrar who entered the billing data is able to review the work by inspecting the charge vouchers before they are forwarded to the billing department. This allows the registrar to catch errors before they are printed on bills and sent to insurers or patients. Errors are corrected in OCIS, and corrected vouchers are then printed.

OCIS also produces various labels which are placed on encounter forms to ensure complete documentation. They are used to record information on the administration of platelets and red blood cells. By using these labels, the provider is reminded of which pieces of data are needed to properly document the procedure that is taking place. These labels help ensure consistency and completeness in documentation. They are affixed by hand onto the patient’s encounter form. Although the label is printed blank, and does not capture any patient data from OCIS, the use of the label ensures that the appropriate information has a better chance of being captured.

Charge Capture The OCIS charge capture function allows for the computerized collection and recording of patient charges incurred in the OPD. It also maintains an on-line record of past charges so they can be referenced in the future.

Patient charge information is retrieved in two ways, directly through OCIS and from OCIS-generated hard copy. The charge capture program is linked to the patient scheduling system. As described, above, when a patient presents for a scheduled appointment, the registrar signals this to OCIS through an appointment-kept flag. OCIS then transfers its data about this appointment directly to charge capture. The charge capture registrar is presented with baseline data that list the patient’s scheduled appointments and any laboratory tests, x-rays, or procedures that were ordered. If a patient appeared for an appointment and tests were ordered, OCIS presumes that these tests were carried out. Any variations from this can be recorded in the charge capture editing process.

The charge capture function is a mixture of editing and data entry. The registrar views each patient’s account and then adjusts it as necessary to be sure it is correct. For example, if the patient was scheduled for a Heme-8 lab test, but the laboratory informs the registrar that the test was canceled, it is then deleted from that patient’s list of charges. This is the editing function.

The data entry function consists of entering any additional charges incurred by the patient and not included on the patient’s original list of charges. The primary source documents for this are the routing form and an OCIS list of pharmacy charges. As described earlier, the routing form is the patient-specific document used by the physician and nursing staffs to record billable services. The charge capture registrar examines each completed routing form and the pharmacy charge list for additional charges, and will then input this information into OCIS so that the patient’s charge record is complete and accurate. When one patient’s record is complete, the registrar will then move to the next patient and repeat the same procedure.

In order for this system to work successfully, all faculty and staff members must be conscious of the importance of accurate and complete charge capture. This requires education. The provider is expected toidocument his or her services clearly and accurately. The laboratory must remember to inform the charge capture registrar if a scheduled test is canceled. Likewise, each frontline registrar must be compulsive about accurately recording whether patients have or have not appeared for their scheduled appointments.

This system does have some checks built in. The list of drug charges generated by OCIS from input by the pharmacy provides a check for recording the administration of chemotherapy, which is the most costly procedure. By using this type of check system, the chances of missing important charges or incorrectly charging for services that were not delivered are minimized.

After all the charges for a given day are put into the system, OCIS will print the data gathered in charge capture in two formats. One format is for hospital billing and the other is for professional fee billing. The hospital billing data are printed on individual hospital charge vouchers, as described above. The professional fee billing data are printed in report format, listing all patients to be billed, all billable procedures that may have a professional fee component, the name of the provider, and patient identifiers. The Professional Fee Billing Office can then use this report as the basis for issuing bills for physician services.

The database created by charge capture is an extremely valuable tool. It is used as the source for multiple operational statistics. In addition, the lists of billed patient procedures are stored in OCIS. If there is a problem with a patient bill a staff member can view on line a copy of the patient’s outpatient charges incurred on a particular day (Figure 11). This provides a rapid response to patients and assists in maintaining quality control.

Resource Forecasting The database collected by OCIS provides a wealth of historical information for use in resource forecasting. In addition to the standard reports, data can be arrayed in any number of ways by writing a program in OCIS. Using these historical data, the manager can prepare more educated forecasts of future patient volume.

Figure 11. Outpatient charge capture report for individual patient.

For example, in planning the number of physicians scheduled to see new patients for the coming fiscal year, OCIS provides historical data about the number of new patient visits for the past several years. It refines the data by breaking down new patients into individual clinics and reports what percentage of scheduled new patients did not show up for their appointments. Using these data, the manager can predict trends and obtain an estimate of the required staffing.

The Acuity of the Illness Classification System4

The changing environment of health care funding has been influential in stimulating hospitals to manage their resources better. Information systems provide a tool for this. Prospective payment systems, the decreasing length of inpatient stay, and a shift toward a higher proportion of more severely ill hospitalized patients emphasize the need for better tools to project long-term use of resources and to manipulate day-to-day adjustments in patient care staffing.

4The author of this section is Linda M. Arenth, M.S., who joined the Oncology Center as Director of Nursing in 1974. In 1976 she began the development of the oncology patient classification system. In 1987 she became Vice-President for Nursing and Patient Services at The Johns Hopkins Hospital.

The number of nurses needed to staff a hospital unit is based on the number of patients on that unit and the severity of their illness. When planning for a new cancer center began, nursing recognized a need to gather data that would be useful in planning long-term staffing strategies and also in managing current staff resources.

The oncology patient classification system (OPCS) was developed to address the need for a quantifiable measure of the special-care needs of patients admitted to the Oncology Center and to address limitations in available patient classification instruments. Primarily, these instruments did not reflect the special requirements for patient care associated with current cancer therapies. Additionally, they tended to be specific for an institution, generally for medical-surgical patients, and focused on tasks.

Through a retrospective review of patient experience, it was concluded that the primary determinant of oncology patient care needs was the type of treatment and its associated clinical course. A secondary factor was the extent of disease and its associated physiological impairment. The intent of the OPCS was to capture the special-care needs of patients such as the needs associated with severe bone marrow aplasia following bone marrow transplantation or intensive chemotherapy treatment, untoward effects of chemotherapy or radiation therapy, the evaluation of new drug or radiation therapies, and severe disease.

Patient care requirements vary by the type and phase of treatment. Levels of care required during different phases of hospitalization are often predictable and directly related to specific times following treatment-induced toxicity such as lowered white blood count or platelet depression. Clinical experience provided the basis for designing this classification system which relates care requirements to resource utilization. Further, the OPCS provides a practical method of forecasting and monitoring patient requirements for nursing resources.

The OPCS categorizes patients by acuity of illness and divides the associated intensity of nursing services into five levels of care using a simple data collection instrument. It contains 41 critical indicators which are descriptive phrases of the clinical conditions or support situations that have the greatest impact on nursing resources and for which there are predictable sequences of nursing interventions. The critical indicators were defined by a panel of experts. Standard nursing hours per patient day (NHPPD) were assigned to each level of care. These were based on standard NHPPD for patient classification categories of care reported in the literature and an estimation of the nursing resources required for each. Patients are concurrently categorized every 24 hours on the basis of an assessment of their clinical situation.

The critical indicators are defined on a single, easy to use form. They are grouped into five levels of severity, categorized from grade 1 (minimal severity— patients ambulatory and able to care for themselves, but hospitalized for protective isolation) to grade 5 (maximum life support—patient in cardiovascular collapse requiring intravenous pressors and external ventilator support). To determine the level of care, beginning with the highest level of nursing care (category V), the nurse checks the first appropriate indicator on the classifica tion instrument. The overall level of care is determined by the highest level of care in which an indicator is checked. Implicit in the categorization scheme is the assumption that indicators within and below each level of care may also be applicable, but checking multiple indicators is not necessary and does not change the designated level of care. Reliability has been demonstrated by a consistently high level of agreement between two nurse raters. The medical record provides supportive documentation for the assigned level of care. Content validity was established by a panel of nursing experts. Physicians provided supportive information relative to medical practice.

After four years experience, an evaluation of the system was undertaken to provide further evidence of the instrument’s validity. A criterion-related approach was taken. This involved a concurrent audit comparing observed nursing time and effort using work measurement methods and nursing hours established for each level of care in the classification instrument. The results indicated that the mean nursing hours observed for each level of care were not significantly different from the standard nursing hours of care, with the exception of category V. The variance observed in category V reflected the groupings of multiple activities that occur when patients are classified as intensive and is related to limitations of the work measurements.5

Since its inception, the OPCS has provided a simple, reproducible, and reliable method for categorizing patients each day according to their use of nursing resources. A summary of monthly data available through OCIS is illustrated in Figure 12. Monthly and year-to-date statistics on census, acuity, and occupancy rate are compared with those for the same month in the prior year and the year to date. NHPPD can be computed by multiplying the average acuity score by 4.

We believe that the OPCS provides a better indication of actual requirements for patient care resources than other systems that do not account for the variations in patient acuity that we have observed with cancer treatment. Of specific concern is patient classification by diagnosis-related groups (DRGs), the basis for hospital case mix management under Medicare prospective payment. Variations in patient acuity and the greater use of hospital resources that may occur during the treatment phase of hospitalization are not fully accounted for in the DRG payment rate.

Classification data from our experience with patients on treatment protocols reflect utilization of patient care resources and permit one to predict the care (costs) required for future patients. The OPCS has contributed to the effective management of patient care resources and can be used to reflect case mix severity, nursing utilization and productivity, resource utilization, program and budget planning, and nursing and hospital costs. The applicability of the system to oncology practice in other clinical settings has been demonstrated with modifications, when indicated, to reflect differences in protocols and practice.

5L.M. Arenth, The Development and Validation of an Oncology Patient Classification System, Oncology Nursing Forum, 12:17-22, 1985.

Figure 12. Nursing patient classification system monthly statistics.

A Resource Management, Forecasting, and Reimbursement System6

Background Since 1985, personnel at the Oncology Center have been developing a case mix database and analysis system. The system was established in response to specific internal resource management needs and to the hospital regulatory environment. In regard to management, in the early 1980s administrative personnel began using personal computers and associated financial application packages, such as Lotus 1-2-3, to forecast and manage resources at the Center. Over time, it became apparent that a more sophisticated database and analytic system would be useful in future planning efforts.

Concurrently, a substantial growth in hospital costs prompted a series of federal, state, and third-party-payor efforts to control inpatient costs through prospective per case reimbursement for hospital stays. Of the federal strategies, the most controversial has been the use of the Yale ICD-9-CM diagnosis-related group (DRG) classification for payment of inpatient services used by Medicare beneficiaries. The DRG payment scheme was approved by Congress in 1983 with a three-year national implementation period. Passage of this legislation stimulated many state and third-party payors to begin experimentation with DRG payment for beneficiary groups of all age ranges.

6This section was authored by Catherine Kelleher, Sc.D., M.S.N., who joined the Oncology Center in 1986 as a faculty member. Her primary research interest has been in the development of inpatient, outpatient, and episode-of-care classifications for cancer patients.

Since their implementation, DRGs have not been found to account for much of the variability in use of resources by acute care inpatients. As a result, government and third-party payors continue to experiment with modifications of the original methodology. They also increasingly fund research designed to develop severity-of-illness adjustments and to identify other characteristics to be used in conjunction with DRGs to account for variability in inpatient use of resources.

The Oncology Center case mix system is specifically designed for management and health services research applications. The primary management goal is to identify patient and provider characteristics that can be used to pinpoint deficiencies in quality and efficiency of care, and to forecast resource requirements. The research goal is to develop policies and recommendations for reimbursement methods that will yield more equitable compensation for oncology patient care. The specific policy research includes the development of models for payment of inpatient care on a per stay basis and investigation of approaches for capitation payment inclusive of inpatient and outpatient services over defined periods of time.

Data Sources and Structure The database used by this system is a composite of information from a variety of institutional sources. The major data elements available through the case mix system are displayed in Table 1. The sources include The Johns Hopkins Hospital billing and discharge abstract systems, and data from the OCIS. The OCIS supplies a significant portion of the clinical data.

The database structure mimics the OCIS in that cross-sectional and longitudinal analyses can be done at patient and population levels. The primary unit of data collection is the patient rather than a specific element of patient care. This provides flexibility in the use of the database.

Merging selected subsets of data from the OCIS and other hospital information systems was not the only option in designing the case mix system. Among the alternatives was the selection of one or more of the financial and utilization management packages currently available on the market. These packages were developed in response to the evolving hospital regulatory climate and the need to collect data to go beyond DRGs in attempts to understand what drives length of stay and costs.

Use of ready-made packages was not an attractive choice owing to the numerous shortcomings of most that were available. First, they were narrow in focus and not easily adapted to broader applications. Second, they were not easily modified to permit collection of additional data items found to be important in explaining use of resources. Third, they appeared to be marketed with built-in

Table 1. Variables, the Johns Hopkins Oncology Center Inpatient Case Mix Analysis System



Resource variables Length of hospital stay

Charges adjusted to cost and for inflation


Total for the hospital stay


Subsets of the total for hospital stay (room and board, supplies,


pharmacy, blood products, laboratory, etc.) Patient clinical variables



Admission urgency


Repeated admissions

First Johns Hopkins Oncology Center admission


Number of Johns Hopkins Oncology Center admissions in the past 6,


12, 18, 24 months Diagnosis

ICD-9-CM diagnos(es) for the hospital stay


ICD-9-CM diagnosis-related group (DRG) for the hospital stay


ICD-0 diagnosis for the primary cancer


Nursing levels of care^



Clinical course




Toxicity-of-treatment indexes^



Clinical course




Severity-of-illness indexes

Patient management categories (PMCs) for the hospital stay


Systemetrics computerized disease stag(es) for the ICD-9-CM


Diagnos(es) for the hospital stay

Centralized cancer patient data system (CCPDS) stage for the primary


cancer diagnosis

Discharge disposition


Patient personal variables





Marital status


Home-hospital distance


Payment source


Hospital variables

Fiscal year of discharge


Admission day of the week


Discharge day of the week


Admission transfer status


Protocol status


obsolescence because they were regularly superseded by updated versions claiming to take advantage of state-of-the-art improvements in monitoring methodology. Fourth, they did not integrate easily with existing data systems.

In contrast, the basic design of the OCIS was well suited to our needs despite the fact that its installation predated the onset of cost containment concerns. Because it was conceptualized to support medical decision making by minimizing the need for the medical record in conventional hard-copy format, the OCIS online data set was substantially more comprehensive than that required by the special-purpose data collection tools critiqued above. In addition, the OCIS data set was also easily linked with other standard data sources available throughout the institution, including the hospital discharge abstract and billing files listed as sources in Table 1.

Information in Table 1 suggests that only one-third of the data items are uniquely from the OCIS. However, most of the items obtained from the hospital discharge abstract file are also available via the OCIS, a circumstance providing the opportunity for data validity checks between the systems. More important, short of a detailed medical record review, the data attributed to the OCIS in the table are only available from this source. It is these particular data that have the most exciting potential to produce new models of hospital resource use by oncology patients.

Preliminary Results As this book is being written, data analysis is in its early stages and has been limited to data obtained from inpatient hospital stays. A number of pilot studies are underway using selected Oncology Center inpatient discharge data sets to develop models to be tested across multiple fiscal years. Among the findings to date are those using fiscal year 1985 discharges to test the explanatory power of unique data from the OCIS for length of stay.

*In fiscal year 1985 there were 1488 discharges; 81 discharges consisting of 54 bone marrow donor admissions and 27 same-day admissions and discharges were eliminated from the analytical data set because their hospital stays were considered atypical from the remaining discharges. In the analytic fiscal year 1985 data set, all cases totaled 1407, the solid tumor set totaled 1121, and the lymphoma and leukemia subset totaled 286.

*WBC: white blood cell count; NEUT: neutrophil count; PLATE: platelet count; HCT: hematocrit; HGB: hemoglobin; TEMP: temperature; BUN: BUN; CREAT: creatinine; ALB: albumin; SGOT: SGOT; SGPT: SGPT; PHOS: alkaline phosphatase; BILI: bilirubin; CAL: calcium; NA: sodium; K: potassium; CL: chloride; C02: carbon dioxide.

*For each toxicity and nursing parameter tested, the actual number of cases having values for it is shown.

Only percentages that are significant are reported. Unless indicated, the p value for the percentage

= .000; + = .01; * = .01 < p < .05. All p values are 2-tailed.

II •

A daily nursing pattern-of-care variable was also tested and explained 36% of the variance. See the section on preliminary results by Catherine Kelleher in the text for a description of the variable.

(Table 2). Five values for each of these parameters were selected as those most likely to give insight into inpatient clinical course. They were the first value, the last value, the minimum value, the maximum value, and the difference between the maximum and the minimum value.

One major finding was that, across all 18 parameters, the first value of the stay explained little or no variance for the natural logarithm of length of stay. This finding is in striking contrast to other derangement indexes, which attempt to get first-day data in order to capture severity of disease before onset of therapy intended to normalize the imbalance. All other values for the clinical parameters were found to provide better explanatory power. The value that provided the greatest explanatory power was the difference between the maximum and minimum for the stay (Table 1). These results suggested that costly physiological abnormalities were largely treatment induced.

A second finding of interest in Table 1 is that selected abnormalities considered resource intensive, such as low white blood cell count, do poorly in explaining variation in the natural logarithm of length of stay because they are just too common in our inpatient mix. In addition, although not shown in Table 1, when correlations were calculated between the 18 clinical parameters being considered for inclusion in the toxicity index, many were found to serve as proxies for each other, including parameters of different organ systems as physiological functions became increasingly deranged.

The above findings were also consistently observed when controlling for diagnosis by stratifying discharges into solid tumor and systemic (leukemia and lymphoma) cases. These results indicate that, for oncology patients, treatment may be an important determinant of length of stay. In addition, the high correlation among the 18 parameters suggests that it will be possible to simplify the toxicity index to a handful of indicators.

Findings for daily nursing acuity ratings obtained from a five-level ordinal rating nursing classification instrument used routinely at the Oncology Center are also displayed in Table 1. These daily nursing ratings are summarized into six variables. Five of the six are constructed in a fashion identical to the temperature and laboratory values (first, last, minimum, maximum, and maximumminimum values for the stay). The sixth, the daily-nufsing-pattern-of-care variable, was designed to capture instability of clinical course. For this sixth variable the daily ratings were used to construct a set of dummy variables that capture patterns of nursing care over the entire hospital stay. Data were coded to reflect a steady care pattern; a steady increasing care pattern; a steady decreasing care pattern; and a fluctuating pattern. Because of the difficulty in determining valid cut points using data of a continuous nature, no attempts were made to construct instability-of-clinical-course counterparts from the temperature and laboratory values.

Results indicated that the nursing, temperature, and laboratory data generally had similar explanatory power. Exceptions were the minimum nursing value for the stay with its relatively poor performance, and the daily-nursing-pattern-of-care variable, which shows promise owing to its high explanatory power.

Projected Activities Without the OCIS, the preceding analyses would probably have never been undertaken or would have met with massive resistance owing to the cost of data retrieval from the medical records and the lack of a guaranteed payoff of a data set highly explanatory of differences among patients in length of stay and costs.

Results encourage continued effort toward building a toxicity index and examining how nursing acuity is related to toxicity of treatment. Relationships of the toxicity and nursing variables with others listed in Table 2 will also be explored. Anticipated final products include the identification of the minimum data set required for internal planning and management of inpatient resources, and the formation of a set of inpatient reimbursement models to validate in other oncology treatments facilities so as to make policy recommendations for inpatient payment reform.

Analysis of outpatient resource use is expected to begin in the near future. Expected activities include comparison of similarities and differences in inpatient and outpatient use of services, and investigation of patterns of substitution and cycling between inpatient and outpatient care. Among the long-term plans are linkage of the inpatient and outpatient case mix databases to begin work on development of capitation payment models and to assist administration in resource management and identification of quality-of-care issues.

Tumor Registry System7

As has been previously described, planning and prototyping activities for the OCIS began while the Oncology Center building was being designed and constructed. The patient management system that has evolved from these initial planning activities is enormous in both scope and complexity. However, the foundation for this patient management data system began many years before during the early stages of the Hospital Cancer Registry.

The Johns Hopkins Hospital Tumor Registry was formed in the early 1950s. Even in this early stage, records in the partially computerized registry contained the basic information deemed necessary to complete the patient management profile. In the early 1960s this system was converted to a completely manual system utilizing a card file referred to as “Info-Dex.” As the number of patients increased, it became increasingly difficult to manage and utilize this database effectively. Data retrieval became a tedious task.

In 1968, the system was again partially automated by the entry of selected data onto key-punched cards for computer processing. This provided a mechanism for accessing registry data and generating reports in batch mode using a remote computer facility. This method allowed improved search and information retrieval techniques, and remained in effect until 1975.

The construction of The Johns Hopkins Oncology Center was preceded by the development of a Cancer Center Provisional System (CCPS). The CCPS fulfilled

7This section was written by Anne Kammer, A.R.T., C.T.R., who has been in the health care field for over 30 years. She has managed The Johns Hopkins Tumor Registry since 1963 and in 1976 became the Manager of Oncology Data Operations. Ms. Kammer played a major role in the initial development of OCIS, and in 1979 she assumed her present position as Manager of Oncology Medical Information.

many objectives including providing a means of assisting with patient care while meeting the requirements established by the American College of Surgeons for a cancer registry, and complying with the American Association of Cancer Institutes (AACI) data set. In order to meet these diverse objectives, additional information was incorporated into the cancer registry core data set. The resulting system provided patient status, presentations, and clinical activity aids to assist physicians in the management of cancer center patients being treated by selected chemotherapy protocols.

As a result of this process, a more patient-oriented database was developed. This database would eventually serve as the foundation for future cancer center systems having extended clinical, administrative, and research objectives. Additionally, this cancer registry data system provided the institution with a working understanding of the operational management and clinical capabilities provided through such information in a cancer center setting.

Prior to the implementation of the CCPS, three phases of development were necessary. First, a comprehensive summary file of all patients from 1955 through 1975 was built. Although this file was not quite as complete as that for subsequent patients, it provided essential historical information for future studies. The second phase included the expansion of the system functions to support on-line edit and search capabilities. This phase included the implementation of an inhouse computerized system with the capability of entering data directly into the database and querying the data for patient care and ad hoc studies purposes. The final phase encompassed the development of a more comprehensive computer-based data set with more system-oriented and patient-related capabilities. This provisional system immediately preceded the Oncology Clinical Information System (OCIS).

During these stages of development, the Tumor Registry evolved from a simple patient profile to an expanded data set, which complements patient care and research in the new Comprehensive Cancer Center at Johns Hopkins. The initial patient profile contained approximately 20,000 patient records. There are currently 45,000 patient records in the database, of which approximately 17,000 are under active annual follow-up. In 1987 over 3400 new patients were accessioned into the registry, encompassing both The Johns Hopkins Medical Institution and the Comprehensive Oncology Center (Figure 13). Close to 19,000 patients are actively followed by the registry.

The Tumor Registry has evolved from a one-person registry in 1955 to its present level of a staff of eight. While the OCIS can be viewed as the information backbone that supports the Oncology Center, the Tumor Registry is an integral part of that system as both a data provider and an information user. Data collected by registry personnel and data collected by clinical personnel are transparently available to all functions of the system.

Administratively, the Oncology Medical Information component of the Cancer Center is a part of the central administration services. Activities of this component include the Data Quality Unit, Oncology Medical Records Unit, and the Cancer Registry. Organizationally, the Tumor Registry is a function of The Johns Hopkins

Figure 13. Number of new cases (malignancies) and total patient follow-up: The Johns Hopkins Hospital Tumor Registry, 1977-1987.

Hospital’s central administration that is carried out by the Cancer Center. Thus, the registry is responsible for collecting information on all cancer cases seen throughout the Hospital including the Cancer Center. Functionally, database maintenance and programming tasks are performed by OCXS staff under a joint agreement with the Hospital.

The data collection staff of the Tumor Registry performs such routine functions as case finding, data abstracting, quality control, coding, data entry, patient follow-up, and other assigned duties, such as ad hoc report generation. Patient identification begins when a document or computer listing is provided to the Tumor Registry staff through a variety of sources, including Admissions, and Pathology. Screening and selection of registry accessions begin with this procedure, and later decisions are made regarding the formal entry of the patient into the system. Factors influencing this decision are case reportability and department reportability, and whether the cases are on a consult only with no treatment or outside review only basis.

Once the decision is made to enter the case into the system, the available information is first verified against a centralized Hospital database containing all patient identification numbers and demographic information. The long-term database is a soundex patient identifier system developed by the Medical Records Department to ensure correct and unique history number/patient name matches. After verification, the significant data about the patient is abstracted. This information is coded into a format termed a preliminary entry, which includes primary site, morphology, stage, pathology data, and other information that may be important in identifying the patient.

The case is maintained in a preliminary file for later completion. This preliminary file is maintained on line for immediate access by users, as well as in a manual form retained in a selective file. Within six months of this initial entry, the medical record is requested and the case is completed and entered into the computer system. The exception to this procedure is that Oncology Center inpatients are abstracted and entered into the system at the time of discharge.

The Oncology Clinical Profile (abstract) is completed manually by the abstracter and entered into the on-line system. A sample abstract is provided in Chapter 2, Figure 2. This procedure allows the abstracter to view all entries, identify any errors, and make immediate corrections to the database. A hard copy of the abstract is placed with the existing documents and, if appropriate, is then prepared for the quality control process.

The focal point of this process is to prepare the abstract. The abstract contains all the data needed to meet the requirements of the American College of Surgeons, support administration and research activities, and administer other oncology services. Its primary purpose, however, is to serve as the nucleus for Oncology Center patient summary. It provides essential information about the patient’s disease in order to assist in clinical management.

The abstract file is a combination of coded information and free text within selected fields. The development of this type of profile was based on the needs of the Oncology Center physician staff to complement patient care. The basic contents of the profile are (1) demographic, (2) administrative, and (3) diagnostic information; (4) treatment; (5) medical history; (6) follow-up and end results.

At the request of physicians and administrative staff, it has been necessary in the past several years to develop a confidential section as part of the abstract. This suppressed information can be viewed only by authorized individuals and with the permission of the supervisor. Examples of information that may be contained under this section are psychiatric illness, family relationship to a staff member, AIDS diagnosis, and other predefined data.

As a component of the abstract, two systems currently exist to validate data. An on-line edit check system was developed initially as a spin-off of the Centralized Cancer Patient Data System (CCPDS), organized by the National Cancer Institute in the mid 1970s among comprehensive cancer centers. This procedure allows the abstracter to view all entries, identify any errors, and make immediate corrections to the database. The second portion of the quality control process of the abstract is a visual review of the abstract. This has functioned since the development of the computer system. This review was enhanced by a designated section of the abstract referred to as the administrative section (Figure 14).

The two primary reasons for the implementation of the quality control and edit check procedures were to ensure that the quality of data was valid and consistent,

Figure 14. Administrative information of the patient abstract: The Johns Hopkins Hospital Tumor Registry.

and to ensure that the case met the requirements for inclusion into the database. In addition to the on-line edit checks, it is possible to generate a report that captures all elements and identifies those items that require further verification for accuracy. This report can be generated on an ad hoc basis and be specific as to the individual abstracter who entered the case (Figure 15).

The visual review of the abstract is intended to detect cases that would not be reportable according to predefined criteria, and to detect inconsistencies in data collected in the text sections of the abstract data.

The quality control review provides the supervisor with a method of assessing the performance of the employees who perform the abstracting function and to use this information as part of the overall job performance evaluation mechanism. Errors are evaluated as major versus minor discrepancies.

Although cancer registry information use is limited in many hospitals, such information has been a primary data resource in The Johns Hopkins Medical Institutions. There are several factors that have influenced this high level of use. The first and foremost has been compliance with “individualization” of requests from the database. This is accomplished through an orientation of the users with the system and an explanation of the data available. Using this method has the advantages of providing education and streamlining the ultimate report request.

Second, with the continued development of more sophisticated information systems throughout The Johns Hopkins Medical Institutions, users have become extremely interested in having this information on line for a wide variety of purposes. As a result, the number of requests continues to increase. For example, the staff of the Surgical Pathology Department is provided with on-line review of existing physical, laboratory, and treatment information in order to facilitate better evaluation of surgical specimens.

Contacts are made annually with all internal departments, as well as with our affiliated institutions to encourage utilization of available cancer patient data. Many benefits are derived by the existence of the Tumor Registry. It is able to provide the Center and other requesters with comprehensive cancer statistics for patients

Figure 15. Quality control Edit Check Report: The Johns Hopkins Hospital Tumor Registry.

diagnosed and treated within the institution in any specified year. The Registry also enhances cancer patient management. A significant benefit is that lifetime follow-up is effected for all patients diagnosed to ensure that they stay in touch with the health care system. The data are available to identify patients at risk for second malignancies and to stimulate interest in cancer prevention. The database supports patterns-of-care evaluations both short term and long term as required by both external and internal agencies.

Frequent requests are made by Oncology and Hospital administration for information to aid in resource planning and to evaluate the institution’s experience related to cancer patients. This can easily be obtained through the Tumor Registry database. Research has been enhanced by defining populations of specific cancer patients for planned clinical and epidemiologic protocol development. Information on cancer is available to support research by physicians, students, health care providers, and organizations and to provide data for grant requests. Valuable epidemiological data are available to identify common variables and perhaps contribute to the prevention of this disease.

The information maintained by the Tumor Registry also enables the institution to meet the American College of Surgeons requirements for accreditation of the institution’s cancer program. In addition, it provides information needed to meet state and local requirements. Presently, The Johns Hopkins Hospital Registry reports its new cancer cases to the Maryland State Cancer Registry. It is to be hoped that the recent establishment of a statewide population-based cancer registry will assist with local primary and secondary cancer prevention activities.

In summary, the Cancer Registry has played a major role in defining data collection and reporting activities that have been incorporated into the OCIS. Today the Registry is an integrated part of the OCIS and shares in a synergistic relationship with all data collection and utilization activities at the Cancer Center. It continues to serve a critical role in multiple areas within both the institution and the Cancer Center. Its role will grow with the other data utilization activities evolve.

System Operation and Administrative Services8

Introduction This final section addresses some of the issues that relate to the computer support of the OCIS. Two factors are considered. The first deals with the methods used to protect the confidentiality of the patient information in the OCIS database; the second describes some special considerations that relate to the system’s operation. The material in this section was prepared by the OCIS System Manager (A.W.S.), the Supervisor of Programming (F.M.), the Supervisor of Computer Operations (G.L.K,), and one of the original OCIS designers (B.I.B.).

Authority Control Because the OCIS maintains a very large database containing sensitive patient data that are necessary for the efficient operation of the Oncology Center, special steps must be taken to ensure (a) data protection, that is, that the data are properly backed up to provide continued availability in the event of failures or catastrophe, and (b) data privacy, that is, that the data are guarded from unauthorized access. The former is accomplished by the rigid application of routine procedures, and this subsection addresses only the second issue.

A secure automated system requires three dimensions of control: control over the personnel, the facility, and the computer system. In a hospital system there is limited control over personnel and facility. All clinical workers are schooled in the sensitivity of patient data; they are taught how to retain the patient’s confidentiality. Unlike a system that must control national secrets, however, no special screening of the staff is performed beyond that necessary to ensure that they will be effective members of the health care team.

8This section was written by Bruce I. Blum, Gary L. Kinsey, Farideh Momeni, and Alan W. Sacker.

Gary L. Kinsey joined the OCIS staff as a Data Coordinator for Hemapheresis in 1979. In 1981 he became Supervisor for Computer Operations. In 1987 he assumed his present position as Systems Programmer II.

Farideh Momeni, M.S., began work on OCIS in 1982 as a member of the clinical information component of the Johns Hopkins Biomedical Engineering Department. She joined the Oncology Center in 1985 as a programmer and assumed her present position of Senior Systems Programmer in 1989.

Alan W. Sacker joined the Oncology Center in 1976 and was initially a data coordinator/operator for OCIS. In 1978 he assumed a role as an applications programmer and participated in the early Phase I development efforts. In 1988 he assumed his present position as Systems Programmer III.

With respect to the facility, most areas must be left unsecured. Although many rooms are locked, the general hospital layout cannot prohibit visitor or patient access to all locations. Obvious exceptions include work areas such as the registrar’s desk and the nursing control booth; here an unauthorized presence would be questioned immediately. During nonworking hours, however, a work area might be unattended. In this situation there would be no one to guard against the unauthorized use of a computer terminal. For example, it might be possible for a visitor to wander into the outpatient department in the early evening and experiment with a terminal.

Clearly, therefore, OCIS must have some means of authority control that can protect against accidental penetration of the system, that is, the review of private data by casual access. Nevertheless, it must be recognized that no hospital organization is designed to protect itself from a deliberate penetration of its security system by experienced and dedicated criminals. Any attempt to do so would be prohibitively expensive. Consequently, OCIS need not be concerned with all of the security attributes of, say, a national defense application.

There are a variety of techniques used in ensuring authorization to the data. The most common method is the use of a password during the sign-on process. The major difficulty with this approach is that it requires a log-on for each session. This involves casual users to remember their passwords. Moreover, because one would like the system to be available as a utility, a log-on prior to each session tends to act as a barrier to system use. These problems are often overcome by leaving the terminal in a logged-on state or by posting a common password for all to use. Both techniques violate the intent of the authority system.

In designing an authority system for OCIS the following goals were established:

The use of a terminal should be encouraged. Therefore, each terminal would provide access to all data that were normally available in that physical location. For example, in the 2 North unit, on-line access would be available to all data on 2 North patients; in the administrative areas, access would be available to the patients administrative (nonclinical) data.

Terminals should be identified by a location, which would indicate what data should be available and a time window of availability. For example, the outpatient terminals would not provide access to outpatient data after clinic hours. Any terminal should be able to access OCIS. If the terminal did not already have a location-specific authorization level, then it would display the top-level menu (called the universal terminal) and demand a log-on with a password before performing any protected task.

Any terminal already logged on should provide access to any data in the system when the proper authority is given. This would be accomplished by testing each request against the authority of the terminal. If the request exceeded the terminal authority (as it almost certainly would in the case of the universal terminal), then the user would be instructed to log on. If authorized, processing would continue. When the processing was complete, the terminal authority would continue. When the processing was complete, the terminal authority would be returned to its earlier state.

Remote access and programmer access to OCIS should require additional levels of control.

Authority is established at the program (or function) level. This is a different philosophy from that used with most database systems in which individual files or attributes are protected. The designers felt that authorization according to how the data were to be used provided a finer granularity for control. Consequently, each program can have associated with it one or more authority levels. In general, it is sufficient to restrict the authority testing at the level of the menu programs that provide access to an associated group of functions. However, it is possible to associate a special authority with any individual program.

The authority codes are defined as a network. Each user or program may be given many authorities. For example, some codes might be:

Clinical data, view only (CD) or view and update (CDU).

Administrative data, view with (AFD) or without (AD) access to financial information.

Data coordinator special functions (DCSP).

Data coordinator assignment defined to be all the above, except for the access to financial information; for example, DC is defined as the set CDU, AD, DCSR SUPER, which provides maximum authority; that is, SUPER contains DC, AFD,. . .

A program may be given the authorities CD and AD which would require the user to have both authorities or an authority that includes both.

The OCIS System Manager is the person responsible for assigning authority codes to new users and to all programs. Log-on is initiated with a short public identifier, usually the individual’s initials. This is followed by a prompt for a password. For the initial log-on, the user supplies the password. The password can be altered by the user at any time. Periodically, the unused authorizations are removed from the system. This approach to authority control has been in use since 1982, and it has been well received.

Computer Operations In this final subsection we address some of the features that were incorporated into OCIS to support its computer operations. Because the system was initially developed in a period when computers were not a common tool in the delivery of health care, there was a limited demand for interactive displays. Moreover, because of limited funding, few terminals were available until the mid-1980s. Thus, OCIS was designed to be a paper-oriented system. It provided on-line access to clinical data, but this access was limited to special functions, such as the review of the morning hematology results. Also, because OCIS was developed well before there was any Hospital commitment to networking, communication with remote sites and computers had to rely on custom-crafted interfaces.

As a paper-oriented system, the daily operation was scheduled according to the need to produce and distribute data products. The key events were:

Plots and Flow Sheets. Plots and flow sheets had to be available in time for morning rounds and clinic opening. Drug doses were cumulated as a daily dose; processing, therefore, could begin only after midnight. By that time most outstanding clinical laboratory data had been reported, and little change to the database could be expected until the morning blood work was reported. Thus, the clinical database was updated each day during the early morning hours.

Daily Care Plans. The patient data had to be updated to indicate any deviations from the previous day’s plan. This was done early in the morning by the data coordinators. Once the database was updated, the current day’s plans could be produced and delivered to the units for the current day’s orders.

System Backup. Each day the database was copied to backup disk packs.

System backup required a dedicated machine, but the first two activities were executed in parallel with on-line use. The first two activities were computationally intense and, given the limited OCIS computing resources, required several hours to process. Unfortunately, the running of computationally intense programs affected response time, and optional long runs, such as a Tumor Registry search, would be scheduled for the weekend.

To manage this standard production processing, a scheduler-stacker-spooler was developed, using both vendor-supplied and custom code. Routine jobs were identified along with the time at which they should be initiated. Requests for printed output were entered into the queue according to their priority. All clinical terminals were given the facility to enter requests for printed outputs. Because the computing facility had no local printers, all output requests were either picked up at the computer center or delivered.

The interfacing of OCIS with other systems introduced new problems. Chapter 6 has presented the issues from the perspective of the Pharmacy. Similar issues were raised with respect to the link with the Clinical Laboratory computer. Because OCIS was the only automated system that required access to the individual values in the laboratory reports, it was not reasonable to expect the Clinical Laboratory to modify its programs and provide access to this level. Consequently, OCIS was allowed to read only the automated form of the printed report and extract the data values. The obvious difficulties included matching patient identification, parsing the data after changes were made to the report format, dealing with text messages, and processing changes to previously reported values.

Because the conversion of the text report produced by the Clinical Laboratory into a value-oriented OCIS database was a time-consuming process, data transfers and updates initially were scheduled on a two-hour cycle. As the equipment was improved, this was reduced to an hourly cycle. Timeliness improved; nevertheless, there remains a lag between the time that a report is available on the Hospital system and the time it is available in OCIS.

When a link was established between the OCIS computer and the hematology laboratory located in the Oncology Center, it was possible to integrate the OCIS programs with the laboratory functions. These clinical data are available to OCIS users as soon as the data are recorded. As a result, on-line query using the OCIS Data function is the standard method of communicating the results of the hematology laboratory. Because of this use, the Data function is also used for reviewing the blood chemistry work as well.

A further system complication was introduced by the need to report clinical data in several formats, that is, vertical flow sheets, horizontal flow sheets, and plots. Because it is possible to have hundreds of data points per patient day and because a patient may have years of data available on line, some method was required to manage this diversity and, at the same time, provide acceptable response times. This was accomplished by replicating some of the data in formats that were suitable to the different reports. The normal storage of data provided very rapid access to the Data display and vertical flow sheets. However, the other formats proved to be more effective in displaying large amounts of patient data. Thus, during the evening update period, these secondary formats were partially regenerated to include new data and corrections to previously reported data. Although an individual patient’s data could be updated on demand at a terminal, the practical consequence of this design approach was that the plots and horizontal flows were updated daily.

Clearly, there is nothing in the OCIS design that prohibits its use as an interactive system. The history of its development and the limitations imposed by its processing power combined to give the system a paper orientation. As noted already, the Data function is a very important part of patient management, and the discussion in Chapter 9 provides strong evidence that the system is used as an interactive resource. Nevertheless, most of its activities are supported in a paper-oriented manner. As is demonstrated in Chapter 10, an environment that has grown accustomed to interactive access for all functions may not find such a design satisfactory.