Commandalot Ugm Pmac 2010 Act
•
1 like•305 views
Describes the use of the Emergency Management Incident Command Structure in support of an organizational project go-live
Recommended
Recommended
More Related Content
What's hot
What's hot (17)
Similar to Commandalot Ugm Pmac 2010 Act
Similar to Commandalot Ugm Pmac 2010 Act (20)
Commandalot Ugm Pmac 2010 Act
- 1. CommandaLot Building an Organizational Go-Live Command Center that Isn’t a Silly Place Epic UGM 2010 – PMAC Presented by: Adam Tallinger, R.Ph. Director of Application Services
- 2. About Salem Health Not-for Profit, private, 2 Hospital System with rapidly expanding ambulatory clinic program 10 HealthGrades Ratings in heart, orthopedics, gastrointestinal and critical care services Salem Hospital recently awarded HIMSS Analytics Stage 6 in the EMR Adoption Model 2 X Beacon award winner Epic Enterprise customer Top 5 Finalist for Computerworld Magazine's Best Practice for the Planning, Designing and Building a Next Generation Storage and Server Infrastructure.
- 3. The Need – Organizational Projects Governance, Control, Coordination, Communication
- 4. Emergency Management Incident Command Structure
- 5. Why to use the ICS Structure Consistent and Standardized based on Best Practices Unified Command and Management by Objectives Chain of Command (Unity of Command) and Span of Control Resource management and tracking Communication and Information Management Accountability and Transfer of Command Allows for scaling if Go-Live turns into an internal disaster, Modular Organization
- 6. Incident Commander Control Unified Command IC notified of all Severity 1 and 2 issues Issues visible on live centralized dashboard Twice daily public report outs with follow-up media-based report Severity 1 and 2 issues must be closed by the IC Limited staff reporting directly to the IC Conducts Change Control Meetings
- 7. Call Center Structure Calls come into a single location for ease of issue reporting Consistent messaging Scripting follow-up process Ensures documentation of key information into issue report Scaled to handle multiple calls at once Roll-over phone lines Paper reported issues still go to call center – nothing bypasses the single point of entry
- 8. Issue Triage Knowledgeable person to properly assign issues Able to track multiples of the same issue that must be combined and or escalated Assigns consistent level of severity Single point for Incident Commander to have an “at a glance” view of issues Maintains dashboard and runs twice daily reports Single point for security to close Severity 1 and 2 issues upon IC confirmation.
- 9. Issue Severity Severity 1: Critical Priority - Significant risk of patient care impact, significant revenue impact, inability to conduct business, no workaround or problems that result in a major interruption in services (e.g. a critical system, platform or network failure) Severity 2: High Priority - A significant issue affecting a single function/activity, group of users or physical location. May be impacting patient safety or revenue. Severity 3 – Medium Priority: a problem that can be circumvented, within a reasonable period of time and with a reasonable level of end user impact so that the impacted user population can continue processing with no loss of efficiency (low risk of patient care, small revenue impact, able to conduct business, acceptable workaround) Severity 4 - Low priority: a user inquiry or problem that does not immediately affect the general user population and/or the performance of production systems (user preference or workaround already in place). Severity 5 – Future: cosmetic and minor system improvement requests
- 10. Issue Tracker Tool to allow tracking of issues as well as triage Developed in house in Microsoft Silverlight with SQL database Ties into Business Objects for reporting Could use any ticketing system – but… Could have licensing issues Could get jumbled with other issues not related to the current project
- 11. Issue Tracker Issue List/Dashboard
- 12. Issue TrackerNew Issue Entry & Management
- 13. Communication Use of internal Marketing and Communication Department Use of e-mail, phones, pages and status publications Twice daily review of status and provision of updates Invite leadership as well as superusers to updates Command transition – Incident Command report out and formal transition of issues
- 16. Example 1 – New Tower New patient care tower with all core hospital patient care – ICU, IMCU, CVCU, Neurotrauma, Imaging, ED, Surgery, Lab, Access Services, IV Pharmacy
- 17. New Tower Command Structure
- 18. Example 1 Results Move and transition of patient care achieved in 12 hour cutover Clear communication to all staff on status, role and sequencing of move. Coordination of wide range of issues from construction, biomed, information services, facilities, staffing and supplies Move classified as a “non-event” by senior leadership.
- 19. Example 2 – CPOM Computerized Provider Order Management Inpatient CPOM with 450+ non-employed independent physicians & 3600+ staff No paper order accepted after go-live.
- 20. CPOM structure
- 22. Example 2 – Issue Reports
- 23. Example 2 – Issue Reports
- 24. Example 2 – Issue Reports
- 25. Example 2 – Issue Reports
- 26. Example 2 Results Clear visibility and control of go-live event Issues closed in minutes to hours vs days 2 Weeks of Command Center scaled back after 5 days Allowed clear view to remaining issues to follow up on after Command Center closure Goal of “Best Go-Live in the Universe” achieved….
- 27. Best Go-Live in the Universe
- 28. Summary Even the best built system can be perceived as an initial failure if the go-live is not managed properly. A Command Center structure based on the ICS structure can help ensure your organizational project go-live is a success from day 1 through: Unified Command, Communication, Coordination and Span of Control
- 29. Questions? adam.tallinger@salemhealth.org Adam Tallinger, R.Ph. Director of Application Services Office # 503-561-2464 Other Presentations involving CPOM at Salem Hospital Session 14 – CPOM: Changing a Volunteer Medical Staff for Success (engagement and change management for non-employed physicians) Presented Tuesday at 11:45 by Dr Cort Garrison and Jason Stark , Project Manager Session 273 – CPOM: Mamma Mia, Here We Go Again! (training non-employed physicians without making it “required”) Presented Thursday at 12:15 by Sandra Shore, Informatics Coordinator
Editor's Notes
- Salem Hospital 454 beds with the busiest ED in the state (54 beds and >111000 visits/yr) and West Valley Hospital, a small critical access hospital.3600 staff and 450 physiciansEpic Modules: EpicCare IP, ClinDoc, Orders, CPOM, MAR with Barcoding, ASAP, Willow, Radiant, Stork, and Ambulatory on the clinical side.Revenue Cycle and Access have HB, PB, HIM, Cadence, Prelude/ADT, Clarity, and Bridges. Currently on Spring 07 and in process for a go live with Summer 09 and Extended Clinical Documentation in February. Projects needed to meet stage 1 meaningful use are in process along with ICD-10 evaluations.21,000 inpatient admissions per year12,000 surgeries per year3,600 births per year1,000 traumas per year
- To be a success;governance, control, coordination and communication must all play a role in an organizational level project go-live.Let me show you a representation of our first Epic big bang Command Center:<show video of Camelot>Story of our initial big-bang Epic go-live:It’s 2006.Picture a conference center with multiple rooms all filled with computers. Analysts fill the chairs in those rooms all tasked with working on issues related to their specific piece of Epic. There is a call center, but that is only one of many ways in which to report issues to the analysts. Superusers, Epic staff, or general new users can all either call the analysts directly or stop by the individual rooms where issues are being worked. There is an incident commander, but without any organization of global visibility – he becomes an incident observer.I’m not stating that good work was not being done or that we were not successful overall – what I am saying that there was a definite lack of control and internal communication. Huddles and report outs were based on information through verbal reports and perception, not quantifiable data. We succeeded through hard work and perseverance; not by design. Our command center truly was a silly place.Issues reported on one shift and fixed to one users preferences were switched back on the next shift based on separate preferences by another.The number of issues reported is long gone with a legacy ticketing system, but I do know that there were over 1000 outstanding issues still being worked for months after the command center closed.
- The ICS was developed in the 1970’s after a series of fires in California that claimed both lives and property. In the analysis of how these fires were handled, it was not a lack or resources or know how in firefighting but a lack of management that led to the poor outcomes.The ICS uses key divisions within the command structure and provides a common framework for any organized incident response.
- Consistent– Familiar Structure and common terminologyUnified Command – single point of command over all departments. Objectives can be broad or discrete – but the mere point of having the objectives defined leads to the ability to both develop plans methods for measuring the objectives.Chain of Command and Span of Control – every person has a designated person to report to and the reports are tree’d downward so that no one person (including the incident commandeer) has too many people feeding him/her information.Resource Management – in most cases with a go-live, this becomes people management. People are needed across the spectrum from answering phones to fixing reported issues behind the scenes to providing at the shoulder help for end users.Communication – Information is filtered through the communication officer so that mixed messages do not develop.Accountability/Transfer of Control – supervisors can hold people personally accountable for specific actions and assignments, check in/out process, incident commander schedules overlap so that command can be transferred appropriately.If things go bad and you can no longer care for patients, the model is easily scaled into a Code Triage/Disaster.
- Incident Commander is the top level for the Unified Command.We made all severity 1 and 2 issues go through the Incident Commander for both awareness on opening and authorization to close to ensure proplerfollowthrough had occurred.Issues were made available in real time to the incident commander via a dashboard (that we will show in a minute).Incident commander worked directly with the communication officer to provide twice daily, in person, report outs for the staff. These report outs were summarized in a global e-mail and communicated to the rest of the staff.Span of Control – in this structure, you do not have too many people reporting up to the Incident Commander as to overwhelm him/her. This leaves the ability to focus on the larger issues of control, communication and management of the larger issues.Incident Commander led ad-hoc change control meetings for large scale changes to ensure due diligence when making the changes.
- All issues are reported to the command center through the call center. Phones would roll over line by line – easily scaled back based on call volume. The use of specific personnel in these roles allowed for better scripting of messaging going out (ie what’s going to happen with their issue) as well as better collection of the information needed to begin work on the issue, including callback information. The also allowed the other command center staff work the issues reported without interruption.For issues brought on paper forms or verbally to the command center, the staff would be directed to the call center and work directly with a call center person to log their issue.
- While the Incident Commander was the peak of the command structure, the Issue Triage role was the central focus. This person took all reported issues from the call center and assigned both a priority as well as the best group to work the issue.For this reason, you need a global thinking, knowledgeable person in this role.By sending the issues through this single point, severity could be consistently assigned and that person could look for commonalities in smaller issues that may represent a larger problem.Liaison to the Incident Commander for displaying dashboard as well as ensuring proper documentation to close severity 1 and 2 issues.
- Due to the issues seen with our existing ticketing system in the first Epic go-live, the need was seen for a better tool to manage issues in a command center atmosphere. We designed what we needed to see and our web architect built an application for us in Microsoft Silverlight. The app uses an SQL database and the heavy lifting reports are done through Business Objects.
- This is the dashboard view of the application. Issues can be filtered so that the issues can be viewed by status, priority, type, oreach group can see their own dashboard assignments. We built an auto-refresh feature for the projector driven dashboard view in the command center.
- This is the issue reporting and editing screen itself. You can see the information gathered by the call center, the ability to change and track statuses, priority setting, and assignee tracking. There is a notes function at the bottom that allows adding and viewing documented updates to the issue.
- We engage our internal marketing manageras the communication officer. She provided a smooth transition from the pre-go-live communication to the materials at go-live. Emails were sent out twice daily with the in-person report outs mentioned previously. CPOMFlash and TowerFlash. Command transition was mentioned before, but bear repeating as an essential element in the command center communication – the outgoing and oncoming incident commander must have ample time for a handoff and access to the issues list.
- Here are some examples of media materials used in the CPOM project. We have a business card sending people to our public CPOM website with the physician champions on the back to contact as needed. We took advantage of our Grand Rounds presentations to market CPOM. And CPOM Matters, a monthly booklet publication for getting the word and acceptance for CPOM.
- We’ll now discuss some examples where we used this command structure.
- May 2009 - opened a new patient care tower as a phase 1 of 3 for the replacement of Same Hospital. The tower uses evidence based design and elements for warmth and a healing environment. All core and critical care services moved into the new tower including 120 new patient beds.
- Here you can see the command structure used for our New Tower Go-live. The incident commander was always one of our vice presidents; this tied their normal authority in with the command centers unified command.We utilized IS management and Informatics Management for issue triage since their business dealings tend to span the other departments. We has what we called SWAT teams (Swift Action Teams) that were structured under separate logistics and operations leads.Since this was a planned event, the planning role was coordinated by the project leads in process engineering in the form of a detailed minute by minute move plan spanning all departments.And, while there was not an official Finance section in the command center, our CFO and the finance department were carefully watching for impacts on revenue as this move took place.
- The bulk of the service moves took place over a 12 hours period through a carefully scripted minute by minute plan. Beds were filled as new admissions arrived – by 48 hours out, the tower was full. There was always clear communication, coordination and check offs on the minute by minute move plan. With a new tower, unlike an application go live, we had issues with everything from toilets to security to our wireless phones. I’m happy to say that after extensive printer testing, the number of issues reported for application services were minimal when compared with biomed, facilities and supply chain.
- CPOM – Computerized Provider Order ManagementWe realized part way through our project that the physicians were only ½ of the story – those receiving the orders and acting on the orders were major stakeholders. Also, it wasn’t just about order entry – it was also about order modification, order reconciliation and order discontinuation.Single metric from our Chief Medical Officer was to have the “best go-live in the universe”In order to have a great go-live, we needed to pull on the lessons learned from our non-event tower move and have a robust command structure.
- As you can see, there is a similar structure involving the components such as: IC, Safety Officer, Communications, Liaisons (Ambassadors), Triage and Call Center and then Ops and Logistics. Logistics focused on the IS pieces. Not just the application support, but also security, desktop support and other tech support like network and servers.Ops were split into 2 groups to provide a manageable span of control – Clinical Informatics had oversight of training and the superusers. An Ancillary lead coordinated other key stakeholder departments such as pharmacy, imaging, lab, etc.As with the tower move, planning was managed through a robust cutover document and finance monitored revenue at the department level.
- Here is the physical layout of our command center. We purchased command center equipment to support our structure and then gifted the equipment to the director of emergency management so that we would always have the necessary equipment for a command center.
- The next few slides have some report examples from our CPOM go live. All of the reports were pulled after the closure of the command center and represent that point in time. As you can see, overall the majority of our issues were a Severity level 3. Issues that remained open after we closed up shop were easily identified and moved to a separate spreadsheet for individual workgroup assignments. These were assigned out, given deadlines, and resolved over the 45 day period following the go-live.
- We were able to track Issues by time of day to optimize and flex call center staffing. You can see here that issues dramatically dropped off after 22:00 until the morning. The 2 peaks in issue reporting correlate to the report out times where any superusers with issues on paper brought them into the call center.
- Issues by group. As you would expect with a software go-live, the majority of reported issues were for IS or the Informatics regarding workflow and training.
- This report shows issues by status. As the report was pulled at the end of the project, the remaining issues in this database are the ones that were moved to separate workgroups.
- The Incident Commander always had a good working knowledge regarding key issues and their status. Issues could be triaged and worked to closure quickly and with the right change management.We were able to scale back staffing in the command center after 5 days.There was no uprising or backlash to turn off the system.
- On Feb 23rd, only 7 days after go-live, our Chief Medical Officer had completed his “research” and certified us as having the “Best Go Live in the Universe”. I think that just the fact that our CMO had the time to spend creating this document and not listening to physician complaints speaks volumes to the success of this project.Our current CPOM adoption rate numbers (we did have our own metrics) for July (5 months after go-live), show 327000+ orders entered for the month. 92% of those were entered by the physicians, clinical staff protocol orders were 5%, telephone orders were 2.5%, and verbal orders were 0.5%.August shows 338000+ orders and almost exactly the same breakdown within fractions of a percent.