Clinical trial patient recruitment: how EHR screening fixes the top of the funnel

The scene repeats at research sites everywhere. A coordinator hand-screens charts between clinic sessions, hunting eligible patients one record at a time. A site that swore during feasibility it saw these patients every week is six months into the study with a fraction of its projected enrollment. Then comes the sponsor call nobody wants to take. A late trial bleeds money by the day: the Tufts Center for the Study of Drug Development pegs a single day of delay at roughly $500,000 in unrealized prescription drug sales, plus about $40,000 a day in direct trial costs (Smith, DiMasi and Getz, 2024).

Against numbers like that, the standard recruitment stack (flyers, physician referrals, more coordinator hours against the chart backlog) is not a strategy. It's a hope.

Yet for most trials, the eligible patients already exist, documented in detail, inside the EHRs of the very health systems hosting the study. Recruitment is largely a findability problem, and findability is what computational phenotyping solves: turning a clinical definition of a patient into a query you can run against EHR data at scale. The concept itself is covered in our primer on computational phenotyping and EHR patient cohorts (Part 1); this post focuses on the highest-value application we know of, the top of the trial recruitment funnel.

Why is clinical trial recruitment so broken?

Because the default screening method is a human reading charts one at a time, and the funnel math is brutal. Manual prescreening runs 15 to 20 minutes per chart, so a coordinator gets through a few dozen a day at best; a complex protocol with fifteen inclusion/exclusion criteria might qualify one patient in several hundred reviewed. Multiply those and you get the industry's dismal site statistics.

In a 2013 Tufts CSDD analysis of more than 150 trials and roughly 16,000 investigative sites, 11% of activated sites enrolled zero patients and another 37% under-enrolled (Tufts CSDD, 2013): nearly half of all sites failing to deliver, after the sponsor paid to select, contract, and initiate each one. Tufts' 2024 benchmarking update shows enrollment performance improving overall, with wide variation remaining by region and site type, so the shape of the problem persists even where the averages have moved.

The failure compounds upstream, too. Sites get chosen on investigator questionnaires ("How many patients like this do you see?"), and investigators reliably overestimate, because they remember patients by clinical impression, not by exact lab thresholds and washout windows. Sponsors discover the shortfall six months in, when every option is expensive.

Recruitment doesn't break at the point of consent. It breaks earlier, at identification, and identification is the part software does well. Software can read every chart in the system every night. No coordinator can.

How does automated eligibility screening against EHR data actually work?

You translate the protocol's inclusion and exclusion criteria into computable phenotypes (queries and models that run against EHR data) and let the system produce a ranked list of probably-eligible patients for coordinators to confirm. In practice that translation has two layers, because eligibility criteria live in two different parts of the record.

Unstructured criteria are where trials get hard, because protocols routinely hinge on facts that never get coded: ejection fraction buried in an echo report, tumor staging in a pathology note, "ambulatory without assistance," prior treatment failure described in free text. That's an NLP problem, and one of the most consequential applications of natural language processing in healthcare. Clinical language models have made this layer dramatically better in recent years, but the architecture that works in production is still the combination: structured rules for what's coded, NLP for what's narrative. (For the fuller set of methods, see the algorithm approaches post (Part 2); we won't restate it here.)

The useful output isn't a binary eligible flag. It's a prioritized worklist: patients ranked by likelihood of eligibility, with the evidence for each criterion attached (the lab value, the note excerpt), so a coordinator confirms in minutes what used to take a twenty-minute chart dive.

The whole pipeline is a narrowing funnel, with the automated layers tuned to keep every plausible candidate in play until a human confirms:

Should you tune prescreening for precision or recall?

Recall. Tune the automated layer for sensitivity, accept the false positives, and put human review behind it, because the two error types have wildly asymmetric costs.

A false positive costs a coordinator a few minutes of confirmation. A false negative is an eligible patient who, as far as your trial is concerned, never existed. In a rare-disease or oncology study, that missed patient may be one of forty in the entire health system.

This inverts the instinct most teams bring from other ML applications, where precision is the headline metric. In prescreening, a system that's 95% precise but misses a third of eligible patients is quietly worse than one that's 60% precise and catches nearly all of them. The design problem is really queue economics: set the threshold so confirmation workload matches coordinator capacity, then make each confirmation fast, with evidence inline, criteria pre-checked, and one click to flag for outreach.

The human-review step isn't a concession to imperfect models, either. Coordinators catch context no phenotype encodes: the patient who moved away, the one already in a competing study. The system's job is to make sure humans spend judgment on plausible candidates instead of hours on chart archaeology.

Can the same phenotypes fix site feasibility?

Yes, and for sponsors and CROs this may be the more valuable use, because it moves the intelligence ahead of the spend. The same eligibility logic that screens patients prospectively can run retrospectively against a site's historical EHR data to answer the question investigator surveys answer badly: how many patients meeting these exact criteria does this site actually see, at what rate?

Feasibility counts built this way replace unsupported patient estimates with measured evidence: what the site's data support today, with the assumptions that turn documented eligibility into projected enrollment stated, not implied. A sponsor can test protocol criteria against real data before finalizing them, and discover cheaply that tightening one lab threshold cuts the eligible population by 60% while a criterion everyone argued about barely moves it. That conversation costs a query before launch and a rescue plan after.

Health systems benefit symmetrically. A research office that can produce a credible eligible-patient count in days walks into site selection with evidence instead of estimates, and has a defensible basis for declining trials it would under-deliver. Counting before committing is the cheapest fix in clinical operations.

One honest caveat: counts are estimates of documented eligibility, not of consentable patients. Good feasibility reporting states its funnel assumptions (documented-eligible, to approachable, to consented) rather than presenting a raw count as an enrollment forecast.

What are the compliance guardrails?

The short version: prospective screening means identifiable PHI, which means IRB oversight, a defined access model, and usually an honest-broker pattern. A designated team or system queries identified records and releases identities only to IRB-authorized personnel, typically routing outreach through the patient's own care team. Feasibility counting can often run on de-identified data, which generally falls outside IRB oversight, or under HIPAA's preparatory-to-research provision where your institution allows it, one more reason to treat it as a separate workflow. Log every access, query, and disclosure from day one; your IRB and privacy office will ask.

None of this should stop a build. It should shape one: design governance in from the start rather than bolting it on later, the pattern that sinks most healthcare apps on HIPAA compliance. We go deep on consent models, data flows, and honest-broker architecture in the phenotyping compliance and PHI governance post (Part 5); if you're scoping a build, read that next.

What does building this with a dev partner look like?

Smaller than you'd think, if it's scoped as a workflow and not a platform. The builds that succeed follow a consistent shape: start with one protocol, translate its criteria into computable form with the study team in the room (ambiguous criteria get resolved with the PI, not guessed at), stand up the structured-data layer first, add NLP only where the protocol demands it, and ship the coordinator worklist early so the review loop generates validation data from week one. Measure against a chart-review gold standard, publish sensitivity numbers, then generalize to the next protocol.

The hard parts are rarely the models. They're EHR data access, identity and audit plumbing, coordinator workflow fit, and keeping the system running when the protocol amends. That unglamorous production work is what turns the pipeline into something coordinators can rely on daily, and it's its own discipline.

It's also what we do at Digital Scientists: healthcare-native product engineering, from the FHIR integration to the phenotype logic to the screen a coordinator uses every day. If enrollment is blowing your timelines, the top of your funnel is sitting in an EHR right now, findable.