Post Go Live Issue Management

1
Post Go Live Issue Management

• New Build, Maintenance, Enhancements etc.

2
Evanston Northwestern HealthcareWho we are . . .









Evanston Hospital 420 beds

Glenbrook Hospital 126 beds










Highland Park Hospital 240 beds

65 Medical Group offices

3
ENH Statistics

• Admissions (Including Births) ?
• Patient Days ?
• Deliveries ?
• Outpatient Visits (Excluding ER) ?
• Total ER Visits ?
• Employees ?
• Physicians (Professional Staff) ?
• ENH Medical Group ?
• House Staff ?

42,000
195,000
5,700
454,000
88,500
7,500
1,700
500
150
4
Our Focus

• EpicCare Inpatient HOV
• Medical Informatics its role in work and issue
  management
• Work and issue management in an integrated
  product
• Evolution of the current process
• Issues
• Request For Service
• Projects

5
ENHs Portfolio of EPIC Products
PatientData
HOV
ICU
ADT HIM Hospital Billing
Oncology
6
Evolution of Epicare IP and HOV at ENH

• Implementation
• First Hospital Clin. Doc 03/2003
• First Hospital CPOE 05/2003
• Second hospital Clin. Doc 06/2003
• Second hospital CPOE 11/2003
• Third Hospital Clin. Doc 12/2003
• Third Hospital CPOE 04/2004
• ICU 06/2005
• Beacon 08/2006
• Stork 03/2008
• Upgrades
• MU3, MU4, MU5, MU6, Fall 04, Spring 05, Fall 05,
  Spring 06, Spring 07 Spring 08,ADT,HIM,and
  Hospital Billing

7
Evolution of Medical Informatics

• 2001 - Operations Sr. VP led an IP application
  group
• 2002 - Formalization of a Medical Informatics
  Department
• Lead by Sr.VP of Medical Informatics Reporting
  to the COO
• 4 Sr. Directors (IP, HOV, Ambulatory and
  Business)
• Facilitated all meetings between IS and
  Operations
• 2007 - Medical Informatics moved under
  operations
• Maintain Sr. Director Structure (IP, HOV, and
  Ambulatory)
• Added Project Manager positions
• Added a Director Systems Integration and
  Development

8
Collecting the Work!

• Prior to Go Live Fit testing Database-one avenue
  for reporting issues
• During Go Live Avenues for reporting issues
  expanded and excel spreadsheets proliferated
• Post Implementation Issue management was
  fragmented and decentralized
• Maintenance Added Help Desk and Epic Help
  button

9
Epic Help Button
10
Controlling the Wild Beast!

• Fit testing exported into Excel Issues List - all
  teams add their spread sheets to the Issue List.
• Spreadsheets proliferated again as a place to
  enter and track end-user requests
• Pivotal event
• Change management process was needed.
• Calendar was created where all changes to
  production needed to be scheduled
• Weekly call to review changes for impact on other
  applications.
• Still not enough!

11
Birth of the RFS

• Requests needed to be centralized
• Implemented the use of an existing Request For
  Service (RFS) system
• Direct entry by end users
• Entry by MI IS

12
We feel we are in control - Just

• ENH Spreadsheet issues list
• Managed by IS Team
• Weekly call with Epic
• RFS database
• User requests Enhancements, New build,
  Maintenance
• Strange little collection of issues
• Projects

13
It is Not the Perfect Solution!

• RFS perceived as Black Void
• Within Medical Informatics User request process
  differed
• Inpatient requests came from multiple users,
  groups and administration
• HOV came from Managers and Administrators
• Design issues hindered RFS management
• Inpatient team Database created
• HOV Ring binder!
• Double data entry
• Weekly RFS calls

14
Mutiny!

• Classified everything in the RFS system
• Defined what went on the Issues List
• Defined what would stay in the RFS
• Required
• Discretionary
• Created a third category Projects
• Made changes to the RFS System
• Mapped out ideal RFS workflow

15
RFS Process Workflow
16
Projects

• Lived on a spreadsheet
• Worked on ad Hoc
• Operational demand
• Analyst availability
• Available functionality
• No dates or timelines
• Things not getting done but perception of
  constant change
• No operations ownership of projects

17
The Projects Project Plan
18
More Projects Project Plan
19
So.

• We have
• The Issues List
• RFS System
• The Project Plan

• Now we need
• Operational ownership
• Communication
• Prioritization

20
Ownership

• ENH Issues List Spreadsheet
• Managed by an IS team member
• RFS System
• MI review new requests and classify them
• Project Plan
• Steering Committee

21
Communication

• ENH Issues List Spreadsheet
• MI/IS biweekly call with Epic
• RFS System
• Monthly RFS Reports for discretionary requests
• Project Plan
• Monthly Score Card

22
Prioritization

• ENH Issues List Spreadsheet
• IS MI
• RFS System
• Essential to business moved into IS work queue
• Patient Safety
• Impacts Business
• Regulatory
• Enhancements assigned to operations VP for
  prioritization
• Project Plan
• MI IS review, estimate work hours, and schedule
• Steering Committee

23
Current State

• Shifting Project Plan
• To meet Regulatory Requirements
• Unanticipated changes in Projects
• Refinement of RFS Workflow
• Rules of Engagement for the RFS
• Reclassification of Required

24
RFS Rules of Engagement

• Types of RFS
• Required - Services that have an immediate impact
  on patient safety, revenue or operations.
• Discretionary - Enhancements that improve or
  increase efficiency.
• The Modification Type - Assigned by Medical
  Informatics, in collaboration with Information
  Systems and/or the Requestor, as necessary.

25
Rules of Engagement

1. Until the Modification Type is defined, the
   request should remain in the status of Request
   Received
2. Status changed from Request Received to Approved
   by MI only after approval and prioritization from
   the designated VP or higher level administrator.
3. IS and MI will collaborate on the order in which
   the prioritized Discretionary RFS are to be
   completed (Ex. If there are 10 1 priorities, the
   MI Sr. Director will determine order).
4. Information Systems will assign Approved RFS to
   application coordinators
5. Information Systems is responsible for marking an
   RFS as Complete in the system.
6. Monthly production report runs (i.e. reminder or
   tickler systems) should be tracked outside of the
   RFS system.

26
Rules of Engagement

• An RFS must be created for
• Help Desk calls that require more then 30
  minutes to complete. This includes total
  resolution effort analysis, build, test, and
  implementation. etc.)
• For every Request for Change (RFC) including
  code changes.
• Multiple RFS must be created for regularly
  scheduled maintenance, according to the schedule
  (ex. 1 RFS per month for monthly maintenance, 1
  RFS per quarter for quarterly maintenance, etc).
• All RFS must have a defined scope.
• Each application team must open its own RFS for
  integrated projects.
• All parties are responsible for keeping the RFS
  system accurate and current.
• Any change to the RFS process must be approved by
  the RFS Committee, chaired by Medical Informatics
  and Information Systems.

27
There are still.

• Clandestine Spread Sheets

Unrecorded requests
Things that get done because of who you are or
know
But All cynicism aside

• Things are more organized
• Less gets lost

28
In Summary

• Long Journey
• Classified Requests/Issues
• Formalized the processes
• Returned ownership of change back to Operations
• Improved Communication

29
Contact Information

• Kate Reynolds, RN
• KReynolds_at_enh.org
• Janet Ryan, BS, RN
• JRyan_at_enh.org