YouTube Facebook LinkedIn Google+ Twitter Xingrss  

Site Gripes and Solutions for EDC


Of all the e-clinical technologies, electronic data capture causes the most site frustration.

BY DEB BORFITZ

September 15, 2009 | Even the most progressive, tech-savvy investigative sites are aggravated by many of the e-clinical systems being embraced by study sponsors. Virtually no type of clinical trial technology escapes criticism, but EDC systems seem to be the biggest offenders, according to several sites that spoke to Bio•IT World about their experience. However, the same sites also made suggestions for easing the relationship.

Today’s EDC systems typically have the horsepower to process large volumes of data simultaneously, but still manage to create more rather than less work and expense than they did in 1995, says Kelly Walker, director of operations at Research Across America (RAA), an independent site network based in Dallas.

The biggest problem is with web-based EDC systems that get placed on servers and networks “not nearly robust enough to handle the workload,” says Walker. In some cases, web pages won’t “refresh” correctly because the browser is trying to cache those pages to reduce server load and perceived lag. Although there are cache-control settings to rectify the problem, site personnel aren’t instructed how to make the necessary adjustments.

Another ongoing issue is the variability with which EDC systems support different versions of foundational software such as Internet Explorer and Adobe Reader, says Walker. “It means study coordinators working on two different studies [often] need two different computers on their desk.” Site staff can also inadvertently wreak havoc whenever they respond to automated promptings to update any of that underlying software.

That sponsors now have the ability to instantaneously reformat pages or add new questions to electronic case report forms (CRFs) has also created problems for RAA, says Walker. Sites are expected to gather the new information retroactively on patients who probably don’t remember if that headache they had several months earlier was mild, moderate, or severe. Other times there is rampant indecision about what should count as an adverse event, leaving sites to alternatively delete and re-insert data. The high turnover rate among study monitors is a contributing factor, he adds.

Perhaps the biggest technical oddity at RAA is that two of the three PCs outfitting Walker’s office won’t display CRF pages correctly. Date field boxes are missing and no manner of technical support can figure out why. “Our people have had to learn how to enter data without the boxes….where they know [from experience] the answers should go.”

Pedia Queries
At Pedia Research, the chief complaint about EDC systems is that they often generate unnecessary queries, says Richard Litov, director of the dedicated, three-site network based in Owensboro, Ken. To avoid answering umpteen automatically generated queries, site personnel wait until they have every last piece of patient visit information (including lab results) before entering any data at all. Often contributing to the query problem is that the software fails to help users at the sites visualize what information is missing or incomplete without the time-consuming process of opening each individual screen.

CRF pages written in-house by large companies using the Oracle database are the bane of Diane Palmer, site administrator and clinical research coordinator at Coastal Connecticut Research (CCR), a dedicated site in New London. With one recent study, the site had to enter data on 46 separate pages for every neurological exam done by the investigator. Each exam took only ten minutes, but data entry took a whopping 90 minutes. “We almost quit recruiting for the study because we were losing money.”

Part of the problem is that headers are frequently not pre-populated with data from their previous visit, says Palmer, meaning someone at the site has to constantly re-key the visit date in the prescribed format—i.e. 03 May 2009 versus May 3, 2009 or, if the date is unknown, “not done” versus “ND” or “00.” To make matters worse, each CRF page often contains only one or two data fields that have to be filled in and saved before moving on to the next set of questions.

Palm Pilot-type based electronic patient diaries also aren’t particularly popular with the interviewed sites. One recent e-diary study at Pedia Research was a “complete disaster,” says Litov. Patients ended up making entries on paper and the site struggled to re-key the information into the unwilling system. In this case, the central problem was a rushed timeline. “The poor vendor didn’t have enough time to get the system ready to go, error-free.” Patient misuse of the technology is part of the problem, says Walker, but the bigger issue is that e-dairies don’t mimic clinical practice. If study participants fail to take a pill at the exact time specified the data they enter will be rejected. Questions can also be oddly or unclearly posed, confusing patients. Diaries appear at times to erroneously record entries about symptoms, disqualifying subjects who seem perfectly suited to a study.

The vendors, of course, blame the site or the user. But Walker says such predicaments happen often enough that the technology must be called into question.

Site Solutions 
But sites also offered some solid remedies for improving the situation. Sponsors building electronic case report forms (eCRFs) in-house might want to start pre-populating data fields with information from subjects’ prior visits, suggests Palmer. Better yet, site personnel could enter study visit data on a single page.

The Holy Grail of eCRFs would be for the industry as a whole to come up with standards for data entry, she continues. For sites like CCR doing multiple studies, it’s difficult to remember company-specific requirements for inputting information. There are four alternatives for the date format alone: 5/26/2009, 26May2009, 26May09, or 5/26/09. Failure to follow data-entry rules results in automatically generated, time-consuming queries, which steals time from patient recruitment activities.

Palmer declares Phase Forward’s Inform EDC system “one of the best” and worthy of mimicking, including its online training module that includes a printed certificate of completion. 

EDC systems as a rule fail to provide the kind of information that could make life easier for sites, such as a study’s enrollment status, says Litov. Instead, they deliver the intelligence six weeks late via hardcopy newsletters. “Sponsors and CROs can see that information [electronically]. Why not us too?” Similarly, adds Litov, central lab vendors continue to transmit lab values via fax. In an ideal world, sites would receive lab reports electronically, including graphics comparing current and previous lab values of a study subject so investigators don’t have to sift through paper charts to detect important changes. Doing so “would lead to better oversight and evaluation of safety.”

Litov says it would serve sponsors’ interests to involve a few sites in the technology acquisition process and then conduct post-study surveys to learn how well a chosen EDC system performs in the real world. “We’ve seen a sponsor switch to a different EDC system for each of three studies conducted in the same program.”

From consistency and accuracy, it would be advantageous for sponsors to provide a standard, study-specific template for source document forms rather than rely on each site to generate their own forms from scratch, especially since these forms mirror the CRFs that are already produced, says Litov. He estimates that Pedia Research donates between 5-20 hours of “secretarial work” per study to create the requisite forms. “Multiply that by 50 or more sites for a multi-center trial and that is a lot of wasted time diverting sites from starting up a study.”

Kelly Walker believes it is time EDC systems were incorporating user-friendly handwriting or voice recognition features. Knowing it could be a long wait, he has taken matters into his own hands by developing a single-data-entry system called DB Pharma, with a programmer familiar with Microsoft tools.

DB Pharma, run off a wireless tablet, utilizes handwriting recognition technology and immediately transmits data to a web host. But it only gets used on a few studies a year, when RAA is responsible for either all of the data capture or all of the data analysis. The system’s only downside, Walker says, is that it doesn’t accommodate doctors’ notoriously sloppy script. 

View Next Related Story
Click here to login and leave a comment.  

0 Comments

Add Comment

Text Only 2000 character limit

Page 1 of 1


For reprints and/or copyright permission, please contact  Terry Manning, 781.972.1349 , tmanning@healthtech.com.