“Perpetually learn and share” is one of the main principles of the Galen team. We not only strive to share with our Galen peers, but also with our clients and non-clients. While it is important to share knowledge with each other, it is also very important to learn from each project so that we can improve our methods and overall outcomes. The Galen team does this on a regular basis and we also schedule time at the end of our client projects so that they too can learn and improve their workflows.
We had one such lessons learned meeting recently with a client who just completed a two phase NextGen to Epic data migration. Typically, we try not to perform migrations in two phases, but for this project it was necessary because there was a short timeline where we needed to get the most clinically relevant data in quickly. After phase two was complete, we reviewed our processes used during the project, and examined how well we had applied our accumulated lessons learned from a previous migration project.
Some of the lessons learned from this project included:
Tracking New Build
It was important to have a tracking system in place for all new build required to support the data being migrated into the target EHR for both the test and production environments. This is a key piece of any data migration project, but especially for a new EHR implementation. Early on in this project we were having difficulty tracking build across teams and needed to implement some of the ideas in this change control process article to get ourselves on track.
Production Latency Consideration
The effect of a data load into the production environment also needs to be considered. Commonly a testing environment will not be configured the same as the production environment, and therefore it is important to assess how a data load into that testing environment will correlate to the load into production. For this project it was not possible to replicate in test how the loading of message files to the production server would slow down certain reports that were only run in their production environment. Once this issue was identified we were able to come up with a game plan to test a new method in Prod that we used throughout the remainder of the project.
It is a good idea to involve providers and clinical staff early and often in the data migration process. If you do not get their feedback early on you could waste a lot of time testing and working on data that ultimately gets cut from scope or is deemed to be duplicate data. Because we had such a short timeline, it gave us less time to get the providers involved, and we were making a lot of changes late in the game. The key lessons learned from this situation for our client was ultimately to try to extend their future data migration timelines so that there would be more time to do assessments with their Providers and staff that will led to a more focused and streamlined validation process.
These three examples of lessons learned highlight different areas of considerations for any data migration project. They also highlight the importance of always examining each project for what has been learned and using those lessons learned in future data migrations. To see more about what we have learned over the years working on data migrations please visit our data migrations blog series and feel free to share your experience and knowledge with others on our Galen public wiki.