The other day, I had a doctor’s appointment. I know, this is not the way a technology-related blog should start but you’ll understand the message soon enough. My doctor’s office conveniently includes a lab on the same floor which I go to after my appointment if any bloodwork or tests are needed. It just so happens that the health care system that manages my doctor’s office recently divested its lab operations to one of the national lab operations. As a result, the friendly phlebotomist I have become accustomed to transitioned to the new provider.  

Since I had labs due this visit, I made my way to the lab window. As I walked up, the phlebotomist pulled up my doctor’s orders and exclaimed, “Oh this is wrong”. She then called her coworker over who’s been with the new provider for some time to take a look. The coworker reviewed the order and said, “Well they put those in wrong! I’m going have to go tell them how to do it again.” At this point, I interrupted the mounting frustration in the air and told them that the orders had been on the books for three months and were not recently entered.  

Here is where the technology tie-in comes into play. My orders were part of a Data Migration effort that occurred four days prior. During the migration, open orders from the local health care system transitioned to the national lab. When my doctor had entered the order three months back, he selected a single order with six separate tests. When the data migration occurred, the data transitioned as six orders with a single test.

For any of us working in the technology space, we comprehend the consequences of this, but for some reason, the people migrating the data didn’t catch it. Perhaps they didn’t realize the consequence of it? Maybe the extent of their testing was only to double-check record counts to ensure they matched? 

Nevertheless, it was very clear to me that the end-user, the friendly phlebotomist, had not seen the results of the data migration within a test environment. If she had, she would have immediately said the data was wrong and sent the tech team back to try again. In the end, she deleted my six orders with one test and manually entered them correctly. While not a huge deal for me personally, it probably made her job 10 times more stressful as this was her first week with the new provider and new system.

I write all this to say, had the project champion/lead/manager included an end-user that properly tested the new system or in this case data migration, this could have been avoided. Being able to identify and include end-users that work day-to-day in the trenches, who will be impacted the most by changes, significantly improves the outcome of testing.

Have any questions on how Dynamics Consulting can help with Data Migrations and End-User Testing? Please don’t hesitate to Contact Us and feel free to connect on LinkedIn and Twitter!