Home » Readers Write » Currently Reading:

Readers Write: EHR Go-Live Activation – Big-Bang or a Phased Approach?

January 30, 2015 Readers Write 8 Comments

EHR Go-Live Activation – Big-Bang or a Phased Approach?
By Zack Tisch

image

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.

Zack Tisch, PMP is director of strategic solutions with Nordic Consulting Partners.

View/Print Text Only View/Print Text Only


HIStalk Featured Sponsors

     

Currently there are "8 comments" on this Article:

  1. great article! You summed up the issues well. When looking at a phased in approach, there are different “flavors” of phased in: are you phasing in functionality? Such as a clinical data repository, CPOE, BKMA and ADT and ancillary interfaces prior to bringing up clinical documentation? Or/and are you phasing in full functionality by unit or hospital. I have certainly seen the use of a big bang approach increase over the years. A smaller organization with fewer users and hardware is much more tolerant of a “full functionality” implementation at one time. Much of my experience is with multi-hospital health systems, where I believe the risk of interruptions in workflow, or the failure of technology compound the risk due to the number of users (and patients!) involved.

  2. Thanks for re-publishing this piece from 2011, when so many health systems were implementeing new systems… Whoa wait, this was written in 2015?!?

    While there are some good points here, shouldn’t we be focusing our attention on driving real value from IT investments rather than discussing the best way to install the plumbing?

    Interesting that Nordic is still in implementation mode.

  3. As a former ambulatory EHR salesman I can verify the downside of phased implementations. Partially implemented systems. Many practices plateau with this approach. Never using the full functionality of clinical documentation tools at the point of care. One popular and highly ranked software had less than 10% of the installs fully implanted.

  4. Although it is an interesting article, I found the silence on having the RIGHT people on the team deafening. I wish you spent more time on this paragraph:

    “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.”

    Laboratory results are 70% or more of the patient chart, yet the “Epic model” is to prevent lab from being involved unless Beaker is part of the project. Epic came to (unnamed hospital) and did not ask for lab people on the build. The lab leadership begged for someone to represent lab on the build and finally it was approved – after the rest of the build team was already in Verona for training. And, while the lab part of Epic was still being built, they used the single lab rep on the team to test printers and workstations. Such a waste of talent and precious time we had little of.

    You have to have seen over your years that they need more people on the build team, more of the RIGHT people on the team focused on the RIGHT things, and more time to implement than the unrealistic timelines Epic pushes. You have to have learned how much lab talent is required for a successful launch. Yet, Epic STILL refuses to bring lab to the table when implementing (for instance, the LIS team at a large implementation currently going on in Pennsylvania does not even have access to the TEST AREA!).

    You have a lot of influence on Epic implementations – I hope you use it to push for changes in the “model” to bring more of the right people doing the right things from the beginning.

  5. Big bang is the way to go if you are able to customize the application enough to be useful. Physician participation and ownership with the appropriate governance structure makes any implementation a non issue. Dual process and IT owing in the development and governance yields failure.

  6. very good article. My team has been successful with both approaches and differant vendors, including Epic. I think the biggest variable has to do with the culture of the organization and the ability of the organization to manage through the amount of change that is being introduced .

  7. Zach,

    Correct me if I’m wrong, but didn’t you lead the Epic implementation at University of Arizona Health Network? I’m not sure you’re the best person to be giving Go-Live advice considering UAHN’s implementation was an EPIC failure.

    Didn’t the health system lose $30 million in the first quarter post go-live?

    Let me guess, you blame politics for the failed implementation?

    Banner has since purchased UAHN and will be ripping out the Epic system you installed and implementing Cerner.

  8. Hi all,

    Thank you for reading this article and sharing your thoughts. I wanted to share a few updates based on your feedback.

    Dave Cohen – I agree that the ultimate goal for any organization implementing all or portions of a new EHR system should be driving value from those systems, whether it be patient care and quality gains, revenue benefits, or operational efficiency improvements. Getting your organization on an integrated and effective EHR platform is only step one in that journey. Nordic is working with healthcare organizations at every step of this process, from initial vendor selection to implementation through post-live optimization and roll out to affiliated clinics or hospitals. In fact, the optimization and affiliate roll out areas are some of our busiest and fastest growing.

    Lab Matters – You make a number of excellent points. Having the right people is critical, and lab in particular is a very integral component of any EHR implementation. I cannot speak for vendor methodology at large, but all of my projects (whether Beaker or non-Beaker) have had a strong lab presence. Laboratory, Medical Imaging, OR, and Supply Chain are critical areas that need to be highly involved during any inpatient, outpatient, or billing application implementation.

    LL Cool J – I did indeed help lead the implementation of Epic at The University of Arizona Health Network, and am extremely proud of the tremendous achievement by the UAHN team. They built a very high quality integrated system on an aggressive timeline and with a short budget, and had a successful go live with minimal issues. As you mention, the organization had been going through financial challenges prior to, during, and after the Epic implementation. Many of these challenges were related to unreimbursed care and that UAHN takes on due to their guiding principles and role within the community. While the EHR implementation itself was costly (as any large EHR project is), we were able to meet our budget goals while also retrofitting a primary data center, upgrading the lab system, and implementing a new medical imaging platform concurrent with the Epic project. For specifics on the financial challenges experienced by UAHN and their subsequent acquisition by the Banner Health system, I would refer you to the number of press releases and statements issued by the executives of both organizations.







Subscribe to Updates

Search


Loading

Text Ads


Report News and Rumors

No title

Anonymous online form
E-mail
Rumor line: 801.HIT.NEWS

Tweets

Archives

Founding Sponsors


 

Platinum Sponsors


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Gold Sponsors


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Reader Comments

  • Classic Jonathan: Dissing on Epic to dismiss athena's failures. If your fundamental premise in business is that every one of your compe...
  • meltoots: Anyone else think that it screams excessive for athenahealth to OWN a Challenger 300 private plane? EHR vendors have a n...
  • HHC...: Not that this should come as a surprise, but the amount of corruption and “side deals” involved with the HHC Epic im...
  • HIT Girl: That's quite a bloodbath....
  • Where's Kyle: Nevermind. Obviously, Kyle's been busy....

Sponsor Quick Links