Archive for Data Migration

Feelin’ Lucky With Your Data Migration or Integration Project?

My wife and I recently went to the home of Ernest Hemingway in Key West. Learning about the history of the house and some of the background of the books by Mr. Hemingway, I decided to read some of Mr. Hemingway’s work. I started with The Old Man and The Sea.

For those of you who have not read this wonderful, short, piece of literature, I won’t ruin the story for you. I will just give you a synopsis of the story here so we can get to the point.

The story is located in and off the shores of Cuba (also Mr. Hemingway’s origin). There was an old man. He was a fisherman. He hadn’t had much luck with the fish lately. One day he went out alone on his small fishing boat. There is one quote that I want to focus on for this blog. The old man says it to himself several hours after he set out on the boat.

“Every day is a new day. It is better to be lucky. But I would rather be exact. Then when luck comes you are ready.”

I think this quote especially applies to system testing. In the “Magic!” blog, we discussed the process of integration projects:

Vendors involved in implementation of an interface usually do roundtrip testing (to verify communication) and basic test cases. The responsibility for the more rigorous testing typically falls to the client. This is what is called user testing. The client needs to outline the different business scenarios that the interface was designed to solve and develop test cases that will verify all of the business scenarios. Make sure you devote ample time to testing. It will save you headaches in the long run.

Let’s break this down further.

What is roundtrip testing? For each type of message (demographics/ADT, scheduling/SIU, charge/DFT, etc), the sending side of an interface will send a message. The receiving side will verify receipt and verify the message is formatted as expected (see “Standard is not so Standard” for more discussion of setting expectations). Note that this is more to confirm that the two systems are talking rather than to verify any sort of business logic.

Why do most vendors only do roundtrip testing? Most vendors will not know the workflow intricacies of a practice. The vendor knows what is in the specification document for the integration. They can test what is outlined in the specification, but what is outline in the specification does not necessarily encompass all variations in workflow practice encounters, especially rare scenarios. The vendor relies on the practice to know their workflow and to understand the different scenarios that need to be tested in the integration. This is not always the case. For example, the practice may have a couple patients that come in once or twice a year. These patients are special cases and the practice may need to have a special workflow in their system for these two patients when they visit. An integration built for the standard use case that covers 95% of all encounters may not properly handle the special cases in your practice.

It is the practice’s responsibility to identify these special use cases and test for them. When I discuss testing with a client I ask them to first describe the typical workflow. For example, we have a client that implemented a demographics interface from an associated hospital. The typical workflow for a patient that doesn’t exist in their system is to add the patient, add the guarantor, and add the patient insurance. The typical workflow for a patient that does exist matched on account number, first name, last name, and date of birth is to just update demographic information, leave the guarantor as is, document the patient insurance in the demographic notes, but don’t update the patient insurance on the patient.

Once you have described the typical workflow, start going through the possible variations of the workflow. You need to include knowledgeable people from all departments that are affected by the interface to catch the possible different scenarios. In our example, as we were testing, we found a special scenario where a patient was admitted to the hospital ER, but the new account entered in the hospital system had a temporary patient name. Well, this prompted a message across the interface with the temporary name. This name was entered in the receiving system side as a new patient. When the name was updated, we got a mismatch because the account number matched, but the patient name and date of birth did not. This prompted us to change the scope and logic of the interface on receiving side to discard patients with certain specified names and departments. Once all of the information was filled out, we would then enter the patient on the receiving side.

It is always better to understand these different scenarios when you are scoping out the integration project, but if the practice does not catch the scenario in testing, it can cause bigger data issues in production. In the example, not testing all of the scenarios could have resulted in lots of incorrectly entered and mismatched patients when the interface was put into production.

Another important point with testing is to test everything every time there is a revision. If you caught an error in one of your testing scenarios, make sure to test every step in all of your scenarios again when the error is resolved by the interface vendor. There have been many times when I am testing for a client that when the vendor fixes one thing it breaks something else. The fix had unintended impact on a different part of the integration process. Start from the beginning. Test every scenario thoroughly with every revision. You may even find that other scenarios come up when you find an error that you need to test specifically to make sure the previous error does not rear its ugly head again.

A practice should realize the system is theirs. Accepting what happens to you after the fact is never a good position to take. The practice is the last line of defense before a system or interface is implemented that could benefit or harm the practice. Test it. Understand it. Even if project scope needs to change, it is best to catch an issue up front before your practice is reliant on the system and has to implement work-arounds to accomplish their goal. You may realize that it costs more in the long run to allow things to happen without testing than to put the effort in up front and make the system work as you need it. As the quote said, you might get lucky, but it is better to be exact. It is better to be prepared. Then you will be ready if you are lucky.

Is your practice planning a data migration or integration project, and relying on luck to get you through it? Don’t do it! Luck will only get you so far. It will probably not catch you a fish, and most certainly won’t lead to a successful data migration for your medical practice or physician organization. Migrating data from one electronic health records system to the next takes careful planning and testing. Rely on the data migration gurus at Mi7 to put you on the right path. We’re not lucky, we’re exact. And that’s the way (uh-huh uh-huh) we like it (uh-huh uh-huh).

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.