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.
Key Problems
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.
Map It
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.
.(JavaScript must be enabled to view this email address) welcomes feedback about the state of CTMS or other topics. He has more than 25 years of experience in the pharmaceutical industry, including data management, programming and IS support. He has personally witnessed the evolution from a pure paper process to the development of eclinical processes.
Editor’s note: ClinPage welcomes articles from readers. Contact the .(JavaScript must be enabled to view this email address), or take a peek at our editorial guidelines.
d9A2t49mkex



Rob I am working on one of the solutions to these dilemmas. Take a look at http://www.clinicalink.com and view the flash demo. I would be interested in your thoughts.
»» Posted by: Thomas Littlejohn at February 5, 2008 11:29 AM
Thank you for sending the link to Clinical Ink. This solution is interesting. It is very reminiscent of the earlier Padcom and Penergy systems that never took off. Hopefully today’s technology better supports this platform. The earlier systems suffered from a variety of problems, particularly speed of page turns, and character recognition rates.
The claim that this system eliminates the source documents may not be completely true. In my experience you will encounter some sites who want the source documents in their own site specific format. Since this system is only being used for the clinical trial(s), they would still have their own source records and worse off if it is for a regular patient they would have a gap in their records (this gap being the time during which Clinical Ink) was used for a clinical trial. It would be nice if the system could be provided in an cost effective enough manner for the sites to switch to this system for all their records.
One point I’m curious about, but did not see mentioned in the online information, is how the clinical trial data is kept separate from any additional medical records accumulated during the course of the trial. Also how is patient confidentiality assured. I expect all these points have been covered.
Since different sites have different source record conventions, forms, etc. Is the expectation that this system is modified for each investigator site?
From what I saw in the demo it appears as though the AEs are presented in a pick list approach. This may be a regulatory hurdle as I know many sponsors take a very conservative approach and fear that such an approach can be viewed as leading the investigator. To address these concerns the system would need to allow for AEs to be entered as direct text entries.
The portability of the system is nice. But I’m curious as to whether the records reside on the tablet device itself, or is a network connection required the entire time. Since wireless network connectivity can often vary from room to room, this approach would obviously be a concern (if it is used).
Total uptime for the hosting service will be another concern. Obviously there is always some maintenance requirements. In a global trial there is often no adequate window for downtime. So I’m also curious as to how this is handled.
Just my thoughts from a 10 minute look at the web site.
—Rob Musterer
»» Posted by: RMusterer at February 13, 2008 10:20 PM