John P. Enterline, Raymond E. Lenhard, Jr., and Bruce I. Blum1

Introduction The Oncology Clinical Information System (OCIS) at The Johns Hopkins Hospital is a computer-based decision support system for the clinical management of patients with cancer. It was developed in response to a need for more effective mechanisms to manage the large volume of clinical data used during the medical care of these patients. The goal of OCIS is to assist in providing an optimal clinical management, research, and educational environment for The Johns Hopkins Oncology Center through the automated collection, storage, and access of appropriate information. The major premise of the system is that timely access to complete and accurate clinical information will significantly improve the effectiveness and efficiency of the clinical management of cancer patients. Obviously, access to good information can only help if it is appropriately used. Consequently, considerable emphasis also is placed on providing the information in a format that conveys clinical meaning in a natural manner.

We believe that OCIS has achieved its objectives. It has made possible the effective use of large amounts of data in a timely manner for clinical care. It also supports many secondary tasks such as patient scheduling, admit/discharge

'John R Enterline is presently Director of Information Systems at The Johns Hopkins Oncology Center. He joined the Center in 1983 as Director of Biostatistics and followed Bruce Blum as Technical Director of the OCIS. He assumed the role of Director of Information Systems later that year when Dr. Raymond Lenhard left to become Director of Information Systems for The Johns Hopkins Hospital.

Dr. Raymond E. Lenhard, Jr. was a professor of Oncology and head of Medical Oncology at The Johns Hopkins Oncology Center during the development of the OCIS. He was responsible for information systems, postgraduate medical training programs, and numerous clinical research projects. He is now Vice-President for Information Systems at The Johns Hopkins Hospital.

Bruce I. Blum was Technical Director of The Johns Hopkins Oncology Center’s clinical information center when the Center opened in 1976. He played a major role in the design and implementation of the OCIS. He left the Oncology Center in 1983 and is now engaged in research in software engineering at The Johns Hopkins Applied Physics Laboratory.

functions, the ordering of procedures and blood products, clinical research protocol reporting, drug ordering and monitoring, charge capture, and a variety of administrative functions. Any comparable attempt to manage these OCIS tasks with manual techniques would be logistically difficult and financially prohibitive.

This chapter provides an overview of OCIS and the environment in which it operates. It begins with a brief description of the Oncology Center and its philosophy of patient management that led to the creation of OCIS. Following a brief development history, the basic functions of OCIS and its support organization are presented. Because the development process is dynamic, the chapter concludes with a brief overview of the Oncology Center’s current activities and future plans.

Rationale for OCIS Medical oncology is a relatively new discipline in internal medicine. Its origins in clinical pharmacology place a strong emphasis on drug development and have positioned the young specialty at the forefront of the design and conduct of clinical trials. The discipline of medical oncology requires both the fine categorization of specific clinical problems and quantitative methods to measure treatment outcome. Thus, there is a heavy emphasis on research protocols in the day-to-day management of cancer patients. The prospective collection of well-defined data items and the standardization of study results in time-oriented tabular format (flow sheets) have become necessary components of clinical care.

As would be expected, enormous volumes of laboratory, pharmacological, and clinical observations are needed to support the ongoing decision-making process and to determine the success of cancer treatment. Because of this, research-oriented data management tools have received general acceptance in clinical practice. Additionally, because most medical oncology training programs arose in a clinical research environment, the techniques learned in this setting have been adopted into clinical practice in both oncology and general internal medicine by graduates of these programs.

Given the overwhelming data management requirements of medical oncology, the opening of a new cancer facility at The Johns Hopkins Hospital in 1976 provided the opportunity to examine how an automated system might further patient care. After a detailed preliminary analysis, the Oncology Center administration committed itself to an automation project. They were convinced that the Center’s proposed methods of patient care would be particularly well suited to the use of a computer-based system. Therefore, it chose to underwrite development of OCIS with internal funds.

Several key decisions regarding the OCIS philosophy were made early in the development process. First, the system was to be clinically oriented. It was to focus on the patient, then on the disease and other medical complications, and finally on specific treatments for diseases and complications. This meant that all treatments, whether primary or secondary, inpatient or outpatient, were to be integrated into one time-oriented database organized by patient. This implied that the system had to be concerned with the total patient history and not just particular disease and treatment episodes. There was an initial presumption that the system did not need to address either administrative or research tasks directly, except as they related to the clinical functions. Thus, OCIS could be designed around the information requirements for total patient care within the Oncology Center.

Another major decision leading to the philosophy and structure of OCIS was that it should be tightly coupled with the patient care process. As a system, all data and procedural support would be linked to ongoing patient care activities. This meant that there would be an analysis of the care process in the Oncology Center and, where appropriate, automated tools would be developed and integrated into the operational flow. As a result, early ties were formed with data-intensive ancillary functions, such as pharmacy and blood product support.

Of course, the development of these tools took time and the early computer resources were limited. Therefore, the third key decision and understanding was that the system would be phased into use gradually so that learning could be part of the design process; that is, the OCIS would not be a turnkey system but an evolutionary system prospectively sculpted to meet clinical needs.

The OCIS developers were fortunate in their initial choice of a database structure. If OCIS did not have a global patient orientation from its inception, development of any internal system would have logically centered around the administrative needs of the Oncology Center. In that case, it would have been necessary to integrate clinical functions with a system having an administrative architecture. This may have proved to be an impossible task owing to the relatively fixed nature of administrative structures and the dynamic nature of patient care. However, with the patient orientation, once the clinical functions were in place it was not difficult to add the necessary administrative tools and research links.

Further, if OCIS did not have a global patient management support orientation, the system might have become a series of specialized tools for the support of selected activities. All components of the OCIS are integrated because of this global structure. Every entity in the data model is either directly or indirectly linked to a patient record. One of the major benefits of this OCIS structure is that it permits the hosting of very simple features with broad utility (such as pain management tools, body surface area computations, and chemotherapy reaction monitoring) with only minor development activity.

Finally, we note that if there were not a willingness to underwrite a long-term commitment to automated support, the products of the early years of exploration and demonstration would have been scaled back to the limited number of applications that could be shown to save costs at that time. System growth might have been stunted at the level of what was efficient and essential in 1980.

In summary, the past success of OCIS is very dependent on the establishment of a favorable and flexible development environment within the Oncology Center. Although such management vision may have been rare in the mid-1970s, one would hope that there are many who now share this perspective.

Building an Oncology Clinical Information System The Johns Hopkins Oncology Center was organized in 1975 as part of the National Cancer Program sponsored by the National Cancer Institute. The basic goals of the Oncology Center are (1) specialized diagnosis and treatment management of patients with cancer, (2) conducting basic and clinical cancer research, and (3) education of medical specialists in the field of cancer.

The development of OCIS began just before the new Oncology Center building was opened. This created both opportunities and disadvantages. On the positive side, there was the freedom to organize the care process as the staff felt it ought to be organized, and there were few established precedents to inhibit change. On the other hand, this open structure implied that much learning would be required by both the clinical and development personnel. The experience base was narrow. A new system was to support a process that was not defined fully and that, by definition, had to operate effectively even before the system would be complete enough to provide it any assistance. The OCIS development team and the users were able to take advantage of the opportunities and overcome these difficulties. In the remainder of this section we describe our initial vision of OCIS and review its development history.

At this time (1988) the Oncology Center has over 200,000 square feet of space containing 84 inpatient beds, a large outpatient facility, several ancillary ambulatory care clinics, and a large basic research facility. A move to a new and much larger facility is planned for 1992. Presently, there over 750 full-time employees, including 80 clinical and research faculty, 40 fellows, and 150 nurses. The inpatient component of the Center admits over 800 individual patients per year, with an average of 2.1 admissions per patient, and an average length of stay of 25 days. The outpatient component of the Center has over 50,000 visits per year to its medical oncology and radiation oncology facilities.

The Decision Support Role of OCIS The initial intent of OCIS was to help support the information essential for managing patients with complex, chronic medical problems who have repeated admissions to the hospital and frequent outpatient visits. When on the acute inpatient nursing unit, these patients present a special problem in data management. Much information is collected and reported. The physician finds it difficult to recall which tests have been ordered, which have been reported, and which are still pending. Moreover, when the test results return, they may not be delivered in the same chronological order in which they were sent.

As a result, physicians spend considerable time organizing clinical information. Frequently, they are required to telephone several laboratories to get the most recent information that may not have been returned to them. Additionally, they transcribe results by hand to flow sheets, which provide a more efficient tool for decision making. This time-consuming effort is driven by the level of illness of the patient and the urgency for retrieving and assessing information as quickly as possible. As physicians have only a limited amount of time to allocate to each patient, time spent correcting errors of omission and processing data must compete for time spent in direct patient care, family interactions, and making decisions on the basis of available (and often incomplete) information.

The goal of OCIS is to provide ready access to information that is not only reliable, complete, and timely, but that is also presented in a manner that leads most directly to the correct decision. Many models of computer-assisted decision support have been explored over the last several decades. Differences in these systems relate to the distribution of responsibility between man and machine. Artificial intelligence solutions attempt to capture the knowledge of experts in medical diagnosis and thereby automate some of the decision making. OCIS has taken a simpler path to decision support owing to its relatively narrow focus. Well-understood processes are automated. In all other cases the responsibility for assimilation of data into diagnostic and treatment plans is left to the physician. This implies that OCIS must be able to present its information in formats that the physicians will consider useful in patient management.

Naturally, OCIS was intended to operate in a specific institution. However, the concept can be applied both to other oncology environments and other medical subspecialties. The need to assess enormous volumes of data in a timely manner has become essential in many areas of health care.

We conclude this subsection by identifying some of the philosophic foundations and operational constraints that provided a context for its design.

Acutely ill patients should be clustered into treatment units organized by disease category. This implies that the assessment of information about a specific patient may be difficult.

The setting of limits and thresholds for action, along with the monitoring of data as these limits are approached is a prerequisite for the timely response to medical changes.

Care of cancer patients must be managed by a team of providers; the use of the system by nonphysician specialists to initiate and provide follow-up medical support of antibiotics, fluids, and platelets is necessary.

The senior supervisory staff must monitor the quality control and compliance with agreed-upon support standards. This is particularly important in a teaching environment in which the medical house staff spend one-third of their rotation in the Oncology Center.

There is a need to integrate senior staff knowledge into the system by establishing prospective treatment protocols for both research and individual therapy. Graphic representation of data facilitates analysis by physicians and should be encouraged whenever feasible. For time-oriented information (both long and short term), displays that facilitate the recognition of subtle trends are required.

Information processing is aided by the clustering of data from various sources (hematology, laboratory, patient vital signs, pharmacy, blood bank) into meaningful disease-oriented displays that integrate several databases. Consequently, displays should group information into clusters by disease or treatment hypothesis, rather than by strict laboratory report groupings.

Because the Center staff rotates assignments frequently, any information system must provide considerable functionality to those who are not expert in its use. Such support may come from a very “friendly” interface or trained permanent staff members.

Development Chronology The ten-year development, implementation, and evolution of OCIS are described in some detail in Chapters 3 and 9. The evolution of OCIS spans several generations of computer technology, and a short review of its history will be helpful toward understanding how OCIS fits into the Oncology Center’s computer environment.

OCIS implementation has been organized as system phases.

Phase 0:

Development of an OCIS prototype began in 1975. It concentrated on determining general system requirements, demonstrating a rudimentary system, and selecting an appropriate hardware and software environment.

Phase I:

This phase consisted of moving the prototype system to a PDP-11/70 operating under MUMPS and implementing the system on a broad scale. Virtually all OCIS features described in this book can be traced to the one-computer Phase I system.

Phase II:

This phase of development consisted of two stages. The first was to translate the Phase I MUMPS applications into the newly released Standard MUMPS using a two-computer architecture. A special environment called TEDIUM2 was developed to support this activity. The second stage entailed the integration of an evolving microcomputer environment with the OCIS database.

Phase III:

The present phase of development integrates the essential OCIS functions both to take advantage of a rapidly evolving computing technology and to meet the other computational demands of the Oncology Center. This expanded environment includes local-area networks, user workstations, distributed processing, image access and analysis, and modular growth of the system.

Table 1 presents a summary of the development activities. Although the Phase I OCIS performed many useful functions, there were limitations that restricted its utility in a clinical setting. There was only a single computer, the

2TEDIUM is a registered trademark of Tedious Enterprises, Inc.

July 1975

Analysis and prototype of clinical systems begun

October 1976

Oncology Center facility opened

August 1977

First PDP-11 delivered, Phase I development of clinical systems begun

December 1977

Prototype database moved to new system

April 1979

Limited clinical management system on line

August 1979

Second PDP-11 installed to provide needed power

June 1980

Phase I development of clinical system completed; conversion to Standard MUMPS begun (Phase II)

August 1982

Phase II conversion of clinical system completed

October 1982

IBM PC selected as Oncology Center standard

January 1983

Development of research component to OCIS begun

September 1983

Network with School of Hygiene statistical computer

August 1985

Conversion to MUMPS M11+ completed; threefold increase in throughput; additional on-line storage

August 1985

Prototype of clinical protocol management system completed

February 1986

High-speed access to newly developed Hospital network

September 1986

Final Phase III plans submitted for funding

August 1987

PDP-11 /70s replaced by PDP-11 /84s; MicroVAX II installed for hemapheresis system; data switch installed

May 1988

Two MicroVAX 3600s installed and port of selected OCIS functions begun; PDPs networked with MicroVAXs

data were not always timely, and not all the computer programs were complete. The Phase II system changed this. It provided a mature two-computer system that could support a 24-hour-a-day, 7-day-a-week operation. There also was a trained staff, a collection of proven programs, and a group of physicians that were anxious to increase their use of the system. All the necessary prerequisites for a timely information system were now in place.

Attention was now directed to operational, as opposed to functional, considerations. During the early period of use, data were manually collected and entered into the system. This was an expensive, error-prone activity that inhibited the timely display of information. As the technology matured, electronic links were implemented for both on-line and batch, communication with other computer-based information systems in The Johns Hopkins Medical Institutions, that is Laboratory Medicine, Pathology, several Pharmacy charge capture systems, and the Hospital’s Blood Bank.

As OCIS became an essential component in the care process, user demands for computer applications increased. Additional functions were added to or integrated with the system. These functions included a unit-dose pharmacy system,

an in-house blood products system with order entry capabilities, additional research and analysis capabilities, additional administrative functions.

The query and report capabilities of the system were continuously enhanced, and a personal database that linked with data in the OCIS system was developed to assist with nonclinical data collection and analysis activities. Finally, moderate-level statistical tools, such as sample-size calculations, and low-level descriptive and analytic tools, were incorporated into the system in early 1983.

As the demand for data-processing applications increased beyond that initially intended for the central OCIS system, requirements for a broader applications environment became apparent. Fortunately, this need arose at approximately the same time the IBM PC was introduced (1982). Using the personal computers, the Oncology Center staff and faculty could address the specific computational needs that were not supported by OCIS. Of course, this trend was replicated in many medical and nonmedical environments at the same time. The advantage was that users had tools that required minimal external assistance for supporting their local needs. The obvious disadvantage was that the decentralization made the sharing of common resources and data more complex.

Within two years, there were over 80 PCs throughout the Oncology Center. Because it was unrealistic to expect OCIS to incorporate all the functions required by the Oncology Center, additional applications such as imaging, graphics, inhouse publication, personal databases, and sophisticated statistical analysis tools were quickly incorporated into the Center’s data-processing environment through PCs. Several local-area networks were developed in the administrative and laboratory areas. These networks presently incorporate approximately 40% of the Center’s PC population.

Today, with over 140 PCs and 175 terminals, the Center is undertaking the task of integrating the prevalent PC MS/DOS5 and MUMPS environments with additional environments, such as UNIX,3 VAX/VMS,4 5 OS/2,5 Ethernet, TCP/IP, DECNet,4 and the coming Open Systems Interconnect (OSI) architecture. Low-level communication between the OCIS/MUMPS system and the PC environment were established in early 1983. This level of communication between the two environments has increased gradually over the past four years, but has been restricted by a lack of integration tools and standards. Recently, the availability of such tools and standards has grown.

As shown in Figure 1, OCIS is now seen by users as one function or node in an Oncology Center network. It is the key clinical system, and its clinical database is used as a resource for the many research and administrative activities conducted at the Center. Because OCIS never was intended to meet all of the Center’s computational needs, development efforts continue to be directed toward integrating the Oncology Center systems with each other and with other resources throughout The Johns Hopkins Medical Institutions. Present and future development activities are discussed in further detail in Chapter 9.

3UNIX is a trademark of AT&T Bell Laboratories.

4 VAX/VMS and DECNet are Trademarks of the Digital Equipment Corp.

Description of OCIS The Oncology Center is a part of a larger system: The Johns Hopkins Hospital. Consequently, there is no need for OCIS is replicate functions that are available elsewhere. The Oncology Center relies upon the Hospital’s admission-discharge-transfer system and its billing systems. As a part of the Hospital, the Oncology Center must also look to other departments to provide services or modify existing systems. For example, it is the responsibility of the Pharmacy Department to operate the pharmacy located in the Oncology Center and of the Clinical Laboratory Department to certify the laboratory located near the outpatient department.

Thus, OCIS should not be viewed as a complete system for a hospital unit. It is a patient-oriented information system, which complements the resources that others provide. Its mission is to establish a comprehensive, integrated information management facility for patient care. The remainder of this section describes the functions supported by OCIS. The following section provides an overview of Oncology Information Systems, which manages the operation of OCIS, and a description of the computing resources that support it.

OCIS Clinical Data Management Functions The primary function of OCIS is to provide a subset of information from the medical record in an electronic form for both the generation of routine reports and on-line ad hoc access. In general, it is the intent of OCIS to minimize the need for the paper medical record in the day-to-day care of cancer patients. There are over 2500 variables for which data could be collected on each patient. These data can be used to generate reports on patient status or to provide ad hoc profiles on various patient parameters. Basic demographic and medical history data also can be easily viewed for all patients.

In addition to the primary clinical function of OCIS, there are several ancillary functions for which the system provides assistance. These include an inpatient pharmacy, a blood products matching and distribution system, an outpatient scheduling system, an in-house hematology system, an inpatient admit/discharge system, integrated treatment plans, and a clinical research protocol system.

The administrative spin-offs from OCIS include daily patient census, charge capture capabilities, a tumor registry, staff scheduling, and resource monitoring and forecasting capabilities. All of theses functions are summarized in Figure 2. As shown in the figure, virtually all computer-supported activities rely on information that is either directly related to the clinical status of a patient or related to the processing of such elements.

The patient data organization is structured as follows:

Summary patient information is linked to the unique identifier for all Johns Hopkins Hospital treatments (both inside and outside the Oncology Center). It includes a summary of Center treatments retained as short descriptive notes,

Figure 1

Figure 2.

an abstract of key demographic data, and some essential administrative information. These data are included in most reports in various degrees of detail. Data should be represented in time-oriented tabular form. Examples are test results, vital signs, coded performance measures, and daily totals of drug administration. These data can be displayed as plots or flow sheets.

Some clinical data cannot be represented as flow sheets or plots and require specially formatted reports. Examples are microbacteriology reports, daily drug administration profiles, and displays of blood product transfusions. The format of the output will depend on the data structure and the orientation of the user. To illustrate, the physician and the pharmacist require different displays of the same drug administration data.

Treatment data should be organized using fixed sequences of therapies and tests to monitor the patient response. Such data include both the patient-independent plans and the daily treatment recommendations as modified for each inpatient.

Because the OCIS may contain hundreds of therapy days for an individual currently being treated, and because there may be over a hundred data items collected during a single therapy day, the key function of OCIS is to collect the patient information rapidly and accurately and make it available to the health care team in appropriately focused displays. This implies that some data will be plotted, other data listed in greater detail, and some data presented in formats designed to facilitate the recognition of events and trends.

Table 2 is extracted from the OCIS Users' Manual. It lists alphabetically those functions supported by the system that will be of the greatest interest to clinicians. Most of these functions produce outputs that are used in medical decision making. How these outputs are used is discussed in Chapter 2. A description of the displays and the tools used to manage the data entry and display is contained in Chapter 4. The protocol-directed care system is presented in Chapter 5.

Ancillary Clinical Functions There are two functions supported by OCIS that focus on both the patient and the operational units. These are the pharmacy, which integrates its internal processing with the OCIS data collection and display functions, and the blood product support system, which manages a broad range of functions from product collection to transfusion management. These two systems are described in Chapters 6 and 7.

Administrative Functions Much of the data collected by OCIS can be used to support administrative activities. In fact, in an integrated environment it is difficult to separate administrative from care-oriented activities. For example, The Tumor Registry manages an abstract and summary of the diagnosis and treatments for all Oncology Center

Function Name


Page Number

Abstract (A) Complete diagnostic history

Tumor registry coding, patient history and symptoms, diagnosis, morphology, protocol IDs/dates, and physician follow-up information


Admissions scheduled (SA)

Displays a listing of patients who are currently scheduled to be admitted into the Oncology Center


Appointments By patient (PT) By provider (PR)

Short or full listing of appointments scheduled with emphasis on either provider, patient, or clinic appointments; dates can be specified


By clinic (CL)

Bacteriology report (B)

Up-to-date results of patient specimens, organisms found, and antibiotics with susceptibility factors


By date By specimen By organism

BMT screen display (PLAN)

Shows the BMT date, the number of days following transplant, the primary and associate nurse(s)


Blood and body fluid precautions

Provides a list of all active patients positive for blood and body fluid precautions by serology


list (BF)

Body surface area (BS)

Calculates a patient’s BSA on the basis of a given height and weight; calculates the dose for drugs on the basis of a given dose per square meter


CCPDS number conversion (CC)

Provides the actual HNO and name of a patient when it has been hidden or encrypted by OCIS


Census (C)

Flexible format that includes patient information, inpatient admits, OPD visits, protocol activity, and specific patient treatment responses and comments with diagnosis information


Chemistry screen (CHEM)

Displays routine chemistry values for any desired date on a per-unit basis and is time specific


Chi-square (CS)

A calculation routine used for patient statistical analysis


Clinical items Item Groups (IG) Item Names (IT)

Provides an alphabetical listing of the data item names (e.g., WBC, RBC, AMPH) used within OCIS


Counts—outpat ient (C)

Displays the routine hematology values of all outpatients being seen on the current day; values include the time results were collected and can be listed by provider, by medical oncology or radiology oncology


Cumulative doses (CD)

A calculation routine that provides the total dosage given to a specific patient since first admission


Function Name


Page Number

Data (D) Today’s data Latest data

Includes daily clinical data for each patient seen in the Oncology Center for any given date. User selects data range and search data


Search data item

Date difference (DD)

A calculation routine that results in the total number of days between any two dates given


Dictionaries (Y)

Several functions that are used for referencing interhospital physicians, protocol IDs, preformatted plot, and flow definitions and data items within OCIS



horizontal (F) Preformatted

A tabular representation of patient data showing any specified clinical values for seven days/dates in columns


Special order

Flow— vertical (F)

A tabular representation of patient data showing up to seven data elements in columns for values collected over long periods of time


Hematology counts (COUNTS)

Provides the most recent hematology values of the current day for each patient on an inpatient unit


Individual All or print

Hematology screen (HEM)

Hospital names

Provides time-specific routine hematology values of a unit for any given date See Physicians, referring in this list.


Inpatient census screen display

Displays the HNO, name, age, race, sex, room number, admission dates, and estimated length of stay for patients who are currently admitted to one of the Oncology Center units


Item ID (IT)

Provides the full name for a data element abbreviation that may be used in OCIS displays


Message system (W)

Electronic mail with editing capabilities for OCIS users with a password


Output definitions (OD)

Provides the data structures and data elements for the available preformatted plots and flows


Pain table (PAIN)

Provides conversions of narcotic analgesic doses and routes of administration; also lists pain medications


Personal data base (PD)

A menu of varied options that allow development and manipulation of a personal database


Physicians (JHOC) (JP)

Given a last name and initial, provides an alphabetical listing of JHOC physicians with the full name and ID number


Function Name


Page Number

Physicians, referring (RP)

Given a physician’s last name and initial or a beginning hospital name, provides an alphabetical list for access to full names, addresses, ID/phone numbers for a specified physician or hospital


Plots (P) Preformatted Special order

A graphic/linear representation of related data items showing changes and patterns on a plotted grid


Protocol ID (PR)

Provides a protocol list for selection of full protocol name, description, status, and overview


Provider schedule (VP)

Provides a current day display of the baseline schedule and times of availability for a provider or nurse


Provider summary (PS)

Using a specified date, displays a schedule of appointments with patient names for a specified provider or nurse


Registration (R)

Displays a patient’s name, address, insurance information, and pro fee comment


Schedule (S) CH

Shows all scheduled appointments, tests, and procedures for a requested radiology or medical oncology patient; user specifies the date


Search (S)

Provides the last 10 values of any selected data element for any patient


Transfusions (TR) NS Transfusion plan Transfusion history Transfusion reactions Platelet matching data Lymphocytoxic-

ity Glossary of blood products

Provides an extensive reference for an individual patient’s blood transfusion information


Treatment sequence plan (T) X PLAN

Shows a patient’s current treatment with start day and number of days on treatment; shows standing orders, daily care plans, clinical findings, and protocol definitions


Unlisted functions

See inpatient census section


Function Name


Page Number

View listings Patient’s by

protocol Protocol


descriptions Scheduled




Projected census


View option line

A command line that offers a selected patient’s



abstract, bacti reports, census, scheduling, data, flows, plots and other information

patients. This information can be used in patient care, research, or Center management. By first addressing the clinical needs, the data that exist can be applied in other contexts. Chapter 8 discusses these uses of the database.

Research Functions The Oncology Center conducts both laboratory and clinical research, and participates in four multi-institutional cooperative clinical protocol groups: the Eastern Cooperative Oncology Group, the Pediatric Oncology Group, the Radiation Therapy Oncology Group, and the Gynecology Oncology Group. The OCIS database serves as a central resource to support these activities. Clinical data routinely are copied over into research databases, and the OCIS database has been expanded to record items of interest in a clinical study, for example, outcome measures. In some cases, research laboratory data are also entered into OCIS for use in patient care or integration into clinical research protocols. At any point in time there are well over 150 clinical studies being conducted at the Center— approximately one-half are of a cooperative group nature and one-half are internal. OCIS provides tools to manage the administration of the research and to organize the data to be analyzed.

Users requiring large data extractions from the OCIS system file a request with appropriate OCIS staff and receive clearance. Data requests are scrutinized with regard to the resulting use of data and are cleared through the internal Clinical Research Committee. All requests are accompanied by a formal commitment to maintain patient confidentiality. Additional restrictions are placed on requests for research data coming from outside the Oncology Center.

Within the Center, there also is an increasing trend toward the electronic transfer of data between systems. Because OCIS was designed for clinical patient management, the structure of the OCIS database may require reformatting to manage some aspects of clinical research. As a result, there are plans at the Center for integrating the hierarchical OCIS database with a relational database. In this model the OCIS database will be used to collect essential clinical data, and the relational database will be used to monitor clinical research activity and provide a natural interface for ad hoc queries or statistical analysis of data. Details are discussed in Chapter 9.

Administration of OCIS Operation of OCIS is the responsibility of Oncology Information Systems (OIS). This organization has a clinical and research orientation and does not have a primary role in the financial and administrative functions. However, its director is charged with the coordination of the procurement and integration of all Oncology Center computer resources. Some of the facilities located in the Oncology Center are controlled by other Hospital organizations. The satellite pharmacy is the principle example. In what follows, the organization of the Information Center and its computer resources are described.

Oncology Information Systems The OIS has a full-time staff of 28 that includes a director, a senior manager, a development leader, a maintenance leader, 4 maintenance programmers, 2 development programmers, a systems supervisor, a network supervisor, 5 operators, 8 data collection personnel, a PC technician, and several administrative staff. The great majority of these individuals support the development and maintenance of OCIS. All OIS staff have cross-coverage responsibilities for OCIS.

Figure 3 displays the general information flow, organizational structure, and administrative responsibilities from an Oncology Center perspective. OIS is responsible for the 24-hour-a-day operation of oncology computer and communications equipment, developing communications capabilities with other facilities in the Hospital, the centralization collection of clinical information, and the development and maintenance of the necessary clinical management applications.

A unique position within OIS is that of the clinical data coordinator. The coordinators are assigned to specific clinical units within the Oncology Center and become closely integrated with the units’ medical staffs. They are responsible for a variety of routine and specialized data collection and entry tasks. They also serve as the primary physician interface with the system for specialized reports and queries. Thus, although all physicians and medical staff have on-line access to a multitude of generalized data query functions and reports, the OIS staff also provides routine access to the database without requiring special provider action. This is a very helpful feature in an environment in which interns, residents, postgraduate fellows, and attending physicians all change assignments frequently.

The OIS staff also provides clinical data interfaces and technical guidance for other computer-based activities within the Center and throughout the Hospital. The development of specialized applications that are not direct patient care func-

Figure 3.

tions is handled in a decentralized manner. For example, although the centralized collection and management of general clinical research data is the responsibility of the biostatistics component of the Oncology Center, close ties with the OCIS database are essential. The management of the Hospital’s Tumor Registry is performed by a hospital-funded component of the Center which is supported by OIS computing resources and staff. Data processing in support of administration is performed by a separate group in OIS that has high-level access to the OCIS database. In most instances, the OIS staff is responsible for recommending automation solutions for other areas of the Center. In many instances OIS both develops and maintains these applications.

OCIS Computer Resources The OCIS is presently composed of over 5000 TEDIUM programs (9000 MUMPS routines), 1300 relations, and 2500 data elements. The database contains information on over 55,000 individual cancer patients seen throughout The Johns Hopkins Hospital, of which over 20,000 were seen at the Oncology Center. There is on-line information on approximately 500,000 Center patient days. These include over 25,000,000 separate data points. Complete microbacteriology data are available for all Center patients seen after 1984 (approximately 35% of the Center’s total patient population).

Data are collected in two ways. The majority of the data is collected electronically from analytic laboratory instruments both within the Center and throughout the Medical Institutions. For laboratories in the Center, data are collected and displayed in real time. Externally recorded data are collected in batches and added to the patient records every two hours. All data are subjected to an extensive validation process before they are added to an active data set.

Where electronic data capture is not possible, as in the case of the recording of vital signs (temperature, pulse, blood pressure), the data are recorded by nurses or doctors in a hard-copy form and later entered by data coordinators and other data entry personnel. (Because the computer requires very little operational support, computer operators perform most of the manual data entry.) Very few individuals have authority to enter data into the system. This limited access to data entry and electronic data capture provides a controlled mechanism for ensuring the completeness and accuracy of data within the system.

Presently, the Oncology Center computing hardware consists of two PDP-11/846 computers, one MicroVAX II,6 and three MicroVAX 36006 series computers, and over 140 IBM PCs7. These computers are linked over an Ethernet8 architecture network using distributed database software, namely, InterSystems’ M/net9 and DECnet6 (See Figure 1). Approximately 170 terminals and 120 personal computers can be connected through a Gandalf StarMaster10 data switch to

6PDP-11/84, MicroVAX 360 & MicroVAX II are tradenames of the Digital Equipment Corp. 7 IBM any of the Oncology computing and peripheral resources. Peripheral resources include a 40-page-per-minute network laser printer that has PostScript capabilities, two 800-line-per-minute line printers, several smaller special-function character printers, and a large-bed plotter. The switch also can serve as a means of low-level communication between PCs within the Oncology Center and for on-line communication with other institutional computing resources. OCIS operates on the two PDP-11/84 computers and two MicroVAX 3600s. It has access to all the other peripherals as well.

The critical role that OCIS plays in the Center requires that it be in operation 7 days a week, 24 hours a day. Although two PDP computers are'the minimum required for normal system operation, the system is structured to provide a form of fault tolerance. If one of the computers and/or its associated peripherals fails, all critical functions can be moved to a backup processor until appropriate repair is made. Critical users are virtually remapped through the data switch to be connected with the operational computer should one of the systems fail. The MicroVAX systems can also serve as backups for each other and the PDP systems. Several very critical applications are maintained concurrently in both the PDP and VAX environments to provide an extremely low probability of extended down time. This backup strategy will be expanded in the future to cover the majority of OCIS functions. Any future functional expansion of OCIS, such as bedside data entry and a user query system, will be placed on the MicroVAX computers. Operators are available 24 hours a day and perform routine maintenance and backup functions for the PDP, VAX, and switching systems.

The Oncology Center network is connected with The Johns Hopkins Hospital Ethernet network through a filtering LAN bridge (See Figure 1). Individual devices can communicate with the Hospital network and associated devices through a Bridge CS-1 interface. The majority of computing facilities within The Johns Hopkins Medical Institutions are connected to this network. Thus, individuals within the Center that have either terminal or PC access to OCIS also have access to a variety of other services within the institution. Such services include medical literature searching, radiology, pathology and laboratory reporting systems, a centralized patient demographic database, and a variety of electronic mail systems. Conversely, with proper authorization, individuals throughout the Medical Institutions have full access to the OCIS database and associated functions. Thus, the information systems within the Oncology Center are integrated with other systems throughout the Hospital.

Future Directions Luck is a major ingredient in any successful venture. The OCIS is not an exception. When development began in 1976, we had a vision and the courage of the naive. We tried to build a system to help manage a complex process. As described in the chapters that follow, some of our initial goals proved unrealistic. But we adopted a philosophy and structure that demonstrated itself to be remarkably resilient. The OCIS grew and prospered. Technology changed, and networks obscured the boundary between the original OCIS and the automated tools used in the clinical, research, education, and administrative functions of the Oncology Center.

As the basic design philosophy in building the system was one of iteration and evolution, it is likely that there will continue to be ongoing phases of development. These developmental phases will probably include the integration of elements such as parallel processing, enhanced decision support and expert systems, some form of artificial intelligence, and on-line access to image data. However, in each new phase of development the iterative and interactive design philosophy that has made the overall system successful will be repeated and built upon.

The initial developers of OCIS are no longer associated with it; in fact, all have left the Oncology Center. A new generation of managers and developers is presently adding to the system and integrating it with other Johns Hopkins systems. Versions of the OCIS have been exported to two other cancer centers. We hope that readers will learn from what follows and that portions of OCIS will appear in other settings and systems.