Don Sargent Expert Interview

Don Sargent: EHR Implementation Tips

Vice President of Customer Experience, Patagonia Health

Don Sargent shares Patagonia Health’s best practices for EHR system implementation.

The Health Organization has signed up with Patagonia health, what happens next? How soon until implementation starts?

Well, those are real common questions for new customers. I think the process typically begins with a flurry of questions for most people. It’s kind of a, “You’ve purchased the system. Now what?” moment for a lot of folks. But to your questions, you sign the contract, what happens next? At Patagonia Health, once a contract is signed, we’ll do a sales handoff internally between the sales team and the implementation team (the folks that will be working with the client directly). That’s largely to make sure that we understand the details of the contract, so we know everything that the sales folks know to make sure that we understand the key reasons for the purchase. Once we have our project managers assigned, they’ll reach out directly to the client to schedule a kickoff call. So how soon do things get started? They get started right away in our process.

What can someone expect from the organization? What does the overall implementation process consist of?

At the highest level, overall, the process boils down to these five key steps. It’s a System Kickoff, or a Project Kickoff (1). And then we go into System Setup process (2), we go right through to an Operational Review (3), which is sort of requirements gathering and system configuration. And then we go on to complete all of that before we get to User Training (4). And once we’ve trained the users, we Go Live (5) on the system.

Can you walk us through the highlights of each of those steps? Maybe a little bit more in depth?

Let’s begin with the kickoff meeting. We formally kick off the project with the client and our project manager. We’ll review the contract, discuss basic timelines, walk through the overall process, and answer any and all questions as much as we can early on. We’ll highlight implementation and training plans, which is essentially highlighting what work needs to be done, and how are we going to manage it. So this includes basic project scope and key milestones along the way throughout the project. We also cover basic governance – mostly about how we’ll be communicating with their teams, managing the project, and so forth. So that’s the Kickoff process and we are really just to get things started.

Then we roll into the System Setup process. We don’t conduct a traditional file build process, for folks that may have been through this implementation before. We provide a System Setup Packet of questionnaires and forms for the implementation team. And then we gather core information about their clinical programs and services, any clinical forms or letters that they use, any reports if they need critical reports that are maybe tied to grant programs or grant funding, and then workflow examples that they have to share with us. At this point we also begin gathering information about any data migration needs or interface to projects that they’ll have in their contract.

We then process what we call this “system setup-as-a-service” – as we create a client’s database and build out the base core system based on this information that they provide us in their setup packet. That is the beginning of their database. They’ll have access to log into the database at that point in time. They don’t have to build any of these files. In fact, our system comes pre-built with core code sets, like diagnosis codes, and CPT codes, insurance payers, and a lot of key demographic fields as well. So then we’ll add in their programs, their locations, things that are specific to their health department.

The next step is the Operational Review. So we will review this initial core build at the first operational review session. And at this point, it’s great for us to begin to include more people in the process; all of their implementation team members and subject matter experts they have within their organization. We start with a group product demonstration, which is really the first time some folks in the operational side of the health department are going to see the product.

We walk through the workflows, how the product works, and fundamentally look for gaps in workflow. We delve deeper into their functional areas; administrative, billing, all of their clinical services. We talk through their workflow, we look at any forms that they use, we do any additional product review on either side to make sure that we understand their workflow and that they understand our system.

This process typically takes several cycles to share all of this information, and to really gain a better understanding of the workflows and requirements. So what we’re really looking for is to identify any additional needs that they have that might require additional configuration. Once that is done, and the system is completely set up, we’re ready to move on to training.

So then at this point, the system setup is complete. With a number of projects we will complete UAT (user acceptance testing) testing at this point in the process. This is basically having the client verifying that the system is configured to meet needs of the Health Department. Also, for some projects, we will train a level of users called a “super user”. These are for larger projects. And in many cases, we can do this UAT and the Super User Training at the same time. Super User Training is conducted prior too End User Training, which is what we all think of when we think of training. The End User Training begins once we have all the final preparations complete.

Our training philosophy here at Patagonia Health is simple; on-site, classroom style, and instructor-led. We have great trainers. They’ll introduce a feature, and users will watch the trainer demo that feature (so they see one), and then all the users perform hands on of that feature on their laptops (so they do one). And then it’s tied all together with the overall workflow process, upstream and downstream.

So users understand that the process that they’re working on, or the feature that they’re learning, and what functions within the health department they’re responsible for – how that fits within the overall workflow. And who in the health department might be the benefactors of the output of that process in the workflow. So they have a good idea of how it fits within the overall workflow.

And then we move on to the next feature. So [users] see one, do one, and understand how it all fits together. The hands-on training approach really works. We really lean on clients to have their staff attend and be engaged. As simple as that sounds, that’s really the key to training – be there and ask questions. Have the classroom ready in the facility, prepared with the technology, the users have their laptops, the leadership’s engaged and there’s some enthusiasm about the project. And then additionally, have some post-training activities or even pre-live activities.

We have these checklists that we share with clients in advance, so all of these items can be addressed. We actually have a formalized process we share. Best practices, largely though, for those who haven’t been through implementation before. It’s good prior to the go-live to thin out the patient schedule as best they can, to slow down the pace of work during those go-live days. And then prior to go-live, establish workgroups to practice sessions within the Health Department. And just practice, practice, practice.
That really goes a long way when they practice skills prior to go-live. Again, leadership and enthusiasm are keys to success.

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.

About Don Sargent

VP – Customer Experience, Patagonia Health

Don has more than 25 years of experience in the Healthcare IT / Medical Software industry with roles ranging from account management to organizational leadership. He has worked directly with Electronic Health Records and Practice Management systems, Revenue Cycle Management solutions and Clinical Data Repositories. Don has extensive operational experience in the areas of product implementation & training, customer support, call centers, technical services, software deployment and process improvement.

Don has held prior positions as Director EHR Support Service at Misys Healthcare Systems (Allscripts), Director of Customer Service Operations for eCast Corporation, and Program Manager/Principal Consultant for The Carolinas Center for Medical Excellence.

Don is a certified Project Management Professional (PMP), and has earned a Bachelor’s degree from Purdue University.