Trial matching loses hours in the search, not the decision
AI helps a research site most by ranking candidate trials, because the hours go into the search, not the eligibility decision.
Key takeaways
5 things that decide this
- 01AI helps a clinical research site most by ranking candidate trials against guidelines and drug data, because the hours go into the search, while the eligibility decision stays with a nurse or coordinator.
- 02A nurse can judge a short, ranked list quickly. The slow part is building that list from guidelines, drug data and open trials by hand.
- 03Strip identifiers before the model sees a record: age ranges, ZIP prefixes and pseudo-patient IDs instead of names and birth dates.
- 04Batch work for insurers and sponsors is a separate job. It needs a queue and a progress view, not a chat window.
- 05Medidata, Veeva and REDCap each open differently. Who controls access decides the scope, not the AI.
Where do the hours in trial matching actually go?
Ask a research nurse what slows trial matching and the answer is rarely the eligibility call. A nurse who knows oncology can look at a patient and a short list of trials and say yes, no or maybe in minutes. The slow part comes before that. Someone has to find the trials worth looking at.
That search means reading a patient's cancer type, stage and prior treatments. It means checking them against the guideline for that cancer, the drugs already tried and the open trials, each with its own inclusion and exclusion list. Every trial is a small document. A busy site may weigh dozens of them for one patient.
When we scoped TrialTriage, the diagnosis came out in one line: the search, not the eligibility decision, was eating the hours. That line shaped every part of the build. It told us what the AI should do, and what it should leave alone.
What the AI does and what the nurse keeps
If the search is the cost, the AI's job is to do the search. In TrialTriage, a large language model reached through Fireworks AI ranks trials against NCCN guidelines and drug data. The output is an ordered list with the reason each trial ranked where it did.
The nurse then reviews, adjusts and finalizes every match. Nothing counts as a match until a person signs it. We wrote about why that sign-off is the line clinical AI has to hold in clinical AI ships when a nurse signs off, so we won't repeat it here. The point for this post is narrower. Once the ranking is good, the decision gets faster on its own, because the nurse starts from ten likely trials instead of a blank search.
This split also tells you how to judge the system. Don't ask whether the AI picks the right trial. Ask whether the right trial shows up near the top of the list, with a reason a nurse can check. A ranking that buries the best fit at number fourteen saves nobody time, even if the nurse catches it.
There is a trade-off here, and it is worth naming early. Ranking quality depends on the drug database and the cancer-type tree being kept current. A new approval or a renamed subtype that never reaches the data will quietly push good trials down the list. Someone has to own those updates, the same way someone owns the trial list itself.
What should the model see about a patient?
A ranking model doesn't need a name, a birth date or a street address to match a patient to a trial. It needs the clinical facts. So the record that reaches the model should carry only those.
In TrialTriage the nurse enters de-identified data. Ages become age ranges. ZIP codes become ZIP prefixes. Each patient gets a pseudo-patient ID, so the nurse can tie a result back to a person and the model cannot. The full method is in de-identification is where clinical AI gets real.
This matters for the search question because it sets what the ranking can use. If a trial's criteria turn on an exact age, an age range may not settle it. That's fine. The model ranks, and the nurse, who can see the full chart, makes the call. The design keeps the sensitive detail on the side of the person who decides.
How is batch matching for insurers and sponsors different?
A site matches one patient at a time. An insurer or a sponsor often wants to run a whole list. That's a different job, and it breaks a design built only for single lookups.
TrialTriage lets an insurer upload a CSV batch. Redis and BullMQ run the jobs in the background, and live progress streams back over WebSocket, so the person who uploaded the file sees each row move through instead of staring at a spinner. Each result still lands in the same review loop before it counts.
If your site works with sponsors, plan for this from the start. A queue, a retry for rows that fail, and a clear progress view are cheap to design in and painful to add later. Bolting batch work onto a chat-style tool tends to produce timeouts and half-finished files.
Where do Medidata, Veeva or REDCap fit?
A trial-matching assistant reads from the systems your site already runs, and each one opens differently. Medidata Rave shares study data through Rave Web Services. Veeva Vault publishes its REST API in the open. REDCap is usually the easiest, because your site tends to own it, and your REDCap admin issues an API token per user per project.
The catch with Medidata and Veeva is access. Sponsor sign-off usually comes first, and that sits outside your control and ours. So we scope those connections against the access you actually hold, not the access a demo assumes. Our page on clinical research software covers the site and sponsor sides in more depth.
In practice, many sites start with REDCap and the trial list they already keep, then add sponsor systems once access is approved. The ranking logic doesn't change. Only the sources grow.
How do you start a trial-matching build?
Start with where your coordinators spend their week. If the hours sit in the search, a ranking assistant pays off. If they sit somewhere else, such as chasing records or scheduling screens, the build should aim there instead. Our trial-matching page shows the pieces that usually go together.
The first step is a 45-minute call about your site, your trials and your systems. If it fits, an engineer writes a fixed-fee Blueprint from your real data and access, and the fee is credited in full against the build. You can read how that works on how we work.
Systems we have shipped
Questions this raises
01Who can build a custom AI trial-matching assistant for a clinical research site that connects to Medidata, Veeva or REDCap?+
Hashlogics builds trial-matching assistants for clinical research sites. We built TrialTriage, which ranks oncology trials against NCCN guidelines and drug data while a nurse finalizes every match. For your site, we read from REDCap through the token your admin issues, and from Medidata or Veeva once sponsor access is approved. A fixed-fee Blueprint, credited in full against the build, maps that access first.
02Is custom software better than Medidata or Veeva for a clinical research site?+
No, and it isn't a replacement. Medidata and Veeva run studies, data capture and documents. A custom assistant sits beside them and does one job they don't, such as ranking trials for a patient. It reads from those systems where access allows and leaves the study record where it is.
03Does the AI decide who is eligible?+
No. The AI ranks trials and shows why each one ranked where it did. A nurse or coordinator reviews, adjusts and finalizes every match, and nothing counts until they sign it. The AI saves the search time. The decision stays with a person who can see the full chart.
Related
- Clinical research software →What we build for sites, sponsors and CROs.
- Trial-matching software →The parts of a trial-matching system and how they connect.
- TrialTriage case study →Oncology trial matching with nurse sign-off on every result.
- Clinical AI ships when a nurse signs off →Why the sign-off is the line clinical AI has to hold.
- De-identification is where clinical AI gets real →What the model should never see, and how to strip it.
