Running Head: Waverly Family Health Services PracticeFusion EHR Implementation Project Plan

Waverly Family Health Services

PracticeFusion EHR Implementation

Project Plan

Steven Zhang

University of San Diego

Running Head: Waverly Family Health Services PracticeFusion EHR Implementation Project Plan

Document Control
Document Information
©

Information
Document Id 1
Document Owner Steven Zhang
Issue Date [10/28/2019]
Last Saved Date [10/28/2019]
File Name [HCIN 542 Project Plan]

Document History

Version Issue Date Changes

[1.0] [10/28/2019] V1.0

Document Approvals

Role Name Signature © Date

Project Sponsor
Dr. Waverly

Project Manager
Steven Zhang
Running Head: Waverly Family Health Services PracticeFusion EHR Implementation Project Plan 3

Table of Contents

1. WORK FLOW MAP FROM MODULE 1

2. PROJECT CHARTER AND SCOPE FROM MODULE 2
3. PROJECT PLANNING PHASE FROM MODULE 3
4. CAUSE AND EFFECT DIAGRAM FROM MODULE 4
5. FAILURE MODE EFFECT ANALYSIS FROM MODULE 4
6. STAKEHOLDER ANALYSIS FROM MODULE 5
7. “GO-LIVE” CHECKLIST FROM MODULE 6
8. IMPLEMENTATION EVALUATION FROM MODULE 7
 Patient needs new blood pressure  Patient leaves home for the  Patient waits for the correct 
medication  bus stop bus to arrive 
 

Patient takes the correct bus and  Patient arrives at  Patient waits in  Mini Registration 

heads to the pharmacy  the pharmacy line

Patient leaves the 
pharmacy No 
Mini Registration 

Patient is recalled  Patient is sent to  Waiting or 

to verify medical  waiting area  Pickup? 
information 
Yes 
Patient is 
informed of wait 
time 
Patient is sent to  Pharmacy Clerk  Pharmacy Clerk  Pharmacist checks 
waiting area  Prints Medication  Fills the  the prescription 
Label prescription

No

Medication is 
Signs off the  Yes Was the 
Patient is recalled  handed back to  medication 
medication  filled correctly? 
clerk 

Pharmacist explained the 
Yes Patient pays 
Medication  medication to the 
patient  copay  Patient leaves with 
explanation 
needed ?  medication 

No 
 Waverly Family Health Services EHR Implementation
Project Charter Template 
A.  General Information 
 
Project Sponsor:  Robert Brown 
Project Manager:  Steven Zhang 
Prepared by:  Steven Zhang 
Date:  9/23/2019 
 

B.  Purpose 
The Purpose of this Project Charter is to outline the requirements and goals of this specific EHR implementation 
projection. The goal is to convert Waverly Family Health Services’ patient health records from paper charts to digital 
by implementing the new Practice Fusion EHR.  
 
C.  Constraints and Assumptions 
Constraints 
 Six months completion date 
 Budget: $20,000.00 
 Three key stakeholders and five project team members 
Assumptions 
 Waverly Family Health Services Staff is qualified to perform the implementation 
 Current hardware and infrastructure are compatible with the Practice Fusion EHR system. 
 
D.  Project Scope Statement 
 Waverly Family Health Services team will be moving away from traditional paper charting to the Practice 
Fusion electronic health record (HER). The completion date is six months with a total project budget of 
$20,000.00. 
 The Waverly staff will be fully trained and using the new software within the 6‐month period.  
 No additional equipment should be purchased 
 No outside assistance besides PracticeFusion will be needed for the implementation of this product. 
 
E.  Resource Requirements 
 Budget $20,000.00 
 Three Key Stakeholders (Dr. Waverly, Dr Jones, Mrs. Jones) 
 Five Project Team Members (Mrs. Johnson, Mrs. Wright, Ms. Felps, Ms. Smith, Mr. Lawrence) 
 High Speed T‐line 
 Wi‐Fi Access 
 Eight Dell Workstations (4 in exam rooms, front office clerk, medical assistant, accounts and billing, clinic 
director) 
 Practice Fusion Support team. 
 
 

F.  Risks 
 Staff is unable to implement the EHR correctly 
 The current equipment is not compatible with the HER 
 Unforeseen events that will lead over budget and behind schedule 
 Lack of proper training will lead to medical and service errors of patients  
 

G.  Success Metrics: Criteria for Evaluating Project Success and Milestones 
 Project success: 

University of San Diego © 2016. All Rights Reserved.

 o Total cost under $20,000.00 
o Completed within six months 
o Full transfer of patient data onto EHR 
o Staff are trained to use the EHR effectively 

F.  Key Stake Holders 
 Dr. Waverly, clinic owner and medical director 
 Dr. Jones, physician and clinic partner 
 Mrs. Jones, clinic director 
 

F.  Executive Summary  
Waverly Family Health Services team will be moving away from traditional paper charting to the Practice 
Fusion electronic health record (HER). The completion date is six months with a total project budget of $20,000.00. 
 
Waverly Family Health Services will be utilizing Practice Fusion’s electronic health record software to 
modernize Waverly Family’s patient records‐ allowing both Waverly staff and its’ patients easier access to their 
health records. Additionally, updating to EHR will put Waverly Family Health Services in compliance with the 
Federal HIPPA act. 
 
Waverly Family Health Services projects a six‐month implementation period with a budget of $20,000.00. 
The Project is consider a success when the all medical records are transferred into the new system with a fully 
trained staff on using the new system‐ all while under the $20,000 budget maximin and within the six month period.  
 
 

University of San Diego © 2016. All Rights Reserved.

Practice Fusion EMR Implementation
Corporation 4

Project Manager Steven Zhang

Today's Date: 9/30/2019

[42] Start Date: 9/30/2019 (Mon) 0

Days Remaining
Duration (Days)

Days Complete
Working Days
% Complete

10 / 14 / 19
10 / 21 / 19
10 / 28 / 19

11 / 11 / 19
11 / 18 / 19
11 / 25 / 19

12 / 16 / 19
12 / 23 / 19
12 / 30 / 19
10 / 7 / 19

11 / 4 / 19

12 / 2 / 19
12 / 9 / 19

1 / 13 / 20
1 / 20 / 20
1 / 27 / 20

2 / 10 / 20
2 / 17 / 20
2 / 24 / 20

3 / 16 / 20
3 / 23 / 20
3 / 30 / 20

4 / 13 / 20
4 / 20 / 20
4 / 27 / 20

5 / 11 / 20
5 / 18 / 20
5 / 25 / 20

6 / 15 / 20
6 / 22 / 20
6 / 29 / 20

7 / 13 / 20
7 / 20 / 20
7 / 27 / 20

8 / 10 / 20
8 / 17 / 20
8 / 24 / 20
1 / 0 / 00

1 / 6 / 20

2 / 3 / 20

3 / 2 / 20
3 / 9 / 20

4 / 6 / 20

5 / 4 / 20

6 / 1 / 20
6 / 8 / 20

7 / 6 / 20

8 / 3 / 20
WBS Tasks Task Lead Start End

1 Kickoff Meeting Steven 10/02/19 10/02/19 1 100% 1 1 0

1.1 Operations Analysis Mrs. Jonhson 10/02/19 10/15/19 14 0% 10 0 14
Operations Analysis
1.11 Meeting Steven 10/16/19 10/16/19 1 0% 1 0 1
1.2 Functional Analysis Dr. Jones 10/16/19 10/30/19 15 0% 11 0 15
Functional Analysis
1.22 Meeting Steven 10/30/19 10/30/19 1 0% 1 0 1
1.3 Feasibility Definition Mr. Lawrence 10/30/19 11/13/19 15 0% 11 0 15
Feasibility Definition
1.33 Meeting Steven 11/13/19 11/13/19 1 0% 1 0 1
1.4 Needs Validation Mrs. Wright 11/13/19 11/27/19 15 0% 11 0 15
Needs Validation
1.44 Meeting Steven 11/27/19 11/27/19 1 0% 1 0 1
Planning Phase
2 Meeting Steven 12/18/19 12/18/19 1 0% 1 0 1
2.1 IT Equitment Setup Mr. Lawrence 12/18/19 1/06/20 20 0% 14 0 20

2.2 Paient Communication Ms. Felps 11/01/19 1/29/20 90 0% 64 0 90

Patient Record
2.3 Preperation Ms. Smith 1/02/09 1/29/09 28 0% 20 0 28

2.4 Training Documentation Mrs. Wright 12/18/19 1/16/20 30 0% 22 0 30

2.5 EHR Testing Mrs. Wright 12/18/19 3/16/20 90 0% 64 0 90
Execution Phase
3 Meeting Steven 1/15/20 1/15/20 1 0% 1 0 1
Installation of EHR on
3.1 all workstations Mrs. Wright 1/20/20 1/27/20 8 0% 6 0 8
3.2 Clinlic Wide Training Mrs. Wright 1/29/20 1/29/20 1 0% 1 0 1
Uploading Patient
information onto EHR
3.3 system Ms. Smith 1/30/20 2/28/20 30 0% 22 0 30

Project Review,
3.4 patches, and updates Steven 3/04/20 3/04/20 1 0% 1 0 1

University of San Diego © 2016. All Rights Reserved.

 Brief Summary: This process reviews in detail the technical components of the EHR implementation 
process. The FMEA explores the possible points of hardware failure during the usage of usage of 
EHR by the clinicians. Severity of these failures are measured‐ in our case, for auxiliary hardware 
(keyboard, mouse and monitor) are considered minor; Wi‐Fi connections are considered 
moderate issues, and internal hardware failures are considered critical. For the testing plan 
reviews what aspect of the EHR will be spanned from December to March (allow time for Winter 
holiday and new years). Only when the testing phase is complete is when training and 
implementation can occur.  

1. In this Failure Mode and Effect Analysis exercise, we are analyzing the computer hardware at 
the Waverly Family Health services and how failure of components will affect the effectiveness 
of the practice.  Each of the workstations at Waverly have identical Dell All‐In‐One workstations. 
Their hardware specifications are: 
 CPU: Intel I7 Processor 
 RAM: 8 GB 
 27‐inch non‐touch computer screen 
 Wi‐Fi Connectivity  
2. Assisting in this trail will include Dr. Waverly, Mrs. Wright, and Mr. Lawrence. Dr Waverly is the 
owner and a clinician, Mrs. Wright has previous EHR implementation experience, and Mr. 
Lawrence has pervious IT experience.  
3. Step 3 

Doctor Loads  Clinician finds  Clinician finds 

Doctor signs 
the EHR  patient’s HER  patient’s HER 
Start process into computer 
Program   or creates a  or creates a 
new one  new one 
 

Clinician SENDS  Clinician  Clinician ask 

Clinician  Clinician saves  patient 10 
patient to the front  updates 
office for follow up  treats the  the patient  questions regarding 
patient chart  their medical 
appointment  patient  profile  
on EHR   history 

 
Closes the 
Saves file   
program 
 

4. What could go wrong during the Doctor patient interaction process (Hardware Only Assuming 
no other stations are available) 
a. Data not reaching to the cloud servers‐ no connectivity 
b. Power Outage 
c. Computer Overheats 
d. Monitor Display is broken 
 e. Ram Fails 
f. CPU failure 
g. Wi‐Fi is down 
h. Internet is down 
i. Water spilled onto workstation 
j. Workstation falls over 
k. Keyboard or mouse stops working 
5. A. If the EHR (hardware only) workstation fails 

 
Table 1 Level of Severity Outcome 

Rating Outcome Category Description

5 Catastrophic Any hardware failure of the
workstation (Rare). Power Surge

4 Major Computer Overheats

3 Moderate Data not reaching to the cloud 
servers‐ no connectivity 

2 Minor WIFI goes down, Monitor,

Keyboard mouse stops working
1 Near Miss
 
Table 2 Failure Probability Rating Scale 

Rating Outcome Category Definition (the following are

examples you need to define your
own)
5 Very High probability: 1 failure in 1 week
failure is most inevitable

4 High: repeated failures 1 failure in 1 month

3 Moderate: occasional 1 failure in every 3 months
failures
2 Low: relatively few 1 failure in every 6 months
failures
1 Remote: failure is < 1 failure in one year
unlikely
 

6. Your final step is to design and implement changes to reduce or prevent problems. Identify
the processes that have high ratings and a high probability of failure and create a brief plan for
each one you identify.
 In order to prevent hardware failure, the workstations will be positioned in areas
within the patient rooms to avoid excessive movement. The usage of computer cables
will be carefully placed in which only the power cable will be plugged into a surge
protected outlet. Workstations will around at least size inches of around the vents to
ensure proper ventilation- reducing the chance of the computer overheating. Scheduled
maintience of these workstations will be performed to ensure computer hardware is in
good working condition.
FMEA Template

This template can be used to document the completed FMEA including follow-up actions and
measures. Revise this template as necessary to meet your needs. Review the Guidance for
Failure Mode and Effects before using this template.

Process analyzed: Hardware Failure Process

Team leader: Steven Zhang

Team members:

Name Position Name Position

Dr. Waverly Key Stakeholder Mrs. Jones Key Stakeholder

Dr. Jones Key Stakeholder Ms. Felps Team Member

Mrs. Johnson Team Member Ms. Smith Team Member

Mrs. Wright Team Member Mr. Lawrence Team Member

Describe your process steps (flowchart): As per the suggested guidance, you might use sticky
notes on separate papers.

Doctor Loads  locate patient  Clinician finds 

Doctor signs 
Start process the EHR  file or creates   patient’s HER 
into computer 
Program   new file   or creates a 
new one 
 

Clinician SENDS  Clinician  Clinician ask 

Clinician  Clinician saves  patient 10 
patient to the front  updates 
office for follow up  treats the  the patient  questions regarding 
patient chart  their medical 
appointment  patient  profile  
on EHR   history 

 
Closes the 
Saves file 
program 

Identify what could go wrong during each step of the process. You might use sticky-notes
indicating what could go wrong for each step. Line these up beneath each process step.

a. Data not reaching to the cloud servers‐ no connectivity‐ 5 
b. Power Outage‐ 5 
c. Computer Overheats‐ 5 
d. Monitor Display is broken‐ 5 
e. Ram Fails‐ 5 
f. CPU failure ‐ 5 
g. Wi‐Fi is down ‐5 
h. Internet is down ‐5 
i. Water spilled onto workstation ‐4 
j. Workstation falls over ‐3 
k. Keyboard or mouse stops working ‐2 

For each item identified that could go wrong, rate each for the seriousness of this
outcome (severity) and how often the mistake is likely to occur (probability) (per the

Review your ratings and decide on your process failures identified as high priority for corrective
actions. List the process failures you will focus on in the table below.
 Rating Outcome Category Description
5 Catastrophic Any hardware failure of the
workstation (Rare). Power Surge

4 Major Computer Overheats

3 Moderate Data not reaching to the cloud 
servers‐ no connectivity 

2 Minor WIFI goes down, Monitor,

Keyboard mouse stops working
1 Near Miss

Rating Outcome Category Definition (the following are

examples you need to define your
own)
5 Very High probability: 1 failure in 1 week
failure is most inevitable

4 High: repeated failures 1 failure in 1 month

3 Moderate: occasional 1 failure in every 3 months
failures
2 Low: relatively few 1 failure in every 6 months
failures
1 Remote: failure is < 1 failure in one year
unlikely

Describe your corrective actions for process failures identified as high priority:

Specific Actions to
Root Cause
Process Reduce or Responsible
of Process Completion Time Frame
Failure Eliminate the Individual/Group
Failure
Failure

Schedule Could be done by

CPU,
Overheating Maintenance of purchasing a new CPU from Mr. Lawrence
Failure
workstations local computer store

Component is Purchase new Could be done by

Hard Drive,
old and equipment prior to purchasing a new CPU from Ms. Smith
Ram failure
exceed life equipment failure local computer store

Loss of Router Failure Backup Router Swapping backup router Mr. Lawrence
internet should take no more than
connection two hours.

Measures of Success

Measure(s) of Success
(How we will

know if this action is successful)

Corrective (Consider measures of how often the Reporting Schedule and Individual or
Action failure is still occurring after process
changes and the incidence of adverse Group Responsible for Reviewing Results
events related to the failure)

Regular Scheduled miantience of

1 Mr. Lawrence
computer hardware and maintained

Staff knows basic knowledge of

2 Mrs. Wright
computer troubleshooting

Backup parts for critical hardware

3 Ms. Smith
components such as routers.

4 No level 5 issues in a year. Ms. Felps

Signature of FMEA leader/facilitator: Steven Zhang Date 10/23/2019

 
 
Problem Statement: No direct access to physician caused the prescription to exceed two hours.  

Equipment/Supplies   Environmental 

Lack of governmental enforcement to enforce 
digital prescription ordering‐ allowing for 
Phone call only method to reach patient’s 
paper medication records 
doctor. 
Work flow design of the pharmacy is poor and 
creates double work. 
Location is far away from the patient even 
though it’s considered a neighborhood 
No direct line to the patient’s Doctor  pharmacy  

Prescription took 8 
hours to fill. 

Did not tell patient about missing signature 
until after the patient has left the pharmacy 

No Process to communicate with patient after  Did not check the prescription for completion 
discovery of error  until after the fact. 

Either no standard operations process for  Did not know Dr. Would take 6 hours to return 
receiving prescriptions or lack of training.  the call to confirm prescription. 

Rules/Policy/Procedures  Staff/ People 
[
Project Name: Waverly EHR
Date: 10/14/2019

Project Stakeholder Analysis

PURPOSE

The purpose of stakeholder analysis is to inform the Project team who the stakeholders are, how
those stakeholders should contribute to the project, where barriers might be to project success
(from the stakeholder’s perspective and their potential impact) and the actions that need to be
taken to ensure stakeholders needs are met. Depending on your project the stakeholder analysis
could be performed informally but more complex projects that involve: multiple departments,
agencies, or disciplines may require an extensive analysis. Keep in mind that stakeholders are
not always obvious and requires interviewing and discovery. Taking time to understand the stake
holders and how they can contribute to the success of the project warrants a formal analysis.

The identification of stakeholders will also assist in determining if an advisory board for the project
is necessary (this is not always the case) and what the concerns of the steak holders is.

CONTENTS

Purpose ............................................................................................................................................ 1
Stakeholder Analysis ........................................................................................................................ 1
Stakeholder Interview ................................................................................................................... 1
Influence / Interest Grid .................................................................................................................... 3
Guidance notes ................................................................................................................................ 4

STAKEHOLDER ANALYSIS

Identify the key stakeholders (both internal and external) in your project and determine their
interests or requirements from the project; what the project needs from them, any perceived
attitudes and/or risks the stakeholders may have and the actions to be taken to achieve this.

This may require a series of meetings or workshops in order to complete the Interview Sheet
below.

From your list of stakeholders you may determine more easily how they fit into your Project
Organisation. The majority of whom will fit into the Advisory Board or Business Community.

Stakeholder Interview
Category Name Objectives/Questions
Topics to Cover (adjust as necessary):
 Special Interests
 Influence
 Dependencies
 Critical Timelines / Risks
 Actions required
Non clinical Staff Ms. Felps Special Interest
(could be listed by Mr. Lawrence Dependencies

Page 1 of 4
HCIN 542 M5 Stakeholder Analysis Steven Zhang Waverly EHR
Date: 28/10/2019

department or Superusers and champions for change

agency)
Clinical staff (could Dr. Waverly-KEY Influence
be listed by Dr. Jones-KEY Dependencies
department or Mrs. Johnson Special Interest
agency) Mrs. Wright Concerns (both patient and financial)
Ms. Smith
Admin staff (this Mrs. Jones-KEY Superusers and Change Champions
might include your Dr. Waverly-KEY Special Interest
practice manager Dr. Jones -KEY Highly influential
and medical
director)
Outside personal or N/A
agencies

Vendors Printer & Paper Special Interest

Practice Fusion Discount and Contract Terms
Internet Service Provider Order Frequency and bulk discounts
PC Workstations

Patients Community Patient Interest

Group Concerns
Patient Advocacy

Misc. Federal HITECH & Compliance

HIPAA Act

External to Clinic Kaiser Permanente Software compatibility

(this could be Stanford Medical Centre Influence
outside Alameda County Health Referral continuation
organizations like Specialist Clinicians
practices that have
a contract for
referring patients)
Finance Bank of America Loan, line of credit

Page 2 of 4
 HCIN 542 M5 Stakeholder Analysis Steven Zhang Waverly EHR
Date: 28/10/2019

INFLUENCE / INTEREST GRID

Once the key stakeholders are identified, plot their position on the grid below. Please refer to the
‘Guidance Notes’ below for reference.

KEEP SATISFIED MANAGE CLOSELY

High
Mrs. Jones-KEY Practice Fusion EHR
Dr. Waverly-KEY Ms. Felps
Dr. Jones -KEY Mr. Lawrence
Mrs. Johnson
Mrs. Wright
Ms. Smith

INFLUENCE
MONITOR KEEP INFORMED
(MINIMUM EFFORT)
Community Patient Group
Federal HIPAA and HITECH Act
Printer & Paper
Bank of America
Kaiser Permanente
Stanford Medical Centre
Alameda County Health
Specialist Clinicians
Internet Service Provider
PC Workstations Provider
Low

Low INTEREST High

Page 3 of 4
HCIN 542 M5 Stakeholder Analysis Steven Zhang Waverly EHR
Date: 28/10/2019

GUIDANCE NOTES

Brainstorm to identify stakeholders, the intention is to use the most powerful stakeholders to
shape your project in the early stages. Not only does this make it more likely that they will support
you in the future but their input can aid the quality of your project. Using these powerful
stakeholders can assist with gaining the correct level of resources for your project. Using your
influence/interest grid to drive your communications strategy ensures that stakeholders receive
the correct level of information at the right time, the earlier you start communicating with your
stakeholders the better their understanding of the project and its benefits.

Plot stakeholder’s position on the grid above using the following guidelines:

 High influence, interested people: these are the people you must fully engage and make
the greatest efforts with e.g. A head of department, who represents the users/customers

 High influence, less interested people: provide sufficient information to these people to
ensure that they are up to date but not overwhelmed with data e.g. the Accountable Body
(Management Board or Operations Committee)
 Low influence, interested people: keep these people adequately informed, talk to them
to ensure that no major issues arise. These people can help with the detail of the project
e.g. End Users, other Project Managers, Business Community
 Low influence, less interested people: provide these people with minimal
communication to prevent boredom e.g. other departmental members, teams unaffected
by the change.

When plotting stakeholders position on your grid it is worthwhile establishing who will be
advocates/supporters of your project and who will be blockers/critics of your project. Use colour
coding to identify which of these two groups the stakeholder belongs – e.g. green for
advocates/supporters and red for dis-interested/unsupportive. The following questions help you to
understand their needs/drivers and grouping and assist in establishing the best way to engage
them in your project:

 What financial or emotional interest do they have in the outcome of your work – is it
positive or negative?
 What motivates them most of all?
 What support do you want from them?
 What information do they want from you?
 How do they want to receive information from you – what is the best way of communicating
your message to them? (This will input into your communications plan)
 What is their current opinion of your work and is it based on good information?
 Who influences their opinions generally and who influences their opinion of you?
 Do some of these influencers therefore become important stakeholders in their own right?
 If they are not likely to be positive what will win them round to give their support?
 If you are unlikely to win around, then how will you manage their opposition?
 Who else might be influenced by their opinions and decide if they need to become
stakeholders in their own right?

Remember that projects become more important the nearer they get to implementation and will
therefore affect more people. Keep abreast of your stakeholder analysis and change your
communications techniques as necessary to ensure that your stakeholders are kept informed to
the right level.

Page 4 of 4
Running head: GO‐LIVE IMPLEMENTATION CHECK LIST  1 
 

Go-Live Implementation Check List  

Steven Zhang 
University of San Diego   
GO‐LIVE IMPLEMENTATION CHECK LIST    2 
 

Go‐Live Implementation Check List. 

1. Staff 
o Dr. Waverly, clinic owner and medical director  
o Dr. Jones, physician and clinic partner  
o Mrs. Johnson, physician’s assistant  
o Mrs. Wright MSN NP, nurse practitioner  
o Mrs. Jones, clinic director  
o Ms. Felps, front office clerk 
o Ms. Smith MA, back office medical assistant  
o Mr. Lawrence, clinic accounts and billing  
2. Hardware 
o Dell all in one desktop 
 8 GB of Ram 
 Intel I7 Processor 
 23‐inch computer monitor 
3. Down Time Procedures 
o Customized paper charts that are replica of the EHR software forms. When power or 
internet is restored, staff will have to manually enter the information onto the EHR 
system. 
1. Two weeks prior to “Go‐Live:” Ensure all staff have met training requirements 
2. One week prior to “Go Live”. All equipment has been tested and meets specification for 
operating with the HER.  
3. Feel free to be creative and use the supplied resources or others you might locate to assist in 
drafting your “Go live” checklist. Remember to ask your instructor for additional information to 
bridge any gaps that might exist. 

One Month before Go‐Live Implementation: 

o Training manual is updated with approved customizations by key stakeholders and project 
managers.  
o Confirm the roles and task of the implementation team 
o Communication with the upcoming changes are communicated with stakeholders 
o Confirmed what data will be uploaded into the EHR system and what will be archived 
o Confirm the schedule of rollout dates and times and verify stakeholder availability 
o Confirm EHR testing log.  
o Confirm hardware and IT needs are met 
o Confirm software testing schedule  
o Develop training documents and workshop schedule for patients that will need computer 
training to access their medical records electronically.  

Three Weeks before Go‐Live Implementation: 

o Use sandbox version of EHR to ensure software and hardware are integrated correctly.  
o Confirm workstations are communication with each other and also onto the service. Work with 
vendors to confirm that outgoing and incoming data are working as expected.  
GO‐LIVE IMPLEMENTATION CHECK LIST    3 
 

o Confirm locations of workstation will not hinder workflow efficiency ( workstations are easily 
accessible)  
o Medical records that will to be uploaded into the EHR are collected and prepared (Active and 
frequent patients) 

Two Weeks before Go‐Live Implementation: 

o Review staff schedule to ensure proper staff allocation 
o Staff members have completed pre implementation and understand who and where to go for 
technical support 
o Run different training scenarios to ensure staff understand what to do during emergencies 
o Develop contingency plans with superusers and vendors to plan for as many ‘worse case’ 
scenarios as possible.  
o Ensure scheduling of new patients are adjusted to anticipate for the new EHR learning curve. 

One Week before Go‐Live Implementation: 

o Reward stakeholders and team members for their continual efforts, continue to encourage the 
team and reinforce positive behavior.  
o Secondary with team to ensure new operating procedures are understood and ready to be 
implemented.  
o Update patient information sheets and other new patient information to showcase the new EHR 
system. 
o Create patient demo accounts so staff understands what patients see on their profiles to better 
assistance with questions.  
o Assign staff members to run information meetings for new patient orientation regarding the 
new EHR program  
o Hold informational seminars for patients interested in learning how to access their new patient 
information online 

3 days before Go‐Live Implementation: 

o Verify that all users can log into the system 
o Ensure that correct permissions are set up for individual users 
o Ensure secondary internet option is available and working  
o Review the partial rollout and what metrics we will be measuring before launching phase two of 
the implementation 

2 days before Go‐Live Implementation: 

o Review chain‐of‐command procedures and where to get support regarding your EHR systems.  
o Understand who can make immediate EHR decisions on the fly.  

1 day before Go‐Live Implementation: 

o Pulls and preps patients for the next day, practice simulations to ensure training is adequate and 
correct.   
o Remind patients that the change to EHR is officially happening tomorrow.  
GO‐LIVE IMPLEMENTATION CHECK LIST    4 
 

Day of Go‐Live Implementation: 

o Staff is to arrive 45 minutes early to prepare for the first patients.  
o Expectations that today is a learning day and errors and mistakes are part of the learning 
process.  
o Ensure that the appointments slots are adjusted to accommodate the new EHR system 
o Food and snacks are provided as morale boosters for the staff and patients 
o Staff understand that they will record any issues not covered by the training manual 
o All users can sign in under their own credentials 
o IT confirms that system safeguards are functional (automatic timeouts, credential verification on 
critical area, etc) 
o Correct permissions and access from all workstations 
o Ensuring the staff are following the schedule and the breakdown of responsibilities.  

3 days after Go‐Live Implementation: 

o Formal review of the rollout process, feedback, adjustments 
o Celebrate implementation 

A week after Go‐Live Implementation: 

o Patches, adjustments based off the feedback from the initial rollout. 

2 weeks after Go‐Live Implementation: 

o Full office rollout with all patent medical data uploaded onto the EHR system. 

References: 

1. “Electronic Health Record (EHR) Implementation.” Electronic Health Record (EHR) 
Implementation | Technology and Finance | AMA STEPS Forward | AMA Ed Hub, 
https://edhub.ama‐assn.org/steps‐forward/module/2702512 

2. “Electronic Health Record (EHR) Implementation Go‐Live Planning Checklist.” National Learning 
Consortium, 31 Mar. 2012, https://learn‐us‐east‐1‐prod‐fleet01‐xythos.s3.us‐east‐
1.amazonaws.com/5c2103143e6a3/1159923?response‐content‐disposition=inline; 
filename*=UTF‐8''Go_Live.pdf&response‐content‐type=application/pdf&X‐Amz‐
Algorithm=AWS4‐HMAC‐SHA256&X‐Amz‐Date=20191021T211455Z&X‐Amz‐
SignedHeaders=host&X‐Amz‐Expires=21600&X‐Amz‐
Credential=AKIAIBGJ7RCS23L3LEJQ/20191021/us‐east‐1/s3/aws4_request&X‐Amz‐
Signature=069180585017b94aa2c8bc08d238cac587c99dc608aaa2c5e157b33102070eb1. 
UNIVERSITY OF SAN DIEGO
HEALTH CARE INFORAMTICS PROGRAM

POST IMPLEMENTATION EVALUATION

1.0 HOW DO I CONDUCT A POST-IMPLEMENTATION EVALUATION?

You may find additional information for HER implementation on the HEALTH IT.Gov website
https://www.healthit.gov/providers-professionals/ehr-implementation-steps/step-1-assess-your-
practice-readiness

1.1.1 The Basics

Evaluating your electronic health record (EHR) implementation is a critical EHR implementation step.
Conducting a post-implementation evaluation will enable your practice to continue improving workflows,
achieve your goals and needs, and realize the benefits of EHRs. During your post-implementation
evaluation, you should check that the practice/hospital/health center team is still intact and that
workflows are running smoothly, with few workarounds. You should also seek to identify unresolved
vendor issues, interface issues, and staff training needs. You can use the findings of your post-
implementation evaluation to target and implement initiatives that will enable your
practice/hospital/health center to continue quality improvement.

1.1.2 Timing

You should evaluate your EHR implementation approximately three to four weeks after your go-live
date. If the EHR system is not working, the practice may revert back to the previous paper-based
workflow, which can impair the overall success of your EHR implementation. To avoid reverting back to
your previous paper-based workflow, it is critical that you are evaluating your EHR implementation
right after go-live. You should be creating a punch list of items to fix and providing just in time fixes
and training for fixes.

1.1.3 What information should I collect?

Consider asking the following questions as you continue quality improvement and evaluate your EHR
implementation:

• Culture and Adoption

• What did we learn about ourselves that we did not know before?

• Have all of our providers/departments migrated to an EHR or are some providers still waiting?

• Do workflow processes need to be re-evaluated? Are providers returning to pre-

EHR workflows?
• Do any staff need additional training?

• Are we capturing the required data elements needed for internal clinical priorities, as well as for
reportable quality measures and meaningful use objectives?

• Have unplanned consequences arisen due to the implementation of the EHR?

• Network and Infrastructure

• If there are network bottlenecks and downtimes, have we logged and reported them?

• Is technology (hardware, software) in the right places?

• Are technology tools reliable?

• Have we ensured personal health information is used and disclosed in a secure environment?

• EHR Vendor

• What did we learn about our EHR vendor that we didn't know before?

• What issues must be resolved before the practice is handed over to the vendor's Technical
Support and Maintenance division?
UNIVERSITY OF SAN DIEGO
HEALTH CARE INFORAMTICS PROGRAM

POST-IMPLEMENTATION REVIEW REPORT

Overview
The Post-Implementation Review is used to evaluate the effectiveness of the system implemented
(in this case your EHR). Some of the questions in the template are worded in a general fashion
and some are specific to an EHR. Feel free to make changes as necessary to ensure you have a
complete evaluation document.

Information to complete this document

*You will need to contact your instructor who will provide you with further data to complete this
document. It is your responsibility to formulate your questions to obtain additional information.

The overall objectives are:

• Determine if the system does what it is designed to do:
• Does it support the user as required in an effective and efficient manner?
• The review should assess how successful the system is in terms of functionality,
performance, and cost versus benefits, as well as assess the effectiveness of the life-cycle
development activities that produced the system.
• The review results can be used to strengthen the system as well as system development
procedures.

General guidelines for reviewing a system implementation

The review is scheduled to follow the release of a system or system revision by an appropriate
amount of time to allow determination of the effectiveness of the system. A representative from
the functional development group or other member of the major user organization participates in
the review. The System Proponent ensures that all documentation and all personnel needed to
participate in the review are accessible.

The reviewer and an assigned team collect the information needed for the Post-Implementation
Review by interviewing end users and their managers, system administrators, and computer
operations personnel. The report is then prepared and provided to the user organization that
requested it and the information systems organization, which may jointly use the findings to
initiate other actions.

The Post-Implementation Review is a free-form report, and not all sections are relevant or
necessary to the final product. A description of the Post-Implementation Review Report is
attached.
Template

1 INTRODUCTION

1.1 Project Identification

Waverly Family Practice EHR implementation project.

1.2 System Proponent

The EHR being implemented at Waverly’s Family practice is Practice Fusion.

1.3 History of the System

Practice Fusion is currently the #1 cloud-based EHR system with over 30,000 medical
practices and over 5 million patients a month. Practice Fusion was founded in 2005.

Practice Fusion’s EHR system enable medical clinics to save time and improve accuracy
with: practice management, patient engagement; charting; e-prescribing; labs & imaging;
and PHR.

Practice Fusion takes traditional paper charting and uploads them onto their cloud-base
server. With this software clinicians can use the data to coordinate patient care with a
intelligent unified practice management system to manage various aspects of their practice
that was not possible with traditional paper charting.

2 EVALUATION SUMMARY
The purpose of this section is to provide a summary of the overall adequacy and acceptance
of the system.

2.1 General Satisfaction with the System

Describe the users’ experience with the implemented system. Comments should address
the following:

• The level of user satisfaction

• The strengths of the system, including specific areas of success
• Any problems
• Frequently used features
• Infrequently used features
• Features not used at all
• Suggested improvements

Overall, the staff at Waverly office are happy with the EHR implementation. Ms. X and
Mr. Y, who have EHR implementation and IT experience, respectively played a major role
as change champions and keeping the morale of the team high. As anything that is new,
there are some growing pain associated with this EHR implementation, such as the increase
time it takes to get familiarized with the Practice Fusion software. This is especially true
for individuals that are not particularly technology savvy who will need additional EHR
training.

Some strengths of the system that everybody enjoyed is the automation that comes with the
software. The front end staffed the new billing processed, which is now simplified thanks
 to the EHR software. Patient information can be accessed faster now processing time of
specific tasks are much faster and accurate (sans the learning curve). It is also worth noting
that penmanship is no longer an issue now they have made the switch over to EHR.

Some potential problems that may arrive is the over reliance of the autofill feature and the
charting the right patient on the right file. There was an instance in which two patients had
an identical first and last name and the doctor nearly selected the wrong account because of
the autofill feature. Training will be required to ensure that they verify that that correct
EHR was pulled for the right patient. We have also reached out to the EHR software
company to create a system block when two patient’s name pops up, thus forcing the user
to slow down and ensure that the correct file is pulled.

The three most common features used with the new EHR are, patient file look up, billing &
coding, prescription orders and referrals. This is to be expected as majority of the training
was focused on these common usages. As time goes on more complex EHR usages will be
introduced such as reports that will aid in making financial business decisions.

As of right now the least used features are the reports. Again, this is expected as the entire
clinic is focused on the daily transactions of the clinic. Continual training will be held on
the advance EHR features that will not only make running the clinic easier but also grow
the clinic as well. Feature that is not being used at all is the to-do list. Currently to-do lists
are schedule tasks are written on a traditional whiteboard

Some potential suggestions would be a more robust and interactive assistant on the EHR
software. When staff runs into a problem, they are unsure of, they have to either resort to
their notes or go into the help function and find the area in which they are stuck. If the
software has links throughout the software that will automatically take the person to the
desired manual- that would save time from the staff.

2.2 Current Cost-Benefit Justification

Assess if the system is paying for itself Base the assessment on the anticipated benefits and
costs projected during the System Concept Development phase and revised during the
subsequent phases of the systems development life cycle. This section is intended merely
to review the costs and benefits and to provide details of costs and benefits in other
sections. Comments should address the following:

• The extent of the benefits and if they are reported to be less or greater than those
projected in the development analysis and functional requirements report
• If any difference is permanent or will change over time
• If the system is or will be cost-justifiable.

The benefits reported are slightly less than originally projected as staff tend to use features that
are the easiest to learn. As the clinic gets experience with the software, they will use the more
advance features and shortcuts to become even more productive.

It is important to understand that as staff gets more comfortable using the new EHR, we must
continue training before the onset of bad habits. Training will help enforce the way we want the
staff the use EHR and avoid personalized customization in order to maintain a level of consistent
service across the board.
The clinic believes this is a good investment for the clinic. With the increase productivity the
clinic can see more patients for the same amount of time. Error rate will reduce due to the
system’s auto checking system. In addition to the time saving and the error reducing aspect of
EHR, the reports features associated with the EHR system allows the clinic to plan strategically
with real time data. This would not have been possible prior to the EHR implementation

2.3 Needed Changes or Enhancements

Gauge the magnitude of effort needed to change or improve the system. Describe the
nature and priority of the suggested changes~ more detail will be provided in other
sections. Comments should address the following:

• The suggested changes

• The scope of the changes
• The resource requirements to effect the changes

One of the requested changes for the system is the request to customized specific forms
and processes to better fit the needs of the clinic. The second change request are bigger or
duel screen monitors from the back office so they can have more information available
immediately.

The resources needed for the change will be an agreed upon list of updates on the
selected pages within the EHR system and a budget allocation to purchase new monitor
screens for the front and back end work stations. Time allocation for the webpage
customization is budgeted for a month for with a two-week follow-up window. The
monitors can be purchased and installed in one week.

3 ANALYSIS AND IMPLEMENTATION

The purpose of this section is to gauge the completeness of the functional requirements and
implementation according to the study.

3.1 Purpose and Objectives

Evaluate the adequacy of the original definition of purpose and objectives presented in the
functional requirements document and if the objectives were achieved during
implementation. Evaluate if any objectives have changed or should have changed.
Comments should address the following:

• Extent to which goals were met

• The level of the objective definition
• Extent to which objectives were met
• Possible changes to the objectives

The primary objective of this project was to convert Waverly clinic from traditional paper
charting to Practice Fusion’s electronic EHR within six months. This objective was
completed on schedule and on budget.

3.2 Scope
Analyze if proper limits were established in the design of the implementation within your
project plan and if they were maintained during implementation. Comments should
address the following:
 • Variations from the scope definition as agreed to in the concept development
• The extent to which the scope was followed
• Any possible future changes to the scope

The scope definition agreed upon on this project was essentially a minimal viable
product. Later request will come in terms of updates and secondary projects. Because of
this, the variable at the end of this project varied little from the original concept. This
prudent approach to EHR implementation appeared to set proper expectations and the
staff understands that later updates/patches will be applied at future products.

3.3 Benefits
Analyze if the benefits anticipated by implementing the new HER system are met and if
they are not met how did they miss the metric for measuring success. Detail all benefits,
quantifiable or non-quantifiable, and any quantifiable resources associated with each.
Comments should address the following:

• The adequacy of the benefit definition

• The level and types of benefits of the EHR system realized
• The anticipated benefits that can be realized
• The reason for the variance between planned and realized benefits

Thanks benchmarking the pre-implementation times to complete various tasks within the
clinic. Staff was able to see quantifiable improvements on majority of their tasks when
switching over to the new EHR process. The only exception to that was charting by the
physicians, in which the charting process took longer than traditional charting. This can
be explained due to familiarity of the software in addition to the EHR requesting the
clinician to fill out the charting completely-whereas with traditional charting the clinician
can write as much or as little as they pleased.

The EHR system completed the benefits requirements as expected and the results were
within expectation of the key stakeholders.

3.4 Development Cost

Determine the adequacy of the development cost estimated and any deviation between the
estimated and actual development costs. Comments should address the following:

• The adequacy of the original and subsequent cost estimates

• The actual costs, by type
• The reasons for any difference between estimated and actual costs

The development cost was under budget, as the scope requirement was reduced to just the
minimal viable product, and the extra contingency budget was not needed. As a result,
more projects are scheduled to add additional features for the clinic regarding the EHR
software which will most likely equate to the total budget allotted for the initial EHR
implementation.
3.5 Operating Cost
Analyze the adequacy of the operating cost estimates and any deviation between the
estimate and the actual operating costs. Summarize the resources required to operate the
system. Comments should address the following:
• The adequacy of the operating estimates
• The actual operating costs
• The difference

The operating cost associated with the EHR implementation are as follows:
High Speed Internet
Secondary backup internet
EHR monthly subscription fee
IT infurstrture (modems, cables etc.)
Workstations
Higher electricity bill

The operating estimates were on target as we were able to obtain accurate estimates of
the items in question (except with the slight variations of the electricity bill)

3.6 Training
Evaluate if all levels of user training were adequate and timely. Comments should address
the following:

• The timeliness of the training provided

• The adequacy of the training
• The appropriateness of the training
• Identification of additional training needs by job category
• The ability of the personnel to use the training provided

The timeliness of the training provided was done on a steady manner. The lesson plans
were designed after observing the clinics day-to-day operations. Additional training will
be performed once the staff felt confident, they have mastered the EHR basics before
moving onto the more advance features of the EHR software- with the exception of for
Dr. Waverly who took longer charting using the EHR than traditional paper charting.

4 OUTPUTS
The purpose of this section is to evaluate the adequacy and usefulness of the outputs from
the system. Outputs are defined as the clinical records (data) generated by patient visits and
any associate data such as billing, coding, quality reports/data.

4.1 Usefulness
Measure the extent to which the users feel the EHR systems meets the intended needs.
Comments may address identification of the level of need, such as the following:

• Usability
• Absolutely essential (does it effectively replace the paper based system)
• Important and highly desirable
• Interesting - proves what is already known
 • Incomplete - does not provide all the necessary information
• Unnecessary- “We need to go back to the paper based system”
• Identification of information/reports needed but not currently generated by the system
or unable to be obtained
• Demonstration of the ability to do without the reports
• Alternatives for obtaining the information where improvements can be achieved

Overall the staff finds that the EHR software is useful and is a huge upgrade from
traditional paper charting. They believe this EHR software is essential and allows the
team to focus on more patient focus activities and less on proper filing of patient
information. As of anything new, there are certain growing pains; such as proper 10-
keyboarding and memorizing the new standard operating procedure of the new EHR. The
staff is excited that they have an active role on customizing an EHR that are based on
their needs.

4.2 Timeliness
Determine if output production performance meets user needs. Comments should address
the availability of clinical records, clinical data, lab reports, imaging data, previous
clinical visits, and billing data.

Production requirement meets user needs within the six-month implementation period.
Initially hesitant regarding the length of time needed to ‘install a simple software’, the
team understands the planning and the training needed to maximize the utility of the EHR
software. The staff are excited to see how the software can auto complete reports,
imaging data, past visit and billing data with several clicks of the mouse. The number of
manhour saved from puling files and manually creating reports clearly outweighs the cost
of the EHR machine.

4.3 Data Quality

Assess the need to provide for effective use of shared data to enhance performance and
system interoperability. Comments should address data accuracy and data reliability.

Shared data is one of the big features of EHR as all Waverly workstations can access
patient information from the cloud. By having one single location to store location- this
increase data accuracy and avoid duplication of patient record. Since patient record can
only be accessed by one individual at a time, this avoids data conflicts by preventing
multiple individuals accessing patient information.

5 SECURITY
The purpose of this section is to determine if the system provides adequate security of data
and programs. A reassessment of HIPPA compliance should be part of the review process.
In addition to access security, procedures for backup, recovery, and restart should be
reviewed.

One of the training sessions was a refresher on the HIPAA and the introduction of the
HITECH and how that affects the EHR implementation. Each staff understands that the
primary weakness of EHR security is human error. Each staff member understood the
concept of phishing attack and what they can do to protect themselves and the clinic from
said dangers. Additionally, understand the criminal ramifications of abusing their access to
 patient information-which could result in loss of employment, fine and/or jail time. For
Superusers and key stakeholders, they are trained on how to backup, recovery and restart
EHR programs to protect the EHR system and patient data.

5.1 Data Protection

Determine if the security, backup, recovery, and restart capabilities adequately safeguard
data. Comments should address the following:

• The adequacy of the security, backup, recovery, and restart procedures

• Data and activity meet HIPPA compliance
• If data and clinical activity with the EHR does not meet HIPPA/security compliance
indicate what additional steps will be necessary to ensure compliance
All superusers and key stakeholders are trained on the backup and recovery of the EHR
process. Tech support form the EHR is also available for major breaches of security
and/or other EHR issues. All staff have refresher HIPAA and HITECH courses and have
signed a documentation stating that they understand their responsibilities as medical
professionals.

5.2 Disaster Recovery

Determine if appropriate clinical files, programs, and procedures are established to enable
recovery from a disaster (unintended down time of EHR) resulting in the potential loss of
data or lack of access to stored data. The following are suggested areas of comments:

• Back up and recovery procedures are established

• Staff demonstrate ability to perform down time procedures for all clinical activities
• Ability to access backup data for downtime procedures

Backup and recovery procedures are taught to superusers and key stakeholders in case of
emergency. Patient information are uploaded to the cloud at real time. In an event of a
connection outage (both lines failing) and/or a blackout, the clinic are trained to use
temporary paper charting until power/EHR functionality is restored.

5.3 Audit Trails

Review the ability to trace clinical documentation and other online processes transactions
through the system. Comments might address the following:

• Who manages the audit trails?

• What data is contained in the audit trails
• When: frequency of audit trails

Mr. Waverly, clinic director and two super users have various administrative privileges to
track usage of staff members. The data contains the login information and the history of
actions of each user. We can trace who logged into the workstation, what information
they accessed and what was inputted and what was erased on the EHR application. Audit
trails are done on a twice-yearly basis by an outside auditor.

5.4 System Access

Evaluate systems that manage access to HIPPA data. Comments should address the
following:
 • Policy governing access for the EHR systems
• Assignment of security officer
• Criteria for level of access to EHR systems
• Documenting any access breaches
• Frequency of access review for new, established and terminated employees
• Breech notification plan is created

An outside independent auditor will review system access twice a year at Waverly to
ensure that both HIPAA and HITECH are being allowed by all parties. This auditor will
work closely with a key stakeholder and a superuser to review policies of hiring and
firing of employees and the language used for data breeching communication.

6 COMPUTER OPERATIONS
The purpose of this section is to ascertain the current level of operational activities.
Although the user point of view is primary to the Post-Implementation Review Report, the
computer operations view is also important to investigate.

6.1 Control of Work Flow

Evaluate the EHR user interface for collecting clinical data for given workflows.
Investigate issues related to data gathering at given points in work flow. Comments should
address the following:

• Any problems in accomplishing clinical work flow processes

• The frequency and extent of problems related to clinical data gathering within a work
flow
• Suggested changes from end users
• The effort or barriers required to make changes to the EHR to remediate issues

Overall, the staff was able to navigate through the new EHR clinical work flow processes,
thanks to the training leading up to the go-live date. Additionally, the engineers from the
EHR company was able to customize certain EHR functions and forms, allowing the staff
to have EHR forms that are like their paper version.

6.2 Scheduling
Determine the ability of computer operations to schedule according to user needs and to
complete scheduled tasks. Comments should address the following:

• Any problems in scheduling patient visits, procedures or follow up

• The frequency and extent of the problems
• Suggested changes
• The effort required to make changes

Because of EHR new patient feature, patients are now able to make appoints online at the
comfort of their own homes. This ability has reduced the strain on the front office staff,
allowing them to reallocate their time to other priorities. Additionally, the EHR’s
scheduling system allow more information to be added onto the appointment log,
 compared to just the name of the patient on a calendar book. This added feature enable
clinicians more time to prepare for the patient visit.

6.3 EHR User Interface

Analyze the usability of the system. The transaction throughput and error rate are included
in this analysis. Comments should address the following:

• Number of patient visits processed (number of transactions)

• Number of errors made when carrying out clinical documentation
• Frequency of problems with the interface
• Suggested changes from users
• Effort required to make the changes

6.4 Computer systems

Analyze computer issues and problems. Some areas to review are as follows:

• The correct or incorrect use of forms and off line files

• The adequacy of instructions for end-users on use of EHR
• Downtimes via web access through practice
• Downtimes via the EHR company of your systems is web based
• software bugs or glitches as described by end users
• Hardware issues

Overall, the computer systems worked as expected. The tutorials provided by the EHR
software is helpful, but most staff tend to refer to their hand-written notes that they took
during training. There are were no recorded down time of our software since
implementation, and no software bugs or glitches that were reported. Suggestions of what
they would like for future updates are collected. There were no hardware issues reported
by the staff at this time.

6.5 Peak Loads

Assess the ability of the system to handle patient volume at peak loads and to resolve
backlogs when they occur. Any offloading that could be helpful should be investigated.
Comments should address the following:

• The level of user satisfaction

• The adequacy of the response time (for online systems)
• The effect of delays on online and/or batch systems
• Suggested changes
• The effort required to make the changes

Even with the peak loads, both the hardware components and the EHR worked
flawlessly. Everyone is receptive of the new EHR system and they understand that it will
take time to get fully adjusted to the new system. Waverly has organized a monthly
meeting regarding the EHR software to talk about suggested changes that each member
believes will be beneficial to the clinic. Decisions are voted for approval and then
submitted to the EHR customer service for customization.
7 MAINTENANCE ACTIVITIES
The purpose of this section is to evaluate maintenance activity involving the EHR system
software and all hardware components.

7.1 Activity Summary

Provide a summary of maintenance activity to date. Provide type, number of actions, and
scope of changes required. Estimate a projected maintenance workload based on the
findings of the review. Discuss the adequacy of maintenance efforts or if major
enhancement/revision is required.

On the first week of each month each of the five workstations will be inspected and
cleaned. Externally the workstations will be dusted to prevent overheating and inspect for
any damages. Internally each workstation will run a series of cleaning and antivirus
software to ensure optimal efficiently.

7.2 System Maintenance

Discuss the system maintenance based on the design, types of changes required,
documentation, and knowledge about the system (both user and technical personnel).

There will be very little system design changed from the initial workstation and EHR
setup. Since PracticeFusion is a cloud base EHR system, majority of the software
maintience will be done through the internet. The hardware system maintenance will
primarily consistent of keeping the hardware dust free and proper RAM management
(clearing up cache, anti-virus, and other system enhancing functions) and will be
relatively be unchanged