A protocol’s eligibility section looks like a bulleted list and behaves like a specification. Each line is a predicate somebody has to evaluate against a real person, and the extraction fails the moment a line contains two predicates joined by an “and” that is doing structural work.
Where the criteria actually live
There are two sources and they are not the same document. The protocol itself carries the authoritative eligibility section, typically a numbered inclusion list followed by a numbered exclusion list, inside a document of a hundred pages or more. A trial registry entry carries a summary of the same criteria — and on ClinicalTrials.gov the eligibility field is a free-text block, which is precisely why extraction is needed rather than a query.
The registry text is shorter, easier to process and not authoritative. It is a summary prepared for public listing and it routinely omits qualifications present in the protocol. If your use case is finding candidate trials, the registry text is reasonable input. If it is screening, the protocol is the document, and the difference between them should be recorded as a field rather than assumed away.
Within the protocol, the eligibility section is usually its own numbered section, and the reporting guidance reinforces the structure — the SPIRIT statement, which specifies what a trial protocol should contain, lists eligibility criteria as its own item, and the ICH good clinical practice guideline sets out the protocol contents generally. Neither prescribes a machine-readable format, which is the whole problem.
A protocol is a research document, not a patient record, so nothing on this page is about protected health information. The moment you evaluate criteria against actual patients, that changes completely, and the record-side obligations described elsewhere in this cluster attach to the patient data rather than to the protocol.
Inclusion, exclusion, and double negatives
The two lists are not symmetrical opposites and treating them as one list with a polarity flag introduces errors. An inclusion criterion is a condition that must hold. An exclusion criterion is a condition that must not hold. Formally you can negate one into the other, and practically you should not, because the negation of a criterion containing its own negation is where people go wrong.
“Exclusion: patients not willing to use contraception” is a real construction, and its logical content is that willingness is required. Flip it mechanically and you get a double negative that a downstream rule engine evaluates backwards. Keep the list membership as extracted — inclusion or exclusion — record the internal negation as its own attribute, and never normalise one list into the other during extraction.
There is a third category worth a field: criteria that are conditional on another criterion or on a cohort. Multi-arm protocols routinely have a common list plus arm-specific additions, and an extraction that flattens them produces a criteria set that no arm actually has.
One criterion, one assessable claim
Atomicity is the property that makes the extraction useful. A criterion should express exactly one thing that can be evaluated as true, false or unknown for a given person. Protocol authors write for human readers, so they bundle:
As written (one numbered item):
4. Adequate organ function as evidenced by absolute neutrophil
count >= 1.5 x 10^9/L, platelet count >= 100 x 10^9/L, and
serum creatinine <= 1.5 x the upper limit of normal, all
obtained within 14 days prior to randomisation.
Atomised (three criteria, one parent):
4 parent "Adequate organ function" (grouping only)
4.a ANC >= 1.5 x 10^9/L window: 14 days pre-randomisation
4.b platelets >= 100 x 10^9/L window: 14 days pre-randomisation
4.c creatinine <= 1.5 x ULN window: 14 days pre-randomisation
Three things about that decomposition. The parent is retained, with its original number, because the protocol refers to criterion 4 and a system that only knows 4.a through 4.c cannot resolve the reference. The time window distributes across all three children, because it was stated once at the end and applies to the group — the same scoping-backwards problem as the trailing unit on a radiology measurement. And the creatinine threshold is expressed relative to the upper limit of normal, not as an absolute number, which means it cannot be evaluated without the reference range from the specific laboratory that ran the test.
That last point connects the two halves of this cluster. A criterion expressed as a multiple of ULN is only assessable against a lab report that carries its own reference range, which is exactly the argument for extracting the range per result rather than looking it up — see extracting reference ranges.
The shape of a lab-threshold criterion
Once atomised, a large fraction of criteria fit one predicate shape, and modelling it explicitly is what turns extracted text into something a screening system can use:
{
"criterion_id": "4.b",
"parent_id": "4",
"list": "inclusion",
"verbatim": "platelet count >= 100 x 10^9/L",
"subject": { "concept": "platelet count", "loinc": "777-3" },
"comparator": ">=",
"value": 100,
"value_basis": "absolute", /* or "multiple_of_uln" */
"unit": "10*9/L",
"window": { "amount": 14, "unit": "day", "anchor": "randomisation",
"direction": "before" },
"negated": false,
"assessable": true
}
The assessable boolean carries the weight. Many criteria are not reducible to a predicate at all — “in the investigator’s judgement, able to comply with the protocol”, “any condition that would confound interpretation of the results”. These are deliberately open, they are meant to be exercised by a person, and an extraction that coerces them into a machine-evaluable rule has invented a specificity the protocol declined to provide.
Mark them as narrative criteria, keep the verbatim text, and let them route to a human — a routing decision made on the criterion’s type rather than on a score, which is the case confidence threshold review routing treats as a hard route. The valuable output of this whole exercise is usually not a fully automated screen: it is a criteria set where the objective ones are structured, the subjective ones are flagged as requiring judgement, and nobody has to read the protocol again to find out which is which. Deciding whether a specific person meets a specific criterion is a clinical and regulatory judgement, and nothing here is advice about that.
Units in this field are their own hazard. Cell counts appear as 10^9/L, 10*9/L, K/uL and x1000/mm3, some of which are numerically equal and typographically unrelated. Normalise to a coded unit system and store the printed form, for the same reason as every other as_printed field in this cluster.
Numbering, cross-references and amendments
A protocol is amended, often several times, and the amendments are where a corpus that worked on one document falls apart.
Criterion numbers are not stable across versions. Amendment 3 inserts a new exclusion criterion, everything below it shifts by one, and a database keyed on protocol identifier plus criterion number now has rows from two versions pointing at different criteria under the same key. The fix is that the key must include the protocol version and version date, and that a criterion’s identity across versions is established by matching content, not number — a job for review rather than an automatic join.
Cross-references make this worse. Criteria reference each other (“patients excluded under 5.2 may be rescreened”) and reference other sections of the protocol (“as defined in Section 8.4”). Extract these as typed references rather than leaving them in the text, and validate that every reference resolves within the version you extracted. A dangling cross-reference usually means you extracted from a document that was amended and the reference now points somewhere else.
Two more version-related traps. Amended protocols circulate as documents with tracked changes rendered visually — struck-through text for removed criteria and underlined text for added ones — and a text extraction that ignores the formatting produces a criteria set containing both the old and the new criterion, with no indication that they conflict. And a protocol summary sheet at the front frequently restates the key criteria in abbreviated form; extracting from it because it is shorter gives you a version of the criteria that is missing qualifications and is not the operative text.
Record, for every extracted criterion: the protocol identifier, the version, the version date, the section it came from and the page. That five-field provenance is an extraction field audit trail by another name, it is what makes the difference between a criteria database and a pile of sentences, and it is the same argument for provenance that the dosing schedule page makes about the schedule of activities table.
Top comments (0)