This is part of our data migration blog series – a range of topics intended to help organizations who are migrating from one EHR to another.
“Your migration is only as successful as your testing and validation efforts.” – Mary Ellen Ford, Conversion Manager Baptist Health
When it comes to testing migration data, the overall rule is to validate absolutely everything. Details, details, details! Our goal as consultants in a migration project is to load the data, confirm that it is going to the right places, then test and validate that data for accuracy. Additionally, it’s important to note, we need to involve our clients in this process!
Conducting a testing and validation stage inclusive of client resources is crucial. This will confirm that all employees are able to go through their normal workflow once we’ve gone live on the new system.
A common misconception during testing is that anyone can assist in the validation process. Our recommendation is to involve resources who are familiar with all types of workflow. From reception to check out, we highly value the feedback of your front desk, intake staff, nurses and providers!
While, workflow is certainly one of the items that is highlighted throughout testing, there are other items that you must keep in mind when processing patient data.
Since no two systems are alike, some fields may need to be mapped, altered or augmented in some way. Throughout the conversion process, there are pieces of data in the extractions from the legacy system that need to be reformatted to fit the new target systems specifications. If these data files have already been modified over the course of the last few years, knowing what changed, why it was changed, what it was changed to, and when, is an important step during the mapping of data entering the target system. Our client’s involvement in providing this type of detail is important as we move the data, then attempt to test its validity.
Once we have tested the data to ensure accuracy and proper mapping, we then need to make sure it makes sense in a clinical setting. Will the newly altered data filter seamlessly into the future state workflows? This question is important as we navigate through the testing periods of the project. If the workflows cannot be supported, we must analyze the alterations we have done, and communicate amongst the client teams what the best solution will be. We cannot go back after the go-live and augment the data again, so testing becomes extremely valuable to everyone involved.
Best practice for testing and validation follows the same format for both the client and the consultant roles. Carefully reviewing patient demographic detail for matching purposes would be step one. Then we can move forward to testing the clinical data that has been entered on that patient. Validating the existence of a specific clinical entry (for example an Active Problem) would then be your next step.
Step three and four of the testing process could vary amongst the client if you are not utilizing a clinical resource in your validation stages. We request that these next steps test, and validate the fine details of the clinical element. Do the data elements that support that entry display correctly and make sense clinically? Did we map the dose unit (for example), correctly so that a new workflow will make sense in the new target system? Does the formatting and grammar within that entry also look correct? Only a client side resource familiar with that clinical data will know if this converted item makes sense. In this way, the client side testers are the most important piece of the testing stage, and we value that insight as we, your consultants, are doing all that we can to ensure a successful conversion go live.
As stated above, a successful conversion project involves education behind the decisions made to the augmented data, well documented past and future state workflows, and resources who are knowledgeable about the history of your legacy system and who are interested in how that will look in your new target environments. If you would like to learn more about our Migration process and the roles needed to ensure a successful project, please download our whitepaper, or visit our wiki.
For further information, make sure to catch our full data migration blog series or contact us below: