CHAPTER 8
System Implementation and Support

Once a health care organization has finalized its contract with the vendor to acquire an information system, the system implementation process begins. Selecting the right system does not ensure user acceptance and success; the system must also be incorporated effectively into the day-to-day operations of the health care organization and adequately supported or maintained. Whether the system is built in-house, designed by an outside consultant, leased from an application service provider (ASP), or purchased from a vendor, it will take a substantial amount of planning and work to get the system up and running smoothly and integrated into operations.

This chapter focuses on the two final stages of the system development life cycle: implementation and then support and evaluation. It describes the planning and activities that should occur when implementing a new system. Our discussion focuses on a vendor-acquired system; however, many of the activities described also apply to systems designed in-house or by an outside developer or acquired through an ASP.

Implementing a new system (or replacing an old system) can be a massive undertaking for a health care organization. Not only are there workstations to install, databases to build, and networks to test but there are also processes to redesign, users to train, data to convert, and procedures to write. There are countless tasks and details that must be appropriately coordinated and completed if the system is to be implemented on time and within budget—and widely accepted by users. Essential to the process is ensuring that the introduction of any new health care information system or workflow change results in improved organizational performance, such as a reduction in medication errors, an improvement in care coordination, and more effective utilization of tests and procedures.

Recently concerns have been raised about the potential for EHRs to result in risk to patient safety. Health care information systems such as EHRs are enormously complex and involve not only the technology (hardware and software), but people, processes, workflow, organizational culture, politics, and the external environment (licensure, accreditation, regulatory agencies). The Institute of Medicine recently published a report that offers health care organizations and vendors suggestions on how to work collaboratively to make health IT safer (IOM, 2011). Poor user-interface designs, ineffective workflow, and lack of interoperability are all considered threats to patient safety. Several of the suggested strategies for ensuring system safety are discussed in this chapter.

Along with attending to the many activities or tasks associated with system implementation, it is equally important to address organizational and behavioral issues. Studies have shown that over half of all information system projects fail. Numerous political, cultural, behavioral, and ethical factors can affect the successful implementation and use of the new system (Ash, Anderson, & Tarczy-Hornoch, 2008; Ash et al., 2007; Sittig & Singh, 2011). We devote a section of this chapter to the organizational and behavioral issues that can arise and other things that can go wrong during the system implementation process and offer strategies for avoiding these problems. The chapter concludes by describing the importance of supporting and maintaining information systems.

SYSTEM IMPLEMENTATION PROCESS

System implementation begins once the organization has acquired the system and continues through the early stages following the go-live date (the date when the system is put into general use for everyone). Like the system acquisition process, the system implementation process must have a high degree of support from the senior executive team and be viewed as an organizational priority. Sufficient staff, time, and resources must be devoted to the project. Individuals involved in rolling out the new system should have sufficient resources available to them to ensure a smooth transition.

The time and resources needed to implement a new health care information system can vary considerably depending on the scope of the project, the needs and complexity of the organization, the number of applications being installed, and the number of user groups involved. There are, however, some fundamental activities that should occur during any system implementation, regardless of its size or scope:

  • Organize the implementation team and identify a system champion.
  • Determine project scope and expectations.
  • Establish and institute a project plan.

Failing to appropriately plan for and manage these activities can lead to cost overruns, dissatisfied users, project delays, and even system sabotage. In today’s environment, where capital is scarce and resources are limited, health care organizations cannot afford to mismanage implementation projects of this magnitude and importance.

Organize the Team and Identify a Champion

One of the first steps in planning for the implementation of a new system is to organize an implementation team. The primary role and function of the team is to plan, coordinate, budget, and manage all aspects of the new system implementation. Although the exact team composition will depend on the scope and nature of the new system, a team might include a project leader, system champion(s), key individuals from the clinical and administrative areas that are the focus of the system being acquired, vendor representatives, and information technology (IT) professionals (Figure 8.1). For large or complex projects, it is also a good idea to have someone skilled in project management principles on the team. Likewise, having a strong project leader and the right mix of people is critically important.

c8-fig-0001

Figure 8.1. Sample composition of implementation team

Implementation teams often include some of the same people involved in selecting the system; however, they may also include other individuals with knowledge and skills important to the successful deployment of the new system. For example, the implementation team will likely need at least one IT professional with technical database and network administration expertise. This person may have had some role in the selection process but is now being called on to assume a larger role in installing the software, setting up the data tables, and customizing the network infrastructure to adequately support the system and the organization’s needs.

The implementation team should also include at least one system champion. A system champion is someone who is well respected in the organization, sees the new system as necessary to the organization’s achievement of its strategic goals, and is passionate about implementing it. In many health care settings the system champion is a physician, particularly when the organization is implementing a system that will directly or indirectly affect how physicians spend their time. The physician champion serves as an advocate of the system, assumes a leadership role in gaining buy-in from other physicians and user groups, and makes sure that physicians have adequate input into the decision-making process. Other important qualities of system champions are strong communication, interpersonal, and listening skills. The system champion should be willing to assist with pilot testing, to train and coach others, and to build consensus among user groups (Miller & Sim, 2004). Numerous studies have demonstrated the importance of the system champion throughout the implementation process (Ash, Stavri, Dykstra, & Fournier, 2003; Miller, Sim, & Newman, 2003; Wager, Lee, White, Ward, & Ornstein, 2000; Yackanicz, Kerr, & Levick, 2010). When implementing clinical applications (such as computerized provider order entry [CPOE] or medication administration using bar coding) that span numerous clinical areas, such as nursing, pharmacy, and physicians, having a system champion from each division can be enormously helpful in gaining buy-in and in facilitating communication among staff. The various system champions can also assume a pivotal role in ensuring that project milestones are achieved and celebrated.

Determine Project Scope and Expectations

One of the implementation team’s first items of business is to determine the scope of the project and what the organization hopes the project will achieve. To set the tone for the project, a senior health care executive should meet with the implementation team to communicate how the project relates to the organization’s overall strategic goals and to assure the team of administration’s commitment to the project.

The goals of the project and what the organization hopes to achieve by implementing the new system should emerge from early team discussions. The system goals defined during the system selection process (discussed in Chapter Seven) should be reviewed by the implementation team. Far too often health care organizations skip this important step and never clearly define the scope of the project or what they hope to gain as a result of the new system. At other times they define the scope of the project too broadly or scope creep occurs. The goals should be specific, measurable, attainable, relevant, and time bound (www.healthit.gov/providers-professionals/ehr-implementation-steps/step-1-assess-your-practice-readiness). They should also define the organization’s criteria for success.

Let’s look at two hypothetical examples, from two providers that we will call Mason Hospital and St. Luke’s Medical Center. The implementation team at Mason Hospital defined its goal and the scope of the project and devised measures for evaluating the extent to which the hospital achieved this goal. The implementation team at St. Luke’s Medical Center was responsible for completing phase 1 of a three-part project; however, the scope of the team’s work was never clearly defined.

Establish and Institute a Project Plan

Once the implementation team has agreed on its goals and objectives, the next major step is to develop and implement a project plan. The project plan should have the following components:

  • Major activities (also called tasks)
  • Major milestones
  • Estimated duration of each activity
  • Any dependencies among activities (so that, for example, one task must be completed before another can begin)
  • Resources and budget available (including staff whose time will be allocated to the project)
  • Individuals or team members responsible for completing each activity
  • Target dates
  • Measures for evaluating completion and success

These are the same components one would find in most major projects. What are the major activities, or tasks, that are unique to system implementation projects? Which tasks must be completed first, second, and so forth? How should time estimates be determined and milestones defined?

System implementation projects tend to be quite large, and therefore it can be helpful to break the project into manageable components. One approach to defining components is to have the implementation team brainstorm and identify the major activities that need to be done before the go-live date. Once these tasks have been identified, they can be grouped and sequenced based on what must be done first, second, and so forth. Those tasks that can occur concurrently should also be identified. A team may find it helpful to use a consultant to guide it through the implementation process. Or the health care IT vendor may have a suggested implementation plan; the team must make sure, however, that this plan is tailored to suit the unique needs of the organization in which the new system is to be introduced.

The subsequent sections describe the major activities common to most information system implementation projects (outlined in the following list) and may serve as a guide. These activities are not necessarily in sequential order; the order used should be determined by the institution in accordance with its needs and resources.

Typical Components of an Implementation Plan
  1. Workflow and process analysis
    • Analyze or evaluate current process and procedures.
    • Identify opportunities for improvement and, as appropriate, effect those changes.
    • Identify sources of data, including interfaces to other systems.
    • Determine location and number of workstations needed.
    • Redesign physical location as needed.
  2. System installation
    • Determine system configuration.
    • Order and install hardware.
    • Prepare data center.
    • Upgrade or implement IT infrastructure.
    • Install software and interfaces.
    • Customize software.
    • Test, retest, and test again …
  3. Staff training
    • Identify appropriate training method(s) to be used for each major user group.
    • Prepare training materials.
    • Train staff.
    • Test staff proficiency.
    • Update procedure manuals.
  4. Conversion
    • Convert data.
    • Test system.
  5. Communications
    • Establish communication mechanisms for identifying and addressing problems and concerns.
    • Communicate regularly with various constituent groups.
  6. Preparation for go-live date
    • Select date when patient volume is relatively low.
    • Ensure sufficient staff are on hand.
    • Set up mechanism for reporting and correcting problems and issues.
    • Review and effect process reengineering.
  7. System downtime procedures
    • Develop downtime procedures.
    • Train staff on downtime procedures.

Conduct Workflow and Process Analysis

One of the first activities necessary in implementing any new system is to review and evaluate the existing workflow or business processes. Members of the implementation team might also observe the current information system in use (if there is one). Does it work as described? Where are the problem areas? What are the goals and expectations of the new system? How do organizational processes need to change in order to optimize the new system’s value and achieve its goals? Too often organizations never critically evaluate current business processes but plunge forward implementing the new system while still using old procedures. The result is that they simply automate their outdated and inefficient processes.

Before implementing any new system, the organization should evaluate existing procedures and processes and identify ways to improve workflow, simplify tasks, eliminate redundancy, improve quality, and improve user (customer) satisfaction. Although describing them is beyond the scope of this book, many extremely useful tools and methods are available for analyzing workflow and redesigning business processes (see, for example, Guide to Reducing Unintended Consequences of Electronic Health Records, by Jones et al., 2011). Observing the old system in use, listening to users’ concerns, and evaluating information workflow can identify many of the changes needed. In addition, the vendor generally works with the organization to map its future workflow using flowcharts or flow diagrams. It is critical that all key areas affected by the new system participate in the workflow analysis process so that potential problems can be identified and addressed before the system goes live. For example, if a new CPOE application is to be implemented using a phased-in approach, where the system will go live unit by unit over a three-month process, how will the organization ensure orders are not lost or duplicated if a patient is transferred between a unit using CPOE and a unit using handwritten orders? What will downtime procedures entail? If paper orders are generated during downtime, how will these orders be stored or become part of the patient’s permanent medical record?

Involving users at this early stage of the implementation process can gain initial buy-in to both the idea and the scope of the process redesign. In all likelihood, the organization will need to institute a series of process changes as a result of the new system. Workflow and processes should be evaluated critically and redesigned as needed. For example, the organization may find that it needs to do away with old forms or work steps, change job descriptions or job responsibilities, or add to or subtract from the work responsibilities of particular departments. Getting users involved in this reengineering process can lead to greater user acceptance of the new system.

Let’s consider an example. Suppose a multiphysician clinic is implementing a new practice management system that includes a patient portal for appointment scheduling, prescription refills, and paying bills. The clinic might wish to begin by appointing a small team of individuals knowledgeable about analyzing workflow and processes to work with staff in studying the existing process for scheduling patient appointments, refilling prescriptions, and patient billing. This team might conduct a series of individual focus groups with schedulers, physicians and nurses, and patients, and ask questions such as these:

  • Who can schedule patient appointments?
  • How are patient appointments made, updated, or deleted?
  • Who has access to scheduling information? From what locations?
  • How well does the current system work? How efficient is the process?
  • What are the major problems with the current scheduling system and process? In what ways might it be improved?

The team should tailor the focus questions so they are appropriate for each user group. The answers can then be a guide for reengineering existing processes and workflow to facilitate the new system. A similar set of questions could be asked concerning the refill of prescriptions or patient billing processes.

During the workflow analysis, the team should also examine where the new system’s actual workstations will be located, how many workstations will be needed, and how information will flow between manual organizational processes (such as phone calls) and the electronic information system. Here are a few of the many questions that should be addressed in ensuring that physical layouts are conducive to the success of the new system:

  • Will the workstations be portable or fixed? If users are given portable units, how will these be tracked and maintained (and protected from loss or theft)? If workstations are fixed, will they be located in safe, secure areas where patient confidentiality can be maintained?
  • How will the user interact with the new system?
  • Does the physical layout of each work area need to be redesigned to accommodate the new system and the new process?
  • Will additional wiring be needed?
  • How will the new system affect the workflow within the practice among office staff, nurses, and physicians?
  • Will the e-prescribing function with local pharmacies be affected by the change?

Install System Components

The next step, which may be done concurrently with the workflow analysis, is to install the hardware, software, and network infrastructure to support the new information system and build the necessary interfaces. IT staff play a crucial role in this phase of the project. They will need to work closely with the vendor in determining system specifications and configurations and in preparing the computer center for installation. It may be, for example, that the organization’s current computer network will need to be replaced or upgraded. During implementation, having adequate numbers of computer workstations placed in readily accessible locations is critical. Those involved in the planning need to determine beforehand the maximum number of individuals likely to be using the system at the same time, and accommodate this scenario. Vendors may recommend a certain number of workstations or use of hand-held devices; however, the organization must ensure the recommendations are appropriate.

Typically when a health care organization acquires a system from a vendor, quite a bit of customization is needed. IT personnel will likely work with the vendor in setting up and loading data tables, building interfaces, and running pilot tests of the hardware and software using actual patient and administrative data. It is not unlikely when purchasing a CPOE product from a vendor, for example, that the health care organization is provided a “shell” or basic framework from which to build the order sets or electronic forms. A great deal of customization and building of templates occurs. Thus, it is a good idea to pay physicians for their time involved in the project. For instance, if you need a physician’s time to assist in building or reviewing order sets for the cardiology division, factor that into the resources needed for the project, perhaps by allocating two hours per week to the project for a certain period of time. Otherwise, you may be pulling physicians away from seeing patients and revenue-generating activities. It demonstrates the value placed on the physician’s time and commitment to the project.

We recommend piloting the system in a unit or area before rolling out the system enterprise-wide. This test enables the implementation team to evaluate the system’s effectiveness, address issues and concerns, fix bugs, and then apply the lessons learned to other units in the organization before most people even start using the system.

Consideration should be given to choosing an appropriate area (for example, a department or a location) or set of users to pilot the system. Some of the questions the implementation team should consider in identifying potential pilot sites are these:

  • Which units or areas are willing and equipped to serve as a pilot site? Do they have sufficient interest, administrative support, and commitment?
  • Are the staff and management teams in each of these units or areas comfortable with being system “guinea pigs”?
  • Do staff have the time and resources needed to serve in this capacity?
  • Is there a system champion in each unit or area who will lead the effort?

Plan, Conduct, and Evaluate Staff Training

Training is an essential component of any new system implementation. Although no one would argue with this statement, the implementation team will want to consider many issues as it develops and implements a training program. Here are a few of the questions to be answered:

  • How much training is needed? Do different user groups have different training needs?
  • Who should conduct the training?
  • When should the training occur? What intervals of training are ideal?
  • What training format is best—for example, formal, classroom-style training; one-on-one or small-group training; computer-based training; or a combination of methods?
  • What is the role of the vendor in training?
  • Who in the organization will manage or oversee the training? How will training be documented?
  • What criteria and methods will be used to monitor training and ensure that staff are adequately trained? Will staff be tested on proficiency?
  • What additional training and support are available to physicians and others after go-live?

There are various methods of training. One approach, commonly known as train the trainer, relies on the vendor to train selected members of the organization who will then serve as super-users and train others in their respective departments, units, or areas. These super-users should be individuals who work directly in the areas in which the system is to be used; they should know the staff in the area and have a good rapport with them. They will also serve as resources to other users once the vendor representatives have left. They may do a lot of one-on-one training, hand-holding, and other work with people in their areas until these individuals achieve a certain comfort level with the system. The main concern with this approach is that the organization may devote a great deal of time and resources to training the trainers only to have these trainers leave the institution (often because they’ve been lured away by career opportunities with the vendor).

Another method is to have the vendor train a pool of trainers who are knowledgeable about the entire system and who can rotate through the different areas of the organization working with staff. The trainer pool might include both IT professionals (including clinical analysts) and clinical or administrative staff such as nurses, physicians, lab managers, and business managers.

Regardless of who conducts the training, it is important to introduce fundamental or basic concepts first and allow people to master these concepts before moving on to new ones. Studies among health care organizations that have implemented clinical applications such as CPOE systems have shown that classroom training is not nearly as effective as one-on-one coaching, particularly among physicians (Holden, 2011; Metzger & Fortin, 2003). Most systems can track physician usage; physicians identified as low-volume users may be targeted for additional training.

Timing of the training is also important. Users should have ample opportunity to practice before the system goes live. For instance, when a nursing documentation system is being installed, nurses should have the chance to practice with it at the bedside of a typical patient. Likewise, when a CPOE system is going in, physicians should get to practice ordering a set of tests during their morning rounds. This just-in-time training might occur several times: for example, three months, two months, one month, and one week before the go-live date. Training might be supplemented with computer-based training modules that enable users to review concepts and functions at their own pace. Training has to be a priority and at least some of training should be in an environment free of distractions. Eventually staff will want to use the system in a “near live” or simulated environment. Additional staff should be on hand during the go-live period to assist users as needed during the transition to the new system. In general, the implementation team should work with the vendor to produce a thoughtful and creative training program.

Once the details of how the new system is to work have been determined, it is important to update procedure manuals and make the updated manuals available to the staff. Designated managers or representatives from the various areas may assume a leadership role in updating procedure manuals for their respective areas. When people must learn specific IT procedures such as how to log in, change passwords, and read common error messages, the IT department should ensure that this information appears in the procedure manuals and that the information is routinely updated and widely disseminated to the users. Procedure manuals serve as reference guides and resources for users and can be particularly useful when training new employees.

Effective training is important. Staff members need to be relatively comfortable with the application and need to know to whom they should turn if they have questions or concerns. We recommend having the users evaluate the training prior to go-live.

Convert Data and Test System

Another important task is to convert the data from the old system to the new system and then adequately test the new system. Staff involved in the data conversion must determine the sources of the data required for the new system and construct new files. It is particularly important that data be complete, accurate, and current before being converted to the new system. Data should be cleaned before being converted. Once converted, the data should run through a series of validation checkpoints or procedures to ensure the accuracy of the conversion.

IT staff knowledgeable in data conversion procedures should lead the effort and verify the results with key managers from the appropriate clinical and administrative areas. The specific conversion procedures used will depend on the nature of the old system and its structure as well as on the configuration of the new system.

Finally, the new system will need to be tested. The main purpose of the testing is to simulate the live environment as closely as possible and determine how well the system and accompanying procedures work. Are there pro­gramming glitches or other problems that need to be fixed? How well are the interfaces working? How does response time compare to what was expected? The system should be populated with live data and tested again. Vendors, IT staff, and user staff should all participate in the testing process. As with training, one can never test too much. A good portion of this work has to be done for the pilot testing. It may need to be repeated before going live. And the pilot lessons will guide any additional testing or conversion that needs to be done. In some cases, it may be advisable to run the old and new systems in tandem (parallel conversion) for a period of time until it is evident that the new system is operating effectively. This can reduce organizational risk. However, running parallel systems is not always feasible or appropriate. Instead, organizations may opt to implement the system using a phased approach over a period of time.

Communicate Progress or Status

Equally as important as successfully carrying out the activities discussed so far is having an effective plan for communicating the project’s progress. This plan serves two primary purposes. First, it identifies how the members of the implementation team will communicate and coordinate their activities and progress. Second, it defines how progress will be communicated to key constituent groups, including but not limited to the board, the senior administrative team, the departments, and the staff at all levels of the organization affected by the new system. The communication plan may set up both formal and informal mechanisms. Formal communication may include everything from regular updates at board and administrative meetings to written briefings and articles in the facility newsletter. The purpose should be to use as many channels and mechanisms as possible to ensure that the people who need to know are fully informed and aware of the implementation plans. Informal communication is less structured but can be equally important. Implementing a new health care information system is a major undertaking, and it is important that all staff (day, evening, and night shifts) be made aware of what is happening. The methods for communication may be varied, but the message should be consistent and the information presented up-to-date and timely. For example, do not rely on e-mail communication as your primary method only to discover later that your organization’s nurses do not regularly check their e-mail or have little time to read your type of message.

Prepare for Go-Live Date

A great deal of work goes into preparing for the go-live date, the day the organization transitions from the old system to the new. Assuming the implementation team has done all it can to ensure that the system is ready, the staff are well trained, and appropriate procedures are in place, the transition should be a smooth one. Additional staff should be on hand and equipped to assist users as needed. It is best to plan for the system to go live on a day when the patient census is typically low or fewer patients than usual are scheduled to be seen. Disaster recovery plans should also be in place, and staff should be well trained on what to do should the system go down or fail. Designated IT staff should monitor and assess system problems and errors.

When organizations are implementing information systems with clinical decision support, we recommend that they adhere to these “ten commandments” for effective clinical decision support.

Ten Commandments for Effective Clinical Decision Support
  • Speed is everything—this is what information system users value most.
  • Anticipate needs and deliver in real time—deliver information when needed.
  • Fit into user’s work flow—integrate suggestions with clinical practice.
  • Little things can make a big difference—improve usability to “do the right thing.”
  • Recognize that physicians will resist stopping—offer alternatives rather than insist on stopping an action.
  • Changing direction is easier than stopping—changing defaults for dose, route, or frequency of a medication can change behavior.
  • Simple interventions work best—simplify guidelines by reducing to a single computer screen.
  • Ask for additional information only when you really need it—the more data elements requested, the less likely a guideline will be implemented.
  • Monitor impact, get feedback and respond—if certain reminders are not followed, readjust or eliminate the reminder.
  • Manage and maintain your knowledge-based systems—track users’ response to decision support and update to coincide with changes in medical knowledge [Bates et al., 2003].

A great deal of planning and leadership is needed in implementing a new health care information system. Despite the best-made plans, however, things can and do go wrong. The next section describes some of the unintended consequences and common organizational challenges associated with system implementation projects and offers strategies for anticipating and planning for them.

Develop and Communicate Downtime Procedures

One thing that you can count on is that systems will go down. Both scheduled and unscheduled downtime exists, and downtime procedures need to be developed and communicated well before go-live. Hopefully, the organization has invested in a stable and secure technical IT infrastructure and backup procedures and fail-safe systems are in place. But everyone needs to know what to do if the system is down, from the registration staff to the nursing staff to the medical staff and the transport team. How will orders be placed? If a paper record is kept during downtime, what is the procedure for getting the documentation in electronic form when the system is up again? How will scheduled downtime be communicated to units? And all staff members? If an organization relies heavily on computerized systems to care for patients, downtime should be minimal or near 0 percent. However, business continuity procedures must be in place to ensure patient safety and continuity of care.

MANAGING THE ORGANIZATIONAL ASPECTS

Implementing an information system in a health care facility can have a profound impact on the organization, the people who work there, and the patients they serve. Individuals may have concerns and apprehensions about the new system. They may wonder: How will the new system affect my job responsibilities or productivity? How will my workload change? Will the new system cause me more or less stress? Even individuals who welcome the new system, see the need for it, and see its potential value may worry: What will I do if the system is down? Will the system impede my relationship with my patients? Who will I turn to if I have problems or questions? Will I be expected to type my notes into the system? With the new system comes change, and change can be difficult if not managed effectively.

The human factors associated with implementing a new system should not be taken lightly. A great deal of change can occur as a result of the new system. Some of the changes may be immediately apparent; others may occur over time as the system is used more fully. Many IT implementation studies have been done in recent years, and they reveal several strategies that may lead to greater organizational acceptance and use of a new system:

More research is needed to explore the extent to which these and other strategies can lead to more widespread adoption of health care information systems, particularly clinical applications such as the CPOE and EHR systems.

Create an Appropriate Environment

If you ask a roomful of health care executives, physicians, nurses, pharmacists, or laboratory managers if they have ever experienced an IT system failure, chances are over half of the hands in the room will go up. In all likelihood the people in the room would have a much easier time describing a system failure than a system success. If you probed a little further and asked why the system was a failure, you might hear comments like these: “the system was too slow,” “it was down all the time,” “training was inadequate and nothing like the real thing,” “there was no one to go to if you had questions or concerns,” “it added to my stress and workload,” and the list goes on. The fact is, the system did not meet their expectations. You might not know whether those expectations were reasonable or not.

Earlier we discussed the importance of clearly defining and communicating the goals and objectives of the new system. Related to goal definition is the management of user expectations. Different people may have different perspectives on what they expect from the new system; in addition, some will admit to having no expectations, and others will have joined the organization after the system was implemented and consequently are likely to have expectations derived from the people currently using the system.

Expectations come from what people see and hear about the system and the way they interpret what the system will do for them or for their organization. Expectations can be formed from a variety of sources—they may come from a comment made during a vendor presentation, a question that arises during training, a visit to another site that uses the same system, attendance at a professional conference, or a remark made by a colleague in the hallway.

Furthermore, the main criterion used to evaluate the system’s value or success depends on the individual’s expectations and point of view. For example, the chief financial officer might measure system success in terms of the financial return on investment, the chief medical director might look at impact on physicians’ time and quality of care, the nursing staff might consider any change in their workload, public relations personnel might compare levels of patient satisfaction, and the IT staff might evaluate the change in the number of help desk calls made since the new system was implemented. All these approaches are measures of an information system’s perceived impact on the organization or individual. However, they are not all the same, and they may not have equal importance to the organization in achieving its strategic goals.

It is therefore important for the health care executive team not only to establish and communicate clearly defined goals for the new system but also to listen to needs and expectations of the various user groups and to define, meet, and manage expectations appropriately. Ways to manage expectations include making sure users understand that the first days or weeks of system use may be rocky, that the organization may need time to adjust to a new workflow, that the technology may have bugs, and that users should not expect problem-free system operation from the start. Clear and effective communication is key in this endeavor.

In managing expectations it can be enormously helpful to conduct formative assessments of the implementation process, in which the focus is on the process as well as the outcomes. Specific metrics need to be chosen and success criteria defined to determine whether or not the system is meeting expectations (Cusack & Poon, 2011). For example, if wide-scale usage is a priority, collection of actual numbers of transactions or usage logs may be meaningful information for the leadership team. Other categories of metrics that might be helpful are clinical outcome measures, clinical process measures, provider adoption and attitude measures, patient knowledge and attitude measures, workflow impact measures, and financial impact measures. The Agency for Healthcare Research and Quality recently published the third edition of the Health Information Exchange Evaluation Toolkit, which can serve as a guide for project teams involved in evaluating the system implementation process or project outcomes (Cusack & Poon, 2011).

Know Your Culture and Do Not Underestimate User Resistance

Before embarking on system implementation, it is critical to know your culture. Understanding the culture is important before you make the investment. For example, you might ask, How engaged and ready are the physicians and other clinicians for the new system? Are they comfortable with technology? Do you have hospitalists on staff? Or are you a community hospital where the bulk of your medical staff are physicians who have admitting privileges at several hospitals and make rounds only once a day? How engaged have the physicians been in the design and build of the new system? Is there strong support? If you don’t have sufficient medical staff buy-in and support or hospitalists on staff who are committed to the project, you run the risk of encountering user resistance and system failure due to inadequate use.

During the implementation process it is also important to analyze current workflow and make appropriate changes as needed. Earlier we gave an example of analyzing a patient scheduling process. Patient scheduling is a relatively straightforward process. A change in this system may not dramatically change the job responsibilities of the schedulers and may have little impact on nurses’ or physicians’ time. Therefore, these groups may offer little resistance to such a change. (This is not to guarantee a lack of resistance—if you mess up a practice’s schedule, you can have a lot of angry people on your hands!) In contrast, changes in processes that involve the direct provision of patient care services and that do affect nurses’ and physicians’ time may be tougher for users to accept. The physician ordering process is a perfect example. Most physicians today are accustomed to picking up a pen and paper and handwriting an order or calling one in to the nurses’ station from their phones. With CPOE, physicians may be expected to keyboard their orders directly into the system and respond to automated reminders and decision-support alerts. A process that historically took them a few seconds to do might now take several minutes, depending on the number of prompts and reminders. Moreover, physicians are now doing things that were not asked of them before—they are checking for drug interactions, responding to reminders and alerts, evaluating whether evidence-based clinical guidelines apply to the patient, and the list goes on. All these activities take time, but in the long run they will improve the quality of patient care. Therefore, it is important for physicians to be actively involved in designing the process and in seeing its value to the patient care process.

Getting physicians, nurses, and other clinicians to accept and use clinical information systems such as CPOE or EHR can be challenging even when they are involved in the implementation. At times the incentives for using the system may not be aligned with their individual needs and goals. On the one hand, for example, if the physician is expected to see a certain number of patients per day and is evaluated on patient load and if writing orders used to take thirty minutes a day with the old system and now takes sixty to ninety minutes with the new CPOE system, the physician can either see fewer patients or work more hours. One should expect to see physician resistance. On the other hand, if the physician’s performance and income is related to adherence to clinical practice guidelines, using the CPOE system might improve his or her income, creating a greater chance of acceptance.

The physician’s workload or productivity goals might, however, be beyond the organization’s control. They might be individual goals the physician has set for himself or herself. Can or should organizations mandate the use of clinical information systems like CPOE? In effect, the organization is stating that resistance is unacceptable. Several health care facilities have instituted policies mandating physician use of CPOE, with mixed results. Physicians’ acceptance of such a mandate may have a lot to do with the organizational culture, the training they received, their confidence (or lack of confidence) in the system, how the mandate was imposed, and a host of other factors. Mandating use is most common in academic medical centers where residents and fellows are expected to enter orders in a computerized system (Sklarin, Granovsky, & Hagerty-Paglia, 2011). Mandating physician use can be taxing for community hospitals or other facilities that are not the physicians’ employers. Community-based physicians often see patients at more than one hospital and spend limited time at each facility. Trying to get these fairly independent physicians to buy into a facility’s CPOE system and participate in the necessary training can be difficult.

To address this and related acceptance issues, the California HealthCare Foundation, in collaboration with First Consulting Group, conducted an in-depth study of ten community hospitals throughout the United States that have made significant progress in implementing CPOE (Metzger & Fortin, 2003). The study found that CPOE leaders tended to avoid the term man­date and instead recommended that health care executives work toward an enterprise-wide policy for universal CPOE. Key staff in participating hospitals recommended starting with a strong commitment to CPOE, delivering a consistent message that CPOE is the right thing to do, and working within the culture of the medical staff toward the goal of universal adoption. This goal might take years to achieve. Readiness for universal adoption occurred when (1) a significant number of physician CPOE adopters showed their peers what was possible, (2) sufficient progress was made toward achieving patient safety objectives, and (3) the medical staff came together with one voice to champion CPOE as the right thing to do.

It perhaps goes without saying that user acceptance occurs when users see or realize the value the health care information system brings to their work and the patients they serve. This value takes different forms. Some people may realize increased efficiency, less stress, greater organization, and improved quality of information, whereas others may find that the system enables them to provide better care, avoid medical mistakes, and make better decisions. In some cases an individual may not experience the value personally yet may come to realize the value to the organization as a whole.

Allocate Sufficient Resources

Sufficient resources are needed both during and after the new system has been implemented. User acceptance comes from confidence in the new system. Individuals want to know that the system works properly, is stable, and is secure and that someone is available to help them when they have questions, problems, or concerns. Therefore, it is important for the organization to ensure that adequate resources are devoted to implementing and supporting the system and its users. At a minimum, adequate technical staff expertise should be available as well as sufficient IT infrastructure.

We have discussed the importance of giving the implementation team sufficient support as it carries out its charge, but what forms can this support take? Some methods of supporting the team are to make available release time, additional staff, and development funds. Senior managers might allocate travel funds so team members can view the system in use in other facilities. They might decide that all implementation team members or super-users will receive 50 percent release time for the next six months to devote to the project. This release time will enable those involved to give up some of their normal job duties so they can focus on the project. Senior leaders at one health care organization in South Carolina gave sixty-four full-time staff release time for one year to devote to the implementation of a facility-wide health information system. This substantial amount of release time was indicative of the high value the executive team members placed on the project. They saw it as critical to achieving the organization’s strategic goals.

Providing sufficient time and resources to the implementation phase of the project is, however, only part of the overall support needed. Studies have shown that an information system’s value to the organization is typically realized over time. Value is derived as more and more people use the system, offer suggestions for enhancing it, and begin to push the system to fulfill its functionality. If users are ever to fully realize the system’s value, they must have access to local technical support—someone, preferably within the organization, who is readily available, is knowledgeable about the intricacies of the system, and is able to handle both hardware and software problems. This individual should be able to work effectively with the vendor and others to find solutions to system problems. Even though it is ideal to have local tech­nical support in-house, that may be difficult in small physician offices or community-based settings. In such cases the facility may need to consider such options as (1) devoting a significant portion of an employee’s time to training so that he or she may assume a support role, (2) partnering with a neighboring organization that uses the same system to share technical support staff, or (3) contracting with a local computer firm to provide the needed assistance. The vendor may be able to assist the organization in identifying and securing local technical support.

On busy nursing units, it can be extremely helpful to have nursing informatics analysts assigned to assist designated areas 24/7. One large academic medical center in the Southeast employs approximately eight nursing informatics specialists (in addition to the IT support) to provide additional support to nurses and other clinicians and systems users on the patient care units. The specialists wear “red” lab coats so they are easily identified and roam the halls, providing one-on-one assistance, additional training, and troubleshooting as needed.

In addition to arranging for local technical support, the organization will also need to invest resources in building and maintaining a reliable, secure IT infrastructure (servers, operating systems, and networks) to support the information system, particularly if it is a mission-critical system. Many patient information systems need to be available 24 hours a day, 7 days a week, 365 days a year. Health care professionals can come to rely on having access to timely, accurate, and complete information in caring for their patents, just as they count on having electricity, water, and other basic utilities. Failing to build the IT infrastructure that will adequately support the new clinical system can be catastrophic for the organization and its IT department.

An IT infrastructure’s lifetime may be relatively short. It is reasonable to expect that within three to ten years, the hardware, software, and network will likely need to be replaced as advances are made in technology, the organization’s goals and needs change, and the health care environment changes. Downtime, both scheduled and unscheduled, should be limited. For example, one hospital’s goal is to have no more than nine hours of downtime a year.

Provide Adequate Training

Earlier we discussed the importance of training staff on the new system prior to the go-live date. Having a training program suited to the needs of the various user groups is very important during the implementation process. People who will use the system should be relatively comfortable with it, have had ample opportunities to use it in a safe environment, and know where to turn should they have questions or need additional assistance. It is equally important to provide ongoing training months and even years after the system has been implemented. In all likelihood the system will go through a series of upgrades, changes will be made, and users will get more comfortable with the fundamental features and will be ready to push the system to the next level. Some users will explore additional functionality on their own; others will need prodding and additional training in order to learn more advanced features.

It is also critical to provide the type of training that works best for your users’ needs and learning preferences. Do not be afraid to have different training methods for different user groups (Holden, 2011). Memorial Sloan-Kettering Cancer Center is a perfect example. It is one of the world’s oldest private cancer centers in the world. All of its physicians are employees of the organization. When they were first implementing their CPOE, all clinical and administrative staff underwent group training sessions (Sklarin, Granovsky, & Hagerty-Paglia, 2011). The system was not accepted by the physicians for a variety of reasons, and training was a critical issue. Once the leadership team realized this, they regrouped, changed tactics, and added three new approaches to working with the physicians: (1) they rolled out one service at a time with one hour of personalized training to each physician of that service (additional time did not seem to help); (2) support staff were stationed at the clinical areas during the implementation period for individualized assistance (similar to the “red coats” mentioned earlier); and (3) a physician champion was involved in workflow discussions and key in facilitating the placement of orders in the system and in helping ensure physician compliance (Sklarin, Granovsky, & Hagerty-Paglia, 2011). Understanding the culture and the physician training needs of the organization is vital when implementing a new system, as is a willingness to reevaluate the project. It is important to view the system as a long-term investment rather than a one-time purchase. The resources allocated or committed to the system should include not only the up-front investment in hardware and software but also the time, people, and resources needed to maintain and support it.

Manage Unintended Consequences

Management expertise and leadership are important elements to the success of any system implementation. Effective leaders help build a community of collaboration and trust. However, effective leadership also entails understanding the unintended consequences that can occur during complex system implementations and managing them. Unintended consequences can be positive, negative, or both, depending on one’s perspective. Several years ago, Ash and colleagues (2007) conducted interviews with key individuals from 176 U.S. hospitals that had implemented CPOE. CPOE is one of the most complex and challenging of clinical information systems to implement. From their work, they identified eight types of unintended consequences that implementation teams should plan for and consider when implementing CPOE:

  1. More work or new work. CPOEs can increase work due to the fact that systems may be slow, nonstandard cases may call for more steps in ordering, training may remain an issue, some tasks may become more difficult, the computer forces the user to complete “all steps,” and physicians often take on tasks that were formerly done by others.
  2. Workflow. CPOEs can greatly alter workflow, sometimes improving workflow for some and slowing or complicating it for others.
  3. System demands. Maintenance, training, and support efforts can be significant for an organization, not only in building the system but also in making improvements and enhancements to it.
  4. Communication. CPOE systems affect communication within the organization; they can reduce the need to clarify orders but also lead to people failing to adequately communicate with each other in appropriate situations.
  5. Emotions. Clinician reactions to CPOE can run the gamut from positive to negative.
  6. New kinds of errors. Although CPOE systems are generally designed to detect and prevent errors, they can lead to new types of errors such as juxtaposition errors, in which clinicians click on the adjacent patient name or medication from a list and inadvertently enter the wrong order.
  7. Power shifts. Shifts in power may be viewed as less of a problem than some of the other unintended consequences, but CPOE can be used to monitor physician behavior.
  8. Dependence on the system. Clinicians become dependent on the CPOE system, so managing downtime procedures is critical. Even then, while the system is down, CPOE users view the situation as managed chaos (adapted from Ash et al., 2007).

Conflicts can also occur between paper-based and electronic systems if providers who prefer paper records annotate printouts and place them in patient charts as formal documentation, and in essence create two distinct and sometimes conflicting medical records (Jones et al., 2011).

Health care executives and implementation teams should be aware of these unintended consequences, particularly those that can adversely affect the organization, and carefully plan for and manage them.

Establish Strong Working Relationships with Vendors

Developing strong working relationships with the vendor is key. The health care executive should view the vendor as a partner, and an entity with which the organization will likely have a long-term relationship. This relationship often begins when the organization first selects a new information system and continues well after the system is live and operational. The system will have upgrades, new version releases, and ongoing maintenance contracts. It behooves both parties, the health care provider organization and the vendor, to clearly define expectations, resource needs, and timelines. It is important to have open, honest, and candid conversations when problems arise or differences in expectation occur. Equally important is for both parties to demonstrate a willingness to address needs and solve problems collaboratively.

SYSTEM SUPPORT AND EVALUATION

Information systems evolve as an organization continues to grow and change. No matter how well the system was designed and tested, errors and problems will be detected and changes will need to be made. IT staff generally assume a major role in maintaining and supporting the information systems in the health care organization. When errors or problems are detected, IT staff cor­rect the problem or work with the vendor to see that the problem is fixed. Moreover, the vendor may detect glitches and develop upgrades or patches that will need to be installed.

Many opportunities for enhancing and improving the system’s performance and functionality will arise well after the go-live date. The organization will want to ensure that the system is adequately maintained, supported, and further developed over time. Selecting and implementing a health care information system is an enormous investment. This investment must be maintained, just as one would maintain one’s home.

As with other devices, information systems have a life cycle and eventually need to be replaced. Health care organizations typically go through a process whereby they plan, design, implement, and evaluate their health care information systems. Too often in the past the organization’s work was viewed as done once the system went live. It has since been discovered how vital system maintenance and support resources are and how important it is to evaluate the extent to which the system goals are being achieved.

Evaluating or accessing the value of the health care information system is increasingly important. Acquiring and implementing systems requires large investments, and stakeholders, including boards of directors, are demanding to know both the actual and future value of these projects. Evaluations must be viewed as an integral component of every major health information system project and not an afterthought. In fact we believe that assessing the value of a health IT investment is enormously important and thus have devoted Chapter Seventeen entirely to the subject.

SUMMARY

Implementing a new information system in a health care organization requires a significant amount of planning and preparation. The health care organization should begin by appointing an implementation team comprising experienced individuals, including representatives from key areas in the organization, particularly areas that will be affected by or responsible for using the new system. Key users should be involved in analyzing existing processes and procedures and making recommendations for changes. A system champion should be part of the implementation team and serve as an advocate in soliciting input, representing user views, and spearheading the project. When implementing a clinical application, it is important that the system champion be a physician or clinician, someone who is able to represent the views of the care providers.

Under the direction of a highly competent implementation team, a number of important activities should occur during the system rollout. This team should assume a leadership role in ensuring that the system is effectively incorporated into the day-to-day operations of the facility. This generally requires the organization to (1) analyze workflow and processes and perform any necessary process reengineering, (2) install and configure the system, (3) train staff, (4) convert data, (5) adequately test the system, and (6) communicate project progress using appropriate forums at all levels throughout the organization. Attention should be given to the countless details associated with ensuring that downtime and backup procedures are in place, security plans have been developed, and the organization is ready for the go-live date.

During the days immediately following system implementation, the organization should have sufficient staff on hand to assist users and provide individual assistance as needed. A stable and secure IT infrastructure should be in place to ensure minimal, ideally zero, downtime and adequate response time. The IT department or other appropriate unit or representative should have a formal mechanism in place for reporting and correcting errors, bugs, and glitches in the system.

Once the system has gone live, it is critical for the organization to have in place the plans and resources needed to adequately maintain and support the new system. Technical staff and resources should be available to the users. Ongoing training should be an integral part of the organization’s plans to support and further develop the new system. In addition, the leadership team should have in place a thoughtful plan for evaluating the implementation process and assessing the value of the health care information system.

Beyond taking ultimate responsibility for completion of the activities needed to implement and to support and evaluate the new system, the health care executive should assume a leadership role in managing the organizational and human aspects of the new system. Information systems can have a profound impact on health care organizations, the people who work there, and the patients they serve. Acquiring a good product and having the right technical equipment and expertise are not enough to ensure system success. Health care executives must also be attuned to the human aspects of introducing new IT into the care delivery process.

KEY TERMS

  1. Implementation team
  2. System champion
  3. System implementation
  4. Train the trainer
  5. Unintended consequences
  6. User resistance
  7. Workflow and process analysis

LEARNING ACTIVITIES

  1. Visit a health care organization that has recently implemented a health care information system. What process did it use to implement the system? How does that process compare with the one described in this chapter? How successful was the organization in implementing the new system? To what do staff attribute this success?
  2. Search the literature for a recent article on a system implementation project. Briefly describe the process used to implement the system and the lessons learned. How might this particular facility’s experiences be useful to others? Explain.
  3. Physician acceptance and use of clinical information systems are often cited as challenges. What do you think the health care leadership team can or should do to foster acceptance by physicians? Assume that a handful of physicians in your organization are actively resisting a new clinical information system. How would you approach and address their resistance and concerns?
  4. Assume you are working with an implementation team in installing a new nursing documentation system for a home health agency. Historically, all its nursing documentation was recorded in paper form. The home health agency has little computerization beyond basic registration information and has no IT staff. What recommendations might you offer to the implementation team as it begins the work of installing the new nursing documentation system?
  5. Discuss the risks to a health care organization in failing to allocate sufficient support and resources to a newly implemented health care information system.
  6. Assume you are the CEO of a large group practice (seventy-five physicians) that implemented an EHR system two years ago. The physicians are asking for an evaluation of the system and its impact on quality, costs, and patient satisfaction. Devise a plan for evaluating the EHR system’s impact on the organization in these three areas.
  7. Read the Executive Summary of the Institute of Medicine’s (2011) report entitled Health IT and Patient Privacy: Building Safer Systems for Better Care. How can the introduction of health IT that is designed to enhance or improve patient quality and safety lead to patient safety concerns? Do you agree that patient safety is a partnership between the health care organization and health IT vendor when implementing health care information systems? Explain the role of each and your rationale.

REFERENCES

Ash, J. S., Anderson, N. R., & Tarczy-Hornoch, P. (2008). People and organization issues in research systems implementation. Journal of the American Medical Informatics Association, 15, 283–289.

Ash, J. S., Sittig, D. F., Poon, E. G., Guappone, K., Campbell, E., & Dykstra, R. (2007). The extent and importance of unintended consequences related to computerized provider order entry. Journal of the American Medical Informatics Association, 14(4), 415–423.

Ash, J. S., Stavri, P., Dykstra, R., & Fournier, L. (2003). Implementing computerized physician order entry: The importance of special people. International Journal of Medical Informatics, 69(2–3), 235–250.

Bates, D. W., Kuperman, G. J., Wang, J., Gandhi, T., Kittler, A., Volk, L., … & Middleton, B. (2003). Ten commandments for effective clinical decision support: Making the practice of evidence-based medicine a reality. Journal of the American Medical Informatics Association, 10, 523–530.

Cusack, C., & Poon, E. (2011). Health information exchange evaluation toolkit. Agency for Healthcare Research and Quality. Retrieved February 2013 from healthit.ahrq.gov/portal/server.pt/community/health_it_tools_and_resources/919/health_information_exchange_(hie)_evaluation_toolkit/27870

Holden, R. J. (2011). What stands in the way of technology-mediated patient safety improvements? A study of facilitators and barriers to physician’s use of electronic health records. Journal of Patient Safety, 7(4), 193–203.

Institute of Medicine. (2011). Health IT and patient privacy: Building safer systems for better care. Washington, DC: National Academies Press.

Jones, S. S., Koppel, R., Ridgley, M. S., Palen, T., Wu, S., & Harrison, M. I. (2011, August). Guide to reducing unintended consequences of electronic health records. Rockville, MD: Agency for Healthcare Research and Quality.

Metzger, J., & Fortin, J. (2003). Computerized physician order entry in community hospitals: Lessons from the field. Oakland: California HealthCare Foundation.

Miller, R. H., & Sim, I. (2004). Physicians’ use of electronic medical records: Barriers and solutions. Health Affairs, 23(2), 116–126.

Miller, R. H., Sim, I., & Newman, J. (2003). Electronic medical records: Lessons from small physician practices. Oakland: California HealthCare Foundation.

Sittig, D. F., & Singh, H. (2011). Defining health information technology-related errors: New developments since To Err Is Human. Archives of Internal Medicine, 171(14), 1281–1284.

Sklarin, N. T., Granovsky, S., & Hagerty-Paglia, J. (2011). Electronic health record implementation at an academic cancer center: Lessons learned and strategies for success. American Society of Clinical Oncology, 411–415.

Wager, K. A., Lee, F., White, A., Ward, D., & Ornstein, S. (2000). Impact of an electronic medical record system on community-based primary care practices. Journal of the American Board of Family Practice, 13(5), 338–348.

Yackanicz, L., Kerr, R., & Levick, D. (2010). Physician buy-in for EMRs. Journal of Healthcare Information Management, 24(2), 41–44.