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

and
analysis are required prior to system development activities.
We begin to analyze what will be necessary to complete the
project. Here all relevant factors are analyzed to develop the
project
scope.
Several reports can be created here:
• Feasibility Study; in other words, will it work?
• Cost/Benefit Analysis; in other words, is the cost really worth
it?
• System Boundary; in other words, how far should the project
go?
• Risk Management; in other words, what will happen if we
don’t do it?
These reports are then presented to the powers that be, and a
decision is made whether or not to go ahead. They approve the
funding. If they give their approval, it’s on to the next phase.
9

During the Planning phase, we determine who is doing what,
when, and how, along with the personnel and other resources
that will
be needed to complete the project. For instance, should we use
existing personnel or hire consultants? During this phase we
determine what developmental resources will be required to
create the specific software.
Other questions are also contemplated during this phase:
• Should we develop in-house software, or buy it off the shelf?
• What are the “deliverables” – such as completed software
programming and documentation, user manual, training, testing
plans,
etc.?
Finally, a planning document is submitted to management for
approval.
10
The Requirements Analysis Phase focuses on what the system
will do, in an effort that considers all stakeholders, including

sponsors and potential users, as important sources of
information.
During this phase you will determine what Operating System, or
OS, and interfaces are required; e.g., will it run with Windows
or
LINUX? Here you will answer a number of other questions as
well: What functionality will be required? Should it be run with
the
mouse, keyboard, or touchscreen input? How much training will
be required of the user? Will a new room be needed for the
hardware
that runs the system?
There are a variety of techniques that can be used to gather the
requirements, but some key points to remember are that the
requirements must be systematic, verifiable, related to
identified business needs or opportunities, and defined to a
level of detail
sufficient for system design.
Once the requirements documentation is approved, the project
moves on to the design phase.
11

The Design Phase takes those requirements and develops a
detailed blueprint outlining the software specifications. Here,
the
program architecture, which defines the various software
components, along with their interfaces and behaviors, is
established.
The design phase is also where much of the program
documentation begins to take shape, including the Maintenance
Manual,
Operations Manual, and Training Manual.
Flaws in the original planning, which require some adjustment,
are often revealed during the design phase.
12
The system is built during the development phase. This includes
source-code files, header files, make files, and binaries.

This is where everything is coded and assembled, and the actual
design of the system is realized as “living, breathing” software.
This
process is usually a team effort with its own set of sub-goals
and milestones, involving many software developers who
coordinate their
efforts to realize a final product.
13
Integration and testing of the entire system is a formal,
documented testing procedure, which ensures that the system
performs as
designed.
Testing the roll-out of the system also begins, including
migration of existing data into the new system, as well as
usability.
Usually, the system is rolled-out over a weekend so that if
anything goes wrong, the old system is still active and
available.

Integration and testing is a critical step. If the software fails
testing, it cannot be trusted to work.
Approval of testing and test results is necessary before the
project moves into the next phase: implementation.
14
Now that the software has been formally tested and passed, it is
time for distribution to the production environment. In this
implementation phase, user training takes place, previous data
is migrated, and the system is brought online.
After the system “goes live”, it is once again tested and data is
collected to determine if it is working to specifications. This
process is
often referred to as a “debriefing”. It is also where any
problems that were not crucial to the implementation can be
addressed and any
necessary changes to the system documented for future
versions.
15

The Operations & Maintenance Phase is the day-to-day
operation of the software after deployment. The software must
be
maintained, patched, and regularly updated to ensure long,
reliable life. Upgrades can be tested and deployed to improve
functionality.
16
Every software application eventually becomes obsolete.
Perhaps a new system is being developed, or this system cannot
keep up.
Whatever the reason, disposition involves more than just
shutting off the server. Often, the system may be kept going due
to
regulatory requirements or because there are still projects using
it. Sometimes there is data on board that must be kept safe and
secure even after its useful life is over.

Software disposition needs to be planned to ensure that you
meet all regulatory requirements and ensure a smooth transition
to
whatever the replacement product will be. A disposition plan
must be developed which may outline everything from the
dismantling of
the software itself, to the safe and secure disposal of old
hardware and data, to archiving of documentation.
17
As briefly shown and discussed earlier in this presentation,
many different SDLC models exist. Each of these models was
designed to
fit specific business needs, to accommodate available resources
and skills, or to work with a specific programming language or
toolkit.
Usually, these models are divided into two categories, the
Waterfall Model and the Iterative model, each of which employs
a different
workflow philosophy.

18
The waterfall model uses more traditional planning, testing and
implementation techniques to design and implement new
software
products. This model promotes strong documentation of each
step of the development process.
The waterfall SDLC model represents a sequential development
process, where progress is seen as flowing steadily downwards
through each of the phases of development.
Winston W. Royce has been given credit for formalizing the
waterfall model in an article around 1970, where he presented
this
modeling concept as flawed from a software development
standpoint.
The waterfall development model is actually a product of the
manufacturing and development industries where making after-
the-fact
changes is often prohibitively costly. Therefore progression to
the next phase of development does not typically commence

until the
previous phase has been perfected and ”locked down.”
Many have criticized the waterfall model, citing that it is
difficult, if not impossible, to finish a phase of a software
product’s lifecycle
perfectly before progressing forward to the next stage. To that
end, several variations of the waterfall model have been created
to help
address some of these issues.
19
This diagram, which I described on an earlier slide, depicts just
one of the many variations of the waterfall model employed by
developers. As this variation of the waterfall model suggests,
the waterfall model can best be described as a sequential
software
development process whose workflow progresses in a linear,
downward fashion, just like a waterfall flows.
20

Using a waterfall methodology is most likely to be successful
when the complexity of the system is low and requirements are
static,
but there is little room for mistakes and no process for
correcting errors after the final requirements are released.
Feedback can be quite limited when using this approach. And,
as I mentioned previously, most believe it is nearly impossible
to finish
a phase of a software product’s lifecycle perfectly before
progressing forward to the next stage.
21
Iterative and Incremental model:
These models were developed in response to identified
weaknesses of the waterfall model and often considered cyclical
in nature.
One variation of the iterative model is the Spiral model, which
we will look at after we see a more basic Iterative model.

This approach works well in environments where perceived
requirements are subject to change as the project progresses or
where
more feedback is warranted.
Let’s take another look at the illustration.
22
As you can see from this diagram, which I described earlier in
the presentation, in iterative models, the phases of software
development take on a more cyclical nature.
It starts with an initial planning phase and ends with
deployment, with the cyclic interactions in between, or even
after the initial
deployment occurs. With this model, several deployment cycles
of the product are possible as the software becomes further
refined,
analyzed, and tested, and as new enhancements are added.
23

Another variation of the cyclical model is the spiral lifecycle
(or spiral development) model used in IT. This model combines
the
features of another model, called the prototyping model, with
those of the waterfall model. The spiral model is intended for
large,
expensive, and complicated projects where client
responsiveness is a significant issue.
In this model, one or several prototypes may be created
throughout the lifecycle. At each iteration, the prototype is
tested and further
input is gathered until all concerns have been adequately
addressed.
Let’s walk through the diagram. The action begins in the center
of the spiral, with initiation, and then cycles repeatedly through
four
conceptual quadrants: Identify, Design, Construct, and
Evaluate. The first cycle contains the phases Concept and Risk
Analysis. Later
cycles contain the phases Implementation, Testing, and
Delivery.

24
As you can see, the SDLC is very similar to a project plan, but
it integrates several software-specific aspects into the planning
infrastructure to specifically address the concerns associated
with developing and deploying a new software system.
However, you
should consider an SDLC as augmenting your overall EHR
project plan, not replacing it.
Employing SDLC in your environment, when developing a new
EHR system or designing changes to an existing system, is
crucial to
ensuring that your new software, whether developed in-house or
purchased off the shelf, adequately meets expectations while
mitigating overall risk to the organization.
25
Now let’s discuss a scenario in which EHR installation utilizes

SDLC principles.
Sunny Happy Care (SHC) Clinic, a small primary care practice,
wants to upgrade their paper records to an EHR system. Before
purchasing and deploying, they do extensive planning, including
evaluation of their requirements and analysis of market options.
They
ultimately select and implement a commercial EHR.
26
You’ll have recognized those actions by the clinic staff as
several of the general steps in the SDLC. The fact that they are
specifically
following an iterative SDLC model in their deployment soon
becomes clear. According to the project plan, the business
manager has
been assigned to test and evaluate the EHR after go-live. In her
analysis, she determines that the SHC clinic staff is spending
excessive time manually entering laboratory data, since a
laboratory integration module was not part of the initial
purchase. Thus the
staff enters a new cycle of planning, requirement-gathering, &

analysis of vendor options, leading to purchase & deployment of
a
laboratory module. Subsequent re-testing & re-evaluation of the
EHR now shows satisfactory improvement in staff effort &
availability
of lab data.
27
This concludes our unit on the Software Development Life
Cycle.
In summary, the SDLC is a set of steps that were codified by
the software development industry but are useful in executing
many
types of projects. Common steps include concept development,
planning, requirements analysis, design, development,
integration &
testing, implementation, and operations & maintenance.
The relationships between these steps have been formulated into
different models based on different needs. The waterfall is one
such

prominent model, and it emphasizes steady progress through the
steps and careful completion of each before moving on. The
iterative, or incremental, is another prominent model, and it
emphasizes iterations, in which the steps are repeated in a cycle
of
improvement. It has variations such as the spiral.
The SDLC is useful for EHRs, and its steps should be carefully
considered whether one is creating a new EHR or deploying a
purchased EHR, in order to maximize the success of the project.
28
No audio.
29
IT Project Management
In this course, we only introduce project management, but the
main

concepts are covered. In order to be a good project manager,
you
should specialize in this area. Project management certificates
are
offered by universities such as UMUC, and there is at least one
recognized certification authority—the Project Management
Institute
(PMI). PMI evaluates both your experience as well as your
knowledge
before a certification is awarded. So, you can see that project
management cannot really be learned from a book or a class, but
from
those combined with experience in the "real world."
A couple of definitions with which you should be familiar are:
product, service, or result
tion of knowledge, skills,
tools, and techniques to project activities to meet project

requirements.
What is the role of a project manager? Is it different for an IT
project
manager? A project manager must control the four key variables
associated with any project: time (schedule), resources (human
and
financial), scope of work, and quality. The project manager
leads the
development of a project plan that takes all of these into
consideration. Frequently, trade-offs are required. For instance,
the
budget may be limited, which restricts the scope of the work
and
perhaps how many people can work on the project. Or, the
project is
needed within a certain time frame, which may drive the costs
up,
since more people would have to be hired to complete the
project on

time. When any one of the four variables changes, there is an
impact
on at least one (and often more than one) other variable. A
strong
project manager pays close attention to the project plan and the
progress of the project against the plan, and manages the
variables
appropriately to ensure successful completion of the project.
Successful completion is accomplished if the project is
delivered on
time, stays within the allocated budget, performs the required
functions, and does so correctly. This role is the same for any
project
manager, including an IT project manager.
The four variables are interdependent. You cannot change one
without affecting the others. For example,

either increasing the
cost of the project or decreasing the scope of the project to meet
the new deadline.
project's time frame or increasing the project's cost—or both—
to meet the increased scope changes.
necessitate a reevaluation of the scope and/or the quality. The
scope may need to be reduced to avoid decreasing the quality,
or if the scope must remain unchanged, quality will suffer.
time and money to incorporate more perfection and test all
possible outcomes for correctness.
Project management is the science of making intelligent trade-
offs
among time, cost, scope, and quality. This is the job of the

project
manager. As things change, the project manager must adjust the
four
variables to keep them in balance.
The first step is the selection of strategic projects. Now, the
project
manager does not select the projects alone; usually that is done
by
senior management after the presentation of a "business case"
that
outlines the project plan, stating the objectives (how the project
supports the corporate strategy), cost, schedule, functionality,
and risk
associated with the proposed project. Once senior management
allocates resources, the project manager ensures the project plan
is
executed according to plan. A smart project manager makes sure
that
his or her plan has "SMART" criteria – useful reminders on how
to

ensure that the project has created understandable and
measurable
objectives:
These objectives are documented in the project plan, used
throughout
the project's life to help keep the project on track to a
successful
completion. The project manager monitors progress against the
plan
and manages any changes and mitigates risks as they become
known.
Project risk management involves identifying potential events
or

conditions that could have a negative effect on the project,
estimating
the impact if the risk occurs, determining a mitigation strategy
to
reduce the likelihood of the risk occurring, and identifying what
will be
done if the event or condition actually arises.
Since almost no project goes exactly according to the plan, the
project
manager needs a tool to detect and manage the changes. The
process
of change management is this tool. The project manager
documents
all approved changes, revises the project plan accordingly, and
then
continues managing and monitoring the project.
Keep in mind that the job of the project manager is to stay on

top of
all the variables and manage the cost, schedule (time), scope
and
quality. He or she must seek additional resources (money or
people)
or a schedule change (time) when the scope increases, and must
be
able to articulate the effect on quality if additional resources or
a
schedule change are not authorized. The project manager is
responsible to senior leaders to monitor the variables, keep
leadership
informed, and propose solutions for changes as they occur.
license.

systems-1.379705
Welcome to Introduction to Project Management: An Overview
of Health IT
Projects. This is Lecture a.
1
The Objectives for An Overview of Health IT Projects are to:
•Review the history of project management.
•Define what a project is.
•Define project management.

•Identify reasons that more organizations are implementing HIT
projects.
•Identify key characteristics for project success and failure.
•Describe the range and characteristics of health IT projects.
For Lecture a we will focus on all of the objectives.
2
This unit will provide you with a high-level overview of health
IT projects.
Here is a brief history of project management. Project
management can be traced to early
civilizations, including the Egyptian pyramids and the Great
Wall of China. The year 1910
brought the Gantt chart, a project management tool still in use
today. Project management
was first considered an isolated concept in 1954.
The latter part of the 1950s saw great strides in the development
of project management
concepts and techniques. After the Soviet Union launched

Sputnik in 1957 and with it, the
Space Race of the Cold War between the United States and the
Soviet Union, the US
Department of Defense focused greater resources toward
strengthening its space and
defense project procedures. In the same year, the U.S. Navy
created the Program
Evaluation and Review Technique, or PERT, to help manage its
Polaris missile submarine
program. Around the same time, the DuPont corporation
developed its Critical Path
Method, usually referred to as CPM, as a project management
tool for scheduling various
processes or activities. Eventually, PERT was adapted to
employ a work breakdown
structure, or WBS), which we discuss in other units of this
course. Private enterprises
began to adapt some of these methods.
One of the most important guiding techniques to specify how a
project should be
managed is the Project Management Body of Knowledge or
PMBOK, created by PMI in
the late 1980s. The techniques outlined in the PMBOK
standardize the practices of the
development team, which makes it easier to predict, manage,

and track projects. The
2000s brought the development of the agile alliance, along with
an update of the PMBOK
into its fourth edition.
The multi-project company environment of today requires more
flexible and cyclical models
than the critical chain models used in the past. Many of the
critical chain-oriented project
management techniques, which focus on the resources required
to complete project tasks,
are aimed at very large scale, one-time, non-routine projects,
and are unnecessarily
complex and costly for smaller projects. Modern project
management, however, includes all
kinds of projects and all kinds of management models and
techniques.
3
The PMI PMBOK defines a project as, “a temporary endeavor
undertaken to create
a unique product or service.” You can consider a project
complete when its goals

have been reached, and you can consider a project terminated
when its goals can
no longer be reached for any reason or the project is no longer
necessary.
4
As a professional area of knowledge, project management
provides a methodology
for preparing, coordinating, and supervising people, supplies,
and processes, from
project initiation to closure, to achieve definite targets. While
its scope is broad
enough to apply to complicated, multifaceted concerns such as
software
development, the techniques of project management are
appropriate to for any
project.
5

Project management helps organizations achieve specific goals,
use resources
effectively and efficiently, and typically provides feedback or
information that will
impact future decision making. It helps an organization build a
culture of execution
and collaboration and achieve desired results reliably. Project
management can also
provide timely and accurate data that informs business decisions
to maintain a
competitive edge. Finally, project management ultimately
increases productivity and
enthusiasm among employees by developing and implementing
effective
communication processes.
6
Because project management has such a broad scope, the
literature on the topic is
equally vast. We can study it in general terms as it is applied
across domains, or we
can drill down as our projects become more narrowly focused

on such areas as IT
projects, or even more specialized, IT projects in health care.
Each of these professional arenas foster communities of practice
that include
professional associations, publications, and meetings. Many are
broad and/or
influential enough to cultivate their own special interest groups
or sponsor industry
standards and guidelines.
The IT field offers such professional organizations as the
Association for Computing
Machinery and the Institute of Electrical and Electronic
Engineers, better known as
IEEE. Professional resources for the specific area of health IT
can be found at
associations like Health Information Management Systems
Society, the American
Health Information Management Association, and the American
Medical Informatics
Association.
The Project Management Institute, or PMI, is also a great
source of information on

project management. Along with its PMBOK guide, it offers a
PMI health care
special interest group.
7
Like any professional area of knowledge, project management
comes with its own
vocabulary and concepts. The first term you will need to
understand is scope.
Scope defines the boundaries of a project, such as schedule,
financial resources,
objectives, and staff.
“Scope creep,” refers to the tendency of most projects to shift
boundaries as the
project moves forward, and professionals often use the term,
“gold plating,” when
they speak of adding needless details to a project. Keeping a
watchful eye and a
firm hand on your project scope will help you avoid such
project roadblocks as
scope creep and gold plating.
Scope is considered one of the recognized project constraints,

which also include
schedule and funding.
Project risk refers to those factors that may delay or obstruct a
project’s completion.
Part of a project manager’s job is to plan for and reduce the
amount of risk to a
project.
Another primary part of your job focuses on communications.
No project can run
smoothly if expectations, responsibilities, objectives, and
timelines are not clearly
understood by all stakeholders, or those who are invested in
your project.
Stakeholders can include team staff, clients, or consultants. As
a project manager,
you may find yourself communicating with these stakeholders
though a number of
different media, including hardcopy documents, email, or
project websites.
Finally, the term, “deliverables,” refers to the project’s final
product or results – the
outcome that you “deliver” upon completion of the project.
8

The five process stages of project management include the
following:
•Initiation,
•Planning,
•Implementation,
•Monitoring and Controlling, and
•Closing.
The initiation stage covers all the processes that define the
project’s scope,
objectives, and environment. Once the manager develops a
comprehensive grasp
of these details, he or she can begin the planning stage. This
stage focuses on
developing a schedule and budget, identifying necessary staff,
resources, and
supplies, and preparing for potential risks – all of this work is
captured in the project

plan. During the implementation stage, the manager will target
the project’s staff,
process, activities, and resources toward the project objectives.
The monitoring and
controlling stage includes supervising this entire execution,
while constantly
reviewing the current outcomes against the project plan and
defined baselines, and
controlling for risk. Finally, the manager presents the final
deliverable for client
acceptance or approval during the closing stage, while
finalizing the project
processes and activities.
9
Why use process? A defined process technique is not an
assembly line of
automated steps. Rather, it provides structure, consistency, clear
communication,
and efficiency controls that improve the way you and your team
work. It also
minimizes risk and eliminates problems.

10
11
The literature on project management offers many approaches,
or project life
cycles, to the work. Based on certain project details, such as
project scope,
complexity, outcomes, and timelines, the project manager
decides which life cycle
best suits a project.
This unit provides a basic overview of project life cycles, but
you will receive more
in-depth information on various project approaches in later
units. For now, briefly,
project life cycles include a linear method, which is typically
best applied to large,
complex projects, while iterative and adaptive methods are more
appropriate for

rapid application development or projects that occur over short
periods of time and
require high levels of prototype development, feedback,
modification, and redelivery.
Agile techniques are best used in small-scale projects or on
elements of a broader
project that require a quick turnaround.
12
•This slide identifies several common reasons for initiating a
project.
•First, opportunity.
•Market demands often call for a project.
•Technological advances or challenges often inspire new
projects.
•Challenges include customer-requested tools or social needs.
•The last category of drivers is business requirements.

•In the field of health IT projects, these include legal
requirements, clinical
advances, and regulatory requirements.
13
Over the next five years, Meaningful Use (MU) will become a
major driver of health
IT projects. Meaningful use is a new term that has come into
the health care market
in recent years. The American Recovery and Reinvestment Act
of 2009 outlined the
government’s expectations for meaningful use of health care
technology.
Implementing meaningful use initiatives nationwide improves
quality, safety, and
efficiency of patient care, engages patients and families in their
own health care,
improves care coordination, ensures adequate privacy and
security for personal
health information, and improves population and public health.

14
Let’s take a look at the state of health IT implementation across
the nation. The
2011 HIMSS survey of health care information technology
noted that 51 percent of
hospital respondents have an IT strategic plan for health IT
conformance to
meaningful use; 36 percent have health IT strategic plans that
are separate from,
but aligned with their IT strategic plan; and the rest have no
plan at present.
15
This slide shows the survey respondents’ plans for future
projects: 64 percent plan
to increase their IT staffs in the next 12 months, and 76 percent
will definitely and/or
probably increase their budgets for health IT initiatives.
Clearly, we are on the edge

of a big reform in health IT.
16
Achieving meaningful use requires necessary changes in the
health industry. It
demands changes to the way the entire information system in
this industry is
managed, distributed, and exchanged, by whom, how, and for
what purpose.
It requires a realistic approach to the technological landscape
that can capture the
knowledge and skill sets necessary to achieve meaningful use.
These include the
current and future workflow of health information, the
appropriate health IT
infrastructure, and the ability to drive projects effectively.
This is where project management comes in. Meaningful use
affects everyone in
the health care strata. A small doctor’s office can receive tens
of thousands of

dollars in incentive payments from the government for
implementing a health care
IT system, while a large academic hospital could get millions of
dollars for
increasing its meaningful use of health care IT.
All of these organizations need someone who can understand
and manage the
demands, resources, processes, challenges, and benefits of these
complex
projects.
17
As a project manager, you will be driving the health IT
initiatives. Although these
projects can have specific and complex details, the basic lessons
of project
management apply: You are responsible for realizing the
project’s vision by
following the typical processes for project management:
planning, execution,
monitoring, and closure. And you will also provide a level of

subject matter
expertise. Since so many IT projects are supervised by
committees unfamiliar with
the specific issues and challenges of these jobs, the committees
often hire project
management professionals to oversee operations and achieve
their objectives. You
will function as that subject matter expert.
18
Your first job will be to understand this new landscape, so that
you can define your
scope and lead your team authoritatively. Project managers who
come from a
business or IT framework will need to learn the medical
terminology so that they can
discuss projects with health care professionals. At the same
time, those who come
from the medical side of project management will need to
acquaint themselves with
the technical requirements so they can have productive
conversations with the

technical groups. Project managers need to be able to work on
both sides of the
tracks.
According to the HIMSS survey, hospitals’ health IT priorities
include achieving
meaningful use by focusing on such clinical systems as
computerized practitioner
order entry, electronic health records, and e-prescribing, and by
optimizing current
systems. Nearly half of all respondents noted that their health
IT projects will focus
on implementing the International Statistical Classification of
Diseases and Related
Health Problems, 10th Revision, better known as the ICD-10.
The ICD-10 includes
the medical classification list for the coding of diseases as
maintained by the World
Health Organization.
The HIMSS website is a great resource for information on
health IT.
19

You will need to gather details about the organization’s current
information systems
and how they perform on the meaningful use intended outcomes
of quality, safety,
and efficiency. This information will provide your baseline to
track your new system’s
improvement. As you begin developing your new system, the
choices you make will
impact future information systems, so it is important to employ
staff with the
appropriate skill sets who can design with an eye to future use.
20
What kind of information does health IT share? It breaks down
as 94 percent clinical
information, 89 percent patient demographics, and 49 percent
billing code
information. These kinds of details will help your IT staff tailor
the system
appropriately.

21
22
Once you’ve done the legwork in developing your scope, the
rest of the process
should be very similar to other project management work.
During your planning
stage, you’ll assemble a team of skilled, creative professionals
and develop a time
line and resource allocation. It is important to know that
because health IT projects
are so complex, they tend to become unwieldy. One way to
tackle an overwhelming
project is by reducing it to a number of simpler goals. So, you
might take a complex
project, such as digitizing a medical office’s paperwork, and
break it down into
manageable parts. These might include one project for
converting records to digital
format, another for training personnel to use the digital
database, and then a final

project to post the database online. This process allows you to
step up to meeting
the overall objectives of the project by reaching achievable
goals and charting your
progress.
A major part of your job requires a constant vigilance regarding
your project
boundaries, so don’t let a project grow in complexity beyond its
scope. Your
stakeholders, especially those on the client side, often propose
“improvements” to
your project that would ultimately tax your budget and
resources without offering
truly beneficial functionality. You will need to weigh these
requests against your
project constraints and objectives, and thoughtfully consider
only those that bring
true value to your project.
A large part of project management is personnel management,
so you must
communicate time lines, deliverables, and expectations to your
staff. Be willing to
implement motivation or negotiation techniques, and maintain a
respectful
awareness of others’ politics and cultures.

Project success factors include the following:
•Executive support can make or break a project, particularly in
regard to
resource allocation.
•From the very beginning of a project, user investment and
participation is
essential to your success. If you don’t have a comprehensive
understanding
of your user’s requirements or how they hope to use the
product, your project
will fall short.
•A profitable undertaking often depends on an experienced
project manager,
especially in a highly specialized field like health IT. Their
background and
familiarity with the demands of the specific environment and its
users can
help a project reach successful completion. For instance, an
experience
project manager will take a clinical provider’s hectic schedule
into account
when planning meetings or requesting feedback. Unlike the

fairly predictable
schedule of a business environment, the demands on a
clinician’s time can
be irregular and urgent. To accommodate the changing
schedules of these
stakeholders, meetings must be short, efficient, goal-oriented,
and above all,
flexible.
•Using a clear set of business objectives to frame and focus
your project are
critical elements in your success. Why are you undertaking this
project?
What do you hope to achieve? How will it help the
organization’s business?
These are all questions that can help you define your business
objectives for
this project.
23
Factors contributing to failure include lack of planning, lack of
resources, and an
unwieldy scope—but if you have planned correctly in your early

stages, these
should not become major issues.
24
This concludes Lecture a of An Overview of Health IT Projects.
In summary, health
IT projects and the approaches to those projects vary widely in
terms of scope,
critical need, and risk factors, but they all have one aim: to
produce a needed
product or service.
Understanding that certain factors are common across all
projects can help you
manage those differences to achieve success in any kind of
project. The project
management process is not magic: it is built on a sure
combination of technique and
experience, and if you educate yourself on the details of the
health IT scope of your
institution, it will lead you to a successful outcome.

25
No audio.
26
No audio.
27
comp8_unit3_lecture_slidescomp8_unit2_lecture_slidescomp14
_unit3_lecture_slidescomp8_unit4_lecture_slidescomp14_unit8
_lecture_slidescomp8_unit5_lecture_slidesIT_Project_Managem
entcomp19_unit1a_lecture_slides
Stage 4: System Recommendation & Final System
Recommendation Report
Overview
Before you begin work on this assignment, be sure you have
read the Case Study, and reviewed the feedback received on
your Stage 1, 2 and 3 assignments. Refer to the System

Recommendation Report (SRR) Table of Contents below to see
where you are in the process of developing this report.
In this Stage 4 assignment, you will identify a certified
Electronic Health Records (EHR) system for the Midtown
Family Clinic and explain how it meets the requirements, how it
will improve the processes at the Clinic, and what needs to be
done to implement the system within the Clinic. You will add
the Conclusion to the Report. In addition, you will provide a
complete final System Recommendation Report incorporating
feedback from earlier stages.
System Recommendation Report
Table of Contents
Introduction (Stage 1)I. Organizational Analysis and
Requirements (Stage 1) A. IntroductionB. Organizational
StrategyC. Strategic Use of TechnologyD. Components of an
Information System
E. Requirements
F. SummaryII. Sharing Data (Stage 2)
A. IntroductionB. Need to Share DataC. Types of Data to be
Shared D. Data Interchange StandardsE. SummaryIII. Ethical,
Legal and Regulatory Policy Issues (Stage 3)
A. IntroductionB. Table of Ethical, Legal and Regulatory Policy
IssuesC. Addressing the Most Difficult IssueD. SummaryIV.
System Recommendation (Stage 4)
A. IntroductionB. Proposed IT solutionC. How the Proposed IT

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

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

More Related Content

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

More from helzerpatrina (20)

Recently uploaded (20)

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