Examining Rescue Studies
Examine the Work and Risks Involved in a Rescue Study as well as the Actions that can Help Avoid or Mitigate these Risks during Deployment.
Introduction
The purpose of this whitepaper is to define a Rescue Study, outline the basic assumptions, including risks, in setting up such a trial based on Fountayn’s prior experiences, and present the actions that can help avoid or mitigate these risks during a deployment
What is a Rescue Study?
A Rescue Study is a clinical trial, previously conducted in paper, EDC, or both, that was run by one or more vendors over time, but is now contracted to continue with a different vendor. The new vendor will take over certain project duties and “rescue” the project. The study may have been in a Production Environment for several months or even years. Data may have been entered into a client database through double data entry, entered manually in another EDC system, or other data may have been imported into the EDC or database system, etc.
Why do Studies need Rescuing?
Conducting even one Clinical Trial is a monumental task. Many issues can arise during the course of a clinical trial and negatively affect a study timeline, which in turn delays reporting to the FDA, and can ultimately delay a chance at profitability. It may be that tasks assigned to study personnel (such as coordinators, monitors, medical coders, etc.) are not being performed at the level expected of them. This can result in poor quality data or data that is missing altogether. Sometimes a vendor will have an unexpected problem with personnel turnover or an increased amount of work generated from another study, and the vendor will not be able to provide an adequate amount of qualified resources to the project. In instances of vendor consolidation, many software programs become legacy systems and resources to support these systems are at minimal or nonexistent levels. Sponsors might also encounter problems with data analysis and FDA reporting. In short, a study most often needs rescuing when it is in danger of not being completed within an appropriate time-line, its quality is suspect or it has lost access to resources. One other possibility is that unexpected results have caused a regulatory agency to halt the trial. The purpose of this whitepaper is to define a Rescue Study, outline the basic assumptions, including risks, in setting up such a trial based on Fountayn’s prior experiences, and present.
Rescue Concerns
Although rescue studies are usually intended to speed up study timelines, sometime must be spent on the rescue process itself. Therefore, rescue study vendors are carefully chosen and must demonstrate the ability and experience necessary to perform an efficient rescue, enabling the study sites to perform data entry and cleaning tasks with minimal interruption.
These are a list of requirements to help ensure a seamless migration or rescue:
New clinical database developed quickly – more quickly than in a normal contract
New eCRFs designed to provide the easiest transition for existing study personnel
Import of existing study data performed quickly and accurately
Query handling and other data cleaning tasks made more efficient - shortening study timeline
Problem areas specific to the study must be assessed and then improved
Key Elements for Consideration
There are several key items that must be addressed before beginning development on a Rescue Study. First, the scope of the project must be identified, and the client’s expectations set accordingly. Project timelines, costs and deliverables must be defined or estimated. Key stakeholders in the process must be identified, as well as any client personnel who will be primary contacts. Any risks that may affect the success of the project must be identified and planned for as well as measurements for quality. (See Figure 1 below)
In order to complete these items, questions must be asked about project specifications.
File Import of Existing Data
How will the existing data be entered into the eCRF?
Will there be a file to import? Paper?
What are the specifications of the import file?
Is there one file to import or several?
If several, are all the files of the same type? (Text, ASCII, SAS)
Is the format type(s) supported?
Are all of the fields in the file consistent?
In order to map the file to the eCRF, each of the fields mapped needs to be in the same location within the file.
The fields of the file need to be consistent in terms of format. For example, if you have a field that captures weight with the unit of measure as pounds but it periodically changes to kilograms, you will have inconsistencies when you export the data. The same problem may occur if the field is formatted to be an integer in one file but set as a date only in another file.
Who will be responsible for reviewing and validating the file prior to design?
How will file discrepancies be resolved? Who will be responsible for approving?
In some cases, the file will need to be imported to create the existing patients and completed visits before the new data entry can begin. If the time-lines set by the client are too short or do not take the import file review into account, the project may be at risk of failure. This is a key expectation that needs to be set early in the project planning phase.
Double Data Entry of Existing Paper Data
Will paper CRF’s need to be entered through double data entry?
If yes, who will enter the data, the client or the vendor?
Does the client have an established DDE guideline or SOP that should be followed?
If Fountayn or one of it’s connect partners is asked to perform the data entry, the clinical trial processes and SOPs should be reviewed first. This step is always completed early in the planning phase to ensure client expectations are being met and any gaps that need to be addressed are identified before the eCRF design starts.
What are the time-lines for entering the data? Can this be done concurrently with the live data entry or does it need to be completed prior?
Once a plan for migrating the existing data into the system is established, the next step is to understand the design requirements. This part of the process is similar to any other EDC study. The same planning, design, testing, and approval process applies; however, there are historical issues that can have a large impact on the design.
Figure 1
eCRF Design
Does the client have an existing paper CRF?
If so, has this been used throughout the trial or has it changed over time (mid‐study changes or amendments)? If the CRF has changed, it can greatly affect the import and export of the data. For example, the client may want to eliminate certain questions or forms. What happens to the existing data that needs to be imported but the question or form no longer exists?
What happens if the question text on a form is changed? This may completely change the meaning of an answer previously recorded.
If the metadata in the file varies within a question, you may consider only importing the answer and having a second drop-down or other type field to associate it with.
As in the example above, you could import the numeric value in one field and have another field to select either pounds or kilograms. However, this will have an impact on the auditable fields, which may have an impact on the overall budget. The client may want to import all of the data but hide certain questions from the eCRF. This data would then appear on the export but not be collected going forward.
Finally, we need to consider our points of contact and the associated expectations and risks. Because this is a rescue study, we are going to be taking the project over from one or more previous vendors. Often, the reason we are getting the trial is that the previous vendor either failed or was unable to manage the project. This will provide quite a challenge to both Fountayn and the client, as the key personnel with knowledge of the trial are often unavailable or unwilling to help with the project. These are some of the key points to consider regarding expectation and risk.
Stakeholders, Expectations & Risk
Who with knowledge of the project is available for contact? This may include lab companies, the client data management or clinical team, executives or previous vendors.
Who will have the power to make the final decisions? Who is driving the timelines? Who can help coach or assist in obtaining information?
Is there adequate time to review the import file prior to eCRF design?
What flexibility in time and cost is allowed if the file does not meet the import mapping requirements?
What experience levels do these users have in EDC and in rescue studies in particular?
Are the timelines and budgets in line with the estimated level of work? Will the client approve certain deliverables, such as the export mapping, to be done after deployment?
How can Fountayn Help?
The Fountayn eClinical platform has several key underlying features that make it ideal for taking on a rescue study.
Single Database
Patient CRFs, adverse events, lab data and other types of data can all be stored in the same database. This allows for fast, accurate reporting with no overhead cost of reloading data into a separate database. All trial revisions are tracked and retrievable online. Different revisions can be loaded to environments specifically for designing, testing and approving clinical studies
One Interface
Fountayn provides users with a consistent and intuitive interface across all modules from one user name and password. This allows for seamless data integration and usability among data entry, coding, randomization, inventory and reporting tools. It is not necessary to switch between applications or spend countless hours providing backend data packaging.
Import & Manage External Data
Foutayn eClinical features a highly flexible data import system as part of our integration capabilities. While normally used for items such as ECG and lab data, entire patient records can be imported with the push of a button. We support a large number of import formats (sas, excel, csv, text, xml, dat, and more) as well as industry standard formats such as HL7 ECG, ICH, CDISC, CDASH and SDTM.
Advanced Data Monitoring Tools
Because no two monitors approach data cleaning quite the same way, the Alert and Query Managers allow users to easily identify and manage unresolved edit checks and queries. Standard trial management reports allow users to quickly review the overall study progress, site metrics, visit schedules and more. Edit checks can be programmed into the eClinical application to alert coordinators and monitors to and potential problems as soon as the patients are imported into the system. Powerful scripting tools allow for complex edit checks to trigger on‐screen alerts or even send emails directly to study personnel.
Highly Flexible & Powerful System
Fountayn eClinical has a wide array of features designed to make conducting clinical trials easier. The following are just some of the many features available:
The Form Manager identifies CRFs that need to be reviewed, source document verified or signed.
Custom filters and labels group patients for efficiently managing data subsets and intermediate database locks.
Real time data access provides up‐to‐the‐minute data review or exports.
Ad hoc reporting engine allows users to create data listings via an intuitive interface, including statistics, filters and multiple formats.
Dynamically‐generated manager screens allow users to manage study progress.
Users randomize patients and make drug assignments in a system that supports kits, open volume drug, drug lookup tables, permuted block randomization, or dynamic randomization algorithms and more.
Emails are sent to notify the team when randomization, un‐blinding or other key events occur.
Drug Inventory provides control, management, and automation of drug supply fulfillment through a single
The advanced auto‐coding and smart synonym technology increases coding efficiency.
In addition, Fountayn’s clinical and consulting services as well as those from our partners can provide relevant and needed resources surrounding the eClinical platform and trial processes.
Summary
The success of a rescue study depends on the quality of the data file being imported, developing realistic time-lines to account for the pre‐design review work, setting client expectations, and above all communication.
Inevitably, the biggest threat to the project’s critical path will be the data import. If the fields being mapped are not consistent, if the data values or format of the fields change within the file, or if the question/form structure of the eCRF changes over time, the work effort to prepare the file for import will rise exponentially along with the costs. But, if the effort is made upfront to educate the stakeholders of the risks and to communicate the progress of the deliverables, the success of these projects can be greatly increased.
Success in a rescue study also brings the added benefit of strong customer loyalty. Usually, these studies are a result of a project or vendor failure resulting in a negative customer experience. A successful deployment in a rescue situation can lead to a solid partnership going forward.
*Fountayn Formerly known as Datatrak