OR WAIT null SECS
Ways to ensure the transition between vendors is as smooth as possible for everyone involved.
The growth of the global pharmaceutical market, estimated by PricewaterhouseCoopers to reach $1.3 trillion by 2020, is by necessity propelling the progress of enabling technologies. Whether due to deep development pipelines or industry wide initiatives effecting clinical trials such as the Critical Path, it's becoming increasingly imperative for research organizations to manage extremely large volumes of data in real time. In fact, the PricewaterhouseCoopers analysts predict that the pharma industry will not be in a position to capitalize on opportunities unless R&D productivity improves. Yet despite technological progress, it's been well documented that at least three out of four clinical trials today experience costly delays.
There aren't the same statistics available for measuring a hot topic in the world of ongoing clinical trials: the rescue study. It's a term applied to the transfer of study responsibilities from an existing vendor (EDC or otherwise) to a new vendor midway through a clinical trial.
While it is always the goal to choose a compatible vendor from the start, sometimes problems occur that necessitate a change in vendor before study completion. This is usually a costly and timely proposition, but there are valid reasons why a sponsor may need to prematurely sever the relationship, such as: unresponsiveness to the sponsor or the needs of its study sites; lack of support desk assistance; the platform is not as robust or user friendly as originally thought; the system is unstable, with significant downtime or data crashes.
Should the sponsor and research team decide that a vendor change is warranted, there are ways to mitigate problems that might occur when inserting a new technology into an existing study.
Any EDC or Web-based services vendor will require two things to determine the best methodology for switching data from a current vendor to a new one: the existing database specifications and screen shots. These should be offered during the discussion process; it will help determine whether the vendor is a good fit.
The specifications will give the new vendor a roadmap for determining how to best convert existing data into a format compatible with the new vendor's software. The screen shots of the existing EDC system will illustrate to the new vendor how the sponsor and sites currently view the data and will help them create forms and datasets that closely match the existing ones in look and feel.
Next, set a hard stop date for entering data into an old database and for blocking access to it. Give sites the target date and work with them to get all data current and in the system by this time. If a site is behind in data entry, maybe have its staff just enter the data into the new database once it is up and running. This can be determined on a case-by-case basis.
Once the old database has been turned off, the old vendor should forward the final SAS extract to the new vendor so that data may be loaded into the new system. In the interim, instruct sites to hold off entering any data. Once the process of loading data into the new system is complete, the system will be opened up to the sites and access will be given to study personnel and the sponsor. The goal is to make the transition between vendors as seamless as possible for site personnel and the project team.