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.