NCM 110

LESSON 2.1 SYSTEM LIFE CYCLE (A FRAMEWORK)

- Electronic Health Record
o 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. 
o Included in this information are patient demographics, progress notes,
problems, medications, vital signs, past medical history, immunizations,
laboratory data, and radiology reports. 
o The EHR automates and streamlines the clinician’s workflow. 
- Project Management
o With roots in the construction industry, a significant body of knowledge in
the area of planning and tracking large-scale projects has evolved.
o The Project Management Plan (PMP) developed through their efforts has
migrated to the Information Technology (IT) area and is commonly called
a project workplan. 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.
o 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.
- System Lifecycle

o 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.
o 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 struc- ture. 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.
 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.
 Project Team
 The project team is led by an appointed project manager 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. 
 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.
 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.
 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.
 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. 
 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.
 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. 
 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.
 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.
 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.
o 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
 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 stor- age 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.
 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.
 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.
o 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.
 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.
 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.
o 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. 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 accurately reflected in the patient’s record. This often
includes developing forms streamlining the documentation to
be entered when the new system is available.
 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. Nursing Informatics personnel must bridge the
support of the basic system requirements with the fast paced
release of new technologies used in patient care. The cost of
purchase and implementation is high; maintaining and
improving the system’s ability to support all aspects of
patient care delivery are mandatory.
 To upgrade a system, the same phases and activities
described for the SLC must occur; however, when
 upgrading, dovetailing the changes into the current system
will require close evaluation and planning.

LESSON 2.2 SYSTEM AND FUNCTIONAL TESTING

- System and functional testing are critical components of the system life cycle,
whether the software or system is under new development or is commercial off-
the-shelf (COTS) software that is being configured for a customer’s specific
needs. 
- Testing definitions and goals have evolved over the past 60 years from the most
simplistic “bug detection” process, conducted toward the end of the design and
coding phases. 
- Testing and quality assurance are NOT SYNONYMOUS. 
- Testing is composed of activities performed at various intervals during the
development process with the overall goal of finding and fixing errors. The
system life cycle phase usually drives how testing activities are organized, but
the testing plan will normally include coordination of test efforts (scheduling
resources, preparing scripts and other materials), test execution (running
prepared test scripts with or without automated tools), defect management
(tracking and reporting of errors and issues), and a formulation of a test
summary. 
- Quality assurance (QA) is a proactive, planned effort to ensure that a defect-free
product fulfills the user-defined functional requirements. Testing is an
indispensable tool, but it represents the most reactive aspect of the quality
assurance process. 
- Testing is all about finding defects. Quality assurance is all about preventing
defects.
- TESTING MODELS AND METHODOLOGIES
o Testing models have evolved in tandem with the ever- increasing
complexity of healthcare software and systems.
o The Waterfall model, for example, was characterized by relatively linear
phases of design, development, and testing. Detailed definition of end-
user requirements, including any desired pro- cess redesign, flowed to
logical design (data flow, process decomposition, and entity relationship
diagrams), which flowed to physical design (design specifications,
database design), then to unit design, and ultimately to coding (writing in a
programming language). Testing occurred toward the end of the Waterfall
development model—a bit late for any substantive code modifications.
 
o Agile software development, in contrast to some of the earlier models, is
characterized by nearly simultaneous design, build, and testing. Extreme
Programming (XP) is a well-known Agile development life cycle model that
emphasizes end-user engagement.


- TESTING STRATEGY AND PROCESS

o Broad goals for health information technology system and functional
testing include building and maintaining a better product, reducing costs
by preventing defects, meeting the requirements of and maintaining
credibility with end users, and making the product fit for use. Failure costs
in system development may be related to fixing the product, to operating a
faulty product, and/or to damages caused by using faulty product.
o Resources required to resolve defects may start with programmer or
analyst time at the component level, but in the context of a clinical
information system thought to be “ready for use,” defect resolution
includes multiple human resources: testing analysts, interface analysts,
analysts for upstream and downstream applications, analysts for
integrated modules, database administrators, change management
analysts, technical infrastructure engineers, end users of the new system
and upstream and downstream interfaced systems, and others. 
 o Operating a faulty software product incurs unnecessary costs in computer
resources and operational efficiencies, and potential damages include
patient confidentiality violations, medical errors, data loss,
misrepresentation of or erroneous patient data, inaccurate aggregated
data, and lost revenue.
o Testing plan is as indispensable to a clinical system project as an
architect’s drawing is to a building project. You wouldn’t try to build a
house without a plan—how would you know if it will turn out “right”? Test
planning should begin early in the system life cycle, and should align
closely with business and clinical goals. Project definition and scope,
feasibility assessments, functional requirements, technical specifications,
required interfaces, data flows, workflows and planned process redesign,
and other outputs of the planning and analysis phases become the inputs
to the testing plan.
- TESTING TYPES
o Testing types used vary based on where in the system life cycle testing is
planned, and the degree of development or programming that is involved. 
o Test Planning
 Define what is to be accomplish
 The goals should include the scope, expectations, critical success
factors, and known constraints, which will be used to shape the rest
of the plan.
o Testing Specifications
 Define format standards, identify features to be tested, cross-
reference features to the functional requirements, and break down
the work into manageable pieces.
o Scheduling
 A vital test planning component, involves coordination of multiple
human and technical resources.
 Testers want to test for failures. Defects may include:
 Functions that do not work as designed
 Workflow issues that were not identified during requirements
definition and workflow analysis
 Unintended effects
 Defects are usually given a priority. Priority examples include:
 Critical: Significant impact to patient safety, regulatory
compliance, clinical workflow, or other aspect, for which no
workaround is possible
  High: Significant impact to workflow or training or other
aspect, for which the resolution effort or the workaround is in
itself a major effort and may be high risk
 Medium: Impact on workflow or training is noteworthy, but a
reasonable workaround exists
 Low: Impact on workflow or training is minimal; workaround
is not required
o Regression Testing
 Ensures that fixes implemented during the integration cycles didn’t
break something else
o Acceptance Testing
 Allows users to validate that the system meets their requirements,
and is usually conducted using scripts that reflect redesigned
processes from the workflow analysis phase
o User Acceptance Testing
 UAT should represent a final validation of “fit for use,” but  not a
“surprise” to end users
o Alpha and/or Beta Testing
 Scheduled when a software or system is newly developed, and
both mimic real-world use
o Usability Testing
 Ideally begins early in the design phase and is conducted
throughout the system life cycle, through optimization and
maintenance as well as during implementation.
 Usability’s broadest definition, “quality in use,” includes the user
and task dimensions along with the tool and the environment
o Safety Testing
 Safety testing incorporates the people, process,
technology,  environment, and organization-related issues identified
in the literature, with a focus on provider order entry, clinical
decision support, and closed-loop (bar-coded) medication
administration
- CHALLENGES AND BARRIERS
o Resources
 Liberating end users from their regular work for testing can prove
difficult
o Timeline Pressures
 Pressure to attain project milestones may tempt even the most
seasoned project managers to shorten test cycles or use testing
 shortcuts, though the costs of failure may outweigh costs of timeline
changes
o Materials / Inadequate Script Development
 User acceptance testing requires detailed scenario-driven scripts
that simulate real workflows

LESSON 2.3 SYSTEM LIFECYCLE TOOLS

- Like the nursing process, the system life cycle (SLC) is a continuous series of
system changes, or evolutions. Even after the system is installed, there is
continuous analysis, design, and implementation of new modules, upgrades, and
improvements.
- Nurses are accustomed to leading interdisciplinary team in the patient care
environment, so leading interdisciplinary teams to address clinical information
systems is a natural progression.
- The American Nurses Credentialing Center defines the System Life Cycle as
having five phases: System Planning; System Analysis; System Design,
Development, and Customization; System Functional Testing; and System
Implementation, Evaluation, Maintenance, and Support.
- There are variations of these phases, some experts include the functional testing
in the analysis phase, and some include, for example, the development and
customization in the system design phase. No matter how they are broken down,
each of these phases has specific elements and tools that can aid in the goal of a
successfully installed and maintained system that meets the needs of all
stakeholders.
- Analysis and Documentation of the Current Process and Workflow
o All phases of the SLC may require analyzing the data and workflow.
System analysis and workflow analysis can be described as a way to
understand how a system works, and how the different elements in the
system interact. There are many ways to depict a workflow, but the critical
part is the analysis of the process or workflow and accurately and
completely documenting each step.
o Documenting a workflow may be done by walking through the steps via an
intensive interview with those intimately familiar with the process by
observation or by a combination of the two. Interviewing staff about how a
lab or diet order is processed from the time it is entered until it is
completed is an example using the interview to document a process. A
combination of observation and interviews might be the most effective way
to capture all of the nuances for medication administration, and
observation alone would be effective for a time and motion study. 
o A workflow diagram is generally prepared to document the current state
when planning for a system implementation and to identify problems or
areas that need improvement. A workflow diagram documents the
processes of the users; the data workflow diagram documents the
interaction and flow of the information system(s). There are several types
of diagrams that can be utilized to document a process, including swim
lanes, data flow diagrams (DFDs).
o A swim lane diagram represents a process and is usually grouped in lanes
(either columns or rows) to help visualize the users or departments
involved. Workflow can be documented using a simple list of the steps in
the process, a swim lane, or a workflow diagram. No matter what method
is used to display the process, it needs to be clear and complete for
accurate analysis. 
o System Selection and Implementation
 An information system should support patient care by allowing
clinical staff to easily navigate the system to enter information about
the system, monitor, and be alerted to changes. Selecting a system
that meets the needs of all levels of stakeholders, from bedside
staff to the executive team, is a complicated process with multiple
factors involved.
 Systems must be easy to use in relation to entering and obtaining
data and information. Today’s clinical systems included embedded
analytics, clinical decision support (CDS) to prompt clinicians with
warnings and evidence- based suggestions, as well as business
intelligence to capture financial and operational data. Clinical and
Business Intelligence provides historical and predictive perspective
of the operations and clinical areas to improve business and clinical
decisions.
 Understanding how the different parts of the system work together
as well as how the system will impact the clinical workflow is key to
be considered during the system selection process. While having a
system that is easy to learn and use is important, if the data cannot
be reported or shared its value decreases significantly. 
o System Implementation
 System implementation requires system design and building, and
testing. System design should involve key stakeholders, especially
end users throughout. Testing involves making sure that each part
of the system works, and that the system works correctly with other
modules and systems. 
  Integrated testing is done after unit testing has been accomplished
and is the last phase of testing, ensuring that all systems that share
data are working correctly in real-life scenarios (National Learning
Consortium, 2012), similar tools can be used for integrated testing
involving interfaced system or conversion verification to ensure that
converted information is correct. 
 Another trend in healthcare is converting not from paper to an
electronic record, but from one electronic system to another
system. Whether this conversion is due to replacing a legacy
system or due to a merger, the complexity of a system conversion
brings its own set of requirements in the user expectation, the
design and build, testing and the decision of what information to
convert, and what to “backload” from the existing system to the new
system.
 Backloading, or manually entering information into the new system,
is often done in between two and five days before a new system is
live so that important patient information is available. 
o System Optimization and Metrics
 The system life cycle, like the nursing process, is a fluid process of
assessment, diagnosis, planning, implementation, and evaluation.
After the system is implemented, the process of system changes
does not end. System optimization and support along with changes
due to upgrades, regulatory and payer changes, as well as clinical
changes due to new research all lead to constant changes to the
system. As stakeholders become more familiar with the system,
they will have ideas on improvements and enhancements to make
the system more user friendly, as well as improving the ability of the
system to prompt staff to improve patient care.
- Measuring Success, Continuing to Improve
o Continuous Quality Improvement (CQI) is based on the principle that there
is an opportunity for improvement in every process. CQI begins with a
culture of change and improvement, and encourages all levels of staff to
look for ways to improve the current process, and for variations of the
process, which can create errors. There are many philosophies that can
be utilized to implement a CQI program; some can be used in
combination. 
o Some of these include the following:
 Six Sigma is a “data-driven quality improvement methodology that
uses statistical analysis to reduce process variation. Six Sigma has
a strong focus on reducing variation, in fact the term, Six Sigma
 refers to a defect rate of 3.4 defects per million opportunities and
represents a statistically high standard of quality”. Six Sigma
utilizes five steps to evaluate metrics, known as
DMAIC: Define, Measure, Analyze, Improve, and Control. Six
Sigma focuses on the reductio of variation to improve processes;
the goal is to permanently resolve errors by focusing on the
underlying processes.
 Lean Six Sigma has a strong focus on eliminating waste by
removing non-value activities including defects, unnecessary, or
redundant steps using value stream mapping (VSM). It focuses on
the process and works best if all employees are involved. Lean Six
Sigma creates a “culture and practices that continually improve
all functions by all people at all levels in the organization, and also
utilizes the DMAIC model.”
 Plan Do Study Act (PDSA) is a process for enacting and evaluating
change;  it has been recommended by the Joint Commission and
the Institute of Medicine as an effective tool for complex processes.
It is a four-step scientific method to enact and evaluate
change: Planning, Do it or implement the change, Study the results,
and Act—which may include modifying the change based on the
results of the initial test.
 Failure Mode and Effects Analysis (FMEA) can be used throughout
the system life cycle to evaluate processes for real or potential
failure points.
o The processes are mapped out and each step of the process is
documented. Flow charts or Swim Lane Process maps can be used to
help visualize the process maps. The process maps or process flows are
then used to identify where in the process there are risks for failure (or
errors), and the associated risks including the severity and likelihood. The
FMEA team, which includes representatives of all affected areas, then
identifies solutions and implements them. The implementation is followed
by an evaluation, and reevaluation process until no failures can be
identified.

LESSON 2.4 HEALTHCARE PROJECT MANAGEMENT

- It is difficult to read a newspaper, magazine, or Web page today without
somehow hearing about the impact of information technology. Information in all
forms is traveling faster and being shared by more individuals than ever before.
Think of how quickly you can buy just about anything online, make an airline
reservation, or book a hotel room anywhere in the world. Consider how fast you
 can share photos or video clips with your family and friends. This ubiquitous use
of technology is permeating the healthcare industry as well, and the future of
many organizations may depend on their ability to harness the power of
information technology, particularly in the area of electronic health records and
health information exchange.
- Good project management is needed in order to accomplish the work, facilitate
the change, and deliver the improvements facilitated by health information
technology implementation. Project management is not a new concept, it has
been practiced for hundreds of years, as any large undertaking requires a set of
objectives, a plan, coordination, the management of resources, and the ability to
manage change. Today, however, project management has become more formal
with a specified body of knowledge, and many healthcare organizations have
adopted the project-oriented approach as a technique to define and execute on
their strategic goals and objectives.
- Good project managers for health information technology projects are in high
demand. Colleges have responded by establishing courses in project
management and making them part of the health informatics’ curriculums for
continuing education, certificate and degree programs. This chapter provides a
high-level look at the methodology behind project management in order to
provide a framework for the project manager skills development, structure for the
implementation work processes, and organization of the projects’ tasks.
- What is a Project?
o There are many different definitions of a project, but they all have the
same components—a project is temporary, has a defined beginning and
end, and is managed to time, budget, and scope.
o A project is defined as a temporary endeavor undertaken to create a
unique product, service, or result. Distinguishing features of a project are
specific objectives, defined start and end dates, defined funding
limitations, consumption of resources (human, equipment, materials), and
if needed, a multifunctional or cross-organizational structure.
- What Is Project Management?
o Project management is facilitation of the planning, scheduling, monitoring,
and controlling of all work that must be done to meet the project
objectives. PMI states that “project management is the application of
knowledge, skills, tools and techniques to project activities to meet project
requirements”. It is a systematic process for implementing systems on
time, within budget, and in line with customer expectations of quality.
Project managers must not only strive to meet specific scope, time, cost,
and quality project goals, they must also facilitate the entire process to
 meet the needs and expectations of the people involved in or affected by
project activities.
- Project Management Knowledge Areas
o The Project Management Knowledge Areas describe the key
competencies that project managers must develop and use during each of
the Process Groups. Each of these competencies has specific tools and
techniques associated with it, some of which will be elaborated in the
following sections of this chapter. 
o The four core areas of project management are project scope, time, cost,
and quality management. These are considered core as they lead to
specific project objectives. The four facilitating knowledge areas of project
management are human resources, communication, risk, and
procurement management. These are considered facilitating as they are
the processes through which the project objectives are achieved.
- Initiating Process Group
o The Initiating Process Group is defined by the PMI as “those processes
performed to authorize and define the scope of a new phase or project or
that can result in the continuation of halted project work”.
o The purpose of the IPG is to formally define a  project including the
business need, key stakeholders,  and the project goals.
o Characterized by  information gathering and research that leads to full
disclosure of both the benefits and the costs associated with a  given
project.
- Planning Process Group
o The Planning Process Group is often the most difficult and unappreciated
process in project management, yet it is one of the most important and
should not be rushed.
o This is the phase where decisions are made on how to complete the
project and accomplish the goals and objectives defined in the Initiating
Process Group. The project plan is created, whose main purpose is to
guide the project execution phase.
- Executing Process Group
o The phase where decisions are made on how to complete the project and
accomplish the goals and objectives.
o INTEGRATION MANAGEMENT 
 Coordination of project   resources and activities to complete the
project on time, within budget, and in accordance with the  project
scope defined by the customer.
o QUALITY MANAGEMENT
  Monitoring of project performance to ensure that the deliverables
will satisfy  the quality requirements specified by the customer.
o HUMAN RESOURCE MANAGEMENT
 Enhancing and  motivating performance of project team members
to ensure effective use of human resources to advance project
deliverables.
o COMMUNICATION MANAGEMENT
 Distribution of information in a complete and timely fashion to
ensure all stakeholders are informed and miscommunication
channels are minimized.
o PROCUREMENT MANAGEMENT
 Obtaining goods and services from outside an organization
including identifying and selecting vendors and managing contracts.
- Monitoring and Controlling Process Group
o Facilitates project control by measuring actual performances against the
planned or estimated performance from the project plan in the areas of
scope, resources, budget, and time.
o Observes project execution so that issues and potential problems can be
identified in a timely manner and corrective action can be taken
when necessary to control execution of the project.
o Key benefit of project control occurs when project performance is
observed and measured regularly, variance to the plan can be identified
and mitigated quickly to minimize delays and avoid cost overruns.
- Closing Process Group
o Goal: finalize all project activities and to formally close the project
o Project goals and objectives set during the IPG are compared with
deliverables and analyzed to determine the project success
o Key stakeholders are engaged with evaluating the degree to which the
deliverables were met
o The inputs needed to support the work of the CPG includes outputs from
earlier process group phases and tools and information that support the
knowledge areas of project integration and procurement management
- Triple Constraint
o The concept is that a modification to the project will impact one or more of
the three constraints, and often require trade-offs between them:
 Cost: The financial constraints of a project, also known as the
project budget
 Scope: The tasks required to fulfill the project’s goals
 Time: The schedule for the project to reach completion
- Other Considerations
o Project Governance
 Led by top business and clinical leaders, with membership built on
broad representation from key business and clinical departments.        
 They set guiding principles for concepts like integration versus
best-of-breed systems.
 Do not just see themselves as “governing” the project selection
process, but rather as “driving” the implementation of projects
o Project Management Office
 Many have now created a project management office (PMO) to
provide best practices and support for managing all projects in an
organization
 The office can also provide education, coaching, and mentoring, as
well as project management resources
o Project Management Institute
 Founded by 1969 by a group of project managers
 “To advance the practice, science and profession of project
management throughout the world in a conscientious and proactive
manner so that organizations everywhere will embrace, value and
utilize project management and then attribute their successes to it.”
o Project Management Professionals
 Offers multiple levels of credentialing to assist project professionals
with advancing their careers in project, program, and portfolio
management
o Project Management Resources on the Web
 Web-based resources exist to support project management best
practices