A Guide to Protecting Data Integrity When Transitioning Rescue Studies

Nancy Bates

Every clinical trial is a monumental undertaking, with a myriad of variables that can put the study at risk. Missed deadlines, missteps in data quality, regulatory or performance issues, study re-designs, and even acquisition at the sponsor level may spur the need for a rescue CRO to step into a study that is already underway. This decision to switch CROs requires careful consideration and meticulous planning for effective preservation of data integrity and efficient transfer of data management responsibilities.

Clear communication between the sponsor and the lead data manager of the incoming CRO is essential for a successful study transition. Establishing preferences and expectations for the frequency, format, and content of communications at the outset helps solidify the new relationship and keep the transition on track.

Developing a transition plan and timeline

The transitioning of data management activities requires thorough planning and preparation. As soon as a scope of work and budget have been defined, the incoming CRO should request 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. The incoming CRO should then create a draft transition plan and timeline, which will help to identify areas for discussion during a formal kickoff meeting with the sponsor.

During the kickoff meeting, it may be useful for the sponsor to provide insight into why the study is being rescued and any concerns they had with the outgoing CRO. Another key discussion topic is how the sponsor wishes to handle the existing study database. Knowing the answers to the following questions helps clarify what is expected of the data management function and provides the details necessary for finalizing the transition plan and timeline:

• What type of database is it and who has administrative rights to it?
• Will transferring the database URL be straightforward?
• Does the sponsor prefer to transfer the data to an entirely new database?
• Are there randomization, drug dispensation, or other database modules that need to be transitioned?
• What is the target database transition date?
• Is there an upcoming interim analysis or safety review meeting that requires a data cut?

The kickoff meeting is also an optimal time to establish a data entry cutoff date for the sites and for monitoring visits.

Following the kickoff meeting, the incoming CRO should have all the information needed to finalize the transition plan and timeline and to create the transition checklist for the data management and database programming teams. This transition checklist should reflect all tasks identified in the scope of work and transition plan. If and as new tasks are identified, the transition plan, timeline, and transition checklist should all be updated and distributed to the data management and database programming teams.

Selecting an approach to database transfer

There are several options for transferring the database, including:

Directly transferring the database URL to the incoming CRO, where the incoming CRO assumes responsibility for all management and administrative duties for all related modules, maintenance, revisions or updates, and database locking. Administrative access is necessary for allowing future database updates and requires coordination with the outgoing CRO and the database vendor. This is the most common and preferred approach.

It is important to note that while the URL, environments, modules, and administrative access are transferred to the incoming CRO, the original database configuration settings are owned by the outgoing CRO or database vendor and cannot be changed as any changes would affect all the studies that are on the same URL. Since database configuration settings affect multiple functions, such as roles, permissions, lab administration, and clinical views, 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, where 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, where data from the existing database is either re-entered manually by the sites (or a designated group) or programmatically remapped and uploaded by the incoming CRO into a new database. Manual re-entry may be preferred, as remapping and uploading is more resource-intensive, costly, and time-consuming.

With this option, the incoming CRO works with the sponsor to select a good data cut off point, decide what data will need to be re-entered, and determine whether elements of the existing database should be re-used to preserve the original data entry experience. Data issues in the existing database may surface during the process of building a new database, so it is also important to establish and document a process for handling data discrepancies.

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 involvement to ensure that all documentation from the existing database is provided in the trial master file (TMF).

The most appropriate method of database transfer for a rescue study will depend on the type of data, the entity that holds administrative rights for updates, and the URL upon which the electronic data capture (EDC) system resides.

Performing a gap analysis and quality review

After settling on a database transfer option, the next step is to identify any issues related to the database and to document those issues in a findings log. The lead data manager begins the gap analysis by cross-checking the CRFs against the protocol to ensure all assessment data are collected. Then, the lead data manager reviews the edit check specifications to confirm they are sufficient for catching site data entry issues and compares the back-end configuration settings of the outgoing and incoming CROs.

The sponsor, lead data manager, and Database Programmer should meet to discuss any findings, questions, concerns, or recommended changes. If any changes are suggested, it is important for all stakeholders to discuss their feasibility and understand any downstream effects.

Other important tasks to complete the gap analysis and quality review include:

• Determine if any protected health information (PHI) has been collected and if CRF changes will be required to remove it to protect patient privacy
• Identifying any blinded forms that are restricted to certain roles and testing 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 updating them if needed.
• Checking correct mapping of all roles and trainings
• Reviewing and testing email notifications
• Entering a clean test patient to identify queries that misfire or determine whether new edit check specifications are needed

Updating and validating the database

If database modifications are required, the sponsor approves the updates and the database programming team programs the changes. Once the modifications are complete, internal—and sometimes sponsor—user acceptance testing (UAT) is performed to ensure the database works as expected. Before re-opening the database, the incoming CRO works with the sponsor to perform a thorough review of the user access listing. Upon approval by the sponsor, the new database is ready to go live.

Going live

Once the database transition is complete, the lead data manager and data management and database programming teams move into the next phase of database maintenance and data cleaning and management, including programming of the listings, metrics, reconciliations, and ad-hoc reports using data from the transitioned database. As new documents—such as the transition plan, data management plan, CRFs, aCRFs, edit check specifications, and data transfer specifications—are created, fully executed copies of these documents are filed in the project TMF.

When transitioning a study, protecting and validating data integrity from database transfer to database re-opening is a top priority. Consistent communication, detailed planning, and rigorous documentation are the foundation of a seamless handoff and successful rescue.

Nancy Bates, associate director of data management, Precision for Medicine