A clinical trial eligibility criterion looks like a simple logical proposition. "ECOG performance status of 0 or 1." "Adequate renal function as defined by creatinine clearance greater than or equal to 50 mL/min." "No prior treatment with a PARP inhibitor." Each of those statements appears to be directly checkable against a patient record.
In practice, matching a patient against a protocol's full eligibility section is an exercise in navigating layered complexity. The surface proposition is simple. The data requirements, interpretation questions, and edge cases beneath it are not. This post is about what the matching problem actually looks like from an engineering and clinical informatics perspective, because the gap between what it looks like and what it is has real consequences for how patient-matching tools should be built.
The Structure of a Criterion
Every eligibility criterion, when you break it apart, has at least three components: a clinical concept, a qualifying condition, and often a temporal anchor.
The clinical concept is the thing being measured or checked: a diagnosis, a lab value, a therapy, a procedure, a patient characteristic. The qualifying condition is the logical statement about that concept: the lab must be above a threshold, the therapy must have been received or not received, the diagnosis must be present or absent. The temporal anchor is when: the diagnosis must be current, the lab result must be within 28 days of screening, the therapy must have been completed at least six months before enrollment.
Some criteria have all three components in a single sentence. Some distribute them across multiple clauses. Some leave the temporal component implicit, defaulting to "at screening" or "in history" depending on clinical convention rather than explicit protocol language. A matching system has to correctly identify all three components before it can evaluate a criterion against patient data.
Where the NLP Problem Lives
The criterion extraction problem, parsing a protocol document to identify and structure the individual criteria, is a natural language processing challenge with its own complexity. Protocols are not written to a consistent format. Different sponsors and writing teams use different conventions. Criteria that belong logically together are sometimes split across numbering schemes. Compound criteria, where a single numbered criterion contains two or three distinct conditions, are common.
Negation is one of the most consequential parsing challenges. "No prior treatment with X" and "prior treatment with X is required" look syntactically similar, but a parsing error that conflates them produces an eligibility determination that is exactly wrong. Negation scope, which words in a sentence fall under the negation modifier, is a known difficulty in clinical NLP and remains an active research area.
Temporal qualifier parsing has its own challenges. "Within 6 months of study entry" requires knowing the enrollment date, which does not exist at pre-screening time. "At least 12 months prior to screening" requires precise date data from the patient record. "No active" versus "no history of" are different temporal scopes that affect which patient records are relevant to the criterion evaluation. Getting these distinctions right requires more than keyword extraction. It requires a semantic representation that captures the relationship between the temporal qualifier and the clinical concept.
The Data Retrieval Problem
Once a criterion has been correctly parsed and structured, the next challenge is retrieving the relevant data from the patient record to evaluate it. This is where the EHR data heterogeneity problem becomes central.
For a criterion like "adequate renal function as defined by creatinine clearance greater than or equal to 50 mL/min," the matching logic needs a recent creatinine clearance or serum creatinine value from which it can be calculated. That value may exist as a discrete lab result with a standard LOINC code, which is queryable through a structured API. Or it may be documented in a progress note as a narrative value. Or it may be absent from the local EHR because the relevant labs were drawn at an outside institution. The retrieval logic has to handle all three cases, including the last one, which means the system has to represent data absence as a distinct state rather than defaulting to a passing or failing determination.
Prior therapy history is the hardest retrieval problem in oncology and in many other indications. Medication order records in EHRs typically capture currently and recently prescribed medications well. They are inconsistent for therapies received at other institutions, for therapies administered in clinical trials that are recorded separately from routine clinical documentation, and for historical therapies that predate the patient's relationship with the current institution. Free-text notes often contain the most complete prior therapy histories, which means the matching system has to run structured extraction from unstructured text to retrieve information that should ideally be in a queryable structured field but often is not.
Interpretation at the Criterion Boundary
Even with perfect data retrieval, some eligibility determinations require clinical judgment that cannot be fully automated. This is not a failure of the technology. It is a property of the medical knowledge the criteria are encoding.
Consider a criterion that excludes patients with "clinically significant cardiac disease." What counts as clinically significant is a judgment call that depends on the clinical context, the severity of the condition, and how it is managed. Two investigators might reach different conclusions about the same patient. Automated matching can flag the relevant information, but the determination requires a clinician. A well-designed matching system makes that boundary explicit: here is the relevant information, here is the criterion, this one needs PI review.
Criteria that reference drug classes rather than specific agents introduce a categorization problem. "Prior treatment with any antiangiogenic agent" requires knowing which drugs belong to that class, which is a knowledge base problem on top of the data retrieval problem. Class membership can be ambiguous for drugs with multiple mechanisms of action, and different protocols may draw class boundaries differently.
We are not saying these interpretation problems are unsolvable. We are saying that a matching system that presents binary pass/fail results without flagging where human review is needed is providing false confidence. The correct architecture distinguishes between criteria the system can evaluate with high confidence from available structured data, criteria that require extraction from unstructured sources with associated uncertainty, and criteria that require clinical judgment regardless of data completeness.
The Precision-Recall Tradeoff in Pre-Screening
Patient matching for pre-screening is an application where the cost asymmetry between false positives and false negatives is important to understand explicitly.
A false negative, a patient who passes the matching filter but would actually fail a criterion on closer inspection, wastes coordinator time during the detailed review step and, if not caught before formal screening, wastes patient time and creates a screen failure. False negatives have direct costs.
A false positive, a patient who fails the matching filter but would actually have been eligible, is a missed enrollment opportunity. The patient never gets evaluated, so the cost is invisible. It does not appear in any screen failure metric. It appears only as a gap between actual and achievable enrollment rate, which is hard to measure.
Most pre-screening tools, and most manual pre-screening workflows, are calibrated toward minimizing false negatives. They include anyone who might be eligible. The practical consequence is that the candidate list sent to coordinators for review is inflated with patients who will be ruled out quickly on detailed review, which absorbs coordinator time.
A well-calibrated matching system tries to push that burden back earlier, distinguishing between patients who clearly pass, patients who clearly fail, and patients in the uncertain middle who warrant manual review. The goal is not zero false negatives; that would require including everyone. The goal is a candidate list where the high-confidence positives come first, the uncertain cases are flagged with specific reasons, and the clear disqualifications are filtered out before they consume coordinator review time.
What This Means for Tool Design
Matching tools that present eligibility as a simple pass/fail are almost always hiding complexity that gets surfaced later, either at the coordinator review stage or at formal screening. The complexity does not disappear because the interface does not show it. It gets displaced to a more expensive point in the process.
The design decision we made early in building Enrollvue was to expose the matching rationale, not just the result. A coordinator looking at a candidate list should be able to see which criteria the system evaluated with high confidence, which criteria it was uncertain about and why, and which criteria require clinical judgment that the system cannot provide. That transparency is more useful than a clean-looking score, even if it makes the interface feel more complicated. The complexity is real. The tool's job is to make it navigable, not to hide it.