Module 11 Week 11 NCM 110 Nursing Informatics

Part 11: System Life Cycle: A Framework
(Marina Douglas / Marian Celli)
OVERVIEW
In the past, clinical systems implementation projects were considered successful when
implemented on time and within budget. Later, the concepts of end-user perceptions
determining project success in conjunction with streamlining clinician workflow layered clinical
systems projects with additional success criteria. In the past five years, the focus for clinical
systems implementations has been on systems improving patient safety through evidence
based medicine while meeting the federal requirements set forth in the Health Information and
Technology for Economic and Clinical Health (HITECH) Act of 2009 (Trotter & Ulman, 2013).
As part of the HITECH Act, the Centers for Medicare & Medicaid Services (CMS), set
forth a program providing organizations who demonstrate the meaningful use of an EHR to
improve patient safety significant financial incentives. Today, the successful system
implementation project must be completed on time, within budget, and offer end users
streamlined workflow, with added safety in the delivery of healthcare and qualifying the
organization for the financial benefits of meeting the meaningful use requirements.
The System Life Cycle (SLC) outlined in this chapter discusses the tasks multiple
disciplines must accomplish to produce a technically sound, regulatory compliant and user-
friendly EHR supporting safe, effective, and efficient patient care delivery. The SLC framework
described by the American Nurses Credentialing Center’s Nursing Informatics, (2012)
(Available from http://www.nurse credentialing.org/Informatics-TCO2012) consists of four
major phases. The chapter further defines these phases into the key tasks of a practical clinical
systems implementation checklist and high-level workplan used successfully for real-world
implementations in the acute care setting. Many examples in this chapter refer to the
implementation of an EHR; however, the framework, phases, and tasks discussed can and
should be applied to any clinical system or application implementation.
ELECTRONIC HEALTH RECORD

The Electronic Health Record (EHR) is a longitudinal electronic record of patient health
information generated by one or more encounters in any care delivery setting. Included in this
information are patient demographics, progress notes, problems, medications, vital signs, past
medical history, immunizations, laboratory data, and radiology reports. The EHR automates
and streamlines the clinician’s workflow. The EHR has the ability to generate a complete
record of a clinical patient encounter—as well as support other care-related activities directly
or indirectly via interface (Anderson, 2011; Rouse, 2010).
The skills required to deliver direct patient care include the ability to understand and
coordinate the work of multiple disciplines and departments. As multiple departments work in
concert for optimum and safe patient care delivery, the components of an EHR integrate data
in a coordinated fashion to provide an organization’s administration and clinicians
demographic, financial, and clinical information. The SLC provides a framework to attain a
successful implementation.
CURRENT LANDSCAPE
NCM 110 (Nursing Informatics) Page 1 of 26
The U.S. government has become one of the largest payers of healthcare. As the costs
of healthcare increase, both the U.S. population as well as the US government have become
more critical of a payer-based health system. Four factors impacting healthcare payments and
hospital information systems implementations are the evolution of evidence-based
healthcare/medicine, the Federal Meaningful Use requirements set forth in the HITECH Act of
2009, the cost of technology, and the use of Project Management principles.
Evidence-Based Medicine (EBM)

Both the Cochrane Collaboration and the Centre for Evidence Based Medicine have
adopted the definition of EBM as “…the conscientious, explicit, and judicious use of current
best evidence in making decisions about the care of individual patients” (Sachett, Rosenberg,
Gray, Haynes, & Richardson, 1996). The purpose of EBM is to utilize scientific studies to
determine the best course of treatment. Functionality within the EHR provides access to the
studies to understand the recommended treatment while reviewing a patient’s data in real time
(Timmermans & Mauch, 2005).
Federal Initiative—HITECH Act 2009. This act seeks to promote the meaningful use of
information technology to improve patient safety in healthcare delivery. The initiative requires
an organization or provider to demonstrate consistent and appropriate use of information
technology. Adoption of the technology is required in stages, with increasing numbers of
requirements in each stage. Federal financial incentives are awarded to those meeting each
stage. Financial penalties will be levied against organization failing to meet the requirements
by 2016 (Trotter & Ulman, 2013).
The Meaningful Use requirements leverage the results published in studies indicating
a marked increase in patient safety when specified functions of an information system are
utilized. In addition, standardized terminology criteria permitting comparison of healthcare
treatments and outcomes across healthcare facilities are incorporated into the later HITECH
Act’s stages. Legislative and legal aspects of informatics are discussed in another chapter.
Technology: Cost, Benefit, and Risk. Technology costs are high, increasing the risk of
significant financial losses from a poor implementation. Vendors deliver the same software to
clients; the success of an information system project often rests on a well-planned and well-
executed implementation. A well-planned implementation dovetails an organization’s strategic
goals and culture, with the introduction of and ability to assimilate technology and workflow
changes into the daily practice of healthcare delivery. The SLC provides a structured
implementation approach to accomplish this.
Healthcare information systems implementation time lines are often long, spanning 10
to 16 months for a full hospital information system implementation.
Increasing a project’s risk level, a technology generation, now only 6 to 8 months in
length, can render partial obsolescence of a system by one technology generation before the
first productive use of a system is sometimes obtained. A well-planned and executed
implementation, on the other hand, provides a high level of risk mitigation and cost
containment. It is important to remember that technology is not the best solution to every
problem; failure to recognize problems caused inefficient processes from an information
system problem contributes to the risk and potential costs of a system.
Project Management
With roots in the construction industry, a significant body of knowledge in the area of
planning and tracking large-scale projects has evolved. The Project Management Institute
(PMI) has become the central and certifying organization for project management
professionals. The Project Management Plan (PMP) developed through their efforts has
migrated to the Information Technology (IT) area and is commonly called a project workplan
(PMI, 2014). It is the main planning document for an IT project and describes how major
aspects of the project will be executed and managed. The workplan is a living document,
updated continually throughout the project. Nurses have the ability to coordinate and manage
multiple diverse care situations; this affords them strong skills to manage complex projects
using a Project Workplan as a primary tool (Wilson, 2012). See also Chapter 14 which is
devoted to Project Management.
A second essential tool for clinical implementations is the project’s “issues list.” As
concerns, unusual situations, special education/training needs, programming errors,
sequencing concerns impacting workflow, and new regulations are uncovered, they are placed
on the issue’s list. Issues are added to the list and prioritized in relation to other issues and to
the project goals and given a status. Examples of issue statuses are open, in progress, testing,
and closed. The progress of an issue is tracked by the team on a regular basis with short
progress notes added to the issue. When a resolution is reached, the resolution is documented
in the issue’s list and the status is updated. The resolution documentation detail helps
eliminate the need for the team to revisit the decision.
Suggested data elements in an issue’s list are as follows:
•Issue number
•Status
•Date added to the list
•Person identifying the problem/adding it to the list
•Module/application involved
•Description of the problem/issue
•Type of problem (e.g., programmatic, training, process, hardware, network)
•Note date
•Notes (e.g., work/efforts to resolve issue)
•Responsible party
•Resolution date
•Resolution description
SYSTEM LIFE CYCLE

The System Life Cycle is defined by the major components of (a) Planning, (b)
Analysis, (c) Design/Develop/Customize, and (d) Implement/Evaluate/Maintain/Support.
While this chapter discusses phases of the SLC related to an EHR implementation in an acute
care setting, it is applicable to many healthcare settings and projects. To continue to meet new
regulatory and professional standards, EHRs and software applications must be continuously
updated and upgraded in the Maintenance Phase (Wilson, 2012).
Regardless of the size or type of the system, any EHR, single application
implementation, or upgrade project, should address each of the items on the clinical system
implementation checklist in Fig. 11.1. Though not every project will require interfacing or data
conversion or the addition of new devices, review of the checklist’s steps will assure essential
considerations are not overlooked (Fig. 11.1).
System Life Cycle Clinical Software Implementation Major Tasks

Phases
Planning Governance StructureProject Purpose
Project Scope DocumentResource Planning
Analysis Technical Requirements Functional Design Document System Proposal Document

Design, Develop, and Design
Customize Functional SpecificationsTechnical Specifications
Develop Focused Plans
Customize
System Dictionary Data and ProfilesPolicies and Procedures
Implement, Evaluate, ImplementPlans

Support, and Maintain Policies and ProceduresLive Operations
Cut Over and Go Live PlansEvaluate›post-live
Daily support operationsOngoing maintenance
• FIGURE 11.1. SLC Stages in Relation to ClinicalSoftware Implementation Checklist.

The SLC phases use a problem-solving, scientific approach. Problem solving begins
with observation and understanding of the operations of the current systems or processes,
sometimes referred to as the “Current State.” The second phase requires an in-depth
assessment and definition of the new system’s requirements: defining the “Future State.”
Designing, developing, and customizing a plan to meet requirements are addressed in the
third phase. The last phase, implementing, evaluating, supporting, and ongoing maintenance,
assures the system is sustainable after implementation.
Nurses’ daily use of the Nursing Process, a problem-solving methodology, underlies
the successes nurses have achieved in clinical informatics. Countless iterations of the
problem-solving methodology are used during the implementation and updating/upgrading of
software.
Inherent in the implementation process is the need to recognize and manage change
and its impact on patient care delivery and clinician work patterns/workflow. “The ability to
manage change often marks the difference between the success and failure of implementing
a change initiative and moving an organization forward” (Ritter & Glaser, 1994, p. 168). Often,
finding a balance between the technical data capture criteria and the daily workflow of
clinicians is required. Details are discussed in Chapter 13, System Life Cycle Tools.
As noted, vendors supply essentially the same software to clients at the time of
purchase. The abilities of the project team members and organization to introduce and
assimilate changes into daily practice can determine the success of a project. Literature
focusing on the workflow impact of an EHR and the cultural impact to an organization are well
documented by the Project Management Institute (PMI) and the Healthcare Information
Management Systems Society (HIMSS). Ash et al. (2000), Augustine (2004), Kaplan (1997),
Lorenzi and Riley (2000) all stress the need to manage the change process foundational to
an EHR implementation if success is to be attained.
Attempting to implement or upgrade a system without reviewing each of the checklist
items within the SLC framework generally results in failure in one or more of the following
areas:
•EHR or application does not meet the stated goal of the project.
•There is failure to gain end-user acceptance.
•Expenditures exceed budget.
•Anticipated benefits are unrealized.
In recent years the quality and abundance of online resources specific to clinical
systems implementation have grown significantly. Due in large part to the Federal HITECH
meaningful-use requirements, the PMI and HIMSS both offer training and certification
processes specific to healthcare-related projects.
The following online sites provide additional and supporting information:
www.pmi.org www.himss.org
www.cms.gov/EHRincentivePrograms
www.hhs.gov/ocio/eplc/Enterprise%20
Performance%20Lifecycle%20Artifacts/eplc_ artifacts.html
www.hitechacthelp.com/2010/05/25/ understanding-the-state-hie-toolkit/
www.ahima.org/advocacy/rec/default.aspx www.healthit.hhs.gov/portal/server.pt/community/
healthit_hhs_gov_home/1204
PLANNING PHASE
The planning phase of the project begins once an organization has determined an
existing requirement may be filled or solved by the development or implementation of an EHR
or application. Establishing the committee framework to research and making
recommendations for the project are an important first step.
The key documents created in the Planning Phase are the following:
•Project Governance Structure
•Gap Analysis
•Feasibility Study
•Project Scope Document
•Development of a high-level workplan and resource requirements
Governance Structure and Project Staff

The clinical leadership of an organization is highly involved in the establishment of an
EHR committee structure. The organization’s strategic goals and priorities must be reviewed
and considered. The informatics nurse and information systems management team provide
oversight; however, committees work to develop the structure and participate to best
guarantee the success of the project. Assigning the appropriate resources, whether financial
or personnel, is a critical success factor (McCormick & Gugerty, 2013; Protti & Peel, 1998;
Schooler & Dotson, 2004; Trotter & Ulman, 2013).
Recent evaluations of both successful and less than successful implementations have
stressed the need to anticipate the impact of the new system on the culture of the organization
and to take active steps to mitigate the effects of change on the organization (Lorenzi & Riley,
2000; Peitzman, 2004). Transition management is a series of “…deliberate, planned
interventions undertaken to assure successful adaptation/assimilation of a desired outcome
into an organization” (Douglas & Wright, 2003). The nursing informaticist often leads the
assessment and documentation of the “Current State” and development of the desired “Future
State.” Cognizance of the new system’s impact serves as a visible leader in the transition
management efforts.
Steering Committee
Before an EHR is developed or selected, the organization must appoint an EHR
steering committee. The EHR steering committee, composed of internal and external
stakeholders, is charged with providing oversight guidance to the selection and integration of
the organization’s strategic goals relative to the EHR requirements. During the planning
phase, the projected return on investment (ROI) is established. The Steering Committee
members’ collective knowledge of the organization’s daily operations provides global insight
and administrative authority to resolve issues. In most facilities, the Steering Committee has
the ultimate authority for decision-making (Fig. 11.2).
Project Team
The project team is led by an appointed project manager (often the Nurse Informaticist)
and includes a designated team leader for each of the major departments affected by the
system selection, implementation, or upgrade proposed. The objectives of the project team
are to (1) understand the technology and technology restrictions of the proposed system, (2)
understand the impact of intradepartmental EHR decisions, (3) make EHR decisions at the
interdepartmental level, and (4) become the key resource for their application. A stated goal
for the selection, implementation, or upgrading of an EHR is to improve patient safety and
care; gains made by one department at the expense of another department rarely work to
improve overall patient safety and care delivery. The project team’s ability to evaluate multiple
departments’ information requirements in light of the capabilities of the proposed system is
integral to overall success. Issues unable to be resolved by the Project Team are presented
to the Steering Committee for resolution (Fig. 11.3).
The project manager is responsible for managing all aspects of the project; this
includes software application development, hardware, and network acquisition/readiness, as
well as oversight of the interface and conversion tasks. The project manager must possess
good communication, facilitation, organizational, and motivational skills when leading a
successful implementation. A sound knowledge of healthcare delivery, regulatory
requirements, and hospital culture, processes, and politics is essential.
CIS/EHR Steering Committee
CIO/CFO – Chair
Project Team
Project Manager - Chair
Team Leaders for each
major unit/department affected
Department Team Department Team Department Team Department Team

Team Leader – Chair Team Leader – Chair Team Leader – Chair Team Leader – Chair
Pharmacy Nutritional Service Radiology Finance

Team Leader – Chair Team Leader – Chair Team Leader – Chair Nursing Team Leader – Chair
Laboratory Registrations/ Admissions Medicine

Team Leader – Chair Technical Manager – Chair Team Leader – Patient Team Leader – Chair Health
Quality/Management/ Accounting Information Management
Utilization Review
Interface Team Conversion Team Hardware and Systems Team Network Team
• FIGURE 11.2. Clinical Information System Steering Committee Structure.
Representative
• FIGURE 11.3. Application Implementation Committee Structure.

Departmental Teams
The charge of the departmental teams is (1) to thoroughly understand the department’s
information requirements and workflow, (2) to gain a full understanding of the software’s
features and functions, (3) to complete a gap analysis for the new system’s capabilities with
the department’s requirements, (4) to assist in the system testing effort, (5) to participate in
developing and conducting end-user education, and (6) to provide a high level of support
during the initial activation period of the new system. The team leaders must possess a sound
knowledge of the hospital and departmental policies and procedures (both formal and
informal), and good organizational and communication skills, and must be adept at gaining
consensus and resolving conflict.
Team members may well change during the course of a 10- to 16-month
implementation. Hospital leaders, visionaries, and change agents’ participation must balance
the pragmatic, bottom line dictated by organizational needs (e.g., meaningful use incentives
vs. patient outcomes). Shabot (2004) notes, “…both excellent leaders and excellent followers
will be needed to make the new clinical information system a success” (p. 269).
DEVELOP PROJECT SCOPE

During the planning phase, the problem statement and goals of the implementation are
defined, committee structures established, and the organization’s requirements are defined
for selecting, implementing, or upgrading an EHR or application, including the implications for
regulatory compliance for safe and quality clinical practice. Commercial software developers
and consultants rank this phase as the most critical factor in the selection of a system, even
more important than the system itself (Zinn, 1989). Excellent planning takes time and
thoughtful consideration. Time spent in developing a sound plan that encompasses all the
checklist steps will reduce the amount of time spent in reworking areas not reviewed during
the planning phase. Plan the work and then work the plan.
The planning phase involves the following tasks:
•Definition of committee structure
•Definition of requirements and/or stated goal
•Feasibility study
•Gap analysis
•Documentation and negotiation of project scope document
•Development of a high-level workplan
•Allocation of resources
Definition of the Project’s Purpose

Definition of the project’s purpose/stated goal is essential and often not readily
apparent. Not until the information requirements of the project and/or stated goal and
outcomes are precisely defined will the real characteristics of the requirements be revealed
(Fitzgerald, Fitzgerald, & Satllings, 1981).
The project definition includes a description of how the system will be evaluated.
Establishing the evaluation criteria early in the process supports the successful management
philosophy of beginning with the end in mind (Convey, 1992). The results and improvements
expected from implementing the system are described by realistic goals for the system. They
might include increased functionality, decreased costs, increased personnel productivity, and
meeting Federal Meaningful Use requirements. When updating or expanding the EHR or
application, the project definition includes the identification of equipment currently available,
its age, the degree of amortization, and the need for hardware or operating system software
upgrades prior to undertaking an upgrade project.
Feasibility Study

A feasibility study is a preliminary analysis to determine if the proposed problem can
be solved by the implementation of an EHR or component application. The feasibility study
not only clarifies the problem and/or stated goal but also helps identify the information needs,
objectives, and scope of the project. The feasibility study helps the EHR steering committee
understand the real problem and/or goal by analyzing multiple parameters and by presenting
possible solutions. It highlights whether the proposed solution will produce usable products
and whether the proposed system’s benefits more than justify the costs. Operational issues
are reviewed to determine if the proposed solution will work in the intended environment.
Technical issues are reviewed to ensure the proposed system can be built and/or will be
compatible with the proposed and/or current technology. Legal and statutory regulations are
reviewed to ensure compliance with local and federal law. The feasibility study includes a high-
level description of the human resources required and how the selected system will be
developed, utilized, and implemented. The feasibility study describes the management
controls to be established for obtaining administrative, financial, and technical approvals to
proceed with each phase of the project. The feasibility study seeks to answer the following
questions:
•What is the real problem to be solved and/or stated goal to be met?

•Where does the project fit into the overall strategic plan of the organization?
•What specific outcomes are expected from the project?
•What are the measurable criteria for determining project success from the above
outcomes?
•What research and assumptions support the implementation project?
•What are the known limitations and risks to the project?
•What is the timing of the remaining phases of the project?
•Who will be committed to implementing the project?
•What are the estimated costs in both dollars and personnel time?
•What is the justification for the project, including the relationship between costs and
benefits?
A feasibility study includes the following topic areas.
Statement of the Objective

The first step in conducting a feasibility study is to state the objectives for the proposed
system. These objectives constitute the purpose(s) of the system. All objectives are outcome-
oriented and are stated in measurable terms. The objectives identify the “end product” by
defining what the EHR will do for the end users.
Environmental Assessment
The project is defined in terms of the support it provides to both the mission and the
strategic plans of the organization. The project is evaluated relative to the organization’s
competition. The impact of legal, regulatory, and ethical considerations is reviewed. The
regulatory impact of the Meaningful Use criteria is far reaching. Often one resource is assigned
to assure each Meaningful Use criteria will meet the HITECH requirements. Individual software
vendors often provide “best practice” guidelines demonstrating their software’s intended
functionality relative to Meaningful Use criteria.
Scope
The scope of the proposed system establishes system constraints and outlines what
the proposed system will and will not produce. Included in the scope are the criteria by which
the success of the project will be judged. The Scope Document outlines the boundaries of the
project, establishes responsibilities for each team members, and sets up procedures as to
how completed work will be verified and approved (Rouse, 2012).

Timeline
A project timeline is developed providing an overview of the key milestone events of
the project. The projected length of time for each major phase of the project is established.
Often called a project workplan, the major steps required for project are outlined in sufficient
detail to provide the steering committee background on the proposed development or
implementation process.
Recommendations
Committees may lose sight of the fact that not all projects are beneficial to the strategic
mission of the organization. A decision can be made not only to proceed but also not to
proceed with a project. The viability of the project is based on the review of the multiple factors
researched in the feasibility study. It is critical to consider whether more personnel or
equipment is necessary rather than more computerization. In addition to identifying potential
hardware and software improvements, the costs and proposed benefits are factored into the
project’s viability decision. In upgrading or considering expansion of a system, a concerted
effort to maximize use of the current system and to make process improvements in the current
management and coordination of existing systems should be undertaken before deciding to
procure a new system(s). If, based on the findings of the feasibility study, the project steering
committee determines to continue with the project, a project scope agreement is prepared.
Documentation and Negotiation of a Project Scope Document

A project scope document is drafted by the project team and submitted to the project’s
steering committee for acceptance. The project scope document includes the scope of the
project, the application level management requirements, the proposed activation strategy for
implementing the EHR or application, and the technical management and personnel who will
implement and maintain the equipment and programs. The Scope Document is based on the
findings of the feasibility study. The project scope document becomes the internal
organizational contract for the project. It defines the short-and long-term goals, establishes
the criteria for evaluating the success of the project, and expands the workplan to include
further detail regarding the steps to be accomplished in the development or implementation of
a system or application.
Resource Planning
An important step in the planning phase is to determine what resources are required
to successfully carry out the agreed upon project scope. A firm commitment of resources for
development of the entire EHR project includes all phases of implementation and is for the
system to fulfill its stated objectives. The following points should be considered when planning
for resources:
•Present staffing workload
•Human resources (i.e., number of personnel, experience and abilities, and percentage
of dedicated time to the project)
•Present cost of operation
•Relationship of implementation events with non-project events (e.g., The Joint
Commission accreditation process, state certification inspections, peak vacation and census
times, union negotiations, and house staff turnover)
•Anticipated training costs
•Space availability
•Current and anticipated equipment requirements for the project team
Highly successful projects have spent the requisite amount of time to thoroughly
complete the planning phase. Further, successful organizations have communicated senior
management and administration’s project expectations through dissemination of the project
scope document to all departments in the organization.
ANALYSIS PHASE
The system analysis phase, the second SLC phase of developing an EHR, is the fact-
finding phase. All data needs related to the requirements are defined in the project scope
agreement developed in the Analysis Phase.
Key documents created in this phase are the following:
•Gap Analysis
•Technical requirements for hardware, software, networks
•Functional Design Document
•System Proposal Document
Data Collection
The collection of data reflecting the existing problem or goal is the first step in the
system analysis phase. As a result of thorough data collection, refinements to the project
scope agreement may occur. Added benefits to the organization may be realized through the
small refinements. Larger project scope refinements should be carefully researched and
evaluated (using the steps outlined in the feasibility study methodology) prior to requesting a
major project scope change. Large or small, all changes must continue to support the goal(s)
of the project and the strategic plan of the organization.
Two important documents are created as a result of data collection. The first is the
creation of a workflow document for each major goal or problem to be resolved by the
implementation of the new software or system; the second is a functional design document
outlining how the new system will resolve the identified goals/problem.
Gap Analysis
Drawing on the work completed in the Planning phase, the workflow document, and
the system proposal document from the analysis phase, a comparison of what is available in
the current processes and what is desired in the new system is completed. Often referred to
as a Gap Analysis, the comparison provides the project team with a list of features and
functions desired but not immediately available in the new system/application. The
departmental teams review the features/functions and estimated costs, evaluate alternatives
to achieving them, and make recommendations to the Steering Committee. Features/
functions may be delayed to a subsequent activation phase of the project, lobbied for inclusion
in the current activation plan, or eliminated from the project.
Data are collected and analyzed to gain a sound understanding of the current system,
“Current State,” how it is used, and what is needed from the new system. Process analysis is
foundational to the actual system design, since it examines the objectives and project scope
in terms of the end-user requirements, the flow of information in daily operation, and the
processing of required data elements.
Through the analysis effort, the individual data elements, interfaces, and EHR
decision points of the project are identified (www.pmi.org). The “Future State”—how the
system will look and function upon completion of the implementation begins to take shape.
The review of requirements of the Americans with Disability Act (www. ada.gov/) is done to
assure compliance with special needs of staff. Stakeholders review the document to assist in
the prioritization of problems/issues to be resolved. Current costs and resources required for
processing the organization’s volume of data are compared with estimates for the cost of
processing with the new system. If a system is being upgraded or expanded, the current
equipment and functions are described. Careful evaluation is undertaken to ensure
compatibility with the new system’s requirements and to maximize the use of available
equipment as long as possible. Depreciation costs of available equipment and projected
budget expenditures are reviewed.

The importance of this phase should not be underestimated. Design changes made
during the analysis stage often add minimal costs to the project; as the project progresses to
the development and implementation phases, the cost of programmatic or design changes
increases dramatically. According to one source, when a project is in the planning phase, the
relative cost to make a design change or fix an error is one; in the analysis phase, the relative
cost to fix the error/design change is three to six times that of the planning phase. The relative
cost to fix an error or change a system design jumps to 40 to 1000 times once the system is
operational.
Technical Analysis
A review of the project’s technical requirements is conducted in the Analysis Phase.
Trained/certified technical personnel review the requirements for EHR software to run
efficiently. This may include programs to run the EHR software, hardware, and networks.
Physical requirements for space, electrical needs, and air conditioning/cooling are considered.
A technical architecture is developed to assure the speed of data transmissions, and sufficient
storage capability to meet clinical and financial requirements over time. These requirements
in conjunction with costs are evaluated and compiled into technical recommendations for the
project.
Determination of Information Needs

A needs assessment outlines the high-level information required by multidisciplinary
users. Standard terminology use as defined by the Centers for Medicare & Medicaid Services
(CMS) and the Office of the National Coordinator for Health Care Information Technology
(ONC) is critical to meeting Federal Meaningful Use requirements. The numbers of federally
mandated data elements are significant, and increase with each Meaningful Use stage.
Planning for the data collection across an organization’s multiple departments and clinician
workflow is imperative to successfully meeting the requirements of the HITECH Act. Workflow
review and identification of the information needed clarify what users will expect from the
system and how it can be collected in the course of daily operations. Such knowledge is
essential in designing the system’s output, input, and processing requirements constituting
the basis for the new “Future State.”
Workflow Document
The workflow document assimilates the data collected into logical sequencing of
functions/tasks performed by the end users for each goal or problem area. Departmental
standards of care, ordering patterns, procedures, operating manuals, reports (routine,
regulatory, and year-end), and forms used in day-to-day operations are collected. Individual
data elements required by clinicians in each department are identified and analyzed for
continuity, duplication, and cross-referenced to the required HITECH data elements. The
workflow document includes the following:
•A list of assumptions about the process or work effort
•A list of the major tasks performed by the user
•A list of the subtasks and steps the user accomplishes and outlines
•The determination of optional or required status for each task
•The frequency of the task being performed
•The criticality and important factors of the tasks/ subtasks
•The order of the subtasks
•The number and frequency of alternate scenarios available to the end user to accomplish a
particular task
There are multiple sources of data for completing a workflow document. These include
the following:
•Written documents, forms, and flow sheets
•Policy and procedure manuals
•Questionnaires
•Interviews
•Observations
•Development of workflow diagrams utilizing available software is most helpful in documenting
the flow of information, people, and processes involved in the “Current State.” The graphic
representation provided by workflow diagrams allows a clear visualization of the gains
proposed in the “Future State.”
Functional Design Document

The functional design document is the overview statement of how the new system will
work. It uses the workflow documents as its base, adding the critical documentation of the
integration of each of the workflow documents to create a new system, implement a
commercial software application, or upgrade a system. The functional design document, in
this phase, outlines the human and machine procedures, the input points, the processing
requirements, the output from the data entry, and the major reports to be generated from the
new system. The functional design is a description of the functions required from the proposed
EHR system or component and describes how tasks will be accomplished. From the functional
design document, database structure will be determined.
Two data types are often used in databases—free text data (allowing the user to
describe a response in their own words) and discrete data (structured data presented in
application via check boxes or drop-down lists). Discrete data elements with links to standard
terminology are the preferred data type. They increase the ability to report on and compare
data. Meaningful Use 2014 requirements include the use of structured data linked to standard
terminologies such as SNOMED-CT (Structured Nomenclature of Medicine—Clinical
Terminology) and LOINC (Logical Observation Identifiers Names and Codes) used for
laboratory tests. See also Chapter 8, Standardized Nursing Terminologies.
When new software is being created, the functional design document provides the
programmers with a view of screens, linkages, and alternate scenarios to accomplish a task.
Initial programming efforts can begin once the functional design is accepted. In the instance
where a commercially available system or application is being implemented, the functional
design outlines how the end users will use the system’s programs to accomplish their tasks.
In some cases, commercial software provides multiple pathways to accomplish a single task;
the functional specification may suggest deploying a limited number of available pathways.
Data Analysis
The analysis of the collected data is the second step in the analysis phase. The
analysis provides the data for development of an overview of the clinical requirements and/or
stated goal defined in the project scope agreement.
Several software tools can be used in the development of the workflow and functional
design documents and are discussed in Chapter 12, System and Functional Testing.
Data Review
The third step in the analysis phase is to review the data collected in the feasibility
study, the workflow documents, and the functional specification and provide recommendations
to the project steering committee for the new system. The review focuses on system
requirements and/ or attaining the project goals outlined in the feasibility study based on the
best methods or pathways derived from the workflow documents and the functional design.
Recommendations for streamlining workflow are suggested. The success of an EHR
implementation project rests on the ability of the departmental and project teams to analyze
the data and propose solutions benefiting the total organization without favoring certain
departments at the expense of others. The benefits of a thorough structured analysis provide
objective data to support the EHR. The careful analysis of end-user requirements and potential
solutions has been proved to reduce the cost of design and implementation (Gause &
Weinburg, 1989).
Benefits Identification
The overall anticipated benefits from the system are documented in the fourth step in
the system analysis process. The benefits are stated in quantifiable terms and become the
criteria for measuring the ROI and success of the project.
System Proposal Development

The final document created in the system analysis stage is a system proposal
document. The proposal is submitted to the project’s steering committee for review and
approval. It sets forth the problems and/or goals and the requirements for the new system’s
overall design. It outlines the standards, documentation, and procedures for management
control of the project, and it defines the information required, the necessary resources,
anticipated benefits, a detailed workplan, and projected costs for the new system. The system
proposal furnishes the project steering committee with recommendations concerning the
proposed EHR or application. The system proposal document answers four questions:
1. What are the major problems and/or goals under consideration?

2. How will the proposed EHR solution correct or eliminate the problems and/or accomplish
the stated goals?
3. What are the anticipated costs?
4. How long will it take?
The system proposal describes the project in sufficient detail to provide a management
level understanding of the system or application without miring in minutiae. Much of the
information required in the system proposal is collected in the earlier phases of the analysis.
It has been suggested this proposal is best accepted when presented as a business proposal
and championed by a member of the project’s steering committee. The format of the final
system proposal includes the following information:
•A concise statement of the problem(s) and/or goal(s)
•Background information related to the problem
•Environmental factors related to the problem
•Competition
•Economics
•Politics
•Ethics
•Anticipated benefits
•Proposed solutions
•Budgetary and resource requirements
•Project timetable
Acceptance of the system proposal by the project steering committee provides the
project senior management support. Following acceptance by the project steering committee,
it is not unusual for major EHR proposals to be presented to the institution’s governing board
for their acceptance and approval and to receive funding. Often the requirement for board
approval is dependent on the final cost estimates of the system. Acceptance of the proposal
by the project steering committee and the governing board assures not only funding for the
project but critical top-down management and administrative support for the project. The final
system proposal is an internal contract between the EHR committees/teams (steering, project,
and departmental) and the institution.

As noted earlier, the active support and involvement of all senior executives in the
development of the feasibility study are essential. The championing of the final system
proposal greatly enhances the chances of acceptance of the system proposal.
SYSTEM DESIGN, DEVELOPMENT, AND CUSTOMIZATION PHASE ______________

In this phase, the design details to develop the system and the detailed plans for
implementing and evaluating the system evolve for both the functional and the technical
components. Data dictionaries are populated with entries and project team’s work to assure
the functional design supports the clinician and departmental workflows. Policies and
procedures are reviewed and updated to reflect the use of the new application/system in the
delivery of care. Thorough testing of the new system occurs and detailed plans, developed in
this, as well as previous phases, are executed.
There are multiple project documents created in this phase:
•Gap Analysis
•Functional specifications
•Technical specifications
•Implementation Workplan containing detailed plans specific to
•Hardware and Peripheral Devices
•Interfaces
•Conversions
•Testing
•End-User Training
•Cut Over Plan
•Go Live Plan
•Post-Live Evaluation Reports
System Design
The project teams receive application training often directly from the vendor. In some
cases a limited number of team members attend training with the expectation they will train
other team members. The Project Teams determine the best utilization of functionality based
upon the identified elements of project goals, scope, software functionality, and the
organization’s workflow. The definition of current workflow, documented in the analysis phase,
serves as the bases for changes, both programmatic and process-oriented, required to
support the new system’s workflow.
Functional Specifications. The functional specifications use the functional design document
developed in the system analysis phase of an EHR and builds on the design by formulating a
detailed description of ALL system inputs, outputs, and processing logic required to complete
the scope of the project. It further refines what the proposed system will encompass and
provides the framework for its operation.
Commercial software vendors generally provide a detailed functional specification
document for their system or application in the form of manuals. The manuals, usually
application-specific, include an introduction, a section for each workflow, and a technical
section. From the provided documentation, the hospital’s departmental and project teams
produce the organization’s functional specification by evaluating the available commercial
software’s functions with the organization’s workflow documents and making decisions on the
functionality to be used by the institution.
The detailed functional specifications are critical to the system’s acceptance; each
screen, data flow, and report the user can expect to see is analyzed. The examples
incorporate real data into the explanations and drawings. The technical aspects of the HITECH
Act and Meaningful Use criteria must be fully understood and followed carefully including the

use of both evidence-based medicine links and clinical decision support rules for patient safety
within clinical workflows. Additional information can be found at
http://www.healthit.gov/providers-professionals/ehr-implementation-steps/step-5-
achieve-meaningful-use.
During this step, the departmental teams and users determine what the actual data will
look like in its output form, and they gain consensus from the departmental teams for the
proposed workflow design. Requirements for meeting the HITECH Meaningful Use data
collection are integral to completing the functional specifications. In-depth understanding of
the federal criteria, layered with thoughtful implementation planning and execution, will lead to
staff’s universal adoption of new data collection and data sharing procedures.
There is fluidity between the functional specification and initial programming prototype
efforts. The design team creating the new application often works closely with the
programmers, making adjustments in the design and specification based on federal
requirements, programming logic, newly identified information needs, and/ or technologies. As
the functional specification matures and major design decisions (e.g., selection of the
underlying application technology and database structure) have occurred, a design freeze
point is established. This indicates the functional specification is complete and full
programming efforts can begin.
Once completed, the functional specification provides not only the road map for
programming efforts but also the starting point for developing testing and training plans. The
advantages of establishing testing plans in concert with the development of the functional
specification include a more thorough test plan (workflows are not missed), and “what if”
questions often spark the need to develop or allow alternate workflow.
Technical Specifications
In the system design phase, technical personnel work closely with the project and
departmental teams to ensure the components of the proposed system work in concert with
technology and end-user needs and to assist in the development of the implementation plan.
A dedicated technical manager is required. He or she is responsible for the coordination of
efforts in five major areas: hardware, networks, software, interface application, and legacy
system data conversion. Detailed technical specifications are developed for each area. The
project’s technical manager and team leaders ensure all of the components/applications of
the EHR work in concert with all the other components.
Hardware
In the case of new software development, the technical project manager ensures the
new software uses the best technology platform available. The ability to operate the new
application on multiple hardware platforms is often desired. Technical specifications
describing the recommended equipment are developed and tested in the development
laboratory.
When commercial software is being implemented or upgraded, the technical project
manager ensures the physical environment for the new system conforms to the new system’s
technical specifications. This may include the need to build a new computer room, establish
or upgrade a network, and procure the correct devices for the new system. The types of
devices to be used (mobile PCs vs. handheld vs. bedside devices) require dialog and testing
with team leaders and department team members. The testing and deployment of the new
equipment (terminals, multiple types of printers [e.g. card, label, prescription], Internet output
[e.g. electronic prescription systems], and/or wireless devices) are the responsibility of the
technical manager. Ongoing maintenance requirements for the new system’s processing unit,
operating systems, and network are coordinated by the project’s technical manager.
Selecting the correct hardware for the system depends on its design, application, and
software requirements. Technical conditions may dictate selection of a mainframe, a
minicomputer, a microcomputer, or a combination of the above. Computer hardware is
obtained in several different ways. Central processing may be purchased or leased from a
hardware vendor for in-house use; however, when cost is a significant factor, timesharing
computer processing with other facilities may be considered. Many Internet Web-hosted
medical applications are now available. The technical manager must evaluate such offerings
in light of interoperability with the main hospital information system as well as data security
during transmissions to and from the Web. Input, output, and processing media, including
secondary storage, are selected.
Peripheral Device Plan

Knowledge of the many clinical workflows is an important component of the Peripheral
Device Plan. There are now many types of devices available to clinicians to support their daily
workflow. For some data collection, wireless tablets may work well when full features and
functions are needed (e.g., provider/nursing/ancillary rounding). For other data collection,
smaller handheld devices may provide connectivity for limited data collection needs. Nurse
Informaticists are integral in reviewing the primary needs of each stakeholder, suggesting a
limited number of companies/devices to trial, and providing the compilation of the trial
evaluation data. Nursing Informaticians and the technical team work together to assure all
hardware is installed and tested at the appropriate time.
Networks
Proliferation of Web-based applications and reference/ search engines in addition to
the locally based EHR necessitates a thorough review of the current and anticipated volume
of transactions (financial and clinical) and high utilization times for accessing the EHR. The
EHR no longer resides simply within the walls of a hospital. Health systems composed of
inpatient, outpatient, long-term care, home health, and patient access are variables to be
considered when determining the size and types of networks. “During day to day utilization,
what users want is sub-second screen flip response time” (Shabot, 2004, p. 265).
Application Software
The project’s technical manager is responsible for establishing the technical
specifications outlining the operational requirements for the new system. The specifications
detail the procedures required to maintain the application software on a daily, weekly, and
monthly basis. The specifications are compiled as the starting point for determining the
operations schedule for the system and/ or the institution. The operations plan includes
detailed information related to when the system will be scheduled for routine maintenance,
plans for operations during system failures, and acceptable periods, if needed, during the
week/month for the system to be unavailable to the users. Additional requirements for assuring
data reliability and availability following planned and unplanned system downtime as well as
procedures outlining data recovery following a downtime are developed. Change control
policies and procedures for identifying, tracking, testing, and applying software fixes are
established. Mark Anderson, the healthcare IT futurist, acknowledges prevailing requirements
from panel of physicians stating “…if the system was not available a minimum of 99% of the
time, they (physicians) would not consider the application reliable enough to use…”
(Anderson, 2011, p. 2).
With the popularity of Web-based systems, Web design, maintenance, and security
have added a level of complexity to maintaining a system within a healthcare environment’s
security regulations (e.g. HIPAA, Meaningful Use). Often niche software (e.g., patient portal,
secure texting software, e-prescribing, appointment scheduling, preventative healthcare
alerts) complements the central hospital information system. Requirements of each must be
reviewed and outlined in the technical specifications.

Interface Applications
An interface system defines those programs and processes required to transmit data
between disparate systems. The project’s technical manager coordinates all interfacing
activities for the new application. While utilization of the industry’s Health Level Seven (HL7)
interface standards has greatly reduced the effort required to establish clinical interfaces by
providing a standard specification for the transmission of data, the number of clinical interfaces
in an EHR has dramatically increased. It is not unusual for an EHR to interface with separate
registration, patient billing, ancillary departmental systems (e.g., lab, radiology, pharmacy, ICU
systems), as well as multiple types of wireless devices. With the advent of Health Information
Exchanges (HIEs), patient data will be sent via interfaces outside a healthcare systems
domain. Interface developments advocate the use of an interface engine decreasing the
number of individual interfaces to be managed. System security is detailed Chapter 10,
Trustworthy Systems for Safe and Private Health Care.
Meaningful Use Stage 2 requirements encompass the ability to share data
electronically with Federal and local agencies as well as with the patient. Implementation and
use of an Internet portal by patients is a Meaningful Use Stage 2 requirement. Adherence to
the Federal Meaningful Use data and transmission criteria is, therefore, essential. More
complex environments may include interfaces to physiological monitors and wireless portable
devices, and provide remote access into the healthcare network’s clinical system for
physicians and their staff.
The interface specification details whether the interface will be one-way or
bidirectional. A bidirectional interface implies data are flowing both to and from a system.
Conversely, a one-way interface may either send data to or receive data from a separate
system but does not do both.
An important process in development of the interface specification is the comparison
of data elements in each system in order to determine the data elements and their technical
format be included in the interface.
LEGACY SYSTEMS DATA CONVERSIONS ________________________________

The conversion of data from legacy systems to a new system is a major area of
coordination for the project’s technical manager. Most hospitals currently use automated
registration and billing systems; determining the conversion requirements and developing and
testing the conversion programs are critical steps in implementing a new system or application.
While all steps are important in the implementation of a new system, the interface and
conversion design and testing tasks are frequent areas causing project delays. The
importance of oversight and communication by the project technical manager to keep the
technical tasks on the established timetable should not be underestimated.
Development
Multiple plans are developed during this portion of the Design, Develop, Implement,
and Evaluate Phase. The detailed implementation workplan encompasses the multiple plans
targeting specific aspects of the EHR. Often the appropriate departmental teams are
responsible for creating the details for a focused plan. Together with the Project Manager and
Team Leaders, the focused plans are incorporated into the implementation workplan. At a
minimum the following focused plans are required:
• Communications Plan
• Hardware and Peripheral Devices plan
• Interface plan
• Conversion plan
• Testing plan
• End-User Training plan

The developed functional and technical specifications define a significant amount of
form and substance for the new EHR. The next step is to assess the timeframes established
in the final scope document with the development timeframes established during the system
design and the interface and conversion requirements to establish a detailed workplan. The
workplan identifies a responsible party and a beginning date and end date for each phase,
step, task, and subtask. This plan coordinates all tasks necessary to complete the
development of new software, implement a new system, and/or upgrade a current system.
Many software vendors and consultants provide an implementation workplan for their system
or applications. The supplied workplans must be reviewed and revised to meet the individual
needs and timetables of the organization’s project. Automated workplan software is available
to create and monitor a project/implementation plan. The implementation checklist describes
the high-level tasks to be included in clinical implementation workplans. It is advisable to take
advantage of automated software and existing plans. Figure 11.4 provides an example of
detailed workplan based on the checklist.
Whether the project is software development or the implementation or upgrading of a
system, the implementation workplan details the following:
• Personnel
• Timeframes
• Costs and budgets
• Facilities and equipment required
• Operational considerations
A successful implementation ensures all checklist items are planned, executed, and
tracked by the project manager and project team leaders.
• FIGURE 11.4. Sample Clinical Implementation

Workplan
System Selection
In the instance where commercially available software is being considered, the key
documents completed in earlier phases assist in beginning the system selection process. The
task of selecting a new system becomes more objective as a result of the thoughtful evaluation
for the functional specification and design document. The process and documents provide
the steering committee and project team with information to objectively evaluate commercial
system offerings. The system proposal document also assists the institution’s legal team in
formulating a contract with the software vendor as well as providing the basis for the
development of a formal request for proposal (RFP) or request for information (RFI) to
potential vendors.
Vendor A Costs Vendor B Costs Vendor C Costs
Information System Application Year 1 Year 2 Year 3 Year 1 Year 2 Year 3 Year 1 Year 2 Year 3
Nursing Documentation
Implementation
License
Hardware
Training
Support
Interfaces
Conversions
Order Entry
Implementation
License
Hardware
Training
Support
Interfaces
Conversions
Yearly Total $ $ $ $ $ $ $ $ $
3 Year Total $ $ $
• FIGURE 11.5. Sample Cost Comparison Worksheet.
Request for Proposal (RFP)/Request for Information (RFI)

The creation of a Request for Information (RFI) document is sent to selected vendors
indicating the organization’s interest in gaining knowledge about the vendor’s products. At a
high level, the key features desired for the new system are listed. Vendors respond to the RFI
with their product’s likely ability to meet the high-level requirements. Additional knowledge
about available technical solutions not considered is often gained from the RFI responses.
The project team reviews the responses and selects two to four vendors meeting the majority
of the high-level requirements. A Request for Proposal (RFP) document is created by the
project team and sent to the selected vendors outlining in greater detail the features and
functions desired for the new system. Clinical and financial workflow scenarios as well as the
desired functions developed by the project team can be included in the RFP. The vendor RFP
responses are equally detailed; they are closely evaluated both from the written responses
and during subsequent in-person or webinar style demonstrations of their product.
A number of system evaluation tools (Nielsen, 1992; Shneiderman, 1998) have been
published. A heuristic method relies on information common to the evaluators in assessing
the usability of a system. The 14-point tool, termed the Nielsen–Shneiderman Tool (Zhang,
Johnson, Patel, Paige, & Kubose, 2003, p. 25), provides a list of areas to be assessed during
the review and evaluation of systems or applications. Preparation activities for project team
members evaluating demonstrations of systems or applications for purchase should include a
discussion of aspects of the evaluation tool to be used and the definition of the criteria to
increase objectivity in the selection process.
Figures 11.5 and 11.6 are examples of tools utilized in evaluating the cost and potential
usability of prospective vendors’ software.
Communications Plan
Healthcare systems or applications often affect more than one department. Results
from a laboratory system are reviewed by clinicians; the pharmacy system utilizes creatine
results to adjust medication dosages for renal impaired patients. Documented nursing
observations (e.g., wounds, catheters, psychosocial assessments) are utilized by case
management, providers, and insurance companies. New functionality must be planned and
communicated to all stakeholders. A communications plan is often created in conjunction with
the organization’s public relations department. The plan is developed to promote frequent
face-to-face communications among departments, to multiple levels of administration, and to
external stakeholders (e.g., regulatory organizations, payers, and the local communities
served). Communications to all stakeholders/constituents affected by the project are
developed. Segment-targeted communications plans are developed identifying the type,
content level, and media for information dissemination to each identified stakeholder. Rarely
have staff complained of receiving too much information about a new process or change. More
often the complaint is “…no one told us!” Multiple communication mediums are utilized,
including but not limited to the following:
•Verbal updates presented at departmental/staff meetings
•Fact sheets/newsletters/flyers
•Faxes, e-mail, and Web site posting
•Social media/blogs
The communication plan, once developed and executed, must be monitored and
modified as the implementation progresses.
Up to this point, thorough planning and thoughtful design discussions have been held.
During Development, the decisions are actualized with the entry of elements into the data
dictionaries, and comparison of the clinical and departmental workflow to those created in the
system. The functional specification indicating how the departments and clinicians want the
system to work and the workflow document describing how processes are carried out are
established by populating in the data dictionaries. The plans for Interfaces, Conversions,
Testing, Communications, and Training are carried out.
Policies and Procedures

Reviews of policies and procedures are conducted, revisions reflecting changes being
implemented with the new system/application workflows. It is advisable to complete the policy
reviews and complete procedure revisions prior to the start of end-user training.
Workflow, Dictionaries, and Profiles

In this portion of the phase, project team members review data requirements and
workflow previously documented. Data dictionaries and profiles are populated with entries to
established desired new system workflow. This becomes an iterative process of populating

data dictionaries with values supporting the workflow design and functional specification;
testing the design with the project team; evaluating options suggested as a result of testing; and
refining/reevaluating the functional specification.
As data dictionaries are established, project teams begin to develop clinical decision
support functions. Clinical decision support is defined as “…an application that analyzes data
to help healthcare providers make clinical decisions” (Rouse, 2010). “Clinical Decision
Support Software (CDSS) is software designed to be a direct aid to clinical decision-making
in which the characteristics of an individual patient are matched to a computerized clinical
knowledge base and patient-specific assessments or recommendations are then presented to
the clinician or the patient for decision” (Sim et al., 2001, p. 528). Two main types of clinical
decision support systems exist. One type uses a knowledge base while systems without a
knowledge base rely on machine learning to analyze data. The challenge for the project team
is to find the correct balance of the number and types of alerts presented to the clinician.
Clinical alert fatigue, caused “…by excessive numbers of warnings about items such as
potentially dangerous interaction presented to the clinician and as a result the clinician may
pay less attention or even ignore some vital alerts…” (Kesselheim, 2011, p. 2310) is a well-
documented phenomena (see Chapter 40, Evidenced-Based Practice).
Testing
The system, whether newly developed or commercially available, must be tested to
ensure all data are processed correctly and the desired outputs are generated. Testing verifies
the computer programs are written correctly and when implemented in the production (live)
environment the system will function as planned. System implementation requires three levels
of testing. The first level is often called a functional test. During this round of testing, the
departmental teams test and verify the databases (files, tables, data dictionaries), ensuring
correct data have been entered into the system. The expected departmental reports are
reviewed to assure correctness and accuracy. Multiple iterations of the functional test often
occur until the departmental team is confident the system setup and profiles support the work
of the department. The second level of testing, integrated systems testing, begins when all
departments indicate successful completion of their functional testing. During integrated
testing, the total system is tested; this includes interfaces between systems as well as the
interplay between applications within the same system. The integrated test must mimic the
production (live) environment in terms of the volume of transactions, the number of users, the
interfaced systems, and the procedures to be followed to carry out all functions of the system.
It is at this point, organization-wide procedures to be instituted when the system is unavailable,
often called downtime procedures, are thoroughly tested. Downtime procedures must be
taught during end-user training.
At the end of integrated testing, the organization makes a formal decision to proceed
or postpone activation of the new systems. Often referred to as the “Go-No Go” decision,
members of the steering committee, project team, and technical staff review the outstanding
issues from both unit and integrated testing to make their decision. The final round of testing
occurs during end-user training. As more users interact with the new system, previously
unfound problems may surface. Evaluation of the severity of the newly discovered concerns
and the corrective action required is an ongoing process during implementation. Significant
information on testing processes and tools can be found in Chapter 12, System and Functional
Testing.
End-User Training. It is essential to train the end users on how to use the system in their
daily workflow. An EHR will function only as well as its users understand its operation and the
operations streamline their workflow. Two levels of training take place for the implementation
of a system. The project team and selected members of the departmental team receive
training from the developers or vendor. This training details the databases (files and tables),
processing logic, and outputs of all the system’s features and functions. End-user training
takes place once the departmental and project teams have finished profiling the system to
meet the functional and technical specifications developed and functional testing has been
completed. The preparation for end-user training necessitates a “mini-workplan” often
developed and managed by a team led by the Education/Training department. End-user
training stresses how the user will complete his or her workflow using the system features and
functionality.
All users of the new system or application must receive training. Training on a new
system should occur no more than six weeks prior to the activation of the new system. When
training occurs for more than six weeks before activation of the system, additional refresher
training is often required by the end users.
Training takes place before and during the activation of a new system. After system
implementation, refresher courses as well as new employee introductory training on the use
of the system are often provided by the institution. The large number of provider, nursing and
ancillary staff members to be trained necessitates a significant amount of advance planning.
Training is most effective when hands-on, interactive instruction is provided. Training
guides or manuals explain the system; however, retention of information is increased if the
learners are able to interact with the new system in a manner simulating their workflow with
the system. Computer-assisted instruction (CAI) can be used to provide hands-on experience.
Often the Web-based training provides the user opportunities for self-paced, on-demand
learning. End-user training is offered with two perspectives. One perspective provides a
general overview of the system, and the second perspective explains how the user will interact
with the system to complete his or her daily work. While a training manual is developed for the
training sessions, most end users express the desire to have a pocket-size reminder (“cheat
sheet”) outlining the key functions of the new system or application. Both the user’s manual
and the pocket reminders should be available for departmental use. When possible, a training
environment on the computer system should be established for the organization. Establishing
a training lab as well as providing access to the training environment from the departments
and nursing units prior to the activation of the new system provides end users the opportunity
to practice at times convenient to their work requirements and reinforces the training.
IMPLEMENT, EVALUATE, MAINTAIN, AND SUPPORT PHASE ____________________
System Documentation
The preparation of documents to describe the system for all users is an ongoing
activity, with development of the documentation occurring as the various system phases and
steps are completed. Documentation should begin with the final system proposal. Several
manuals are prepared: a user’s manual, a reference manual, and an operator’s maintenance
manual. These manuals provide guides to the system components and outline how the entire
system has been developed.
Implementation—Go Live
Few if any healthcare organizations have the luxury to stop operations during an
implementation (Lorenzi et al., 2008). Implementation encompasses the Cut Over plan (data
driven) and the Implementation plan for the facility to continue to operate (people/processes)
during this period. Staffing, patient care delivery, and support of the end user during the “Go
Live” period are detailed within the “Go Live” plan. The planning includes assuring patient care
functions as smoothly as possible during the time between the cutoff of the old system and
the start of processing on the new system. Downtime functions/ processes and forms are
reviewed to assure patient care, and processing of data continues and is able to be accu-
rately reflected in the patient’s record. This often includes developing forms streamlining the
documentation to be entered when the new system is available (Fig. 11.7).
TARGET
START END TASK RESP. HANDOFF
DONE DATE TIME TIME SEQUENCE TASK DESCRIPTION DEPENDENCY PERSON CONTACT COMMENTS
Change profile PRFDT to 29 days. All areas that enter orders. To
Continue changing this profile (minus prevent future orders to be placed in
one day) on a daily basis until 11/30 legacy system with start date greater
2-Nov 8:30 30-Nov SMS-1 when it is set to 1. none than conversion date.
30-Nov 12:00 23:00 CAI-1 Review/Final configuration changes none
30-Nov CHECKPOINT CONFERENCE CALL scheduled ALL
6 a.m. Lab draws should not wait
until 2 p.m. Enter when orders are
Order rewrites by physicians. Nursing rewritten. WE ARE NOT
staff will hold on to any orders which REWRITING MEDICATION
30-Nov 14:00 16:00 MD-1 can be held until 02:00 none ORDERS!
Enter orders for 6 a.m. Lab draw in Legacy Lab Nursing
30-Nov 14:00 16:00 Nursing-1 legacy system Up Staff
Validation of Allergies (including food
allergies) and patient factors data on Hand off Go Live patient factor validation
Go Live patient factor validation Nurses validation form checklist created to help with
30-Nov 18:00 00:00 Nursing-2 checklist Only checklist this.
• FIGURE 11.7. Sample Cutover Plan.
Sample Cutover Plan

Four activation approaches are possible: (1) parallel, (2) pilot, (3) phased-in, and (4)
big bang theory. In the parallel approach, the new system runs parallel with the existing system
until users can adjust. In the pilot approach, a few departments or units try out the new system
to see how it works and then help other units or departments to use it. In the phased-in
approach, the system is implemented by one unit or department at a time. In the big bang
approach, a cutover date and time are established for the organization, the old system is
stopped, and all units/departments begin processing on the newly installed system.
The timing of conversion activities and the activation of all interfaces require particular
coordination between the technical staff and the project teams. The project’s technical
manager, in conjunction with the project manager, is responsible for assuring the development
of thorough go live plans. A command center is established to coordinate all issues, concerns,
and go live help desk functions. A sufficient number of phone lines and beepers/cell phones
are secured to support the move to the live production environment. Team members and
trainers often serve as resources to the end users on a 24-hour basis for a period of time post-
implementation. Sometimes called “super users,” these team members are available in the
departments and on the nursing units to proactively assist users during the first one to two
weeks of productive use of the new system or application.
The coordination of all activities requires a cohesive team effort. Communication
among the team members is foundational; end users are informed of the sequence events,
the expected time frames for each event, and the channels established for reporting and
resolving issues. Daily meetings of key team members to review issues and chart the progress
of the new system are held. Decisions affecting the “Go Live” are made in a timely manner
and require a thoughtful and thorough approach when changes to procedures and computer
programs are contemplated. The executive team and senior management group are kept as
up to date as the end users. The goal of most clinical implementations is to improve the
delivery of information to the end user. The end-user suggestions and issues, therefore, must
be tracked and resolved. Providing timely follow up to issues and suggestions will be critical
to the success of the new system. Often, the informatics nurses are responsible for this follow-
up.

It is highly recommended to have all end-user logins, passwords, and system devices
and printers tested five to seven days before going live. Requests for login and password
support comprise the largest number of calls to the Command Center during the first few
weeks of a new system’s use. Clinical and departmental managers are in the best position to
assure all staff have logged into the new system and have the appropriate role for their job
requirements. Login issues are followed closely by printer issues (e.g., printer offline, printer
settings incorrect, output expected to print at a location doesn’t print) during the first weeks of
a new system. The Hardware team members can troubleshoot issues best if they have been
given a script outlining one or two functions resulting in a printed output. Assuring these two
areas are addressed completely prior to “Go Live” will dramatically lessen the anxiety of the
end user as well as eliminate a large number of calls to the Command Center during the “Go
Live” period.
With an organized and thorough Integrated Testing period, the actual first productive
use of the system and subsequent days of the “Go Live” period are likely to be a “boring”
nonevent. Feedback from the end users and administrative staff will help determine how long
the Command Center will need to be staffed on a 24-hour- a-day basis.
The command center is set up and ready to coordinate all issues, concerns, and “Go
Live” Help Desk functions. The Command Center has a sufficient number of phone lines and
beepers to support the move to the Live, production environment. For a period of time, this
will include 24 hours a day operations. Often, the representatives/ consultants of the new
software company are on site to assist with “Go Live” support and staffing of the Command
Center. The advantages of having designated command center include close proximity of
clinical, administrative, technical, and vendor team members to quickly assess and prioritize
issues. This close proximity also allows rapid communications and trending of problems in
near real time during the first days of the new system’s use. Team members, trainers, and
super users serve as resources to the end users on a 24-hour basis during “Go Live,” often a
period of one to two weeks.
Evaluation Post-Live. The important tasks of Evaluation are:

•Collection of post-live Success Criteria
•Completion of a System/Project Evaluation including the results of the Success
Criteria
•Transitioning end-user support from the Command Center to the Help Desk
•Closure of the project
The system is evaluated to determine whether it has accomplished the Project Scope’s
stated objectives. It involves a comparison of the working system with its functional
requirements to determine how well the requirements are met, to determine possibilities for
growth and improvement, and to preserve the lessons learned from the implementation project
for future efforts. The Post “Go Live” evaluation describes and assesses, in detail, the new
system’s performance. Utilizing the criteria established in Planning Phase, the evaluation
process summarizes the entire system, identifying both the strengths and weaknesses of the
implementation process. Comparison of the pre-and post-implementation Success Criteria
data provide quantitative data as to the successes obtained with the new system. The
evaluation often leads to system revisions and, ultimately, a better system.
To evaluate an implemented hospital information system, many principles are
important. One authority suggests evaluating duplication of efforts and data entry,
fragmentation, misplaced work, complexity, bottlenecks, review/approval processes, error
reporting via the Issue Tracking mechanism, or the amount of reworking of content,
movement, wait time, delays, set up, low importance outputs, and unimportant outputs.
This evaluation component becomes a continuous phase in total quality management.
The system is assessed to determine whether it continues to meet the needs of the users.
The totally implemented system will require continuous evaluation to determine if upgrading
is appropriate and/or what enhancements could be added to the current system. Formal
evaluations generally take place no less than every six months and routinely every two to four
years after the systems have been implemented. The formal evaluation can be conducted by
an outside evaluation team to increase the objectivity level of the findings. Informal evaluations
are done on a weekly basis.
Other approaches to evaluating the functional performance of a system exist. The
Clinical Information System Evaluation Scale (Gugerty, Miranda, & Rook, 2006) describes a
37-item measurement tool for assessing staff satisfaction with a CIS. Investigating such
functions as administrative control, medical/nursing orders, charting and documentation, and
retrieval and management reports are used to assess system benefits. Each of these areas is
evaluated through time observations, work sampling, operational audits, and surveys (Nahan,
Vaydua, Ho, Scharf, & Seagull, 2007). System functional performance can be assessed by
examining nurses’ morale and nursing department operations.
Documentation of care must be assessed if patient care benefits are to be evaluated.
The following questions should be asked:
•Does the system assist in improving the documentation of patient care in the patient record?
•Does the system reduce patient care costs?
•Does the system prevent errors and save lives?
•To evaluate nurses’ morale requires appraising nurses’ satisfaction with the system. The
following questions may be considered useful:
◦Does the system facilitate nurses’ documentation of patient care?
◦Does it reduce the time spent in such documentation?
◦Is it easy to use?
◦Is it readily accessible?
◦Are the display “screens” easy to use?
◦Do the displays capture patient care?
◦Does the system enhance the work situation and contribute to work satisfaction?
To evaluate the departmental benefits requires determining if the CIS helps improve
administrative activities. The following questions must be answered:
•Does the new system enhance the goals of the department?
•Does it improve department efficiency?
•Does it help reduce the range of administrative activities?
•Does it reduce clerical work?
Other criteria are necessary to evaluate technical performance; these include
reliability, maintainability, use, response time, accessibility, availability, and flexibility to meet
changing needs. These areas are examined from several different points—the technical
performance of the software as well as hardware performance. The following questions must
be answered:
•Is the system accurate and reliable?
•Is it easy to maintain at a reasonable cost?
•Is it flexible?
•Is the information consistent?
•Is the information timely?
•Is it responsive to users’ needs?
•Do users find interaction with the system satisfactory?
•Are input devices accessible and generally available to users?
Implementation of a clinical system is a project; by definition a project has a beginning,
a middle, and an end (Lewis, 2007; Project Management Institute, 2014). The transitioning of
the end-user support functions from the Command Center to the Help Desk and submission
of the Post-Live Evaluation to the Steering Committee are particularly important events in
determining the end of an implementation project and the beginning of the maintenance and
growth phases of the new system.
Daily Support Operations
Daily support operations begin during the Go Live period. “Help Desk” functions for
recording and tracking end-user calls/tasks for help are often managed by the Go Live team
in the Command Center during the first one to three weeks post-live. Daily meetings/huddles
are held with the Go Live team and IT Help Desk staff to review both type and frequency of
problems encountered by the end users. The most frequent type of call during the Go Live
period are from users unable to log into the system. The proactive recommendation is to
include a task in the Cut Over Plan to assign user logins and have all users log into the new
system two to seven days before Go Live. The second most frequently received calls stem
from the user’s lack of knowledge on how to complete a specific task. Reinforcement of
training through one-to-one interventions as well as via mass communications (e-mails/flyers/
Web site updates) are done. Early resolution of problems and communication back to staff is
imperative and fosters confidence that the Project Team and the organization are addressing
their needs during this stressful period.
Ongoing Maintenance
The requirement for support resources in the hospital/ healthcare environment is a
challenge for organizations. Many organizations utilize technical, analyst, and nursing
informatics resources to provide the 24/7 support coverage. Strong communication and
issue/task resolution procedures assist in responding to user needs.
The technical manager reviews requirements for networks, servers, hardware, and
certain software concerns. Commercial software companies continue to provide upgrades and
updates to their systems/applications. Ongoing review of new features and functions, federal
and state requirements, and insurance and billing requirements occur.
SUMMARY
This chapter describes the process of designing, implementing, and/or upgrading a
clinical information system/ EHR in a patient healthcare facility. It outlines and describes the
four phases of the SLC process—planning, system analysis, system design, development,
implementation, and evaluation and system maintenance and support. The upgrading process
reviews all of the components described to assure a technically sound, regulatory complete
implementation supporting safe patient care and streamlined workflow. A clinical system/EHR
implementation checklist utilizing the SLC process has been developed (Fig. 11.8).
The planning phase determines the problem scope and outlines the entire project to
determine if the system is feasible and worth developing and/or implementing. The analysis
phase assesses the problem being studied through extensive data gathering and analysis.
The design phase produces detailed specifications of the proposed system. Development
involves the actual preparation of the system, support of workflow, review of policies and
procedures impacted by the new system, and detailed implementation planning. Testing is
generally conducted on three levels for both the design and implementation of a commercially
available system. Training focuses on the use of the system to improve their everyday plans
for moving the new system into the production or live environment. Evaluating the system
determines the positive and negative results of the implementation effort and suggests ways
to improve the system. Upgrading the system involves expansion or elaboration of initial
functions by expanding capability or function or by adding entirely new applications. Upgrading
projects requires all implementation phases be reviewed to assure success.

Module 11 Week 11 NCM 110 Nursing Informatics

Uploaded by

Copyright:

Available Formats

Module 11 Week 11 NCM 110 Nursing Informatics

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Module 11 Week 11 NCM 110 Nursing Informatics

Uploaded by

Copyright:

Available Formats

Part 11: System Life Cycle: A Framework

(Marina Douglas / Marian Celli)

ELECTRONIC HEALTH RECORD

Evidence-Based Medicine (EBM)

SYSTEM LIFE CYCLE

System Life Cycle Clinical Software Implementation Major Tasks

Analysis Technical Requirements Functional Design Document System Proposal Document

NCM 110 (Nursing Informatics) Page 3 of 26

Implement, Evaluate, ImplementPlans

• FIGURE 11.1. SLC Stages in Relation to ClinicalSoftware Implementation Checklist.

Governance Structure and Project Staff

Department Team Department Team Department Team Department Team

Department Team Department Team Department Team Department Team

Department Team Department Team Department Team Department Team

• FIGURE 11.2. Clinical Information System Steering Committee Structure.

• FIGURE 11.3. Application Implementation Committee Structure.

DEVELOP PROJECT SCOPE

Definition of the Project’s Purpose

NCM 110 (Nursing Informatics) Page 7 of 26

•What is the real problem to be solved and/or stated goal to be met?

Statement of the Objective

NCM 110 (Nursing Informatics) Page 8 of 26

Documentation and Negotiation of a Project Scope Document

NCM 110 (Nursing Informatics) Page 10 of 26

Determination of Information Needs

Functional Design Document

System Proposal Development

1. What are the major problems and/or goals under consideration?

NCM 110 (Nursing Informatics) Page 13 of 26

SYSTEM DESIGN, DEVELOPMENT, AND CUSTOMIZATION PHASE ______________

NCM 110 (Nursing Informatics) Page 14 of 26

Peripheral Device Plan

NCM 110 (Nursing Informatics) Page 16 of 26

LEGACY SYSTEMS DATA CONVERSIONS ________________________________

NCM 110 (Nursing Informatics) Page 17 of 26

• FIGURE 11.4. Sample Clinical Implementation

• FIGURE 11.5. Sample Cost Comparison Worksheet.

Request for Proposal (RFP)/Request for Information (RFI)

Policies and Procedures

Workflow, Dictionaries, and Profiles

NCM 110 (Nursing Informatics) Page 20 of 26

IMPLEMENT, EVALUATE, MAINTAIN, AND SUPPORT PHASE ____________________

• FIGURE 11.7. Sample Cutover Plan.

Sample Cutover Plan

NCM 110 (Nursing Informatics) Page 23 of 26

Evaluation Post-Live. The important tasks of Evaluation are:

NCM 110 (Nursing Informatics) Page 26 of 26

You might also like