Post Go Live Issue Management

1. Post Go Live Issue Management New Build, Maintenance, Enhancements etc.

2. Evanston Northwestern HealthcareWho we are . . . EvanstonHospital 420 beds Glenbrook Hospital126 beds HighlandPark Hospital240 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 →

4. Our Focus • EpicCare Inpatient & HOV • Medical Informatics & it’s 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. ENH’s 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. We have: The Issues List RFS System The Project Plan Now we need: Operational ownership Communication Prioritization So……….

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 • Until the Modification Type is defined, the request should remain in the status of Request Received • Status changed from Request Received to Approved by MI only after approval and prioritization from the designated VP or higher level administrator. • 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). • Information Systems will assign Approved RFS to application coordinators • Information Systems is responsible for marking an RFS as Complete in the system. • 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. Clandestine Spread Sheets Things are more organized Less gets lost There are still………. Unrecorded requests Things that get done because of who you are or know But……… All cynicism aside

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@enh.org • Janet Ryan, BS, RN JRyan@enh.org