Part of our data migration blog series – a range of topics intended to help organizations who are migrating from one EHR to another.

In the current landscape of the Healthcare world it has been very common for larger practices and Healthcare Organizations to acquire smaller practices and consolidate resources.  Just as common, those larger organizations are then responsible for transitioning their newly acquired physicians and staff away from their old legacy EHR and into the current EHR.  This can be a daunting task because there are many factors that come into play, some being: new EHR training, archival, and the migration of historical clinical data between EHRs, to name a few.

Galen has become accustomed to working with clients in this situation due to our experience with historical data migrations and our archival services.  We’ve worked with many organizations that have acquired or partnered with smaller groups of practices that use a variety of EHRs.  To have consistency throughout the organization, they will switch the new practices to their current or intended EHR.  There are three to four main EHRs we see larger organizations using or implementing.  Our most common data migrations are with organizations switching to Epic.

There are many factors to take into consideration when migrating data into Epic, such as: timeline, scope, resourcing, and competing projects/initiatives.  The current state of the Epic environment also needs to be factored in.  For organizations implementing Epic for the first time you have a lot more control over the configuration and loading of data into Epic, but when you are already live with Epic you will need to consider a few things before migrating data from any legacy EHR:

1. Will the legacy system be archived or read-only?
   This will drive the scope and depth of your migration project. If you know that the legacy data is being archived it might be beneficial to narrow the scope so that you are only bringing over the most pertinent patient information for the Providers to perform their job. It’s also important to consider when the legacy EHR will be retired or turned to read-only.  Once the new providers are switched over to Epic, how much time will they have to finish up documentation in the legacy EHR and will this documentation need to be migrated to Epic.  We often recommend doing 1-2 gap migration loads after providers have started using Epic.  This will help catch any last-minute documentation or results that we received after the switch.
2. Is there already a process in place for the Epic system to receive data from the legacy EHR?
   You may already have a process in place where certain interfaces are set up for the data that was sent from your legacy system into your live Epic environment.  Many smaller practices may use a larger health system’s lab services or other ancillary services, so those results will already be in the Epic system.  Sometimes organizations will also have a process in place where documents from the legacy system were already scanned into Epic.  Overall, make sure you are mindful of these scenarios so that you are not duplicating effort and presenting more risk than is necessary.
   Similarly, patients are often seen by providers in both organizations, so their data is already in both systems.  With a patient’s data in both systems, duplication is a major concern as well as the accuracy or variance in how the data was recorded when converting it from one system to another.  Depending on how organizations plan on migrating the data, there are Epic tools that can help with the cleanup and reconciliation of some of the major data types such as problems, medications, and allergies.
3. What does the EMPI load schedule look like?
   This is very important in many ways.  If you already have a process in place where the legacy PM system feeds into Epic, congratulations!  Most times the patients from the legacy EHR will need to be loaded into the live Epic system which leads to additional set up.  Organizations should work with Epic to confirm their system is set up to recognize duplicates and handle the addition of legacy IDs to the patient’s ID in Epic.  You will also want to map out the EMPI load plan for your migration testing environment so that you can prepare for your validation efforts and be sure that all patients are in place before you begin your initial production data loads.
4. What build is needed to support the data migration?
   During your data migration project, you will need to determine what additional build is needed to support the new site going live with your Epic system.  Some build is always necessary, for example: users, providers, departments, and results interfaces.  In regards to specific data elements being converted you will, in most times, try to use existing build entries to map to so that the data reflects how it currently appears in Epic.  However, if your existing build doesn’t match up with the data being migrated, then you will need to build and move new build through a vetted change management process.

Moral of the story, if you’re migrating data into an existing Epic environment you want to treat it much differently than you would a migration into a new Epic environment.  Every organization will implement new EHRs and acquire practices at vastly different points in their history and every situation will have different hurdles and obstacles to overcome.  Make sure you take these considerations into account and don’t be afraid to think outside the box.  Many times, Epic and other consulting groups can help lead the way, but ultimately only you know your organization’s current state along with any decisions that had been made in the past.

Check out our full data migration blog series for more insights on implementing a successful process.

To learn more about how Galen can help with your data migration projects visit our website or contact us below: