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

Congratulations! You did it!  You just completed your yearlong project to migrate your patient’s data from your legacy system to your new EHR.  You are now ready to move on to your next project, but wait – a Provider notices that they are unable to find a document they wrote for a patient they are seeing in their office that day.  Ultimately, you will try to cover all scenarios before you go live with your new system, but there can be unforeseen issues that you may not have been able to account for.  In this article, we will look at a few circumstances Galen Analysts have encountered in some of our data migration projects as well as what steps you can take to discover these “unknown” issues as early as possible.

• Forgotten Statuses
  During the discovery period of your project it is important to work with the technical resource to determine what the various statuses are for all data elements in scope.  While performing this analysis, make sure you understand each type of “status” as well as how that status changes throughout the life-cycle of the data.  The most common example is Note statuses – where a Provider might begin a note in one status, save it into another status, and possibly wait for others to edit it as well.  The key status however will be when they “sign” the note into a final status.  Typically, in a data migration we will only migrate notes in a “final” status, but in some cases the source system has a variety of statuses that may mean the same thing.

• Duplicate Data
  Another commonly overlooked scenario might be an instance where you have a 3^rd party system that feeds data into your legacy and target systems.  If you simply look at only the data in your source system and fail to account for data that may possibly already be in your target system you may create a headache for your end users having to sort thru duplicate data.  Failing to account for this scenario early in the process will make testing rounds very important to uncover these types of scenarios.

• Database Changes
  One unique situation encountered recently on a Galen project involved a source system database that had been updated multiple times in throughout the history of that system.   Come to find out, some data in the current database had been “dumped” into that database 10 years in the past.  The issue presented because of this was that there were recycled patient MRNs.  This was not discovered until late in one of the testing rounds and in the end a game plan was devised to account for it. However, if this had been uncovered earlier it may have changed the scope altogether and certainly would have avoided pain points later in the project.

These are only a few of the many unique scenarios that the Galen team has encountered over the years in our data migration projects.  It’s important to know that every legacy system has its quirks and oddities that even the experts in that system might not know about.  Therefore, when a Health Organization and a 3^rd party firm or vendor are working together, it is important to get all the cards on the table as early as possible to understand the history of the source system and what decisions were made in the past so that you will succeed when you migrate data in the future.

If you would like to learn more about data migrations and our go-live experiences, download our whitepaper or visit our wiki.