Conversational file processing system FLXFL (FLeXible FiLe) for nonprogrammers

Conversational file processing system FLXFL (FLeXible FiLe) for nonprogrammers

COMPUTERS AND BIOMEDICAL RESEARCH Conversational IFLeXible 1% 335-349 (1979) File Processing System FiLe) for Nonprogrammers MIHOKO FLXFL OKA...

878KB Sizes 0 Downloads 102 Views

COMPUTERS

AND

BIOMEDICAL

RESEARCH

Conversational IFLeXible

1%

335-349 (1979)

File Processing System FiLe) for Nonprogrammers MIHOKO

FLXFL

OKADA*

Department of Physiology, School of Medicine, Toyama Medical and Pharmaceutical University, Sugitani, Toyama 930-01, Japan AND MASAHIKO

OKADA

Department of Neurophysiology, Brain Research Institute, Niigata University, Asahimachi, Niigata 951, Japan Received July 20. 1978 The system FLXFL (FLeXible FiLe) is a general purpose file processing system developed to support the function of conversational data handling for nonprogrammers. The operations provided, including the definition of (or modification of) the record format and statistical computations as well as data retrieval, are all carried out in a simple question-and-answer manner throughout the system. FLXFL allows even a user with no computer background to have the complete control over the computerized management and analyiis of the varied types of data. At present, FLXFL runs on minicomputer PDP 1l/40 with 32K words of memory. The system is designed for general purpose, but is particularly suitable for research works.

In recent years, Data Base Management Systems (DBMS) have played an increasingly important role in a great variety of application areas. The need for a computerized information system is felt strongly in clinical medicine, among other areas, as statistical analysis of the voluminous data is becoming more and more essentialfor the progressof medical science. At present, a number of DBMSs are available commercially (I), and someclinical institutions incorporate such DBMSs into their medical information systems(2, 3). Most of these commercial systems, however, require a large computer as their operational environment. In medical application, they are oriented toward the managementof hospital data, and the performed operations are usually stereotyped and routine. In clinical investigations, however, a large size general purpose DBMS is not necessarily best fit, becausethe usage of or the demandsfor the computer system *To whom reprint requests should be addressed. Present address: Brain Research Institute, Niigata University, Asahimachi, Niigata 95 1, Japan. 0010/4809/79/040335-15%02.cKY0 335 Copyright 0 1979 by Academic Press. Inc. All rights of reproduction in any form reserved. Printed in Great Britain

336

OKADA

AND

OKADA

differ greatly from those under clerical work environment. To be an ideal data processing system for research work, the system must satisfy conditions such as (a) it is economically feasible; (b) it is operable interactively, and operable without a programmer interface; (c) it is provided with functions to perform statistical computations and to generate statistical reports; (d) it is flexible enough to allow changes of various levels in the stored data, etc. Many information systems have been designed and implemented in an attempt to meet these requirements. Among them are the full-fledged DBMSs such as MUMPS (4), GEMICSHE (5), and TOD (6, 7) which provide a versatile capability with a language as an operational tool. There are also systems which permit the user to store and retrieve information by using simple commands or by just setting some parameters (8-1.3). MEDINFO (8) and RISS (9) are general purpose and render the statistical output just as obtainable. Others seem to be more limited, as they lack the function of statistical computation (10, II), or they are designed for a particular study (12, 23). Common to the existing systems is that the users are forced to learn a language pertinent to that system and/or to obtain some help from people at the computer center, when it comes to critical operations such as describing the data file structure. As is mentioned by some authors (8, 9, 11, 12), this is true even when the system is equipped with interface level for naive users, and the actual operation is often left to the computer center personnel. As the number of users grows, there arc corresponding increases in the workload of the center personnel which will soon impose a burden on them. It may be worth their while to teach the frequent users how to do the operations. But it is apparent that there are many users whose usage is very infrequent (perhaps one time only) and who naturally are not willing to spend much of their time in acquiring the operation technique. The problem is serious in a small institution where the budget is limited and a well-organized computer center is not affordable. In order to expedite his work, the researcher should be provid.ed with a system in which he can perform all the operations necessary without the aid 01 computer personnel. The system FLXFL (FLeXible FiLe) has been developed to implement a general purpose file processing system which provides the capability of describing, storing, and analyzing the data in conversational mode. Under FLXFL, data file creation (or modification) and statistical analysis as well as retrieval of data are all carried out in a simple question-and-answer manner, that is to say. even for a user with no computer background, every function of the system is prepared to his hand. The system is designed for general purpose, but is particularly suitable for research works. The detailed description of the system will be given in the following sections. GENERAL

DESCRIPTION

File Structure

The record format (which is defined by the user) is fixed for the entire records that belong to one particular file. A record consists of up to 128 data fields, and each field

CONVERSATIONAL

FLEXIBLE

FILE

331

SYSTEM

has one of the following three data types associated with it: (1) NUMERIC (a numeric value); (II) CHARACTER (a character string); (III) MULTIPLE CHOICE (a set of item numbers selected from a user-defined choice of items). As an example, let each record contain (1) the name, (2) age, (3) sex, (4) blood type, (5) height, (6) weight, and (7) past history (childhood illness) of a student in a college. In this case, a record consists of seven fields with the data types set as follows: (1) name-CHARACTER; (2) age; (5) height; (6) weight-NUMERIC; (3) sex; (4) blood type; (7) past history-MULTIPLE CHOICE. As for the fields of MULT. CHOICE, i.e., sex, blood type, and past history, let the choices of items be { 1. male, 2. female}, { 1. A, 2. B, 3. 0, 4. AB}, and { 1. pertussis, 2. measles, 3. field Record

1

TANAKA,

Record

2

SATO,

Record

n

h

1

KENICHI

2

34

5

7 I

20

1

3

173.4

62.5

2;

23

1

1

165.8

59.2

2;

18

2

4

158.7

50.4

2;

I

5;

I

MINORU

MICHIKO

I

I

1 61

c

3:

1

UZUKI,

I

51

r ; I

8 r

5;

I

6;

1 I 4

I

I

t

; I

I

I

r

1

I

I I

; I

; I

FIG. 1. Diagrammatic file structure of the STUDENT FILE. A record consists of seven fields, i.e., (1) name, (2) age, (3) sex, (4) blood type, (5) height, (6) weight. and (7) past history.

varicella, 4. mumps, 5. rubella, 6. tonsillitis}, respectively. For the past history, all of the listed six items may be chosen simultaneously. Figure 1 shows the diagrammatic structure of the student file. Operational Environment The program is written, for the most part, in FORTRAN IV with some subprograms in Assembly Language. FLXFL currently runs on minicomputer PDP 1 l/40 with 32K words of memory. Peripherals include two magnetic disk units with 2.2 megabyte for each (which are required) and one magnetic tape unit (which is optional). In the system file, which resides on the magnetic disk, FLXFL keeps the name, the number of records, and the record format of each user file registered in FLXFL. User files are stored either on magnetic disk, or on magnetic tape. If the latter is the case, the system copies the designated file onto disk as its very first task, and any succeeding work will be done on disk file only.

OKADA AND OKADA

338 Interaction with FLXFL

FLXFL displays a question on the CRT terminal at the points where the system needsinformation from the user. A prompting character and a short bell ring call the user’sattention. A question may be accompaniedby a numbered menu,and if such is the case, the user selectsand enters an appropriate item number depending on the operation that he desires. For an example, the display screen looks as follows immediately after the start of the execution: *SELECT AN OPERATION : 1. 2. 3. 4.

EDIT FILE STATISTICAL OPERATION DELETE FILE INFORMATION

The respectiveoperations invoked by each selection are: 1. Creation of a new file or modification of an existing file. 2. Statistical analysis or report generation. 3. Deletion of a file. 4. Information service on currently registeredfiles. After the user’sresponse,the system returns, *TYPE IN THE FILE NAME: and the user types in the name of the file. If file creation is the operation to follow, then the entered name will be defined as the name of the file to be created. Otherwise, the existing file named as such will be called up by the system. The questionswhich follow hereafter will differ depending upon the selectedoperation. If the user wishes to go back to the previous question, he may do so by responding to the current question with only the carriage return key. (There are a few exceptions to this where the default values are taken by the system if the user enters only the carriage return key.) More details about file editing and statistical operationswill be given now. FILE EDITING

OPERATION

Dejinition of the Record Format of a New File When creating a file in FLXFL, the user specifieswhat fields constitute the records of the file by answeringquestionssuch as, *SELECT AN OPERATION: 1. SET UP A NEW DATA FIELD 2. COPY FIELDS FROM AN EXISTING 3. TERMINATE FORMAT DEFINITION

FILE

CONVERSATIONAL

FLEXIBLE

FILE

339

SYSTEM

in which selection 1 enables one field to be defined newly, and 2 enables one or more fields to be defined consecutively at one time by copying from an existing file. Each time the definition of a field (or fields) is finished, the system repeats this question, until the user chooses to put an end to the format definition by entering number 3. Thus, in defining the record format, it is possible to intermix a new field with those fields copied from an existing file in any desired order. When defining a new field, the question which comes next is, *TYPE >

IN THE FIELD

NAME:

asking the user to assign a name (any sequence of up to six alphanumeric characters which does not begin with a digit) to this field. The user does not always need to give a name to a field, since the system assigns a unique field number to each field in order of definition. If the name is not given, any references to that field must be made only by the field number in later operations. For the next question, *SELECT THE FIELD TYPE: 1. NUMERIC 2. CHARACTER >

3. MULTIPLE

CHOICE

the user must select one item number. If NUMERIC is selected, the definition of this field is complete now. If CHARACTER is selected, the user will specify the maximum number of characters in the next question. Although there is a limit in the number of characters (56 characters per field), a longer character string can also be recorded by defining two or more CHARACTER fields consecutively. If MULT. CHOICE is selected, the user will specify the total number of items in the choice, and the maximum number of items that may be selected simultaneously as an entry. The user may optionally assign names to each item, and if assigned, the names will also be recorded in the system file as a code book for that field. When copying some fields from an existing file, the user answers the question, *SELECT THE TYPE OF COPY: 1. INCLUDE 2. EXCLUDE 3. ALL > The number 3 is selected when the user intends to copy all the fields. If either 1 or 2 is selected, the system returns, *WHICH >

FIELDS?

and the user specifies the fields to be included, or the fields to be excluded from the copy operation according as he selected the number 1 or 2 in the immediately preceding question. With the 1. INCLUDE option, the user may request to change some of the attributes of the specified fields at this point, by typing a slash at the end

340

OKADA

AND

OKADA

of each field ID for which attribute changes are desired. Allowable changes are: rename the field; increase the length of the CHARACTER field; increase the number of items of the MULT. CHOICE field; increase the maximum number of possible simultaneous selections of the MULT. CHOICE field; convert the MULT. CHOICE type field which has been defined to allow one and only one choice into the NUMERIC field. When being copied into the new file. the entries are converted into the relevant forms if necessary. The file from which fields are copied will never be affected. Each time a field (fields) is defined, all the attributes of the field (fields) are displayed in a tabular form for the user to make certain. The STUDENT FILE may have the record format defined as shown in Table I. Note that a copy file, whether a TABLE THE

Field number 1 2 3 4 5 6 1

Field name NAME AGE SEX BTYPE HEIGHT WEIGHT HISTRY

RECORD

Field type CHARACTER NUMERIC MULT. CHOICE MULT. CHOICE NUMERIC NUMERIC MULT. CHOICE

FORMAT

I

OF THE STUDENT

Field lengtha 10 3 1 I 3 3 6

FILE

# Items in a choice

___I-item name&

2 4

I. MALE 2. FEMALE 1.A 2.B 3.0 4.AB

6

I. PERT-US 3. VARICE 5. RUBELL

2. MEASLE 4. MUMPS 6. TONSIL

0 Indicates the number of words (16 bits/word) allocated to each field. NUMERIC field is always set to 3 by the system. CHARACTER field and MULT. CHOICE field are determined according to the maximum number of characters and the maximum number of possible simultaneous selections specified by the user respectively.

complete duplicate or only a part of the original file-can very easily be created. (To distinguish between “a part of the file” here mentioned and a SUBFILE which will be introduced later, let “a part of the file” which includes all of the records and a part of the fields of the original file be termed as a PARTIAL FILE.) Mod@cation of the Record Format of a Previously

Created File

Modification of the record format, such as deleting some fields, inserting new fields, changing the order of the fields, or changing some of the attributes of the fields (allowable changes are the same as listed for copy operation, e.g., the field name, the length of the CHARACTER field, etc.), is carried out in the manner similar to that described in the previous section. When the specification of how to modify the record

CONVERSATIONAL

FLEXIBLE

FILE

SYSTEM

format is complete, every record of the file is updated automatically new format.

341 according to the

Editing of a File Whose Record Format has been Defined During the editing by the field numbers “??w??” . . . . . . is displayed screen looks during

operation, the system displays the contents of a record labeled and the field names on the screen. If a field is undefined, in place of the field entry. Figure 2 gives an idea of how the the editing operation. Displayed at the top right corner, RECORD

1.

NAME

YAMADA,

2.

AGE

21

ID = 105

TOSHIY

3. SEX 4.

BTYPE

L

5.

HEIGHT

170.4

6.

WEIGHT

61.5

7.

HISTRY

1,2,5,6

__________________________i_____________-----------
MODE>

FIG. 2. The display

screen during

editing

operation.

RECORD ID, which is assigned by the system, indicates the sequential position of the record in the file. If a record has more fields than can be fit into the screen, the display can be scrolled both upward and downward by an appropriate key hit. Each time the user writes or modifies the contents of a field, the entry is checked for its validity, and if not valid, the system returns an error message and does not let the user go on to the next operation, ‘insisting on the entry being corrected. Valid data are: for NUMERIC, a number in the range +327 679 999.9999; for CHARACTER and MULT. CHOICE, the data that meet the predefined attributes of the field. An entry of a NUMERIC field is stored as three binary integers internally in three consecutive words (16 bits per word). This scheme is adopted as it is preferable to keep the representation as entered by the user, whereas character representation such as ASCII code is storage consuming. To facilitate the interactive editing, the user is provided with a set of commands,

342

OKADA AND OKADA

each consisting of a single character. The commands provide the following functions: (a) delete a record currently displayed on the screen; (b) insert a new record next to the one currently displayed: (c) search for a record and pull it up onto the screen; (d) display the contents of the nth record, or the record preceding or succeeding the record currently displayed; (e) delete a record from the file temporarily and insert it back to any position in the fiIe; (f) print out the specified field entries of the displayed record; and so forth. In (c), the user specifies the field name (or number) and the entry (or a part of the entry) of that field of the record to be viewed. For any changes in the record sequence, the system updates RECORD IDS accordingly.

STATISTICAL

OPERATIONS

Statistical operations can be directed to a group of records which meet the specified conditions by the introduction of SUBFILE definition. SUBFILE Dejinition

In FLXFL, the currently activated user file in its entirety is called the MASTER FILE, and a group of records of the MASTER FILE is called a SUBFILE. Operations concerned with SUBFILE management start with the question. *SELECT AN OPERATION: 1. DEFINE A SUBFILE 2. CLEAR SUBFILES 3. REGISTER A SUBFILE

IN FLXFL

Each operation will be described in what follows. DEFINE A SUBFILE. A SUBFILE is defined by one or more relational expressions which discriminate the members of a SUBFILE to be defined from all other records of the MASTER FILE. An expression consists of three elements, i.e., a field ID, a relational operator, and a constant value, which are specified one by one in a conversational mode. An expression takes one of the following two forms: [FORM. 11 for NUMERIC or CHARACTER type field field ID

1. IS GREATER THAN 2. IS EQUAL TO value 3. IS LESS THAN 1 r

where field ID: field identification specified by a name or number. ) : a list of options among which a single choice must be made. { value : a numeric value or a character string.

CONVERSATIONAL

[FORM.

21 for MULT.

1. 2. field ID 3. 4. 1 5.

FLEXIBLE

CHOICE

CONTAIN CONTAIN IS EQUAL CONTAIN CONTAIN

FILE

343

SYSTEM

type field

ALL OF SOME OF TO NO OTHER NONE OF

Ii,, . . ., inI THAN I

field ID : same as in FORM. 1. { 1 : same as in FORM. 1. Here, each option represents the relation between the set of item numbers recorded in field ID, and [i,, . . ., i,]. [i 1,. . ., inI: a set of item numbers which is valid as an entry of field ID. For MULT. CHOICE type field, condition is expressed by regarding the entry of the field as a set of item numbers and comparing it with the specified set of item numbers. Any relation that may exist between the two sets is describable by the use of one of the five options listed above. The options l-5 may be used, for example, in the following way: Select every student from STUDENT FILE: 1. who has both pertussis and mumps 2. who has at least pertussis or mumps 3. who has both pertussis and mumps and does not have any other 4. who does not have any other than pertussis and mumps 5. who has neither pertussis nor mumps as his past history. To show how to define a SUBFILE, let us select a group of students who satisfy the conditions (a) include histories of pertussis and/or mumps, (b) aged between 19 and 2 1, (c) male. The following is the first half of the interaction where user’s responses are underlined. *FIELD >7-

ID:

*SELECT THE RELATION: 1. CONTAIN ALL OF 2. CONTAIN SOME OF 3. IS EQUAL TO 4. CONTAIN NO OTHER THAN 5. CONTAIN NONE OF >2 *TYPE IN THE ITEM NUMBERS > 1,4 -

TO BE COMPARED:

344

OKADA

*FIELD

AND

OKADA

ID:

>2 *SELECT THE RELATION: 1. IS GREATER THAN 2. IS EQUAL TO 3. IS LESS THAN >! *TYPE IN THE VALUE TO BE COMPARED: >g After some more question-and-answer’s, the system forms up and displays the following set of expressions, indicating a new SUBFILE has been defined; 7. 2. 2. 3.

HISTRY AGE AGE SEX

INCLUDE SOME OF IS GREATER THAN IS LESS THAN IS EQUAL TO

[I, 41 18 22 Ill

At maximum, 10 SUBFILEs may coexist simultaneously with each SUBFILE defined by up to 16 expressions. To each SUBFILE, the system assigns the names SUBFILE A, SUBFILE B.. . ., and SUBFILE J in order of definition. CLEAR SUBFILES. When the defined SUBFILEs are no longer necessary, they may be cleared and a new set of SUBFILEs may be defined again. The system assigns the names starting from SUBFILE A. REGISTER A SUBFILE IN FLXFL. SUBFILEs do not actually occupy the storage space and a record fetch is made only from the MASTER FILE. That is. SUBFILEs are virtual files and they are pertinent only to that particular run where they are defined. If the user needs to work on one particular SUBFILE many times, possibly at different runs, then he has a choice to have a SUBFILE altered to be a physically existent file and registered in FLXFL with a unique file name. This facility is combined with that of PARTIAL FILE to allow the user to create a compact data file, extracting only necessary fields and records from the original file. Registered files will remain intact until the explicit edit or delete operation takes place. (N.B., differently from a SUBFILE, a PARTIAL FILE becomes a registered file, i.e., a file qualified to be a MASTER FILE at the time it is created.) Statistical Operation Statistical computations. Statistical computations can be performed on a SUBFILE (or the MASTER FILE) for NUMERIC field or MULT. CHOICE field which accepts only one selection. The system accepts the latter as numeric data since MULT. CHOICE field may contain such item numbers that are qualified to be involved in statistical computations, for example, item numbers representing the

CONVERSATIONAL

FLEXIBLE

PILE SYSTEM

345

result of urinalysis { 1. - 2. + 3. + . . . } for protein, 11.0 2. l-10 3. 1l-50 e . . ) for red cell count, etc., and it is assumed that such MULT. CHOICE type field is defined to accept one and only one selection as an entry. Obtainable statistical computations include: (a) computation of mean and standard deviation; (b) test for goodness of fit with normal (or logarithmic normal) distribution, and histogram output; (c) test of equality of two means; (d) test of equality of two variances; (e) regression analysis, and graphic representation of the regression line (or curve) and the data. Cross-tabulafion. For the analysis of relationships among the fields, the user may produce a contingency table which is a joint frequency distribution of the records in a SUBFILE or in the MASTER FILE. As a classificatory field, the user may select any NUMERIC or MULT. CHOICE type field. Row percentages and column percentages are also printed out together with raw frequencies. When the number of categories of the column field is too many to fit onto a single line, a table will be segmented by column and printed out on successive pages until it has been completely printed. With the aid of SUBFILE feature, a joint frequency distribution of the records according to three classificatory fields, i.e., a three-dimensional contingency table may also be produced. The procedure for producing the contingency table and the sample output will be shown in Example 2 of “APPLICATIONS.” Record listing. For the record listing of a SUBFILE (or MASTER FILE), the fields to be output may be specified in any combination and in any order. The user selects one of the two output formats, that is, 1. one record on a single line, 2. one field on a single line. In the first format, the system assigns an appropriate number of columns to each field. For CHARACTER field, the user may set the number of characters to appear. When the total number of columns necessary for one record exceeds 132, the system returns the message and the user respecifies the fields to be listed. The column header (field number and field name) will be placed at the top line. In the second format, each field entry will be listed on a separate line with the field identification at the left. APPLICATIONS

FLXFL has been used in several studies at the Brain Research Institute, Niigata University. Described below are the examples of the usage of FLXFL in such studies. Example I. In the study of quantitative evaluation of motor function, the data file is being processed using FLXFL. A record in the data file consists of 56 fields, i.e., the name, sex, age, type of the subject (either normal, or the severity of disease), and 52 numeric values which are the parameters representing the test performance. The data file contains 909 records at present (5 16 normal people aged between 3 and 87, and 393 patients with mercury poisoning). The collected data have been entered from a CRT terminal in an interactive mode. The study still continues to collect and

346

OKADA

AND

OKADA

input more data. FLXFL has been operated so far to examine (a) among the controls, correlation between the parameters, changes in performance with advancing age, differences in performance by sex, goodness of fit with normal distribution of several parameters, variations in performance within a day; (b) between the group of controls and the groups of patients, any significant differences in test performance; (c) among the patients, any significant differences by the severity of disease; and so on. Example 2. For the study of the development of the Emergency Medical Care System in Niigata Prefecture, the survey over the current situation about emergency care was carried out; the first time from 18 to 24 of July 1977 and the second time from 20 to 26 of February 1978. In the survey, questionnaires were distributed to 1642 clinical institutions, and one collection form was filled out for each patient who visited the institutions out of office hours during that period. The form consists of 19 questions, including (1) the patient ID, (2) the time of arrival, (3) means of transportation, (4) signs and symptoms, (5) causes, (6) treatment, etc. The collection forms were filled out by doctors. Except for identifications, a set of answers was printed on the form for each question, and an applicable answer (or answers) was encircled. A total of 12,788 forms in the first and 7581 forms in the second survey were returned and were transferred to magnetic tape in EBCDIC code at the CODE# RANGE 0.0

1

0'55

2

3

4

5 TOTAL

'E

'72;

0.:

232

24:2

45.0

45.2

0.0

48.6 7.0

100.0 44.'

20.0

32 1.9 51.6

352 20.6 29.2

'034 60.5 18.6

189 11.' '00.0

'03 6.0 21.6

'710 '00.0 22.8

40.0

0':

1%

:l2

17:7

18.9

20.5

0.0

TOTAL

74

100.0 '9.4 355 100.0 '1.4

79 9.2 6.6

713 83.4 '2.8

0 0.0 0.0

6il 7.0 '2.6

0.6 1 1.6

2.3 4 0.3

92.7 '64 2.9

0.0 0 0.0

4.: 1.7

3

62 0.8 '00.0

1206 '6.' '00.0

5569 74.2 100.0

189 2.5 '00.0

'453

15.5 5.1

0.4 4.8

60.0

80.0

0

3308

477 6.4 100.0

lo;'; 2:4 7503 '00.0 100.0

FIG. 3. The contingency table of age by treatment as a sample output of cross-tabulation. The absolute frequency, the row percentage, and the column percentage are printed out in each cell. Each column represents (1) operation in a surgery, (2) surgical treatment other than 1. (3) internal treatment. (4) delivery, and (5) directions only. The rows represent the age of the patients as O-19, 20-39.40-59, 60-79,and 8&, respectively.

CONVERSATIONAL

FLEXIBLE

FILE

SYSTEM

341

information service center which is run as a business. By the conversion program, EBCDIC coded data were then decoded into internal representation of FLXFL and stored on magnetic disk. Contingency tables with various classificatory fields, such as date by time, cause by sex, symptoms and signs by cause, etc., were reported through cross-tabulation feature. The table of age by treatment is shown in Fig. 3 as sample output. The following is the procedure to produce the table, where user’s responses are underlined. *TYPE

IN THE CLASSIFICATORY

>m MAXIMUM MINIMUM MEAN STDV

= = = =

FIELD

FOR ROW:

95.00 0.00 28.97 23.92

*SPECIFY THE LIMITS FROM: TO: BY: 20 -

AND

INCREMENT:

*TYPE IN THE CLASSIFICATORY > TREAT

FIELD

FOR COLUMN:

*ITEM NUMBERS WILL BE: 1. CONSECUTIVE 2. NON-CONSECUTIVE >! *SPECIFY THE LIMITS FROM: TO: --TYPE RETURN IF READY When NUMERIC field is specified as classificatory field, the maximum, minimum, mean, and standard deviation are computed and displayed, and then the lower limit, upper limit, and increment for classification are asked of the user. (The default is the minimum, maximum, and the increment that produces 10 categories, respectively.) When MULT. CHOICE field is specified, the system asks whether tabulation is desired for consecutive or for nonconsecutive item numbers. If the former is the case, the user then specifies the lower and upper limit. (The default is 1 and the number of items in that field, respectively.) If the latter is the case, the system tells the user to type in each item number. (There is no default action.)

348

OKADA AND OKADA

Some outputed results were directed to a storage device for further analysis by the application programs. Since the total number of records was fairly large, several PARTIAL FILES and SUBFILEs were created and registered in FLXFL to shorten the processing time. SUBFILEs and PARTIAL F1LE.s were also accessed directly by the application programs, which was accomplished easily thanks to the simple file structure of FLXFL. DISCUSSION

AND CONCLUSION

The developed file processing system FLXFL and its applications were described in this paper. The self-explanatory manner of operation including record format definition and record format modification enables a user with no computer background to create a data file and analyze a large quantity of data completely by himself. A user does not have to learn a cumbersome language, nor does he have to become well acquainted with the computer system when he uses the system FLXFL. He defines the record format of his data file by responding to the questions from the system. The data entry is carried out through CRT terminal interactively under the editing facility. (EBCDIC or ASCII coded data on some storage media may also be processed in FLXFL by the usage of the conversion program supplied.) Statistical operations, which also proceed with the system’s questions and the user’s responses. may be conducted on a group of records with specified characteristics by the use of SUBFILE feature. SUBFILE is defined by relational expressions which specify the selection criteria. For MULT. CHOICE field, an entry is regarded as a set of item numbers and is compared with the user specified set of item numbers. For example. the condition “the records which do not contain item 3, 18, and 20 in SYMPTM field” is represented as SYMPTM CONTAIN NONE OF 13, 18, 201. Since it is often the case that the number of items of MULT. CHOICE field is more than 10, 20, or 30, and the specification need be made for the combination of some item numbers, the condition on MULT. CHOICE field turned out to be appropriately described in terms of the relation between the sets of item numbers. No requests so far have been unsatisfied under the way of specification adopted in FLXFL. If the user later wishes to add or delete one or more fields to his data file, he may do so just as easily as described above. FLXFL is currently being implemented on the PDP 1 l/34 with 64K words 01 memory, which has only recently been installed. It entails some modifications and expansions of FLXFL. That FLXFL is written in FORTRAN IV, one of the commonest high level programming languages in the world, makes the system expansion easy, and makes the system readily transferable to other computer systems as well. It is nearly one and a half years since FLXFL has been implemented, and the number of users or the studies of current users is increasing. Retaining the principle that the system is totally operable by a casual user, the system will be evolved to be a more sophisticated general purpose file processing system.

CONVERSATIONAL

FLEXIBLE

FILE

349

SYSTEM

ACKNOWLEDGMENT

The authors would like to thank Professor Maruyama of the Department Research Institute, Niigata University for his helpful advice.

of Neurophysiology,

Brain

REFERENCES 1. CODASY L Systems Committee. “Feature Analysis of Generalized Data Base Management Systems.” ACM, May 1971. 2. BAKER, G. J., GARDINER, S. W., AND GRADWELL, D. J. L. A database for four hospitals in the United Kingdom. Proc. MEDINFO 74,323 (1974). 3. GIBBONS, C. H. AND FLEISCHLI, G. Use of a general purpose database manager for automation of ambulatory medical care records: A feasibility study. Proc. MEDINFO 74,335 (1974). 4. GREENES, R. A., PAPPALARDO, A. N., MARBLE, C. W., AND BARNETT, G. 0. Design and implementation of a clinical data management system. Comput. Biomed. Res. 2,469 (1969). 5. HAMMOND, W. E., BRANTLEY, B. A., FEAGIN, S. J., LLOYD, S. C., STEAD, W. W., AND WALTER, E. L. GEMISCH-A minicomputer information support system. Proc. IEEE 61,1575 (1973). 6. FRIES, J. F. Time-oriented patient records and a computer databank. J. Amer. Med. Assoc. 222, 1536 (1972). 7. WIEDERHOLD, G. AND FRIES, J. F. Structured organization of clinical data bases. AFIPS 44,479 (1975). 8. JOHNSON, D. C. AND BARNETT, G. 0. MEDINFO-A medical information system. Compur. Programs Biomed. 7,191 (1977). 9. MCLEOD, D. AND MELDMAN, M. RISS-A generalized minicomputer relational data base management system. AFZPS 44,397 (1975). IO. KARPINSKI, R. H. S. AND BLEICH, H. L. MISAR: A miniature information storage and retrieval system. Comput. Biomed. Res. 4,655 (1971). 1 I. BAKER, R. L. An adaptable interactive system for medical and research data management. Meth. Inform. Med. 13,209 (1974). 12. HORTON, C. L., OKIES, J. E., MESSMER, B. J., HALLMAN, G. L., AND COOLEY, D. A. Computer application in clinical medicine-CARE: A practical system for processing clinical data. Comput. Biomed. Res. 6,286 (1973). 13. BUCKLEY, J. D., GLEDHILL, V. X., MATHEWS, J. D., AND MACKAY, I. R. SEARCH-A language for retrieval and statistical analysis of medical records. Comput. Biomed. Res. 6,235 (1973).