Evaluation and Program Plan Submission

Sarah Armenio

University of San Diego

HCIN-542 02A

July 9, 2018

University of San Diego © 2016. All Rights Reserved.

1 Module 1 Workflow Diagram

Pharmacy Workflow Map Case Study

Customer

Customer
Customer arrives at
called to Customer Customer pays
Customer gets on pharmacy at 9am Customer asks Customer sits in Customer goes to Customer goes to Customer goes to
Start desk and provides PHI copay and exits Stop
bus to pharmacy and stands in line for question waiting area window sits in waiting area pharmacy window
asked to to technician pharmacy
prescription drop off
provide PHI

Yes
Pharmacy Clerk

Secretary answers
question

Secretary inputs Presecription

customers PHI: Does customer dropped in box for
Directs customer to
name, DOB, phone have any No technician
sit down
number, and questions?
prescription

No
Pharmacy Technician

Verifies the stock Generate printed

Technician reads Inform customer Technician acquires prescription bottle s
Is patient PHI verified label with PHI, Label put on bottle Bottle and original Calls customer to Deliver and explain Does the
prescription Pages customer to that it will be 25 correct medication contents with Answer questions
waiting for Yes in computer medication, dosage, and filled with prescription placed the pharmacy prescription to customer have Yes
window minutes to fill from the storage written prescription about prescription
prescription? by techician route, and medication in approval area window customer any questions?
prescription area
frequency

No

No
Pharmacist

Pharmacist reviews Signs off that

Walks bottle to
written prescription, Is prescription prescription
Yes approval box for
PHI, and bottle label filled correctly? is correct in
dispensing
info. computer

University of San Diego © 2016. All Rights Reserved.

Practice Fusion EHR Implementation
Module 2: Project Charter
A. General Information
Information to be provided in this section is general in nature and provides the necessary information about the
organization of the project and project participants.

Project Sponsor: Kurt Hanft

Project Manager: Sarah Armenio
Prepared by: Sarah Armenio
Date: May 29, 2018

B. Purpose
The purpose of this project is to implement the Practice Fusion electronic health record (EHR) at Waverly Family
Health Services. Practice Fusion EHR is a cloud-based, hosted EHR that will be used by Waverly Family Health Services
and technically maintained by Practice Fusion. Staff at Waverly Family Health Services will use this EHR for the
treatment and care of their patients. As part of this project, Waverly Family Health Services will transition from its
paper-based medical records system to an EHR. All paper medical records will be converted into the new EHR. Any
new treatment actions or records will be documented in the Practice Fusion EHR.

The goal of this project is to improve patient care and outcomes. Clinical decision support systems built into the EHR
can alert physicians to possible best courses of treatment or potential adverse drug interactions and allergies. Lab and
other physician orders will be streamlined and the results will be integrated with the patient’s record. The EHR will
improve access to medical records and help identify gaps in care.

C. Constraints and Assumptions

Constraints:
1. Budget will limit the software modules and functionalilty that can be purchased. The limited budget also
prevents any new hardware from being purchased. This may impact the design of the system.
2. Allotted time will limit the ability to plan, test, and train staff on the new EHR. Not all functionality of the EHR
may be able to be implemented due to the limited allotted time.
3. Existing hardware and monitors will be used. Access to the EHR will be limited to these existing workstations.

Assumptions
1. All necessary hardware and network requirements are already provided. Hardware upgrades will not be
necessary.
2. Waverly Health System assumes responsibility for the web installation and system conversion from paper
chart to digital content
3. Paper charts will be available for the conversion, testing, and validation of the solution.
4. Key stakeholders will be available to participate in key decisions and be involved throughout the entirety of
the project. Other staff will be available as necessary as subject matter experts to assist in the design of the
system.
5. All staff will be available for training on the new system.
6. The clinic is able to acquire necessary funds for the project using a small business development loan. All costs
including startup costs, labor, other hardware, and unforeseen costs will be covered through this loan.

D. Project Scope Statement

Waverly Family Health Services will implement the web-based EHR, Practice Fusion. The EHR will be hosted by
Practice Fusion but accessed via a web client at the Waverly Family Health Services locations. The EHR will be used
document patient visits, treatments, and history in a digital format. Staff will be able to view patient records from any
internet connected workstation and share any of the information on a monitor with a patient. The EHR will improve
the accessibility and retention of the medical records while decreasing physical storage for files.

Included in this project is the implementation of digital medical records, clinical decision support, and e-prescribing
functionality available in the EHR. This functionality will help identify gaps in care and streamline medication orders.
Implementation will also include appointment management, coding assistance, and billing services. It is expected that
this implementation will increase efficiencies in these processes, reduce errors, and improve patient satisfaction.
University of San Diego © 2016. All Rights Reserved.
Also included in this project is the complete conversion of all existing paper medical records into digital format in the
EHR. The backlog or existing paper records will either be scanned and attached to the patient’s digital record or
transcribed into discrete data in the EHR.

The project is expected to take six months. The budget for the project is $20,000 and includes all startup costs, labor,
other hardware, and unforeseen costs.

E. Resource Requirements
1. Adequate funds for purchasing or licensing software.
2. A staff project team to learn the new software and make key decisions for the implementation of the EHR at
the practice. Project team is responsible for all phases of the project including initiation, planning, execution,
and deployment. The team is also responsible for all developing testing scripts and a training plan for other
staff.
3. Up-to-date hardware that is capable of operating and accessing the new EHR at all necessary locations.
4. High speed Internet connection from the practice to the hosted EHR environment to reduce latency.
5. Staff available to complete the conversion of paper records to digital format. Records will be either scanned
or manually transcribed. Additional proper scanning hardware may be required for this purpose or for new
day-forward scanning processes.
6. The EHR is hosted by the software vendor and existing staff will be able to maintain the EHR after the
completion of the project. Staff, however, may need to pursue continuous education and training
development to support the solution into the future.

F. Risks
1. Inexperience of the staff with implementing an EHR
 May lead to inadequate decision making or less than ideal system design and implementation of the
Practice Fusion EHR. Failure to implement the EHR properly may require subsequent redesigns of
the system which would increase the cost, scope, and time allotted for the project.
2. Inexperience of the staff with using an EHR
 Significant end user training will be required.
3. Changes to current well known process
 Current processes may need to be changed to accommodate the new software for optimal
performance. Failure to adjust these processes in future paperless environment may result in
inefficient processes and delays in patient care or billing.
 Staff may resist changes to their current process and not embrace the new technology.
4. Limited budget ($20,000)
 Limited budget restricts the ability to hire experienced consultants to assist with the project. This
also reduces the ability to absorb errors or costly redesigns. Exceeding the budget may negatively
impact the operating budget for other business units or areas of the practice.
5. Limited time (6 months)
 The limited timeframe may not be long enough to properly understand all areas of the practice to
ensure a proper design of the system. It may also not be enough time learn the capabilities of the
EHR, implement the software, and train the end-users on new processes and software.

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

Success for this project will be determined by the following criteria:
1. Milestone 1: Completion of a solution discovery or project initiation phase that results in a Solution Design
(project scope document). The Solution Design is a detailed deliverable document that explains the current
business processes and any known issues or pain points. A future state for each of these processes is also
given with descriptions of how these business process will operate and potentially change after the EHR has
been implemented. Completion of Milestone 1 requires that the Solution Design be reviewed and approved
by all key stakeholders. This milestone is expected to be completed in one month’s time.
2. Milestone 2: Completion of project planning phase and delivery of Project Plan. After review of the Solution
Design, a project team will be assembled to plan the work that needs to be completed. A communication
plan should be established to inform all stakeholders in the project on progress and updates. Roles and

University of San Diego © 2016. All Rights Reserved.

 responsibilities are established for the project team and the project plan establishes a timeline for work to be
completed. This Milestone is expected to be completed in two weeks’ time.
3. Milestone 3: Completion of the project execution phase with end-user acceptance testing and sign-off. All
historical patient records must also be converted from paper to digital format. The project team will follow
the project plan and complete assigned tasks as required. The team will be able to adapt the project plan and
task as necessary and as issue arise throughout the execution of the project. Once key components of the
EHR are implemented, staff at Waverly Family Health Services will access a test environment of the system to
provide feedback on the solution to the project team. Changes will be made to the software and solution as
necessary. Once the final changes are made, staff will sign-off on the solution to accept that the solution will
meet their business processes and requirements. This Milestone is expected to be completed in three
months’ time.
4. Milestone 4: Completion of the project testing or quality assurance phase, training of end users, and
migration to Production. Once the solution has been accepted by end-users, the project team will rigorously
test the solution in a variety of test scenarios or scripts. These test script should be developed with end users
and align to the expected business processes of staff. Any technical issues discovered through these test
scripts will be corrected by the project team. All test scripts must pass for this Milestone to be considered
complete. Training on the EHR will be provided by the appropriate resources on the project team to all staff.
Training should accurately represent the day-forward processes for staff. Once the solution is finalized, the
solution is locked from any additional changes and the solution is migrated to a production environment with
real patient data. The production environment is to be used by the end users once validation and testing is
complete. This phases is expected to be completed in one month’s time.
5. Milestone 5: Competition of Go-Live and solution monitoring. Once the solution is implemented, staff will
switch to using the EHR as part of their normal workflows. Any issues reported during this phase should be
documented and addressed by the project team. The project team will also be available to answer any
questions, make changes to the EHR, or provide additional training. After initial Go-Live, the solution will be
actively monitored and re-evaluated to ensure that the EHR is working as desired and that the goals of the
implementation project are met. Completion of this milestone is expected to be completed in 2 weeks’ time.

Upon completion of all milestones, staff will be able to access the EHR from any workstation vat Waverly Family
Health Services. Staff will be able to utilize the advantages of the EHR including clinical decision support, e-
prescribing, billing services, scheduling systems, and coding assistance. A complete historical record of all
patient’s paper records will be available in digital format from the EHR.

F. Key Stake Holders

 Dr. Waverly, clinic owner and medical director
 Dr. Jones, physician and clinic partner
 Mrs. Jones, clinic director

F. Executive Summary
The purpose of this project is to implement the Practice Fusion EHR at Waverly Health Services. The project is
expected to last six months at a cost of $20,000. The budget and expected timeframe for the project are known
constraints that limit the scope of the project to only existing hardware in the organization. Several assumptions were
made for the project to be successful including the ability for staff to be available to assist the implementation of the
project and that existing computer hardware and networks can be used for the project. It is also assumed that paper
charts will be readily available during the project to be converted to digital format.

The Practice Fusion EHR will be hosted by the vendor and the vendor will provide all necessary support. No new
servers or other hardware is expected to be required. All existing paper medical records will be converted to digital
format.

The project requires adequate funding and a dedicated project team to lead the implementation of the project. Other
staff and key stakeholders will be required to be available as necessary to assist the project and receive training
regarding the new software. Ongoing training may be required after completion of the project to support the solution
into the future.

Risks to the project include limited budget and time along with inexperience staff members assuming responsibility of
the project. Changes to current process to support the new EHR may cause short term difficulties and resistance to
University of San Diego © 2016. All Rights Reserved.
accept the new solution. However, these difficulties are outweighed by the long-term benefits of the EHR for the
organization and its patients. Success will be measured by the completion of 5 key milestones of the project each with
one or more accompanying deliverables.

Upon completion of the project, the EHR will be available from any existing Waverly Health Services workstation with
built in features including clinical decision support, e-prescribing, and billing services among others. These
enhancements are expected to improve patient care and streamline processes.

University of San Diego © 2016. All Rights Reserved.

Module #3: Work Break Down Structure

2 Milestones

Milestone Description Delivery Date

Charter approved The Business Case has been documented 06/15/2018
and was approved by the Project Sponsor.
Completion Planning WBS approved 07/07/2018
and Sign-Off on Work
Break Down Structure

End-User Acceptance Staff perform sample routine tasks in test 10/05/18

Sign-off environment and accept the design of the
solution.
Completion of QA All technical and business aspects of solution 10/22/18
Quality Assurance Review and accepted. All
test cases passed.
Migration to Test environment is migrated to Production 11/06/18
Production
environment
End-user Training All staff are trained on new solutions and 11/06/18
workflows in HER
Go-Live Staff use the Production system for daily 11/07/2018
work.

3 Phases

Phase Description © Sequence

Project Initiation Defining the project by developing a Project Phase # 1
Charter as well as recruiting the project team.
Project Planning Develop Work Break Down Structure and Phase # 2
establish roles and responsibilities. Project
plan established and signed off.
Execution Configuration of all technical components of Phase # 3
the solution. Patients loaded into EHR and
paper documents are converted to digital in
EHR.
Testing, Migration, Test scripts are developed and executed for Phase # 4
Training all technical and business aspects of the
solution. Once all test scripts are passed, the
solution is migrated from the test environment
to production. Concurrently, end-users are
being trained on the new workflows.
Go-Live Support and Go-Live is the day that staff beginning using Phase # 5
Optimization the EHR in their normal work. Troubleshooting
and additional training should occur as
necessary. Processes should be monitored
for possible design errors and opportunities
for optimization.

4 Activities
An activity is “a set of tasks which are required to be undertaken to complete the project." Examples
include:

 Develop Quality Plan

University of San Diego © 2016. All Rights Reserved.
 Formulate Supplier Contracts
 Perform Project Closure.

List and describe the major project activities within the following table.

Phase Activity Description © Sequence

Project Deliver Project Analyse the requirements, assumptions, First
Initiation Charter and constraints to determine the scope
of the project and draft a Project Charter
Project Sign off on Once drafted, the Charter needs to be After Project Charter is
Initiation Project Charter approved by all Key Stakeholders. drafted
Revisions may be required
Project Deliver Work Identify task to be completed, time to After Project Chart, but
Planning Break Down complete, and lead resource before any execution or
Structure implementation
Project Establish Document the communication plan that After work break down
Planning Communication will serve to educate the staff on structure
Plan changes and how they can expect to
receive information related to the project
Project Communicate In accordance with Communication After communication
Planning Roles and Plan, explain the roles and responsibility plan, but before any
Responsibilities of all project team members, key execution of work
stakeholders, and other staff.
Execution Configuration Lead resources are responsible for After project planning.
Phase of EHR understanding their assigned business Must be complete
components process and how the process will work before any end-user
in the future state. Resource is acceptance testing
responsible for configuring their module
in the EHR and being a super-user of
the module
Execution Patient back- All existing patients need to be entered Can begin once some
Phase load into EHR into the EHR. Care should be given to initial configuration of
include any new patients that are the EHR is complete. It
created between the time when this is usually best to wait as
patient-load process starts and Go-Live long as possible to do
(the “delta” period). this to reduce the “delta”
period (and reduce risk
of missing patients)
Execution Conversion of All existing paper medical record either Cannot begin until after
Phase paper records need to be scanned and associated to the initial patient
the patient in the EHR or the paper backload/.
record needs to be dictated into the
EHR.
Execution User Develop test scripts that fit normal Cannot begin until after
Phase Acceptance processes. Users will test the EHR and the EHR is initially
testing (UAT) configured module to ensure that the configured and modules
and sign-off design of the solution will meet their are complete.
requirements.
Testing, Final QA of All test scripts must be passed. Final After user-acceptance
Migration, Solution changes from UAT tested. All technical testing, but before
Training aspects of solution tested Try to break it. migration to production

Testing, Migration from All data and solutions in EHR migrated After Final QA and UAT
Migration, Test to from test environment to production. sign-off
Training Production System is on lock-down with no more
changes allowed without committee
approval.
Testing, End-User Users are trained on the system in a test After final UAT, but can
Migration, Training or training environment of the EHR be during migration to
Training Production

University of San Diego © 2016. All Rights Reserved.

 Go-Live Go-Live Key stakeholders evaluate the state of After move to migration
and the solution and if the solution is ready and Go/No-Go Decision
Support to determine no/no-go decision. If a
“Go,” Go-Live initiates as scheduled and
staff use the EHR in Production
environment with real patient data and
perform normal daily duties. Staff is
available for questions, training, issues,
and troubleshooting

5 Tasks
A ‘task’ is simply an item of work to be completed within the project. List all tasks required to
undertake each activity, within the following table:

Phase Activity Task Sequence

Project Initiation Deliver Project Identify Purpose 1st

Charter Identify Constraints and Assumptions 2nd
Identify Resource Requirements 3rd
4th
Identify Stakeholders
5th
Identify Risks 6th
Identify Success Criteria 7th
Identify Scope of Project 8th
Draft Executive Summary 9th

Project Initiation Approval of Meeting to review Project Charter 1

Project Charter Gather feedback and incorporate changes 2
Approval of revised Project Charter 3

Project Planning Deliver Work Identify tasks to be completed 1st

Break Down Estimate time necessary for tasks 2nd
Structure Identify Lead Resource for tasks 3rd
Determine criteria of success of tasks 4th

Project Planning Establish Organize staff list with roles and dept. lead 1
Communication Draft document on how updates 2
Plan communicated
Establish physical location for 3
communication if necessary
Project Planning Communicate Communicate to each staff their assigned 1
Roles and roles
Responsibilities Field questions on expectations and issues 2

Execution Phase Configuration Configuration main EHR functionality 1 (concurrent)

of EHR Configuration of CDS module 1 (concurrent)
components Configuration of e-Prescribing module 1 (concurrent)
Configuration of Appointment Management 1 (concurrent)
module
Configuration of coding assistance module 1 (concurrent)
Configuration of billing services module 1 (concurrent)
Patient back-load into EHR 2
University of San Diego © 2016. All Rights Reserved.
 Conversion of all existing paper records 3
Develop UAT test scripts 4
Initial user acceptance testing 5

Testing, Migration, Final QA of Implement any final changes from UAT 1

Training Solution Develop QA test Scripts 2
Execute/Pass all QA scripts 3
Final UAT sign-off 4

Testing, Migration, Migration from Migration of patients to Prod 1

Training Test to Migration of patient data and documents to 2
Production Prod
Migration of all solutions and workflows o 3
Prod

Testing, Migration, End-User Develop training plan 1

Training Training Develop and print training material 2
Hold training sessions 3
Hold follow-up or continuous training session 4

Go-Live and Support Go-Live Go/No-Go Decision 1

Technical switch to Production environment 2
(turn it “on”)’
Support and training 3 (concurrent)
Issue tracking and resolution (ticketing 3 (concurrent)
system)
Analysis of solution and optimization 4

6 Effort
For each task listed above, quantify the likely ‘effort’ required to complete the task.

Activity Task © Effort

Deliver Project Identify Purpose 23 days total
Charter Identify Constraints and Assumptions
Identify Resource Requirements
Identify Stakeholders
Identify Risks
Identify Success Criteria
Identify Scope of Project
Draft Executive Summary
Sign off/Acceptance of Meeting to review Project Charter 1 Day
Project Charter Gather feedback and incorporate changes 5 Days
Approval of revised Project Charter 1 Day
(7 Total)

Deliver Work Break Identify tasks to be completed 3 Days

Down Structure Estimate time necessary for tasks 1 Day
Identify Lead Resource for tasks 1 Day
Determine criteria of success of tasks 2 Days
(7 Total)

Establish Organize staff list with roles and dept. lead 1 Day
Communication Plan Draft document on how updates communicated 2 Days
Establish physical location for communication if 1 Day
necessary (4 Total)

University of San Diego © 2016. All Rights Reserved.

 Communicate Roles Communicate to each staff their assigned roles 1 Day
and Responsibilities Field questions on expectations and issues 2 Days
(3 total)

Configuration of EHR Configuration main EHR functionality 55 Days

components Configuration of CDS module 55 Days
Configuration of e-Prescribing module 55 Days
Configuration of Appointment Management module 55 Days
Configuration of coding assistance module 55 Days
Configuration of billing services module 55 Days
Patient back-load into EHR 14 Days
Conversion of all existing paper records 45 Days
Develop UAT test scripts 7 Days
Initial user acceptance testing 27 Days
(90 Days Total)

Final QA of Solution Implement any final changes from UAT 3 Days

Develop QA test Scripts 3 Days
Execute/Pass all QA scripts 7 Days
Final UAT sign-off 1 Day
(14 Days Total)

Migration from Test to Migration of patients to Prod 5 Days

Production Migration of patient data and documents to Prod 5 Days
Migration of all solutions and workflows to Prod 4 Days
(14 Days Total)

End-User Training Develop training plan 5 Days

Develop and print training material 5 Days
Hold training sessions 2 Days
Hold follow-up or continuous training session 2 Days
(14 Days Total)

Go-Live Go/No-Go Decision 1 Days

Technical switch to Production environment (turn it “on”)’ 1 Day
Support and training 14 Days
Issue tracking and resolution (ticketing system) 14 Days
Analysis of solution and optimization 14 Days
(15 Days Total)

7 Resources
For each task identified, list the resources allocated to complete the task.

Activity Task Resource

Deliver Project Charter Identify Purpose Sarah Armenio
Identify Constraints and Assumptions Sarah Armenio
Identify Resource Requirements Sarah Armenio
Identify Stakeholders Sarah Armenio
Identify Risks Sarah Armenio
Identify Success Criteria Sarah Armenio
Identify Scope of Project Sarah Armenio
Draft Executive Summary Sarah Armenio
Sign off/Acceptance of Meeting to review Project Charter Sarah Armenio
Project Charter Gather feedback and incorporate changes Sarah Armenio
Approval of revised Project Charter Sarah Armenio
Deliver Work Break Down Identify tasks to be completed Sarah Armenio
Structure Estimate time necessary for tasks Sarah Armenio
Identify Lead Resource for tasks Sarah Armenio
University of San Diego © 2016. All Rights Reserved.
 Determine criteria of success of tasks Sarah Armenio

Establish Communication Organize staff list with roles and dept. lead Sarah Armenio
Plan Draft document on how updates communicated Sarah Armenio
Establish physical location for communication if Sarah Armenio
necessary
Communicate Roles and Communicate to each staff their assigned roles Sarah Armenio
Responsibilities Field questions on expectations and issues Sarah Armenio
Configuration of EHR Configuration main EHR functionality Mrs. Wright
components Configuration of CDS module Mrs. Johnson
Configuration of e-Prescribing module Mrs. Johnson
Configuration of Appointment Management Ms. Felps
module
Configuration of coding assistance module Mr. Lawrence
Configuration of billing services module Mr. Lawrence
Patient back-load into EHR Mr. Lawrence
Conversion of all existing paper records Ms. Smith
Develop UAT test scripts Sarah Armenio
Initial user acceptance testing Sarah Armenio

Final QA of Solution Implement any final changes from UAT Mrs. Wright
Develop QA test Scripts Ms. Felps/Mrs.
Execute/Pass all QA scripts Wright/Mrs.
Final UAT sign-off Johnson/Mr.
Lawrence

Migration from Test to Migration of patients to Prod Ms. Smith

Production Migration of patient data and documents to Ms. Smith
Prod
Migration of all solutions and workflows to Prod Mrs. Wright

End-User Training Develop training plan Sarah Armenio

Develop and print training material Sarah Armenio
Hold training sessions Sarah Armenio
Hold follow-up or continuous training session Sarah Armenio
Go-Live Go/No-Go Decision Key Stakeholders
Technical switch to Production environment Mrs. Wright
(turn it “on”)’
Support and training Project Team
Issue tracking and resolution (ticketing system) Sarah Armenio
Analysis of solution and optimization

University of San Diego © 2016. All Rights Reserved.

8 Project Plan

8.1 Schedule(Gantt chart)

Note: Refer to the Appendix for a detailed project schedule.

8.2 Dependencies

Activity Depends on © Dependency Type

Sign off/Acceptance of Deliver Project Charter Finish-to-start
Project Charter
Deliver Work Break Sign off/Acceptance of Project Finish-to-start
Down Structure Charter
Establish Deliver Work Break Down Finish-to-start
Communication Plan Structure
Communicate Roles Finish-to-start
and Responsibilities Establish Communication Plan
Configuration of EHR Communicate Roles and Finish-to-start
components Responsibilities
Conversion of all Patient back-load into EHR Finish-to-start
existing paper records
QA of conversion data Conversion of all existing paper Finish-to-start
records
UAT testing and sign- Configuration of EHR Finish-to-finish
off components
Final QA of Solution Development of Test Scripts Start-to-finish
Migration from Test to Final QA of Solution Finish-to-start
Production
End-User Training Final QA of Solution Start-to-start
Go-Live End-User Training Finish-to-start

University of San Diego © 2016. All Rights Reserved.

8.3 Assumptions
4. All necessary hardware and network requirements are already provided. Hardware
upgrades will not be necessary.
5. Waverly Health System assumes responsibility for the web installation and system
conversion from paper chart to digital content
6. Paper charts will be available for the conversion, testing, and validation of the solution.
7. Key stakeholders will be available to participate in key decisions and be involved
throughout the entirety of the project. Other staff will be available as necessary as subject
matter experts to assist in the design of the system.
8. All staff will be available for training on the new system.
9. The clinic is able to acquire necessary funds for the project using a small business
development loan. All costs including startup costs, labor, other hardware, and unforeseen
costs will be covered through this loan.

8.4 Constraints

1. Budget will limit the software modules and functionality that can be purchased. The limited
budget also prevents any new hardware from being purchased. This may impact the design
of the system. The project must operate within the funding and resource allocations
approved.
2. Allotted time will limit the ability to plan, test, and train staff on the new EHR. Not all
functionality of the EHR may be able to be implemented due to the limited allotted time.
Project must be completed by Go Live.
3. Existing hardware and monitors will be used. Access to the EHR will be limited to these
existing workstations.

University of San Diego © 2016. All Rights Reserved.

9 Module 4: Failure Mode Effects Analysis
Process analyzed: Reviewing patient’s chart at clinician's work station that is in a
dedicated clinical room and entering in physician notes into EHR

Team leader: Dr. Jones, Physician

Team members:

Name Position Name Position

Physician’s
Dr. Jones Physician Mrs. Johnson
Assistant
MA, Back office
Ms. Smith Mr. Pink IT Staff
medical assistant

Describe your process steps (flowchart):

University of San Diego © 2016. All Rights Reserved.

 Start

Patient enters room

Physician assistant
takes vitals and basis
info for visit

Physician enters and

review patient chart
in EHR

Physician asks
questions and
documents info in
EHR, tests or follow-
ups ordered

Patient leave clinical

room

End

Identify what could go wrong during each step of the process.

University of San Diego © 2016. All Rights Reserved.

Step 1: Patient enters room.

Failure Mode: In this step, it is possible for the patient to enter the wrong room, but
otherwise few failure modes identified as the patient is escorted by the physician’s
assistant.
Severity: 1 (near miss)
Probability: 2 (low)

Step 2: Physician Assistant takes vitals and documents reason for visit. Enters
information into EHR.

Failure Mode: Hardware failure

Severity: 4 (major)
Probability: 2 (low)

Failure Mode: Network failure (on-site at clinic)

Severity: 5 (catastrophic)
Probability: 2 (low)

Failure Mode: Internet Failure (off-site either Internet or in cloud/hosted site)

Severity: 5 (catastrophic)
Probability: 2 (low)

Failure Mode: Power Outage

Severity: 5 (catastrophic)
Probability: 2 (low)

Step 3: Physician enters and review patient chart in EHR

Failure Mode: Hardware failure

Severity: 4 (major)
Probability: 2 (low)

Failure Mode: Network failure (on-site at clinic)

Severity: 5 (catastrophic)
Probability: 2 (low)

Failure Mode: Internet Failure (off-site either Internet or in cloud/hosted site)

Severity: 5 (catastrophic)
Probability: 2 (low)

Failure Mode: Power Outage

Severity: 5 (catastrophic)
Probability: 2 (low)

Step 4: Physician asks questions and documents information in EHR. Tests ordered
and follow-ups scheduled if necessary.

Failure Mode: Hardware failure

Severity: 4 (major)
Probability: 2 (low)
University of San Diego © 2016. All Rights Reserved.
 Failure Mode: Network failure (on-site at clinic)
Severity: 5 (catastrophic)
Probability: 2 (low)

Failure Mode: Internet Failure (off-site either Internet or in cloud/hosted site)

Severity: 5 (catastrophic)
Probability: 2 (low)

Failure Mode: Power Outage

Severity: 5 (catastrophic)
Probability: 2 (low)

Step 5: Patient leaves clinical room

Failure Mode: In this step, it is possible for the patient not leave or leave to the
wrong area, but otherwise few failure modes identified as the patient is escorted by
the physician’s assistant.
Severity: 1 (near miss)
Probability: 2 (low)

Root Cause Specific Actions to

Process Responsible
of Process Reduce or Eliminate Completion Time Frame
Failure Individual/Group
Failure the Failure

Clinical CPU
Routine checks and
Workstation malfunctionin
tests of hardware. 1 week Mr. Pink
hardware g or old
Replacement if needed
failure equipment
Onsite Create downtime
Router or ISP
Network procedure with paper 1 month Ms. Smith
down
Failure documentation
Poor Weather Create downtime
Power
or facility procedure with paper 1 month Ms. Smith
Outage
failure documentation
Internet
Failover plan to backup
failure-
Main Hosted EHR site or downtime
Inability to 1 month Ms. Smith
EHR down procedure using paper
access EHR
documentation
remotely

Measures of Success

Measure(s) of Success
(How we will

know if this action is successful)
 Reporting Schedule and
Corrective Action (Consider measures of how often the Individual or
failure is still occurring after process
changes and the incidence of adverse Group Responsible for

University of San Diego © 2016. All Rights Reserved.

 events related to the failure) Reviewing Results

Reduction in unexpected hardware

failures. These failures are prevented
through regular diagnostic checks and
Routine diagnostic proactive hardware replacements when
checks and tests of necessary (before failure occurs). Staff System Diagnostics checks
Hardware and Network should keep metrics of failures before reviewed once per week
in clinical rooms and after implementation of Correction
Action. Diagnostic checks should be
tracked to ensure they are completed
as scheduled.

Documented downtime
procedure to use paper When a downtime does occur, staff will
medical records when have all necessary paper forms to
EHR is not accessible continue to fulfill duties (paper forms Procedures reviewed once
for any always available) and staff is aware of per month
hardware/network the procedure when such events occur.
failure or power When procedure
outage.

Signature of FMEA leader/facilitator__________________________ Date __________

University of San Diego © 2016. All Rights Reserved.

10 Module 5: 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.

10.1 Stakeholder Interview

Category Name Objectives/Questions

Topics to Cover (adjust as necessary):
 Special Interests
 Influence
 Dependencies
 Critical Timelines / Risks
 Actions required
Non clinical Staff All stakeholders in this category will be using the
(could be listed by  Ms. Felps, Front new EHR in their day-to-day operations. Should
department or Desk Clerk have influence into the design of the project specific
agency)  Ms. Smith, back to their functions. These staff members may also be
office MA participating on the project team to implement the
 Mr. Lawrence, EHR. They should participate in project meetings
clinical accounts and be tasked with completing certain actions or
and billing testing according to the project timeline and project
plan.

Questions:
 Describe your current process for checking in a
patient.
 What is the process for filing a patient’s chart
today and any new documentation created during
a visit?
 How are patients billed today? How do you track
outstanding balances.
 Will you have time to learn the new system?
 Will you be able to participate in assigned tasks
along with your current responsibilities?
 Do you need anything before you can begin
work on the project?
 What do you hope to gain from the
implementation of the EHR?
Clinical staff (could  Dr. Waverly, All stakeholders in this category will be using the
be listed by clinical owner new EHR in their day-to-day operations. Should
department or and medical have influence into the design of the project specific
agency) director to their functions. These staff members may also be
 Dr. Jones, participating on the project team to implement the
physicians and EHR. They should participate in project meetings
clinic partner and be tasked with completing certain actions or
University of San Diego © 2016. All Rights Reserved.
  Mrs. Johnson, testing according to the project timeline and project
physician plan.
assistant
 Mrs. Wright, Additionally, these staff members have a specific
nurse practitioner clinic focus and use of the EHR. This group will
need to be the most familiar with the EHR’s clinical
functions since they will be using it to care for
patients. This group will be especially important in
end-user acceptance testing. However, a risk to the
project is that this group is also already completing
full-time work to care for patients. Fitting in training
or testing will be a challenge with patient and
operational priorities, however such tasks are critical
to the success of the project. They need to be made
aware of the importance of this training and testing.

Questions:
 What is the current process for treating a patient
when they are seen at the practice?
 Will you have time to learn the new system?
 Will you be able to participate in assigned tasks
along with your current responsibilities?
 Do you need anything before you can begin
work on the project?
 What do you hope to gain from the
implementation of the EHR?
Admin staff(this These are key stakeholders and should be champions
might include your  Dr. Waverly, of the project. They need to understand the
practice manager clinical owner criticality of the project and be able to convey this
and medical and medical message to other staff. They will set the vision for
director) director the future state in the practice. These stakeholders
 Dr. Jones, will be the final decision makers and should be
physician and engaged when major roadblocks or issues occur.
clinic partner Risks include lack of availability of these
 Mrs. Jones, clinic stakeholders due to competing priorities or existing
director commitments. However, it is critical that they are
involved in any key decisions and sign off of the
project plan. They may not be involved in all
implementation actions or tasks, but should be aware
of all milestones and progress.

Questions:
 Will you be able to participate in key meetings
and decisions?
 Who will make decisions on key items if you are
not available?
 Will you accept the decisions of the project team
even if they may differ from your own?
 What if more or budget is necessary for the
project?
 What do you hope to gain from the
implementation of the EHR?
University of San Diego © 2016. All Rights Reserved.
Outside personal or Will not be involved directly in the decisions or
agencies  CMS influence the project. However, the implementation
 Insurance/Payers of the EHR and billing system may affect how
payments or communication with these agencies are
received and processed. Communication with payers
may need to be initiated to determine if any changes
are needed that would affect the project.

Questions:
 Are there any changes to the current processes
with the introduction of the EHR?
 Do we need to develop any cut over plan for
paying for services during this transition?
Vendors All vendors should be aware of when the
 Practice Fusion implementation will occur. Prior communication
 Internet Service may be necessary to ensure that technical support is
Provider available during Go-Live. The ISP may need to be
 Hardware/IT engaged to ensure that the connection speed and
vendor bandwidth will be sufficient to access the hosted
EHR. IT vendor should be engaged for any
hardware or network issues and an evaluation of
hardware compatibility with the EHR should be
conducted. Practice Fusion should be heavily
engaged to provide guidance, support, and general
training throughout the whole implementation and
beyond. None of these stakeholders necessarily have
decision capabilities on the project, but they may
influence the project and adjust timelines for tasks
based on their availability.

Questions:
 Are you available during Go-Live to provide
support if necessary?
 What hours is support available?
 What if any issue occurs off-hours?
 What if we need a technician onsite? How soon
could someone be on-site?
 Is there any preparatory work necessary for the
EHR?
Patients Patients Patients will not directly impact the project or make
decisions. However their feedback and input will be
critical to measuring the success of the project.
Providing better patient care is a goal of the project
and as such, understanding how patients will be
affected is important to the project. Risks include
longer than normal wait times or confusion during
Go-Live as staff adjusts to the new system. This may
initially decrease patient satisfaction and care.
However, long term goals are for higher patient
satisfaction. No specific actions required of this
stakeholder, however patient satisfaction survey
prior to and after implementation may be helpful.

University of San Diego © 2016. All Rights Reserved.

 Questions:
 How satisfied are you currently with the
management and care at the practice?
 Is there anything that you would like to see
introduced with the EHR?
 What do you hope to gain from the
implementation of the EHR?

Misc.

External to Clinic Competing organizations or hospitals may need to

(this could be  Nearby hospitals interact differently with the practice once the EHR is
outside  Competing implemented. There may need to be a new process
organizations like Clinics/Practices for referrals to capture all documentation
practices that have electronically. These organizations will not directly
a contract for influence the project, but any interactions or process
referring patients) involving other organization should be evaluated as
part of the project.

Questions:
 Are there any changes to the current processes
with the introduction of the EHR?
 Do we need to develop any cut over plan for
paying for services during this transition?
Finance Provided loan of $20,000 for project. While not a
 American direct influencer of the project, the amount of money
Express loaned is a risk to this organization. If the project
cannot adhere to the original budget additional funds
may need to be borrowed from the stakeholder. This
would be considered an increase in risk to the
project.

Questions:
 What if additional funds are necessary for the
project?
 What is the re-payment plan for the loan?

University of San Diego © 2016. All Rights Reserved.

 11 Module 6: Go-Live Checklist
Comple
Task Practice lead Due date ted?

Staff Readiness

1 1 months prior: Develop training plan and material Sarah 10/23/18

Armenio

2 2 weeks prior: Front Desk staff EHR training Ms. Felps 10/24/19

3 2 weeks prior: Clinical Staff EHR Training Mrs. Johnson 10/24/18

4 2 weeks prior: Back-office and financial training Mr. Lawrence 10/24/18

5 2 days prior: Create training “Cheat Sheets” and have available at Sarah 11/05/18
workstations Armenio

6 Day prior: Ensure all staff have interacted and tested the EHR on Sarah 11/06/18
their own time for training and readiness. Go/No-Go Decision Armenio

Hardware

7 1 month prior: Create inventory of all workstations for EHR use Sarah 10/07/18
Armenio

8 1 month prior: Confirm hardware and network compatibility and Mrs. Wright 10/12/18
readiness for all workstations

9 Completed 1 week prior: Test access to EHR and all workflows at Mrs. Wright 11/01/18
workstations

10 2 weeks prior: Install any scanners at necessary workstations Ms. Felps 10/23/18

Downtime procedures

11 1 month prior: Downtime procedures created for all scenarios Sarah 10/07/18
Armenio

12 2 weeks prior: Staff trained on all downtown procedures Mrs. Wright 10/23/18

13 Day prior: All paper downtime forms printed and available Ms. Felps 11/05/18

14 Day prior: Downtime procedure process printed and available Ms. Felps 11/05/18

Data Migration

15 3 months prior: All patients created or back-loaded into Production Mr. Lawrence 8/15/18
EHR

University of San Diego © 2016. All Rights Reserved.

16 Day prior: All workflows migrated from test to production Mrs. Wright 11/06/18

17 2 months prior: All patient records scanned or converted to EHR Ms. Smith 9/30/18

18 1 months prior: Proactively communicate with patients (e.g., send Sarah 10/07/18
informational letter). Armenio

University of San Diego © 2016. All Rights Reserved.

12 Module 7: Post-Implementation Review Report

1 INTRODUCTION

1.1 Project Identification

Practice Fusion EHR Implementation at Waverly Family Health Services

1.2 System Proponent

Practice Fusion EHR (cloud hosted)

1.3 History of the System

Waverly Family Health Services has used paper medical records for the treatment of patients.
Only one person at a time can view a patient’s paper medical records. These records require
handwritten notes for documenting the treatment of the patient.

The purpose of this project is to implement the Practice Fusion electronic health record
(EHR) at Waverly Family Health Services. As part of this project, Waverly Family Health
Services will transition from its paper-based medical records system to an EHR. All paper
medical records will be converted into the new EHR. Any new treatment actions or records
will be documented in the Practice Fusion EHR. The goal of this project is to improve patient
care and outcomes.

1.4 Functional System Description and Data Usage

Clinical decision support systems built into the EHR can alert physicians to possible best
courses of treatment or potential adverse drug interactions and allergies. The EHR will
improve access to medical records and help identify gaps in care.

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

Overall users are now satisfied with the benefits of the EHR. Less time is spent retrieving
medical records and multiple users can view the records simultaneously. However, there was
initial frustration learning the new system during Go-Live understanding changes to
established workflows. Clinicians are spending more time charting and documenting patient
care. This caused delays for patients and common processes took longer than normal. These
delays seem to have since subsided and process times have returned to normal or have seen
improvements in some areas. Additionally, clinicians understand the long-term benefits of
data entry and entering notes.

Computer physician order entry (CPOE) functionality is used regularly and has reduced
confusion for orders or prescriptions. Increased accuracy should reduce adverse events.
Clinicians also regularly check alerts and notifications for their patients.

The scope of the project was sufficient for timeline. However additional modules for billing
processes could be added as a future enhancement to the system.

2.2 Current Cost-Benefit Justification

The cost of the system is justified by its benefits. Costs included the software purchase,
University of San Diego © 2016. All Rights Reserved.
 continual maintenance of the system, and time of the staff partaking in the implementation.
Benefits include patients experiencing a higher quality of care with less risk for adverse event
do to CPOE and active alerts and reminders for recommended preventative care.
Additionally, by implementing the EHR, the practice is no longer subjected to penalties or
reduced payments from the Center for Medicare and Medicaid Services (CMS) as part of
meaningful use requirements of the HITECH Act.

2.3 Needed Changes or Enhancements

Needed changes include the necessity of a test environment to train new staff or to reinforce
training for current staff without risk to production data.

Additionally, few billing modules were implemented with the EHR. The organization should
purchase additional modules from Practice Fusion to improve the insurance denials process
and other patient billing or correspondence processes.

Finally, there are few direct integrations with external labs or other diagnostic testing sites.
Staff spends a significant amount of time manually keying result data or scanning paper to be
associated with the patient’s chart. The organization should investigate integrations with
common lab partners to reduce the amount of paper results.

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

The purpose of this project was to implement the Practice Fusion electronic health record
(EHR) at Waverly Family Health Services and convert all existing medical records into the
EHR. To this extent, the project goals were mostly achieved.

All project milestones were completed with the exception of completing the full patient paper
record conversion. Due to the staff’s existing responsibilities, not enough time or resources
were dedicated to scanning and converting the existing paper records into the EHR. Only 60%
of patients records were able to be converted by time of Go-Live. However, since the project
gave priority for the conversion to those patients that had existing appointments, all of the
most immediately needed records were available in the EHR by Go-Live. The conversion of
the remaining paper records will continue post implementation.

3.2 Scope
The project scope was ambitious for a practice that had limited previous experience with
implementing an EHR and limited exposure to best practices or outside consultations.
Additionally, the requirement that all paper records be converted into the EHR may have
been unnecessary as some patients have not been seen by the practice in several years and are
unlikely to be seen again by the practice. Changes to the scope should have included a year
limit for the number of historical records converted.

3.3 Benefits
The goal of this project was to improve patient care and outcomes. Clinical decision support
systems built into the EHR now alert physicians to possible best courses of treatment or
potential adverse drug interactions and allergies. Labs and other physician orders are now a
part of the patient’s record and provide a comprehensive view of the patient’s past treatment.
There is also improved access to the medical records and assistance in identifying gaps in care
University of San Diego © 2016. All Rights Reserved.
 and routine, preventative treatment. These features highlight the benefits of the system

3.4 Development Cost

The cost to implement the system was generally on target. The project could have benefitted
from external consultation to supplement the project as the staff took on extra tasks in
addition to their daily responsibilities. However, external consultation would have been very
costly and not within the budget of the project.

While the organization obtained a loan to cover the initial costs, costs for maintenance of the
hosted system will be ongoing and the organization will need to be budget for in the future.

Budget: $25,000

Actual Cost:
 Hardware Costs: None. Existing hardware and network used.
 Software Cost: Subscription based at $500/month for 3 physicians
 Staff Implementation Cost: Overtime paid to complete project tasks: $17,000 over
6 months.
 Facility and Resources Costs: Minimal to print training material.
 External Cost: $5000 for vendor support

3.5 Operating Cost

Operating costs are expected to be $500 per month paid to the vendor for hosting the EHR.
Additional operating costs will include regular maintenance and upgrades to the hardware and
network. The organization will need to budget for these costs going forward.

3.6 Training
While training was timely, several questions could not be answered during the training
sessions. This could be due to lack of familiarity with the new software. Certain processes and
functionality may need further evaluation to ensure that the staff is comfortable with all
aspects of the solution. Additionally, even though staff was supposed to make time to
familiarize themselves with the software, many were unable to do so on their own time.
Therefore, staff forgot some aspects of the training in the time between the train sessions and
Go-Live. Additional “refresher” sessions should be held with the staff. Also, a training
environment should be made available to the staff to practice certain activates without
impacting real patient data.

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: Some process are not user friendly or take an excessive amount of “clicks.”
This has resulted in additional time to complete some processes such as checking a
patient in for an appointment. Patients still complete a paper check-in form, but now that
information needs to be transcribed into the EHR or scanned. However, usability is

University of San Diego © 2016. All Rights Reserved.

 acceptable once the users became comfortable with the system and new processes.
System was not intuitive initially.
 Absolutely essential (does it effectively replace the paper based system): Yes. The EHR
is now instrumental for the treatment of patients. Very rarely are paper records being
pulled for view.
 Incomplete – some information occasionally missing from the EHR for the paper record
due to missed conversion components, but overall the information is there. Occasionally
lab results are not input in a timely manner. Improvements to integrations with other
systems could be made.

4.2 Timeliness
Patient medical records are now available instantaneously and can be viewed
simultaneously. This is a marked improvement from the old system. Occasionally, there is
network or Internet lag that delays the retrieval of a patient record, but this is sporadic.

This improved availability has improved patient care and historical treatment. However, it
has also meant that clinicians spend more time charting and documenting the patient visit.

4.3 Data Quality

Information is generally accurate and up to date. However, several errors were noted with the
patient back load and missing conversion data. An analysis should be done to examine the
extent of the missing or incorrect data and a plan developed to mediate the issues.

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.

5.1 Data Protection

All data is protected and backed-up by Practice Fusion. The hosted EHR is accessed through
secure channels (HTTPS) and accepted industry protocols. Practice Fusion meets all HIPAA
and security regulations. Disaster recovery (DR) and high availability (HA) services are
provided and supported by Practice Fusion. Downtime of no more than 5 hours is guaranteed
through these services.

5.2 Disaster Recovery

Practice Fusion provides disaster recovery (DR) services as part of their hosted offering. N
the event of a disaster that prevents access to the main production system, access to a
replicated environment of production or DR environment will be available. Users will be able
to access and use this site for normal activity.

However, in the event of a local disaster that causes an Internet or power outage, the
organization has created a downtime procedure. Under these circumstances, the organization
will utilize pre-printed forms to document the care of the patient. These forms will be scanned
back into the system once production access is restored. Staff has been trained on these
downtime procedures.

5.3 Audit Trails

All user history and patient access is logged by default within Practice Fusion. The practice
University of San Diego © 2016. All Rights Reserved.
 has the ability to research any user activity within its own organization or the access of any
patient records. This creates a comprehensive audit trail for all activity within the system.
This information can be obtained on an ad-hoc or needed basis. However it may be
beneficial to create reports for a more comprehensive view of activity that are less labor
intensive.

5.4 System Access

Only authorized users from the practice can access patient records. According to HIPAA
rules, these records should only be accessed by necessity for the treatment of the patient and
should remain confidential. Unauthorized access is not preventable by the EHR; however, the
EHR logs all access and keeps these records indefinitely if needed. The practice assumes
responsibility for monitoring access to the system and the security and privacy of its medical
records.

Periodic (once per month) access reviews should be done to ensure that access breaches or
abuse of access has occurred. If an employee is terminated, his or her access should be
immediately revoked. In case of a security breach, a plan should be create to notify the patient
(if necessary) and to identify the cause of breach so that future breaches are prevented.

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

Staff are taking considerably more time adjusting to the new workflows within the system.
While every effort has been made to train staff on the EHR capabilities, more time and
training is required in order for staff to be comfortable in their daily activities. The user
interface of Practice Fusion may take time for staff to adjust. Not only does staff need to
adjust to the software, but also using a computer for patient charting rather than paper records.

6.2 Scheduling
The scheduling process takes more time than prior to the EHR implementation. Staff is still
adjusting to the new software and the order of events for scheduling a patient. However, it is
expected that the amount of time to schedule a visit will return to pre-implementation rates or
better once the staff has adjusted to the new system.

6.3 Peak Loads

During peak times, there may be a backload of patients waiting to be seen or to turn in
registration form. Front desk staff may not be able to keep pace with the number of patients
scheduling appointments, leaving, or checking in for appointments. The documentation and
paper scanning required may slow the ability for the staff to provide acceptable customer
service or complete the necessary documentation. In these cases, it may be necessary for staff
to copy or store forms to be scanned as a batch at the end of the day. This frees the staff to
complete their immediate duties while fulfilling their responsibilities to complete
documentation.

Outside of these peak times, the system performs moderately well and to user satisfaction.
Clinicians spend more time documenting the patient care which can be burdensome during
peak times. However, clinicians recognize the benefits and necessity of such documentation.

University of San Diego © 2016. All Rights Reserved.