Post Go Live Issue Management New Build, Maintenance, Enhancements etc.
Evanston Northwestern HealthcareWho we are . . . EvanstonHospital 420 beds Glenbrook Hospital126 beds HighlandPark Hospital240 beds 65+Medical Group offices
ENH Statistics • Admissions (Including Births) → • Patient Days → • Deliveries → • Outpatient Visits (Excluding ER) → • Total ER Visits → • Employees → • Physicians (Professional Staff) → • ENH Medical Group → • House Staff →
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
ENH’s Portfolio of EPIC Products PatientData HOV ICU ADT HIM Hospital Billing Oncology
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
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
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
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!
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
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
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
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
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
We have: The Issues List RFS System The Project Plan Now we need: Operational ownership Communication Prioritization So……….
Ownership • ENH Issues List Spreadsheet • Managed by an IS team member • RFS System • MI review new requests and classify them • Project Plan • Steering Committee
Communication • ENH Issues List Spreadsheet • MI/IS biweekly call with Epic • RFS System • Monthly RFS Reports for discretionary requests • Project Plan • Monthly Score Card
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
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
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.
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.
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.
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
In Summary • Long Journey • Classified Requests/Issues • Formalized the processes • Returned ownership of change back to Operations • Improved Communication
Contact Information • Kate Reynolds, RN KReynolds@enh.org • Janet Ryan, BS, RN JRyan@enh.org