Expert Interview: Don Sargent

We typically go live on portions of the system ahead of time. So things like patient registration and calendaring can already be live prior to the official clinical go-live. So once the training is complete, the client is ready to Go-Live on the system. I’ve always said the go-live is not the end of the process, it’s really the beginning. You know, from an overall System Adoption standpoint, it’s really somewhere in the middle.

This process is a little bit different for everyone. There’s some fast learners, there’s some slower learners, so folks need to have assistance, maybe even from a training standpoint and go-live. And then change is energizing to some people, and it’s a strong stressor to others – some people resist it more than others. And so we’re always identifying who needs a little extra help even within the Health Department during go-live. Lastly, we look at our clients for help – they know their team’s best, and how to get everyone to a comfortable place for this key stage of the process.

I always joke around with folks that learning an EHR is like learning a musical instrument – it takes practice, playing time to get comfortable, and ultimately get good and pick up speed. Folks need to just be patient and think about it as a skill that they’ll eventually get better and better at. And of course, at this time is a key factor that the leadership and super users support their teams over this stretch of adoption. Be leaders and maintain that enthusiasm to get through this phase of the project.

And then post go-live. Lastly, it’s about keeping momentum going. It’s about making that shift from “how we used to do it” to “how we do it now”. Leadership at all levels is critical at this point. Subject matter experts and key individual contributors who can own and lead and help others run the health department is critical at this stage of the game.

How long does the EHR take to implement on average?

Yeah, that’s always a tough one. I will tell you that it can take anywhere from three to four months for a smaller project. And that’s really the bare bones for folks who are ready to implement. Or [it can take] as long as three to four years for much larger enterprise projects. But I’d say that the typical organizations, say for Public Health Organization with 50 users or less, the average for us is about six months. Give or take any, you know, particular needs that the client might have. But largely, we’re coming in at about six months for an average project.

How do you make a plan for implementing an EHR? And how is the client’s team involved in that plan?

Yeah, great question. I mean, I think every project is different from a customer standpoint. For us, we assign a project manager to each implementation project. And it’s with the assistance of this project manager that a client’s plan is created. We have a standard structure that we utilize as a common starting point for all projects, and then we tweak and adjust that standard framework based on the client’s specific needs.

We’re always looking for what makes each customer unique. So also there’s a shared responsibility, as well between, say, any vendor and any client with Patagonia Health and our customers. And understand that projects like these are a big change for everyone in the health department, especially for the individual staff members. So like I mentioned a minute ago, people handle change differently, people learn differently. As leaders within these health departments in these projects, (the folks that are making these decisions to adopt the technology) provide resources and support and training and encouragement as needed to make these transitions successful.

What we have learned is that when it comes right down to it, there’s about three real critical components for successful EHR transition, that focus around Product, Process, and People. And our take on that is from a product standpoint. Patagonia Health provides the software product and all the services needed to set it up, configure it, train it, take all their users live on the product, all the features and functionalities that the health department needs. That’s our area of expertise. From a process standpoint, in our experience, it doesn’t matter if you’re coming from another EHR or transitioning from a manual process, or in some cases, both.

There’s typically the opportunity to improve processes throughout the health department at a time like this. And it could be redefining or streamlining workflows, or it could be revenue cycle improvements, or just overall process efficiencies.

As part of the transition, organizations need to review how they’ll apply the new technology to make it work best for all their programs and services. Our implementation team can share the expertise that we have, from all of the experiences we have working with other health departments, pros and cons. And [they can share] all of the approaches that we’ve seen, taken by helping guide health departments through the process. In the end, all of these decisions are the health department’s to make. We will pose the questions and then guide them through, and our team will help assist along the way.

The people piece is really the best part. The aspect here [with these projects] that is the most significant change to manage is people. To have a successful implementation requires people. The potential for big changes in the organization will impact staff in different ways – again, some positively and some negatively. So, as I’ve said a million times, clients know their people and their teams best. So it’s their leadership teams that will need to be engaged to provide adequate assistance to their staff to help them transition and know how to manage their people appropriately. And then keeping their staff informed throughout this entire process will help them all feel included in the process, and better positioned to embrace the changes. And so those are the key things that we see throughout the planning process: product, process, and people.

Who needs to be involved on the client side of implementation, and what are their responsibilities?

The client is going to create an implementation team that will participate and engage in this process from start to finish. Projects like these are going to require leadership, some decision making, and good communication. Then we touch on that throughout the process. But typically, that depends [on the organization’s size]. If it’s a small project, it might be that we have fewer people wearing multiple hats. And if it’s a large project, we might fill all of these positions with different folks.

But largely, we need a Project Sponsor. Oftentimes it’s whoever purchased the system. It could be the Administrator of the Health Department or an executive in an agency. And then ultimately a Champion on the clinical side for EHR adoption. So that’s a medical officer, or maybe a lead physician. And then we have a Project Manager. This would be our primary point of contact. Our project manager would work directly with the client’s project manager. That [person] has a key position on both sides of the equation.

And then [you need] some form of leadership throughout the functional areas. I call these “Transition Leaders”. Needed for the billing function, the administrative or front desk folks, each of the clinical service programs should have transitioned leaders, including if they have an IT or a data analyst within their county or in their health department that too, would be a transition leader. And if they have multiple locations (we have a few health districts that have multiple locations) it’s nice to have a site leader to transition at the site level as well.

And then Subject Matter Experts (SMEs) are needed for billing, administration, the clinical service programs, IT, and data functions. Sometimes these folks wear the same hats, they’re the SMEs and transition leaders, but in large organizations, they might be separate folks.

And then considering larger systems, I believe finding key frontline staff for roles within the implementation team is a best practice. Where we see that happening, we have seen a lot of success. I mean, who knows better how the Health Department operates. Who has a good rapport with other frontline workers and users that can help listen to the frontline staff, and be a frontline, support staff person as well. So bringing in key individual contributors to the team is a good practice, and I encourage it for a lot of projects.

And then ultimately, Executive leadership, [which are] any other stakeholders that need to be informed, or could contribute at certain times to help make a decision, or just lead and communicate and be cheerleaders. So any combination of that group of people is how we make up a customer side and implementation team.

Can a client go through the implementation process virtually? Or do we prefer to do on-site training?

You know, this is a tricky question. We prefer on site, I’ll just say that. You know, I think I’ve been my entire career (25 plus years) working in client facing roles, and healthcare IT, I’ve always gleaned the most the most benefit from having visited a customer on site. And sometimes you wonder, even nowadays, prior to a trip, I will wonder: is this worth the expense and the time? And then I always come back feeling like, how did I discount the value that that would provide just seeing people meeting people being in their office? Building that trust helps.

So on-site, classroom style, instructor led, like I mentioned before, is our preference. That’s our philosophy. Again, the see one, do one [will help them] understand the workflow. And so being in the office, knowing where the label printers are, and knowing where the administrative people’s offices are… just understanding how a customer works. The patient flow all the way through the office really matters. So there’s a multitude of advantages to having our trainers on site. And there for the go-live as well. And so, again, I label it this way: the ability to walk through the office, seeing the clinical workflow firsthand, and meet all the staff directly is worth it alone. Even if we did one visit to do that, and they went live virtually, it would be a big difference.

This builds trust. I think once they know who we are, and they have a relationship with more than just the project manager, but also a key trainer or maybe a few other folks within the business, that helps projects be successful. And so when we come on site, I can honestly say that we see more success. But during the pandemic, we were able to shift to a virtual process by necessity and we had active projects in progress, many of which wanted to move forward. So we developed a virtual training program to support those clients. And then we continued to use that throughout the pandemic for the last couple of years. [Now,] we’ve begun to travel again.

[This program] utilizes video meetings and conferencing tools and encourages clients to attend and be present for all those meetings. Trainings are losing that direct face to face interaction. But we’ve incorporated additional touch points through our virtual process to make sure that the engagement level is maintained. And that opportunities for communication and collaboration with clients were available, when we were doing that through the pandemic.

So with any project, some will have more challenges than others. And this is true with virtual training projects as well. Where the clients have strong implementation teams, we seem to have more success, and unfortunately, vice versa. So our preference is to have trainers go on site for the main training events, and for go-live support. And we’ve had success rolling out projects with either a full virtual or partial virtual method as well.

What happens if a client already has an EHR and would like to switch to another, say, Patagonia Health? Should they plan for an overlap period? While they continue yours in their current system while they are going through training? And then what happens with their data from their current system? Will it transfer from EHR to EHR?

These are a lot of questions we get– sometimes, right off the bat. And these are all great questions. Even in this day and age, we’re seeing clients implement an EHR for the first time, and some them are even migrating from manual processes. Again, I’ve been in this industry a long time, and [most] everyone seems to have had an EHR at least once. There’s a lot of system replacements where we are in the lifecycle of the product, but in most cases, these clients have had some form of an automated billing system in place, but maybe not an EHR. So at that end of the market, the back office solutions, has been fully saturated for a long time.

But the front end’s clinical EHR systems, not so much. So on occasion, there’s a billing service on the back end. But in either case, there’s no EHR. So you still see that. The majority, however, are migrating from current fully automated, integrated solutions, many of them have been through the implementation process before in one form or another. As far as overlapping systems during implementation, it can be done for some situations, but generally, it’s best practice to stop using the old system and cut over to the new one. For billing processes, working down the AR in the old system can take some time. And we encourage folks from the very beginning to start working down that AR and cleaning it up. It can be done in parallel, with a few caveats;

I think that all old charges should be put through the old system and cleared through for claims processing via clearing house, (or if they’re billing to direct payers) and get that traffic processed and out the door. We do this because we need a short blackout period between claims going out of the old system, and claims going out of the new system. So usually in a couple of weeks, we can do [that]. Then we want to begin entering new charges in the new system.

And then for patient balances, however, once you get down to just a patient balance and all the claims traffic has been processed, those can be brought over after this transition (but before the next statement run goes out, as appropriate to the client). That is how our system is set up. It allows for those insurance claim processes to be separate from bringing over patient balances at a later date, [for example].

So what we’ll do is work with each client on developing a strategy for this process to help them clean up the process. They want to bring over balances that are not collectible, so we help them clean that up first and then bring it over clean to the new system. So a few detailed steps, but billers appreciate that and we help them through that process as cleanly as we possibly can.

As for data migration, that can be done for sure. [Of course], there are some common sense limits to it. But largely, patient demographics are essential, and some core clinical data can migrate. And when I say that, I mean as discrete data. This is data that would populate our database and can be utilized within the new system, and reported against. Also, documents and PDFs, even old system reports, can be migrated through our document management system as well. So these will come over as whole documents, not discrete data, but used for reference only. And this is an easy method for folks to maybe get some basic chart history or patient information over to the new system in a way that they could reference it without having to go through the very tedious process of a discrete detail conversion.

What are the benefits of doing a phased approach? And why do we recommend that rather than doing it all at once?

So how we refer to these options is “phased” and we call the other method the “big bang”, which is kind of a fun term. But [when choosing] the phased [implementation] approach versus the big bang approach, sometimes that decision is made for us. And here’s why: if we talk about just basic process flow of a, let’s say, a fully manual, paper driven organization, this can be entirely manual, or it can be a manual clinical process, with a billing system on the back end. Either way, there’s no clinical system. But the clinical documentation that’s captured on paper is very frequently the same clinical format that we would build into our system for electronic forms and data collection.

So what happens in a manual process, if the result of the patient visit is a charge of any kind, whether it’s patient statement, or say an insurance claim, then a super bill, or a routing slip (or some call it a charge sheet) is filled out on paper and supplied to the billing office to be processed. So billers then enter those charges manually, whether it’s into a separate billing system, or payer portal to complete the claims process. And then when the insurance check is received, the charges are pulled back up manually, and the payments are posted against them manually. So that’s the process. The back end piece is fed by paper, and it’s completed and followed up with paper.

So in a phased [implementation] approach, the billing system is always the first phase. The paper output from a manual clinical process is fed into our system for billing. So we’re switching the billing systems out. This is manual posting of charges just temporarily, but with all the benefits of the back end of our electronic claim submission and clearing house, and automatic payment posting on the back end – we provide all the back end services. And then we can get that billing system replaced and live in the first phase.

For the second phase– the implementation of the clinical system– the previous clinical paper forms, we use those to configure electronic encounter note formats within our system. Like [putting] the paper form in an electronic form, so it looks the same, and they can contain all the same content. So in the EHR, once the encounter note is completed electronically, then the charges are entered into the system at the end of the note. So when the encounter note is signed, the charges move automatically from the clinical system to the billing system. And we call this the ESB, the Electronic Super Bill.

So it’s no longer a paper supplied process to the billing system. It’s an electronic-supplied process to the billing system. So when the clinical system goes live, which is phase- two, the temporary paper charge slips are no longer needed due to the ESB, and the appropriate clinical and charging data moves directly to the billing process and claims get filed automatically, as appropriate.

So the life of the billers improves immensely at this point as the temporary paper [process] is gone and the process is much more efficient at this point going forward. And what’s more, when the insurance payment is received an automatic payment posting feature posts all the payments against the appropriate charges automatically. So that’s the phased approach.

Now for the big bang approach. This decision is generally made for us if the client is on a fully integrated [EHR/Billing} solution. If they have a clinical EHR and a billing system, they have to go through a big bang approach. And that’s because if we were to try to feed the billing process with paper, it would be moving backwards. So the main reason is for efficiency. And so in order to attempt to take the billing system live, paper charges would have to be produced, and an automated system does not generate these. So the big bang [process] helps us in that regard [by] taking everything live at once. We’re seeing more actual Big Bang approaches, because we’re replacing more integrated systems than we used to.

Additionally, and on occasion, we still see a need to take a separate clinical program live, maybe after a core system, at a later time. This happens when we have some development or customization to do. So we can do a big bang [approach] for the majority of the health department, and then technically do a phase two for a separate clinical program once the development is complete. And that’s just another version of the phased approach.

Our teams will assist the client with all of these decisions and plans, based on what we learned through the setup and operational review process.

What are the keys to success for implementation?

Leadership, decision making, and communication. I mentioned leadership a number of times because it is important as change can be difficult. So top down leadership is always key.

Decision making is really critical throughout the entire process. Any change process is going to require options to be presented to the client and decisions to be made. Clients need to be prepared that they’ll have a lot to learn. And they’ll have a lot of options. And with those options come decisions to make.

Communication. I can’t think of any process where you’re operationalizing something as complex as an EHR, that communication doesn’t lead to success. So making sure your core teams and users understand what’s going on, that no one is surprised, and they keep that enthusiasm level of good. Solid communication within implementation is critical.