Clinical Data Management

Gloria J. Stuart1, Bruce I. Blum, and Raymond E. Lenhard, Jr.

Introduction The primary objective of the OCIS, as described in Chapters 1 and 2, is to manage patient data and to present clinical information in a manner that facilitates medical decision making. This means that the OCIS must be able to produce reports in a variety of formats for each category of clinical data. To accomplish this, the OCIS also requires tools to define the desired formats, to produce the outputs at the appropriate times, and to collect the data in a timely and accurate fashion.

The OCIS clinical reports are patient oriented, and the system offers a variety of mechanisms for viewing a report. When the patient is being treated as an inpatient, the patient record is linked to an Oncology Center nursing unit. Table 1 lists the current inpatient units. Each unit has associated with it a home screen that identifies the patients currently in the unit. Figure 1 illustrates a sample inpatient screen. Access to the data for a patient is accomplished by entering the number to the left of the name. Thus, to view the data for Patient C, one would enter “3.”

When patients have been discharged, the clinical information is available by entering either the patient name or identification number. For patients being treated as outpatients, the appointment subsystem, which associates patients with clinic (and physician) appointments, provides another means of accessing patient information.

Clinical information is maintained on line for both active and deceased patients. The inpatient and outpatient data are merged, and summary abstracts are maintained. The primary goal of the OCIS is to display information that will facilitate the treatment of patients at the Center. The following subsections

'Gloria J. Stuart is presently Manager of the OCIS system. She has been in the health care field for over 20 years and has been affiliated with OCIS for the past 9 years. Prior to her position as Manager of OCIS she worked for the Pediatric Oncology Division and held the position of supervisor of data coordinators.

Unit

Number of Beds

Primary Diseases Treated

2 North

14

Solid tumor

2 South

14

Leukemia

3 North

22

Solid tumor

3 South

20

Bone marrow transplant

Pediatrics

14

Pediatric malignancies

describe the kinds of data that OCIS maintains and some of the functions that are associated with the maintenance of the data and reports. Naturally, there are administrative and nonclinical uses for the same data; these are discussed in Chapter 8.

The Clinical Data OCIS maintains clinical, support, and administrative data. All clinical data are patient oriented and keyed by The Johns Hopkins history number (HNO). This is a seven-digit number (with an optional eighth check digit) assigned to the patient and used for all inpatient stays and outpatient encounters. Assignment of the history number is the responsibility of the Johns Hopkins Hospital Medical Records Department, and the JHOC staff assumes the responsibility for seeing that the correct HNO is manually entered into the OCIS database.

Associated with the HNO are the patient’s name, demographic information, and administrative data. The OCIS duplicates portions of the central hospital system, but there has been no attempt to link the two patient identification systems electronically. Relative to the rest of the hospital, the JHOC sees a small number of patients over an extended period of time and has the facilities to verify that the correct HNO is being used. The OCIS does not require all of the administrative information used by the central business office, and it collects information not used

Figure 1. Inpatient home screen with unit census.

by the other systems. For example, there are provisions for both a home and local address, and the name can be of arbitrary length and written in both upper-and lowercase.

Below the level of the patient identifier, there is a record of all patient treatments administered at JHOC. This is maintained in a census file containing a summary of admissions, outpatient activities, diagnoses, and therapies. The census is augmented by an abstract of the patient’s medical record, which includes both medical and administrative data.

Although the census and abstract both contain some clinical data, they are used primarily as a summary to identify the patient, the disease, and an overview of the treatment. The clinical data are reported in more detail. Several categories of data are retained.

Tabular Data. These data can be represented as a triple consisting of an identifer, a time or date, and a value. Examples are laboratory results, cumulative daily medication doses, and subjective scales for performance. These data are displayed in the form of plots and flow sheets. Special formats are also provided to display current laboratory results on line, that is, the data reports. Bacteriology Data. These data follow a general pattern, but they require special report formats. There may be many organisms found in a single specimen and many antibiotic sensitivities for each organism. The bacteriology reports organize the data by time, specimen, and organism.

Treatment Plans. The protocol-directed care plans, described in Chapter 5, rely on treatment plans that are initiated, reviewed, and canceled by the Oncology Center physicians. Some of the treatment sequence plan displays that they use are presented here briefly.

Pharmacy Information. The OCIS tabular displays of medications summarize activity in the form of daily accumulations. Clearly, greater granularity is required for patient management. The pharmacy system, described in Chapter 6, provides tools for reviewing drug profiles and supporting medication administration. Most of the provider-oriented outputs are integrated into the other data displays and are not discussed in this chapter.

Transfusion Data. The presentation of this category of data must include the patient status before and after the transfusion, the kind of product used, and other information relevant to the planning of future transfusions. Although the display of these data are considered part of the blood product management subsystem described in Chapter 7, the blood transfusion summary report is an important tool in patient care.

Special Functions. There are a variety of special data management functions that can be managed easily when there is a comprehensive database available to support them. Examples include the computation of body surface area and the management of pain medications.

The OCIS philosophy is that all reports should be available on line from any terminal provided that the viewer has the appropriate authorization. (See Chapter 8 for a description of the authority system.) Because paper records can display more information and are more portable, all reports are available in hard-copy form as well. The OCIS has a task-scheduling system (see Chapter 8) that produces outputs whenever required, typically in time for morning rounds for inpatients and before visits for outpatients. Finally, we note that it is OCIS policy not to archive data. Thus, the provider has access to all information about a patient beginning with his or her initial treatment at the Oncology Center.

The equipment available for the initial implementation had a major impact on the appearance of the OCIS reports. In this era of microcomputers and bitmapped displays, it sometimes is difficult to recall what the state of the art was in the mid-1970s. Because many of the clinical reports have an “old fashioned” feel, we close this introduction with some background on this artifact.

At the time that the OCIS equipment was procured, there were two choices regarding a high-speed printer. One could opt for upper- and lowercase, or one could have the uppercase character set repeated twice, thereby doubling the printer’s throughput. We chose the latter option, a standard selection at that time. Unfortunately, the System treated the lowercase characters as nonprinting characters, and so the database was built in uppercase only. When we purchased the second computer, we added the ability to print upper- and lowercase, but the logistics of associating an output with a printer trapped us into continuing with uppercase abstracts, etc. It was only the introduction of the Phase III system that freed us from this limitation.

If printers were expensive in the mid-1970s, then plotters were even more expensive. In order to get the desired throughput, we elected to use character printing for our plots. When the 11 X 14 computer paper proved too cumbersome, we purchased an electrostatic printer and produced the plots in a landscape orientation on X 11 paper. The clinicians became accustomed to our plot formats, and there has been no demand to convert to a new format as the appropriate equipment has become less costly.

Finally, we note that OCIS does not use full-screen cursor control for any of its functions. (This fact would not be apparent from the examples in this book.) This also goes back to the mid-1970s. Although today there are over 200 OCIS terminals, our original system had only 8. We added to this number as we could, buying a variety of terminals that relied on evolving standards. Because of this diversity, we elected to restrict the OCIS applications to the common functions supported by all terminals, that is, clear screen, home, and scroll. Such is the fate of those who are among the first to implement.

Administrative Data Recall that most of the JHOC administrative functions are performed by other hospital or university systems, for example, inpatient billing, admissions, professional fees. Thus the OCIS administrative functions are limited to those activities that are integrated with the patient care functions. In some cases OCIS tools parallel those of the central hospital systems; this duplication is required because of the interactions between the administrative and clinical systems.

OCIS supports the following clinically oriented administrative functions. Each of these functions uses some of the clinical data for other purposes. More complete discussions of each function are contained in Chapter 8. They are catalogued here simply to remind the reader that, once a clinical database has been established, there are many uses for it.

Admission, Discharge, and Transfer (ADT). Although the central hospital system is responsible for the management of the ADT function, OCIS maintains schedules for both new and old patients; it provides an up-to-date locator for all patients in the Center, and it integrates discharge planning with the delivery of care. Projected admission and discharge dates are available on line or as printed reports.

Outpatient Scheduling. Preparation of reports and tests must be integrated with the patients’ outpatient schedule. Therefore, OCIS must maintain a scheduling system. This system must provide access to information organized by patient, clinic unit, and provider.

Tumor Registry and Research Office. The Tumor Registry is a registry of all patients who are diagnosed as having cancer at The Johns Hopkins Hospital. The JHOC Research Office maintains records about all JHOC patients who have been treated on a protocol study. Both units must interact with the clinical operation of JHOC, but neither can be considered a clinical function. Level-of-Care Reporting. A level-of-care nursing tool was developed at JHOC to record the intensity of care required by inpatients during their admission. This is recorded as a number from 1 to 5 and entered into the OCIS database. The number can be reported in the clinical displays; there also are special reports that are produced periodically.

Center Administration Reports. All of the data collected for patients can be organized by time or unit for use in Center management and planning. OCIS produces a large number of reports that describe Center activities in terms of occupancy rates, lengths of stay, diagnoses, protocols, etc.

Maintaining the Database The emphasis in the previous subsections was on the use of the OCIS database. We now consider how the data are collected. This is done in one of two ways: automatically through electronic data transfer or by manual entry. The first has the obvious advantages of ease of use, timeliness, and a low error rate. In many situations, however, electronic transfer is not possible, and manual entry is required.

Electronic Data Entry. Data can be transmitted directly to OCIS from the Clinical Laboratory, the Hematology Laboratories located in JHOC, and from the pharmacy system. The link with the Clinical Laboratory is discussed in Chapter 8, and the interface with the pharmacy system is described in Chapter 6. The Clinical Laboratory and Pharmacy links manage an exchange of data between independent systems. There is a need for tools and procedures to coordinate dictionaries and identify mismatched history numbers. This extra processing results in a delay between the time data are available on the host system and the time that the data are in the OCIS database ready for reporting.

Communication with the hematology laboratories is managed in a more efficient fashion. Because of the Center’s unique demands upon a hematology laboratory, the JHOC maintains two such laboratories. One is located in the inpatient facilities, where it is used by the inpatient units, the Medical Oncology Clinic, and the Radiation Oncology Department. A second laboratory is located off-site; it supports the Department of Hemapheresis and the Medical Oncology Consultation Service.

Three hematology analyzers in these laboratories provide the hematology results. The analyzers are linked directly to the OCIS computers. Results are generated via the Coulter counter, verified by the medical technologist, and sent directly to the OCIS database via electronic transfer. They are immediately reformatted for easy display on inpatient units. This has eliminated multiple calls to the Hematology Laboratory by physicians awaiting results on patients who potentially are in need of immediate blood product support. This is, perhaps, the most used facility offered by the OCIS.

Manual Data Entry. Operation of the OCIS data entry is divided into two categories. Routine, well-formatted data are entered by the computer operators. This fact implies that computer operations do not require much attending and that very little data remain to be entered manually. In fact, most of the data entered into the OCIS database require judgment regarding what should be entered and what the database contents should contain. As indicated in Chapter 1, the clinical data coordinator is responsible for this type of database maintenance.

The clinical data coordinator plays an important role with regard to the Oncology Information System. This position was developed specifically to serve as the interface between the health care providers and the programs and applications that reside in the OCIS. The clinical data coordinator has a comprehensive knowledge of the capabilities and limitations of the applications and is thus able to supply health care providers with the data in a format that best assists them in the daily clinical management of their patients.

Data coordinators are assigned to permanent locations within the Center and are regarded as members of the health care teams. The data coordinator assigned to the Bone Marrow Transplant (BMT) Unit, for example, has an office in that inpatient unit. Data coordinators attend daily rounds and provide updated computer reports on each patient. They attend routine meetings involving patient care; they are responsible for monitoring the data entered into the OCIS computer and serve as quality control mechanisms. In addition, they work with the health care providers to ensure that important data are captured and that new reports are developed to display that data in the best format.

Data coordinators serve each of the inpatient locations; Medical Oncology Clinic, Pediatric Oncology, and Hemapheresis. Although each area has specific duties unique to its location and program, data coordinators are cross-trained to provide coverage in other areas should the primary data coordinator be absent. This ensures continuous quality data support. Core coverage is provided on the weekends and holidays as well.

The data coordinator is the primary interface between the OCIS and the health care professional. To meet their obligations as clinical team members, data coordinators must possess sufficient knowledge of medicine to enable them to understand how to present the data in a manner that supports clinical care. Training is provided on the job, but all new employees have clinical work experience and college-level coursework in anatomy, physiology, and medical terminology. Although a programming background is not a necessity, a knowledge of data processing is helpful. Common data coordinator backgrounds include nursing, medical technology, and radiology.

To guarantee that the OCIS database contains correct and timely information, the data coordinator must assume responsibility for its validity. This implies that the data coordinators maintain appropriate internal dictionaries, schedule the listing of all periodic reports, enter the physicians’ plans into the daily care plan system, verify that scheduled actions have been carried out, record clinical findings that must be extracted from the medical record (e.g., weights and temperatures), coordinate admission and discharge actions, and communicate with the Research Office regarding protocol starts. Clearly, this involves much more than manual data entry. By assuming these responsibilities, however, the clinical data coordinator eliminates the need for any other member of the clinical team to enter data into the OCIS. Thus the providers typically operate in a “read only” mode; they are users of the system.

Supporting Functions We conclude this overview of the OCIS clinical data management functions by identifying briefly some of the support functions that are required to make the former operate effectively. The OCIS includes the following facilities.

Dictionaries of Terms. There are a variety of dictionaries used throughout the OCIS. Some identify the names of tests and findings. These provide short character identifiers, longer descriptive names, limits on the normal and allowable values, etc. Other dictionaries describe how to translate the data sent from the clinical laboratory and pharmacy system. There is a dictionary that describes all tests ordered in the hospital, what forms and containers should be used, where the specimen should be sent, etc. There are dictionaries for the units, the providers, the protocols, and so on.

Format Definition Output. The plots and flow sheets are considered to be reports produced by a report generator. The OCIS provides tools to define a format, edit or delete a report, and build a dictionary of available reports. Naturally, this dictionary of reports is integrated with the other dictionaries.

Routine Report Scheduling. Because the OCIS can produce so many different types of reports, it was essential that tools be provided to schedule the routine preparation of outputs for distribution to the clinical areas. Reports can be requested for delivery every day, on specific days of the week, when there is an outpatient visit, etc. A schedule may include several different reports, and many schedules may be active for a single patient.

Electronic Mail. The OCIS maintains an electronic mail facility that is used to send messages between the data coordinators and the Pharmacy, the Research Office, and other coordinators. The system can be used for communications among the staff or as a personal reminder system. ,

Data Sets for Analysis. Because the major orientation of the OCIS is patient care, little effort has been expended on the building of tools for retrospective data analysis. The system does have facilities for building data sets in formats that can be used directly by the standard statistical packages.

The Clinical Data Reports This section presents an overview of the clinical data reports that the OCIS provides. In some cases the use of these reports has already been described, and the reference in this section is very brief. There are many other reports and system outputs beyond those that are described in this section. The criteria for selecting an output for presentation here include its importance to the JHOC staff and its potential interest to designers and users of other clinical systems.

As noted earlier, to view the clinical data, the provider first identifies the patient and then selects the desired report. Patient identification for inpatients is by selection from a display of the current unit census; selection for all other patients is by either name or history number. (The OCIS recognizes whether a number has been entered and, if so, does an HNO lookup. Otherwise, it displays all names that match the initial letters entered and allows the user to select from this list or reenter another name.) Once the patient has been identified, the OCIS responds with the “view” prompt shown in Figure 2.

The commands for selecting a report are given in parentheses. Most reports also have options; most can be displayed on line or printed. If a printed output is requested, the user indicates to whom the output should be delivered. In practice, however, most printed reports are scheduled for printing and delivery automatically. Terminal use normally is limited to the display of data.

Commands may be strung together without waiting for the prompt. For example, if the provider wants to see the follow-up information (F) in the abstract (A) for the third patient listed in the unit census (3), then it is possible to enter

3, A, F and get the display without having to respond to intermediate prompts. Conversely, if the provider is unfamiliar with the OCIS, it is possible to enter a question mark (?) at any prompt and get a help message. Finally, if the provider enters

Figure 2. View options with description (page numbers refer to Users’ Manual).

a return without previously entering any information, the first option in the list (usually considered to be the recommended default) is selected. Naturally, entering an invalid command results in the repeating of the prompt line.

The clinical data available to the providers can be divided into the higher level summaries of treatment, for example, the abstract and census, into displays of the clinical data, for example, the plots, flow sheets, and bacteriology data, or into other specialized reports. The following subsections examine some examples in each category.

Patient Summary Information The OCIS patient summary information is relatively static. It is used for periodic reference, especially when the provider may not be familiar with the patient’s history. For example, the admitting officer may review this information when making a priority decision regarding admission. Segments of the patient summary database also are included in other reports.

The Census Subsystem. The patient census is an extension of what one might normally think a census should contain. This subsystem began as historic record of all census activities and was gradually enlarged to its present form. Even though the name is misleading, it has been retained.

The OCIS patient identification consists of the patient’s history number (HNO), name, and a demographic string consisting of age, race, and sex. (The age

Figure 3. Sample census report with description.

is updated each year automatically.) The census data consists of this identification information plus:

An optional text field. This text can be broken into strings with each string identified by a date. There are no Center standards regarding the use of this text field; its application varies from provider to provider.

A log of all hospital admissions, including the dates, length of stay (computed automatically), and final action, for example, discharged, transferred. There is an optional field for a brief comment.

A summary of the first and most recent outpatient visit for each clinic visited and/or radiation oncology treatment.

Patient diagnosis. A special Center disease dictionary is used so that patients may be grouped by disease in categories that are meaningful to JHOC. A more complete ICD categorization is available in the abstract, and there is also a field for the provider to write a clinical description of the diagnosis.

Protocol activity including the protocol, start and stop dates, where treated, outcome, and optional text field.

Figure 3 displays a sample census report. Other report formats may restrict some of the information displayed or order the information by diagnosis or protocol. (For a different census example, see Chapter 2, Figure 1.)

The Abstract. The abstract is an extension of the Tumor Registry record. It contains all the information necessary to satisfy the requirements of the American College of Surgeons and adds summary information of value to the OCIS clinicians. The use of the abstract in patient care was discussed in Chapter 2, and a sample

Figure 4. Abstract display options.

abstract was shown in Figure 2 of that chapter. A discussion of the abstract from the perspective of the Tumor Registry is contained in Chapter 8. The on-line display of the abstract allows the user to page through the entire abstract or jump to any section of it. Figure 4 lists the abstract display options.

Tabular Clinical Data In the OCIS, the data are divided into two categories: tabular data and special data. As the name implies, tabular data can be organized in a table (i.e., relation). The OCIS maintains the data in two tables. The Patient Data (PDATA) is indexed by HNO, date of the data, and name of the data item; each entry contains the value for that item, a normal/abnormal flag, and an optional (and seldom used) comment field. For data that may have more than one value reported each day, there is a Patient Data Time (PDATAT) file that adds the time of the value to the index.

The OCIS does not archive any data, and there are some 16 million data items on line. The MUMPS data access method facilitates immediate access to any value by date for a given patient. As discussed below, several of the standard reports can be built from data stored in this format. However, as discussed in Chapter 2, the key goal of the system is to display data in formats that are meaningful to the providers in the context of their current activity. Thus, there can be clashes between storage efficiency and display efficacy.

In the OCIS this clash is managed by replicating the tabular data in preformatted files so that the various displays can be produced rapidly. This is done periodically, usually at night just after the pharmacy data have been updated. The printed plots and flow sheets (which are generated from the tabular data) use this early morning state of the database. During the day, as the tabular data entries are updated, the updates are not reflected in the preformatted files. There are two reasons for this. First, the printed tabular displays satisfy most of the clinical needs; requests to view the most current data can be satisfied by listing from the Patient Data files or the unformatted flow format. Second, the processing demand to retain current preformatted files is heavy, and the high system load prevents more frequent updating during peak periods. (Compare this with the Ohio State University experience discussed in Chapter 10.)

The tabular data are displayed in the form of plots, flow sheets, and simple lists. For inpatient units, some summary data may also be displayed by unit. Examples of the most frequent displays are shown below; the use of these displays in a clinical situation was presented in Chapter 2.

Flow Sheets. The flow sheet is a tabular display of clinical data. Two formats are provided. The horizontal flow lists the dates as columns and the items as rows. The advantage of this format is that it can display all the appropriate clinical data for a limited number of days. (The narrow flow lists 7 columns on 8 Vi X 11 paper; the wide flow, which is very seldom used, lists 15 columns on 11 X 14 paper.) The disadvantage of the horizontal flow is that it cannot present long-term trends. For this reason, there also is a vertical flow that lists the data in columns and the dates (or times) in rows.

There are many flow-sheet formats; each is considered to be a special report for a particular need. Once the F command is entered, the user is asked to enter the name of the desired flow. A null return produces the default comprehensive flow that is shown in Figure 5. This horizontal flow sheet displays all the tabular clinical information for the patient for the period covered. The default is the most recent seven days of treatment as either an inpatient or outpatient. When browsing on line, there are options for starting with the earliest date or a selected date and paging forward and back.

At the top of the flow the patient identification, date of listing, unit, and flow name are printed. Below these are the dates of the data. For inpatients, the convention is to start listing with a Sunday in column one, except when the most current data are presented. If the patient is on protocol, then the protocol identification and day on protocol are shown. In Figure 5 the patient was started on two protocols on the same date. For BMT patients, the day of transplant is day 0, and negative protocol days can be listed.

Figure 5. Portion of a sample comprehensive flow.

JOHNS HOPKINS ONCOLOGY CENTER 2S

HISTORY NO:

: 123 45

67

NAME:

: SAMPLE,PATIENT

HEMATOLOGY CTS

DATE;

: 08/01/86

1986 TEMP

WBC

PLTS

HOT NEUT

BAND

ANEU

MANAN DEG C

#/CU

/MM3

%

%

%

07/17 30 38.8

066

37000

31.5

07/18 31 37.9

154

19000

31.0

07/19 32 37.9

187

57000

22.3

07/20 33 38.2

231

53000

31.3

07/21 34 38.8

200

52000

33.6

07/22 35 39.3

300

48000

30.9

07/23 36 38.4

300

31000

30.8

07/24 37 38.4

200

57000

26.1

1

07/27 40 37.8

330

58000

37.8

(C)URRENT (E)ARLIEST (D) ATE (P)RINT (Q)UIT

Figure 6. Sample vertical flow, unaligned format, terminal display.

The clinical data in the flow are grouped and ordered in clinically useful ways. A typical comprehensive flow may be three pages long. In Figure 5, the patient status data are given in the first block, blood product transfusions in the next block, hematology in the next, and so on. The medications exclude chemotherapy drugs; these are listed as a separate category. In each block, items are identified and data are listed only if values were reported during the period covered by the flow sheet. Abnormal values are indicated by an asterisk to the right of the value.

If the provider wants some other flow sheet, the initial characters are entered using the OCIS standard prompting convention. For example, entering “A” might return

where the letters in parentheses indicate the type of flow, for example, horizontal, vertical, narrow. As described below, the provider may define new formats as necessary.

If a vertical flow is selected, the user must then select the format option. Unaligned is the default; other options include listing a line for each date even if no data are available (aligned), compressing the date field to preserve space (compressed), and including all data with a time (time). Because space is limited in the vertical flow, on-line users may select only one protocol to be listed. Figures 6 and 7 show two formats for the hematology counts flow sheet for patients during a period in July 1986. Each patient was on the MANAN protocol; day 30 was 7/17/86.

Figure 7. Sample vertical flow, time format.

Plots. One of the most useful clinical displays for identifying trends is the plot. Several examples of their use were presented in Chapter 2, and an explanation for their character orientation was given above. Plots are available both on line and in printed form. The on-line plots are seldom used because of the limitations of the video screen: 80 X 24 characters as compared with 132 x 60 characters in the listing.

A sample plot is shown in Figure 8. It consists of two plotted items, platelet counts (P), and white blood cell counts (W). Both are plotted on a log scale from 100 to 1,000,000. (It is possible to plot up to four items with different scales on the same plot, but the resulting clutter makes this feature undesirable.) In this example, lines are drawn at 20,000 and 1000 to suggest decision boundaries.

Below the plot events are shown. In this case the first group of events is the administration of chemotherapy. There is no space to indicate the dosage; only the fact is indicated. A line separates the antibiotic medications, and the final group of events contains the temperature and the number of units of platelets and white blood cells transfused. (The asterisk in the temperature line indicates that the patient is afebrile; the number is degrees above 39° C.) From this plot one can see the effect of the chemotherapy upon the white blood cell count, the success of the therapies that respond to infection, and the use of platelet transfusions to prevent hemorrhage. (This plot was produced in 1981 with the Phase I OCIS; by comparing this sample with the plots in Chapter 2 it can be seen that the plot function has remained essentially unchanged since the late 1970s.)

Figure 8. Sample plot.

On-line Displays. Although the flow-sheet and plot formats are available for online review, they were intended to provide access to more data than can be assimilated comfortably at a small video display. Consequently, they tend to be used in their printed form throughout JHOC. The database is constantly being updated, however, and the paper reports soon lose their timeliness. Therefore, the OCIS provides a variety of on-line data displays designed to report the most recent clinical values.

The standard format is called the Data format, and it is selected by using the “D” command of the view prompt string. This results in the listing of the option prompt line shown in Figure 9. The default is the data for the current day, and a sample listing is shown in Figure 10. In this case all clinical data reported for patient SAMPLE, PATIENT on 7/20/88 are grouped and listed. Where there is a time associated with a result, it is listed.

All data items are identified by a 6-character item code. The selection of this short code was based on the amount of space available in the listing. There is also a 10-character code that is used in the horizontal flows and a 20-character description. These codes are maintained in an Item Dictionary, which also includes an internal sort code (used to group the items and order them within a group), the format of the value (e.g., numerical or alphabetical code, pattern match), and the ranges of normal and unreasonable values (the latter suggesting a data entry error). The “I” option of the Data prompt allows the user to review the codes in the Item Dictionary. Figure 11 shows the sample response to I,TMP as an input following the “D” command.

There are several other data display options. The Data Search (S) lists the most recent 10 values for the selected item. Figure 12 contains a sample output. There are also data display options available that allow the user to view data values for an entire inpatient unit. CHEM shows chemistry results for the patients on the 2S inpatient unit (Figure 13), HEM displays all hematology values for the 2S inpatient unit (Figure 14), and COUNTS displays a summary of critical hematology counts for the current day for the entire inpatient unit (Figure 15).

Bacteriology Reports The reports from the tabular data are relatively simple to implement because there is a common format for most data, and the data of most interest are those of the current day. In the case of microbacteriology data reporting, there are many different formats, the data may not be reported until weeks after the specimen was submitted, and the amount and kind of data reported will vary with the test results. For these reasons, a separate reporting (and data entry) subsystem was created.

Figure 9. Data display options with description.

Figure 10. Sample standard data display.

The provider enters the Bact reporting system with the “B” command and is requested to supply a sort order and a date or range of dates. There are three orderings available.

Report by Date. This is the standard format. It lists all results by date. If antibiotic sensitivities are reported, these also are listed and documented. Figure 16 shows part of a date-ordered report.

Report by Specimen. In this case the user is prompted to select a specimen. OCIS lists out all sites from which a specimen was taken for this patient, and the user selects a site. The system then produces a report of the results of all cultures for this site within the given date range. Figure 17 contains a sample report on blood cultures.

Report by Organism. As in the case of the report by specimen, OCIS prompts with a list of all organisms reported for this patient, and the user selects an organism from that list. Figure 18 contains a report for cultures containing Candida Albicans.

Figure 12. Sample Data Search listing.


Figure 14. Sample patient hematology report.

Figure 15. Sample unit hematology report.


Figure 17. Sample bacteriology report by specimen.

Schedules Although the scheduling function is considered an administrative activity, providers require access to patient schedules. There are a variety of schedule reports available from the inpatient and outpatient scheduling systems. The “S” command of the view prompt line produces a summary schedule, as shown in Figure 19.

Treatment Plan Reports Chapter 5 describes the OCIS daily care plan system. In this system we briefly describe some of the reports that this system makes available to the providers. The purpose of the treatment plans is to generate therapy recommendations


Figure 19. Sample schedule report.

based on therapy plans and research protocols that define the general rules for care. The care rules are described as “treatment sequences,” and a protocol may be defined by many different treatment sequences, for example, what to do at the start of a cycle of therapy and what the routine follow-up actions are.

Patients are managed by assigning them treatment sequences to create “standing orders.” Figure 20 contains a patient’s standing order list. Under blood procedures, the report indicates that a hematocrit (HCT) is required on day 1 according to the leukemia admission (LEUK ADM) treatment sequence and every day (Q1D) according to the leukemia follow-up (LEUK FOL) sequence. Under radiology procedures, the report indicates that a chest x-ray (CXR) is to be done beginning on day 7, every 3 days, until day 21 (B7/Q3D/C21) in accordance with the 8410 induction (8410IND) sequence. The report also indicates when the test was done last, how many times it was done, and the day on the protocol. In this example it is day 53 in treatment sequence 8410 IND, and therefore no chest x-ray will be ordered.

Each day, plans are generated from the standing orders that indicate what therapies, procedures, and tests are recommended for the current day. The reports are produced in several formats. Figure 21 shows the form used by the providers. At the top is the standard OCIS patient heading. In this case it is augmented to include the patient’s height and body surface area (BSA); these are used to compute drug doses. Below this are the text messages from the census system. Because these messages are optional, not all plans include this descriptive text. Next the protocols on which the patient has been entered are listed. Finally, the recommendations for tests and procedures to be ordered that day are presented.

Figure 20. Extract from a standing order report.

Transfusion Reports Chapter 7 describes the OCIS blood management system. In this section we briefly describe some of the features of that system that are available to the providers for their use in patient management. Figure 22 shows the transfusion option menu that is listed when the “TX” command is entered. Because the OCIS is used by the rotating house staff, as well as by the permanent staff and faculty, this menu provides access to both patient specific data and general introductory material.

For each patient, the menu provides access to plans and histories for both red blood cells and platelets. Figure 23 displays a red blood cell transfusion plan and Figure 24 a transfusion history starting on 9/12/86. For each date the history shows the protocol date (PD), the time at which the blood was drawn from the patient or the time at which it was transfused (if there is an RBC in the TR column), the hematocrit level (HCT), the normalized RBC increment (see below), a bleeding indicator (BLD where 0 is no bleeding and 4 is massive bleeding), the patient’s weight (WT) and reticulocyte count (RET), and the average number of RBC units used per week (R PER WK).

There are similar reports for platelets. Figure 25 contains a platelet transfusion history. This is slightly more complex in that the donor platelets must be matched to the patient by HLA type. (This is discussed in further detail in Chapter 7.) In this report, the patient’s HLA antigens are listed in the heading (A2,ll B13,46 BW4,6) and those of each transfused product in the HLA column. The MATCH column codes the degree of match between the patient’s HLA type and that of the product

Figure 21. Sample physician’s daily care plan.

, and the final column is the product identifier. (The prefix SS indicates that the platelets were collected at JHOC.) The INCREM/HR is the number of transfused platelets (normalized for patient weight) that were retained over a given period. It can be seen from this report that the transfusion of the first product (with a match of 10100) was highly effective compared with the subsequent poor transfusion increment of only 57%.

In addition to the transfusion histories, there is a transfusion reaction history that is used to record any adverse reaction the patient has had to platelet transfusion and any premedications given to prevent such reactions. Figure 26 contains a sample report. There also are reports that cross match available products with patients and detail lymphocytotoxity cross matches. Finally,

TRANSFUSION OPTION MENU

BLOOD TRANSFUSION INFORMATION

TRANSFUSION PLAN :

RED CELL

R

PLATELET

P

TRANSFUSION HISTORY:

RED CELL

RC

1

PLATELET

PL

TRANSFUSION REACTION

HISTORY

TR

PLATELET CROSS MATCH

DATA (RGT)

CM

LYMPHOCYTOTOXICITY -CROSS MATCH DATA (QS)

L

HELP: GLOSSARY OF BLOOD PRODUCT TERMS & DEFINITIONS

G

NEXT PATIENT

N

ENTER:

Figure 22. Transfusion option menu.

TRANSFUSION PLAN INFORMATION: RED CELL SAMPLE, PATIENT 1212123

APLASTIC ANEMIA - BMT

** PREFERRED RED CELLS **

1. IRRADIATED (TO PREVENT GVHD)

2. LEUKOCYTE POOR (TO REDUCE RISK OF FEBRILE TRANSFUSION (REACTION) WARNING: THIS TRANSFUSION PLAN MAY BE 72 HOURS OLD. IF THERE HAS BEEN A CHANGE IN CLINICAL STATUS OR A TRANSFUSION REACTION, THIS PLAN MAY HAVE BEEN VERBALLY ALTERED. IF THERE ARE ANY QUESTIONS, CALL BLOOD BANK (6580) OR DR. PLATELET (5020) .

** COMMENT **

SUGGEST PREMED WITH DIPHENHYDRAMINE (092686) AND ACETAMINOPHEN (103086);SUGGEST LEUKO.POOR PLTS.(110686);PT. HAS MULTIPLE RED BLOOD CELL ANTIBODIES (110786)

Figure 24. Sample red blood cell transfusion history.

Figure 25. Sample platelet transfusion history.

Figure 26. Sample transfusion reaction history.

the transfusion menu provides a dictionary and some tutorial instruction (see Figure 27).

Special Reports OCIS offers several other reports that are helpful to the providers. Some list data from special files. The blood and body fluid precautions report shown in Figure

28 identifies those active patients who are positive for blood and body fluid precautions by serology. There is also a PAIN function, described more fully in Chapter 6, that assists in converting one narcotic analgesic dose and route of administration to another dose and/or route of administration. This is especially helpful when preparing medications for patients about to be discharged. Figure

29 shows a sample of the narcotic information listing.

Providers also have access to the statistics and analysis menu shown in Figure 30. This provides access to sample-size calculation routines and quick calculation functions for computing chi-squares, date differences, body surface area, and cumulative doses. The PAIN function is available from this menu, as well as from other menus. Finally, the menu provides access to a personal database system; the demand for this feature has diminished as the number of personal computers in the JHOC has increased. (A separate “study” menu can be used to

1

WHOLE BLOOD

2

RED BLOOD CELLS

MODIFICATIONS:

3

LEUKOCYTE POOR RED CELLS

4

WASHED RED CELLS

5

FROZEN DEGLYCEROLIZED

6.

, CMV NEGATIVE RED CELLS

7.

. AUTOLOGOUS BLOOD

8.

, IRRADIATED

9.

, POOLED PLATELET CONCENTRATE

10.

. PLATELET CONCENTRATE, PHERESIS

MODIFICATIONS:

11.

. CONCENTRATED

12.

, CMV NEGATIVE

13.

, IRRADIATION

14.

, WASHED

15.

, LEUKOCYTE POOR PLATELETS

16.

, ABO COMPATIBLE

17.

, FRESH FROZEN PLASMA

18.

GRANUL0CyTES

NUMBER OF

DEFINITION REQUESTED ("RETURN" TO QUIT):

TERM

DEFINITION

INDICATIONS

LEUKOCYTE POOR RED CELLS

UNIT OF RED CELLS PROCESSED SUCH THAT 70% OF LEUKOCYTES HAVE BEEN REMOVED AND >70%

OF RED CELLS RETAINED. CURRENTLY DONE BY A HARD SPIN & ADMINISTRATION WITH PALL FILTER; MAY ALSO BE DONE BY 1 LITER SALINE WASH.

*TO PREVENT FEBRILE TRANSFUSION REACTIONS (GREATER THAN 1 DEGREE C UNEXPLAINED RISE IN TEMPERATURE DURING OR SHORTLY AFTER TRANSFUSION).

Figure 27. Transfusion dictionary display.

extract data sets for electronic transfer to other computers. Most clinical researchers prefer to work in their own environment, usually a networked PC.)

Clinical Support Functions The previous section described the clinical outputs produced by the OCIS. From the providers’ perspective, this represents what the system does for them. Yet, the production of those reports requires considerable OCIS infrastructure. We close this chapter with a brief summary of some of the hidden system features that are essential for the effective operation of a clinical information.

ONCOLOGY INFORMATION SYSTEM

07/20/88

HEPATITIS BLOOD & BODY FLUID PRECAUTION PATIENTS

(LAST UPDATED: 07/18/88)

NAME

HNO

FIRST POSITIVE

LAST POSITIVE

PATIENT,

A.

2238193

10/23/86

10/23/86

PATIENT,

B.

2152021

03/14/85

03/14/85

PATIENT,

C.

2020580

09/30/87

01/21/88

PATIENT,

D.

1622570

02/05/88

02/05/88

PATIENT,

E.

2319724

05/12/88

05/12/88

PATIENT,

F.

2318449

04/20/88

04/20/88

PATIENT,

G.

2256068

03/04/87

03/31/87

Figure 28. Sample blood and body fluid precautions report.

NARCOTIC

INFORMATION

EQUI-

•ANALG. TO

DRUG

FORM 10 MG MORPH.

RETAILED DOSE

CODEINE

SOLUTION SOLUTION

200

3 MG/ML*, 6 MG/ML

(W/ACETAMNPHN)

200

12 MG/ML

SYRINGE

130

15*, 30, 60

TABLETS

200

15,30,60

DEMEROL

SOLUTION

300

10 MG/ML

(MEPERIDINE)

SYRINGE

75

25,50,75,100

TABLETS

300

50,100*

DILAUDID

SUPPOSITORY

? ?

3

(HYDROMORPHONE)

SYRINGE

1.5

1*,2,4,10*

TABLET

7.5

1*,2,3*,4

METHADONE

SOLUTION

20

2 MG/ML, 5 MG/ML*

(DOLOPHINE)

SYRINGE

10

8*, 10

TABLETS

20

5,10,40 (DISKETTS)

MORPHINE

SOLUTION

60

2 MG/ML,4 MG/ML,20 MG/ML

SUPPOSITORY

??

10 MG*

SYRINGE

10

1,2*,4*,8,10,15

TABLET

60

10*, 15*, 30*

Figure 29. Sample narcotic information display.

Figure 30. Statistics and analysis menu.

System Dictionaries Like any large information system, the OCIS relies upon dictionaries to provide generality. There are over 100 system dictionaries plus equal numbers for the daily care plan, pharmacy, and blood management systems. Many of the dictionaries are simple tables, for example, a table listing provider identification and name; others require a more complex structure, for example, a dictionary that associates the valid ZIP code ranges with a state.

For each dictionary, the OCIS requires programs to maintain the dictionary. Adding new terms is always easy to implement. However, editing and deleting existing entries can introduce referential inconsistencies whenever the changed data are pointed to from other segments of the database, for example a result for a test whose identifier has been deleted from the dictionary. In some cases, where it is important, the OCIS implements tools to preserve referential integrity; in other cases the OCIS provides a mechanism to accommodate those occasional referential failures that would be computationally too expensive to avoid.

A catalog of dictionaries would be beyond the scope of this section. Nevertheless, the reader should be aware that the management of such a large number of dictionaries requires considerable effort. There is a need for programs to maintain them, menus to provide access to the programs, and documentation so that the maintainers know which dictionaries are to be updated. Most difficult of all,

however, is the building of a correct and complete dictionary and then keeping it up-to-date. This is commented on in Chapter 10.

Clinical Data Entry It was briefly noted above that the clinical data entry falls into one of three categories:

Manual data entry, for example, entry by a clinical data coordinator of material taken from the medical record, or by a computer operator of data already formatted for entry.

Automated data transfer using the JHOC facilities, for example, between the Pharmacy and the OCIS, or from the Hematology Laboratories to the OCIS. Automated data entry between the JHOC and another Hospital organization, for example, from the clinical laboratory system to the OCIS, or between the Oncology satellite pharmacy and the central pharmacy system.

In the first two categories the process is closed within the JHOC, and it is easier to define and control the software. In the third category, on the other hand, the OCIS is a secondary user of the data. The entry software must be able to recognize inconsistencies that can result from the use of two independent systems, for example, data with an inappropriate history number. Also, because all systems are subject to change, the OCIS must be able to identify changes in the data formats transmitted, for example, results reported in a new format or different units.

The problems that the OCIS faces in this third category is common to all decentralized systems that share data over a network. In some cases there are formal, low-level, institutional exchange standards. In this event, mechanisms exist to maintain the standard at a cost in responsiveness. However, when a independent system such as the OCIS is tied into a network, it is interfaced with the understanding that it will not hinder the data supplier’s main mission. Therefore, the independent system must be programmed to insulate itself from changes that it cannot control. In our situation we have always had the full cooperation of the data suppliers, but, because we are dealing with the data used in clinical decision making, we have had to write programs that do not take that cooperation for granted.

Report Definition and Scheduling Because the OCIS was designed to produce paper reports, it includes a variety of tools that automate the production and distribution of the reports. The standard processing flow is oriented around the distribution of the clinical data reports in time for morning rounds (inpatients) or an encounter (outpatients). After the database is updated from the clinical laboratory system and the pharmacy system, the requested plots and flow sheets are printed. The outputs are organized by nursing unit and outpatient clinic and delivered to the units in time for their use. Separate schedules are followed for the generation of the daily care plans, pharmacy operations, and the management of blood products.

Figure 31. Definition of a horizontal flow-sheet format.

There are OCIS system-level tools that manage the production of the reports on a predefined schedule (see Chapter 8). Additional tools are required to establish which reports the system is to produce. The clinical data coordinators have a menu that allows them to define new output formats and patient-specific report requests. We briefly describe these functions.

All plots and flow sheets are considered general reports created from the Patient Data files. Each report is given a short name and an optional description; its contents are defined using the terms in the Item Dictionary. For example, Figure 31 contains the definition for a horizontal flow sheet that displays all antibiotics (ANT) and drug levels (DLV). The dictionary terms *ANT and *DLV indicate that a heading line should be printed and that all data values in this category reported during the days covered in the report should be listed. A sample flow sheet from this definition is shown in Figure 32.

When a report is defined for a class of items, the contents of each page will vary with the patient’s treatment. It is also possible to define explicitly what items are to be included in a flow sheet. For example, the flow sheets shown in Figure 32 could have been defined as

>ANT This produces just the heading line FLU This produces the FLUCYTOSIN line ACYC ....

Of course, in the second definition, if a specified drug was not administered during the period, then a line with no values would be included. Also, if an antibiotic that was not explicitly listed was administered, then it would not be reported in the flow sheet. The vertical flow sheets are defined in a similar fashion, except, because of their limited width, the headings and generic item classes (e.g., > ANT and *ANT) are not accepted.

Figure 33 contains a definition of a plot output. Here the user must specify the items to be plotted, the letter to be used in the plot, the kind of plot (log or linear), and the scale. In addition, one must define what events are to be displayed at the bottom of the plot. In this example, MEDICATION TYPE 3 and CHEMOTHERAPY are generic terms, and the plot will include all events of that category.

Figure 32. Sample output from flow-sheet definition.

Figure 34 illustrates an on-line plot that was produced with that definition. Because the plot is limited to 24 lines, the plot and event portions are displayed as separate screens; in this figure the two screens are combined into a single unit.

In addition to defining the report formats, the clinical data coordinator schedules their routine production. This is done by (a) identifying a patient, (b) selecting a report format, and (c) selecting a schedule for production. Examples of schedules are every day, every Monday, and Wednesday and Friday. The bacteriology reports can be ordered on a fixed schedule or whenever they are updated.

Figure 33. Definition of a plot format.

Figure 34. Sample output from plot definition.

All of the report definition and scheduling programs use a prompting interface so that all selections are made from the current dictionaries of valid terms.

The OCIS and the Medical Record The ability of the OCIS to manage and maintain the patient’s clinical data has been described in this chapter. The power of the OCIS raises obvious questions about the relationship between the computerized system and the formal medical record. In The Johns Hopkins Hospital, the Medical Records Department is responsible for the maintenance of a complete paper record. The fact that the JHOC duplicates much of the clinical data in that medical record does not eliminate the requirement that a paper medical record be kept. Thus, the OCIS need not maintain all of the information that would otherwise be required of a medical record.

The JHOC maintains a supplementary or local record. It consists of the patient abstract, the standard flow sheet for the entire period of treatment, optional plots, and copies of all consultation and discharge notes. (The notes are prepared by a dictation service and are not maintained as part of the OCIS database.

Perhaps the use of word processing and networking will facilitate the future integration of these notes into the OCIS database.) A hard copy form of this record is stored within the JHOC; virtually all of the information also is available on line.

The paper medical record is requested from Medical Records for all admissions and many outpatient visits. If the record is not delivered promptly, the local record is used. All required notes are entered into the medical record. If appropriate, a copy of the note is also entered into the local record. To reduce the bulk of the paper record, some OCIS printed reports can be used to substitute for individual laboratory reports.

At first glance, this may seem to be a cumbersome system. However, the reader should recognize that there is a considerable increment in system responsibility when one goes from displaying the clinical data of greatest interest to the management of a complete medical record. Moreover, it must be remembered that the JHOC is but one unit in a 1000-bed hospital; it must conform to institutional standards. Therefore, the OCIS was designed to meet the internal JHOC clinical needs in a manner that would be compatible with Hospital practices. Clinical decision making is freed from a reliance on the bulky paper record, and record delivery delays do not affect emergency admissions. At the same time, the OCIS developers and operational staff do not have to address some of the more difficult problems that confront the Medical Records Department.

Рекомендуем к просомтру

www.kievoncology.com благодарны автору и издательству, которые способствует образованию медицинских работников. При нарушении авторских прав, сообщите нам и мы незамедлительно удалим материалы.