Evaluation Plan Project: a Case Study and Model

Case studies are valuable tools in academics as well as in professional practice. Case studies illuminate how products or services can be applied, or how innovation or disruption can be managed. Case studies enable learners and practitioners to apply critical thinking while finding ways to develop solutions to problems.

Much like travelers might apply the lessons learned from previous visitors to their own plans to visit destinations, case studies can help researchers and practitioners to develop plans, either by applying lessons learned from past shared experiences or by practicing analysis skills necessary to develop effective plans. Similarly, case studies can help those developing health information technology (HIT) evaluation plans by guiding their application of a specific evaluation model to their own plans.

Using the Triangle Model – the health informatics evaluation model and one of the case studies (from chapters 6 to 12 – attached) compare this to other potentially applicable models like the sociotechnical model, the Participatory Model for Multi-Document Health Information Summarization, and the Software Quality Evaluation Models.

Select a case from chapters 6 through 12 of the Lorenzi text that will serve as the basis for your evaluation plan.

To maximize your benefit from this project, consider selecting a case study that is relevant to a healthcare organization with which you are involved.
Review the research models covered in the Week 2 Learning Resources.
Consider the key points of each and when they would be the most appropriate choice for an evaluation of your selected case.

In a 3- to 4-page, address the following:

Provide a brief, 1- to 2-paragraph summary of your selected case.
Describe the model selected for your evaluation of the case study you selected.
Justify your choice by comparing your selected model to at least three of the other models presented in this week’s reading.

References

Lorenzi, N. M., Ash, J., Einbinder, J., McPhee, W., & Einbinder, L. (Eds.). (2005). Transforming health care through information (2nd ed.). Springer.

Chapter 6, “Bar Coding: It’s Hard to Kill a Hippo” (pp. 65–68)
Chapter 7, “Developing an Emergency Department Information System” (pp. 69–79)
Chapter 8, “Implementation of OpChart in West Medical Building” (pp. 81–91)
Chapter 9, “Development of the Scientific Computing Center at Vanderbilt University” (pp. 92–100)
Chapter 10, “Early Implementation Problems of an Integrated Information Systems Within the White Mountain University Health System” (pp. 101–113)
Chapter 11, “Implementation of a Web-Based Incident-Reporting System at Legendary Health System” (pp. 114–120)
Chapter 12, “Managing Change: Analysis of a Hypothetical Case” (pp. 121–135)

McGonigle, D., & Mastrian, K. G. (2018). Nursing informatics and the foundation of knowledge (4th ed.). Jones and Bartlett Learning.

Tilley, S. (2020). Systems analysis and design (12th ed.). Cengage.

Please feel free to add other peer-reviewed resources in-text citation in this assignment.

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

Margaret Keller, Beverly Oneida, and Gale McCarty

Having Trouble Meeting Your Deadline?

Get your assignment on Evaluation Plan Project: a Case Study and Model completed on time. avoid delay and – ORDER NOW

Get a 20% Discount

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

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

EBSCO Publishing : eBook Collection (EBSCOhost) – printed on 3/9/2022 6:29 AM via WALDEN UNIVERSITY AN: 145750 ; Nancy M. Lorenzi, Joan S. Ash, Jonathan Einbinder, Wendy McPhee, Laura Einbinder.; Transforming Health Care Through Information Account: s6527200

• 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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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 h

ase I P

h ase 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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

EBSCO Publishing : eBook Collection (EBSCOhost) – printed on 3/9/2022 5:28 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

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

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

* 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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

However, in stage 4, which has a centralized organizational structure, the objective is for the organization to move to an integration of systems. An IIS fits this organiza- tional structure best. The conflict present at WMUH stems from individual departments continuing to seek the best IS for their needs without regard for the institutional infor- mational needs.

4. Communicating the Plan

The opinion leaders may support the system, but they are not adequately communi- cating and marketing this support to other staff members. The best way to deal with the time concerns is by communicating the reasons behind the implementation time- line. Items to consider for improved communication include the following:

a. Inform end users about system expectations. b. Include end users in communications and decisions regarding changes. c. The end user must be committed to the success of the system. d. The leaders must support the system and push or pull through various times of

success or failure. e. End users must “see and know” results rapidly.

The scheduled phase planned for implementing the clinical phase of the project is a difficult situation for WMUH. The leadership could begin with the end users and change processes so that when the information system is introduced, it is an easy tran- sition. Time could be used as a benefit instead of being viewed as a risk. The opportu- nity to communicate and inform the users, coupled with seeking their input, could help eliminate the fears end users may have about the system.

5. Change Management Plan—Physicians Continue to Feel Left Out of the Loop

Lorenzi and Riley4 describe a five-stage model for change management that serves as a foundation for organizational development.

a. Assessment b. Feedback and options c. Strategy development d. Implementation e. Reassessment.

The assessment phase is represented by an informational component that informs the organization of the proposed change (process). Also included in this phase is a com- ponent of information gathering whereby user perceptions, concerns, and suggestions are collected. The feedback and options phase represents the analysis of collected data with the presentation of data to the organization’s decision-making (administration/ board of directors) level. Implicit in this phase is the ability of the organization to learn (and therefore change) from the information collected. The strategic development phase represents the level of effecting processes. The implementation phase refers to actual implementation of the process, and the reassessment phase allows for postim- plementation assessment and feedback.

Other factors to be considered by an organization include:

a. Determining the level and type of change to be considered. b. Defining the organization’s structure and its impact on the process. c. Defining and understanding the organization’s cultural and political philosophy.

110 Section III. Implementation

LTF10 10/11/2004 8:47 AM Page 110

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

EBSCO Publishing : eBook Collection (EBSCOhost) – printed on 3/9/2022 5:37 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

d. Identifying the participants in the change process i. Those making change decisions (administrators)

ii. Those facilitating the change process (managers) iii. Those affected by the change (workers, users, and customers)

e. Identifying promotion and resistance factors.

The application of change management at the WMUHS appears fragmented and poorly organized. Although the WMUHS attempted to put the informational compo- nent of Lorenzi and Riley’s assessment phase into action, the process does not appear to have functioned well. Though not expressed, communication of the IIS project and phased implementation were carried out over a reasonable period of time and by various methods (media). Despite this, physicians continue to feel “left out of the loop.” This response highlights the lack of an “information gathering” component in the assessment phase. If WMUHS utilized a formal method of gathering user data (infor- mation regarding perceptions, concerns, suggestions, etc.) and subsequently employed a system of analyzing and presenting this information to the decision-making level of the organization, it would appreciate less resistance to the current system. One can argue that this process is in fact in place. Even so, the components of assessment and feedback require an organization that is able to learn. Given this background infor- mation, WMUHS appears to be a complex, moderately conservative organization with a political/administrative composition and an organizational history that do not express this ability to learn (change). Unfortunately this lack of ability also appears to perme- ate the institution beyond the administrative levels, as noted by physician comments. It appears that even Dr. Weber is unable to learn (understand) the need for infra- structure development as a prerequisite for full integration. The implementation and reassessment phases of the model are relatively unimportant in this case because of the obvious absence of the prior phases.

Part III

Solutions? The problems we have identified—defining vision, weaving together individual cul- tures, aligning the incentives for centralization, and developing a change management plan—are the responsibilities of the senior administrative leadership. This case exclu- sively highlights the role of the chief information officer CIO because he is the only individual in the senior leadership taking charge of this implementation. In this case, the chief executive officer (CEO) and other executive members are absent from all proceedings and planning. This transforms a complex situation into one of increased tension and difficulty. Given the aforementioned absence of other senior leaders, as well as the problems identified in this case, what can WMUH do to improve the success of the IIS project implementation?

First, the CIO, CEO, and other executive members should hold meetings with department leaders. By communicating the defined goals of the organization and gathering support for the IT vision, other vital members of the project can serve to enhance the credibility and goals of the IIS. With the CEO and CIO both taking active roles, senior leadership can hopefully address the concerns of all those involved in a way that demonstrates to other departments the willingness of all senior leadership to work together toward full integration.

10. Early Implementation Problems of an Integrated Information System 111

LTF10 10/11/2004 8:47 AM Page 111

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

Second, the executive leadership, most specifically the CEO and CIO, should be sen- sitive to the cultural values of each department. By understanding the culture of each department, senior leadership will possess an innate ability to understand specific departmental needs and issues. By gaining the support of departmental leaders, the leadership will be in a better position to communicate their vision to other staff. The department leaders should look for change agents in their departments and develop a plan that will cater to the staff.

Third, the senior leadership has a vital role in the success of this project and should encourage teams to:

1. Communicate and inform users regarding changes being considered and/or developed.

2. Seek input from department leaders and push and pull through various times of success or failure.

3. Provide appropriate feedback to users regarding their concerns/suggestions. 4. Foster an understanding of the importance of communication throughout all levels

of the organization.

Senior leadership must also align the incentives for departments. Anything that allows departments to act independently without regard for the mission and vision of the institution should be restructured. The CEO and CIO should work closely with the clinical advisory committee. They should empower that committee to make the neces- sary changes, as well as give the committee direction and a sense of purpose. The clinical staff should know they will not be allowed to bypass the decisions of this group (the clinical advisory committee). The CEO should be an advocate for the committee, making it known to the board of directors that this group must be given decision- making authority.

Finally, senior leadership, as well as the board of directors, must accept the fact that there may be a loss of productivity during this phase but realize this is a short-term loss in favor of a long-term gain. All involved must continue to communicate the IT vision and strategy for the institution. A process of conflict resolution should be adapted so that individuals will feel that their concerns are being addressed in a fair manner. A committee representing the various cultures at WMUH should be directed to develop a process to resolve conflicts that arise.

In closing, none of these suggestions will guarantee the success of the IIS project at WMUH. However, without the commitment of senior leadership to promoting an atmosphere of open communication and change management, one can certainly envi- sion a future of difficulty, if not failure.

Questions

1. What clinical and/or administrative needs is the IIS project intended to address? Who perceives these needs to be a problem?

2. What is the definition of success for IIS? From whose perspective? 3. WMUH is a large, complex organization with many professional groups and fac-

tions. In addition, IIS is an ambitious, long-term, expensive, high-risk project. These conditions provide ample opportunity for the use of power and politics to derail the project. Does CIO Richard Solomon have the power or political resources to make IIS succeed? If not, how should he handle this situation?

112 Section III. Implementation

LTF10 10/11/2004 8:47 AM Page 112

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

4. Comment on the needs of Dr. Mark Weber, department of medicine chair. Is he being unreasonable? How should Richard Solomon approach Dr. Weber?

5. RDI, the vendor for IIS, was selected after a fairly thorough evaluation process that involved a number of clinicians. Yet Dr. Weber perceives that the system is being forced on his department without consideration of its needs. What might account for this perception?

References 1. Senge PM. The Fifth Discipline: The Art and Practice of the Learning Organization. New York:

Doubleday, 1990. 2. Friedman CP. Information technology leadership in academic medical centers: a tale of four

cultures. Academic Medicine 1999;74(7):795–799. 3. Greiner LE. Evolution and revolution as organizations grow. Harvard Business Review 1972;50

(July–August):37–46. 4. Lorenzi NM, Mantel MI, Riley RT. Preparing your organization for technological change.

Healthcare Informatics 1990;12:33–34.

10. Early Implementation Problems of an Integrated Information System 113

LTF10 10/11/2004 8:47 AM Page 113

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

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

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

12 Managing Change: Analysis of a Hypothetical Case*

Organizer and Moderator: Joan S. Ash Participants: James G. Anderson, Paul N. Gorman, Rita D. Zielstorff, Natalie Norcross, Jody Pettit, and Patricia Yao

Case Presentation

Mercer Medical Center has been successfully competing for business because of the strong visionary leadership of chief executive officer (CEO) E. Joseph Burns. However, the pressure has been relentless to constantly update expensive systems and equip- ment. The latest lawsuit has brought this forcefully home yet again. The publicity will undoubtedly have a negative impact on the public’s perception of Mercer and on crit- ical negotiations with the area’s largest employer, Syntel. Medical director of informa- tion services (MDIS) Kathryn Reed has just left a meeting where she and chief information officer (CIO) Barry Marks were informed that it is critical that the time- line for implementation of the new physician order entry (POE) system be moved up. They now have only 9 months instead 2 of years to make this happen. And make it happen they must.

Background Mercer Medical Center is a 450-bed community hospital in a large metropolitan area in the Pacific Northwest, with 650 medical staff and a residency program. It is part of an ever-growing health system that has been successful in competing with two other major health systems in the city. Managed care penetration is increasing, and Mercer has bought up small private clinics as well as having its own managed care insurance plan. To remain competitive in the marketplace, Mercer has gone after contracts with the high-technology firms in “Silicon Forest,” as the area is known. These contracts are sought after because these companies tend to employ lots of young, relatively healthy people who, overall, use fewer healthcare dollars—a critical advantage in this area of high managed care penetration.

One such company, Syntel, a leading manufacturer of processing chips for the com- puter industry, is currently in negotiation with Mercer for a managed care contract. Interestingly, Syntel has recently announced its plans to get more involved in the healthcare arena. The medical industry, top executives say, is due for a consumer-driven

121

* This presentation and discussion were part of the Cornerstone on Managing Change, one of four Cornerstone sessions included in the program of the AMIA Annual Fall Symposium, Washing- ton, DC, November 6–10, 1999. All names of organizations, individuals, and software systems are fictitious, with the exceptions of Stanford University and Edward H. Shortliffe. Reprinted, with permission, from The Journal of the American Medical Informatics Association 2000;7(2):125–133.

LTF12 10/11/2004 8:55 AM Page 121

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

technological revolution that will result in advances that have already changed the busi- ness world in retailing, banking, and investing. The prevailing sentiment is that the health industry is lagging behind the corporate world. Questions about the hospital’s information system arose during negotiations. Mercer’s information services are com- parable with those of the other health systems in town, with the exception of its POE system. One of the competing medical centers has announced its plan to deploy a new POE system. Syntel was impressed by this innovation and queried Mercer about its plan for a POE system. Mercer’s CEO, loath to be upstaged by the other health system, told Syntel that they also plan to implement such a system in the not-too-distant future.

The Pressures Two years ago, the hospital attempted to implement a nursing documentation system called Physician Manager, and it ended in a disaster of grand proportions. The medical staff had opposed this system from the time they previewed it. It was implemented without any consideration of physicians’ opinions. After only 2 days of operation, it had to be abandoned because there were so many technical problems. A substantial amount of money was wasted, the CIO nearly lost his job, and the information serv- ices department’s image was severely tarnished. More recently, another system, called CareReviewer, was deployed and the medical staff was challenged yet again by unwel- come technology. In general, information service systems are seen by medical staff members as adding to their workload when these systems should be making jobs easier. Physicians are increasingly being pushed to see more patients in less time and with less compensation. Managed care is driving down their salaries. Professionals who had pre- viously enjoyed a great degree of autonomy are now feeling like cogs in the health- care machinery, working to make more money for the top executives. All these pressures are driving physicians to the breaking point.

The corporation is under pressure as well. Negative publicity from a recent lawsuit could damage Mercer’s position in the market and its managed care contracts. A 35- year-old woman, a promising new talent at Syntel, was admitted to Mercer, through the emergency department, for high spiking fever and rigors. Blood cultures, blood for a complete blood cell count, and appropriate samples were drawn in the emergency department. The doctors were about to administer antibiotics when the patient’s blood pressure dropped; she was rushed to the intensive care unit with a presumptive diag- nosis of sepsis. The ordering systems in the emergency department and the intensive care unit were separate, so new orders had to be written. A sleep-deprived physician who had been up for 27 hours quickly scrawled a stat order for ampicillin/sulbactam (a potent antibacterial medication). The order was issued in triplicate, with one copy going to the pharmacy. The pharmacy read the medication as Acyclovir (an antiviral medication) and filled it as such. A registered nurse from the float pool quickly hung the intravenous medication, and it was administered. A seasoned intensive care unit nurse recognized the size IV medication bag as being the wrong size and caught the error, but 2 hours had elapsed. Unfortunately, the young woman’s pressure continued to drop, and she suffered irreversible brain damage.

Information Services Leadership After the PhysicianManager system failure and the resulting uproar from the physi- cians, the board of directors created the position of MDIS. This person would be a

122 Section III. Implementation

LTF12 10/11/2004 8:55 AM Page 122

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

medical information specialist who would work closely with the CIO and develop an alliance with the medical staff. Kathryn Reed, M.D., was appointed because of her excellent informatics background. After receiving her M.D. and M.B.A., she earned a Ph.D. in medical informatics from Stanford University. Under the guidance of Edward Shortliffe, one of the pioneers in medical informatics, Kathryn proved to be a formi- dable student. She was hired as the MDIS reporting directly to CIO Barry Marks. The goal was for these two people to work together, the CIO to bring management disci- pline to the complex organization, and the MDIS to work with the medical staff to both stimulate effective user input and build support for technology improvements. It was hoped that these efforts would go a long way toward overcoming the organiza- tional and political barriers in the organization.

Physician Computing Council Reed eventually received enough funding to hire six people devoted to supporting physician computing. She created positions for two technical specialists, a network analyst, two support technicians, and a support person for her department. She focused all these resources on meeting the needs of the physicians and being their trustworthy ally in the organization. She established a twelve-member physician computing council to create a venue for presenting new ideas, brainstorming, and having physicians “test- drive” programs before they were introduced throughout the organization. She also hoped to gain their support and have this group champion ideas to other physicians.

Reed is acutely aware of the dangers of imposing a system on unwilling users. She has worked hard to gain the respect and trust of the medical community by being straightforward and honest and having no hidden agendas. By keeping the users’ needs foremost in her mind, she sets a high standard of customer service for everyone in her department. She has also had to overcome automatic distrust because she is seen as part of the hospital administration and because she did not advance from within the existing medical staff. Reed demonstrates her commitment to “walking the talk” by going the second mile herself. When introducing e-mail to the medical staff, she offered to help them get hooked up at home by personally visiting each one at home. By doing this, she was not only building trust but was also making a first step toward getting physicians to use information technology on a personal level and seeing advantages to the system. She is further building relationships through the training program she has created. Nurses have been challenged to teach physicians one-to-one to use the current information system to look up patient data. For the nurse who manages to teach the most physicians, she offered the unorthodox incentive of an all-expenses-paid trip to Hawaii.

Managing the Change Implementing a POE system has been identified as a future goal, and Reed is working toward that step by step. She knows that this will be a challenge at Mercer, given its previous history. She also knows that such a system will cause dramatic change in the organization and that such change will naturally be resisted. Her research has shown her that the whole organization can expect to be stressed by several aspects of POE implementation:

• Changes in established work flow patterns and practices. • The strict, literal interpretation of rules by the computer or the inability of the system

to identify intent.

12. Managing Change: Analysis of a Hypothetical Case 123

LTF12 10/11/2004 8:55 AM Page 123

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

• The ambiguity of governance policies. • The lack of a clear understanding in the physician community of the long-term strate-

gic value of the information services initiative.

Reed is also familiar with the experiences of other hospitals in implementing POE systems, and she is determined to learn from them. She has seen how profoundly orga- nizations change when new technology comes along. New organizational structures are configured. The vision developed by the administration takes time to percolate into the hearts of personnel at all levels. Integrating the vision into the strong culture of the medical staff requires senior, respected, and powerful members of that staff to viscer- ally and intellectually believe in it too. Such champions must be able to sell the vision to others and respond to any pressures with innovative methods. Reed has been making progress in developing such champions. The physicians on her physician computing council seem to be coming along nicely. They are beginning to understand the poten- tial of this technology and are able to speak convincingly in support of a POE system. However, considerable skepticism remains, even in their minds. From them, Reed knows that physicians want a system that:

• Is fast (subsecond response time). • Is easy to use, requiring a minimum of training. • Has help available 24 hours a day either on line or by telephone. • Has a consistent system interface. • Will affect patient care positively. • Is accurate and reliable.

Physicians’ needs must be thoroughly addressed prior to implementation if there is to be any hope that they will use the system. The ability to review a patient’s record on demand is powerful. Once they realize that their time is being maximized as they use a POE system, they will then be motivated to use it. The innate desire of physicians for information is a factor in motivating them to use a clinical information system. Essentially, ensuring ongoing use would require meeting their efficiency needs through productivity and ease of use.

Opposition would naturally be expected to any change that challenges assumptions and routine behaviors of practicing physicians, and Reed knows she can expect mighty opposition from that group especially. She hopes to manage the expected change by carefully leading the medical staff to acceptance of the new system. She plans to work on substantial physician involvement and leadership in the process of application development, focusing on speed and convenience and showing a willingness to iden- tify user needs and reflect them in the system. By having physicians on the develop- ment team, Reed is looking to establish the physician champions who will lead the rest of the medical staff into smooth adoption of the POE system.

What Should Dr. Reed Do? Reed now finds herself in a difficult position. The CEO is pressing hard for a fast imple- mentation of the POE system. Critical negotiations and public perceptions are depend- ent on making it happen. Reed is convinced that the corporation is not ready for this change. Without physician support, such a system will be doomed to failure. She sees all her hard work in building trust and credibility going up in smoke if she forces the system on the organization without taking the time to do it right, and time is what she now does not have. What should she do?

124 Section III. Implementation

LTF12 10/11/2004 8:55 AM Page 124

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

Comment by James G. Anderson

Assessing the Motives The rush to implement the POE system is driven by all the wrong forces. The first is competition: Mercer Medical Center wants to negotiate managed care contracts. It is competing with other managed care providers in the area, so basically the implemen- tation is being driven by this as a primary motive. Also, there is a secondary motive here: public relations. Having a state-of-the-art POE system will be a good promotional tool for negotiating these contracts. The unfortunate thing, of course, is that a system that has been implemented too hastily increases the risk of failure, of errors, and of increased staff resistance. We have already described the instance of the case of the young woman who was injured because two systems—the emergency department system and the intensive care unit system—did not articulate. Certainly, hastily imple- menting a new system is likely to lead to more failure and more errors and more dis- trust from the physicians. We have also heard that the physicians are angry and upset about managed care and already feel that they were not consulted adequately in an earlier implementation, and this hasty implementation is likely to increase staff resistance.

Failure What do we know about failure? Many published case studies illustrate failure: failure to demonstrate improvement in patient care;1 failure because a system was unable to demonstrate savings in operating costs;2 failure because there was not adequate train- ing and preparation of residents and house staff and, as a result, the new system increased patient waiting time and staff overload;3 failure of a system that was put into a private practice because none of the physicians had intimate knowledge of the system or took part in the decision making;4 and failure because physicians opposed a system that interfered with traditional practice routines.5,6 All these cases demonstrate the folly of rapid implementation without adequate participation of the medical staff. In fact, these failures are likely to result in lawsuits. These failures have a key element: a lack of physician involvement in and acceptance of clinical information systems. Without that, we are almost guaranteed failure.

Ensure Physician Involvement What can Dr. Reed do about it? She seems well aware of the problems she will have with the staff. The first thing she can do is to ensure broad physician involvement in the selection and implementation of the system. It may be too late in this case, but systems without the sponsorship of the medical staff are likely to fail. One strategy, of course, is to enlist the support of influential physicians. In one study, we identified and recruited influential physicians on the medical staff of a university hospital in order to increase use of a POE system. As a result, the hospital experienced an increase in the use of the system by the medical and house staff and a reduction in order entry errors.7

A second major factor here is to make sure the system provides immediate benefits to users. To do that, you need to identify key features that users will need on a daily basis and stress both short-term and long-term benefits. It is not sufficient to merely say that the hospital will benefit by being at a better competitive advantage and that the new system will bring more to the bottom line. There clearly have to be tangible benefits

12. Managing Change: Analysis of a Hypothetical Case 125

LTF12 10/11/2004 8:55 AM Page 125

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

EBSCO Publishing : eBook Collection (EBSCOhost) – printed on 3/9/2022 5:39 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

to the individual clinical users. I worked with Carolyn Aydin and the people at the Kaiser Permanente Medical Center in San Diego in the implementation of the CompuHx system, which was a computer-based health appraisal system.8 It was a fairly successful medical system implementation, not only because the medical director was strongly behind it and we had support from the medical staff, but also because it pro- vided tangible benefits to the examiners who were taking in patients, collecting medical history data, and entering physical examination data. There were clear benefits to the users in this case.

Assess Work Flow Another major factor that you should consider in advance is how the system will affect routine practice patterns and professional relations. Study current work flows and iden- tify the processes that the computer can improve, especially those that it will have an impact on. One technique for doing this, which was used effectively in a recently pub- lished study,9 is to use surveys and interviews of every organizational unit and profes- sional group to identify training needs, potential problems, and areas where support is needed. In the study, this was done not just one time; it was done before implementa- tion and repeatedly during implementation, so that the implementers could head off problems before they arose.

Behavioral Change Another factor is to anticipate and be prepared to manage a host of behavioral and organizational changes caused by the implementation of this system. Unfortunately, as much as we talk about them and look at past implementations, every organization is different and has a unique culture. One technique that has been used effectively is to introduce the system in stages, possibly in one unit or in one department, instead of all at once throughout the organization.10 Provide specialized training to each group of users. Physicians frequently want to be trained by other physicians, and they will not attend continuing medical education types of programs or in-service training. It is likely that physicians are going to have to have one-to-one contact with other physicians who are experienced in using the system if implementation is to be successful. Provide tech- nical assistance on a 24-hour basis. If you do not do this, there is likely to be frustra- tion, anger, and failure.

The Ethical Challenge If we are going to successfully develop and implement a system, it must be fast, flexi- ble, easy to use, and reliable. The ethical challenge here is this: If the physicians really believe that the system requires 18 months and not 9 months to implement, then to protect patient welfare, safety, and institutional morale they need to tell the adminis- tration that the administration is wrong. They need to refuse to do the job poorly.

Comment by Rita Zielstorff

Force Field Analysis The Mercer Medical Center case depicts a situation that is not uncommon when auto- mated systems are implemented, when diverse, often conflicting forces taken together

126 Section III. Implementation

LTF12 10/11/2004 8:55 AM Page 126

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

affect the likelihood of success of a planned change. Confronted with a situation like this, the change agent must analyze the nature of these forces and work to change them, or at least accommodate them, to achieve the desired goal.

One method that I have found useful for doing this is to use Kurt Lewin’s classic force field analysis model.11 The parameter of interest in the Mercer Medical Center case is the likelihood of success of the POE system. Figure 12.1 shows the general model. In Figure 12.2, the circled arrows represent forces that indicate a low likelihood of success, whereas the circled arrows in Figure 12.3 indicate a high likelihood of success.

So how does this apply to Mercer Medical Center? First, we identify the forces them- selves and determine whether they are positive or negative in their impact on the like- lihood of success. Next, we determine how to manipulate the forces so that the negative ones are weakened and the positive ones are strengthened.

12. Managing Change: Analysis of a Hypothetical Case 127

FIGURE 12.1. Kurt Lewin’s classic force field analysis model. The likelihood of success is classi- fied as low, moderate, or high. The arrows symbolize the forces that have an impact on each pos- sible outcome. The downward arrows represent forces that drive the likelihood of success down; the upward ones represent forces that drive the likelihood of success up. In this adaptation of the model, the length of each arrow indicates the strength of the force it represents. Adapted from Lewin.11

FIGURE 12.2. Adapted Lewin model. The area inside the oval shows that the forces driving down the likelihood of success are strong, while those driving it up are weak, resulting in the likelihood of success being low.

LTF12 10/11/2004 8:55 AM Page 127

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

Analysis of Forces at Mercer Medical Center It is important to point out that the forces themselves are neither good nor bad. They are only positive or negative with respect to whether they influence the likelihood of success of the POE system. Table 12.1 summarizes the forces in play at Mercer Medical Center. They include a competitive environment that leads to the perceived need for rapid deployment of the POE system, a CEO who seems unaware of the risks involved in such a course, a skeptical clinician population that has been burned by a previous mismanaged implementation, a strong MDIS, a physician computing council headed by a sympathetic leader, and several others. After carefully examining each force that is expected to affect the likelihood of success, we can categorize them as positive or negative, as shown in Table 12.2. Having done that, we can figure out how to weaken the negative forces and strengthen the positive ones.

Example of Weakening Negative Forces Let us look at one of the forces categorized as negative: an unenlightened CEO. This person has responded to pressure by making a promise to implement the system within 9 months, a highly risky proposition. It might be possible to weaken this factor by giving him information about previously failed attempts at implementation. For example, two articles by Massaro5,6 provide useful descriptions of lessons learned in a failed imple- mentation, with all of its ramifications. Other tactics might include surveying other

128 Section III. Implementation

FIGURE 12.3. Adapted Lewin model, showing weak downward forces and strong upward forces, resulting in the likelihood of success being high.

TABLE 12.1. Forces in Play at Mercer Medical Center.

Unrealistic time frame Unenlightened CEO Pressure from Syntel for rapid implementation Promises of implementation by competing hospital Skeptical clinicians, but fragile trust is building Strong administrative support for implementing POE Existence of physician advisory group Creation of position of Director of Medical Information Systems Desire for safe care among all participants A ‘‘good’’ system capable of delivering the functionality needed to provide value to clinicians

LTF12 10/11/2004 8:55 AM Page 128

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

hospitals like Mercer to find out about their experiences; hiring a consultant who is experienced with the selected POE system, to provide a quick assessment of how much time is actually needed for implementation; asking the vendor about their experience with implementing such a system at similar hospitals; or reminding the CEO of the considerable disruption that occurred when the practice management system was implemented at Mercer.

The aim is to make the CEO aware of the risks of a hasty implementation and the consequences of failure. In this case, the consequences of failure could include further negative publicity for Mercer, possible withdrawal of the Syntel contract (or at least failure to renew the contract), and further weakening of Mercer’s competitive position for acquiring other contracts.

Example of Strengthening Positive Forces One of the forces we classified as positive is the beginning trust among clinicians that has been nurtured by the MDIS, Dr. Reed, who created the physician computing council. This trust could be strengthened by being absolutely honest about the strong motivating factor for implementing the system as quickly as feasible: competition for contracts that underpin the survival of the medical center. After all, two thirds of the physicians (and probably most of the nurses) are on salary. If the medical center fails for lack of business, these employees and many others will lose their jobs, and patients may have a harder time getting care. Rallying around a common goal and capitalizing on the support of opinion leaders could foster a “can do” environment, a culture where everyone identifies with the need to get the system up and is willing to make compro- mises to do so. The implementation is then seen as something that is done not to them but with them or, better still, by them. This is, admittedly, hard to pull off, but the insight and sensitivity shown by Dr. Reed and her colleagues are very strong positive forces that can be leveraged to strengthen other, weaker positive forces.

It is not always possible to mitigate every negative force or strengthen every posi- tive force to the degree that one would like. However, using tactics like these can usually at least alter the likelihood of achieving the desired goal.

Comment by Paul N. Gorman

The Language Used We are talking about two things here: implementing systems and caring for patients. It is interesting to look at the language used in this discussion about managing change. These are some of the words and phrases used in reference to the implementers, the advocates of change: They show “strong leadership” in the organization, an organiza-

12. Managing Change: Analysis of a Hypothetical Case 129

TABLE 12.2. Forces Classified as Positive or Negative. Positive Negative

Strong administrative support Unrealistic time frame Director of Medical Information Systems Unenlightened CEO Physician advisory council Pressure from Syntel for rapid implementation Beginning trust among clinicians Competing hospital promises implementation Desire for safe care among all participants A ‘‘good’’ system

LTF12 10/11/2004 8:55 AM Page 129

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

tion that is “competitive and innovative”; they are people of status, people who are “chief officers” and “directors” of various kinds; they are characterized by “movement” in various directions, by “vision,” “value,” and “integration.” Other words used to describe them are “champions” and “early adopters,” conjuring up images of people carrying standards as they ride forward on their white horses. These are some very pos- itive terms.

Looking at the language used about the implementees, the people on whom the change would be imposed or inflicted, we see words describing their “objections,” “bar- riers,” “resistance,” and “reluctance.” We are told that they would “fight it.” These are not people of status, these are “staff”—“medical staff, nursing staff, hospital staff.” We are not told about what they think but about how they feel. They feel like cogs, they feel distrust, they feel tension, they feel fear, and they are not ready. They need edu- cation and they need training, presumably from the implementers. These differences in language are important because they suggest implicit constructs or models about people. In fact, they set up for us a nearly adversarial relationship, an us-vs.-them rela- tionship. The words describing us are positive and proactive; those describing them are mostly negative and reactive. We embrace the new; they cling to the old. We are think- ing and cerebral; they are feeling and affective. We use logical scientific rationale for change; they are resistant, irrational, and unscientific. The words do imply our forceful way of changing the way we think and changing the way we act. They may set us up in a really counterproductive relationship.

Is Resistance to Change Rational? The next point has to do with whether resistance to change is irrational or unscientific. To quote David Miller’s essay in Science:12 “But science is more than the sum of its hypotheses, its observations, and its experiments. From the point of view of rationality, science is above all its method: essentially the critical method of searching for errors.” It is not argument, it is not logic, it is not hypotheses; it is a critical method of search- ing for errors. In medicine, this has been especially important. The history of medicine is littered with good ideas that were bad for patients. If you know about using oxygen for babies in the 1940s, it was considered an obviously beneficial therapy. It was diffi- cult to organize randomized trials for this therapy because of the ethical dilemma of depriving patients, babies, of such obviously beneficial treatment. For those of you who are not familiar with the story, the trials showed that oxygen causes retrolental fibro- plasia and blindness.

The ethical dilemma was very difficult to get past in that case. There are many other examples. During the 1950s the left internal mammary artery was tied off because it was thought that this would be good for coronary artery disease. Nowadays, we use the left internal mammary artery to bypass to the coronaries because it is so useful not to tie it off. We have used massive doses of steroids to treat things like acute respiratory distress syndrome and cerebral hemorrhage. It was rational; it made perfect sense that it would work, but it did not work and in some cases it was harmful. In the 1970s and 1980s, the pulmonary artery catheter, the Swan-Ganz catheter, really swept the nation because it was so rational, it made such good sense that this catheter would help people, would help us manage patients in a rational way. But in the 1990s, proponents of this test called for a moratorium on its use until trials had shown that it was beneficial, because none had.

Advanced cardiac life support protocols, if you have ever seen the old ones from the 1970s and 1980s, were mostly based on theories, and today we scoff and laugh at the

130 Section III. Implementation

LTF12 10/11/2004 8:55 AM Page 130

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

kinds of treatments that were included in the early protocols, because now we do not think they are right. In medicine, it has been very important that we make sure that what makes sense is actually good for people. Sackett,13 in his typical fashion, put it this way: “Reports with enthusiasm generally lack controls, while reports with controls generally lack enthusiasm.” That is the rationale that underlies evidence-based medi- cine. We have got the same problem with technology. To quote Michael Crichton:14

We live in a culture of relentless, round-the-clock boosterism for science and technology. With each new discovery and invention, the virtues are always oversold, the drawbacks understated. Who can forget the freely mobile society of the automobile, the friendly atom, the paperless office, the impending crisis of too much leisure time, or the era of universal education ushered in by tele- vision? We now hear the same utopian claims about the Internet. But everyone knows science and technology are inevitably a mixed blessing.

Gregory Bateson15 has pointed out a logical rationale for clinging to the old:

It is very easy to fall into the notion that if the new is viable, there must be something wrong with the old. . . . What is always important is to be sure that the new is not worse than the old. Other things being equal, the old, which has been somewhat tested, is more likely to be viable than the new, which has not been tested at all.

What Is a Clinician? The above argument shows that not changing has a rationale. It is not necessarily irra- tional, and it might be a very rational approach. Let us now talk about what we mean by clinical or clinician. The word clinical can mean different things to different people. For example, a clinical assistant professor is not a real professor. It is a title we give out to people so that they will come and teach at a medical center. In Chicago, a radio report told how a policeman was describing an assailant who stuck an automatic weapon in the window of his squad car and began firing. The policeman was asked what the man looked like. He said the man looked “cold and clinical,” which is different from how clinicians imagine themselves looking. We all have different views of what a cli- nician might be. In our research on information needs, we have tried to come up with an operational definition, and these are some of the features that we use: Clinicians possess specialized knowledge, they have received some kind of experiential training, and they have a direct relationship with a person one calls a patient or sometimes a client. They make decisions about patient care; and they act in the patient’s best inter- est, not Syntel’s, not the CEO’s. They integrate diverse information into decisions, and they function within time and resource constraints. For those of us who design infor- mation systems, the central task is the use of the information systems. The patient care problem and problem resolution are secondary things. For physicians and clinicians, the main problem is to resolve the patient’s problem, and they take the shortest path to the best resolution of the problem. Sometimes that includes the information system and sometimes it doesn’t. Those flying on airplanes are not avoiding trains; they are taking the shortest or easiest path to a destination. When physicians do not use com- puter systems, it may not be sabotage or avoidance but simply a matter of taking the shortest, most direct path to the goal they are trying to accomplish, which is usually a goal for their patients.

Understanding this can help us work with them a little better. Annas16 pointed out, in the New England Journal of Medicine in 1995, that metaphors matter and that lan- guage has a powerful effect on how we think and act. He suggests that we can invig-

12. Managing Change: Analysis of a Hypothetical Case 131

LTF12 10/11/2004 8:55 AM Page 131

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

orate the debate by adopting a new metaphor, and one of the things that we might do as we think about how to change healthcare processes with information systems is to think about how we use language, and refine the metaphor to make ourselves more effective.

Constructive Engagement To summarize, language suggests implicit constructs, and if we reexamine the model, we might be able to frame the debate in a more productive way. Second, skepticism is scientific and rational; it is not reactionary or irrational or affective or feeling. It may be that people have feelings about computers, but there is also a scientific or rational reason to stick with what works. The clinician’s task is caring for patients, not using a computer. If we understand that, we can understand how to help them use computers more effectively. Finally, “constructive engagement” might be the way to view this process, and that requires time. Nine months might not be enough, and physicians need to say that if it is the truth. The process requires time, effort, patience, and understanding.

Audience Discussion

Joan Ash: In summary, the ethicist has said that the physicians should probably take a stand. The implementer has done a careful, practical force field analysis to identify the strengths of the various influences on the likelihood of success, and the clinician has stated that not changing may actually be a rational thing to do. Audience, what would you do?

Member of the audience: The question emphasizes the point that the senior execu- tive is telling the experts in systems implementation, the people who know how to do things, what to do. This represents the wrong people making the wrong decisions. This is micromanagement, actually mismanagement. You never hear the term mismanage- ment; we do not usually phrase it as such, but in medicine we look at mismanagement of patients very carefully.

Paul Gorman: There is a difference between failures in those different domains and between the models in those different domains. First of all, with respect to failures, there are failures in business, failures in information systems, and failures in medicine. In business, most businesses fail. The failure rate of small businesses is enormous, and business is the most Darwinian of worlds: It is the survival of the fittest. Failure is something that happens all the time; you get some more money, acquire some more capital, and move on. Failure is frequent. The business model of what failure means is a little different from ours. In information technology, similarly, failure happens all the time. You write a program, it crashes, you change it, you fix it, and you write a better program.

In medicine, failure is different, in that somebody either gets worse or dies. I don’t know that we fail less—we hope that we fail less—but failure matters in a very differ- ent way; it matters as it does to aircraft operators. Failure has different meanings, and I think the differences make people think differently. The management model, the information technology model, and the medical model are very different. Librarians also have a different way of thinking about things, and when these cultures come together it takes a lot of work, a lot of time, a lot of talking to get to where you under-

132 Section III. Implementation

LTF12 10/11/2004 8:55 AM Page 132

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

stand one another. Often, you’re using the same words and talking about something different, or you’re using different words and talking about the same thing. It takes a fair amount of time to get to that point. This computing council idea is one of the key ways to get there, and it usually takes more than 9 months. I agree that the idea that you can just tell information technology people how to do something if you’re not in information technology is not the best course.

Joan Ash: Don’t we have an obligation to teach these CEOs our point of view? We could provide some sort of training or education for them so that they would be better at making those decisions, or at least they could let the right people make the decisions.

Member of the audience: Where in the structure of the hospital environment and through the approval process does the clinical point of view come in, and where should it come in?

Paul Gorman: Some technologies that get into hospitals don’t affect work flow much, like telephones. No one pays much attention to what kinds of phones get purchased. Part of the problem is that we used to think about computers that way. They’re just devices: Buy a bunch of them, install them, and keep them running. Yet they’re much more like the real tools of the trade, the bronchoscope or the catheter that the cardi- ologist uses. The cardiologist wouldn’t dream of having someone else specify what catheter to insert into a coronary artery to do an angioplasty. Computers are now tools that affect the way we work every bit as much as that, and we don’t have a model or structure that has the people who use those tools engaged in specifying what the tools are or how they should be used. One of the comments about the Mercer Medical Center scenario is that no one is actually asking for physicians’ input about whether or when to install the system. They want buy-in and not input, and those are very different things.

Member of the audience: When Nancy Lorenzi17 gave her overview, she pointed out how important communication is. I was struck during the discussion by the lack of involvement of the CEO. There’s a glass wall here, because the CEO has been allowed to make these decisions, yet communication hasn’t taken place.

Member of the audience: The analyses have been a bit hard on the CEO. It seems that the issues of competition and public relations aren’t things that can be ignored. My CEO is puzzled but not irrational. The best thing that Dr. Reed can do is cancel the meeting. Then she needs to engage the CEO productively. I would challenge the CEO to come into the rescheduled physicians’ meeting and lay out the case to get everybody moving in the same direction. Let the physicians go back and explain why it can’t be done in 9 months and lay out a pilot implementation, work out the details, try to solve the competition issues, and solve the Syntel issues. We can get everybody engaged in the challenge of accelerated implementation through pilots in 9 months and further roll out in 12 months. This is taking the force field analysis and beginning to engage the people. We can’t ignore the CEO’s point of view.

Jody Pettit: Our assignment in writing the case included making a recommendation. Part of our suggested strategy was to actually do just what the last person said— increase communication and get everyone working on a solution together. We propose the creation of a new, smaller, multidisciplinary planning group of six to eight people, including at least two physicians and a representative from Syntel. This group should be charged with specific goals and a tight timeline. Dr. Reed should provide a facilita- tor and all the resources necessary to meet the goals. She should also create a com- prehensive communication plan to keep everyone in the organization informed all along the way.

12. Managing Change: Analysis of a Hypothetical Case 133

LTF12 10/11/2004 8:55 AM Page 133

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

Conclusion

The Mercer Medical Center case offers a real-world scenario illustrating many of the points raised by Lorenzi and Riley.17 Organizations need to become learning organi- zations if they are going to survive and adapt to change. The environmental influences outlined in the Mercer case are not very different from those pressuring many orga- nizations. The panelists and members of the audience suggested different strategies for dealing with Dr. Reed’s dilemma because they represent different stakeholder groups. However, there was a common theme underlying all of the recommendations—com- munication. The stakeholders must come together, engage in constructive problem solving, create a common strategy, and actively take charge of the change.

References 1. Barnett G, Winickoff RN, Morgan MM, Zielstorff RD. A computer-based monitoring system

for the follow-up of elevated blood pressure. Medical Care 1983;21:400–409. 2. Dambro MR, Weiss BD, McClure CL, Vuturo AF. An unsuccessful experience with comput-

erized medical records in an academic medical center. Journal of Medical Education 1988; 63:617–623.

3. Campbell JR, Givner N, Sellig CB, et al. Computerized medical records and clinic function. MD Computing 1989;6(5):282–287.

4. Chessare JB, Torok KE. Implementation of Costar in an academic group practice of general pediatrics. MD Computing 1993;10:23–27.

5. Massaro TA. Introducing physician order entry at a major medical center: I: impact on orga- nizational culture and behavior. Academic Medicine 1993;68:20–25.

6. Massaro TA. Introducing physician order entry at a major medical center: II: impact on medical education. Academic Medicine 1993;68:25–30.

7. Anderson JG, Jay SJ, Perry J, Anderson MM. Modifying physician use of a hospital informa- tion system: a quasi-experimental study. In Evaluating Health Care Information Systems: Methods and Applications, Anderson JG, Aydin CE, Jay SJ (eds). Thousand Oaks, CA: Sage, 1994:276–287.

8. Aydin CE, Anderson JG, Rosen PN, et al. Computers in the consulting room: a case study of clinician and patient perspectives. Health Care Management Science 1998;1:61–74.

9. Martin-Baranera M, Planas I, Palav J, Miralles M, Sancho JJ, Sanz F. Assessing physicians’ expectations and attitudes toward hospital information systems. The Imasis experience. MD Computing 1999;16:73–76.

10. Schroeder CG, Pierpaoli PG. Direct order entry by physicians in a computerized hospital information system. American Journal of Hospital Pharmacy 1986;43:355–359.

11. Lewin K. Field Theory in Social Science. New York: Harper Row, 1951. 12. Miller D. Being an absolute skeptic. Science. June 4, 1999;284(5420):1625. 13. Sackett DL. How to read clinical journals: V: to distinguish useful from useless or even harmful

therapy. Canadian Medical Association Journal 1981;124(9):1158. Paraphrased from Bywaters EG. Treatment of rheumatic fever. Circulation 1956;14:1153–1158.

14. Crichton M. Ritual abuse, hot air, and missed opportunities. Science. March 5, 1999; 283(5407):1461.

15. Bateson G. Mind and Nature. New York: Dutton, 1989:177. 16. Annas G. Reframing the debate on health care reform by replacing our metaphors. New

England Journal of Medicine 1995;332:744–747. 17. Lorenzi NM, Riley RT. Managing change: an overview. Journal of the American Medical Infor-

matics Association 2000;7:116–124.

134 Section III. Implementation

LTF12 10/11/2004 8:55 AM Page 134

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Robert T. Riley

Chapter 13 E3 at Vanderbilt University Medical Center . . . . . . . . . . . . . . . . . . . . . . . . . . 143

David Posch, Nancy M. Lorenzi, and Thomas Campion

Chapter 14 Catch 22: The Case of Utilization Management’s Return on

Investment Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Fern FitzHenry

Chapter 15 Antimicrobial Utilization Program at the University of Central State

Medical Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Melissa Kaplan and Beth Wickerham

Chapter 16 Central Medical Healthcare System: The Case of the Well-Aggregated Pa- tient Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Laura Larsson, Michael Lieberman, and Kelly J. Bradway

Chapter 17 Building Consensus: Quality Improvement at Vesalius Health System . . . . . . 174

Sarah Corley, Steven Cohen, Jeffrey Gilbert, Cora Lam, and Benjamin LeBlanc

Section IV Economics

LTF13 10/11/2004 8:57 AM Page 135

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

Introduction

Robert T. Riley

Economic Impacts

The true techie says, “If it can be done, it should be done!” The true bean counter says, “Show me a detailed cost-benefit analysis—and I don’t want to see any of those phony soft benefits included!” In economic terms, today’s optimal health informatics strate- gies lie somewhere between these two extremes. Healthcare systems everywhere are facing increased economic pressures; therefore, our informatics endeavors must recognize and adapt to these pressures.

Key Historic and Organizational Points

Before looking at some basic economic approaches and tools, we need to recognize several key historic and organizational points that strongly affect the economic strug- gles occurring within many of our healthcare organizations.

Information and Health Care Many healthcare organizations have been slow to realize just how critical information and its proper management are to the modern healthcare organization. As an example, hospitals in the United States typically spend 2 to 4 percent of their revenue on information systems, while organizations in other industries typically spend 5 to 15 percent. Even in the late 1980s, there were still a few hospitals in the United States that could not produce an itemized, computerized bill on demand—let alone a revised one.

While computerization has lagged behind other industries in the administrative areas it lags even further behind in the clinical areas. It is a general axiom of informatics that computers produce their greatest productivity benefits when they reach the hands of those on the “factory floor,” i.e., those people in the system who actually produce the organization’s goods or services.

Physicians—the historic driving force in the clinical area—have traditionally valued most highly the information they receive by word of mouth from other physicians. For a variety of reasons, many have been slow to utilize systems with significant potential for providing information in written form from alternative sources, and this has slowed the “factory floor” implementation.

LTF13 10/11/2004 8:57 AM Page 136

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

Weak Accounting Systems Quality decision making requires quality inputs. Many healthcare organizations have accounting and tracking systems that were never designed to provide sound cost and operational data. Systems have typically been designed to ensure fiduciary accounta- bility and meet mandatory billing and reporting requirements. To compound the problem, one of the biggest challenges for any complex organization is the accurate costing of diverse products and services. As a result, many healthcare organizations today cannot accurately determine whether they are making or losing money on par- ticular services.

The Pace of Change “But we just bought the one we have two years ago!” is often the complaint. Many decision makers have difficulty accepting the economic aspects of today’s rates of technological change—whether in informatics or in other health areas. Regardless of logic or economic analyses, these “bill payers” often have a negative visceral reaction to replacing an expensive physical unit that they still psychologically regard as new.

Historic Investment Benefits Many noninformatics managers, especially financially oriented ones, are disillusioned by the mediocre measurable benefits from the money that has been poured into the informatics area over the years. Where are the miracles we were led to expect? Stan- ford economic historian Paul David1 has explained this phenomenon. When major new technologies are introduced, they are first applied to the existing paradigms—organi- zational structures, market structures, legal frameworks, workforce skills, etc. The full benefits of a new technology are realized only as the total framework or paradigm slowly shifts to allow these benefits to take effect. At the same time, paradigm shifts might well not be possible without the new technology. The full benefits of informa- tion systems in our healthcare systems will accrue only after our healthcare systems have undergone massive transformations, which in turn cannot happen without these new information technologies. In health care, we are much closer to the beginning of these massive transformations than to the end.

Budgets As Power A joking remark about American males is, “He who dies with the most toys wins!” For living bureaucrats, the winner is often perceived as the manager with the biggest budget or the largest staff, the library with the most books, or the hospital with the most beds (or increasingly in the United States, the hospital with the most insured patients). Bigger is better; therefore, any technology promising that the job can be done with a smaller budget, less staff, fewer books, or fewer beds normally encounters resistance from everyone except the bean counters. For example, as the information function has become decentralized in recent years with the advent of distributed systems, many tra- ditional centralized data processing managers have stubbornly—and even bitterly— resisted a decrease in their direct budgetary power.

Introduction 137

LTF13 10/11/2004 8:57 AM Page 137

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

Cost-Benefit Analysis Regardless of what the process is called, virtually every informatics program or project must survive some form of cost-benefit analysis. What will this system cost? What will it do for us? Will the benefits to the entire organization exceed the cost and by how much? As with many management terms, there is no standardized definition of the term cost-benefit or of the analytical process. Twenty different organizations could perform such an analysis in twenty different ways. Despite these differences, we need to examine a few key points common to all cost-benefit analyses.

Analysis vs. Rationalization Organizational life becomes easier when we finally internalize the following observa- tions: Most organizational decisions are made at the emotional level, and logic is sub- sequently used to justify or rationalize them. Nevertheless, decision makers defend to their dying breaths the belief that decisions were made on a completely rational basis. As a result, cost-benefit analysis in many organizations has become cost-benefit ration- alization, “massaging” of the data until a desired outcome is obtained. We know that we need this new system, and we also know that our recommendation will be chal- lenged. Therefore, we will ensure that the cost-benefit data for the system appears very positive.

For example, one hospital chief executive fell in love with a particular informatics system he felt would give him national prominence if it were implemented. Despite the extremely questionable technology involved, the staff was charged with producing a study that would make the proposed system appear to be the answer to all their prob- lems—including some they didn’t even have! The chief executive then moved on to greener pastures, leaving the hospital with a glowing cost-benefit analysis in the files and the hospital staff saddled with a mediocre dead-end system.

This is not the way to run a quality organization, but it is all too common. Unfortu- nately, we may be forced at times by organizational pressures to “play the game.” Still we should always be clear in our own minds as to when we are analyzing and when we are rationalizing.

Hard vs. Soft Costs and Benefits In any significant cost-benefit analysis, we face the twin problems of measurability and uncertainty. Measurability refers to the difficulty in determining exact measures of eco- nomic value for subjective variables—especially on the benefits side—such as staff morale and improved quality of services. The terms hard and soft are often used to rep- resent the ends of the measurability spectrum. In addition, there is uncertainty, which refers to the difficulty in accurately predicting the values of variables that may be quite measurable after the fact, e.g., hardware costs 3 years in the future or just how many staff we will be expected to service the hardware 2 years from now.

Early health informatics implementations tended to be in the accounting area, paralleling the trend in other types of organizations. These early implementations appeared to have attractive levels of measurability and certainty: The processes to be computerized were highly structured and well known; there was typically only a small, disciplined group of users; and the benefits were typically predicted as definite mone- tary savings resulting from labor displacement, i.e., hard benefits. In reality, the costs

138 Section IV. Economics

LTF13 10/11/2004 8:57 AM Page 138

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

often overran estimates by huge amounts, and many of the cost savings were never realized. Still, viewed in advance, cost-benefit analyses in this era had an aura of “fiscal responsibility” about them that appealed to the bean counters.

As health informatics implementations move more into clinical areas, the traditional levels of measurability and predictability inevitably fall. How do we assess the eco- nomic value of various types of improvements in patient care? How do we predict all the direct and indirect costs that this complex implementation will ultimately incur? Dr. Michael Bourke2 also makes a parallel point for heavy investments in a technical infrastructure, e.g., a backbone network. This infrastructure investment may enable massive future progress in a wide variety of specific applications areas, but we may find it very difficult to measure and/or allocate its precise benefits. In Bourke’s terms, an investment with the lowest “directness of benefits” and “quantifiability of benefits” might well have the highest “potential impact of benefits.”

Probably the most neglected soft issue on both the cost and benefit sides is the time and/or inconvenience costs imposed on various groups coming into contact with the system. Time costs or inconveniences imposed on employees are often rationalized by saying, “That’s what they are paid for.” Costs to users or customers have also often been ignored. A classic example is the waiting time imposed on patients by many physi- cians who use atrocious, self-serving office scheduling models.

By this time, you might logically conclude that we view cost-benefit analysis as a useless tool. Not at all. What alternative do we have? We ultimately have to make a judgment as to whether a proposed step is worth more than it costs. Otherwise, we can simply resort to tossing a coin or using a Ouija board.

Realistic Cost-Benefit Judgments We must face the reality that our limited current financial technologies—coupled with the high uncertainties of a fast-changing world—dictate that our informatics cost- benefits analyses require managerial judgments. There are no techniques that can mechanically produce accurate numeric values and generate “automatic” decisions. We inevitably face a mass of data of widely varying quality that we try to organize as best we can into useful information. However, at some point we must tighten our belts and say yea or nay, with our decision based on much poorer information than we would like. It will always ultimately be a judgment call, given that some will be easier than others.

It is essential that we list in a subjective sense the wide variety of cost and benefit areas that we anticipate will be involved. This is typically quite impossible. The problem is to assign reasonable economic values or ranges of values to these cost-benefit impact areas. One process that can help in producing reasonable rough estimates is the mod- ified Delphi process described by Lorenzi and Riley3 in Organizational Aspects of Health Informatics. Group processes such as this can be very effective in assessing values in ill-structured, amorphous situations. Ultimately, we may have to feel or think that there will be a cost or benefit in some area but have no way to judge, estimate, or even guess its magnitude.

The true value of this overall process is often more in the reduction of subsequent unpleasant surprises than in the specific cost or benefit estimates developed. A Pandora’s box discovered and opened in the cost-benefit stage is far less dangerous than one discovered only at some later project implementation stage.

Introduction 139

LTF13 10/11/2004 8:57 AM Page 139

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

Lorenzi et al – 65-79
Lorenzi et al – 80-94
Lorenzi et al – 95-109
Lorenzi et al – 110 – 124
Lorenzi et al – 125 – 139

2/24/22, 12:48 PM Rubric Detail – Blackboard Learn

https://class.waldenu.edu/webapps/bbgs-deep-links-BBLEARN/app/course/rubric?course_id=_16936340_1&rubric_id=_2920725_1 1/5

Rubric Detail Select Grid View or List View to change the rubric's layout.

Excellent Good Fair Poor

Choose an evaluation model for application to selected case study, and compare to other applicable models.

23 (23%) – 25 (25%)

The response clearly identi�es the chosen evaluation model that is to be applied to the case study and includes several clearly and accurately described distinguishing characteristics of the model and how these characteristics relate to the environment and circumstances of the case study.

20 (20%) – 22 (22%)

The response identi�es the chosen evaluation model that is to be applied to the case study and includes some accurately described distinguishing characteristics of the model and how these characteristics relate to the environment and circumstances of the case study.

18 (18%) – 19 (19%)

The response identi�es the chosen evaluation model that is to be applied to the case study and includes a few distinguishing characteristics of the model, with some vague or inaccurate details about how these characteristics relate to the environment and circumstances of the case study.

0 (0%) – 17 (17%)

The response inaccurately or incompletely identi�es the chosen evaluation model that is to be applied to the case study and/or vaguely or inaccurately describes characteristics of the model, or provides vague or inaccurate details about how these characteristics relate to the environment and circumstances of the case study.

Name: NURS_6451_Week3_Assignment_Rubric EXIT

Grid View List View

2/24/22, 12:48 PM Rubric Detail – Blackboard Learn

https://class.waldenu.edu/webapps/bbgs-deep-links-BBLEARN/app/course/rubric?course_id=_16936340_1&rubric_id=_2920725_1 2/5

Excellent Good Fair Poor

In 2–3 pages, address the following:

Provide a brief, 1- to 2-paragraph summary of your selected case.

23 (23%) – 25 (25%)

The response clearly, accurately, and with speci�c detail sunmmarizes the selected case study.

20 (20%) – 22 (22%)

The response accurately summarizes the selected case study.

18 (18%) – 19 (19%)

The response summarizes the selected case study with a few vague and/or inaccurate details.

0 (0%) – 17 (17%)

The response summarizes the selected case study with important details that are omitted or presented in a vague and/or inaccurate manne

Describe the model selected for your evaluation of the case study you selected.

23 (23%) – 25 (25%)

The response clearly, accurately, and with speci�c detail describes the selected model for evaluation of the selected case study.

20 (20%) – 22 (22%)

The response accurately describes the selected model for evaluation of the selected case study.

18 (18%) – 19 (19%)

The response describes the selected model for evaluation of the selected case study with a few vague and/or inaccurate details.

0 (0%) – 17 (17%)

The response describes the selected model for evaluation of the selected case study with important details that are omitted or presented in a vague and/or inaccurate manner.

2/24/22, 12:48 PM Rubric Detail – Blackboard Learn

https://class.waldenu.edu/webapps/bbgs-deep-links-BBLEARN/app/course/rubric?course_id=_16936340_1&rubric_id=_2920725_1 3/5

Excellent Good Fair Poor

Justify your choice by comparing your selected model to at least three of the other models presented in this week’s reading.

9 (9%) – 10 (10%) The response clearly, accurately, and with speci�c detail justi�es the selected model by comparing the selected model to at least three of the other models presented in this week’s reading.

8 (8%) – 8 (8%) The response accurately justi�es the selected model by comparing the selected model to at least three of the other models presented in this week’s reading.

7 (7%) – 7 (7%) The response justi�es the selected model in a vague or inaccurate manner, and/or compares the selected model to fewer than three of the other models presented in this week’s reading.

0 (0%) – 6 (6%) The response justi�es the selected model in a vague or inaccurate manner, and/or compares the selected model to fewer than three of the other models presented in this week’s reading in a vague or inaccurate manner.

2/24/22, 12:48 PM Rubric Detail – Blackboard Learn

https://class.waldenu.edu/webapps/bbgs-deep-links-BBLEARN/app/course/rubric?course_id=_16936340_1&rubric_id=_2920725_1 4/5

Excellent Good Fair Poor

Written Expression and Formatting — Paragraph Development and Organization: Paragraphs make clear points that support well- developed ideas, �ow logically, and demonstrate continuity of ideas. Sentences are carefully focused—neither long and rambling nor short and lacking substance. A clear and comprehensive purpose statement and introduction are provided that delineate all required criteria.

5 (5%) – 5 (5%) Paragraphs and sentences follow writing standards for �ow, continuity, and clarity.

A clear and comprehensive purpose statement, introduction, and conclusion are provided that delineate all required criteria.

4 (4%) – 4 (4%) Paragraphs and sentences follow writing standards for �ow, continuity, and clarity 80% of the time.

Purpose, introduction, and conclusion of the assignment are stated, yet are brief and not descriptive.

3 (3%) – 3 (3%) Paragraphs and sentences follow writing standards for �ow, continuity, and clarity 60%–79% of the time.

Purpose, introduction, and conclusion of the assignment are vague or o� topic.

0 (0%) – 2 (2%) Paragraphs and sentences follow writing standards for �ow, continuity, and clarity < 60% of the time.

No purpose statement, introduction, or conclusion were provided.

Written Expression and Formatting — English Writing Standards:

Correct grammar, mechanics, and proper punctuation

5 (5%) – 5 (5%) Uses correct grammar, spelling, and punctuation with no errors.

4 (4%) – 4 (4%) Contains a few (1 or 2) grammar, spelling, and punctuation errors.

3 (3%) – 3 (3%) Contains several (3 or 4) grammar, spelling, and punctuation errors.

0 (0%) – 2 (2%) Contains many (≥ 5) grammar, spelling, and punctuation errors that interfere with the reader’s understanding.

2/24/22, 12:48 PM Rubric Detail – Blackboard Learn

https://class.waldenu.edu/webapps/bbgs-deep-links-BBLEARN/app/course/rubric?course_id=_16936340_1&rubric_id=_2920725_1 5/5

Excellent Good Fair Poor

Written Expression and Formatting — The paper follows correct APA format for title page, headings, font, spacing, margins, indentations, page numbers, running heads, parenthetical/in- text citations, and reference list.

5 (5%) – 5 (5%) Uses correct APA format with no errors.

4 (4%) – 4 (4%) Contains a few (1 or 2) APA format errors.

3 (3%) – 3 (3%) Contains several (3 or 4) APA format errors.

0 (0%) – 2 (2%) Contains many (≥ 5) APA format errors.

Total Points: 100

Name: NURS_6451_Week3_Assignment_Rubric

EXIT

Evaluation Plan Project: a Case Study and Model

Having Trouble Meeting Your Deadline?

Order a similar assignment, and have writers from our team of experts write it for you, guaranteeing you an A

AGREE Project

Being Prepared: Impact of Disaster, Terrorism, and War

Social Determinant Assignment

Study Daily

Nursing leadership

Biostatistics Homework

Payments

QUICK LINKS

Discover

Help

Having Trouble Meeting Your Deadline?

Order a similar assignment, and have writers from our team of experts write it for you, guaranteeing you an A

Similar Posts

Payments

QUICK LINKS

Discover

Help

Get in touch