Most data problems in a clinical trial are built in before the first participant is enrolled.
Oct 2, 2026
Most data problems a clinical trial will ever have are built in before the first participant is enrolled. Not during analysis, which is where people go looking for them. During protocol development, when someone decides what a measure or survey will ask, which answers it will accept, and who will be sitting there filling it in at the end of a clinic day. By the time a participant is in the chair, you are not preventing problems any more. You are living with the ones you designed in.
Almost all of them are cheap to prevent and expensive to fix. That is a bad combination for anyone who starts thinking about data only once the data is arriving.
I run the HESTIA Core, a new university-wide clinical data science core at the University of South Carolina. Studies come to us with a protocol and a deadline, and we build what they need to collect, manage, and report their data. Most of that job is translation. What a clinician means by a measure, what a statistician will need at the end, and what a database can actually hold are three different things, and somebody has to make them agree before anyone starts typing. It means spending a lot of time in rooms with investigators, clinicians, informatics staff, and research administrators, who do not naturally share a vocabulary.
STARS is one of those studies and the one I know best. I am its Data Core Manager. It is an NIH-funded Phase II/III trial testing transcranial direct current stimulation paired with lexical-semantic therapy for people with chronic post-stroke aphasia, running at three sites: USC, MUSC, and Utah. I do not deliver the therapy. I build and run everything underneath it, and nearly all of that work happens in the months before anyone is enrolled.
Where it came from
Most academic trials now run on REDCap, Research Electronic Data Capture, which came out of Vanderbilt and was first described in a 2009 paper by Harris and colleagues. The idea was almost unreasonably practical. Clinical researchers kept building study databases the hard way, which usually meant multiple spreadsheets, or a custom application that needed a developer who left halfway through the grant. REDCap let the researcher define the study as metadata, a data dictionary, and generated the application from that.
That design choice is the whole story. Because a study is described rather than programmed, the person who knows the protocol best can build the database, and what they build arrives with an audit trail, user accounts, validation, and exports already attached.
It spread the way useful free things spread. By the time the consortium paper came out in 2019, REDCap had grown into thousands of institutional partners across more than a hundred countries, supported by a consortium rather than a company. I am taking those figures from the two papers rather than from a current count, and they move every year.
What the revolution actually hands you
REDCap hands you a building. It does not hand you a study. The foundations hold, the audit trail works, the exports are clean. What happens inside is still yours to design, and the software will let you design it badly in complete silence.
That gap is not a flaw. It is the direct cost of the thing that makes REDCap good. You cannot both remove the gatekeeper and keep the gatekeeping.
What this looks like on one trial
The build is 39 instruments and 959 fields: every paper form and validated measure in the protocol turned into something a clinician can complete without a manual open beside them.
766 of those fields are required. 334 carry validation rules, so a date cannot be a word and a score cannot be 400. 168 appear or disappear depending on earlier answers, so nobody reads questions that do not apply to the person in front of them. 49 calculate themselves, which is 49 chances for arithmetic to go wrong that I have taken away from a tired human at four in the afternoon.
Every one of those decisions was made before enrollment opened. That is not a scheduling detail. A required field you forgot to mark required produces two years of partially empty records, and no amount of careful analysis afterward will put the answers back.
Giving the therapy room its time back
The people entering this data are speech-language pathologists. Every hour one of them spends re-typing a form is an hour not spent with someone who is trying to get their language back after stroke. Most of what I have built comes from that single idea, and it is the part of the job I would defend hardest.
Screening happens in a separate REDCap project, which is right for consent and privacy reasons and inconvenient for everyone doing the work, because the same case history then exists in two places. So I mapped it. 115 fields now copy from the prescreening project into the main study when a participant advances. The clinician types an ID, clicks a button, and never re-keys a form they already filled in. That is 115 opportunities to mistype something, removed, on every participant who enrolls.
Eligibility scores itself. The screening form evaluates the inclusion and exclusion criteria as they are entered and tells the person at the keyboard, right there, whether this participant qualifies. No separate checklist to keep in sync with the protocol, and nobody waiting two days for someone to review a spreadsheet.
The treatment session log watches for the safety items that matter during stimulation and flags them for follow-up. That one matters to me more than the time it saves, because the alternative is relying on somebody to remember at the end of a long clinic day. Memory is the wrong material to build a safety net from.
None of this is clever engineering. It is taking seriously that the person at the keyboard is doing their best under time pressure, and deciding the system should meet them there rather than ask them to be more careful.
The part that runs itself every month
A trial reports continuously: enrollment, safety, and whether the data arriving is any good. That used to mean someone sitting down with an export and assembling numbers by hand for a day.
Ours is one command. An R pipeline authenticates against the REDCap API, pulls the project, builds a rulebook, runs quality checks against it, and writes the report.
The piece I am most pleased with is that the rulebook is not something I maintain. REDCap already knows what every field is: its type, its allowed range, the coded answers it accepts. The pipeline reads the data dictionary and converts that into data quality metadata, so a rule like "this score must fall between 0 and 60" is not something I wrote down separately and have to remember to update. It is derived from the same dictionary that generates the form. Amend the protocol and the checks change with it. There is no second copy of the truth to drift.
The hard part was never the checking. It was the denominators.
Consider missingness. If you count every blank field as missing data, a form a clinician started this morning and will finish this afternoon shows up in your report as a wall of red. Do that once and people learn the report is noise, which is worse than having no report. So missingness is counted only over forms the site has marked complete, and a form nobody has finished does not flag. Range violations work the opposite way. An impossible value is impossible whether or not the form is done, so those are checked over every row, in progress or not.
Enrollment has its own version of the problem. REDCap exports one row per participant per event, so a participant who has been to nine visits is nine rows. Counting rows instead of distinct people would have inflated our enrollment in a report that goes to a safety monitoring board, which is not a mistake you want to make twice. Everything counts distinct participants, cumulative and new this month, broken out by site.
About twenty tests sit underneath those functions. They exist because every one of these decisions looks obviously correct while you are writing it and produces a quietly wrong number six months later.
Available is not the same as easy
I think the REDCap revolution is real, and I think the way it is usually described is slightly wrong.
It is not that REDCap made clinical data management easy. It made clinical data management available. Those are different claims. A tool that lets a five-person lab in a country with no informatics budget run a registry properly is a significant thing, and the consortium model is why that happened instead of a licensing fee.
But availability moves the work rather than removing it, and it moves it earlier. The database is easy to build and just as easy to build in a way that quietly costs you a study. None of that work produces a figure or a citation, which makes it easy to defer, and deferring is exactly how trials end up discovering their data problems at the end, when fixing them is expensive, and some of them cannot be fixed at all.
Somebody is sitting in a clinic room with two wet sponges on their head, working through pictures, trying to get back a word they used to have. Between them and the result that might help the next person is a chain of forms, exports, and checks that nobody will ever read about. My job is to make sure that chain never becomes the reason the answer is wrong.
STARS is funded by NIDCD (U01 DC022447), with sites at USC, MUSC, and the University of Utah.
References
Harris, P. A., Taylor, R., Thielke, R., Payne, J., Gonzalez, N., & Conde, J. G. (2009). Research electronic data capture (REDCap): A metadata-driven methodology and workflow process for providing translational research informatics support. Journal of Biomedical Informatics, 42(2), 377-381.
Harris, P. A., Taylor, R., Minor, B. L., Elliott, V., Fernandez, M., O'Neal, L., McLeod, L., Delacqua, G., Delacqua, F., Kirby, J., & Duda, S. N. (2019). The REDCap consortium: Building an international community of software platform partners. Journal of Biomedical Informatics, 95, 103208.