How to Transition to a New EHR Without Disrupting Patient Care
Changing EHR systems can be extremely disruptive for a mental health practice, and the damage is usually caused not by inadequate software, but rather by insufficient planning for the people who will be utilizing it. Practices that successfully navigate a transition without sacrificing momentum are those that approach the switch as a clinical change-management process right from the get-go.
Clean Your Data Before You Move it
Legacy EHR systems tend to accumulate years of clutter: duplicate patient files, outdated demographics, even billing records in inconsistent formats. And migrating all of that into your new system doesn’t just fail to give you a fresh start. It locks you into the past and forces you to relive it every day going forward.
But if you don’t migrate your data, you’re stuck with your old system, that’s if it hasn’t been discontinued or doesn’t go out of business entirely.
So before you hire a contractor or turn some intern loose on your database, appoint someone to audit that old system. We don’t use the term "inactive" for patients or the data we have on them, but you know the records that haven’t drawn a recent change. Flag them for archiving rather than migration. Far easier to pull a legacy record back from the archive should it become needed than shovel terabytes of moldy bits and bytes over to your shiny new EMR.
Design Templates That Actually Fit Mental Health Documentation
Standard EHR templates do not facilitate efficient mental health documentation. Behavioral health clinical teams require specific templates to document an encounter that can include lengthy paragraphs and verbiage to describe subjective information that is easy to convey in shorthand with pen and paper but difficult to categorize in a checkbox or dropdown.
When building a template for a primary care visit you know will last around 15 minutes, you optimize for fast documentation. How can we check if this patient has a sore throat or not? If you check all the necessary boxes will it meet the criteria for follow-up mammogram billing? Did you discuss vaccines, if yes, which ones and was an allergy flagged? Your template should steer the provider to the pertinent positives and negatives without overloading them with unused sections of the template.
At the end of a visit, a doctor is only getting back to their workstation to document when another patient, a nurse, an emergency, or a sandwich interrupts them. Finding the exact location on their screen where they can type the three words that complete today’s note with an accurate picture of the patient encounter is key to making sure that note is complete while still allowing them to get home sometime before their kids graduate college. A platform like ICANotes is built specifically for this kind of documentation, pre-configured with mental health-specific templates designed to reduce charting time rather than add to it.
Build a Team Before You Build a Training Schedule
Do not wait until the week of launch to determine who is most familiar with the new system. Early on, designate super-users: two or three employees per department who undergo training weeks before the go-live date. These individuals will be the go-tos for their colleagues whenever a feature is not working as expected based on the demo.
Super-users lower both anxiety and downtime. Nobody wants to be on hold with the vendor customer service line when a patient is waiting on launch day. A knowledgeable co-worker can resolve most problems in less than two minutes.
Work with both the clinical and administrative staff on the implementation team. Billing tasks are vastly different from clinical documentation, and training that lumps both together typically does a disservice to one of the two.
Space Out Your Training and Make it Role-Specific
A single all-day training session the week before launch is one of the worst ways to prepare staff. People retain almost none of it by the time they’re in a live system with real patients.
Instead, structured, multi-phase training works significantly better. Start with orientation sessions that cover navigation and basic concepts. Follow up with role-specific modules, billing staff need to understand claims workflows, clinicians need time with documentation templates, front desk staff need scheduling and intake. Then run a sandbox environment where everyone can practice with fake patient records before touching real ones.
Studies have shown that clinicians who receive poor EHR training are more than 2.5 times more likely to experience burnout compared to those who receive high-quality training (Journal of the American Medical Informatics Association). For mental health providers already working in a high-demand specialty, that’s not an acceptable risk.
Reduce Patient Volume During the First Week of Launch
This piece of advice is often overlooked because, well, practices don’t want to lose appointments. But decreasing volume by 20-30% the first week, or adding an extra 10-15 minutes between appointments provides providers with a real cushion to get accustomed to the live system.
Phasing rollout can also be beneficial here. You don’t have to turn on everything at once. Release the basic documentation and scheduling tools in the first week, and enable billing, telehealth, and interoperability during the following weeks.
Keep Access to Your Old System
No matter how good your data migration’s sanitation, a handful of historical records will be left unwashed. A treatment note from a decade ago loses all formatting, or an old billing code just doesn’t slot neatly into the new platform’s equivalent. For the average user, immediate access to the legacy EHR is easy enough at the outset, but inconvenient, slower, or sometimes seemingly impossible for the first 2-3 months.
That’s your fallback. The legacy EHR is a nearly costless system to operate as compared to trying to explain to a patient that you can’t provide the medical records necessary for their ongoing care because, well, they’re sort of stuck on the old computer.
There’s always going to be some pain with the loss of familiar tools and routines, but it should be workflow pain.