EHR Go-Live Activation – Big-Bang or a Phased Approach?
By Zack Tisch
After completing the RFP process and determining which vendor and products will be part of the implementation, the real fun begins. Should the organization deploy this change in a single event — typically referred to as a big bang go-live – or would a methodical, phased approach be a better fit?
At first glance, a big bang can feel aggressive, particularly in a healthcare environment where risk can mean significant consequences, not only to organizational financial health, but potentially to quality and patient safety. This surface analysis can be, misleading however, and more detailed consideration often reveals challenges to a phased approach that can be even more significant, particularly for multi-hospital organizations that may be on different core clinical or financial software platforms. The following considerations are a start to determining which approach may be best for a given organization.
Carefully categorizing likely risks and how to manage them is a major factor in determining a go-live activation approach. A successful go-live is one where known risks are decisively and quickly managed and unknown risks are quickly analyzed and attacked. Both activation approaches can be equally successful, but there are specific tasks and processes that should be put in place prior to go-live to help support the approach.
For example, with a big-bang go-live, technical considerations become primary due to the volume of users and equipment that will be interacting with the system at the same time. Is security configured correctly? Can all users log in? Have they verified this in the production environment prior to go-live? With a phased install consisting of a smaller initial pilot, security, login, printing, and hardware issues may not be as pressing.
On the other hand, with a large-scale big bang featuring potentially thousands of users and workstations, the first few days or week of go-live can easily be spent just resolving technical issues that could have been sorted out with a thorough pre-live plan. This is a known risk and I would strongly advocate as much testing in production with real hardware and actual end users as possible, regardless of the chosen go-live approach.
Outside of technical issues, another key risk for most EHR go-lives is operational change and how well clinicians, front desk, and back-office staff accept and adopt the new workflow changes and tools. With a phased install, there is the luxury of being able to portion this change over time, reducing end-user anxiety and the amount of information they need to process and retain from training. However, one major drawback is that with a phased go-live, there will often be interim workflows, requiring end users to learn a new process and then unlearn aspects of that process shortly thereafter.
One key area in the organization to evaluate for potential risks is physician coding, particularly on the outpatient side. Physician coding is a highly integrated process, beginning with appointment scheduling and patient registration through clinical support staff rooming, physician documentation and order entry, charge generation, coder review, and ultimately claims submission. When implementing a new system, it is important that there is clarity and consistency on who is performing what task, particularly for the charge generation and coding review steps.
Will physicians or clinician support staff be entering or reviewing charges? What about evaluation and management (E & M) codes for level of service? How do coders work with providers to get clarity or update documents? When considering a phased approach (as an example, bringing outpatient clinical modules live prior to a separate billing go-live), will these workflows change? Each change to this workflow introduces key elements of risk, primarily of missing or delayed documentation and charges. This is an area that can quickly spiral out of control, and if not well understood and managed prior to go-live, can lead to significant financial risk for an organization, which unfortunately seems to dominate headlines, rather than the many highly successful projects.
My suggestion would be to take the time to perform a detailed risk analysis or partner with industry experts to assist with this. Also, work closely with organizational senior leadership to evaluate the benefits of having a phased install versus a big bang. Going through this process in the past, I have seen highly risk-averse organizations that initially wanted to move forward with a very phased install transition to a big-bang approach because the interim workflows and frequent system changes of a phased approach posed a higher risk of failure.
Another key factor to consider is the current state of the legacy EHR data. If the health system has multiple ADT or EHR systems, with multiple patient MRNs, a phased go-live can be much more difficult. A detailed analysis and thorough testing of how this will impact your downstream systems must be performed. One of my clients who had two separate clinical and registration systems initially desired a phased approach. However, upon further analysis, there was significant crossover for orders and results between the two. As a result, it would have been extremely difficult to keep all systems in sync. While the new EHR could handle these multiple MRNs, a number of key integrated systems could not handle interfaced merge messages or multiple patient identifiers. We would have had to pursue a major parallel project to implement an additional patient identity management application or merge and update MRNs across the entire organization.
One other example that is often identified late or overlooked is the ability for a new system to run alongside the legacy system during a phased install. There are often significant compatibility issues between vendors related to the versions of Internet Explorer, Java, and other critical Windows / Web architecture components necessary for a system to function correctly. With a thin client deployment, it may be possible to get around this with separate setups on the individual servers, but this is not always possible.
Lastly, as someone who has experienced many implementations in a variety of roles — from analyst through project leadership — I would highly advocate considering the health, effectiveness, and well-being of the project team as it relates to the go-live approach. These implementations are challenging, requiring significant hours and brainpower, often well above and beyond a 40-hour work week. With a big bang go-live, the team has a single mission and a single event. Team members can see the light at the end of the tunnel and this is particularly critical as they work through the challenging build completion and testing phases of the project. Having an event to rally around can be significant for motivation and keeping everyone on the same page.
The downside is that one large go-live means only one chance to get it right. This can introduce significant anxiety, particularly for team members who have not previously worked on a similar project. It’s important for leadership to direct time and energy with the project team and end users to understand why a big-bang approach was selected and the significant steps and thousands of hours of hard work the team is putting in to ensure the go-live will be successful.
The benefit of a phased approach is each individual go-live is more approachable for the project team. The smaller scope and scale makes it easier for team members to wrap their heads around the effort and the amount of support required for the go-lives to be successful. However, by having multiple go-lives, the team now has to get up for more “showtime” events and more weekends and late nights performing pre-live cutover and go-live support. It can also make it more difficult to define when the project can be considered a success.
It is especially important to limit the number of phases and space them out appropriately. If they are too close together, it can feel like one very large and extended go-live, particularly if the initial phase is challenging and it is difficult to stabilize and move to support on time. I’ve also seen challenges where go-lives are spaced too far apart, and the project team and end users have become apathetic. If the amount of change at any one time is too little to be felt broadly across the organization, or too spread out, it can become difficult for staff to understand the benefits from the project and why the organization undertook this significant and expensive process. If choosing a phased approach, work carefully with the project team and vendor to make sure there is a realistic timeline with enough time between phases to appropriately stabilize and shift focus.
These considerations are just a small subset of the topics that are critical to discuss with the leadership team when deciding on a go-live approach. There are benefits and drawbacks to both approaches and one size certainly does not fit all. With appropriate foresight and planning, either approach can be highly successful. There are a multitude of expert resources and organizations that can share lessons learned to help follow in their footsteps.