How to Make a Go-Live Go Smoothly: Q&A with The HCI Group’s Chris Belmont

12.12.19
By Candace Stuart, Director, Communications & Public Relations

Chris Belmont oversaw two Epic go-lives as CIO at Ochsner Health System and MD Anderson Cancer Center. Now executive vice president of operations and strategy at The HCI Group: A Tech Mahindra Company, his career has included positions with Siemens, IBM and Healthlink. He recently talked with CHIME about lessons learned and trends in the industry. This is the first of a two-part Q&A. It has been edited for length. 

Q: What lessons did you learn through your Ochsner go-live that you applied to MD Anderson?

A: I learned that you have to sweat the small stuff. Little things matter. It is a long journey; it is typically 3-5 years from the time you think about making a change to the contract signing to the building and implementation to the point where things have stabilized.

The most predictable parts of the project, in my opinion, are the big pieces: the build of the system, the methodologies work and the technology. Then there is the small stuff: How do you manage the project? How do you manage scope creep? There are a thousand things you have to think about during the go-live day. Any one of those can disrupt years of work. That was the best lesson learned for me.

Q: Can you actually recognize the small stuff at that point?

You can but you have to be intentional about it. You have to sit down and go through some scenarios. Play “what-if’s” and look at it from many perspectives. Take the command center, for example, if you need to feed the troops. You need to have a constant flow of food and if your go-live is in the middle of the night or weekend, maybe food services at your organization is not fully staffed to support those hours so you must engage with them. Getting your food services team to be part of the project is invaluable. In both situations, our facilities and food services teams stepped up in a big way. They rallied around the project even though it didn’t directly impact them.  

Do you have enough power? All of a sudden you have a command center with 100 people in one room. Will the power handle that? Can you get enough phones in there? Can you get enough network coverage? We also learned to load test everything. The volume of activities in the first few days and weeks will spike.

There will be a large influx of people supporting the go-live. How do you get people in and out when you have a shift change? At MD Anderson we had a thousand support folks, maybe 400 per shift, for example. How do you get 400 in and 400 out without disrupting normal hospital operations, especially at a cancer center?

The fatigue of your team is another one. The EMR team will sprint to the starting line. You worked long hours to get the system built, tested and ready for production and when you turn it on your team needs to be at their peak performance. If your team is fatigued or you didn’t intentionally manage their hours, then you have a team who is burned out when you need them to be at the top of their game.

Q: Did you learn those lessons specifically at Ochsner?

A: Ochsner was the first very large project where it was a full EMR, but in my career with Siemens, IBM and Healthlink I probably did 40 major EMRs or large departmental system installs over my 30-plus years in healthcare IT. Definitely not as big as Ochsner but you still have the same issues on a smaller scale. I have done a lot of different command centers, go-lives and builds. Many things are similar but they all have their unique nuances.   

You have to make tough decisions like what data do you migrate to the new system. Do you really need medical record No. 1 in Epic when they were a patient 50-plus years ago and you don’t really have any digital records? There are things like that that you need to think through. There is no right or wrong decision. You just need to have an educated discussion with all of the stakeholders.

The doctor says, ‘I need every lab result ever in the new system.’ For some specialties like cancer, probably, but for primary care, do I really need my blood results from 30 years ago? If you ask users what they want, they will say everything. You have to sit down with them and ask, ‘What is important to you?’ It typically is two or three years of data in the active system and access to the historical data in an archive. These decisions must be balanced against the effort and cost. It may be more difficult and costly to filter the data than to move it all.

Q: How about the data quality itself?

A: That is the biggest challenge. It may not map one for one. When you build your new system, you have the opportunity to revisit, standardize and update some of the critical values, ranges, prices, order set and so on. While some of this may be valuable effort, make sure it is managed closely. Some of these projects are major efforts and change management challenges themselves. The good news is this process has been refined over the last decade and the data migration effort is much more predictable and based on the experiences of others.  

On the flip side, you must think about the use of the data down the road. At MD Anderson, we quickly realized we were building a system that would support clinical operations and standards of care but with a little more effort we could turn it into a strong research data collection tool. For example, the diagnosis and other clinical information may be appropriate for care or billing. But did we have enough granularity to know specific cancers, specific stages? Could we make that available for the research community by collecting it in the EMR in the normal patient flow?

Look bigger and broader and institutional. We adopted a “data first strategy” and built our system with that in mind. Not just is it good for billing, clinical care, research, operations and reporting? Do we have enough detail for scheduling optimization or is the metadata there to look at staff productivity and so on? Is it accessible and consistent with the enterprise analytics strategy?

It is a transformation you are going through, not purely an Epic implementation. You will never have the opportunity, probably ever again – hopefully – to do a project of that magnitude that impacts literally everybody in the organization all the time. Don’t overdo it, don’t over engineer it or take too long. Be aggressive but smart about what you are doing. Be careful with the amount of change you introduce.

Q: How do you keep the momentum going?

A: It is very cyclical. A member of the board at Ochsner asked me what the biggest concern I had about the project and I said communication and change management. Probably the most valuable resource that I brought onto the project was a dedicated communication resource.  There is a steady drumbeat that you have to maintain over the lifecycle of the project. It can’t be communications for communications sake; it has to keep the project relevant and in everyone’s mind.

You must be aware of where you are in the project lifecycle. For example, when we were in the middle of the build and were far enough along that the system was somewhat presentable yet still a year or so away, it was time to get the organization back engaged. We held a couple of demo fairs in public areas. What was nice about that is they got to see their friends, the MD Anderson or Ochsner employees showing them an MD Anderson or Ochsner system. It was not an Epic demo done by Epic people.

That was the launch to the go-live, months ahead of the actual go-live date. People realized that, ‘Wow, this is really happening. This is our system.’ There were booths where they could see different system features and function. If you were a radiologist there was a radiology booth. There was an admission and registration booth, a nursing booth and a physician booth. They could see how the system would impact their role in the organization.

We started getting the momentum and level of excitement back up. In my experience, over the long period while the system is being built, you want to keep the project in everyone’s mind but not overdo it. At about 180 days before the go-live you want to ramp up the awareness and focus. That is when you start giving the system to the users through testing and validation. That is when you need to get the user community heavily involved. You want them to actively participate in training, building preferences, practicing in the sand box and participating in the go-live. You can never communicate enough in my opinion. The more you do prior to the go-live, the shorter the stabilization and adoption period will be.

Our go-lives were successful because we did that work. We adopted a mantra, and we still use it today at HCI:  We do it with our users and not to our users.

Join the Discussion >