HOSPITAL INFORMATION A GUIDE FOR MANAGERIAL PLANNING …web.mit.edu/smadnick/www/MITtheses/04404726.pdf · o System management tended to be delegated to a data pro-cessing department

6

HOSPITAL INFORMATION SYSTEMS:

A GUIDE FOR MANAGERIAL PLANNING

by

Eric William Kurtz

B.A. Harvard

M.A. Yale

Ph.D. Yale

University (1957)

University (1959)

University (1966)

IS~~~ ~ t31r.J.

4, "'t

7%,~2

SUBMITTED IN PARTIAL FULFILLMENT

OF THE REQUIREMENTS FOR THE

DEGREE OF

MASTER OF SCIENCE

at the

MASSACHUSETTE INSTITUTE OF TECHNOLOGY

June, 1977

Signature of Author ...............................................Alfred P. Sloan School of Management, June 1977

Certified by ......................................................Professor Stuart E. Madnick, Thesis Supervisor

Accepted by........................................................Chairman, Departmental Committee on Graduate Students

3

ACKNOWLEDGMENTS

This study is based on the continuing work of the Center for

Information Systems Research at the Massachusetts Institute of

Technology. Special thanks are due to Professor John F. Rockart,

who suggested the topic and generously gave advice as the project

was carried out; to Christine Bullen, who contributed helpful

information and encouragement; and to Professor Stuart E. Madnick,

whose Management Information Systems Research Practicum provided

guidance and incentives.

The author also wishes to thank Allen Cullis, of Burroughs Corporation;

Robert Cohen, of Keane Associates; Kent Bradford, of Huff, Barrington,

and Owens; and Louis Cellinari and William Macomber, of Salem Hospital,

Salem, Mass., who generously gave information and valuable suggestions.

TABLE OF CONTENTS

Introduction................................................ 5

Chapter 1. Historical Dynamics............................ 7

Chapter 2. The Decision Process........................... 23

References.................................................. 49

LIST OF EXHIBITS

Figure 1.

Figure

Figure

Figure

Figure

Figure

Figure 7.

Figure 8.

Figures 9,10, 11,&12.

Figure 13.

Alternative Systems.............................

Characteristic Functional Design................

Outline of the Decision Process.................

Advantages and Disadvantages: ASummary of Alternatives.......................

Scoring Sheet for Situational Factors...........

Alternatives Mapped on the Decisionsof Systems Development and SystemOperation.....................................

Feasibility Investigation Process...............

Features to Consider in PackageEvaluation....................................

Vendor Evaluation Sheet.........................

Outline of the Iterative Decision Process.......

18

26

33

34

35

37

39

42, 43, 44, 45

47

5

INTRODUCTION

This study of hospital information systems is intended to advise

hospital administrators who are responsible for making decisions about

the automation of information processing. It looks principally at the

medium- to large-sized community hospital, and it speaks to the hospital

director, the business manager, the head of data processing, and the

planning committee. It attempts to guide the processes by which they

arrive at a long-range plan for the architecture of a computerized

information system and a set of immediate decisions about the development,

operations, and management of individual computer applications.

The study is based on a variety of sources of information. It

attempts to bring together a large number of articles on the design of

management information systems, which focus on the complex debate over

centralization vs. decentralization, and the smaller, more specialized, and

more descriptive literature on hospital information systems.

The approach is eclectic, sorting and weighing reports of the

experience of others. And it relies heavily on the ongoing work of

the Center for Information Systems Research at M. I. T.

But the study has a contribution of its own to make, in at least

two respects. First, in examining the hospital administrator's decisions

against the broader background of current developments and problems in the

design of information systems, it provides a rational, long range planning

approach which can coordinate the divergent goals and interests of the

decision makers. And second, it offers a set of practical guidelines

which can be used in evaluating the choices among service bureaus,

facilities management plans, turnkey systems, and software packages,

as alternatives to in-house development of computer applications. The

study takes into account the point of view of the data processing

professional, but it stresses the responsibility of the hospital

administrator who is concerned to improve management for the sake of more

efficient and effective delivery of health care.

Chapter 1. Historical Dynamics

Throughout the 1960's and early 70's, the literature on hospital

information systems reflects the predominance of forces tending toward

centralization of all aspects of data processing. Here, as throughout

this paper, it will be useful to follow David P. Norton (1972) and the

approach of the Center for Information Systems Research in distinguishing

three separate data processing functions:

o System operations which include the physical hardware as

well as the operations and maintenance personnel directly

associated with the computer.

o System development which involves the analysis, design and

programming of new computerized applications as well as the

updating and maintenance of existing applications.

o System management which encompasses the administrative aspects

of planning, developing, operating, and controlling the

organization's information system.

When one looks at the pattern of centralization and decentralization of

hospital information systems, thereuas a tendency toward centralization

in all three areas.

o System operation was dominated by the superior performance

of large machines. "Grosch's law" describes the savings

in time and money which resulted from faster, more complex

hardware. The naivete of users and the difficulty

of hiring and keeping expert data processing personnel made

small-scale and decentralized operations impractical.

o System development required either a central data processing

staff within the hospital or relinquishment of system

development to a service bureau or a regional consortium

of shared services. Large programs written in lower-level

languages were difficult to code and debug without an

experienced central staff. Small and medium-sized hospitals

tended to "centralize" systems analysis and programming

by buying services from vendors.

o System management tended to be delegated to a data pro-

cessing department which reported to the business manager or

hospital director. Departmental aspirations and pressures

from hardware and software vendors combined to foster a "total

hospital information system" approach.

The successes of the heavily centralized approach are well documented

in Morris F. Collen's Hospital Computer Systems (1974). (See especially the

articles on the Karolinska Hospital Computer System, the Medical School of

Hannover Hospital Computer System, and the Texas Institute for Research and

Rehabilitation). These systems have several features in common. They

were designed in large research institutes heavily funded from outside

sources; they attempt to achieve a "total" integrated system based on an

automated medical record and a widespread communication system; they

centralize systems operation around a large computer, typically an

IBM 360 or 370; they centralize system development around a large staff

of analysts and programmers; and they concentrate system management in

a joint committee of administrators and data processing professionals.

They are funded by outside grants for computer development, and while

they claim success in improving both the administrative and medical

procedures, they acknowledge the difficulties of measuring costs and

benefits in a health care setting, and they do not claim anything like

full cost recovery.

The failures are less well documented, for understandable reasons.

One should note that some of the "successful" systems are now at least

partially dismantled: the ambitious continuing integrated medical record

for over 1 million patients in the Kaiser Health Plan, for example, has

been discontinued because of curtailment of research funds, and apparently

also because of problems in implementing a flexible data base management

system, given the limitations of available hardward and software (Davis

and Terdiman, 1974). John Anderson gives an admirably frank account of

the difficulties encountered in implementing an ambitious centralized

"total" system at King's College Hospital, London (in Collen, 1974). The

problems in the system can be directly attributed to the centralization

strategy in all three areas. System development was complicated by a

shift in objectives as the project evolved: the original goal of a central

automated medical record gave way to the competing goal of a centralized

communications network, and since the various applications programs were

interdependent, much time was lost and energies were paralyzed by the

conflict. Systems operations were impaired by unreliable hardware and by

the isolation of the centralized computer staff, who had little

knowledge of the workings of the hospital and little communication with

users of the system. And systems management was complicated by the

attempt to follow a "multi-team approach" to a centralized system. The

diverse objectives of the teams and the divided responsibilities of

individual team members made progress difficult, particularly in the

absence of clearly articulated goals. Anderson's rueful and richly

detailed account deserves thoughtful reading by anyone planning a

centralized system: although the difficulties encountered were extreme

and perhaps unrepresentative in degree, they indicate vividly the kinds

of problems experienced by many hospitals which prematurely attempted an

ambitious "total hospital information system" approach.

The failures discussed so far have been large scale ventures with

substantial outside funding. For the manager of a community hospital,

a more immediately relevant cautionary tale can be found in Harrington

and Buchak's account (1972) of the automation of the business functions

of St. Luke's Hospital, in New York City, during the late 1960's. The

hospital attempted centralized development,operations, and management of

an ambitious in-house information system. The authors point to problems

which can be attributed partly to matters of scale (the hospital was not

large enough to command sufficient resources of money and personnel),

partly to limitations of available hardware, software, and service, but

partly also to the strategy of in-house development by a centralized

data processing staff.

Six years and nearly $1.5 million later, only a limited numberof applications were operational. The many problems includedsystems that: were poorly developed and designed; failed to

meet user department needs; required extensive modificationsto incorporate minor operational changes; had poor documentation,making them difficult to maintain; were incomplete and requiredduplication of effort in maintaining the old manual systems,and were incompatible with others in terms of integration intoa total hospital information system....

The principal reason for this failure was our inabilityto perform the myriad tasks associated with an in-house installation,including: recruiting highly skilled electronic data processingpersonnel in competition with large corporations and glamorousservice groups; almost continuous training of new personnelbecause of a high turnover rate; executing management planswithin budget and schedules; converting from manual to E.D.P.system; dealing with equipment manufacturers and their maintenancepeople, and providing our own support services when the computermanufacturer withdrew his.

Ironically, the reasons for failure are closely connected with the

pressures that had originally impelled hospitals, as well as other

industries, in the direction of centralization. Economies of scale

and the superior performance of large machines made the large central

computer a promising option, but a very expensive one when those promises

could not be fulfilled. Difficulties in hiring and retaining qualified

personnel made decentralization impractical, but they damaged continuity

in the centralized plan as well. The problems of coding and debugging

complex programs made a central staff necessary, but when the programs

were made interdependent they failed to do the work. Since users did not

understand computers, it was easier to import data processing experts

than to educate the health care professionals, but the result was that

the managers of data processing did not understand the organization

that they were automating.

The problems with the centralization strategy in hospitals have

their counterparts in other industries as well, but the hospital setting

makes them more severe. The complex organization of the hospital and the

necessity to integrate the health care delivery system around the treatment

of the individual patient generate contradictory demands: on the one hand,

each professional staff, each department, and each ancillary services wishes

to retain control over its own operations; and on the other hand treatment

of the patient's illness requires that all information should be organized

around the patient's unpredictable path through the institution.

As John Anderson puts it in his article on the King's College Hospital

Computer System (1974),

It was felt with the advent of real-time computing in the airlineseating business that medical computing would be much easier,certainly not as complex as it is. What was forgotten was thatattending to the average sick patient is as complex a task asrunning.an entire aeroplane, including engineering and controlaspects as well as seating requirements. In a hospital patientmanagement information system or health care system, we areconsidering the equivalent of moving a fleet of aircraft roundthe world every day, seven days a week. Such problems havenever been tackled, much less solved.

The complexities of the information flow in the hospital are well described

in the literature (see especially Rockart and Grossman (1976) and Garrett

(1976)). And the unusual demands for system reliability, data integrity, and

data security are well known. The point to be made here is that the complex

requirements of the hospital make the advantages of the centralization

strategy hard to attain.

A variety of solutions to the dilemma evolved in the 1960's and early

70's, in the form of attempts to capture some of the advantages of

centralization by handing some of the responsibility for systems development,

systems operations, and systems management over to commercial service vendors

or to groups of hospitals forming shared service ventures. The range of

options is familiar to all hospital managers:

o Service bureaus which characteristically provide batch

processing on a large computer, primarily for financial

applications (payroll, accounts payable, general ledger,

accounts receivable, billing).

o Shared services which provide cooperative development and

operations, batch or on-line, for financial applications,

laboratory, and other ancillary services.

o Facilities management, which contracts to provide all

computer services, including hardware, software, and

management of personnel, either through the vendor's

central facilities or through operation of equipment

located in the hospital.

o Turnkey systems, comprising both hardware and software,

which are designed as integrated systems, many including

data communications capability and some including a

medical data base for partially automated medical records.

o Software packages, self-contained modules, often designed

with interfaces allowing simple forms of data communication

between programs, and varying possibilities for customizing

to the clients' needs.

The range of options is summarized in the Systems Dimensions Limited

monograph (1974), and details are available (not always with scrupulous

accuracy) in the brochures of vendors. Later sections of this study will

raise the issue of how to decide among the options. The point to be made

14

here is that these services can be seen as attempts to carry centralization

one step further and to place one or more of the data processing functions

in a location which will allow the advantages of centralization without the

costs and organizational complexities that result from placing the "center"

inside the data processing department of the hospital.

The pattern of centralization can be roughly seen in the diagram

below. The "center" for system development, operation, and management

can be located in the vendor organization (indicated with a V) or in

the hospital (H). The result is a continuum of possibilities, with important

consequences for the processes of systems management.

Syst. Development: Syst. Operation Syst. Management:Analysis, Design, Hardware, Planning, Hiring

Programming Personnel Controlling

Facilities Mgt. V V or H Vendor

Service Bureau V V 0o 1

Shared Services V&H cooperatively V " t 00 0iCf

Turnkey Systems V H g eQ0

W o

Software Packeges V H S ,

ert

Customized V&H cooperatively H

Software Packages

In-House H H Hospital

Figure 1. Alternative Systems

There is some overlap in the categories of services: some vendors

offer three or four of the options; and in the operations and development

columns there is much oversimplification, since the hospital and the

vendor can negotiate some sharing of responsibilities. It is important

to recognize, however, that the hospital, in contracting for services,

is making a decision about the centralization of responsibility for data

processing. If the hospital contracts with a facilities management service

or a service bureau for exclusive responsibility for the hospital information

system, it has made a commitment (though not an irrevocable one) to a form

of centralization which should be judged by the same criteria as the

centralized system of a manufacturer with geographically dispersed plants,

or a large bank with several branches, or a VA hospital system with

multiple installations.

Historically, the strategy of centralization through contracting with

service vendors has proven to be a productive one for community hospitals

in the past decade, particularly in the financial applications. The recent

survey conducted for the Hospital Financial Management Association by

Chervenak, Keane & Company shows that 87% of hospitals have computerized

payroll processing, 47% through contracts with outside EDP services, and

28% through in-house standard computers and 12% through in-house minicomputers.

"Greatest increase in computer usage is in accounts receivable, inpatient

billing and outpatient billing. For accounts receivable, 32 percent reported

using outside service centers, 31 percent in-house standard computers, and

15 percent in-house minicomputers. Utilization of computers for inpatient

billing is fractionally less." The report stresses the increased development

of service bureaus specializing in hospital applications in the last seven

years.

Unlike 1970, pre-programmed "packages" are now available forvirtually all the basic financial applications, and for manyadministrative and related areas. This minimizes the time andexpense which must be spent by the staffs of individual hospitalsin system design, programming, debugging, and testing. (Chervenak, 1977)

Another development noted in the Chervenak report is an increase in the

number of hospitals which combine purchased services

applications, and hospitals which purchase different

applications. Although the report does not quantify

it notes that "the total of responses indicating use

responses indicating use of outside services exceeds

that some hospitals use their own computers for some

services for others."

These developments can be expected to continue.

Corporation reports that the medical computer market

compound annual growth rate of 19% which will result

million in 1974 to $450 million by 1980. Accounting

with in-house

services for different

these developments,

of in-house computers and

100 percent, showing

applications and outside

The Theta Technology

is experiencing a steady

in growth from $174

applications are now

65% of these data processing systems, but the main growth will be in turnkey

services and mini-based computers (Computerworld, Aug. 30, 1976).

The improvement and easy installation of vendor services and packages

has brought about a significant change in the allocation of responsibility

for systems management. As the systems management column of the table on

page 14 suggests, the hospital delegates some of the responsibility for

planning and hiring when it contracts with a service vendor, particularly

when it contracts with a facilities management service, and to a diminishing

degree with the other services vendors in the column. But the hospital as

a whole retains the responsibility for overall planning for data processing,

hiring of its own personnel, and control of the utilization of the

computerized service. If we now look at the delegation of responsibility

for systems management within the hospital, we can see a change which has

been brought about by the improvement and the increased availability of

commercialized modular services and packages.

To the extent that the purchased service or package can stand alone

as an independent module, the hospital can delegate responsibility for someaspects of/systems management to the user department. This tendency is particularly

pronounced in the accounting department and in the clinical laboratories.

As "off-the-shelf" packages and turnkey systems improve, the business

offices and the laboratories become less dependent on data processing staff,

more knowledgeable about their own computer needs and capabilities, and more

capable of planning and controlling their own computerized functions.

The development of laboratory turnkey systems based on dedicated

minicomputers can be expected to accelerate this tendency in the future.

If it is possible to plan the necessary interfaces with the order entry

system from terminals in admissions and nursing stations and with the

billing system, the operations and management of the laboratory systems can

be almost entirely decentralized within the hospital organization, precisely

because systems development is fully "centralized" at the vendor's location.

In effect, many hospitals are developing a de facto distributed network

based on purchased services for the financial functions, dedicated

minicomputers for ancillary services, and a data communication system

connecting patient accounting and patient care functions with the financial

applications and with ancillary services. The Massachusetts Hospital

Association, for example, offers a service bureau contract for financial

applications ("Concept I") and a minicomputer turnkey system under a

contract with Huff, Barrington, Owens for data communications ("Concept II"),

which can connect terminals in the admissions office, nursing stations, and

dietary services. McDonnell Douglas offers a similar arrangement, with

remote financial services and a minicomputer in the hospital for communications.

The typical configuration is that of a "star" network:

Figure 2. Characteristic Functional Design

Patient AdmissionECensus Patient Care

Financial TransferApplicationE Schedulin g Nursing Stations

UtilizationGen. Ledger Statistics

Clinical Labs

Payroll

A/P Purchasin Pharmacy

A/R & billing Data CommunicationsRadiology

inpatient- - - - - - - - - -

outpatient3rd party D B M S EKG

Services Blood Bank

Food ServicesHousekeeping Patient moni"

Maintenance toring OR, D

Central Supply Intensive Car

The dotted line surrounds a data base management system which many managers

envision as a desirable way to complete the system, as soon as a dedicated

minicomputer can be developed with adequate software to handle medical

records (Blois and Henley, 1971, Blois & Wasserman, 1974, Ball & Hammond,

1975).

The imagined result would be an integrated system that fulfills many

of the objectives of the older, centralized "total hospital information

system" based on a large central computer such as Technicon turnkey

system or the successful centralized in-house systems described in Collen's

collection (1974). (For a partial evaluation of the often-cited Technicon

installation at El Camino Hospital see Norwood, Hawkins, & Gall, 1976). The

difference is not simply a matter of hardware. It is partly a matter of

implementation through time, a modular approach based on stand-alone systems

which are progressively connected, rather than a collection of interdependent

programs which are designed to be implemented together (see Barnett, 1975).

And it is partly a difference in the configuration of centralized and

decentralized responsibility for systems development, operations, and

management, The modular system is "distributed" not only in the sense that

the computing power is put physically close to the users, but in the sense

that the responsibility for some aspects of planning and control is assigned

to the user departments, while responsibility for long-range planning, coor-

dination, and financial control is assigned to the central hospital

administration.

These developments in hospital data prodessing run parallel to developments

in large corporations in the private sector. Although the size of the hospital

organization is much smaller, the diversity of its functions makes it even

more complex, particularly in the tension between pressures toward integration

around a record of the progress of the patient through the health care

system.

Hospitals that follow the present tendencies toward modular

development of a system which is gradually integrated into a distributed

network configuration should be aware of some of the possible pitfalls

in the path. Multiple vendors create multiple problems, particularly

at the interfaces between application subsystems. Standards for data

linkages between the subsystems should be carefully specified in

advance, and responsibility for maintenance should be clearly articulated,

to avoid "finger-pointing" in case of inadequate performance. The

centralization and decentralization of common data elements must be

carefully planned. Some redundancy of data can have advantages in

increasing the efficiency and independence of the subsystems, and in

securing against the loss of data in case of breakdowns; but it can

create problems if the shared data is to be changed or updated. A central

communications processor can help in reducing redundancy and in maintaining

compatible interfaces. The advice of Anthony Waswrman (1974) on this

subject is cogent:

A communications processor is usually necessary if the medicalinformation system is designed to support terminals on theindividual wards of a large hospital. It can serve as thecentral recipient of all requests from the wards, multiplex theterminals, and switch information requests to the varioussubsystems and can begin to concentrate some of the data heldin the individual subsystems. This concentration offersnumerous advantages, including a reduction in total informationflow, yielding improved system performance, and reduction intotal data stored, resulting in lower storage costs....

One general conclusion is clear: if hospital subsystems areindividually designed for eventual operation in an integratednet, the ease and economy of doing so is maximized. If hospitalsubsystems are developed sporadically, at random, and withoutconstraint as to standards, they can still be integrated into

a net, but the cost of doing so will be much greater, and mayexceed the aggregrate cost of developing the subsystems themselves.

Canning (1976) adds additional warnings. If some of the responsibility

for systems management is given to individual departments, they may

begin to want their own computer operators and programmers "to serve

local needs." System reliability is often improved by a distributed

network configuration, since the breakdown of one element does not

affect the entire system; but plans for backup must be carefully thought

through:

The system designers must consider each component in thechain -- from the remote terminal to the central processor atthe top of the hierarchy (if the network is designed thatway). The fall back mode of operation must be spelled outunder the assumption that each component fails. That is,what is done when the terminal fails? When the terminalcontroller fails? When the communications line to the node

processor fails? And so on.

Finally, costs of decentralized systems must be thoroughly investigated,

and comparisons made between alternative system configurations. Canning

points out that the present economies made possible by minicomputers

may result from a temporary superiority in technology. In a more

advanced state of the art, large computers may regain their cost

advantages, and the pendulum may swing again in the direction of

centralization.

The historical dynamics of changing pressures in the direction of

centralization and decentralization of systems development, operations,

and management can be expected to continue in the future. As Ronald

Henley states (1975):

There are several counter-balancing forces at work in the

computer industry and in the medical information science fieldthat will probably always, not only allow, but encourage, both

the development of systems that are oriented about large central

computers and networks of small modular systems. The field is mostcertainly more than big enough for both. I feel that as the minicomputer field develops adequate operating systems, languages, andsoftware, a tendency to use extraordinarily large but inexpensive,single mini computers to support some hospitals will arise thuscreating perhaps a trend from the modular systems back to thesingle processor. However, the advent of the newer micro processorsthat support four to eight terminals will again turn the economictide back the other way. Thus, there will be a continual oscillatingtendency, and because of the lengthy time to develop medical systems,we will always see a mixture of both types; eventually, the steadystate will undoubtedly end up having many of both.

Henley's stress on the lengthy time to develop systems is a useful

reminder that planning for an information system is constrained by the

history of the organization as well as by the current state of the art of

data processing.

The issues of centralization and decentralization along the three

dimensions of data processing will recur in the subsequent chapter on

the decision process. The foregoing summary of developments in the last

ten years has stressed the pressures that tend in the direction of modular

planning, distributed system configurations, and delegation of systems

development to vendors. The reader may agree or disagree with these

emphases. The more important point to be made is that the decision process

should be guided by an awareness of the several dimensions along which

the managers must make the decision to centralize or decentralize

responsibility.

Chapter 2. The Decision Process

The design of the decision process proposed in this chapter

is an iterative one, to be repeated each time the hospital encounters

the need for a major change in the computerized information system,

whether that change is the replacement of a financial package, a new

laboratory turnkey system, or a new admitting system involving changes

of personnel and in the working relationships of departments to one

another. The design is based on various articles on decision making

for hospital information systems (especially Dunn, 1974, Pomrinse,

Reps, and Slavin, 1976, and Davis and Freeman, 1977), and on interviews

with administrators from Salem Hospital, Salem, Massachusetts.

Assumptions made at the outset of the decision process inevitably

influence the outcome. One of the most critical points is the decision

about who is to decide. A wise administrator will recognize the tendency

for the plan to mirror the structure of the planning group. A decision

process dominated by a single persuasive advocate for data processing is

likely to produce a centralized plan, and a diverse, loosely coordinated

planning committee is likely to produce a decentralized plan. It is the

administrator's responsibility to judge the effectiveness of the present

distribution of responsibility processing as he or she assigns the tasks

of reviewing the present system and planning for the future.

It is important to recognize the tendency for the issue of

responsibility for operations management to be decided early, without

adequate debate or weighing of evidence. The hospital administrator

who initiates the decision process may wish to confront the issue openly

at the outset, by assuming responsibility for planning, personnel

management and control himself; by distributing these tasks to a planning

committee and to existing offices in the hospital; or by opening the

issue to debate. Alternatively, he or she may want to delay the decisions

about operations management until the configuration of the functional

system has been decided. If this is the strategy chosen, it will be

important to recognize and control the political processes which tend

to settle the issue prematurely.

A frequent compromise is to constitute a planning or steering

committee which cuts across the functional areas of the hospital,

including members from the financial, nursing, and laboratory staffs,

as well as from the data processing department, if there is one, and

possibly representation from the physicians as well. A strogg advocate

of data processing is a useful member of the group, though it may be diplomatic

not to make him the chairman. In order to reserve judgment on the issue of

operations management, the responsibility of the committee can be cir-

cumscribed and defined as advisory to the chief administrator of the

hospital, rather than as executive.

The design proposed in this study assumes that the process will be

guided by a steering committee. The membership of the committee

will naturally vary according to the scope of the decision to be made. If

it is a choice of a service bureau for electrocardiogram analysis, the

laboratory director can be expected to undertake most of the work, with the

help of his staff. If it is the design of an automated medical record system,

the committee will have to cut across departmental lines throughout the

hospital, as the medical record itself does. The committee may be formed

ad hoc, or it may be a subcommittee of a permanent long-range planning

committee for the hospital information system.

An increasing number of hospitals are using the services of outside

consultants for a formal data processing audit. Chervenak (1977) reports:

One of the survey questions was whether or not the hospitalhad an external audit of the effectiveness of its data processingoperations within the last year. (It was explained that thisis separate from an internal control audit Of hospitalsusing data processing, 39 percent reported that they do useeffectiveness audits.

An EDP audit can be a useful adjunct to the evaluation of the present

system. But the focus of the evaluation effort as a whole should be

on setting managerial goals, not simply measuring efficiency retro-

spectively, and the managers should not assign all responsibility for

the review to the consultants.

A suggested outline for the decision process is presented on the

next page. The actual process is naturally messier, involving more

iterative loops; but- the suggested sequence of steps is both rational

and reasonably accurate as a description of the way in which managers

actually make decisions.

Externalice Intellig

needs survey

onal Feas

gn Altern

Choice

update long-rangeplan

Implementation

Evaluation- -I

Outline of the Decision Process

Preliminary

Evaluation

set goalsguidelinescriteria

ence

options

ible

at ives

Functi

Desi

Figure 3.

I. Preliminary Evaluation

The first step, a preliminary evaluation of the present system,

should generate forward-looking goals while it measures past performance.

Hospitals will differ in the degree of thoroughness with which they carry

out the evaluation, depending on how much has been automated already,

how recently the system has been evaluated, and how pressing the need

for change is seen to be. In any case, the outcome of the preliminary

evaluation process should be a measure of previous progress, a soberly

optimistic hierarchy of objectives for the future, and a set of criteria

to be used in judging the options. Among these criteria should be con-

siderations such as the following:

o Cost displacement and cost recovery may come first, as the

most persuasive marks of success. Experience has shown

that most data processing changes do not save money in

simple, straightforward ways. More often, they allow a

growth in services without an increase in total expenditure,

and they replace labor costs by machine costs, with

some gain in the recovery of previously lost charges and some

gain in effectiveness from the transfer of personnel from

manual processing to more productive tasks.

o Improved administration involves such considerations as

managerial effectiveness in planning, budgeting, and control

which may result from more accurate and timely information.

These gains require planning, however, and they do not result

automatically from computerization of routine tasks (Davis

and Freeman, 1977). The organization can adapt to increased

demands for accountability from third parties, federal, state,

and local governments, and the public generally without an

increase in personnel.

o Medical care can be improved through indirect benefits of

data processing in shortening length of stay, coordinating

the efforts of various staffs and services around the progress

of the patient, and freeing professional employees from some

of the distractions of paperwork.

o Education of hospital personnel is an indirect benefit of data

processing. The increasing sophistication of the staff in

computer applications can facilitate future adaptability and

allow for the gradual evolution of an effective organizational

structure for computerized information. The hospital should aim for

computer sophistication in all departments, not simply in the data

processing department or the controller's office.

The last step in the preliminary evaluation is an extension of the

goal setting process, but distinct because it begins to focus on

immediate action. It translates goals into more immediate objectives,

establishing guidelines in the form of "willingness to pay" limited

amounts of money for the more urgent needs, which are now specified with

more precision (Dunn, 1974). Time constraints should be set, and preliminary

effectiveness criteria should be formulated to guide future evaluation.

(For a persuasive argument on this point, see Keen, 1975). At the end

of the preliminary evaluation, the planners should have circumscribed

an area of the hospital, or a sequence of areas, which are to be automated.

Much depends, naturally, on the particular circumstances of the

hospital. A hospital uhich has not yet begun the process of automation

and has had no previous long range plan may want to postpone a decision

about which area to begin with until it has completed some of the detailed

analysis of needs and evaluation of options, the process to be discussed

in the next section. As Blois and Wasserman (1974) point out,

Institutions show a wide variety of individual variation, andthe subsystems first adopted will be those that meet the mosturgent local requirements, or those which are supported most

favorable to the development of such systems, or those where

a department has a financial ability to develop such a subsystem.

Thus, a major determining factor in the choice of subsystems will

be the hospital administration's perception as to where costscan be reduced or local problems can be solved. Another major

determining factor will be the availability of commercial subsystems

which a hospital department can simply acquire, and install, in

the hope that the medical usefulness and cost-effectiveness of

these subsystems has been demonstrated elsewhere.

On the other hand, a hospital which has done considerable planning in previous

years and is reentering the decision process in order to carry out the next

step will want to circumscribe clearly at this point which area is to be

automated next.

As with the question of the responsibility for systems management,

there is a possibility that important choices concerning modularity

and integration will be made prematurely. These choices cannot easily

be localized. It is important for planners to ask at various points

throughout the planning process: "How much do we want to stress independent

applications which stand alone? What aspects of integration must be

planned ahead and how much can be postponed?" Again, hospitals will differ,

according to their progress in formulating and implementing a long range

plan; but the questions naturally arise at this point and again after the

analysis of needs and the detailed examination of available options,

when the long-range plan is updated.

II. Intelligence and Design

The intelligence phase of the decision process is complicated

in a setting like the hospital, where it is important to look

simultaneously at the needs of the organization and at the commerically

available options.

The Center for Information Systems Research at M.I.T. stresses

the useful concept of the Logical Application Group in analyzing the

needs of the organization.

A Logical Application Group is, in general, a complete applicationsystem, such as order entry. In some cases it may, however,be an application sub-system (e.g., only order editing, creditchecking, and inventory updating) or, rarely, a single application.As a result, although there usually is some transfer of informationbetween LAGs, these transfers are minimal and well defined. Transfersof data within each LAG are, on the other hand, relatively intensive -i.e., the applications within each application system interactextensively (e.g., in the order entry family: billing, A/R, etc.).(Rockart, Leventer, & Bullen, 1976)

The concept of the LAG is relatively straightforward in an organization

which plans to have all computer programs custom-written to specifications

based on a model of the logical information flow. It is more complicated

when the organization allows system development, and therefore the definition

of the LAG, to be done by vendors.

The diagram of the decision process on page indicates separate

boxes for the "internal intelligence" process of analyzing the hospital's

needs and the "external intelligence" process of inspecting commercially

available systems. In fact, the processes must be carried out in parallel,

by one common group of planners, who must allow the commercial options to

help define the hospital's needs. A planning group which allows the

structure of present manual or automated information flows to dictate too

severely the form of the computerized system may restrict its choices

unnecessarily to the more expensive options, in-house development or

highly customized packages or turnkey systems. On the other hand,

a group which simply allows the vendor to define the Logical Application

Groups may have difficulty comparing differently structured options, and it

may find unanticipated problems during implementation of the system.

In some areas, hospital procedures and the relationships among

professional staffs are similar enough from one hospital to another

that the larger decision units are relatively clearly demarcated, and

competition among vendors tends to foster standardization. A financial

package may include programs which differ in detail from those of another

vendor, but the boundaries of the package, surrounding general ledger,

accounts receivable and billing, accounts payable, and payroll are similar.

A hospital may decide to leave payroll out of this LAG and let it be

handled separately, by the bank for example; and it may find that different

vendors have quite different ways of handling the purchasing office and

inventories for central supply. Less standardized applications,

particularly those in the areas of patient admissions, patient care, and

communications, are likely to differ more markedly from one vendor to

another, and more flexibility will be necessary in defining the boundaries

of the LAG, for purposes of comparison.

Interfaces between Logical Application Groups must be inspected

carefully. It is important to think through in detail questions about

the format of data to be passed from one subsystem to another, frequency

and criticality of communication, sharing of databases, and organizational

issues. The question "Who needs the information, and when?" goes beyond

choices among batch, remote-job-entry, and on-line systems to decisions

about the number of terminals needed and the scheduling of peak work times.

At this point it may be useful to summarize the answers to questions

about the needs of the organization, with respect to the LAG under

consideration, in the form of the advantages and disadvantages of

centralized vs. decentralized development and operations. The two charts

on pages 33 and 34 may be helpful. The first chart, based on discussions

in the literature on the centralization-decentralization debate, the CISR

Working Paper #23 (Rockart and Leventer, 1976), and articles on hospital

information systems, summarizes the advantages of vendor development vs.

in-house development; vendor operations vs. in-house operations; and

within in-house operations, a centralized data processing site and

personnel vs. decentralized (or distributed)operations. Shared services

are treated like other vendors; that is, the vendor is the consortium.

The manager will recognize ways in which different options require different

emphases. The manager is invited to use the chart as a checklist of issues

to be explored, and as a way of sorting out the factors favoring one con-

figuration or another for this Logical Application Group.

The second chart, on page 34, looks more closely at situational

factors pertaining to the particular hospital and the particular LAG

being considered. It is presented in the form of a scoring sheet. The

manager is invited to circle a number next to the considerations which

are relevant. In some cases, a choice between numbers allows the manager

to weigh the factors more or less heavily. The numbers have about as

much reliability as those in personality tests found in family magazines,

Vendor Development In-house Development Vendor Operations In-house Operations

Centralized DecentralizedClarity & variety of choice. System can be tailored to Lower start-up costs Hardware and Staff Hardware and Staffproduct can be seen before hospital Less long-term comsitmentbought Innovative research can to hardware Economics of Sale User can control his

Cost comparisons are clear attract outside funding No personnel turnover less inefficiency from un- own computing.fewer hidden costs Less disruption of worries even use, less wasted cap- Lower hardware and in-

Shorter time to implement standard proceedures. Fewer certificate of need acity, less redundancy of stallation costsand begin using DP staff can educate users, problems operating system software Costs & benefits easilyEasily introduced to naive Integration of system can New technology is vendor's Small user access to large tied to programsusers. Vendor can help be tailored to hospital responsibility to judge CPU Encourages modularGreater flexibility: can Programs can be tailored to Less empire-building in Easier to maintain stand- approachchange vendors managerial use and decision DP departmen: ards for system integra- Less skilled operations'Modular growth is easy support Fewer space a-id logistical tion personnel requiredSome integration problems Continuity of effort problems Sharing of central data Users encouraged tocan be solved by vendor Costs of obsolescence are base easier; less data develope expertise

Low risk of failure in smoothed redundancy Greater systen rlia-implementation User education partly Fewer communication costs bility: breakdowns

Fewer problens of uneven done by vendor and problems are localizedaworkload for personnel

Less flexibility: larger Software limitationsNo package satisfies all Costs(tine & money) hard Telecoimunication costs & longer coneitment to of minis ay restrictneeds to anticipate, Large hid- If several veadors, hardware flexability. Mini may

Customizing can be ex- den costs, longer lead responsibility can be Users have less control, be too small for job,pensive time necessary unclear acquire DP skills more or if big cnough, nayInterfaces with in-house Higher risk of failure Interfaces with in-house slowly have wasted capacityand other vendors' in implementation can be difficult Political problems: User DP skills may beapplications may be hard More top mgt. involved Database hard to centralize responsiveness to users inadequateto plan Mistakes hurt longer and maintain Peter-principle effects Backup problems require

Programming capability of Political problems: empire Less DP educa:ion of staff More expert personnel detailed planningstaff is not enhanced, building. unresponsiveness needed Redundancy of data,

to other depts problems of updatingPersonnel problems: turnover Staff expertise harderinefficiency from uneven to share with otherworkload dept.

Vendor's profits Space problems Diversity may be hard toinefficiencies add to Harder to adapt to new tech- manage: multiple vendors

costs nology multiple serviceLess learning from other contractshospitals' successes & Standards for interfacesfailures hard to plan & maintainInflexible: hard to reduce Security problems:coa itment & costs accessInefficiencies burdenhospital directly

Vendor Development In-house Development Vendor Operations

Standard packages areadequate to needs

Users lack DPsophi.tication

Hospital is medium-sized or small

DP staff has notproved developmentcapability

Application usesstate-of-the-art,rapidly changingsoftware technology(e.g. communications,DBMS)

lor2

lor2

1

lor2

Capable DP staff hasalready developedsuccessful programsin other areas

Special needs ofhospital can't be metwith packages

Large teachinghospital

Dev't cost can beshared with otherhospitals

1,2 V.A. or militaryor3 hospital or

proprietary chain

Skilled operators hardto hire & keep

Hospital just beginningto automate

Vendor is -;eographicallyclose

Application uses rapidlychanging hardwaretechnology

Hospital is medium-sized or small

Hospital is risk-averse

Hospital lacks spacefor hardware

TOTAL TOTAL TOTAL

In-house OperationsCentralized Decentralized

lor Capable DP staff al- lor Departments have DP2 ready in place 2 sophistication

1 Large CPU required lor Dept'al control is2 important for fast

1 Large memory required turnaround time,reliability

2 Vendor-developed pro-grams assume central 1 lospital services geo-operations graphically dispersed

1 Central hardware can 1 Dept. has outside re-be efficiently used search fundingfor additionalapplications 1 Teaching hospital with

traditionally in-lor Problems with standards dependent depts.2 at interfaces

-1 Communication of data tolor Database is shared with other depts. is complex2 other LAGs

-1 Problems of redundantor-2 data bases

Subtotal Subtotalcent. operations I decent. operations

TOTAL In-houseTOTALT(OTALTOTAL

Facilities Mt.hardware in

vendor location

Service Bureau ServiceBatch and -RJE Bureau

on-lineintelligentterminals

Service Bureau RegionalCustomized servicespackages develop

advantages of4-- vendor operations

Leased time-sharing for programsdeveloped in-house

Figure 6.

04-

0~44 -4

sharedcooperament

4)

0

;. 4-

Facilities Mgt.with in-house Off-the-hardware shelf software

packages run onhospital's hardware

Turnkey services withsome customization

Customized softwareLtive on hospital

hardware

advantages ofin-house operations--->

In-house applicationsbased on programsdeveloped elsewhere

Programsdeveloped in-houserun on hospital

hardware

Alternatives Mapped on the Dimensions of System Development& System Operations

(Units correspond very roughly with totals on the "Scoring Sheet",

A third dimension might represent centralized vs. decentralized

operations within the hospital. For example, a Technicon turnkey

system run on a central IBM 370 would be high above the plane of

the paper and a turnkey dedicated-minicomputer laboratory system

would be below the plane of the paper.)

36

but they may help the manager to see a pattern which favors one configuration

over another.

A rough graphic display is provided on page 35 for anyone who wishes

to play further with the idea of quantifying the factors favoring different

locations for system development and operations. The horizontal axis

represents the continuum between vendor operations and in-house operations.

The vertical axis represents vendor development vs. in-house development.

The units correspond roughly to the totals at the bottom of the scoring sheet

for situational factors.

The next step in the "internal intelligence" process is a transition

to the "design" phase. The planners should summarize the investigation

so far in the form of a sketch or series of sketches indicating the range

of functional designs which seem appropriate at this point. The sketch

does not need to specify the hardware, but it should show the logical

topology of the system, in order to indicate how the LAG under consideration

relates to sub-systems already in place and others in the long-range plan.

Turning now from "internal intelligence" to "external intelligence"

(and remembering that these processes overlap and are at least partly

concurrent), the planners can begin to survey the options. The procedures

here are relatively obvious: proposals should be solicited from vendors

(for listings seethe Systems Dimensions Ltd. monograph, "Information Processing

Applications...,"1974). Brochures should be read carefully, with determined

skepticism; salesmen should be not only listened to but cross-examined system-

atically, and sites which successfully use the systems should be visited

(with and without the salesman). If in-house development is a lively option,

prototype programs should be studied, and comparable installations at

other hospitals should be carefully inspected.

As this process goes forward, in parallel with the examination of

the hospital's needs, it should be possible to begin narrowing down the

choices. Pomrinse, Reps, and Slavin (1976) represent this process in the

diagram below.

STUDY TEAMACTIVITYPROGRAM

DECISIONCHECKPOINTS

STEERINGCOMMITTEEMEETINGS

MEETINGSWITH HOSPITALDIRECTOR

INFEASIBILITY INFEASIBILITYDECISION MAY DECISION MAYBE MADE HERE BE MADE HERE

DECISION MAYBE MADE HERE

Figure 7. Feasibility Investigation Process

Their description is useful in specifying activities on three levels:

meetings with the hospital director; meetings of the steering committee;

and activities of the study team, which is a subcommittee of the steering

committee. And it indicates decision points, at which a decision concerning

the feasibility of a given system might be made. This process can be re-

peated for all the systems to be investigated. If the steering committee

has been divided into a number of study groups, the investigation of several

systems can take place concurrently.

In examining the systems offered by vendors, the study groups should

take the initiative and question the salesmen and preferably also hospitals

which presently use the system, pressing for detailed responses to a

list of performance criteria developed by the hospital. A sample

list for the patient billing and accounts receivable system, taken from

King (1975) is reproduced on the next page.

Figure 8. Features to Consider in Package Evaluation

(patient billing and accounts receivable system)

" ability to process various types of patientaccounts

preadmissioninpatientdischarged patientemergency roomone-time outpatientsrecurring outpatientsdoctor or institutional accountsbad debt accounts

* quality of audit trail from patient billsand other reports back to the charge slip

* flexibility with regard to business officeorganization and philosophy

" quality of data validation and other con-trols

" ability to produce interim billings for in-patients

" ability to produce cycle bills and follow-up statements

" special reporting capabilities* means of handling monthly payment ar-rangements

" availability of automatic write-off feature" quality of error reporting and controls

over re-entry of corrections" ease of operation and control of census

reporting and room change generation

The end of this process should be the identification of

one, two, or at most three systems which have been judged feasible for

the Logical Application Group. On the "external" side, as earlier on

the "internal" side, this phase involves a transition from "intelligence"

to "design" in the decision process. The previous sketch of the func-

tional design can now be combined in detail with a sketch of the

software (and hardware, in the case of facilities management and

turnkey systems) offered by each vendor, or by the in-house option.

By this point, the alternatives with respect to the location of

systems development and systems operations will have become clear. The

questions of systems management should also be reviewed before proceeding

to the final choice. How much responsibility for the final choice should

be given to the department which will principally use the system, the

controller's office, for example, or the chemistry laboratory? If

computer operators or technicians are necessary, who will be responsible

for hiring and training them? If existing staff members are capable

of operating the system, how should their duties be defined? How are

the costs of the system to be recorded and controlled? The answers

may vary, depending on the system chosen, but the questions should be

kept in mind during the process of choosing.

III. Choice

As the CISR Model for Decision Making (Rockart, Leventer, and Bullen,

1976) suggests, the final evaluation depends on three measures of performance:

cost - of performing a given process

time - to develop and implement the process

effectiveness - of the specific alternatives.

Costs should include the initial investment, monthly operating costs,

and costs of future expansion, as far as they are foreseeable. Indirect

costs and benefits should be at least roughly estimated in the form

of the time expended by personnel, or released by the changeover from

current procedures. An estimate of the risk of cost overrun is important,

particularly if there is a difference in this respect between two

alternatives (as there might be for example if the choice is between

in-house development and a service bureau).

Time to develop and implement the system should also include an

estimate of the risk of overrun. The estimates should be based not only

on the promises of vendors, but on the experiences of hospitals which

have chosen comparable systems.

Effectiveness includes many of the considerations brought up

previously in the "intelligence" phase. It is important, however, to

summarize the criteria and the expected performance of alternative

systems in a way that will clarify the choices and tradeoffs. The

evaluation sheet developed by Baker and Bakewell (1974) can be useful.

It is based on Donald P. Kenney, Minicomputers: Low-Cost Computer Power

for Management, 1973, and designed specifically for minicomputer appli-

cations. But the criteria apply equally to service bureaus and to in-

house development. The Baker & Bakewell evaluation sheet has the added

advantage of including estimates of the reliability of the vendor organ-

ization. The sample evaluation sheet on pages 42, 43, 44, and 45 has been

Figure 9. VENDOR EVALUATION SHEET

Rating values: 10-excellent; 8-very good; 6-good; 4-average or nominal value;2-poor; 0-unacceptable.

A rating of zero for any asterisk factor is cause for rejection, regardlessof overall score.

FACTOR RATING SCOREEVALUATED WEIGHT A B C A B C

I. Vendor Organization (40%)*Stability(years in business, project as aper cent of hospital business..... 4 10 4 10 40 16 40

*Financial rating................. 3 10 2 10 30 6 30

*Experience with similar systems.. 7 2 8 4 14 56 28

*Client satisfaction.............. 4 2 8 2 8 32 4

Maintenance and software support.. 5 2 10 2 10 50 10

Timeliness of delivery............ 2 4 4 4 8 8 8

Quality of proposal (revealedlevel of understanding)........... 4 6 8 6 24 32 24

Level of staffing andmanagement for project............ 3 6 8 2 18 24 6

Project plan and organization..... 2 6 6 6 12 12 12

Quality and cost controltechniques........................ 1 8 4 8 8 4 8

Experience with proposalhardware/software................. 5 2 10 8 10 50 40

Subtotal 182 290 210

- -4.----

VENDOR EVALUATION SHEET (Cont.)

II. Proposed System (60%)A. General (25%)

*Suitability for user's intendedsolution(such as specifiedvolume,timing,inputs ,outputs,storage, retrieval,routingcontrols,recovery,interrupts)...... 8 6 8 4 48 64 32

*Capability compared to cost....... 3 6 8 8 18 24 24

Simplicity......................... 1 8 8 6 8 8 6

*Compatibility..................... 2 10 6 8 20 12 16

Scheduling (realism,mileposts,accountability).................... 1 6 8 6 6 8 6

Ease of installation, cutover plan. 2 6 8 10 12 16 20

Consideration ofalternatives/trade-offs............ 1 4 6 6 4 6 6

Training........................... 1 4 8 8 4 8 8

Documentation..................... 1 2 4 2 2 4 2

Growth potential................... 2 6 8 4 12 16 8

Backup/recovery.................... 3 6 8 6 18 24 18

Subtotal 152 146 190

VENDOR EVALUATION SHEET (Cont.)

FACTOR RATING SCORE

EVALUATED WEIGHT A B C A B C

II. Proposed System (60%)B. Sof tware (20%)

*Suitability to problem (such ascontrol, security, error handling,translation, file organization,formatting, sorting, updating)..... 7 8 8 4 56 56 28

Modularity......, ................... 2 8 8 8 16 16 16

Use of previouslydeveloped hardware................ 4 6 0 6 24 0 24

*Ease of revision andmaintenance .... .... ............... 4 4 8 2 16 32 8

Versatility..... . . ............ 2 4 8 2 8 16 4

Report, printing, file, record-keeping capacity..,................. 1 8 8 2 8 8 2

128 128Subtotal

VENDOR EVALUATION SHEET (Cont.)

II. Proposed System (60%)C. Hardware (15%)

*Suitability to project(such as terminals, computer,peripherals, capacity)......... 5 4 8 2 20 40 10

*Performance compared to cost(storage capacity, speed,redundancy)................... 2 8 8 8 16 16 16

*Reliabilipy................... 2 4 6 4 8 12 8

*Maintainability andmanufacturor support........... 2 4 6 6 8 12 12

*Number in use............... 1 2 4 4 2 4 4

In-house experience............ 1 2 4 4 2 4 4

Ease of changingconfiguration...... ............ 2 6 6 6 12 12 12

subtotal 68 100 66

SummationSubtotal ISubtotal II-ASubtotal II-BSubtotal II-C

Total (1,000)

182 290 210152 190 146128 128 8268 100 66

708 1504I - - __ I -

522

filled out with hypothetical ratings for three options, A, B, and C.

As with the summary of advantages and disadvantages and the scoring

sheet for situational'factors, the manager is invited to regard the

numbers skeptically. But the evaluation sheet can be useful in spec-

ifying measures of effective performance, and in revealing trade-offs

between factors which may produce an overall superiority of one system

over another.

Having completed the process of choosing among the final alter-

natives, the steering committee should revise and up-date the long

range plan, in order to guide future iterations of the decision process.

And they should formulate the expected performance criteria of the

chosen system in a way that will guide the future evaluation process.

As Keen (1975) suggests, these criteria should explicitly include in-

direct benefits such as education of users and changes in organizational

behavior, as well as more easily measurable criteria of performance

effectiveness.

Following completion of the decision process, the planners can

proceed to implementation and thence to evaluation, which are steps

that lie beyond the focus of this study. It is important to recognize,

however, that the entire process is iterative, and that a new cycle

may be begun after the evaluation of the new system is completed:

47

Preliminary

Evaluation

set goalsguidelinescriteria

ExternalIntelligence

needs wlo survey options

401-n Feasible

Alternatives

il

Clptce

updoat lng-range

ITp ementation

Evaluation

Figure 13. Out1tpe of the Jterative Decision Process

The iterative pattern facilitates modular planning, while the

emphasis throughout on interfaces between subsystems, and on the relation-

ships between the individual Logical Application Group and the long-

range plan, facilitates eventual integration of the entire system.

The decision process outlined here can be adapted to the use of

hospitals that are just beginning the process of computerization, as

well as to hospitals that are well advanced. Depending on the definition

of the Logical Application Group to be considered, it can be adapted

to a highly modular large teaching hospital with many decentralized

computer applications, or to a smaller community hospital modestly

planning for a single service bureau or turnkey system. It could even

be adapted for use by planners who envision a total hospital information

system, based on centralized in-house development and operations. For

the reasons summarized in the first chapter, that approach does not

appear to be suited to the present state of software and hardware

technology. But the decision process, as outlined, does not require

prior commitment to any particular philosophy in the continuum of modular

vs. integrated systems, or centralization vs. decentralization.

As all writers on computerized information systems agree, the rate

of change which has prevailed in the last decade is likely to continue

in the next. The iterative decision process which has been outlined

here is designed to take advantage of the opportunities provided by

change, in planning for a flexible system which can adapt not only to

present but to future needs.

References and Selected Bibliography

Anderson, John, "King's College Hospital Computer System(London)," in Morris F. Collen, Hospital Computer Systems,New York, 1974.

Baker, John D., and Geoffrey Bakewell, "Mickey or Mini,"

Hospital Administration in Canada, Oct. 1974.

Ball, Marion J., and G. L. Hammon, "Maybe a Network of Mini-Computers Can Fill Your Data Systems Needs," HospitalFinancial Management, April 1975.

Barnett, G. Octo, "Massachusetts General Hospital ComputerSystem (Boston)" in Collen, 1974.

Barnett, G. Octo, "The Modular Hospital Information System,"Computers in Biomedical Research, Vol. 4, 1974.

Blois, Marsden S., and Ronald R. Henley, "Strategies in thePlanning of Hospital Information Systems," TechnicalReport #1, Office of Medical Information Systems, Univ.of California, San Francisco, 1971.

Blois, Marsden S., and Anthony I. Wasserman, "The Integrationof Hospital Information Sub'ystems," Technical Report #4,Office of Medical Information Systems, Univ. of California,San Francisco, 1974.

Burnett, Gerald J., and Richard L. Nolan, "At Last, Major Rolesfor Minicomputers", Harvard Business Review, May 1975.

Canning, Richard, "Structures for Future Systems,""EDP Analyzer,August 1974.

Canning, Richard, "Distributed Systems and the End User," EDPAnalyzer, Oct. 1976.

Cannon, Dean R., "The System Integration Experience," inPatient Centered Health Systems, Proceedings of the 5thAnnual Conference of the Society for Computer Medicine,Chicago, Nov. 1975.

Carren, Donald M., "Multiple Minis for Information Management,"Datamation, Sept. 1975.

Chervenak, Larry, "EDP is Up," Hospital Financial Management,Feb. 1977.

Collen, Morris F., ed., Hospital Computer Systems, New York, 1974.

Davis, Lou S., and Joseph F. Terdiman, "The Medical Data Base,"in Collen, 1974.

Davis, Lou S., "Data Processing Facilities," in Collen, 1974.

Davis, Samuel, and John R. Freeman, "Hospital Managers NeedManagement Information Systems ," Health Care ManagementReview, Fall 1976.

Dunn, M. D., "Criteria for Evaluating and Choosing a ComputerSystem," Hospital Progress, May 1974.

"Evaluation of a Modular Hospital Information System," Unsignedarticle, Hospital Progress, June 1972.

Ferderber, Charles J., "A Standardized Solution for HospitalSystems," Datamation, Sept. 1975.

Garrett, Raymon D., Hospital Computer Systems and Procedures,Vol. 2, Medical Systems, New York, 1976.

Giebink, Gerald A., and Leonard L Hurst, Computer Projects inHealth Care,, Ann Arbor, Michigan, 1975.

Harrington, F. D., and M. Buchak, "Insiders Have Fewer HeadachesWhen Outsiders Manage EDP," Modern Hospital, May 1972.

Henley, Ronald R., "Modular Management Information System Researchand Development at the University of California, San Francisco,"Papers presented at the 5th Annual A.H.A. Institute on HospitalInformation Systems, 1975.

Hodge, M. H. "Choosing a Computer System," Modern Health Care,December 1975.

"Information Processing Applications and Planning Models in theHealth Service Sector: A Review of the State of the Art,"Systems Dimensions Ltd., Toronto, 1974.

Keen, Peter G. W., "Computer-Based Decision Aids: the EvaluationProblem," Sloan Management Review, Spring 1975.

Kenney, Donald P., Minicomputers: Low Cost Power for Management,New York, 1973.

King, Alan S., "You Probably Can't Afford Not to Have Your OwnComputer System (If You're a Small Hospital)," HospitalFinancial Management, Feb. 1975.

Mathews, J. B. "Planning for Hospital Information Systems,"Modern Health Care, Dec. 1975.

Norton, David P., "Organizing for the Computer: to Centralizeor Not to Centralize," Unpublished paper, Index Systems,Cambridge, Mass., 1972.

Norwood, Donald D., R. Edwin Hawkins, and John E. Gall Jr.,"Information System Benefits Hospital, Improves PatientCare," Hospitals, Sept. 1976.

Patrick,,Robert L., "Decentralizing Hardware and DispersingResponsibility," Datamation, May 1976.

Pomrinse, S. David, David N. Reps, and Richard K. Slavin, "Cost-Benefit Analysis of Computer,"

Rockart, John F., and Jerome H. Grossman, "A Managerial Perspectiveon Information Systems in Medical Care Organizations,"Advances in Biomedical Engineering, Vol. 6, 1976.

Rockart, John F., and Joav Steve Leventer, "Centralization vs.Decentralization of Information Systems: A Critical Surveyof Current Literature," Center for Information SystemsResearch Report #23, M.I.T., 1976.

Rockart, John F., Joav Steve Leventer, and Christine V. Bullen,"Centralization vs. Decentralization of Information Systems:A Preliminary Model for Decision Making," Center forInformation Systems Research, M.I.T., 1976.

"RX for Hospital Management: to Buy or Share?" Data Management,Feb. 1975.

Sahin, Kenan, "Keeping Up With... Data Base Management Systemsand Health Care Managers," Health Care Management Review,Winter 1977.

Schmitz, Homer H., "An Evaluation of a Modular Hospital InformationSystem," Hospital Progress, June, 1972.

Soder, Earl, "Service Bureau vs. In-House Computer," HospitalFinancial Manageent, Jan. 1972.

Shelton, Robert,"The State of Information Processing in theHealth Care Industry," Hospital Financial ManagementAssociation, Chicago, 1976.

Van Brunt, Edmund E., Lou S. Davis, and Morris F. Collen,"Kaiser-Permanente Hospital Computer System (San Fran-cisco) ," in Collen, 1974.

Wasserman, Anthony I., "Some User-Oriented Considerations in theDesign of Medical Information Systems," Technical Report#10, Office of Medical Information Systems, Univ. of Cali-fornia, San Francisco, 1975.

Weller, Charles, ed., Computer Applications in Health Care Delivery,Miami, Florida, 1976.

Williams, Douglass A., "The Administrative System," in Collen, 1974.

Withington, Frederic G., "Fourth Generation Computer Systems,"Proceedings of COMPCON, Fall 1974.

Withington, Frederic G., "Distributed Computer Networks -

Prospects and Problems," Unpublished paper, EDUCOM meeting,Nov. 1976.