Working with Health IT Systems is available under a Creative C.docx

Working with Health IT Systems is available under a Creative
Commons Attribution-NonCommercial-
ShareAlike 3.0 Unported license. © Johns Hopkins University.
UMUC has modified this work and it is
available under the original license.
http://knowledge.amia.org/onc-ntdc/working-with-health-it-
systems-1.379705
https://creativecommons.org/licenses/by-nc-sa/3.0/us/
Welcome to Installation and Maintenance of Health IT Systems,
System Selection-Functional and Technical
Requirements.
1
The objectives for this unit, System Selection – Functional and
Technical Requirements are to:
• Identify 12 possible steps to choosing an EHR system
• Gather functional requirements from institutions and others
• And document use-cases and relate them to functional
requirements

2
The purchase of an EHR system will have a profound effect on
your practice or healthcare institution. It is important
that you develop a plan for assessing your institution’s needs to
facilitate vendor selection. Today we are going to
discuss twelve steps in the decision-making process when
choosing an EHR system. Though neither these steps,
nor the order in which you choose to execute them are written
in stone, we have chosen to present them in a logical
progression to help you understand the importance of
developing a plan that will work for your organization and to
help ensure that you are capable of making a high quality
decision when it comes to EHR selection.
The article “How to Select an Electronic Health Record System”
lists 12 recommended steps to evaluating an EHR
system:
1. Identify the decision makers
2. Clarify your goals
3. Determine functional requirements and write a request for
proposal, or RFP
4. Determine RFP recipients
5. Review RFP responses

6. Attend vendor demonstrations
3
7. Check references
8. Rank vendors
9. Conduct site visits
10. Select a finalist
11. Solidify organizational “buy-in”
12. Negotiate the contract
Now, let’s discuss each of the steps in some detail.
4
People, as well as whole institutions, are often resistant to
change. Despite the fact that many agree on the benefits of
using
electronic records, resistance will certainly become evident
when discussing conversion to an EHR system within your own
institution. Success or failure will often hinge on how well the
EHR system is received by managers and practitioners alike, as

well as on ensuring staff and management are comfortable that
their concerns have been adequately addressed during the
decision-making process.
Here are some tips to help ensure adequate buy in for your EHR
selection process:
In many healthcare institutions, the selection of EHR systems
has been led by committed physicians who devote much time
and
energy into learning about EHR systems and promoting
adoption to their peers. Consider this tactic when considering
who will be
involved in the selection process. Also, remember to keep your
committee as diverse as possible, being sure to invite influential
people from all elements of the institution, managers and staff
alike, to assist with the selection efforts.
5
Before evaluating EHR systems, you must evaluate your
institution. In this stage, you’ll want to examine what it is you
want to
accomplish with your new EHR system. Define which
inefficiencies and limitations you currently see in your
environment today.

For instance, do lab reports take too long to be added to the
patient chart? Are your billing codes consistently outdated?
Be sure to identify the overall business strategy for your
organization and be sure that these goals are in alignment there
as well.
6
A critical step to purchasing any health information technology
is performing a requirements analysis of your environment. In
the
past, performing a requirements analysis often involved asking
stakeholders what they wanted in the application they were
seeking.
For clinical information systems, this process has not worked
well, primarily because most stakeholders simply have not been
exposed to these systems adequately to understand their overall
potential and possible limitations, often resulting in
assessments with minimal functionality or unrealistic
expectations.
Today, most experts recommend a three-step process for

identifying functional and non-functional requirements:
1. Understand existing standards
2. Understand the market place and
3. Apply “use cases”
7
Functional requirements can be defined as those processes that
you want a system to perform. These can be discussed as an
overview or can be analyzed in great detail. The more granular
you get with your requirements, the better overall understanding
you will have of how the systems will work and the impact
implementation will have on workflow and processes. There are
copious examples of functional requirements, from results
reporting, to remote access, and on and on.
8
Conducting a needs assessment will assist in these efforts.
Once you have identified the functionalities your system should
have, rank them in order of importance. It may be helpful to
classify them as “must-haves”, “want-to-haves”, and “not-
criticals”.

Perhaps results reporting is more important in your institution
than electronic fax reports. Maybe remote access is critical
because of the number of satellite locations.
Next, map these needs you have identified to the specific
system features and functionality which will address them.
9
Be sure to take time to learn what’s available from the many
vendors providing EHR solutions. Browsing the internet for
ideas, as
well as reading up on vendor specifications and trade
publications, can give you an idea of what functionality
requirements are
most often associated with your particular organization and thus
can paint a picture of the “market norm.”
10
Now let’s discuss the HL7 EHR System Functional Model,
which is a repository of standard EHR functions that could be
very
helpful in your assessment.

HL7, which stands for Health Level Seven, is an all-volunteer,
non-profit organization involved in the development of
international healthcare standards for storing & exchanging
clinical and administrative data.
The February, 2007, version of the Functional Model contains
more than 160 functions which form a superset of possible EHR
functions – more than any one system is likely to need. Subsets
of these functions, called “functional profiles”, are then created
and described for use in specific healthcare settings, such as
behavioral health, child health, and emergency department.
Each functional statement has corresponding “conformance
criteria” which provide more detail about how the system can
carry
out the task.
11
Healthcare organizations can use this model to help generate
their EHR requirements.
The following steps provide a good start in taking advantage of
the functional model as a tool.
Learn the key words used in developing criteria:

• Shall is used to indicate a mandatory requirement for an EHR
system to achieve conformance with the standard.
• Should indicates an optional or recommended action for an
EHR system.
• May indicates an optional or permissible action for an EHR
system.
Learn to read the model. Understand that there are over 160
functions divided into three sections:
1. Direct care
2. Supportive
3. Information infrastructure
and that it is represented as a hierarchical list.
Lastly, review the model (particularly a relevant Functional
Profile, if available) and select sections relevant to your
particular
healthcare setting, then evaluate each of these functions to
determine relevance to your organization.
12
Let’s look at an example of an HL7 functional statement and its

related conformance criteria.
The functional statement says the system “provide[s] patient
data in a manner that meets local requirements for de-
identification”.
To meet the standard for this function, four conformance
criteria are given:
1. “The system shall provide de-identified data according to
realm-specific law or custom when requested by an authorized
internal or external party.
2. The system should comply with I.2.4, Extraction of health
record information (conformance criteria 2). (The system should
provide de-identification functionality for extracted
information.)
3. The system may provide the ability to export deidentified
data to authorized recipients.
4. The system may provide a key with de-identified data to
enable re-identification of the data or the contact of primary
care
provider.”
13

Non-functional requirements refer to attributes of the system as
a whole or its environment rather than to specific tasks that the
user needs to accomplish (like writing an electronic
prescription).
Nonfunctional requirements include:
• Usability is the ease with which a system can be learned and
used. An example of a nonfunctional requirement for usability
would be that the end user can navigate to any page in the EHR
in five clicks or fewer.
• Reliability is the degree of uptime the system must perform
for the users. An example of a nonfunctional requirement for
reliability would be that the EHR system will have redundant
back ups allowing for 99.5% uptime.
• Performance usually refers to how well the system works for
the user in measurable degrees. Examples of performance
would be response time and capacity.
• Supportability is the application’s ability to be easily modified
or maintained to accommodate typical usage or change
scenarios.
14
• Scalability is the ability to increase the number of users or

applications associated with the product.
• System requirements would include minimum and
recommended required operating systems, commercial-grade
software
development tools, specific hardware or platform requirements,
and any environmental requirements such as redundant
environmental controls.
• Legal and regulatory requirements would include
telecommunication requirements, compliance, etc.
• Security is the ability to provide confidentiality, data
integrity, and data availability, for example as mandated by
HIPAA. An
example of a nonfunctional requirement for security would be
the capability to log all patient access by any user in the system
and retaining such logging for one year.
15
A use case is a technique for documenting the potential
requirements of a new system or any type of system change.
Each use
case provides one or more scenarios that explain how the system
should interact with the end user or another system
component to achieve a specific goal or function. Use cases are
usually written in simple terms and focus on how workflow

processes correspond with system or application processes to
accomplish the goal.
16
As an example, here is a use case scenario for writing a
prescription for a patient before an EHR is available. The
analyst
gathers this information from interviews, observations, or any
combination of the two.
• First, Joe pulls out his prescription pad and pen.
• Next, Joe consults with a pocket drug reference to check the
usual dosage.
• Then, Joe glances at Jane's allergy list to make sure she is not
allergic to the new medication.
• Next, Joe handwrites the drug name and the "sig" - in other
words, the dose, route, frequency, quantity, and number of
refills.
• Finally, Joe hands the handwritten prescription paper to Jane
for her to bring to the pharmacy.
17
Now this use case describes the same task with an EHR, also
known as “e-prescribing”:

• First, Joe activates the e-prescribing module within the EHR.
• Next, Joe searches for and selects the drug he wants to
prescribe, and he sees the usual dosage, frequency, etc.,
presented
as options on-screen
• Next, the e-prescribing system checks behind the scenes to see
whether Jane is allergic to the selected medication or
whether it has any significant interactions with her other current
prescriptions.
• Then Joe fills in the required data to complete the
prescription. If it is a commonly prescribed medication, he
quickly selects a
complete prescription (i.e. drug, dose, route, quantity, refills,
etc.) from a list of common options for that drug.
• Finally, Joe asks Jane from which pharmacy she would prefer
to pick up the medication, selects that pharmacy in the system,
transmits the e-prescription, and tells Jane it should be available
for pickup shortly.
As you can see from comparing the tables, the analyst expects
to see significant improvement in this process once the EHR
system has been installed. The analyst will use this scenario to
compare performance ratios with each of the EHR vendors.
There could be dozens of use cases to consider when choosing a

new EHR system before it is all said and done. The case study
analyst will look at each of the various components including
needed software, hardware, data transmission, change in work
flow, etc…that would provide the best fit for seeing each of
these scenarios to completion.
18
Now let’s discuss how you would create a Request For
Proposal, or RFP, following a specific outline to tell
prospective vendors
what they need to know about your practice in order to provide
you with useful information about their products. This will help
ensure that the responses you receive can be easily compared.
A typical outline for an RFP includes:
Cover letter
Introduction and selection process
Background information, including organization size and
specialty and current systems and hardware in place
Desired EHR functionality
Vendor information you should receive should (at the very
least) include:

Product description
Hardware and network components needed
Customer maintenance and support and warranties
Training available
System implementation plan
19
Proposed costs
Sample contract and
Applicable references
19
There are more than 200 different EHR systems currently
available on the market. How can you narrow the list to only
those
EHR systems most relevant for your organization?
Start with these four questions:
1. Does the software have a history of interfacing with your
practice management system, or PMS? To work

effectively, your PMS (which generally performs operational
functions such as patient scheduling, billing, and
reporting) and the EHR must be able to share data. This is
typically done through a software interface. Building,
maintaining, and updating an interface requires the cooperation
of personnel from both companies. Be sure that
these two systems can talk to each other with a minimal amount
of customization.
2. Is the EHR typically marketed to practices of your size?
EHR vendors typically market their systems to one of three
scales: small practices, with 1 to 15 providers; medium-sized
practices, with 10 to 99 providers; or large practices,
with 100 or more providers.
3. Does the EHR have favorable published ratings? Several
excellent sources for EHR ratings are available. In 2003,
for example, the American College of Rheumatology, in
conjunction with the Aurora Consulting Group, evaluated
EHRs in small practices. Also, trade shows such as Healthcare
Information and Management Systems Society, or
HIMSS, or Towards an Electronic Patient Record, or TEPR, can
provide opportunities to see vendors’ wares and
glean knowledge from show-goers.
4. Does the EHR meet your organization’s functionality needs?
Will the EHR adequately address all or most of the
goals and functionality requirements you are looking to address
with your new EHR system? Compare each system
to your checklist and rankings and determine which ones should
receive an RFP.
20

Now that you have received responses to your RFP, take one or
two sessions as a committee to review the proposals and select
the best candidates based on your criteria.
Next, set up vendor demonstrations with each of your
contenders. Prepare a couple of patient scenarios for them to
document,
and use a standardized rating form. Use the same approach with
each vendor to ensure consistent ratings.
21
Check at least three references for every vendor that is still in
the running. Ideally, references should include one or more
physician users, an information technology (IT) person, and a
senior management person. The vendor will provide you with a
list
of references – note that these are likely the vendor's happiest
customers, and they may even be financially rewarded for
talking
to you (e.g., discounts on service fees or individual rewards), so
be skeptical. Nonetheless, these folks can be very informative
and honest, in our experience. If you know a person or group
not on the vendor's reference list who has used their product,

call
them too. Have a prepared list of questions for these phone
calls.
Consider asking questions from each reference centered around
these areas:
•Background
•Provider usage
•Training and support
•Implementation & hardware and
•Satisfaction
22
Now that you've reviewed the RFPs, seen the vendor demos, and
done all the reference checks for each vendor you are
considering, it's time to rank the vendors and narrow the field to
two or three vendors for whom you should set up site visits to
view the software in action. Site visits can take up lots of time
and can require the organizational efforts of a master to get
your
team together at a common time, making more than three visits
pretty much impractical.

Before you rank the vendors, you should formally weigh your
priorities in the following areas:
• Functionality. How well does the product perform to your
specifications?
• Total cost. How much will the product cost, including all the
needed hardware, software, technical support, etc.?
• Vendor Services. Will the vendor provide the expected
service, training, and initial implementation support, and will
they be
there for the long haul?
Once you've selected your final contenders, plan site visits to
see how the systems perform. Go to practices that are similar in
size and configuration to yours. If possible, go to one that is
using the same practice management system, or PMS, that you
are
using. Bring at least one physician and the most senior
management person that will be responsible for the EHR
purchase. Plan
to visit with physicians and observe them with patients. Also
talk to their back-office personnel, relevant management, and
key IT
personnel. Take notes.
23

Finally, after each site visit, go back to your vendor rankings
and see if they still agree with your latest findings. Select your
top contender
and a runner-up. If negotiations don't go well with your number
one choice, you may want to fall back on your runner up instead
of
wasting more time reevaluating the vendor pool again.
23
Earlier, as part of the RFP, you asked each vendor to list the
minimum and recommended hardware and software
requirements
for installing their version of the EHR in your institution’s
environment. Choosing the right hardware is important to
ensure that
your EHR’s performance potential is fully realized and to
minimize installation and performance issues down the road.
Hopefully, your institution, as part of the decision-making
process, your institution has already come to terms that at least
some
technology will need to be acquired or upgraded to
accommodate the integration of a new EHR system.

Prior to solidifying a deal with a particular vendor, take a hard
look at these requirements, being sure to address these issues:
Take an inventory of your current server, workstation, and
mobile technology hardware (such as laptops and PDAs) as well
as
the current operating systems and applications being deployed
and used in your computing environments. Do the vendor’s
specifications align well with your current technologies?
If the vendor recommendations exceed your current hardware
and software requirements, is your organization prepared to
dedicate the financial and organizational resources needed to
meet these recommendations?
24
Your organization is likely already using different patient
management software. Your EHR will need to be able to
communicate
with this pre-existing system. Does the EHR you’re considering
integrate well with these existing packages, or will you need to
budget for customized interface engines or even new PM
software applications? We will discuss interfaces and interface

engines
in more detail in a later unit.
Purchasing an EHR is usually a long-term commitment. EHR
software life cycles can often span decades. Your organization
will
want to have the flexibility to integrate new computing
technologies as they become available. Is the vendor up to date
on these
emerging technology trends, and are they committed to ensuring
that their software will be scalable for the foreseeable future?
25
Hopefully, if you are choosing an EHR system for a smaller
practice, you have already included all the relevant decision-
makers
in the selection process. Larger organizations may require
additional “selling.” Consider inviting the vendor to do a public
demonstration or a presentation to the stakeholders group to
help solidify commitment.
As noted before, typical EHR contracts span from 10 years to
lifetime. If the contract is to terminate in 10 years, be sure you
know what happens after that. Current and future costs should

be spelled out, as should the role the vendor will play and the
amount of time the vendor will commit to the implementation
process. Be sure to consider the possibility that the vendor
could go
out of business before you do. Request that the vendor's source
code be put into escrow, and clarify the circumstances under
which you could get access to it. Have a lawyer experienced in
software contracts help with this step.
26
Now that we’ve walked through those steps on evaluation and
selection of EHRs, let’s look briefly at the process as
recommended by HealthIT.gov, a website launched in
September, 2011, by ONC, the Office of the National
Coordinator for
Health Information Technology. They list 9 steps, which should
sound very familiar after our prior discussion:
1. “Site visits for EHR solution
2. Develop and distribute request for proposals (RFPs)
3. Review vendor proposals
4. Conduct vendor demonstrations
5. Review specialty specific functionality and general usability

6. Identify hardware and IT support requirements
7. Rank EHRs and compare functionality, usability, and pricing
8. Negotiate contract and licensing agreements
9. Purchase an EHR solution”
27
This concludes Unit 3, System Selection – Functional and
Technical Requirements.
In summary, it is important to follow a step-wise method
carefully in evaluating and selecting an EHR, and we have
walked
through 12 such steps from the informatics literature and looked
at the 9 similar steps recommended by the federal government.
You should determine and prioritize your functional
requirements using various sources, including the HL7
Functional Model, and
create use cases to help determine and illustrate those
requirements. And do not forget to pay close attention to the
software and
hardware requirements of the systems you consider.
28

No audio
29
Commons Attribution-NonCommercial-
ShareAlike 3.0 Unported license. © Johns Hopkins University.
UMUC has modified this work and it is
available under the original license.
http://knowledge.amia.org/onc-ntdc/working-with-health-it-
systems-1.379705
This is System Selection – Software and Certification
This component covers fundamentals of selection, installation,
and maintenance of typical Electronic Health Records (EHR)
systems.
This unit, System Selection - Software and Certification, will
discuss the differences in COTS (Commercial Off-The-Shelf)
and
in-house/homegrown systems and how to select the system to

meet the needs of the end users
1
There are many important steps to choosing the correct system
for your institution and ensuring that it will be quickly adopted
by
your users.
Discussion will begin with COTS (Commercial Off-the-Shelf)
and MOTS (Modifiable Off-the-Shelf) versus in-house software
products; their advantages and disadvantages, along with costs
associated with them.
We’ll also discuss EHR certification and ARRA’s meaningful
use criteria with regard to EHR systems.
Finally, we will touch on some typical costs associated with
selection and implementation of EHR systems.
2
COTS, or Commercial Off-the-Shelf, is a term used to describe
a product that is implemented "as-is" while MOTS, or
Modifiable Off-the-Shelf, refers to a commercially available

software product which can be, to some extent, modified
by the purchaser, vendor, or contractor to better suit the
purchaser’s specific needs. For the purposes of this
discussion we will refer to both variants as COTS products.
COTS systems are designed by a software vendor to address the
needs of many different purchasers. The services
provided are those most popular and often most generic, that are
desired by the majority of the customer base.
Most software can be considered COTS; operating systems,
office productivity software, and Internet communication
programs are examples. Because it can be sold to a larger
market, COTS software may be available at relatively low
cost.
At present, well over 200 software companies offer some sort of
off-the-shelf EHR solution. Some of these solutions
include “freeware” solutions, which are open-source products
freely available for use, with commercial support.
3
There are several advantages to buying complete off-the-shelf

products.
For starters, vendor companies have already put up the up-front
costs associated with developing and testing the product. This is
especially advantageous for smaller healthcare settings that
cannot afford an extensive IT development team. As part of the
roll-
out process, vendors often will work with the clinical IT teams
to ensure the product is successfully integrated within the
healthcare setting and plays well with preexisting software
components. When things do go wrong, the vendor provides
additional troubleshooting and support and usually works with
the IT staff to resolve software glitches and bugs. The COTS
products also generally have previously developed training
documentation. This can mean that difficulties in learning the
new
system have been addressed in previous installations at other
institutions.
Because the vendor generally has already created training
programs and materials to help ensure a successful adoption of
the
product into the workplace, users and administrators can often
be brought up to speed faster than with an in-house product.
4

Because many EHR systems are proprietary, access to the
source code is often limited or nonexistent. This reduces the
flexibility of the program and makes the institution dependent
on the vendor to make enhancements to the system, which are
often costly.
Compatibility is also a concern as EHR vendors must contend
with an ever-increasing variety of hardware and software
combinations. Add in the staggering number of drivers,
peripherals, testing devices, and so on, and it becomes obvious
that
there is no way the vendor can test compatibility for all possible
combinations. The issue is compounded with every new
upgrade, which holds the potential to “break” something that
was working perfectly in the earlier version. If a COTS product
is in
your institution’s future, you will need a plan that adequately
addresses which users will receive upgrades and when, as well
as
contingency plans for use in the event that the upgrade is not
successful. Be sure that an adequate test environment exists in
your institution and that upgrades are thoroughly tested before
deployment.

Each vendor is different with regard to frequency of upgrades.
Reputable vendors theoretically are motivated to maintain a
high
level of product quality; however, this is not a guarantee. Keep
open lines of communication with your vendor and stay abreast
of
product issues and pending upgrades. Never assume the vendor
will meet upgrade release dates and never assume a certain
level of quality until you have tested the product in your own
institution's environments.
Another disadvantage to purchasing a COTS product is the
inability to find a product that fits your institution “just
perfectly,” often
5
requiring workflow changes on an institutional level for
successful adoption of the product.
5
Some institutions decide to build their own in-house EHR
solution. In-house software is developed by the operating
institution

and installed and managed by an existing IT team.
This kind of development is only undertaken by larger
organizations with their own IT departments.
Development of the EHR system will often start through
extension of existing In-House systems. Alternatively, the
institution may
elect to use an open-source or otherwise modifiable system and
(depending on the software license) adapt it solely for its own
use, or participate in further public development by contributing
changes back to the source.
6
More often than not, the decision to build an EHR in-house is
driven by the desire to make a product that can fully integrate
with
existing software and/or closely match institutional processes
and objectives.
The existing IT infrastructure and personnel will guide
development of the system to ensure maximum compatibility
with existing
processes.

7
There are several obstacles to creating your own in-house EHR
solution.
First of all, you need to have the right team in place. If you
decide to build an in-house solution, you will be spending a lot
of
time, money, and energy in recruiting and retaining quality IT
developers capable of implementing such a large-scale project.
Not
many people take into consideration the costs involved in
recruiting and hiring the right software development team along
with
the associated hardware and software needed to develop,
compile and test coding components. You should expect to
expend
years of effort and dedicated resources toward the development
and implementation process of an in-house EHR solution.
Secondly, you should have a person capable of monitoring and
assessing the quality of the work, the output, and the
productivity

of the team hired. This consultant or project manager represents
another added expense.
Likewise, your IT team will need to stand on its own when
testing, troubleshooting, debugging, or adding enhancements to
the
EHR system throughout the product's entire lifecycle. This takes
lots of time and resources. Products developed by vendors
have the advantage of multiple clients providing feedback and
bug reporting.
Lastly, before the product can be successfully rolled out to your
users, planning programs and materials must be created,
generally from scratch.
8
Given these obstacles, it's not surprising that many healthcare
institutions – especially those that are not large institutions with
adequate
resources – choose to go with a COTS or MOTS software
solution.
8

The Office of the National Coordinator for Health Information
Technology (ONC), as empowered by the US Department of
Health
and Human Services, provides for a certification program for
Health Information Technology providers and systems.
According to ONC, “Certification of Health IT will provide
assurance to purchasers and other users that an EHR system, or
other
relevant technology, offers the necessary technological
capability, functionality, and security to help them meet the
meaningful
use criteria established for a given phase. Providers and patients
must also be confident that the electronic health IT products
and systems they use are secure, can maintain data
confidentially, and can work with other systems to share
information”
Given that use of a certified system means eligibility for
payments from Medicare and Medicaid incentive programs – up
to
$44,000 for individual practitioners, and over $2 million for
participating hospitals – there is strong incentive for any EHR
system
or module to become certified by an ATCB.

9
A Final Rule on an initial set of standards, implementation
specifications, and certification criteria for adoption by the
HHS
Secretary was issued on July 13, 2010. This Final Rule
represents the first step in an incremental approach to adopting
standards, implementation specifications, and certification
criteria to enhance the interoperability, functionality, utility,
and
security of health IT and to support its meaningful use. The
certification criteria adopted in this initial set establish the
required
capabilities and related standards and implementation
specifications that certified electronic health record (EHR)
technology will
need to include in order to, at a minimum, support the
achievement of meaningful use Stage 1 (beginning in 2011) by
eligible
professionals and eligible hospitals under the Medicare and
Medicaid EHR incentive programs.
10
Certification of EHR systems accomplishes four major goals:

It reduces the risks to investment in EHR systems, which
represent a sizable business investment, by providing additional
assurance that the system is worthwhile.
It may facilitate interoperability between EHR systems, as
multiple systems would adhere to the same set of standards.
As mentioned previously, certification is a prerequisite for
Medicare and Medicaid incentive payments, among other
stimulus
incentives.
Finally, certification requires that EHR systems and networks
protect the privacy of personal health information.
11
Choosing to narrow your search to certified EHR products also
allows you, as the evaluator, to be assured that each of the
certified software products will meet similar standards for basic
functionality, interoperability, and security. This will allow you
to
focus your evaluation more on any special or unusual needs of
your institution. It’s important to note that interoperability is at
an

early stage and requirements for interoperability are still being
established.
Note: Certification examines only the system itself, and does
not evaluate the company’s service aspects or financial
solvency.
You should perform this type of due diligence yourself. It is
important to know that your vendor has a good reputation and
plans
to provide continuous support for your software throughout the
product’s lifecycle.
12
ARRA (American Recovery and Reinvestment Act of 2009),
commonly referred to as the “stimulus bill”, is the economic
package
passed by the U.S. Congress in February 2009. Of the $787
billon in expenditures, $22 billion were allocated to facilitate
modernization of health information technology systems.
The HITECH Act, part of the stimulus package, aims to induce
more physicians to adopt EHRs with potential payments of more
than $40,000/yr via Medicare or more than $60,000/yr via
Medicaid during the initial years of the program.
Starting in 2015, failure to meaningfully use health IT will lead

to financial penalties, starting with 1% reduction in Medicare
reimbursement and growing over time.
13
The meaningful use of EHRs, promoted by US government
incentives, can be broken into five categories:
1. Improve Quality, Safety, Efficiency, and Reduce Health
Disparities
2. Engage Patients and Families in Their Health Care
3. Improve Care Coordination
4. Improve Population and Public Health
5. Ensure Adequate Privacy and Security Protections for
Personal Health Information
14
Let’s take a look at each of these five categories in better detail,
starting with number one: Improve Quality, Safety, and
Efficiency, and Reduce
Health Disparities.
In order to meet this criteria, EHR systems are expected to:

• Use Computerized Provider Order Entry, or CPOE, which
allows the authorizing provider to enter the order directly, for at
least 10% of all orders, of any type
• Implement drug-drug, drug-allergy, & drug-formulary checks
• Maintain an up-to-date problem list of current and active
diagnoses, based on ICD-9 or SNOMED
• Maintain active medication list
• Maintain active medication allergy list
15
Furthermore the government requires EHR systems to:
• Record demographics (preferred language, insurance type,
gender, race, ethnicity, date of birth, date and cause of death in
the event of mortality)
• Record and chart changes in vital signs: height, weight, blood
pressure; calculate and display BMI; plot and display growth
chart, including BMI, for children from 2-20 years old.
16

Compliance also means providers must use technology to:
• Record smoking status for patients 13 years old or older
• Incorporate clinical laboratory test results in the EHR as
structured data
• Generate lists of patients by specific conditions
• Report hospital quality measures to CMS or to the states
• Implement five clinical decision support rules relevant to
specialty or high clinical priority, including for diagnostic test
ordering, along with the ability to track compliance with those
rules
• Submit claims electronically to public and private payers
17
In order for EHR systems to meet the specifications laid out for
category two, Engage Patients and Families in Their Health
Care, EHR systems
are expected to:
• Provide patients with an electronic copy of their health
information (including diagnostic test results, problem list,
medication
lists, allergies, discharge summary, procedures) upon request
• Provide patients with an electronic copy of their discharge

instructions at the time of discharge, upon request.
18
category three, Improve Care Coordination, EHR systems are
expected to:
• Electronically exchange key clinical information (problem list,
medication list, allergies, and diagnostic test results) among
care providers and patient-authorized entities
• Perform medication reconciliation at relevant encounters and
each transition of care
• Provide summary of care record for each transition of care and
referral
19
category four, Improve Population and Public Health, EHR
systems are
expected to have the capability to:
• Submit electronic data to immunization registries
• Provide electronic submission of reportable lab results (as

required by state or local law) to public health agencies.
• Provide electronic syndromic surveillance data to public
health agencies.
20
category five, Ensure Adequate Privacy and Security
Protections for Personal
Health Information, EHR systems are expected to protect
electronic health information created or maintained by the
certified
EHR technology through the implementation of appropriate
technical capabilities.
21
The Stage 2 and Stage 3 Meaningful Use requirements are not
officially defined as of 2011. However, according to the
Department of Health & Human Services, “we [can] expect that
stage two meaningful use requirements will include rigorous
expectations for health information exchange, including more
demanding requirements for e-prescribing and incorporating

structured laboratory results and the expectation that providers
will electronically transmit patient care summaries to support
transitions in care across unaffiliated providers, settings and
EHR systems.”
22
Startup costs include:
• New hardware and network components, including servers,
switches, cabling, racks
• Software components, including purchasing and licensing the
EHR product, along with any customization and support
contracts
and
• Interfaces, including laptops, workstations, PDAs, etc.
Bear in mind that licensing options vary and different licensing
options may be available for each product. As an example, a
single user license or tiered pricing (where the fees are different
depending on the level of access the user has to the system)
may be quite viable for a small practice. On the other hand, site

licensing (a single fee covering all potential employees for an
entity) may be a more viable option for larger entities but far
too costly for the smaller practice settings.
Maintenance costs include all costs associated with the
continued upkeep, maintenance, and upgrades to the system.
This
would include routine hardware replacement, software support
fees, licensing renewals, and major upgrades.
23
Training costs include fees incurred by the vendor to train new
system users and administrators during startup, as well as
training materials, simulators, etc., throughout the lifecycle of
the product.
What are the anticipated productivity costs associated with the
implementation of this product? Are the users going to have to
make significant changes in workflow resulting in substantial
loss in productivity?
Lastly, what consultants will you need to bring in to implement
the installation? Wireless and network upgrades may require
consultation to ensure optimal results. Will you be bringing in

an implementation specialist at $125/hour?
Be sure to consider these costs when selecting an EHR system.
24
This concludes System Selection – Software and Certification.
In summary, when choosing a system, be aware of broad
categories of systems available for selection. Weigh the
advantages
and disadvantages of them, paying special attention to the
required resources for development and maintenance.
Certification of
systems should be strongly considered. Finally, any system that
is considered and implemented should address the meaningful
use priorities.
25
No audio
26

No audio
27
No audio
28
Commons Attribution-NonCommercial-ShareAlike 3.0 Unported
license.
© Johns Hopkins University.
https://knowledge.amia.org/onc-ntdc/working-with-health-it-
systems-1.379705
This is component 14, unit 3. We will be discussing how
organizations select an Electronic Health Record (EHR),
Lessons from the
Frontlines. A tremendous amount of work is involved in

selecting an EHR. We can't cover all the topics today but we
will be discussing
four of the principle tasks involved in selecting an EHR.
1
This unit will prepare students to be able to:
1. Demonstrate concept knowledge of the request for proposal
(RFP) process
2. We will talk about stakeholders’ involvement, and their roles
in selecting an EHR
3. Then we will review the costs that needed to be calculated
when selecting an EHR, the capital, the maintenance and
staffing costs.
4. Lastly, we will discuss the importance of evaluating the
financial strength of each vendor being evaluated.
2
A request for a proposal, or RFP, is a document that is sent to
suppliers. It invites them to submit a proposal to provide goods
and
services. Remember that it's only to be used for complex
projects that require the vendor or supplier to be creative. Very
importantly it
assists with internal alignment. It's one of the best means to
force an organization to describe its needs before involving a
vendor.
Assembling the responses to the RFP helps an organization
compare vendors and understand potential project risks.
3

However, you need to remember that the RFP process is very
time consuming for both the purchaser and the vendor. And it is
always
difficult to accurately describe all the requirements and, and
even when you get all of the results in. Additionally, it's hard to
make the
comparisons and score responses.
4
What does an RFP include? It will include an overview of the
business issues, what are you trying to accomplish? It will
include a
description of the product or the services that you require. It
needs to detail all the business requirements. It requires specific
instructions on how the proposal will be formatted, when it will
be returned by the vendor, detailed instructions on how to select
the
vendors, what is the required timeline and many, many
questions and must include who to contact for the vendor if they
have any
questions.
5
In addition to RFP's, there are other request formats that could
be useful during your search for an Electronic Medical Record
(EMR).
There's a request for quotation, when you actually know exactly

what you want and you're looking to find out what the prices are
when
price is the main factor.
6
You can issue a request for information, which is used to find
out who's a potential seller of products and knowing the
capabilities of
those sellers in the market.
7
Before a request for proposal goes out, a request for
qualifications (RFQ), an RFQ could be issued to find out who
you would send the
RFP to.
8
HIMSS is an excellent source for sample RFP documents.
They're meant to act as tools used by health organizations and
other
healthcare providers in developing it’s own RFP. Remember
they're meant to be starting points for your RFP. The questions
and
requirements are meant to be illustrative and not exhaustive.
You cannot take an RFP from the HIMSS site and simply issue
it. It's
meant to help you get started in developing your own after

extensive meetings with stakeholders and detailed determination
of your
own specifications.
9
And remember that access to the sample RFP documents
requires active HIMSS membership.
10
As an example, I was able to find, on the HIMSS website, an
ambulatory EHR sample RFP. Remember, it's provided as a tool
for your
organization to use and develop its own RFP. It's a structured
approach to listing the various criteria that may be relevant in
the RFP
process. It's part of the series of documents that list the common
features and questions that need to be answered for enterprise
systems that are normally evaluated by an RFP but require
extensive editing by you and your organization. Now that we've
discussed
the RFP process, let's move on to stakeholders, another
important aspect of selecting an EHR.
11
Involving stakeholders is a crucial aspect of the project. The
notion of stakeholder dates back to a 1963 internal
memorandum at

Stanford, which defined stakeholders as quote, those groups
without whose support the organization would cease to exist,
close
quotes. It was later championed by Edward Freeman in the 80's
and gained wide acceptance in business practice.
12
Stakeholder theory is a theory of organizational management in
business ethics that talks about morals and values and managing
an
organization. Management needs to give due regard to the
interest of groups. Stakeholder theory addresses the principle of
who or
what really counts.
13
Every organization and every type of organization has its own
set of stakeholders. In addition, every project will have its own
stakeholders. In selecting an EHR, the project won't involve
everyone in the organization but it will involve many of the
principal
stakeholders. Here we list a set of stakeholders who may be
involved in an EHR selection process: physicians, nurses,
clerical staff,
lab staff, management, and you also need to remember your
product suppliers and even patients and the community as you
research
your needs to select an EHR. All of these groups should be
involved, at least at some level, in your discussions and in
developing

your detailed selection specifications. Knowing who to involve
is the first step. It’s important to know exactly how to engage
your
stakeholders.
14
One of the most important roles that stakeholders can play is to
help develop communication plans, which are targeted to the
specific
stakeholders involved. Using stakeholders to review all
communication is very important. They also know how to
develop the benefit
discussions and plans and track the benefits for their specific
groups. A stakeholder will also know the business processes
involved
and assist in developing a gap analysis between the current
situation and the desired outcome, which then is described as a
gap and
which will be filled by the new system. They will also help
develop policy and procedure changes. As business processes
change,
policy and procedures need to be adapted and specific
stakeholders will assist. Most importantly is their assistance in
developing
targeted lesson and learning plans for the specific groups.
Physicians will be trained differently than nurses, will be
trained differently
than clerical staff.
15

An important aspect of selecting an EHR is the determination of
the total project costs. I cannot understate how important it is to
do a
good job of determining project costs. Many projects fail due to
inadequate funding. There are several types of costs involved in
a
project. The first that will be dealt with is the capital costs.
These are onetime costs to set up the system, to purchase
products and
materials, and to hire consultants. It involves software,
hardware and labor. These can all be capitalized because they're
onetime
costs. Capitalized costs are amortized such that the recorded
cost of that asset is distributed over the estimated useful life of
the
system. Another aspect of the project cost is that of license. A
license is an official legal permission to use or own a specific
thing. It
principally applies to software projects and involves application
software and also the operating systems for the hardware on
which
the software products run.
16
After a project goes live, maintenance costs kick in. These are
the recurring operational or running costs of a system. It
includes labor
costs, license costs and various OTPS, other than personnel
costs. Maintenance costs for licenses typically incur about 15 to
20
percent costs annually. A very, very critical component of a
project is the staffing costs. You need to also remember to
include all the

costs of staff, including fringe benefits and other administrative
overhead costs such as desktop computers, laptops,
administrative
overhead, cell phones, travel costs, and training. Remember
adequate funding can make or break a project.
17
On this screen is a very detailed list of staffing costs and OTPS
costs that come from an actual ambulatory EHR project. This
project
was an enterprise scaled project with costs estimated to be 65
million dollars over 10 years. On the staff costs, at the top is,
physician
champion, application, coordinators, database administrators,
network support, trainers, go live support, help desk support
and at the
bottom, it includes the very important calculation of fringe
benefit for all the staff.
18
From the same project, on the OTPS side, is a full range of
costs from software license, and notice that it includes the
maintenance
cost. This was a 10-year cost projection for the project.
Implementation fees are estimated because it depends on the
actual number
of incurred hours. Contingencies are listed here and are a very
important component of project costing and include,
contingencies for
software, hardware, network, data center, consulting fees and

even desktop scanners.
19
An often-overlooked aspect of selecting an EHR is the
performance of a financial strength analysis of the involved
vendors. Many
companies supply credit information on businesses corporations
but Dunn & Bradstreet may be one of the most famous and in
fact a
colloquial term is to do a Dunn & Bradstreet on a company. But
available are other companies such as Experian, Equifax,
MarketWatch, InfoUSA and even Yahoo! Financial. On this
page is listed their websites. For a fee these companies perform
financial
strength analyses. It's an important aspect and should be
remembered that it needs to be done before signing a contract
with the
vendor. It’s not a onetime purchase of a product from a
company. Instead a very long relationship will be developed
with these
companies. You need to know how strong the financials are
since you don’t want to be purchasing an EHR system from a
company
that will go out of business.
20
In addition to hiring a company to do a financial strength
analysis, there are other steps that can be performed. Vendors
should be
willing to share an audited financial statement. This is a lot

easier with publicly traded companies because they're available
on their
website by law. But even a non public company should be
willing to share audited financials. It’s essential to review the
management
team. What is their tenure? What is their industry experience?
And importantly, what is the turnover in the company? How
long has
the management team been with the company? Does the
company turnover senior management almost annually? Does
the company
generate cash? This is known as liquidity. Cash is important in
all companies and helps during economic downturns so that they
are
able to continue to develop software and deliver services. In
addition it’s crucial to check references on companies. It will be
useful to
call on the phone and most importantly visit customer sites.
Talk directly with current users of the system and check
references
carefully. An often-overlooked step is to talk directly with the
CFO of any company before signing a contract. You can ask
very direct
and pointed questions about the company’s financial strength
and a CFO will answer those questions. We've gone through
several
aspects of selecting an EHR but by no means has this been an
exhaustive list of steps involved in selecting an EHR. These are
just
some of the most important steps and unfortunately too often
overlooked.
21

In this lecture, we have covered just a few of the most important
steps that an organization carries out when selecting an EHR.
First
and foremost, we talked about the value of the RFP. We
covered the importance of involving the key stakeholders.
Finances are
always critical so we discussed cost considerations, both capital
and operating. And finally, we reviewed the importance of
ascertaining the financial health of vendors involved in the
project.
22
No audio.
23
license.
systems-1.379705

Welcome to Installation and Maintenance of Health IT Systems.
Unit 4: Structured Systems Analysis and Design.
This component covers fundamentals of selection, installation,
and maintenance of typical Electronic Health Records (EHR)
systems.
This unit will discuss generalities about project management
along with the role of the project manager. It will also cover in
some
detail the various components of a typical project plan and how
to design a project plan for a typical EHR system.
1
The selection, installation, and adoption of a new health IT
system is a major undertaking, requiring the talents and
coordination of
many people in order to ensure success. Today’s lecture will
outline steps used in successfully managing such an undertaking
from
start to finish.
Objectives for this unit are to:
• Identify the 8 basic components to a project plan
• Define the role of a project manager
• Equate the basic project plan components to a typical EHR
implementation plan
• Create a project plan for system design and implementation
2

Project management can be defined as a carefully planned and
organized effort to accomplish a specific, and usually one-time,
objective.
There are several facets to successfully managing any project,
including:
• developing the plan and managing its implementation, along
with the various controls put into place to ensure that
performance is
sustained and that objective timelines can be adequately met;
• being able to adjust the plan for any errors or unforeseen
circumstances while ensuring the overall success of the project;
• and lastly, once the project implementation is complete, being
able to measure the success outcomes in relation to the project
expectations in some sort of quantifiable way.
3
A project is usually defined in phases. The number and types of
phases are solely dependent on the project at hand; however,
some
of the more common phases include:
• Determining feasibility: the process of determining if
undertaking the project will net beneficial outcomes for the
organization as a
whole?
• Definition, and determining the scope of the project: Who is
affected by this project…both directly or indirectly? Who will
be

involved with the project? What other factors are relevant to the
success of the project?
• The project planning phase: Developing a roadmap for project
success as well as tools for measuring that success when
completed.
• The project implementation phase: Actually DOING the work.
• Evaluation; and
• Support and maintenance: Determining the project’s net
benefit to the organization and putting in place processes to
ensure
longevity.
4
As this picture suggests, successful project management means
effectively balancing the components of time, cost, scope,
quality,
and expectations, each having a symbiotic relationship as
represented by the diamond shape in the center. This is referred
to in
project management circles as the “Project Diamond.” The
concept is quite simple: When a user requests an additional
report not
originally agreed on in the project specifications, the project's
scope and quality change, resulting in an imbalance and
skewing the
shape of the diamond unless changes in the remaining
components are made to bring the project back on track. We
refer to this
relationship as the “Project Diamond.”

5
Every project needs a someone who can lead the project from
start to finish: someone who is able to understand, relate to, and
coordinate between the project’s many facets.
This project manager is responsible for everything required to
ensure the project’s success, whether directly or indirectly.
It’s important to note that a project manager is NOT like a
typical hierarchical line management role. Rather, they can best
be viewed
as the center of everything relating to the project. Let’s look at
an illustration.
6
As you can see from this illustration, the project manager acts a
focal point where different aspects of the project come together.
The
project manager is responsible for coordinating project
activities as well as developing and maintaining the scope and
time table of the
project.
The four arrows represent the relationships between the project
manager and various groups typically associated with project
completion. It is not uncommon for the project manager to be in
both a supervisory position and at the same time subordinate to
stakeholders or upper management affiliated with the project.
The project manager must also be able to forge productive
relationships

with any internal and external elements such as other
departments and outside vendors or contractors of over which
he or she may
have no direct authority.
7
A project plan is basically a blueprint charting the entire
project’s expected progress from start to finish. A project plan
can contain as
little as a framework for the project or spell out every minute
detail– in other words, it can be either detailed or summarized –
as
needed to successfully manage the project itself.
A good project plan effectively balances all of the components
of scope, time, cost, quality, and outcome expectations while
minimizing costly errors, by adequately anticipating and
addressing problems early on which could negatively impact the
project’s
success.
8
A typical project plan formalizes the following:
• Agreements between the employer, the project team,
contractors and anyone else affiliated with the project
• The project’s primary purpose
• Organizational, institutional and project goals and objectives
as to their relationship to the project’s outcomes
• Scope and expectations
• Roles and responsibilities of Project staff/affiliates

• Assumptions and constraints
• Quality management approach
• Project management approach
and
• Policies and procedures that must be adhered to for the
project’s success.
9
Before beginning to write your final project plan, consider
performing a factor analysis. Factor analysis is “a disciplined
technique used
for investigating, analyzing, and understanding a project prior
to making any formal commitments.” A factor analysis allows
you to
consider all of the relevant system requirements and
environmental conditions necessary to ensure the project’s
success before
finalizing any commitments.
In other words, by examining where a project’s many variables
are interdependent upon one another, you will gain a better
understanding of the project’s importance as well as which
variables are most likely to hinder or help complete the project.
An example of one such factor to consider would be looking at
the client’s commitment level toward seeing the project to its
completion.
Another would be taking a look at your organization’s current
level of technology and determining its capabilities in relation
to the
project’s expected specifications.

10
When performing a factor analysis, there are at least ten areas
you should consider
1. Definition/Scope: Understanding the project’s primary
purpose as well as listing all of the major functions and
deliverables expected to complete the project is
very important. Likewise, by determining why the project was
created and what mission it fulfills within the organization is
crucial for determining the project’s
overall relevance and what support the project has.
2. Resources: A factor analysis attempts to identify all of the
necessary resources needed for the project’s success. This
includes monetary, technical, personnel,
or special materials needed.
3. Time: You should calculate the actual work time needed to
complete the project as well as the overall timeline.
4. Procedures: Most projects are subject to special polices and
procedures to ensure proper outcomes are realized. Here you
should catalog all of the relevant
organizational requirements as well as any regulatory policies
or mandates, financial reviews, special methodologies, or any
other requirements.
5. Environment: Explain the project's environmental factors that
may have spurred the project or could hinder its completion.
This could include geography,
culture, political environment, available technology, and so on.
6. Change: The factor analysis should take into account all

changes (procedural, policy, etc) that will be necessitated and
implemented because of the project and
any potential issues or risks associated with these changes. An
effective change management plan should then be developed to
adequately address these
issues.
7. Communications: A good communication strategy is key to
the success of a project. However, there are many factors such
as geographical location for
instance, that can inhibit this process. Determine the best
communication strategy for the project, considering any routine
meetings, reports, presentations, and
such needed to keep the project on track. Be sure to catalog any
foreseeable obsticles that will affect communication efforts and
plan accordingly.
8. Commitment: For a project to succeed it must gather
momentum and maintain a level of support from key proponents
capable of driving the project to
completion. Analyze and determine the degree of support for the
project from sponsors, users, and stakeholders. Are they willing
to commit to seeing the project
through to completion? What factors are currently driving
support for this project? Will those factors still be in play as the
project moves forward? What’s at stake
if the project is NOT completed?
9. Expectations: What positive outcomes can you expect from
completion of this project? What goal or objective will
completion of the project satisfy? To what
measurable degree?
10. Risk: Summarize any potential obstacles that will hinder
project completion. Additionally, take time to analyze the risks

associated with not completing the
project or portions of the project.
Completing the factor analysis will help you gain further insight
into the many different facets needing consideration and will go
a long way toward completing a
thorough project plan.
11
A typical project plan should have at least eight components,
each of which is essentially a work product resulting from
subtasks.
Introduction
The Introduction of the project plan should state the overall
purpose of the project. Ask yourself to define the mission you
are trying to
accomplish. The project description typically provides a short
statement about what the plan hopes to accomplish, as well as a
brief
background synopsis of how the project was originally derived.
What motivated, or demonstrated the need for, the project?
What
background history led up to this project being created?
Goals & Objectives:
A goal is a specific and desirable achievement that the
organization chooses as a focus in support of its overall
mission. Goals tend to
be long term while objectives, on the other hand, tend to be
short-term targets (typically 12-24 months or less) of defined,
measurable
achievement.

12
The expected project goals and objectives should be clearly
defined within the project plan. Reaffirm project objectives by
establishing the motives driving the project and determine how
completing the project will achieve specific aims for the
organization or
institution and its mission as a whole. Essentially you should
be able to identify the specific results to be realized and the
benefits to
be achieved, and establish a desirable and realistic time frame
for meeting the project objectives. A visible and reliable
method for
monitoring and measuring progress toward meeting these
objectives will also need to be devised.
13
Before we begin discussing scope, it’s important to note that, in
project management, there are two distinct definitions for
scope:
1. Project scope refers to the work needing to be accomplished
to deliver a product, service, or result with the specified
features and
functions as outlined.
2. Product scope can be defined as the features and functions
which characterize a product, service, or result.
Note that project scope defines a more work-oriented approach,
while product scope focuses on the functional requirements of a

deliverable. Defining the scope of a project is often neglected;
however, properly defining the scope in detail is critical to
properly
planning a schedule, budget and the needed resources to ensure
successful completion.
14
With that said, having clearly and concisely defined the scope
of a project is key to its success. The project scope should
describe,
from a quantitative perspective, what is to be accomplished.
Defining the scope aids in establishing realistic work plans,
budgets,
schedules, and expectations. Should identified work arise that
falls outside of the defined scope, it becomes the project
manager’s
responsibility to determine whether the additional work falls
out of the project’s scope and should be deferred, or whether
the scope
of the project should be expanded to include the work.
Expanding the project scope would mean making formal
changes to the work
plan, resource allocation, budget, and/or schedule.
Scope Definition
You will want to detail what work will be done and what
resources will be included in the project; we call this Scope
Definition. If the
project is part of a phased approach, it may include deliverables
from the previous stage and the scope may be characterized by
which objects will be further defined and developed. Focus on
the components identified within the project plan scope
definition.

Define the scope of the project by determining which criteria
constitute maintenance of the product. This will help prevent
the
occurrence of “scope creep”, a term that refers to the
incremental expansion of the scope of a project, as when
requirements are
introduced that were not part of the initial planning. Scope
creep is often due to inadequate planning or a failure to consult
all of the
stakeholder parties during the project’s initial stages, and it can
result in costly financial and scheduling overruns.
15
The deliverable scope of the project is a complete listing of the
products and/or other “deliverables” expected. These could
include
tangible items as well as specific results resulting from the
project’s completion. Every project plan should have a
deliverable scope.
It should Include a list of these deliverables often times with
more detailed explanations of each deliverable which may be
contained
within the project plan’s Appendix.
When writing a deliverable scope for a project plan be sure to
contain the following, for each deliverable:
• Name and a description
• Purpose behind creating the deliverable
• Major task(s) producing/updating the deliverable
• Expected audience
• Sign-off participants
Remember to include any project management deliverables,
including the project plan itself.

Milestones represent the timeline, or temporal scope, of the
project. Here you describe significant project accomplishments
that will
act as primary checkpoints marking the project’s progress.
These are generally points marking the completion of a specific
activity or
group of activities and resulting in a significant product or
result, such as equipment delivery, material delivery, review
meeting, or
approval checkpoint. Not every task completion date in the
project will be a milestone, but every milestone should be tied
to a
deliverable.
16
Include the estimated time of completion for each milestone.
Milestones are targets that should be met. If they are not met, it
is likely that the
project will not finish on time. Ensure that milestones are
clearly identified in the timeline and project plan.
16
Assumptions
Assumptions are necessary if we are going to make decisions
about the future. They help us fill the gaps where facts are
lacking but
are not always proven to be true. Use this section to describe
any assumptions made about the project or its completion
related to
items such as available resources, scope, expectations,

schedules, etc. Assumptions should be specific and measurable.
Be sure to
differentiate between assumptions made about the project and
real facts that can be proven.
For instance, when determining the project’s hiring budget you
can assume from the facts you are currently given whether or
not you
will be able to fully staff the project throughout it’s duration or
perhaps whether cut backs will be needed at a later phase of the
project
due to projected budgetary constraints.
Constraints
Describe and plan for any limitations under which the project
will need to be conducted, This could include any operational or
environmental parameters such as projected timeframes,
deadlines, available funding, staff skill levels, or resource
availability that
may or may not impede the project’s progress.
17
Related Projects
Other projects can be potentially impacted by your project as
well. Other projects may be dependent on deliverables
associated with
your project or your project may affect the parameters of other
projects. You should address these issues and ensure managers
of
these related projects should be kept in the communication loop
on all matters related to your project.
Critical Dependencies

Likewise, it is also essential that the critical dependencies
between related tasks and subtasks whether internal or external
to the
project be understood to ensure that tasks are sequenced
correctly so you can maximize efficiency and so that the project
can run
smoothly, minimalizing unwanted downtime.
Determine the relationship between work performed in a given
task or subtask with the work performed in other tasks or
subtasks.
Identify the predecessor and successor activities.
Identify any tasks within a related project on which this project
is dependent, and describe each relationship.
18
Quality management is the process of ensuring that the
project’s objectives, adequately meet expectations. Your project
plan should
identify and list the methods you plan to use to ensure your
deliverables are up to snuff and how that methodology aligns
appropriately
with any industry standards or regulations which must be
followed. This would include any project reviews or inspections
you plan to
conduct, along with any testing or test scripts and where in the
process each should occur to ensure quality guidelines are met.
You
should also define the specific and measurable standards used in
determining acceptable results.
Also list and describe any special tools, skills, and techniques
that will be needed on the project to perform the testing and
ensure

positive outcomes, including any specific hardware or software
packages. Some such packages would include project
management
software, measuring devices or testing software.
Lastly, define the specific quality management roles and
accompanying responsibilities that individuals will be assigned
to ensure
quality is adequately met on the project.
19
Project Management
Effective project administration is key to success. Ground rules
need to be set into place outlining acceptable standards for
providing
effective administration, communication, and project oversight.
Identify the administration policies agreed to by the project
team that govern the way in which the project will be
conducted. Such
standards include status reporting, staff meetings, product
review acceptance criteria, and celebration criteria. Describe
which
standards, if any, already exist within the organization and are
appropriate for the project. Such standards typically include
project
model management, technology, documentation management
and training techniques, naming conventions, quality assurance,
and
testing and validation. These may be standards that are
recognized and embraced as an industry standard or that are
specific to your
organization.

Define & describe the roles and responsibilities of each team
member, along with the overall communication plan to ensure
that team
members understand what is expected of them. Describe the
mechanism for communicating responsibilities across the
project team
and within the organization at large. Be sure to develop a
strategy that promotes communication among team members;
consider
using a directory of all team members and liaisons.
Identify how progress on the project will be determined and
how it will be communicated to those involved in or impacted
by the
project. Identify how often status reports will be distributed
and to whom. Determine how often progress meetings will be
held and
who is expected to attend.
20
Approvals
Unexpected situations and setbacks are bound to occur.
Likewise, project tasks need some sort of approval process to
ensure quality checks
have been sufficiently completed to move to the next phase It’s
important to develop an efficient approval strategy for
monitoring and moving the
process forward and can also anticipate and adequately address
any unexpected variations and modifications that become
necessary during
the project’s life cycle.

20
We have already discussed in detail the steps involved in
selecting an EHR system that’s right for your practice or
institution. Now
let’s review the steps for implementation as a whole.
Stage 1: Assessment
Your project team, represented by a variety of physicians, staff,
and stakeholders with the appropriate skills, is formed, and
regular
team meetings are conducted. These team meetings continue
throughout the six stages. The assessment stage helps prepare
for the
implementation by completing a “practice readiness
assessment”; this includes a profile of the organization in terms
of goals and
priorities, and an assessment of IT, healthcare, and business and
office personnel. A “hardware requirement analysis” is also
carried
out at this stage.
Step 2: Planning
The practice data collected from the previous stage is carefully
reviewed. Based on this, the electronic health records
implementation
goals are defined, and improvement opportunities are identified
and targeted.
Step 3: Selection
The EHR system's requirements are defined, including
configuration needs, and a selection process and details of the
goals that are
archieved based on the selection. The EHR system is also

selected in this stage.
21
Step 4: Implementation
Once the EHR selection has been made, a system
implementation plan is developed with the vendor, along with
timelines. The implementation
plan includes details on installing and configuring hardware and
EHR software. A plan for migrating any old data over to the
new system must
also be devised, including any necessary database conversions
in a manner that ensures data integrity. A staff training program
is initiated and
system testing follows. Then the staff begin to use the EHR
system. Throughout the process, a journal of experience and
processes is
maintained.
Step 5: Evaluation
A post-implementation review is conducted and the journal of
experience and processes is updated. The performance measures
created during
the planning phase are validated and an improvement plan is
prepared.
Step 6: Improvement
The EHR is then modified to resolve issues encountered during
the evaluation phase. Improvements are carried out as defined
in the
improvement plan.
Reference: http://www.binaryspectrum.com/Healthcare

Solution
s/ElectronicMedicalRecords/Roadmap-for-implementation-of-
EHRsystem-at-a-
practice.html
21
There are special concerns for implementing an EHR project in
smaller settings. First, it’s important to understand that
implementing
an EHR is a time consuming process that cannot be rushed.
Smaller practices are more often than not limited in their
resources,
creating additional pressures which can hinder EHR adoption
rates. Consider using a step by step approach for
implementation,
particularly after the EHR rollout begins; allowing time for
staff to become familiar with the new technology at their own
pace. For a
single physician practice you should expect the project to span

from 12-18 months at least from start to rollout; or longer for
practices
with multiple physicians.
Implementation of your EHR should be driven by the long term
goals you wish to achieve. You should begin by evaluating your
practice and looking for deficiencies or areas where
improvement can improve quality of care and efficiency.
Special areas to consider
could include coding, medication management, quality
improvement, patient satisfaction, and so on. There are many
goal setting
tools and resources available. MedQIC, an online goal-setting
tool hosted by the Centers for Medicare and Medicaid Services
is just
one such tool which may prove valuable but there are many
more.
Just like large practices, you should take care to include a
thorough workflow analysis, in your project plan, particularly
when it comes
to scheduling, triaging, patient registration, referral
management, visit documentation, orders, result management,
protocols,
treatment plans, clinical decision support, copayment capture,

claims processing, and billing. Other areas should be
considered as
well. Special consideration should also be given in office
environments where the transition to an EHR coincides with a
transition from
a paper tracking system to a paperless tracking system.
22
In a smaller practice, you will probably need to focus more on
up front and long term costs associated with choosing an EHR.
Establishing a budget early on will help guide you toward
selecting an appropriate EHR vendor. For instance, many
smaller practices
opt for a hosted EHR solution over an in-house solution, which
may help offset costs for maintenance and support of the EHR
infrastructure.
In smaller practices, building a PARTNERSHIP between your
practice and the EHR vendor is just as important if not more so.
You will
be more dependent on the vendor providing technical expertise
and even on-site support during and after the implementation

process
has begun. Choose a vendor that’s a good fit for your practice
and understands your goals and will work with you to develop a
project
plan that not only focuses on the technical requirements and
deliverables but also encompasses the project plan as a whole
including
time for analysis, staff training, and testing. Choosing a vendor
should not rest on cost analysis alone.
23
We’ve covered a lot of concepts in today’s lecture. Lets
summarize the important points:
Project management is the process of carefully planning and
organizing efforts for accomplishing a specific, and usually
one-time,
objective.
A project manager is directly responsible for activities of all
participants, tasks, & deliverables however, the project manager
may not

necessarily be the top level of the hierarchical management
structure.
Projects have major phases designed to move the project along
in a logical and timely progression
A factor analysis is often done before the project begins to help
determine scope resources and time needed to be successful.
24
A project plan is then developed and typically should have at
least eight components, each of which is essentially a work
product
resulting from subtasks. The project plan helps identify specific
details including workflow, teams, communication and
approvals
needed to ensure project success.
EHR project implementations follow similar patterns as many
other projects including six typical stages:
Assessment

Planning
Selection
Implementation
Evaluation
Improvement
Special considerations such as limited staffing and financial
resources should be considered when developing EHRs project
plans for
smaller practices.
That concludes today’s material. A lot of concepts were
covered, here so take additional time to digest these concepts
before moving
25
on to the next unit.
25

No audio.
26
No audio.
27
license.
systems-1.379705

This is Component 14 Unit 8: EHR go-live strategies.
1
At the end of this lecture, you will be able to evaluate training
and go-live strategies in terms of impact on cost and workflow.
More specifically, by the end of this unit, you will be able to
Describe characteristics of training and go-live strategies that
would facilitate implementation of a new Electronic Health
Record
(EHR) system.
Compare the advantages and disadvantages of a big-bang roll-
out versus a phased roll-out and vice-versa.
Identify staffing, command center and consultant considerations
Compare strategies for monitoring systems and change
management during the immediate post go-live period.
2

One of the first project decisions that have to be made is
whether to rollout the system in a big bang or a phased
approach. When
referring to big bang or phased, we are mostly referring to the
software modules or main application functions. However, with
the big
bang approach, you still have implementation choices. You
could rollout all modules in selected locations or all modules in
all
locations. This big bang approach is usually used when
replacing a legacy system. It would be difficult to have two
systems running at
the same time. In the phased or incremental rollout, selected
modules are implemented. Again, you have the choice of
selected
modules in all locations, selected modules in some locations or
a combination of both.
3
There are pros and cons to both the big bang and the phased
rollout approaches. Let's talk about big bang. The pros for doing

the big
bang rollout are a short-term disruption and there will be no
need to link the old and the new system. Since the old legacy
system will
not be running during the go-live, it will not require support.
On the other hand, the rollout will demand much more
organization. It
absolutely requires comprehensive planning and all the users
will need to be trained and ready to go at the same time. This
can be a
massive undertaking.
4
So, what are the pros and cons of the phased or incremental
rollout? The benefit of this approach is that it allows you to
progressively
adjust your strategy during implementation. Your planning can
be more focused. Any disruptions will be isolated to only those
locations and those modules involved. As a result, smaller
groups of users are affected during the rollout. Against this
approach is the
need to maintain two systems: both the new and the old or

legacy systems. There is a danger that the project will stall or
stagnate. In
addition, obstacles will be found which may cause groups to
think about not continuing with the implementation. It will be
necessary
to correlate information from both systems for management
reporting. Furthermore, detailed business operations will have
to be
extracted from both systems simultaneously.
5
The staffing required for implementing and maintaining an EHR
depend on many factors. For example, you need to consider the
product being implemented, the location (whether hospital,
inpatient or physician office), whether the implementation will
be formed by
the vendor or consultants and if it is a big bang or a phased
rollout. All of these factors will greatly determine the required
staffing.
From a technical standpoint, if the application is hosted locally,
that would require a much larger team versus hosted remotely
by a

vendor. In addition, you will have to determine temporary
staffing during implementation, actual go-live support, and the
permanent
staffing once the project is fully functioning.
6
In Unit 3, we reviewed an example EHR implementation cost
profile including staffing requirements. Here, we have the same
list of
personnel including physician champion, application
coordinators, database designers, third party reporting, two
administrators,
programmers, security analysts, work station management staff,
trainers, go-live support, and chief privacy officer, just to name
a few.
7
An important component of an EHR go-live is the command
center. This is a special location set up during implementation.

While
command centers can exist in the phased or incremental rollout,
they are more typical of big bang rollouts. All project
communications
go through the command center. It serves as the project's help
desk and all user calls are routed to the command center. Field
staff
meets at the command center usually at the beginning and end
of each day to report and get project updates. Moreover, project
executives meet together at the command center to take the
pulse of the project and to make immediate necessary decisions.
8
Onsite consultants can play many important roles in an EHR
project. Staff is needed during implementation and during the
go-live
period; but not needed during the maintenance phase. For
example, consultants can assist with EHR selection; develop
processes
during implementation, work on meaningful use criteria, assist
in EHR review of existing projects and direct training and
certification

processes.
9
A very important task to be formed during the rollout is
monitoring system usage. As the system gains users, increases
functionality
and takes on heavier loads, it is critically important to watch all
system health indicators. The operating system, disk space and
application usage need to be monitored. Each day requires a
tally of the number of documents created, orders written, orders
completed and prescriptions written. It is also important to
monitor the count of calls coming into the help desk. Some
concerns could
be: Are there system issues? Are there logon issues? Are there
application questions? Monitoring all of this will help detect
early on
whether the system has some issues. A lot will be learned from
performing these tasks.
10

A lot goes on during the implementation of an EHR. There is a
significant amount of change that occurs. While organizational
change
is a fascinating topic, where organizations evolved to different
levels in their lifecycle, here we will be specifically talking
about system
change. This typically refers to information systems or other
process changes in an organization.
11
An important aspect to the system change is the management of
changes. If a formal change management system is typically
instituted immediately post go-live, a structured approach to
transition individuals, teams and organizations from a current
state to a
desired future state is needed. Changes are implemented in a
controlled manner by following a very well defined framework
managing all modifications.
12

During implementation and go-live, changes are usually made
on the fly and that is okay. However, during post go-live, when
the
system is stable, it is very important to follow the formal
processes of change control. This ensures that changes are
introduced in a
controlled and coordinated manner. This is done to reduce the
possibility that an unnecessary and harmful change is
introduced;
thereby, creating defects in the system. The goals are to
minimize disruption, to reduce having to back out changes, and
to utilize
resources in a very cost effective manner.
13
Change control management consists of the following steps:
recording and classifying each requested change, assessing all
aspects
of the change, planning for the change, building and testing
every aspect of the system including the parts that no one thinks

will be
affected by the change, implementing the change, closing it out
and gaining acceptance from all users.
14
In this lecture, we have covered just a few of the most important
go-live strategies. We talked about big bang versus phased
rollout.
We talked about staffing, command centers, use of consultants
and change management. These are just a few of the very
important
aspects of go-live strategies that have to be considered during
the implementation of an EHR in both the inpatient and
ambulatory
settings.
15
No audio

16
license.
systems-1.379705
Software Development Life Cycle. This component Installation
and Maintenance of Health IT Systems covers fundamentals of
selection, installation, and maintenance of typical Electronic
Health
Records (EHR) systems.

This unit, Software Development Lifecycle, will discuss
methods for planning for the creation, development,
implementation, and
eventual phase-out of software packages using various Software
Development Life Cycle Models.
1
The Objectives for this unit are to:
1. Define the steps of the Software Development Life Cycle, or
SDLC, and the purpose and importance of each.
2. Describe different models of the SDLC and their key
differences.
3. Describe how and why an HIT software application would go
through the SDLC.
The SDLC is a well-developed concept from the IT world that
promotes an organized, long-term view of the software you’re
working
with, from its “birth” to its “death” (hence the term “lifecycle”).
It’s important for those who work in healthcare IT to understand

this model and apply it when appropriate. This will be crucial if
you
work in an institution that chooses to build its own EHR
components. But even if your institution lets a commercial
vendor make all the
changes to the software, it will be helpful to understand the
conceptual phases they are using … particularly since your
institution’s
success will be dependent on the outcome.
We’ll start by describing the SDLC and its importance, then
we’ll discuss the conceptual phases of the lifecycle. Then we’ll
look at
three different models – the waterfall, iterative, and spiral
models – that illustrate different views of the relationships
between the
phases. Then we’ll go through an example of the SDLC in
practice. Finally, we’ll close with more remarks about the role
of the SDLC
in EHR systems.
2

The SDLC is a term used for modeling a detailed plan for the
creation, development, implementation and eventual phase-out
of a
software or software system package. It’s a complete plan
outlining how the software will be born, raised, and eventually
retired from
its function.
Many different SDLC models exist. Each of these models was
designed to fit a specific business needs model, to accommodate
available resources and skills, or to take advantage of a specific
programming language or toolset that would be used.
Usually, these models can be divided into two categories - the
waterfall model and the iterative model - each employing a
different
workflow philosophy.
3
So why is SDLC important, anyway? Well, as computers and
software became integrated into the business environment and
businesses became more dependent on computers not only to

manage their business data, but also to assist or track every
aspect of
the workflow process, it became increasingly apparent that poor
design, or failure, of software can be quite costly in terms of
lost
productivity. Additionally, poorly designed software can
increase security risks and decrease data integrity. Replacement
of outdated
or inadequate software can cost many thousands of dollars.
Therefore SDLC was designed to control the development
environment to help ensure that developers produce a high
quality system
that meets or exceeds their customer expectations, is completed
within time and cost estimates, works effectively within the
designed
infrastructure, and is inexpensive to maintain and cost-effective.
4
Factors for developing a successful SDLC are not unlike those
already discussed in previous units for developing your
successful

project plan or for selecting your EHR system. Again, these
factors are not steps in your SDLC; rather, they are elements
that will
dictate whether the SDLC will be followed, which in turn
assures the success of the program being developed.
1. Management support - Developers need to have the support
of the management as much as possible, since management will
dictate the business need, budgeting, and top-level buy-in for
the product.
2. Technical and business expertise – As in any field, there are
experts (in this case, programmers) who just know what needs
to
be accomplished even when the objective is originally
presented. These programmers know which SDLC model is most
appropriate for the programming language or toolkits that need
to be utilized to ensure the software project will be successful.
Likewise, business experts are also critical in the software
development cycle, since they understand the overall demand
and
needed functionality for a particular software. Additionally,
business experts can help determine whether the software will
eventually show any cost savings over other products or
processes.

3. Determining the product focal points - Some parts of the
program should be rated a higher priority than other parts.
Choosing
which elements are most important will allow developers to
make decisions when issues arise which may compromise the
software’s overall functionality, ensuring that there will always
be some strong selling points in the developed software
compared
to a product that provides only mediocre service.
5
4. Follow well-defined procedures - Developers should have a
clear understanding of goals at each phase, along with the
methods and
accepted tolerances for evaluating each of the goals.
5. Develop proper documentation for maintenance – Developing
good documentation will help with the implementation and
continued
success of the product throughout its entire life cycle.

5
Now let’s take a brief look at how these phases can relate to
each other, initially using the so-called “Waterfall” model.
The initial assessment of feasibility is followed by an analysis
phase, which is followed by the design phase, which is followed
by the
implementation phase, then the testing phase, then the
maintenance phase.
6
Contrast that with this “iterative” or “incremental” model,
which starts with initial planning and research. Then begins a
cycle --
consisting of planning, requirements, analysis and design,
implementation, testing, and evaluation -- which repeats as
needed until
the decision is made to do deployment.

We’ll discuss the models in more detail at the end of this Unit.
Now let’s discuss what each phase generally entails.
7
Initiation
In the software vendor world, where profits are realized by
fulfilling consumer market needs with new software products,
initiation is
where a need is identified for a new software system. Software
development companies use this stage to determine the needs of
the
present market. The software vendor’s management is often
involved in this stage as they want to determine what the
developers
have to do and how it will impact the market.
In a clinic or other healthcare institution, this need is usually
identified by clinicians or staff such as a flawed workflow
process or other
issue.
For instance, a healthcare clinic currently uses three different

programs to record patient data, dispense online prescriptions,
and run
the business office, requiring a lot of work overlap and
generation of paper documentation between systems. Both the
physicians and
the billing department are looking for a more efficient way to
communicate and improve efficiency. They would like a system
that can
communicate seamlessly between the various business
components and streamline operations.
A Project Manager typically would be assigned and would
eventually generate a Concept Proposal – a document which
identifies the
problem and why the new system needs to be pursued. Upper
management would then review the proposal and approve it, and
the
project moves on to the next phase.
8
The Concept Development phase begins when the Concept
Proposal has been formally approved but when additional study

Working with Health IT Systems is available under a Creative C.docx

Working with Health IT Systems is available under a Creative C.docx

Recommended

Recommended

More Related Content

Similar to Working with Health IT Systems is available under a Creative C.docx

Similar to Working with Health IT Systems is available under a Creative C.docx (20)

More from helzerpatrina

More from helzerpatrina (20)

Recently uploaded

Recently uploaded (20)

Working with Health IT Systems is available under a Creative C.docx