Replacing Study Subjects

Case Studies

Problem:

Figures presented at a recent North Carolina pharmaceutical conference show that 50% of the clinical sites selected to conduct a clinical trial will enroll zero or only one subject. Even with the advent of social media initiatives and other creative new ways to boost recruitment, enrolling an adequate number of subjects in a timely fashion remains a critical issue for the drug development industry. Eligible subjects, in a word, are precious.

Precious, too, are randomization schedules and statistical design. A second wave dilemma comes after an eligible subject is finally enrolled, assigned to the next slot in the randomization schedule, and then turns out to be, for one reason or another, a case of early withdrawal. Not only does this impact the goal of a treatment group’s minimum number of subjects, but –importantly – it impacts the balances and ratios built into the study randomization schedule at study startup.

Getting Data Sooner with IRT Part 2

Case Studies

The Challenge:

In a recent post (see hot topic “Getting Data Sooner”) we talked about how using a ‘give some, get some’ strategy in an IRT system contributes to getting your clinical trial data faster. Users are motivated to enter data in a timely fashion because use of the IRT is required for the site to get critical information required for study conduct and subject treatment — for example, their next kit number, or a dosing calculation. Visit data must be entered before the visit can be accomplished…as distinguished from an EDC system where data entry by the site can lag considerably behind.

But what about data that you want to capture in the IRT which doesn’t fit the ‘give some, get some’ strategy? For example, screen failure, early withdrawals, or receipt of drug shipments. For these kinds of data there is nothing the user requires from the system that would force them to do timely entry.

The Solution:

For instances like these, Veracity Logic’s VLIRT® system provides motivation by appealing to basic principles of human psychology… and by manipulating visit/response windows.

For example: When a subject fails screening, the subject obviously does not show up for their next visit. VLIRT® tracks visit status on the main Subjects page (the landing page for most studies) and turns the name and date of the next scheduled activity bright red once the timeframe for that activity has lapsed. Site personnel, our years of experience attest, don’t like to see red — they know their CRA will also “see red” and will be soon demanding to know what’s happening with the subject in question! Users are thus motivated to eliminate this warning color from their table views by entering the necessary screen fail activity.

The same applies to receiving shipments. Acknowledging receipt is a key factor in keeping site drug inventories accurate and up to date within the IRT. The system can assist by turning red the Sent Date of any shipment that was sent more than X days previously and has not yet been modified to a status of Received.

When selecting an IRT, Program Managers should give careful thought to the application of creative designs that can help solve some of these common problems of clinical trials.

Getting Data Sooner With IRT

Case Studies

The Challenge:

A classic problem in the conduct of a clinical trial is how to motivate site personnel to enter their clinical data in a timely fashion. What can be done to enable project personnel to receive study data sooner?

Push vs. Pull — Tips on IRT Data Integrations

Case Studies

The Challenge:

Your EDC system will house the bulk of your clinical data for the upcoming clinical trial but you’re using an IRT for screening, randomization, and drug assignment. What’s the most efficient, cost-effective way to accomplish two key study goals: to integrate certain data as needed (in a timely fashion), and to avoid time-wasting duplication and reconciliation requirements between systems?

Using Enrollment Thresholds

Case Studies

Problem: A classic struggle in the world of clinical trials is how to ensure there is ‘just enough’ drug at each study site throughout the trial – that is, how to achieve minimal wasting of precious investigational product, but minimize, at the same time, the risk that a site will run out of stock and miss enrollment opportunities that cause study delays as a result. How can your IRT (IWRS/IVRS) system help?

Solution: Veracity Logic’s VLIRT® system allows clients to assign individual enrollment thresholds for each site in the study. A site can be defined as a Low, Medium, or High enroller based on best industry information at the onset of the trial. Each enrollment level feeds into the study’s resupply and inventory management algorithms to determine the optimal amounts of drug to be provided to the site – at initial shipment, for baseline maintenance, and in terms of resupply alert levels for study drug. Recognizing that the one firm rule of clinical trials is that change will occur, enrollment thresholds in the VLIRT® system are easily configurable throughout the study – threshold designation can be changed by Project Managers as events dictate at any point in the trial without requiring custom coding or vendor involvement.

The application of enrollment thresholds is particularly useful when the design of the study doesn’t permit the use of predictive resupply functionality. Predictive resupply is not always a good option for low numbers of users and dosing visits, nor for studies where visits are too close together to handle a just-in-time approach to shipping. In such cases, enrollment thresholds can help project managers put study drug where it will do the most good throughout the trial.

Managing Users in the IRT

Case Studies

Managing Users is one of the key functions of an IRT system in a clinical trial. Typically, IRTs provide the important subject randomization and drug supply management activities for the study. Assigning access to the array of permissions that determine what each user can see and not see in each arena must be foolproof, easy to set up, speedy to change and maintain, and friendly when it comes to adding and subtracting Users throughout the life of the study.

When the Project Specification and the Project System don’t match…

Case Studies

Sometimes it’s a simple thing that gives quality management theory a challenge. For example:

Conventional practice for testing a clinical trial project system asserts the following: When tracing from a test result to the official Project Specification (PS), any discrepancy between the PS and the system requires failing the test step and then re-testing it again in a new test cycle after a correction interval. If we translate this assertion into other terms, the problem with this reasoning becomes obvious: The approach mandates that errors that occur only in the project specification document must result in failing the system – even though the system is perfectly correct. Impact on timelines and project costs are the unfortunate results of this convention.

A typical example: The PS for System XYZ, which outlines the setup configurations for the new project system, has an error in the table that describes the permitted treatment windows for each clinical visit. The PS says X plus or minus three days is permitted at Visit 2; the system is configured to allow four days. From client meetings and correspondence, it’s certain that four days is correct– that is, the system is entirely accurate. The only error that has occurred is that the team has forgotten to make the update to the project specification document prior to the start of testing.

Veracity Logic takes the following view in such cases: When there is certainty and collateral confirmation that only the PS document needs to be corrected, Testers are instructed to mark the test step as a Pass and open a new case in our Issue Tracking System for the required PS Update. A unique tracking number is generated for the case and a discrepancy note including this number is added by the Tester to the test case/step. The Validation Summary Report for the entire testing process captures both the number of Passed and Failed test steps and the number and location of PS Updates required to be corrected (and the PS re-approved) prior to releasing the system for Client User Acceptance Testing.

Enrollment Expectations and Site Management

Case Studies

Problem: Your clinical trial will be conducted at more than 50 clinical sites in the U.S. and another 40 internationally. The incidence of disease for the indication of interest varies widely based on geography, but your IRT algorithm treats sites as a unitary phenomenon–a sure path to cost inefficiencies. How can you leverage known statistical differences to control drug waste, shipping costs, and reduce problems with drug allocation?

Solution: As part of its CORE system, Veracity Logic’s IRT (IWR/IVR) includes the option to accommodate site diversity with respect to known enrollment thresholds. Clients can designate a site as an anticipated low, medium, or high enroller. For each enrollment threshold, users can specify differences in the initial drug allocation to a site, the baseline drug supply that is to be maintained at a site, and the alert levels which will let the system know when it’s time to ship more drug. IRT limitations no longer need to contribute to an overabundance of study drug at one site while the study team wrestles with an insufficient amount of drug at a site performing better. Site assignment to the low, medium, or high enrollment category can also be easily modified at any time the circumstances change.

Veracity Logic-Medrio Integration Spells Success

Case Studies

Through Integration of Medrio and Veracity Logic, Atlantic Research Group Expands Capabilities

Finding themselves under a strict timeline and in need of drug supply management, Atlantic Research Group was searching for a way to bolster their software repertoire. Using a free API from Medrio, they were able to access the comprehensive drug supply management capabilities of Veracity Logic without forfeiting Medrio’s top-shelf electronic data capture.

Why Visual Verification?

Case Studies

The Problem: On the one hand we’ve got statistics. On the other hand, we’ve got human lives. Because of the latter, our hearts tend to have zero tolerance for errors in clinical trial data. How do we find the right level of risk and quality control (QC)?

Let’s tempt the wrath of risk assessors everywhere and look at the issue. What’s the real purpose of QC? To be sure, it is NOT to achieve perfection. On that most of us can wholeheartedly agree, including the FDA.

The question is how to decide how much and which types of QC will help ensure the acceptable error margins we’ve set for ourselves.

That’s a whole other kettle of fish.

The Solution: What we strive to produce is a quality management system that works as a whole. Over time, we add and subtract QC tasks until the right balance emerges—one that satisfies both the risk assessment model and the passion for correct data.

At Veracity Logic, one of the steps in our total QC package is a little bit of bother known as “visual verify”. We’ve reached down into the data management archives, pulled it out, dusted it off, and propped it up on the mantel, remembering a time when it was axiomatic that any single-entry act in the double entry world of quality control had to be independently reviewed. One can almost hear the wooden wagon wheels creaking….

Every data change (DCR) and configuration change (CCR) we’re asked to make in an active IRT project system is executed by a qualified project team member and then subjected to an independent visual confirmation by another qualified member of the team. Successful verification is signed off by the reviewer and becomes part of the project record. Only then is the DCR/CCR regarded as complete.

One almost wants to hum the theme song from ‘Somewhere In Time’…