What a data query is, why it’s not an accusation, and what a backlog does to a database lock. Written for coordinators learning the data side of the job.

In this file:

·        Who writes queries and why they are not accusations

·        The three kinds: missing, inconsistent, and implausible

·        Why answering fast and answering well are different skills

·        What a query backlog does to a database lock

11 queries landed on a Thursday, all of them on Walter's week four visit, all of them from someone called Sam whom Nani has never met and will probably never meet. She read them in one sitting with her coffee going cold. 9 of them were fair. 2 of them weren’t, and the 2 not-fair ones took her longer than the 9.

A data query is a question raised against a specific data point in the study database. Someone or something has looked at a value the site entered and cannot accept it as it stands, so the system sends the question back to the site and waits.

It is worth being blunt about the emotional part, because nobody warns you and it lands badly the first time. Queries arrive in bulk, weeks after the visit, phrased flatly, from a person who has never met your patient. Eleven of them at once reads like a performance review. It’s not one. A query is the mechanism by which a database becomes clean enough to analyze, and generating them is the entire job of the person on the other end.

The unit of the trial is not the patient here. It is the row. Sam has never met Walter, does not know he was a mail carrier, and does not know he apologized for having to sit down halfway through the walking assessment. Sam sees a heart rate, a date, and a value that does not sit right next to another value. That distance is not indifference. It is what makes him able to see a pattern across four hundred patients that nobody at a single site could ever see.

Queries come from four places, and knowing which one you are answering changes how you answer.

·        The system itself. Edit checks are programmed into the database before the study opens. A date outside a range, a required field left blank, a value outside prespecified limits. These fire automatically, without judgment, and some of them fire wrongly.

·        Data management. People like Sam, reviewing the data as it accumulates, looking for internal contradictions.

·        The monitor. Mira raises queries from what she found during source data verification.

·        Medical review. A physician on the sponsor side reading safety data and wanting more detail on an event.

They all exist for one reason. At the end of the study the database has to survive statistical analysis and, potentially, regulatory review, and every unexplained value is a hole in it. A value nobody questioned is not the same as a value somebody confirmed.

Almost everything you will ever answer falls into one of three shapes.

Missing. A required field is blank. The visit happened, the assessment was done, and the value never made it into the database. These are the easiest to answer and the most annoying, because they are almost always a transcription gap rather than a mystery.

Inconsistent. Two fields contradict each other. A visit date that falls after the next visit's date. A concomitant medication with a stop date before its start date. An adverse event that resolved before it began. The data is not impossible in isolation, it just cannot all be true at once.

Implausible. The value is typeable but unlikely. A weight that moved forty kilograms in two weeks. A heart rate of four. A patient who apparently grew three centimeters at sixty-four. These are the ones where an edit check earns its keep, because a slipped decimal looks perfectly normal until something compares it to the value before it.

The nine fair queries on Walter were a mix of all three. The two that were not fair were an edit check that fired because a lab was drawn one day outside its window, which was true, documented, and already logged as a protocol deviation, and a query asking Nani to confirm a value that matched source exactly with no indication of what was in doubt.

You answer those two anyway, in writing, once, without commentary. Arguing with an edit check is a way of spending an afternoon and changing nothing.

Answering fast and answering well are genuinely different skills, and new coordinators tend to learn the first one and stop.

A fast answer closes the query. A good answer closes it and stops it coming back. The difference is almost always in whether you answered the question that was actually asked and pointed at the evidence.

Bad, and extremely common: "Confirmed."

Better: "Value verified against source. No change required."

Good: "Value verified against source lab report dated 12 Sep. No change. Sample was drawn one day outside the protocol window; deviation already logged, see PD-014."

The last one takes ninety seconds longer and pre-empts the follow-up query that the second one guarantees. A re-queried data point costs roughly three times what a properly answered one cost, because it is read twice, answered twice and reviewed twice.

Note to File: Answer the query in the query, not in your head. The single most expensive habit in data management is fixing the value, closing the item, and never writing down what you did or why. Six months later nobody, including you, can tell whether that number changed because you found a transcription error or because you looked at it and decided it seemed wrong. The answer text is not paperwork sitting on top of the real work. It is the audit trail, and it is the only part of your reasoning that survives.

Queries feel like background noise until the end of the study, when they stop being background.

A study database cannot be locked with open queries in it. Database lock is the moment the data is frozen so the statisticians can analyze it, and everything downstream, the analysis, the study report, the submission, waits on it. A site sitting on two hundred open queries in the final month is the reason a lock date moves, and lock dates moving is the kind of thing sponsors remember when they are choosing sites for the next study.

The other cost is quieter. Queries answered in a panic, in bulk, at the end, get worse answers. "Confirmed" appears a lot in a backlog cleared under pressure. The data still passes, and something real that a careful answer would have surfaced quietly does not get surfaced.

Nani answers hers weekly. Not because anyone told her to, and not because a weekly cadence is written anywhere. Because eleven queries on a Thursday is an hour, and two hundred queries in March is a week she will not have.

A data query is a question raised against a specific value in the study database, generated by an automated edit check or by a data manager, monitor or medical reviewer, and it is not an accusation. Nearly all of them are one of three kinds: a missing value, two values that contradict each other, or a value that is typeable but implausible. A good answer resolves the question, points at the source record and says what changed and why, which takes slightly longer than "confirmed" and prevents the follow-up query that "confirmed" reliably produces. And because a study database cannot be locked with open queries in it, a site's query backlog eventually stops being that site's private problem. Nani closed nine of the eleven that afternoon, wrote two careful sentences on the two she disagreed with, and put the whole thing out of her mind until the following Thursday.

·        Previous in the site file: Issue 10, source documents

·        Next in the site file: Issue 14, protocol deviations

·        The whole file: roottorx.com/t/open-site-file

·        Root to Rx: the newsletter and The Root Room, the patient-facing side of the same story, at roottorx.com

·        21 CFR 312.62 — Investigator recordkeeping and record retention (eCFR)

·        21 CFR Part 11 — Electronic Records; Electronic Signatures (eCFR)

·        FDA — Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers (October 2024)

·        FDA — E6(R3) Good Clinical Practice, Guidance for Industry

•  •  •

The Open Site File is general education about how clinical research sites work. It is not regulatory, legal, or medical advice, and it is not tied to any specific study, sponsor, or employer. Study OLS-114 and all names are invented. Always follow your own site's SOPs, your protocol, and your PI and QA team. Characters are composites.

Filed by Justin Yamashita, MSc., Open Label Media

Next in the file: Issue 14, the visit that happened two days outside the window, and what the site did about it.