Junk in the Trunk… and the Data Migration Process

We bought a car about a year and a half ago. Every time I switch cars, I have this feeling of “where did all of this crap come from?” It’s a car…I like to think I don’t store a bunch of stuff in my car, but when I start clearing out the trunk, the middle console, the glove compartment and all of the little door cubby holes, there ends up being a lot more than expected. I’m not a traveling salesman, I don’t work out of my car, and I don’t have kids. There shouldn’t be that much in there. When you start going through the stuff that needs to be transferred, there are a few pieces of paper (old insurance information, receipts, etc) that can be thrown out, but you ultimately believe that you need to move all of that stuff to the previously clean new or new to you car. That stuff can add up. I remember having three full shopping bags of stuff last year.

Switching EMR systems is a lot like switching cars or moving. There is a lot of planning involved, you have to move stuff from one place to another, there is a learning curve to the new car or place even though you have the basics down, and there may even be some buyer’s remorse (there probably will be at some point). I have been involved with hundreds of system switches. The biggest issue facing implementations is expectations. Typically car buyers do some research about the car they are buying. I’m not saying that EMR system buyers don’t do their research. It’s just that the expectations they have of the system and the implementation process don’t typically match reality.

A system buyer not only needs to have researched the system they are buying, but also the process for the switch. How exactly are you going to stop using one system and start using another? What is the process for training users? Will the practice be down for a period of time? What is the plan for getting data from my old system into another?

It is this last question that I want to focus on here. There are several moving parts to a data migration. You have the current system and how it is implemented, the current vendor, the new vendor, and the new system. Any one, or more, of these parts can put limitations on the data you can move from the old system into the new.

In the past few years, system vendors have started limiting the data they will provide when a client leaves to specific data formats. This means that you get what they will give you. Some vendors will still estimate a custom extract, but typically it is more cost effective to take what they will give you in the standard extract. When evaluating a custom extract, you really need to think about the cost benefit of getting the data you want that is not in the standard. I recommend getting the information about what data a system vendor will provide and costs as early on in the process as you can. You will probably get a shopping list of the different data you can get. This is good information to discuss with the vendor for the system to which you are switching.

When you talk to the vendor who is migrating data into your new system there are several things you want to understand. Below is a non-exhaustive list to get you started:

Data To Be Migrated
  • What data can they migrate into the new system in comparison to the data the current system vendor provides?
  • What is this data going to look like in the new system?
  • Will the migrated data be reportable?
  • Will there be a test migration so that you can evaluate the data migrated?
  • If there is a test migration, will anything be erased or overwritten when the production migration is run?
  • Does the data need to be pulled from the current systems multiple times?
  • Will there be a staggered go-live so that different groups of patients need to be migrated at different times?
  • Will there be downtime in the old or new system for the migration?
  • Will there be a period of time in which you’ll have to track data in both systems? In other words, after the data is extracted from the current system, will you need to track any data changes in the current system and enter them manually in the new system?
  • What are the different options for migrating the data and what are the costs? (Are there cost benefits for doing something different?)
  • What is the timeline? When do you need the data and when will it be in the new system ready to review?

Data migration really comes down to getting the most useful data you can into the new system. If you are not going to use the data for reporting, it is all right to get the data in summary form (like a PDF of a progress note). If you need the data for reporting or quality metrics, it may be best to pay to have the data migrated. You really have to look at the cost benefit of having the data for reporting vs the cost of getting the data migrated.

I know this is a lot of information to gather, review, and understand, but the more you know, the less you will be surprised by the process. It also helps prevent issues during implementation when you expect one thing and are provided another.

Remember: When you are moving, it’s okay to get rid of stuff you don’t need. Oh… and don’t forget the garage door opener!

The above article on EMR data migration for your medical practice has been brought to you by the Mi7 team, who not only know how to move the junk in the trunk, they also know a thing or two (or a hundred) about moving your patient records, data, and vital stats out of your existing electronic health records system into a new one. Email them today to find out more. Oh, and they’ll help you decide whether to dispose of the gum wrappers you find under the seat.