Replacing the CRO in an ongoing study – how to do it?

We have previously written about our successful experience with different data migration scenarios in MainEDC. 

We venture to address a rather painful topic – replacing the CRO in an ongoing study by the decision of the sponsor. Yes, sometimes in the business of clinical trials a surgical approach is taken and a professional operation is required.

Let’s not look at the reasons, there may be many, let’s focus on the solution.

Technically, the migration is done in the same way as we detailed in case study 2.

But in this case there is also an ethical dimension. For an organ transplant (and the clinical data of an eCRF is a very sensitive organ) the consent of both the donor and the acceptor is required. Informed consent, of course.

If the sponsor manages to link the first CRO (data donor), the second CRO (data acceptor) and the system provider into one process in a harmonious way, then everything will go according to plan.

The data owner, of course, is the research sponsor, not the CRO. We have chosen a vivid but not quite accurate metaphor, we hope the reader understands and forgives us =)

And the operation plan might look like this:

1. A single interaction agreement between all parties involved is drawn up.
   1. a description of each party’s actions in accordance with existing, expiring and entering contractual obligations,
   2. a communication plan for the parties involved,
   3. outlining the related deadlines for each action – such as locking down the original database and revoking user access, technical migration of the data, testing the result by the host party, training the users and granting access to the new project environment, etc,
   4. ensuring the study blind continuous maintenance, if applicable,
   5. ensuring protection of confidential information,
   6. agreeing on suspension of data entry (not mandatory, as data entry and processing can continue on the side of the “donor” and the final migration of the project can take literally one working day).
2. A technical plan for data migration is agreed upon.
   1. installation and decommissioning of the environments,
   2. description of the sending and receiving systems,
   3. locking and unlocking the databases,
   4. definition of the volume of information to be migrated, 
   5. test migration and validation of the results,
   6. control over access to the environments with delimitation of user rights,
   7. migration of data and metadata itself,
   8. destruction of the original database after the transfer,
   9. other necessary actions depending on the characteristics of the project.
3. Reporting is done, documentation is closed.

We are grateful to our clients that the successful cases have been carefully co-designed, no problems occurred during the operations and the results allow us (while maintaining confidentiality) to write such articles and propose solutions to companies who might never have risked such a maneuver had they not known that what is described here is really feasible.

Read more: Data migration in clinical trials and A little more about successful CT data migration