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

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 66

66 Section III. Implementation

• 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.
LTF6 10/11/2004 8:42 AM Page 67

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 68

68 Section III. Implementation

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?