Picture this scenario: It’s Monday morning and you’re driving into work. Cars are typically bumper to bumper at this hour, but not today. Traffic’s flowing so well, you’ll have enough time to stop and get Starbucks before your 8 a.m. meeting.
Then, WHAM! You hit a pothole. It came out of nowhere. The next thing you know, your car’s making a loud thumping sound.
You pull over to the side of the road and, sure enough – you’ve got a flat. To make matters worse, you don’t have a spare tire. In an instant, your morning commute went from smooth to stressful. It’s time to call a tow truck. Oh, and never mind Starbucks, you’re not even going to make it to that 8 a.m. meeting.
Wouldn’t it have been nice if you had a little warning about that pothole? A simple road sign or barrier would have helped you avoid a morning of chaos.
Warnings signs are helpful for many scenarios in life – especially as you develop your Affiliate extension strategy. There’s a lot you can learn from other organizations that have experienced challenges during this process, so you can account for and avoid potential pitfalls (or potholes) with your own program.
Experts from our Affiliate Solutions team recently discussed the most common pitfalls they see organizations experience with an extension program:
- Expectation-setting
- Delineating responsibility
- Identifying decision-makers
- Developing repeatable processes
- Testing oversight
Listen below as they offer planning tips to avoid these issues, so you can experience a more seamless affiliate extension – free from any potholes. And if you need help developing your EHR extension strategy, or have questions about specific challenges you’re facing, let’s talk. We’ll listen to your needs and help you determine the best roadmap for your organization and its affiliates.
Show notes
[00:00] Intros
[01:56] Setting expectations: The who, what, and when
[05:07] How to delineate responsibility for upgrades, hardware implementation, and other gray areas
[06:27] Tips for identifying your key decision-makers and change champions
[09:13] The benefits of developing a repeatable process
[11:57] Common areas of testing oversight
[14:10] Why you should keep your affiliate’s EHR needs and uses top-of-mind
[16:26] How to ensure you’ve found the right partner for your organization
Transcript
Lauren Piazza: Today we're going to be chatting about common pitfalls of an affiliate extension. I have with me Ben and Natalia from our affiliate team, and they're going to be talking about their experiences in this area. I'll hand it over to Natalia and Ben so they can introduce themselves.
Natalia Chebikina: Hi everyone. My name is Natalia Chebikina. I am a senior manager with the affiliate team. I'm based out of Minneapolis, and I've been in the healthcare IT for 10 years.
Ben Maultsby: And I'm Ben Maultsby. I'm also a senior manager on the affiliate team here at Nordic. I've been in healthcare IT about nine years now, and I live in North Carolina.
Lauren: Great. Thank you guys for those introductions. So we'll dive right on in and talk about some common pitfalls of affiliate extensions. The first one that I want to chat about is setting expectations. Any thoughts in that area?
Ben: Absolutely. Setting expectations is extremely important. If your expectations are not set properly, your project can often be derailed, delayed, or have cost overruns. So, it's extremely important to make sure you're setting those expectations clearly with the hosting organization and the connecting organization.
Good example I can think of there is a pediatric organization I worked with who did deliveries at multiple hospitals. They assumed that because they were connecting with a hosting organization that had Epic, they would have access to Epic at all those organizations. Unfortunately, they just had it at the single one, and were quite disappointed with that, and ended up leaving the program. Obviously, it looked very bad on everyone.
Natalia: Definitely. I think another area of setting expectations is really around time commitment, and that's both with the hub organization as well as the Connect practices. One of the projects I work on, there wasn't a very direct expectation-setting with a practice on what their time commitment will be involved, or there was a lot of times lost in communication. So they didn't expect to have as much involvement in both training, and technical dress rehearsal, anything you're required with appointment conversion. A lot of that would come as a surprise and we would have to have those conversations.
Those expectations are important to set early on, and then continuously repeated throughout the implementation so that everybody's on the same page and you have the right level of commitment from both the hub and the practice organization.
Lauren: Natalia, you bring up a good point around training. I think that's one area that's often overlooked or underestimated – the time commitment. If we look at even just a standard training for your host organization when they have a new hire, sometimes those classes can be up to eight hours. So really, having that conversation is so important, because some of these practices that are affiliates maybe don't have the ability to close down their entire practice for three days because everyone needs to go to training. So again, setting those expectations are very important.
Natalia: Right, and having those conversations early is good, because that's when you can have those conversations about being creative. So if it's a smaller practice, maybe it's after hours training or weekend training, but getting everybody on the same page will have a less chance of a surprise down the road when it is time to complete that training.
Ben: I also thought it was interesting you brought up conversions, Natalia. That's one area I usually see is miscommunicated and expectations are missed. Oftentimes people think data conversion, and they have a preconceived notion of what that would be. But often it includes different sets of data, different costs, different timelines and if you're not going to be doing a data conversion, you need to know that upfront, so that you can take the steps necessary to plan for some manual data validation and work.
Lauren: And I'm sure we've all worked with other software vendors where it's a little bit difficult to sometimes get that information from them. They have competing priorities, as well, so, how fast our timelines can be, maybe it doesn't align with other organizations' timelines.
Another common pitfall that we've seen is delineating responsibilities. Do you have any examples where you have seen this be an issue in rollouts?
Natalia: Definitely. I think it kind of goes back to what we were been discussing before with setting expectations, again as, in the beginning, it should be agreeing on responsibilities, and who is going to be in charge of what piece of the implementation. So, I definitely think it's a part of that setting expectation conversation that should be happening early in the project and then throughout the projects to kind of touch base.
I think one area I see a lot of gray in, as far as responsibilities, is the hardware, and who is going to own upgrades to any hardware that may be required, now that they're bringing Epic on board, or additional costs of pieces of equipment that the practice will have to be brought on. So that's definitely a conversation that needs to be had early on so that way everybody's aware of the costs involved and who's responsible for which piece.
Ben: Absolutely agree with you, Natalia, that that hardware is often a place where responsibilities are dropped. We oftentimes have third party organizations involved with our hardware deployments, as well as, the standards of the hosting organization that have to be met. Couple that with any specific build that the application needs to do related to that hardware, and you often have a recipe for dropped responsibilities because there's no clear ownership of any single piece.
Lauren: I think tying into that directly is identifying decision makers early on. So, making sure that we know who's doing what, but then, who are the key stakeholders at the affiliate that really are the ones that get to make those decisions. Have you seen any issues with this in the past or can you provide any examples?
Ben: Yeah, I can think of a few times where we haven't identified the appropriate stakeholders and it's caused problems for us. Many times the connecting organizations, or those out on the spoke, are smaller physician practices, and they may be part of larger organizations or other cooperatives, in addition to, having their own group of physician stakeholders within their organization who don't always come to the table when you first start a project, but if you leave those folks out, you don't capture them during the process. Oftentimes they're going to want to revisit decisions later on in the project, which again will cause delays and cost overruns.
Lauren: I think adding to that, I would even say in the physician front, if you don't have the physician champion or someone identified and that person is, yes I am the decision-maker or the voice for our whole group, at go-live you could be scrambling to create content, or you redoing build to actually meet the needs so that they're able to perform their job functions within Epic appropriately.
Natalia: Yeah, I definitely agree with that, Lauren. I’ve definitely seen an example of an organization that made a lot of the decisions without the practices at the table, so a lot of the build, and what was put into place, came a little bit of a surprise to the organization, to the practice, when they went live, and so there was a lot of revisiting of decisions, revisiting of scope that could have been taken care of early on if all of the decision-makers were there from the beginning.
Ben: This can also be very important for the hosting organization. So, I've seen scenarios where an organization may have an established Connect program and they're introducing new functionality. Again, back to the data conversion. Making sure you pull in that HIM department, and any other teams and executives that may need to be involved in the decision-making process, is something that's often missed, but it's an easy win. It's super easy to pull people in at the beginning. It's really hard to pull them in after the fact.
Lauren: And I think, Ben, going from that, I think, who from the affiliate do we need at the table, and we need the sign off from them, but even thinking from being the host organization, who from your own organization needs to be involved, and needs sign off? Is this, you know, a direction that you, as your organization wants to go down, you know, are the right people at the table having those conversations and sharing that the path you're going down, and the decisions, and what you're extending to your affiliates are the appropriate things.
Ben: Oftentimes, another pitfall that I think I've seen happen quite frequently, is not making your process repeatable. So oftentimes, in healthcare IT, we're looking at projects in a very singular manner. You're doing your Epic implementation, you're doing a hardware implementation, you do that, and it's completed. With the Community Connect program, oftentimes the goal is to create a repeatable process that can be carried on from organization to organization and tailored to fit anyone that you may want to affiliate with.
Lauren: I think also, having that repeatable process, that's going to decrease your costs. If you have a very streamlined project plan, you know what tasks needs to be completed and when, who to pull in and when. All that's really going to keep your costs down, which, in the end, is keeping down the costs to your affiliates.
Ben: It's interesting you bring up costs, Lauren. As we know, resources frequently move around. They shift from team to team, from organization to organization. Sometimes you're using internal resources, and sometimes you're bringing on consultants. So, it's extremely important to have the build, the project, the testing, the hardware, all of those requirements clearly documented and in a repeatable process, so that any individual resource with some experience can pick up the playbook and run.
Natalia: I definitely agree with that, Ben. I think having a playbook is key to making sure that the process is repeatable, and as efficient as possible, so that way you're saving time and costs for the organizations.
I think the other thing to think about when you're working on this process, is to keep it simple. A lot of times, the organizations that the hub is rolling out to, are a little bit smaller, and might not have as many people working in their offices as they would in the hub organization. So, really have to think about what their process is and how to customize the build to them, and, in the end, keeping it simple will keep the maintenance down as well.
So, for example, one of the organizations I worked with really wanted to replicate the working structure that the hub organization had, which was much more complex, and much more robust than was needed for the smaller practice that, really, only has one or two people that are looking to work those work queues. So, in keeping the list of work queues down, and keeping the list of those work areas for them is not only simplifying the process for the Connect organization, but also for just the maintenance of the build, and the repeating of the process down the road.
Lauren: Talking about different roles, and how they may not match one-to-one with your hub organization, I think overlooking testing is another common pitfall. So, if there is additional security templates being created, are those actually, are they being fully tested and vetted against what those individual's job responsibilities are? Are there any other testing areas that you've seen commonly overlooked or, kind of, oh shoot, we have to hurry up and get this done, in the past, in your experiences?
Ben: Absolutely. I can think of two good times when, or two good examples, when testing was not done and things went south. So, it's important to remember that your existing build may have changed. I worked with an organization that felt that their security at the service area and the department level was set up exactly as it needed to be, but the program had been in existence for probably five or six years. What they discovered is that things were not set up the way they thought they were, due to some unforeseen build changes over the years, and that resulted in some very unhappy clients that did not have the appropriate delineations between their organizations.
Another good example of that is copying build. So, we do want to make a repeatable process and copying build is very enticing. It saves you a lot of time, especially if you're rolling out one practice after another in a community program. However, if you just grab and copy one practice into another, that practice may not match in the way that they do business, the way that they're organized, and the way that they're set up from a security build standpoint. So, while copying is a great benefit at times, it needs to be tested, and you need to understand what you're copying before you do so.
Natalia: Those are definitely really good examples, Ben. I want to do another plug for regression testing. I think it's definitely an area that's overlooked, not just in affiliate rollouts, but in any kind of implementation that's bringing on new build. So, it's very important to take a look, and make sure you test your existing build so there's no unexpected changes that could potentially affect your live end users.
And then, in addition to that, I think interface testing, as well, with new organizations or new Connect practices, you might be bringing in new lab interfaces or potentially anything else, so it's important to make sure that's accounted for in your testing plan, so that there's no side effects during your go live, as far as the lab results not rounding correctly and not affecting patient care.
Lauren: Another thing I want to touch on is considering how the affiliate organization will be using your system. So, one thing that I like to always keep in mind is, will they fit into your existing implementation structure? One of the roles that we often see is a rev cycle oversight individual. That really helps the affiliate understand billing. Obviously, all financial information is kept separate, so really helping them work through those work queues. The process of doing billing within Epic could be drastically different from what they were using in the past. So, just making sure they're successful, and then the financial health of their practice is not going to suffer from going live with your organization's Community Connect program. Any thoughts on that area?
Ben: Yeah, I've seen some times when we have deployed the system to a smaller connecting organization, and that organization doesn't use the system the same way that you would expect the health system to use it. So, what I'm thinking of specifically, is a patient search. So, maybe you have a very specialized practice that is going to be a connecting affiliate. They may not want to search every single patient in the health system database, whereas a nurse at the hospital very well may need to do so. So, it's important to consider that, and make sure that you've set up the patient search in a way that is most efficient for all parties involved. You don't want a physician trying to search through tens of thousands, even hundreds of thousands of patients if it's not necessary.
Natalia: Going back to your point, Lauren, I think it's also important to have the rev cycle contact, or someone along those lines, with the hub organization. Mainly because their rev cycle timeline is so long. It's usually way longer than the normal go-live period because you have to wait for the claims to go out, and the payments to come back in. So, by the time some of those practical lessons come into play, a lot of times the support, that go-live support has already rolled off. So, having someone to connect with at the hub organization is very helpful for the practice as they navigate the rev cycle flow.
Lauren: As we work with organizations to help stand up their Community Connect program through our Community Connect strategy engagements, one thing that we always like to talk about is: What are the requirements or eligibility around a Connect partner? Are they going to be a good fit for you or not, and really making sure that's been established, and everyone in your organization understands that.
So, as your business development folks are going out into the community and having these conversations, are they really talking to the right practices? Is this really the type of folks that you want to be included into your organization’s community? Any experiences where you've seen this go drastically horrible or just maybe not necessarily as planned?
Ben: I don't know if I could ever say that I've seen something go drastically horrible. I think it is important to consider, not only does the connecting organization fit into the program at the hosting organization, but is this Connect model a good fit for the connecting organization? Oftentimes, if you have a small ambulatory practice, they're working with a much smaller, less functional EHR. You have introduced a whole new set of work flows, a very complicated system, that is probably more robust than what they actually need on a day-to-day basis.
We don't do the proper gap analysis. It's not often thought of. We think of our Community Connect programs as a smaller slice of the health record that we use and work with on a daily basis in a health system. So, to us it's simplified. To them, it's not. So, it's very important to make sure that we take the time to understand what their work flows are, and how that's going to fit or translate into the work flows that we're building out in the Connect program.
Natalia: And I think to add on to that, it's very important for an organization that's putting together their Connect program to put together their goals and their vision for the program, and what it is they're trying to achieve from rolling out the software to other organizations in the area, and to make sure they share that as they're selling the program to other Connect sites, and making sure everybody's on board with the vision, and everybody's working towards a common goal. I think, in that case, you are truly creating a community around patient care and making sure you're working as a team, instead of just a provider of a software.
Ben: Another great example of making sure that an organization is a good fit for your program, is your governance. So oftentimes, you have governance representation from the connecting organizations as part of the Community Connect program. I once worked with an organization that extended their system to a conglomerate of other organizations. What they did not realize when they did that, is that that then comprised 50% of their Community Connect program, and gave those physicians a very large voice as to the direction of their program. What they ended up with, was kind of losing control of their Community Connect program, based on the number of voting seats that they then had. So, we had a scenario where the connecting organization was now in the driver's seat of the Community Connect program. Not a bad or a good thing, but something to consider before, you reach out to organizations and you start that sales process and building that relationship.
Lauren: Well, thanks for Natalia and Ben so much for your thoughts this afternoon. I think we have outlined many of the different pitfalls that have been seen from your experiences with clients over the past several years.
One way to avoid these many pitfalls of an affiliate extension, is to really make sure that your Community Connect program is very sound. If you have any interest in developing a Community Connect program or doing a health check on your existing Community Connect program, please reach out to us at nordicwi.com, and someone on the Affiliate team will get back to you to chat through your concerns or questions.