No clinical trial sponsor intentionally plans a study migration. Sometimes the decision to migrate data from one database (or data collection platform) to another just can’t be avoided. Once considered a rarity, more and more sponsors are finding the need to switch vendors in the midst of a study. There are a host of reasons for such “rescue” or transition studies, but the decision to initiate one generally stems from issues with the data capture system or a vendor’s inability to meet – or continue meeting – a sponsor’s requirements for a specific clinical trial.
However, making the decision to move forward with a data migration isn’t one sponsors take lightly. The decision typically follows numerous manual workarounds and other internal efforts, which usually incur significant effort, time and costs.
As such, when a sponsor decides to move forward with a data migration, it’s critical to develop a strategy and execution plan that ensures the process is as seamless as possible. Study momentum and clinical trial site team motivation must not be compromised, and a well-thought data migration plan is essential to minimizing downtime and disruptions to protocol-related activities at investigative sites during the transition.
Although it may feel daunting, a study migration can be successfully managed with a solid, well thought-out data migration plan. That said, there’s no template or one-size-fits-all plan for a “rescue study.” And that’s because each migration is different. The experience is shaped by the type data you are trying to migrate, the location of the data and where it is being migrated to, and how quickly it must be migrated.
To overcome these challenges and successfully implement a study migration, focus on:
1 Improving the study database design:
When planning to migrate data, sponsors can also take the opportunity to make changes to the study database design. It’s important to think about the improvements you want to make at this point. For example, instituting a different way to capture fields that can actually be calculated/derived by the database (eg: BMI, or a score or sorts) would reduce the burden on clinical trial sites by removing additional entry/calaculations done manually.
Remember: If you are going to add new data points, you must also think about what you would like to do with legacy patients. Only some data can be collected retrospectively (date stamped, of course!), so a discussion with the biostatistician is an essential step to determining how to manage legacy patient data in a migration study.
2 Assessing why and where you’re migrating the study:
It is also vital to clearly understand the reason you are moving your data. I have met customers who simply say: “because the regulator told us to do so.” Following instructions is obviously crucial, but knowing exactly what you want to achieve when changing your database/platform will help you identify a database or platform that better suits your needs. Make sure you have experts to guide you on how to implement the new database/platform, as well as the data migration process. If you don’t have the expertise in house, outsourcing it will be key to your success.
Remember: A critical early step is assessing the data migration capabilities of the technology system you’ve selected, particularly how data can be imported into it and whether re-entering data will be necessary.
3 Ensuring consistency within your new database or platform:
Once your new database or platform is in place, focus on keeping those fields that do not need updating as consistent as possible. For example, if the format the study uses for visit dates is in dd/mm/yyyy, don’t change it to mm/dd/yyyy, unless you have a valid reason for doing so. Inconsistencies increase the complexity of a data migration, so it is best to proactively avoid them, as much as possible.
Remember: Through all of this, keep clinical trial sites top of mind. Try not to change too much of the CRF structure in terms of the order in which fields are collected. Sites are accustomed to completing forms a certain way and changing the order – for no specific or valid reason – could result in avoidable data entry issues and frustration.
Additionally, take the time to rethink queries and consider whether to add or retire a few.
4 Mapping old fields to new ones:
When comparing the new database structure to the legacy database, a key focus should be determining how to map the old fields to new ones. Identifying if there have been changes to, for example, the field’s name, structure or location on forms is important because those will require careful mapping. And this mapping exercise provides a clear indication of the complexity involved in migrating certain fields, which is essential for effective planning purposes.
Be careful not to get caught up in the automation hype by assuming that using any form of technology will be the way to go. Some “automated” plans can be a lot more labor-intensive and time consuming to implement than anticipated. When bringing in a technology partner, estimate how long it would take you and how much it would cost you to manually enter all of the data. If a technology/ automation solution can migrate the data quicker, and at the same or a lower cost, it is likely an investment worth exploring further.
Remember: If you migrate the data from one platform to another, you should still anticipate some challenges on the backend of the database. Be sure to clarify this with your technology partner so that you understand exactly what to account for in your study migration plan.
5 Outlining a quality control process:
Understanding how you will get each of your data points migrated is key to developing your data migration plan. Identify what data will be moved electronically and what data may need to be entered manually. In your data migration plan, you should clearly explain how each of these processes will be executed and the associated risks. Putting in place a quality control process will help you confirm the data entered, whether manually or electronically, is exactly the same as it was before the migration. This can be done through manual quality control checking or, most efficiently in most cases using a SAS platform, by a “proc compare” or comparing procedures between databases.
Remember: If you have added any queries, now is the time to define how they should be addressed by sites. You may have a large batch of queries that are released at once, and the clinical team will need to manage expectations with the sites. Additionally, it is just as important to discuss how queries that re-fire should be handled. Even though they have previously been answered and closed in the old database, these queries will now, by virtue of data entry, fire again. For that reason, this is also the time to define who will be responsible for closing out those queries, whether the staff at sites or someone else. Replicating the status of the queries in the new database won’t compromise the integrity of the study, as long as quality control measures are in place to ensure the data in the new database matches what was in the previous one.
The same should be defined and thought through for the status of forms, such as those that are “SDV-ed” and locked. Do you want these to be moved over or replicated in the new database? If so, who will execute the replication and who will ensure quality control?
Ideally, you want your sites and clinical team to be able to log into the new database and simply pick up where they left off, without having to redo any work. However, this may not always be possible and some training may be required to ensure site and clinical teams are up to speed on the changes that have been made to the database structure. Furthermore, if you used a new platform to migrate the data, then you will need to ensure that the entire team has completed the applicable trainings before providing access to the database. Note that all trainings should also be clearly documented in your data migration plan.
6 Managing unforeseeable issues:
Executing the data migration should be pretty straightforward if you have created a thorough and well-thought-out plan. Still, you will undoubtably encounter a surprise or two along the way, during the electronic migration. This is where the risk analysis from the data migration plan is important. Don’t forget to review what’s outlined in your contingency plan. If an unforeseeable issue comes up, be adaptive and don’t fear a short delay. Taking a few hours to think something through, or to regroup to identify a workable solution, will be far more valuable than rushing through just to win a few hours on delivery.
Considering these six best practices when you develop a data migration plan will help set up your “rescue” study for success. And you can more easily get there by taking the time to bring in the right experts to ensure you only have to do the migration once.
If you are considering a data migration, Bioforum’s experienced team can strategically guide you through the entire process. To learn more about our capabilities and subject-matter experts, contact Tanya du Plessis ([email protected]).