TruTechnologies
TruTechnologies co-founder Rick Graham argues that the industry’s real execution problem is not a modeling problem. It is a data collection problem. And he has the phase three results to prove it.
The clinical trial industry has spent a decade debating how to modernize execution: risk-based monitoring, decentralized protocols, AI-assisted signal detection. Rick Graham has watched that debate from an unusual vantage point. As a clinical pharmacologist who spent more than 20 years inside drug companies, he did not theorize about sample integrity failures. He cleaned them up. After a phase three trial produced drug detections in patients who had never received a dose, Graham concluded that the infrastructure problem was upstream of every tool the industry was reaching for. In 2018, he co-founded TruTechnologies with Scott Ogle, a financial-services software veteran, to address the failure point directly: the moment of sample collection at the clinical trial site. What follows is a conversation about where that conviction came from, what it looks like in practice, and why Graham is skeptical that ICH E6 R3 will move the needle.
Why did three specific failures across your career convince you the infrastructure itself had to change?
Richard Graham: I’m trained as a clinical pharmacologist. The discipline covers two things: pharmacokinetics, how the body processes and eliminates a drug, and biomarkers, which are proteins or patterns of gene expression that shift with treatment or disease. When you pick up a medicine at the pharmacy, the package insert includes information telling you what dose to take, when to take it, what other drugs to avoid. That comes from the work of a clinical pharmacologist. We rely heavily on biological samples to get the right dose to the right patient, for both safety and efficacy.
The first time I saw something that genuinely stopped me was during a phase 2 oncology trial. Cancer patients were coming in every eight weeks for a pharmacokinetic blood draw. When we started analyzing the data over time, the results within individual patients didn’t make scientific sense. The values were all over the place from one visit to the next. When we went back to the sites to figure out what happened, we found that the sites had sheets of pre-printed sticky labels and were not associating specific labels with specific patients and visits. They were just putting an “eight-week sample” label on whatever tube was in front of them. All the samples were getting mixed.
Once we found it, a research associate spent roughly eight hours a day for at least three months trying to reconstruct what actually happened in that study. At the end of that effort, I still had maybe 70% confidence that the data was correct. That was hard to accept.
At the same company, we had two drugs under FDA review, one a biologics license application and one a new drug application. During review, the FDA came back and said there was a major disconnect between what the clinical study report said about the biological samples and what the electronic records for those samples showed. The root cause was inaccurate data capture at the point of collection. What got recorded didn’t match what actually happened to the samples. Same underlying issue.
Then, at a different company, a drug was detected in blood during a phase 3 trial from patients who had never received a dose. The FDA reviewer concluded during the application review that the pharmacokinetic data integrity was compromised. That was all I could take. I went to Scott Ogle, who had never been in this industry before, but whom I knew had the technical expertise to help me solve the problem. I explained the situation and he did not believe me at first. He said, “You’re supposed to be curing diseases and making patients’ lives better. How is that possible?” That was around 2018, and that’s when we started the company.
How did you decide to combine live data capture with protocol-guided workflows in TruLab rather than tackle the data latency problem alone?
Richard Graham: When we started the company eight years ago, we set out to solve the biological sample problem I had seen across my entire career. And to be fair, we did try to solve both the quality issue and the speed issue from the beginning. Data latency was one part of the problem, but I was really concerned about quality.
What we learned over time, and it took a couple of years, is that once we built a technology for contemporaneous source data capture at the clinical trial site, the majority of errors we were seeing happened at the site during sample collection. And the reason comes down to how trials are run. A sponsor writes a protocol, sometimes over 100 pages, that tells a site how to execute the study. Then there’s a lab manual, also potentially 100 pages, that explains how to process the biological samples. You might have 50 sites around the world, and each of them is sending their team into a patient visit armed with their own interpretation of how to conduct a study visit based upon those two documents.
When we saw that, we realized we could fix it. We have a mobile platform, essentially running on an iPhone or Android device, that can be in the hands of the research coordinator running that trial and give them step-by-step instructions through a digital workflow. So it was never really a sequence of solving one problem and then the other. It was, let’s solve quality and speed, and then we hit an insight: we can actually go further and make the site’s job easier by giving them harmonized, step-by-step guidance across all the sites.
“What we learned over time, and it took a couple of years, is that once we built a technology for contemporaneous source data capture at the clinical trial site, the majority of errors we were seeing happened at the site during sample collection. And the reason comes down to how trials are run.”
How did one of those 25 randomization risk interventions actually play out in the rare disease phase three study?
Richard Graham: In that particular phase 3 study, the primary statistical endpoint was a protein measured in urine. The level of that biomarker was expected to decrease over time if the drug was working, because elevation of the biomarker is associated with disease. So the baseline biomarker level during screening was critically important. If a patient has the disease but their biomarker is already very low at baseline, there’s no room for it to fall and you can’t show a treatment effect in that patient.
To get randomized, patients had to complete a screening period of around 14 days. During that window, each patient needed to provide two separate 24-hour urine collections at home. They’d come into the site for a blood draw and to answer eligibility questions, then take two collection containers home and collect every urine sample over a 24-hour period, with timing notes. Then they’d come back, the site would aliquot those samples into tubes, ship them to a central lab, and wait for the results. All of that had to happen within the 14-day screening window. It’s a lot to coordinate.
What our technology showed us, in real time, was that one site had not asked the patient to bring back a second sample, and had not provided instructions for the patient to record when they collected. Our system flagged that automatically through pattern recognition, we had a human review it, confirmed it was a problem, and then escalated it to the CRO and the sponsor. They were able to call the site, course-correct, and the patient remained eligible for the study.
The other 24 risks looked different. Protocol non-compliance at a site, insufficient patient instructions during screening, discrepancies between what the protocol said and what the lab manual said. And sometimes a sample would arrive at the central lab and get held because someone couldn’t read the handwriting on the label. That kind of thing would just sit until someone manually went in and resolved it. For the first time, people can see those things instantaneously and course-correct.
Why does TruLab’s AI work where the FDA’s real-time initiative risks falling short?
Richard Graham: I want to set the stage here, because I have made remarks along these lines publicly and I want to be clear about what I’m actually talking about.
The FDA put out an initiative called the FDA’s Real-Time Clinical Trial Initiative and I’ve been very open regarding my point of view on it and where I think we can improve its aims. Directionally, the idea of having the FDA reviewing information sooner so we can get drugs to patients faster is a good one. But here’s where I think it misses the mark. The concept is that an AI system is fed data while a trial is ongoing, and with a relatively small number of patients and data points, that system flags safety or efficacy signals that then go to the FDA. My concern is what I’d call “garbage in, garbage out”. Anybody can build a model. And what I worry about in that FDA initiative is using AI to identify a signal on a small and potentially inaccurate data set.
Now, our platform uses AI, and we did use it in the randomization example we just discussed. But the important distinction is that our primary focus is not AI. Our primary focus is collecting source data contemporaneously at the site where mistakes actually happen, so that we prevent mistakes in the first place rather than detect them later. We’re not asking people to write on paper and then enter it into an electronic data capture system after the fact, with all the back-and-forth queries that may never fully get resolved. We’re capturing high-quality data right at the source.
So there will always be AI model limitations, including on our platform. But the contrast I want people to seriously think about is the difference between running AI models on incomplete and inaccurate data versus running them on accurate, high-quality data. AI is a bright, shiny object right now. I use it a lot myself. But I’m trained as a modeler, and I know the accuracy of underlying data is way more important than the model you build on top of it.
Why hasn’t ICH E6 R3 changed sponsor behavior the way its advocates expected?
Richard Graham: I’ll start with a skeptical view, and you can challenge me from there.
The prior guidance, ICH E6 R2, already allowed risk-based monitoring. That was from 2016, I believe. And there’s been underwhelming adoption. There was a report from Tufts CSDD in 2024 that found adoption of risk-based quality management was slow, with companies implementing it roughly 50% of the time on average. You’d want to check the source for the exact numbers. So for me, if this approach didn’t get meaningful traction under the prior guidance, what in R3 specifically is going to drive a different result?
Here’s the broader problem. The way we run clinical trials has been in place for a really long time and hasn’t had meaningful change. And there are many stakeholders required to execute a trial: patients, clinical trial sites, CROs, central labs, tech vendors. Each of those stakeholders has different incentives. Take risk-based monitoring, which means you’re not required to have a CRO monitor go to the site and source data verify 100% of the data. You shouldn’t do it. It’s not a good use of time. But that monitor is paid to spend more time doing it. So the incentive to monitor less just isn’t there.
Given the 10-year history under the prior guidance, where it didn’t lead to meaningful change, I personally don’t see significant change in 3 to 5 years. Change in this industry doesn’t happen without accountability. You need a carrot or you need a stick, and I don’t know what either of those is with this particular guidance.
Let me also say that TruTechnologies is in the business of issue prevention. That’s very different from what everybody is used to. This guidance is framed around the way things have been done for 60 years. Risk-based monitoring finds problems weeks later after something has already been entered incorrectly in the EDC. It’s far more important to prevent the errors from occurring in the first place.
Here’s an analogy. Think about a city building code that says buildings should not fall down. Amongst other things, this guidance says studies should be conducted under good clinical practice and should generate reliable results. The analogy is buildings should not fall down. But it never specifies exactly how you prevent the building from falling down. So every builder reads that code and says, I’ve been building buildings for 60 years and they haven’t fallen down. They assume they’re fine. Those buildings stay upright until there’s a catastrophic event. I think the same thing happens here. People will read R3 and say, yes, I’m following good clinical practice and generating reliable results because that’s what I’ve always done. I don’t personally see significant change in 3 to 5 years.
“Change in this industry doesn’t happen unless there’s accountability. You need a carrot or you need a stick, and I don’t know what that is with this particular guidance.”
Why does recovering those two months of enrollment time matter beyond the operational win?
Richard Graham: Part of what led me to start a technology company, while still doing drug development, was ethics. I was trained by someone who worked in the clinical trials office at Stanford’s cancer center before he moved into drug development. He always told me: no matter what data you need from a trial, think about the patient sitting in the chair in the clinic. They’re sick. They’re taking time away from their jobs and their families. Don’t design your trial in a way that makes that patient’s life worse.
The patients in this study wanted to be there for two reasons. One, they wanted to help advance science and medicine. That’s part of being in a clinical trial. The other is they had a chance to benefit from an experimental therapy. If those patients had been turned away because a site missed an inclusion or exclusion criterion by mistake, when they would have otherwise been eligible, that’s an ethical problem. They would have lost an opportunity to benefit from a therapy they might have been helped by. So I’m really proud of what our company was able to contribute here for that reason.
But there’s a broader picture too. By expediting study completion we are consistently helping sponsors bring their timelines in. Think about what that means for patients who are not part of the clinical trial. They’re going to have access to a life-changing (and sometimes life-saving) therapy sooner than they would have otherwise, because it reaches the market faster. And then there’s the economic perspective. Tufts CSDD has done good work on this. On average, they estimate the cost of a delayed drug coming to market at around $500,000 per day. So there’s the patient benefit and the ethical dimension, and there’s also a significant financial benefit.
Richard Graham is co-founder and chairman of the board of directors at TruTechnologies.
Moe Alsumidaie, MBA, MSF, is founder and Chief Editor of Vanguard Publications, which publishes Clinical Trial Vanguard, Pharma Vanguard and BullScope, and Head of Research at CliniBiz. He has two decades in clinical trial operations and data science, with earlier roles at Genentech, Abbott Vascular and Stanford University Medical Center, and is a guest lecturer in clinical trial sciences at Rutgers University.
