Disc 3 IT health Admin

ATTACHED FILE(S)
3
Watch this video on SDLC (Software Development Life Cycle) steps -https://www.youtube.com/watch?v=gNmrGZSGK1k). Analyze the SDLC process explained in the video. How it would differ/be the same when applied to the development of Healthcare Management Information Systems (HMIS) and/or Healthcare Information Systems (HIS)? Explain which of the step(s) can you omit if your organization does not maintain internal IT staff (Hint: Feasibility Study slide), and how would you complete this step of the SDLC process without affecting the integrity of the HMIS/HIS? Justify the cyclic nature of the SDLC process.
Develop the managerial process steps with 2-3 main action item points intended to define the specific requirements for the necessary HMISorHIS acquisition (https://tettra.com/article/management-process/).Make sure it follows a basic process decision-making model (http://www.free-management-ebooks.com/news/decision-making-models/)to make a choice between turn-on or in-house built system considering the economic, workforce, scope of practice and application as well as managerial compliance of the final decision.
CHAPTER
361
HEALTH INFORMATION TECHNOLOGY
PROJECT PORTFOLIO MANAGEMENT
Learning Objectives
1. Identify some of the primary causes of health information technology
(HIT) project failures.
2. Describe the main differences between HIT project management, HIT
program management, and HIT portfolio management.
3. Describe the five key processes of project management.
4. Understand how project metrics and portfolio dashboards can facilitate
HIT governance.
5. Describe the major roles and functions of the portfolio management
office.
6. Identify the actions and changes that are necessary in an organization to
reach the synchronized stage.
Overview
Healthcare in the United States now consumes more than 17 percent of the
country’s gross domestic product and is projected to grow to more than
19 percent by 2027 (Centers for Medicare & Medicaid Services 2020),
yet US residents generally do not live longer nor are they healthier than
those in other developed nations that spend less than half that amount on
healthcare (Papanicolas, Woskie, and Jha 2018). The reality of these statis-
tics, along with the Institute of Medicine’s 1999 report (To Err Is Human)
on preventable deaths in the United States, has energized federal and state
governments in ways that will continue to put pressure on healthcare organi-
zations. For example, plans for reduced reimbursement rates will counteract
the increasing pressure for a healthy bottom line. Clearly, just by their sheer
size—seven-, eight-, or even nine-figure expenditures—electronic health
record (EHR) projects (depending on the size of the organization) should
automatically create a heightened need for due diligence among healthcare
executives; nothing can get an executive fired faster than spending $50 mil-
lion with nothing to show for that investment.
10
C
o
p
y
r
i
g
h
t

2
0
2
0
.

A
U
P
H
A
/
H
A
P

B
o
o
k
.
A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

M
a
y

n
o
t

b
e

r
e
p
r
o
d
u
c
e
d

i
n

a
n
y

f
o
r
m

w
i
t
h
o
u
t

p
e
r
m
i
s
s
i
o
n

f
r
o
m

t
h
e

p
u
b
l
i
s
h
e
r
,

e
x
c
e
p
t

f
a
i
r

u
s
e
s

p
e
r
m
i
t
t
e
d

u
n
d
e
r

U
.
S
.

o
r

a
p
p
l
i
c
a
b
l
e

c
o
p
y
r
i
g
h
t

l
a
w
.
EBSCO Publishing : eBook Collection (EBSCOhost) – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS
AN: 2546243 ; Gerald L. Glandon, Donna J. Slovensky, Detlev H. Smaltz.; Information Technology for Healthcare Managers, Ninth Edition
Account: s4264928.main.eds
I n f o r m a t i o nTe c h n o l o g yf o rH e a l t h c a r eM a n a g e r s362
In their presentation titled “IT Disasters: The Worst IT Debacles and
the Lessons Learned from Them” at the American College of Healthcare
Executives Congress on Healthcare Leadership, Hunter and Ciotti (2006)
provided ample evidence that risks are associated with large-scale health infor-
mation technology (HIT) projects. While inadequate planning and foresight
are problematic in such projects, the single greatest cause of project failure is
poor execution (Abouzahra 2011; Hunter and Ciotti 2006). Furthermore,
historical studies have suggested that HIT systems may have caused, rather
than reduced, medical errors (Han et al. 2005; Koppel et al. 2005) and more
recently may contribute to physician fatigue and burnout (Downing, Bates,
and Longhurst 2018; Shanafelt et al. 2015). However, a careful reading of
these academic articles shows the obvious system design and implementation
problems indicating that medical errors are caused by human error, caregiver
fatigue and burnout, and workflow process design, and not the HIT itself.
In 2010, studies revealed that 65 percent of HIT projects failed to
achieve anticipated benefits (Standish Group 2011). Organizations that fell
into the category of the 65 percent who failed to achieve benefits often relied
on the collective experience of the individuals who have previously imple-
mented HIT at the organization but typically did not employ disciplined
project management methodologies, such as those suggested by the Project
Management Institute (www.pmi.org; discussed in more detail later in this
chapter). As more and more organizations employ disciplined project man-
agement practices, those metrics have started to turn around. A recent Proj-
ect Management Institute (PMI 2017b) survey of more than 3,200 project
management professionals found that only about 31 percent of HIT projects
did not meet their goals, while 43 percent still exceeded initial budget esti-
mates, and 49 percent were completed late (see exhibit 10.1).
EXHIBIT 10.1
IT Project
Success
Statistics
60%
50%
40%
30%
20%
10%
0%
Total Failure Failure to
Meet Goals
Exceeded
Budget
Completed
Late
Source: Data from PMI (2017b).
EBSCOhost – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
C h a p t e r1 0 :H e a l t hI n f o r m a t i o nTe c h n o l o g yP r o j e c tP o r t f o l i oM a n a g e m e n t 363
Healthcare delivery is a complex business with incredibly multifaceted,
interdependent workflows, yet the field as a whole has been inexplicably slow
to adopt professional project management approaches. Organizations that
fall into this category typically implement a go-live only to find that large
stakeholder groups or key workflows have been overlooked. These organiza-
tions must then scramble, after implementation, to reengineer processes that
easily could have been proactively addressed had the organization followed
disciplined project management methodologies. This chapter provides an
overview of HIT project management and encourages healthcare organiza-
tions to improve their project success rate by establishing an HIT project
portfolio management office.
What Is a Health Information Technology Project
Portfolio Management Office?
The following terms and their definitions are used in this chapter to clarify
concepts related to portfolio management:
• A project is a temporary effort to create a unique product, service, or
result (PMI 2017a).
• Project management is the application of knowledge, skills, tools, and
techniques to project activities in an effort to meet project requirements
(PMI 2020).
• A program is a group of related, often interdependent projects.
• A portfolio is a collection of programs and projects.
• Portfolio management encompasses managing the collections of
programs and projects in a portfolio. This responsibility includes
weighing the value of each project, or potential project, against
desired organizational strategic business and clinical objectives. It
also encompasses monitoring active projects to ensure adherence to
specified objectives and desired outcomes, balancing the portfolio with
other investments of the organization, using resources efficiently, and
balancing return on investment with risk (PMI 2017a).
• A portfolio management office (PMO) is a centralized organization
dedicated to improving the practice and outcomes of projects via
holistic management of all projects.
While definitions can help distinguish concepts, often the terms proj-
ect management office, program management office, portfolio management
office, and project portfolio management office are used interchangeably in
the business press. All imply the professional management and oversight of
EBSCOhost – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
I n f o r m a t i o nTe c h n o l o g yf o rH e a l t h c a r eM a n a g e r s364
an organization’s entire collection of current projects. PMO, however, spe-
cifically refers to the activity of providing investment decision support capa-
bilities to an organization’s overall HIT governance structure and processes.
The term project management office or program management office does not
necessarily mean that decision support capabilities for these investments are
in place. Organizations that use the term PMO or project portfolio manage-
ment office are intentionally and accurately referring to a more expansive
concept, reflecting the methodology’s HIT portfolio investment decision
support capabilities (Jeffery and Leliveld 2004). In short, effective PMOs
are (1) aligned with and serve an organization’s strategic governance and
investment decision-making processes and (2) practice disciplined project
management in the successful execution of the organization’s projects. To
be consistent, we use the term PMO throughout this chapter. Exhibit 10.2
illustrates how projects, and programs of projects, might interrelate in a typi-
cal HIT portfolio.
Individual projects, such as a new inpatient EHR or a new pharmacy
system, are grouped into a clinical applications program. Ideally, clinical
application projects are led or championed by an influential stakeholder from
the clinical leadership of an organization. Likewise, upgrades of an existing
financial budgeting system and implementation of a new human resource
system are grouped into a business applications program. Business application
projects are ideally led or championed by an influential business stakeholder.
Purely infrastructure–type projects, such as a network upgrade or implemen-
tation of wireless technology, are grouped into an HIT infrastructure program
Inpatient EHR
project
Pharmacy system
project
Business
Applications
Program
Human resource
system project
Financial system
project
Network upgrade
project
Wireless project
HIT
Infrastructure
Program
Clinical
Applications
Program
Note: EHR = electronic health record, HIT = health information technology.
EXHIBIT 10.2
HIT Portfolio
EBSCOhost – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
C h a p t e r1 0 :H e a l t hI n f o r m a t i o nTe c h n o l o g yP r o j e c tP o r t f o l i oM a n a g e m e n t 365
championed or led by the chief information officer (CIO) or one of the
CIO’s key directors. All of the projects in all program groupings then make
up the entire HIT portfolio that can be professionally managed via formal
HIT portfolio management structures and practices—an HIT PMO.
Why Is a Portfolio Management Office Essential?
As indicated earlier in exhibit 10.1, there continues to be room for improve-
ment with respect to projects meeting intended goals, remaining on budget
and on time (PMI 2017b). One of the primary causes of failed HIT projects
is a “silo” project management mentality, which occurs when projects are ini-
tiated, planned, and fully executed without an effective consideration of their
impact on other, preexisting systems or other parallel projects being planned
and executed. As indicated in exhibit 10.2, contemporary healthcare appli-
cations have significant interdependencies that, if not explicitly and deliber-
ately addressed, can have unintended consequences. Exhibit 10.3 provides
real-world examples of unintended consequences of HIT projects that were
planned and executed in relative isolation.
While the examples described in exhibit 10.3 may seem to be obvious,
common-sense mistakes, they are not uncommon because in reality health-
care delivery organizations have thousands of cross-departmental interrelated
workflows that must be considered when embarking on a new HIT project.
Exhibit 10.4 depicts sample high-level application interfaces that are in place
at a typical academic medical center that is representative of any medium-to-
large integrated delivery system. This graphic conveys an incredibly complex
web that relies heavily on interfacing applications wherever possible. The
sheer volume of interdependencies shown in this exhibit clearly makes a case
that individual projects or programs of applications should not be managed
in silos but rather in a professional PMO focused on successfully achieving
envisioned benefits of particular projects.
In many ways, allowing informal, silo-based project management to
occur in a healthcare organization is somewhat like attempting to minimize
collisions at an airport without the benefit of a flight control tower. Not inci-
dentally, exhibit 10.4 resembles a typical major airline hub city with flights
coming and going from all points on the compass, yet it depicts a real organi-
zation’s current applications and how each is interfaced and interrelated. This
level of interrelatedness strongly suggests the need for a professional control
tower to manage HIT projects. An organization’s ability to implement large
HIT projects successfully and efficiently increases as its project management
maturity moves from no professionally managed projects to simple project
management to program management and ultimately to portfolio manage-
ment (PMI 2018).
EBSCOhost – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
I n f o r m a t i o nTe c h n o l o g yf o rH e a l t h c a r eM a n a g e r s366
Typically, as an organization’s HIT project management matures,
its overall cost of HIT projects decreases significantly and the success rate
of these projects increases substantially. A nonintuitive overall time savings
occurs as well, although one would suspect that it would take more time to
accomplish the additional work of identifying and tracking interdependencies
with other projects across the portfolio of projects. However, this additional
IT Project Project Outcome
New Pharmacy System
The pharmacy
director sponsored
a new best-of-
breed pharmacy
system project
The pharmacy system project was expertly managed and
implemented on time and within budget. Unfortunately,
only after the system was implemented did the pharma-
cist realize that this new proprietary best-of-breed system
could not be reliably interfaced with the hospital’s preexist-
ing EHR system, which had built-in computerized physician
order entry capability. As such, when a provider entered
an order for a pharmaceutical into the EHR, that order had
to be printed out in the pharmacy and then reentered into
the new pharmacy system. From a pure project manage-
ment standpoint, the project was successful. From an
enterprise portfolio standpoint, however, a very inefficient,
labor-intensive workflow was created to overcome the lack
of integration that this silo-based project management
approach created.
Voice Over Internet Protocol (VOIP) Project:
A telecommuni-
cations director
sponsored a switch
to digital phone
service
The telecommunications director of a large metropolitan
hospital system wanted to save millions of dollars annually
by switching from a basic traditional phone service model
to a VOIP model, whereby the hospital system’s existing
computer network would be used to provide digital phone
service. Unfortunately, the project did not consider the
robustness of the existing computer network, which had
single points of failure in many of its buildings. The digital
phone service was implemented, and soon thereafter, any
network outage to one of the buildings affected all phone
service for the building. More than an inconvenience,
these outages eroded consumer trust and market appeal.
Using contingency funds, the hospital system scrambled
to redesign its computer network to provide the level of
redundancy and reliability needed to ensure digital phone
service. Had a portfolio management approach been
taken for this project, computer network inadequacies
could have been identified up front and computer network
upgrades could have been built into the project plan.
EXHIBIT 10.3
Examples of HIT
Projects That
Did Not Follow
an HIT Portfolio
Management
Approach
EBSCOhost – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
C h a p t e r1 0 :H e a l t hI n f o r m a t i o nTe c h n o l o g yP r o j e c tP o r t f o l i oM a n a g e m e n t 367
te
xt
E
G
at
e
In
te
rf
ac
e
E
ng
in
e
(S
un
/S
ee
B
ey
on
d
)
B
ed
si
de
(C
lin
iC
om
p)
C
ar
di
ol
og
y
(C
F
P)
D
ie
ta
ry

(C
B
O
R
D
)
La
bs
/P
at
h
(S
un
qu
es
t)
M
at
er
ie
l S
ys
.
(O
m
ni
C
el
l)
P
ha
rm
ac
y
(G
E
)
R
ad
io
lo
gy
(I
D
X
R
ad
)
R
ad
O
nc

(S
ie
m
en
s)R
es
pi
ra
to
ry

(C
lin
iV
is
io
n
)
R
es
pi
ra
to
ry

(S
ta
tL
ab
)
S
w
itc
hb
oa
rd

(X
T
en
d)
La
bs
/U
R
L
(A
nt
rim
)
E
C
G
(G
E
)
In
st
ru
m
en
ts
M
at
er
ie
l S
ys

(C
la
ss
)
D
is
pe
ns
in
g
(P
yx
is
)
P
A
C
S
(A
G
F
A
)
D
IC
O
M

M
od
al
iti
es
E
nd
os
co
py

(P
ro
V
at
io
n)
T
ra
ns
pl
an
t
(H
om
eg
ro
w
n)
E
m
er
ge
nc
y
E
D

(D
is
c
12
3)
E
ch
o
(H
ea
rt
la
b)
C
on
g
H
ea
rt

F
ai
l
(C
H
F)
P
V
S
(V
as
cu
P
ro
)
O
R
S
up
pl
ie
s
(Q
si
gh
t)
P
h
ys
ic
ia
n
C
h
ar
g
es
D
ia
g
n
o
si
s
O
rd
er
s
R
es
u
lt
s
S
ch
ed
u
lin
g
A
D
T
M
ed
R
ec
or
ds

(S
of
tM
ed
)
O
R
S
ch
ed
(O
R
IS
)
T
ra
ns
cr
ip
tio
n
(M
ed
Q
st
)
C
as
e
C
ar
t
F
ax
S
er
ve
r
H
ou
se
ke
ep
in
g
E
m
er
ge
nc
y
O
S
U

(I
be
x)
“V
is
it
D
at
ab
as
e”
O
ne
S
ou
rc
e
A
pp
s
O
ut
pa
tie
nt
R
eg
is
tr
at
io
n
/S
ch
ed
(I
D
X)
H
os
pi
ta
l I
nf
o
S
ys
te
m
(S
ie
m
en
s)
O
S
U
M
C
P
at
ie
n
t
A
cc
o
u
n
ti
n
g
E
as
t
P
at
ie
n
t
A
cc
o
u
n
ti
n
g
Ja
m
es
P
at
ie
n
t
A
cc
o
u
n
ti
n
g
O
S
U
M
C
/
Ja
m
es
P
at
ie
n
t
M
an
ag
em
en
t
E
as
t
P
at
ie
n
t
M
an
ag
em
en
t
M
P
I –
E
A
D
Im
ag
in
g
ID
X
R
eg
ID
X
B
A
R
ID
X
S
ch
ed
A
B
N
C
he
ck
er
(M
ed
iQ
u
an
t)
W
eb
A
D
T
D
o
w
n
ti
m
e
F
o
rm
O
ut
pa
tie
nt
E
le
ct
ro
ni
c
H
ea
lth
R
ec
or
d
(E
P
IC
)
Fu
tu
re
D
ia
g
n
o
st
ic
D
ep
ar
tm
en
ta
l S
ys
te
m
s
H
o
sp
it
al
In
fo
rm
at
io
n
S
ys
te
m
s
C
lin
ic
al
D
ep
ar
tm
en
ta
l S
ys
te
m
s
S
u
p
p
o
rt
S
ys
te
m
s
H
om
e
H
ea
lth

(H
B
O
C
)
G
C
R
C

(H
om
eg
ro
w
n)
R
es
ea
rc
h
D
at
ab
as
es
:
S
tu
de
nt
H
ea
lth

(P
yr
aM
E
D
)
R
ap
id
O
ns
et

D
et
ec
tio
n
In
fo
rm
at
io
n
W
ar
eh
ou
se
U
R
L
(A
tla
s)
C
P
D
C
ac
tu
s
O
rd
er
E
nt
ry
C
or
re
ct
io
ns
L
eg
en
d:
T
h
ic
ke
r
L
in
es
=
S
o
u
rc
e
R
in
g
s
sh
ad
ed
f
o
r
d
at
a
ty
p
e.
H
os
pi
ta
l S
ys
te
m
s
A
nc
illa
ry
S
ys
te
m
s
In
fo
W
ar
eh
ou
se
s
E
X
H
IB
IT
1
0
.4
E
xa
m
p
le
o
f T
yp
ic
al
H
o
sp
it
al
A
p
p
li
ca
ti
o
n
In
te
rf
ac
es
EBSCOhost – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
I n f o r m a t i o nTe c h n o l o g yf o rH e a l t h c a r eM a n a g e r s368
planning time, which is marginal, actually reduces the number of surprises and
“gotchas” that occur later when unforeseen interdependencies invariably crop
up in projects that are run in a more informal, silo approach, thus decreasing
overall project time (Alexander 2015; Hadjinicolaou and Dumrak 2017). One
of the main causes of time delays in projects is scope creep—when the original
agreed-on requirements for a system are continually expanded by the project
sponsors. With project management methodologies in place, added or new
requirements are collected and saved for a future version of the system so that
the original system scope can be implemented in the established time frames.
The next section addresses project management methodologies.
Thereafter, managing the collection of projects is discussed, and we reiterate
the suggestion that a PMO is a logical organizational response to the increas-
ing HIT complexity in healthcare organizations.
Project Management
Project management entails the following five processes (PMI 2017a):
1. Project initiation: launch of a process that can result in the
authorization of a new project
2. Project planning: definition of the objectives, scope, and plan of action
to achieve the desired outcomes
3. Project execution: actions to complete the work defined in the project
planning process
4. Project monitoring and controlling: measurements designed to assess
how well a project is being executed per the budget and deliverables
as well as to alert project managers to potential corrective actions that
might be necessary from time to time
5. Project closing: actions to terminate formally all activities associated with
the project either by delivering a finished product or by ceasing effort
on a canceled project
Professionalizing project management at a healthcare delivery organi-
zation means that each HIT project should follow these five key processes.
While project management frameworks are important, hiring profession-
ally trained and well-credentialed project managers is equally important. A
number of project management credentialing organizations exist, including
the PMI, which offers the Project Management Professional (PMP) certi-
fication. The PMP certification ensures that an individual has mastered a
requisite body of knowledge on project management (see exhibit 10.5 for
a list of applicable knowledge areas) and has at least 60 months of project
EBSCOhost – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
C h a p t e r1 0 :H e a l t hI n f o r m a t i o nTe c h n o l o g yP r o j e c tP o r t f o l i oM a n a g e m e n t 369
management experience. Furthermore, survey data suggest that increasing
the number of individuals in the organization who have professional project
management skills and experience and following an explicit HIT project
management process framework raise the likelihood that the project will be a
success (PMI 2017a); see exhibit 10.6.
Project Management Knowledge Area Individuals Must Know How To
Project integration management Develop project charter
Develop project management plan
Direct and manage project execution
Manage project knowledge
Monitor and control project work
Perform integrated change control
Close project or phase
Project scope management Plan scope management
Collect requirements
Define scope
Create work breakdown structure
Verify scope
Control scope
Project schedule management Plan schedule management
Define activities
Sequence activities
Estimate activity resources
Estimate activity durations
Develop schedule
Control schedule
Project cost management Plan cost management
Estimate costs
Determine budget
Control costs
Project quality management Plan quality management
Manage quality
Control quality
Project resource management Plan resource management
Estimate activity resources
Acquire resources
Develop team
Manage team
Control resources
Project communications management Plan communications management
Manage communications
Monitor communications
EXHIBIT 10.5
Project
Management
Knowledge
Areas
(continued)
EBSCOhost – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
I n f o r m a t i o nTe c h n o l o g yf o rH e a l t h c a r eM a n a g e r s370
Project Management Tools
A number of project management applications are available that provide
the automated support to manage projects more professionally. While not
intended to be an exhaustive list, the following are applications that Hen-
derson, Stang, and Shoen (2019) rate highly for being able to provide auto-
mation to support the five project management processes outlined earlier;
Project Management Knowledge Area Individuals Must Know How To
Project risk management Plan risk management
Identify risks
Perform qualitative analysis
Perform quantitative analysis
Plan risk responses
Implement risk responses
Monitor risks
Project procurement management Plan procurements
Conduct procurements
Control procurements
Project stakeholders management Identify stakeholders
Plan stakeholder engagement
Management stakeholder engagement
Monitor stakeholder engagement
Source: Information from PMI (2017a).
EXHIBIT 10.5
Project
Management
Knowledge
Areas
(continued )
Note: PMO = portfolio management office.
EXHIBIT 10.6
Benefits of HIT
PMO
EBSCOhost – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
C h a p t e r1 0 :H e a l t hI n f o r m a t i o nTe c h n o l o g yP r o j e c tP o r t f o l i oM a n a g e m e n t 371
many of these applications also carry the higher-level program and portfolio
management capabilities discussed later in this chapter:
• Broadcom: Clarity PPM
• Changepoint: Daptiv PPM and Changepoint
• Microsoft: Project Server, Project Online, Project, Planner, and Teams
• Planview: Enterprise One, PPM Pro, Projectplace, LeanKit, and Spigit
• Planisware: Enterprise and Orchestra
Standardizing HIT operations on a set of project and portfolio man-
agement tools provides a common way to establish the processes and business
rules that an organization must follow for managing projects. For instance,
a healthcare organization’s applications group uses one tool (say, Microsoft
Project software), the infrastructure group uses a different tool (say, Broad-
com’s Clarity PPM), and the informatics and analytics group uses no tool at
all. Because there is no visibility into the total number of projects going on
among these groups, it becomes incredibly difficult to establish standardiza-
tion of project management processes that is a prerequisite for managing
interdependencies between projects; thus, it is difficult to achieve program
or portfolio management capabilities.
Entire textbooks have been written on project management (e.g.,
Coplan and Masuda 2011; Schwalbe 2016) and the tools that support it. For
illustrative purposes, we discuss project plans and Gantt charts as examples
of key artifacts that are easily developed in most project management and
portfolio management tools.
Project Plans and Gantt Charts
All project management applications should have the ability to create a
project plan and display it in a way that easily shows task interdependencies.
Exhibit 10.7 shows a simple example of a Gantt chart for some tasks in an
infrastructure project of a hospital system. This list of tasks is known as a
work breakdown structure in project management parlance. Note how the
interdependencies are clearly visible by the linking arrows that show which
tasks must be fully completed before their successor tasks can begin. Other
tasks without these interdependencies can be accomplished in parallel (i.e.,
they have no interdependencies but must nevertheless be accomplished
to complete the project). Project management applications have the abil-
ity to collapse these tasks—these are all of the tasks that have predecessor
(tasks that must be completed before the next tasks can be started) or suc-
cessor (tasks that cannot begin until certain tasks have been completed)
interdependencies— into the critical path of a project (see exhibit 10.8). The
reason critical path analysis is important is that it provides a forecast of the
shortest possible time in which the overall project can be completed.
EBSCOhost – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
I n f o r m a t i o nTe c h n o l o g yf o rH e a l t h c a r eM a n a g e r s372
E
X
H
IB
IT
1
0
.7
P
ro
je
ct
P
la
n
in
G
an
tt
C
h
ar
t
Fo
rm
at
EBSCOhost – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
C h a p t e r1 0 :H e a l t hI n f o r m a t i o nTe c h n o l o g yP r o j e c tP o r t f o l i oM a n a g e m e n t 373
E
X
H
IB
IT
1
0
.8
C
o
ll
ap
se
d
P
ro
je
ct
P
la
n
G
an
tt
C
h
ar
t
S
h
o
w
in
g
O
n
ly
t
h
e
C
ri
ti
ca
l P
at
h
EBSCOhost – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
I n f o r m a t i o nTe c h n o l o g yf o rH e a l t h c a r eM a n a g e r s374
Program Management
As noted earlier, organizations that put in place program management capa-
bilities have moved beyond managing individual projects to managing the
interrelationships between projects and preexisting applications and systems.
While managing this level of complexity takes slightly longer to plan up
front, the extra time expended is recovered during the execution phase of the
project in the form of reduced surprises and cost overruns associated with
unforeseen interdependencies. In essence, the critical dependency analysis
and management depicted in exhibits 10.7 and 10.8 are simply extended
beyond a single project to interdependencies that exist within a particular
program of projects or even across the HIT portfolio (see exhibit 10.2).
Portfolio Management
Along with the professional project management expertise described in the
previous sections, organizations that employ a portfolio management approach
also have tightly coupled HIT governance (essentially, making decisions about
which information technology to invest in and which not to invest in) with its
PMO. In other words, think of project and program management as ensuring
that things are done right in a particular project, whereas portfolio manage-
ment concerns itself with doing the right kinds of projects that align with the
organization’s overall strategic goals and objectives. This distinction is why a
PMO must work hand-in-hand with an organization’s HIT governance struc-
ture (covered in chapter 4). Illustrating this point is exhibit 10.9, which shows
an HIT portfolio of all the projects that are “in flight” at a for-profit healthcare
organization. Prior to its annual HIT capital budget process, the particular
organization, using the knowledge gained from professionally managing its
portfolio of current HIT projects, put together a profile of all of the current
HIT projects already in flight and rated them on the basis of value and risk.
The organization further labeled each quadrant. The lower left quadrant, which
represents low-value and high-risk HIT projects, is labeled “Think Twice (or
More).” The upper right quadrant represents HIT projects that are deemed to
both be of high value and have low risk associated with implementation; this
quadrant is labeled “Ideal.” The size of the bubbles in exhibit 10.9 denotes the
size in relative dollars of each individual project. Projects are categorized into
nondiscretionary projects (e.g., some projects are mandated by law, such as the
Sarbanes-Oxley Act) and discretionary projects. Much like an investor review-
ing a portfolio of stocks before deciding which to divest and which to add to,
an organization developing a graphic such as exhibit 10.9 gains a powerful and
succinct decision-support means to evaluate proposed HIT projects.
In addition to decision support, an HIT portfolio management capabil-
ity also provides regular portfolio status reports to the HIT governance of an
organization. For instance, an HIT portfolio dashboard is typicallycreated—
sometimes via one of the project and portfolio management applications and
EBSCOhost – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
C h a p t e r1 0 :H e a l t hI n f o r m a t i o nTe c h n o l o g yP r o j e c tP o r t f o l i oM a n a g e m e n t 375
sometimes via an organization’s overall quality or other enterprise dashboard
tools—to give leadership a view of project progress. Exhibit 10.10 is a sample
of one such view, showing all in-flight projects of the organization (listed
in exhibit 10.9) grouped by strategic categories that are important to the
organization, along with the dollar amounts budgeted for each category. The
graph on the left of this exhibit, titled “Portfolio by Category,” depicts the
monthly expenditures of each project category. The graph on the right of
this exhibit, titled “Resource by Category,” depicts the amount of full-time
equivalent resources being expended on each project category.
While an HIT portfolio dashboard can be set up to provide status along
any number of dimensions, its greatest impact comes in providing strategic
views of the myriad projects the organization is working on to benefit HIT
governance decision-making. In the examples provided in exhibits 10.9 and
10.10, this for-profit healthcare organization is trying to balance strategically
the need for greater regulatory compliance with the Sarbanes-Oxley Act and
other legislation with the need for revenue growth. Therefore, the dashboard
is designed to quickly provide a view within the past three quarters and the
Risky, But Worth it? Ideal
Low Risk, But
Worth it?
Think Twice
(or More)
5
4.5
4
3.5
3
2.5
2
1.5
1
0.5
0
Va
lu
e
5 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0
6
1
2
11
8
23
22
16
20
2418
9
10
15
14
25
5 19
4
17
13
3
7
12
21
1 Connected
2 Diagnostic System (IDX)
3 Motion Tablet Deployment
4 Basic Relationship
Management
5 Smart Order (eProcurement)
6 Hyperion
7 DSL for Outpatient
8 Automated Bank Recon.
Project circle size determined by budget
Denotes Nondiscretionary Projects Denotes Discretionary Projects
9 People Soft Enforcer
10 HIPAA Security Regulation
11 Patcom
12 Property Tax Mgt. System
13 Business Cont. Planning
14 Policy IQ
15 Identity Mgt. System
16 Concuity Contract Mgr.
17 ISS (Black Ice, Server Sen.)
18 Sales Territory Mgt. System
19 Problem Mgt. System
20 TherapySource Patient Reg.
21 Corporate Web. Devl.
22 People Soft Financials
23 SIS Windows Conversion
24 Outpatient Document Imaging
25 CPSI
Key Risk
Source: Carpenter (2005). Used with permission.
EXHIBIT 10.9
Illustrative HIT
Portfolio
EBSCOhost – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
I n f o r m a t i o nTe c h n o l o g yf o rH e a l t h c a r eM a n a g e r s376
next six quarters of the amount of money being (or slated to be) invested in
compliance-related projects, operational effectiveness projects, and projects
the organization hopes will generate increased revenue. While this example
is illustrative—not intended to be definitive—this example makes the point
that organizations must be able to produce flexible data representations (such
as exhibit 10.9) on the entire portfolio of HIT projects to aid their HIT
governance bodies. Such data are essential to making informed investment
decisions and monitoring progress.
The Portfolio Management Office
Generally, these high-functioning portfolio management capabilities are
being formalized in many leading healthcare organizations via the establish-
ment of an HIT PMO. Typically, the functions of a PMO include but are not
limited to the following:
• Issuing regular communications to project stakeholders and the rest of
the organization regarding progress or status, programs of projects, and
the entire portfolio
Source: Carpenter (2005). Used with permission.
EXHIBIT 10.10
Sample HIT
Portfolio
Dashboard
EBSCOhost – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
C h a p t e r1 0 :H e a l t hI n f o r m a t i o nTe c h n o l o g yP r o j e c tP o r t f o l i oM a n a g e m e n t 377
• Providing authoritative management and oversight of all projects in the
portfolio
• Serving as staff support to the HIT governance of the organization,
including performing portfolio analyses as requested by HIT
governance and recommending HIT investments
• Creating metrics and dashboards to facilitate transparency
These tasks can be accomplished without putting in place a formal
PMO, but there is some evidence to suggest that organizations that institute
a PMO may have a competitive advantage over those that do not (Caliste
2013). Do note that establishing a PMO is not a quick fix to whatever project
management challenge the organization is facing, and it is an effort that likely
will take between two and four years to generate significant benefits for the
organization. Jeffery and Leliveld (2004), from data derived in their study of
130 Fortune 1,000 companies, created the useful IT Portfolio Management
Maturity Model, which outlines the four stages of maturity of any organiza-
tion’s portfolio management capabilities. Jeffery and Leliveld refer to these
four stages as ad hoc, defined, managed, and synchronized; each stage indicates
a higher, more capable PMO function.
In the ad hoc stage, no formal project management capability is in
place at all. Projects are managed informally and inconsistently, and project
results are equally inconsistent.
In the defined stage, the organization has created a centralized entity
to maintain and inventory projects and to manage them centrally. In this
stage, applications and infrastructure are well defined and documented.
In the managed stage, the organization has created processes for vet-
ting and rationalizing or ranking projects on the basis of key strategic criteria.
Furthermore, investment decisions employ financial metrics to help prioritize
projects (e.g., return on investment, return on assets, net present value) and
conduct at least annual reviews with business unit leadership on how well the
HIT portfolio is aligned with overall organizational strategies.
In the synchronized stage, organizations conduct much more frequent
evaluations of the HIT portfolio with business unit leaders and include a con-
sistent assessment of returns versus risks in their project portfolios. Typically,
organizations at the synchronized level of HIT portfolio management matu-
rity have created PMO scorecards or dashboards that serve to communicate
project status and value transparently. They also consistently conduct post-
project benefits realization assessments to see whether benefits envisioned
prior to the project’s adoption have been achieved.
Since Jeffery and Leliveld (2004) articulated this maturity model,
there has been considerable debate in the project management community
about the best framework to use for assessing an organization’s maturity
EBSCOhost – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
I n f o r m a t i o nTe c h n o l o g yf o rH e a l t h c a r eM a n a g e r s378
(Pasian, Sankaran, and Boydell 2011; PMI 2017a; Zhang, He, and Zhang
2012). Each framework suggests more complex and granular approaches
for assessing an organization’s project management capabilities. While the
debate continues, Jeffery and Leliveld’s model continues to provide HIT
leaders and professionals with a simple, quick way of assessing the maturity
of their organization’s HIT portfolio management capabilities.
Summary
This chapter made the case that many HIT projects generally do not achieve
the benefits envisioned and that implementing professional portfolio man-
agement capabilities is an important first step toward mitigating this project
risk. Furthermore, identifying and managing the cross-project interdepen-
dencies that a portfolio management approach embodies is an important
second step toward mitigating project risk. Finally, implementing an HIT
PMO that is tightly coupled with an organization’s HIT governance struc-
tures and processes and that provides the full complement of capabilities
outlined in Jeffery and Leliveld’s (2004) IT Portfolio Management Maturity
Model represents the greatest return on HIT investments for a healthcare
organization.
Web Resources
A number of organizations (through their websites) provide more informa-
tion on the topics discussed in this chapter:
• Vendors that provide project and portfolio management software
include the following:
– CA Technologies: Broadcom, Clarity Project, and Portfolio
Management software (www.ca.com/us/services-support/
ca-services/project-portfolio-management-services.html)
– Changepoint: PPM software (www.changepoint.com)
– Planview: Project Portfolio Management (www.planview.com/
products-solutions/solutions/project-portfolio-management)
– Microsoft: project software (https://products.office.com/en-us/
project/project-and-portfolio-management-software)
• Other website references for project and portfolio management include
these:
– CIO magazine, Project Management section (www.cio.com/
topic/3198/Project_Management)
EBSCOhost – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
C h a p t e r1 0 :H e a l t hI n f o r m a t i o nTe c h n o l o g yP r o j e c tP o r t f o l i oM a n a g e m e n t 379
– Healthcare Information and Management Systems Society,
Project Management Special Interest Group (www.himss.org/
project-management)
– The Project Management Institute conference paper on PMOs
in healthcare IT organizations (www.pmi.org/learning/
library/project-management-office-healthcare-information-
technology-8060)
Discussion Questions
1. Discuss some of the primary reasons an HIT implementation project
might fail in a healthcare organization.
2. What are the main differences between HIT project management, HIT
program management, and HIT portfolio management?
3. What are the five processes of project management?
4. What requirements should be considered when selecting project
management tools for an organization?
5. Why are project metrics and portfolio dashboards important to HIT
governance?
6. List and describe the major roles and functions of the PMO.
7. Which two project management knowledge areas described in exhibit 10.5
do you consider to be the most important? Why?
8. What actions and changes are necessary in an organization to reach the
synchronized stage of maturity of Jeffery and Leliveld’s IT Portfolio
Management Maturity Model?
9. Even with the development of a PMO, will there be instances in which
an HIT venture fails? Explain your rationale.
References
Abouzahra, M. 2011. “Causes of Failure in Healthcare IT Projects.” International Con-
ference on Advanced Management Science. Accessed March 11, 2020. https://
pdfs.semanticscholar.org/d9f2/fb98c62b4dbd69510d7dffa016de722a6631.pdf.
Alexander, M. 2015. “Planning Is Key to Project Management Success.” CIO. Published
June 10. www.cio.com/article/2932987/planning-is-key-to-project-management-
success.html.
Caliste, A. 2013. “The PMO, Maturity, and Competitive Advantage.” Paper
presented at the PMI Global Congress 2013—North America, New
Orleans, LA, October 29, 2013. www.pmi.org/learning/library/project-
office-management-competitive-advantage-5843.
EBSCOhost – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
I n f o r m a t i o nTe c h n o l o g yf o rH e a l t h c a r eM a n a g e r s380
Carpenter, R. 2005. “IT Governance.” Guest lecture, University of Alabama at Birming-
ham, Birmingham, AL, January 8.
Centers for Medicare & Medicaid Services. 2020. “National Health Expenditure Projections
2018–2027.” Accessed January 15. www.cms.gov/Research-Statistics-Data-and-
Systems/Statistics-Trends-and-Reports/NationalHealthExpendData/ Downloads/
ForecastSummary.pdf.
Coplan, S., and D. Masuda. 2011. Project Management for Healthcare Information Tech-
nology. New York: McGraw-Hill Company.
Downing, N. L., D. W. Bates, and C. A. Longhurst. 2018. “Physician Burnout in the Elec-
tronic Health Record Era: Are We Ignoring the Real Cause?”Annals of Internal
Medicine. Published July 3. https://annals.org/aim/article-abstract/2680726/
physician-burnout-electronic-health-record-era-we-ignoring-real-cause.
Hadjinicolaou, N., and J. Dumrak. 2017. “Investigating Association of Benefits and Bar-
riers in Project Portfolio Management to Project Success.” Procedia Engineering
182: 274–81.
Han, Y. Y., J. A. Carcillo, S. T. Venkataraman, R. S. Clark, R. S. Watson, T. C. Nguyen,
H. Bayir, and R. A. Orr. 2005. “Unexpected Increased Mortality After Imple-
mentation of a Commercially Sold Computerized Physician Order Entry System.”
Pediatrics 116 (6): 1506–12.
Henderson, A., D. Stang, and M. Schoen. 2019. “Magic Quadrant for Project and
Portfolio Management.” Gartner. Published May 21. www.gartner.com/en/
documents/3917095/magic-quadrant-for-project-and-portfolio-management.
Hunter, D. P., and V. Ciotti. 2006. “IT Disasters: The Worst Debacles and Lessons
Learned from Them.” Healthcare Executive 21 (5): 8–12.
Institute of Medicine. 1999. To Err Is Human: Building a Safer Health System. Washing-
ton, DC: National Academies Press.
Jeffery, M., and I. Leliveld. 2004. “Best Practices in IT Portfolio Management.” Sloan
Management Review 45 (3): 41–49.
Koppel, R., J. P. Metlay, A. Cohen, B. Abaluck, A. R. Localio, S. E. Kimmel, and B. L.
Strom. 2005. “Role of Computerized Physician Order Entry Systems in Facilitat-
ing Medication Errors.” Journal of the American Medical Association 293 (10):
1197–203.
Papanicolas, I., L. Woskie, and A. Jha. 2018. “Health Care Spending in the United States
and Other High-Income Countries.” Journal of the American Medical Association
319 (10): 1024–39.
Pasian, B., S. Sankaran, and S. Boydell. 2011. “Factors for Designing a Second Generation
of Project Management Maturity Models. Paper presented at PMI Global Congress
2011—North America, Dallas, TX, October 22. www.pmi.org/learning/library/
second-generation-project-management-maturity-models-6241.
Project Management Institute (PMI). 2020. “What Is Project Management?” Accessed
January 14. www.pmi.org/about/learn-about-pmi/what-is-project-management.
EBSCOhost – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
C h a p t e r1 0 :H e a l t hI n f o r m a t i o nTe c h n o l o g yP r o j e c tP o r t f o l i oM a n a g e m e n t 381
———. 2018. PMI’s Pulse of the Profession: 10th Global Project Management Survey.
Accessed January 15, 2020. www.pmi.org/-/media/pmi/documents/public/
pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2018.pdf.
———. 2017a. A Guide to the Project Management Body of Knowledge (PMBOK Guide),
6th ed. Newtown Square, PA: Project Management Institute.
———. 2017b. PMI’s Pulse of the Profession: 9th Global Project Management Survey.
Accessed January 15, 2020. www.pmi.org/-/media/pmi/documents/public/
pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2017.pdf.
Schwalbe, K. 2016. Information Technology Project Management, 8th ed. Boston: Cen-
gage Learning.
Shanafelt, T., O. Hasan, L. Dyrbye, P. Sinsky, D. Satele, J. Sloan, and C. West. 2015.
“Changes in Burnout and Satisfaction with Work-Life Balance in Physicians and
the General US Working Population Between 2011 and 2014.” Mayo Clinic
Proceedings 90 (12): 1600–13.
Standish Group. 2011. CHAOS Manifesto. Boston: Standish Group.
Zhang, L., J. He, and X. Zhang. 2012. “The Project Management Maturity Model and
Application Based on PRINCE2.” Procedia Engineering 29: 3691–97.
EBSCOhost – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
EBSCOhost – printed on 6/14/2022 1:45 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
105
Chapter 5
System Selection and Implementation
Objectives
Assist in the system selection process.•
Assist in the system implementation.•
Participate in the implementation team.•
Develop training materials.•
Assist in the development review of the request for proposal.•
Assist in the system analysis process.•
Conduct training classes for users.•
Key Terms
Alpha site
Application service provider
(ASP)
Best of breed
Best of fit
Beta site
Chief information officer
Computer-assisted instruction
Data conversion
Escrow
Feasibility study
Force majeure
Functional requirements
Gantt chart
Go-live
Graphical user interface (GUI)
Information systems project
steering committee
Information systems strategic
planning
Interface
Interface engine
Middleware
Payment milestone
Project
Project definition
Project Evaluation and Review
Technique (PERT) chart
Project management
Project manager
Project team
Prototype
Reengineering
Report design
Request for information (RFI)
Request for proposal (RFP)
Scope creep
Screen design
Setting configuration
Site preparation
Site visits
Source code
System analysis
System development life cycle
(SDLC)
System evaluation
System implementation
System selection
Test environment
Testing
Train the trainer
User preparation
User task force
Weighted system
AB103409_ch05.indd 105AB103409_ch05.indd 105 2/1/10 1:20:38 PM2/1/10 1:20:38 PM
C
o
p
y
r
i
g
h
t

2
0
1
0
.

A
H
I
M
A

P
r
e
s
s
.
A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

M
a
y

n
o
t

b
e

r
e
p
r
o
d
u
c
e
d

i
n

a
n
y

f
o
r
m

w
i
t
h
o
u
t

p
e
r
m
i
s
s
i
o
n

f
r
o
m

t
h
e

p
u
b
l
i
s
h
e
r
,

e
x
c
e
p
t

f
a
i
r

u
s
e
s

p
e
r
m
i
t
t
e
d

u
n
d
e
r

U
.
S
.

o
r

a
p
p
l
i
c
a
b
l
e

c
o
p
y
r
i
g
h
t

l
a
w
.
EBSCO Publishing : eBook Collection (EBSCOhost) – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS
AN: 667498 ; Nanette B. Sayles, Kathy C. Trawick.; Introduction to Computer Systems for Health Information Technology
Account: s4264928.main.edsebook
106 Chapter 5
Introduction
System selection and system implementation is the process of deciding on an informa-
tion system (IS), preparing it, and training facility staff for use of the system in the health-
care facility. The system selection and implementation process begins with the idea that the
facility should consider obtaining a particular system such as the electronic health record
(EHR), for example. The process continues until the system is in use and has been evalu-
ated as to whether or not it meets the established objectives.
The complexity of the system selection and implementation process varies widely, from
implementing Microsoft Office or other standard software products to the very complex
implementation of an EHR system. The length of time required thus varies from a few days
or weeks to months or even several years. The number of people involved will also vary based
on who is impacted by the system and the complexity of the system to be implemented.
Systems selected should support the facility’s business objectives. The systems should
be identified and prioritized during the information systems strategic planning process,
as more systems are usually identified than the facility’s resources can handle. Strate-
gic information system planning is defined as “the process of identifying and assigning
priorities to the application of information technology that will assist an organization in
executing its business plans and achieving its strategic goals and objectives” (Austin and
Boxerman 2003, 259). For example, if a facility’s business objective is to meet a goal of
improved quality of care, then the facility should look for information systems that would
support this goal, such as the EHR or clinical provider order entry (CPOE). The EHR
would improve the quality of care because of the immediate access to patient information
as well as the use of alerts and other features. The CPOE would improve care because the
orders would be immediately available to the ancillary department, and the healthcare pro-
vider would be able to take advantage of reminders and alerts regarding contraindications,
the need for laboratory tests to monitor blood levels, and so on.
Steps included in the system selection process are:
Planning•
Organization of the project•
System analysis•
Request for proposal•
Evaluation of systems•
Selection of a system•
Contract negotiation•
Steps included in the implementation process are:
Site/space preparation•
Installation of hardware/software/networks•
Programming modifications to software•
User configurations and settings•
Interface development•
Report design•
Screen design•
Testing•
Training•
AB103409_ch05.indd 106AB103409_ch05.indd 106 2/1/10 1:20:38 PM2/1/10 1:20:38 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
System Selection and Implementation 107
Go-live•
Evaluation•
Some of the system selection and implementation steps are linear, but others can be
performed concurrently. For example, the contract has to be signed before the software
can be installed, but the organization can design screens and reports at the same time. It is
imperative to remember that throughout implementation and planning, the plan itself is a
working document and will continuously change and evolve. Flexibility is necessary. Each
of the system selection and implementation steps will be covered in this chapter.
Planning
Planning is critical to the system selection and implementation process. Planning for an
information system is a complex process and includes many steps such as:
Conducting a feasibility study•
Setting the budget•
Setting the goals and objectives•
Identifying the project manager•
Identifying the project team•
Determining who will build and maintain the system•
Choosing between integrated and interfaced systems•
Obtaining buy-in from management and users•
Training•
Planning a major system implementation requires a lot of work by a lot of people. A
lack of planning can and will cause problems with the system, which can cause the system
to fail or delay the implementation date, thus costing the facility money. An example of
poor planning is ordering hardware without evaluating the space. Insufficient space can
lead to inability to install the hardware due to insufficient electrical wiring, inadequate
space, or other problems with the physical plant.
Conducting a Feasibility Study
A feasibility study determines if a proposed information system is an appropriate option
to meet the objectives of the organization (Englebardt and Nelson 2002). The study exam-
ines the costs, the benefits, and any expected problems and determines whether or not to
proceed with the proposed system. The benefits should be both tangible and intangible.
Tangible benefits are easy to quantify (Austin and Boxerman 2003), such as elimination of
duplicate tests. Intangible benefits, while critical, are not easy to quantify. An example of
an intangible benefit would be to improve quality of care. If the benefits do outweigh the
costs, then the project should be considered.
Setting the Budget
Developing the budget for a system implementation is important since cost is a key deter-
mining factor in deciding whether or not to implement. The budget should be comprehen-
sive and as accurate as possible because it is used in the decision-making process. The
budget should include system selection and implementation expenses as well as the cost of
maintaining the system for a specified period of time, such as 2 to 5 years. Additionally, the
budget should include items such as cost of software, upgrading infrastructure, hardware,
training, renovations to the physical plant, maintenance of the system, project manage-
ment, and travel expenses for site visits.
AB103409_ch05.indd 107AB103409_ch05.indd 107 2/1/10 1:20:38 PM2/1/10 1:20:38 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
108 Chapter 5
Goals and Objectives
Goals and objectives for the system must be established as part of the planning process.
The goals and objectives identify what the facility wants to accomplish with the implemen-
tation of the proposed system and how these goals will be achieved. These system goals
should be based on the facility’s business goals (Austin and Boxerman 2003). As with any
goals, they should be measurable yet realistic and attainable. It never hurts to add on some
cushion time for any unforeseen issues. Examples of goals are: to reduce the number of
staff by five, to reduce the discharge not final billed (DNFB) report to $500,000, and to
reduce the number of duplicate tests by 75 percent. Goals will be determined by the type
of system and the needs of the facility. Once established, goals should be used to identify
which information system best meets the desired outcomes.
Once the system is implemented, it should be evaluated regularly thereafter as to
whether the system met and will continue to meet or exceed the stated goals and objectives.
For example, the post-implementation evaluation will identify whether the duplicate tests
were reduced by 75 percent or whether staffing was reduced by five.
Identifying the Project Manager and Project Team
The project manager and project teams are an important part of project management. Proj-
ect management is “a formal set of principles and procedures that help control the activi-
ties associated with implementing a usually large undertaking to achieve a specific goal,
such as an information system project” (Amtayakul 2007, 467). Project Leadership includ-
ing the project manager and the project team members should be identified before the
project begins. The project manager leads the project, and therefore must have an under-
standing of the system being implemented, knowledge of project management, leadership
skills, and conflict management skills (Amatayakul 2007). A sample project manager job
description is presented in figure 5.1. The project manager is responsible for ensuring that
the project plan stays within the designated timeline, issues are resolved, desired outcomes
are met, and customer satisfaction is achieved. A project team is a collection of multi-
disciplinary individuals (that is, billing, clinician, administration, IT) assigned to work on
a project. Their role is important because they are responsible for ensuring that the system
implementation plan is carried out according to the project manager’s specifications. Their
backgrounds will vary according to the needs of the project (Amatayakul 2007). For exam-
ple, implementation of an EHR will require information system staff, health information
management, physicians, nursing, and other clinical users of the system. The project team
will be discussed in detail later in the chapter.
Determining Who Will Build and Maintain the System
One of the critical decisions to be made during the planning process is whether a facility
should build the system itself, purchase it from a vendor, or use an application service
provider (ASP) (Austin and Boxerman 2003).
An ASP is a third-party service company that delivers, manages, and remotely hosts
(off-site, usually at the host location) standardized applications software via a network
through an outsourcing contract based on fixed, monthly usage or transaction-based pric-
ing (Amatayakul 2007).
With an ASP, a user simply logs into the system and accesses it exactly as if the data
center were located in-house, although the data center may be located at a great distance
from the facility. An ASP is similar to paying rent and can significantly reduce the capital
expenditures up front, and monthly expenditures are a preapproved flat-fee structure so
expenses are always known. This method is favored by facilities that do not have staff with
the necessary skills to develop and maintain a system. A disadvantage to the ASP format is
that the user may not have as much control over the system. For example, the scheduling of
maintenance and upgrades is up to the host, and the client has no say in the matter. Another
disadvantage is that since an organization is “renting” the system, it is not investing in its
AB103409_ch05.indd 108AB103409_ch05.indd 108 2/1/10 1:20:38 PM2/1/10 1:20:38 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
System Selection and Implementation 109
Position: EHR Project Manager
Reports to: Chief Science Officer
Key Functions and Responsibilities
Integrated Healthcare Information
1. Using an evidence-based approach, facilitate culture of having integrated healthcare information by screening clinical
systems for appropriate fit, integration potential, and timing of projects based on EHR architecture. This will be done
in partnership with the chief information officer and person(s) championing the specific clinical system.
Electronic Health Record System
2. Direct selection and implementation of EHR components to include:
a. Enterprisewide master person index
b. Clinical data repository
c. Document imaging to include medical (for example, PACS) and administrative images
d. Physician order-entry and electronic signature capabilities
e. Patient care documentation
f. Clinical decision support tools to include:
(1) Clinical alerts and reminders
(2) Care management protocols
g. Other information systems and emerging technology as necessary and feasible
3. Lead break-through project team to deliver the following:
a. Longitudinal record of patient care across the organization’s continuum of care sites
b. Clinician utilization of EHR that facilitates and enhances patient care delivery processes at the point of care
and remotely as appropriate
c. Patient interaction with clinicians, access to their personal health record of care at the organization, and quality
education
d. Tools that facilitate cost-effective care management and respond to a growing number of managed care
contracts
e. Capacity to perform large patient database searches and studies without impacting the performance of the EHR
in day-to-day activities
f. Support for the organization’s training and research programs
Business Process Redesign and Information Protection
4. Coordinate reengineering of work flows and patient care documentation with clinical users to leverage and
maximize organizational and personal productivity to improve patient care delivery processes.
5. Ensure that systems selected are compliant with all applicable laws, regulations, and standards, and that their
storage, retention, authentication, accuracy, and transmission integrity support admissibility.
6. Develop processes for determining who has access to specific health information; how users will be educated,
trained, and kept continually aware of patient privacy and security requirements to provide data confidentiality,
integrity, and availability; and ensure that ongoing auditing of access is performed and supported by appropriate
sanctions and disciplinary processes.
Budgetary/Operational Responsibility
7. Develop and account for operating and capital budgets for above processes.
8. Determine appropriate staffing and resource requirements for the EHR project.
9. Establish appropriate metrics and monitor benefits realization.
Skills/Experience Required:
• Knowledge of health information management and technology, clinical user needs, and healthcare work flow
• Extensive and progressive healthcare management experience
• Experience with the selection and implementation of healthcare information systems
• Ability to enroll and build strong relationships with all levels of management, physicians, and staff
• Ability to lead a project team through uncharted territory, shift paradigms, take risks, and bring ideas from concept
to reality
• Relentless focus on outcomes
Figure 5.1.Project manager job description
Adapted from Job Description for Director, Integrated Healthcare Information, Central DuPage Health System, Ann
Ogorzalek, RHIA
AB103409_ch05.indd 109AB103409_ch05.indd 109 2/1/10 1:20:38 PM2/1/10 1:20:38 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
110 Chapter 5
own structure and therefore would have to make a large investment should it ever decide to
bring the system in-house.
The second option would be for the facility to build the system. If a facility decides to
build a system, it would be designed to meet the specific needs of that facility. The system
would have the look and feel that is desired as well as the desired functionality. There are,
however, disadvantages such as:
It could take longer to develop.•
The planning must be more detailed than if purchasing a system.•
If the facility loses the staff that developed the system, it may be difficult to •
upgrade the system to meet the needs of the facility over time.
The final option mentioned here would be to purchase a predeveloped software system
from a vendor. As with the other options, there are advantages and disadvantages to this
option. A system purchased from a vendor may not be exactly what the facility wants, but
it would be faster to implement, and the facility would benefit from extensive research and
development conducted by the vendor. The design of the system would be less detailed,
but the facility would have the use of the vendor’s customer support system to assist with
upgrades and problems that arise.
When working with a vendor, the healthcare facility may have the opportunity to be an
alpha site. An alpha site is the first healthcare facility to implement the information system.
The facility generally receives a discount for the system in exchange for participation in the
development of the system. Because the system is still being developed, the facility may face
problems with the implementation that would not be encountered with a more mature version
of the same system. It also takes more time than a typical implementation. The facility may
also be asked to be a beta site. Beta sites are the next few healthcare facilities who subse-
quently implement the system. Many of the problems with the system are resolved with the
alpha site but these beta sites are likely to encounter numerous problems as well.
Choosing Between Integrated and Interfaced Systems
If the decision is made to purchase an information system from a vendor, the next decision
is whether the product should be integrated or interfaced.
Integrated Systems
Integrated systems are designed to work together. A good example of an integrated system
is Microsoft Office. The user can share information among Microsoft Word, Microsoft
Excel, and other products within the Office suite. Many healthcare vendors use this model
to interface systems used by healthcare facilities. This type of system is much easier to
manage than an interfaced system because of the lack of interfaces. Integrated systems
collect, store, and retrieve information from the same database and, further, technologies
allow that they support each other. The user is quickly able to move between systems
because they have the same look and feel, which can also make it easier to use (Austin and
Boxerman 2003). The decision to purchase software from a single vendor is frequently
called best of fit (Amtayakul 2007).
Interfaced Systems
In an interfaced system, the products are not designed to work together, but rather are
linked through an interface. An interface takes data from one system and plugs that data
into another system. In other words, an interface acts as a bridge between two systems/data-
bases to translate data into each system’s respective language. Interfaces will be discussed
in detail later in the chapter. An interface has to know what data to retrieve, where the data
are located in the first database, whether any data manipulation has to be performed, what
that manipulation is, and where the data are to be entered into the second database. If the
interface is not working, the systems will not be able to share information until the prob-
lems with the interface are resolved (Austin and Boxerman 2003).
AB103409_ch05.indd 110AB103409_ch05.indd 110 2/1/10 1:20:38 PM2/1/10 1:20:38 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
System Selection and Implementation 111
Although an interfaced system takes more effort to manage, many facilities choose
this method because the facility’s users can choose the various products that they want
instead of choosing a single vendor’s product, which may have a wonderful encoder but
an inadequate laboratory information system, for example. Choosing the systems based on
functionality rather than by vendor and interfacing them is frequently the option selected.
Choosing the best product for your organization regardless of vendor is called choosing the
best of breed (Amatayakul 2007).
Obtaining Buy-in from Management and Users
It is critical that the facility’s upper management support the project from the very begin-
ning of the process. If management shows support for the system, the employees will fol-
low suit and support it. However, if management displays discontent or lack of support,
the employees will be most likely to resist the change. Support can be shown by attending
meetings, talking about the system’s benefits to the organization, its employees, and its
customers, and generally demonstrating that the system is valued. Communication is criti-
cal here. Remember to keep staff and all those to be affected by the system updated to the
decisions, the changes, and all expectations. The more the personnel are informed, the less
likely for resistance to occur because they will know what to expect.
The Importance of Planning
The importance of planning becomes evident when the most common reasons for project
failures are examined. According to Young (2000) these reasons are:
Lack of clear vision•
Inadequate resources•
Lack of planning•
Use of inappropriate resources•
Lack of experienced staff to complete assigned tasks•
Unrealistic expectations•
Other reasons for project failure include lack of training, poor communication, and an
inadequate system.
If a facility spends more time and energy on the front end of a system implementation
project, it will be better positioned to succeed. Adequate planning is demonstrated, in part,
when the facility has from the outset of the project the necessary staff, money, and other
resources, as well as an understanding of what is needed and what the desired outcomes
are expected to be.
Organization of Project
Once the decision is made to implement a system, the project’s formal organizational struc-
ture must be put in place. A project is a plan and course of action that will address a spe-
cific objective, made up of a series of activities and tasks with a defined start and stop date.
The plan has a targeted objective and deliverable to be accomplished. The project will need
specific resources assigned to it in order to be completed (Abdelhak et al. 2007).
Project Team
Most, if not all, information system projects require a team of individuals to successfully
implement the system. The number of individuals needed and the make-up of this team
vary from project to project depending on the needs of the implementation (Austin and
Boxerman 2003). For example, if the facility is implementing a chart deficiency system
AB103409_ch05.indd 111AB103409_ch05.indd 111 2/1/10 1:20:38 PM2/1/10 1:20:38 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
112 Chapter 5
for use only in the health information management (HIM) department, the team should
include the appropriate people in HIM and information systems. The team would not need
to include physicians, nurses, risk managers, or laboratory staff. If the facility is imple-
menting an order entry system, the team would need representatives from the physician
staff, as well as from the HIM, nursing, laboratory, and pharmacy departments to ensure
that the system is properly planned and developed.
An HIM professional will frequently sit on the committee because the system may
impact the HIM department indirectly, and having an HIM professional involved in the
process can help ensure that the department’s needs are addressed. Additionally, the HIM
professional can serve as a consultant and source of information for compliance, legal,
and other concerns. For example, the HIM professional can assist with retention, privacy,
security, and documentation issues, among many other considerations of the system, which
may ultimately affect the HIM department.
The major participants in the project management team are the information systems
project steering committee, the project manager, the user task force, the project team, the
vendor, and, possibly, one or more consultants. These roles are described here:
The • information systems project steering committee is responsible for every
information system acquisition project in the facility (Wager et al. 2005).
Each project team will report back to the steering committee. The steering
committee’s role is to ensure that the strategic information system plan is being
efficiently and effectively implemented and that the project stays on target
(LaTour and Eichenwald Maki 2006). This committee is frequently led by the
chief information officer (CIO). The CIO is generally at the vice president
level and is responsible for all information resource management functions at
the facility. The information system, HIM, and other information management
departments frequently report to the CIO. The CIO must be a visionary and have
strong management skills. While the CIO is not a technical role, the individual
must understand enough about information technology to ensure the proper
management of the systems (Glandon et al. 2008). Other team members may be
administrators, managers, project managers, and other leaders in the facility.
The project team works with the project manager to implement and manage •
the project. This team will meet periodically, based on project needs, to discuss
progress of the project and any issues that arise. The project team generally meets
less frequently in the early stages of the project; the frequency increases as the
implementation date gets closer. The team may even meet daily right before
go-live. This team should be multidisciplinary. The makeup of the team will be
determined by the type of system being implemented and its complexity. The team
should include information system staff, clinicians, HIM personnel, and others as
appropriate. It is important to include a representative from facility management if
possible, to show support for the system.
The • project manager is responsible for coordinating the individual project,
monitoring the budget, managing the resources, conducting negotiations, and
keeping the project on schedule. These roles require the project manager to have
both technical and analytical skills as well as people skills. The project manager
should be skilled in conflict resolution, communication, and project management.
Leadership skills are also important because the project manager must be able to
develop a consensus and manage meetings for the project team.
The • user task force is a group of users, who will ultimately be using the
system, that test the system and perform other project-related tasks for which
the committee receives feedback. These users are generally on loan from various
departments to assist in the project. Some members of the user task force may be
deployed as needed for testing (performing an examination or evaluation) and
other tasks, whereas others are pulled out of their department for the duration of
AB103409_ch05.indd 112AB103409_ch05.indd 112 2/1/10 1:20:39 PM2/1/10 1:20:39 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
System Selection and Implementation 113
the project. This reassignment may last a year or more depending on the project
(Kreider and Haselton 1997).
The vendor representative is the expert on the system and so will be an •
extremely valuable team member. This individual will be the liaison between the
facility and the leadership at the vendor’s company. The vendor representative
knows the product and can be a valuable resource with regard to how best to
implement and use the system. Additionally, he or she can give the project
team information on what has (and has not) worked for other facilities. This
information can help the facility recognize and use best practices, and help it
avoid costly mistakes. If not scheduled to be on site during a meeting, the vendor
representative may need to meet via telephone conference due to their expertise
(Kreider and Haselton 1997).
If the facility decides to hire a consultant, the consultant will be a valuable •
member of the team as well. The consultant hired should not have ties to a
particular vendor’s product, but rather be objective to help the facility obtain the
product that best meets its needs. The consultant should have experience in system
selection and implementation.
Project Identification
Before any decisions are made, the facility must define what the accomplished project is.
The project definition is defined during the project planning process to tell the facility
exactly what it is trying to do with the system being implemented and the expected out-
comes (Kreider and Haselton 2003). The facility must identify:
The purpose of the system•
How the system links to the facility’s business strategy•
The goals for and scope of the project•
The scope of the project determines exactly what work is—and is not—to be included
in the project based on resources available. Identifying the project’s scope is important to
prevent scope creep. Scope creep happens when items not included in the original scope
are added after the project has begun. The additions to the project will increase the time
needed for the project and the money and resources required to accomplish it (Englebardt
and Nelson 2002).
Once the facility knows what it plans to do, the project team can begin dividing the
project into specific activities or tasks. The team may start out with a basic skeleton of a
project plan and continue to add substance to it as they go along. This plan should describe
each task to be completed, how it will be completed, who is responsible for its completion,
when a task should begin, and when the task should be finished. The basic components of
the plan are:
Feasibility study: This study defines the objectives and need for the project and •
justifies the plan.
Resources: The resource plan identifies the resources needed in order to meet the •
objectives of the plan. This includes money, time, staff, space, and other resources.
Design: In the design stage, the project team identifies the specific details required •
to implement the plan. For every task identified, the plan must provide a start and
end date and a person responsible. If the project requires programming, the team
must establish the standards that will be used in writing the program.
Hardware and software procurement: This stage includes ensuring that the facility •
has all of the hardware and software needed and that any missing components
AB103409_ch05.indd 113AB103409_ch05.indd 113 2/1/10 1:20:39 PM2/1/10 1:20:39 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
114 Chapter 5
arrive in a timely manner. Hardware delivery may take 6 weeks, for example, so
ordering needs to be done early in the process.
Transition: The transition phase prepares the facility for the conversion from the •
old system to the new. This stage includes not only the actual conversion of data,
but preparing staff for the change.
Implementation: The implementation stage includes the steps to be taken to •
prepare for the implementation and the actual conversion to the new system.
Postimplementation: The postimplementation stage begins immediately after •
implementation is complete. The team must evaluate itself to prepare for the new
project. It should also include an evaluation process to determine if the objectives
of the project were met and how the process could have been improved (Kreider
and Haselton 1997).
The level of organization for the project depends on the level of complexity of the
system being implemented. If it is a small department system, it may only require two
to three people to implement. Large systems that impact the entire facility can take hun-
dreds of people. In large projects, there are frequently subcommittees that are responsible
for small areas of the project. The subcommittees meet and work on their segment of the
project. The chair of the subcommittee then reports back to the full project committee.
Project Tools
There are a number of tools that can be used to control the project. These tools include
Gantt charts and PERT charts, project plans, trouble tickets, and status reports.
The project plan provides details for how to accomplish the project. It directs •
and guides the team on activities, time, costs, and sequencing of activities. It also
provides a narrative description of the project. The project plan could include
project tools such as the Gantt chart and the PERT chart (Abdelhak et al. 2007).
The • Gantt chart (see figure 5.2) is a project management tool that records
specific tasks, their start and end dates, the person responsible for the tasks, and
any connections between tasks. The Gantt chart can easily show which tasks are
behind schedule, which are on target, and which are ahead of schedule (Abdelhak
et al. 2007).
A Project Evaluation and Review Technique • (PERT) chart (see figure 5.3) is
a management tool that evaluates the tasks, dependencies on other activities,
activity sequence, and the time required to complete the task. Because the PERT
chart shows interdependencies between tasks, it will help determine whether the
implementation date is slipping due to delinquent tasks (Abdelhak et al. 2007).
This slippage is shown by review of the critical path. Because the critical path
shows the longest amount of time to complete the project, if key tasks along the
critical path are delayed, the critical path itself lengthens, thus lengthening the
duration of the project.
Status reports are periodic updates on where the project is, what has been •
accomplished, and what problems have been encountered. Solutions for the
problems should be identified in the report. Status reports are typically directed to
the information systems project steering committee to keep that group informed
on the project’s progress. The status report is generally written by the project
manager, but could be written by a designee.
The trouble ticket is a tool used during the implementation phase to document and •
track problems encountered. The project manager keeps track of all trouble tickets
turned in, assigns someone to be responsible for the resolution of the problems,
and monitors the tickets for closure. Some of the issues recorded may be minor,
AB103409_ch05.indd 114AB103409_ch05.indd 114 2/1/10 1:20:39 PM2/1/10 1:20:39 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
System Selection and Implementation 115
Figure 5.2.Sample Gantt chart
whereas others may be major. Either way, all of the problems recorded by the
trouble tickets should be resolved prior to implementation of the system.
Figure 5.2 shows an example of a Gantt chart, and figure 5.3 shows an example of a
PERT chart.
Additionally, software such as Microsoft Project can be used to help manage a project.
Project management software can create the Gantt and PERT charts as well as other types
of tools for the project team to review. It can also track how much of each task is complete
(0 to 100 percent), who has been given the responsibility for each task, the beginning and
ending dates, the sequencing of tasks, and more.
AB103409_ch05.indd 115AB103409_ch05.indd 115 2/1/10 1:20:39 PM2/1/10 1:20:39 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
Identify project manager
Start: 8/8/08 ID: 1
Finish: 8/8/08 Dur: 1 day
Res: Chief Information Officer
Identify project team
Start: 8/11/08 ID: 2
Finish: 8/15/08 Dur: 1 wk.
Res: Project Manager
Conduct systems analysis
Start: 8/18/08 ID: 3
Finish: 1/30/09 Dur: 6 mos.
Res: Project Team
Write RFP
Start: 2/2/09 ID: 4
Finish: 3/13/09 Dur: 6 wks.
Res: Project Team
Distribute RFPs to vendors
Start: 3/15/09 ID: 5
Finish: 3/17/09 Dur: 2 days
Res: Project Manager
Meet with vendors
Start: 4/5/09 ID: 6
Finish: 4/6/09 Dur: 1 day
Res: Project Manager
Update network to accommodate
increased traffic
Start: 9/7/09 ID: 16
Finish: 9/24/09 Dur: 14 days
Res: Network Administrator
Develop training plan
Start: 9/7/09 ID: 21
Finish: 10/30/09 Dur: 2 mons.
Res: Project Team
Identify data conversion needs
Start: 9/29/09 ID: 22
Finish: 10/3/09 Dur: 5 days
Res: Project Team
Write program required for data
conversion
Start: 10/6/09 ID: 24
Finish: 10/31/09 Dur: 1 mon.
Res: Programmer
Correct errors identified in testing
Start: 1/26/10 ID: 27
Finish: 2/22/10 Dur: 1 mon.
Res: Programmer
Test software
Start: 12/1/09 ID: 26
Finish: 1/25/10 Dur: 2 mons.
Res: Project Team
Receive RFP submissions
Start: 4/7/09 ID: 7
Finish: 5/4/09 Dur: 1 mon.
Res: Project Manager
Review RFPs
Start: 5/5/09 ID: 8
Finish: 6/1/09 Dur: 1 mon.
Res: Project Team
Site visits
Start: 6/2/09 ID: 9
Finish: 6/29/09 Dur: 1 mon.
Res: Project Team
Check references
Start: 6/30/09 ID: 10
Finish: 7/6/09 Dur: 1 wk.
Res: Project Team
Make decision on system
Start: 7/7/09 ID: 11
Finish: 7/13/09 Dur: 1 wk.
Res: Project Team
Sign contract
Start: 7/14/09 ID: 12
Finish: 7/20/09 Dur: 1 wk.
Res: Chief Information Officer
Order hardware for users and
data center
Start: 7/21/09 ID: 13
Finish: 7/27/09 Dur: 1 wk.
Res: Project Manager
Install hardware in computer room
and units
Start: 9/7/09 ID: 15
Finish: 9/24/09 Dur: 14 days
Res: Technology Support
Install software on file server
Start: 9/25/09 ID: 17
Finish: 9/25/09 Dur: 1 day
Res: Technology Support
Configure settings in system
Start: 9/28/09 ID: 18
Finish: 10/23/09 Dur: 1 mon.
Res: Project Manager
Write routine reports
Start: 9/29/09 ID: 19
Finish: 12/18/09 Dur: 3 mons.
Res: Project Team
Develop new screens
Start: 9/29/09 ID: 20
Finish: 12/18/09 Dur: 3 mons.
Res: Programmer
Write interfaces
Start: 9/28/09 ID: 23
Finish: 11/20/09 Dur: 2 mons.
Res: Programmer
Write user manual, training
materials, and policies and
procedures
Start: 10/26/09 ID: 25
Finish: 4/9/10 Dur: 6 mons.
Res: Project Team
Train the trainers
Start: 4/12/10 ID: 28
Finish: 4/23/10 Dur: 2 wks.
Res: Vendor
Conduct training
Start: 4/26/10 ID: 29
Finish: 6/18/10 Dur: 2 mons.
Res: Trainer
Go-live
Start: 6/21/10 ID: 30
Finish: 6/23/10 Dur: 3 days
Res: Project Team
Acceptance testing
Start: 6/24/10 ID: 31
Finish: 8/18/10 Dur: 2 mons.
Res: Project Team
Evaluation of implementation
Start: 8/19/10 ID: 32
Finish: 9/1/10 Dur: 2 wks.
Res: Project Team
Site preparation (add outlet, shift
existing computers)
Start: 7/21/09 ID: 14
Finish: 7/23/09 Dur: 3 days
Res: Project Manager
Figure 5.3.Sample PERT chart
A
B
1
0
3
4
0
9
_
ch
0
5
.in
d
d
1
1
6
A
B
1
0
3
4
0
9
_
ch
0
5
.in
d
d
1
1
6
2
/1
/1
0
1
:2
0
:3
9
P
M
2
/1
/1
0
1
:2
0
:3
9
P
MEBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
System Selection and Implementation 117
Check Your Understanding 5.1
1. True or False: The information systems project steering committee is responsible for the day-to-
day implementation of new systems.
2. The process that outlines the cost, benefits, and disadvantages of the proposed systems is
the:
A. feasibility study
B. project plan
C. trouble ticket
D. status reports
3. The PERT chart shows if there is slippage in the implementation date. This slippage is shown
by:
A. dependencies
B. Gantt chart
C. project plan
D. critical path
4. The coding supervisor performs a monthly audit of coding quality. Is this a project?
A. Yes
B. No
5. Differentiate between integrated and interfaced.
A. Integrated systems are designed to work together, and interfaced systems must be linked.
B. Interfaced systems are designed to work together, and integrated systems must be linked.
C. Integrated systems are designed to be embedded in your hospital information system, and
interfaced systems are part of your hospital information system.
D. Interfaced systems are designed to be embedded in your hospital information system, and
integrated systems are part of your hospital information system.
System Analysis
System Development Life Cycle
Abdelhak (2007, 306) defines the system development life cycle (SDLC) as the “process
used to identify, investigate, design, select, and implement information systems.” Generally
the SDLC (illustrated in figure 5.4) has five steps:
Initiation•
Analysis•
Design•
Implementation•
Maintenance/evaluation (LaTour and Eichenwald Maki 2006)•
Benefits of the SDLC
The SDLC is an important part of the system selection process because it helps you under-
stand your organization and its needs. The SDLC is a structured process that can be use-
ful by identifying users’ needs and alternatives, selecting the information system, system
AB103409_ch05.indd 117AB103409_ch05.indd 117 2/1/10 1:20:39 PM2/1/10 1:20:39 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
118 Chapter 5
implementation, and other steps in managing information systems. SDLC requires the
involvement of people throughout the organization including those who use the system
(Johns 2006). The use of people throughout the organization who are impacted by the orga-
nization ensures that the needs of all of the users and the organization are met.
SDLC Process
The SDLC is an ongoing process as demonstrated by the circular nature of Figure 5.4.
There are a number of models used to describe the SDLC. Each of the four stages in the
model used in this book is described below.
Initiation
Initiation is where the facility decides to acquire a specific information system (Abdelhak
et al. 2007). This decision may come about because of an information system strategic plan,
the obsolescence of an existing system, or some other reason. In analysis, the facility deter-
mines what users need from the proposed system. This stage reviews the current processes
of the facility, the proposed processes, and the desired functional requirements. Func-
tional requirements describe “what, not how, nor to what degree of accuracy, nor to what
format” (Mikulski 1993). The design phase determines how the system will be selected or
developed. It includes the specific design of a system to be developed by the facility or how
the facility will identify the system for purchase. The implementation phase begins with
the signing of the contract and ends when the system is operational. Some of the steps in
this stage are installation of hardware or software, training, testing, and change manage-
ment. The final stage is maintenance/evaluation of where the system is used, updated, and
evaluated. The facility needs to know if the system meets the goals established for it and
to conduct the day-to-day operations to keep the system up and running. This is a cyclical
process; once the system no longer meets the needs of the users, the process begins again
(LaTour and Eichenwald Maki 2006).
Systems Analysis
Systems analysis is “the process of collecting, organizing, and evaluating data about IS
requirements and the environment in which the system will operate” (Austin and Boxer-
man 2003). Systems analysis is generally the first step in the SDLC after the decision
to implement the system has been made. It helps determine the needs for data, storage,
reporting, and functionality. To identify the needs of the facility, the team would look at the
Maintenance/
Evaluation
Implementation
Initiation
Analysis
Design
Figure 5.4.System development life cycle (SDLC) diagram
AB103409_ch05.indd 118AB103409_ch05.indd 118 2/1/10 1:20:39 PM2/1/10 1:20:39 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
System Selection and Implementation 119
existing systems and the needs of the users, and identify and evaluate alternatives. During
systems analysis, users are asked questions such as:
What do you like about the current system?•
What problems do you have with the current system?•
What changes do you foresee that will impact this system?•
What information do you need from the system?•
Answering these questions helps the project team understand the current system and how
it meets or does not meet the needs of the users. A system will be used by the facility for a long
time and therefore must be adequate both at the time of go-live and in the foreseeable future.
To identify the needs of the facility for the foreseeable future, the team needs to under-
stand the environment in which the system will operate. No one can see into the future with
certainty, but internal and external environmental scanning can identify some issues that must
be addressed. Internal scanning is identifying changes within the facility that will impact the
information system. External scanning is identifying changes outside of the facility that will
impact the information system. For example, if a facility was developing a new system that
contained protected health information in 2002, it would have to ensure that the system would
meet the strict Health Insurance Portability and Accountability Act (HIPAA) privacy rule
that was implemented in April 2003. The facility may be aware of other pending legislation,
trends, or other issues that may impact the system under consideration. Understanding the
environment helps ensure that the system will work today and for the expected future.
Questionnaires, interviews, observations, flowcharts, and other data collection tools
may be used to obtain the data needed to answer these questions (Austin and Boxerman
2003). The team should collect data from all levels and types of users. The needs of the
clerical staff will be very different from the needs of management staff. Many managers
think they know the needs of their staff, but many of these managers know what the policy
states, not what is actually happening. The information gathered should include all aspects
of the system such as data elements, reports, privacy, security, and overall functionality.
Questionnaires allow for a large number of users to provide input about the needs of the
system (Austin and Boxerman 2003). This is especially true if closed-ended questions are
used so that the responses can be tabulated quickly and easily. Closed-ended questions can be
answered with yes or no, Likert type scales, and other limited choice responses. Likert type
scales are great for obtaining the users’ beliefs regarding a statement. An example of a Likert
scale begins with a statement such as: “On a scale of 1 to 5 with 1 being strongly agree and
5 being strongly disagree, rate the following statement.” An example of a belief could be
“The new EHR will improve the efficiency of the facility.” An example of a typical closed-
ended question could be, “Do you generate reports as a part of your job?” Obviously, the
response to this question is limited to yes or no. Computerized tools such as Survey Mon-
key and even machine-readable Scantron forms make the aggregation and analysis of the
responses quicker. The downside of questionnaires is that the correct questions may not be
asked, so there may be gaps in the data collected. The use of open-ended questions may
help fill some of these gaps, but they slow down the aggregation of data and data analysis
(Austin and Boxerman 2003). Open-ended questions allow the participants to expand on
their response; however, the team must collect, read, and analyze each statement individu-
ally. An example of an open-ended question is: “How does the current information system
help you in your job?”
Interviews are powerful tools for obtaining information. There are three types of inter-
views: structured, unstructured, and semi-structured. In the structured interview, everyone
is asked the same questions. This improves analysis of the findings, but does not encourage
the interviewee to talk openly about pertinent issues, thus taking the risk that important data
will be overlooked. In the unstructured interview, the interviewer does not have a list of
questions but rather gets the interviewee talking about their job, their data needs, and other
issues related to the information system. The semi-structured interview is a combination of
AB103409_ch05.indd 119AB103409_ch05.indd 119 2/1/10 1:20:39 PM2/1/10 1:20:39 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
120 Chapter 5
the structured and unstructured formats. There are questions that interviewees are asked,
but they are also encouraged to discuss in detail their job, data needs, and other issues
related to their information system needs. The unstructured and semi-structured formats
make it harder to identify trends and to analyze data, but major issues that could have been
overlooked otherwise may be identified.
Typically, two members of the team are needed to conduct interviews because one per-
son interacts with the interviewee and the other person takes notes (Abdelhak et al. 2007).
Because of the increased staffing needs, the amount of time required to collect and analyze
the data, and the need to meet with users individually, interviews are very time-consuming,
which makes them costly. This means that the planning team may interview fewer indi-
viduals than those who may respond to a questionnaire.
Observation is watching an action being performed. It is useful in determining what
employees are actually doing. This is important because frequently supervisors or others
may tell the interviewers what they think is happening but in reality something very dif-
ferent is occurring. The use of observation is a way to validate what the interviewee has
been told. If using observations, each observation session should be short—maybe 30 to
40 minutes—because the observer becomes bored and misses details (Abdelhak et al.
2007). Also, observation sessions should be scheduled throughout the day because differ-
ent tasks may be performed at different times.
Flowcharts may be used to “provide a concise, logical, and standardized mechanism
for depicting and analyzing current information flows” (Austin and Boxerman 2003) (see
figure 5.5). The flowchart frequently uses geographic symbols to demonstrate the steps
performed (McWay 2008). Problems and inconsistencies may be identified through the
development and analysis of the flowchart. The process on the flowchart would depend
on the type of system being developed but could represent the flow of the medical record
in the HIM department, the flow of a physician query, or the steps in denial management.
The flowchart would identify critical points in the process as well as problem areas. This
Move chart from magnetic
disk to long-term storage
media
Complete chart
processing
Code chart
Quality indicator
monitoring
Analyze chart
Scan chart
Charts are picked
up from unit
Figure 5.5.Sample flowchart
AB103409_ch05.indd 120AB103409_ch05.indd 120 2/1/10 1:20:39 PM2/1/10 1:20:39 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
System Selection and Implementation 121
information can be used to improve new processes implemented along with the new infor-
mation system.
Many facilities use a combination of questionnaires, interviews, observations, and
other data collection tools to obtain the best information. The use of multiple tools also
allows the team to involve more users and at the same time obtain detailed, validated
information. The large number of participants helps to foster buy-in from the users. Buy-
in refers to the acceptance of the system and recognizing its value to the user and to the
facility. Users who buy-in to the system are supportive and less likely to resist using the
system into their job role.
System analysis is a “process of studying organizational operations and determining
information systems requirements for a given application” (Glandon et al. 2008, 75). It is
frequently ignored or given only minimal attention during the system implementation pro-
cess. This is a mistake. System analysis is critical because it forces the facility to evaluate
itself and to look at how it does business. This understanding will help select the system
that will best meet the needs of the facility.
Design
In the design phase, the standards upon which the system will be evaluated and selected are
identified (Abdelhak et al. 2007). This includes functionality, purchase vs. develop vs. ASP,
and other attributes desired in the IS. This will be further described in the system selection
section of this chapter.
Implementation
This stage of the SDLC addresses the steps required to implement the IS. This includes a
comprehensive plan for the implementation process. (LaTour and Eichenwald Maki 2007).
This will be discussed in the implementation section of this chapter.
Maintenance and Evaluation
The maintenance and evaluation stage addresses the day-to-day operations of the IS after
implementation. The system should be evaluated on an ongoing basis in order to ensure
that the IS continues to meet the needs of the organization (LaTour and Eichenwald Maki
2007). This is discussed further in the implementation section of this chapter.
System Selection
Most facilities today decide to purchase a system from an IS vendor. The vendor has
invested millions of dollars in research and development and has a support system to assist
the facility in the implementation of the IS being purchased. The facility must identify what
they demand from an IS. This information is used to determine which system best meets
the needs of the organization.
Request for Information
The request for information (RFI) is a formal document requesting information on infor-
mation systems. The RFI asks the information system vendor for basic information about
the product and how their information system would meet the requirements outlined in the
RFI (Abdelhak et al. 2007). The RFI can be used to select minor information systems, or the
information gathered in the RFI can be used to determine who will receive the more rigorous
request for proposal (RFP), which “details all required system functionality, including func-
tional, technical, training, and implementation requirements” (Abdelhak et al. 2007, 343).
Request for Proposal
The RFP is a much more detailed document than the RFI and is critical to the selection
process. The purpose of the RFP is to give the vendor all the information needed to propose
an information system that meets the needs of the facility. The RFP describes what system
AB103409_ch05.indd 121AB103409_ch05.indd 121 2/1/10 1:20:40 PM2/1/10 1:20:40 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
122 Chapter 5
is needed, how many people will be using the system, and how the system will be used.
Common components of the RFP are:
Letter of introduction•
Information for potential vendors, including:•
Information about bidders’ conference —
Description of facility —
Patient (or other) volume statistics —
Description of the proposed system, including:•
Technology requirements —
Functional requirements —
Required format of response —
Instructions for RFP•
Request for sample documentation•
Request for sample contract•
Vendor profile•
System testing requirements•
Sample résumés of implementation staff•
System selection criteria•
Training requirements•
References•
Appendix B shows a detailed template for an RFP (AHIMA 2007).
Letter of Introduction
The letter of introduction is a cover letter that is sent to the vendor along with the RFP. The
letter introduces the vendor to the RFP, and identifies who the vendor should contact at the
facility. It may also provide some information that did not make it into the RFP. The infor-
mation on the bidders’ conference gives the date, time, location, and other information.
The bidders’ conference is a meeting for vendors to come to the healthcare facility to
ask questions about the RFP, the facility, and more. This meeting enables all of the potential
vendors to hear the same information and to get all of their questions answered so that they
can completely respond to the RFP.
Information for Potential Vendors
The description of the facility section provides the vendor with enough information about
the facility to enable the vendor to properly respond to the RFP. This information includes
the size of facility, number of employees, number of employees who would use the system,
and number of locations that would use the system (Austin and Boxerman 2003). This sec-
tion also should describe the facility’s existing systems so the vendor can respond as to how
they can work with the existing system.
It should also include patient (or other) volume statistics that would be related to the
system (see table 5.1). The statistics may include number of discharges, number of surger-
ies, number of emergency department visits, and the number of outpatient visits—whatever
is needed for the proposed system (Abdelhak et al. 2007).
Description of the Proposed System
In the proposed system section, the vendor describes the system that it is proposing to meet
the needs of the facility. The vendor should describe the infrastructure required, licensing,
the capabilities of system, the benefits that would be realized, and more.
AB103409_ch05.indd 122AB103409_ch05.indd 122 2/1/10 1:20:40 PM2/1/10 1:20:40 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
System Selection and Implementation 123
The functional requirements identify the desired functions of the IS, which makes this
a significant part of the RFP. This document is developed during the system analysis pro-
cess and outlines all of the functions expected of the system. The functions should include
all aspects of the information, including but not limited to, individual data elements, data
entry methods, reporting, management of the system, functionality, and technical issues.
Technical issues can include topics such as the type of database used and the ability to work
with a certain operating system or interface with existing products.
Each functional requirement is listed. The vendor indicates whether the function is
available, is available with customization, will be available in the future, or is not available
(Hebda et al. 2005). The facility will take this same list of functional requirements and use
it to evaluate the RFP. There are at least two ways to classify each functional requirement.
The first is that each functional requirement should be designated at least as mandatory or
desirable (Austin and Boxerman 2003). Some RFPs use three categories: mandatory, desir-
able, and luxury. Each functional requirement is categorized into one of the designations.
A numeric rating system can be used as well; in other words, “scoring” each func-
tion based on its importance. For example, each function is rated on a scale of 1 to 5,
1 = unimportant, 5 = highly important. The functional requirements with the available,
not available, and other categories are part of the RFP, but the version with the evaluation
ratings is not. The functional requirements are used in the system evaluation to determine
if a vendor has all of the functionality, and also to determine if the missing functionality is
important. For example, if there is a functional requirement to combine duplicate medical
record numbers, and it is missing from one of the products under review, the rating would
help the reviewer determine whether this is a serious gap.
Other RFP Requirements
The required format of response tells the vendor what the facility requires regarding the RFP.
For instance, the facility might require a specified number of paper copies and an electronic
copy in Microsoft Word or Portable Document Format (PDF). The facility may also limit the
number of pages, or the look of the document. The facility may even provide an electronic
template for the vendor to complete. The instructions for RFP may include rules regarding
whom the vendor can talk to at the facility, the deadline for submission, and a statement
that the vendor assumes responsibilities for the expenses to complete the RFP as well as the
expenses for any on-site demonstrations, along with expenses for RFP preparation.
The request for sample documentation and request for sample contract is simply that—
a request for a copy of the documents. The vendor profile is a description of the vendor
Table 5.1.Sample of requested volume
Imaging System Statistics Facility Findings Number
Average number of discharges per day 45
Average number of emergency department visits per day 60
Average number of outpatient surgeries per day 25
Average number of outpatient visits per day 125
Average number of pages—inpatient discharge 100
Average number of pages per emergency department visit 12
Average number of pages per outpatient surgery record 40
Average number of pages for each outpatient visit 2
Average number of release of information requests per day 21
Average number of pages copied for release of information/day 475
Number of forms utilized in medical record 325
Number of forms already having barcodes 200
Percentage of medical record to be entered into the imaging system via COLD technology 40%
Projected number of change in workload over the next 5 years 10%
AB103409_ch05.indd 123AB103409_ch05.indd 123 2/1/10 1:20:40 PM2/1/10 1:20:40 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
124 Chapter 5
and is designed to ensure that the company is financially sound and capable of meeting the
needs of the facility for years to come (Abdelhak et al. 2007). The RFP asks for informa-
tion on the number of installations of similar systems the vendor has performed, financial
viability of vendor, and the number of years the product has been available.
System testing requirements would outline the expectations the facility has regarding
testing. The RFP would provide the types of testing to be performed and the role of the
vendor in that testing.
Many facilities request sample résumés from the vendor’s staff, which provide details
of the experience and qualifications of the staff who could be assigned as consultants to that
particular project. These sample résumés are used to ensure the vendor has experienced
staff members who can support the facility throughout an implementation. It is not a guar-
antee that any of the individuals represented would be assigned to the project, but rather a
sample of the experience that the vendor’s employees have.
The system selection criteria are used to select the system. This would include major
steps such as findings of the demonstration, findings of site visits, review of the RFP, costs,
expected benefits, and reliability of vendor’s products. It would not include rankings of
importance and other details that the project team will utilize to make the final decisions.
Finally, the RFP should request the training requirements for the system, including the
number of people trained by the vendor, cost of training, the estimated time it should take to
train each user, types of training required, and other recommendations regarding the training
process.
Check Your Understanding 5.2
1. I am configuring settings. This falls into what stage of the system development life cycle?
A. Analysis
B. Design
C. Implementation
D. Maintenance/evaluation
2. I am collecting data as part of the system analysis function. If I want to get the most system
users involved as possible, which would be the BEST method of data collection?
A. Observation
B. Questionnaires
C. Interviews
D. Flowchart
3. I have asked a vendor for detailed written information on their product. This would be:
A. RFI
B. RFP
C. flowchart
D. vendor profile
4. I am calling six hospitals that use XYZ’s EHR. This is an example of:
A. reference check
B. site visit
C. demonstration
D. RFP review
5. What problems do you encounter with the existing hospital information system? Is this an open
or closed question?
A. Open
B. Closed
AB103409_ch05.indd 124AB103409_ch05.indd 124 2/1/10 1:20:40 PM2/1/10 1:20:40 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
System Selection and Implementation 125
Evaluation of Proposed Systems
The evaluation process used to select a system should be established during the planning
process. The process should include multiple components including:
On-site demonstrations•
Site visits•
Review of RFP•
Reference checks•
On-Site Demonstrations
In an on-site demonstration, the vendor brings its product to the healthcare facility, either
as a demonstration version or a full version of the product. Project team members and other
users gather to view the product and to ask questions of the sales team. The idea is to have
as many people as possible watch the demonstration to see what the product can and can-
not do. All attendees should come to the demonstration with situations they encounter in
their daily tasks and ask how the system would handle it. The on-site demonstration allows
for multiple user involvement and is an important method to learn about the product. This
may be the only chance for some team members or other users to see the system before
implementation; not everyone can go to site visits to see the system in a live environment
(Abdelhak et al. 2007).
Site Visits
Site visits are a great way to view the products in a live environment. A site visit usually
consists of a small group of team members (usually key players) visiting a facility, pref-
erably similar in size and characteristics, which has the product implemented, to observe
the system in use. During the visit, the team asks questions of the site visit facility’s staff
involved in the system. The salesperson for the product will attend the site visit as well
to answer questions and ensure that the project team obtains the information needed to
make a decision. It is recommended that the project team ask the vendor’s staff to step
outside the room for a few minutes. The philosophy behind this is that the facility staff
may be more open about problems with the system if the vendor is not in the room. See-
ing the system operating in a real environment is quite different from a demonstration
environment and thus gives the project team a much more realistic view of the system
and how it works.
Reviewing RFP Responses
The vendor spends a lot of time responding to an RFP, so the RFP should only be sent to the
vendors who are seriously being considered (Abdelhak et al. 2007). It is also very expen-
sive (Wager et al. 2005). The number of RFPs submitted is typically limited to three to five
vendors. The healthcare facility also spends hours reviewing the RFP responses because
for major information systems purchases, the responses could fill a 3- or 4-inch binder. A
spreadsheet is frequently developed to assist in the analysis of the RFPs, and this enables
the decision makers to compare key information between products more easily when mak-
ing their decision.
Some of the information that could be included in the spreadsheet includes:
Cost•
Compatibility with existing system•
Level to which the system meets functional requirements•
Reaction to site visits•
A sample comparison is shown in table 5.2.
AB103409_ch05.indd 125AB103409_ch05.indd 125 2/1/10 1:20:40 PM2/1/10 1:20:40 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
126 Chapter 5
Reference Checks
The facility should contact several facilities where the product under consideration is in
use. These reference checks are a great way to learn if other facilities are satisfied with
the product without the expense and time it takes to go on site visits. The vendor will
provide a list of references, and the evaluating facility should try to obtain a complete
list of client sites from the vendor or independently identify client facilities that are not
on the reference list (Amtayakul 2007). Best practices recommend that the evaluating
project team contact facilities from the vendor’s reference list, as well as facilities that
are clients of the vendor but are not included on the reference list. The reference list may
only contain customers who are satisfied with the product and leave off the unsatisfied
ones. Facilities not on the list may be identified through the corporate offices, network-
ing, or cold calls. Notes from these reference checks should be collected and used as part
of the decision-making process.
Making the Decision
It is the responsibility of the project team to review the responses to the RFP and other evalu-
ation tools to determine which system will best meet the needs of the facility. To prevent
arguments over which system to choose, there should be a quantifiable means of evaluat-
ing the systems. One way is to assign points to the RFP review, site visits, observations,
and other evaluation methods. If a point system is used during the evaluation process, then
the system with the highest number of points should theoretically be the best system and
therefore the one that is chosen. However, this is not always the case, because a vendor may
have the overall highest score but have low scores in key functions; not only should the total
points be used, but each individual task should also be considered. A weighted system is one
method of a point system that can be used (see table 5.3) (Abdelhak et al. 2007). With the
weighted system each function would be listed along with a score showing how important the
functionality is. The project team would give each function a score and the score would be
multiplied by the weight. The weighted scores would then be totaled. There should also be a
tiebreaking process, just in case. Examples of tiebreakers could be cost, site visit findings, or
other evaluation criteria. As an example of the importance of a complete evaluation system,
one corporate entity had all of their HIM directors critique an information system and vote on
Table 5.2.Sample of comparisons between vendors responding to RFP
Comparison of Vendor Systems
System Capabilities System A System B System C
Works with existing
hospital information
system
Yes Yes Yes
One-time costs $654,000 $498,500 $576,000
Ongoing costs (3 years) $65,000 $89,000 $79,000
Hardware needed File server, PCs
throughout facility,
barcode scanners, and
printers
File server, PCs
throughout facility,
barcode scanners, and
printers
File server, PCs
throughout facility,
barcode scanners, and
printers
Works with existing
database
Yes Yes Yes
Number of years vendor
in existence
31 12 6
Number of installations 123 26 2
RFP shows financial
viability
Yes Yes Yes
AB103409_ch05.indd 126AB103409_ch05.indd 126 2/1/10 1:20:40 PM2/1/10 1:20:40 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
System Selection and Implementation 127
the one they wanted. There was a tie and none of the directors would change their vote. The
project was cancelled because of the inability to select a system.
In the weighted score example, system B has the highest score and does beat system A
in every criteria except one. The one function where it is lower is “EHR can easily access
knowledge-based resources on the Internet,” where its score is substantially lower than
that of System B. The weight of this function is higher than the other functions so decision
makers would have to determine what is more important, a higher score or the ability for
providers to access knowledge-based materials quickly and easily.
Contract Negotiation
Once the decision on which system to purchase has been made, the contract negotiation
process begins. Some hospitals start negotiations with more than one vendor. Based on the
initial meetings, the facility chooses one vendor to continue on with negotiations. Typi-
cally, a contact team, not the project team, negotiates the contract. The negotiating team
should include at least the CIO and an attorney; however, with a minor implementation,
the HIM director may work with a member of administration. A minor system might be a
chart location system that is used only by the HIM department and is quickly and easily
implemented and has a simple contract. A major implementation would involve multiple
areas of the healthcare facility, a significant period of time to implement, and a complex
contract. The goal of the contract negotiations is a win-win situation. Obviously, the health-
care facility wants a good product at a reasonable cost that is implemented in a reasonable
time period. The facility should not try to secure the product under such strict requirements
that the relationship with the vendor is negatively impacted from the beginning. With many
of these installations, the facility will be working with the vendor for 10 years or longer;
therefore, it is in the facility’s best interest to create a good working relationship. The facil-
ity should not accept the sample contract provided by the vendor because this contract is
written in favor of the vendor. The negotiation team is responsible for working with the
vendor to develop a contract that works for both parties.
Some of the clauses covered by the contract include:
Delivery dates•
Licensee grant•
Warranties and guarantees•
Table 5.3.Sample weighted scores for system selection
Weighted Scores for System Selection
Functionality Weight
Vendor A
Score
Vendor B
Score
Vendor A
Weighted
Score
Vendor B
Weighted
Score
System is user friendly 3 4 6 12 18
EHR can easily access
knowledge-based
resources on the
Internet
3 10 6 30 18
EHR allows patient to
view PHR information
2 4 6 8 12
EHR allows patient to
enter PHR information
1 2 5 2 5
Total 52 53
AB103409_ch05.indd 127AB103409_ch05.indd 127 2/1/10 1:20:40 PM2/1/10 1:20:40 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
128 Chapter 5
Responsibilities of each party•
The state whose laws govern the contract•
Cost•
Milestones for payment•
Force majeure•
Software in escrow•
Version of software•
Penalties•
Cancellation of contract•
Acceptance testing•
Maintenance and updates•
Training•
Documentation (Austin and Boxerman 2003)•
A licensee grant is the section of the contract that controls what the healthcare organi-
zation can do with the software. It controls the locations that can use it, who can use it, and
how it can be used (AHIMA 2006).
Delivery dates are the dates that the software and hardware will be delivered to the
healthcare facility. The inclusion of these dates in the contract is important because noth-
ing can be done until the software is available and installed at the facility. Warranties and
guarantees are affirmations the vendor makes that if broken, they can be held accountable.
Samples of warranties are:
Vendor has the legal right to sell software.•
If it is found that the vendor does not have the right to sell the software, then the •
vendor is legally responsible.
Information systems will be available 99.9 percent of the time.•
Information systems will perform query within 3 seconds.•
Response time for technical support.•
Contract law varies by state; therefore, the contract must specify which state’s laws
cover the terms of the contract. The vendor generally asks for the laws of their state and the
hospital asks for their state, so negotiation is required.
It is important to detail the responsibility of each party in the contract (see table 5.4).
This helps ensure that no problems will arise later over whom is responsible for what. This
information will be used in the negotiation of the price. Obviously, the more participatory
a vendor is during implementation, the more the vendor should be paid.
The cost of the system is one of the last clauses negotiated. The amount of money
paid to the vendor will be based on the responsibilities of the vendor, the number of users
specified in the contract, and other clauses. The facility should require a fixed price so
they know exactly what the cost of the system will be. Healthcare facilities should never
pay the entire negotiated amount or a large percentage of the cost up front. The contract
should establish payment milestones (see table 5.5) (Mikulski 1993). A payment mile-
stone is an action that once occurring triggers payment to the vendor. This payment is a
specified percent of the total cost of the system. This must be negotiated and spelled out
in the control. Typical milestones include delivery of software, go-live, and acceptance
AB103409_ch05.indd 128AB103409_ch05.indd 128 2/1/10 1:20:40 PM2/1/10 1:20:40 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
System Selection and Implementation 129
testing. A significant percentage of the payment should be held until acceptance testing
is complete. Failure to do so could result in the vendor moving to the next installation
and not responding in a timely manner to any outstanding issues. If there is a significant
amount of money involved, the vendor is more likely to be responsive to the needs of the
facility.
Force majeure is a legal term that refers to an “act of God” (Merriam-Webster
2009). This contract clause is designed so that the parties of the contract cannot be held
accountable to a deadline if there was an “act of God” that prevented compliance. For
example, say there was a hospital in New Orleans implementing a computer system
and the vendor was responsible for a task due in the middle of Hurricane Katrina. In
this case, the vendor would not be held accountable for any penalties as specified in the
contract.
Healthcare facilities have the need to protect themselves in the event the vendor goes
bankrupt. One way of doing this is to place a clause in the contract that requires the vendor
to place the source code in escrow (Dolan 2006). Source code is the programming code
that was used to develop the system. Escrow is a situation in which a third party holds a
copy of the software in case the vendor goes bankrupt (AHIMA 2006). This means that if
the vendor goes out of business, the healthcare facility can obtain access to the code behind
the software so they can maintain the system themselves or hire someone else to do so.
Both parties prefer to use escrow rather than obtaining access up front. The vendor prefers
this method as well because it does not want its trade secrets to be widely available.
Cancellation of the contract becomes important if for some reason the product or ven-
dor does not meet the needs of the facility. This clause allows the vendor or healthcare
facility to void the contract with appropriate notice. There should also be a period of time
in which the contract is in force unless cancelled earlier by either party. This clause may
require a 30- or 60-day notice to the other party in the event of a cancellation (Austin and
Boxerman 2003).
The version of software that will be delivered to the facility should be specified in the
contract. The vendor will know when the next version is scheduled for release. Depending
on the time frame of implementation, the facility may receive the current version or the new
Table 5.4.Sample allocation of responsibility list
Task Responsible Party
Train the trainer Vendor
Train end users Facility
Develop interfaces Facility and vendor
Design screens Facility
Testing Facility and vendor
Table 5.5.Sample milestones for payment
Milestones for Payment
Milestone Percent of Vendor’s Payment
Signing of contract 20 percent
Delivery of software 10 percent
Commencement of testing 10 percent
Go-live 30 percent
Completion of acceptance testing 30 percent
AB103409_ch05.indd 129AB103409_ch05.indd 129 2/1/10 1:20:40 PM2/1/10 1:20:40 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
130 Chapter 5
version. The contract may also state that the facility will install the current version but will
receive the upgrade to the new system as part of the contract or at a reduced cost (Austin
and Boxerman 2003).
The contract should specify penalties for both the vendor and the facility for failure
to meet the dates specified in the contract. Penalties vary widely and can be monetary or
in the form of free training, free software modules, or other forms. The penalties should
be serious enough to keep the parties on target, but not so punitive they would seriously
risk the financial stability of the facilities. One facility had negotiated such a tight time
frame with major penalties that the information systems department essentially did not do
anything other than implement the new system and keep the current systems operational
for an entire year. If departments needed assistance with the information system, they were
told to hire someone to do it for them. Placing this amount of pressure on the vendor or the
project team is not the purpose behind the penalties in the contract. The purpose is to keep
everyone on task and on target.
Acceptance testing is a critical part of the information system implementation because
it establishes whether the terms of the contract have been met regarding performance and
functionality. The contract must spell out what outcomes are acceptable. These outcomes
will be used to determine when the acceptance testing is complete and the vendor can
receive payment (Austin and Boxerman 2003).
Information systems are constantly changing. Maintenance must be an ongoing respon-
sibility for both the vendor and the facility. The contract should spell out the responsibili-
ties of both parties. The contract should also specify if upgrades to the information system
are included in the contract and the costs for those upgrades. These upgrades will assist
the facility in remaining compliant with accreditation, regulations, and other mandates.
The system updates also repairs any problems found in the system and keeps the system
operational (Austin and Boxerman 2003).
Training responsibilities of the vendor, including issues such as the number of people
to be trained, where they will be trained, the cost of the training, and the length of the train-
ing, should be spelled out in the contract (Austin and Boxerman 2003).
The contract should include the type of documentation provided by the vendor to the
facility. This documentation generally includes technical manuals for technical support as
well as user manuals (Austin and Boxerman 2003).
System Design
As discussed earlier in the chapter, a decision will be made during the planning phase in
which a facility will purchase a system, use an ASP, or design a system. The requirements
identified in the system analysis phase are used to create specifications for the system. The
specifications will be used for programming the system in-house or for evaluating vendor
systems. If the facility is designing its own system, the facility could create a formal system
design or use a prototype. Creating a prototype is a way to quickly design and develop a
system (Abdelhak et al. 2007). With prototyping, programmers quickly develop a system,
show it to the users, obtain feedback, make revisions to the program, and continue until the
system is developed. Although this is an option for system design, most system designs are
much more formal and detailed.
The design should include system objectives, output specifications, input specifica-
tions, database design, and expected costs of the system. The objectives are the goals the
facility wants to achieve with the implementation of the system. The output specification
would be reports and screens to be produced in detail. Input specifications identify the data
needed to accomplish the goals and produce the outputs. The design should specify what
data are collected, from where the data will originate, and in what format the data should be
stored. The design should specify the size of the database and amount of activity expected.
Once the specifications are developed, administration must approve them before proceed-
ing with the project (Abdelhak 2007).
AB103409_ch05.indd 130AB103409_ch05.indd 130 2/1/10 1:20:40 PM2/1/10 1:20:40 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
System Selection and Implementation 131
Check Your Understanding 5.3
1. Our new system is operated on a computer that is physically located at a remote location for
our facility. We pay a monthly fee to the company that owns the computer and in return they
manage our system for us. This is:
A. vendor product
B. ASP
C. facility developed product
D. site visits
2. The vendor will be paid 20 percent of the negotiated amount of the contract at the time of the
contract signing. This is an example of:
A. warranty
B. force majeure
C. escrow
D. payment milestone
3. Evaluate this statement: A hospital should be tough in contract negotiating and insist on
obtaining the software code.
A. This is a true statement.
B. This statement is true only if there is staff to make changes.
C. This statement is not true. The hospital does not need or want access to the code.
D. The hospital would be best served by escrow.
4. True or False: In a point-based evaluation system, the information system selected should
always have the highest score.
5. True or False: System design must be more detailed for evaluation of software for purchase
than for an in-house developed product.
System Implementation
There are many tasks involved in system implementation. Some of these steps can be com-
pleted concurrently, whereas others must have one or more of the previous steps completed
before proceeding. If any of these tasks are omitted or given little attention, the project will
fail. The plan should implement the information system in such a way as to have the least
impact on the facility. For example, the new system can be implemented at midnight when
the activity in the hospital is low.
Hardware/Software
Because it may take a long time to receive hardware (that is, computers, monitors, and
servers), staff needs to plan accordingly and place the order early. The most critical piece of
hardware is the file server or other computer storage component that will house the applica-
tion software. System implementation may be delayed if the file server or other hardware
is not available according to the project plan.
The application software will be provided to the healthcare facility by the computer
vendor based on the date specified in the contract. The version of the software provided
will also be controlled by the contract. If the vendor is late in sending the software for
installation, the implementation of the system will be delayed.
Site Preparation
Site preparation is making any needed changes to the physical location where the com-
puter, workstations, printers, or other hardware will be installed (Abdelhak et al. 2007). Site
AB103409_ch05.indd 131AB103409_ch05.indd 131 2/1/10 1:20:40 PM2/1/10 1:20:40 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
132 Chapter 5
preparation needs vary widely, from construction of a new building, to renovations of an old
one, to use of existing structures and upgrades to the infrastructure. Modifications needed
may require the installation of special air conditioning and/or floors designed to run cables
under it, added security measures, or more electrical outlets to name a few. However, site
preparation may be as simple as moving existing hardware around to make room for the new.
The nursing units, the HIM department, and other locations may need to be renovated to add
space for computer terminals, barcode printers, network printers, and other hardware, but the
data center must be completed first because the nursing units and other departments will not
use the system until go-live. In addition to the physical plant, the facility network may need
to be updated to accommodate the extra traffic resulting from the new system.
Failure to properly prepare the site and infrastructure will result in delays in the instal-
lation of hardware and software, which will in turn delay the entire implementation plan
of the system. One facility learned this lesson when they attempted to plug in the hardware
and did not have an available electrical outlet.
User Preparation
User preparation is providing the users with enough information about the system being
implemented so that they are prepared both psychologically and through training to use
the system. It is important for system users to be notified and updated throughout the
system selection and implementation process. The users need to know that the system is
being implemented and should have an accurate understanding of what to expect from the
system and what is expected of them. Many people have doubts about their job security or
fear computers when new systems are installed; therefore, these fears must be addressed.
Management must be open and honest with the users regarding expectations, downsizing,
changes in job descriptions, and other concerns. The information must be accurate; oth-
erwise, users will lose trust in the manager’s word. Sometimes a new system is promoted
so intently that users expect more from the system than it can provide. These unrealistic
expectations lead to disappointment and, in turn, a lack of support from the users. There
should be as many users involved in the system as possible to obtain their support. Their
involvement can be through the system analysis function, being part of the implementation
team, assisting in testing, and other ways. Even those users not involved in the selection
and implementation need to have realistic expectations. Their expectations can be managed
through training, articles in the facility newsletter, updates at department meetings, and
other formal and informal means of communication (Abdelhak et al. 2007).
Installing Hardware/Software
Once the hardware arrives, it will need to be set up and installed in the data center. Com-
puters will also need to be installed in the nursing units, training rooms, and all locations
decided upon according to the project plan. The printers, network, scanners, and all of the
other hardware will also need to be installed according to the project plan.
The software will then need to be loaded onto the file server, mainframe, or other com-
puter in the data center. Some applications require software to be used on the individual
user computers. If this is the case, the software has to be loaded on to each individual com-
puter to be used in development and testing. The software on the user computers will have
to be installed on all authorized computers prior to implementation. Any failures in the site
preparation will be identified in this stage.
Setting Configuration
Most computer software purchased by hospitals or other healthcare facilities provides the
facility with at least some flexibility in the implementation of the system. This flexibility
is allowed through setting configuration. Setting configuration is the entry of the desired
behaviors of the system into tables or setting fields. For example, if the computer system
will keep track of the patient type, the hospital gets to determine if patients will be classi-
AB103409_ch05.indd 132AB103409_ch05.indd 132 2/1/10 1:20:41 PM2/1/10 1:20:41 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
System Selection and Implementation 133
fied as inpatient, outpatient, emergency department, testing, outpatient surgery, or another
patient type. The facility may even be able to determine that an “I” means inpatient.
The project team sets up the specifications by filling in tables and other fields with
the desired setup. They will also be able to update tables that provide their reimbursement
rates, tax identification number, national provider identifier, or other appropriate values.
Other settings may include time frame before bills drop, data/format of claims submitted
to fiscal intermediary, and what fields are required. The settings will ensure that the system
works according to the needs of the healthcare facility.
It can take minutes or months to get all the specifications and tables updated, depending on
the complexity of the specifications and the system. For example, each user’s information must
be entered into the system, including their username, initial password, location, type of access,
and permissions as to what they can perform within the system. For example, Mary Smith may
have access to the laboratory results, but she can only view these results—not delete or modify
them. Determining who has access to what and what they can do with it, especially if the sys-
tem’s security controls screens and individual data elements, is a time-consuming task.
Programming and Customization
There may or may not be programming required depending on the type of system, complex-
ity of the system, and whether the facility is purchasing a system or programming one them-
selves. If the system interfaces with other systems to share information such as demographic
or other information, the interfaces will have to be programmed. If the facility is converting
data from another computer system, programming will have to be done to perform data
conversion. Data conversion is the process where data is copied from the existing system,
manipulated into the format required by the new system, and entered into the new system.
The facility may want to have some changes made to the software to better meet the
needs of the facility. This customization of the system can be completed by either the facil-
ity or the vendor. Although customization may better prepare the system to meet the needs
of the facility, there are reasons why the facility should not customize the software beyond
what is already built into the system by the vendor. Some of these reasons are:
If the facility makes changes to the software and then has trouble with the system, •
the vendor can blame the modifications. The vendor may then refuse to work on the
system.
The vendor may not give the facility a service agreement.•
Every time that the facility receives a software update from the computer vendor, •
the information system staff will have to check the modifications to see if they
are affected by the new update. Because the facility may receive several updates a
year, this can be an onerous task (Rollins 2006).
Screen Design
The information system may allow the facility to make changes to the computer screen so
that it works the best for the facility. Screen design is developing screens of an informa-
tion system to meet the needs of the user and to promote job efficiency. To accomplish this
goal, team members involved in this process must be aware of the needs of the users and
the work they perform. Reasons why the facility may want to change the computer screen
include:
No single screen contains the data needed to make data entry or viewing efficient.•
The vendor’s screens do not have data elements in a logical order for the •
workflow of the users.
The existing screens are too cluttered for the users’ preference.•
AB103409_ch05.indd 133AB103409_ch05.indd 133 2/1/10 1:20:41 PM2/1/10 1:20:41 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
134 Chapter 5
The screen design may include designing computer views for various types of users.
This flexibility would allow nurses to see new orders, care plans, or other information first;
the cardiologist and neurologist would have first access to cardiac and neurologic tests,
respectively.
When designing screens, the fields should be in a logical flow to facilitate data entry.
The flow of data entry should be from left to right and top to bottom. Screen design is very
different from form design. Screens have about one-third of the view that a paper form has
(Rhodes 1997). Screens, like paper, should have a title and/or a control number to manage
the screen. Screens should be simple to use and have a standardized terminology across
screens to facilitate data entry, training, and data quality. For example, the data element
medical record number should be called that on all screens—not medical record number
on one and patient identifier on another. Screens should also have the same look and feel
so that the user can easily move from screen to screen. Instructions can be posted on the
screen where necessary to assist users. Color, blinking, and reverse video can be used to
draw the user’s attention to important data such as allergies. Special features such as color
should be used sparingly so the user’s attention is drawn to the information displayed. The
color of the screen and text should be pleasing to the eye and comfortable for users to view
for long periods of time.
A graphical user interface (GUI) is a method of screen display that uses icons, menus,
and other tools to assist in the use of the system (Hebda et al. 2005). These icons are shown
on a toolbar. Icons provide shortcuts to functionality within the system, along with buttons
and menus, allowing the user to command the software to perform specific tasks and pro-
viding shortcuts to functionality within the system (Williams 2006). The most common and
recognized GUI interface is the Windows GUI.
Report Design
Report design is the process of creating and formatting a report. This design includes the
content of the report, the order of the data on the report, and any desired formatting specifi-
cations. The system may come with standard reports, but most likely will not have all those
needed by the facility. In addition, the reports provided will probably not be presented the
way users want them to look. Because of this, the facility will need to design new reports
and/or alter existing “canned” reports to make sure that users have all of the information
routinely needed. This does not mean that the implementation team has to write every
report the facility will ever need now. The report design discussed here is for the standard
reports that users will need daily, weekly, monthly, quarterly, semiannually, or annually.
Ad hoc reports, which are one-time reports, can be created as needed. Many information
systems have a report writer built into them. Many allow data to be exported into various
reporting systems such as Crystal Reports, Cognos, and Microsoft Access.
Typical characteristics of reports are report title, the date and time that the report was
run, the time period that the data covers, the page number where appropriate, appropri-
ate column headings, and data. These reports may be in a multitude of formats, some of
which can be changed or manipulated and others that cannot. For example, a report may
be generated in Microsoft Excel format, which would allow the user to sort data, run cal-
culations, group, and perform other data manipulations. Other reports may be in Adobe
Acrobat format, which is generally used for the display of data only. A sample report is
shown in figure 5.6.
Interfaces
According to AHIMA (2010, 155), an interface is “the zone between different computer
systems across which users want to pass information (for example, a computer program
written to exchange information between systems or the graphic display of an applica-
tion program designed to make the program easier to use).” Interfaces link two or more
systems together, enabling them to share data such as demographics. In other words, an
interface acts as a bridge between systems transporting and translating data into each
AB103409_ch05.indd 134AB103409_ch05.indd 134 2/1/10 1:20:41 PM2/1/10 1:20:41 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
System Selection and Implementation 135
system’s respective programmed language. Interfaces can be one-way or two-way. One-
way interfaces send data from one system to another without any data returning. In a
two-way or bidirectional interface, data is exchanged between systems regularly.
Writing interfaces is a difficult and time-consuming process because a program has
to be written and maintained for sending and receiving data. Representatives from both
computer vendors must be involved in the process. If one system has the insurance type
Medicare stored as MED and the other system has it stored as MCR, this information
must be converted. This conversion can be performed by an interface engine. An interface
engine allows “two applications to exchange information without having to build a custom-
ized interface for each application” (Abdelhak et al. 2007, 280). The interface engine has
to convert the data so that it can be accepted by the system receiving the information. The
interface must know where the insurance type is stored in the originating system, retrieve
the data, convert the data, and then plug the converted data into the correct field in the new
system. As a tool, the interface engine has made interfaces easier to work with, but there
is still a lot of work to do. An interface engine is a type of middleware. Middleware is
software and hardware that connects applications (Abdelhak et al. 2007). The interface
engine does not eliminate the work necessary to transmit data between systems, but, rather,
reduces it. If the interface engine goes down, no data can be transmitted, which can cause
issues especially with patient care and the need for current information. Figure 5.7 illus-
trates interface engine connectivity.
Figure 5.6.Sample report
Macon General Hospital
Admission Register
March 31, 20XX
Encounter
Number MR Number Patient Name Admit Date Admit Time Attending MD Bed
123456812 1123568 Benson, Mary 3/31/08 19:22 Scott, A 264
123456800 0568745 Johnson, Claude 3/31/08 13:26 Wilson, J 547
123456789 1234567 Smith, Amanda 3/31/08 01:23 Scott, A 246
123456806 0984562 Thomas, Frank 3/31/08 17:47 Jones, X 534
Number of admissions4
Chart locator systemTranscription
Release of
information system
Chart deficiency
system
Interface engine
Hospital information
system
Figure 5.7.Example of interface engine connectivity
AB103409_ch05.indd 135AB103409_ch05.indd 135 2/1/10 1:20:41 PM2/1/10 1:20:41 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
136 Chapter 5
Conversion
With most new information systems, a facility is converting from one system to another—
even if the first system is paper. The facility cannot ignore the historical data but, rather, must
bring some (if not all of it) to the new system. In a paper system, the historical data must be
captured through abstracting, scanning, or other data entry methods. In an information system
implementation, conversion is transferring data from one computer system to another while
simultaneously making any necessary changes in format or content. A conversion is more
difficult than it sounds because systems frequently store data very differently or the facility
may be making changes to how it wants data to be collected. During conversion planning,
the implementation team has to determine how much data is being converted and what data
fields will need to be converted from one format to another. The amount of data transferred
is a decision that must be made by the facility. The decision will be influenced by the type
of system, laws and regulations, whether or not the old system will remain operational, and
other issues. Sometimes facilities decide to transfer data from a specified time period only
into the new system. For example, they may decide to convert only the last 2 years. Other
conversions require all data be transferred. The facility may also choose to enter data for all
time periods, but only selected data elements rather than all data collected.
Planning is critical to ensure the quality of data in the new system. Once the conversion
planning is finished, a program needs to be written that will make the necessary changes.
A formal testing plan is required to determine how the implementation team will test the
conversion to work out any problems before go-live.
Reengineering Processes
Reengineering, also known as business process reengineering, is reevaluating the way the
facility does business in order to improve efficiency. Reengineering is a task that is fre-
quently overlooked in the efforts to implement the IS. Every task and every preconceived
notion must be challenged. The question “why” should be asked over and over. There are
no exemptions from being subjected to evaluation and change—everything is subject to
change. This is challenging to employees who are comfortable with the status quo. Some
of the tasks performed by the employees have been performed for years. The reason behind
the task may be outdated, but the task continues because the employee is afraid to stop. At
one facility, an employee received a report generated by the information system department
every day. The report was filed away and never reviewed. When asked how the report was
utilized, the employee stated that it was never reviewed. The employee balked at the idea of
stopping the report—just in case it was ever needed. The implementation of a new informa-
tion system is a perfect time to critique the tasks performed to try and improve efficiency,
costs, and effectiveness (Abdelhak et al. 636).
The employees may feel threatened and afraid because of the changes impacting their
job, but reengineering is a necessary part of the information system process. The facil-
ity cannot implement a computer system and expect the work processes to remain the
same. The facility will need to change procedures, update the policy and procedure manual,
change workflow, eliminate unnecessary tasks, and add new tasks. Failure to do so can
decrease efficiency rather than maximize on the benefits the system affords. The informa-
tion system changes the way a facility conducts business and impacts the manual processes
and workflow as well as their overall interaction with the computer. The documentation
tested during the testing phase should contain the revised processes.
Policy and Procedure Development/Documentation
After the reengineering is completed, the policy and procedure manual must be updated
to reflect the new way of doing business (Abdelhak et al. 2007). Policies and procedures
should blend together the manual processes and decision-making processes. Management
AB103409_ch05.indd 136AB103409_ch05.indd 136 2/1/10 1:20:41 PM2/1/10 1:20:41 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
System Selection and Implementation 137
and maintenance of the system itself must also be clearly outlined. Examples of system
policies are backups, downtime policies for routine maintenance, upgrades, testing of
upgrades, and disaster planning.
The policies and procedures need to address how the system will be used by the various
users throughout the facility such as coders, admission clerks, and other staff. In addition,
the healthcare facility must create training manuals and user guides for reference. These
materials will be available to the users as resources on how to use the system, how to incor-
porate it into their job, and how to identify how their job has changed.
Check Your Understanding 5.4
1. An interface engine is an example of:
A. system analysis tool
B. functional requirements
C. setting configuration
D. middleware
2. The type of testing where both the old system and the new system are operating at the same
time is:
A. interface testing
B. application testing
C. parallel testing
D. conversion testing
3. The form used to report problems with the new system is frequently called:
A. trouble ticket
B. request for proposal
C. functional requirements
D. testing plan
4. The implementation stage that looks at the way the business does business is called:
A. testing
B. reengineering
C. conversion
D. system analysis
5. True or False: Volume testing tests the amount of data stored on the computer.
Training
Training is crucial to the success of the implementation process. There needs to be a well-
designed training plan that addresses the timing and methods used to train the users (Engle-
bardt and Nelson 2002). The plan must be properly executed or negative repercussions can
occur. Users may be concerned they are reverting back to being a novice employee after
being an expert in their position. They may also be concerned about whether or not they
will be able to keep their job if they are unable to learn the new computer system. Individu-
als who are most concerned with the new computer systems are those who are not comfort-
able with computers at all. Communicating with employees and keeping them informed of
changes, impact, and expectations of their position will help prepare them for training.
Each person learns differently. Learning ability is impacted by their age, maturity level,
and experience, so their preferred learning style may change over time. Because of these
AB103409_ch05.indd 137AB103409_ch05.indd 137 2/1/10 1:20:41 PM2/1/10 1:20:41 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
138 Chapter 5
factors, instructors should use a variety of methods that will reach all learning styles. Typi-
cal learning styles are:
Sensory: Is the learner auditory (prefers to listen), visual (prefers to read), or •
kinesthetic (prefers to practice)?
Personality: Various personality traits shape our orientation to the world.•
Information processing: People differ in how they receive and process information.•
Instructional and environmental preference: Sound, light, structure, and learning •
relationships affect perceptions. (LaTour and Eichenwald Maki 2007, 717)
Instructors and trainers should have a basic understanding of adult learning principles
and practice them in the development of training and its implementation. Some key adult
learning principles are:
Adults like being responsible for their own decisions: They resent not having •
control, so the instructor should let the learners have a say in the program. This
can take the form of helping to set the agenda, deciding which of two or three
activities to do, and so on (Bryant and Reimer 2007).
Adults are experienced: Adult learners come to the training session with a lot •
of experience and knowledge upon which they can draw. Not all adults have
the same knowledge and experience. The instructor and students can learn from
each other. The varied backgrounds and knowledge can make for an interesting
discussion and an improved learning experience (Bryant and Reimer 2007).
Adults need to know why: Instructors should get into a habit of telling the adults •
why they need to do or learn what they are being taught. They need to know why
something is important just as much as they need to know how to do something
(Bryant and Reimer 2007).
Adults need to see relevance: Adults do not want to waste their time. They want •
to learn what they need to know for the immediate future. The instructor will
need to tie the material in the class to what the individuals in the course will be
doing. In other words, do not teach nurses how to do something with the computer
system that only the HIM department will be doing in the future. The nurses need
to know what they will be doing. If an adult learner does not see relevance to
themselves, they will not be motivated to learn (Bryant and Reimer 2007).
The adult needs to be ready to learn: Training sessions may be mandatory and the •
learners may show up physically to the session, but they cannot be made to learn.
The instructor must engage the learner and encourage the desire to learn (LaTour
and Eichenwald Maki 2006).
The learner has to be motivated to learn: Some healthcare facilities have motivated •
learners by making them take a competency test at the end of the training session.
This test makes the learner use skills they learned in class. The motivation comes
in because the healthcare facility usually ties the future of their job to successfully
completing this test. These tests are generally very easy, but there are people who
cannot pass them. These users are usually given a second or third chance before
they are terminated. The threat of termination is not the best motivation because
motivation to learn should come from within; however, the facility must know that
the users are competent to use the systems (Bryant and Reimer 2007).
Planning for Training
There should be someone on the project team who is responsible for planning the complete
training process. This trainer has a wide range of responsibilities including developing
objectives, developing the training plan, and implementing the training.
AB103409_ch05.indd 138AB103409_ch05.indd 138 2/1/10 1:20:41 PM2/1/10 1:20:41 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
System Selection and Implementation 139
The trainer would attend implementation team meetings in order to keep up with the
status of the project. The trainer needs to know when training will be needed, the type of
training needed, and also be a superuser (or expert) on the new system. With this knowl-
edge, the trainer will be prepared to develop the training program necessary to teach others
to use the system. The trainer is responsible for sharing and providing the necessary knowl-
edge needed to prepare other trainers to teach as well.
The trainer will also work with the training staff from the vendor. The vendor’s staff
knows the product well and will be able to offer the team suggestions on different teach-
ing methods directly related to the system. The vendor should provide the trainers with
resources that can be customized for the facility.
Keep in mind, that as the trainer, he or she will be working with both management and
end users during the training planning and training implementation stages. These interac-
tions make the trainer an excellent liaison between the two groups. The trainer will be able
to communicate expectations of administration to users as well as communicate the fears
and concerns of the users back to administration.
Contents of the Plan
The project team should create a training schedule that allows everyone who needs training
to participate (Englebardt and Nelson 2002). The schedule should include sessions for all
work shifts. This may mean training sessions are conducted for the day, evening, night, and
weekend shifts. The training plan should contain learning objectives providing both trainer
and trainees with information about what will be accomplished throughout the training
sessions. The training plan should also outline the agenda, which describes the functions
of the computer system that will be covered, how they will be covered, and how much time
will be spent on each topic (Englebardt and Nelson 2002). The “how it will be covered”
section includes teaching tools such as PowerPoint, hands-on training, demonstrations, and
computer-assisted instruction to be used during training.
The training plan should also address the content that will be covered. These may
include topics such as rollout schedule, policies and procedures, confidentiality, and secu-
rity. When planning content, trainers need to determine the level of computer literacy each
trainee possesses before determining what training is needed. For example, have they ever
used a mouse? Do they need to learn Windows? The trainer will need to determine how
many students will attend each session so that the number of trainers and training sessions
can be determined. The planners will also have to determine the resources that will be
needed such as a training room, computers, Internet access, training database, data projec-
tor, and handouts.
Another decision to be made is how the training will be divided into sessions, because
not all users need the same training. Two examples for the division of sessions are by
department (such as nursing) or by function (such as order entry). In other words, the plan-
ner needs to decide whether the session will teach all nurses together or will the session
teach people how to look up test results and have everyone who needs to know how to do
this included in the same session. The division of the training will impact the number of
teachers, the schedule, and the training materials.
Selecting the Training Location
Not every trainer is fortunate enough to have a dedicated training facility. Trainers may be
forced to reserve computer classrooms throughout the facility. If so, the rooms need to be
reserved early. Whether there is a dedicated room or not, the trainer should make sure the
room is physically comfortable. This means that the room is at a comfortable temperature,
has appropriate lighting, and the workstations are ergonomically sound. Cellular phones
and beepers should be turned off in order to prevent distractions.
Scheduling the Training
Scheduling can be a very tricky task because trainers have to conduct different training
classes required by patient care providers, administrative office staff, and other groups of
users. Many healthcare facilities are open 24 hours, 7 days a week, thus employees work a
AB103409_ch05.indd 139AB103409_ch05.indd 139 2/1/10 1:20:41 PM2/1/10 1:20:41 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
140 Chapter 5
variety of shifts. Because of this, training must be offered on all shifts including weekends.
Issues to consider are as follows:
If there is more than one class required, the team must make sure that they are •
offered in a logical format. Breaking modules down into separate classes is
wise because otherwise the students become confused. For example, the trainers
would need to teach an introduction to computers class before the trainers teach
Windows, and the trainer would need to teach Windows before they can teach
people to use a Windows-based application.
This is further complicated by the fact that the trainers need to schedule the •
classes as close as possible to go-live while starting training early enough to
get everyone trained in time. Completing training too early is also problematic
because the users can forget what they learned before the system is implemented,
thus making the transition difficult for the user and the facility.
Length of a session matters. Short sessions tend to work better because most •
healthcare professionals are used to being on their feet while working. They are
unaccustomed to sitting down and may become frustrated by inactivity (Abdelhak
et al. 2007).
The training sessions should not be scheduled during holidays because many people •
take time off, which causes scheduling problems with getting everyone trained.
Physicians should be scheduled for one-on-one training sessions. The reason for •
this is that physicians do not like to appear less than competent in front of peers.
Some physicians do not know how to use the computers and do not want others
to know about their lack of knowledge. Physician training is scheduled at the
convenience of the physician, which is basically any time. It could be early in the
morning, at lunch, late in afternoon, the evening, or on weekends in order to avoid
interfering with physicians’ schedules.
Resources Needed
Each user should be provided a handout at the training session to take back to their work
area. Training materials are excellent resources to be utilized by users to look up how to
do some task that may have been forgotten. Several days, weeks, or even months may pass
between the initial training session and the implementation of the computer system. During
that time, it is likely for users to forget much of the material learned. To help users retain
the knowledge acquired in training, the facility may also want to make the system available
(in test mode) to users for practice throughout this interim period.
Content suggestions to the development of educational materials provided to the stu-
dents are as follows:
The objectives should be clearly outlined.•
The agenda for the course should be sent to the scheduled attendees ahead of time. •
The agenda is subject to change, but acts as a guide to help keep trainers on track.
Train the Trainer
“Train the trainer” is a phrase used to describe a group of one or a few people sent to the
vendor to be trained on how to use the new system and then go back to the facility to train
more trainers (Wager et al. 2005). These people are generally called “superusers.” Super-
users return to the healthcare facility and train other trainers who will in turn help conduct
training sessions (Englebardt and Nelson 2002).
The trainer is the one person whom the user associates with knowledge of the system
and its uses, so the trainer is very likely to receive calls from former students about it. This
visibility will make the trainer a key player in the hours and days following go-live. It will
likely be the trainer that users turn to with questions and fears.
AB103409_ch05.indd 140AB103409_ch05.indd 140 2/1/10 1:20:41 PM2/1/10 1:20:41 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
System Selection and Implementation 141
Conducting the Training
Now that all of the work planning the training is finished, it is time to conduct the class.
Instructors should be prepared to enter the classroom to make sure it is ready for training.
Trainers should use a variety of instructional methods during the session as this has been
found to improve learning. Students should be provided with handouts, policies and proce-
dures, and other materials that they can keep (Hebda et al. 2005).
Evaluating the Training
Trainers must be evaluated on their delivery, impact, and knowledge of the application to
make sure objectives of the training are being met.
LaTour and Eichenwald Maki (2007) identified four outcomes of training that should
be critiqued. These are:
Reaction: What is the reaction of the trainees immediately after the program? Are •
they excited about what they learned?
Learning: What have the trainees actually learned? Can they now use a new •
software program?
Behavior: Have supervisors noticed a change in employee behavior? Has morale •
improved?
Results: How does the actual level of performance compare with the established •
objectives? Can the employees assign codes more accurately? (LaTour and
Eichenwald Maki 2007, 731)
A valuable method for obtaining feedback is to have each trainee complete a written
evaluation at the completion of the session, answering questions about the overall training and
the ability of the trainer. These evaluations can help to identify what is and is not working.
Findings may identify needed improvements such as in the handouts, poor instructors, or not
enough time for hands-on activities. Findings from the trainee evaluations should be shared
with the instructors anonymously so that any needed modifications can be identified, and to just
evaluate the overall training plan performance. Evaluation results should be used to improve
the quality and method of training where needed. There is always room for improvement.
The overall training program should also be evaluated on an ongoing basis to ensure
that goals of training are met. A formal plan for evaluation should be developed prior to the
start of the training sessions.
Additional and Ongoing Training
After the training phase and before go-live, the facility eventually won’t need the same number
of trainers or frequency of class sessions. Training needs should be reassessed to determine fre-
quency and structure of needs. Training may be reorganized to be in conjunction with the facil-
ity’s human resources department new employee orientation program or it may be separate.
Training may be required before the employee is issued a user identification and password.
In a perfect world, the system on which users are trained would remain the same as
the one implemented. However, changes to the system will be made and are necessary for
technology advances, resolving glitches, and other issues. Therefore, training does not end
with go-live of the system. When significant changes are made, training may have to occur
to update and prepare users for the changes. Also, existing employees may need additional
training to learn advanced capabilities, reinforce what they’ve already learned, or if they
transfer jobs or their job changes over time.
Computer-Assisted Instruction
Computer-assisted instruction (CAI) will not be used by most healthcare facilities, but
it is a viable option. CAI is a software program designed to use multimedia and interactive
AB103409_ch05.indd 141AB103409_ch05.indd 141 2/1/10 1:20:41 PM2/1/10 1:20:41 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
142 Chapter 5
technology to teach a topic. A good example of CAI is the CD that comes with many medi-
cal terminology textbooks. Multimedia can use audio, video, simulation, self-quizzes, and
other tools to engage the student. Drill and practice CAI reinforce material that the learner
already knows, whereas problem-solving addresses issues that the learner may face in his
or her discipline (Kreider and Haselton 1997).
The benefit to CAI is that it has been proven to increase learning while decrease learn-
ing time (Hebda et al. 2005). Students are able to work at their own pace and on their own
schedule. They are able to receive immediate feedback on whether or not they do some-
thing right (Kreider and Haselton 1997). CAI also reduces costs, provides standardized
training, and is designed to use multiple learning styles. The student is actively engaged in
the training (Hebda et al. 2005).
Documenting the Training
Documentation of all training provided is critical. Students should sign into each training
session to provide proof of attendance for both employee’s and employer’s benefit. If a
competency test is given, documentation of the results also should be maintained. Copies
of all training materials and objectives for the training also should be retained.
Testing Plan
All components of the information system will need testing before the go-live. The purpose
of testing the computer system is to ensure that everything is functioning properly (Aus-
tin and Boxerman 2007). Testing helps the implementation team identify any bugs (prob-
lems) with the system. This is a cyclical process so the team will test the system, identify
problems, fix problems, and test the system again. The test cycle will continue until all
problems have been resolved. Testing requires careful and detailed planning to ensure that
complete and accurate testing is carried out in a timely manner.
Types of Testing
There are many types of testing that must be performed in preparation for a system imple-
mentation. The types of testing include:
Interface Testing: Ensures that the interfaces function properly. The facility must •
test to confirm that data from the feeder system are transferred into the new system
in the correct field and in the right format. Data to be transferred varies by system
but commonly include the patient’s name, medical record number, date of birth, and
other demographic information. Other types of data that may be transferred include
laboratory tests, radiology results, or any other data that are collected.
Hardware Testing: Ensures that all hardware, including computers, printers, and •
scanners, work together as they should. Examples of testing to be performed
include the ability to scan documents, print a report, or scan barcode. Some
computers may have limitations placed on their abilities for privacy, security, or
other reasons. For example, the facility may choose not to print laboratory results
on the nursing units to protect confidentiality, thus forcing users to look up the
most current results available.
Application Testing: Ensures that every function of the new computer system •
works. Application testing also ensures that the system meets the functional
requirements and other required specifications in the RFP or contract. Application
testing should also ensure that every conceivable situation that the computer will
be used to address can be handled. The team must also test the reports to ensure
that the data and statistics contained therein are correct.
AB103409_ch05.indd 142AB103409_ch05.indd 142 2/1/10 1:20:41 PM2/1/10 1:20:41 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
System Selection and Implementation 143
Documentation Testing: During the implementation process a number of documents, •
including user guides, policies and procedures, and training materials, are created.
These documents should be followed during the testing process to ensure that the
instructions in the documents are accurate. In testing the documentation, the tester
follows and tests the information system documentation that will be provided to the
users. Errors in the documentation will be identified and corrected so that the user
will have the proper instructions.
Conversion Testing: Ensures that the team is able to transfer data from the •
old system to the new system. Conversion testing will confirm that the data
conversion is performed correctly. Testing usually begins with a small amount
of real data that have been copied. After the initial test has been run, the team
would fix any problems, rerun the test, and then continue to add larger and larger
amounts of data. This testing will continue until the team is sure that the problems
have been resolved prior to the actual data conversion.
Training Testing: The team should train a group to see how well the training •
materials, agenda, format of training, time allotted for training, and other
attributes work. Changes are made to the training process as needed before real
training begins.
Volume Testing: Most of the testing performed on the application is done with •
a handful of people sitting at a computer system trying to identify problems.
The system may work fine with a small group of people, but most systems are
used by large groups of people simultaneously. To test the system in as real an
environment as possible, volume testing should be performed. Volume testing
gets as many people to use the system at one time as possible. Volume testing
confirms that the computer system and the network can handle the large volume
of users and data. The user task force as well as other users throughout the
facility can be brought in for volume testing. The project team will need to
recruit as many users as possible to use the system at the same time (Abdelhak
et al. 2007).
Parallel Testing: Unlike most other testing, parallel testing occurs when the new •
system is operational. This is not a required test, but can be a valuable one. Parallel
testing is when the facility runs the old and the new system simultaneously and
compares the reports and data from the two systems to validate both performance
and synchronization. For example, the facility could compare the number of
admissions for a specific date, the number of tests ordered, or the number of times
that a test was ordered. Because of the extra resources needed to operate both
systems, this test is frequently omitted. The benefit to parallel testing is that if
the new system does not work as expected and the facility has to shut the system
down, then the existing system is current, thus not impacting the operations of the
facility.
Acceptance Testing: Like parallel testing, acceptance testing occurs after go-live. •
It is a time to verify that the system is working as expected in a live environment.
It gives the healthcare facility time to confirm that the new system meets response
time, functional requirements, and other standards guaranteed in the contract
(Amatayakul 2007).
Test Plan
The testing plan must cover areas such as what is to be tested, who will be involved in the
testing, dates of testing, documentation of testing results, and types of testing. The testing
must continue until all problems are fixed. The testing must include the documentation cre-
ated for use with the system as well.
AB103409_ch05.indd 143AB103409_ch05.indd 143 2/1/10 1:20:41 PM2/1/10 1:20:41 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
144 Chapter 5
The testing plan should create a realistic testing environment. For example, the set-
tings in the test system should be the ones that the facility will utilize during operation.
The testing plan will identify a “laundry list” of functions that must be tested before the
system is implemented. One way to test the functions is scenario or use-case testing, during
which users bring real-life situations to be addressed by the system. These scenarios should
be documented in the plan. The use of scenarios allows the user to think through how a
situation will be handled by actually using the system. Scenario testing thoroughly tests
the system because it addresses entries into the system, tasks, and output from the system
(Amatayakul 2007).
Testing Documentation
Many healthcare facilities use what is frequently called a trouble ticket to report problems
encountered during the testing phase. The trouble ticket is simply a form that is used to give
specific information on problems encountered. The information provided may include:
screen where problem occurred, function being performed, error message received, data
entered, report with incorrect data, or other problems encountered. The information pro-
vided must be as detailed as possible so that the problem can be replicated by the project
manager or designee. The trouble ticket is logged into some type of tracking system when
received, assigned a tracking number, and assigned to the appropriate person to solve. Once
the problem has been resolved, the resolution is recorded, and the system testing begins
again. The team cannot just test the part that was broken because the change that was made
to fix the problem may have broken something else.
Conversion
Once the system is ready for use and the facility is ready for the system, the data con-
version plan must be implemented to move the existing data into the new system in the
appropriate format (Wager, Lee, and Glaser, 2005). If data conversion is successful, the
facility is then ready to start using the new computer system. Facilities frequently capture
the information available in the system at midnight so that they can determine what data
are in the old system and what data are in the new system. A specific time period of transi-
tion is useful in case the facility has to go back to the old system because the new system
did not work.
Go-Live
Go-live is the official time and date that the facility begins using the new system. The go-
live is generally scheduled for a time when the facility is the least busy. For example, a hos-
pital will generally go-live during the night shift because there is less activity at that time.
Go-Live Models
There are four philosophies with regard to go-live: parallel, phased, pilot, and big bang
(Young 2000).
Parallel Approach
Although parallel start-up works well, it is labor intensive and therefore expensive. Because
the old system is in place and current, this approach provides a safety net and has the least
amount of risk involved.
Phased Approach
Another method is the phased approach. In this method, the implementation starts with one
module of the system, and then gradually other modules of the system are added. A module
AB103409_ch05.indd 144AB103409_ch05.indd 144 2/1/10 1:20:42 PM2/1/10 1:20:42 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
System Selection and Implementation 145
is a subset of an information system such as pharmacy orders in a clinical provider order
entry system. All units, departments, and other entities utilize the system, but they only
use it for one module at a time. For example, a hospital could start using their order entry
system by ordering medications only. After the medication ordering is successful, then
laboratory will be added and so on. With an optical disk system, hospitals frequently start
scanning emergency department records, then outpatient surgery, and then other record
types until they work their way up to inpatient records. The advantage of this method is that
staff is not overwhelmed by trying to do everything at once and the impact on the staff is
lessened. The disadvantage is that it seems to take forever to finish the start-up process.
Pilot Method
The next philosophy is the pilot method in which only one nursing unit, department, or
other entity starts using the new system at a time. Once consistently successful, the next
group is implemented. For example, the 3W nursing unit starts ordering everything using
the new system, but nobody else uses the system. The next unit scheduled would be unit
3E. Again, this method is designed to limit the impact on the facility.
Big Bang Method
The last method, the big bang method which is also called the cutover method, is the most
risky. With this method, the facility stops using the old system and starts using the new
system. It is the riskiest because the facility no longer has the old system as a backup and
the new system is being used all over the hospital, so there are a lot of scared people trying
to use a computer system they are not comfortable with.
Planning for Go-Live
Whichever method is chosen, planning is critical because system implementation cannot
interfere with patient care. There are some steps that should be taken no matter which plan
is selected.
Initial Support
First of all there needs to be a member of the implementation team in every unit or depart-
ment when the system goes live. These team members should be highly visible. They could
all wear the same t-shirts or buttons or some other means of identifying them as a member
of the implementation team. Team members are needed to answer questions and generally
ensure that the system start-up runs as smoothly as possible. Keep in mind that users will
be scared and will want to see someone who can help them. Trainers play an important role
not only in the training but during go-live, which means they are a key part of the imple-
mentation presence throughout the facility.
Ongoing Support
Initially someone must be available 24 hours a day, 7 days a week to assist users. The
length of time that this intensive support is needed will depend on how major a system it
is and how well the implementation is going. Generally this intensive support is needed
no longer than a week (Englebardt and Nelson 2002). There should be a special help desk
users can call for help when needed. The amount of coverage needed will eventually be
reduced to the use of beepers and the regular help desk support. The implementation team
must be prepared to go back to the old system if the new one does not work.
System Evaluation
After the system is implemented and functioning properly, the implementation team will
need to evaluate how well the system implementation went. “The purpose of system evalua-
tion is to determine whether the system functions in the way intended” (Abdelhak et al. 337).
The team needs to learn what did and did not work and determine how they can improve
AB103409_ch05.indd 145AB103409_ch05.indd 145 2/1/10 1:20:42 PM2/1/10 1:20:42 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
146 Chapter 5
the next implementation. The team will also want to know if the facility met the goals
that were established for the project and if the project came in on budget. This evaluation
allows the team to learn from mistakes and from the experience. After a predetermined
time period, the team will need to determine if the facility has realized all expected benefits
(Johns 2007). Some examples include goals such as, did the number of staff get reduced,
or did the facility save the money that was expected, or did it reduce the turnaround time
on obtaining test results?
Post-Implementation
Post-implementation, or maintenance, is the final step of the implementation process. In this
stage, the system is operational and the goal is to provide ongoing maintenance and improve
the system where needed (Hebda et al. 2005). In the immediate post-implementation period,
problems may be found that were not revealed during the system testing and will need to
be resolved. Changes may need to be made to correct the problems and more testing will
need to be done. Even after the system is working well, there will be periodic updates to
ensure the system is current. There will also be routine maintenance and upgrades such
as backing up data, increasing storage capacity, and upgrading hardware and software.
As discussed earlier, major computer systems have what is called a test system or a test
environment (Hebda et al. 2005). This is an exact duplicate of the system in use, exclud-
ing data. In this test environment, changes can be made to the system and tested to see what
happens.
Because it is in the test and not the production environment, the software changes can
be tested without worrying about problems resulting from the changes. This will enable
support staff to solve problems before the update is moved to the live. Once the system is
working appropriately in the test environment, it can be implemented into the live one.
Check Your Understanding 5.5
1. True or False: The active learner prefers to learn by case studies rather than writing papers.
2. The go-live model where the old system is stopped and the new system used is:
A. phased
B. pilot
C. cutover
D. parallel
3. Which of the following is an adult learning principle?
A. Adults need to see relevance
B. Adults like to be told what to do
C. Adults learn well even if not motivated
D. Adults have the same knowledge and experience
4. True or False: System training should be broken into short sessions for healthcare
professionals.
5. The implementation stage where the team determines what they could have done better is:
A. training
B. post-implementation
C. evaluation
D. system analysis
AB103409_ch05.indd 146AB103409_ch05.indd 146 2/1/10 1:20:42 PM2/1/10 1:20:42 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
System Selection and Implementation 147
References
Abdelhak, M., S. Grostick, M.A. Hanken, and E. Jacobs. 2007. Health Information: Management of a Strategic
Resource. St. Louis, MO: Saunders Elsevier.
Amatayakul, M.K. 2007. Electronic Health Records: A Practical Guide for Professionals and Organizations.
Chicago: AHIMA.
American Health Information Management Association. 2006. Wordpower: A glossary of software licensing
terms. Journal of AHIMA 77(4):42, 44.
American Health Information Management Association. 2007. RFI/RFP template. Journal of AHIMA
78(6): web extra. http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_034278.
hcsp?dDocName=bok1_034278.
American Health Information Management Association. 2010. Pocket Glossary of Health Information
Management and Technology, 2nd ed. Chicago: AHIMA.
Austin, C.J. and S.B. Boxerman. 2003. Information Systems for Healthcare Management. Chicago: AUPHA
Press Health Administration Press.
Bryant, G. and J. Reimer. 2006. E-learning for HIM, theory and practice: A new world order or reinforcement
of existing (e-) learning theory. Proceedings of the American Health Information Management Association’s
79th National Convention and Exhibit.
Dolan, T.G. 2006. Contracting for ASP services: When signing for the benefits, remember to manage the
risks. Journal of AHIMA 77(5):48–50.
Englebardt, S.P. and R. Nelson. 2002. Healthcare Informatics: An Interdisciplinary Approach. St. Louis, MO:
Moseby.
Glandon, G.L., D.H. Smaltz, and D.J. Slovensky. 2008. Austin and Boxerman’s Information Systems for
Healthcare Management. Chicago: Health Administration Press/AUPHA.
Hebda, T, P. Czar, and C. Mascara. 2005. Handbook of Informatics for Nurses & Health Care Professionals.
Upper Saddle River: Pearson Prentice Hall.
Johns, M.L., ed. 2006. Health Information Management Technology: An Applied Approach. Chicago: AHIMA.
Kreider, N.A. and B.J. Haselton. 1997. The Systems Challenge. Chicago: American Hospital Association.
LaTour, K.M. and S. Eichenwald Maki, eds. 2006. Health Information Management: Concepts, Principles,
and Practice. Chicago: AHIMA.
McWay, D.C. 2008. Today’s Health Information Management: An Integrated Approach. Clifton Park, NY:
Thompson Delmar Learning.
Merriam-Webster. 2009. Force majeure. http://www.merriam-webster.com/dictionary/force+majeure.
Mikulski, F.A. 1993. Managing Your Vendors. Englewood Cliffs, NJ: Prentice-Hall, Inc.
Rhodes, H. 1997 (March). Practice brief: Developing information capture tools.
Rollins, G. 2006. The perils of customization. Journal of AHIMA 77(6):24–28.
Wager, K.A., F.W. Lee, and J.P. Glaser. 2005. Managing Health Care Information Systems. San Francisco:
Jossey-Bass.
Williams, A. Design for better data: How software and users interact onscreen matters to data quality. Journal
of AHIMA 77(2):56–60.
Young, K.M. 2000. Informatics for Healthcare Professionals. Philadelphia, PA: F.A. Davis.
AB103409_ch05.indd 147AB103409_ch05.indd 147 2/1/10 1:20:42 PM2/1/10 1:20:42 PM
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
AB103409_ch05.indd 148AB103409_ch05.indd 148 2/1/10 1:20:42 PM2/1/10 1:20:42 PM
This page intentionally left blank
EBSCOhost – printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use
4
Merlyin
Software Development Life Cycle is a process which is followed for a project that involves software for organizations such as healthcare. It is a detailed master plan that explain steps of building, maintaining, replacing, and improving certain software. The life cycle is an operation that intensify the quality of software and the entire development and its process(Adanna & Nonyelum, 2020).
There are different stages in SDLC:
1. Feasibility – project time, existing budget, build from among the organization staff/ hire people from outside
2. Analysis – Business rules, security roles, use cases, access to the system, and sample reports
3. Design Phase – logical design, physical design; designs will be reviewed
4. coding phase – writing codes, targets to meet specific requirements that are generated in early stages
5. testing phase – checks to make sure that system works properly
6. Deployment – software is released in to the production environment for operations(Learning, 2019).
SDLC is an essential tool in leading the HMIS system implementation. It supplies the steps for expanding any meaningful system as it already renders the needed steps for accuracy. SDLC is the actual requirement any organization that would need to match their needs with the software development projects for their entity(Adanna & Nonyelum, 2020).
Different models of the SDLC can be applicable to several projects. The use and requirements of each software differs for each particular projects. Time and resources are two sources that organizations need to consider when deciding which model serves the purpose. The key-note is that each definite process in the life cycle plays an important role in developing these software products(Adanna & Nonyelum, 2020).
Reference
Adanna, A. A., & Nonyelum, F. O. (2020). Criteria for Choosing the Right Software Development Life Cycle Method for the Success of Software Project. .IUP Journal of Information Technology,16(2), 39–65.
Learning, D. (2019, February 14).What are the steps of the software development lifecycle … – youtube.
https://www.destinlearning.com/p/itguide
. Retrieved June 14, 2022, from

Roberta.
The system development lifecycle, or SDLC, is the seven general steps taken to build software. These steps are performing a feasibility study, requirements analysis, design, code, test, deploy, and operate/maintain (Destin Learning, 2019). Both Healthcare Management Information Systems (HMIS) and Healthcare Information Systems (HIS) are software that help healthcare organizations to improve efficiency and, ultimately, provide better patient care. As these are two forms of software, SDLC steps apply to both. At the same time, some smaller healthcare organizations may not have the capacity to have their own internal IT staff. If an organization does not have their own internal IT staff, SDLC can be adapted from making a software, to buying a software.
By purchasing a program that has already been developed and well tested, that meets the needs of the organization, there are less direct steps involved in building a program and operations/ maintenance. These steps are outsourced to a company that can meet with management and help them decide the best program for the goals of the facility (McMurtrey, 2013, pp. 17-19). Integrity is not compromised because management is working collaboratively with a vendor that can provide guidance, maintenance, and the software. Although, management must also be knowledgeable enough to properly establish what their needs are and how a software will work for their facility. There needs to be proper communication between the vendor and management regarding the implementation progress, a timeline, performance expectations, and testing to ensure an organization is being set up for success (Blake, 2004).
SDLC is a cyclic process, working as a feedback loop. If everything is running smoothly, the steps will flow from one to another. Once testing occurs, developers may find errors that require going back to a previous step. The same steps are also used to add new features to a developed software as well (Destin Learning, 2019). The more tests and data collected; the more information developers can use to optimize their software for a facility.
Part II.
A managerial process for system acquisition based on the Vroom-Yetton-Jago Decision Model could include (Free Management Books, n.d.):
1. Assess the needs of the organization based on current mission statement and goals. Identify risks and any necessary quality standards (Blake, 2004).
Begin by assessing how implementing new technology would create short-term and long-term improvements to the organization. This may include identifying any gaps in quality reporting for reimbursement, identifying what financial or staff resources are available to commit to these projects, and gathering the opinions of other stakeholders once an assessment is complete.
2. Research potential vendors and meet with unit managers to gain insight into their perspective (Blake, 2004).
After goals have been established and stakeholders have given their approval for such a large expense. Begin researching vendors in the area that are used by other organizations for potential future interoperability. Present the options to unit leaders as they will be the ones utilizing these programs. Select a unit to trial the program before large-scale implementation. This allows management to gather insight from staff and adjust the software in collaboration with a selected vendor. Keep stakeholders updated with project progression.
3. Solidify plans: Timelines, Rollouts, Future Maintenance (Blake, 2004).
A vendor has been selected with input from stakeholders and unit managers. A small-scale implementation plan has been established with a timeline of two months before implementing throughout the facility to help determine any errors or improvements that could be made. Bedside staff are given informal education sessions regarding the upcoming additions to the facility, eventually to be formal training sessions. This allows them to ask questions and vocalize any concerns. Vendor will provide maintenance and IT assistance for staff after full-scale implementation. Budgets have been planned and agreed upon. Stakeholders are informed and accept this agreement.
References:
Blake,J. (2004).Project managing the SDLC: Using milestones to align project management and system development lifecycles and report project success. Project Management Institute.
https://www.pmi.org/learning/library/project-managing-sdlc-8232
Destin Learning. (2019, February 14).What are the steps of the software develop lifecycle?[Video]. YouTube.

Free Management Books. (n.d.).The top 5 decision making models you need to know.
https://www.free-management-ebooks.com/news/decision-making-models/
McMurtrey,M. (2013). A case study of the application of the systems development life cycle (SDLC) in 21st century health care: Something old, something new?Journal of the Southern Association for Information Systems,1(1), 14-25.
https://doi.org/10.3998/jsais.11880084.0001.103

Place your order
(550 words)

Approximate price: $22

Calculate the price of your order

550 words
We'll send you the first draft for approval by September 11, 2018 at 10:52 AM
Total price:
$26
The price is based on these factors:
Academic level
Number of pages
Urgency
Basic features
  • Free title page and bibliography
  • Unlimited revisions
  • Plagiarism-free guarantee
  • Money-back guarantee
  • 24/7 support
On-demand options
  • Writer’s samples
  • Part-by-part delivery
  • Overnight delivery
  • Copies of used sources
  • Expert Proofreading
Paper format
  • 275 words per page
  • 12 pt Arial/Times New Roman
  • Double line spacing
  • Any citation style (APA, MLA, Chicago/Turabian, Harvard)

Our guarantees

Delivering a high-quality product at a reasonable price is not enough anymore.
That’s why we have developed 5 beneficial guarantees that will make your experience with our service enjoyable, easy, and safe.

Money-back guarantee

You have to be 100% sure of the quality of your product to give a money-back guarantee. This describes us perfectly. Make sure that this guarantee is totally transparent.

Read more

Zero-plagiarism guarantee

Each paper is composed from scratch, according to your instructions. It is then checked by our plagiarism-detection software. There is no gap where plagiarism could squeeze in.

Read more

Free-revision policy

Thanks to our free revisions, there is no way for you to be unsatisfied. We will work on your paper until you are completely happy with the result.

Read more

Privacy policy

Your email is safe, as we store it according to international data protection rules. Your bank details are secure, as we use only reliable payment systems.

Read more

Fair-cooperation guarantee

By sending us your money, you buy the service we provide. Check out our terms and conditions if you prefer business talks to be laid out in official language.

Read more