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
• 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
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
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
