The Nursing Informatics Implementation Guide

By Eleanor Callahan Hunt, Sara Breckenridge Sproat and Rebecca Rutherford Kitzmiller

Health institutions are investing in and fielding information technology solutions at an unprecedented pace. With the recommendations from the Institute of Medicine around information technology solutions for patient safety, mandates from industry groups such as Leapfrog about using infor­ mation systems to improve health care, and the move toward evidence­ based practice, health institutions cannot afford to retain manual practices. The installation of multi-million dollar computerized health systems repre­ sents the very life blood of contemporary clinical operations and a crucial link to the financial viability of institutions. Yet, the implementation of health information systems is exceptionally complex, expensive and often just plain messy. The need for improvement in the art and science of systems implemen­ tation is clear: up to 70-80% of information technology installations fail. The reasons are multi-faceted, ranging from the complexity of the diverse workflows being computerized, the intricate nature of health organizations, the knowledge and skills of users to other reasons such as strategies for obtaining key executive support, weaving through the politics peculiar to the institution, and technical facets including the usability of systems. Thus, the art and science of successfully implementing systems remains deeply layered in elusiveness. Still, given the pervasiveness of system implementa­ tions and the importance of the outcomes, this is a critical topic, especially for nurses and informatics nurse specialists.

• Language: English
• Publisher: Springer
• Release date: Mar 9, 2013
• ISBN: 9781475743432

Book preview

1

Implementation Overview

Eleanor Callahan Hunt¹

Email: [e-mail]

Sara Breckenridge Sproat²

Email: [e-mail]

Rebecca Rutherford Kitzmiller³

Email: [e-mail]

¹Informatics Consultant, 27614, Raleigh, NC, USA

²67th Combat Support Hospital, Unit, 26610, Wuerzburg, Germany

³Duke University Health System, 27708, Durham, NC, USA

This implementation guide presents the informatics nurse with the ideas and framework to successfully implement a technological system, large or small. Strategies, case studies, and informatics advice highlight issues a project director or analyst might experience.

The moment an informatics nurse becomes involved in a system implementation, ideas start swirling and then panic sets in as the enormity of the task dawns. Eventually, a plan unfolds as to how to best approach the enormous task of implementation. A nurse informaticist’s level of involvement, position, and responsibilities may vary dramatically. These may include implementing an entire system, implementing a part of the system, coordinating clinical input, coordinating nursing input, acting as a liaison from a clinical area to the system implementers, directing a department, or any point in between.

In the beginning, the burning questions include: How should I start? What does this position mean? What am I actually responsible for? How long do I have to do this? What staff is available? What other resources do I need? I agreed to do this because … ? How can I successfully implement this thing? As these questions get answered, the role or degree of involvement becomes clear and the position and the project gathers momentum.

This introductory chapter describes the system life cycle, phases of a system implementation, and implementation strategies.

System Lifecycle

Systems Lifecycle is a well-defined concept within the literature. The purpose of managing a system throughout its use is to deliver quality systems when promised and within cost estimates using an identifiable, measurable, and repeatable process.¹ The literature describes different systems lifecycle models; five of these models are graphically represented in Figure 1.1.

FIGURE 1.1. Systems Life cycle models

In Figure 1.1 the model represented by the letter A is adapted from project management literature. It has four phases: request and initiation; planning; execute and control; closure. The model represented by the letter B has five phases: inception; elaboration; implementation, which consists of architectural design and coding; rollout; maintenance. This model is used in general software development. Model C represents a four-phase lifecycle frequently cited in nursing infomiatics literature and can also be graphically displayed as a circ1e.² Model D is from project management theory and has six phases: analysis; design; development; quality assurance; deployment; support.³ The content of these phases are expanded upon in Table 1.1 and this model is the one that is reflected most closely in the content of this book. From experience, greater emphasis is placed on the analysis phase because this phase lays the groundwork for success. Model E is a model also used in government project management.⁴ This model has six phases: initiation; concept; detailed analysis and design; development; deployment; operations. In this model, the identification of a need and the exploration of a solution mark the beginning of the initiation phase. This phase will result in the recommendation of an acceptable and affordable course of action. During the concept phase, the organization defines systems requirements, including the requirement to integrate or interface with other systems. The detailed analysis and design phase matches the system requirements to organizational business processes. Changes needed to both the system and the organizations are detailed, resulting in a high-level design

TABLE 1.1. Content of the six phases of systems lifecycle model D.

plan. The development phase produces the actual system: a plan for deployment as well as work unit business process reengineering. During deployment, the system is installed, users are trained, and end users accept the system. The final phase, operations, includes activities that maintain the operation and enhancement of the system, such as maintaining functionality, ensuring data integrity and data security, and continuously assessing the system’s need for modifications and hardware upgrades.

The five systems lifecycle models represented in Figure 1.1 depict different approaches to the same concept. Varied professional backgrounds may work from different wording of the same ideas, depending on preparation and personal or organizational preference. The names of the steps and stages may differ depending on professional foundation, but they describe basically the same concepts. The phrases or words used is not what is important–it is the content.

Select System

Within this book, the system selection process including envisioning the system, conducting a feasibility analysis, and obtaining executive team buyin are the first steps to implementation. Completing these tasks often takes a significant amount of time. Recognize that staff actively involved in the selection process may have become vested and often try to hurry the process in their anxiety to start implementation and reap the benefits of system use. It is critical to complete each step in its entirety. The amount of time spent in this process depends on the degree to which the organization is prepared to embrace the system and on the executive clinical and administrative vision for the system. If the process is started with a clear mission, the entire executive team endorses the system, the budget has been allocated, and the selection team has clear guidance, then the selection process should move along quickly. If there are still naysayers at the executive level, if influential stakeholders need to be brought in, if there is a lack of clear vision of the properties the system should have, or if the organization continuously changes its vision, then be prepared to spend significant time in the selection process.

System selection includes the following tasks: forming a selection team, developing the vision, mission, goals of the project, performing a needs assessment, writing the Request for Information (RFI) and Request for Proposal (RFP), gathering vendor information, conducting site visits and user interviews, holding vendor site visits, making the decision, negotiating the contract, and creating the project implementation team and transferring selection team knowledge to the implementation team. These tasks are described in detail in a later chapter. As noted in the Swedish Medical Center ABIA story, sometimes the selection process takes a very long time, yet that time was used wisely. The subsequent steps should be significantly easier because the following tasks were carefully completed: establishing a

vision, obtaining stakeholder buy-in, negotiating with the vendor for the time line and task completion, and marketing to customers. Conversely, if selection tasks are rushed, the implementation team may run into surprises that were not discovered during a hurried selection process. For example, the implementation team may discover that the system does not work well in mental health areas or research units because input was not gathered from those areas or those representatives did not fully understand the impact of the system.

In summary, the selection process can drag out, or seem to be dragging, to anxious promoters of the system. However, time spent analyzing user processes and gathering user buy-in benefits the implementation in later stages. A lengthy process caused by the politicizing of the purchase or changing missions of the organization has the potential to harm the implementation. A solid vision, backing by the executive team, plentiful funding and resource availability, and a solid system selection process will only benefit the implementation.

Form Project Team

The project implementation team may differ significantly from the selection team. The selection team is often more user-focused, with representation from every work unit or department affected by system implementation. The implementation team is usually comprised of a mix of technical and clinical resources. The team may include analysts, programmers, and network engineers, as well as clinically experienced representatives from the involved work units.

Determine Project Scope, Time Line, and Budget

The project’s scope, time line, and budget are intimately tied to the system vision, established during the system selection process. It is difficult to adequately plan for a constantly changing project scope. It is critical to avoid scope creep and the additions to or changes in system functionality requirements which contribute to scope creep. Scope creep also contributes to increases in time and budgetary resources. Once the scope is determined, the team estimates the tasks and time required to complete implementation. Although the budget was determined during the system selection process, the team must match the time line with budgetary resources to validate that the budget is adequate. At a minimum, the budget should include resources to meet both contractual and implementation requirements: hardware and software purchases, technical training of the team, vendor support costs, maintenance and upgrade costs, salaries for the team members, costs of materials for the team and for training users, additional costs of interfaces required, and additional hardware and software not in the system contract. The implementation strategy needs to be chosen prior to budget finalization, because each strategy requires different resources. An implementation time line and budget will include contingency plans for both scope creep and anticipated problems. Rarely do projects come in on budget and on time. A change in either impacts the other. Scope, time line, and budgets are discussed in depth in a later chapter.

Determine Stakeholders, Build Support

Part of risk assessment is determining who is going to support the project, who will support the project if they perceive value, and who will not be supportive of the project, regardless of benefit. Not everyone will be supportive or jump on board to support innovations.⁵ This causes problems for the project when the resisters are highly influential and start lobbying against the project. It is important to include all potential stakeholders and continuously work on marketing for and maintaining support throughout the

project. Defining the value of the system to different individuals and groups and clearly and frequently communicating this value is key to maintaining support. For example, many nurses can be won over when describing the benefits of Computerized Provider Order Entry (CPOE) on their workload (which, for the most part, diminishes or eliminates transcription). However, this will anger providers as they realize that CPOE will increase the time to document.⁶,⁷ The project team must market the system’s value to providers: decreases in phone calls regarding illegible orders, reduction in delays to ancillaries, including the pharmacy, and a real-time view of care team documentation. System implementation rarely effects only a single department. Communicating to all potential users is key to preventing alienation, anger, and resistance.

Successful negotiation of the political landscape includes understanding the impact of project information on the organization and may require the project team to consider what information to release and when to release it. Vendors and the project team will take their cues from the project leader. Understanding organizational culture and the formal and informal leadership structure is important in an implementation. Knowing who to connect with in the clinical arena, who has the credibility of their peers, as well as when to approach them with information is invaluable in eliciting system support. Speak with providers when they are able to focus, rather then when they are tired or when they are prioritizing patient care. For example, a surgeon is most accessible on a nonsurgery day, a pediatrician is available after rounds, and an internist is available in the morning prior to the exhausting work of the day.

Assess Risk

Risk assessment is an integral part of system implementation planning. Risks are things that threaten the project’s success and include the following: interfaces, computer literacy, technical, training, resources, security, privacy, buy-in (or lack thereof), administrative support, budgets, vendor health, and communications. It is imperative that the project team expect and develop contingency plans for issues and problems that may delay or derail the project.

Customize the System

System or product customization is the process of adapting the system to meet the needs of the clinicians. Vendors have a usable vanilla or generic product that they sell, but the system will need to be modified to incorporate dictionaries, acronyms, user screen views, and organizational policies. Requirements gathering and workflow analysis generate lists of customizations required and desired. Encouraging and actively pursuing user input improves the system’s quality and ensures buy-in at all levels.

Train All Users of the System

Training encompasses planning, scheduling, creating documentation, as well as the actual hands-on teaching. For many, actually getting the students into the classroom is the hard part; the next hardest is keeping them there without getting paged. Many system administrators require training prior to issuing sign-ons. Others create alternative training environments such as on-line, computer-based, in-office and on-unit training to improve compliance. Training users for a big bang implementation (all at once) is probably the biggest challenge because everyone needs to be trained at once, as is finding space to conduct training sessions. In a phased implementation, training occurs in stages, but maintaining up-to-date documentation as the system grows and changes becomes a challenge during a phased approach.

Deploying the System to Users

During the planning phase, the project team creates a rollout plan that outlines all of the activities that need to take place when preparing a unit for system installation. These steps include validation of software functionality, assessment of work unit readiness: user equipment placement, work unit resource documentation, training completion, and conversion of existing data. Providing support for the go-live, the first time users are working with the system, is critical in easing the anxiety of users. Working with an established superuser, one involved in the customization of the system, will enhance the success of the go-live. At the conclusion of this phase, the unit will accept the software with recommendations for rework of the system. The project team will assess the installation processes and make process adjustments. These are quality control measures that prevent further mistakes or problems.

Evaluate Implementation, Software, and Use of System

Within this phase of implementation, the project team documents the state of the system. They review the entire implementation process, capturing the lessons learned for use by future implementation teams.⁸ From the project documents—vision, mission, goals, and scope of the project—the team assess the fit between expected functionality and actual functionality. The team also evaluates user interaction with the system, looking for opportunities to increase use and improve data capture. The final evaluation is assessing the true Return on Investment (ROI) and comparing it against any expected ROI outlined during the system selection process.

Maintain, Enhance and Install Upgrades

This phase is the final phase of systems lifecycle management. Day-to-day management of the system includes preventing downtime, ensuring user access to the system, and protecting data integrity. This phase also includes the constant reevaluation of the system for enhancements in functionality. System administrators or analysts (SA) remain familiar with the users in order to anticipate and plan for changes to the system. As the system undergoes software version upgrades, the SAs will assess the impact of the upgrade and plan for downtime and training needs as required. Finally, the SAs are required to project for eventual modernization of the equipment used with the system.

Start Again

Select a system to meet anticipated growth and changes ... were we not just here? Is this not what started this whole exciting project? Should we not just revel in the glory of a stable, well-loved system and be happy with it? The reason for the change is because, originally, the existing system was not meeting the needs of the organization, so a system was chosen, implemented, evaluated, and maintained. Just as the organization outgrew the original existing system, the organization will outgrow the new system. This happens when work processes change, priorities or focus of the organization changes, or the system has grown to the point where it is unwieldy and difficult to maintain. The system might also need to be replaced because the vendor has moved on and is developing new, incompatible products, or the vendor may have merged with another and the product is no longer being maintained.

In any event, the whole process starts again. Is it easier this time? This depends on how much time has passed, turnover of staff, and organizational memory. It is surprising how the familiar is often proclaimed as the best and those resisters that resisted the first system will resist the next change to a new system, or those clinicians actively involved in the system implementation will not want to let go of the old system. Also, a new system may not have the exquisite customizations that have been hard won by the clinicians or will take time to put in. In any event, the whole cyclic process does have to start again from scratch, perhaps with some of the same people and using the same process, but the process will have to begin again starting with vision, mission, and goals1 Good luck.

The Semantics of Project and System Implementation

Many NI’s use the terms project implementation and system implementation interchangeably, however there are subtle differences. Project implementation starts with an assessment of the domain and plans for organizational changes required for success which may include one or more system implementations. For example, if an organization decided improving patient safety regarding medication errors was a major initiative, the team would first analyze the entire process of delivering medications to the patient. Then the team would evaluate which clinical and operational practices place the patient at risk and search for technical and process redesign solutions. Technical solutions might include the installation of several computerized, knowledge-based systems such as computerized provider order entry, pharmacy order management, robotic medication selection and barcode administration. Each of these could be a separate system installation within the overall project, or they could be spun off as separate projects. The phases of project and system implementation are nearly identical, as listed in Table 1.2. If a system is being implemented without being a part of a larger project, the phases

TABLE 1.2. Comparison of project implementation phases and system implementation phases.

FIGURE 1.2.Implementation strategies

of creating vision, mission and goals need to be done prior to selecting a system.

Implementation Strategies

There are three types of implementation strategy typically used when implementing computer systems. These include big bang (also called cutover), parallel, and stepped (also called staged or phased) implementations. Figure 1.2 graphically depicts a comparison between these implementation approaches. The implementation strategy has a large impact on project planning, including the allocation of resources, project budget, and project time line. The implementation strategy needs to be discussed and decided upon almost as soon as the system has been selected, if it was not discussed prior to the system selection process. The implementation strategy decision is guided by the combination of five factors.

1. Project vision, mission, goals

2.Organizational culture

3.Resource availability

4. Technology maturity

5.Software maturity

If a big bang strategy is required due to technology or time constraints, then these requirements influence the system selection criteria and the deployment plan. A discussion of these three implementation strategies occur in this chapter, emphasizing that a strategy should be considered first or at least remain uppermost in the informaticist’s mind during the system selection and implementation process.

The degree of customization also influences the implementation strategy used. One strategy is to use the system as it is delivered from the vendor, also called a vanilla or as-is system, with limited customization. From a deployment standpoint, this is a relatively quick and simple installation, and follow on upgrades to the system require minimal work on the part of the organization because the vendor has (or should have) fully tested the software. Overall, the impact of a vanilla system on the organization is minimal. The opposite of the vanilla installation is a fully customized system. Users favor customization because it adjusts the system to users’ daily routines and work practices. However, customization is often complicated, lengthy and expensive and it causes the implementation to be more complex. Upgrades for such a specialized system may be unavailable or be expensive,² resulting in a system that is more complex to maintain. In this situation, a phased approach is often used so that changes and implementation coexist and are easier to manage.

Big Bang Implementation

The big bang approach is used to switch all users from an original system to a new system at once. Generally, all work units will use the entire software system at a set point in time. It is also called the cutover, cold turkey, or burned bridge approach. This approach requires the organization to flip the switch to the new system. If the results are not satisfactory, the system can be turned off, revised, and activated again.⁹ The term evokes an interesting picture if the switchover does not go well. If it does go well, it is still a hectic few days or weeks until the system and users stabilize. The big bang strategy is usually used when switching from one automated system to another. Rarely is it used when switching from a manual system. System upgrades are usually implemented in a big bang method, because the upgrade affects all programs and areas at once.

This implementation approach is used infrequently, particularly in healthcare organizations, due to the enormity of the support required¹⁰ from the Information Technology department and the changes in organizational process standpoints. Some might question the wisdom of such an approach; however, it may be the only way to implement a system, given certain constraints¹⁰:

Limited time to replace an aging obsolete system

Limited time, resources, or expertise to develop individual interfaces to existing systems

Lack of consistent coding standards, making interfaces to obsolete systems impossible

Tightly integrated patient care processes, making it difficult for staff to deal with several separate computer systems simultaneously

This strategy has a huge impact on the project team because all work to prepare the system and the organization must be completed by a specific date and time:

Training for staff must be completed prior to the go-live date.

All hardware needs to be placed in a relatively short period of time across the organization.

Software needs to be tested and functional throughout the organization.

Project staff needs to be ready to fix critical system bugs; less time for user support is available. It may be necessary to create temporary project positions to support users in each work area. Budget plans should accommodate hiring temporary staff, paying for overtime, or both.

The main advantage with this strategy is speed. Risks include intensive resource use, system failure, and inability of project staff to adequately support users or to respond to critical system bugs. The project is implemented and the users move through the transitional (painful) stage of the changeover and then start realizing the benefits of the system.

Parallel Implementation

A parallel implementation occurs when two systems run simultaneously. Whether paper or electronic, work unit staff will use both systems at the same time, performing work processes in both systems so that their results can be compared.⁹ This strategy is typically used when there is a financial impact or the application is critical to the operation of the organization. It is an excellent strategy to use to identify missing software functionality due to the inherent step-by-step evaluation process. This strategy is also used when implementing untried, prototype, or cutting-edge technology and project team members are concerned about functionality, usability, and credibility of the system. The parallel approach can be used to replace an existing computerized system, a manual, pencil and paper system, or a nonintegrated system with a fully integrated system.

The advantage of this strategy is that it builds trust and credibility for the new system, demonstrating that it will work as well as or better than the existing system. If parallel is the chosen deployment strategy, it is best to use a service area or work unit approach that will allow patients and information to move seamlessly from one clinical service area to another during a single stay. As an example, the deployment of a patient care documentation system would follow the patient’s care process—as the patient moves from the preadmission unit to the operating room to the surgical intensive care unit to the step-down unit to the surgical ward; all these units should be implemented at one time, streamlining information sharing, and decreasing risk to quality patient care.

There are two primary disadvantages to this implementation method. The first disadvantage is the workload impact on the implementing unit. Because all tasks are replicated in two systems, the time to complete work obviously increases, decreasing productivity. It is easy to see how this situation would grow tiresome for work unit staff or might introduce potential errors. The duration of parallel system use needs to be as short as possible and well defined so the users do not revolt. Another disadvantage is that it allows users time to compare the old and new systems. The time it takes to use the system, the comfort level users have with the old versus new systems, the impact on workflow, and the formatting of screens and reports may negatively impact user acceptance of the system or may generate a huge increase in customization requests not anticipated by the project team. It is important to establish acceptance criteria in writing, prior to the deployment to the test unit, so the old system can be switched off as soon as possible.

Phased Implementation

A staged implementation is probably the most common strategy used in health care. An incremental, simplified approach to system creation and implementation.… is a strategy with which even the smallest healthcare institutions can get a handle on electronic documentation.¹¹ The terms stepped, staged, and phased are used interchangeably and occur when the new system is implemented in increments. As in the development of the deployment plan, unit preparedness as well as software maturity influence this choice.

This approach is relatively safe for the organization because it allows project team members to reassess system functionality after each module or unit is operationalized. It also allows the project team to provide support to the users. Although system deployment initially affects work unit productivity negatively, the effect is much less than that experienced in the parallel approach.⁹ The phased approach takes longer than the big bang. Due to the ongoing assessment by the project team, extension of the time line may be necessary, as unexpected problems will arise. There are several ways to phase a deployment. The first option is to implement one component of a system across all departments in the organization. An alternate method is to pilot the entire system in one area (a department or a patient care area) and then implement the system incrementally throughout the organization. A third approach is to implement one or several component(s) of the system in an area or throughout the entire organization and subsequently implement additional components until the entire system is live in all areas. This strategy allows the delivery of incremental value to the users, which can help earn the buy-in of skeptical users. For users who are wary, skeptical, or previously burned with an unsuccessful implementation, initiate automation slowly. Bring one nursing unit, or discipline online at a time, evaluate anxiety, disruption, and resistance at each step.¹¹

One caveat is to not deliver too much value to the users too early, so interest and support is lost to less mission-critical components or to those components that require more work and less ROI on the part of the user. In other words, providing lab results without requiring the entry of lab orders takes away an incentive to get the providers to enter orders themselves. Also, once laboratory, radiology, nutrition, and pharmacy is implemented, there may be less interest in investing time to implement the rest of the departments.

Pilot Approach

Pilot implementation is a type of phased implementation. Using a pilot, the project team rolls out the new system in sites that are representative of the complete system. This means that certain locations or departments serve as alpha pilot test sites, followed by other beta pilot sites.⁹ Alpha testing and beta testing is commonly used when testing new versions of vendor software and is typically done with a pilot to minimize potential impact on the rest of the organization. Once the pilot has been deemed successful, the system can be implemented throughout the organization in one fell swoop (modified big bang strategy) or in increments (modified phased implementation). If the pilot is for project learning, to assess user interest, check workflow, or to test procedures or new hardware, the pilot can be discontinued without further rollout.

There are many advantages to this strategy, including being able to adequately train staff and support deployment with a smaller project staff, which, in turn, requires less financial resources. It is less time-consuming and complex to create, test, and develop policies and procedures in stages instead of having them ready all at once. This technique is also useful when introducing cutting-edge technology: New technology can be tested and potential problems or bugs worked out before introduction to the entire organization. This technique is effective when the impact on workflow is not obvious during the system analysis process. Workflow can be assessed and changes made to either software or to work processes when system deployment occurs in the pilot and phased methods.

This method of managing a deployment requires users to work with a hybrid system—the new and the existing. This creates problems for users and mechanisms, for moving patients and information between the two systems must be carefully planned for prior to deployment so that patient care is not negatively impacted. There is a high potential for missed documentation and potential errors in patient care due to the use of mixed systems. Also, note that using hybrid processes requires additional support from the help desk, and user calls may increase or become more complex related to the use of two systems. Recognize that users are doing additional work when using a hybrid system, impacting the overall benefits of the system as well as patient care. Other disadvantages include the following:

An increased potential for error

Potential decrease in the timeliness of care delivery

Potential increase in user dissatisfaction

Support for a hybrid system for a long duration

Lengthening the deployment time period

Lengthened time to realize the identified benefits of the system.

Organization of This Book

For the sake of simplicity, the chapters of this book are approached as if one system is being implemented. This is a luxury most of us are not afforded. There is the occasional tip on how to integrate projects and tasks, but for the most part, the book deals with