EVALUATION PLAN PROJECT: SELECT A CASE STUDY AND MODEL

6
Bar Coding: It’s Hard to Kill a Hippo

Margaret Keller, Beverly Oneida, and Gale McCarty

For years, the quality improvement committee (QIC) at University Hospital had been
collecting incident reports documenting errors in patient ID, medication administra-
tion, and specimen collection. QIC became interested in the possibility of utilizing bar
code technology to enhance patient care by decreasing these types of errors. After
failing in an effort 2 years earlier, a bar coding project team was built consisting of rep-
resentatives from admitting, pharmacy, clinical labs, clinical engineering, medical center
computing (MCC), hospital procurement, operations improvement, quality improve-
ment, and health unit coordination. The project was defined and divided into three
phases for ease of implementation and cost control. The team decided to start with the
least expensive and least controversial project, replacement of the “B-plates.” These
plates are the embossed, credit card–like plates used to stamp patient ID information
on all hospital and major procedure documentation and on ID bracelets. The Address-
ograph typeface embossing machines used to make the patient ID blue plates
were known as “hippos,” because of their resemblance to the open mouth of a
hippopotamus.”

Valentine’s Day 2001

“One step forward and two steps back . . . ,” mused the usually optimistic Janet Erwin,
director of value analysis and operations improvement, who was beginning to worry
about the timeline she had set for implementation of phase I of her bar coding project.
As the strains of her singing Valentine faded and the February 14 meeting began in
earnest, she reviewed the phase 1 goal: replacement of the B-plate system of inpatient
ID with bar coding technology in order to provide accurate and legible patient ID
information at the time a patient presents to the health system for admission or for
extended periods of care. The requirements for the bar coding project are:

• Use patient ID technology to support bar code and/or radiofrequency applications
to enhance patient safety and to increase staff efficiency

• Limit noise production on patient care units
• Eliminate hand writing of patient ID
• Use technology that supports a secure patient ID band system based on patient age
• Eliminate the need to replace patient ID bands when a patient transfers from unit

to unit

65

LTF6 10/11/2004 8:42 AM Page 65

C
o
p
y
r
i
g
h
t

2
0
0
5
.

S
p
r
i
n
g
e
r
.

A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

M
a
y

n
o
t

b
e

r
e
p
r
o
d
u
c
e
d

i
n

a
n
y

f
o
r
m

w
i
t
h
o
u
t

p
e
r
m
i
s
s
i
o
n

f
r
o
m

t
h
e

p
u
b
l
i
s
h
e
r
,

e
x
c
e
p
t

f
a
i
r

u
s
e
s

p
e
r
m
i
t
t
e
d

u
n
d
e
r

U
.
S
.

o
r

a
p
p
l
i
c
a
b
l
e

c
o
p
y
r
i
g
h
t

l
a
w
.

EBSCO Publishing : eBook Collection (EBSCOhost) – printed on 6/14/2023 6:08 PM via WALDEN UNIVERSITY
AN: 145750 ; Nancy M. Lorenzi, Joan S. Ash, Jonathan Einbinder, Wendy McPhee, Laura Einbinder.; Transforming Health Care Through
Information
Account: s6527200.main.eds

• Produce printed patient information on patient ID bands and patient ID labels
including the patient’s full name, medical record number, gender, account number,
and date of birth.

Subsequent phases of the project were envisioned to include medication and lab spec-
imen/collection tracking (phase II); equipment, personnel, and patient tracking; and
mother/baby ID (phase III).

Janet had been brought into the project early in 1999 and had worked hard to deter-
mine the problems with the current system as well as a technology solution. The entire
project had been initiated not only in response to dissatisfaction with the current B-
plate system but also because of an overall desire to eliminate errors in patient ID,
medication administration, and specimen collection. Bar coding had been used in the
lab for 15 years, and in the pharmacy for 5 years, so the technology base was familiar
to end users. Janet felt there was no support in the medical center for keeping the
current B-plate system, so replacing it with more advanced technology seemed to be
a good initial project for the QIC. The discussion today centered on phase I of the total
patient ID initiative and whether a solution should be developed in-house or pursued
with a third-party vendor. The MCC division was reluctant to support in-house
development.

The View from MCC

The quietly commanding voice of Carl Cusak, chief information officer, resonated from
behind his desktop, laptop, and personal digital assistant (PDA), all on active screens,
as he summarized the reasons why he needed to call “time out” on the bar code project
and “regroup” to a prior point in the planning process. “Most projects involving
advanced technology and informatics at University Hospital begin with fervor, energy
and commitment, but often fail because pertinent points in process development are
assumed or overlooked,” he noted. Carl spoke with the authority of his experience.

The lack of MCC involvement meant that technical requirements had never been
defined, including details such as standards for data input, hardware infrastructure
requirements, or a charter document stating the purpose, scope, timeline, or product
development requirements. In addition, software specifications and interface require-
ments were lacking. Carl also felt that little attention was being paid to the substruc-
ture and interface problems inherent in bar coding, i.e., the capability of the bar code
reader to read the code on a patient’s wrist band. The use of radiofrequency technol-
ogy and the use of hardware such as PDAs into which the bar code could be uploaded
via a software program, allowing real-time ID of patients and tracking, were consid-
ered, but the benefits and drawbacks were not well researched. Backup strategies for
unanticipated breakdowns in the system also had not been defined.

Carl complemented some of the long-standing individuals involved with the bar code
project, such as Janet, for their commitment and effort. He noted that bar coding had
long been used for applications in the pharmacy, the operating room, central supply,
and the lab. Despite these varied uses of bar coding at University Hospital, however,
no standards had evolved among these bar coding efforts. Carl admitted that MCC
should have taken ownership of these disparate bar coding projects earlier and should
have become the major shareholder in bar coding development. However, MCC
personnel changes and priority mandates had kept it from assigning the necessary
resources to the project.

66 Section III. Implementation

LTF6 10/11/2004 8:42 AM Page 66

EBSCOhost – printed on 6/14/2023 6:08 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

6. Bar Coding: It’s Hard to Kill a Hippo 67

“I can’t believe that the bar coding initiative could still become an in-house devel-
opment project at this point!” said Chris Matt, a QIC member who could remember
when the idea of replacing the B-plates with bar code technology was brought up back
in 1996. On the surface, the project seemed to be popular enough with anyone involved
with direct patient care to ensure its success. MCC, however, had been so busy with
other projects that the perceived lack of immediacy or of a high-level champion had
tabled the bar coding initiative in the past.

With an increased focus on all patient safety issues, especially those related to ID,
the QIC continued to identify and evaluate examples of potential problems. It seemed
that once ID issues were examined, the scope of the concerns grew. Chris noted that
the team went from a working goal of all patients having an ID wristband to that of
all patients having a correct ID wristband. It became evident that something had to
change to prevent a potential catastrophe. Processes tightened, but the basic difficul-
ties surrounding the lack of clear, accurate, consistent patient ID were now in the
spotlight.

On April 13, 2000, the request for proposal (RFP) was developed and distributed
to certain third-party vendors for response. Chris was not happy to hear that phase I
of the project could still end up being accomplished in-house, despite the RFP
responses. If that was the decision, the project could have been completed a long time
ago.

Needs of End Users

Charlotte Graham, inpatient admitting director, had been involved with the bar coding
project from the start. After all, her area would be affected the most by any change in
inpatient ID. Over the years, she had heard the complaints about the current system.
She knew well how costly the “hippos” were and how much maintenance they required,
and she was aware of the poor quality of many of the imprints. She also realized that
the B-plates often did not get to their destination in a timely fashion, as they were gen-
erated in admitting and put in a central location for transportation to pick up. Even
after pickup, the plates were taken to a sorting area and often awaited transport to the
units. Some plates never reached their destination and had to be regenerated. This was
especially true for unplanned admissions that were brought directly to the floor or were
admitted through a major procedure area. Charlotte realized that while mistakes could
not be totally eliminated, there was a need to minimize the areas where mistakes could
be made. She saw bar coding as a tried-and-true method of inventory control that
could be easily adapted to track patients and match patients to their records, films, or
specimens.

Charlotte was disappointed to be back at the point of considering an in-house solu-
tion to the problem. If the project was not contracted out to a third-party vendor, it
would need to be interfaced with the current admitting information system, which was
very old and in need of being upgraded. The admitting information system was cur-
rently used to maintain demographic, billing, and visit information on all patients seen
at University Hospital. Charlotte also felt that the current admitting information
system could not support phases II and III of the project in the future.

In addition to Charlotte and her admitting staff, the front-line people, including unit
coordinators, nurses, doctors, therapists, etc., would be directly affected by a change in
the method of patient ID. One of their representatives on the project team was Risi
Kay, an administrative assistant with experience working on the inpatient units.

LTF6 10/11/2004 8:42 AM Page 67

EBSCOhost – printed on 6/14/2023 6:08 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

Risi felt that despite the fact that most people would be happy to see the B-plates
gone, a bar code system with labels would probably require a little more effort. This
would especially be true during off-shifts, when unit coordinators were not available,
as someone would have to be able to generate additional patient ID labels as they were
needed. Just who would be trained to use the new system had not been determined.
Time was often in short supply in completing day-to-day patient care activities. Ease
of use and an institutionwide consistency of flow would be critical.

The Decision and the Implementation Plan

While awaiting the final word from MCC, Janet mused, “I would be delighted if we
could do this project in-house, as long as we could meet goals and project deadlines.
. . . It would be so much easier . . . it would help having MCC own this with us.”

On March 20, an update meeting was held. It was noted that MCC had successfully
generated patient identified bar codes from the admitting information system and had
designed a system that permitted additional patient ID labels to be printed on request.
They had also been able to generate various font sizes that would be consistent with
adult, pediatric, or neonate bandwidths. The RFP for phase I was then canceled. The
RFPs for phases II and III would remain open to enable University Hospital to better
evaluate the available technology solutions for future phases.

It had been a long time coming, but Janet enjoyed the feeling of satisfaction she was
experiencing with a job well done. She finally had her project on the agenda of the
information technology governance committee, and with their support she felt that it
would become a reality. “I am not going to dwell on the issue that this should have
been happening all along, but hopefully the process that we have all had to go through
will have a positive effect on other projects that go forward and require everyone to
be on the same page and same priority level.” Jane sat at her desk and smiled.

Questions

1. How could the MCC group have better worked with the end users on the bar coding
project?

2. Develop a plan for moving patient identification to phase II.
3. What strategies could the QIC develop with the MCC to ensure future coopera-

tion?
4. Was bar coding a good first project? Why? Why not?

68 Section III. Implementation

LTF6 10/11/2004 8:42 AM Page 68

EBSCOhost – printed on 6/14/2023 6:08 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

8
Implementation of OpChart in West
Medical Building

Nathan R. Hoot and David L. Sanders

“The system is locking up again! Are you kidding me? I swear this program hates me.”
Walter Sellers glanced over at the patient, who lay on the operating table. The patient
was a 12-year-old boy who was being operated on to repair an inguinal hernia. This
procedure is generally minor in scope, but any task can become difficult when the tools
impede, rather than facilitate, one’s ability to work. The pediatric surgeon glanced over
to see Walter with his full attention on the unruly computer and his back turned to the
patient. This prompted a swift rebuke. “Hey! You need to be doing your job here—
you’ve got an airway to manage!” “Yes sir, I apologize.” Walter turned back to attend
to the patient’s endotracheal tube. He needed both hands free to secure the patient’s
airway, and yet he also needed both hands available to force the computer into sub-
mission. It was indeed frustrating to him, to feel the hot temper of the surgeon directed
at him when it was not his fault that the computer would not function properly. “You
know, you really should scrap that newfangled computer and just do your charting on
paper, like we always have,” the surgeon suggested.With a sigh of relief,Walter reached
for some paper and said, “That sounds good to me. . . .”

Introduction

This case study describes the implementation of an anesthesia informatics system in a
surgical unit at Riverview University Medical Center (RUMC). This tool is one part
of a larger perioperative informatics initiative that includes many computer-based
modules. All these systems were developed locally with direct involvement by practic-
ing anesthesia staff and are in daily use across the varied surgical units of this large
medical center. Developers and users attest that these products have been readily
adopted into the clinical practice of anesthesiology and are happily used in the various
operating suites within the hospital—with one notable exception. The module of inter-
est to this case study, called OpChart, allows for electronic documentation of patient
information during an operation. In the one surgical area where the majority of pedi-
atric and ophthalmologic surgeries are performed, OpChart has not been successfully
adopted. In fact, an attempt was made to implement it in these operating rooms 3 years
prior to the date of this case study. This effort resulted in widespread rejection of the
system in these areas, conflict within the anesthesiology department, and a general
feeling of resentment and mistrust toward the OpChart system. These sentiments
persist to this day. However, with the advent of the Health Insurance Portability and
Accountability Act (HIPAA), the need for electronic documentation during surgery is

81

LTF8 10/11/2004 8:45 AM Page 81

C
o
p
y
r
i
g
h
t

2
0
0
5
.

S
p
r
i
n
g
e
r
.

A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

M
a
y

n
o
t

b
e

r
e
p
r
o
d
u
c
e
d

i
n

a
n
y

f
o
r
m

w
i
t
h
o
u
t

p
e
r
m
i
s
s
i
o
n

f
r
o
m

t
h
e

p
u
b
l
i
s
h
e
r
,

e
x
c
e
p
t

f
a
i
r

u
s
e
s

p
e
r
m
i
t
t
e
d

u
n
d
e
r

U
.
S
.

o
r

a
p
p
l
i
c
a
b
l
e

c
o
p
y
r
i
g
h
t

l
a
w
.

EBSCO Publishing : eBook Collection (EBSCOhost) – printed on 6/14/2023 5:53 PM via WALDEN UNIVERSITY
AN: 145750 ; Nancy M. Lorenzi, Joan S. Ash, Jonathan Einbinder, Wendy McPhee, Laura Einbinder.; Transforming Health Care Through
Information
Account: s6527200.main.eds

now greater than ever, so a fresh attempt at deploying OpChart in this unit of nine
operating rooms has been planned. In this case study, the authors explore the unique
features of this surgical unit, attempt to uncover the causes of the failed implementa-
tion in the past, and evaluate the barriers that must be overcome for successful imple-
mentation of the OpChart system.

Background

RUMC is an academic, nonprofit tertiary care center in an urban setting. Located in
the Midwest, this health center is comprised of an adult and a pediatric hospital with
more than 650 patient beds and an annual volume of about 31,000 admissions. RUMC
offers multidisciplinary surgical services that include general, pediatric, cardiothoracic,
ophthalmology, trauma, neurosurgery, transplant, and others. There are six distinct sur-
gical units with thirty-nine operative rooms in total. RUMC operates with a surgical
case volume of approximately 1,600 cases per month. These include inpatient and elec-
tive outpatient operations, as well as emergently required procedures. Operating rooms
are available for use at all times thanks to surgical and anesthesia personnel who are
on call 24 hours a day, 7 days a week.

The Department of Anesthesiology is responsible for all perioperative patient care
and is comprised of a staff that includes fifty attending anesthesiologists, forty resident
physician trainees, thirty-five certified registered nurse anesthetists (CRNAs), and fifty-
two student registered nurse anesthetists (SRNAs). Perioperative patient care encom-
passes all aspects of patient management from preoperative assessments until the
patient is considered stable in the recovery room after surgery. Clinical responsibilities
include a medical preoperative risk evaluation, insertion of any necessary vascular
lines, the induction of anesthesia and airway management including intubation, moni-
toring of patient vital signs during the operation, and transfer of the patient to the
recovery room area where a final clinical assessment takes place. First-line patient care
and monitoring are performed by either an anesthesia resident physician or a CRNA.
All patient care is supervised by an attending physician who is board-certified in anes-
thesiology and who may oversee multiple ongoing cases at one time.

The Department of Anesthesiology uses a suite of medical informatics tools devel-
oped locally by the perioperative informatics group. This set of tools, is known as the
Riverview Perioperative Computerized Management Suite (RPCMS). The develop-
ment group gives the following description of their software.

RPCMS was developed . . . to bring electronic charting to surgical patient care. The system is
designed to be a complete solution providing documentation and management tools for all care
providers (nurses, surgeons, anesthesiologists) throughout the entire care process from the initial
visit in the surgical clinic through all phases of operative care. In addition to providing for elec-
tronic documentation and information sharing, the system was developed to support billing,
quality improvement, cost containment, and clinical research efforts.

RPCMS began development in 1995 with implementation of the preoperative
module. The outcomes module, which documents postoperative care and supports
quality improvement efforts, began clinical implementation next. The anesthesiology
intraoperative charting component of the intraoperative module, OpChart, was rolled
out in 1996. The patient tracking product was implemented in early 1997 and has
received several additions/modifications, achieving its current form in early 1999.

RPCMS makes the life of the user easier.The operating room (OR) schedule, patient
anesthesia evaluations, and all past intraoperative reports are available over the Inter-

82 Section III. Implementation

LTF8 10/11/2004 8:45 AM Page 82

EBSCOhost – printed on 6/14/2023 5:53 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

net. In addition, special equipment needed for the next day (fiberoptic bronchoscopes,
rapid infusers, etc.) can be reserved online. User case logs are available along with vaca-
tion schedules, lecture schedules, and other useful information.

The informatics development group for anesthesia is led by Phillip Knowles, who is
the director of the perioperative informatics group. Although he holds a joint appoint-
ment in the Department of Anesthesiology, his primary position is within the infor-
matics center at large. Knowles holds a masters in biomedical engineering. He built the
perioperative informatics group and is the principal developer of all the anesthesiol-
ogy informatics initiatives. As the technical project leader, there are a number of pro-
grammers assigned to the projects who report directly to him. These include three
current developers, as well as two more who have been hired but have not yet begun
working with the group. In addition, one programmer is serving in active military duty.
Knowles has the latitude to determine the priority of small projects and to assign spe-
cific tasks to the programmers. The group is physically located within the same office
space as the Department of Anesthesiology.

Two committees direct the efforts of this development group. The first is the peri-
operative executive steering committee. Its responsibilities include overseeing the peri-
operative informatics group as a whole and prioritizing its future development efforts.
Its members control the RPCMS development budget, which includes funding for
hardware and software development personnel. The steering committee is also respon-
sible for coordinating the integration of the perioperative informatics group within
the overall informatics goals of the entire medical center. Its members consist of
administration-level faculty in the anesthesiology department, including Phillip
Knowles. Another member is Raymond Bryce, M.D. Bryce is an associate professor
and the clinical vice-chairman of anesthesiology, as well as the medical director of
perioperative services. Also on this committee is Doug McPeak, M.D. Trained in
pediatric anesthesiology, he is an assistant professor of anesthesiology as well as the
associate director of anesthesia informatics. Second, there is an operations committee
to handle the RPCMS day-to-day operating issues.

OpChart Product Description

The OpChart software tool represents the intraoperative anesthesia management com-
ponent of the RPCMS toolset. What was the most important rationale for the creation
of this system? The answer to this question varies depending on who is asked. Accord-
ing to the developer, the primary motive was not electronic documentation but rather
to improve the outcomes analysis of surgical procedures at the local institution.
The goals of such an analysis included minimizing bad outcomes and maximizing good
outcomes, decreasing patient length of stay, and demonstrating trends of improvement.
A secondary goal was to facilitate automatic data collection for research purposes,
creating a master clinical data repository. A number of publications have already
resulted from this collected data. Additionally, having clinical data consolidated into
a central database allows a degree of information availability not possible with a
paper chart, whereby only a single, easily misplaced, copy of a chart exists. John Eaves
is a CRNA who worked at RUMC during the time of OpChart development. Accord-
ing to him, the impetus for change was to cut down on paper storage, to enhance access
to old patient charts, and to create an easily accessible database. Similarly, Sarah
Koehler, also a CRNA, suggested that the drive to move to computerized record
keeping mainly involved the desire to eliminate paper trails, to capture charges in a

8. Implementation of OpChart in West Medical Building 83

LTF8 10/11/2004 8:45 AM Page 83

EBSCOhost – printed on 6/14/2023 5:53 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

punctual fashion, and to allow easier access to lab results and other relevant patient
information.

During a surgical case, OpChart use begins when the patient is brought into the OR.
A new case can be opened using either a blank document or a premade template. Basic
information about the case is maintained, such as the start time. Real-time charting of
vital signs then begins, and the user updates the values for heart rate, blood pressure,
temperature, respiratory rate, and oxygen saturation every 5 minutes for the duration
of the procedure. All information about anesthesia administration is logged into the
system, including drugs given, doses, and routes of administration. Any intravenous
fluids or drug infusions given can also be added to the case information. Information
about airway management is also entered.The user may elect to monitor certain values
as the operation progresses, such as hematological parameters or other laboratory
values of interest. Special dialogs are available where the user can enter information
pertinent to any abnormal or emergent events that arise, or any unexpected delays that
are encountered. Last, the electronic charting is completed in the recovery room. At
this stage, a final vital signs entry is recorded, a postoperative assessment is performed,
postoperative orders are entered into the system, and the chart is closed.

Development of the OpChart system was begun in 1996, and its first clinical deploy-
ment occurred at the Riverview Clinic (TRC) as a pilot site in 1997. From there, it was
also deployed in an orthopedic outpatient surgery unit, in West Medical Building
(WMB), in gynecological ORs, and in the main Riverview University Hospital (RUH)
operating suites. All these implementations went smoothly with the exception of the
one in WMB, which will be described later in detail. Of note, the system has also been
successfully deployed at a private nonteaching hospital in Fairview, located about 1
hour from RUMC. The system is presently being used in twenty-eight operating rooms
at the local institution, not including the operating rooms located in WMB. The
intended users of the system include attending physicians in anesthesiology, resident
physicians, CRNAs, and SRNAs. The decision of whether to use OpChart for any given
case is made by the attending physician at the time when the patient is brought into
the OR. During the course of a case, the primary end user of the system is generally a
resident or a CRNA. Only one individual can use the system at a given time for each
case, but the designated user can change during the course of longer operations, with
a maximum of three users associated with any particular case.

As the system was being implemented, users were trained in the OpChart system
through in-service instruction consisting of group classes. Some test patient files and
real charts from old cases are available to these users for training purposes. End user
feedback is obtained through a forum, open to all RUMC users of OpChart, which
typically meets once or twice a month. The frequency of these meetings is adjusted
according to user attendance, and some time periods passed without forum meetings
because of low attendance. The official front line of support for the OpChart system
comes from the local medical center help line. The help line is a general user support
desk that services all clinical informatics applications. This center therefore serves as a
general relay center for messages regarding issues with the system. According to the
help line, any computing problem that interferes with the ability of a clinician to deliver
patient care is labeled a “critical problem,” and consequently calls from OpChart users
who have an ongoing case are given the highest priority. From the help line, a request
for help can be relayed to an on-call anesthesia support person, although passing along
the issue like this causes a concomitant delay. As backup, a system analyst or pro-
grammer is also on call and can be contacted for support. It should be noted, however,
that most users prefer to obtain informal technical support from other end users, par-

84 Section III. Implementation

LTF8 10/11/2004 8:45 AM Page 84

EBSCOhost – printed on 6/14/2023 5:53 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

ticularly those who are most savvy with technology. In fact, while the authors were
interviewing Charles Bertram, a CRNA “superuser” of OpChart, he fielded a phone
call from another system user who needed assistance. Moreover, Bertram assembled
the only comprehensive documentation for OpChart, in the form of a user guide that
was released in January 2003. He undertook this documentation project under his own
initiative.

The overall user sentiment toward the software is positive from the staff members
who work in the adult operating suites. Resident physicians obtain the most varied
exposure to OpChart since they rotate through different surgical services and experi-
ence it in a variety of environments. As a result, they are reportedly comfortable with
the system and do not have problems using it in these different areas. One resident
interviewed in the outpatient surgical area stated that he liked the system because of
the ease of transfer between users in the middle of an operation. He also noted that it
eliminates the need for the interpretation of handwriting, which is sometimes ambigu-
ous and may lead to medical errors. Charles Bertram reported that he likes the system
because he can pull a record from prior surgeries for a given patient, check the status
of the airway in those cases, and see how it was managed. When he finishes an opera-
tion and closes the chart, he is satisfied knowing that the charting is “100 percent com-
plete.” A few users have complained about specific aspects of the system. For example,
it cannot interface with the monitors that display vital signs, so the user must read the
monitors and enter this data into the system manually. Also, some of the available tem-
plates are a bit limited because the template does not include intravenous drips, drug
selection is limited, and there is no option to customize which vital signs will be mon-
itored. One particularly common complaint is that the system is slow and unrespon-
sive when it is querying the central server for information. This slowdown can lead to
a great deal of waiting when the system is overloaded, and delays in the OR can cause
frustration for the entire team.

WMB and the Initial OpChart Implementation

The focus of this case study is the implementation of OpChart into an operating suite
consisting of nine rooms located in WMB, a building adjacent to the main hospital. The
case load for this area includes most pediatric surgical cases, including pediatric sub-
specialty cases such as orthopedics and ear, nose, and throat. Adult ophthalmology
operations are also performed at this location. The only pediatric cases not performed
in WMB are pediatric cardiothoracic procedures, which are done in the main RUMC
operating suite. Six rooms are designated for pediatrics, two rooms are reserved for
ophthalmology, and the remaining room is used for either type of operation.The WMB
operating suite has its own dedicated preoperative rooms and postoperative recovery
areas. Procedures are scheduled Monday through Friday from 7:00 a.m. through
approximately 4:00 p.m. to 5:00 p.m. The anesthesia staff who work in WMB are spe-
cially trained for pediatric care, and the vast majority of them work only at this loca-
tion and do not rotate through any other surgical areas of the hospital. The notable
exceptions to this are the anesthesia residents, who rotate monthly among all the
surgical areas.

Each surgical suite within the medical center is unique, having its own clinical focus,
management style, and local culture. The operating suites in WMB are perhaps even
more unique than most. Anesthesia department members at large and the individual
staff who work there have expressed a number of ways in which they differ from other

8. Implementation of OpChart in West Medical Building 85

LTF8 10/11/2004 8:45 AM Page 85

EBSCOhost – printed on 6/14/2023 5:53 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

surgical locations. First, the primary clinical focus in WMB is on pediatric patients.
Operations performed on children require that closer attention be paid to the patient,
and as a consequence, less time can be spent on other things such as electronic docu-
mentation. Significant attention must be paid to airway management, as pediatric cases
generally use uncuffed endotracheal tubes which are more prone to becoming dis-
lodged during an operation. Second, in WMB, cases take less time on average to com-
plete. This means there are more operations being performed in each room per day
and that efficient, rapid turnaround time between cases in an OR is essential. This
turnover rate is dependent on many factors, and the speed with which the anesthesia
staff can finish charting one case and begin charting the next may be, but ought not to
be, a rate-limiting factor.

Finally, there appears to be a different culture in the work styles of the pediatric spe-
cialists. Many of the attending anesthesiologists are very opinionated and particular
about how charting should be done. As previously mentioned, OpChart allows for cus-
tomized user templates which serve as a basis for clinical documentation. It has been
observed that some anesthesiologists in WMB have strong feelings about not using the
same templates used in other areas. For example, some request that no information
about emergency situations be included in the templates and that the airway manage-
ment details be documented without the use of a premade template. Despite these dif-
ferences, there are important aspects of the care delivered in WMB that are shared by
other locales. As previously mentioned, pediatric cardiothoracic surgery is performed
in the main hospital OR, and OpChart is used for documentation in all these cases.

In 2000, the majority of the operating rooms at RUMC were using OpChart for their
intraoperative documentation. Because the operating suite in WMB was already using
some of the RPCMS applications to perform preoperative and postoperative assess-
ments, this location was next on the implementation schedule for OpChart. The first
step of the implementation involved the installation of hardware in each of the nine
operating rooms. Some users attended an informal 1-hour “in-service” training session
led by Dr. McPeak, the clinical lead for the project, as a means of introduction to the
system. However, there was no mandate at this point that the system be used during
operations, nor were there any official training classes or dedicated support staff. No
timetable for the planned implementation was generally publicized.At this point, many
of the users who had little experience with OpChart (attending physicians and CRNAs
who work only in WMB) began to experiment and use the system on their own,
attempting to use OpChart for some of their cases.

Although they were already using other RPCMS components, the introduction of
OpChart did not go smoothly. Over the course of several weeks, a general feeling of
contempt for OpChart developed among the users. Objections to the system were
legion—however, they can be classified into a few broad categories. First, users felt that
OpChart did not integrate well into the clinical work flow. The extra time needed to
initiate and complete the charting between cases added delays to the room turnaround
time. These delays were extremely unpopular with all the staff but especially with sur-
geons who desire to finish their cases as quickly as possible. Unfortunately, the impact
of this time delay was greatest for shorter operations, which are very common in pedi-
atrics. Also affecting short cases was the amount of time it took to document vital signs
on the computer vs. the traditional paper-based system. A second complaint was that
OpChart was not well suited for use with pediatric patients. Because more careful
attention must be paid to managing a child’s airway than an adult’s airway, pediatric
CRNAs commented that having to use the computer required them to have their hands
off the patient for too long. Also, the database of drug information in OpChart did not

86 Section III. Implementation

LTF8 10/11/2004 8:45 AM Page 86

EBSCOhost – printed on 6/14/2023 5:53 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

contain many common medications or the doses used in pediatrics. The system did not
enable weight-based dosing for many medicines, did not allow medications to be given
per rectum, and did not allow for dosing in quantities of micrograms.The result of these
problems was frustration during charting and a necessity to revert to paper-based chart-
ing when obstacles were encountered. A third shortcoming was that many technical
issues were encountered during the implementation. The computers used had only a
mouse as a means of input, and there was a very limited surface on which to roll the
mouse. One user noted that OR rooms elsewhere in RUMC were equipped with touch
screens that allowed faster data input. Furthermore, a number of software bugs were
mentioned as a problem. Computers momentarily paused or crashed and might require
up to 10 minutes to remedy. This led to unacceptable delays in the operation and an
overall mistrust in the reliability of the OpChart system. A fourth objection was that
training and support were very limited.Although there was no official mandate to begin
using OpChart, users felt that they were not adequately trained by the 1-hour in-service
instruction. No additional classes or tutorials were available for further training, and
although users trained in OpChart at other sites seemed pleased to lend assistance,
they were not always available to help.Technical support was provided by the help line,
although as noted previously, these staff members did not have sufficient knowledge
to troubleshoot RPCMS and there was a time delay in contacting a systems expert.
This delay of even a few minutes was unacceptable when a problem occurred during
an operation. A final category of complaints related to the specialized culture of WMB
in general. The personnel who work in WMB are focused on two types of cases: pedi-
atrics and ophthalmology. Overall, they seemed to be resistant to a change in their work
flow, and there was a belief that their current charting methods were adequate and that
no change was needed. It was reported that one ophthalmology attending physician
forbade the use of OpChart while he was operating. Many users felt that OpChart was
a good application but that it was designed to be used with long adult cases and that
it was not suitable for the type of work performed in WMB.

After several weeks of nonmandatory implementation, the resistance to OpChart in
WMB reached a boiling point. One CRNA at the time noted that it was felt that the
system was being imposed on them from the outside and that all the problems had led
to a “climate of skepticism.” Some users had suggested to the administration ways to
make OpChart more usable in WMB. However, these changes were not made. Overall,
both new and seasoned OpChart users felt that the implementation should end. “No
one was against stopping,” stated one member of the staff who remembers this event.
The implementation was finally halted by Dr. McPeak. For the time being, OpChart
would not replace paper-based charting as the preferred method of documentation in
WMB.

A Second Effort at WMB Implementation

Although the initial deployment of OpChart in the WMB operating suites failed, a
second initiative is under way to implement the tool in that location. The current plan
for implementation involves a general rollout in November 2003. The hardware
required for OpChart deployment was already present in the operating suites prior
to implementation, and the software was rolled out in all the rooms at once—both
the dedicated pediatrics and the adult ophthalmology rooms—with no pilot site. This
implementation began approximately 3 weeks before the time of this writing. As
before, the project manager for this effort is Dr. Doug McPeak, who is an expert in

8. Implementation of OpChart in West Medical Building 87

LTF8 10/11/2004 8:45 AM Page 87

EBSCOhost – printed on 6/14/2023 5:53 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

OpChart and informatics. Two superusers, George Gibson and Charles Bertram, are
serving as program champions. They are both CRNAs who have extensive experience
in both using and troubleshooting the system. Dr. Steve Hays, an attending physician
in anesthesiology, is not a project champion per se, but he is very familiar with the
system, so he is assisting the implementation by providing assistance whenever possi-
ble to the CRNAs working on a given case. The help line staff is also responsible for
supporting this second installation, although none of them is specifically assigned to
the project. Last, the application developers are also available to support their product
for the WMB personnel. System education once again consisted of 1 hour of in-service
training led by Dr. McPeak. The switch to OpChart use is mandatory, although there
is provision for paper-based charting at the discretion of the attending anesthesiolo-
gist. Moreover, it is permissible for users to “bail out” to paper charting in the event
of computer hardware failure or application error that cannot be reconciled prior to
the end of the operation. At present, the software is being used in approximately 50
percent of the procedures performed in the WMB operating rooms. Paper charting is
primarily used for quick-turnaround cases of 15 minutes or less.

Some issues that created resistance to change in the initial implementation of
OpChart in WMB have been recognized and addressed. Some of the specific technical
changes that the users have requested have been implemented, including an area to
record patient body weight, the capability for weight-based drug dosing, dosing in
micrograms, and new routes for administration that are useful for pediatric caregivers.
Some hardware issues have been causing users trouble. One user noted: “Have a
network that is capable of handling [OpChart]. I know it is not that simple, but it seems
that the more traffic, the more traffic tie-ups. I am not a computer guy, but the network
and the servers need to able to handle the traffic, whether it is 6 a.m., 12 noon, or 8
p.m.”The perioperative informatics group has been proactive in addressing these issues.
For the one OR in which users have been experiencing extreme hang-ups and freezes,
they are rewiring the network cables to that room at their own expense. Moreover,
they are bringing in a computer known to be good to test it in the room and see if the
problem is with the computing hardware instead of the network. One user notes that
it remains difficult to attend the official OpChart forums, but more peer support is avail-
able at the present: “It is hard to attend the Gas Chart Forums that are held in the
Control Room. Often, they are held at 6:30 a.m.—those of us working in the WMB
usually have 7:00 a.m. starts and are unable to attend. Other informal meetings are held
during the day—I’m usually in a busy room.This time around, people have been around
to listen.” Another user likewise notes the improved user support but wishes that the
WMB operating rooms did not have to go live all at once: “We have provided a lot of
feedback. I feel like we have been listened to and several things have been changed.
However, I feel like it should have been implemented in one room first with a small
number of people to try it and find things to be changed, before it was started in all
the rooms.”

Of note, a few issues might arise in the plan for implementation of the system. No
formal mechanism has yet been developed to evaluate and learn from this implemen-
tation as it progresses. Dr. McPeak reviews the surgeries that were done with the paper-
based system to discern why they were not done using the OpChart system. Also, users
were not well informed about the timeline for change. One user said,“I’m not sure that
I know the timeline for the change.” Another commented that the change will occur
“when a system is available that meets the end user’s needs for charting, speed, and
reliability. When any of these are missing or lacking, it creates much frustration to new
users and old ones as well.” In other words, it will happen “when the system is ready.”

88 Section III. Implementation

LTF8 10/11/2004 8:45 AM Page 88

EBSCOhost – printed on 6/14/2023 5:53 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

Also, training again consisted of only 1 hour of in-service instruction, this time from
Dr. McPeak. Charles Bertram suggested that it might have been even more useful if
training involved a 2-hour one-on-one session with him or some other superuser who
has more time available to spend with individual users than an anesthesiology attend-
ing physician. Another user suggested that the training that was conducted might be
inadequate: “At the in-service there were problems with people signing on and a
problem with the instructor being able to show us everything they wanted to, not
because of time, but because it could not be done where we were being taught.” Also
noteworthy is the fact that the end users of the system have very little stake in the
implementation of OpChart in the WMB operating suite. Additionally, the benefit that
would be achieved by a successful deployment of the software will be reaped by the
hospital and WMB administrators, but it will not directly serve the end users of the
system.

A number of issues have already arisen in the presently ongoing implementation of
OpChart. Not all users are enthusiastically putting forth an effort to aid the system’s
adoption. One particular user at the site very quickly bailed out to the paper-based
system on two occasions out of frustration. As a general rule, some people are very
resistant to this change in WMB. Some staff members believe that for short operations,
using OpChart will increase the documentation time and thus lead to slower OR turn-
around time, which will create more costs to outweigh any of the benefits achieved by
the system. There is a belief that they do not need to change because current docu-
mentation techniques are adequate. Indeed, one CRNA has informally threatened to
quit if OpChart use is made mandatory. Possibly as a result of the prior failed imple-
mentation, some negative feelings already existed before the present implementation
ever started. A sentiment of “I don’t want to do this” exists. One CRNA reported that
for some users,“If they can find any excuse to change to paper, they will.” Some attend-
ing physicians are also resistant to OpChart—in particular, surgeons don’t like to see
a CRNA with their back turned to the patient. Some of them have a perception that
it takes away from their ability to care for patients. Surgeons expect the anesthesia staff
to be patient-centered, not computer-centered, during an operation—particularly
during pediatric operations. As one user summed it up, “Kids just need to be watched
a lot closer, period.”

Some technical issues also appear to be barriers to adoption. The speed of the com-
puters remains a common complaint. The system appears to be slow, causing a great
many lock-ups. One user points out how this slows down their work flow: “The longer
and busier the day, the longer it takes to start and to chart . . . 5 to 10 seconds here, 30
seconds there, 2 or 3 minutes to boot-up, 10 minutes to reboot in the OR may not seem
like much time, but with shorter cases and quicker turnovers between cases, it really
slows us down.” Another user laments the ever-recurrent “fickle hourglass” that
appears on the computer screen when it is processing—“I swear that it knows when
one is trying to finish a chart or start a case.” One operating suite is notoriously slower
than any of the others, but as mentioned earlier, this issue is being addressed. Also,
users are frustrated by the slowdown that occurs when one is required to wade through
multiple log-in screens at the beginning in order to access the system. They would
prefer to enter their user name and password once and then have complete access as
needed. This issue has been raised with the Department of Anesthesiology adminis-
tration as well as with the help line.

Ergonomic issues are again a point of contention in the OpChart implementation.
Some users wish that they were more flexibly mounted. One comments, “I find that I
am having more neck pain even though I have tried to position the computer to help

8. Implementation of OpChart in West Medical Building 89

LTF8 10/11/2004 8:45 AM Page 89

EBSCOhost – printed on 6/14/2023 5:53 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

me. For adult eyes, a few of the attendees spend a lot of time on the room workstation
when they could use another workstation—what about laptops or something that is
more portable?” One user feels that the computers are poorly mounted: “The mounts
are not stable. To stay in one position, you have to have a support under them.” Some
computers may be difficult for the user to reach during an operation, and users need
to keep two hands on the patient as much as possible. Thus, input devices remain an
issue. There is very little room for moving the mouse. One user seems to be envious of
the input abilities in other areas: “The computers do not have touch screens, unlike
many of the computers in other places. . . .”

Support for the end users will play a key role in determining the success of the
present OpChart implementation, and some users currently have an issue with insuf-
ficient support. Moreover, the help line, which serves as the official front line of support
for OpChart, is not trained in the use of the system. As one user noted, “On day one
we had good support, day two was only one person and we asked for that. We do not
have the ability to talk directly to a clinical person with a problem. We have to call the
help line and talk to a nice person, but they have no clue as to the frustration you expe-
rience when error screens pop up and you are trying to take care of a patient.” Because
the OR is a pressing environment where delays may carry significant consequences,
users would like to have on-site support available. “I do not feel like we as clinicians
should have to call the desk, report the error messages, tell what we were doing imme-
diately prior to the message coming up, and take care of a patient at the same time. It
distracts us from the patient. A computer ‘guru’ should be here in the operating rooms
to handle problems.” Finally, the relay mechanism for support, whereby the help line
pages the on-call anesthesiology support person, can be frustrating to users because of
the delay it causes. “Being told hang on, I will page someone, I will call you back, etc.,
does not help when a case is finishing.” Users are relatively helpless to accomplish their
designated clinical tasks during this time period if they are reliant on support to help
them continue using the computer system. This may further encourage reversion to the
paper-based system.

Evaluation and Conclusion

In this case study, the authors have described efforts to implement a medical infor-
matics system in a suite of operating rooms used for pediatric surgery and adult oph-
thalmic surgery. Although this system has been readily accepted by all other surgical
units within the medical center, successful adoption in this one area has been elusive.
Although they care for a specialized patient population with a different case mix from
other surgical areas, there is no single factor that stands out as the most direct cause
for the failed initial deployment. Both short operations with a rapid turnover and pedi-
atric cases are performed in other surgical areas where OpChart is used successfully.
In addition, rotating anesthesiology residents who are already accustomed to using
OpChart in other surgical areas seem to be able to use it effectively in WMB as well.

The difficulties encountered during OpChart implementation in the WMB operat-
ing suite seem grounded in two main areas: technical issues and cultural issues. The
technical limitations of the system led to the opinion that the application is not well-
suited for use in this area, and that the system lacks some functionality that would have
made it better suited for use in this environment. These complications were exacer-
bated both by a relative low level of training and preparation of the users for imple-
mentation, and by technical support that has been insufficient for a demanding surgical

90 Section III. Implementation

LTF8 10/11/2004 8:45 AM Page 90

EBSCOhost – printed on 6/14/2023 5:53 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

environment. Nonetheless, some of these limitations likely existed and were overcome
during the OpChart adoption in other areas. Thanks to ongoing development of the
OpChart software, some of these technical issues were addressed prior to the start of
the present implementation, but other problems still remain—particularly those with
hardware and network slowdowns and with difficult OR ergonomics. Cultural and
organizational barriers seem to be another significant barrier to acceptance of the
OpChart system in the WMB operating rooms. The highly specialized, self-sufficient
pediatric anesthesiology staff members have demonstrated a low perceived need for
the documentation tool. They became fixed on the system’s imperfections and ulti-
mately viewed the product as a potential liability rather than as a beneficial tool. A
negative bias toward the software persists after the first deployment. Finally, the staff
members seem to view the proposed implementation of OpChart as being imposed on
them by outside forces. They have no sense of ownership of the project because the
implementation is being forced on them by those higher up in the RUMC hierarchy.
This sentiment likely further increases their resistance to adoption.

Three years have passed since the first incident of failure, and now another attempt
is being made to bring OpChart into WMB. Many obstacles still remain in the path of
successful adoption of the software. This unique blend of cultural and technical road-
blocks may prove to be difficult to conquer. However, none of these problems are likely
to be insurmountable given time, patience, and responsiveness on the part of all parties
involved. The future of the current OpChart implementation in WMB hinges on the
ability of the administration, developers, and end users to recognize the difficult issues,
lying in the path to success and to find a means of overcoming them.

Questions

1. What problem(s) was OpChart intended to address? Who perceived these issues to
be problems?

2. What factors contributed to OpChart’s poor reception in WMB? Could they have
been anticipated or mitigated?

3. From a behaviorist point of view, comment on the positive and negative reinforcers
that influence users of OpChart. How were these reinforcers different in WMB?

4. What would you do to increase the probability that OpChart will have a successful
reimplementation?

5. What extra costs would you incur in order to address user complaints?
6. What are the implications of another unsuccessful implementation? What are the

sunk costs already incurred?

8. Implementation of OpChart in West Medical Building 91

LTF8 10/11/2004 8:45 AM Page 91

EBSCOhost – printed on 6/14/2023 5:53 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

7
Developing an Emergency
Department Information System

Duncan Belser, Dominik Aronsky, David M. Dilts,
and Jose Ferreira

It was the summer of 1997 when executive leadership and managers from the emer-
gency department (ED) and the informatics center first teamed up to contemplate
implementing an information system to support clinical processes and administrative
functions in the ED. Three years later, the same group, with a few new members, by
then called the emergency department information system (EDIS) team, abandoned
its efforts to purchase an off-the-shelf solution and commissioned the development of
a set of custom interfaces to the institution’s multitude of existing applications. After
two more years, the most central and publicly visible of these components, the elec-
tronic whiteboard (eWB), successfully passed its first uninterrupted overnight usabil-
ity test. After more than 5 years of effort, the passage of this milestone marked a long
overdue win for the EDIS team.

Although the project achieved its stated objectives, why had it taken so long? What,
if anything, could have been done differently to speed up the process? More impor-
tantly, what could be learned from this experience to facilitate other healthcare infor-
matics projects in the future? To answer these questions, we examined the history of
the development and implementation of the EDIS from its inception to the imple-
mentation of the eWB in September 2002. (See Table 7.1 for the EDIS project time-
line.) Through interviews with key project participants, analysis of project documents,
and discussions with other relevant stakeholders, it appears that the project was com-
plicated and prolonged initially by the team’s inability to find a suitable solution in the
vendor marketplace and subsequently by delays associated with designing and rapid-
prototyping a custom information system. In retrospect, it is also apparent that the
project is best described not as one activity but two that occurred as separate phases
marked by distinct differences in scope, approach, goal setting, leadership, and out-
comes. This chapter presents the relevant history of each phase and traces the major
distinctions between them that we believe show the lessons to be learned from the
experience.

Early History of the EDIS Project

By the spring of 1997, service levels in the ED required serious attention. Foremost,
wait times were well above industry benchmarks and patient satisfaction was low.Addi-
tionally, referring primary care providers consistently complained about poor notifica-
tion while their patients were in the ED, and few were satisfied with the summary
reports provided after discharge. Finally, according to an internal study, 76 percent of

69

LTF7 10/11/2004 8:43 AM Page 69

C
o
p
y
r
i
g
h
t

2
0
0
5
.

S
p
r
i
n
g
e
r
.

A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

M
a
y

n
o
t

b
e

r
e
p
r
o
d
u
c
e
d

i
n

a
n
y

f
o
r
m

w
i
t
h
o
u
t

p
e
r
m
i
s
s
i
o
n

f
r
o
m

t
h
e

p
u
b
l
i
s
h
e
r
,

e
x
c
e
p
t

f
a
i
r

u
s
e
s

p
e
r
m
i
t
t
e
d

u
n
d
e
r

U
.
S
.

o
r

a
p
p
l
i
c
a
b
l
e

c
o
p
y
r
i
g
h
t

l
a
w
.

EBSCO Publishing : eBook Collection (EBSCOhost) – printed on 6/14/2023 6:02 PM via WALDEN UNIVERSITY
AN: 145750 ; Nancy M. Lorenzi, Joan S. Ash, Jonathan Einbinder, Wendy McPhee, Laura Einbinder.; Transforming Health Care Through
Information
Account: s6527200.main.eds

70 Section III. Implementation

TABLE 7.1. EDIS project timeline.

• July 1997—EDIS steering committee decides to investigate technology solutions to transform
emergency department (ED) operations.

• November and December 1997—External consultants conduct ED operational review.

• January 1998—ED considers piloting an application to replace transcription.
• July 1998—Computerization work group produces request for information entitled “Functional

Requirements for Patient Tracking System” for circulation to vendors.
• July 1998—EDIS team begins investigating vendors of off-the-shelf patient tracking system

solutions.

• EDIS team continues investigating vendors of off-the-shelf patient tracking system solutions.

• March 2000—EDIS team holds kickoff meeting to discuss purpose, priorities, and issues related
to implementing an information system in the ED.

• September 2000—EDIS team decides to build an ED patient tracking system that integrates
with existing information systems and identifies key functional requirements, proposed data
flow, and action steps.

• January 2001—EDIS team presents data flow diagram for ED processes.
• March 2001—Hospital administration approves budget to update network and install hardware

in the adult and pediatric emergency departments for EDIS.
• Spring 2001:

1. EDIS team gets new project manager with Informatics and ED experience.
2. EDIS team begins meeting with the ED staff weekly.
3. EDIS team presents prototype of an ED information system.

• June 2001—EDIS team introduces Web cam to broadcast the dry-erase board to the
registration area.

• July 2001—EDIS team receives approval to hire a programmer/developer.
• September 2001—EDIS team redesigns adult ED registration process by focusing on speed

(rapid registration).
• October 2001—EDIS team implements rapid registration process in the adult and pediatric

EDs (including completing the installation of a wireless network).
• Fall 2001:

1. EDIS team hires a programmer/developer to work on the Web-based EDIS as first priority.
2. EDIS team demonstrates early ED whiteboard prototype.

• March 2002—EDIS team completes early manual for ED whiteboard application and begins
developing user training materials, including Web-based training tools.

• April–May 2002:
1. EDIS team presents electronic whiteboard (eWb) Overview presentation to the ED and

suggests a plan for a staged go-live, first using existing systems in tandem use, then without
original marker board; includes documented contents to maintain and role-based
responsibilities.

2. ED nurse educator, assistant managers, and managers conduct user training on the job.
• September 19, 2002—eWB application completes first overnight operational usability test.
• December 11, 2002—EDIS project manager produces first new reports on ED operational

statistics for September, October, and November using EDIS.

P
hase I

P
hase I

1997
1998

1999
2000

2001
2002

the ED faculty and 58 percent of the ED nursing staff were dissatisfied with the exist-
ing technology resources that were in place to facilitate the clinical and administrative
functions of the department.

In reaction to these issues, the EDIS steering committee convened a team of infor-
matics and ED staff members (Table 7.2) on July 14, 1997, to discuss how information
technology might be applied to ease the operational problems in the ED. The team,

LTF7 10/11/2004 8:43 AM Page 70

EBSCOhost – printed on 6/14/2023 6:02 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

7. Developing an Emergency Department Information System 71

composed of representatives and executives from a broad number of hospital func-
tions, immediately targeted what it identified as two separate problems. First, they
brainstormed a preliminary list of features the department would require in a system
to manage its information needs; and, second, the group hired a team of external con-
sultants to conduct an operational review of the ED and recommend key changes to
improve satisfaction and performance.

Over the course of November and December of 1997, external consultants inter-
viewed a number of patients and staff and examined most of the department’s core
processes. In a February 1998 report, they highlighted five key factors that were nega-
tively affecting the service environment in the ED. Specifically, they noted ambiguity
among staff roles and a general lack of concern for patient or referring physician sat-
isfaction. They also reported that staffing levels were not well matched to patient
volumes, managers could not monitor occupancy levels efficiently in real time, and
administration of the cross-function paper-based processes was highly cumbersome.
They recommended that the department would benefit from service-oriented team-
building exercises, focused discussions around job duties with respect to departmental
responsibilities, and, as examined below, implementation of a suitable information
system to measure and coordinate its activities.

Regarding the department’s need for an information system, the consultants specif-
ically noted that volatility in daily and sometimes hourly demand for emergency serv-
ices often resulted in gaps between the number of patients waiting to be seen and the
number of providers available to care for them. It was primarily these gaps that caused
excessive wait times and, consequently, drove down patient satisfaction. However, gaps
were compounded by the fact that department managers could not efficiently monitor
and adapt to changes in occupancy. Rather, they could only rely on retrospective and
time-consuming analysis of historical throughput metrics (admissions, discharges, etc.)
for ex post facto guidance in staffing model planning. The right information manage-
ment system, it was expected, would enable dynamic monitoring of waiting and care
delivery areas. Monitoring data collected by the system, combined with rules-based
condition triggers embedded in the software, could alert managers to react when some-
thing unusual happened, e.g., if, on a hypothetical Friday, demand peaked in the
morning rush hour rather than as usual in the afternoon or early evening because of
an accident on the nearby interstate.

TABLE 7.2. EDIS Team.
Emergency department (ED) representatives Informatics department representatives

• Chair of the Department of Emergency Medicinea • Director of informatics centera

• ED administrative directora • Members of the order entry application team
• Director of adult EDa • Members of the information systems support team
• Director of pediatric ED • Chief technology officer
• Manager of adult ED • Chief information officer
• Assistant manager of adult ED • Information services consultants (to serve as
• Manager of pediatric ED project managers until Spring 2001)
• Assistant manager of pediatric ED • EDIS lead programmer/developer (since Fall
• Director of admitting 2001
• Director of ED finances • EDIS project manager** (informatics faculty;
• ED nurse educator since Spring 2001)
• Director of ED registration (added in 2001)

a Member of the EDIS steering committee.

LTF7 10/11/2004 8:43 AM Page 71

EBSCOhost – printed on 6/14/2023 6:02 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

72 Section III. Implementation

In addition to the lack of real-time activity monitoring and staffing-level planning
capabilities, the consultants observed that data collection for care delivery and admin-
istration required an unmanageable and often unorganized volume of paperwork. In
fact, they observed, paper-based processes in the ED were so cumbersome that they
were a major cause of dissatisfaction to all parties involved and a primary obstacle to
preparing documents for referring physicians. Perhaps worse, some paperwork was the
limiting factor in the speed of care delivery sequences. For example, in patient regis-
tration, lengthy forms had to be completed before triage could be performed—a major
source of patient dissatisfaction. In addition, discharge summaries were challenging to
create because information was stored in collections of charts and shadow charts
throughout the care delivery process. An appropriate information system, it was
thought, could reduce the paperwork onus by separating information collection activ-
ities from care delivery sequences. Such a resource would centralize information man-
agement and enable report production on demand.

With these findings in mind, the EDIS team began discussing possible information
technology solutions. Because the institution had considerable experience with build-
ing its own clinical applications, the debate quickly centered around evaluating the
classic “build-vs.-buy” decision. In many ways, however, these conversations were pre-
mature because the question of what to buy or build had never been completely clar-
ified. Some favored implementing a patient tracking system and advocated scouring
the marketplace for vendor solutions. Others with a broader interest began defining
the feature set of a tool to meet a variety of the department’s operational needs. As
one might have expected, there were also a few who resisted the effort entirely, expect-
ing that the ED physicians would never adopt such a system.

Eventually, because of the substantial patient satisfaction and care delivery issues
associated with the department’s long wait and throughput times, the team focused on
acquiring a system for real-time activity monitoring and resource management. In what
ultimately was a fateful choice, solving the paper-based process challenges became a
secondary priority. Instead, the dominant vision became that of a patient tracking
system that could be used to capture time-and-motion statistics that would help man-
agers identify those situations when waiting areas grew full or process bottlenecks that
needed to be addressed. They planned that ED nurses and staff would keep the system
current by recording the time of each patient’s check-in, triage, encounter, discharge,
etc., and thereby the task of tracking patients through departmental areas would be
accomplished. With this in mind, team members finalized their desired functional
requirements for a tracking system by early July 1998 (Table 7.3) and began evaluat-
ing vendor solutions in late summer.

Despite a rather confident start, success did not come quickly. To the contrary,
the group corresponded with almost a dozen vendors for the next 18 months and
held numerous meetings to no avail. There were, in fact, major issues with the team’s
approach that complicated the project. Foremost, it proved impossible to find a system
that could be cost-effectively integrated with the array of internally developed and
continuously evolving applications already in use throughout the medical center.
Although legacy system issues were common to similar information technology
projects, they were particularly limiting in this circumstance because the environment
was changing at a rapid pace of two or three major clinical application additions each
year. Furthermore, the team eventually concluded that vendor dependency would
reduce the organization’s flexibility to implement software design changes in future
versions. Because flexibility was particularly important in the context of such a dynamic

LTF7 10/11/2004 8:43 AM Page 72

EBSCOhost – printed on 6/14/2023 6:02 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

7. Developing an Emergency Department Information System 73

system environment, the team was reluctant to make any commitment to an external
party.

Perhaps even worse, the market for ED information systems was in its infancy at the
time. As such, the risk of losing flexibility for customization was not as significant as
the risk of the chosen vendor not being able to maintain its customer service levels or
even going out of business in the middle of the implementation. Although this default
risk could have been managed through software contract provisions specifying source
code escrow arrangements, the possibility of the project collapsing for reasons beyond
the control of the team made it difficult to settle on a single vendor. Finally, in addi-
tion to the technical and business issues mentioned, more challenging perhaps was the
vagueness of the notion of a patient tracking system and how it would integrate with
emergency medicine operations. In the planned scenario, nurses and staff were
expected to maintain the system in addition to their normal activities. Some feared that
this model of patient tracking, with its additional administrative layer, would overtax
an already burdened team and reduce satisfaction even further. As a result, documents
show that in September 2000 the EDIS team abandoned its efforts to pursue an off-
the-shelf solution and began planning to design and build its own system, an effort that
would extend the project into the following spring when new leadership would arrive
to carry it in a new direction.

TABLE 7.3. EDIS design process results, July 1998.
Planned features Expected benefits Desired tracking statistics

• Increased revenue from lost
charges

• Reduction of emergency
department (ED) paper-/form
costs

• Increased quality of medical
information available to
primary care providers

• Reduced risk due to illegible or
incomplete clinical or billing
information

• Improved use of nurse time
• More efficient tracking of

patients
• Reduced length of stay (LOS)
• Reduced patient elopement
• Improved ability to retain staff
• Improved relations with other

hospitals
• Increased availability of

management reports with
increased facility of reporting

• Increased documentation of
supplies utilized in care
delivery for better
reimbursement

• Security and confidentiality
protection to meet JCAHO
requirements

• Computer-generated medical
record automatically interfaced
with hospital information
system

• Integrated hospital registration
with insurance verification

• Computer-generated triage
note

• Computer-maintained tracking
board with automatic warning
prompts

• Computerized order entry
• Computerized nursing notes
• Automatic retrieval of

laboratory and radiology
results

• Full electrocardiograph (ECG)
recorded in record (not just
interpretation)

• Automatic coding of diagnosis
• Support for continuous quality

Improvement (CQI) initiatives
• Built-in time out if user walks

away from terminal
• PIN identification for quick

access
• Prompts and flags based on

preset parameters

• Time of arrival
• Time of triage
• Time to bed
• Time of initial nurse

assessment
• Time of initial physician

contact
• Time of disposition

decision (admit to hospital
or treat and release)

• Time of ED departure
(discharged from ED or
admitted to hospital

Source: Internal memoranda.

LTF7 10/11/2004 8:43 AM Page 73

EBSCOhost – printed on 6/14/2023 6:02 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

Designing the EDIS

From a historical perspective, the spring of 2001 marked a new and second phase in
the EDIS project timeline (Table 7.1).At the beginning of this period, the team restruc-
tured itself from a collaborative “system selection” team into a project manager–led
“system design and development” work group. To mesh the design process with the
department’s operational realities, the team named a physician informaticist with pre-
vious experience in emergency medicine as the project manager and partnered this
individual with the director of the adult ED (a practicing attending physician).

The project management duo began by making a number of strategic changes
to the project’s objective and scope, and they entirely reorganized the team’s approach.
Foremost, they focused the project on improving overall ED performance—
addressing the operational issues identified in 1998—through process analysis and
information needs assessment across all ED functions. This was a marked difference
from the earlier goal of implementing an off-the-shelf patient tracking system. In fact,
this new objective meant reevaluating a number of long-standing processes, many of
which had been previously considered unalterable, to identify opportunities where
information technology might help to increase efficiency. In addition to advocating
process analysis, the pair asserted that an integrated approach to using technology
within functions should dictate process redesign efforts. Specifically, the idea of track-
ing patients by implementing a supplementary departmental system was inappropri-
ate. Instead, the pair argued that tracking data could be collected in the background
of any activity if an appropriately designed information system could be integrated
with the process. For example, if supported by the right series of screens and dialog
boxes, a nurse could use a custom module of the EDIS to record triage information
while the system was automatically collecting timing statistics based on specific button
clicks. Under this integrated approach, data from triage could be combined with data
collected in a similar fashion from other process functions, e.g., discharge, to form the
foundation data set for analyzing throughput metrics and identifying improvement
opportunities. This model of process-integrated and function-specific components was
drastically different from the layered tracking system approach first contemplated by
the EDIS team. Implementing this strategy required weekly meetings and rapid pro-
totyping of the process-related software components, but it produced results almost
immediately.

The EDIS team had noteworthy success in adopting this new strategy, and no
redesign was more dramatic than that of the patient registration function. In fact, the
operational analysis from 1998 had indicated that the 20 to 25 minutes required to reg-
ister a patient caused unnecessary delays and negatively affected patient satisfaction.
However, after careful review, the team concluded that registration could be completed
in less than 2 minutes if the focus could be shifted away from “completing the admin-
istrative (nonclinical) data collection” to instead emphasize “getting the patient into
the system for treatment” as soon as possible. With this in mind, the team implemented
a rapid registration procedure that simplified the registration process from a series of
ten computer screens to a single computer screen with only six basic data elements. To
complete gathering of the required data, the team implemented a new process by which
nurses would use wireless laptops at the bedside only after triage and urgent care needs
had been addressed. By letting patients receive the care that they were seeking as fast
as possible, this redesign eventually made better use of waiting time and significantly
improved satisfaction. Redesign efforts for triage, assessment, order entry, and dis-
charge processes had similar results.

74 Section III. Implementation

LTF7 10/11/2004 8:43 AM Page 74

EBSCOhost – printed on 6/14/2023 6:02 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

7. Developing an Emergency Department Information System 75

In parallel with its process redesign efforts, the team began to design the EDIS as a
suite of integrated software components. To prioritize the development of these func-
tion-specific tools, the project managers developed prototypes and encouraged the
team to evaluate each one along three dimensions: ED priority, EDIS team priority,
and implementation difficulty (Table 7.4). After this analysis, the project managers
readily identified the two components that represented their greatest opportunity for
dramatic success: the eWB and its notification interfaces. However, to achieve success
and have a dramatic impact on the department, they knew they had to carefully manage
the associated risks. With this in mind, the new project leadership segmented their
design approach to address interfaces separately from system components and focused
their efforts on the highest-priority items.

The two highest-priority interfaces that the design team had to incorporate into the
EDIS were links to the hospital’s longitudinal patient record and its provider order
entry system. Because both these major applications were still evolving and because
both were being implemented on independent timetables beyond the control of the
EDIS team, creating interfaces to them was particularly risky. To manage this risk,
however, the EDIS project managers strategically decoupled the success of the inter-
faces from the project’s overall success by stratifying the level of integration required
and staging the availability of difficult-to-create features. For example, because the lon-
gitudinal patient record had been implemented on workstations in the ED, clinicians
could already use its basic functionality to access patient records. However, the EDIS
project managers deferred promising the ability to notify ED staff when a new lab
report or radiology impression was available in the electronic record until they knew
it was technically possible. In a similar fashion, the EDIS project managers carefully
planned an interface to the hospital’s provider order entry system. However, because
order entry had not been implemented in the ED by the time planning for the EDIS
began, the team designed an interface that could be activated at a later date but was
not a required component of the core EDIS. This strategic separation proved fortunate
because, as it turned out, the plan to implement order entry software in the ED was
postponed, but EDIS development proceeded without interruption.

The highest-priority noninterface component of the EDIS was to be an electronic
version of the department’s whiteboard. In fact, the prominent dry-erase board that

TABLE 7.4. Assessment of proposed EDIS Components.a

EDIS team Implementation
Proposed EDIS component ED priority priority difficulty

Electronic whiteboard 1 1 1
Real-time notification through interfaces to laboratory, 1 1 1

order entry, radiology, and electrocardiograph systems
Rapid sign-on mechanism 1 1 2
Rapid registration 1 1 3
Discharge documentation 1 2 4
Electronic triage documentation 2 2 3
Demographic information access 2 3 3
Management reporting 2 3 3
On-call management 2 3 5
Staff scheduling 4 4 3
Nurse charting 5 4 2

a Proposed components were assessed across three dimensions: emergency room (ED) priority, EDIS team
priority, and implementation difficulty. Score ranges: 1 (highest) to 5 (lowest). Scores of one (1) indicate highest
priority or most difficult to implement.

LTF7 10/11/2004 8:43 AM Page 75

EBSCOhost – printed on 6/14/2023 6:02 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

the proposed eWB would replace was the department’s most central and vital tool for
managing its operations at a glance. It was a central place to look for information on
patient status and flow, occupancy levels and waiting room queues, operational statis-
tics and emergency telephone numbers, etc. With the right information on the board,
providers, staff, and operations managers could use it to make decisions about the
service they were providing and the activities they were monitoring. Unfortunately,
manual processes associated with the maintenance of time-sensitive information on the
whiteboard were problematic. Keeping it up-to-the-minute took nurses away from their
direct patient care responsibilities, and physicians wasted time looking for patients,
checking for lab results, or occasionally ordering redundant tests when the information
was not current. Cleaning staff wasted time unnecessarily searching for rooms to clean
instead of knowing exactly which rooms required attention, and receptionists often had
to physically check a room’s status when they needed to admit a patient because the
information on the board could not be seen from the reception area. In sum, the manual
whiteboard did not enable the vital status monitoring functions that it was intended to
support. It was these shortcomings that made the creation of an eWB a top priority for
the EDIS team in the Fall of 2001.

The focus that the team placed on developing and prototyping the eWB resulted in
total replacement of the manual system in a period of 9 months. One of the first pro-
totypes demonstrated how a network could distribute information to multiple areas of
the ED, and it was immediately beneficial. Specifically, the team installed an inexpen-
sive network camera in the clinical area of the department, focused it on the manual
whiteboard, and posted its images to an intranet site. Receptionists were then able to
view the whiteboard from their desks through a Web browser, eliminating the need for
them to run to the back in the middle of an admission. This interim solution based on
simple technology brought early relief to the user group most negatively affected by
the manual system. At the same time, feedback from the department facilitated the
team’s rapid prototyping efforts to design and build a Web-based, database-driven soft-
ware application for a touch-sensitive plasma monitor that would eventually hang on
the same wall where the original marker board had been for years. Figure 7.1 shows
the transformation from the manual whiteboard to the electronic version.

Today, the eWB is not only different from the original whiteboard in appearance but
is also radically different in the way it is populated with information and in the way it
makes information available. For example, because of the redesigned rapid registra-
tion process, patient names and chief complaints are automatically added to a central
database and therefore become visible and editable instantaneously to authorized indi-
viduals throughout the department. Patient tracking happens automatically in real
time, and special tools to highlight extended waits have increased staff awareness of
potential service issues. Notification engines are implemented to keep the eWB infor-
mation about room status, clinical alerts, and test results updated continuously. The
system also automatically tracks the length of stay for individual patients and computes
aggregate operational statistics for the department (occupancy rate, waiting room
count, average length of stay) that can be queried and presented in performance analy-
sis reports. Furthermore, clinicians, managers, and executive leadership can use the
tool’s Web interface to conduct off-site monitoring of events in the ED if necessary.
On a larger scale, the monitoring capabilities have even been extended to facilitate the
department’s participation in a countywide biosurveillance program, a capability that
was never anticipated. In sum, the eWB has met and exceeded the expectations that
surrounded its initial development. These phase II project successes are summarized
in Table 7.5.

76 Section III. Implementation

LTF7 10/11/2004 8:43 AM Page 76

EBSCOhost – printed on 6/14/2023 6:02 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

7. Developing an Emergency Department Information System 77

FIGURE 7.1. The traditional whiteboard and the electronic whiteboard (eWB). (Reprinted with
permission.)

The marker board-based traditional whiteboard

The Web-based and database-driven electronic whiteboard

LTF7 10/11/2004 8:43 AM Page 77

EBSCOhost – printed on 6/14/2023 6:02 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

78 Section III. Implementation

Conclusion

Despite its ultimately successful outcome, considering the total EDIS project duration,
extending from its conception in 1997 to the first full run of the eWB in late 2002, a
reader might wonder how to evaluate and justify a project with such a long history. As
has been described, however, development of the EDIS was a two-phase project with
distinct differences between its phases (Table 7.6). In retrospect, we conclude that the
success realized after the second phase was fundamentally dependent on the failure of
efforts to identify an off-the-shelf solution. Specifically, although one might be disap-
pointed with the first phase of the project because no tracking system or measurable
performance improvement tool was implemented to address the department’s opera-
tional issues, exploration of functionality options and research of the vendor market-
place produced the valuable decision that it was worthwhile to develop a custom
solution internally. In fact, it was only with this conclusion from the research that the
second phase of the project was commenced. Although it might seem that the due dili-
gence phase of the build-vs.-buy decision was perhaps excessively extensive in this case,
it appears that such scrutiny and deliberation were required to assure all stakeholders
that investing in the development of another custom application was the best approach.

From a historical perspective, however, it is worth commenting that the “due dili-
gence” phase, phase I, might have been hastened, albeit to the same outcome, if spe-
cific changes had been made to the project’s goals and organizational structure in the
beginning rather than at the conclusion of the first phase. Specifically, the shift in the
team’s goals from phase I to phase II transformed the project from a generic effort to
implement a patient tracking system into a focused initiative to improve the depart-

TABLE 7.5. EDIS project goals and outcomes.
Goals Outcomes

Decrease physician time looking for patients Æ Physicians see room status at a glance on the
and checking status of lab results. whiteboard and can quickly locate patients or

receive alerts that test results are available.

Increase staff knowledge of each patient’s Æ Physicians no longer enter exam rooms, or poll
emergency department (ED) service history. patients in the waiting area, to check if radiology or

other auxiliary services have been performed

Decrease inefficient use of time by nurses. Æ Nurses use computer terminals to update the
information system from workstations throughout
the ED.

Increase staff awareness of patient service Æ Staff can change priorities to focus on patients based
time (how long patients have been at the ED) on eWB’s up-to-the-minute waiting time

Decrease janitorial time spent roaming for Æ Janitors now use the board as a task list.
rooms to clean.

Decrease reception time spent checking Æ Receptionists now admit patients to the ED and
rooms for availability. assign rooms without having to leave their desks to

check the board.

Enable alerts for emergency operational or Æ eWB automatically reports occupancy level,
clinical situations. extended wait times, and uses a color schema to

convey its message.

Make operational statistics available to help Æ The EDIS enables standard and ad hoc reporting for
managers improve performance. management decision making.

LTF7 10/11/2004 8:43 AM Page 78

EBSCOhost – printed on 6/14/2023 6:02 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

7. Developing an Emergency Department Information System 79

ment’s operational performance by applying information technology to support
redesigned processes. Had this focus on outcomes been present in the first phase, less
attention might have been placed on finding a “silver bullet” system solution, and the
team might have realized the opportunity to improve certain processes (e.g., registra-
tion) much sooner.

Also, the second phase of the project benefited significantly from a change in the
project’s leadership structure (Figure 7.2). In the project’s first phase, the organization’s
strategic elite played a key role in developing the ideas behind what a patient track-

TABLE 7.6. Evaluation of key project criteria for phases I and II.
Comparison Phase I Phase II

Needs assessment Needs assessment was based on an Needs assessment was based on an
understanding of operational problems analysis of the tools and processes used
in the department and team member in performing functions in the
evaluation of commercial products. emergency department (ED).

Project leadership The EDIS steering committee led the After the decision to build a system was
project and invited ED and informatics announced, two physicians, one each
staff to participate. from the ED and informatics, under the

sanction of the EDIS steering
committee, stepped up to lead the EDIS
project to completion.

Coalition building The steering committee made efforts to The physician-led eWB development
include people in the process of team rebuilt support in the EDIS project
forming ideas for the system selection through focused attention on process
but alienated people from the process revision, prototypes, and demonstrating
by having endless, fruitless meetings. progress in a timely manner.

Objective and scope The EDIS team had a vision to use Two informatics physicians would lead
definition information technology to help track the EDIS team to replace the

patients through the ED. Exactly what functionality of the ED whiteboard
technology would be used, how it through process analysis and using
would be deployed, and who would be software already in place in the
responsible were questions left for institution. Additional functionality
research and debate. would be added over time.

Schedule planning There was no schedule for delivering a The project leaders planned to
and project revised EDIS. Research and possible implement functionality in order of
organization options were considered for 4 years. importance and ease of implementation

over 18–24 months.

Political sponsorship The EDIS steering committee was The project leaders communicated with
divided over key questions of what ED staff and the steering committee to
could be done and how it would be build consensus and support for the
accomplished. project plan and its implementation.

Project process The process of researching off-the-shelf The software development processes
organization solutions led to unending cycles of followed a rapid application

discovery and evaluation. development (RAD) model.

Obstacle-targeting When proposed solutions were The RAD model supported building
unsatisfactory, more research was functionality incrementally so that issues
conducted. could be resolved quickly.

Institutionalization of No solution was identified or Process revisions were made to
progress implemented. incorporate technology solutions.

Source: Adapted from Hyer N, Wemmerlöv U. A short note on change management: managing the transition
to cells. In Reorganizing the Factory: Competing Through Cellular Manufacturing. Portland, OR: Productivity,
2002. (Reprinted with permission.)

LTF7 10/11/2004 8:43 AM Page 79

EBSCOhost – printed on 6/14/2023 6:02 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

80 Section III. Implementation

ing system might require, and they wisely solicited the feedback of key individuals.
However, during this period, no individual or set of individuals played a role in trans-
lating the vision of the strategic elite into specific tasks for the team to accomplish. In
contrast, during the project’s second phase, the director of the adult ED and the project
leader from informatics together formed the necessary managerial layer with the del-
egated authority to perform key functions like clarifying goals, prioritizing activities,
and managing risks. As a result of their efforts, meetings were efficient, and energy was
focused on the outcomes-oriented activities of process redesign and rapid software pro-
totyping. In retrospect, it appears that the presence of this translation layer was a
primary catalyst for the ultimate completion of the EDIS project. Although we can
only speculate in hindsight, a similar project management model for phase I might have
helped the EDIS team reach the pivotal conclusion to develop a custom solution much
sooner.

Questions

1. What problem is the eWB intended to address?
2. Was the project a success? Why or why not?
3. Initially, the EDIS team chose to focus on selecting a patient tracking system. Later,

the scope of the project was broadened to include a substantial component of
process analysis and redesign.What were the reasons for this change in scope? What
are the implications for the project?

4. The EDIS team used a variety of processes and criteria to prioritize their work, ulti-
mately settling on an eWB as the top initial priority. Critique the prioritization
process and decisions.

FIGURE 7.2. Changing EDIS project organization structure over time.

LTF7 10/11/2004 8:43 AM Page 80

EBSCOhost – printed on 6/14/2023 6:02 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

9
Development of the Scientific
Computing Center at
Vanderbilt University

Lawrence Fu

Background

When Jason Moore1 came to Vanderbilt University in 1999 as a professor in the Depart-
ment of Molecular Physiology and Biophysics, he knew that he needed a parallel
computer (a computer with more than one central processing unit, used for parallel
processing) to conduct his research. His research involved the statistical analysis of
genetics, specifically the study of gene-gene interactions and the implications for
disease risk. The work he wanted to do would require computational power that could
be provided only with high-performance computing (HPC).* The first step he took
toward this goal was to apply to the Vanderbilt University Medical Center for a
Vanderbilt University discovery grant.2 This program was a mechanism to stimulate the
development of new ideas and allow investigators to develop them for future external
federal funding. He received $50,000 to build a parallel computer.

Instead of simply starting work on building a system, he decided to find out if any
other researchers at Vanderbilt were working on developing a parallel computer. After
talking to other researchers from all over the campus, he discovered that Paul Sheldon,3

a professor in the Department of Physics and Astronomy, had done more work than
anyone else in this area. Paul’s area of research was elementary particle physics and
the study of the physics of heavy quarks. He had worked on the development of a
workstation farm called Vanderbilt University physics analysis cluster (VUPAC).4 A
workstation farm is a cluster of workstations loosely coupled to provide a very coarse
parallel computing environment. Initial support for VUPAC was provided by a
National Science Foundation (NSF) academic research infrastructure grant with
matching funds from Vanderbilt University. Additional funding by the NSF and the
Department of Energy later facilitated upgrades, administration, and maintenance.

Jason and Paul decided to work together and develop a shared resource which they
called Vanderbilt multiprocessor integrated research engine (VAMPIRE).5 Paul
remembers: “Jason and I quickly realized that we pretty much wanted to do the same
things. We had similar goals and similar amounts of money to do it. Basically, it was a
meeting of the minds, and we realized [that working together] was the right way to do
it. It was an interesting thing to try.” Additional funding for the project was provided
by a second Vanderbilt University discovery grant and from the startup funds of

92

*This type of computing requires scientific workstations, supercomputer systems, high speed net-
works, a new generation of large-scale parallel systems, and application and systems software with
all components well integrated and linked over a high-speed network.

LTF9 10/11/2004 8:46 AM Page 92

C
o
p
y
r
i
g
h
t

2
0
0
5
.

S
p
r
i
n
g
e
r
.

A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

M
a
y

n
o
t

b
e

r
e
p
r
o
d
u
c
e
d

i
n

a
n
y

f
o
r
m

w
i
t
h
o
u
t

p
e
r
m
i
s
s
i
o
n

f
r
o
m

t
h
e

p
u
b
l
i
s
h
e
r
,

e
x
c
e
p
t

f
a
i
r

u
s
e
s

p
e
r
m
i
t
t
e
d

u
n
d
e
r

U
.
S
.

o
r

a
p
p
l
i
c
a
b
l
e

c
o
p
y
r
i
g
h
t

l
a
w
.

EBSCO Publishing : eBook Collection (EBSCOhost) – printed on 6/14/2023 5:58 PM via WALDEN UNIVERSITY
AN: 145750 ; Nancy M. Lorenzi, Joan S. Ash, Jonathan Einbinder, Wendy McPhee, Laura Einbinder.; Transforming Health Care Through
Information
Account: s6527200.main.eds

another physics investigator. This Vanderbilt University discovery grant came approx-
imately a year after Jason’s initial grant, but this time it came from the university side
rather than the medical center. All together, the group had secured about $150,000 to
accomplish the project.

Developing VAMPIRE

Since the group had limited funds, financial costs played a major role in hardware and
software decisions. All hardware including the central processing units (CPUs), hard
drives, and networking cards were purchased on the Internet for the cheapest prices
possible. From the beginning, they knew that they wanted to use Linux for the oper-
ating system, but deciding on the specific build and distribution took some time and
effort. Information technology services (ITS), the campus agency responsible for over-
seeing the information infrastructure of the university as a whole, provided much
helpful assistance by supplying personnel support for this decision and other technical
details. Another software issue was providing a mechanism to share the resource effec-
tively with many users.Two different packages, MAUI6 and OpenPBS,7 were used. Both
of these are freely available HPC cluster resource management and scheduling systems.
Unfortunately, these options did not provide all the functionality that was needed and
were not significantly supported by their developers. However, the fact that the
software was free outweighed the shortcomings.

While Jason and Paul were the leaders in making these types of decisions, Alan
Tackett8 played a critical role in the technical development of VAMPIRE. Alan’s
research background is computational physics, and he came to Vanderbilt in 1998 as a
postdoctoral research fellow in physics. In 1999, he heard about the VAMPIRE effort
getting under way and became involved. With previous parallel computing experience,
he ultimately took the lead on technical details. He was instrumental in providing tech-
nical expertise and input for key hardware and software decisions. Another contribu-
tion Alan made was leading the outreach efforts to attract new investigators. He
routinely met with research groups, learned about their work, and explained to them
how a parallel computer could aid them in their research.

Finding physical space for the VAMPIRE system was not a difficult task. ITS, besides
providing helpful input, volunteered space in one of its raised-floor air-conditioned
rooms within the Hill Center, where ITS was located. Jason notes that “ITS was instru-
mental throughout the whole process. Having a group on campus that was willing to
support us with space and resources was key. ITS was incredibly helpful. If ITS hadn’t
been involved, space would have been a bigger issue.”

In the spring of 2000, the group, along with the help of graduate students and post-
doctoral research fellows, assembled VAMPIRE. A 2-day pizza party coincided with
the activities. It required about 48 hours for the group to assemble by hand the paral-
lel computer with fifty-five dual-processor nodes. Since that time, VAMPIRE has been
operational 24 hours a day. There have been some hardware failures such as losing a
few CPUs, memory sticks, and hard drives, but these types of issues are expected for a
system of this size.

In the beginning, only a few other investigators were involved. They made contri-
butions to the system in exchange for access to VAMPIRE. One such person was Walter
Chazin,9 professor of biochemistry and director of the center of structural biology.
Another group that was involved early on was the nuclear physics group. The number
of investigators started at five in 2000, grew to ten in 2001, and continued to grow to

9. Development of the Scientific Computing Center at Vanderbilt University 93

LTF9 10/11/2004 8:46 AM Page 93

EBSCOhost – printed on 6/14/2023 5:58 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

sixteen in 2002. The popularity of VAMPIRE grew as others heard about its useful-
ness. There was no formal mechanism for attracting other researchers, but word of
mouth was particularly effective. Initially, Paul and Jason knew of a few people with
whom they wanted to talk, but others simply approached them after hearing about the
effort from others. One person who helped publicize VAMPIRE and brought people
together was Chip Cox, director of the Vanderbilt Internet 2 project. After the initial
setup, additional funding resulted from the participation of new investigators.Two engi-
neering professors contributed a large sum of money. One provided $250,000 as part
of his startup funds, and another $250,000 came from a U.S. Navy grant. At this time,
Ron Schrimpf10 joined the effort and would play a large role in the further maturation
of VAMPIRE into a larger system. Ron, a professor from the Department of Electri-
cal Engineering, contributed a large number of nodes for VAMPIRE through one of
his department’s research programs. His research deals with the interface of physics
and the semiconductor aspects of electrical engineering. He requires the use of heavy-
duty computing for simulations, and his role represents the perspective of a major user
of the system.

Growing VAMPIRE into the Scientific Computing Center

The success of VAMPIRE alleviated many initial concerns about its viability. There
were questions about whether different research cultures would clash, whether they
could all agree on hardware and software decisions, whether it was possible to create
a fair sharing mechanism for all users, and whether there would be synergy among the
users. VAMPIRE proved that all these concerns could be handled. Jason believes that
VAMPIRE was key in making the idea of an even larger computing facility seem fea-
sible:“VAMPIRE was critical because it showed that an interdisciplinary team of inves-
tigators from across the entire university could come together and work on a project.
It brought the School of Medicine, School of Arts and Sciences, and School of
Engineering together on a single project. It got us talking to one another. That in and
of itself is a tremendous achievement for the university. . . . VAMPIRE provided a focal
point for bringing together investigators. It was a successful pilot project that showed
that we could all work together towards a common goal.” Building on the achieve-
ments of VAMPIRE, Paul, Ron, and Jason developed the idea for a scientific comput-
ing center (SCC). It would not merely be a larger system accommodating more users
but would also entail educational outreach efforts to introduce inexperienced users to
the world of HPC.

Paul agrees that VAMPIRE was essential to the development of a more compre-
hensive computing center for the university: “In our minds, we were going to see how
this [VAMPIRE] went. This was a test case to see if we could work together. Always
in the back of my mind, I knew that I was going to need significantly more computing.
There was never any question in my mind that I was going to have to find some way
to get it. Exactly how much wasn’t clear. Once we got things together and working and
moving forward, we realized that we could work together, and it was a great idea. It
always seemed to us that we were going to grow.There was talk very early on of a large
system. It wasn’t the SCC, but there was talk of a large facility. The SCC and its idea
developed and grew over time.”

Another important lesson learned from VAMPIRE was that the education outreach
efforts and attracting new users were possible. Paul emphasized this point: “We real-

94 Section III. Implementation

LTF9 10/11/2004 8:46 AM Page 94

EBSCOhost – printed on 6/14/2023 5:58 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

9. Development of the Scientific Computing Center at Vanderbilt University 95

ized that the whole education outreach efforts and low barriers to participation were
possible. For example, Alan interacted with other research groups on campus, talking
with them, and working with them. He also taught a class11 with Greg Walker12 from
engineering about methods of parallelizing applications. . . . We realized that there was
a lot of interest on campus. There weren’t just going to be a few dedicated computer
nerds using it. There were a lot of people on campus who could benefit from this with
a little bit of help.” Ultimately, the SCC would not merely cater to a few users but would
aim to serve the university community as a whole. In Jason’s words, “We wanted to set
up a center that will span the entire university and reaches out to all people doing com-
putational work in every department. We eventually hope to get people from music,
law, and business using the system.”

Obtaining Funding

Once the concept of the SCC was developed, the next step toward making it a reality
was to secure funding. However, initial attempts to find funding were unsuccessful.Two
requests were made to the NSF through its major research instrumentation13 (MRI)
program. This program aims to increase the scientific and engineering equipment for
research by supporting large-scale instrumentation investments.Awards typically range
between $70,000 and $140,000. Both applications for the SCC asked for $1.5 million
but barely missed approval. In addition, Jason in 2001 submitted an application to the
high-end instrumentation program14 of the National Institutes of Health (NIH). It
received good scores and good reviews, but it did not get approval for the $1.5 million
amount that he requested.

Besides external federal funding, internal funding through the university was possi-
ble. The university’s Academic Venture Capital Fund15 (AVCF) was established to
launch major new transinstitutional initiatives in order to advance Vanderbilt to the
front rank of American research universities. The application process required sub-
mission to at least one of two strategic academic planning groups (SAPGs), which
included one for the medical center and one for the university central. In the event
that a proposal involved both the medical center and the university, simultaneous con-
sideration would be conducted by both SAPGs, and this was the case with the SCC
proposal. If SAPG approval is given, proposals are forwarded to the integrated finan-
cial planning (IFP) council for further consideration, and the final step for approval is
a recommendation to the university chancellor for funding. One of the central require-
ments for a successful proposal was for it to satisfy a set of ten prespecified selection
criteria including the following:

1. The proposed effort is in accord with the Vanderbilt University chancellor’s five
basic goals for academic excellence and strategic growth:
• We must renew our commitment to the undergraduate experience at Vanderbilt.
• We must reinvent graduate education at Vanderbilt.
• We must reintegrate professional education with the intellectual life of the

university.
• We must reexamine and restructure economic models for the university.
• We must renew Vanderbilt’s covenant with the community.

2. The proposed effort will help advance Vanderbilt to the front rank of American
universities. To offer only two examples, this could be accomplished by bringing

LTF9 10/11/2004 8:46 AM Page 95

EBSCOhost – printed on 6/14/2023 5:58 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

96 Section III. Implementation

together existing institutional strengths in a new and distinctive way, or by pro-
posing a creative way to strengthen a critical area that limits Vanderbilt’s ability to
move forward.

3. The proposed effort enhances the learning environment and opportunities
for undergraduate, professional, and graduate students and recognizes the need
to recruit and retain an intellectually, racially, and culturally diverse campus
community.

4. The proposed effort will require a significant investment in graduate education,
and, if successful, will improve the national ranking of one or more graduate
programs.

5. The proposed effort involves a broad range of faculty rather than a few individu-
als and will foster greater collaboration among the schools.

6. The proposed effort will strengthen disciplinary integrity and expand the interdis-
ciplinary range of departments.

7. The faculty leadership is already in place.
8. The proposed investment will strengthen the core disciplines.
9. The proposed effort is bold, requiring significant intellectual and financial invest-

ment, with anticipated gains commensurate with the magnitude of the investment.
10. The proposed effort shows clear promise for generating the funding needed to

sustain itself after the initial period of AVCF support (of no more than 5 years).

In 2002, the first proposal was submitted to the AVCF but did not receive approval.
It was an administration-driven effort led by the director of ITS at the time. Then in
mid-2003, a second proposal spearheaded by Jason, Paul, and Ron was submitted to
the AVCF and received approximately $8.2 million in funding for the SCC. One impor-
tant distinction to note between the different sources of funding is that federal funding
would have provided means solely for building the computer. It would not have
covered any other aspects of the SCC. On the other hand, the internal AVCF funding
provided capital for data storage, data archiving, data visualization, and personnel
related to outreach and support efforts.

Details About the SCC

The approved AVCF proposal explicitly laid out the administrative and organizational
structure for the SCC. Jason, Paul, and Ron were the principal investigators and make
up the steering committee, while Alan served as project administrator. The steering
committee is responsible for all major decisions but will seek input from other com-
mittees. There are four other committees:

1. The investigators committee consists of all faculty members who are using or will
be using the system. It currently contains approximately fifty investigators from the
university. This internal advisory committee is chaired by Walter Chazin, Peter
Cummings16 (chemical engineering), Mark Magnuson17 (molecular physiology and
biophysics, assistant vice chancellor for research), and Nancy Lorenzi18 (biomedical
informatics, assistant vice chancellor for health affairs), and it will provide a diverse
array of opinions.

2. The external advisory committee consists of three or four individuals from outside
Vanderbilt in order to provide an objective perspective.

3. The technical advisory committee, chaired by Jarrod Smith19 from the Depart-
ment of Biochemistry, will make hardware and software recommendations.

LTF9 10/11/2004 8:46 AM Page 96

EBSCOhost – printed on 6/14/2023 5:58 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

4. The users committee will communicate the needs of the daily users such as grad-
uate students. It is chaired by Greg Walker, a professor from the Department of
Mechanical Engineering.

There is an organized reporting structure in place to facilitate communication between
committees. Alan, the project administrator, submits quarterly reports to the steering
committee. The technical advisory committee provides an evaluation of current oper-
ations as well as recommendations for future infrastructure through quarterly reports
to the steering committee. The external advisory committee provides biannual reviews
to the steering and investigators committee. The steering committee submits annual
reports to the investigators committee for approval, and it also provides the annual
report to Dennis Hall,20 associate provost for research, and Lee Limbird,21 associate
vice chancellor for research.

Within the proposal, three types of targeted users are enumerated:

1. Experienced investigators who use parallel computing regularly will be able to
immediately take advantage of the center.

2. Users who regularly do computing may have never had the resources to do paral-
lel computing. These users know about parallel computing but never have had the
opportunity to take advantage of it.

3. People who do not know about parallel computing and are not aware that it can
help them in their research are still able to use the resources.

In order to aid the second and third types of users, the SCC will employ an education
and outreach staff. Informational and tutorial sessions will provide assistance to
researchers on how to take advantage of HPC. In Ron’s opinion,“the educational activ-
ities in a way are more important [than the computer]. We’re going to have hardware,
and we need hardware. If it sits there by itself without anyone helping new people use
it, it’s not going to have a big impact on the culture of the campus. What will really be
transformative about the center is the other side of it [education outreach], which will
help people get involved.” In addition to the outreach staff, there will also be an oper-
ations staff, which will maintain the hardware and software resources, and a scientific
staff, which will include visiting scholars and center fellows.

By identifying the three types of potential users, the SCC emphasizes catering to the
needs of researchers. One of the core philosophies of the center is that it is an inves-
tigator-driven resource. Jason believes that this idea is central to the ultimate success
of the SCC: “From the start, this has been a grassroots effort. This has been an inves-
tigator initiated project. We said we needed this resource, and we’re going to put
together the funds to get it started. This was our project. We started it, we organized
it, we put it together, and we made it work. Our philosophy is that nobody knows better
what we need for our research than us. It’s going to be a center run by the investiga-
tors for the investigators.” Paul echoes this sentiment: “I don’t think it makes sense any
other way. Investigators are the ones with the stake in it and motivation to make it
work. . . . I think the day it stops being that is the day it starts falling apart.”

In order to allow simultaneous use by many people, the SCC follows a relatively
straightforward sharing mechanism. Investigators gain access by contributing
resources, such as CPUs, to the center.The use of these resources is guaranteed to them
whenever they want them. However, people do not use their resources all the time.
Consequently, the pool of excess resources can be split among all other users. So far,
this arrangement has worked smoothly. The beauty of this simple agreement can be

9. Development of the Scientific Computing Center at Vanderbilt University 97

LTF9 10/11/2004 8:46 AM Page 97

EBSCOhost – printed on 6/14/2023 5:58 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

summarized in Paul’s words, “You can buy thirty machines and get access to a
thousand machines.”

Current State

At this point, the SCC has not yet grown to its full size. It currently contains 400 proces-
sors and ranks as number 199 among the top national HPC clusters.22 Eventually, the
SCC will possess 2,000 processors or 1,000 dual-processor nodes. The first major hard-
ware purchases will occur in January or early 2004, and there is a rolling schedule for
hardware purchases. Each year, one third of the processors will be added, so the system
will not reach full capacity for 3 years. Afterward, the oldest third of the nodes will be
replaced each year because the processors typically have a 3-year life cycle before
becoming obsolete. While VAMPIRE originally consisted of commodity-priced parts
assembled by the group, the SCC will purchase hardware from a third-party vendor
who will assemble and test the system.

Besides the processors, supporting infrastructure was another consideration of the
proposed budget. The groundwork has been laid for a large tape archive facility with
a $75,000 tape library purchase. A disk storage system has been chosen that can suffi-
ciently handle the large amounts of data that will be generated. It will be flexible
enough to handle growing user needs. Furthermore, the budget allocated funds for spe-
cialized visualization hardware that will enable real-time analysis of large, complex data
sets with immersive display technologies.

The SCC’s budget calls for an initial large investment in equipment. In subsequent
years, the funds will shift a greater percentage to personnel and will reach a steady
state of personnel and equipment costs. After 5 years, the center hopes to be able to
sustain itself financially because the AVCF provides funding for a maximum of 5 years.
To reach this end, the steering committee plans to hire a financial director in the begin-
ning of 2004. The director’s responsibilities will include overseeing the finances as well
as driving the outreach efforts. The ideal candidate will have management, financial,
and accounting experience. In Jason’s opinion, the financial independence of the SCC
will be the biggest challenge to the center. He realizes that this will require much effort
but is optimistic: “I think it will work since there are so many people at the university
who will use the center. There will be a lot of funding coming into the center, and we
should be able to recover most of the costs to keep it going.”

Another major consideration for the future is how to accommodate the needs of so
many users. When VAMPIRE was in its beginning stages, involving only a few inves-
tigators, Paul recalls that the small group had good communication and a loose orga-
nization. They saw eye to eye on most issues. However, as the SCC grows larger,
decisions become more complicated: “When everything was small and friendly, it was
easy. Now, it has to be big and professional. We have to work for a lot of people. In
some cases, we have competing needs and issues. What do we do first [in ramping up
the system]? What do we emphasize? Should we spend the personnel and resources
this way or another way?” One current example of varying needs of users is the fol-
lowing: One individual requires each CPU that he utilizes to have 4 gigabytes of
random access memory (RAM) instead of the customary 1 gigabyte. According to
Jason, the steering committee, with input from the technical advisory committee, must
answer such questions as, “Do we want to have every node have 4 gigabytes? Is it cost-
effective to do that? If it’s too expensive, can we have 10 percent of the nodes have 4

98 Section III. Implementation

LTF9 10/11/2004 8:46 AM Page 98

EBSCOhost – printed on 6/14/2023 5:58 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

gigabytes? How feasible is it to have one part of the system have an increased amount
of RAM?”

So far, the SCC has been able to bring together a diverse community. An increased
rate of scientific discovery by university researchers should be possible because previ-
ously prohibitive computational work is now possible. Other anticipated benefits
include enhancing education for students, and the center can serve as a recruitment
tool for new faculty. Those who played a major role in its development undoubtedly
have learned many lessons along the way. Paul admits that “there a lot of little things
that I would have liked to have done differently. I wish I’d understood better that tape
systems are such a headache, but it wouldn’t have mattered since there would have
been other technical issues. I wish that we had all understood better how best to get
this project going. . . . This was the first time I ever took on a project of this magnitude.
You learn things about management along the way . . . how to handle the people
involved in the project and the people who will benefit from the project.”

However, future unanticipated obstacles may arise because the SCC is still matur-
ing and has yet to achieve its envisioned size. The steering committee is well aware of
the fact that what works on a 55-node cluster will not necessarily work on a 1,000-node
cluster. Paul notes that “If you have 100 different groups, each may be able to con-
tribute in only a special way since NSF [or whichever funding agency] says that they
can only spend the money a certain way. We have this infrastructure we have to pay
for, and we have to somehow find a way to allocate it back to the users. We’ve been
successful so far, and everybody’s been happy.”

Questions

1. The initial phases of development with VAMPIRE went relatively smoothly. What
factors contributed to this success?

2. What were key factors in making an interdisciplinary project of this size work?
3. Were there any decisions that you would have made differently?
4. Are there any potential issues you believe that the steering committee may not have

considered?
5. If another university were planning to set up a similar computing center, what are

the most important lessons that they should learn from the Vanderbilt University
example?

References
1. http://phg.mc.vanderbilt.edu/jason.shtml.
2. http://medschool.mc.vanderbilt.edu/oor/pd/index.php?PD=4.
3. http://www.hep.vanderbilt.edu/~sheldon/.
4. http://www.vupac.vanderbilt.edu/.
5. http://vampire.vanderbilt.edu/.
6. http://mauischeduler.sourceforge.net/.
7. http://www.supercluster.org/projects/pbs/.
8. http://vampire.vanderbilt.edu/staff.php#tacketar.
9. http://structbio.vanderbilt.edu/chazin/.

10. http://www.vuse.vanderbilt.edu/~schrimpf/persinfo.html.
11. http://tplab.vuse.vanderbilt.edu/~walkerdg/hpc.html.
12. http://frontweb.vuse.vanderbilt.edu/vuse_web/directory/facultybio.asp?FacultyID=341.

9. Development of the Scientific Computing Center at Vanderbilt University 99

LTF9 10/11/2004 8:46 AM Page 99

EBSCOhost – printed on 6/14/2023 5:58 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

13. http://www.eng.nsf.gov/mri/.
14. http://grants1.nih.gov/grants/guide/rfa-files/RFA-RR-03-009.html.
15. http://medschool.mc.vanderbilt.edu/oor/pd/doc/AVCF_Guidelines_2002_03.doc.
16. http://www.vuse.vanderbilt.edu/~cheinfo/cummings1.htm.
17. http://www.mc.vanderbilt.edu/vumcdept/mpb/magnuson/.
18. http://www.mc.vanderbilt.edu/dbmi/people/faculty/lorenzi_nancy/index.html.
19. http://structbio.vanderbilt.edu/~jsmith/home.html.
20. http://www.physics.vanderbilt.edu/cv/dghall.html.
21. http://medschool.mc.vanderbilt.edu/limbirdlab/.
22. http://www.top500.org/.

100 Section III. Implementation

LTF9 10/11/2004 8:46 AM Page 100

EBSCOhost – printed on 6/14/2023 5:58 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

11
Implementation of a Web-Based
Incident-Reporting System at
Legendary Health System

Sylvia Bae, Samone Khouangsathiene, Christopher Morey,
Chris O’Connor, Eric Rose, and Abdus Shakil

Incident Reporting

Research results demonstrating that medical errors occur frequently and can be asso-
ciated with serious adverse outcomes have spurred interest in preventing them.1,2 It has
been argued that by studying how medical errors occur, medical institutions can iden-
tify breakdowns in system processes that cause them to happen. The knowledge
obtained can then be used to modify medical practices and work flows to reduce the
risk of error recurrence.3

Incident reporting (IR) is a process by which personnel submit a structured report
of any action that caused or might have caused an adverse outcome. Examples of inci-
dents that should be reported include a patient falling out of bed, a malfunctioning
piece of medical equipment, and administration of an incorrect type or dose of med-
ication. This approach to identifying and studying errors originated outside medicine
but has now been used in medicine for several decades.4 The most frequently cited
argument for IR is that the study of “near miss” events identifies factors that might,
under other circumstances, lead to an adverse event. In addition, IR serves to alert
administrators to problematic managerial situations and problem personnel and
creates a detailed documentation of events surrounding an error. It is common for
medical institutions to perform statistical analyses of IR data over time to detect poten-
tial problems in specific departments or care processes.5

Partial computerization of the IR process in medicine occurred decades ago, typi-
cally with the completion of initial reports on paper by those involved in the incident
and subsequent data entry into computerized systems by clerical staff.6 More recently,
IR systems have been developed in which the entire process is computerized: IR by
the personnel involved, communication of the report to the appropriate administra-
tors, and a response-planning process and subsequent aggregate data analysis.5,7,8

Computerized incident-reporting systems (CIRS), it has been argued, can make the
IR process more efficient and enhance compliance with reporting policies. In addition,
it increases the flexibility of the process (for instance, the set of collected data elements
can be modified without distributing new paper forms).8 In addition, collecting discrete
data (e.g., requiring users to choose the type of incident from a fixed list rather than
writing in free text on a paper form) can facilitate aggregation of the results. Further-
more, computerized IR allows automated transmission of the report and associated
documentation and commentary to the appropriate recipients.5 To date, however, there
is little published data on whether CIRS achieve their intended goals any better than

114

LTF11 10/11/2004 8:49 AM Page 114

C
o
p
y
r
i
g
h
t

2
0
0
5
.

S
p
r
i
n
g
e
r
.

A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

M
a
y

n
o
t

b
e

r
e
p
r
o
d
u
c
e
d

i
n

a
n
y

f
o
r
m

w
i
t
h
o
u
t

p
e
r
m
i
s
s
i
o
n

f
r
o
m

t
h
e

p
u
b
l
i
s
h
e
r
,

e
x
c
e
p
t

f
a
i
r

u
s
e
s

p
e
r
m
i
t
t
e
d

u
n
d
e
r

U
.
S
.

o
r

a
p
p
l
i
c
a
b
l
e

c
o
p
y
r
i
g
h
t

l
a
w
.

EBSCO Publishing : eBook Collection (EBSCOhost) – printed on 6/14/2023 6:04 PM via WALDEN UNIVERSITY
AN: 145750 ; Nancy M. Lorenzi, Joan S. Ash, Jonathan Einbinder, Wendy McPhee, Laura Einbinder.; Transforming Health Care Through
Information
Account: s6527200.main.eds

11. Implementation of a Web-Based IR System at LHS 115

paper-based IR systems and how their implementation affects the organizational
dynamics of a medical institution.

Background

Legendary Health System (LHS) is a nonprofit healthcare organization based in Michi-
gan. It is one of the largest healthcare systems in the state. LHS provides an integrated
network of healthcare services, including acute and critical care, inpatient and outpa-
tient treatment, community health education, and a variety of specialty services. It also
offers continuing medical education and graduate medical education programs.

LHS was formed in 1989 by the merger of St. Joseph’s Hospital and Medical Center
and the Ann Arbor Community Health Plan, a community-based health services orga-
nization. LHS includes five hospitals and a number of primary care clinics, as well as a
clinical laboratory and research facilities. LHS’s stated mission is to enhance the quality
of life by improving the health of the communities it serves by providing and manag-
ing comprehensive, accessible and integrated healthcare services that emphasize clini-
cal excellence, value, and human sensitivity.

LHS is governed by a board of directors and managed by the president and chief
executive officer (CEO). There are five main divisions, each headed by a senior vice
president. These divisions are clinical operations, legal services, financial, information
systems, and medical. Each senior vice president reports directly to the president and
CEO, except in two cases where the division heads report to two different people in
different departments. The chief of medical informatics reports to both the chief infor-
mation officer (CIO) and the chief medical officer (CMO).

LHS’s Quality Management Programs

LHS has a continuous quality improvement (CQI) program in place for managing the
quality of its operations. The CQI program was implemented in 1991 and is founded
on four values: (1) satisfying customers, (2) leading and empowering people, (3) pre-
venting errors, and (4) managing with data. The CQI philosophy focuses on treating
errors as systemic issues rather than assigning blame to individuals. It is recognized that
errors are complex and unavoidable, but that their frequency can be reduced. This is
done by first examining the situation and defining the problem. Next, effective solu-
tions are developed. A plan is then deployed to correct the problem. Finally, the result
is evaluated and, if need be, the steps are followed through again.

IR has been integral to the LHS’ CQI approach to error prevention. Prior to 2001,
the LHS error-reporting system consisted of structured reports completed on paper
forms that were scanned into the hospital computer system. This system did not allow
managers to have immediate access to reports concerning adverse events. Reporting
was also limited and difficult to track. In addition, there was no established mechanism
for collecting quality improvement suggestions.

In 2002, LHS began using a Web-based IR system. The stated purpose of this project
was to improve the safety of the work environment and medical care processes at LHS
by using “root cause” analysis to rapidly identify and correct systemic problems that
might otherwise result in adverse events. The application was chosen by a multidisci-
plinary group, which considered a total of five vendor systems. The vendor system
selected had the following positive attributes:

LTF11 10/11/2004 8:49 AM Page 115

EBSCOhost – printed on 6/14/2023 6:04 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

116 Section III. Implementation

• Web-based, allowing access from any computer on the LHS network running a com-
patible Web browser client

• Robust security architecture
• Support for aggregate reporting to track trends in IR data
• Automatic routing of incident reports to appropriate personnel, including managers

of relevant departments.

After a 90-day pilot, a phased rollout of the CIRS began—intended to entirely replace
the old paper-based IR system at LHS.

The CIRS Implementation

All healthcare employees required to complete internal reports were expected to use
the CIRS. Users underwent a 45-minute training session conducted by the quality man-
agement department staff; managers received additional training. User-specific log-ons
were used, precluding anonymous reporting.

The LHS administration expected that adoption of the CIRS would improve
employee attitudes toward IR and foster a culture that would embrace the CQI
approach to error prevention because of the following assumptions:

• Increased ease of data entry compared with paper internal report forms
• Increased speed of resolution of issues raised in internal reports
• Increased feedback to employees regarding process changes made in response to

internal reports.

However, the CIRS generated mixed reactions among LHS employees, with clinical
personnel decidedly less enthusiastic than administrative personnel.

CIRS Implementation Challenges

Leah Overhill is the director for quality leadership; her responsibilities include quality
data management, managing the quality improvement specialists, and infection control.
Her prior outstanding performance in a lower-level role in infection control led to an
expanded role in quality control. She has had little previous experience in quality
control or information technologies, yet she was charged with spearheading the CIRS
selection and implementation process.

A year after the launch of the CIRS, Overhill is pleased with the CIRS implemen-
tation, as are her colleagues in the quality management department. They have an
easier time making statistical analyses of error reporting, and they can actually track
errors to find the causes. They recognize some shortcomings in the implementation,
however.The demands for user support are greater than anticipated and have exceeded
the technical support resources allotted, resulting in users having difficulty getting help
in using the software. In addition, the IR process, just as before the CIRS implemen-
tation, still does not include any formal assignment of responsibility for handling resolv-
ing issues raised in incident reports. This is unchanged from the situation prior to
installation of the CIRS.

In addition, Overhill has become aware of growing user dissatisfaction with the
CIRS. Many feel it is more time-consuming than the old paper-based IR process,
though this complaint seems to decrease with duration of use of the system. In partic-

LTF11 10/11/2004 8:49 AM Page 116

EBSCOhost – printed on 6/14/2023 6:04 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

ular, older employees with little computer experience have found the CIRS difficult to
use. The system is not installed on the same computer workstations as other clinical
applications, so there are separate workstations for it. Many employees complain that
they are too few in number and that it is inconvenient to find one when needed. In
addition, many employees complain that they see no end result from the IR process
and doubt that incident reports have any real impact on the issues identified in the
reports.

In retrospect, Overhill has realized that the product selection and implementation
planning processes did not involve the end users of the system. In addition, she regrets
not having taken a proactive approach to soliciting user feedback once implementa-
tion started since she learned of user dissatisfaction only “through the grapevine,” long
after it began. What options does she have to address the less than ideal implementa-
tion of the CIRS?

Analysis

Overhill’s Options
1. Abort the CIRS project and return to paper-based incident reports.

Pros: This would have the advantage of “cutting the losses,” minimizing the loss
of tangible and intangible resources should the project be destined to fail. It also
might temporarily improve the reputation of the quality management department
with clinical staff.

Cons: This might be perceived as a personal failure of Overhill and affect her
chances for professional development. The benefits derived from the CIRS would
be abandoned.

2. Choose another CIRS.
Pros: To the degree that some of the difficulties encountered might be specific

to the CIRS application (the need for user support and cumbersome data entry
procedures), this might alleviate the problem. In addition, a “fresh start” might
provide at least a temporary change in attitude among the employees.

Cons: The employees and the administration might perceive this option as reflect-
ing disorganization on the part of Overhill and her department. Implementing
another CIRS does not fundamentally address the employees’ discomfort
with change and the employees’ perception of how management uses IR data.
Implementing a different system might be met with the same outcome.

3. Adopt an approach of “benign neglect,” continuing the implementation as
scheduled without any new or modified tactics to ensure its success.

Pros: This might be a politically expedient approach. If the employees adapt to
the system, Overhill will have achieved her goals without an additional expenditure
of resources. If they do not, it is possible, given the size of the organization and the
communication gaps between upper-level administrators and rank-and-file employ-
ees, that Overhill could still present it to her superiors as a success. Cut off from the
lower-level employees, it is unlikely that senior management would ever become
aware of the problems surrounding its implementation.

Cons: If Overhill is truly motivated to contribute to the mission of her organiza-
tion, this approach will likely be ethically problematic for her. In addition, she takes
on the risk of encouraging employees to reduce IR efforts—leaving her with no
source of data from which to report.

11. Implementation of a Web-Based IR System at LHS 117

LTF11 10/11/2004 8:49 AM Page 117

EBSCOhost – printed on 6/14/2023 6:04 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

4. Try to salvage the CIRS project as follows.
Directly address the problem of accountability. Currently, no one is specifically

charged with the responsibility for facilitating process improvement. Overhill should
implement an accountability structure with guidance and input from her senior col-
leagues and at least some of the managers. Options for this include:
• A stable IR resolution team that would include managers (and possibly others)

from different departments, who would have dedicated time to perform this task,
in collaboration with employees and managers in the departments where any par-
ticular CIR originated.

• A system for assembling a temporary, self-organizing, multidisciplinary team for
each computerized incident report submitted, which would be responsible for
addressing issues raised in the incident report. These teams might be constituted
according to a fixed “recipe,” e.g., the individual who filed the report, the manager
from the corresponding department, and a dedicated employee from the quality
management department, which could potentially be Overhill.

There should be a formalized process of feedback whenever an error is reported.
When employees see that error reporting does make a difference, maybe they will
be more likely to report incidents. Fortunately, CIRS software provides the ability
to support many communication requirements.
• There have been several significant successes with the CIRS already. For instance,

the system facilitated a solution to a long-standing problem that the paper-based
system never caught. These successes need to be communicated, loudly and
repeatedly, to the entire LHS community so that the potential value of the system
is understood.

• Increased resources for training and user support, especially for employees who
are uncomfortable with computer technology in general. It might be possible to
achieve this without additional expense by recruiting some employees who are
more facile with the system to champion it and support other employees who are
having difficulty.

Overhill should explore the options of adding more workstations or making it pos-
sible to run the CIRS software on all the LHS computers. Easier access would
encourage more employees to use it.
• Develop ways to reward reporting without rewarding the incidents that lead to

reporting. This would be challenging but might be structured as a reward to IR
report filers for suggesting solutions to systemic problems should the suggestion
be adopted. Another option is to focus the reward at the unit level to foster an
atmosphere of cooperation among unit members. This will improve morale and
enable the teamwork necessary to correct errors due to complex issues of work
flow.

• The CQI approach toward IR, with its nonblaming, nonpunitive approach, should
be communicated more effectively to the employees to reduce fears that individ-
uals might be targeted for mistakes made. This could be achieved in multiple
ways—through newsletters, posters in employee break rooms, and meetings with
employees.
Pros: This approach would result in an effective, usable CIRS if successful. It

builds on the financial and human resources that have already been invested in the
CIRS project. In addition, it would be counterproductive to waste the institutional
momentum that has been generated to initiate this implementation. None of the dif-
ficulties with the CIRS project are insurmountable. If Overhill is able to make the
project a resounding success, with enthusiastic adoption by the employees, it will be

118 Section III. Implementation

LTF11 10/11/2004 8:49 AM Page 118

EBSCOhost – printed on 6/14/2023 6:04 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

much more likely to advance her career than a begrudging, dissatisfied acceptance
of the system.

Cons: The steps detailed above will increase the visibility of the CIRS project to
both administration and employees. Should the project fail despite her efforts, Over-
hill’s career could suffer a severe setback.

Overhill will be addressing some of the basic difficulties with IR in general (like lack
of feedback to originators of incident reports). Thus, she will not merely be salvaging
a troubled information technology implementation but will also be furthering the
quality improvement goals of her department and the overall mission of her organi-
zation. The current difficulties with the CIRS represent both a risk and an opportunity
for Overhill. The current situation, if managed poorly, could lead to cost overruns,
demoralized staff, and a system failure. Managed well, a new CIRS could be used to
significantly improve care at LHS, and that is the best possible outcome for Overhill.

Questions

1. What is the stated purpose of the IR system?
2. What does the LHS adminstration expect that adoption of the IR system will

achieve?
3. What do you think the definition of success should be for this IR project?
4. Who are the intended users of the IR system?
5. What do clinicians think of the IR system?
6. Overhill heads the CIRS selection and implementation. What are her strengths and

weaknesses in this role?
7. What are the attributes of IR that are different from clinical IS used for direct

patient care? What are the implications of these differences with regard to how
implementation should take place?

8. What would you do in Overhill’s position?

References
1. Leape LL, Brennan TA, Laird N, Lawthers AG, Localio AR, Barnes BA, Hebert L, Newhouse

JP, Weiler PC, Hiatt H. The nature of adverse events in hospitalized patients. Results of the
Harvard Medical Practice Study II. New England Journal of Medicine 1991;324(6):377–384.

2. Kohn LT, Corrigan JM, Donaldson MS. To Err Is Human: Building a Safer Health Care System.
Washington, DC: National Academy Press, 2000.

3. Battles JB, Kaplan HS, Van der Schaaf TW, Shea CE. The attributes of medical event-
reporting systems: experience with a prototype medical event-reporting system for transfusion
medicine. Archives of Pathology & Laboratory Medicine 1998;122(3):231–238.

4. Braff J, Way BB, Steadman HJ. Incident reporting: evaluation of New York’s pilot incident
logging system. QRB Quality Review Bulletin 1986;12(3):90–98.

5. Maass G, Cortezzo M. Computerizing incident reporting at a community hospital. Joint Com-
mission Journal on Quality Improvement 2000;26(6):361–373.

6. Pena JJ, Schmelter WR, Ramseur JE. Computerized incident reporting and risk management.
Hospital & Health Services Administration 1981;26(5):7–11.

7. Wu AW, Pronovost P, Morlock L. ICU incident reporting systems. Journal of Critical Care
2002;17(2):86–94.

8. Kobus DA, Amundson D, Moses JD, Rascona D, Gubler KD. A computerized medical incident
reporting system for errors in the intensive care unit: initial evaluation of interrater agreement.
Military Medicine 2001;166(4):350–353.

11. Implementation of a Web-Based IR System at LHS 119

LTF11 10/11/2004 8:49 AM Page 119

EBSCOhost – printed on 6/14/2023 6:04 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use

Appendix 11.1: Survey Questions

1. How often do you use CIRS per shift? When are your shifts (day, swing, night,
weekends, etc.)?

2. Is the current system better than the old one and if so, in what ways?
3. What was the training like? Was it adequate? Is the system easy and convenient to

use? Are you comfortable using it?
4. Does the system interrupt your work flow? If so, how much and in what ways?
5. Do you see an improvement in quality due to the current system?
6. Do you receive feedback concerning quality outcomes you were involved in? If so,

when, how much, and what kind?

120 Section III. Implementation

LTF11 10/11/2004 8:49 AM Page 120

EBSCOhost – printed on 6/14/2023 6:04 PM via WALDEN UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use