Data management for clinical research

Transcription

1 Data management for clinical research by W. L. SIBLEY, M. D. HOPWOOD, G. F. GRONER, W. H. JOSEPHS and N. A. PALLEY The RAND Corporation Santa Monica, California ABSTRACT This paper discusses a prototype system intended for the personal use of physicians engaged in ciinical research. In particular, the prototype is a highly integrated, interactive, minicomputer based data management and analysis system. The facilities offered by the system allow the clinical investigator to store, recall, analyze, and display his research data without resorting to computer programming. Modem data base techniques are available to the physician as aids in organizing, storing, and retrieving his data. The data base concepts are expressed in terms that are familiar to a clinical researcher. PURPOSE The purpose of this paper is to discuss a prototype system intended for the personal use of physicians engaged in clinical research. In particular, the prototype is a highly integrated, interactive, minicomputer based data management and analysis system. THE CLINFO PROJECT Th~ c:linfq,pr()totyp~.~~ta manag~m~ut and anab:~is system described in this paper has been developed as part of the CLINFO project, a scientific inquiry sponsored by the Division of Research Resources (DRR) of the National Institutes of Health (NIH). The goals of the project are to identify and characterize the information analytic tasks and the information flows in clinical research, and to develop methods for facilitating these tasks and flows. The project is being conducted by clinical investigators at the Baylor College of Medicine, the University of Washington, the University of Oklahoma, and Vanderbilt University; by information scientists at the Rand Corporation; and by staff members of the DRR. We have thus far (1) interviewed clinical investigators both formally and informally., (2) characterized their information processing needs, (3) identified data management and analysis as major problems, (4) examined existing computer systems aimed at satisfying those needs, (5) designed, built, and installed three copies of a prototype system, and (6) started the analysis of instrumentation data and user interviews to help us evaluate the system. References 1, 2, 3, and 4 discuss various aspects of the foregoing points. CLINICAL STUDY DATA VOLUMES AND ACTIVITIES A General Clinical Research Center (GCRC) provides facilities which clinical research personnel can use in conducting a variety of medical studies. Each study tends to be separate and distinct from other studies and provides a natural focal point for data collection and analysis. A large study involves approximately 75 subjects (patients) and a total collection of approximately 67,000 data values. 1 Generally, a clinical study involves the following activities: During the study design the investigator decides what data are to be collected, at what rate, and in what volume. As the study progresses, data are collected and recorded in a central data file. Considerable care is taken to ensure the validity of those data. As the study progresses, the investigator reviews and sum~~r!:z~~ th~ d~t"~."p~i1 of the::. pro~,ess, of S,Un::Wlllrizahon Involves transcribing the data into a form suitable for statistical analysis as well as the preparation of plots, graphs, and reports. The CLINFO prototype is designed to accommodate 25 such studies. SYSTEM OVERVIEW The prototype is implemented on a commercial minicomputer (Data General Eclipse S2(0) using multi-user extended BASIC.5 Each study has its own portion of a 25 million character disk. When an investigator (or a member of his staff) uses the system, he interacts with the CLINFO software (primarily by responding to prompts) and is prevented from using BASIC procedures to affect his data. Figure 1 illustrates the main features of the CLINFO 63

2 64 National Computer Conference, 1977 ( DESCRIBE }--s Vl UPjTE ~ C ( ENTER )-- ~_V' M I PATIENTS I S T o U A 0 ( RETRIEVE )-+ ~-i T '{ I SUBSETS I A I ( ANALYZEDISPLAY }--_I WORKSHEETS I-1COMM FILE I Figure I-Command(---) and data (-) flow in the CLINFO prototype for a single protocol prototype. The ellipses encompass the three general activities which were mentioned above. The rectangles indicate the various ways in which data (or descriptions of data) are stored in the prototype. The diagram encompasses a single study (or research protocol). This paper is concerned primarily with the activities labeled "DESCRIBE," "EN TER" and "RETRIEVE" and the data contained in the "SCHEMA," "UPDATE," "PATIENTS," "SUBSETS," and the "STUDY DATA" structures. The "ANALYZE DISPLAY," "INPUT," "OUTPUT," and "BASIC" activities and their associated structures will be described, but in less detail. THE DATA BASE The organization of a CLINFO study data base is predicated on three observations: The fundamental unit of analysis is usually the patient. Data are collected about that patient over time. The data have natural groupings in time (e.g., the vital signs of a patient are sampled at essentially the same time). The time-oriented nature of clinical research data has been discussed by Fries. 6 Dr. Fries' ideas have been further reinforced by our observations of the current manual techniques for recording that data. For example, data are recorded in patient flowsheets (one for each patient) which are two-dimensional arrays with the rows representing the data items to be measured and the columns containing the values of an item for different times of measurement. We have further observed that some of the rows can be grouped naturally into related items (examples of such groups are vital signs, blood serum tests, urine analyses, etc.). However, the groupings differ widely from study to study. The CLINFO term for a grouping is PANEL." The concept parallels records or groups in the CODASYL Data Base Task Group (DBTG) report. 7 PATIENTSSUBSETS The key structure is the PATIENT file which contains an eight character abbreviation for each patient (assigned by the clinician when the patient is added to the study) and an internal numeric key (assigned by the system). This file can contain up to 392 different entries. The entries are ordered alphabetically on the patient abbreviation to allow for efficient searching. A subset is a named file (e.g., LOWBLOOD) with the same structure as the PATIENT file but containing patients with particular properties. No particular patient ordering is maintained for subsets. There can be as many subsets as space allows. The numeric key associated with each patient references a block of data in a PATIENT DIRECTORY (not shown). That block contains some redundant identification data and two tables. The first table contains pointers to the patient's set of panels (see above) in the STUDY DATA file and counts of the numbers of instances of the panels. The second contains data concerning the state of the various EVENTS (to be described later) for this patient. DESCRIBESCHEMA The SCHEMA 7 provides the means for adapting the CLINFO data base structure to the needs of a particular investigator. It is a description of the panels and their contents. The schema exists in two forms: the external textual form and the internal compiled form. The former is for human interaction, the latter is for computer processing. The DESCRIBE activity is in essence an interactive editor which allows the clinician to create, edit, and compile his schema. The schema describes three main entities: ITEMS of data, PANELS of items, and EVENTS triggered by the occurrence of certain values for particular items. PANELS have eight character names, and references to them by name imply reference to all of their items. There are two types of panels, numeric and textual. The type of the panel determines the types of the data items included in that panel. Each panel can contain at most 30 items, all of which are either 32-bit floating decimal numbers, or character strings at most 70 characters in length. A sample panel entry in the schema might be PANEL 1 hist,patient ID & history,numeric; Reading from left to right, this is the first panel (PANEL 1), its name is "hist ", it contains "patient ID & history," and its items are all numeric. ITEMS also have eight character names which are used to reference the data associated with an item in a wide variety of circumstances. Again, an item may either be numeric or textual. In addition, there are parts of the item description that serve to screen, validate, and possibly encode the value associated with that item. For example: ITEM 9 HT,Height,inches,num,range,(55,80),no;

3 Data Management for Clinical Research 65 Reading from left to right, this is the ninth item in the schema (ITEM 9), its name is "HT ", its values represent height in inches, its values are numeric and must lie in the range 55 to 80 inches inclusive, and its value need not be considered confidential ("no"). "Height" and "inches" are purely descriptive and do not imply automatic units checking by the system. The sequence "num,range,(55,80)" illustrates one option available for data screening. Other options for items in numeric panels are: date,range( , ) the item value is a date in the indicated range ( to inclusive). time,range(1300, 1330) the item value is a time in the indicated range (13:00 to 13:30 inclusive). num,check(4),(7,10,6,5) the item value is numeric and one of the listed 4 values. char,code(3),(yes,no,unk ) the item value is externally one of the listed 3 character strings and is carried internally as one less than the ordinal position of the string in the list (i.e., 0, 1, or 2). the data types date, time, and num may require no validating, e.g., num,none. The textual panels and items are of the form: PANEL 2,demo ITEM 20,name,demographic data,text;,patient name,text(30); The item "name" will then be allocated 30 characters in each occurrence of a "demo" panel. EVENTS are time markers maintained by the CLINFO prototype system to aid the user in the retrieval of his data. It is common in clinical research to relate the response of a patient to a procedure by referencing some events which marks the application of that procedure. For example, blood sugar levels are measured at regular intervals after the ingestion of glucose. Events provide the means for cieaiing with relative time. A sample event is: EVENT 3 test,glucose ingest,gluc,first; Reading from left to right, this is the third event in the schema, its name is "test," it relates to glucose ingestion, and it records the time at which the item "gluc" FIRST takes on a value. Time is taken here to mean a combination of date and time. Events may be triggered by the "FIRST," "LAST,""MAX," and "MIN" values of its governing item. In addition, an event may be triggered at the first or last time the item takes on a particular value. When the clinician is satisfied with his description of the data he intends to collect, he compiles the schema (the system provides appropriate feedback about errors in the compilation). He then requests that disk space be allocated to accommodate his study. He assists the allocation by estimating the number of patients he expects to include in his study and an approximate number of occurrences of each panel type for the average patient. He is then ready to start entering patients and their data into the data base. ENTER The main function of the ENTER activity is to process data (entered interactively) in the light of the data screening specifications contained in the schema. The data that are accepted are not passed directly to the STUDY DATA file, but are recorded in an UPDATE file whose contents are merged with the STUDY DATA file at some convenient time. This buffering of the input data allows a simple structure for the STUDY DATA file, reduces the exposure of the system to computer malfunctions, and provides a means of reviewing the input data before it is actually recorded in the STUDY DATA file. Again, a CLINFO data base is patient- and time-oriented. In order to enter data, a "context" must be established for that data. That is, the data must Belong to a patient already in the PATIENT file. Have an associated date and time of day at which the data are assumed to have been sampled. After a context has been established (by interactive prompts and responses) the clinician may then enter values for items by either Typing the name of an item followed by its value or Typing the name of a panel, whereupon the system prompts for each of the items in that panel. The context stays in force for all data entered subsequently until the clinician desires to change it. The context may be changed at any time by typing "patient:," "date:," or "time:" followed by the corresponding value. As each value (including patient aijbreviations. dates. times, and panel and item names) is entered, that value is checked for reasonableness. The patient abbreviation must be in the PATIENT file; dates and times must have the correct format; panel and item names must exist in the schema; the value for an item must satisfy the criteria in the schema. Incorrect values are refused and re-prompted for by the system. An exception is the case of an out-of-range numeric value which may be forced upon the system by entering the initials of the data enterer. Incorrect but reasonable values that have been accepted by the system may be corrected by re-typing them (perhaps after reestablishing the correct context). ENTER has three additional functions: Adding patient abbreviations to the PATIENT file. Reviewing data in the UPDATE file. Copying and screening data from a worksheet into the UPDATE file.

4 66 National Computer Conference, 1977 As an alternative to item-by-item data entry, an entire twodimensional array (Le., a "worksheet") of data may be entered. A worksheet is a two-dimensional array of numeric entries extended to include 8-character labels for the rows and columns as well as a worksheet name, title, date of creation and date of last modification. A worksheet is stored by the system as a file with the same name as that of the worksheet. Worksheets provide the data organization required by the ANALYZEDISPLAY activities. The row and column labels can be used to reference patients, relative times, and items. These labels are used to direct the data entry process. Data entry via worksheets provides the facility for entering "derived" data (i.e., data produced as the result of the analysis of raw data) into the STUDY DATA file. It also provides another data entry route that may be more convenient in some circumstances. As indicated above, the clinician can interactively review the contents of the UPDATE file and edit it to the extent of deleting blocks of data. When he is satisfied that the data are correct, the clinician can request that the UPDATE file be merged with the data already in the STUDY DATA file. The newly entered data are organized automatically into panels, those panels are marked with the internal patient identifier, the panel number, the date and time of sample, the date and time of data entry, and the initials of the data enterer, and the results are merged by date and time of sample. The merge process checks for existing instances of panels with the same date and time as those being merged and for item values previously entered in those instances. The investigator is now in a position to retrieve his data from the STUDY :bat A file and to format it in a variety of ways: into worksheets, as a display at the terminal, or as a file to be passed to an externally generated applications p~ckage (Such a file is a "communication" file in CLINFO terminology.). RETRIEVE The data in the STUDY DATA file may be viewed as values associated with points in a three dimensional space. Figure 2 illustrates that space. The axes are labeled "PA TIENT", "TIME," and "ITEM" to reflect the parameters that uniquely identify a data value. The three dimensional space is sparsely populated with data points, especially if the TIME axis is taken to represent absolute dates and times. Moreover, not all data are collected about all patients for all of the expected times. It is the intent of the RETRIEVE activity to identify a planar slice of the data space and to abstract part of that slice into a two-dimensional form (i.e., a worksheet). Selecting a slice as illustrated in Figure 2 results in what was referred to above as a flowsheet for that patient. A slice parallel to the PATIENT-ITEM plane produces an array of items for a group of patients at a particular time. That time may be either an absolute date and time, or it can be a time relative to an event (e.g., two hours after glucose ingestion). Finally, a slice parallel to the PATIENT-TIME plane P A T I E N T P ITEM Figure 2-A three-dimensional representation of a time-oriented data file. I-I is a panel of items for patient P at time T results in a worksheet containing the time history of a particular item for a group of patients (again either absolute or relative time). The clinician constructs his retrieval request interactively under the control of the schema. In particular, coded items (e.g., sex may be either "male" or "female", but is encoded as either 0 or 1) are referred to in terms of the external form ("male," "female") while the system deals with them as numeric values (0 or 1). The values of items playa role if the clinician wishes to restrict the panels being retrieved by specifying conditions that the values must satisfy. When he completes the specification, the system surveys the appropriate parts of the STUDY DATA file and produces a worksheet with the rows and columns appropriately labeled. The retrievals discussed above are limited to numeric (or coded) items. However, textual panels may be retrieved and displayed at the terminal or passed in their entirety to a communication file. This facility allows the clinician to review his notes about a patient or to pass demographic data to a BASIC program that, for example, produces mailing lists. For those retrievals in which a list of patient abbreviations is appropriate (e.g., a slice parallel to the PATIENT ITEM plane), the investigator may provide that list by giving the name of a SUBSET. SUBSETS As mentioned above, subsets are files containing patient abbreviations and numeric keys. The files have the same structure as the PATIENT file.

5 Data Management for Ciinicai Research 67 Subsets are created in a variety of ways: By listing patient abbreviations. By the usual set operations (e.g., intersection and union) among existing subsets. By requiring that a patient's data in the STUDY DATA file satisfy a set of conditions. By requiring that a patient's data in a worksheet (e.g., the values in a row labeled with the patient's abbreviation) satisfy a set of conditions. The sets of conditions mentioned in the last two members of the above list are made up of lists of either conjunctions or disjunctions (but not both) of range restrictions on the values of items. A sample set of conditions is: If 30:s; age :s; 65 and if 120:s; systol :s; 140 and if sex = male The last line illustrates the use of a coded item which takes on one of a set of discrete values. In addition to the conditions placed on item values, the time at which a sample was taken can play a part in the selection. For example, the above conditions might be required to hold in the third hour after the ingestion of glucose. In any case, the usual result of a retrieval using either a subset or all of the PATIENT file is a worksheet. ANAL YZEDISPLA Y The CLINFO approach to data analysis is to abstract the desired data from the STUDY DATA file (which can cause very intensive accessing of the disk storage) into a worksheet which fits into the user's working space in main memory. The worksheet can then be manipulated efficiently, especially since its contents need not be re-abstracted from the STUDY DATA file each time a new question is asked of those contents. A sample worksheet has the format illustrated in Figure 3. WORKSHEET CLINICAL TITLE Clinical Characteristics of Diabetic Patients CREATED MODIFIED # OF ROWS 7 # OF COLS 4 ROWSCOLS 2 4 LABELS age sex %idl wt dur diab 1 case 1 27 male case 2 24 female case 3 32 male case 4 34 male case 5 21 male case 6 23 male 7 case 7 28 female 99 JO (Note:... indicates missing values) Figure 3-A sample worksheet A worksheet can hold approximately 2200 entries and its dimensions can vary within that restriction. In the case above, the row labels are patient abbreviations and the column labels are item names. These labels and the contents of the worksheet would ordinarily be supplied by the retrieval process. In addition, Figure 1 indicates an INPUT facility that allows the direct creation of worksheets, the labelling of their rows and columns, and the entry of data into those rows and columns. This facility allows the investigator to use CLINFO's analysis and display features independently of the STUDY DATA file. CLINFO maintains a "current" worksheet so that the same worksheet can be used in a variety of situations without the user respecifying it as the worksheet of interest. Most of the worksheet analysis and display functions apply to the current worksheet. The main worksheet manipulation facilities are: Select a worksheet as the current one by typing its name. If there is no worksheet by that name, create one as specified by the user. Display a worksheet at the terminal (see Figure 3). Label worksheet rows or columns. Enter data into a worksheet by row or by column or by individual cell. Discard (destroy) a worksheet. Sort a worksheet by rows or columns. Edit a worksheet by adding, deleting, or moving rows or columns. Copy a sub-array of a worksheet, with labels, into the same or another worksheet. Print a worksheet on the system printer. Display a list of all the worksheets in this study. Worksheets created by the retrieval process or by direct means can be used by the analysis facilities. In general, the analyses can be made to apply to sub-arrays within the body of a worksheet. The results of some analyses may be stored in worksheets to minimize transcription and to make those results available for further analysis. The CLINFO analysis facilities include: Descriptive Statistics (means, standard deviations, etc.). T Test. Chi Square Test. Linear Regression (simple and multiple). Analysis of Variance. Cross Tabs. Scatter Plots and Bar Charts. Histograms. Frequency Distributions. Normality Test. Non-parametric Paired Tests. In addition, special calculations may be performed on a worksheet, and the result of these calculations are stored in the worksheet. This facility replaces in part the need for special purpose computer programming. These calculations

6 68 National Computer Conference, 1977 are: Generate values in a row (or column) as the result of evaluating a single algebraic-like expression involving other rows (or columns) as variables. Generate truth values (0, 1) on the same basis. Perform special calculations such as cumulative sum, time differences, etc. SUMMARY The foregoing discussion does not describe the properties and facilities of the CLINFO prototype in their entirety. The intent is rather to outline those properties and facilities and to emphasize the idea of a personal, integrated, highly interactive system placed in the hands of personnel whose primary interest is to use the system as a tool. At least one CLINFO prototype has been in daily use by medical personnel since January of The acceptance of the system seems to be good and it is being used in productive ways. Moreover it is being used personally by senior medical staff, that is, the research staff for which it was designed. Our experience to date indicates that modern data base techniques (e.g. the SCHEMA), when expressed in the user's own terminology, are readily understood, accepted, and used by those personnel. The use of terms such as "PATIENT", "PANEL", and "WORKSHEET" and the time orientation of the STUDY DATA file are not accidental. They play an important role in making the computer scientist's techniques understandable by and useful to the clinical researcher. Another point of interest is the utility of two distinct data structures, the STUDY DATA file (and its associated files) and worksheets. The STUDY DATA file acts as a pool of data whose contents can be abstracted and arranged into a form more suitable for viewing and analyzing (i.e., a worksheet). In addition, worksheets serve to store data and to communicate them between steps in the analysis process. ACKNOWLEDGMENTS Although the authors accept the responsibility for the words in this paper, a much wider group is responsible for the content those words express. We would like to express our appreciation to our co-contractors Howard K. Thompson, Jr., M.D., at the Baylor College of Medicine, T. Graham Christopher, M.D., at the University of Washington, and Arthur W. Nunnery, M.D., at the University of Oklahoma, our project officer, William R. Baker, Jr., Ph.D., of the NIH, and to our colleague Thomas L. Lincoln, M.D., of the Rand Corporation. They have all contributed significantly to the design and continuing development of the CLINFO prototype. This research was supported by Contract No. NOI-RR from the Division of Research Resources, National Institutes of Health. REFERENCES I. Palley, N. A., and G. F. Groner, "Information Processing Needs and Practices of Clinical Investigators-Survey Results," AFIPS Conference Proceedings (1975), Vol. 44, AFIPS Press, Montvale, New Jersey, 1975, pp Groner, G. F., N. A. Palley and N. Z. Shapiro, "A Structural Characterization of Clinical Research Participants and Their Activities," R NIH, The Rand Corporation, January Groner, G. F., M. D. Hopwood, N. A. Palley, N. Z. Shapiro, and W. L. Sibley, "A Plan for the Development and Evaluation of a Data Management and Analysis System for Clinical Investigators," R-1541-NIH, The Rand Corporation, August Sibley, W. L., M. D. Hopwood, G. F. Groner, and N. A. Palley, "A Prototype Data Management and Analysis System for Clinical Investigators: An Initial Functional Description," R-1621-NIH, The Rand Corporation, August Data General Corporation, Extended BASIC User's Manual, publication , September Fries, James F., "Time-Oriented Patient Records and A Computer Databank," The Journal of the American Medical Association, Vol. 222, December 18, CODASYL Data Base Task Group (DBTG) Report, April Available from the Association for Computing Machinery.