Three-phase approach to make a midstudy vendor transition less painful.
1. EDC Project Success [http://appliedclinicaltrialsonline.findpharma.com/appliedclinicaltrials/Project+Management/EDC-Project-Success/ArticleStandard/Article/detail/591995]
2. Putting a Face on EDC [http://appliedclinicaltrialsonline.findpharma.com/appliedclinicaltrials/Online+Extras/Putting-a-Face-on-EDC/ArticleStandard/Article/detail/588116?ref=25]
3. Switching Vendors Midstudy [http://appliedclinicaltrialsonline.findpharma.com/appliedclinicaltrials/CRO%2fSponsor/Switching-Vendors-Midstudy/ArticleStandard/Article/detail/579334]
Once considered a rarity, the "rescue" or transition study is becoming more commonplace in today's fast-paced world of clinical trials. For a variety of reasons, more and more sponsors are finding the need to switch vendors midstudy. Examples include vendor inability to meet sponsor requirements, issues with the data capture system, and vendor collapse or acquisition.
While the transition process is relatively straightforward for a paper-based trial, this is not the case for an Electronic Data Capture (EDC) trial. This is true even more so if the legacy and new EDC platforms are different. Detailed up-front planning and collaboration are required for a successful transition. The transition itself is often the most challenging aspect of the study.
The main goal of the transition is to minimize the impact of change upon the clinical sites by making the process as seamless as possible. It is critical to minimize the amount of downtime during the transition in order to maintain study momentum and site motivation. Another goal is to make sure that the new system contains all the relevant data and is adequately equipped with elements for success. Ideally there should be no interruption of protocol activities at the investigative sites during the transition.
To accomplish this goal, a three-phased approach to the transition should be used (see Figure 1). The first phase involves obtaining all documentation necessary to build the study in the new platform as well as initiating the build and testing processes. Required documentation should include, at a minimum, the functional specifications, database schema, electronic Case Report Form (eCRF) screen shots, eCRF completion guidelines, and edit check specifications (see Table 1).
The legacy system should be left active during this phase. Only at the point where the new system is ready to be populated should the legacy system have site access restricted.
The second phase of the transition is the most critical in terms of interruption of site activities. A firm deadline for data entry and clean-up activities should be established with the sites. The sites should be strongly encouraged to have their data as up to date as possible at the time that site access to the system is restricted. In particular, the sites should make every effort to resolve any open queries. Any open queries that are not resolved at the time of legacy system restriction will refire in the new system.
The third and final phase of the transition is the migration of the investigative sites and, if necessary, the study monitors to the new system. Adequate training must be ensured for all parties using the new system.
Prior to the initiation of any of these phases, an EDC Study Transition Plan should be prepared and distributed to all stakeholders for review and adoption. [A list of the key elements of an EDC Study Transition Plan can be found in Table 2.] Upon approval of the EDC Study Transition Plan, a meeting should be scheduled for all stakeholders to review the plan and agree on the tasks and responsibilities required for the transition to be successful.
A review of the essential documents should be performed prior to the meeting and any issues arising from the review should be discussed at the meeting. If the legacy vendor is still in existence and cooperative, they should be included as a part of the transition team. Any additional vendors (IVR, Lab, ePRO) should also be included in the team.
Due to their proprietary nature, no two EDC systems are identical in look and feel. Having said this, the design process should seek to replicate the look and feel of the legacy system as much as possible. The flow of the original eCRF, including the order of the data fields, should be followed. The forms, drop down lists, radio buttons, check boxes, and on-screen instructions should be kept consistent with the legacy system wherever possible.
The ideal approach is to perform the design interactively with representatives from the sponsor, the new vendor, and, if applicable, the study monitors. Every effort should be made to have the individuals with the most detailed knowledge of the study present during the interactive build. This is also a good opportunity to address any issues (entry screens, edit checks, etc.) within the legacy system that were found to be problematic.
Using the documents provided by the legacy vendor, the study should be built and then fully unit tested prior to being populated with the legacy data. Time should be included for the integration and testing of any external data feeds (IVR, Labs, safety) that need to be viewable from within the EDC tool. The data extraction process must also be tested as a part of this phase.
If integration is problematic, time-consuming or cost-prohibitive, an alternate approach is to freeze the prior systems database and merge the new and old databases at study close. This approach is the fastest way to reactivate the study—and indeed may be the only viable option in the event of vendor collapse. Unfortunately, viewing prior relevant data (Labs, etc.) will not be possible, and any automatic workflow triggers dependant on prior data will not operate, so it is a less than ideal solution.
Once the new database and eCRFs have been fully designed and tested, the system is ready to be populated with the legacy data. Depending on the volume of data entered into the legacy system, there are two approaches one can take. In either case, the legacy vendor must be able to supply the data within a reasonable time frame following site access restriction. The first approach is a relatively low tech one that simply involves manual entry of the data into the EDC platform. This would be the ideal approach for a study that does not have a large volume of data entered into the legacy system. The legacy vendor should be able to supply paper versions of the subject eCRF data. A quality control plan should be in place to assure that the data were entered correctly. If possible, a programmatic comparison of the two data sets is preferable to a manual one. Once entered, the data can be source document verified by clinical research associates.
The second approach would apply to studies in which a large volume of data exists in the legacy system, precluding a manual repopulation of the new EDC platform. In this case, a series of data integrations would need to be programmed and validated to populate the EDC platform. If at all possible, the integrations should seek to include any "flags" (Source Document Verification complete, Data Management Review complete, Safety Review complete) from the legacy system into the new one. This will alleviate the need to remonitor the legacy data, saving time and cost.
Regardless of the approach taken, an electronic transfer of the final legacy data, including the audit trail, must be made available to the sponsor and, if applicable, to the new EDC vendor.
At this stage, the study is ready to be deployed for site use. If necessary, this can be done on a site-by-site basis in order to allow high enrolling sites to get up and running in the new system as quickly as possible.
Adequate training of sponsor, site, and monitoring personnel must be performed and documented. A variety of approaches exist, including eLearning or online training and "Train the Trainer" programs in addition to the traditional classroom-style training session. Once all users have been trained, the system can be made available to the site for resumption of data entry and clean-up activities.
Regardless of whether one switches EDC vendors midstudy, there are several strategies a sponsor can use to reduce the amount of risk they expose themselves to should a vendor end up collapsing or prove to be uncooperative when faced with losing business. The first strategy is to obtain all essential study documentation (see Table 1) from the vendor when available and keep this information on file as opposed to receiving a comprehensive set at the time of study finalization. Most, if not all, of this documentation should be available prior to production system deployment.
A second strategy would be for the sponsor to require the EDC vendor to provide routine electronic data transfers on an ongoing basis. These transfers ideally should be on media (CD or DVD) and must also include the electronic audit trail. This should be considered a "data safety net" and will assure that at least some of the data is available. Depending on the capabilities of the vendor, these transfers should ideally be provided as an ASCII version of the normalized data (one row per patient per field).
With the paradigm shift from paper to EDC, switching EDC vendors midstudy can be a daunting task, but with proper planning, communication, and cooperation this can be accomplished successfully and in a timely manner.
Choosing a vendor with experience in EDC rescues, interactive study builds, and a solid data management background will make the transition for the sponsor, investigative sites, and any external vendors a smooth one and minimize program risk.
The author would like to thank Deborah Hoss, United BioSource Corporation, for her contributions on this article.
Eric Chappell is senior director, clinical data management, biotechnology solutions, for United BioSource Corporation, 17 Blacksmith Road, Newtown, PA 18940, email: [email protected]
1. T. Pratt, "Losing Your Vendor," Applied Clinical Trials, June 2008, 19-22.
2. L. Shaffer, "Switching Vendors Midstudy," Applied Clinical Trials, February 2009, 66.
Accelerating Clinical Trial Design and Operations
Fully-integrated, component-based CDMS offers flexibility, customization, and efficiency.