Best Practices for Database Transfer in a Rescue Study

Easing the transition, protecting your outcomes

On occasion, a Sponsor may need to employ a rescue CRO for some or all of an ongoing study. Whether it is due to slow enrollment or a more systemic problem, the decision to change CROs is never made lightly, and a critical component of any successful transition is effective, efficient transfer of the study database.  

In this article, we cover the key elements of a successful database transition.

Communication is key

Vital to the success of any study transition is clear communication between the Sponsor and the Lead Data Manager of the incoming CRO. Establishing preferences and expectations for communication—frequency, format, and content—helps solidify the engagement and keep the transition on track. 

Planning and preparing: Database transition

Developing a transition plan, timeline, and transition checklist is crucial for ensuring that the database transition is as seamless as possible. Typically, the incoming CRO develops a draft transition plan and timeline after the scope of work and budget have been defined. The CRO also requests and reviews key documents, including all versions of the protocol and copies of the data management plan, data review plan, case report forms (CRFs), annotated CRFs (aCRFs), configuration settings, edit check specifications, CRF completion guidelines, coding licensure information, local laboratory reference ranges, if applicable, and external vendor contact information.  

This is followed by a kickoff meeting with the Sponsor, where there is a deeper discussion of how the Sponsor wishes to handle the existing study database and whether there are any upcoming interim analyses or safety review meetings that require a data cut. The kickoff meeting is also an optimal time to establish a data entry cutoff data for the sites and for monitoring visits. Following the kickoff meeting, the incoming CRO should have all the information necessary to finalize the transition plan and timeline and to create the transition checklist that will guide the Data Management and Database Programming teams through all the steps required for the transition. 

Determining how to transfer the database

A key variable impacting the timeline is what the Sponsor wants to do with the database. There are several options for the data and database, depending on the type of data, who retains administrative rights for updates, and the URL upon which the electronic data capture (EDC) system resides. These database options include: 

Directly transferring the database URL to the incoming CRO

In this scenario, the incoming CRO assumes responsibility for all management and administrative duties for all related modules, maintenance, revisions or updates, and database locking.

Direct transfer of the database URL or the study database and all environments and modules, along with administrative access, is the most common and preferred option among the Sponsors we have worked with at Precision for Medicine. Administrative access is necessary for allowing future database updates and requires coordination with the outgoing CRO and the database vendor.

Importantly, while the URL, environments, modules, and administrative access are transferred to the incoming CRO, the original database configuration settings cannot be changed as they are owned by the outgoing CRO or database vendor and any change would affect all the outgoing CRO’s studies that were on the same URL. Configuration settings affect multiple functions, such as roles, permissions, lab administration, and clinical views. Consequently, the Sponsor and the Data Management and Database Programming teams need to be aware of any differences in configuration settings so they can be addressed during the database transfer.

Leaving the database with the vendor that built it

That vendor retains administrative rights and assumes responsibility for making database changes and performing database final lock activities. The incoming CRO’s data management activities are limited to data cleaning and query management. 

Building a new database

The incoming CRO builds a new database and data from the existing database is either re-entered manually by the sites (or another designated group) or programmatically remapped and uploaded by the incoming CRO. Manual re-entry may be preferred, as remapping and uploading requires extensive preparation and quality control (QC) and is invariably more costly and time-consuming.

If the Sponsor prefers to build a new database, the incoming CRO works with the Sponsor to determine a good data cut off point and to decide what data will need to be re-entered and whether to re-use the edit checks and case report forms (CRF) from the existing database to maintain the same look and feel of data entry. During the process of building a new database, data issues may be discovered in the existing database. Therefore, it is important to determine how data discrepancies will be handled and to add this process to the data management plan.  

If an analysis is going to be performed, the Sponsor will need to work with a biostatistics vendor to combine the datasets from both databases. Further, the Sponsor will need to determine whether the outgoing CRO will be responsible for all archival activities related to their study participation to ensure that all documentation from the existing database is provided in the Trial Master File (TMF). Whichever database transfer option the Sponsor selects, the timeline and steps required for the transfer should be defined in the transition plan.

Performing a gap analysis and quality review

Once a database transfer option has been chosen, the next step is to identify any issues related to the database using the documents provided by the Sponsor or outgoing CRO. Any issues discovered are documented in a findings log.  

The Lead Data Manager begins the gap analysis by cross-checking the CRFs to the protocol to ensure all assessment data are collected. This is followed by review of the edit check specifications to ensure that they are sufficient for catching site data entry issues. 

Then, the back-end configuration settings of the outgoing and incoming CRO are compared. The Sponsor, Lead Data Manager, and Database Programmer should meet to discuss any findings, questions, concerns, or suggestions for changes. If any changes are to be implemented, it is important for all stakeholders to understand any downstream effects resulting from these changes. It is important to remember for some EDC systems, the configuration settings and setup at the outgoing CRO may be at a high level and changes to these settings may not be possible as they may affect all EDC databases across different Sponsors. 

Other important items to complete during this phase of database transition include the following

• Determining whether any protected health information (PHI) has been collected. If so, CRF changes will be required to remove PHI to protect patient privacy. 
• Identifying any blinded forms that are restricted to certain roles. If such forms exist, test that only those roles can view the data.
• Confirming that all modules linked to the database, such as randomization or drug dispensation, are working as expected 
• Confirming the coding dictionaries are the expected version and finding out whether they need to be updated 
• Checking that all roles and trainings map correctly 
• Reviewing email notifications, removing or adding individuals, and testing those notifications 
• Entering a clean test patient to identify queries that misfire or determine whether new edit check specifications should be added 

Modifying and Validating the Database

Discoveries made during the gap analysis and quality review often lead to potential database modifications. Once these updates are approved by the Sponsor and programmed by the Database Programming team, it is necessary to perform internal user acceptance testing (UAT) to ensure the database works as expected. This may be followed by Sponsor UAT. 

Prior to re-opening the database, the incoming CRO performs a thorough review of the user access listing in collaboration with the Sponsor. When the Sponsor gives their approval, the new database is ready to go live. 

Key Takeaway

Effective, efficient migration of study data from one database to another requires clear communication and close collaboration between the Sponsor and the incoming CRO. Meticulous planning and detailed execution minimize the risks of database transfer and set up the rescue study for success.

Request a rescue >