Your EDC Query Count Is Trying To Tell You Something

By Krishna Sai Penumarthi, PharmD, PgDipRA, MSRA, CCRP

Two thousand three hundred twenty-two. That was the number of outstanding EDC queries I inherited when I stepped into my current clinical research management role. Roughly six months after I joined, our team reduced the number to less than 100.

Working through that backlog taught me how to close queries faster. I started paying attention to patterns within the queries. Why were certain questions appearing again and again? Why did some issues keep returning even after earlier queries had been resolved? And when a pattern started forming, was the problem really happening inside the EDC, or was the EDC simply the place where a problem somewhere else in the trial was finally becoming visible?

An EDC system is very good at telling us when data need attention. It can flag missing information, inconsistent values, unexpected entries, and discrepancies that require clarification. But it cannot always tell us why those problems occurred. The query may appear in the EDC, but the problem may have started several steps earlier. Sometimes, a query is a data problem.

EDC Sees The Symptom, Not The Cause

Think about the journey of a clinical data point. The protocol defines what needs to be collected. The site turns that requirement into a workflow. Information is documented in source and then entered or transferred into the EDC, where edit checks, data management review, monitoring, and other processes may identify something that needs clarification.

By the time a query appears, the data have already traveled through several steps.

One example from our backlog stands out. After one study visit, we received about 20 similar queries related to discrepancies between the source documentation and the EDC. At the time, we treated them as individual queries, clarified what was needed, and moved on.

Months later, as more participants completed the same visit, we received more than 130 additional queries of the same type. That was when we realized something else was going on. We went back through the queries and compared what the site collected with what the data management team expected to see. We eventually found the problem: Our site was using a different version of the source documents. An updated version included additional questions, but that update had not been communicated to our site.

Suddenly, more than 150 similar queries made sense. What initially looked like a series of individual source discrepancies was really one underlying process problem. We still had to resolve every query, but simply closing them would never have told us why they kept appearing.

These individual queries form a pattern worth understanding.

The cause could be source documentation, CRF design, protocol interpretation, training, workflow, or data entry. The pattern does not give us the answer, but it gives us a better question to ask.

Closing The Query Is Only Half The Job

The traditional query workflow requires site staff to identify the discrepancy, generate the query, respond, correct or clarify the data, and close it. Technically, that process works. But imagine a CRF field that repeatedly generates queries because its completion requirement is unclear. Every query can be resolved, but the underlying ambiguity remains.

This was one of the biggest lessons I took from working through our backlog. Quickly clearing old queries mattered, but finding their origin mattered more.

Your Query Backlog Is Also a Data Set

We usually talk about a query backlog as unfinished work. I think there is another way to look at it: The backlog itself is a data set.

Clinical trial technology makes it easy to track open queries, query age, response times, and differences between sites. But totals can hide the more interesting story.

Let’s take an example: Site A has 100 open queries, and Site B has 30. It’s easy to assume Site A has the bigger data quality problem. But what if Site A enrolled four times as many participants? What if 60 of its queries came from the same CRF field? What if several sites are receiving the same query because of one edit check?

Technology can give us the metric, but we need to determine the meaning. Instead of looking only at query volume, look for the study's query fingerprint: recurring combinations of fields, forms, visits, sites, timing, edit checks, and query types.

That fingerprint can help identify patterns that deserve a closer look.

A Simple Way To Learn From Queries

After working through a large backlog, I began thinking about query management as more than a close-and-move-on exercise. A practical approach follows:

COUNT → CLUSTER → TRACE → FIX → RECHECK

Count the problem, but don't stop at the total. Cluster recurring queries to see what they have in common. Trace those patterns upstream to understand where they may originate. Fix the likely cause rather than repeatedly correcting the symptom. Then recheck the EDC to see whether the pattern actually changed.

For example, if one CRF repeatedly creates confusion, clearer completion guidance may help. If several sites interpret the same protocol requirement differently, targeted training or clarification may be needed. If an automated edit check repeatedly generates low-value queries, it may be worth asking whether that check is accomplishing what it was intended to do.

And then comes the important part: Look again.

Did the pattern decrease? If not, perhaps the intervention did not address the real cause. That turns EDC query data into a feedback loop rather than simply a record of problems that have already occurred.

Don't Turn Every Metric Into A Site Score

Sites absolutely have a responsibility to enter timely, accurate data and resolve legitimate queries. Sometimes, recurring patterns will identify a real site-level problem that requires retraining, process changes, or greater oversight.

But high query volume alone does not tell the whole story.

If the same issue is appearing across several sites, repeatedly telling each site to “do better” may miss the point. The study team may need to look at the CRF, protocol language, training, edit check logic, or study-wide workflow. Query analytics should be diagnostic before they become punitive.

Maybe Zero Queries Isn't The Best Goal

Bringing our outstanding query backlog from 2,322 to fewer than 100 was an important accomplishment, but what truly stands out is how much information was sitting inside those queries.

EDC systems are powerful tools for collecting, reviewing, and cleaning clinical trial data, but their value does not have to end when a query is closed. Patterns can help us understand the workflows, instructions, systems, and decisions that produced the data. The goal, then, should be a clinical trial process that produces cleaner data in the first place.

The next step in query management isn't simply getting better at closing queries; it's getting better at learning from them. The next time your EDC query count starts climbing, ask yourself, “What are these queries trying to tell us?”

About The Author:

Krishna Sai Penumarthi, PharmD, PGDipRA, MSRA, CCRP, is a clinical research manager whose work spans clinical trial operations, regulatory affairs, and research quality across pharmaceutical sponsors, CROs, and investigator sites. Over more than six years in the field, he has contributed to Phase 1–4 drug, biologic, and medical device studies and has held leadership responsibilities in the operational and regulatory management of industry-sponsored clinical research.

In his current role, Krishna leads a portfolio of clinical trials and works across study start-up, regulatory compliance, quality systems, inspection readiness, sponsor and CRO collaboration, and trial execution.

Krishna has completed more than 35 independent manuscript reviews for medical and scientific journals and has been selected to evaluate scientific work through programs including the Regeneron International Science and Engineering Fair and the Sigma Xi Student Research Showcase. He is an IEEE Senior Member, a Full Member of Sigma Xi, and a SOCRA Certified Clinical Research Professional.