During a recent presentation at a conference, I described clinical trial management systems (CTMS) as “data hungry beasts.” The nods and smiles of agreement from the audience were nearly unanimous.
At the same conference, an investigator was present. He described his general surprise at how often sponsor companies act as though they do not have information that they should have. His examples included late payments and sponsor companies contacting physicians who no longer participate in clinical trials—or who did not have the appropriate patient population for a trial.
What’s Wrong With This Picture?
I have nothing against any of the current CTMS. But in my experience, these systems suffer from poor user compliance and data quality. As a result, users tend to create their own workaround solutions to CTMS in spreadsheets or in simple databases.
CTMS do offer the promise of better clinical trial management. No one could be opposed to that. The systems accomplish this by tracking details of the trial process and reporting performance metrics. That’s valuable and useful, in theory.
In practice, however, why do investigators still lament about late payments? Why do internal users still bypass CTMS designed to address such problems? In my opinion, the reasons come down to a few root causes.
First, clinical trials have been seen as an extension of research, run as a scientific endeavor—not a business process. Attention is paid to the scientific merits of the trial, the accuracy of the data, and the regulatory compliance to assure that the results hold up under scrutiny. This model may have been perfectly acceptable ten years ago, but the current environment requires adding a stronger business focus and better management practices.
Second, the nature of CTMS design is that the value derives from tracking and reporting metrics. As such, monitors and other users who are the initial data entry users (more about them later) must enter a lot of data into the system. But (and this is crucial) those initial users personally receive limited value from such effort. This is what I mean by CTMS as data hungry beasts. The users have the responsibility of feeding and caring for the beast. But they get almost nothing back.
Declining Data Quality
As a result, the timeliness and quality of CTMS data suffer. Not only do the initial users get limited value from entering the data, but all too often this labor is a transcription from other records. Nobody likes to transcribe information from one place to another. Because of the resulting poor data quality, secondary users higher in the organization start to distrust the information.
It is common for pressure to be applied to the initial users to get them to enter the data and improve the quality. This stick-based approach works for a while. Typically, however, the initial users start to slack off and the problems re-emerge.
An Unfortunate Cycle
The stick is then typically supplemented with training to highlight the value to the organization of having reliable data in CTMS. Compliance improves for a short period, but then human nature reasserts itself. The initial users start to slack off on the data entry again.
At this point, it is common to find secondary users developing side solutions to meet their needs. The most common workaround are spreadsheets, loaded initially with an extract from CTMS. Later, the spreadsheets are manually updated with personal information obtained from discussions with various project team members.
A highly inefficient process ensues. Multiple users keep overlapping copies of relevant data supplemented by manual updates taken periodically from CTMS, with varying levels of sophistication and accuracy.
Other user groups who find that CTMS do not fully meet their needs develop their own custom solutions, using simple databases. All of this leads to less data being fed into CTMS, which leads to a self-fulfilling cycle. Users feel that the system doesn’t meet their needs and their workarounds virtually guarantee that CTMS cannot meet their needs.
A New Approach
How do CTMS regain their promise? Sadly, current products have been designed with the end result in mind, but without sufficient attention to the clinical trial process. What is required is a new type of trial facilitation tool—a system designed for the users who initially populate CTMS with data. Note that I do not use the title of any such initial users, because at different stages of the trial process, there may well be different types of people that handle such roles.
I can already hear objections. Different companies have different procedures. Within a single company, different types of trials have different procedures. How can one system possibly support them all? There are several ways this nut can be cracked.
The answer lies in developing a flexible solution that sits on top of a core backbone. A framework for data exchange and consolidation in a repository must be defined. Then a work flow engine that maps procedures must be created. This mapping needs to be done by the initial users to allow them to identify the points where data gets captured and how they can best capture that data, rather than simply transcribing it from one system to another.
Additionally, the system needs to support user defined extensions with options to make them available to a broader user base. These extensions can thus eliminate the creation of side solutions for unique requirements. Yes there is a risk of these extensions duplicating data already captured within the core system, but at least such instances will be more visible and open for being rectified than numerous independent workarounds.
Tie It Together
Such a system would require looking at new ways to architect such systems. The goal: to provide portable devices or web-based interfaces that initial users can appreciate in the field at clinical sites. Integration with other clinical tools, such as interactive voice response (IVR) or electronic data capture (EDC) systems, will assure data is obtained from an authoritative source.
New approaches to implementing various solutions must make it easier for initial users to populate a database as part of their regular duties in an unobtrusive manner, yet still allow for this data to be transferred to a new trial facilitation system.
There are PDAs and tablet PCs with bar code scanners, portable OCR scanners, digital pens, conventional laptops, etc. Surely with a little ingenuity and observance of the initial users’ true work flow, a system can be created that eliminates the need for transcription. Once we have sufficient reliable data, it will be easier to provide meaningful aggregations of the data in reports that turn the data into actionable information.