Health Information System Case Selection and Proposal

You will propose how the particular health information system used in your selected case would be applicable in a health care organization of your choice. Refer to your chosen organization as System Implementation and Support.

• Evaluate the needs that are present within your selected case study as it applies to your “ABC Health Care” organization.
• Examine the practices from your selected case study that confirm or contradict that data is complete, accurate, consistent, timely, secure, and fit for use.
• Compare and contrast the different types of data and information generated by the health care organization in your case.

**please use the proposal form attached**

QUALITY IMPROVEMENT STUDENT PROJECT PROPOSAL: TYPE YOUR SPECIFIC
TITLE HERE

Fill-in the details below between the brackets

1. BACKGROUND

Setting: Here, describe the place that you will focus on for this proposal and the specific of that

place.

[ ].

Health Care Service: In this section, share the specific health care service that you are

proposing a quality improvement for.

[ ].

Problem: In this section, describe the specific problem you have found. Be sure to include

evidence from sources that support this is a problem.

[ ].

Barriers to Quality: Here, share any barriers that exist that hinder the quality that is needed.

Be sure to provide evidence from sources to support your claims.

[ ].

2. THE INTERVENTION

In this section, discuss the intervention or solution you are proposing to improve the quality of

the problem you have identified. Provide evidence from sources to support your suggestions.

[ ].

Process Defect: Here, include the overall process that will be used to implement the proposed

solution.

[ ].

Aim (Objective): Here, state the objective of the proposed

intervention.

[ ].

3. STRATEGY FOR IMPLEMENTATION

Here, identify and describe the steps or the strategy that will be taken to implement the

intervention.
[ ].

Measures : In this space, share what will be used to measure the implementation of the

intervention or how the results of the implementation will be measured.

[ ].

Barriers to Change : Here, include a discussion of any barriers that could get in the way of the

proposed change. Include any evidence from sources that can support your claims.

[ ].

Simple Rules: Here, include the rule that will be satisfied by your proposed intervention.

[ ].

Cost Implications : Here, include any costs associated with the proposed intervention.

[ ].

1

QQUALITY IMPROVEMENT STUDENT PROJECT PROPOSAL:

IMPROVING HANDOFFS IN SAN FRANCISCO GENERAL

HOSPTITAL’S EMERGENCY DEPARTMENT

TMIT Student Projects QuickStart Package ™

1. BACKGROUND

Setting: Emergency departments are “high-risk” contexts; they are over-crowded and

overburdened, which can lead to treatment delays, patients leaving without being seen by a

clinician, and inadequate patient hand-offs during changing shifts and transfers to different

hospital services (Apker et al., 2007). This project will focus on the Emergency Departments in

county hospitals, specifically San Francisco General Hospital. SFGH has the only Trauma Center

(Level 1) available for the over 1.5 million people living and working in San Francisco County

(SFGH website)

Health Care Service: This paper will focus on intershift transfers, the process of transferring a

patient between two providers at the end of a shift, which can pose a major challenge in a busy

emergency department setting.

Problem: According to the Joint Commission on Accreditation of Healthcare Organizations

(JCAHO), poor communication between providers is the root cause of most sentinel events,

medical mistakes, and ‘‘near misses.” Furthermore, a recent survey of 264 emergency

department physicians noted that 30% of respondents reported an adverse event or near miss

related to ED handoffs (Horwitz, 2008). A similar survey notes that 73.5% of hand-offs occur in

a common area within the ED, 89.5% of respondents stated that there was no uniform written

policy regarding patient sign-out, and 50.3% of those surveyed reported that physicians sign out

2

patient details verbally only (Sinha et al., 2007). At SFGH, handoffs occur in the middle of the

ED hallway, usually next to a patient’s gurney. Sign-out is dependent on the Attending and

Residents on a particular shift; thus, it is non-uniform, and hand-offs are strictly verbal.

Barriers to Quality: In a 2005 article in Academic Medicine, four major barriers to effective

handoffs were identified: (1) the physical setting, (2) the social setting, and (3) communication

barriers. Most of these barriers are present during intershift transfers at SFGH. The physical

setting is usually in a hallway, next to a whiteboard, never in private. Presentations are frequently

interrupted, and background noise is intense from the chaos of an overcrowded emergency room.

Attendings frequently communicate with each other and assume that the resident can hear them.

Solet et al. suggests that Residents are unlikely to ask questions during a handoff if the

information is coming from an Attending physician. All transfers are verbal, none are

standardized, and time pressures are well known, since sign-out involves all working physicians

in the ED at one time.

2. THE INTERVENTION

The Institute for Health Care Improvement (IHI) lays out several steps for conducting a quality

improvement project. First, an organization needs to explicitly state what they are trying to

accomplish by setting “time specific and measurable aims” (IHI website). Next, an organization

needs to establish measures that will indicate whether the improvement works. Changes that

result in an improvement need to be identified and then tested in a Plan-Do-Study-Act (PDSA)

cycle. Specifically, the change needs to be planned, tried, studied, and then members must act on

what they have learned (IHI website). PDSA cycles should start out in a small group before

being tried in a large institutional setting. Finally, the changes should be made throughout the

institution.

3

Most projects that use rapid PDSA cycles to address issues with patient handoffs

measured their compliance with a standardized communication method. Programs such as the

Five Ps (Patient, Plan, Purpose, Problems, Precautions), I PASS the BATON, or SBAR, are all

acronyms for a standardized, tested procedure to ensure compliance with the Joint Commission

requirements (Runy, 2008). Such methods may standardize the handoff process, but may not be

considered the most efficient tool by providers; therefore, provider satisfaction is a key

component for compliance and implementation (Wilson, 2007).

Process defect: This project will attempt to address non-uniform patient handoffs at the SFGH

ED by using rapid PDSA cycles to implement the SBAR handoff technique:

– S-ituation: complaint, diagnosis, treatment plan, and patient’s wants and needs

– B-ackground: vital signs, mental and code status, list of medications and lab results

– A-ssessment: current providers assessment of the situation

– R-ecommendation: pending labs, what needs to be done (H&HN, 2008)

Aim (Objective): to improve patient safety, content reliability, and peer satisfaction with SFGH

ED handoffs by having 100% compliance of the SBAR standardized protocol within 18 months

(adapted from Owens et al., 2008)

3. STRATEGY FOR IMPLEMENTATION

The first step of this implementation strategy will be to identify the early adopters and process

owners. A small team, perhaps of one attending and two residents that are passionate about this

project need to be identified and initiate the first PDSA cycle using the SBAR format for patient

handoffs. In this small group, they can work out their pit-falls, and adapt the SBAR technique to

the physical setting and social setting at SFGH. This group may wish to develop an index card

with an SBAR template to improve communication. The first PDSA cycle may look something

like this:

4

– Plan—develop a strategy to reduce noise and distractions, use SBAR (perhaps with an

index card that can be passed on), and have opportunity to ask questions.

– Do—early adopters need to try out the process during two changes of shift.

– Study—evaluate satisfaction, review pitfalls, was it easy to comply?

– Act—Implement changes during next two changes of shift.

Next, this group will need to identify opinion leaders within the organization, perhaps the Chief

Resident, to help convince the early majority that this technique will improve patient safety and

save time and effort during changes of shift. The early adopters may want to hold a training to

convince this larger group. Next, this larger group will initiate its own PDSA cycle, until 100%

compliance with the SBAR protocol is achieved.

Measures: (a) compliance with the SBAR format, via an “all or none” metric, (2) provider

satisfaction via survey, which will include questions on perceptions of time saving.

Barriers to change: The major barriers to change will be from opinion leaders within the SFGH

ED that want to protect the status quo. Some Attending and Resident physicians may be wary of

a new technique for fear that it may add to the amount of time it takes at the change of shift.

Second, most of these physicians have “always signed-out this way and have never had a

problem.” Once the early adopter group has worked out many of the kinks in implementation,

leadership will play a key role for further adoption of this project. Leaders may take note of the

Joint Commission’s recommendation on handoffs (JCAHO, 2006), and support this project, and

help nudge the late adopters along. However, in the long run, provider satisfaction of the

protocol, including provider’s perceptions of saving time, will dictate adherence, so even late

adopters need to have input during PDSA cycles.

5

Simple Rules: The landmark IOM report Crossing the Quality Chasm identified 10 simple rules

to help redesign health care processes (IOM, 2001). This quality improvement project is in

accordance with rule ten: cooperation among clinicians. Clinicians should “actively collaborate

and communicate to ensure and appropriate exchange of information and coordination of care.”

Standardizing patient handoffs in a busy emergency department setting is crucial to patient safety

and helps place patients needs first; this change manifests this simple rule.

Cost implications: This process change does not require any additional costs.

REFERENCE

Apker et al. (2007) Communicating in the “gray zone”: perceptions about emergency physician-

hospitalist handoffs and patient safety. Aca Emerg. Med. 14(10), 884-94

Coleman et al. (2004) Lost in Transition: Challenges and Opportunities for Improving the quality

of Transitional Care, Ann Intern Med. 140:533-36.

Horwitz et al. (2008) Dropping the Baton: A qualitative analysis of failures during the transition

from emergency department to inpatient care. Annals of Emergency Med. Article in press,

accessed April 21, 2009

Horwitz et al. (2009) Evaluation of an Asynchronous Physician Voicemail Sign-out for

Emergency Department Admissions. Annals of Emergency Med. In press, accessed April 21,

2009.

IHI website. Improvement methods-PDSA cycle.

http://www.ihi.org/IHI/Topics/Improvement/ImprovementMethods/HowToImprove/ accessed

April 29, 2009.

Institute of Medicine (IOM). Crossing the Quality Chasm. Washington, DC: National Academy

Press, 2001.

Joint Commission on Accreditation of Healthcare Organizations. Sentinel event root causes. Jt

Comm Perspect Patient Saf. 2005; 5(7):5–6.

JCAHO. Improving Handoff Communications: Meeting National Patient Safety Goal 2E. Joint

Perspectives on Patient Safety. 2006; 6(8): 9-15.

Owens et al. (2008) Improvement Report: Improving Resident-to-Resident Patient Care

Handoffs, IHI.org, accessed April 29, 2009.

6

Runy, Lee Ann (2008) Patient Handoffs, the pitfalls and solutions of transferring patients safely

from one caregiver to another. H&HN.com, accessed April 29, 2009.

SFGH website; http://sfghed.ucsf.edu/Index.htm, accessed April 21, 2009.

Sinha et al. (2007) Need for standardized sign-out in the emergency department: a survey of

emergency medicine residency and pediatric emergency medicine fellowship program directors.

Aca Emerg Med.; 14(2) 192-6.

Solet et al. (2005) Lost in Translation: Challenges and Opportunities in Physician-to-Physician

Communication During Patient Handoffs. Academic Medicine; Volume 80 – Issue 12 – pp 1094-

1099

Wilson, Mary Jane (2007) A template for Safe and Concise Handovers, Medsurg Nursing. 16(3);

201-06.

Chapter 6
System Implementation and Support
Learning Objectives
To be able to discuss the process that a health care organization typically goes through in
implementing a health care information system.
To be able to assess the organizational and behavioral factors that can affect system
acceptance and use and strategies for managing change.
To be able to develop a sample system implementation plan for a health care information
system project, including the types of individuals who should be involved.
To gain insight into many of the things that can go wrong during system implementations and
strategies that health care manager can employ to alleviate potential problems.
To be able to discuss the importance of training, technical support, infrastructure, and ongoing
maintenance and evaluation of any health care information system project.
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, or leased 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, by
an outside developer, or acquired or leased through cloud-based computing services.
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 also there are 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.
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 also people, processes, workflow, organizational
culture, politics, and the external environment (licensure, accreditation, regulatory agencies).
The Institute of Medicine 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 manage change effectively and 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, Sittig, Poon, Guappone,
Campbell, & Dykstra, 2007; McAlearney, Hefner, Sieck, & Huerta, 2015; Sittig & Singh, 2011).
We devote a section of this chapter to strategies for managing change and the organizational
and behavioral issues that can arise during the system implementation process. 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). Similar to 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.
Clearly define the project scope and goals.
Identify accountability for the successful completion of the project.
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 fact, during the industry rush to
take advantage of CMS incentive dollars, a flurry of EHR stories hit the news—with everything
from CIOs and CEOs losing their jobs as a result of “failed” EHR implementations, to hospital
operations screeching to a halt, to significant financial problems arising from glitches in the
revenue cycle. These high-profile cases brought national attention to the consequences of a
failed implementation. During system implementation, facilities often see their days in accounts
receivable and denials increase while cash flow slows. By organizations anticipating risks to the
revenue cycle prior to go-live and as part of EHR workflow, they are in a much better position to
stay on track and maintain positive financial performance during the transition (Daly, 2016). In
today’s environment, in which capital is scarce and resources are limited, health care
organizations cannot afford to mismanage implementation projects of this magnitude and
importance. Examining lessons learned from others can be helpful.

Organize the Implementation 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. 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.
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; Daly, 2016; Miller, Sim, & Newman, 2003; Wager, Lee,
White, Ward, & Ornstein, 2000; Yackanicz, Kerr, & Levick, 2010). When implementing clinical
applications 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 members. The various system champions can also
assume a pivotal role in ensuring that project milestones are achieved and celebrated.
Clearly Define the Project Scope and Goals
One of the implementation team’s first items of business is to determine the scope of the project
and develop tactical plans. 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 the administration’s commitment to the project.
The senior executive should also explain what the organization or health system hopes the
project will achieve.

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 Five) 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 timely. They should also define the
organization’s criteria for success (Cusack & Poon, 2011).
Let’s look at two hypothetical examples from two providers that we will call Rutledge Retirement
Community and St. Luke’s Medical Center. The implementation team at Rutledge Retirement
Community defined its goal and the scope of the project and devised measures for evaluating
the extent to which Rutledge 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.
Case Study
Rutledge Retirement Community
Rutledge Retirement Community in a Commission on Accreditation of Rehabilitation Facilities
(CARF)–accredited continuum of care community offers residential, assisted living, and skilled
care to residents in southern Georgia. An implementation team was formed and charged with
managing all aspects of the EHR rollout. Rutledge’s mission is to be “the premier continuum of
care facility in the region providing high-quality, resident-centered care with family engagement.”
Considering how to achieve this mission, the team identified the EHR as the building block
needed to improve care coordination, reduce medication errors, and create communication
channels with families of residents by offering a family portal. In addition to establishing this goal,
the team went a step further to define what a successful EHR implementation initiative would
consist of. Team members then developed a core set of metrics—reduction in medication
errors, reduction in duplicate services, and increased communication with family regarding
residents’ health status. Family and caregiver satisfaction with communication were also
assessed.
St. Luke’s Medical Center
St. Luke’s Medical Center set out to implement a digital medical record, planning to do so in
three phases. Phase 1 would involve establishing a clinical data repository, a central database
from which all ancillary clinical systems would feed. Phase 2 would consist of the
implementation of computerized physician order entry (CPOE) and nursing documentation
systems, and Phase 3 would see the elimination of all outside paper reports through the
implementation of a document-imaging system. St. Luke’s staff members felt that if they could
complete all three phases, they would have, in essence, a true electronic or digital patient
record. The implementation team did not, however, clearly define the scope of its work. Was it to
complete Phase 1 or all three phases? Likewise, the implementation team never defined what it
hoped to accomplish or how implementation of the digital record fit into the medical center’s
overall mission or organizational goals. It never answered the question, How will we know if we
are successful? Some project team members argued that a digital record was not the same as

an EHR and questioned whether the team was headed down the right path. The ambiguity of the
implementation team’s scope of work led to disillusionment and a sense of failing to ever finish
the project.
Identify Accountability for the Successful Completion of the Project
Four roles are important in the management of large health care information system projects:
Business sponsor
Business owner
Project manager
IT manager
Business Sponsor
The business sponsor is the individual who holds overall accountability for the project. The
sponsor should represent the area of the organization that is the major recipient of the
performance improvement that the project intends to deliver. For example, a project that
involves implementing a new claims processing system may have the chief financial officer as
the business sponsor. A project to improve nursing workflow may ask the chief nursing officer to
serve as business sponsor. A project that affects a large portion of the organization may have
the CEO as the business sponsor.
The sponsor’s management or executive level should be appropriate to the magnitude of the
decisions and the support that the project will require. The more significant the undertaking, the
higher the organizational level of the sponsor.
The business sponsor has several duties:
Secures funding and needed business resources—for example, the commitment of people’s
time to work on the project
Has final decision-making and sign-off accountability for project scope, resources, and
approaches to resolving project problems
Identifies and supports the business owner(s) (discussed in the next section)
Promotes the project internally and externally and obtains the buy-in from business constituents
Chairs the project steering committee and is responsible for steering committee participation
during the life of the project
Helps define deliverables, objectives, scope, and success criteria with identified business
owners and the project manager
Helps remove business obstacles to meeting the project timeline and producing deliverables, as
appropriate
Business Owner
A business owner generally has day-to-day responsibility for running a function or a department;
for example, a business owner might be the director of the clinical laboratories. A project may
need the involvement of several business owners. For example, the success of a new patient
accounting system may depend on processes that occur during registration and scheduling
(and hence the director of outpatient clinics and the director of the admitting department will both
be business owners) and may also depend on adequate physician documentation of the care
provided (and hence the administrator of the medical group will be another business owner).

Business owners often work on the project team. Among their several responsibilities are the
following:
Representing their department or function at steering committee and project team meetings
Securing and coordinating necessary business and departmental resources
Removing business obstacles to meeting the project timeline and producing deliverables, as
appropriate
Working jointly with the project manager on several tasks (as described in the next section)
Project Manager
The project manager does just that—manages the project. He or she is the person who
provides the day-to-day direction setting, conflict resolution, and communication needed by the
project team. The project manager may be an IT staffer or a person in the business, or function,
benefiting from the project. Among their several responsibilities, project managers accomplish
the following:
Identify and obtain needed resources.
Deliver the project on time, on budget, and according to specification.
Communicate progress to sponsors, stakeholders, and team members.
Ensure that diligent risk monitoring is in place and appropriate risk mitigation plans have been
developed.
Identify and manage the resolution of issues and problems.
Maintain the project plan.
Manage project scope.
tasks. Together they set meeting agendas, manage the meetings, track project progress,
communicate project status, escalate issues as appropriate, and resolve deviations and issues
related to the project plan.
IT Manager
The IT manager is the senior IT person assigned to the project. In performing his or her
responsibilities, the IT manager does the following:
Represents the IT department
Has final IT decision-making authority and sign-off accountability
Helps remove IT obstacles to meeting project timelines and producing deliverables
Promotes the project internally and externally and obtains buy-in from IT constituents
Establish and Institute a Project Plan
Once the implementation team has agreed on its goals and objectives and has identified key
individuals responsible for managing the project, 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 members 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 (see Figure 6.1.). 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 “Typical Components of an Implementation Plan” box)
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.
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. In complex settings, it can be
critically important to have informatics professionals such as CMIOs and CNIOs actively
involved in the implementation team in analyzing workflow and information flow (Elias,
Barginere, Berry, & Selleck, 2015). 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, Koppel, Ridgley, Palen, Wu, & Harrison, 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, in which 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?
Typical Components of an Implementation Plan
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.
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 . . .
Staff training
Identify appropriate training method(s) to be used for each major user group.
Prepare training materials.
Train staff members.
Test staff member proficiency.
Update procedure manuals.
Conversion
Convert data.
Test system.
Communications
Establish communication mechanisms for identifying and addressing problems and concerns.
Communicate regularly with various constituent groups.
Preparation for go-live date
Select date when patient volume is relatively low.
Ensure sufficient staff members are on hand.

Set up mechanism for reporting and correcting problems and issues.
Review and effect process reengineering.
System downtime procedures
Develop downtime procedures.
Train staff members on downtime procedures.
Involving users at this early stage of the implementation process can gain initial buy-in to 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 members 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 members,
nurses, and physicians?
Will the e-prescribing function with local pharmacies be affected by the change?
System Installation
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 members 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 clinical application such as
order entry 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. Vendors will
often offer guiding principles and strategies that they have found effective in implementing
systems.
Consideration should be given to choosing an appropriate area (for example, a department or a
location) or set of users to pilot the system. Following are some of the questions the
implementation team should consider in identifying potential pilot sites:

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 members 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?
In migrating from one electronic system to another, such as from a legacy EHR to a new EHR,
it may be more appropriate to go-live at once, instead of a more staggered or phased approach.
For example, when Bon Secours Health System embarked on the implementation of an EHR
system among fourteen hospitals, they decided after the second hospital EHR implementation
to adopt the EHR vendor’s revenue cycle system along with the clinical application, and go-live
with both systems at once (Daly, 2016). This enabled them to monitor clinical and financial
indicators at the same time and ensure that the charge master and revenue cycle teams
worked collaboratively prior to and following implementation.
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:
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 members are
adequately trained? Will staff members 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 members 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 members. The trainer pool might include IT professionals (including clinical analysts) and
clinical or administrative staff members 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 enable 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 use; 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. Its purpose is to
enable users to practice on the system multiple times before go-live. 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 members will want to use the system in a
near-live or simulated environment. Additional staff members 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 members.
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.
Conversion
Another important task is to convert the data from the old system to the new system and then
adequately test the new system. Staff members 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 members who are 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 programming 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 members, and
user staff members 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. Again, 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.
Communications
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 members at all levels of the organization affected by the new system.
The communication plan may set up 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 members (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.
Preparation for System Go-Live

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 members are well trained, and appropriate procedures are in
place, the transition should be a smooth one. Additional staff members 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 members should be well trained on
what to do should the system go down or fail. Designated IT staff members should monitor and
assess system problems and errors.
System Downtime Procedures
One thing that you can count on is that systems will go down. Both scheduled and unscheduled
downtime exist, and downtime procedures need to be developed and communicated well before
go-live. Any negative impact will be minimized if 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
members to the nursing staff members to the medical staff members 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 Change and 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: 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.
Effecting Organizational Change
The management strategies required to manage change depend on the type of change. As one
moves from incremental to fundamental change, the magnitude and risk of the change increase
enormously, as does the uncertainty about the form and success of the outcome.
Managing change has several necessary aspects:
Leadership
Language and vision
Connection and trust

Incentives
Planning, implementing, and iterating (Keen, 1997)
Leadership
Change must be led. Leadership, often in the form of a committee of leaders, will be necessary
to accomplish the following:
Define the nature of the change.
Communicate the rationale for and approach to the change.
Identify, procure, and deploy necessary resources.
Resolve issues and alter direction as needed.
Monitor the progress of the change initiative.
This leadership committee needs to be chaired by an appropriate senior leader. If the change
affects the entire organization, the CEO should chair the committee. If the change is focused on
a specific area, the most senior leader who oversees that area should chair the committee.
Language and Vision
The staff members who are experiencing the change must understand the nature of the change.
They must know what the world will look like (to the degree that this is clear) when the change
has been completed, how their roles and work life will be different, and why making this change
is important. The absence of this vision or a failure to communicate the importance of the vision
elevates the risk that staff members will resist the change and through subtle and not-so-subtle
means cause the change to grind to a halt. Change is hard for people. They must understand
the nature of the change and why they should go through with what they will experience as a
difficult transition.
Leaders might describe the vision, the desired outcome of efforts to improve the outpatient
service experience, in this way:
Patients should be able to get an appointment for a time that is most convenient for them.
Patients should not have to wait longer than ten minutes in the reception area before a provider
can see them.
We should communicate clearly with patients about their disease and the treatment that we will
provide.
We should seek to eliminate administrative and insurance busywork from the professional lives
of our providers.
These examples illustrate a thoughtful use of language. They first and foremost focus on
patients. But the organization also wants to improve the lives of its providers. The examples use
the word should rather than the word must because it is thought that staff members won’t
believe the organization can pull off 100 percent achievement of these goals, and leaders do not
want to establish goals seen as unrealistic. The examples also use the word we rather than the
word you. We means that this vision will be achieved through a team effort, rather than implying
that those hearing this message have to bear this challenge without leadership’s help.
Connection and Trust
Achieving connection means that leadership takes every opportunity to present the vision
throughout the organization. Leaders may use department head meetings, medical staff forums,

one-on-one conversations in the hallway, internal publications, and e-mail to communicate the
vision and to keep communicating the vision. Even when they start to feel ill because they have
communicated the vision one thousand times, they have to communicate it another one
thousand times. A lot of this communication has to be done in person, where others can see the
leaders, rather than hiding behind an e-mail. The communication must invite feedback, criticism,
and challenges.
The members of the organization must trust the integrity, intelligence, compassion, and skill of
the leadership. Trust is earned or lost by everything that leaders do or don’t do. The members
must also trust that leaders have thoughtfully come to the conclusion that the difficult change
has excellent reasons behind it and represents the best option for the organization.
Organizational members are willing to rise to a challenge, often to heroic levels, if they trust their
leaders. Trust requires that leaders act in the best interests of the staff and the organization and
that leaders listen and respond to the organization’s concerns.
Incentives
Organizational members must be motivated to support significant change. At times, excitement
with the vision will be sufficient incentive. Alternatively, fear of what will happen if the
organization fails to move toward the vision may serve as an incentive. Although important,
neither fear nor rapture is necessarily sufficient.
If organizational members will lose their jobs or have their roles changed significantly, education
that prepares them for new roles or new jobs must be offered. Bonuses may be offered to key
individuals, awarded according to the success of the change and each person’s contribution to
the change. At times, frankly, support is obtained through old-fashioned horse-trading—if the
other person will support the change, you will deliver something that is of interest to him or her
(space, extra staff members, a promotion). Incentives may also take the form of awards—for
example, plaques and dinners for two—to staff members who go above and beyond the call of
duty during the change effort.
Planning, Implementing, and Iterating
Change must be planned. These plans describe the tasks and task sequences necessary to
effect the change. Tasks can range from redesigning forms to managing the staged
implementation of application systems to retraining staff members. Tasks must be allotted
resources, and staff members accountable for task performance must be designated.
Implementation of the plan is obviously necessary. Because few organizational changes of any
magnitude will be fully understood beforehand, problems will be encountered during
implementation. New forms may fail to capture necessary data. The estimate of the time
needed to register a patient may be wrong and long lines may form at the registration desk. The
planners may have forgotten to identify how certain information would flow from one department
to another.

These problems are in addition to the problems that occur, for example, when task timetables
slip and dependent tasks fall idle or are in trouble. The implementation of the application has
been delayed and will not be ready when the staff members move to the new building—what do
we do? Iteration and adjustment will be necessary as the organization handles problems created
when tasks encounter trouble and learns about glitches with the new processes and workflows.
Organizational and Behavioral Factors
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:
Create an appropriate environment, one in which expectations are defined, met, and managed.
Know your culture and do not underestimate user resistance.
Allocate sufficient resources, including technical support staff members and IT infrastructure.
Provide adequate initial and ongoing training.
Manage unintended consequences, especially those known to affect implementations such as
CPOE and EHR systems.
Establish strong working relationships with vendors.
Each of these strategies is described in the following sections.
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 such as 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.
Previously 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 members
might consider any change in their workload, public relations personnel might compare levels of
patient satisfaction, and the IT staff members 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 use is a priority,
collection of actual numbers of transactions or use 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 published the Health Information Technology
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 in which the bulk of your medical staff members 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 because of
inadequate use.

During the implementation process it is also important to analyze current workflow and make
appropriate changes as needed. Previously 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!) By 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. Historically most physicians were 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
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, care coordination, and patient health outcomes, using the system may be
far more enticing. A recent study among six health care organizations found that more senior
physicians often feel a loss of power by having junior physicians more comfortable with
computers than they are and a loss in power in the physicians’ ability to shift work to others
(McAlearney et al., 2015). That is, with the implementation of EHRs, the physicians were now
required to use the computers and input their orders rather than delegate the tasks to junior
physicians or nurses.
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 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 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 members, 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.
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 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 technical 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 members, 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.
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, scheduled and unscheduled, should be limited.
Provide Adequate Training
Previously we discussed the importance of training staff members 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
members 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 members were stationed at the clinical areas during the
implementation period for individualized assistance; 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 et al., 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 upfront 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. A decade ago, Ash and
colleagues (2007) conducted interviews with key individuals from 176 US hospitals that had
implemented CPOE. CPOE is one of the most complex and challenging of clinical applications
to implement and a key function of EHR systems. From their work, they identified eight types of
unintended consequences that implementation teams should plan for and consider when
implementing CPOE.

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, in
essence creating two distinct and sometimes conflicting patient 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.
Perspective
Unintended Consequences of CPOE
More work or new work. CPOEs can increase work because 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.
Workflow. CPOEs can greatly alter workflow, sometimes improving workflow for some and
slowing or complicating it for others.
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.
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.
Emotions. Clinician reactions to CPOE can run the gamut from positive to negative.
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.
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.
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.
Source: Adapted from Ash et al. (2007). Reproduced with permission of American Medical
Informatics Association.
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 members 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 members correct 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 optimizing 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. In fact, health care organizations that have
implemented EHR systems are now actively in the midst of optimizing use of the system in
practice (Sachs & Long, 2016). Optimization can take the form of additional training, revised
workflows, adding new features or functionality, or using data from the system for quality
improvement initiatives, as examples. Optimizing systems and assessing their value is
discussed in Chapter Seven.
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 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. Chapter Seven is devoted to this topic.
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 members,
(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 members 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
members 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
support and evaluate the new system, the health care executive should assume a leadership
role in managing change and 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.
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.
Cusack, C., & Poon, E. (2011). Health information exchange evaluation toolkit. Agency for
Healthcare Research and Quality. Retrieved February 2013 from
http://healthit.ahrq.gov/portal/server.pt/community/health_it_tools_and_resources/919/health_inf
ormation_exchange_(hie)_evaluation_toolkit/27870

Daly, R. (2016). The EHR evolution: New priorities and implementation changes. Healthcare
Financial Management (Feb.), 45–50.
Elias, B., Barginere, M., Berry, P. A., & Selleck, C. S. (2015). Implementation of an electronic
health records system within an interprofessional model of care. Journal of Interprofessional
Care, 29(6), 551–554.
Holden, R. J. (2011). What stands in the way of technology-mediated patient safety
improvements? A study of facilitators and barriers to physicians’ use of electronic health
records. Journal of Patient Safety, 7(4), 193–202.
Institute of Medicine (IOM). (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, Aug.). Guide
to reducing unintended consequences of electronic health records. Rockville, MD: Agency for
Healthcare Research and Quality.
Keen, P. (1997). The process edge. Boston, MA: Harvard Business School Press.
McAlearney, A. S., Hefner, J. L., Sieck, C. J., & Huerta, T. R. (2015). The journey through grief:
Insights from a qualitative study of electronic health record implementation. Health Services
Research, 50(2), 462–488.
Metzger, J., & Fortin, J. (2003). Computerized physician order entry in community hospitals:
Lessons from the field. Oakland, CA: 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, CA: California HealthCare Foundation.
Sachs, P. B., & Long, G. (2016). Process for managing and optimizing radiology work flow in the
electronic health record environment. Journal of Digital Imaging, 29, 43–46.
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, pp. 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.