Implementing Healthcare IT Through True Partnership with Doug Allen

Doug Allen: We really want to make sure we differentiate ourselves based on our skill and our ability to work hand in hand with facility resources on site. And I can tell you, that is a huge part of why our customers are most satisfied because they do feel like they have an outlet. They feel like they have a voice.

Host: You're hearing from Doug Allen, vice president of implementation services at MEDHOST. In this episode, he walks us through the customized process of introducing brand new information technology to a healthcare organization. From the initial discovery phase all the way up to going live. Along the way, he also shares how MEDHOST's flexible process helps reach two major goals: increasing patient safety and utilizing integrated systems. All of this is achieved through communication and true partnership.

Doug: MEDHOST has a variety of different customers. The last thing we want to do is say, "Here's our system, it works this way." We have to listen to what they have to say. They provide great ideas for how we can improve this system.

Host: This is Health IT on the Record, presented by MEDHOST. A show that dives into how health information technology innovations impact every aspect of a health system, from multi-hospital networks down to individual patients.

Working with healthcare professionals on site, Doug stresses the importance of having a skilled team with a variety of backgrounds that can meet a customer where they're at for a smoother implementation. Giving customers an outlet and a voice while creating efficient, meaningful change within health organizations. Enjoy the conversation.

Doug: Hi, this is Doug Allen, vice president of implementation services for MEDHOST.

Host: Doug, thank you so much for taking the time to share with us today just kind of an overview of the implementation process, your role, VP of implementations at MEDHOST. You're able to give us a really clear look at what it takes to do this successfully, and a couple key areas we want to make sure we cover during this conversation and if any stories or examples come to mind while we're chatting, please feel free to share those.

But this interview is really going to be helpful for someone who's trying to consider going down this route to implement something that's really new to a team. I'm sure we're going to be able to hear some success strategies on how to do this stuff the right way so you can get to that expected outcome that everyone is anticipating. But the key areas about MEDHOST that will kind of guide this conversation: not a one size fits all implementation, you're able to leverage the expertise of your team, differentiation in the industry and last but certainly not least, workflows.

So that's kind of the main success ingredients that I know you're using, but kind of walk me through, whether someone is working with you right now or not, general advice for someone when they're thinking about implementing something brand new for their team. What's the biggest thing that you've seen that someone needs to be thinking about to make sure this works correctly?

Doug: Sure. And thanks, Clark, for your time. I think one of the first things we try to do when it comes to an implementation is really gauge the capability and the goals of the organization we're working with. So, typically what happens, for those of you who are considering MEDHOST or have chosen MEDHOST is, we sit down and talk about what expectations there would be from their side, the timeline from our side, and then we really walk through what makes the most sense for them.

We have standards and guidelines and timelines for all of our projects that can range anywhere from a week to nine months, but it's important for us to understand that these folks have a day job, they are nurses, they are doctors, they're pharmacists, they're lab techs, and so any time we need them involved in the project it's going to take them away, potentially, from their role. So, when we talk about not one size fits all, when I'm working with sales I want to make sure we're setting proper expectations with a customer that we know what the average timeline is, but the average doesn't have to be their timeline. They may want to go a little faster and they may want to go a little bit slower.

The important thing is that we're on the same page. So, once we assign our teams, we kind of talk through that at a high level with their executive team and then we develop a timeline that works for both parties. So that both sets of resources that can be involved in this process throughout are on the same page and we enable the customer to build a system that works for them.

And that's really the important thing is we're not going from one size fits all, where everybody gets the same solution. Every hospital has different operations that they utilize, whether they are a rehab hospital, behavioral hospital, a short term acute, a long term acute, critical access, we see all types of hospitals at MEDHOST. So it's really important that we're very flexible with our approach to them.

Host: I want to come back to what you're saying in just a moment, on the topic of not a one size fits all implementation. But before we to get to that, so you're just sharing how important it is when you set a timeline, whether it's longer, whether it's shorter, just make sure you're on the same page.

We're talking a little bit about some of the capabilities that are being explored, but you also mentioned goals. And goals, from your view, from the client's side, what have you seen in the past have been smart goals? And maybe goals that you might want to avoid, going into something like this. If this is new territory for someone, based on what you've seen, what and where should someone's head space be when they're thinking about setting goals for an implementation?

Doug: Sure. We're almost all the way past most hospitals having actually used an electronic system, but back in the day, a big part of their goals was for patient safety to kind of have everything kind of stored electronically. And so we saw quite a few customers talk about, patient safety is one of their number one goals whether they're moving from another system or going to an electronic system for the first time.

Another one is really kind of coordinative care, so across the spectrum, utilizing what they would consider integrated systems. So one of the things we do encounter is MEDHOST is typically not the only system a customer is implementing. We may be interfacing with a General Electric PAX or a laboratory system that the customer has in place, so they want to make sure that when they're implementing a system, the workflow itself makes a lot of sense. So they're setting goals for the most part strategically around ease of reporting, ease of use, patient safety. They're the three most common ones we see.

They're very realistic and if they aren't sure what their goals are, we can actually help them with that and say, "We can make sure that we keep your AR down when you convert to our system and we have service offerings for that. Or we can help manage various components through the process to minimize their downtime."

So we talk a lot about more simplistic goals as we're going through their strategy, but a lot of it is just kind of back and forth and we hit on those goals, oftentimes after we kick the product off at discovery. Where we actually go on site for the first time with the customer so they may be saying, "Our nurses today have to do this many rounds per shift, they have to document this way, how could your system kind of evolve to help us in that area?" So, we just want to make sure we're aware of those goals, and we try to apply what we've seen as best practices because we've done this 1200, 1300 times over the years with different facilities.

Host: Whenever you are working closely with a hospital, with an implementation, so, can you kind of walk me through how you're walking alongside with them? Whether it's early stage, how you're talking about kind of going back and forth, coming up with what the capabilities and goals and what the timeline should look like. But when you get closer to that implementation, I'm sure that's when a lot of the emotions are probably going to be running high and there's been a lot of anticipation. How do you work directly with a hospital and make everything go smoothly and help ease any kind of tensions and to help training and to help just have a smooth roll out?

Doug: Sure. I think one of the things we try to do, Clark, is spend a lot of time with their executive team up front. And I will assign an executive sponsor on our side that becomes the high level point person should they feel any of that anxiety because, while we do have a project manager and typically the customer will have a project manager and those two parties are talking all along and setting proper expectations, it's important the executive team has a voice or an outlet that they can talk to throughout the process so any of our larger projects gets an executive sponsor.

But as part of the project, we'll put together a high level timeline that kind of walks through what they should expect. So we have a methodology, like a lot of folks, that outlines work into phases. We have the discovery phase where we kick the project off and we collect some data from them. They give us some file information, employee lists, physician lists, and we start to load them into our system. Then we have a testing phase, we have a training phase, we have a cut over phase and a go live phase, so when we're talking to the customer, we'll give them enough nuggets inside each of those phases for what to expect. And then, where necessary, we'll give the various departments the details because, at the high level, the executive just wants to know this is going to take me nine months, it's going to cost me X amount of dollars, it's going to consume this many resources.

When you're talking to the pharmacy director or lab director or surgery director, they really want to know when do my people need to be available, for how long, what kind of space do I need to give you, how many people need to be trained and what's your expectation in each phase of the project? So we do communicate quite lengthy throughout the process. More is better than less. We have regular status calls with the customer; we have a monthly status call with the executive team to give them a high level overview and to kind of break tithe if we're caught in a timing issue with something else.

And we want to learn about other competing projects. Like I said, MEDHOST is a part of their electronic health records system. They may also be doing a new construction, adding on a wing to the hospital that may consume resources. So, we try to look at the big, big picture from the hospital's perspective and then over-communicate with our project manager and their key contact to make sure that every step of the way, they know what's going to happen in the project.

Host: When you're talking about project managers working, and an executive sponsor, you were talking about how a lot of the work you try to do on the front end. I know I'm putting you on the spot here, but if you had to kind of guesstimate, I guess, or estimate the amount, percentage-wise, how much work is spent on the front end versus the percentage of effort that's spent on the implementation?

Doug: Sure. I think about 10% is a good, reasonable number. Obviously the heavy lifting happens during the implementation, but we really don't want to start the implementation until everybody's on the same page. So, while I have a lot of phone calls on the early part of the sales cycle to support them, and make sure they understand kind of the overlying methodology and how we approach projects and what formats we use for particular elements of the project, the front end stuff before we get started adds up to about 10% of the project and then the meat of the project is really towards the back end where you're doing multiple rounds of integrated testing and then ultimately moving to go-live support, which lasts a week to ten days depending on the size of the hospital. So it's a material enough number, that 10% is not a small number when you're talking about nine months or the amount of dollars it can cost to implement a large system, but if I had to put a finger on a number, you're probably looking at around 10%.

Host: Gotcha. So 10% on the very front end, but then you're saying the meat of it – so much time is spent on integrated testing, to make sure it is all going to fit together like you said in the big picture. So you think the remaining, that would be like 90%?

Doug: No, so if you break it down, when we talk about the big phases, the discovery phase which includes kind of that front end stuff, you're looking at about 10% and we call something "the deployment phase." These terms don't typically mean a lot to the customers, but what we try to do is kind of bring it down as simplistically as possible.

We're going to kick off the project and collect a bunch of information. That information, again, can be their employee list, these are all the people that are going to use this system; physician list, these are the physicians that are going to go through a different level of security to use the system; nursing list. We're going to collect all the AP vendors that they actually bill and pay to. We're going to collect a whole bunch of information on how they track their general ledger and load all that into the system. Then we're going to actually build out the system with them. That percentage is about 30%. It's called the build phase or deployment phase, if you want to call it.

Once the system is built, we kind of freeze it and then we allow them to begin to get their super users trained and we make a big distinction on training super users, and sometimes that confuses the customer a little bit, so we try to spend a lot of time in that area because the reason we don't hit all the end users is, one is for timing purposes, and two, at some point, our implementation team is going to move on. The customer's going to be transitioned to Kim McTavish, my peer, the senior vice president of customer support, where she'll handle phone calls.

So when we leave and there's not a physical body from MEDHOST, somebody really needs to be the expert there. And just delivering end user training to the organization at kind of a higher level and not having somebody who knows how to maintain the system would be doing a disservice. So we really emphasize that it's important that, if you're talking nursing, you want two people on day shift, two people on night shift, that know the system inside and out. And they help us identify who those right resources are and we fully accelerate our emphasis on those resources and so the training phase moves into the testing phase.

The testing phase, as we talked about, kind of emphasizes two rounds of integrated testing where, either they provide us some scripts of, "Hey, we provide these service lines today, let's run a patient from registration on to being admitted to being orders placed to being discharged. Show me how your system does that." And so we have scripts we can run or the customer can say, "I want you to do these scripts." And so we'll work with them jointly on that, but we'll run through two rounds of that testing to make sure we're good and then we move to what we call a go/no-go. They say we're ready to go live/we're not ready to go live and here's why.

And we either remediate, if they're not ready to go live, or we move to the go live phase, in which case we send bodies on site to sit with their people and really help them go through their first week of go live and then we move out and get them transitioned to customer support.

Host: Health IT on the Record is brought to you by MEDHOST. With over 30 years of experience partnering with providers nationwide, MEDHOST is helping evolve better solutions for healthcare management through innovative workflows and technologies. For more information, visit www.medhost.com. Let's jump back in.

Host: So to kind of shift on to one of the next points we want to talk about: expertise of your team. And you were talking about, just a moment ago, working with nurses. And when it comes to expertise on your team, I know you've got folks with a clinical background, financial, business background, but how do you find a variety of backgrounds? How does that blend in together to help with an implementation?

Doug: Yeah, that's a really good point. Something we're really proud of is, when you look at nursing for example, and you mentioned that one, 80% of our resources that implement the nursing solutions are nurses. They have a Bachelor of Science degree in nursing, they're registered nurses, so their ability to identify with the customer really resonates. As opposed to, if I was to go and place an ad out there to find a resource who knows system-related information around nursing, sometimes that's more difficult to generate the same kind of buzz with a customer.

So, if a nurse is talking to a nurse, they've been in their shoes, they understand what they're going through, they can talk about the workflow, it's a much easier understanding, peer to peer. Because they feel like they have somebody who's in the system with them and won't steer them down the wrong path, and will listen to some of the challenges they're going through.

And if you shift to financials, we have CFOs, we have business office directors, we have HIM directors that have worked in hospitals. So it's a whole lot easier for them to have the conversation with the HIM director, with the CFO, with the business office director, because they've been in that role and so when I'm looking to fill an opening, should I have one? That's the type of resource we're very particular about getting. We really want to make sure we differentiate ourselves based on our skills and our ability to work hand in hand with facility resources on site. And I can tell you, that is a huge part of why our customers are most satisfied is because they do feel like they have an outlet, they feel like they have a voice.

And that's not to take anything away from any of the other resources that we utilize on our projects who may not be an HIM director or may not be a nurse because they've used our system for 20 years. So they're very knowledgeable, but when we're looking for that skilled resource that can hit a home run with the customer, that's what we're looking to identify. Who's been a pharm tech, who's been a lab tech, who's been a nurse? If we have an ability to get a physician, if we can get a nurse practitioner, I'm always looking to make sure we have the highest level skill possible so that there is that resonation.

Host: I like it, it makes sense. And you said the word differentiation and I would love to transition over to that next. And that theme of partnership I know is a big thing I've heard you talk about before. Tell me about the partnership that you aim to create with every one of the hospitals, every client that you're working with. Walk me through that, how you look at it differently, anything else that you think helps MEDHOST stand out as a differentiation in a marketplace? I'm really eager to hear your take on that.

Doug: Sure. I know at a high level is from MEDHOST's vision perspective, we spend a lot of time talking about being a trusted partner. We want to empower our healthcare organizations to advance their patient care experience. We want to improve their business operations, so the way that I go about it with our implementation team is really listening to them.

And we talked about at the outset, what we don't want to do is force a system on them that says, "This is the way this customer used it, but 90% of our customers use it this way so that must be right for you." It's very customizable. We do a lot with reporting. We do a lot with the way they can build order sets. So the partnership really is listening. We really spend an awful lot of time on the early part of the project listening instead of telling them, this is how long the build's going to take and this is how we're going to do it.

The first most important thing we could do is go on site and listen to how their processes work today and so we document what we call a current state. How is their business run today, both clinically, financially, operationally, and then we talk about our systems. Now let's talk about our system for a second. MEDHOST goes in this direction, your current system is this direction, here's the gap. How do we want to close this gap? If there is a gap. And if there's not a gap, this is what your future state will look like. Do you agree? And then we basically get sign-off from them that says, "I agree this is the process we want to go towards."

And so, both parties document and we visually show that when a patient comes in, they're going to go here, here, here, here. Do you agree that's the process? Registration does this, HIM does this, we sign off on that together and we store that document. They get a copy locally for their policies and procedures. We keep a copy here so that there's no mystery, that we're on the same page and we've talked about it at length. So we do allow those customizations so our system may work optimally this way, but if there's a reason a customer wants to report something and the system's capable of doing that, we're going to allow them to do that.

So we spend an awful lot of time really talking about anything unique to their business. Because, as I mentioned before, MEDHOST has a variety of different customers. Critical access hospitals, community hospitals, we've got long-term acute, short-term acute, behavioral hospitals, rehab hospitals, so the last thing we want to do is say, "Here's our system, it works this way." We have to listen to what they have to say. They provide great ideas for how we can improve the system, so we're constantly on the lookout and have our ears open for what makes the most sense for them, and I think that is what kind of separates us from being a partner versus a transaction or sale, is that ability to digest what they're saying.

We don't always get it right, like a lot of vendors. It may take us some time because the government may say, for compliance purposes, you have to do this with your system. So we may get a request for an enhancement from a rehab hospital that says, gosh, we really need to do this. And we will document it and we will put it in with our development team and say, "They've got it, they're looking at it, right now the primary focus is this." And we keep them updated. So, I think the most important thing is we can communicate with them on how we can be a partner with them long-term.

Host: I think all of that fits within the not a one size fits all implementation and you're talking about how many different types of customers and I know that requires customization. Today I'm just interested in these ratios. But how often do you think – is every project going to have customization? What's the range of that typically? Maybe it varies. Maybe there is not a clear specific answer on that. But, before we move on, I was just kind of curious about – on that theme of listening and building out, meeting the customer where they're at, helping fill those gaps, any other thoughts you want to share about how much customization can go with each one of these?

Doug: That's a really good question. I would say it's probably 80/20 that they take most of the standards, but since we do have a lot of corporate accounts, the corporate accounts have a fixed way of wanting to do their systems. So once they establish what they would consider a gold standard for the way they want to set their systems up, we pretty much repeat that. It's not a rinse-repeat, but they will take what they've established, apply a new release, and then if they buy a hospital or add a hospital and install a new hospital, we carry that same process forward so the uniqueness and customization is probably from our larger corporates more so than say an individual standalone.

Most of the standalones understand that we provide best practices and they want to go with the best practices and so they run with it. And the customizations will really become involved in the process of, "I want my chart to look this way," not so much change the software itself. So there's a little bit of a distinction that I really want to make, that "hey, we've got this many employees, we don't need this many order sets," so it may not be as robust in certain size hospitals as others but it's not as customized, so to speak, but everybody does things differently. We rarely have back to back customers who run through the exact same process to get to the same place.

Host: Makes sense. Well, moving on to one of our final things I wanted to talk with you about before we wrap and it's on that theme of workflows. I've heard you say that phrase once as we were chatting today and also following along that theme of listening. When you get this feedback from customers, from your internal MEDHOST team of experts, anything you want to add here on just how that has helped refine a system that encourages efficiency and constantly be improving? Anything else you want to add on how you approach workflows?

Doug: Yeah, I think that's a good point. We're in kind of a constant cycle of listening for process improvements, so I can speak to two pretty recent examples. We'll go back to integrated testing for a second.

So, I mentioned we have traditionally two rounds of integrated testing. In the old days, not long ago, probably a year or so ago, we would physically go on site for both rounds of integrated testing. The first round would not involve the customer. We would basically take what they built and we would run through the scripts. So all we effectively were doing were, one, charging the customer to travel to their site, sitting in a conference room, and then producing a report with the results.

So, we asked our customers, does that make a lot of sense to you or would you prefer we stay remotely and do this and provide the information? Of course the answer was remote. It saves them money, so, we kind of had been doing that year after year after year and really hadn't asked the question, does this make a lot of sense? And so quite a few customers brought up the fact that, we don't mind providing you a training space, but if our registration team's not involved and our nurses aren't involved, why do you have to be here? And so we modified our process and listened to them and now we do that remotely and get the same information, get the same results. So that was a good kind of listening exercise for our organization.

And the second one was really discovery phase. Typically, a discovery phase, we would travel in on a Monday, start on a Tuesday, and leave on a Thursday afternoon. But what we weren't doing was talking to the customer at the end of that discovery meeting. So we typically kick off a project in a room with the executive team and department heads and say, "We're here, we're MEDHOST, here's an approximate timeline, you see all these resources around the table here, they're going to meet with your department heads the next three days, we're excited to be here, do you have any questions?" So that's a high level view, but where we did a poor job was wrapping up at the end of the week.

So people would go in their meetings with their department heads and then at the end of the week they would leave. And so they didn't know what the next step was. The customer would say to us, "Okay, did you accomplish what you set out to accomplish?" So, we have established now this wrap-up meeting and obviously we want to work around the customer's schedule. If the customer said, we can't make Thursday afternoon, then we would do a wrap-up report and send it to him, say, "Here you go, here's your report, but our preference is to get the team back together and say, 'Hi, very successful week, we know Materials is on vacation this week, so let's come back and do that one later, but the nursing team was very engaged, we were able to find some good things,'" etc. So we do spend a lot of time listening in those aspects.

But if you come back to workflows, we're constantly on the listen for the ways that different facilities handle their workflows. Because there may be some things at some facilities we can bring up in a non-discrete way to say, "Hey, we saw this at another facility similar to yours. This is the way they tackle that challenge. You may want to consider this, but run it by your CNO first before you obviously make a change." So, there's a ton of listening involved.

We also do pulse surveys as part of our process. So three times during the course of an implementation, we will ask our customers how we're doing, very simple two question surveys on overall kind of their feedback and then they get a chance to kind of do verbatim feedback in a text-only format. But we're asking them, did we set proper expectations at discovery? Were you trained properly after training? And then, what's your perspective of the project now that it's completed?

So, we use that data tons and tons to kind of make modifications and changes and then make real-time calls to customers. If somebody says they were unhappy, and then we get that survey, we're going to immediately place a phone call to them and say, "Hey, talk to me more about this. How could we have done it differently?" So, some of the best feedback we've gotten is from those pulse surveys and we share that across our executive team, so they can see that and they can also help us kind of look at the process from an outside view.

Host: I admire how you're able to call back on just experiences and lessons you've learned along the way. It just shows that you've been doing this a long time and you've built on a solid foundation to become even better over time. And I think it really fits back to that theme you said earlier, MEDHOST is part of the big picture and it's all about being a partner, working alongside them, helping fill those gaps.

So this has been a really insightful to hear about the implementation process from the source. Thank you so much for taking the time to share this with us and I look forward to hopefully continuing the conversation with you again soon.

Doug: Absolutely, Clark. Glad to do it. Pleasure to talk to you as well.

Host: Thanks for listening to Health IT on the Record. Presented by MEDHOST. For more stories and content like this, be sure to visit medhost.com/resources. Thanks.