A never-ending tension in clinical trials exists between a client’s need for quick changes to a technical system – for example, an IRT (IWR/IVR) system in production — and the vendor’s need for time. The axiomatic truth is this: the details of clinical trials are often fluid, with the need for changes commonplace. But Sponsors and CROs often get frustrated …
Everyone makes mistakes – it’s part of being human. We’re not automatons who simply complete tasks day in and day out. If only life were that simple. It seems there are always small “tweaks” to any process involving information management and processing. The question is, how do we minimize errors and remove stress from our lives?
One answer, simple though it seems, is to create checklists — quick, focused lists of reminders. Most of us already have Standard Operating Procedures (SOPs) for each of our processes. Yet few staff find it convenient to re-review an SOP during the execution of a task — not only have they already been trained in that task, but many SOPs are complex documents with more (or less!) information than they need.
Change is a constant in the world of clinical study planning. In The Art of Making Changes Part 1: Five Keys we talked about the stress change can generate, and about the five essential elements for achieving painless change management for IRT (IWR/IVR) systems. The present article outlines the components of a successful management process for technical change.
Doctors will tell you that change – any sort of change – is hard on humans. As endocrinologist Hans Selye observed, “Stress, in addition to being itself, is also the cause of itself and the result of itself.” Good changes and bad changes alike elicit stress points on psychological scales.
Most clinical trial Project Managers will say the same thing applies to managing changes in clinical studies – especially those that impact data systems (e.g., EDC, IRT/IVR/IWR, etc.)! This includes configuration changes, protocol changes that require changes in how a technical system functions, data changes, process changes…and more.
It’s not always big things that make a difference in the efficiency of a clinical trial — sometimes it’s the smallest things.
The IRT (IWR/IVR) database is no exception to the rule. The incorrect formatting of a fax or phone number, or an extra space in an email address where automatic notifications are to be sent can wreak havoc with the best laid plans. Likewise, an error in the spelling of a field label, or failing to update the name of an internal infrastructure unit like a new email server can cause significant issues and must be corrected.
One of the much-lamented aspects of a regulated industry like pharmaceuticals is the amount of documentation required for the successful conduct of a clinical trial for new drug development. The old industry adage ‘if it isn’t documented, it didn’t happen’ was with us at the birth of modern FDA trials and it remains just as true today. The move from a predominantly paper-based environment to an electronic environment didn’t change a thing – the lament just moved from one venue to the next!
To complicate matters further, client audits and government inspections make it necessary to be able to lay your hands on a document expeditiously when called upon to do so. Government endorsement of GCPs and document management standards further add a string of ‘must do’s’ to everyone’s SOPs.
Can Your IRT System React to Surprise Protocol Changes?
If you’re on a dark ocean and spot an iceberg ahead, do you really want to be on board the Titanic? Clinical trials have hidden challenges that surprise sponsors and vendors alike. So using a vendor that reacts quickly is critical to saving time and costs for sponsors.
You’re a Clinical Project Manager (CPM) given a study halfway through enrollment and you need to get up to speed on study status FAST! How can your IRT help?
Fortunately, you’re using Veracity Logic’s Interactive Response Technology system, VLIRT®. Here are five key features geared toward CPMs who find themselves in just this predicament.
The management of multiple cohorts is a standard offering of most IRTs. In the common sequential model, when Cohort 1 reaches a pre-designated limit the cohort is closed by the system and subjects can no longer be enrolled into that cohort. Problem: The design of your study is such that the maximum number of subjects in each of your four planned cohorts cannot be fixed at study startup, and more than one cohort can, in certain circumstances, be open simultaneously. How should the IRT be set up to provide this kind of adaptability?
The Veracity Logic Solution:
A typical approach to achieving flexible cohort functionality is to assign the task to the system development team. Programmers and configuration managers would modify code or system configurations during the trial as needed to adjust cohort parameters. Additional costs, time delays, and the need to produce change orders and approval documents for interparty communication, are three notable downsides to this approach.
Veracity Logic’s IRT platform supports an alternate strategy. In addition to system controls, we offer a user-friendly, manual approach that puts the power of change directly into the hands of authorized users. Cohort parameters are configurable, no coding changes required. Cohort limits can easily be modified and re-modified with the click of a button. Likewise, cohorts can be manually opened and closed, re-opened and re-closed on demand, all by the users themselves, and in the users’ own timeframes.
There are many options for processing manual data changes in an IRT system. Some vendors make all data changes for the clinical site users. Others have electronic systems where users can request and approve changes, while still others require ‘wet’ signatures. What’s the best option for achieving the two key goals of change control, i.e., documenting user approval while streamlining the process so it doesn’t take days to make a change?
At Veracity Logic, we put our emphasis on enabling and training authorized end-users to handle most manual data corrections themselves, just as they do in their EDC systems. The range of edit permissions varies based on the needs of each project.
We’ve found that most users not only don’t mind having the power to make many of the data corrections within the IRT, they actually prefer it to having to generate paper requests and factor in vendor response time (not to mention the increased cost of PM and Help Desk involvement).
For changes that technologically require vendor action, we make the change for them using a documented paper/signature trail. We don’t require the document contain a ‘wet’ signature, a faxed or PDF’d copy is sufficient.
Regardless of the method used, a proper audit trail must be kept whenever changes are made to clinical data by authorized users and it needs to include a justification/reason for the change. That said, when such capabilities (proper authorization, a full audit trail and requirement for recording the reason for a data change) are included in an IRT system, tied with the ability to ‘attach’ notes to records within the database, the additional time/effort of a laborious paper-based process is unnecessary.
- Page 1 of 2