Open any Phase II protocol from the last decade and turn to the eligibility criteria section. What you'll find is prose: carefully worded paragraphs of clinical English that describe the patient population a sponsor intends to study. Those criteria are the product of extensive clinical thought — indication-specific, sometimes negotiated with the FDA, always the result of deliberate decisions about scientific validity and patient safety. They are also, from a data systems perspective, opaque text that every downstream tool must independently re-interpret.
That re-interpretation happens at least four times in a typical trial: at feasibility (when a CRO estimates eligible patient volume), at the site level (when coordinators screen patients from charts), during electronic data capture (when eClinical systems enforce eligibility logic), and in post-enrollment audit (when monitors verify that enrolled patients met criteria). Each re-interpretation is a potential divergence point. The same criterion — "diagnosis of Type 2 diabetes mellitus for at least 24 months prior to screening" — can be interpreted as requiring a coded ICD-10-CM diagnosis of E11 dating back 24 months, or as any documented clinical reference to T2DM in that timeframe, depending on who is reading it and what data they have access to.
The Gap Between Protocol Language and EHR Reality
Inclusion and exclusion criteria are written to describe a clinical population, not to define an EHR query. This is not a design flaw — it is a reflection of the criteria's primary purpose, which is scientific and regulatory, not informatic. But it creates a systematic gap when those criteria need to be translated into structured queries against patient records.
Consider a common cardiometabolic inclusion criterion: "HbA1c between 7.5% and 10.0% at screening, measured within 90 days of the screening visit." Translating this to an EHR query requires knowing which LOINC code maps to HbA1c (LOINC 4548-4 for HbA1c/Hemoglobin.total in Blood by calculation is the most common, but LOINC 17856-6 and LOINC 59261-8 are also used depending on the measurement method), what units the health system stores results in, and how to define "90 days prior to screening" when the screening visit hasn't happened yet. Each of these translation steps involves a judgment call. Different people make different calls, producing different cohort lists from the same underlying patient population.
Exclusion criteria introduce additional complexity. "No prior treatment with GLP-1 receptor agonists" requires querying RxNorm drug codes across the semaglutide, liraglutide, dulaglutide, and exenatide families — and also checking that the criterion applies to prior treatment, not concurrent treatment, which may require a temporal query across the patient's medication history rather than their current medication list.
What Structured Criteria Actually Look Like
Structured criteria are protocol eligibility requirements expressed in a machine-readable format that maps directly to EHR data fields. At the most straightforward level, this means translating each criterion to a set of coded clinical terms with explicit logic operators: the diagnosis code to check, the value range to evaluate, the time window to apply, and the Boolean combination required across criteria.
A structured representation of the HbA1c criterion above might look like:
INCLUDE IF:
Observation.code IN [LOINC:4548-4, LOINC:17856-6, LOINC:59261-8]
AND Observation.valueQuantity.value BETWEEN 7.5 AND 10.0
AND Observation.valueQuantity.unit = '%'
AND Observation.effectiveDateTime WITHIN 90 DAYS BEFORE screening_dateThis is not a query a sponsor's clinical team writes — it is a translation of the clinical criterion into a form that a matching system can evaluate deterministically against an FHIR R4 Observation resource. The clinical meaning is preserved; the ambiguity is resolved.
The structured criteria library concept takes this further: for frequently-occurring criteria patterns across common indications (T2DM staging, NYHA heart failure classification, eGFR ranges for renal exclusions, ECOG performance status), pre-parsed structured representations reduce the per-protocol translation work and ensure terminological consistency across programs. See the protocol matching engine overview for how these structured representations are built and validated.
The Screen-Fail Cascade That Free-Text Criteria Creates
A mid-size CNS-focused CRO running a Phase II major depressive disorder trial in late 2024 observed a pattern that illustrated the downstream cost of free-text criteria precisely. Their protocol included the exclusion criterion: "Current use of any prohibited concomitant medication within 2 weeks of screening." The prohibited medication list was defined in an appendix. Site coordinators applied this criterion inconsistently — some checking the current medication list, others reviewing the 30-day medication history, a few checking only medications the patient self-reported at the screening visit. Across 11 sites, this single criterion was the most common source of screen failures that were later re-evaluated as eligible on monitor review.
The issue was not that the criterion was poorly written — the clinical intent was clear. The issue was that the data source and time window were not specified, which meant each coordinator made independent assumptions. In aggregate, those assumptions produced a screen-fail rate on this criterion that was 15–20 percentage points higher than what a structured query against the medication history with a defined 14-day lookback would have produced.
We're not saying that structured criteria eliminate screen failures — they don't. Patients fail screening for legitimate clinical reasons. What structured criteria eliminate is the interpretation-variance component of screen failures: the patients who were screened out because a coordinator used a different data source than was intended, not because they actually didn't meet the criterion.
The Protocol Design Question: When Should Structuring Happen?
Structured criteria are most effective when they're created close to the time of protocol finalization, before site activation. At that stage, the clinical team can review the structured translation and confirm that the coded representation matches the intended clinical meaning. After sites have activated and begun screening, changing the structured translation — even to correct a mistranslation — creates a protocol amendment risk and may require IRB notification.
The practical implication is that structured criteria design is not just a technology function — it requires clinical team engagement at the protocol stage. A clinical operations lead reviewing the structured representation can catch potential issues before they become screen-failure patterns: the criterion that doesn't account for pediatric age ranges, the lab value that's documented in different units at different sites, the concomitant medication class that has changed since the protocol was written.
This doesn't require the clinical team to write code or understand LOINC terminologies in depth. It requires reviewing a structured representation that maps criteria to specific EHR fields and value ranges, and confirming that the mapping reflects clinical intent. A qualified clinical informaticist or a matching platform's configuration team handles the translation; the clinical team validates it.
Not Every Criterion Can Be Fully Structured
Some protocol eligibility criteria genuinely cannot be fully expressed in structured coded terms, because the relevant information doesn't exist as structured data in the EHR. Performance status assessments documented only in free-text progress notes, comorbidity severity that requires clinical judgment beyond code presence, and criteria that depend on information gathered at the screening visit itself all fall into this category.
For these criteria, the role of structured matching shifts: rather than making a definitive eligibility determination, the structured query can identify patients who are plausibly eligible and flag the criteria that require human review. A CRA reviewing a pre-filtered candidate list still needs to confirm the unstructured criteria — but they're doing that review for a cohort that has already been filtered by the structured criteria, which substantially reduces the pool. The confirmatory review workload is much smaller than the discovery review workload that manual chart review requires across a full EHR population.
The honest framing is this: structured criteria improve matching precision and consistency for the criteria that can be expressed in coded terminology, which represents the majority of common eligibility requirements. They don't eliminate the clinical review step — they concentrate it on the candidates where clinical judgment is actually needed, and on the criteria where it can't be replaced by a deterministic query.
For CRO teams building feasibility programs around structured EHR matching, the criteria structuring question is worth addressing at the protocol intake stage. The more criteria that can be expressed in structured form before the first feasibility run, the more accurate the cohort estimate and the more consistent the site-level screening process. For more on how this interacts with site selection, see the prospective cohort analysis approach to site selection.