A patient with a central venous line — a routine IV catheter placed in a large vein — gets flagged by an AI system as having undergone cardiac catheterization, an invasive heart procedure. The AI sees "catheter" and "venous" in the medical record, notices the patient was in a cardiac care unit, and concludes: ineligible. That patient never gets seen by a trial coordinator. They never get the chance to participate in a study that might save their life.
This isn't a hypothetical. Studies evaluating AI models for clinical trial matching have documented exactly this failure — systems concluding that a central venous puncture is the same as cardiac catheterization. And it's not a rare edge case. It represents an entire class of errors that quietly bleeds eligible patients out of the recruitment funnel every day.
I've spent the last few years obsessing over this problem because the stakes are staggering. Approximately 80% of clinical trials fail to meet their enrollment timelines. Not because there aren't enough patients with the right conditions — but because our tools can't reliably identify them.
The $800,000-a-Day Problem
Every day a clinical trial runs behind schedule, it costs money. But the numbers are worse than most people realize.
Research from the Tufts Center for the Study of Drug Development puts the cost of a single day of delay at roughly $800,000 in lost prescription sales for a high-performing drug. In cardiovascular and hematology trials, that figure climbs past $1.3 million per day. And that's before you count the $40,000 daily operational burn of keeping trial sites open, monitors working, and CRO contracts active.
The real killer is competitive timing. In oncology — non-small cell lung cancer, acute myeloid leukemia — multiple drugs often race toward the same regulatory finish line. The first to market captures the standard of care. Being six months late because you couldn't enroll patients fast enough can turn a scientifically superior drug into a commercial failure.
A six-month recruitment delay doesn't just cost money. For patients with progressive cancer, it's the difference between accessing a potentially curative therapy and receiving palliative care.
I remember the moment this clicked for my team. We were looking at screening failure data — the rate at which patients get flagged as potential matches but then rejected after manual review. The industry average cost per screen failure is about $1,200. When your AI generates 100 candidates and only 5 are truly eligible, you've just wasted $114,000 and, worse, destroyed the site coordinator's trust in your system. They go back to manually scanning PDFs. We explored the full financial and operational dimensions of this crisis in our interactive analysis.
That's the paradox: more automation can actually make recruitment less efficient.
We're Solving a Logic Problem With a Probability Tool
The root cause became obvious once we stopped looking at it as a technology problem and started looking at it as a category error.
Large Language Models — GPT-4, Claude, the models everyone's rushing to wrap into clinical trial tools — are probability engines. They predict the next most likely word. They're brilliant at reading messy handwritten notes and extracting information. But when you ask them "Is this patient eligible for this trial?", you're asking a probability tool to solve a logic problem.
Three things go wrong:
They're not deterministic. Run the same patient record through the same LLM twice, and you might get different answers depending on temperature settings, prompt phrasing, or context window. Clinical trials require 100% reproducible audit trails. Regulators need to know exactly why a patient was included or excluded.
They hallucinate. If a patient note is ambiguous, an LLM might invent a diagnosis to fill the gap — fabricating a comorbidity that excludes someone, or worse, inventing a clearance that includes someone who shouldn't be there.
They conflate similar-sounding things. This is the cardiac catheterization problem. In the mathematical space where LLMs represent meaning, "cardiac catheterization" and "central venous catheterization" sit close together. Both involve catheters. Both involve the vascular system. The model sees similarity where a clinician sees a fundamental distinction.
The industry is trying to cure the recruitment crisis with syntax. The cure is in semantics.
What "Understanding Medicine" Actually Looks Like
When I say our system "understands" the difference between cardiac catheterization and a central venous line, I don't mean it learned from more training data. I mean it checks a map.
We built our system on top of SNOMED CT — the world's most comprehensive clinical terminology system. Think of it not as a medical dictionary but as a massive family tree of medical concepts. Every procedure, diagnosis, and finding has a unique code and sits in a specific place in a hierarchy connected by "is-a" relationships.
Cardiac catheterization sits under "Procedure on heart." Central venous catheterization sits under "Catheterization of vein." They're on completely different branches of the tree. When a trial protocol excludes cardiac catheterization, our system doesn't search for the words "cardiac" or "catheter." It asks: Is this patient's procedure a subtype of the excluded procedure? The hierarchy answers no. The patient stays eligible.
This works even when doctors write "Central Line Placement" or "CVC Insertion" or any of a dozen other shorthand variations, because the system first maps every phrase to its unique concept code. Once you're working with codes instead of words, the ambiguity vanishes.
The same principle handles the synonymy problem that plagues keyword searches. A doctor might write "Heart Cath," "Angio," "Coronary Angiography," or "LHC." A keyword system needs to be hard-coded with every possible variation — and it will still miss novel phrasings. SNOMED maps all of them to the same concept automatically.
The "Unless" Problem That Breaks Every Simple AI
Matching medical concepts is only half the challenge. The other half is parsing the rules.
Trial protocols aren't simple checklists. They're dense legal-medical documents full of conditional logic. Consider this actual exclusion criterion from an oncology trial:
"Exclude patients with hypertension, unless it is well-controlled on stable medication for at least 3 months."
A keyword matcher sees "hypertension" and excludes the patient. A simple boolean filter sees "hypertension = TRUE" and excludes. Both throw away a patient who has the condition but is perfectly eligible because it's controlled.
We handle this with what's called deontic logic — a formal system for reasoning about obligations, permissions, and prohibitions. The system parses the sentence into: hypertension is forbidden, but hypertension that is controlled and stable for 3+ months is permitted. Then it checks the patient's medication history and blood pressure readings against those specific conditions.
It gets more complex. Consider: "Patients must not have received prior chemotherapy, unless it was neoadjuvant therapy completed more than 6 months ago."
Now the system needs to verify three things simultaneously: Did the patient receive chemotherapy? Was the intent neoadjuvant (meaning it was given before surgery to shrink a tumor, not as a primary treatment)? And did it end more than six months before the trial's reference date? We built temporal reasoning into the system specifically to handle these timeline calculations — placing patient events on a timeline and measuring durations against protocol requirements.
We don't match words to words. We evaluate a patient's clinical state against the logical rules of the protocol. That's the difference between a search engine and a reasoning engine.
How the Pieces Fit Together
Our architecture splits the work between two AI systems that are good at very different things.
The neural layer — a large language model — handles perception. It reads messy, unstructured medical records: scanned PDFs, handwritten notes, physician narratives. Its job is only to extract medical concepts and map them to SNOMED codes. It doesn't decide eligibility. We constrain it to output valid medical terminology codes, which cuts hallucination at the source.
The symbolic layer — a logic engine built on a knowledge graph — handles reasoning. It takes those structured codes, applies the protocol's rules using formal logic, checks hierarchical relationships, calculates temporal conditions, and produces a deterministic eligibility decision. Same inputs, same output, every time. With a complete audit trail showing exactly which rule matched which piece of evidence.
When the system encounters ambiguity — a note that says "possible history of..." rather than a confirmed diagnosis — it doesn't guess. It flags the case for human review and highlights the specific criterion and text snippet causing the uncertainty. In testing, this "pre-digested" view reduces the time a clinician needs to review a chart by up to 40%.
We also use what's called Graph Retrieval-Augmented Generation — GraphRAG — to handle the hidden connections that trip up standard AI. If a trial excludes "any drug interacting with CYP3A4 enzymes" and a patient is taking Drug B, a standard system might miss the connection if the patient's record never explicitly states that Drug B is a CYP3A4 inhibitor. Our knowledge graph contains that relationship. It traverses from patient to drug to mechanism to exclusion criteria, catching what text-matching cannot.
For the full technical methodology behind this architecture, see our detailed research.
What About the Privacy Question?
This is the first thing every pharma executive asks, and rightly so. Sending unstructured patient data to a public AI API is a non-starter under HIPAA and GDPR.
Our modular architecture addresses this directly. The knowledge graph and logic engine — the parts that touch actual patient data — stay within the hospital's secure environment. The language model can be deployed as a local, open-source model fine-tuned for medical extraction, running inside the same secure enclave. Protected health information never leaves the firewall, never trains external models, never touches a public API.
Does This Actually Replace Clinicians?
No, and it shouldn't. The goal is to scale the expert, not replace them. A site coordinator reviewing 100 AI-flagged candidates where 95 are genuinely eligible is in a completely different position than one reviewing 100 candidates where only 5 are real matches. The first scenario is augmentation. The second is a denial-of-service attack on their time.
High-confidence matches — where the logic is clear and the data is unambiguous — can be auto-processed. Low-confidence cases get routed to human review with all the relevant context pre-assembled. The clinician's judgment stays central. The AI just stops wasting it.
What This Means If You Run Clinical Operations
If you're in pharma operations, CRO leadership, or clinical informatics, the practical implications are straightforward:
Screen failure rates drop when your matching system understands medical hierarchies instead of just scanning for keywords. Fewer false positives means less wasted coordinator time and lower per-patient screening costs.
Regulatory risk decreases when every inclusion and exclusion decision comes with a complete, deterministic audit trail — not a probabilistic guess from a black box.
Competitive advantage compounds because the same drug, enrolled on time, captures market share that a six-month delay would forfeit permanently.
The bottleneck in drug development is no longer the science. We can design remarkable therapies. What we can't seem to do efficiently is find the right patients to test them on. That's a solvable problem — but only if we stop treating it as a text search and start treating it as what it actually is: a reasoning task.
I'd be curious to hear from anyone working on the operations side of clinical trials — are you seeing these matching failures in practice? What's your experience been with AI tools in recruitment?