Skip to main content

Clinical trial matcher: screen patients against trial eligibility criteria

The Clinical Trial Matcher turns a trial protocol into patient matching logic. It pulls eligibility text from ClinicalTrials.gov by keyword or NCT ID, or takes the protocol text you paste in, parses it into structured inclusion and exclusion criteria, and runs the computable ones against your OMOP patient database, reading clinical notes alongside structured fields. Every criterion reports its own matched count, and the validated patient set becomes a reusable cohort.

Clinical Trial Matching and Eligibility Screening

A sponsor asks whether your site can enroll 40 patients with HER2-low metastatic breast cancer, prior CDK4/6 inhibitor exposure, and ECOG performance status 0 to 1, within six months. Structured data answers "metastatic breast cancer." It does not answer HER2-low, because that reading sits in a pathology narrative, and it does not answer ECOG, because that sits in an oncology progress note.

A feasibility answer built from diagnosis codes describes a population that is larger on paper than in the clinic. The correction arrives months later, as a missed enrollment milestone.

Why trials fail to enroll patients who are sitting in the clinic​

Every figure below comes from a peer-reviewed study published since 2023. Two patterns run through all of it: the criteria that decide eligibility are rarely the ones recorded as codes, and the patients who would qualify are rarely the ones anyone screened.

19.3% of NCI-affiliated trials failed to accrue, and criteria text doubled

Across 1,197 phase II and III NCI-affiliated trials started between 2008 and 2018, 231 (19.3%) failed because of low accrual. Over the same decade the median eligibility criteria text grew from 214 to 417 unique content words. Accrual failure tracked that growth closely: 11.8% in the decile with the shortest criteria, 29.4% in the decile with the longest.

Peterson et al., Cancer Med 2023

7.1% of cancer patients enrolled in a treatment trial, and 4.1% where most are treated

Across 1,200 Commission on Cancer programs covering more than 70% of US cancer diagnoses, the treatment trial participation rate was 7.1%. The rate was 21.6% at NCI-designated comprehensive cancer centers and 4.1% at community programs, where most patients are actually treated. The paper notes this is higher than the historical estimate of under 5%.

Unger et al., J Clin Oncol 2024

Only 35.5% of a trial's eligibility criteria could be mapped to real-world data

A scoping review of 74 oncology target trial emulations found that emulations of real trials specified a median of 29 eligibility criteria and mapped a median of 35.5% of them (IQR 27.3% to 40.6%). Safety and concomitant-risk restrictions mapped least often, at 3.7%. Most emulations mapped criteria by hand using administrative codes.

Chen et al., BMC Med Res Methodol 2026

39.6% of patient-lines had no structured ECOG performance status

Across 480,825 patient-lines from 229,257 patients in a curated oncology database, structured ECOG performance status was available for only 60.4%. Applying NLP to the notes raised availability to 73.2%. Performance status gates eligibility in most oncology protocols, and in a general health system EHR the structured figure is likely to be worse than 60.4%.

Cohen et al., Applied Sciences 2023

Biomarker results were missing from 80% to 100% of structured extracts

In a study of NSCLC patients at an NCI-designated cancer center, biomarker values documented in the source EHR were missing from 80% to 100% of FHIR extracts. EGFR, KRAS, and BRAF were absent for every patient. Manual review of unstructured text recovered 10% to 50% of them. The cohorts were small, 10 and 20 patients, so read this as an illustration rather than a population rate.

App et al., JAMIA Open 2026

60% to 70% of real-world patients were ineligible for any trial in their own mutation class

Among 185 patients with metastatic KRAS G12C-mutated NSCLC at three academic centers, 60% to 70% were ineligible for every KRAS inhibitor trial available. The leading reasons were performance status (48.8%), renal function (37.2%), and active brain metastases (18%). Relaxing the renal and brain-metastasis thresholds raised the eligible pool by 25% with no survival detriment.

Wooster et al., J Natl Cancer Inst 2026

The arithmetic of site capacity explains the rest. Across 455 trials supporting FDA cancer drug approvals, the median trial ran at 92 sites and enrolled 330 patients in total, a median of 18 patients per month across the whole study (Michaeli et al., Target Oncol 2024). Divide those medians and a site contributes roughly three or four patients to an entire trial. At that scale, a handful of patients who were eligible and never screened is the difference between a site that accrues and one that does not.

Delay is expensive in a way that is now measurable rather than anecdotal. A peer-reviewed analysis of 645 drug launches and 409 trial budgets put a single day at approximately $500,000 in delayed prescription sales plus roughly $40,000 in direct cost to run a phase II or III trial (Smith et al., Ther Innov Regul Sci 2024). The authors wrote the paper specifically because the figures circulating in the industry were outdated and anecdotal, which is worth remembering whenever a larger number appears without a citation attached.

What the Clinical Trial Matcher compares: the protocol against the record​

Trial matching is a comparison between what a protocol requires and what a patient's record shows. Both halves need work before they can meet.

The protocol​

Eligibility text reaches the matcher three ways: a ClinicalTrials.gov keyword search, a direct NCT ID, or protocol text pasted straight in. Registry-sourced jobs carry the trial's metadata with them, so the NCT ID, title, phase, recruitment status, conditions, and the original eligibility text stay visible next to the parsed criteria. Parsing separates inclusion from exclusion and keeps each criterion's original wording alongside the parsed query, so a reviewer can always see what a criterion was derived from.

The record​

Execution runs against the OMOP CDM: condition_occurrence, drug_exposure, procedure_occurrence, measurement, observation, and note_nlp. Structured codes and facts extracted from clinical notes are evaluated in the same pass. Concept resolution through the JSL Terminology Server expands a criterion written at the class level into the full set of OMOP concept IDs beneath it, so a protocol that says "prior platinum-based chemotherapy" matches a patient recorded as having received carboplatin.

Why eligibility criteria are the hardest case for structured-only screening

Care gaps mostly turn on whether a test or a prescription happened. Trial eligibility turns on stage, performance status, biomarker results, prior lines of therapy, and response to previous treatment, and those facts are written in prose. The evidence above puts numbers on it: a median of 35.5% of criteria mappable to real-world data, ECOG absent from structured fields for 39.6% of patient-lines, and biomarkers missing from 80% to 100% of structured extracts.

That is why the matcher reads note_nlp evidence alongside structured records, and why the criteria it cannot evaluate are shown as such rather than quietly dropped. See the clinical data accuracy gap for the wider body of research on what structured fields miss.

How the Clinical Trial Matcher screens patients, step by step​

Screening runs in five steps: create a job from a trial or pasted protocol text, parse the eligibility text into structured criteria, select the criteria that are computable locally, execute them against the OMOP patient database, then review the matches and save them as a cohort.

1

Create the job from a trial or from pasted text

Search ClinicalTrials.gov by disease area, intervention, sponsor, or topic; enter a known NCT ID; or paste the eligibility section of a local protocol. Registry-sourced jobs fetch trial metadata and eligibility text automatically.

↓
2

Parse the eligibility text into structured criteria

The eligibility text is separated into inclusion and exclusion criteria. Each criterion keeps its ID, its parsed query text, the original source text where the two differ, and domain or concept information where available.

↓
3

Select the criteria that should define local screening

Review what was parsed and select the criteria that belong in the screening cohort. Criteria that are not computable from the data you hold, or that are not relevant to local screening, are cleared here rather than left to produce misleading counts.

↓
4

Execute the selected criteria against patient data

Selected criteria run as SQL against the OMOP patient database, evaluating structured records and NLP-extracted note evidence together. Each criterion reports its own matched patient count, execution status, and, for administrators, the generated SQL.

↓
5

Combine, review, and save as a cohort

Use the default flat selection or build grouped AND/OR logic in Query Builder, review the matched patients and their timelines, then save the validated set as a Cohort Builder cohort that feeds datasets, screening logs, and the feasibility answer.

What this workflow decides, and what it does not

The matcher produces a screened candidate list with the evidence behind each criterion. Final trial eligibility still requires protocol review and site-specific clinical validation, and the decision to approach a patient belongs to the study team and the treating clinician.

How to run a clinical trial match​

The six steps below follow one job from creation to a saved cohort. Each step names the tab or control it uses, so the walkthrough doubles as a reference once the workflow is familiar.

Step 1: Create the job​

Go to Agents and Tools > Clinical Trial Matcher and select Create Job. Three input modes cover the cases that come up.

Search by keyword

Use this when you know the disease area, intervention, sponsor, or topic but not the identifier. Search ClinicalTrials.gov, review the returned trials with their NCT ID, title, recruitment status, phase, and conditions, hover a result to inspect eligibility detail, then select the trial and create the job.

Enter an NCT ID

Use this when the trial identifier is known, for example NCT01234567. The system fetches the trial metadata and eligibility criteria from ClinicalTrials.gov directly. This is the fastest route when a sponsor has named the study.

Paste eligibility text

Use this for a protocol that is not on the registry, a local study, an amendment not yet published, or a specific eligibility section you want to test. Include both the inclusion and exclusion sections so the parser can preserve the protocol's intended structure.

Add a description when you create the job. Six months later, the difference between a job named after the trial and a job named after the question it was answering is the difference between reusing the work and redoing it.

Step 2: Confirm the trial, then review the parsed criteria​

The Trial Information section shows the NCT ID, title, phase, recruitment status, conditions, and the original eligibility text. Confirm the job is built on the protocol you meant before reading anything downstream, because a wrong NCT ID produces a clean-looking result for the wrong study.

Parsed criteria are grouped into Inclusion and Exclusion. Each criterion can carry:

  • Criterion ID
  • Parsed query text
  • Original source text, where it differs from the parsed version
  • Domain or concept information, where available
  • Execution status
  • Matched patient count

Expand a criterion to inspect its matching patients, and, for administrators, the generated SQL. Select the criteria that should define the local screening cohort and clear the rest. If parsing fails, check that the eligibility text is complete and readable, then use Retry Parsing.

Read the criteria before you read the counts

A criterion that returns zero patients has two very different explanations: nobody qualifies, or the criterion is not computable from the data you hold. A criterion that returns implausibly many usually means it parsed more loosely than the protocol intended. Both are visible at the criterion level and invisible in the combined total, which is why criterion review comes before cohort creation rather than after.

Step 3: Execute the queries​

Use Execute Queries to run the selected criteria. The execution modal lets you choose which unfinished criteria should run; criteria already running or completed are not queued again. Failed or pending criteria can be retried with Run Remaining or from the individual criterion's status action, so one failure does not cost you the whole job.

Execution results report total queries, completed and failed counts, patient counts per criterion, the final matched count for the selected criteria, and execution duration where available. The detail page updates while parsing or execution is active.

A job that finishes as Completed with errors executed successfully but had one or more criteria fail. Open it and inspect those criteria rather than reading the patient count as final.

Step 4: Combine criteria in Query Builder​

After execution, the Query Builder tab refines how the selected criteria combine, using grouped inclusion and exclusion logic with AND and OR operators. Only selected criteria with completed execution and generated SQL are available there.

Drag criteria between groups, drop one into the new-group area to create a group, add or remove groups, change the operator within a group and between groups, or use Reset to return to the default layout. The patient count recalculates as the configuration changes.

Query Builder earns its place when a protocol allows alternative paths to eligibility. A trial that accepts either prior platinum therapy or prior immunotherapy, in patients who meet a shared set of organ function thresholds, is two OR-grouped inclusion paths joined by AND to the common requirements. A flat selection would require all four and quietly discard most of the eligible population.

When the flat selected-criteria count on the Criteria tab differs from the saved grouped logic, the Criteria tab shows a warning. The Query Builder count is the one to validate against, and the combined patient list should be reviewed again after any change to the grouping.

Step 5: Review the patients found​

The Patients Found tab lists the patients matching the selected criteria or the grouped configuration, with identifiers and demographic fields such as age, gender, race, ethnicity, and diagnosis detail where the data supports them. Hover a row to see which criteria matched. Click a row to open the patient timeline for record-level review.

Sample the timelines before you trust the list. A screening list that has never been opened at the patient level is a hypothesis, and the study team will find out which kind it was during screening visits.

Step 6: Create the cohort​

Use Create Cohort once the job is complete and at least one selected criterion has matching patients. The cohort opens in Cohort Builder with the trial job as the base candidate set. Review the cohort name, the selected patients, and the filter summary before saving, and name it after the trial or the study objective so it is still legible to someone else next quarter.

Once saved, the cohort feeds the rest of the platform: dataset creation for the study team, patient review, registry work, and analysis. Screening, the dataset, and the feasibility answer then all rest on one stated definition instead of three hand-built lists.

Managing trial matching jobs: statuses, caching, and reruns​

The Clinical Trial Matcher landing page lists previous jobs with name, status, progress, selected criteria against parsed criteria, matched patient count, creation time, and actions. Statuses run pending, parsing, parsed, executing, completed, failed, and Completed with errors.

Narrow the list with search together with the Status, Created, and Tags filters, sort the supported columns, paginate, mark jobs as favorites, and use the global favorites-only filter. Deleting a job requires confirmation.

When a job is created for an NCT ID that already has completed results, the system may reuse the earlier run and shows a banner saying so. Reuse is the right default for a repeated feasibility question. Use Run Fresh when the patient data has been reloaded since, when the protocol has been amended, or when the matching logic has changed, since a cached answer to a superseded protocol is worse than no answer.

Which eligibility criteria still require a human reviewer​

Automation handles criteria that turn on a documented fact: a coded diagnosis, a lab value, a recorded medication, a biomarker result written in a note. Criteria that turn on inference about behavior, adherence, or social circumstances belong to the study team, and the published evidence on screening bias explains why.

Automated screening is not neutral on every criterion

Across 58 trial protocols and 5.3 million evaluations using nine language models, eligibility judgments were largely stable across patient identities, and explicit eligibility criteria were applied consistently. Disparities appeared in the domains that require inference about behavior or resources rather than reading a documented fact, where housed status produced the largest negative shift in eligibility judgments (Soffer et al., J Am Med Inform Assoc 2026).

This is the reason criterion selection and patient review are steps in the workflow rather than optional finishing touches. A criterion that turns on a documented lab value, a coded diagnosis, or a recorded medication is the kind automation handles well. A criterion that turns on whether a patient is likely to comply, attend, or tolerate is a clinical judgment, and it belongs to the study team.

The same applies to criteria the data cannot answer. When a criterion is not computable from what you hold, record that it was excluded and say so when you report the count. A feasibility number is only interpretable against a stated definition, and a protocol clause dropped in silence is the one that surfaces during screening visits.

Troubleshooting trial matching results​

Most surprising results trace back to one of six causes: the search returned nothing, the job was built on the wrong NCT ID, parsing lost the protocol's section structure, a criterion is not computable from the data you hold, a criterion failed to execute, or the combination logic is flat where the protocol allows alternatives.

No trials returned by search

Broaden the keyword, or search by condition name, intervention name, or sponsor instead of trial topic. When the identifier is known, enter the NCT ID directly rather than searching for the title.

Trial metadata looks wrong

Confirm the NCT ID against ClinicalTrials.gov before going further. Everything downstream inherits the protocol the job was built on, and a wrong identifier produces a result that looks entirely healthy.

Parsing failed

Confirm the eligibility text is complete and readable and contains clearly delimited inclusion and exclusion sections, then use Retry Parsing. Text pasted from a PDF often loses the section structure the parser relies on.

A criterion returned zero patients

Check whether the criterion is computable from the data you hold before concluding that nobody qualifies. Performance status, biomarker results, and prior therapy lines frequently return zero because the fact lives in a note type that has not been ingested.

A criterion failed to execute

Expand the row to inspect the error, then retry that criterion on its own rather than re-running the job. Narrowing the selected criteria often isolates the one that is failing.

The patient count looks implausible

Too high usually means the exclusion criteria were not selected or not executed. Too low usually means criteria parsed more narrowly than the protocol intended, or that a flat AND selection needs grouped logic in Query Builder.

Before a cohort is saved or shared for operational use, open a sample of patient timelines. It is the cheapest check available and it catches the failures that counts alone conceal.

Who uses clinical trial matching, and for what​

Trial matching serves four roles at a research site or sponsor: research coordinators prescreening before screening visits, feasibility teams answering a sponsor's capacity question, principal investigators judging whether a protocol is enrollable locally, and sponsors or CROs testing a criterion's effect on the eligible population before the protocol is finalized.

Research coordinators and study teams

Prescreen the local population against a protocol before screening visits begin, work from a candidate list with criterion-level evidence attached, and re-run against amended criteria without restarting chart review.

Feasibility and site selection

Answer a sponsor's capacity question from the full record rather than diagnosis codes, so the enrollment commitment reflects the population that exists in the clinic. Save the cohort so the same definition backs the answer and the screening log.

Principal investigators

Assess whether a protocol is enrollable locally before agreeing to it, and see which specific criteria are doing the excluding. Where those criteria are modifiable, that evidence is what a protocol amendment conversation needs.

Sponsors, CROs, and clinical operations

Evaluate the effect of a criterion on the eligible population before the protocol is finalized, and compare candidate criteria sets against real patient data rather than against assumptions about them.

Security, compliance, and deployment options​

The Clinical Trial Matcher runs inside your environment. Patient data is never transmitted to an external service; the only outbound request fetches public trial metadata from ClinicalTrials.gov, and air-gapped deployments replace that with pasted protocol text.

Data never leaves your environment

Matching runs inside your deployment. Trial metadata is fetched from ClinicalTrials.gov, a public registry; patient data is never sent anywhere. Data handling meets the HIPAA Privacy and Security Rules and GDPR Article 25 data protection by design.

Inspectable logic at every step

Original eligibility text, parsed criteria, per-criterion matched counts, grouped query configuration, and generated SQL for administrators. A disagreement about a patient list becomes a disagreement about a stated criterion.

Role-based access control

Field-level RBAC scopes what coordinators, analysts, and administrators see. Job sharing is available only to users who hold permission to share that job, so a screening list does not travel further than intended.

Human review before action

Criteria selection and patient review are steps in the workflow, not optional ones. Final eligibility requires protocol review and site-specific clinical validation, and the approach to a patient stays with the study team and the treating clinician.

Deployment options

Runs on-premises, on AWS, Azure, Databricks, or Snowflake, and in air-gapped environments, where registry metadata can be supplied as pasted protocol text instead of fetched.

Open standards throughout

OMOP CDM v5.4 for patient data, FHIR R4 for interoperability, and SNOMED CT, LOINC, RxNorm, ICD-10, and CPT for concept standardization. No proprietary format anywhere in the pipeline.

Where to go next​

The Clinical Trial Matcher is a Patient Journey Intelligence agent that turns a clinical trial protocol into executable patient matching logic. It fetches trial metadata and eligibility text from ClinicalTrials.gov by keyword search or NCT ID, or accepts pasted protocol text, parses the text into structured inclusion and exclusion criteria, executes the computable criteria as SQL against the OMOP patient database including facts extracted from clinical notes, and saves the validated patient set as a reusable cohort.

Yes. Paste the eligibility criteria text directly when creating the job. This covers local protocols, investigator-initiated studies, amendments not yet published to the registry, and any case where you want to test a specific eligibility section. Include both the inclusion and exclusion sections so the parser preserves the protocol's intended structure.

Criteria are executed against the OMOP CDM with structured records and NLP-extracted note evidence evaluated in the same pass, so facts such as performance status, biomarker results, and prior lines of therapy are available to matching when they were documented in narrative text. This matters because published research finds a median of only 35.5% of a trial's eligibility criteria mappable to real-world data, structured ECOG performance status missing for 39.6% of patient-lines, and biomarker results missing from 80% to 100% of structured extracts.

They are visible as parsed criteria with their execution status and matched count, so you can see them and decide. Clear them from the selection rather than leaving them to produce a misleading zero, and record which clauses were excluded when you report the result. A criterion that returns zero because the data cannot answer it looks identical to one that returns zero because no patient qualifies, and only the criterion-level view separates the two.

Use Query Builder when the protocol allows more than one path to eligibility. The default flat selection requires every selected criterion, which is correct for a protocol whose inclusion criteria are cumulative and wrong for one that accepts alternatives. Query Builder supports grouped inclusion and exclusion logic with AND and OR operators, and recalculates the patient count as you change the configuration.

No. It produces a screened candidate list with the evidence behind each criterion attached. Final trial eligibility requires protocol review and site-specific clinical validation, and the decision to approach a patient rests with the study team and the treating clinician. Criteria that require judgment about behavior, adherence, or tolerance are exactly where automated screening is least reliable, which published research on sociodemographic bias in language-model screening confirms.

The published evidence is specific about what works. A randomized trial of 4,476 patients found AI-assisted prescreening identified a 20.4% eligibility rate against 12.7% for manual screening, with screening still incomplete for 887 patients in the manual arm against 37 in the AI-assisted arm. A separate randomized trial found that AI-detected progression triggering clinician notifications did not change enrollment (2.20% vs 2.03%, P = .41). Automating the prescreening labor changed outcomes; an alert on its own did not.

Execution finished but one or more criteria failed. Open the job and inspect those criteria before treating the patient count as final, since a failed criterion is simply absent from the combination rather than flagged in the total. Failed and pending criteria can be retried individually or with Run Remaining, without re-running the whole job.

Cached reuse is right for a repeated feasibility question against unchanged data. Use Run Fresh when patient data has been reloaded since the cached run, when the protocol has been amended, or when the matching logic has changed. The job detail page shows a banner whenever results were reused, so you always know which you are looking at.

No. The Clinical Trial Matcher runs entirely inside your deployment - on-premises, on AWS, Azure, Databricks, or Snowflake, including air-gapped environments. Trial metadata is retrieved from ClinicalTrials.gov, which is a public registry containing no patient information; patient data is never transmitted to any external service. In an air-gapped deployment, protocol text can be pasted in rather than fetched.