DATABASE TECHNOLOGY IN HEALTHCARE

Gio Wiederhold

Stanford University

Computer Science Department

July 15, 1980

CONTENTS

A. Databases and Their Objectives 3

B. Introduction to Data Bases. 4

1. Components of databases 4

2. File management systems versus database management systems 6

3. Related Systems 7

C. Scientific Basis for Database Technology 8

1. The schema 8

2. The data model 10

3. Types of data models 11

D. Database Operation 1

1. Entering data into the database 12

2. Data storage 14

3. Data organization for retrieval 15

4. Data presentation 17

5. Database administration 18

Acknowledgements 18

Glossary and Index

References 19

DATABASE TECHNOLOGY IN HEALTHCARE

In this paper we will introduce the concepts of database technology in a

way that will make it easy to relate the issues of the technology to

problems in health care. After the objectives of the database approach

have been defined, the major components of

databases and their function will be discussed. The remainder of this

paper presents the scientific and the operational issues associated

with database technology in healthcare. The importance and growth of

these systems has been documented [Lindbe79]. Rather than providing a

survey of the field, this exposition is intended to link general concepts

to the practices observed by us [Henley75] and others [Palley75,

Zimm&R78].

A. Databases and Their Objectives

A database is a collection of related data, organized so that

useful information may be extracted. The effectiveness of databases

derives from the fact that much of the information relevant to a variety

of organizational purposes may be obtained from one single, comprehensive

database. In health care the same database may be used by medical

personnel for patient care recording, for surveillance of patient status,

and for treatment advice; it may be used by researchers in assessing the

effectiveness of drugs and clinical procedures; and it can be used by

administrative personnel in cost accounting and by management for the

planning of service facilities.

The fact that data are shared promotes consistency of information for

decision-making and reduces duplicate data collection. A major benefit

of databases in health care is due to the application of the information

to the management of services and the allocation of resources needed for

those services. Communication through the shared information among

health care providers, and the validation of medical care hypotheses from

observations on patients are also a significant aspect of sharing data

and can be the primary objective in certain health care settings.

The contents and the description of a database has to be carefully managed

in order to provide for this wide range of services, so that some degree

of formal data management is implied when we speak of databases. The

formalization, and the large data quantity implied in effective database

operations make computerization of the database function essential; in fact,

much of the incentive for early [Bush45] and current computing technology

[Barsam79] is due to the demands made by information processing needs.

In order to process data we need data and processing tools. The notion

of a database hence encompasses the stored data themselves, the hardware

used to store the data, and the software used to manipulate the data. When

the database is used for multiple purposes we find also an administration

which controls and assigns the resources needed to maintain the data

collection and permit the generation of information.

We will now define the technical scope of databases, and begin with a more

precise definition of the terms.

Wiederhold: Database Technology in Healthcare Page 4

B. Introduction to Data Bases.

Within the scope of databases are a number of concepts, that are

easily confused with each other. The objective of a database is to provide

information, but not all systems that provide information are databases.

We will first define the term 'database', and then some terms that describe

aspects of database technology. As we refine the descriptions more terms

will appear and be defined. For further clarification we will in Section

B.3 present types of systems which are related or similar to databases, but

are not considerd databases within this review.

A database is a collection of related data,

with facilities that process these data to

yield information.

A database system facilitates the collection, organization, storage,

and processing of data. The processing of data from many sources can

provide information that would not have been available before the data

were combined into a database. Hence, a collection of data is not by

itself a database, a system that supports data storage is not neccessarily

a database system, and not all the information provided by computer

systems is produced from databases.

B.1 Components of Databases

We stated earlier that a database is composed of data, of programs or

software to enter and

manipulate the data, and of computers or hardware. Both data and software

are stored within the computers which support the database.

While multiple, interconneccted computers may be used to support a single

database, today such systems are few, and we will define the software

systems in terms of a single, central computer. The users may of course be

remote, and use terminals connected by telephone lines to access the

database. The internal organization of the stored data, the hardware, and

the software may not be obvious to the users. For many users that innocence

may be desirable, but when decisions about databases have to be made

a good understanding of their components and the interactions among them is

needed.

We will now describe some of the components that are

part of database software. Databases require the availability of

well written prrogamming tools, or software subsystems. Some of these tools,

that are used to support databases can also be used independently,

and hence they are at times confused with the database system itself.

Important subsystems are:

a) File Storage Systems : software to allocate and manage space

for data kept on large computer storage devices, such as disks or

tapes.

b) File Access Methods : software to rapidly access and update

data stored on those devices.

c) Data Description Languages : languages that are used to describe

data so that users and machines can refer to data elements and

aggregations of similar data elements conveniently and unambigously.

d) Data Manipulation Languages : languages to allow the user to

write programs that retrieve and process data from the database.

In a databased system these subsystems have to be well integrated, so that

the entire data manipulation is carried out in response to simple

commands that refer to the terms defined in the data descriptions. Storage

is allocated and rearranged as new data enter the database, and access

to old and new data is provided as needed for manipulation. To provide the

reliability that is needed to satisfy demands by users who can not be

bothered by the technical complexities of computer systems, redundant

backup data is stored separatly and appropriatly identified whenever

database is changed. Optional software components of a database may

provide on-line, conversational access to the database, help with the

formulation of statistical queries, and provide printed reports on a regular

schedule.

Wiederhold: Database Technology in Healthcare Page 5

B.2 File Management Systems versus Database Management Systems

Of primary concern to a database effort is the reliable operation of the

devices used to store the data over long periods of time. The programming

systems which provide such services, typically inclusive of the tools listed

in a) and b) above, are called file management systems.

When data are shared, then access conflicts can occur due to concurrent

updates of data, use of data while it being changed, and attempts to read

confidential data without having the proper access privilege.

To resolve access conflicts the system must be able to control database

requests made by the individual users, and recognize the specific

data units which these users will be referencing. Control

over the data and its use can only be achieved if all users access the

database always via programs that will protect the reliability, privacy, and

integrity of the database. We achieve reliability when data are not lost due

to hardware and software errors. We protect privacy when we guarantee that

only authorized access will occur. We define integrity as freedom from

errors that could be introduced by simultaneous use of the database by users

that may update its contents. A database management system should

provide all the required database support programs, including management of

files, scheduling of user programs, database manipulation, and recovery from

errors. To make the system easy to use all of these functions should be

well integrated.

Not every database is managed by a database management system (DBMS).

Database support can also be provided by programs that use one of the

available file management systems (FMS). When an FMS is used programs in

some computer language will have to be written to augment the FMS with the

functions that carry out the query understanding, the dataprocessing,

the output presentation , and any protection tasks that are desired.

The contents of the database can be identical for a system using

a generalized DBMS product or one using programs and an FMS.

A locally developed collection of programs rarely has the all of

the protective features that are desirable when multiple users interact with

the database from terminals. The manner in which users gain access

to shared data will always depend on the choice of the DBMS or

the file management system. For instance, a file system does not

provide automatic scheduling of user requested activities. Without a

DBMS the users will have to schedule their own activities in such a

way that conflicting data entry or update is avoided. Some

file systems will simply disallow such access, in other systems such usage

could lead to inconsistent data. If data entry activities are organized so

that such conflicts are avoided then there is less need for the complexity

of a DBMS. A very popular file management system in medicine is MUMPS,

developed at Massachusetts General Hospital to support clinical use of

relatively small computer systems [Bowie77].

<<< How does MUMPS handle sim. access >>>

Both file management systems (FMS) and database management systems DBMS)

are available from commercial vendors for most computers. Some DBMS's will

make use

of an existing FMS, others will perform all but the most primitive file

access functions themselves. A DBMS interacts closely with the user

of the database, but the specification of the interaction varies greatly.

We find that several distinct types of DBMSs have been

developed. Some systems stress user-oriented data description and operation,

and others stress a high performance for large databases, and expect that a

computer professional will design the database structure, and provide the

users with the functions they need.

DBMS's also differ in terms of the comprehensiveness of software services,

and some commercial DBMS systems are large, have more functions than any

single user would need, and hence are often costly to obtain and to maintain.

Most manufacturers provide an FMS at no additional direct cost, but

acquisition of a DBMS is rarely free.

The choice of a particular type of database management system will influence

the structure of the future database. Not every type of DBMS will be

available on a given computer, but for most medium to large computers there

is some choice. Simplicity versus generality and cost are often a trade-off.

Even so-called generalized database management systems impose, to a great

extent, the view of the designer or sponsor of such a DBMS. Many of the

major systems now being marketed were designed to solve the complexities

of specific applications. We find today some DBMS's that excel in inventory

management, some do excellent retrieval of bibliographic citations, others

Wiederhold: Database Technology in Healthcare Page 6

have a strong bias towards statistical processing. Even within the medical

area different DBMS's will emphasize one of the many objectives that are

found within the range from patient care to medical research. The following

table will list some database systems found in medicine with an indication

of their objective. We distinguish in this table: general ambulatory patient

care, clinical or speciality outpatient care, hospital inpatient care, or

patient management and record keeping in these areas. Clinical studies refers

to research data collection on defined populations. Guidance refers to the

giving of medical advice during the inquiry process. Details of these types

of application are given in [Wieder80]. The types of database organizations

can be categorized as tabular, relational, hierarchial, or network. These

terms will be defined in section B.4.

-------------------------------------------------------------------------

| Name : Application : Type : FMS used : Computers : Reference|

-------------------------------------------------------------------------

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | Med.Guidance| | | V77-600 | |

| | | | | | |

| | | | | | |

-------------------------------------------------------------------------

Database and File Management Systems Found in Health Care

Wiederhold: Database Technology in Healthcare Page 7

B.3 Related Systems

Data are collected and stored into a database with the expectation that at a

later time the data can be analyzed, conclusions can be drawn, and that the

information obtained can be used to influence future actions. Information

is generated from data through processing, and should increase the knowledge

of the receiver of this information. This person then should have the means

to act upon the information, perhaps to the benefit of a larger community.

|| The production of information is the central objective of a database. ||

There are other automated information processing systems which are not

considerd databases, although they may share some of the technology. In the

remainder of this section two categories of such related systems will be

presented.

INFORMATION SYSTEMS store information - often the output of earlier data

analyses - for rapid selective retrieval [Beckle77]. A well known example

is the MEDLARS system [Leiter77,Doszko80], a service of the National Library

of Medicine, which provides access to papers published in the medical

literature. The task of such an information system is the selection and

retrieval of information, but not the generation of information [Lucas78].

Index Medicus for instance only provides the references, and depends on the

user's own library [Kunz79]. Even maintenance of personal reference files

can be effectively automated [Reiche68]. The benefits are due to the speed

and improved coverage with which the documents can be found.

The boundary between information systems and database systems is not at all

absolute. One can perhaps even speak of a spectrum of system types. When

the queries are simple the two system types are in fact indistinguishable.

Retrieval of the age of a patient, for instance, can be carried out with

equal facility on either type of system. But when another observation, say

cholesterol level, has to be compared with the average cholesterol level for

all other patients of the same age, then a computation to generate this

information is needed, and a system which is able to do this is placed more

on the database side of the spectrum.

DECISION SUPPORT SYSTEMS assist with the manipulation of data supplied by

the user [Davis78]. The help may be principally algorithmic - perhaps

assuring that Bayes' rule is properly applied. More specialized systems

embody medical knowledge [Johnso79], for instance in acid-base balance

assessment [Bleich72] and anti-microbial therapy [Yu79]. While these systems

could be coupled to databases, so that they become also knowledgeable about

a specific patient, today they are typically separate [Gabriel78].

The knowledge embodied in databases could provide an objective basis for

knowledge-oriented systems [Blum78]. Work in decision making for health

care cost control has indicated a need for database facilities in these

applications [BrookW76].

The HELP system, at the LDS hospital in Salt Lake City, does keep a separate

file of clinical decision criteria and applies them to the patient database

as it is updated. The system then advises the physician to consider certain

actions or further diagnostic tests [Warner78]. As medical databases become

more reliable and comprehensive we can envisage increased exploitation of the

information contained in them by systems which embody medical knowledge.

Wiederhold: Database Technology in Healthcare Page 8

I.C The Scientific Basis for Database Technology

The emergence of databases is not so much due to particular inventions, but

is a logical step in the natural development of computing technology. The

evolution of computational power began with the achievement of adequate

reliability of complex electronic devices. The mean-time-to-failure reached

several hours for powerful computers about 1955. At that point the concerns

moved to the development of programming languages, so that programs of

reasonable power could be written. These programs had the capacity to

process large quantities of data, and in the early sixties magnetic tape and

disk devices were developed to make the data available. Operating systems to

allocate storage and processing power to the programs became the next

challenge. By the late sixties these systems had matured so that multi-user

operation became the norm. As these foundations were laid it became feasible

to keep data available on-line, i.e., directly accessible by the computer

system without manual intervention, like fetching and mounting computer

tapes. Now a variety of application programs can use those data as needed.

In current systems valuable data can be kept on-line over long periods

without fear of loss or damage to the database.

C.1 The Schema

The one technical concept which is central to database management systems

is the schema. A schema is a formalized description of the data that are

contained in the database, available to the programs that wish to use the

data. All data kept in such a database is identified with a name, say DOB

for date-of-birth. With a schema it is sufficient for application programs

to specify the name of the data they wish to retrieve. A command may state:

date-of-birth = GET ( current-patient, DOB )

The database system will use the schema to match the name of the requested

data. When a corresponding entry in the schema is found, the database system

can use information associated with the entry to determine where the

requested data have been stored, locate the data values, and retrieve them

into the application program area ( date-of-birth ) for analysis or display

During this process it is possible to check that the requestor is authorized

to access the data. The DBMS may also have to change the data into a

representation that the program can handle [Feins70A]. Similar processes

are carried out by the DBMS when old data are to be updated and when new

data are to be added to the database.

The schema is established before any data can be placed into the database

and embodies all the decisions that have been made about the contents and

the structure of the database. Each individual type of data element will

receive a reference name. The data to be kept under this name may be further

defined. The most important specification is whether the data are numeric,

a character string, or a code. Codes then need tables or programs for their

definition. Other schema entries give the format and length of the data

element, and perhaps the range of acceptable values. For observations of

body temperature the five descriptors might be:

TEMP, temperature in degrees C, numeric, XX.X, 36.0 to 44.0.

The data elements so described will have to fit into a structure; a value by

itself, say TEMP = 41.9, is of course meaningless. This data element belongs

Wiederhold: Database Technology in Healthcare Page 9

in an observation record, and the observation record must contain other

data elements, namely a patient identification (ID), a date, and a time.

These data elements, which are used to identify the entity described in the

record, constitute the ruling part; without these there is insufficient

information present to make the TEMPerature observation useful. The ruling

part data types { ID, DATE, TIME } will also appear in the schema.

The observation record may contain, in addition to TEMP, other dependent

data elements as: the pulse rate, the blood pressure, and the name of the

observer. The entire observation record can then be described as a list of

seven attributes, as follows:

Observations: ID, DATE, TIME > TEMP, PULSE, BP, OBSERVER;

The first three attributes form the ruling part, the other four are the

dependent part; we seperate the two parts with a > symbol. Each attribute

has associated with it a schema entry with the five descriptors shown for

the TEMP entry above. There will be other kinds of records in the database:

a patient demographic data record will exist in most databases we consider.

Here the only data element in the ruling part will be the ID field. This

record may be in part as below:

Patients: ID > PATIENT-NAME, ADDRESS, DOB, SEX, ... ;

Matching of the ID fields establishes the relationship between patient

demographic data records and the observation records. The known relationships

between record types should also be described in the schema, so that the use

of the schema is simplified [Manach75, ChangO76].

We use three types of connections to describe relationships between records

[Wieder79], their use is also sketched in the figure on the next page.

a) The Identity Connection - used where the ruling parts are similar,

but different groupings are described;

for instance both hospital patients and diabetes clinic patients

are patients with patient ID's, but have different dependent

data stored in their files.

b) The Reference Connection - used where there is a common descriptive

record referred to by multiple data records;

for instance the Physician-seen is a record type referred to

from the patients clinic visit records.

c) The Ownership Connection - used where there are many subsidiary records

of some type which depend on a higher level record;

multiple ownership connections define an association;

for instance the multiple clinic visits of a specific patient,

each with data on his temperature, blood pressure, etc. form

an owned nest of the patient record.

An association occurs in the figure where a physician has

admitting privileges at one or more hospitals, and each hospital

grants admitting privileges to a number of physicians. The

admitting-privileges file has as ruling part both the physician's

ID and the hospital name, a dependent data element might be the

date the privilege was granted.

Associated with the connection types may be rules for the maintenance of

Wiederhold: Database Technology in Healthcare Page 10

database integrity. Such rules can inform the database system that certain

update operations are not permissible, since they would make the database

inconsistent. For example we would not want to add a clinic patient without

adding a corresponding record to the general patient file, if the patient

did not yet exist there. Similarily deletion of a physicians record from

the database implies deletion of the associated admitting privileges.

C.2 The Data Model

In order to provide guidance for the creator of the schema it is important

to have design tools. A large database can contain many types of records,

and even more relationships between the record types. These have to be

understood and used by a variety of people: the programmers who devise data

entry and analysis programs, the researchers who wish to explore the database

in order to formulate or verify new hypotheses, and the planners who wish to

use the data as basis for modelling so that they can predict the response

to future actions. A variety of models exist [ACM76]; some models are

abstractions of the facilities that certain types of database management

systems can provide, other use more generalized, mathematical abstractions

to represent the data and their relationships. Recent work in database

research is directed towards improving the representation of the semantics

of the data [Hammer78, ElMasr79, Codd79] so that the constraints of the

relationships that exist in the real world can be used to verify the

appropriateness of data that are entered into the database.

Any reasonable model of the database can provide a common ground for

communication between users and implementors, without a model there is apt

to be an excess of detail [Wieder78]. An example of a data model for a

clinical database is shown below.

---------- -----------------

| Patients | <<<<< | Clinic Patients |

---------- -----------------

| ----------- ----------

* / ----------- ----------

---------------/ | |

| Clinic Visits | | |

--------------- | |

| * *

-------------- | ---------------------

-------------- | ---------------------

| |

* *

------------------

| Drugs Prescribed |

------------------

The ownership ( --* ) connections indicate that there may be

multiple inferior instances for each superior instance.

The reference ( --> ) connections indicate that there may be

multiple references to each instance.

The identity ( >>> ) connection defines a subgroup.

Wiederhold: Database Technology in Healthcare Page 11

C.3 Types of Database Models

A popular approach to database analysis distinguishes several categories

of databases. Database system implementations can be associated

with each category. These categories are represented by database

model types, the best known types are the

Relational model- derived from the mathematical theory of

relations and sets.

Hierarchical model- related to tree-shaped database implementations,

similar to corporate organization diagrams.

Network model - permits interconnections that are more complex

than hierarchies, based on a definition developed by a

committee of specialists in commercial system languages.

The structural model, used here, can describe the structures of any of these

three models, as well as of other database implementations. If only a

single record-type - a box in the above diagram - is implemented then we are

dealing with a 'universal relation' [Ullman80]. A single box for a

complex database would have many columns and rows, and contain many null

entries. If the data are organized into several record-types, each

corresponding to some meaningful entity, then we are dealing with a

'tabular database'; if a completely general query and processing capability

exists in such a system, we have implemented the 'relational model'

[Codd70,McLeod75].

At this point the entities stand alone, and some analysis is needed to

relate them. If any of the indicated connections have been implemented then

we may have a network or a hierarchical database. In the hierarchical model

a record-type may have only one ownership connection ( --* ) pointing to it.

Hierarchies model well the view of the data held by physicians or other

controlling groups [Davis70].

The implementation of multiple ownership connections, which creates a

network with associations, is considerably more complex [Stoneb75, Wieder77].

Several of the larger commercial DBMS's are based on work by the Data Base

Task Group of CODASYL, and do support such network structures [Olle78].

These systems often do not support the general inquiry capability of the

relational model implementations.

It is important to note that there is a distinction between a model and its

implementation. A model is an abstraction and provides a level of insight

which can cut through masses of confusing detail. Some models specialize

in selected aspects of the use of data [Bolour79]. In the implementation

this detail has to be considered. It is likely that the implementation will

differ considerably from the model used to describe it. As more powerful

models are developed this distinction may become greater. An implementation

may then be best described in terms of transformations that are applied to

the model which defines the database at a high conceptual level. Most

transformations are done for reasons of operational performance and

reliability. A large class of transformations adds redundant data into

the implementation in order to speed up retrieval and gain reliability,

whereas our models should have minimal redundancy. Examples of redundant

data that may be added during implementation are indexes, duplicated

reference information, and pointers between related data which physically

implement connections.

Wiederhold: Database Technology in Healthcare Page 12

D. Database Operations

In the section above we have discussed the scientific basis of databases.

In order to use and benefit from that science a database operation has to

be established, and that involves many decisions of practical, but critical

importance. This section will consider such topics.

After a database has been established and a suitable software system has

been obtained, data collection can commence. Data is often collected

partially from sources that were in existence before a database was

considered. To complete the database, so it can serve the intended broad

scope, new data collection points may have to be defined. The value of

adding any quantity of data to the database has to be considered since

data collection and entry is costly and susceptible to errors. We will

begin with a discussion of issues in entering of data, and then proceed to

data storage and organization concerns, discuss data presentation issues,

and finish with some remarks about database administration.

D.1 Entering Data into the Database

The relatively high cost of data entry is a major concern. It is obvious

that data that cost more to collect than they are worth should be avoided.

When a certain data element is entered its utility is hard to predict: its

usefulness may depend on its value, on the completeness of this patient's

record, and on the patient's returning to the clinic, so that follow-up is

possible. These factors are not easy to control. The actual problem of

data acquisition can, however, be addressed. Much less formal attention

has been given in the literature to this subject than to the topic of data

retrieval [Greenf76].

When data are to be collected there are the costs of the actual collection,

of the transcription to some processable form, and of the actual entry into

a computer. The data collection is to a great extent the physician's task.

While automated clinical instruments can collect objective values [Friedm78],

and the patients themselves can enter their own history [Slack66], many

subjective and important findings emanate from the physician [Collen74].

It may be considered desirable to minimize changes to the traditional

manner of medical data recording, so that the physicians continue to collect

their findings as notes in free text or by dictation. These reports are

then transcribed by clerical personnel into the computer. This format

presents the medical information in a way that is least affected by

mechanical restrictions. To enable retrieval of such observations the

specific statements or paragraphs may be categorized into functional

groups as findings, treatment, plans, etc. as proposed by [Korein71]. A

system, based on these concepts has served well in a city hospital

pediatric clinic setting. Of particular importance was that patient data

retrieval for emergency and unscheduled visits became possible [Lyman76].

When textual data are to be used for analysis, we find that they are nearly

impossible to process in the form they were entered. An immediate problem

is that the natural language text has to be parsed so that its meaning

can be extracted. Both the parsers and the associated dictionaries are

substantial pieces of software. But even when language understanding is

achieved, consistent data for entry may not have been obtained since

medical terminology varies over time and among health care providers. In

general some encoding is needed. It may then be of benefit both to the

Wiederhold: Database Technology in Healthcare Page 13

physician and to the system to choose a method of data collection which

encodes data immediately into a more rigorous form.

This is done typically through the use of preprinted, perhaps problem

area specific, forms [Barnet79]/ A system for patient surveillance

uses computer-printed forms which are prepared to be specific to each

patient visit [McDonal75].

Various choices exist

to encode data :

1. The encoding can be carried out by clerical personnel [Valbon75].

2. Natural language, i.e. English text, may be analyzed and converted

by a program that processes the text within the medical context

[Pratt73, Okubo75].

3. A constrained set of keywords for data values, for example the list:

{no, light, moderate, serious},

can be attached to the schema entry for a specific data type.

These data values will be converted on data entry to an internal

code [Wieder75].

4. Where the number of possible data elements, for which data are to be

collected, is large, the name of the data element, i.e. 'facial rash',

may be encoded in addition to the data value itself [Hammon73, Wong78].

5. Keywords may be checked on a form or selected from a menu presented

on a display screen [Schult76]. Selection can de accomplished using

touch-sensitive screens, lightpens, cursors operated by joysticks or

key-pads, or by entering on a keyboard a digit which refers to a

line of he presented menu.

6. Where the list of keywords is too long for screen presentation

a hierarchical menu selection can be provided or a subset of the

keywords corresponding to a few initial letters can be displayed

[Morgan77].

7. The forms or menus to be used for data collection may be generated

using the schema of the database managment system [Hanley78].

With the continuing development of fast display technology the latter choices

seem to have the most promise. The response for screen selection and

presentation of the next menu has to be extremely rapid ( 0.4 sec. per screen

is cited ) to encourage direct physician use of the devices [Watson77]. Such

speeds are very difficult to achieve today, since the display frames reside

on remote disk storage devices and have to be fetched, formatted, and

transmitted by file, application dependent, and communication programs for

presentation on terminals. When those terminals are connected via telephone

lines to the computer another bottleneck appears. To transmit a display

frame of 24 lines of 50 characters each, at the fastest available rate, 9600

bits/second, still requires one second. To cope with this problem either

special communication lines or storage devices local to the terminal are

needed.

Wiederhold: Database Technology in Healthcare Page 14

Numeric values are not as easily entered on a touch-screen as are choices

among discrete elements. Keyboard entry may continue to dominate this part

of data entry, unless the values can be obtained directly from medical

instrumentation. Typed data requires much editing. Comprehensive commands

for specification of input editing are part of the MUMPS language, and

have contributed greatly to its acceptance. Modern computer languages, as

PASCAL, also provide within the variable declarations a capability to limit

the range or the set of choices of values to be entered.

D.2 Data Storage

The cost of data storage is now much lower than cost of data entry. This

means that if data entry is worthwhile, the entered data can be stored for a

reasonably long time. The characteristics of medical record structure can,

however, easily lead to a waste of computer storage space which is an order

of magnitude greater than the actual data storage space needed. This

occurs when data are stored in simple rectangular tables, since the variety

of medical data requires many columns, but at one encounter only a few

values will be collected. Hierarchical file organizations allow linkage to

a variable number of subsidiary data elements, and in this manner provide

efficient storage utilization, whereas the older tabular files dealt

poorly with medical data [Greene69]. The encoding techniques used for data

entry can also provide compaction of stored data since short codes are

used to denote long keywords.

Data structures can often be compressed by suitable data encoding

techniques applied to the files. Unobserved data elements should

not need actual storage space. Data compression can reduce both the

storage requirements and the access times greatly [Wieder77]. When space

considerations are no longer an important issue in data organization, an

apparent tabular format can again be used, and this can simplify data

analysis programs. In a clinical databank, TOD [Weyl75], the compressed

data, after encoding to account for missing, zero, or repeating data,

occupied only 15% of the original storage space.

Older data often become less interesting, and can be moved to archival

storage. Storage on magnetic tape is quite inexpensive and the data can be

recovered, if needed for analysis, with a moderate delay. The cost of

long term data storage on tape is less than $1 per million characters per

year, for recent large disk devices on-line costs are still about $200 per

million characters per year, and several times that on older or smaller

devices. Entry of a million characters by keyboard entry costs at

least $500, and much more from typical medical data sources. In a well-run

operation data can be recovered from tapes for on-line access in about

an hour [Soffee76]. The major problems are the development of effective

criteria for selection of data for archival storage and the cataloging of

archival data, so that they can be retrieved when needed. Candidates for

archiving are detailed records of past hospitalizations and episodes of

acute illnesses.

Wiederhold: Database Technology in Healthcare Page 15

D.3 Data Organization for Retrieval

The important point in research usage of databases is that information is

not produced by the retrieval and inspection of a few values, but rather

from the relating of many findings in accordance with hypothesized cause

and effect relationships. When the data files grow very large, repetitive

scans for data selection may become prohibitively slow, especially during

the data exploration phase. We distinguish the following phases in the

research use of clinical databases:

1. Initial definition of the data to be collected, with consideration

for clinical needs. The expected usefulness is often based on

vague or ill-defined initial hypotheses.

2. Exploratory analysis, using tabulations and simple graphics in

order to compare subsets of the population.

3. Hypothesis generation based on perceived patterns, definition of

independent and dependent variables according to some clinical

model.

4. Data validation and sometimes expansion of data collection in the

areas in which patterns appear interesting.

5. Subset definition and generation so that differences due to the

independent variables can be made explicit.

6. Exhaustive statistical analysis of the subsets to verify or refute

the hypotheses.

It is important to have good subsetting facilities and efficient access to

defined subsets. Such services are provided in many clinical systems, but

the techniques vary widely. Often the subsets are extracted and

manipulated as distinct databases [Mabry77]. In other systems a subset is

kept as a collection of references to records in the main database

[German75], and in yet another system the subset is recreated from the

definition of the subset [Todd75].

Since access to data in research is primarily by attribute field rather than

by patient record, it can be profitable to transpose the database [Wieder77].

Transposition generates one, possibly very long, record for each attribute

of the database. Such a record now contains a sequence of values of this

particular attribute for all patients or all visits of all patients. Many

current computer systems cannot manage such long records easily but the

benefits should be clear: to relate blood pressure results to dosage of

an anti-hypertensive drug only two records have to be retrieved from the

transposed file. In a conventional file organized by patient visit every

visit record is accessed to retrieve the two fields needed to accomplish

this comparison.

Wiederhold: Database Technology in Healthcare Page 16

As indicated earlier, the addition of redundant data can speed up the

retrieval process. An index is an access structure which repeats key

data in a compact form, and is used to avoid scanning an entire

conventional file to search for a record. Attributes which are expected

to be used in record selection are entered into the auxiliary index file,

which is then maintained in sorted order. If the attribute being kept sorted

is "bloodpressure", then all hypertensives will appear at the beginning of

the "bloodpressure" index file. With every bloodpressure value a reference

pointer to the corresponding visit record will be kept. Now only the data

records for patient visits where the bloodpressure was high will have to be

retrieved.

Bitmaps provide a simplified form of indexing. Whereas an index is based

on the actual data values, a bitmap uses simple categorizations of these

values. In a list with entries which correspond to the records in the

datafile a bit is set to one if the data values in the record meet a certain

condition. This condition could be a blood pressure greater than 160/100

[Ragan78]. Both indexing and bitmaps can be viewed as providing

the capability of preselection of relevant records. If the selection of

indexes or bit map definitions matches the retrieval requests well,

access to conventional files can become much faster. The maintenance of

such access structures will of course require additional effort at the

time of data entry.

There are many cases where more computation at the time of data entry can

reduce the effort that required at data retrieval time. In some applications

it may be known that certain computable results of the collected data will

be needed at a later time. Then such results may actually be already

computed and stored within the database when the source data are entered.

Typical of a precomputed or actual result is the maximal value of a

clinical observation on a given patient, say blood pressure, which could

be kept available so that no search through multiple visits is needed to

identify a patient with evidence of hypertension [Melski78]. Other

candidates for precomputation are totals, averages, or the range of values

of a variable [Wieder75]. The total amount outstanding on a bill and the

range of a diabetics blood-sugar level are other examples.

D.4 Data Presentation

Data from databases can be presented in the form of extensive reports

for manual scanning, as summary tabulations, or as graphs to provide rapid

visual comprehension of trends. An extensive data analysis may lead to a

printout of statistical findings and their significance, or may provide

clinical advice in terms of diagnosis or treatment. When simple facts are

to be retrieved the results are apt to be compact and easy to display or

print. Queries formulated in English can provide retrieval of such

data [Epstein78]. If much computation is used to generate the information

then presentation of the end-results alone is rarely acceptable. Most medical

researchers will want an explantion of the data sources and algorithms

that led to the output results, as well as information about the expected

reliability of the final values.

These human interface requirements increase the volume of the output for

research studies, so that printed reports dominate. In most clinical

situations less output is used, so that other methods may be practical.

Wiederhold: Database Technology in Healthcare Page 17

We have seen the following alternative [Fries74]::

1. Detailed listings or rapid video display terminal presentations

for quick scanning of data.

2. Cross tabulations or graphics to aid human pattern detection.

3. Well-structured summaries, with automatic data selection and

advice for patient care.

4. Summaries with explanatory backup available on a terminal

when needed.

5. Structured report presentation for outside distribution,

as with billing or result publication.

During a routine patient encounter a paper summary is probably least

distracting, but in emergency situations video terminal access can be much

more rapid. Terminal access helps the researcher in the formulation of

queries, and graphics provide insight to clinicians uncomfortable with

long columns of numbers. As systems mature and become more accepted the

user should be able to move smoothly from one form of output presentation

to another, but most systems now in use do not provide many options for

data presentation, and even fewer offer a smooth transition between

interaction modes.

D.5 Database Administration

Even when all the right decisions have been made and a database exists,

there has to be an ongoing concern with reliability, adaptation to

changing institutional needs, planning for growth, and technical updating

of the facilities. In many institutions a new function, that of database

administrator, is defined to deal with these operational issues. The

database administrator needs strong support from management and high

quality technical assistance. Since the function is responsible for

day-to-day operations it is not reasonable to expect a high level of

innovation from the database administrator, but responsiveness to the

institutional goals is essential.

Acknowledgement

This paper was prepared as part of a review for a Compendium on Computers

in Health Care, Dr. D.A.B. Lindberg, Univ. of Missouri, Editor. Much

intellectual stimulation has come from my colleagues on many evaluation

committees. Marty Epstein of NIH DCRT, Dr. Bob Blum of Stanford, and Dr.

Alan Rector of Nottingham have provided important remarks and insights

into the development of databases. Dr. Blum was also of major assistance

in making this paper more readable and Marty Epstein provided many

corrections and references. The resources provided by the SUMEX Facility,

supported by grant NIH RR-00785 were essential to the preparation of this

document. Background was provided through a study sponsored by the National

Center for Health Services Research (NCHSR) at the University of California

[Henley75] and is aided by research carried out as part of the RX Project,

sponsored by NCHSR under grant No. 1RO3 HS93650. Basic research in database

design leading to some of the concepts presented here is supported by ARPA

within the Knowledge-Based Management Systems project at Stanford University.

Wiederhold: Database Technology in Healthcare Page 18

REFERENCES

ACM76 ACM Surveys: Special Issue; Data Base Management Systems;

ACM Computing Surveys, Vol. 8, no. 1, 1976.

Barnet76 Barnett, G.O., D.E. Souder, J.E. Bowie, N. Justice: "MUMPS:

A Support for Medical Information Systems"; Medical Informatics,

Vol. 1, pp. 183-189, 1976.

Barnet79 Barnett, G.O., N.S. Justice, et al: "COSTAR: A Computer-based

Corporation, Medical Information System for Ambulatory Care";

Proc. of the IEEE, Vol. 67, no. 9, September 1979, pp. 1226-1237.

Barsam79 Barsamian, H.: "Technology and Architecture for Data

Management: An Overview and Perspective"; IEEE Computer

Vol. 15, no. 5, pp. 8-10, May 1979.

Beckle77 Beckley, R.F. and H.L. Bleich: "Paper Chase: A Computer-

Based Reprint Retrieval System"; Comp. Biomed. Res., Vol. 10,

pp. 423-430, 1977.

Bleich72 Bleich, H.L.: "Computer-based Consultation - Electrolyte and

Acid-base Disorders"; Am. Jour. Med., Vol. 53, pp. 285-291, 1972.

Blum78 Blum, R.L. and G. Wiederhold: "Inferring Knowledge from

Clinical Data Banks Utilizing Techniques from Artificial

Intelligence"; Proceedings of the Second Annual Symposium on

Computer Applications in Medical Care, Washington, D.C., IEEE,

pp. 303-307, 1978.

Blum79 Blum, B.I. and R.E. Lenhard: "An Oncology Clinical

Information System"; Computer (IEEE), Vol. 12, no. 11,

November 1979, pp. 42-50.

Bolour79 Bolour, A.: "The Process Model of Data"; Tech. Rep. 38, Medical

Information Science, Univ. of Calif., San Francisco, March 1979.

Bowie77 Bowie, J.E.: "Methods of Implementation of the MUMPS Global

Database"; Proc. of the MUG of Japan Meeting, Nagoya, Japan, 1977.

BrookW76 Brook, R.H., K.H. Williams, and A.V. Avery: "Quality Assurance

Today and Tomorrow: Forecast for the Future"; Annals of Internal

Medicine, Vol. 85, pp. 809-817, Dec. 1976.

Brown78 Brown, B.W., J. McConathy, M. Meigs, B. Munder, and M. Schimek:

"File Arrangement and Maintenance Executive (FAME), A General

Purpose Schema Driven File Maintenance System"; Comput. Biol.

Med., Vol. 8, pp. 159-172, 1978.

Bush45 Bush, Vannevar: "As We May Think"; Atlantic Monthly, Vol. 17

no. 1, pp. 101-108, 1945.

Chan&O76 Chang, S., M. O'Brien, J. Read, R. Borovedc, W.H. Cheng, and

J.S. Ke: "Design Considerations of a Database System in a

Clinical Network Environment"; Proc. 1976 National Computer

Conference, AFIPS, Vol. 46, pp. 277-286, 1976.

Wiederhold: Database Technology in Healthcare Page 19

Codd70 Codd, E.F.: "A Relational Model for Large Shared Data Banks";

Comm. of the ACM, Vo1. l3 no. 6, pp. 377-387, 1970.

Codd79 Codd, E.F.: "Extending the Database Relational Model to Capture

More Meaning"; ACM Transactions on Databases, Vol. 4, no. 4, Dec.

1979, pp. 397:434.

Collen74 Collen, M.F.: Hospital Computer Systems; John Wiley & Sons,

New York, 1974.

Davis70 Davis, L.S.: "Prototype for Future Computer Medical Records

Comput. Biomed. Res., Vol. 3, no. 5, pp. 539-554, 1970.

Davis78 Davis, R.: "A DSS for Diagnosis and Therapy"; ACM SIGBDP,

Vol. 8, no. 3, 1978.

Doszk80 Doszkocs, T.E., B.A. Rapp, and H.M. Schoolman: "Automated

Information Retrieval in Science and Technology"; Science, Vol.

208, no.4439, 4 April 1980, pp.25-30.

ElMasr79 El-Masri, R. and G. Wiederhold: "Data Model Integration

Using the Structural Model"; Proceedings of the ACM-SIGMOD

Conference, pp. 191-202, 1979.

Epstei78 Epstein, M.N.: "Natural Language Access to a Melanoma Data Base";

Proceedings of Second Annual Symposium on Computer Applications in

Medical Care, Washington, D.C., IEEE, New York, pp. 320-327, 1978.

Feins70A Feinstein, A.R.: "Taxonorics"; Archives of Internal Medicine,

Vol. 126, pp. 679-693 (October), pp. 1053-1067 (December), 1970.

Fenna78 Fenna, D., S. Abrahamson, S.O. Loow, and H. Peterson: The

Stockholm County Medical Information System; Springer Verlag 1978.

Friedm77 Friedman, R.B. and D.H. Gustafson: "Computers in Clinical

Medicine, A Critical Review"; Comput. Biomed. Res., Vol. 10,

pp. 199-204, 1977.

Friedm78 Friedman, R.B., S.M. Entine, E.A. Anderson: "Laboratory Data

and Clinical Decision Making"; Proceedings Fourth Illinois

Conference on Medical Information Systems, pp. 31-38, 1978.

Fries74 Fries, J.F.: "Alternatives in Medical Record Formats";

Medical Care, Vol. 12, no. 10, 1974.

Gabrie78 Gabrieli, E.R.: "Knowledge Base Structures in a Medical

Information System"; Proceedings of the 8th Annual Conference

of the Society for Computer Medicine, pp. 1.2.9 to 1.2.11, 1978.

German75 Germano, F. Jr., and S. Weyl: "A Database Organization to

Support a Time-Oriented Medical Record"; Proc. ACM Pacific 75

Conference, Boole and Babbage, Palo Alto, CA., 1975.

Greene69 Greenes, R.A., A.N. Pappalardo, C.W. Marble, and G.O.

Barnett: "A System for Clinical Data Management";

Proceedings of the 1969 FJCC, AFIPS Vol. 35, pp. 297-305, 1969.

Wiederhold: Database Technology in Healthcare Page 20

Greenf76 Greenfield, R.H.: "Clinical Data Base Usage"; Proceedings

of the Third Illinois Conf. on Med. Inf. Systems, pp. 47-56,

Univ. of Illinois at Chicago Circle, 1976.

Groner78 Groner, C.F., M.D. Hopwood, N.A. Palley, et al: "An Interactive

Data Management and Analysis System for Clincial Investigators";

J. Lab. Clin. Med., Vol. 92, no. 3, pp. 325-340, 1978.

Hammer78 Hammer, M. and D. McLeod: "The Semantic Data Model, A

Modelling Mechanism for Data Base Applications", Proc. SIGMOD,

pp. 22-36, 1978.

Hammon73 Hammond, W.E., et al: "GEMISCH: Mini-Computer Information

Support System"; Proc. of IEEE, Vol 61, pp. 1575-1583, 1973.

Hammon78 Hammond, W.E., W.W. Stead, M.J. Straube, and J.D. Collins:

"Experience in the Development of an Ambulatory Care Medical

Information System"; Proc. 3rd USA-Japan Conference, AFIPS-IPSJ,

pp. 452-455, 1978.

Hanley78 Hanley, J.A.: "A Language for the Computer Generation of Medical

Data Forms"; Biometrics, Vol. 34, no. 2, June 1978, pp. 288-297.

Henley75 Henley, R.R., G. Wiederhold, J.V. Dervin, M.A. Jenkin, I.M.

Kuhn, E. Mesel, D. Ramsey-Klee, and J.E. Rodnick: "An Analysis

of Automated Ambulatory Medical Record Systems"; Vol. I, Findings

and Vol. II, Background, Univ. of California, San Francisco,

Office of Medical Information Systems, Technical Report #13, 1975.

Jainz76 Jainz, M. and T. Risch (Eds.): "A Data Manager for the Health

Information System Berlin"; Comp. Prog. in Biomed, Vol. 6,

pp. 166-170, 1976.

Johnso79 Johnson, P.E., D.G. Severance, and P.J. Feltovich: "Design of

Decision Support Systems in Medicine: Rationale and Principles

from the Analysis of Physician Expertise"; Proceedings of the 12th

Hawaii International Conference on System Sciences, B. Shriver,

T.M. Walker, and R.H. Sprague, Jr., Western Periodicals Co., 1979.

Karpin71 Karpinski, R.H.S. and H.L. Bleisch: "MISAR, A Miniature

Information Storage and Retrieval System"; Comp. and Biomed.

Res., Vol 4, pp. 655-660, 1971.

Korein71 Korein, J., M. Lyman, and L.J. Tick: "The Computerized Medical

Record"; Bulletin N.Y. Acad. Med., Vol. 47, pp. 824-826, 1971.

Kronma78 Kronmal, R.A., K. Davis, D. Lloyd, R.A. Jones, and M.J. Gillespie:

"Data Management for a Large Collaborative Clinical Trial. CASS:

Coronary Artery Surgery Study"; Comput. Biomed. Res. Vol.11, no.6,

pp. 553-566, Dec. 1978.

Kunz79 Kunz, J.: "Index Medicus: A Century of Medical Citation";

JAMA, Vol. 241, pp. 301-390, 1979.

Leiter77 Leiter, J.: "On-Line Systems at the National Library of Medicine";

Proceedings of MEDINFO 77, North-Holland, pp. 349-353, August, 1977.

Lindbe79 Lindberg, D.A.B.: The Growth of Medical Information Systems in

the United States; Lexington Books 1979.

Wiederhold: Database Technology in Healthcare Page 21

Lucas78 Lucas, H.C.: "The Use of an Interactive Storage and Retrieval

System in Medical Research"; CACM, Vol. 21, pp. 197-205, 1978.

Lyman76 Lyman, M.: "A Data Support System for Emergency Health Care";

Proceedings of the Third Illinois Conference on Med. Inf. Systems,

pp. 88-97, Univ. of Illinois at Chicago Circle, 1976.

Mabry77 Mabry, J.C., H.K. Thompson, M. Hopwood, and W.R. Baker:

"A Prototype Data Management and Analysis System (CLINFO)";

Proc. of MEDINFO 77, North Holland, pp. 71-75, 1977.

Manach75 Manacher, G.V.: "On the Feasibility of Implementing a Large

Relational Data Base with Optimal Performance on a Mini-Computer";

Proceedings of the First International Conference on Very Large

Data Bases, D.S. Kerr, ed. , ACM, pp. 175:201, 1975.

McDona75 McDonald, C., B. Bhargava, and D. Jeris: "A Clinical Information

System (CIS) for Ambulatory Care"; Proc. of the 1975 NCC, AFIPS,

Vol. 44, pp. 749-756, 1975.

McDona77 McDonald, C.J., et al: "A Computer-Based Record and Clinical

Monitoring System for Ambulatory Care"; American Journal of

Public Health, Vol. 67, no. 3, pp. 240-245, 1977.

McLeod75 McLeod, D. and M. Heldman: "RISS - A Generalized Mini-Computer

Relational Data Base Management System"; Proc. 1975 NCC, AFIPS,

Vol. 44, pp. 397-402, 1975.

Meldma78 Meldman, M.J., D.J. McLeod, R.J. Pellicore, and M. Squire: RISS,

A Relational Data Base Management System for Minicomputers; Van

Norstrand Reinhold, 1978.

Melski78 Melski, J.W., D.E. Geer, and H.L. Bleich: "Medical Information

Storage and Retrieval Using Preprocessed Variables"; Comp. Biomed.

Res., Vol. 11, pp. 613-621, 1978.

Morgan77 Morgan J.L.: "Computerized SNOMED Encoding: a Practical Solution";

Medinfo 1977, North-Holland, pp. 277-281, 1977.

Okubo75 Okubo, R.S., W.S. Russell, B. Dimsdale, B.G. Lamson: "Natural

Language Storage and Retrieval of Medical Diagnostic Information";

Computer Programs in Biomedicine, 1975, pp. 105-130; also in

Computers in Laboratory Medicine, ed. D. Enlander, Academic Press,

1975, pp. 54-60.

Olle78 Olle, W.: The Codasyl Approach to Data Base Management; John

Wiley & Sons, November 1978.

Palley75 Palley, N. and G.F. Groner: "Information Processing Needs and

Practices of Clinical Investigators - Survey Results"; Proc. of

the 1975 NCC, AFIPS Vol. 44, pp. 717-723, 1975.

Penick76 Penick, R.W. and F. M. Crowder: "Integrated Data Communications

System for Ambulatory Care"; Proceedings of the Third Illinois

Conference on Med. Inf. Systems, Univ. of Illinois at Chicago

Circle, pp. 98-109, 1976.

Pratt73 Pratt, A.W.: "Medicine, Computers, and Linguistics"; Advances in

Biomedical Engineering, Vol. 3, Academic Press, pp. 97-160, 1973.

Wiederhold: Database Technology in Healthcare Page 22

Ragen78 Ragen, D.P. and S.A. Jones: "High-Level Language Implementation

of Bit Map Inverted Files"; Comp. Biomed. Res., Vol. 11, pp.

593-612, 1978.

Reiche68 Reichertz, P.L: "PIRS, Personal Information Retrieval Systems";

Meth. Inf. Med., Vol. 7, no. 3, pp. 165-172, 1968.

Sauter76 Sauter, K., P.L. Reichertz, et al: "A System to Support High-

Level Data Description and Manipulation of an Operational Database

System"; Medical Informatics, Vol. 1, no. 1, pp. 15-26, 1976.

Schult76 Schultz, J.R.: "PROMIS: Problem-Oriented Medical Information

System: A Medical and Technical Solution to Four Problems in

Medicine"; Proceedings of the Third Illinois Conference in Med.

Inf. Systems, pp. 1-20, Univ. of Illinois at Chicago Circle, 1976.

Schult79 Schultz, J.R. and L. Davis: "The Technology of PROMIS"; Proc.

of the IEEE, vol. 67, no. 9, September 1979, pp. 1237-1241.

Slack66 Slack, W.F., G.P. Hicks, C.E. Reed, et al: "A Computer Based

Medical History System"; N. Engl. J. Med., Vol. 274, pp. 194-198,

1966.

Soffee76 Soffeer, S.B., S.M. Entine, T. Wolfe, A. Eggert, et al: "A

Database System for Archival Storage of Clinical Lab Data"; Proc.

of 3rd Illinois Conf. on Med. Inf. Sys., pp. 278-288, Nov. 1976.

Stoneb75 Stonebraker, M. and G. Held: "Networks, Hierarchies, and

Relations in Data Base Management Systems"; Proc. ACM Pacific

75 Conference, Boole and Babbage, Palo Alto, CA, 1975.

Todd75 Todd, S.J.P.: "Peterlee Relational Test Vehicle"; Proceedings

of the 1975 VLDB, ACM, pp. 554-556, 1975.

Ullman80 Ullman, J.D.: Principles of Database Systems; Computer

Science Press, Potomac MD, 1980.

Valbon75 Valbona, C., et al: "Computer Support of Medical Decisions in

Ambulatory Care"; Meth. of Inf. in Med., Vol. 14, no. 2, pp.

55-62, 1975.

Warner78 Warner, H.R.: "Knowledge Sectors for Logical Processing of

Patient Data in the Help System"; Proceedings of the 2nd Annual

Symposium on Computer Applications in Medical Care, IEEE, pp.

401-404, 1978.

Watson77 Watson, R.J.: "A Large-Scale Professionally Oriented Medical

Information System - Five Years Later"; J. of Med. Sys., Vol.

1, no. 1, pp. 3-21, 1977.

Weyl75 Weyl, S., J.F. Fries, and G. Wiederhold: "A Modular Self-

Describing Clinical Databank System"; Computers and Biomedical

Research, Vol. 8, pp. 279-293, 1975.

Wieder75 Wiederhold, G., J.F. Fries, and S. Weyl: "Structured

Organization of Clinical Databases": Proc. of the 1975 NCC,

AFIPS, Vol. 44, pp. 479-485, 1975.

Wiederhold: Database Technology in Healthcare Page 23

Wieder77 Wiederhold, G.: Database Design; McGraw-Hill Book Company,

New York, (Computer Science Series), May 1977.

Wieder78 Wiederhold, G.: "The Data Model of MUMPS Globals"; Proceedings

of the 1978 MUMPS User Group Meeting; P. Zimmerman (Ed.), MUG,

Bedford, Mass., pp. 159-183, 1978.

Wieder79 Wiederhold, G. and R. El-Masri: "A Structural Model for

Database Systems"; Stanford CS Report 79-722, May 1979.

Wieder80 Wiederhold, G: "Database Technology in Healthcare"; Stanford

CS Report 80-790, March 1980.

Wirtsc78 Wirtschafter, D.D., M. Scalise, H. Cort, C. Henke, and R.A.

Gams: "Clinical Algorithms in A Cooperative Multi-Institutional

Clinical Trial"; Proceedings of Fourth Illinois Conference on

Medical Information Systems, University of Illinois at Chicago

Circle, 1978.

Wong78 Wong, R.L., R. Plah, A. Baldwin, and T. Hain: "Experience

on a Surgical Pathology Database and a Lexicon Compiled from

Logically Derived Medical English"; Proceedings of the 2nd

Annual Symposium on Computer Applications in Medical Care,

pp. 326-327, 1978.

Yu79 Yu, V.L., B.G. Buchanan, E.H. Shortliffe, S.M. Wraith, R. Davis,

A.C. Scott, and S.N. Cohen: "Evaluating the Performance of a

Computer-Based Consultant", Computer Programs in Biomedicine,

Vol. 9, pp. 95-102, 1979.

Zimm&R78 Zimmerman, J. and A. Rector: Computers for the Physician's

Office; Research Studies Press, Forest Grove, OR., 1978.

From: Erik Gilbert <EJG at SU-AI>

Subject: Re: xspooling of <WIEDERHOLD>HEALTHCARE.ALL

To: GIO at SU-AI

I spooled the file and it is in campus mail to you at Jacks. Six

of its pages were longer than the 63 lines per page which will fit

using the default parameters and the default font, so I respooled

those pages with some magic switches, via:

XSPOOL HEALTH.ALL(2,20,42,43,48,49)/NOHEAD/PMAR=1900/BMAR=100

...which allows you to squeeze 1/2 inch more text than usual at

the bottom of each page.