(Healthcare IT Podcast) Post EMR Implementation: Operational Readiness & Support

For the third episode of our Monday Morning Healthcare IT Podcast, we sit down with our very own COO, Mike Sinno. Mike and Tom will be discussing some of the priorities that healthcare organizations should have when planning for the post implementation phase of an EMR implementation project. In case you missed it, make sure you check out last week’s episode, where we talked about Cyber Security with HCIs Ryan McDaniel.

Transcript

Tom:

Hello and welcome everyone. Thank you for joining us during this, the third episode of our healthcare IT podcast series. My name is Tom Letro of the HCI Group, and today I will be joined by Mike Sinno, our COO here at the HCI Group. Today we will be discussing some priorities that healthcare organizations should have when planning for the support phase of an EMR implementation project. Thank you for joining us today, Mike.

Mike:

Glad to be here Tom, thanks for having me.

Pre-Implementation Strategies for Success

Tom:

Absolutely, we appreciate your time. Now, Mike, it is my understanding that many organizations are faced with a harsh reality post go-live of an EMR implementation. What are some things you do pre-implementation to ensure that your post-live operational support model can be successful?

Mike:

Yeah, that’s a good question Tom. So, in a lot of organizations there is a lot of adrenaline and focus as you move the entire organization towards the most notable milestone in the journey of an EHR, and that is the go-live itself. However, the go-live is not the end-all be-all. It is just a milestone, and in fact, it is the beginning of the journey, and where a lot of organizations tend to fall short is properly planning for the operational support post go-live. And in order to put some context around it, first you have to take a step back and think “why is an organization making such a large investment in an electronic health record to begin with?”

And not only is it a financial commitment, and requiring substantial wherewithal to be able to do so, there are tangible benefits that are expected before you make a capital investment, an operating investment of that magnitude. I mean, that can be anywhere from transformative care, revenue cycle optimization, meaningful use alignment, community outreach, patient engagement, the benefit of a longitudinal record across the entire enterprise, etc. whatever, there is a laundry list of attainable benefits that are expected across the organization when you make an investment in an EHR. So understanding that is, once you’re live, is where you start tracking relative to those metrics. What benefits were you looking to achieve to begin with? Leading up to the go-live, the whole contingent work force is solely focused on the build, the testing, the training, that singular event of getting to the go-live. Go-Live on an electronic health record, you may operate a command center for a 2-4 week period, get your issues resolved, incidents down to a manageable level, and then you turn it over to operational support. Operational support is, you’ve got basically in your new mode of operation, and those same resources that were focused and dedicated on doing the build, and the testing and the training, are now in this dichotomy.

Tom:

Ok and dichotomy, what do you mean by that?

Mike:

They are faced with supporting the new electronic health record they just put in place, but they also have a laundry list of other projects, optimization, benefits that they’re looking to attain, additional module implementations, could be a patient portal. Anything that wasn’t achieved in the “big-bang phase”, is now what they need to focus their energy on. And if they didn’t properly plan from an operational support perspective, they can quickly get pulled into doing keep the lights on activity at the expense of really maturing and taking the electronic health record to the next level, and obtaining those benefits that were first set out to achieve.

Elements of an Effective Support Model

Tom:

Right, and you mentioned improper planning from an operational support perspective, so what goes into an effective support model?

Mike:

Yeah, so, a lot of organizations are not coming off of paper today, right, they are putting in a next generational electronic health record, that is either displacing a clinical system, or, I would call it a previous generation - generation 1, generation 2 - electronic health record. So there is an existing system that is already there that they need to be able to support. Organizations are pretty skilled at putting together a legacy support plan to support the to-be displaced EHR or EMR, and then getting through the go-live and having a road map for what to do with that labor that is no longer needed to support the legacy support because you’re on the new EHR. What they don’t necessarily think through is, the EHR is new. Whatever application you are using, it is new to the entire workforce. Classroom training, at-the-elbow support during the go-live period. That all subsides, and now you are in this operational support model, and you are going to have questions relative to how to use the system, and then those are going to evolve into optimization requests. I know how to use it, but you know what, I would like to get this down from four clicks down to two.

And you have to have a sophisticated support model to be able to respond to that swiftly and succinctly, and if you don’t, you start to lose faith, well maybe not faith, but you start to lose adoption.

Tom:

And what are some examples of a poorly-planned versus a well-planned model?

Mike:

So a typical model, you know, that is not planned for well is calling into a general service desk. Service desk technicians are skilled across a multitude of applications including infrastructure, but are not necessarily masters of any. So, you put yourself in the shoes of a physician, a nurse, or their support staff, and you are calling into a level one help desk, and you are asking for help with the electronic health record, and they are unable to help you, beyond just collecting your basic demographic information, following a checklist of things to check, but basically they are collecting as much diagnostic information as possible to throw it over the fence to a tier-2 analyst that can resolve it, it’s not very helpful.

If you think about it, when you are calling for service, with, say, a credit card, and you have to go through two or three levels of support in order to get resolution. It is not very customer-friendly, and it does not give you a good taste in your mouth when you are done from that support experience. So one thing that clients can do, pre-implementation, is to start thinking, again, the Go-Live is not the end-all be-all. Once I Go-Live and I transfer to operational support, what is that mode going to look like, how am I going to best serve the user populous that is going to be leveraging this new technology, and make it as stream-lined as possible.

And one suggestion that I have had, and one technique that I have employed with a degree of success is putting in an application service desk. In this case, since the application is an electronic health record, sometimes it gets the connotation of a clinical service desk. That clinical service desk then has a contingent labor force that is solely focused on that application. So, perhaps they are trainers, not necessarily analysts, that have a much higher pay scale, right, but more equipped to be able to deal with the first line of questions in incidents that are coming in, than say a regular service desk technician.

So the intent there is that they can answer all how-to type questions, and for those that they can’t resolve, they are collecting the proper information the first time, and they are properly triaging it to their back-end support the first time as well. So, on that last point, I think it is important to point out, legacy systems or maybe a group or two groups, three groups max, of different buckets, or categories of that tier-two support, you put in a new next-generation EMR, that could easily be a dozen or plus different buckets. So there is more opportunity to misroute tickets than there was prior to before. That all contributes to delay, dissatisfaction, lack of adoption.

Application Service Desk and Go-Live Journey

Tom:

Absolutely, but if the application service desk is the best way to go, why would an organization choose a general service desk? Or, I guess, what are some common objections to an application service desk?

Mike:

Again, a lot of organizations get lost or caught up in just working through the Go-Live, and I don’t mean to downplay the significance of the Go-Live, if you can’t bring up the system in a on-budget, on-time manner, you never get to operational support. However, all of that work and energy that goes into making that success is just lost if you don’t properly plan for operational support. So some of the things that can be done, from the inception, you’ve just made a decision to invest in an EMR. Operational support should be in the forefront of your mind as you are building your implementation plan. That is the outcome you are looking to achieve, and making sure that you have proper budget to support what you are putting in place. So an objection to that could be additional cost, right?

You’re adding that middle level of an application service desk, clinical service desk that is additional labor that you don’t have today, that you don’t need for the build. You don’t need it to get to the Go-Live, but you do need it for operational support. I often see it being pulled out as a line item in a budget because, again, the organization isn’t thinking beyond the Go-Live.

Tom:

Right, they are viewing the Go-Live as their end goal, when, as you said, it is the beginning of the project, and should be viewed as such.

Mike: Yeah, the EHR implementation is a journey, it is not a destination.

Internal Versus External Clinical Service Desk

Tom:

Right, ok, and in regards to the cost when it comes to a clinical service desk, what are some pros and cons to doing it yourself versus finding an outsource or maybe even a third party to do it?

Mike:

Experience, is probably one, doing it internally. You’re not going to have as many trainers available to you, so again, you are training a large organization that is a singular event, you have to mobilize the entire workforce, so inevitably, you have to augment your training staff in order to be able to facilitate that. I mean, how do you get 5,000 people through classroom training in a 4-6 week period? You can’t do it, and then have that same amount of trainers post implementation. So that is one barrier of doing it internally, however, you could take a portion of those trainers, and leverage them as your clinical service desk, and then still have them teach classes, get infused into rounding, etc. So there are some benefits of being able to do it yourself. However, those resources, inevitably, will feel as if they are not challenged. Maybe it’s a year, maybe it’s two years after post implementation, and they are going to look to mature as an organization, and look to become analysts and do more. So making sure that you properly plan for succession in terms of that level has the continuity, etc. One of the benefits of outsourcing it, if you will, or buying in a service, is that it is already built, it is already established, and those things, in terms of succession planning, of maintaining the main-level expertise, are already built into a service offering.

Another benefit of outsourcing versus doing it internally – doing it internally, yes, you can create internal SLAs and operating level agreements between different components of the IT organization, however, it is still a best effort. When you contract with the vendor that is providing that service, you can tell which has those SLAs financial penalties and targets. So you are guaranteed a higher level of service, theoretically, and if that service isn’t achieved, then there is financial repercussions to it, which aren’t there when you are doing it internally.

Summary

Tom:

Alright, and thanks Mike, but that is all the time we have here today. For everyone listening, make sure to subscribe to our blog and our podcast, and to follow us on social media. Also, make sure to comment below on anything that you feel we may have missed or is equally important with regards to EMR implementation planning, so we can keep the conversation going. For Mike Sinno, this has been Tom Letro of the HCI Group. The HCI Group, offering a smarter approach to healthcare IT.