2003 Schattauer GmbH

Methods Inf Med 1/2003

1
blood bank, intensive care, ambulatory
care, obstetrical and labor and delivery
care, etc.), these monolithic systems have
generally evolved over decades. In this
model, the application programs are aware
of the database structure when they query
for particular items in the database; there-
fore any changes in the database structure
or the presentation layer usually mean that
all the application programs need to be
changed. It is also extremely difficult to
switch platforms or vendors without signifi-
cant effort and simultaneous disruption of
enterprise operations (so called big-bang
approach to change).
In actuality, the architecture of the var-
ious extant systems is not as pure as the
above characterizations might suggest. If
the monolithic system was originally archi-
tected in a way that separated the presen-
tation layer and the database layer from the
actual application code (services act as
intermediaries between the application
code and the database or the presentation
layer), then it is possible to make changes
in the architecture without changing all of
the programs. Even the most monolithic
systems generally have some interfaced
applications; they typically accept input
from at least one modular component
(generally a clinical laboratory system). As
vendors have acquired specialty applica-
tions (e.g. surgery scheduling, blood gas
measurement systems. etc.), they have
begun to interface them to the clinical
information system. This purchase (rather
than build) approach by vendors them-
selves gives credence to the fact that it is
often less expensive to buy and interface an
existing system than to rebuild something
that already exists from scratch.
Building a Comprehensive Clinical Information
System from Components
The Approach at Intermountain Health Care
P. D. Clayton
1, 2
, S. P. Narus
1, 2
, S. M. Huff
1, 2
, T. A. Pryor
1, 2
, P. J. Haug
1, 2
, T. Larkin
1
,
S. Matney
1
, R. S. Evans
1,2
, B. H. Rocha
1
, W. A. Bowes, III
1
, F. T. Holston
1
, M. L. Gundersen
1
1
Intermountain Health Care, Salt Lake City UT, USA,
2
University of Utah, USA
Introduction
In this paper we discuss the benefits and
drawbacks of a component-based, open
architecture approach to building clinical
information systems and describe the im-
plementation of such a system at Inter-
mountain Health Care (IHC) in Salt Lake
City, Utah. By open architecture we mean
the ability to interface multiple different
individual software applications from a
variety of sources (purchased, and inter-
nally developed) to a central unified clini-
cal repository. This foundation architecture
enables an authorized user to see all patient
data regardless of the application in which
they were collected and removes the need
to enter redundant data into multiple
systems.
In contrast to open architecture, we use
the term monolithic to mean that the appli-
cations and the database are tightly inte-
grated because all software applications
have been developed using the same
common environment, development tools,
database definitions, query processes and
structures, presentation layer and user in-
terface look and feel. This approach infers a
single owner of the system development
process and architecture. To many, the
terms monolithic and integrated have simi-
lar meanings (1). This monolithic approach
is used by most commercial vendors, and,
until recently, most internally developed
systems (2-7). Because it takes so long to
develop all of the programs necessary to
support the provision of health care in a
variety of settings (nurse documentation,
surgery scheduling, patient visit scheduling,
oncology treatment, nutrition support,
pharmacy, clinical laboratory, pathology,
Summary
Objectives: To discuss the advantages and disadvan-
tages of an interfaced approach to clinical information
systems architecture.
Methods: After many years of internally building
almost all components of a hospital clinical informa-
tion system (HELP) at Intermountain Health Care,
we changed our architectural approach as we chose to
encompass ambulatory as well as acute care. We now
seek to interface applications from a variety of sources
(including some that we build ourselves) to a clinical
data repository that contains a longitudinal electronic
patient record.
Results: We have a total of 820 instances of inter-
faces to 51 different applications. We process nearly
2 million transactions per day via our interface engine
and feel that the reliability of the approach is accept-
able. Interface costs constitute about four percent of
our total information systems budget. The clinical
database currently contains records for 1.45 m pat-
ients and the response time for a query is 0.19sec.
Discussion: Based upon our experience with both
integrated (monolithic) and interfaced approaches,
we conclude that for those with the expertise and
resources to do so, the interfaced approach offers an
attractive alternative to systems provided by a single
vendor. We expect the advantages of this approach
to increase as the costs of interfaces are reduced in
the future as standards for vocabulary and messaging
become increasingly mature and functional.
Keywords
HELP, IHC, CDR
Methods Inf Med 2003; 42: 17
On the other hand, the interfaced
systems are also somewhat monolithic. The
developers of such systems generally try to
avoid too much granularity, e.g. they gene-
rally use components that encompass an
entire discipline such as pharmacy, electro-
cardiography, nurse charting or surgery
scheduling. They dont use separate pro-
grams to review problems, transcribed
reports, medications and clinical laboratory
test results; even though all of these data
may come from separate sources.
An institution starting from scratch to-
day has three options. The first is to build all
of the applications from scratch. This has
been a successful model for most currently
existing systems. If an individual institution
were to pursue this approach today, it
would effectively mean duplicating for a
single site, the effort of a vendor that can
spread development costs across many
customers. It should be recognized that in
addition to the expense of such an ap-
proach, the time required until comprehen-
sive functionality is obtained will be exces-
sive.
The second option is to purchase all ap-
plications from a single vendor to insure ea-
se of implementation and seamless integra-
tion. This monolithic approach is probably
the least expensive and least risky in the
short run. It is not without problems how-
ever. One cannot predict whether the ven-
dor will stay in business over the 20-25 year
system lifetime. Switching costs may perpe-
tuate the use of a mediocre system long
past the introduction of new technological
breakthroughs. Perhaps the biggest im-
mediate drawback is that most if not all of the
user constituencies will feel somewhat dis-
appointed with the selected system because
of the need to compromise in the selec-
tion of a single vendor. For example, the
anesthesiologists may have just seen a won-
derful new application at the most recent
national meeting and the contemplated
vendor offering in this area is somewhat pe-
destrian. Even after the best overall vendor
is selected, contracting, implementing, and
training processes can extend for 5-10 years
depending upon the size of the enterprise.
Even if there were no financial limitations,
human beings cannot accommodate chan-
ges that are too rapid.
The third option for people who are not
satisfied with the quality and breadth of the
offerings of a single vendor or the resulting
dependency (all the eggs in one basket and
no control over the pace of technological
evolution) is to build the system from inter-
faced, disparate components and have each
component feed data into or retrieve data
from a common longitudinal repository. In
spite of years of experience and success in
building an integrated monolithic system
(HELP) (7), we have now undertaken
the interface approach at Intermountain
Health Care.
In 1982, Don Simborg and his co-
authors (8) at the University of San Fran-
cisco demonstrated the use of multiple ope-
rating systems on multiple processors that
were bound together via a network to crea-
te a working clinical information system.
In 1988 Simborg (9) published a paper
describing a standard known as HL7 for
linking disparate systems. Since that time,
systems that reflect this approach (10-21)
have begun to emerge. We will now de-
scribe our experience with this approach.
Methods
Intermountain Health Care (IHC) is a not
for profit health care delivery system head-
quartered in Salt Lake City Utah. It opera-
tes 22 hospitals (2500 beds), 72 clinics, and
an insurance plan that covers approxima-
tely 500,000 people. It also coordinates
insurance for another 500,000 people who
are covered by affiliated insurers. Each
year we admit over 100,000 patients to our
hospitals which are located throughout the
state of Utah (and one in Idaho) and pro-
vide for more than 3,000,000 ambulatory
clinic visits. Approximately half of the
people living in Utah are served by IHC.
Until the 90s IHC was primarily focused
on delivering acute care. With the emer-
gence of our own insurance plan and the
creation of a physicians division, which
staffed ambulatory clinics with employed
physicians, we were directed to expand our
in-formation systems beyond the walls of
the hospitals. The options considered were
to remodel the HELP system that had been
developed at LDS hospital and installed at
the other 21 IHC hospitals, purchase a new
system from a commercial vendor, or build
a system from components. For reasons
that we explore in this paper, the last alter-
native was chosen.
Our system architecture is shown in
Fig. 1. We call this system HELP2 to
emphasize that the legacy and philosophy
of the original HELP system are continued
in this new environment. We will now
discuss the various components depicted in
this figure.
Master Patient Index. The foundation of
HELP2 is a central, patient-oriented, clini-
cal data repository (CDR) that IHC co-
developed with the 3M Corporation. All
Clayton et al.
2
Methods Inf Med 1/2003
Fig. 1
An overview of the interfa-
ced architecture used at In-
termountain Health Care.
Each arrow represents one
or more types of interfaces
between component appli-
cations. In all there are 51
different components that
are interfaced. Two-thirds
of the interfaces are for cli-
nical applications and the
rest are for financial pur-
poses.
local identification numbers are maintai-
ned in the master index so that local users
continue to use their traditional numbering
or identification processes to access the
patient data but the data are stored in the
repository using the unique identifier as the
key. We interfaced the hospital and clinic
patient registration systems to the 3M
master patient index and used the associa-
ted services to allow clerical personnel in
those locations to query this index during
the registration process. This connection
allowed the clerks to ascertain whether the
patient was uniquely new to the system or
already existed in our enterprise master
patient index.
Clinical Data Repository Database. The
second part of the clinical data repository is
the patient data structure. The data are
stored as defined codes according to data
models defined for various types of clinical
events. These models are structured using
ASN.1 (22-24), a syntax very similar in con-
cept to XML. Objects can be recursively
nested within an event; this capability
allows reuse of fundamental concepts in
the process of creating broadly generic
data models. In addition to the event object
that is stored using SQL services to access a
Unix-based Oracle database, we also store
references to the individual concepts/ele-
ments of each event in a separate table so
that we can efficiently search for particular
individual elements that may be part of a
larger event. Pointers to waveforms, ima-
ges, scanned documents etc, are stored as
part of the patient record even though they
may exist in a separate file (e.g. a Picture
Archiving and Communication system).
In order to preserve response time at
the point of care, the CDR is tuned to opti-
mize queries for a single patients data.
When one wishes to search across a popula-
tion of patients, we use the Enterprise Data
Warehouse that contains the same clinical
information as the CDR as well as addi-
tional data from the billing and claims
systems.
Health term Data Dictionary. The
Health term Data Dictionary (HDD) (25)
was also developed in collaboration with
the 3M Corporation and its content con-
sists of the uninstantiated data models for
each of the various types of clinical events,
and a set of unique Numerically Coded
Identifiers (NCIDs) for all medical con-
cepts that can be stored as coded informa-
tion in our database. The HDD also assigns
a numerically coded identifier to each
individual provider of services in our orga-
nization. For each element/concept in the
dictionary, synonyms and terms used by the
interfaced application are stored.
Interfaces. Each arrow in Fig. 1 repre-
sents one or more interfaces between sepa-
rate applications. These interfaces allow the
native application to maintain its own data,
and use its own local terminology. Thus
when a message comes from one of the
interfaced systems, the vocabulary in that
message is translated from that of the origi-
nating source to the canonical representa-
tion of the central repository. Messages
going in the reverse direction are translated
back into the local vocabulary. The inter-
face engine also changes the message struc-
ture if necessary and then broadcasts the
message to other subscribing applications
as well as to the data store services for our
clinical data repository. The eGate interface
engine allows interfaces to be built that are
largely soft-coded or table-driven. Soft-
coded aspects of interfaces include message
(record reformatting), routing, error hand-
ling, and even I/O communication protocol
translation. For clinical applications we use
the HL7 message formats, and require that
any products being considered for purchase
provide a real time output using this stan-
dard. There are error logs and queues
which hold messages if a recipient applica-
tion is unable to verify receipt and proper
storage of the message. This approach does
allow storage of redundant data in two or
more places. For instance the clinical labo-
ratory system has the patient registration
information and a copy of the laboratory
orders and keeps a copy of the results after
it sends the result back to the CDR.
Inference engine. We have purchased
a commercial inference engine (Blaze
Advisor) that runs in an XML and J2EE
environment. This application is evoked by
the services that store data in our repo-
sitory or by sending a real-time message for
synchronous activation. We have construc-
ted data queries to the CDR that are used
by this rules evaluation engine to retrieve
data necessary to evaluate the rules and to
store the results. We have also generated
queries to the existing hospital based HELP
system so that we can simultaneously query
data from more than one system in order to
evaluate a patients status. We will also use
Blaze to send appropriate messages and in-
sure that the messages have been read.
Clinical Desktop. For some time we ha-
ve been using a Windows-based clinical
desktop shell to allow the user to seamless-
ly navigate between various applications
(order medications, see laboratory results,
go to the literature, compose a clinic visit
note). The context (user and patient) of
these separate modules is maintained by
this shell in an integrated way. We are now
beginning to install a web-based clinical
desktop that allows the user to Login via a
call to our LDAP (Light weight Directory
Access Protocol) compatible directory and
to select a patient (single sign on) before
choosing which application to run. After
the user clicks to indicate the choice, this
desktop can call various types of applica-
tions (e.g. the original DOS based HELP
application) as well as Windows and web-
based applications. Until recently we have
used hidden screens (web environment) or
hard coded methods to evoke the various
applications and to pass the context (user
and patient). We are now able to use the
Health Level Seven (HL7) Context Mana-
gement Architecture version 1.3 (CCOW:
Clinical Context Object Workgroup) pro-
vided by a company known as Carefx in
order to maintain seamless functionality
as a user switches back and forth between
applications on the desktop.
Applications that do not use the interface
engine. We have chosen to write several
core applications for data entry and results
review ourselves. These applications pro-
vide high performance access to the data-
base. The first of these programs is called
Chart Notes. It is a form-based application
that allows the user to enter data into fields
on the form using text input or codes from
pick lists. The data entry fields in the form
are coded and directly mapped to the
underlying data model. The Chart Note
templates are constructed using a Win-
dows-based editor and are stored in an
XML format. The user can evoke this data
Clinical Information System
3
Methods Inf Med 1/2003
entry tool in the Windows or the web envi-
ronment without the need to rebuild the
form. When the user hits save, the
uniquely defined codes for each element
are stored directly into the CDR in the
appropriate instantiation of the data model.
We also wrote in conjunction with 3M, a
Windows-based, thick client application
called the Clinical Workstation (CW). This
application allows the physician to enter
data (medication orders, visit notes, tem-
plated data via Chart Notes, problems,
allergies etc.) at the point of service. We
actually run the application on Citrix
servers and terminal emulation software to
reduce the maintenance costs associated
with installation of the thick client on every
user desktop. Three features of the CW
have enjoyed exceptional acceptance:
Message Log, Hot Text, and Common Lists.
The Message Log application lets mem-
bers of a clinic staff communicate with each
other asynchronously. A receptionist may
write a note to the physician that says, Mrs.
Jones called to ask for a refill of her xxx
prescription. The physician can respond
that the staff member should go ahead and
notify the pharmacy to refill the prescrip-
tion and call Mrs. Jones.
Hot Text is used to construct narrative
notes. A user can construct a variety of text
macros to reflect common clinical situa-
tions e.g. six week well-baby checkup or
follow up visit for patient with diabetes.
Rather than dictating of typing the entire
note, the user activates the macro with a
simple command and makes a small num-
ber of changes (26), which reflect the actual
patient status.
Common Lists provide the ability to
type a few letters and generate a dynami-
cally pruned list of items that reflect what
one is typing. For example, if one types the
first few letters of a drug name, the list of
fully qualified (dose, route, frequency, num-
ber of tablets to dispense, and number of
refills allowed are set to common default
values) candidate prescriptions of that drug
is displayed. Selection from the list finishes
the prescription unless one wishes to
modify any of these attributes.
In addition to the CW applications that
are primarily written to facilitate data
entry, we have written a Results Review
application to allow viewer access to the
comprehensive clinical data that are avail-
able in the CDR. This application allows us
to restrict access based upon privacy con-
siderations (users relationship to the pa-
tient, location of the terminal, recent acti-
vity of the patient, role of the user and
relationship of the user to the patients
primary care provider). In addition to our
own displays of test results (including
graphs over time) and narrative docu-
ments, we link to commercially purchased
applications as well. We show EKG wave-
forms by linking to the GE/Marquette
MUSE application and radiographs using
the Amicus viewer. For problems, medica-
tions or allergies we provide access to the
literature by letting the user click on the
infobutton (27). This feature generates
the list of the answers to common que-
stions for which our indexed/tagged
literature resource can provide answers,
e.g. is this drug safe to use during preg-
nancy? The user selects the question and
the answer appears.
Results
Our current clinical data repository con-
tains the records for 1.48 million patients.
The average record size is 24 kilobytes per
Clayton et al.
4
Methods Inf Med 1/2003
Fig. 2 A comparison of the number of unique users who logon to one of our clinical applications each month. Most users still use the HELP hospital based system, but there has been
steady growth of the use of HELP2 in the ambulatory setting. We will begin to move the hospital users to HELP2 in December of 2002.
Comparison of Unique Users
patient not counting waveforms, images
and other scanned documents. The record
size for the patient with the most data is
presently 13 MB. Our system currently has
369 GB of storage capacity on a Storage
Area Network (SAN). We have a redun-
dant back up system and test and deve-
lopment systems. We use UNIX for our
database services (24 processors in 6
machines for Oracle and another 24
processors in 6 machines for the services).
Two of these machines are for load ba-
lancing. A query for patient data takes an
average of 0.19 seconds during the busy
part of the day. Our unscheduled downtime
for the central database repository this year
is 0.05% (3.58 hours/ 7200 hours). Our goal
is to have less than one hour per year of
unscheduled downtime. Our scheduled
downtimes (if needed) occur once per
month for approximately 3 hours (15 hours
total through October of this year).
We average 7,176,000 monthly queries
against the database from 2416 individual
clinical users who currently log on to the
system at least once a month (Fig. 2 ). Most
of these users are currently in the ambula-
tory setting. In contrast, during the month
of October 2002, 12,206 different individu-
als used the hospital-based HELP system.
The number of patients accessed via the
new HELP2 system is currently (October
2002) 100,577 per month vs. 94,222 per
month via the HELP hospital system. We
will begin to switch users off of the original
HELP system in December of 2002,
although, by using the clinical desktop and
CCOW, our users are free to seamlessly
switch back and forth between HELP and
HELP2 for the foreseeable future.
Using our Clinical Workstation applica-
tion, 981 individuals entered a prescription
order during October 2002 ( Fig. 3 ). During
this same time period 441 users entered a
progress note and 302 individuals entered
at least one coded problem into a patient
record.
We currently have interfaces to 51 diffe-
rent unique applications. Sixteen of these
are to external trading partners (financial
transaction clearing houses, insurance com-
panies, providers, etc.) Two-thirds of the
interfaces are to clinical systems (clinical
laboratory, PACS, blood bank, anatomic
pathology, surgery scheduling, transcrip-
tion, etc). The remaining third are to finan-
cial systems. Each of these applications may
require several interfaces. For example,
we are working with the IDX CareCast
product to implement computer-based phy-
sician order entry and an evidence-based
patient care management system. For these
two applications, we actually needed to
complete 18 interfaces (Staff in from our
master provider tables, Admit discharge
and transfer, orders out, orderable items in,
problems in, problems out, nurse assess-
ments, etc.). For this particular project, the
costs of the interfaces amounted to 20% of
the total application software costs. When
we added the costs of education, know-
ledge base creation, hardware etc., the in-
terface costs comprised 4% of the entire
projected cost of the project.
This ratio applies on a larger scale as
well. We spend 31% of our overall infor-
mation systems budget on clinical applica-
tions, 17% on administrative applications,
6% on administration, 42% on infrastruc-
ture (machines, personal computers, ope-
rating systems, and networks), and 4% on
interfaces and vocabulary.
For the entire group of interfaced appli-
cations, there are 31 different types of inter-
faces (for example, patient registration in-
formation is one type) that are needed to ac-
commodate the variety of data types (radio-
logy orders, laboratory orders, medication
administration, textual document, etc.). We
have a total of 820 external network connec-
tions to our interface engine and process
nearly two million transactions per day.
We currently have 19 full-time em-
ployees who build and maintain interfaces
(out of a total of 150 who work on clinical
applications). Because of the order entry
project and a new insurance claims product
that we are installing, the number of people
devoted to interfaces is approximately
twice as large as our comparable staffing
level of two years ago. At an average salary
of $30 per hour and an estimated time of
650 hours to build an interface, we estimate
that each interface costs about $20,000. For
example, this means that the interface to
the CareCast product costs us approxima-
tely $350,000. These are our costs and the
vendors typically charge for their side of
the interface as well.
We currently employ eight individuals
who work full time to create and maintain
the vocabulary codes that are stored in our
dictionary. We have expended a total of
approximately 36 person years to define
terms, synonyms and hierarchy and to
maintain the dictionary. We currently have
545,000 uniquely defined concepts in the
dictionary. We import our drug information
from First Data Bank and use other availa-
ble data sets such as LOINC, CPT-4, ICD9,
etc. As an example of the dictionary
content, we have defined unique concepts
for 4392 clinical observations, 2415 clinical
laboratory tests, 3162 laboratory results,
and 848 types of radiology examinations or
supplies. We believe that we currently have
approximately 70% of the content that will
eventually be needed to support a compre-
hensive clinical information system. This
estimate will change as new observations
Clinical Information System
5
Methods Inf Med 1/2003
Fig. 3
This graph shows the gro-
wing use of the Clinical
Workstation to enter data
into the computer. Our
users are not forced to use
this application but have
chosen to do so because of
the benefits the application
offers. This application has
been primarily used in the
ambulatory setting until
now.
Unique CW Users by Application and Role Each Month
Physician Role
from the field of genetics begin to be inclu-
ded in the clinical record. This new content
will include identifiers for genes and their
phenotypic expressions as well as the
names of tests to determine the presence to
particular mutations.
Although we have been running rules in
the HELP system for three decades and
will continue to do so for the foreseeable
future, our HELP2 rules engine capability
is not yet being used in a production envi-
ronment. We are planning to begin clinical
use of our decision support tool in March of
2003. Based upon our experience in the test
environment, we anticipate that we will
have sufficient performance to run the
rules that are currently used in our hospital
system as well as to expand the scope of our
knowledge-based systems.
Discussion
For those institutions with the knowled-
geable people and the resources to invest in
the initially more expensive, yet ultimately
more flexible approach, we believe that the
interfaced approach is much more cost
effective than the alternative approach
over a thirty-year lifetime of such systems.
We have adopted this belief because of the
following observations and experience. In
todays marketplace, no single vendor can
satisfy all the desired functionality, and the
monolithic approach to defining databases
restricts the flexibility and scalability of
such systems. As technology changes over a
thirty-year period, it is the database content
that remains valuable and should be defi-
ned using a well-structured approach to a
controlled medical vocabulary. The physi-
cal implementation of the logical database
model could change over time to take
advantage of new database management
applications. One would only have to chan-
ge the services that store and retrieve the
data and both versions of the database
could simultaneously exist during a transi-
tion much as we are doing with the current
HELP system. When one thinks of the
technological changes that have occurred
in the last three decades (networks, perso-
nal computers, handheld wireless com-
puters, the concept of the world wide web
and its associated information servers, the
National Library of Medicines efforts to
construct a common vocabulary, the emer-
gence of HL7 standards, patient access to
their medical records on-line etc.) and the
improvement in commercially developed
applications that has occurred in this time
period, it is fairly evident that in the next
two to three decades, there also will be
dramatically enhanced capabilities when
compared to the software that we are
installing today. If we must accommodate
this change by relying on a single vendor
that may or may not stay in business or
respond rapidly to these changes or offer
the breadth that is needed, we place our
initial investment at risk. How many
vendors that are in business today were the
leaders 30 years ago?
The ability to gradually change or add
one component at a time to the system allo-
ws us to adapt to change incrementally.
Experience at Columbia Presbyterian (28),
and at IHC shows that getting the data into
the database is the most difficult task. After
the database exists, creating new applica-
tions within a new technology (Web, hand
held, patient home, etc.) is rather straight-
forward. At both institutions, the creation
of new web-based results review applicati-
on took less than 4 person years.
Another example of a gradual transition
is our experience with the existing HELP
application. Importing data from HELP
into HELP2 via the interface shown in
Fig. 1 illustrates the power of the interfaced
approach. HELP simultaneously runs on
the same clinical desktop as HELP2. This
ability means that there is no need to train
everybody at once and have a big bang
switch over to a new and perhaps untested
system. People are drawn to the new
system because of the availability of longi-
tudinal data, literature resources, Radio-
graphs, EKG waveforms, ability to enter
orders and data, etc. As the load increases
we can monitor response time and titrate
the user load gradually as we tune the sy-
stem for optimal performance. One need
not turn off an old system when implemen-
ting the new. As people gradually switch to
the new system and pieces of the old HELP
system are replaced, it can atrophy. This
approach makes the transition easy and
allows us to tune the performance of the
new system in a non-urgent setting as peo-
ple gradually begin to use it. As bugs in the
new system appear, the old system is still
available as a back up.
The biggest drawback to this approach
is the initial cost of building the interfaces.
It costs as much to build the interfaces in a
small system as it does in the large system,
so the proportionate costs of interfaces are
higher. The cost of vocabulary definitions is
less of an issue because vocabulary terms
need to be defined in a monolithic system
as well as in the interfaced system. In the
monolithic system, it is a somewhat simpler
task because there is no need to map syno-
nyms as in the latter model. However, it
should be kept in mind that the cost of
choosing a monolithic system supplied by a
vendor that does not stay in business far
outweighs any interface costs. Usually the
leading companies in one decade are not
the leaders in subsequent decades due to a
phenomenon known as installed user base
anchor. If the interfaced model becomes
widely adopted, the vendor of a safe mono-
lithic choice today may not be competitive
in the future. We believe that the efforts of
the National Library of Medicine to define
a common terminology and the continuing
efforts of HL7 will drive down the costs of
interfaces.
Another hypothetical drawback that is
often raised revolves around the issue of
storing data in more than one place. Most
people who raise this issue are referring to
the case in which there is redundant data
entry and there are subsequent discordan-
ces because the separate databases contain
different information. When examining this
issue it should be kept in mind that, in our
model, the data are not entered redundant-
ly; that is the whole point of interfaces.
Redundant data can be a blessing in some
cases. One can ask the originating applica-
tion to replay its log and resend data if
there is a failure at the recipient end. If the
CDR were to be unavailable, one could get
laboratory results by going directly to the
laboratory. This option was used at Colum-
bia Presbyterian Medical Center (16).
Some worry about the problems of keeping
data perfectly synchronized. We have not
Clayton et al.
6
Methods Inf Med 1/2003
found this to be a practical problem especi-
ally when compared to the manual system
in which there are many results that never
get properly placed in the patient record.
Another drawback of our approach is
that less than accurate registration clerks
use multiple registration programs that we
cannot alter. This combination sometimes
creates duplicate master index numbers for
a single patient. This situation is dangerous
because vital information might be stored
in each fragment of the record, but the
provider might only see one fragment. This
problem with duplicates applies to any
system with a longitudinal record, but is so-
mewhat more challenging when the vendor
registration systems are not expecting to go
to a foreign enterprise master patient record.
In summary, we have attempted to build
upon an architecture where it is possible to
change any component or application with-
out the need to change any other compo-
nent. We have used a dictionary and a data
model that allow us to define the content of
the patient record in a way that is indepen-
dent of any one application. The flexibility
and extensibility afforded by this approach
lets us use additional applications regard-
less of how the data might be collected in
any other application. We are pleased with
our decision to go in this direction. We feel
that as the costs of interfaces are reduced,
this will be a viable alternative to be consi-
dered by all institutions or enterprises not
just those large groups where interfaces are
a smaller proportion of the overall costs of
the system.
References
1. Leguit F. Interfacing Integration in Hospital in-
formation systems:Scope-Design-Architecture
Bakker, AR, Bryant JR, Ehlers CT, Hammond
WE, eds. North Holland, Amsterdam, 1992, pp
141-8.
2. Slack WV, Bleich HL.The CCC system in two
teaching hospitals: a progress report. Int J Med
Inf. 1999; 54 (3): 183-96.
3. Scherrer JR, Baud RH, Hochstrasser D, Ratib
O. An integrated hospital information system
in Geneva. MD Comput. 1990; 7 (2): 81-9.
4. Collen MF.A brief historical overview of hospi-
tal information system (HIS) evolution in the
United States. Int J Biomed Comput. 1991; 29
(3-4): 169-89.
5. Anderson CL, Meldrum KC.The VA compute-
rized Patient Record a first look. Proc Annu
Symp Comput Appl Med Care. 1994; 1048.
6. Overhage J, McDonald CJ, Suico JG. The
REGENSTRIEF medical record system
2000:Expanding the breadth and depth of a
community wide EMR Proc AMIA Symp.
2000, 1173.
7. Pryor TA, Gardner RM, Clayton PD, Warner
HR. The HELP system. J Med Syst. 1983; 7 (2):
87-102.
8. Tolchin SG, Stewart RL, Kahn SA, Bergan ES,
Gafke GP, Simborg DW, Chadwick MG,
Whiting-OKeefe QE.A prototype generalized
network technology for hospitals: initial imple-
mentation. J Med Syst. 1982 Aug; 6 (4): 359-75.
9. Simborg DW. The case for the HL7 standard.
Comput Healthc. 1988 Jan;9(1):39-40-2.
10. Scherrer JR, Spahni S. Healthcare information
system architecture (HISA) and its middleware
models. Proc AMIA Symp. 1999, 935-9.
11. Chu S, Cesnik B. A three-tier clinical informa-
tion systems design model. Int J Med Inf. 2000;
57 (2-3): 91-107.
12. Van de Velde R. Framework for a clinical in-
formation system. Int J Med Inf. 2000; 57 (1):
57-72.
13. Lowe HJ, Buchanan BG, Cooper GF, Vries JK.
Building a medical multimedia database sy-
stem to integrate clinical information: an appli-
cation of high-performance computing and
communications technology. Bull Med Libr As-
soc. 1995; 83 (1): 57-64.
14. Greenes RA. A building block approach to
application development for education and
decision support in radiology: implications for
integrated clinical information systems envi-
ronments.J Digit Imaging. 1991; 4 (4): 213-25.
15. Glaser JP, Beckley RF 3rd, Roberts P, Marra
JK, Hiltz FL, Hurley J. A very large PC LAN as
the basis for a hospital information system. J
Med Syst 1991; 15 (2): 133-7.
16. Clayton PD, Sideli RV, Sengupta S. Open archi-
tecture and integrated information at Colum-
bia-Presbyterian MedicalCenter. MD Comput.
1992; 9 (5): 297-303.
17. Clayton PD Current developments and future
trends in Information technology in health care
in Hospital Information Systems:Scope-De-
sign-Architecture Bakker, AR, Bryant JR, Eh-
lers CT, Hammond WE eds North Holland,
Amsterdam 1992, pp 19-25.
18. Tarczy-Hornoch P, Kwan-Gett TS, Fouche L,
Hoath J, Fuller S, Ibrahim KN, Ketchell DS,
LoGerfo JP, Goldberg HI. Meeting clinician
information needs by integrating access to the
medical record and knowledge resources via
the Web Proc AMIA Symposium 1997, 809-13.
19. Ferrara FM. The CEN healthcare information
systems architecture standard and the DHE
middleware. A practical support to the integra-
tion and evolution of healthcare systems. Int J
Med Inf. 1998; 48 (1-3): 173-82.
20. Van Mulligen EM, Timmers T, Brand J, Cornet
R, van den Heuvel F, Kalshoven M, van Bem-
mel JH. HERMES: a health care workstation
integration architecture. Int J Biomed Comput.
1994; 34 (1-4): 267-75.
21. Patil RS, Silva JS, Swartout WR. An architectu-
re for a health care providers workstation. Int J
Biomed Comput. 1994; 34 (1-4): 285-99.
22. Huff S M, Rocha R A, Bray B E, Warner H R,
Haug P J. An event model of medical informa-
tion representation. J Am Medical Informatics
Ass 1995; 2 (2): 116-28.
23. Huff S M, Rocha R A, Solbrig H R, Barnes M
W, Schrank S P, Smith M. Linking a medical
vocabulary to a clinical data model using Ab-
stract Syntax Notation 1. Methods Inf Med
1998; 37 (4-5): 440-52.
24. Rocha RA, Huff SM. Development of a
template model to represent the information
content of chest radiology reports.Medinfo.
2001; 10 (Pt 1): 251-5.
25. Rocha R A, Huff S M, Haug P J, Warner H R.
Designing a Controlled Medical Vocabulary
Server: The VOSER Project. Computers and
Biomedical Research.1994; 27 (6): 472-507.
26. Wilcox A, Narus SP, Bowes III WA, Using natu-
ral language processing to analyze physician
modifications to data entry templates. Proc
2002 AMIA. Kohane I, ed. Hanley and Belfus
2002, pp. 899-903.
27. Reichert JC, Glasgow M, Narus SP, Clayton
PD. Using LOINC to link an EMR to the perti-
nent paragraph in a structured reference know-
ledge base. Proc 2002 AMIA. Kohane I,ed.
Hanley and Belfus 2002, pp. 652-6.
28. Cimino JJ, Socratous SA, Clayton PD. Internet
as clinical information system: application de-
velopment using the World Wide Web. J Am
Med Inform Assoc. 1995; 2 (5): 273-84.
Correspondence to:
Dr. Paul D. Clayton
4646 W Lake Park Blvd
Salt Lake City UT 84120, USA
E-mail: copclayt@ihc.com
Clinical Information System
7
Methods Inf Med 1/2003