If an organization wants to ensure a successful EHR rollout, there are many components that are important, but one that is absolutely essential. The people who will use the technology must be “intimately involved in developing the strategy and testing the workflows.”
It may sound simple, but in reality, “It’s very easy not to do that,” said Stephanie Lahr, MD, CIO and CMIO at Regional Health. As a physician, she knows firsthand how difficult it can be to dedicate the time needed to sit down with everyone from OR surgeons to the front-desk staff and utilize their input in creating a roadmap. But it absolutely has to happen.
Recently, healthsystemCIO spoke with Lahr about her organization’s transformation – including why they chose to do a big bang, what it took to lay the foundation, and why they contracted with a third party. She also discusses the importance of having a “physician-driven governing body with a technology focus,” her team’s vision for the future, and how she is able to balance dual leadership roles.
- Operational engagement in EHR rollouts – “It’s imperative.”
- Clinical transformation driving by end users, not IT
- Big-bang, organization-wide Epic rollout
- “We weren’t going to be experts at go-live”
- Contracting w/ Nuance for support and clinical help desk
- “That made all the difference.”
- Dual CIO & CMIO roles – “It’s been a learning process.”
LISTEN NOW USING THE PLAYER BELOW OR CLICK HERE TO SUBSCRIBE TO OUR iTUNES PODCAST FEED
The operations team that’s doing that work day in and out day, all day long — the physicians working in the emergency room, the surgeons in the OR, our clinic physicians — they’re the ones we really have to engage.
It wasn’t something where IT came out and said, ‘It’s time to get a new EHR.’ It was very much the opposite; it was the end users saying, ‘We need something different.’
There are more ways to do things, which sometimes is great; but sometimes, it’s difficult to learn the new workflows, and you run into stumbling blocks. We needed our clinical folks to have that support any time, day or night, that they might need it.
From the very moment we went live, if a patient that was in one of our smaller hospitals needed to be transferred to our larger, tertiary care hospital in Rapid City, we were able to do that, leveraging the full information-sharing capabilities of the system.
Gamble: I imagine it’s really important to have the right approach, especially when you’re dealing with this type of change.
Lahr: As a physician in a CIO role, it probably is easier for me because I came into the IT side from operations. Still, you have to have a clear focus on the operational impact of what it is you’re giving to people. And even though I come from a clinical background and still have some limited clinical practice, the operations team that’s doing that work day in and out day, all day long — the physicians working in the emergency room, the surgeons in the OR, our clinic physicians — they’re the ones we really have to engage. And that goes for our front desk staff, our billing folks, and the nursing staff both in clinics and in the hospitals as well. The best way how to figure out how to build them what they need is to get their engagement and their participation.
I think the key to success with any rollout — whether it’s an EHR or any other technology system — is to ensure the operational folks who need that technology are intimately involved in developing the strategy and testing out the workflows; and it’s very easy not to do that. It’s easy, even for someone with my background, to let those slip through the cracks or just not to take the time to do it, because it is difficult to be able to get the time that’s needed from folks on the operational side to be able to sit down and help guide us and create this road map. It’s difficult, but it’s imperative.
Gamble: Sure. Did you have good amount of interest as far as people who wanted to participate in these discussions and be engaged in the process?
Lahr: Yes. We were really lucky in that the initiative to transition to a unified EHR — which ultimately was determined to be Epic — was driven by an operational need. It was driven by an assessment that said we have some gaps and we think transitioning to a unified EHR is going to help us lay the foundation to start to address those gaps. It wasn’t going to be the solution; but it was necessary in order to start putting the right solutions in place.
So from the very beginning, our operational folks — our physicians and our caregivers — were very invested in the concept of making this change. It wasn’t something where IT came out and said, ‘It’s time to get a new EHR.’ It was very much the opposite; it was the end users saying, ‘We need something different.’
From that perspective, it made it very easy to continue that engagement. We set up multiple governing committees with different specialty focuses. We had a physician advisory committee. We had a nursing and ancillary services that had their own advisory committee, and a financial and HIM team that had theirs, as well as an overarching governance group. And we’ve managed to maintain most of those in a modified form since the time we went live. We continue to have those stakeholders involved with us in ongoing decision-making. It’s harder to continue to operationalize that after the big project is done, but I think people have seen the value in it, and so they remain pretty committed to doing it.
Gamble: In terms of training and support, did you end up reaching out to a third party to help manage that?
Lahr: Yes. That was an important decision for us. We were going live with Epic across our entire system at one time, and we were, for all intents and purposes, novices in Epic. The reality is, we know a lot more about our system now after a year of using it, than our analysts and those folks who built the system knew at the time we went live. We acknowledged that a) we weren’t going to be experts at go-live, and b) we didn’t have an internal group to be able to utilize as subject matter experts.
For example, when an organization goes through a rolling go-live, you can limit the size and scope of the first go-live — at least to an extent — and you can leverage those users as you move throughout the rest of your go-live as experts to help the rest of the system to be successful. Since we were doing everything at once, and it was going to be new for all of us, we decided it was going to be necessary to work with a third party to help provide go-live support.
It was also a goal of mine that from the moment we went live with Epic, we would have 24-hour support available for our clinical end users. That was not going to be manageable from the standpoint of actual bodies employed by Regional Health. We’re not a big enough system to be able to accommodate that. And so we also went out to look for a third party that could help us provide that 24-hour support.
I’ve used Epic prior to coming to this organization, and I knew that system is more complicated. There are more ways to do things, which sometimes is great; but sometimes, it’s difficult to learn the new workflows and you run into stumbling blocks. We needed our clinical folks to have that support any time, day or night, that they might need it, even after the initial go-live was complete.
And so I had discussions with several different groups, and we ultimately decided to work with Nuance to provide our clinical service desk as well as third-party at-the-elbow support. Honestly, it was a relatively easy choice. We had just done a major upgrade to our frontend speech tool, which is from their network, in addition to Dragon Medical One, and that had been successful. But we also had the added benefit of utilizing their service desk as well as their at-the-elbow support staff, in that they were familiar with it and able to train Dragon as well.
We combined all of those things at once, and when we went live, we had about 200 people physically here that were doing at-the-elbow support, coordinated all around our system, and providing support both in our clinic environments as well as in our hospitals. It was mostly directed at front desk and clinical staff, but it also included non-clinical folks, like billing and coding.
At the same time, we turned on our clinical help desk. That meant if you didn’t have somebody at-the-elbow immediately available or you didn’t want to wait for someone, you could call the clinical help desk and they could help track problems, log problems, or assist you if it was a training issue. That, I think, made all the difference in the success of our go-live.
One of the ways I measured that success was that, with one exception, I didn’t have an Epic analyst that had to leave the command center to perform at-the-elbow support for any end user during the entire time we had the command center open. The fabulous part is, that meant they were in the command center actually fixing issues or making improvements to the system, and we had a whole other constellation of people who were at the elbow providing support.
Gamble: That’s definitely a positive. Given all the challenges you had in doing a big-bang, like not being able to leverage experience gained in subsequent rollouts, would you still do it that way again? All things considered, do you think it was the right call?
Lahr: Absolutely. It was definitely the right call. While we had to infuse those additional resources to be able to provide at-the-elbow support, we didn’t have to go through any of the challenges of hybrid workflow. From the very moment we went live, if a patient that was in one of our smaller hospitals needed to be transferred to our larger, tertiary care hospital in Rapid City, we were able to do that, leveraging the full information-sharing capabilities of the system. It was the same with our clinics and emergency rooms.
We also, right out of the gate, were able to see some real benefits in sharing with the rest of the Epic community. If a patient, for example, came into one of our emergency rooms and had multiple other ER visits over the preceding couple of weeks, we were able to access all of that information in that hospital for that patient, and were able to change some of the care that was provided, as well as mitigate the need for unnecessary testing, because the results were available to us. Those opportunities wouldn’t have been existed if we had started, for example, in one hospital and then slowly rolled out over time.
I’m not saying there isn’t a number where you might say a system is too big to do it all at once; but for a system of our size, it was perfect. Any heartache that was there because we were all learning at one time, was completely outweighed by the benefits of immediately sharing information and the lack of hybrid workflows.
Gamble: As far as your own role, do you still have the CMIO title? How does that work?
Lahr: Yes. I came here as the CMIO in April of 2016. During the process of our EHR unification project, the CIO that I worked for at that time, Dick Latuchie, who had been here for 16 or 17 years, had announced his impending retirement. And so, after a number of different conversations and considerations of different ways to structure things, we decided that I would take on the CIO role, but keep the CMIO role. And so, technically speaking, I’m the CIO and CMIO, and having been doing that for almost exactly a year. It’s definitely been a learning process, and I think there are some great things about it and there are some challenges in that combined relationship.