Paper deep dive
Scalable High-Recall Constraint-Satisfaction-Based Information Retrieval for Clinical Trials Matching
Cyrus Zhou, Yufei Jin, Yilin Xu, Yu-Chiang Wang, Chieh-Ju Chao, Monica S. Lam
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 98%
Last extracted: 4/14/2026, 1:46:41 AM
Summary
SatIR is a scalable clinical trial retrieval system that uses constraint satisfaction (SMT and relational algebra) to match patient records with clinical trial eligibility criteria. By converting informal clinical text into formal, interpretable constraints and leveraging medical ontologies like SNOMED CT, SatIR improves recall and precision compared to traditional embedding-based retrieval methods like TrialGPT.
Entities (5)
Relation Signals (3)
SatIR → outperforms → TrialGPT
confidence 100% · SatIR outperforms TrialGPT on all three evaluated retrieval objectives.
SatIR → uses → SMT
confidence 100% · Our approach uses formal methods -- Satisfiability Modulo Theories (SMT)
SatIR → uses → SNOMED CT
confidence 100% · canonicalizing terminology with the SNOMED CT medical ontology
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Clinical trials are central to evidence-based medicine, yet many struggle to meet enrollment targets, despite the availability of over half a million trials listed on this http URL, which attracts approximately two million users monthly. Existing retrieval techniques, largely based on keyword and embedding-similarity matching between patient profiles and eligibility criteria, often struggle with low recall, low precision, and limited interpretability due to complex constraints. We propose SatIR, a scalable clinical trial retrieval method based on constraint satisfaction, enabling high-precision and interpretable matching of patients to relevant trials. Our approach uses formal methods -- Satisfiability Modulo Theories (SMT) and relational algebra -- to efficiently represent and match key constraints from clinical trials and patient records. Beyond leveraging established medical ontologies and conceptual models, we use Large Language Models (LLMs) to convert informal reasoning regarding ambiguity, implicit clinical assumptions, and incomplete patient records into explicit, precise, controllable, and interpretable formal constraints. Evaluated on 59 patients and 3,621 trials, SatIR outperforms TrialGPT on all three evaluated retrieval objectives. It retrieves 32%-72% more relevant-and-eligible trials per patient, improves recall over the union of useful trials by 22-38 points, and serves more patients with at least one useful trial. Retrieval is fast, requiring 2.95 seconds per patient over 3,621 trials. These results show that SatIR is scalable, effective, and interpretable.
Tags
Links
- Source: https://arxiv.org/abs/2604.08849v1
- Canonical: https://arxiv.org/abs/2604.08849v1
Trouble viewing inline? Open PDF directly →
Full Text
844,795 characters extracted from source content.
Expand or collapse full text
Preprint. Under review. Scalable High-Recall Constraint-Satisfaction-Based Information Retrieval for Clinical Trials Matching satir.genie.stanford.edu Cyrus Zhou 1 , Yufei Jin 2,∗ , Yilin Xu 3,∗ , Yu-Chiang Wang 4 , Chieh-Ju Chao 4 , Monica S. Lam 1 1 Department of Computer Science, Stanford University, Stanford, CA, USA 2 Samueli Electrical and Computer Engineering, UCLA, Los Angeles, CA, USA 3 Department of Computer Science and Informatics, Emory University, Atlanta, GA, USA 4 Mayo Clinic, Rochester, MN, USA ∗ Equal contribution zikai@stanford.edu, lam@stanford.edu Abstract Clinical trials are central to evidence-based medicine, yet many struggle to meet enrollment targets, despite the availability of over half a million trials listed on ClinicalTrials.gov, which attracts approximately two million users monthly. Existing retrieval techniques, largely based on keyword and embedding-similarity matching between patient profiles and eligi- bility criteria, often struggle with low recall, low precision, and limited interpretability due to complex constraints. We propose S AT I R, a scalable clinical trial retrieval method based on con- straint satisfaction, enabling high-precision and interpretable matching of patients to relevant trials. Our approach uses formal methods—Satisfiability Modulo Theories (SMT) and relational algebra—to efficiently represent and match key constraints from clinical trials and patient records. Beyond lever- aging established medical ontologies and conceptual models, we use Large Language Models (LLMs) to convert informal reasoning—regarding ambi- guity, implicit clinical assumptions, and incomplete patient records—into explicit, precise, controllable, and interpretable formal constraints. Evaluated on 59 patients and 3,621 trials, S AT I R outperforms TrialGPT on all three retrieval objectives. It retrieves 32%–72% more relevant-and- eligible trials per patient, improves recall over the union of useful trials by 22–38 points, and serves more patients with at least one useful trial. Retrieval is fast, requiring 2.95 seconds per patient over 3,621 trials. These results show that S AT I R is scalable, effective, and interpretable. 1 Introduction Importance of Clinical Trial Matching Clinical trials are central to evidence-based medicine, yet enrolling eligible participants remains a persistent bottleneck. Despite large investments in recruitment (estimated at∼ $1.9B annually) (Desai, 2020), nearly 80% of trials still miss enrollment targets or timelines (Brøgger-Mikkelsen et al., 2020). At the patient level, these failures manifest as matching errors. Recall errors hide truly eligible trials, so 0 The example is simplified from the tofersen study NCT02623699. Seehttps://nypost.com/2025/ 03/18/health/mother-with-rare-als-touts-miracle-drug-that-has-stopped-her-disease/for a motivating patient story. 1 arXiv:2604.08849v1 [cs.CL] 10 Apr 2026 Preprint. Under review. Clinical Trial Inclusion Criteria: ●Participants must be 18 years of age or older with histologically confirmed non–small cell lung cancer or metastatic colorectal cancer, and must have measurable disease according to RECIST 1.1. ●Participants must have received at least one prior line of systemic therapy or be considered ineligible for standard chemotherapy, and must not have active autoimmune disease requiring systemic treatment or untreated central nervous system metastases. AND OR NOT AND OR AND I. Ingest for Retrieval ≥ AND AND I.Formalize I. Convert to Relational Algebra ●Weakness attributable to ALS and documented SOD1 mutation at Screening Visit 2. ●A forced vital capacity (FVC) ≥50% of predicted value. Participants with stable FVC <50% but ≥45% may be considered for inclusion. ●If taking riluzole, participant must be on a stable dose. I.Formalize ∧ ((¬ taking_riluzole) ∨ taking_stable_dose_of_riluzole) Qualifier: at Screening Visit 2. Qualifier: documented 50% OR 50% 45% AND OR NOT AND OR ¬ Ingest for Retrieval AND Translate Trial: A Study to Evaluate Tofersen in Adults With SOD1 ALS ●Weakness attributable to ALS and documented SOD1 mutation at Screening Visit 2. ●A forced vital capacity (FVC) ≥50% of predicted value. Participants with stable FVC <50% but ≥45% may be considered for inclusion. ●If taking riluzole, participant must be on a stable dose. Formalize Qualifier: at Screening Visit 2. Qualifier: documented 50% OR 50% 45% AND OR NOT AND OR ¬ Trial: A Study to Evaluate Tofersen in Adults With SOD1 ALS Figure 1: Example: A tofersen SOD1-ALS study showing how S AT I R turns free-text eligi- bility criteria into formal, interpretable constraints that can be executed in a database for scalable retrieval. Terms in blue are ontology-grounded concepts. In Stage I, S AT I R keeps only clauses that can be safely translated into database predicates without ruling out true matches; clauses that cannot be translated this way are dropped. potentially beneficial options are never surfaced. Precision errors flood coordinators with false leads, increasing screening workload, churn, and protocol risk (Gregory et al., 2017; Wendler, 2021; Lee et al., 2025). Existing Approaches to Clinical Trial Retrieval Most recent systems treat patient–trial matching as semantic retrieval over informal representations: clinical notes and structured fields are linearized as text, candidate trials are retrieved by dense embedding similarity, and then ranked and matched by a Large Language Model (LLM). Recent work, including TrialGPT (Jin et al., 2024), follows this embedding-plus-LLM tem- plate. But eligibility is governed by sharp constraints—negation, temporality, numeric thresholds, laterality, and ontology relations—that embeddings often smooth over. As a result, retrieval based on semantic similarity rather than logical compatibility can have poor recall. Expanding retrieval to recover recall also increases false positives and matching burden. Ideally, we want to find all relevant trials so that no patients are left behind. Problem Statement of Clinical Trial RetrievalGiven a set of patient records, the goal is to retrieve relevant and eligible trials from a large clinical-trial corpus with high recall (to avoid missing suitable trials), high precision (to reduce matching burden), high efficiency (to operate at scale), controllability (to apply a uniform matching protocol), and interpretability (to make errors easy to detect). To address these requirements, we propose a new information retrieval method based on constraint satisfaction. Using formal methods—Satisfiability Modulo Theories (SMT) (Bar- rett & Tinelli, 2018) and relational algebra (Codd, 1970)—our retriever efficiently represents and matches key constraints from clinical trials and patient records to produce a highly targeted set of candidate trials for each patient. Designing a formal representation and a semantic parser that faithfully map natural lan- guage to formal semantics for clinical trial matching is challenging. They must capture complex eligibility logic, contextual relevance, incomplete patient records, implicit clinical assumptions, and the breadth of medical ontologies. Addressing these challenges is essential for formal methods to deliver accuracy, scalability, controllability, and interpretability. Contributions.The main contribution of this paper is a new scalable information-retrieval technique based on constraint satisfaction that outperforms embedding-based retrieval in terms of recall, precision, controllability, and interpretability. Our method translates clinical trials and patient records independently into their formal representations and retrieves matches using database queries, as shown in Figure 2. 1. Grounded, context-aware formalization. We introduce T R I A L R E P R, an SMT-based representation for clinical trials and patient records that is (i) expressive, capturing 2 Preprint. Under review. SMT SMT Candidate Trials Why Retrieved / Why Not Retrieved Why Retrieved / Why Not Retrieved Why Retrieved / Why Not Retrieved Why Retrieved / Why Not Retrieved Database Containing Trial-Side Constraints SMT SMT SatIR Patient Representation Database Containing Patient-Side Constraints Patient Notes Patient Notes New Patient Records Patient-Side Semantic Parser Query Executor and Explainer Logic Converter Patient Notes Patient Notes Trial Listings SMT SMT Logic Converter Database Containing Trial-Side Constraints SatIR Trial Representation Trial-Side Semantic Parser Indexing Retrieval Figure 2: Overview of S AT I R. Boolean logic, numeric thresholds, temporal windows, and exceptions; (i) medically grounded, incorporating ontology-aware concept identity and entailment in a SNOMED- based model (SNOMED International, 2025a), with standardized units and temporal conventions; and (i) context- and intent-aware, distinguishing hard and soft constraints while accounting for patient preferences and objectives. We also present an interpretable approach to missing patient data, using LLMs to assess the salience of missing information. 2.Accurate semantic parsing. We propose an LLM-based semantic parser that accurately translates under-specified clinical trials and diverse patient records into T R I A L R E P R. 3. Scalable trial retrieval with high recall. We propose a novel scalable constraint-based retriever by leveraging relational algebra. By storing a projection of T R I A L R E P R as first- class data in databases, our system retrieves a highly targeted set of candidate clinical trials for all patients according to a given objective efficiently with SQL queries. Experimentally, S AT I R consistently outperforms embedding-based baselines across three evaluated retrieval objectives, retrieving more relevant-and-eligible trials, achieving substan- tially higher recall, and winning on more patients overall. These gains come with practical database-level efficiency and persist even under much larger TrialGPT retrieval budgets. 2 Formalization of the Clinical Trial Retrieval Task Design Principles. Clinical trial matching cannot, and need not, be fully captured in a formal language for retrieval. No finite symbolic language can express every clinical nuance. Instead of forcing all text into a rigid schema, we design a representation that is conservative and recall-oriented: it should avoid excluding potentially eligible trials, while remaining as expressive as possible to filter out unsuitable ones and improve accuracy. T R I A L R E P R represents clinical trials and patients as SMT (Satisfiability Modulo Theories) formulas, canonicalizing terminology with the SNOMED CT medical ontology, which con- tains over 350,000 concepts and about three million relationships (SNOMED International, 2019) . Because SNOMED CT does not cover all concepts appearing in patient records and trial text, we extend it with non-canonical predicates whose semantics are specified by free-text descriptions, preserving fidelity to the source text. See Section 2.3 for details. Explicit knowledge representation for formal reasoning. All information used for patient–trial matching must be represented explicitly. We therefore leverage SNOMED’s subsumption structure to support formal reasoning over canonicalized concepts. See Section 3 for details. Handling missing information with a salience assumption. Patient records are often incomplete. We address this by assuming that salient facts about a patient would be documented. When information is missing, we use LLMs to assess whether the record supports, refutes, or is inconclusive about the condition of interest. Making these assessments explicit keeps retrieval transparent and interpretable. We discuss this in Section 4. 3 Preprint. Under review. 2.1 The Medical Ontology A medical ontology for clinical trial matching isO = (R,K,Q,⊑), whereR = R M ∪ R P ∪ R T (elaborated in Appendix B.3), withR M a set of medical relations hasfindingof, hasundergone, ...,R P a set of patient facts pertaining clinical trials including their intents in clinical trial matching and preferences chiefcomplaint, ..., andR T a set of intents of trials treat, prevent, diagnose, .... Further,Kis a set of medical concepts, andQis a set of qualifiers. Finally,⊑=⊑ R ∪⊑ K ∪⊑ causal ∪⊑ Q (Appendix B.1) is the family of subsumption relations. • ⊑ R ⊆ R× Rdenotes subsumption over medical relations. We writeO R = (R,⊑ R ), wherer p ⊑ R r c meansr p is more specific than, and therefore supports,r c ; e.g., H A S D I A G N O S I S O F ⊑ R H A S F I N D I N G O F. • ⊑ K ⊆ K× K denotes subsumption over concepts. A predicate with conceptk p sup- ports one with conceptk c wheneverk p ⊑ K k c ; e.g.,A C U T E A P P E N D I C I T I S ⊑ K A P P E N D I C I T I S. • ⊑ causal ⊆ (R ,K) × (R,K)denotes subsumptionrelations based oncausal or dependency structures across relations and concepts.We derive these from SNOMED graph relations and retain only transformations consistent withR(e.g.,(H A S F I N D I N G O F,P O S T O P E R AT I V E H E M O R R H A G E) ⊑ causal (H A S U N D E R G O N E, S U R G I C A L P R O C E D U R E). • ⊑ Q ⊆ Q× Qdenotes subsumption over qualifiers, including cases where a more specific qualifier, or a qualified predicate, supports a less specific one. 2.2 The T R I A L R E P R Representation An SMT formula is an arbitrary composition of atomic constraints using logical oper- ators such as conjunction, disjunction, counting, and negation. An atomic constraint a = (π,cmp,t) ∈ Aconsists of a predicateπ ∈Π, a comparison operatorcmp ∈ < ,≤, =,̸=,≥, >, and a comparison target t∈ T. A predicateπ ∈Π(R,K,Q)is either:(i) canonical: π = (r,k,q),r ∈ R,k ∈ K,q ∈ Q∪∅ , or(i) non-canonical: π = id, whereidis a mnemonic identifier annotated with free text, used when the predicate cannot be faithfully expressed using R, K, and Q. Given an ontologyO = (R,K,Q,⊑), a set of clinical trialsCwith free-text descriptionsTT, a set of patient recordsPwith free-text descriptionsPT, and a free-text matching objective OT, the T R I A L R E P R consists of: (i) for each trialc ∈ C, a trial constraintTC(c), an SMT formula over predicates inΠ(R M ∪ R T ,K,Q), which may be canonical (e.g., “type 2 diabetes within 5 years") or non-canonical (e.g., “adequate social support for follow-up”); (i) for each patientp∈ P, a patient constraintPC( p), an SMT formula over canonical predicates in Π(R M ∪ R P ,K,Q); and (i) a formalized matching objectiveθ(e.g., “treat chief complaints"). Preprocessing of Free Text Canonicalization of Medical Concepts Programming of Constraints with Representation Language SNOMED-Based Medical Ontology The patient must have Kawasaki syndrome with either coronary artery dilation or aneurysm and meet one of the following conditions: -coronary artery involvement, defined as Z-score ≥ 2.5 in any major coronary segment; -persistent or recrudescent fever, defined as temperature ≥ 38.0°C for ≥ 36 hours after initial therapy; or -evidence of active inflammation, i. Preprocessing of Free Text i. Canonicalization of Medical Concepts i. Programming of Constraints To be included, the patient must have Kawasaki syndrome with (coronary artery dilation) OR (coronary artery aneurysm). To be included, the patient must satisfy ≥ 1 of the following conditions: -(coronary artery involvement, defined as Z-score ≥ 2.5 in any major coronary segment) OR -(persistent fever OR recrudescent fever, defined as temperature ≥ 38.0°C for ≥ 36 hours after initial therapy) OR -(evidence of active inflammation) To be included, the patient must have Acute febrile mucocutaneous lymph node syndrome (ID:75053002) with (Dilatation of Blood Vessel (ID: 248493003)) with the finding site of Coronary Artery (ID: 41801008) or (Aneurysm of coronary vessels (ID: 50570003)). To be included, the patient must satisfy ≥ 1 of the following conditions: -(coronary artery involvement, defined as Z-score ≥ 2.5 in any major coronary segment) OR -((persistent Fever (ID: 386661006)) or (recrudescent Fever (ID: 386661006)), defined as Body Temperature (ID: 386725007) ≥ 38.0 Celsius Degrees for ≥ 36 hours after initial Therapy (ID: 276239002)) OR -(evidence of Acute Inflammation (ID: 4532008)) (assert (and acute_febrile_mucocutaneous_lymph_node_syndro me_now (or dilatation_of_blood_vessel_now@@finding_site_coro nary_artery aneurysm_of_coronary_vessels_now))) (assert (or (and coronary_artery_z_score_value_recorded_now_with unit_unitless@@in_any_major_coronary_segment (>= coronary_artery_z_score_value_recorded_now_with unit_unitless 2.5)) (and (or fever_now@@persistent fever_now@@recrudescent) (>= body_temperature_value_recorded_now_withunit_c elsius 38.0) fever_now@@foradurationof36hours fever_now@@temporalcontext_after_initial_therapy) acute_inflammation_now)) Preprocessing Modifications Canonicalized Concepts Canonical SMT Variables Qualifiers to Canonical Variables Non-Canonical Variables Text Color Legend Dilation: -Dilatation of Blood Vessel -ID: 248493003 Coronary Artery Aneurysm: -Aneurysm of Coronary Vessels -ID: 50570003 Coronary Artery: -Coronary Artery -ID: 41801008I Fever: -Fever -ID: 386661006 Body Temperature: -Body Temperature -ID: 386725007 Active inflammation: -Acute Inflammation -ID: 4532008 Figure 3: Architecture of Semantic Parsing Workflows in S AT I R. @@ denotes qualifiers. 4 Preprint. Under review. 2.3 Semantic Parser from Clinical Text to T R I A L R E P R Accurate retrieval depends on accurately translating natural-language constraints into formal SMT statements grounded in a comprehensive medical ontology. In practice, we found single-shot in-context LLM parsing too error-prone to be reliable. We therefore use a three-stage pipeline (Figure 3): (1) restructure the text to facilitate parsing, (2) link entities to SNOMED CT, and (3) generate the SMT program. Stage 1: Structured Decomposition of Requirements. Clinical trials often specify distinct cohorts, such as control and experimental groups, each with their own eligibility criteria. We create separate requirement lists for each cohort and apply the following steps on them. Further details appear in Appendix C.1. 1.Polarity. Trials often list inclusion and exclusion criteria in separate sections. We generate a unified, context-independent list by reversing the polarity of exclusion criteria. 2.Span Contiguity. We rewrite clinically meaningful spans so that relevant entities appear as contiguous phrases, making concept mentions easier to canonicalize. 3.Logical Structure. We rewrite the logical statements to make conjunction, disjunction, and precedence explicit, so as to clarify the logical relationships within constraints. 4.Decomposition. We break down constraint descriptions into separate, self-contained sentences, creating modular units that can later be compiled and validated independently. Stage 2: Entity Canonicalization. Canonicalization of medical terms simplifies the match between patients and clinical trials. We perform entity linking (Dredze et al., 2010; Zheng et al., 2010) against our ontology. As discussed above, we identify medical facts that cannot be represented accurately with the ontology and introduce new non-canonical predicates to capture their meaning. Further details can be found in Appendix C.2. Stage 3: Incremental SMT Programming. Translating a trial into an SMT program—often around 360 lines per trial—is non-trivial. We therefore program incrementally, with the LLM handling one self-contained free-text constraint at a time. Variables for canonical and non-canonical entities are introduced as needed, qualifiers are extracted under targeted instructions, and SMT declarations andassertstatements are generated requirement by requirement. Each fragment is validated before commitment: parsing checks syntactic and sort correctness, solver checks consistency with the current program prefix, and LLM checks semantic faithfulness, including polarity, qualifier preservation, and variable use. Only validated fragments are added to the final program. Details can be found in Appendix C.3. An example of SMT Program output can be found in Appendix E.3. Patient-side semantic parsing follows a simplified version of the workflow (Stage 1–3) (see Appendix C.7) above with more careful treatment of time-window qualifiers (Appendix C.8). 3 Augmenting T R I A L R E P R for Formal Reasoning about Clinical Trials As discussed in Section 2, reasoning about constraints must account for the family of sub- sumption relations⊑=⊑ R ∪⊑ K ∪⊑ causal ∪⊑ Q . We compile these subsumption relations into the SMT constraints themselves. Concretely, on the patient side, we encode⊑ K ,⊑ R ,⊑ Q , and⊑ causal as additional constraints and inject them into the patient constraint set for each patientp ∈ P. On the trial side, we encode⊑ Q as additional constraints and inject them into the trial constraint set for each trialc∈ C. Thus, constraint solving is ultimately performed over augmented patient and trial formulas rather than over raw extracted predicates alone. We discuss how these subsumption relations are implemented in Appendix B.1 and B.2. 4 Augmenting T R I A L R E P R to Handle Patient Data Missingness Patient records are often incomplete or under-specified. In this section, we describe how we augment T R I A L R E P R to handle such incompleteness, primarily through salience-based 5 Preprint. Under review. Trial asks for ... Patient Record ●Metastatic NSCLC ●Prior chemotherapy ⚠ No explicit evidence for: ●Pregnancy status ●Active infection ●Ability to walk ●Hospitalization status ●Metastatic NSCLC ●Pregnancy status ●Active infection ●Ability to walk ●Hospitalization status Missingness Resolution under Salience Policy ⓐ Explicitly resolved by patient evidence ●Metastatic NSCLC ⓑ Default to False ●Pregnancy Status ●Active infection ⓒ Default to True ●Ability to walk ⓓ Default chosen to satisfy the constraints ●Hospitalization status Trial asks for ... Patient Record ●Metastatic NSCLC ●Prior chemotherapy ⚠ No explicit evidence for: ●Pregnancy status ●Active infection ●Ability to walk ●Hospitalization status ●Metastatic NSCLC ●Pregnancy status ●Active infection ●Ability to walk ●Hospitalization status Missingness Resolution under Salience Policy ⓐ Explicitly resolved by patient evidence ●Metastatic NSCLC ⓑ Default to False ●Pregnancy Status ●Active infection ⓒ Default to True ●Ability to walk ⓓ Default chosen to satisfy the constraints ●Hospitalization status Salience Policy Enforcer (a) Whole-fact missingness: salience determines how absent evidence for a condition is treated. Ⓔ Ⓐ Ⓑ (b) Specificity mismatch: salience determines which ontology-supported alternative targets may be satisfied by under-specified evidence. Figure 4: Salience under incomplete evidence in patient records. reasoning over missing or underspecified evidence (Section 4), and, in some cases, by inferring diagnoses from patient notes (Section 4). Salience as a principle for handling missingness. To improve retrieval accuracy, we make a fundamental assumption: any salient information about a patient’s condition will be documented in their medical record. This allows us to address missing data by focusing on whether the absent information is truly salient. Because salience is not formally defined in the medical literature, we use targeted LLM queries to assess concept importance. We record these judgments explicitly, keeping matching decisions transparent, interpretable, and open to expert review. In contrast, end-to-end LLM matching is much harder to inspect. Missingness in records. Patient records often lack information to support or refute specific constraints. For each clinical trial condition, we use the LLM to determine whether poten- tially missing information is salient, and correspondingly whether it should be interpreted as supporting the condition, refuting it, or remaining inconclusive (Figure 4a). Under-specificity in records. As discussed in Section 3, a patient is logically eligible for tri- als targeting conditions that subsume the patient’s diagnosis. However, since medical records can be under-specified, it may also be reasonable to match patients to trials when their diagnosis subsumes the trial’s targeted condition. Whether we should do so depends on the salience of the targeted condition. As shown in Figure 4b, a patient documented only with appendicitis” may still match a trial for Acute Appendicitis,” since the record may omit that extra specificity. But the same patient should not match a trial for “Ruptured Suppurative Appendicitis,” because such a salient condition would likely be explicitly recorded. For each trial condition, we use the LLM to assess its salience relative to its parent concept in the medical ontology. If it is not highly salient, patients diagnosed with the parent condition are also considered potential matches. Inferring diagnoses from patient notes. Some patient notes describe symptoms or clinical findings without stating a diagnosis explicitly. In these cases, we augment T R I A L R E P R by inferring likely diagnoses using the LLM pipeline from Section 2.3. This component is included mainly to address a limitation of the evaluation dataset (Koopman & Zuccon, 2016), since physicians indicated that real clinical documentation usually states diagnoses explicitly. Further details are provided in Appendix C.9. 5Clinical Trial Matching and a Constraint-Based Information Retriever A Clinical Trial Matching (C T M) task takes a medical ontologyO, clinical trialsC, pa- tient recordsP, their free-text descriptionsTTandPT, and a match objectiveOT, and seeks all trial–patient pairs satisfying the objective and all trial and patient constraints. C T M(O, T, PT, OT) = M AT C H(c, p), ∀(c, p)∈ S AT I R(T R I A L R E P R(O, T, PT, OT)). 6 Preprint. Under review. Our SMT-based T R I A L R E P R is designed to capture strict eligibility and relevance constraints with high recall and precision. Because some nuances are difficult to formalize from free text, final matching is performed by an LLM on the original trial and patient descriptions: it first identifies relevant trial cohorts, then assesses eligibility for each cohort (Appendix E.2). S AT I R takes SMT constraintsTC,PC, andθ, and returns as few non-matching pairs as possible while ensuring that all trial–patient pairs are entailed by TC∪ PC∪ θ: TC∪ PC∪ θ |= S AT I R(TC∪ PC∪ θ). Key Principle. If all constraints parsed from trial and patient free text into the formal representation are necessary, then S AT I R achieves 100% recall with respect to the SMT constraints: it returns every matching trial–patient pair. 5.1S AT I R Constraint-Satisfaction Based Information Retriever For scalability, S AT I R maps SMT constraints to relational constraints for database execution. Conservative conversion from SMT to quantifier-free Conjunctive Normal Form (C N F). Since patient records contain only concrete facts rather than Boolean clauses, we can translate SMT by applying quantifier elimination independently to patient records and clinical trials. At a high level, quantifier elimination removes variables and subformulas involving non- canonical predicates, yielding a quantifier-free formula while preserving entailment (Cooper, 1972; de Moura & Bjørner, 2008). Specifically, quantifier elimination needs to be applied only to the non-canonical predicates. We represent each quantifier-free constraint in CNF, so each entitye ∈ C∪ Ptakes the formC N F(e) = V m i=1 d i , whered i = W n i j=1 a ij and eacha ij ∈ Ais an atomic constraint over canonical predicates. Representing CNF constraints as first-class database objects. CNF constraints are repre- sented in a database. S AT I R uses a patient databasePDand a clinical trial databaseCD, each with five tables: (1) Entity-to-CNF tableE C N F(e,cnf), linking each entityeto its CNF constraint. (2) CNF-to-clause tableC N F D(cnf,d), mapping each CNF to itsmdisjunctive clauses inmrows. (3) Clause-to-atom tableD A(d,a), linking each disjunctive clause to natomic constraints innrows. (4) Boolean atom tableA B(a,π,cmp,t), storing unique Boolean atoms.(5) Numerical atom tableA N(a,π,cmp,t), storing uniquified numerical atoms, wheretis represented by lower and upper bounds together with endpoint inclusivity. Once trials and patients are represented in this form, matches for a given objec- tiveθcan be retrieved with a straightforward SQL query over the database tables, de- noted S Q L(O, CD, PD, θ); see Appendix D.2. 6 Evaluation Methodology System Implementation S AT I R is implemented primarily with GPT-4.1 and uses GPT-5 only in a limited component: the repair pipeline of the semantic parser (Appendix C.4). We compare S AT I R against TrialGPT (Jin et al., 2024), a clinician-keyword baseline derived from the TrialGPT benchmark, and several TrialGPT-style hybrid baselines that replace its dense retriever with PubMedBERT (Gu et al., 2021), SapBERT-PubMedBERT (Deka et al., 2022), BMRetriever (Xu et al., 2024), or BGE-large-en-v1.5 (Xiao et al., 2024). We evaluate all LLM-based baselines with both GPT-4.1 (OpenAI, 2025) and GPT-5 (Singh et al., 2025) Dataset. We evaluate on the SIGIR 2016 patient–trial test collection (Koopman & Zuccon, 2016), which contains 59 synthetic patient vignettes and 3,621 real clinical trials from a ClinicalTrials.gov snapshot (ClinicalTrials.gov). The benchmark provides pooled trial-level judgments: for each patient, candidate trials from multiple systems and query variants were merged into a pool, and only a budget-limited subset was manually judged. These labels are insufficient for our setting. Many patient–trial pairs are unjudged, so they cannot be treated as negatives. In addition, the benchmark does not define relevance with 7 Preprint. Under review. respect to an explicit clinical retrieval objective, and the judgments are not fully internally consistent. For completeness, we report results against the original labels in Appendix A.1.2. We therefore evaluate on the same patients and trial corpus under a new protocol: a retrieved trial must be both relevant under an explicit retrieval objective and eligible for the patient. Retrieval Objectives. We consider three objectives: (1) trials that treat the patient’s chief complaint (treat-chief), (2) trials that treat any condition of the patient (treat-any), and (3) tri- als relevant to any condition of the patient (relevant-to-any). For specifics, see Appendix A.2. In S AT I R, these objectives are implemented as different filters over the stored constraints. TrialGPT does not natively support objective-specific retrieval. For comparison, for each setting we evaluate both objective-aware and objective-agnostic keyword generation under both GPT-4.1 and GPT-5, and report the best result across the four variants. Metrics. S AT I R returns all satisfying trial–patient pairs, whereas TrialGPT-style baselines return ranked lists. For fairness, we truncate each baseline, for each patient, to the same average number of trials retrieved by S AT I R under the same objective. We evaluate the number of relevant-and-eligible trials retrieved using three metrics: (1) average retrieved per patient, (2) micro recall over the union of relevant-and-eligible trials found by any method, and (3) patient-level outcomes: which method retrieves more such trials (Utility winner) and whether the patient receives at least one (Patients served). These metrics are computed by an LLM judge (ran with GPT-5) under three retrieval objectives, with clinician validation. For patient-level outcomes, we compare S AT I R only against the strongest fixed TrialGPT baseline, the GPT-5 variant. Validation of the LLM Judge. Two clinicians independently reviewed a balanced sample of 27 LLM-judge decisions spanning objectives and outcomes. Clinician A accepted 25, marked 1 uncertain, and rejected 1; Clinician B accepted 24, marked 1 uncertain, and rejected 2. Of the four unique disputes, three were clinically ambiguous and one was a clear error agreed upon by both clinicians. Agreement was strong (Gwet’s AC1 = 0.82 (Gwet, 2008)); we report AC1 rather than Cohen’sκbecause the labels were highly imbalanced toward acceptance (Cohen, 1960). Details are in Appendix A.3.1 and Appendix A.3.2. 7 Result Discussion We report the main results; additional results and settings are in Appendix A.1 and A.5. Average relevant-and-eligible trials retrieved. Table 1 shows the mean number of retrieved trials per patient that are both relevant and eligible. S AT I R performs best under all three retrieval objectives: 3.25 under treat-chief, 5.12 under treat-any, and 11.76 under relevant-to- any, compared with 2.17, 2.98, and 8.93 for TrialGPT. Among the TrialGPT-style baselines, the original TrialGPT pipeline is generally strongest, but all remain below S AT I R. ObjectiveRetrieved/Patient BMRet ClinBest S-PubMedB BGE PubMedB TG S AT I R treat-chief361.441.751.972.072.002.173.25 treat-any642.002.542.752.852.682.985.12 relevant-to-any1216.397.248.548.688.928.93 11.76 Table 1: Mean number of retrieved trials per patient that are both relevant and eligible. Abbreviations: BMRet = BMRetriever; ClinBest = best clinician-keyword variant; S-PubMedB = SapBERT-PubMedBERT; BGE = BGE-large-en-v1.5; PubMedB = PubMedBERT; TG = TrialGPT. Recall over the union of useful trials found by any method. As shown in Table 2, S AT I R achieves the highest micro recall under all three objectives: 93.66 for treat-chief, 92.07 for treat-any, and 92.53 for relevant-to-any. TrialGPT is the strongest among the baselines in each setting, but remains substantially lower at 62.44, 53.66, and 70.27, respectively. Patient-level comparison. Table 3 shows that S AT I R outperforms TrialGPT at the patient level under all three objectives, winning on more patients (20 vs. 6 for treat-chief, 29 vs. 2 for 8 Preprint. Under review. ObjectiveBMRet ClinBest S-PubMedB BGE PubMedBTGS AT I R treat-chief41.4650.2456.5959.5157.5662.4493.66 treat-any35.9845.7349.3951.2248.1753.6692.07 relevant-to-any50.2756.9367.2068.2770.1370.2792.53 Table 2: Micro recall against the union of relevant-and-eligible trials found by all methods. treat-any, and 35 vs. 7 for relevant-to-any) and serves more patients overall: 39 vs. 35, 42 vs. 39, and 54 vs. 50, respectively. Utility winnerPatients served ObjectiveS AT I R wins Tie TrialGPT winsS AT I R only Both TrialGPT only Neither treat-chief20336435020 treat-any29282 339017 relevant-to-any3517754914 Table 3: Patient-level retrieval outcomes over 59 patients (S AT I R vs. TrialGPT w/ GPT-5). Speed and Scalability Querying the database took 2.95 seconds per patient over 3,621 trials on Machine 2 (configurations in Appendix A.5), indicating that the system is fast in practice. Evaluation of Recall. To further evaluate recall, we ran TrialGPT with GPT-5 and increased its retrieval budget to 200 trials per patient. Even under this setting, TrialGPT still missed 253 trial–patient pairs across the three objectives that S AT I R successfully retrieved. Conversely, TrialGPT found 20, 18, and 36 trials that S AT I R missed under treat-chief, treat- any, and relevant-to-any (0.34, 0.31, and 0.61 cases per patient), out of 11,800 retrieved trial instances. Excluding 17 cases due to LLM-judge error or unresolved ambiguity left 57 clear failures, mainly from patient-side parsing (14), trial-side parsing (13), under-specified patient evidence (8), missing patient facts (6), and other factors (16) (Details in Appendix A.4). 8 Related Work Most prior pipelines are text-first: they linearize trials and patient records, retrieve candidates by keyword or embedding similarity, and use LLMs for matching and ranking (e.g., TrialGPT- style systems) (Jin et al., 2024). Biomedical retrievers improve candidate generation (Gu et al., 2021; Xu et al., 2024), but reasoning remains largely implicit. Entity linking and ontology grounding help canonicalize surface forms (Liu et al., 2021; SNOMED International, 2025a). S AT I R uses grounding not only for canonicalization but also to guide constraint augmentation with LLM-based informal reasoning (i.e., salience). Related work uses LLMs to manage, synthesize, and query heterogeneous corpora, including STORM (Shao et al., 2024), Co-STORM (Jiang et al., 2024), and LOTUS (Patel et al., 2024). These systems reason largely over free text or weakly structured data at query time. By contrast, S AT I R pushes retrieval-critical semantics into executable, ontology-grounded constraints for scalable symbolic execution. S AT I R also relates to formal methods and neurosymbolic LLM+symbolic systems. SMT enables reasoning over structured constraints (Barrett & Tinelli, 2018; de Moura & Bjørner, 2008), while systems such as LINC, Logic-LM, and PAL translate natural language into formal programs executed by symbolic engines (Olausson et al., 2023; Pan et al., 2023; Gao et al., 2023). Unlike these systems, S AT I R targets real-world large-scale clinical retrieval, emphasizing scalable, interpretable constraint execution under missing data. 9 Preprint. Under review. 9 Conclusion Our work on S AT I R studies how formal methods can be combined with LLMs to improve information retrievers, using critical problem in medicine—clinical trial matching—as a case study. We demonstrate that S AT I R has significantly higher recall and precision over the previous SOTA TrialGPT system. The success is due to 4 factors: (1) The SNOMED CT model provides an extensive ontology and subsumption for formal reasoning, without which this approach would not be feasible. (2) A key weakness in formal methods is their inability to interpret missing data. We identify the concept of salience as a key to resolving the ambiguity, and show that LLM can be used to capture salience judgment in a formal, highly interpretable and controllable representation. (3) Clinical language possesses a depth and complexity that surpasses any fixed symbolic system. Our representation is carefully designed to capture the essential constraints of clinical language—this fidelity is what allows the information retriever to achieve high recall and high precision. (4) Scalability is achieved by mathematically projecting SMT constraints into relational algebra, with no loss in recall. More broadly, our results suggest that in complex real-world, high-recall settings, the strongest systems come from combining LLM reasoning with formal methods to create an interpretable representation amenable to optimization techniques, while still leaving important methodological and practical limitations that we discuss in Appendix E.1. Author Contributions Monica S. Lam proposed the high-level research direction, originated and refined the core ideas, guided the system design, supervised the project, secured funding, and led the writing of the paper. Cyrus Zhou served as the student lead and primary implementer, driving the detailed system design, system development, database logic, and experimental execution, and contributing substantially to the writing and figure creation. Yufei Jin led the devel- opment and evaluation of the patient-side semantic parser, contributed to the design and development of the trial-side semantic parser, including co-leading SMT programming and leading qualifier extraction, conducted patient-side experiments, co-drove the implementa- tion of the subsumption component, contributed to database logic, contributed to evaluation design and problem framing, and assisted with paper writing. Yilin Xu contributed to se- mantic parser development, including co-driving retrieval-objective and trial-intent-related components, helped finalize the preprocessing and canonicalization modules, conducted extensive fine-grained and baseline evaluations, developed the cohort-splitting logic, co-led the implementation of whole-fact salience and missingness handling, contributed to the de- velopment of experimental utilities, and assisted with paper writing and figure preparation. Chieh-Ju Chao provided primary clinical expertise, performed clinician validation, and ad- vised the project throughout. Yu-Chiang Wang provided clinical expertise and contributed to clinician validation. Acknowledgments We gratefully acknowledge support from the Verdant Foundation, the Hasso Plattner Insti- tute, Microsoft Azure AI credits, Itaú Unibanco, BMO Financial Group, and the Stanford Human-Centered Artificial Intelligence (HAI) Institute. Cyrus Zhou is partially supported by the Stanford School of Engineering Fellowship. We thank Yucheng Jiang for designing and implementing the clinician annotation interface. We are grateful to Shicheng Liu, Harshit Joshi, Jiuding Sun, Yucheng Jiang, Sina Semnani, Tamara Czinczoll, Chris Hoenes, Sally Wang, Jungwoo Kim, and Stanford OVAL Lab mem- bers for their support, feedback, and discussions. We also thank Dr. James Ford, Dr. Bryant Lin, Dr. James Dickerson, Dr. Jimmy Lin, Dr. Michael Gensheimer, Professor Gill Bejerano, and Lisa S. Lowy for their expert guidance and helpful discussions. We thank Shengguang Wu, Yicheng Qian, Heng Yu, Juze Zhang, Yue Zhao, Hermann Kumbong, Devon Smith, Youngjoong Kwon, Sa Zhou, Yilong Zhao, Jiaming Tang, Alireza Haqi, Hanchen Li, Qizheng Zhang, Fangrui Huang, Haichuan Wang, Jiahao Lu, Ziqi Shu, Shreyas Agarwal, Jie Zhu, 10 Preprint. Under review. Wenyi Wang, Zhijie Huang, Grace Zhang, Jiashan Zhao, Tianxin Wang, Qinghui Wang, Yunong Zhang, Haochen Pan, Yifei Zhang, and Shiqi Kuang for their support and discus- sions. We further thank Lefan Zhang, Shan Lu, Blase Ur, Nandish Shah, Ning Tang, Youwen Wu, and Qi Hu for their support and perspectives. Finally, we thank our families for their enduring support. Ethics Statement This work presents S AT I R, a clinical trial retrieval system for improving clinical trial re- trieval for patients. Because such systems operate in a high-stakes medical domain, ethical considerations are important. Use of synthetic patient data.Although we use real clinical trial listings, all patient records used in S AT I R are synthetically generated and do not correspond to real individuals. Thus, this work does not involve human subject data or raise patient privacy concerns. Use of LLMs. Large language models were used only in an assistive role, including improving the writing of the manuscript and supporting development of the backend, clinical interface, and project website. All such outputs were reviewed and validated by the authors, who take full responsibility for the final paper and system. References Clark Barrett and Cesare Tinelli. Satisfiability modulo theories. In Handbook of model checking, p. 305–343. Springer, 2018. Mette Brøgger-Mikkelsen, Zarqa Ali, John R Zibert, Anders Daniel Andersen, and Si- mon Francis Thomsen. Online patient recruitment in clinical trials: systematic review and meta-analysis. Journal of medical Internet research, 22(11):e22179, 2020. ClinicalTrials.gov. ClinicalTrials.gov.https://clinicaltrials.gov/. U.S. National Library of Medicine. Accessed: 2026-03-07. Edgar F Codd. A relational model of data for large shared data banks. Communications of the ACM, 13(6):377–387, 1970. Jacob Cohen. A coefficient of agreement for nominal scales. Educational and psychological measurement, 20(1):37–46, 1960. David C. Cooper. Theorem proving in arithmetic without multiplication. In Bernard Meltzer and Donald Michie (eds.), Machine Intelligence 7, p. 91–99. Edinburgh University Press, 1972. Leonardo de Moura and Nikolaj Bjørner. Z3: An efficient SMT solver. In Tools and Algorithms for the Construction and Analysis of Systems, volume 4963 of Lecture Notes in Computer Science, p. 337–340. Springer, 2008. Pritam Deka, Anna Jurek-Loughrey, and Deepak Padmanabhan. Improved methods to aid unsupervised evidence-based fact checking for online health news. Journal of Data Intelligence, 3(4):474–505, 2022. Mira Desai. Recruitment and retention of participants in clinical studies: critical issues and challenges, 2020. Mark Dredze, Paul McNamee, Delip Rao, Adam Gerber, and Tim Finin. Entity disambigua- tion for knowledge base population. In Proceedings of the 23rd International Conference on Computational Linguistics (Coling 2010), p. 277–285, 2010. Luyu Gao, Aman Madaan, Shuyan Zhou, Uri Alon, Pengfei Liu, Yiming Yang, Jamie Callan, and Graham Neubig. Pal: Program-aided language models. In International conference on machine learning, p. 10764–10799. PMLR, 2023. 11 Preprint. Under review. Megan E Gregory, Elise Russo, and Hardeep Singh. Electronic health record alert-related workload as a predictor of burnout in primary care providers. Applied clinical informatics, 8(03):686–697, 2017. Yu Gu, Robert Tinn, Hao Cheng, Michael Lucas, Naoto Usuyama, Xiaodong Liu, Tristan Naumann, Jianfeng Gao, and Hoifung Poon. Domain-specific language model pretraining for biomedical natural language processing. ACM Transactions on Computing for Healthcare (HEALTH), 3(1):1–23, 2021. Kilem Li Gwet. Computing inter-rater reliability and its variance in the presence of high agreement. British Journal of Mathematical and Statistical Psychology, 61(1):29–48, 2008. Yucheng Jiang, Yijia Shao, Dekun Ma, Sina Semnani, and Monica Lam. Into the unknown unknowns: Engaged human learning through participation in language model agent conversations. In Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing, p. 9917–9955, 2024. Qiao Jin, Zifeng Wang, Charalampos S. Floudas, Fangyuan Chen, Changlin Gong, Dara Bracken-Clarke, Elisabetta Xue, Yifan Yang, Jimeng Sun, and Zhiyong Lu. Matching patients to clinical trials with large language models. Nature Communications, 15(1):9074, 2024. doi: 10.1038/s41467-024-53081-z. Bevan Koopman and Guido Zuccon. A test collection for matching patients to clinical trials. In Proceedings of the 39th International ACM SIGIR Conference on Research and Development in Information Retrieval, p. 669–672. ACM, 2016. doi: 10.1145/2911451.2914672. Mingyu Lee, Kyuri Kim, Yoojin Shin, Yoonji Lee, and Tae-Jung Kim. Advancements in electronic medical records for clinical trials: Enhancing data management and research efficiency. Cancers, 17(9):1552, 2025. Fangyu Liu, Ehsan Shareghi, Zaiqiao Meng, Marco Basaldella, and Nigel Collier. Self- alignment pretraining for biomedical entity representations. In Proceedings of the 2021 conference of the North American chapter of the association for computational linguistics: human language technologies, p. 4228–4238, 2021. Theo X. Olausson, Alex Gu, Ben Lipkin, Cedegao E. Zhang, Armando Solar-Lezama, Joshua B. Tenenbaum, and Roger P. Levy. Linc: A neurosymbolic approach for logi- cal reasoning by combining language models with first-order logic provers. In Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing (EMNLP), p. 5153–5176, 2023. doi: 10.18653/v1/2023.emnlp-main.313. URLhttps://arxiv.org/abs/ 2310.15164. OpenAI. Introducing gpt-4.1 in the api.https://openai.com/index/gpt-4-1/, April 2025. OpenAI announcement. Liangming Pan, Alon Albalak, Xinyi Wang, and William Yang Wang. Logic-lm: Empowering large language models with symbolic solvers for faithful logical reasoning. In Findings of the Association for Computational Linguistics: EMNLP 2023, p. 3806–3824, 2023. doi: 10.18653/v1/2023.findings-emnlp.248. URL https://arxiv.org/abs/2305.12295. Liana Patel, Siddharth Jha, Melissa Pan, Harshit Gupta, Parth Asawa, Carlos Guestrin, and Matei Zaharia. Semantic operators: a declarative model for rich, ai-based data processing. arXiv preprint arXiv:2407.11418, 2024. Yijia Shao, Yucheng Jiang, Theodore Kanell, Peter Xu, Omar Khattab, and Monica Lam. Assisting in writing wikipedia-like articles from scratch with large language models. In Proceedings of the 2024 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers), p. 6252– 6278, 2024. Aaditya Singh, Adam Fry, Adam Perelman, Adam Tart, Adi Ganesh, Ahmed El-Kishky, Aidan McLaughlin, Aiden Low, AJ Ostrow, Akhila Ananthram, et al. Openai gpt-5 system card. arXiv preprint arXiv:2601.03267, 2025. 12 Preprint. Under review. SNOMED International. SNOMED CT Managed Service - US Edition Release Notes - March 2019.https://conf.spaces.snomed.org/wiki/spaces/RMT/pages/131957448/SNOMED+ CT+Managed+Service+-+US+Edition+Release+Notes+-+March+2019, 2019. Accessed: 2026- 03-26. SNOMED International. Snomed ct concept model: An overview.https://confluence. ihtsdotools.org/display/DOCTSG/Concept+Model+-+An+Overview , 2025a.Accessed: 2025-08-12. SNOMED International.SNOMED CT Expression Constraint Language: Specifica- tion and Guide, 2025b.URLhttps://docs.snomed.org/snomed-ct-specifications/ snomed-ct-expression-constraint-language. Accessed: 2026-04-01. David Wendler. The inevitability and ethics of inaccurate screening in clinical trials: A call for research and guidance. Ethics & human research, 43(4):37–44, 2021. Shitao Xiao, Zheng Liu, Peitian Zhang, Niklas Muennighoff, Defu Lian, and Jian-Yun Nie. C-pack: Packed resources for general chinese embeddings. In Proceedings of the 47th international ACM SIGIR conference on research and development in information retrieval, p. 641–649, 2024. Ran Xu, Wenqi Shi, Yue Yu, Yuchen Zhuang, Yanqiao Zhu, May Dongmei Wang, Joyce C Ho, Chao Zhang, and Carl Yang. Bmretriever: Tuning large language models as better biomedical text retrievers. In Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing, p. 22234–22254, 2024. Zhicheng Zheng, Fangtao Li, Minlie Huang, and Xiaoyan Zhu. Learning to link entities with knowledge base. In Human Language Technologies: The 2010 Annual Conference of the North American Chapter of the Association for Computational Linguistics, p. 483–491, 2010. 13 Preprint. Under review. Appendix This appendix is organized into six parts. 1. Experimental results and evaluation. Presents aggregate and per-patient results, re- trieval objectives, the annotation interface, clinician review details, failure-case analysis, and experimental settings. 2.Representation and subsumption. Describes subsumption rules, qualifier handling, and the relation vocabularies used in the system. 3.Semantic parsing. Covers requirement preprocessing, canonicalization, SMT program- ming, repair, and patient-side semantic parsing. 4.Database retrieval details. Explains how symbolic constraints are prepared, projected, and executed in the database. 5. Others. Includes: (a) Limitations. Discusses limitations of the current system. (b) Natural-language matching. Describes the auxiliary natural-language matching component. (c)Example SMT program. Provides an example SMT program produced by our semantic parser. 6. Prompts. Lists the prompts used throughout the system. A Experimental Results and Evaluation16 A.1 Relevant Experimental Results . . . . . . . . . . . . . . . . . . . . . . . . . .16 A.2 Retrieval Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 A.3 Clinician Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 A.4 Failure Case Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 A.5 Experimental Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 B Symbolic Representation and Subsumption30 B.1 Patient-Side Implementation of Subsumption Relationships . . . . . . . . .30 B.2 Enriching Constraints with Qualifier Subsumption Relations . . . . . . . . .41 B.3 Relation Vocabularies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41 C Text Preprocessing and Semantic Parsing45 C.1 Requirement Preprocessing: Extended Description (Trial-Side Semantic Parsing)45 C.2 Entity Canonicalization Details (Trial-Side Semantic Parsing) . . . . . . . . .50 C.3 SMT Programming Details: Incremental Orchestration (Trial-Side Semantic Parsing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54 C.4LLM-Orchestrated Repair of Trial-Side SMT Programs (Trial-Side Semantic Parsing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59 C.5 Recovering Positive Canonical Literals from Trial Logic (Trial-Side Semantic Parsing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62 C.6 Disease List Processing and Canonicalization for Trial Target Conditions . .63 C.7 Patient-Side Semantic Parsing Pipeline . . . . . . . . . . . . . . . . . . . . . .65 C.8 Patient-side time intervalization . . . . . . . . . . . . . . . . . . . . . . . . . .67 14 Preprint. Under review. C.9 Patient-side inference modules . . . . . . . . . . . . . . . . . . . . . . . . . .68 D Database Retrieval Details69 D.1Database Preparation for Retrieval and High-Level Execution Flow of Retrieval69 D.2 Projected CNF Storage and SQL-Style Retrieval Execution . . . . . . . . . .70 D.3 Why the Retriever Has Full Recall . . . . . . . . . . . . . . . . . . . . . . . .74 E Others76 E.1 Limitations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76 E.2 Natural-Language Trial–Patient Matching . . . . . . . . . . . . . . . . . . . .76 E.3 An Example of the SMT Semantic Parser Output . . . . . . . . . . . . . . . .77 F Prompts97 F.1Prompts for Trial-Side Semantic Parsing . . . . . . . . . . . . . . . . . . . . .97 F.2Prompts for Patient-Side Semantic Parsing . . . . . . . . . . . . . . . . . . . 192 F.3Prompts for Trial-Side Salience-Based Constraint Augmentation . . . . . . . 216 F.4Prompts for Patient-Side Inferential Constraint Augmentation . . . . . . . . 219 F.5Prompts for Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 15 Preprint. Under review. A Experimental Results and Evaluation A.1 Relevant Experimental Results This appendix provides a comprehensive view of retrieval performance across multiple eval- uation settings and granularities. We first present the primary evaluation results, including macro-level recall, pairwise patient-level comparisons, and per-patient visualizations, which together characterize both aggregate performance and the distribution of useful retrieved trials across patients. These analyses highlight how retrieval utility varies across objectives and baselines and where the gains of S AT I R arise. We then report dataset-faithful results based on annotated qrels, including weighted preci- sion and recall under a shared retrieval budget, as well as fine-grained comparisons across individual baseline configurations. This setting provides a controlled evaluation that com- plements the primary results by isolating the effects of retrieval coverage and precision under standardized annotations. A.1.1 Aggregate and Per-Patient Results ObjectiveBMRet ClinBest S-PubMedB BGE PubMedBTGS AT I R treat-chief50.4951.1364.6868.8166.1870.1493.68 treat-any41.6644.4252.4053.5155.2656.5085.53 relevant-to-any49.8848.5665.3166.0468.6969.2384.52 Table 4: Macro recall against the pooled union of relevant-and-eligible trials found by all compared methods. Per-patient recall is averaged within each objective. Subobjective rows are collapsed by column-wise maximum, and baseline variants are collapsed by row-wise maximum. Abbreviations: BMRet = BMRetriever; ClinBest = best clinician-keyword variant; S-PubMedB = SapBERT-PubMedBERT; BGE = BGE-large-en-v1.5; PubMedB = PubMedBERT; TG = TrialGPT. Macro recall. Table 4 shows the macro recall. It demonstrates that S AT I R substantially outperforms all baselines across all three retrieval objectives. The improvement is partic- ularly pronounced under the chief-complaint treating objective, where S AT I R achieves near-complete coverage of the pooled relevant-and-eligible trial set. Similar trends hold for the any-condition treating and any-condition relevant objectives, where S AT I R consistently achieves large margins over both dense retrieval models and TrialGPT. Notably, even after selecting the best-performing TrialGPT variant across objective-aware and objective-agnostic prompting strategies and across GPT-4.1 and GPT-5, the gap remains significant. This indi- cates that the gains of S AT I R are not attributable to baseline prompt configuration choices, but reflect a fundamental improvement in retrieval effectiveness. Per-patient utility decomposition. Figure 5 decomposes, for each patient, the useful re- trieved trials into three disjoint subsets: trials retrieved by both methods (overlap), trials retrieved only by S AT I R, and trials retrieved only by TrialGPT. S AT I R’s useful retrieval count for a patient is the sum of the overlap and S AT I R-only segments, while TrialGPT’s count is the sum of the overlap and TrialGPT-only segments. Across all three retrieval objectives, the S AT I R-only (orange) segments are consistently more prominent than the TrialGPT-only (green) segments, indicating that S AT I R retrieves additional useful trials that TrialGPT does not. At the same time, the overlap (blue) is often substantial, showing that S AT I R preserves many useful trials that TrialGPT also retrieves. The total bar height represents the union of useful trials retrieved by either method and should not be interpreted as the performance of a single system. Pairwise per-patient comparison. Figure 6 compares the per-patient number of useful retrieved trials between TrialGPT and S AT I R. Each point corresponds to one patient; points 16 Preprint. Under review. sigir-201519sigir-201423 sigir-20147sigir-20157 sigir-201524sigir-201427sigir-201421 sigir-20156 sigir-201430sigir-201518sigir-201417 sigir-20144sigir-20142 sigir-201422sigir-201425 sigir-20153 sigir-201419sigir-201424sigir-201529 sigir-20148 sigir-201520 sigir-20146sigir-20152sigir-20158sigir-20151 sigir-201515sigir-201517 sigir-20143sigir-20145sigir-20141 sigir-201429sigir-201412sigir-201414sigir-201510sigir-201522sigir-201526 sigir-20154 sigir-201413 sigir-20155 sigir-201410sigir-201411sigir-201415sigir-201416sigir-201418sigir-201420sigir-201428 sigir-20149 sigir-201511sigir-201512sigir-201513sigir-201514sigir-201516sigir-201521sigir-201523sigir-201525sigir-201527sigir-201528sigir-201530 sigir-20159 Patient IDs 0 5 10 15 20 Number of useful trials STSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTST S = SatIR, T = TrialGPT Per-patient retrieved trials chief-complaint-treating OverlapSatIR onlyTrialGPT only (a) Chief complaint treating sigir-201519sigir-201423 sigir-20157sigir-20146sigir-20147 sigir-201430 sigir-20141 sigir-201524 sigir-20156sigir-20154 sigir-201515sigir-201421sigir-201518sigir-201417sigir-201520sigir-201427 sigir-20144 sigir-201425 sigir-20143 sigir-201529 sigir-20142sigir-20158sigir-20145sigir-20151sigir-20152 sigir-201429sigir-201422sigir-201424sigir-201419 sigir-20148sigir-20153 sigir-201517sigir-201526sigir-201530sigir-201412 sigir-20155 sigir-201416sigir-201522sigir-201413sigir-201511sigir-201420sigir-201523sigir-201410sigir-201411sigir-201414sigir-201415sigir-201418sigir-201428 sigir-20149 sigir-201510sigir-201512sigir-201513sigir-201514sigir-201516sigir-201521sigir-201525sigir-201527sigir-201528 sigir-20159 Patient IDs 0 5 10 15 20 25 Number of useful trials STSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTST S = SatIR, T = TrialGPT Per-patient retrieved trials any-condition-treating OverlapSatIR onlyTrialGPT only (b) Any condition treating sigir-201519sigir-201423sigir-201515sigir-201430 sigir-20141sigir-20154 sigir-201518sigir-201421 sigir-20157 sigir-201524sigir-201429 sigir-20156sigir-20153sigir-20147sigir-20145sigir-20142sigir-20146sigir-20152 sigir-201417sigir-201520sigir-201425sigir-201517sigir-201424sigir-201427 sigir-20143 sigir-201422sigir-201413sigir-201529 sigir-20148 sigir-201420sigir-201512sigir-201526 sigir-20158sigir-20144 sigir-201412sigir-201514 sigir-20151 sigir-201523sigir-201419 sigir-20159 sigir-201415sigir-201418sigir-201511sigir-201414sigir-201516 sigir-20149 sigir-201513sigir-201521sigir-201530sigir-201525 sigir-20155 sigir-201416sigir-201522sigir-201527sigir-201410sigir-201411sigir-201428sigir-201510sigir-201528 Patient IDs 0 10 20 30 40 50 Number of useful trials STSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTSTST S = SatIR, T = TrialGPT Per-patient retrieved trials any-condition-relevant OverlapSatIR onlyTrialGPT only (c) Any condition relevant Figure 5: Per-patient comparison of the numbers of retrieved relevant and eligible trials under the three retrieval objectives between S AT I R and TrialGPT with GPT-5. 17 Preprint. Under review. 01020304050 # TrialGPT-Retrieved Useful Trials 0 10 20 30 40 50 # SatIR-Retrieved Useful Trials SatIR>TrialGPT: 35/59 Equal: 17/59 SatIR<TrialGPT: 7/59 SatIR vs TrialGPT any-condition-relevant (a) Any-condition relevant 0510152025 # TrialGPT-Retrieved Useful Trials 0 5 10 15 20 25 # SatIR-Retrieved Useful Trials SatIR>TrialGPT: 29/59 Equal: 28/59 SatIR<TrialGPT: 2/59 SatIR vs TrialGPT any-condition-treating (b) Any-condition treating 048121620 # TrialGPT-Retrieved Useful Trials 0 4 8 12 16 20 # SatIR-Retrieved Useful Trials SatIR>TrialGPT: 20/59 Equal: 33/59 SatIR<TrialGPT: 6/59 SatIR vs TrialGPT chief-complaint-treating (c) Chief-complaint treating Figure 6: Per-patient scatter plots comparing TrialGPT retrieval with GPT-5 and S AT I R under three retrieval objectives. above the diagonal indicate patients for whom S AT I R retrieves more useful trials, points on the diagonal indicate ties, and points below the diagonal indicate patients for whom TrialGPT retrieves more useful trials. Across all three objectives, most points lie above or on the diagonal, indicating that S AT I R matches or exceeds TrialGPT for the majority of patients. Points below the diagonal are relatively few and typically close to parity, suggesting that cases where TrialGPT retrieves more useful trials are limited. Summary.Together, these figures show that the improvements of S AT I R arise from consis- tently retrieving additional useful trials across patients while retaining much of the shared set identified by TrialGPT. The gains are not driven by a small number of outlier patients, but reflect a broad shift in per-patient useful retrieval counts under all retrieval objectives. A.1.2 Results Against the Original Benchmark Labels Why these results are limited.For completeness, we also report results against the original SIGIR 2016 benchmark labels. In that dataset, judged patient–trial pairs receive label 0 (not relevant), 1 (possible referral), or 2 (highly possible referral). However, the labels were obtained through pooled, budget-limited judging, so many pairs were never assessed; unjudged pairs therefore cannot be treated as negatives. In addition, these labels are not tied to an explicit retrieval objective like ours, which requires a trial to be both relevant under a stated objective and eligible for the patient. We therefore treat this section as a comparison to the original benchmark labels, not as our primary evaluation. Precision against the original labels. Table 5 reports weighted precision over retrieved patient–trial pairs that received original benchmark labels. Across all three objectives, S AT I R achieves the highest precision. That is, among retrieved pairs that were judged in the benchmark, a larger fraction of S AT I R’s results receive stronger original labels. Relative to the baselines, including the strongest TrialGPT configuration, S AT I R is therefore more selective: under the same retrieval budget, it concentrates more highly rated benchmark pairs in its returned set. Recall against the original labels.Table 6 reports micro recall against the original bench- mark labels, with label 1 and label 2 treated as positive judgments. Under this metric, S AT I R does not achieve the highest recall; some dense-retrieval and TrialGPT-based baselines score higher. This result should be interpreted with caution. Because the benchmark labels are pooled and incomplete, this recall measures recovery of the subset of pairs that happened to be judged, not of all truly relevant patient–trial pairs. It therefore does not directly measure our main task: retrieving trials that are both relevant under an explicit objective and eligible 18 Preprint. Under review. ObjectiveRet./pt. ClinBestTGBGE S-PubMedB PubMedB BMRet S AT I R treat-chief360.2890.328 0.3320.3300.3370.3510.400 treat-any640.2840.310 0.3120.3130.3130.3340.376 relevant-to-any1210.2710.292 0.2930.2980.2930.3200.385 Table 5: Weighted precision on retrieved patient–trial pairs with original benchmark labels (micro, normalized to[0, 1]). Baselines are aggregated by family using row-wise maximum within each grouped family, and subcohort rows are collapsed by column-wise maximum. The highest value in each row is bolded. for the patient. Higher recall on the original 0/1/2 labels thus does not necessarily imply better performance for our setting. Taken together, these results suggest that S AT I R trades benchmark-label recall for higher selectivity, returning fewer judged pairs but concentrating more strongly labeled ones. ObjectiveRet./pt. BMRet ClinBest S-PubMedB BGETGPubMedB S AT I R treat-chief360.2960.4630.4750.500 0.4900.5020.420 treat-any640.4180.6220.6540.673 0.6740.6690.457 relevant-to-any1210.5990.7470.8100.832 0.8460.8400.763 Table 6: Micro recall against the original benchmark labels at the shared retrieval budget, with positive judgments weighted by label strength (1 and 2). Baselines are aggregated by family using row-wise maximum within each grouped family, and subcohort rows are collapsed by column-wise maximum. The highest value in each row is bolded. 19 Preprint. Under review. A.2 Retrieval Objectives This appendix defines the retrieval objectives used in our system and explains how relevance is determined under each one. The objectives differ in how narrowly they connect a trial to the patient’s clinical needs, from a tight focus on the chief complaint to a broader notion of clinical relatedness. Objective 1: Chief-Complaint Treating (treat-chief).This is the strictest objective. A trial is relevant only if it is aimed at treating the patient’s chief complaint, a meaningful higher-level form of that complaint, or an important direct cause whose treatment would substantially relieve it. The standard is intentionally narrow: the condition must be one a patient would realistically search for in order to address the chief complaint. This objective also includes trials that improve procedures the patient is expected to undergo for treating the chief complaint, but only when the improvement supports treatment of the complaint itself rather than secondary issues such as side effects. Preventive trials are included only when they target diseases explicitly mentioned in the patient note or near- universal downstream outcomes of an existing condition, and only when those diseases are not already present. Objective 2: Any Condition Treating (treat-any).This objective broadens the scope from the chief complaint to any condition the patient currently has and might reasonably want treated. A trial is relevant if it aims to treat such a condition and the condition is explicitly supported by the patient note rather than inferred. As in the first objective, preventive trials are included only for explicitly stated risks or near- universal downstream outcomes of existing conditions. Compared with the chief-complaint objective, this objective retrieves a wider set of treatment opportunities while still requiring clear therapeutic intent. Objective 3: Any Condition Relevant (relevant-to-any).This is the broadest objective. A trial is relevant if it is meaningfully related to any condition the patient currently has or is being evaluated for, even if the trial is not directly treating that condition. To keep this broad objective clinically meaningful, relevance must be based on the trial’s real clinical target, not on superficial overlap such as shared symptoms, care settings, or diagnostic workup. The patient must clearly have, or be under evaluation for, the condition targeted by the trial; speculative upgrades to a more specific diagnosis are not allowed. Summary.The three objectives form a spectrum. The first is narrowly focused on treating the chief complaint. The second expands to treating any condition the patient has. The third further broadens the scope to include clinically related trials, while still enforcing safeguards against weak or spurious matches. Together, these objectives let us study different precision– recall trade-offs in clinical trial retrieval. The prompt implementations of the three retrieval objectives can be found in Appendix F.5.1. 20 Preprint. Under review. A.3 Clinician Review A.3.1 User Interface for Clinician Annotation In this section, we show screenshots (Figure 7, 8, 9, 10, 11) of the user interface we provide to clinicians for their annotation. Clinicians are presented with a patient note, a clinical trial description, and the predefined relevance criteria, along with a pre-existing relevance judgment and its associated rationale. Their task is to evaluate this provided judgment. Clinicians are asked to indicate whether they agree, disagree, or are uncertain about the given decision, and to provide a brief explanation supporting their assessment. This design allows us to validate both the correctness of the decision and the quality of its justification, while maintaining consistency across annotations. The Clinicians’ annotation results are present in Section A.3.2. Figure 7: Clinician annotation interface screenshots (1/5): Login Page Figure 8: Clinician annotation interface screenshots (2/5): Overview Page 21 Preprint. Under review. Figure 9: Clinician annotation interface screenshots (3/5): Data Point Page (1/3) Figure 10: Clinician annotation interface screenshots (4/5): Data Point Page (2/3) 22 Preprint. Under review. Figure 11: Clinician annotation interface screenshots (5/5): Data Point Page (3/3) A.3.2 Full Clinician Review Details Physician-validation sampling. To validate the LLM judge, we constructed a physician- review sample by stratified random sampling from the union of judged patient–trial pairs produced by S AT I R and TrialGPT. The sampling unit was a tuple(m,p,t), wheremdenotes the retrieval objective (treat-chief,treat-any, orrelevant-to-any),pthe patient, andtthe trial. We first took the union of all judged tuples appearing in either system’spatient_labels outputs, collapsing duplicates across systems. Each union item was then assigned to one of three judgment buckets according to the LLM judge outcome: relevant-and-eligible, relevant- but-ineligible, or not relevant. We then applied balanced allocation: the total sample was distributed as evenly as possible across retrieval objectives and, within each objective, as evenly as possible across the three judgment buckets. If a stratum contained fewer items than its target allocation, it was capped at its population size and the remaining quota was redistributed to other strata with available capacity. Sampling within each stratum was uniform at random with a fixed random seed. A.3.3 Gwet’s AC1 Calculation. We compute inter-rater agreement using Gwet’s AC1 withN =27 items and three categories. The observed agreement isP o = 23 27 ≈ 0.852. The average marginal category probabilities arep accept = 25/27+24/27 2 = 49 54 ,p uncertain = 1 27 , andp reject = 1/27+2/27 2 = 1 18 . The chance agreement isP e =1− ∑ k p 2 k =1− 49 54 2 + 1 27 2 + 1 18 2 ≈0.172. Thus,AC1 = P o −P e 1−P e = 0.852−0.172 1−0.172 ≈ 0.82. A.4 Failure Case Analysis In this appendix, we present a structured analysis of failure cases described in Section 7. These cases were manually reviewed and categorized to better understand the sources of error across different stages of the system. Failure case analysis.Figure 12 and Figure 13 summarize the distribution of failure cases across three perspectives. The left pie chart compares disagreement sources between the 23 Preprint. Under review. LLM judge and S AT I R, showing that the majority of discrepancies are attributed to our system, with a smaller portion due to judge errors or ambiguous interpretation. The middle pie chart separates failure modes into missed retrievals (no hit) versus retrieved but ineligible trials, indicating that most failures arise from not retrieving relevant candidates rather than eligibility misclassification. The right pie chart breaks down the sources of errors within S AT I R, revealing that mistakes are distributed across patient-side parsing, trial-side parsing, salience handling, and inherent system limitations, with no single dominant failure mode. 1.1.2.3 Concept Coding 1.1.2.4 Schematization 1.1.2.2.1 Fact Coding 1.1.2.2.2 Fact Schematization C. Concept Coding V. Schematization A. Fact Coding B. Fact Schematization Figure 12: Failure case categories. Observed failure cases are organized into a hierarchical taxonomy. This taxonomy is used to label and analyze all failure cases reported in Table 7. Figure 13: Failure case pie charts. The pie charts summarize the distribution of failure cases reported in Table 7. Table 7 reports the full set of analyzed failure cases. Each row corresponds to a patient– trial example and includes the retrieval mode, patient identifier, trial identifier, a concise description of the failure, and its assigned category based on the taxonomy in Figure 12. Table 7: Full failure case table #ModePatientTrialDescriptionCat. 1treat-chief sigir-20141NCT01397175not hit. The trial has target Coronary arteriosclerosis (disorder). ACS wasn’t salience expanded to Coronary arteriosclerosis (disorder) 1.1.2.2.2 2treat-chief sigir-20147NCT00203450The patient should be excluded because the patient is suicidal, and being suicidal is an exclusion criterion 2.1.2 3treat-chief sigir-20147NCT00290914Trial target is Major Depressive Disorder, The patient has depressive disorder. But Major Depressive Disorder is not salience-expanded to depressive disorder 1.1.2.1 4treat-chief sigir-20157NCT00946413Community Adolescents at Risk for Depression and Suicide should actually be processed as suicidal or suicidal thought instead of this weird finding concept 1.1.2.3 Continued on next page 24 Preprint. Under review. Table 7 – continued from previous page #ModePatientTrialDescriptionCat. 5treat-chief sigir-201417NCT01188993observational/assessment study on septic shock (which patient is inferred to have), not treating 1.2 6treat-chief sigir-201419NCT00826813 patient_has_diagnosis_of_primary_malignant_neoplasm_of_esophagus is not satisfied by the patient. patient has pa- tient_has_diagnosis_of_neoplasm_of_esophagus 1.1.2.1 7treat-chief sigir-201421NCT00430677patient_has_undergone_kidney_biopsy, which is a logistical procedure require- ment, is explicitly required 2.2.1.2 8treat-chief sigir-201422NCT00908804Age over 15 years is coded as > 15 years not >= 15 years, resulting in requirement contradiction because the patient is exactly 15 years old 2.1.1.1.1 9treat-chief sigir-201423NCT01561794Trial treats secondary infection of the chronic disease, which is not really directly chief-complaint-related. 1.2 10treat-chief sigir-201424NCT02297659 The patient has trauma, and is inferred to likely to undergo damage control laparotomy, this trial tests hypertonic saline to improve primary fascial closure after DCL. This is not directly treating chief complaint 1.2 11treat-chief sigir-201427NCT01584817The trial is about telephone education for patients undergoing colonoscopy, which is indirectly related to treating the patient’s chief complaint (multiple colonic adenomas) 1.2 12treat-chief sigir-201427NCT02538406 The trial improves the effectiveness of screening colonoscopy, but we didn’t include the part where we infer what procedure the patient needs to undergo 1.1.4 13treat-chief sigir-201430NCT02273232The trial asks for intermittent claudication but we failed to code / infer that from the patient side 2.2.1.4 14treat-chief sigir-201430NCT02436200The trial asks for intermittent claudication but we failed to code / infer that from the patient side 2.2.1.4 15treat-chief sigir-201517NCT00461760Disease list has Cervical Cancer Screening coded, not Cervical Cancer1.1.2.3 16treat-chief sigir-201518NCT00012818The trial is about treating chronic heart failure, the patient most likely has congestive heart failure 1.2 17treat-chief sigir-201518NCT00971386The trial is about treating chronic heart failure, the patient most likely has congestive heart failure 1.2 18treat-chief sigir-201519NCT02182856patient_has_finding_of_acute_exacerbation_of_chronic_obstructive_airways_disease is an exclusion requirement 2.1.2 19treat-chief sigir-201520NCT00001776 Behavioral therapy improving frontal lobe dementia, but we didn’t count it as directly treating. May be our target schematization issue or LLM judge issue, depending on what we mean by "directly treating". 1.1.2.2.2 20treat-chief sigir-201529NCT00000520Bug. Actually categorized to clinically address Kawasaki, but there is a conflict from the positive literal side, so joined on the positive literal hit instead of disease. 1.1.6 21treat-anysigir-20143NCT00124761patient_has_diagnosis_of_widespread_metastatic_malignant_neoplastic_disease is required, but this is unlikely to be coded in any patient note, so it is a whole-fact salience defaulting issue 2.2.1.2 22treat-anysigir-20146NCT01307644Obesity didn’t get kept as a target, it was original in the trial listing.1.1.2.3 23treat-anysigir-20157NCT00946413Community Adolescents at Risk for Depression and Suicide should actually be processed as suicidal or suicidal thought instead of this weird finding concept 1.1.2.3 24treat-anysigir-201414NCT00311753 Trial is about prevention of venous thromboembolism, we didn’t code VTE as a prevention target, so lack of clincal inference 1.1.4 25treat-anysigir-201417NCT01188993observational/assessment study on septic shock (which patient is inferred to have), not treating 1.2 26treat-anysigir-201419NCT00826813patient_has_diagnosis_of_primary_malignant_neoplasm_of_esophagus is not satisfied by the patient. patient has pa- tient_has_diagnosis_of_neoplasm_of_esophagus 1.1.2.1 27treat-anysigir-201420NCT01729559Trial is about prevention of venous thromboembolism, we didn’t code VTE as a prevention target, so lack of clincal inference 1.1.4 28treat-anysigir-201420NCT01787773 Trial is about prevention of venous thromboembolism, we didn’t code VTE as a prevention target, so lack of clincal inference 1.1.4 29treat-anysigir-201421NCT00001676 excludes for patient_has_diagnosis_of_disorder_of_cellular_component_of_blood, the patient does have that. but trial actually excludes with more specific numerical criteria. In my opinion this patient should still be excluded 2.1.2 30treat-anysigir-201424NCT01276561trial enhacing laparoscopic splenectomy which we don’t infer for this trauma patient but we can (we have the module but did’t integrate) 1.1.4 31treat-anysigir-201430NCT02273232 The trial asks for intermittent claudication but we failed to code / infer that from the patient side 2.2.1.4 32treat-anysigir-201430NCT02436200The trial asks for intermittent claudication but we failed to code / infer that from the patient side 2.2.1.4 33treat-anysigir-201517NCT00461760Disease list has Cervical Cancer Screening coded, not Cervical Cancer1.1.2.3 34treat-anysigir-201520NCT00001776 Behavioral therapy improving frontal lobe dementia, but we didn’t count it as directly treating. May be our target schematization issue or LLM judge issue, depending on what we mean by "directly treating". 1.1.2.2.2 35treat-anysigir-201520NCT00024908Trial is designed to improve planning or social behavior of CNS paitents. Doesn’t treat any of the patient’s complaint directly 1.2 36treat-anysigir-201520NCT02212119This trial directly targets a current complaint: paratonic rigidity in a fully depen- dent patient with severe cognitive impairment. But neither the trial target codes this nor the patient codes this. Both have dementia coded though. So it is more like a clinical inference probelm 1.1.4 Continued on next page 25 Preprint. Under review. Table 7 – continued from previous page #ModePatientTrialDescriptionCat. 37treat-anysigir-201522NCT01887457Bug.1.1.6 38treat-anysigir-201529NCT00000520Bug. Actually categorized to clinically address Kawasaki, but there is a conflict from the positive literal side, so joined on the positive literal hit instead of disease. 1.1.6 39relevant- to-any sigir-20141NCT01171911 patient_has_diagnosis_of_non_q_wave_myocardial_infarction not specificity- expanded to myocardial infarction 1.1.2.1 40 relevant- to-any sigir-20143NCT00001776frontal lobe lesion didn’t get coded as a target1.1.2.3 41 relevant- to-any sigir-20143NCT00124761 patient_has_diagnosis_of_widespread_metastatic_malignant_neoplastic_disease is required, but this is unlikely to be coded in any patient note, so it is a whole-fact salience defaulting issue 2.2.1.2 42relevant- to-any sigir-20143NCT00303901patient_has_finding_of_serious_physical_health_problem assumed but should not be defauled as this is unlikely to be coded 2.2.1.2 43relevant- to-any sigir-20143NCT01566682Trial asks for single/multiple lung nodules, didn’t get coded from the patient side though should be strongly inferred. We can only entail nearby concepts from current patient facts 1.1.1 44relevant- to-any sigir-20147NCT00563992patinet has suicidal thoughts but trial asks for suicidal behavior2.2.2 45relevant- to-any sigir-20147NCT01784666bipolar I disorder, current episode depressed and bipolar I disorder, most recent episode depressed are ontology siblings and they show up on both patient and trial sides. Ideally on patient side we should also have most recent episode depressed as alternatives but we didn’t consider siblings 1.1.1 46relevant- to-any sigir-20154NCT01076738Acute coronary syndrome (disorder) didn’t get coded on the patient side, what we have is Acute myocardial infarction which is an ontological sibling 2.2.1.4 47relevant- to-any sigir-201410NCT01599195Trial side has carotid bruit, but carotid bruit is not salience alternative lifted to just bruit, which is coded on the patient side 1.1.2.1 48 relevant- to-any sigir-201414NCT01075035 Trial-side traumatic brain injury not lifted to patient-side traumatic injury by specificity-salience expansion 1.1.2.1 49 relevant- to-any sigir-201414NCT01196299Trial-side traumatic brain injury not lifted to patient-side traumatic injury by specificity-salience expansion 1.1.2.1 50 relevant- to-any sigir-201417NCT01188993Trial-side septic shock not specificity-salience expanded to patient-side shock1.1.2.1 51relevant- to-any sigir-201417NCT01231672patient_has_finding_of_disturbance_of_consciousness whole-fact salient, but should not be 2.2.1.2 52relevant- to-any sigir-201420NCT01729559Trial is about prevention of venous thromboembolism, we didn’t code VTE as a prevention target, so lack of clincal inference 1.1.4 53relevant- to-any sigir-201421NCT01031797patient_has_finding_of_ecg_normal assumed whole fact salient2.2.1.2 54relevant- to-any sigir-201423NCT01785706polarity flip of patient age requirement2.1.1.1.1 55relevant- to-any sigir-201424NCT01103999patient_has_diagnosis_of_contusion_of_spleen, whole fact salient be actually cannot be inferred (too specific salient) 2.2.2 56 relevant- to-any sigir-201425NCT00452036patient_has_finding_of_nausea whole fact salient but not coded. He clearly has head injury and vomiting, but the text does not explicitly say nausea. also this case does not look like minor head injury. 2.2.2 57relevant- to-any sigir-201430NCT00001368Bug. exclusion should not check for overlap but strict contaiment2.1.1.3 58 relevant- to-any sigir-201430NCT01970332patient_has_finding_of_intermittent_claudication salient but didn’t get coded2.2.1.4 59 relevant- to-any sigir-201430NCT02273232The trial asks for intermittent claudication but we failed to code / infer that from the patient side 2.2.1.4 60 relevant- to-any sigir-201430NCT02436200patient_has_finding_of_intermittent_claudication salient but didn’t get coded1.1.1 61 relevant- to-any sigir-201512NCT01646411 trial side has viral and bacterial acute infection but patient side entail acute_infection from meningitis related facts, designed to not hit 1.1.5 62 relevant- to-any sigir-201514NCT00842621coded < 19 years old for adult subcohort2.1.1.1.1 63relevant- to-any sigir-201516NCT00747981experimental issue I accidentally typed something and overwrote an entry1.1.6 64 relevant- to-any sigir-201517NCT00461760Disease list has Cervical Cancer Screening coded, not Cervical Cancer1.1.2.3 65 relevant- to-any sigir-201517NCT00520117abnormal pap results got coded but not hpv status1.1.2.3 66relevant- to-any sigir-201518NCT00133328and / or interpretation – different possiblities . not sure who’s fault it is - it is up to intepretation 2.2.3 67relevant- to-any sigir-201519NCT01628497bronchospasm didn’t get coded on patient side1.1.1 68relevant- to-any sigir-201519NCT01785706polarity flip of patient age requirement 2.1.1.1.1 69relevant- to-any sigir-201519NCT02182856 patient_has_finding_of_acute_exacerbation_of_chronic_obstructive_airways_disease is an exclusion requirement 2.1.2 Continued on next page 26 Preprint. Under review. Table 7 – continued from previous page #ModePatientTrialDescriptionCat. 70relevant- to-any sigir-201520NCT02212119 This trial directly targets a current complaint: paratonic rigidity in a fully depen- dent patient with severe cognitive impairment. But neither the trial target codes this nor the patient codes this. Both have dementia coded though. So it is more like a clinical inference probelm 1.1.4 71relevant- to-any sigir-201524NCT00428831respiratory illness should get coded but didn’t1.1.2.3 72relevant- to-any sigir-201525NCT01396798 Acutely ill children with suspected serious infection is not a common ontology medical term 1.1.5 73relevant- to-any sigir-201526NCT01261026not clear eligible / uncertain. most likely an llm judge issue because not sure if she has mass_of_uterine_adnexa 2.2.2 74relevant- to-any sigir-201528NCT01396798Acutely ill children with suspected serious infection is not a common ontology medical term 1.1.5 27 Preprint. Under review. A.5 Experimental Settings Our experiments were conducted across three machines. Patient-side semantic parsing ran on Machine 1 (Table 8). Trial-side semantic parsing, database construction and querying, and the speed and scalability experiments ran on Machine 2 (Table 9). Detailed evaluations of individual subpipelines, including preprocessing (Section C.1.8) and entity canonicaliza- tion (Section C.2.9), were performed on Machine 3 (Table 10). Pipeline development was carried out across all three machines. Table 12 summarizes the SNOMED and terminology- retrieval configuration used for ontology grounding, and Table 11 summarizes the inference configurations used for GPT-4.1 and GPT-5. ItemValue MachineMacBook Air / Mac14,15 ChipApple M2 CPU Cores8 (4 performance and 4 efficiency) GPUApple M2, 10 GPU cores, Metal 3 Memory16 GB Operating SystemDarwin 14.0 Kernel23.0.0 Python3.12.4 (CPython) JavaOpenJDK 17 Elasticsearch7.17.15 Snowstorm10.7.0 SNOMED CTSNOMED CT International RF2 2025-05-01 Key Python Packages torch=not installed, transformers=not installed, openai=not in- stalled, numpy=1.26.4, pandas=2.2.2 Table 8: Machine 1: Experimental environment. ItemValue MachineMacBook Pro / Mac14,6 ChipApple M2 Max CPU Cores12 (8 performance and 4 efficiency) GPUApple M2 Max, 38 GPU cores, Metal 3 Memory32 GB Operating SystemDarwin 13.0 Kernel22.1.0 Python3.12.2 (CPython) JavaOpenJDK 17 Elasticsearch7.17.15 Snowstorm10.7.0 SNOMED CTSNOMED CT International RF2 2025-05-01 Key Python Packages torch=2.7.1, transformers=4.52.4, openai=1.82.1, numpy=1.26.4, pandas=2.2.3 Table 9: Machine 2: Trial-side Parsing Environment, also used for speed and scalability results 28 Preprint. Under review. ItemValue MachineASUS ChipAMD Ryzen 7 9800X3D CPU Cores16 GPUNVIDIA GeForce RTX 5090 Memory60 GB Operating SystemUbuntu 24.04.2 LTS Kernel6.14.0-1020-oem Python3.12.7 (CPython) JavaOpenJDK 17 Elasticsearch7.17.15 Snowstorm10.7.0 SNOMED CTSNOMED CT International RF2 2025-05-01 Key Python Packages torch=2.9.1, transformers=4.52.4, openai=1.82.1, numpy=1.26.4, pandas=2.2.3 Table 10: Machine 3: Experimental environment SettingGPT-4.1GPT-5 Model gpt-4.1 gpt-5 Temperature0omitted Top-p0.001omitted Output-token control max_tokens max_completion_tokens Seed4242 Connect timeout10s10s Initial read timeout55s55s Read-timeout cap300s300s Max retries55 Backoffexponential full-jitterexponential full-jitter Fallback endpointoptionaloptional Table 11: Inference configurations used for the GPT-4.1- and GPT-5-based components in our experiments. For GPT-5, sampling parameters such as temperature and top-p are omitted. ItemValue Terminology serverSnowstorm 10.7.0 Ontology releaseSNOMED CT International RF2 2025-05-01 Vector index snomed_vectors Embedding model cambridgeltl/sapbert-from-pubmedbert-fulltext Fuzzy threshold0.86 Vector top-k5 Vector score cutoff0.30 Vector overshoot4 Allowed SNOMED top-level roots 363787002, 71388002, 404684003, 373873005, 105590001 Table 12: SNOMED and terminology-retrieval configuration used by the ontology grounding pipeline. 29 Preprint. Under review. B Symbolic Representation and Subsumption B.1 Patient-Side Implementation of Subsumption Relationships This appendix provides implementation details for the ontology-aware patient-side expan- sion described in Section 2. In the main text, the ontology is written asO = (R,K,Q,⊑), with ⊑=⊑ R ∪⊑ K ∪⊑ causal ∪⊑ Q . The materialization described here concerns patient-side subsumptions under⊑ K ,⊑ R , and selected SNOMED-derived⊑ causal enrichments. Before retrieval, we materialize the resulting supported patient facts, yielding an ontology-enriched patient representation used for matching against trial intents and trial-side constraints. We distinguish two complementary mechanisms. First, we materialize entailed patient facts, which become part of the patient-side symbolic representation used at retrieval time. Sec- ond, we maintain a separate relation overlay, which augments SNOMED with task-specific semantic links used as admissible alternatives during matching and debugging, but not as unconditional entailments. B.1.1 Patient-side entailment materialization Facts are represented as canonical predicates with explicit time windows and are dedupli- cated by (name, start_time_in_hours, end_time_in_hours, start_time_inclusive, end_time_inclusive). Each derived fact also carries provenance metadata, including its source fact, the triggering ontology or rule entry, derivation type, and hop depth where applicable. Materialization is implemented in a streaming, memory-safe manner with on-disk deduplication. Concept-level closure (⊑ K ). For a positive concept-grounded fact, we materialize sup- porting ancestor facts under SNOMEDis-arelations while preserving the original time window and qualifiers. For explicit negation, we optionally materialize a bounded set of negative descendants, using caps and maximum hop limits to control combinatorial growth. This stage implements the patient-side concept closure corresponding to⊑ K . Medical-relation closure (⊑ R ). We also materialize supporting facts induced by sub- sumption over medical relations. Concretely, ifr p ⊑ R r c , then a fact with predicate (r p ,k,q)supports one with predicate(r c ,k,q). These derivations preserve the grounded concept, qualifier bundle, and time window, while recording the applied relation trans- formation in provenance. This stage captures support withinO R = (R,⊑ R ), such as H A S D I A G N O S I S O F ⊑ R H A S F I N D I N G O F. Causal/dependency closure (⊑ causal ). Some medically valid supports depend jointly on the relation and grounded concept and therefore cannot be reduced to concept subsumption or medical- relation subsumption alone. To capture such cases, we materialize derived facts when (r p , k p )⊑ causal (r c , k c ). These derivations preserve source time windows and qualifiers unless a specific enrichment explicitly normalizes them. This stage corresponds to causal or dependency subsumption relations across relations and concepts derived from SNOMED definitional structure. B.1.2 Medical-relation subsumption rules (⊑ R ) Medical-relation subsumption is implemented through a curated, recall-oriented rule layer over canonical predicate templates. The full rule inventory is presented in Appendix B.1.7. Each rule captures a pattern under which one grounded patient fact should support one 30 Preprint. Under review. or more additional facts in our retrieval vocabulary. When a rule applies, the grounded conceptk, qualifier bundleq, and temporal context are preserved, while the medical relation is generalized in a controlled way. B.1.3 SNOMED-derived causal/dependency subsumption relations (⊑ causal ) The relation ⊑ causal ⊆ (R, K)× (R, K) captures cases where subsumption depends on the combination of a relation and a concept, rather than on the relation or concept alone. For this reason, it cannot be reduced to⊑ R or ⊑ K . We derive these links from SNOMED CT’s formal concept definitions. In SNOMED CT, a concept is defined using typed attributes that connect it to other concepts. Some attributes may be placed in the same relationship group, which means they should be interpreted together as part of one coherent definition. The SNOMED CT concept model, together with the machine-readable concept model (MRCM), specifies which attributes are allowed, what kinds of values they can take, and whether they are grouped. This structure lets us derive ontology-backed causal or dependency-style subsumption relations. In our implementation,⊑ causal is used in two closely related ways. For finding→procedure, we use two families of attributes. The first is the grouped pairInterprets(363714003) andHas interpretation(363713009). When a finding concept has anInterpretslink to a procedure concept, we derive a base fact that the patient underwent that procedure. If the same group also contains aHas interpretationvalue, we further refine the entailed procedure fact into a normalized status such aspositive,negative,normal, orabnormal using curated mappings. The second family includes more indirect procedure-linking attributes:During(371881003), After(255234002),Due to(42752001),Associated with(47429007), andTemporally related to(726633004). These support more conservative finding→procedure links and yield only the base procedure fact, without a normalized status. The same groupedInterprets/Has interpretationpattern also supports finding→ observable-entity entailments. For example, Acute kidney injury is defined usingInterprets →Renal function andHas interpretation→Impaired. From this, we derive an observable- entity status fact. Similarly, Postoperative hemorrhage is defined withAftersome Surgical procedure, which illustrates the more conservative attribute family that supports finding→ procedure entailment without status refinement. We also use the same ontology structure in the reverse direction, to map status facts back to finding concepts. For observable-entity-status→finding and procedure-status→finding, we retrieve candidate findings using SNOMED CT’s Expression Constraint Language (ECL) (SNOMED International, 2025b), which is SNOMED’s formal query language for searching concept sets and attribute-based definitions. Here, we use ECL to find finding concepts whose definitions include both anInterpretslink to the relevant observable entity or procedure and aHas interpretationvalue. We then keep only candidates whose definitions are fully defined and whose relevant attributes remain in the same relationship group. For example, Normal renal function is defined withInterprets= Renal function andHas interpretation= Normal, showing how an observable-entity status fact can be normalized back into a finding concept. The curated mappings that convertHas interpretationvalues into the normalized status labelspositive,negative,normal, andabnormalare shown in Tables 13 and 14. These correspond to the finding→observable-entity and finding→procedure entailment types, respectively. B.1.4Canonicalization of Qualifiers and Subsumption Relations Among Qualifiers (⊑ Q ) Inour implementation, wecanonicalizetemporalqualifiers, together with severalrecall-oriented, schema-dependentqualifier variables(AppendixB.3). Temporal qualifiers are normalized into interval representations of the form (lower bound, upper bound, lower inclusiveness, upper inclusiveness). 31 Preprint. Under review. For inclusion criteria, subsumption between temporal qualifiers is defined by overlap be- tween the criterion window and the patient’s possible fact window. For exclusion criteria, subsumption is defined more strictly: the exclusion-window requirement must strictly contain the patient fact window. The construction of patient fact windows is described in Appendix C.8. More generally, we treat the absence of a qualifier as the weakest form, so any qualifier subsumes no qualifier. B.1.5 Multi-pass closure computation We compute patient-side expansion in multiple passes to approach a fixpoint without allowing uncontrolled growth. Each pass executes a fixed sequence of stages corresponding to concept-level, relation-level, and fact-level materialization. At the end of each pass, only newly derived facts are retained as seeds for the next pass, after subtracting any fact whose deduplication key has appeared previously. This guarantees monotone growth in unique facts and ensures termination under fixed caps. After the final pass, we export the aggregated and deduplicated ontology-enriched fact set for retrieval and downstream usage. B.1.6 Relation-overlay curation In addition to the patient-side entailment structures⊑ Q ,⊑ K ,⊑ R ,⊑ causal , we curate a sep- arate relation overlay that augments SNOMED with task-specific semantic links. Unlike the entailed facts materialized above, these overlay edges are not treated as unconditional logical consequences. Instead, they are used as admissible alternatives during matching and as explanatory support during auditing and debugging. The relation overlay is intended for cases where strict ontology entailment is too narrow for practical patient–trial matching, but repeated review suggests that certain concept pairs should still be considered connected for retrieval or downstream analysis. These links therefore improve robustness without being folded into the core patient-side logical closure. We store multiple overlay relation types, each with explicit provenance: •Overlap links: clinically meaningful partial-overlap relationships between two concepts. •Synonym and near-synonym links: semantically close alternatives surfaced during concept discovery and verified by an LLM auditor. •Task bridges: curated mappings that are neitheris-anor strict synonymy, but repeatedly help connect patient phrasing or inferred patient states to trial-side requirements. The overlay is designed to capture reusable task-specific relations that are missing from the native ontology but repeatedly arise in patient–trial matching. Rather than expanding concepts through local ontology-neighborhood traversal, we focus on discovering clinically meaningful missing links that can be verified once and then reused across future patients and trials. To identify such links, we use an embedding-based discovery pipeline grounded in patient records. Starting from an existing seed set of extracted patient facts, we retrieve vector- nearest SNOMED concepts using dense retrieval over concept descriptions. These retrieved concepts serve as candidates for missing concepts or missing bridges to existing seeds. An LLM-based medical auditor then determines whether each candidate is clearly supported by the patient note and whether it should be linked to an existing concept through one of the overlay relation types. Accepted links are persisted as reusable overlay edges with note-level provenance, allowing them to support future matching beyond the originating example. We run this process for a fixed number of passes and cap both the number of candidates considered per seed and the number of newly accepted links per pass to ensure predictable runtime and conservative growth. 32 Preprint. Under review. All overlay candidates are passed through a unified verification interface and then persisted to a local SQLite store. Each stored edge includes: • edge key: (base_conceptId, candidate_conceptId, relation_type) • verifier metadata: model version, prompt hash, and timestamp • decision: accept/reject with a brief justification • provenance: associated trial identifiers and/or patient-note identifiers, together with the discovery path We cache verifier outputs so repeated runs can reuse prior judgments, and we write to the database only after successful verifier execution. Downstream components query this store to retrieve admissible alternative concepts during matching and to surface supporting explanations during debugging. B.1.7 Curated inventory of medical-relation subsumption rules (⊑ R ) This section lists the manually curated ruleset used to operationalize medical-relation subsumption. "rules": [ "id": "suspicion_implies_finding_same_time", "match_template": "patient_has_suspicion_of_e_t", "require_bool": true, "produce": [ "template": "patient_has_finding_of_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ,→ ] , "id": "suspicion_implies_diagnosis_same_time", "match_template": "patient_has_suspicion_of_e_t", "require_bool": true, "produce": [ "template": "patient_has_diagnosis_of_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ,→ ] , "id": "suspicion_implies_symptoms_same_time", "match_template": "patient_has_suspicion_of_e_t", "require_bool": true, "produce": [ "template": "patient_has_symptoms_of_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ,→ ] , "id": "diagnosis_implies_finding_same_time", "match_template": "patient_has_diagnosis_of_e_t", "require_bool": true, "produce": [ "template": "patient_has_finding_of_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ,→ ] , "id": "finding_implies_diagnosis_same_time", "match_template": "patient_has_finding_of_e_t", "require_bool": true, "produce": [ "template": "patient_has_diagnosis_of_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ,→ ] , "id": "finding_implies_symptoms_same_time", "match_template": "patient_has_finding_of_e_t", "require_bool": true, "produce": [ "template": "patient_has_symptoms_of_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ,→ ] 33 Preprint. Under review. , "id": "finding_implies_clinical_signs_same_time", "match_template": "patient_has_finding_of_e_t", "require_bool": true, "produce": [ "template": "patient_has_clinical_signs_of_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ,→ ] , "id": "is_undergoing_implies_has_undergone", "match_template": "patient_is_undergoing_e_t", "require_bool": true, "produce": [ "template": "patient_has_undergone_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ] , "id": "status_positive_implies_not_negative_same_time", "match_template": "patients_e_is_positive_t", "require_bool": true, "produce": [ "template": "patients_e_is_negative_t", "type": "Bool", "value": false, "preserve_qualifiers": true ] , "id": "status_negative_implies_not_positive_same_time", "match_template": "patients_e_is_negative_t", "require_bool": true, "produce": [ "template": "patients_e_is_positive_t", "type": "Bool", "value": false, "preserve_qualifiers": true ] , "id": "status_abnormal_implies_not_normal_same_time", "match_template": "patients_e_is_abnormal_t", "require_bool": true, "produce": [ "template": "patients_e_is_normal_t", "type": "Bool", "value": false, "preserve_qualifiers": true ] , "id": "status_normal_implies_not_abnormal_same_time", "match_template": "patients_e_is_normal_t", "require_bool": true, "produce": [ "template": "patients_e_is_abnormal_t", "type": "Bool", "value": false, "preserve_qualifiers": true ] , "id": "allergy_implies_hypersensitivity_same_time", "match_template": "patient_has_allergy_to_e_t", "require_bool": true, "produce": [ "template": "patient_has_hypersensitivity_to_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ,→ ] , "id": "nonimmune_hypersensitivity_implies_hypersensitivity_same_time", "match_template": "patient_has_nonimmune_hypersensitivity_to_e_t", "require_bool": true, "produce": [ "template": "patient_has_hypersensitivity_to_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ,→ ] , "id": "diagnosis_implies_suspicion_same_time", "match_template": "patient_has_diagnosis_of_e_t", "require_bool": true, "produce": [ "template": "patient_has_suspicion_of_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ,→ ] , "id": "finding_implies_suspicion_same_time", "match_template": "patient_has_finding_of_e_t", 34 Preprint. Under review. "require_bool": true, "produce": [ "template": "patient_has_suspicion_of_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ,→ ] , "id": "symptoms_implies_suspicion_same_time", "match_template": "patient_has_symptoms_of_e_t", "require_bool": true, "produce": [ "template": "patient_has_suspicion_of_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ,→ ] , "id": "clinical_signs_implies_suspicion_same_time", "match_template": "patient_has_clinical_signs_of_e_t", "require_bool": true, "produce": [ "template": "patient_has_suspicion_of_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ,→ ] , "id": "is_undergoing_implies_can_undergo_same_time", "match_template": "patient_is_undergoing_e_t", "require_bool": true, "produce": [ "template": "patient_can_undergo_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ] , "id": "will_undergo_implies_can_undergo_same_time", "match_template": "patient_will_undergo_e_t", "require_bool": true, "produce": [ "template": "patient_can_undergo_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ] , "id": "procedure_positive_outcome_implies_has_undergone_same_time", "match_template": "patient_has_undergone_e_t_outcome_is_positive", "require_bool": true, "produce": [ "template": "patient_has_undergone_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ] , "id": "procedure_negative_outcome_implies_has_undergone_same_time", "match_template": "patient_has_undergone_e_t_outcome_is_negative", "require_bool": true, "produce": [ "template": "patient_has_undergone_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ] , "id": "procedure_abnormal_outcome_implies_has_undergone_same_time", "match_template": "patient_has_undergone_e_t_outcome_is_abnormal", "require_bool": true, "produce": [ "template": "patient_has_undergone_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ] , "id": "procedure_normal_outcome_implies_has_undergone_same_time", "match_template": "patient_has_undergone_e_t_outcome_is_normal", "require_bool": true, "produce": [ "template": "patient_has_undergone_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ] , "id": "symptoms_implies_finding_same_time", "match_template": "patient_has_symptoms_of_e_t", "require_bool": true, "produce": [ "template": "patient_has_finding_of_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ,→ ] 35 Preprint. Under review. , "id": "clinical_signs_implies_finding_same_time", "match_template": "patient_has_clinical_signs_of_e_t", "require_bool": true, "produce": [ "template": "patient_has_finding_of_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ,→ ] , "id": "diagnosis_false_implies_finding_false_same_time", "match_template": "patient_has_diagnosis_of_e_t", "require_bool": false, "produce": [ "template": "patient_has_finding_of_e_t", "type": "Bool", "value": false, "preserve_qualifiers": true ,→ ] , "id": "finding_false_implies_diagnosis_false_same_time", "match_template": "patient_has_finding_of_e_t", "require_bool": false, "produce": [ "template": "patient_has_diagnosis_of_e_t", "type": "Bool", "value": false, "preserve_qualifiers": true ,→ ] , "id": "symptoms_false_implies_finding_false_same_time", "match_template": "patient_has_symptoms_of_e_t", "require_bool": false, "produce": [ "template": "patient_has_finding_of_e_t", "type": "Bool", "value": false, "preserve_qualifiers": true ,→ ] , "id": "clinical_signs_false_implies_finding_false_same_time", "match_template": "patient_has_clinical_signs_of_e_t", "require_bool": false, "produce": [ "template": "patient_has_finding_of_e_t", "type": "Bool", "value": false, "preserve_qualifiers": true ,→ ] , "id": "not_has_undergone_implies_not_undergoing_same_time", "match_template": "patient_has_undergone_e_t", "require_bool": false, "produce": [ "template": "patient_is_undergoing_e_t", "type": "Bool", "value": false, "preserve_qualifiers": true ,→ ] , "id": "positive_false_implies_negative_true_same_time", "match_template": "patients_e_is_positive_t", "require_bool": false, "produce": [ "template": "patients_e_is_negative_t", "type": "Bool", "value": true, "preserve_qualifiers": true ] , "id": "negative_false_implies_positive_true_same_time", "match_template": "patients_e_is_negative_t", "require_bool": false, "produce": [ "template": "patients_e_is_positive_t", "type": "Bool", "value": true, "preserve_qualifiers": true ] , "id": "abnormal_false_implies_normal_true_same_time", "match_template": "patients_e_is_abnormal_t", "require_bool": false, "produce": [ "template": "patients_e_is_normal_t", "type": "Bool", "value": true, "preserve_qualifiers": true ] , 36 Preprint. Under review. "id": "normal_false_implies_abnormal_true_same_time", "match_template": "patients_e_is_normal_t", "require_bool": false, "produce": [ "template": "patients_e_is_abnormal_t", "type": "Bool", "value": true, "preserve_qualifiers": true ] , "id": "no_hypersensitivity_implies_no_allergy_same_time", "match_template": "patient_has_hypersensitivity_to_e_t", "require_bool": false, "produce": [ "template": "patient_has_allergy_to_e_t", "type": "Bool", "value": false, "preserve_qualifiers": true ,→ ] , "id": "no_hypersensitivity_implies_no_nonimmune_hypersensitivity_same_time", "match_template": "patient_has_hypersensitivity_to_e_t", "require_bool": false, "produce": [ "template": "patient_has_nonimmune_hypersensitivity_to_e_t", "type": "Bool", "value": false, "preserve_qualifiers": true ,→ ] , "id": "cannot_undergo_implies_not_undergoing_same_time", "match_template": "patient_can_undergo_e_t", "require_bool": false, "produce": [ "template": "patient_is_undergoing_e_t", "type": "Bool", "value": false, "preserve_qualifiers": true ,→ ] , "id": "cannot_undergo_implies_not_will_undergo_same_time", "match_template": "patient_can_undergo_e_t", "require_bool": false, "produce": [ "template": "patient_will_undergo_e_t", "type": "Bool", "value": false, "preserve_qualifiers": true ] , "id": "not_has_undergone_implies_no_positive_outcome_same_time", "match_template": "patient_has_undergone_e_t", "require_bool": false, "produce": [ "template": "patient_has_undergone_e_t_outcome_is_positive", "type": "Bool", "value": false, "preserve_qualifiers": true ,,→ "template": "patient_has_undergone_e_t_outcome_is_negative", "type": "Bool", "value": false, "preserve_qualifiers": true ,,→ "template": "patient_has_undergone_e_t_outcome_is_abnormal", "type": "Bool", "value": false, "preserve_qualifiers": true ,,→ "template": "patient_has_undergone_e_t_outcome_is_normal", "type": "Bool", "value": false, "preserve_qualifiers": true ,→ ] , "id": "finding_false_implies_symptoms_false_same_time", "match_template": "patient_has_finding_of_e_t", "require_bool": false, "produce": [ "template": "patient_has_symptoms_of_e_t", "type": "Bool", "value": false, "preserve_qualifiers": true ,→ ] , "id": "finding_false_implies_clinical_signs_false_same_time", "match_template": "patient_has_finding_of_e_t", "require_bool": false, "produce": [ "template": "patient_has_clinical_signs_of_e_t", "type": "Bool", "value": false, "preserve_qualifiers": true ,→ ] , 37 Preprint. Under review. "id": "sex_female_implies_not_male", "match_template": "patient_sex_is_female_t", "require_bool": true, "produce": [ "template": "patient_sex_is_male_t", "type": "Bool", "value": false, "preserve_qualifiers": true , "template": "patient_has_finding_of_female_sex_t", "type": "Bool", "value": true, "preserve_qualifiers": true ,→ ] , "id": "sex_male_implies_not_female", "match_template": "patient_sex_is_male_t", "require_bool": true, "produce": [ "template": "patient_sex_is_female_t", "type": "Bool", "value": false, "preserve_qualifiers": true ] , "id": "need_to_undergo_implies_is_undergoing", "match_template": "patient_needs_to_undergo_e_t", "require_bool": true, "produce": [ "template": "patient_is_undergoing_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ] , "id": "need_to_undergo_implies_will_undergo", "match_template": "patient_needs_to_undergo_e_t", "require_bool": true, "produce": [ "template": "patient_will_undergo_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ] , "id": "need_to_undergo_implies_can_undergo", "match_template": "patient_needs_to_undergo_e_t", "require_bool": true, "produce": [ "template": "patient_can_undergo_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ] , "id": "need_to_undergo_implies_has_undergone", "match_template": "patient_needs_to_undergo_e_t", "require_bool": true, "produce": [ "template": "patient_has_undergone_e_t", "type": "Bool", "value": true, "preserve_qualifiers": true ] ], "timeframe_implication": "collapse_timeframes": false B.1.8 Has interpretation mappings for causal/dependency subsumption Tables 13 and 14 summarize the curated mappings from observedHas interpretationval- ues in SNOMED CT to the canonical vocabularynormal,abnormal,positive, andnegative for finding→observable entity and finding→procedure entailments, respectively. We main- tain separate mappings for inclusion and exclusion because the two settings have different error trade-offs. On the inclusion side, the mapping is intentionally recall-oriented: broader or more ambiguous interpretation values may be allowed to support canonicalized statuses so that potentially relevant trials are not missed. On the exclusion side, the mapping is more conservative, since an overly aggressive canonicalization could incorrectly disqualify a patient by triggering an exclusion condition from weak or ambiguous evidence. 38 Preprint. Under review. Table 13: Curated mapping from SNOMED CTHas interpretationvalues to canonical- ized vocabulary for finding→observable-entity entailment. Count reports the number of observed occurrences of each source interpretation term. A value of1in a status column in- dicates that the source term is mapped to that normalized status in our vocabulary. Columns marked(inc)are used for inclusion matching; columns marked(exc)are used for exclusion matching. TermCount normal (inc) abnormal (inc) positive (inc) negative (inc) normal (exc) abnormal (exc) positive (exc) negative (exc) Impaired228011 Abnormal224411 Below reference range10301 Increased9671 Absent9621 Decreased9251 Able7671 Difficulty6971 Unable6781 Does642 Does not608 Above reference range5841 Present5271 Normal47011 Altered2041 Non-patent1861 Dependent1641 Patent1571 Excessive1351 Slow101 Deficient931 High84 Inadequate771 Lacking551 Positive4111 Within reference range3711 Low34 Hypokinetic33 Akinetic281 Independent271 Blue color261 Detected251 Reduced23 Equivocal23 Assisted22 Improved21 Abnormally high2011 Outside reference range2011 Narrow191 Thin19 Abnormally low1811 Negative1611 Not detected1511 Small15 Red color13 Decreased relative to previous11 Obstructed101 Pale color saturation101 Moderate9 Exaggerated9 Inefficient8 Broken8 Asymmetry8 Increased relative to previous8 Bent7 Yellow color7 White color6 Enlarged61 Large5 Green colour5 Inconsistent5 Incomplete51 Able to and does41 Short4 Adequate41 Wide4 Decrease4 Pink color31 Insufficient3 Complete31 Raised3 Continued on next page 39 Preprint. Under review. Table 13 – continued from previous page TermCount normal (inc) abnormal (inc) positive (inc) negative (inc) normal (exc) abnormal (exc) positive (exc) negative (exc) Normal range211 Strong2 Weak2 Blue-red color21 Hyperkinetic21 Decreased relative to baseline21 Gray color21 Preparation stage2 Good2 Inaccurate2 Black color2 Brown color2 Very low211 Maintenance stage2 Action stage2 Scanty21 Contemplation stage2 Precontemplation stage2 Long duration2 No status change21 Borderline high1 Late1 Inconclusive1 Trace11 Efficient11 Present one plus out of three plus 111 Silver gray color1 Extremely high11 Borderline low1 Dark yellow color1 Very slow11 Irregular pattern11 Present two plus out of three plus 111 Termination stage1 Very high11 Inefficient emptying11 Indeterminate1 None111 Present three plus out of three plus 111 Decreased relative to expected1 Table 14: Curated mapping from SNOMED CTHas interpretationvalues to canonicalized vocabulary for finding→procedure entailment. Count reports the number of observed occurrences of each source interpretation term. A value of1in a status column indicates that the source term is mapped to that normalized status in our vocabulary. Columns marked(inc)are used for inclusion matching; columns marked(exc)are used for exclusion matching. TermCount normal (inc) abnormal (inc) positive (inc) negative (inc) normal (exc) abnormal (exc) positive (exc) negative (exc) ∅ (missing)3382 Below reference range132411 Above reference range97111 Abnormal74611 Detected32411 Within reference range28211 Normal22511 Present15811 Not detected14411 Outside reference range13811 Isolated2911 Not isolated2111 Positive1911 Equivocal17 Negative1711 Above therapeutic range15 Within therapeutic range15 Below therapeutic range14 Absent1311 Abnormal presence of71111 Increased6 Continued on next page 40 Preprint. Under review. Table 14 – continued from previous page TermCount normal (inc) abnormal (inc) positive (inc) negative (inc) normal (exc) abnormal (exc) positive (exc) negative (exc) Not seen611 Trace611 +411 ++411 +++411 ++++411 Abnormally low411 Inconclusive3 Indeterminate3 High2 Present one plus out of three plus 211 Present three plus out of three plus 211 Present two plus out of three plus 211 Very low211 Abnormally high111 Altered11 Borderline high1 Deficient11 Impaired11 Improved1 Low1 Nil111 No status change1 Stable1 B.2 Enriching Constraints with Qualifier Subsumption Relations How qualifiers are handled on the patient side is described in Appendix B.1.4. On the trial side, qualifiers follow the @@ notation, as discussed in Appendix B.3. In the SMT pro- gramming part of the semantic parsing pipeline (Appendix C.3), each qualifier is instructed to entail the stem it modifies, so that the qualified form also implies the underlying base constraint. If this entailment is omitted by the parser, we inject it automatically through pattern matching and static checks on the trial-side representation, specifically by detecting uses of @@. B.3 Relation Vocabularies In our representation, a canonical predicate has the formπ = (r,k,q), whereris the relation, kis the grounded medical concept, andqis an optional set of qualifiers. This appendix lists the allowed relation and qualifier vocabularies. We keep these vocabularies small and fixed so LLMs can turn free-text clinical statements into symbolic atoms more consistently. Instead of inventing predicate names freely, the model builds atoms from a standard relation vocabulary, grounded concepts, and normalized qualifiers. This makes the representation easier to generate, check, and use later. The qualifier partqincludes only modifiers that can be normalized into our fixed qualifier set, such as timeframe, procedure outcome, and measurement unit. Some useful clinical details do not fit cleanly into that set. To preserve details not captured by the standard qualifier vocabulary, we allow SMT-style variable names to carry extra@@-attached fields. These fields are not part of the canonical core; they are used only to retain modifier information that would otherwise be lost. Thus, a symbolic variable may contain both a canonical core and additional@@fields. The core still has the formπ = (r,k,q), while the@@fields store leftover detail outside the canonical representation. We also use different template families for findings, procedures, numeric observables, prod- ucts, substances or exposures, and demographic or reproductive-status facts. Time is nor- malized through a small timeframe grammar, and numeric observations are represented in a numeric-first form so comparisons can be handled later during reasoning. 41 Preprint. Under review. The templates below are therefore more than naming conventions: they form a controlled symbolic vocabulary for building SMT programs from clinical text. B.3.1 Vocabulary of Medical Relations R M We first define the set of canonical medical relations,R M ⊆ R. Each relation describes one standard way a patient can be connected to a grounded medical concept. To make these relations easy to read, we present them as stem templates. These templates show the basic relation together with placeholders for the grounded entity and any canonical qualifiers. A.1Canonical Medical Relations Findings / Conditions patient_has_diagnosis_of_entity_timeframe patient_has_finding_of_entity_timeframe patient_has_symptoms_of_entity_timeframe patient_has_clinical_signs_of_entity_timeframe patient_has_suspicion_of_entity_timeframe Procedures patient_has_undergone_entity_timeframe patient_has_undergone_entity_timeframe_outcome_is_positive patient_has_undergone_entity_timeframe_outcome_is_negative patient_has_undergone_entity_timeframe_outcome_is_normal patient_has_undergone_entity_timeframe_outcome_is_abnormal patient_is_undergoing_entity_timeframe patient_will_undergo_entity_timeframe patient_can_undergo_entity_timeframe Numeric Observables patient_entity_value_recorded_timeframe_withunit_unit Products patient_is_taking_entity_timeframe patient_has_taken_entity_timeframe patient_has_hypersensitivity_to_entity_timeframe patient_has_intolerance_to_entity_timeframe patient_has_allergy_to_entity_timeframe patient_has_nonimmune_hypersensitivity_to_entity_timeframe Substances / Exposures patient_is_exposed_to_entity_timeframe patient_has_been_exposed_to_entity_timeframe patient_has_hypersensitivity_to_entity_timeframe patient_has_intolerance_to_entity_timeframe patient_has_allergy_to_entity_timeframe patient_has_nonimmune_hypersensitivity_to_entity_timeframe Demographics & Reproductive Status patient_age_value_recorded_timeframe_in_years patient_age_value_recorded_timeframe_in_months patient_age_value_recorded_timeframe_in_days patient_sex_is_male|female|other_timeframe patient_has_childbearing_potential_timeframe patient_is_breastfeeding_timeframe patient_is_pregnant_timeframe patient_is_lactating_timeframe A.2Canonical Qualifier Grammar timeframe ::= now | inthehistory | inthepast(n,unit) | inthefuture(n,unit) outcome ::= positive | negative | normal | abnormal unit ::= minutes | hours | days | weeks | months | years | measurement_unit The qualifier grammar above is only an example, not a complete list. The main idea is that qualifier values are mapped into a small fixed set before symbolic execution. This helps reduce variation in wording and makes both LLM generation and downstream SMT reasoning more reliable. In use, the templates in Box A.1 correspond to typed atomsπ = (r,k,q):rgives the base medical relation,kgives the grounded concept, andqgives modifiers such as timeframe, outcome, and unit. 42 Preprint. Under review. B.3.2 Vocabulary of Trial Intents R T In addition to medical relations R M , our representation uses a small controlled vocabulary of trial intents, denotedR T , to capture how a trial is meant to act upon a target clinical state, procedure, or substance. Intuitively, whileR M describes what fact is under discussion,R T describes why that fact matters in the trial: for example, because the intervention aims to treat it, prevent it, monitor it, improve a procedure, or reduce substance-related harm. As withR M , we keep this vocabulary deliberately small and regular so that LLMs can reliably annotate trial-side predicates with coarse but useful target semantics. These labels are not intended as a complete ontology of all real-world trial purposes. Rather, they form a compact canonical vocabulary sufficient for the retrieval objectives studied in this work, and they can be extended in future work. Because different kinds of targets support different clinically meaningful actions,R T is typed by target category. We distinguish three cases: (i) findings and conditions, (i) procedures, and (i) products or substances. For each case, an LLM is asked to classify a canonicalized trial-side variable into one or more intent labels based on the trial description. These labels are then attached to the corresponding symbolic atoms as a trial-side semantic annotation layer. Intent labels for findings and conditions. For variables denoting diagnoses, symptoms, findings, signs, or other clinical states, we use: •Treats: the intervention is intended to improve, control, relieve, or otherwise clinically address the target condition. •Prevents: the intervention is intended to reduce the probability of future onset of the target condition. •Other: the target is clinically relevant, but the trial’s role is neither primarily treatment nor prevention; examples include diagnosis, monitoring, stratification, prediction, or characterization. • Not Clinically Relevant: the variable is incidental, overly broad, or unrelated background context rather than a meaningful clinical focus of the trial. Intent labels for procedures.For variables denoting procedures already undergone, ongo- ing, planned, or feasible, we use: •Improves Effectiveness: the trial aims to improve the success, precision, completeness, durability, or clinical benefit of the procedure. • Reduces Procedure-Related Harms: the trial aims to reduce adverse effects, complications, or harmful recovery consequences associated with the procedure. • Other: the trial modifies how the procedure is delivered or experienced in another clini- cally relevant way, such as improving tolerability, shortening recovery, optimizing timing, or improving workflow and safety monitoring. •Not Clinically Relevant: the procedure is incidental or not a meaningful target of the trial. Intent labels for products and substances.For variables denoting drugs, biologics, devices treated as products, or substances/exposures, we use: • Reduces Exposure/Use: the trial aims to reduce use of or exposure to the substance. • Mitigates Harms: given use or exposure, the trial aims to reduce its negative effects. •Enhances Benefits: given use or exposure, the trial aims to improve its desired effects or benefit–risk profile. •Other: the trial changes the relationship between the patient and the substance in an- other clinically relevant way, such as monitoring, detection, dose personalization, relapse prevention, or response prediction. 43 Preprint. Under review. •Not Clinically Relevant: the substance is incidental or not a meaningful target of the trial. Operationally, then, the surface templates in this appendix should be read as lexicalizations of typed atomsπ = (r,k,q):rcontributes the base medical relation,kcontributes the grounded concept, andqcontributes canonical modifiers such as timeframe, outcome status, and unit. When additional modifier information cannot be canonicalized, we retain it through@@-attached fields in the concrete symbolic syntax so that the program remains semantically faithful to the source text. B.3.3 Vocabulary of Patient-Fact Relations R P WhileR T captures the trial-side role of a target, we also use a small controlled vocabulary of patient-fact relations, denotedR P , to capture the patient-side role of a fact in clinical-trial search. Intuitively, these labels describe which patient facts are central enough to define what the patient is actually looking for trials about. This vocabulary supports progressively broader retrieval objectives. The key idea is that not every fact in the patient record should contribute equally: some facts correspond to the patient’s main problem, some are closely related to it, some are important enough to justify broader trial search, and some correspond to diseases the patient is trying to avoid rather than diseases the patient currently has. As withR M andR T , we keep this vocabulary small and regular so that LLMs can assign patient-side roles in a consistent way. The labels are not intended to exhaust the full structure of patient intent. Rather, they provide a compact canonical vocabulary sufficient to define the retrieval objectives used in this paper. Chief Complaint.A fact is labeled Chief Complaint if it corresponds to the patient’s main presenting problem or primary condition of concern at the time of trial search. This is the condition, symptom complex, or diagnosis that most directly answers the question: what trials is this patient looking for right now? In practice, chief complaints are often not stated literally in the vignette and may need to be inferred from the clinical presentation. They are usually disease-level conditions rather than isolated low-level symptoms. Chief-Complaint Related.A fact is labeled Chief-Complaint Related if it is not itself the chief complaint, but is still closely and clinically meaningfully related to it. This includes facts that are near the chief complaint in the diagnostic, etiologic, syndromic, or therapeutic space, such that a trial targeting the related fact may still plausibly help address the patient’s main concern. This category is stricter than general semantic relatedness: the connection must be close enough that a patient could realistically search for trials using that fact in pursuit of help for the chief complaint. Any Important Complaint.A fact is labeled Any Important Complaint if it represents an important clinical problem for the patient that may independently justify a trial search, even if it is not the main presenting complaint and not especially close to it. This is the broadest complaint-oriented category used in our objectives. It includes additional meaningful di- agnoses, findings, major symptoms, or significant non-routine interventions that a patient might deliberately search trials for. However, it excludes overly general concepts, trivial routine facts, and vague buckets such as disease, pain, or broad anatomical findings. Prevention Target.A fact is labeled Prevention Target if it denotes a disease that the patient is explicitly seeking to prevent, rather than a disease the patient currently has. This category is handled separately from the complaint-based categories above. Prevention targets must not be inferred current diagnoses. They are included only when the note explicitly indicates preventive intent, or when prevention of a specific downstream disease is the near-universal clinical goal of the patient’s stated condition. Thus, this category represents what the patient is trying to avoid, not what the patient is presently experiencing. 44 Preprint. Under review. C Text Preprocessing and Semantic Parsing C.1 Requirement Preprocessing: Extended Description (Trial-Side Semantic Parsing) Figure 14: Requirement preprocessing workflow in S AT I R. Starting from raw trial eligibility text, the system transforms free-text criteria into parse-ready requirement units through four stages: Extract Requirements, Expand Entities, Rewrite Logic, and Decompose Re- quirements. This appendix expands the preprocessing stage summarized in Section 2.3. The role of preprocessing is to convert raw eligibility text into a representation that is substantially easier for downstream semantic parsing. Rather than asking a model to map long, heterogeneous, and often structurally ambiguous trial text directly into formal logic, S AT I R first rewrites the text into parse-ready requirement units whose cohort structure, polarity, entity boundaries, and logical scope are made explicit. This stage can be viewed as a controlled representation transformation: it reduces ambiguity before formalization. The output is not yet canonicalized concepts or SMT assertions, but a cleaner intermediate language that exposes the semantic decisions the later stages must make. C.1.1 Input and Output The input is free-text trial eligibility text, including inclusion criteria, exclusion criteria, and any cohort-specific enrollment conditions. The output is a cohort-indexed intermediate rep- resentation consisting of self-contained requirement statements with preserved provenance and explicit structure. Each resulting requirement unit is designed to support the next two stages of the pipeline. First, medically meaningful mentions become easier to ground to ontology concepts during entity canonicalization. Second, logical structure becomes easier to translate into formal assertions during incremental SMT programming. In this sense, preprocessing acts as the interface between raw language and symbolic semantic parsing. C.1.2 Why Preprocessing Is Needed Raw eligibility criteria are difficult for end-to-end semantic parsing for several reasons. First, a single trial often mixes multiple enrollment pathways in one document, so the parser must recover cohort structure before it can interpret a criterion correctly. Second, medically meaningful entities are often expressed in compressed or non-contiguous surface forms, which makes faithful grounding difficult. Third, logical structure is frequently implicit: conjunction, disjunction, precedence, and scope may be obvious to a clinician but not explicit 45 Preprint. Under review. in the text. Finally, individual sentences often bundle several distinct constraints together, making them hard to translate and validate as a single unit. The preprocessing stage addresses these issues before formalization. Instead of relying on a single model call to simultaneously recover structure, resolve mentions, and generate logic, S AT I R decomposes the problem into a sequence of simpler transformations, each of which removes one source of ambiguity. The fine-grained evaluation results for preprocessing step could be found in Section C.1.9. C.1.3 Step 1: Extract Requirement Clinical trials frequently encode multiple enrollment pathways, such as different treatment arms, disease subtypes, or severity-based cohorts. Since these pathways may share some conditions while differing on others, S AT I R first organizes the trial into cohort-specific requirement lists. Prompts used for requirement extraction can be found in Appendix F.1.1, F.1.3, and F.1.2 Within each cohort, the system extracts requirement-bearing statements from the eligibility text and rewrites them into a standardized form with explicit polarity. Inclusion statements are rewritten into a form such as “To be included, the patient must . . . ”, while exclusion statements are rewritten so that their exclusion meaning is explicit and does not depend on document layout or section headers. This step corresponds to the Extract Requirements stage in Figure 14. Its purpose is to isolate the requirement content and make the enrollment structure explicit. For downstream semantic parsing, this is important because the same sentence can mean different things depending on which cohort and which polarity context it belongs to. C.1.4 Step 2: Expand Entities Eligibility text often expresses clinically meaningful content in forms that are easy for humans to read but difficult for models to ground reliably. For example, coordinated phrases may share a head noun, abbreviations may omit clinically relevant detail, and multiple distinct entities may be packed into a single local span. To make entity grounding more reliable, S AT I R rewrites each requirement so that medically meaningful mentions appear as explicit contiguous phrases. This may involve duplicating shared heads, unpacking coordinated mentions, or expanding abbreviated forms when supported by the local text. The goal is not to add information, but to expose the entity structure already implicit in the criterion. Prompt for entity expansion can be found in Appendix F.1.6. This step corresponds to the Expand Entities stage in Figure 14. For the downstream canonicalization module, the benefit is straightforward: contiguous and semantically explicit mentions are easier to align with ontology concepts than compressed surface forms. C.1.5 Step 3: Rewrite Logic A major difficulty in semantic parsing of eligibility criteria is that the logical structure is often only partially explicit. A requirement may mix conjunction, disjunction, and modifier scope in a way that is under-specified on the surface. This is especially common in long clinical sentences that combine disease phenotype, prior treatment conditions, biomarker requirements, and procedural obligations. To address this, S AT I R rewrites each requirement so that the internal logical structure is more explicit. Conjunctions and disjunctions are surfaced, grouping is clarified, and ambiguous coordination is rewritten into a form whose scope can be interpreted deterministically. Importantly, this step is meaning-preserving: it does not simplify the criterion, but rather makes its latent logical structure visible. This step corresponds to the Rewrite Logic stage in Figure 14. It makes implicit composi- tional structure explicit by introducing intermediate symbolic scaffolding, thereby reducing 46 Preprint. Under review. structural ambiguity and simplifying downstream parsing. The prompts for logic rewrite could be found in Appendix F.1.8 and Appendix F.1.9. C.1.6 Step 4: Decompose Requirements Even after logic rewriting, a single requirement sentence may still contain several conceptu- ally distinct constraints. Parsing such sentences monolithically is brittle: errors in one part of the sentence can affect the entire formalization, and validation becomes difficult because the output is not modular. S AT I R therefore decomposes rewritten requirements into smaller self-contained require- ment units. For example, a sentence that jointly constrains disease subtype, treatment history, and biomarker evidence may be split into separate requirement statements, each of which can later be canonicalized and translated independently. This decomposition respects the logical structure introduced in the previous stage and avoids splits that would change the scope of negation, disjunction, or qualification. This step corresponds to the Decompose Requirements stage in Figure 14. The result is a set of localized semantic parsing problems that are easier to ground, easier to translate, and easier to validate. The prompts for decomposition could be found in Appendix F.1.12 and Appendix F.1.13. C.1.7 Step 5: Classify After decomposition, each requirement unit is further assigned a functional role that de- termines how it should be treated during early-stage patient–trial matching. While all components are valid eligibility constraints, they differ in how strictly they must be enforced during prescreening, where patient information is often incomplete. S AT I R therefore classifies each atomic-level requirement into a small set of operational categories based on its role in determining relevance under partial information. In particular, the classification distinguishes between (1) requirements that must be explicitly supported by patient notes during prescreening, (2) requirements that do not meaningfully constrain relevance or can be trivially satisfied through simple actions, and (3) requirements that may be unknown at prescreening time but should not exclude a trial unless explicitly contradicted. This distinction reflects a key asymmetry in retrieval: missing information should not prematurely eliminate potentially relevant trials unless the requirement is deemed critical and expected to be known. The classification is performed independently for each decomposed component, using both the local requirement text and the broader trial context to assess its importance. For example, core clinical attributes that define the target population of the trial are typically treated as strict prescreening constraints, whereas laboratory thresholds, screening measurements, or protocol logistics are often deferred to later stages and treated as permissive. Additionally, requirements that can be satisfied through administrative steps or short-term behavioral adjustments are explicitly separated from true eligibility constraints to avoid unnecessary filtering. This step corresponds to the Classify stage in Figure 14. The output is a set of requirement components annotated with their prescreening roles, enabling the retrieval system to balance precision and recall by enforcing only the most informative constraints early while deferring others to downstream eligibility checking. The prompts for classification could be found in Appendix F.1.16 and Appendix F.1.17. C.1.8 Faithfulness Verification and Conservative Fallback Because preprocessing rewrites text, S AT I R applies lightweight verification checks between stages to ensure that the transformed requirements remain faithful to the source. These checks verify that polarity is preserved, clinically meaningful content is not dropped, logical scope is not altered, and decomposition does not introduce unintended semantic changes. 47 Preprint. Under review. When a check fails, the system retries the transformation with targeted feedback. If the issue cannot be resolved reliably, S AT I R falls back to a less processed representation rather than risk semantic drift. For example, a requirement may remain as a larger unit if aggressive decomposition cannot be validated. This conservative fallback policy is important: the goal of preprocessing is to improve parseability, not to force unsupported structure onto the text. Verification prompts for individual preprocessing stages are documented in the appendix. Specifically, verification procedures for Stage 1 (requirement extraction) are provided in Appendix F.1.4 and Appendix F.1.5, corresponding to inclusion and exclusion criteria, respec- tively. Verification for Stage 2 (entity expansion) is described in Appendix F.1.7. Verification for Stage 3 (rewrite logic) is described in Appendix F.1.10 and Appendix F.1.11, correspond- ing to inclusion and exclusion criteria, respectively. Verification for Stage 4 (decompose) is described in Appendix F.1.14 and Appendix F.1.15, corresponding to inclusion and exclusion criteria, respectively. C.1.9 Evaluation of the Preprocessing Pipeline Figure 15: Fine-grained evaluation results for preprocessing modules. We conduct a fine-grained, module-level evaluation of the preprocessing stage, which stan- dardizes free-text eligibility criteria prior to downstream semantic parsing. Three annotators participated in the evaluation. For each module, we compare its input and output and label each requirement against gold annotations to determine whether the module performed the intended operation correctly. Below, we describe the evaluation protocol and results for each module. Extract Requirement.The Extraction module converts bullet points or line-based criteria into a structured list of requirements and prepends relevant preamble context to each re- quirement. For each trial, we evaluate (i) whether all requirements are successfully extracted and (i) whether each extracted requirement is semantically consistent with the original text. Extraction performance is measured using accuracy, defined as #extracted requirements that are semantically correct #requirements should be extracted Across 11 trials (104 requirements), the Extraction module achieves 100% accuracy. Expand Entities. The Expansion module targets requirements containing medical short- hand or ambiguous terms that should be explicitly expanded for clarity. To evaluate this module, we compare the input and output text and label each requirement as one of four categories: true positive (expansion is required and correctly performed), false negative (expansion is required but missing or incorrect), false positive (unnecessary or extrane- ous expansion), or true negative (requirement should not be expanded, and no expansion performed). We report precision and recall, defined respectively as Precision = # true positives # true positives + # false positives , 48 Preprint. Under review. Recall = # true positives # true positives + # false negatives . On 14 trials (152 requirements), Expansion achieves 100% precision and 94.40% recall. Rewrite Logic.Precision Rewrite rewrites each requirement to make implicit logical struc- ture explicit. Similar to expansion evaluation, we evaluate precision rewrite by comparing the input and output text and label them with: true positive (rewrite required and is per- formed correctly), false negative (a rewrite was required but missing or incorrect), false positive (a rewrite was not required, yet the system rewrote the text), or true negative (no rewrite was required, and none was performed). We evaluate Precision Rewrite using the same precision and recall definitions as Expansion. On 14 trials (120 requirements), it attains 100% precision and 94.50% recall, suggesting the module captures essentially all rewrite-needed cases, with a small number of over-edits or incorrect rewrites. Decompose Requirements. Decomposition splits each requirements into atomic com- ponents that preserves the original meaning. Similar to expansion and precision rewrite evaluation, we compare the input and output text and label each requirement with: true pos- itive (the requirement should be decomposed, and decomposition is performed correctly), false negative (the decomposition did not split something that should have been decom- posed), false positive (decomposer splits a requirement that shouldn’t be decomposed), or true negative (no decomposition was required, and none was performed). Decomposition is evaluated using the same precision and recall metrics defined for Expansion. On 14 trials (120 requirements), it achieves 98.00% precision and 92.45% recall, showing strong correctness when decomposition is applied, with some missed opportunities to decompose. Classification.The Classification module assigns each atomic requirement to the appropri- ate preprocessing category. Exclusion requirements are classified into one of two categories: (1)not requirement or always satisfiable with one-off action and (2) other requirements. Inclusion requirements are assigned to one of three categories: (1) prescreen notes must completely suffice, (2) not requirement or always satisfiable with action, and (3) other requirements. For evaluation, we review each requirement in context and count the number of incorrect assignments. Accuracy is computed as # requirements− # incorrectly labeled requirement # requirements On 13 trials (460 atomic requirements), Classification reaches 91.95% accuracy. We note that this accuracy was evaluated using an earlier version of the classification label; subsequent refinements to category definitions may introduce additional distinctions not reflected in this reported score. Error Interaction Across Preprocessing Modules.Although we report per-module preci- sion and recall for diagnostic purposes, errors across preprocessing modules do not com- pound in a strictly sequential manner. In practice, later modules can compensate for missed operations in earlier stages. For example, if a module fails to apply a required expansion (i.e., incurs a false negative), subsequent precision rewrite module may still correct or recover the issue when operating on the same requirement. This behavior arises from two design choices. First, preprocessing modules are not mutually exclusive in functionality: multiple modules are capable of resolving overlapping forms of ambiguity or incompleteness. Second, each module operates with access to the full contextual information of the requirement, including outputs and preserved context from prior stages, rather than relying solely on the transformed text alone. As a result, missed edits are often recoverable downstream. Consequently, per-module recall should not be interpreted as a direct indicator of end-to-end preprocessing failure. Instead, recall reflects how often a specific operation is applied at a particular stage, rather than whether the requirement is ultimately normalized correctly. Precision, which captures incorrect or unnecessary edits, is therefore a more critical metric for maintaining semantic fidelity in the overall pipeline. 49 Preprint. Under review. C.1.10 Relation to the Downstream Parser The output of preprocessing is the input to the later semantic parsing stages described in Section 2.3. The decomposed requirement units produced here are subsequently canoni- calized against the medical ontology and then translated into solver-executable assertions through incremental SMT programming. Preprocessing therefore serves a role analogous to representation shaping in other AI pipelines: it transforms a difficult raw input into an intermediate form whose relevant structure is easier for later components to model correctly. In S AT I R, this intermediate form exposes four kinds of information that are particularly important for faithful formalization: enrollment pathway, polarity, entity boundaries, and logical scope. Summary.Requirement preprocessing converts raw trial eligibility text into cohort-aware, polarity-explicit, entity-expanded, logically clarified, and modularized requirement units. These units are not yet formal logic, but they are designed to be semantic-parsing ready: they reduce ambiguity in the input and make downstream ontology grounding and symbolic translation substantially more reliable. C.2 Entity Canonicalization Details (Trial-Side Semantic Parsing) Trial 1 (NCT03437057) Inclusion Criteria: Patients over 18 years of age benefiting from the social security scheme Patients with at least one renal lithiasis requiring treatment with extracorporeal lithotripsy (ECL). Trial 2 (NCT03105206) Inclusion Criteria: Subject has a diagnosis of low pole renal stones according to CT urography(CTU) or intravenous pyelogram (IVP) results. Trial 3 (NCT01751529) Inclusion Criteria: Be eligible for radical or partial nephrectomy or ablative therapy based upon at least one renal lesion identified during previous contrast enhanced CT or MR. Can match w/o canonicalization Can match w canonicalization, w/o ontology entailments Can match w canonicalization & ontology entailments Patient: A 47-year-old female presents with intermittent right flank pain radiating to the groin for the past two weeks. Urinalysis revealed microscopic hematuria. A non-contrast CT scan demonstrated renal lithiasis involving a 4 m calculus in the right kidney. Figure 16: Why canonicalization is necessary for retrieval in S AT I R. Pure string-level matching cannot reliably connect synonymous or ontologically related medical concepts. In this example, a patient mention of renal stones would fail to retrieve trials written using renal lithiasis, and would also miss trials targeting the broader concept renal lesion unless ontology-based entailment is applied. Canonicalization collapses lexical variation into a shared concept representation, while ontology reasoning recovers relevant abstraction and subsumption structure. Together, these steps allow all relevant trials to be retrieved. This appendix expands the canonicalization stage summarized in Section 2.3. The purpose of this stage is to map heterogeneous clinical language into a shared symbolic vocabulary that supports both ontology-aware retrieval and formal reasoning. Rather than treating entity linking as a standalone normalization problem, S AT I R uses canonicalization as the interface between free-text clinical language and the structured concept space used throughout the system. Concretely, entity canonicalization resolves lexical variation, abbreviation, and span ambigu- ity while maintaining the contextual distinctions needed for correct downstream reasoning. C.2.1 Why Canonicalization Is Necessary Clinical trials and patient records often refer to the same underlying medical concept using different surface forms, abbreviations, levels of specificity, or paraphrases. A retrieval or reasoning system that operates only on raw text spans or surface strings therefore fails in two ways. First, it misses synonymy: semantically equivalent mentions may not match lexically. Second, it misses ontology-mediated generalization: a patient fact expressed at a more specific level should still support a trial target expressed at a more general level. 50 Preprint. Under review. Patient note: “To be included, the patient must have isolated systolic high blood pressure” Extracted Entities: Candidates of entity 1: 1.High systolic arterial pressure 2.Systolic hypertension 3.Systolic essential hypertension Candidates of entity 2: 1.Systolic essential hypertension 2.Systolic hypertension 3.High systolic arterial pressure Candidates of entity 3: 1.Hypertension 2.Primary hypertension 3.Raised blood pressure Systolic hypertension Systolic hypertension Hypertension ① Entity Span Identification ② Dense Retrieval in SNOMED ③ Reranking ④ Filtering: Is the top candidate the same as extracted entity? Not same Same Same Which is more specific? Canonicalized result: Systolic hypertension “Isolated systolic high blood pressure” “systolic high blood pressure” “High blood pressure” ③ Reranking ③ Reranking ⑤ Figure 17: Entity canonicalization workflow in S AT I R. Starting from a preprocessed re- quirement, the system first performs high-recall extraction of medically meaningful spans, including overlapping spans when needed to avoid early information loss (left). For each span, top-kcandidate concepts are retrieved from SNOMED CT (center). Candidates are then reranked, audited for exact contextual meaning match, and filtered by policy con- straints. When multiple overlapping spans survive, the system retains the most specific faithful concept. The final output is a schema-aware canonical symbol that can be shared across patient parsing, trial parsing, retrieval, and downstream formal reasoning (right). Figure 16 illustrates this point. Canonicalization maps diverse surface forms to a shared ontology-grounded concept, while ontology-based entailment recovers medically valid abstraction structure such as subtype–supertype relations. These are both necessary: canoni- calization alone does not recover subsumption, and ontology reasoning alone cannot help if semantically equivalent mentions were never grounded to the same concept space. C.2.2 Objective and Interface The input to canonicalization is a preprocessed requirement unit from the earlier stage of the pipeline. The output is a set of accepted canonical entries, each representing a medically meaningful mention that has been grounded to a standardized concept and converted into a schema-aware symbolic form. Formally, for each input sentence t, the canonicalizer emits a set of entries of the form n (span, [b, e), conceptId, type, preferred_term, variable_name) o , where[b,e)denotes the character span of the mention in the sentence. These outputs form the bridge between raw language and the canonical signature used by later modules. The goal is not simply to assign ontology nodes. Instead, the goal is to produce canonical symbols that satisfy three constraints simultaneously: they must unify synonymous lan- guage across patient and trial text, preserve enough local meaning for correct symbolic use, and remain compatible with the downstream schema used for retrieval and SMT-style formalization. The fine-grained evaluation results for entity canonicalization could be found in Section C.2.9 C.2.3 Stage 1: High-Recall Mention Extraction The first stage identifies as many medically meaningful spans as possible from the prepro- cessed requirement. We intentionally bias this stage toward recall, since an omitted mention cannot be recovered later and may directly cause false negatives in retrieval or eligibility reasoning. This high-recall extraction includes overlapping spans when they correspond to distinct plausible semantic units. For example, a longer disease phrase and a nested subtype mention may both be retained at this stage. Administrative or non-medical framing content, such as boilerplate consent language or document structure cues, is suppressed because it does not contribute to the canonical clinical representation. 51 Preprint. Under review. This design deliberately favors over-generation, allowing later stages to make more informed precision-oriented decisions. This is preferable to aggressive early pruning, which risks permanently discarding clinically important content. Prompt can be found in Appendix F.1.18 and F.1.19 C.2.4 Stage 2: Candidate Retrieval from SNOMED CT For each extracted span, S AT I R retrieves top-kcandidate concepts from SNOMED CT. The purpose of this stage is to project the local surface form into a structured concept space that supports shared reasoning across patient and trial text. Each retrieved candidate includes a concept identifier, preferred term, fully specified name, and semantic type. Candidate retrieval is intentionally permissive, retaining multiple plau- sible interpretations for each span and deferring disambiguation to later stages where additional context enables more reliable resolution. C.2.5 Stage 3: Contextual Link Auditing Candidate retrieval alone is not sufficient, since nearest-neighbor search over ontology concepts often returns semantically related but not meaning-equivalent candidates. To reduce these false positives, S AT I R applies a contextual auditing stage that verifies whether a candidate preserves the meaning of the extracted span at that specific location in the sentence. The audit accepts a candidate only if it is an exact meaning match in context. This means that the candidate must neither lose clinically relevant semantics nor introduce unsupported semantics. For example, a span referring to a symptom complex should not be collapsed into a disease diagnosis unless the sentence actually licenses that interpretation. Similarly, a candidate that adds severity, temporality, or treatment implications not present in the text is rejected. Prompt can be found at Appendix F.1.20 and F.1.21 This stage is important because downstream formal reasoning is highly sensitive to symbol choice. A plausible but slightly incorrect link is often worse than leaving the mention uncanonicalized, since it introduces a false structured commitment into the program. C.2.6 Stage 4: Overlap Resolution and Policy Filtering Because the system intentionally allows overlapping spans in the first stage, multiple valid candidate links may survive for partially overlapping text segments. S AT I R therefore applies a final arbitration and policy-filtering step. Prompt can be found in Appendix F.1.22 This stage enforces representation constraints needed by the downstream reasoning system. Mentions whose concept types are not supported by the canonical schema are discarded, as are spans corresponding only to administrative, demographic, or other non-semantic framing content. Among overlapping candidates that remain faithful to the text, the system keeps the most specific acceptable concept. The goal is to preserve the sharpest faithful representation while avoiding redundant or overly broad symbols. In effect, this step con- solidates a dense set of local grounding hypotheses into a compact symbolic representation, reducing redundancy while preserving maximal semantic precision. C.2.7 Stage 5: Schema-Aware Canonical Symbol Emission Once a concept is accepted, S AT I R converts it into a schema-aware canonical symbol. This is a crucial step: downstream reasoning does not operate directly over ontology nodes alone, but over variables whose names encode both the grounded medical concept and its semantic role in the structured representation. The emitted symbol therefore combines the canonical concept with schema information such as whether the concept is being treated as a diagnosis, finding, procedure, medication exposure, or measurable observable. In addition, normalized contextual information such as timeframe may be encoded in a controlled way when it is required by the downstream logic representation. 52 Preprint. Under review. This design ensures that the same underlying concept is represented consistently across patient parsing, trial parsing, database storage, retrieval, and formal reasoning. It constructs a shared symbolic interface for downstream processing steps. C.2.8 Why the Pipeline Is Staged The canonicalization workflow is intentionally staged rather than performed in a single end-to-end linking decision. This separation is important because the subproblems have different error profiles and different optimization goals. Mention extraction is recall-sensitive, candidate retrieval is coverage-oriented, contextual auditing is precision-sensitive, and overlap arbitration enforces representation compatibility. Combining all of these decisions into a single step would make failures harder to diagnose and harder to control. By isolating them, S AT I R can maintain high recall early, apply meaning-sensitive precision later, and ensure that the final output satisfies the structural requirements of the downstream symbolic system. C.2.9 Evaluation of the Entity Recognition Pipeline Figure 18: Fine-grained evaluation results for entity canonicalization. We evaluate the named entity canonicalization pipeline. For each requirement, we compare the input text with the set of extracted canonical entities and record three quantities: (i) the expected number of gold entities in the requirement(|TP| +|FN|); (i) the number of correctly extracted entities(|TP|); and (i) the total number of entities extracted by the system (|TP| +|FP|). From these counts, the number of false negatives for a requirement is computed as(|TP| + |FN|)−|TP|, and the number of false positives as(|TP| +|FP|)−|TP|. We aggregateTP, FP, andFNacross all evaluated requirements and compute precision and recall using the same definitions as those used for the Expansion module in preprocessing. Across 13 trials (82 requirements), entity canonicalization achieves 100% precision and 96.50% recall. This result indicates that extracted canonical entities are highly reliable, with no false positives observed in the evaluation set, while a small number of gold entities are missed. Importantly, missed entities do not necessarily result in downstream failure: during SMT program construction, free-form entity recognition can still recover uncanonicalized entities directly from the requirement text. As a result, recall at the canonicalization stage is not a strict bottleneck for end-to-end reasoning correctness, whereas high precision remains essential to avoid introducing spurious constraints. C.2.10 End-to-End Summary Overall, the entity canonicalization workflow proceeds as follows: Starting from a preprocessed requirement, the system performs high-recall mention extrac- tion, retrieves candidate ontology concepts, audits these candidates for exact contextual meaning match, resolves overlap and policy constraints, and finally emits schema-aware canonical symbols. The result is a unified concept representation shared across patient and trial text, enabling ontology-aware retrieval and formal reasoning in a common symbolic space. Summary. Entity canonicalization transforms heterogeneous clinical language into a shared ontology-grounded symbolic vocabulary. This vocabulary is meaning-preserving, 53 Preprint. Under review. high-recall mention extraction SNOMED candidate retrieval LLM link auditing overlap arbitration + policy filtering schema-aware canonical symbol emission schema-aware, and reusable across patient parsing, trial parsing, retrieval, and formal rea- soning. In S AT I R, canonicalization is therefore not just an entity-linking component, but a core representation layer that makes symbolic clinical reasoning feasible. C.3 SMT Programming Details: Incremental Orchestration (Trial-Side Semantic Parsing) This appendix expands the incremental SMT programming stage summarized in Section 2.3. In this stage, S AT I R transforms each preprocessed, canonicalized requirement into a solver- executable SMT fragment and integrate it into a growing formal program. Rather than relying on a single end-to-end text-to-logic generation step, S AT I R uses an incremental orchestration procedure in which requirements are translated one at a time, validated immediately, and committed only when they are judged reliable. SMT programming can be viewed as a constrained program construction loop with struc- tured feedback. Instead of generating a complete eligibility program in a single step, the system decomposes the task into localized decisions—including symbol reuse, variable construction, logical translation, and fragment validation. Each fragment is checked before integration, allowing errors to be detected, localized, and corrected early, and preventing propagation to later parts of the program. C.3.1 Input and Output The input to this stage is a set of atomic, SMT-ready requirements produced by preprocessing, together with the canonicalized entities and qualifiers produced by the earlier grounding stage. Each requirement is already localized enough to support independent formalization, but still requires symbolic variable construction and logical translation. The output is a single SMT-LIB program consisting of declarations, auxiliary definitions, and a sequence ofassertstatements that jointly encode the trial’s eligibility logic. Each requirement contributes a tagged fragment to this program, and the system records a mapping from requirements to the corresponding SMT lines so that later debugging and attribution remain possible. C.3.2 Why Incremental Programming Is Necessary Direct one-shot translation from free-text eligibility criteria to a full SMT program is brittle. In practice, such generation tends to fail in several recurring ways: variables are redeclared inconsistently, qualifiers are dropped or attached to the wrong concept, polarity is inverted, and the resulting program may be syntactically valid but semantically unsupported by the source text. These failures are particularly damaging in the clinical setting, where a small symbolic mistake can change the meaning of an eligibility constraint. S AT I R therefore adopts an incremental strategy. Each requirement is translated separately against the current partial program, checked immediately, and either committed or rejected. This design offers two advantages. First, it localizes failures to the requirement that caused them, rather than contaminating the full program. Second, it allows the current symbolic state of the program to guide future translation decisions, especially with respect to variable reuse and consistency. 54 Preprint. Under review. Figure 19: Incremental SMT programming workflow in S AT I R. Starting from atomic, preprocessed requirements, the system constructs a solver- executable SMT-LIB program through a staged orchestration pipeline. For each requirement, S AT I R first prepares the symbolic ingredients needed for formalization, including canonical entities, free non-canonical entities, and their qualifiers. It then identifies reusable variables from the current partial program and introduces new variables only when necessary, drawing from three sources: demographic variables, canonical medical variables grounded in SNOMED CT and the predefined schema, and free variables for clinically meaningful content that cannot be safely canonicalized. Finally,the system translates the requirement into SMT-LIB, validates the resulting fragment against the evolving program, and commits it only if the fragment passes syntactic, logical, and semantic checks. 55 Preprint. Under review. C.3.3 Overview of the Incremental Driver ①②③ Figure 20: SMT programming workflow example. The phrase “steroid-induced osteonecrosis of the jaw” first undergoes qualifier–qualified linking, which identifies osteonecrosis as the base concept and attaches steroid-induced and of the jaw as qualifiers. The system then constructs the corresponding symbolic variable and incrementally commits the resulting SMT assertions only after validation. Even after structured decomposition and entity canonicalization, semantic parsing of clinical requirements into SMT remains challenging. A one-shot LLM translation frequently intro- duces errors, including dropped qualifiers, polarity reversals, conflation of canonical and non-canonical variables, incorrect qualifier attachment, and logically unsupported program structure. For example, in Figure 20, the requirement “steroid-induced osteonecrosis of the jaw” should not be translated by treating steroid-induced, osteonecrosis, and jaw as unrelated symbols. Instead, the system must first determine that steroid-induced and of the jaw both qualify the base concept osteonecrosis, then construct the corresponding symbolic variable, and only then emit the associated SMT assertions. To reduce such errors, S AT I R uses an incremental driver that builds the SMT program requirement by requirement, validating each local fragment before it is committed. For each requirement indexi, the system runs an attempt loop that follows a simple pattern: build a candidate fragment, check it against the current program prefix, and commit it only if it passes validation. Otherwise, the fragment is rolled back and the system retries with feedback from the failed attempt. At a high level, the incremental driver separates five distinct subproblems: 1. identifying which previously declared symbols should be reused, 2. resolving which qualifiers modify which entities or predicates, 3. constructing any new variables needed for the current requirement, 4. translating the requirement into a local SMT fragment, and 5. validating that fragment both logically and semantically before committing it. This decomposition makes the overall synthesis process more stable and more auditable than monolithic generation. C.3.4 Stage 0: Free-Entity Prepass Before per-requirement translation, S AT I R runs a recall-oriented prepass that extracts additional clinically meaningful content not captured by canonical grounding. This includes residual entities or modifiers that remain important for faithful formalization but cannot be safely mapped into the canonical ontology-backed schema. The purpose of this stage is not to compete with canonicalization but to ensure coverage. When clinically meaningful content falls outside the canonical schema, the system still needs a way to represent it symbolically rather than silently discarding it. The free-entity prepass, therefore, seeds the non-canonical naming pathway used later in translation. Prompts used in this stage could be found in Appendix F.1.23 56 Preprint. Under review. C.3.5 Stage 1: Symbol Reuse Identification Given the current partial SMT program, S AT I R first identifies which existing symbols can and should be reused for the current requirement. This step is essential for maintaining global consistency across the evolving program. Many trial criteria refer repeatedly to the same disease, treatment, biomarker, or demographic property, and a correct formalization should represent these repeated mentions with the same underlying symbol whenever their meaning is shared. This stage acts as a structured memory interface for program synthesis. Rather than regener- ating symbols independently for each requirement, the system conditions synthesis on the symbolic state already established by earlier requirements (prompt in Appendix F.1.31). C.3.6 Stage 2: Qualifier–Qualified Linking After identifying reusable symbols, S AT I R resolves qualifier–qualified relationships for the current requirement. This step determines which modifiers attach to which underlying entity or predicate before variable construction and logical translation. It is necessary because qualifiers do not stand alone: they refine the meaning of a specific disease, treatment, finding, temporal condition, or comparison statement, and incorrect attachment can change the meaning of the requirement even when the resulting SMT is syntactically valid. Figure 20 illustrates this step with the phrase “steroid-induced osteonecrosis of the jaw.” Here, osteonecrosis is identified as the base concept, while steroid-induced and of the jaw are linked as attached qualifiers. The resulting symbolic construction therefore starts from the base meaning and augments it with qualifier structure, rather than introducing dis- connected variables. Making this attachment step explicit helps prevent common failures such as dropped qualifiers, wrong modifier scope, and semantically unsupported variable construction. Prompts for stage 2 could be found in Appendix F.1.24, Appendix F.1.25, and Appendix F.1.30. C.3.7 Stage 3: Variable Construction from Three Sources When existing symbols are insufficient, S AT I R introduces new variables. These variables come from three sources, corresponding to three different kinds of semantic commitments in the input: Demographic variables.Controlled template variables are used for schema-level attributes such as age, sex, pregnancy status, and other population descriptors that are commonly expressed in standardized forms (prompt in Appendix F.1.28). Canonical medical variables. When a medically meaningful mention has been safely grounded to SNOMED CT, linked to its relevant qualifiers, and mapped into the predefined schema, the system emits a canonical variable whose name reflects both the normalized concept and its schema role. These variables provide the ontology-aware symbolic backbone of the program (prompt in Appendix F.1.27). Free variables. Not all clinically meaningful content can be safely canonicalized. When grounding is unsupported or the content falls outside the canonical schema, the system introduces a conservative free variable so that the meaning can still be represented in the formal program. This prevents loss of important information merely because normalization was not possible (prompt in Appendix F.1.29). This three-way construction is important because it draws a principled boundary between content that can be represented canonically and content that must remain open-world. The resulting program is therefore both precise where grounding is reliable and conservative where it is not. 57 Preprint. Under review. C.3.8 Stage 4: Local Translation to SMT-LIB Using the requirement text, its decomposition structure, the resolved qualifier links, and the available variable set, the translator generates a local SMT fragment for the current requirement. This fragment may contain new declarations, auxiliary definitions, and one or more assert statements. Each assertion is tagged with a structured:namedlabel that records its requirement identity and internal component structure. These tags support later debugging, especially when the solver returns an UNSAT core or when the system needs to trace a contradiction back to a specific requirement fragment. Translation is also polarity-aware. Inclusion and exclusion requirements must be compiled consistently with the global semantics of the eligibility program, and this stage ensures that the emitted assertions preserve the intended satisfaction behavior (prompts in Ap- pendix F.1.33 and Appendix F.1.32). C.3.9 Stage 5: Solver-Guided Validation and Rollback After a candidate fragment is generated, S AT I R immediately checks the updated program prefix with the SMT solver. If the fragment introduces a parse error, sort mismatch, or immediate contradiction, the fragment is rejected and the system rolls back to the previous program state. The failure signal is then used to guide the next translation attempt. This immediate validation is a key design choice. It turns the solver into an active feedback source during program synthesis rather than merely a final execution engine. By checking each fragment as soon as it is generated, the system prevents local synthesis errors from accumulating into opaque downstream failures. Rollback is strictly local: only the candidate fragment is discarded, while all previously validated requirements remain unchanged. This makes the synthesis process robust and keeps debugging localized. C.3.10 Stage 6: Semantic Verification Syntactic validity and solver consistency are necessary but not sufficient for faithful formal- ization. A fragment can be type-correct and logically satisfiable while still misrepresenting the source requirement. S AT I R therefore applies an additional lightweight semantic verifier after solver validation. The verifier checks whether the fragment preserves the intended meaning of the require- ment and whether it uses the expected entities and qualifiers. In practice, this stage is especially useful for catching common generation errors such as polarity inversion, omitted qualifiers, incorrect qualifier attachment, unsupported variable substitutions, or accidental duplication of symbolic content. The verifier ensures that the generated logic remains seman- tically aligned with the source statement, rather than merely syntactically valid (prompts in Appendix F.1.35 and Appendix F.1.34). C.3.11 Conservative Fallback and Engineering Robustness In rare cases, a requirement may remain difficult to formalize reliably after multiple attempts. To avoid letting a small number of pathological cases stall the construction of the entire program, S AT I R supports a conservative fallback policy. Under this policy, the system may weaken or bypass only the problematic requirement while explicitly recording that this occurred. This fallback is used only as an engineering safeguard. The broader design principle is to preserve forward progress without silently introducing brittle or unverified logic into the final program. 58 Preprint. Under review. C.3.12 SMT Repair Pipeline Although the SMT programming workflow is carefully designed, errors can still occur. We therefore introduce a lightweight repair pipeline for generated SMT programs; see Appendix C.4. C.3.13 Programming of Query Targets in SMT In parallel, we encode the disease list into SMT (Appendix C.6). Once the SMT representation of the disease list and the SMT program of the eligibility criteria are both available, we extract the positive literals from the eligibility-criteria SMT program; these literals define the query targets (Appendix C.5). We then schematize both the disease-list SMT and the positive- literal SMT withR T , following the relation vocabulary described in Appendix B.3. Using the preparation and execution procedure in Appendix D.1, these components are converted into retrieval-ready form and added to the full trial-side SMT constraint representation. Summary. Incremental SMT programming in S AT I R is a staged program synthesis pro- cedure that translates eligibility requirements into formal logic one fragment at a time. By separating symbol reuse, variable construction, local translation, solver-guided validation, and semantic verification, the system turns a brittle one-shot generation problem into a sequence of smaller, checkable decisions. This design substantially improves reliability, interpretability, and debugging for clinical text-to-logic semantic parsing. C.4 LLM-Orchestrated Repair of Trial-Side SMT Programs (Trial-Side Semantic Parsing) This appendix describes the post-processing pipeline we use to improve trial-side SMT programs after initial semantic parsing. The goal of this pipeline is not to re-parse eligibility criteria from scratch, but to repair and tighten existing SMT programs so that they more faithfully encode the intended inclusion and exclusion logic while preserving a conservative retrieval policy. C.4.1 Overview The repair pipeline operates over a canonical directory of SMT-LIB v2 programs, where each file corresponds to one effective trial–subcohort–side pair. Each program represents either the inclusion or exclusion constraints for a particular subcohort. The pipeline applies a sequence of specialized LLM-based repair stages: repair→ polarity→ logic→ gate→ underconstraint→ meaning. The canonical directory is treated as the single source of truth: when a stage produces a valid repair, it overwrites the corresponding canonical SMT file in place. Each stage also records a complete before/after snapshot and stores detailed debugging artifacts. The stages serve different purposes. Early stages correct semantic drift from the initial parser, such as incorrect polarity or malformed logical structure. Later stages identify files that should be removed entirely because the corresponding side has no real natural-language criteria, tighten underconstrained encodings that would otherwise produce false positives, and finally ensure that every declared variable has a self-contained machine-readable inline definition. C.4.2 Inputs and Context For each SMT file, the repair pipeline assembles a structured context bundle. This bundle includes: • the parent trial identifier and effective subcohort identifier; • the target side (inclusion or exclusion); • shared trial-level context; 59 Preprint. Under review. • subcohort-specific context, when available; • side-specific eligibility text for the current subcohort; • the existing canonical SMT program; • the raw trial record from the clinical-trial corpus, used as a fallback safety source. Subcohort matching is performed conservatively. When the snapshot contains explicit map- pings from effective trial identifiers to enrollment cohorts, those mappings are used directly. Otherwise, the pipeline falls back to positional matching only when the corresponding lists are aligned and unambiguous. If no reliable subcohort match is found, a default context is constructed from the available shared trial content. This design allows the repair modules to reason over the correct subcohort whenever possible, while still remaining robust to partially missing upstream metadata. C.4.3 Stage 0: General Semantic Repair The first stage applies a general-purpose semantic repair prompt to the current SMT program. Its purpose is to correct broad semantic drift introduced during the initial text-to-SMT translation, especially cases where literal parsing would make the program overly strict and exclude patients that should remain eligible. This stage is conservative and minimal: it prefers the smallest set of edits needed to restore fidelity to the natural-language criteria. It is allowed to introduce qualified variants of existing predicates, such as@@previous_episodeor@@clinically_significant, when the trial text clearly distinguishes the broad stem from the clinically intended subset. It may also add bridge axioms of the form φ qualified ⇒ φ base to preserve the relationship between the refined predicate and the original stem. A key recurring pattern handled at this stage is the distinction between an index condition required for inclusion and a prior episode of the same condition used for exclusion. For example, if the inclusion criteria require a current thromboembolic event, then an exclusion such as “deep vein thrombosis in the preceding three years” should generally be interpreted as excluding prior episodes rather than the current index event itself. The repair stage makes this distinction explicit by introducing a qualified prior-episode predicate and rewriting the exclusion constraint to use it. Prompt for stage 0 can be found in Appendix F.1.36. C.4.4 Stage 1: Polarity Repair The second stage operates only on exclusion programs. Its purpose is to correct polarity errors caused by the encoding convention used in the system: a patient is eligible only when both the inclusion program and the exclusion program are satisfiable, so exclusion programs are written in a “not excluded” form. Under this convention, a polarity mistake can invert the clinical meaning of an exclusion criterion, making the program satisfiable exactly when the patient should be excluded. This stage inspects each exclusion SMT file against the natural-language exclusion criteria and repairs only the assertions whose polarity is clearly reversed. It does not attempt to rewrite the entire program unless necessary. If no polarity drift is found and the declaration annotations are already valid, the stage returnsNO MODIFICATION REQUIRED. Prompt for stage 1 can be found in Appendix F.1.37. C.4.5 Stage 2: Logic Repair The third stage also operates only on exclusion programs and focuses on logical structure rather than polarity. It repairs errors such as incorrect qualification scope, dropped conjuncts, or mis-grouped conditions whose interpretation depends on the surrounding trial context. A typical example is a qualifier that has been attached too narrowly to one part of a criterion when the natural language makes clear that it should scope over multiple components. 60 Preprint. Under review. This stage is intentionally conservative. It is not a re-parser; instead, it repairs local logical drift when the current SMT structure is inconsistent with the natural-language exclusion criteria for the same subcohort. Prompt for stage 2 can be found in Appendix F.1.38. C.4.6 Stage 3: Criteria Gate The fourth stage is different from the others: it does not repair SMT content. Instead, it decides whether a side-specific SMT file should exist at all. This stage is needed because some trials or subcohorts lack meaningful inclusion or exclusion criteria on one side, but upstream processing may still produce an empty, placeholder, or otherwise non-substantive SMT file. The gate prompt is purely LLM-based and is run even when the SMT file is empty. It receives two evidence blocks: a subcohort-scoped authoritative bundle containing the target side’s criteria, and the raw trial corpus entry for the entire trial. The decision is conservative: the file is deleted only when the model is very sure that the target side for the current subcohort is genuinely absent or placeholder-only. If there is any real side-specific eligibility content, even a single condition such as an age threshold, the file is kept. This stage is destructive only in one direction: it may delete a file, but it never rewrites one. Prompts for stage 3 can be found in Appendix F.1.39 and Appendix F.1.40. C.4.7 Stage 4: Underconstraint Repair The fifth stage addresses the opposite failure mode from the initial semantic repair stage. Whereas the first stage corrects overly strict encodings that would create false negatives, the underconstraint stage tightens encodings that are too lax and would admit false positives. The underconstraint prompt explicitly audits the current program for several classes of failures: •Missing gates: a natural-language requirement is absent from SMT or encoded vacuously. •Weakened structure: the SMT drops conjuncts, weakens thresholds, or otherwise loosens the intended logic. •Overly narrow medical meaning: the SMT uses a predicate that is narrower than the umbrella concept described in the eligibility text. •Insufficient evidence modeling at prescreen: for exclusion criteria, strong clinical support or documented suspicion may need to trigger exclusion when the natural language and prescreen setting justify it. •Undercontextualized variable meanings: the variable definitions themselves are too narrow, too weakly qualified, or attached to the wrong timeframe, causing downstream coding to miss clinically intended matches. A distinctive feature of this stage is that it allows repairs at the level of the representation rather than only at the level of constraints. When the natural language expresses a broader umbrella concept than the one captured by the existing variable stem, the repair may introduce an umbrella variable and connect narrower stems to it via bridge axioms. Likewise, when the natural language justifies a qualifier such as@@suspectedor@@strong_clinical_support, the stage may add the qualified predicate and use it in the constraint while preserving the subset relation to the original stem. This stage is especially important for reducing false positives in retrieval. Without it, a trial- side program may be formally satisfiable while still omitting clinically essential restrictions that a human prescreener would apply immediately. Prompt for stage 4 can be found in Appendix F.1.41. C.4.8 Stage 5: Variable-Meaning Enrichment The final stage does not modify the program logic. Instead, it repairs only variable decla- rations. Everydeclare-constline must contain a valid inline JSON definition on the same 61 Preprint. Under review. line, describing the variable’s meaning and the operational conditions under which it should be set to true, false, null, or to a numeric value. The purpose of this stage is twofold. First, it guarantees that each symbol is self-contained and can be interpreted consistently by downstream coders or patient-fact extraction com- ponents. Second, it eliminates ambiguous or detached declaration metadata, such as JSON comment blocks that appear above the declaration instead of inline. The enrichment prompt derives variable meaning from four sources, in order of priority: the symbol name, its usage in SMT assertions, the side-specific eligibility text, and the broader shared or subcohort context. It is not allowed to change assertions, introduce new declarations, or alter the logical meaning of the program. Its only job is to make declaration annotations complete, valid, and sufficiently contextualized. Prompt for stage 5 can be found in Appendix F.1.42. C.4.9 Strict Validation and In-Place Updates All stages except the gate stage are subject to strict validation before their output can overwrite the canonical SMT file. The validator checks: • balanced parentheses after stripping comments; •absence of forbidden constructs such as datatypes, arrays of unsupported shape, or uninterpreted sorts; • allowed declaration forms and sorts; • validity and completeness of the inline JSON declaration comments; • optionally, the presence and format of assertion names. Before validation, the pipeline also normalizes detached JSON declaration blocks into the required inline form when possible. A repaired program is committed only if it passes vali- dation. Otherwise, the repaired candidate and its validation errors are written to inspection artifacts, and the canonical SMT file is left unchanged. This strict overwrite policy is central to the pipeline’s trustworthiness. The LLM is allowed to propose repairs, but it is not allowed to silently degrade the structural integrity of the symbolic artifact. C.5 Recovering Positive Canonical Literals from Trial Logic (Trial-Side Semantic Parsing) This appendix describes how S AT I R derives the positive canonical literals used in retrieval. Intuitively, these literals identify the clinically meaningful trial-side target conditions that the formal eligibility logic is positively about: diseases, prior procedures, treatment histories, findings, and other canonical clinical states that make a trial relevant to retrieve. These recovered targets are not used merely as raw concepts; they are converted into trial-side target predicates paired with relations fromR t , so that retrieval operates over the same ontology-backed predicate space as the rest of the formalization. The key point is that these targets are not obtained by simply reading off variable names from the SMT program. Instead, S AT I R performs a lightweight semantic recovery procedure over the linked trial logic to identify which canonical clinical propositions are positively enforced by the eligibility criteria. For each trial, the procedure starts from the linked SMT representation together with the canonical variable inventory produced by the normalization pipeline. It then scans the requirement-bearing portions of the SMT program—that is, the assertions corresponding to retained criterion components—rather than treating the full formula as an undifferentiated set of constraints. This keeps the extracted targets aligned with the semantic content of the trial criteria, rather than with auxiliary bookkeeping structure. Within these retained component formulas, S AT I R performs a polarity-aware traversal to recover canonical literals that occur in positive positions. Negation reverses polarity, and 62 Preprint. Under review. implication is handled compositionally, so the method distinguishes conditions that the trial is positively seeking from conditions that appear only in exclusions, guards, or logically reversed contexts. In this way, the extracted literals correspond to clinical states whose truth supports satisfying the trial-side component. To make this recovery robust, S AT I R first inlines shallow Boolean helper definitions of the form (= X φ), so that positivity can flow through auxiliary symbols into the underlying clinical proposition. This is important because trial logic often introduces intermediate variables for readability or modularity, while retrieval should expose the clinically meaningful concept rather than the local helper name. S AT I R also performs a lightweight implication-based expansion over auxiliary constraints. The motivation is that the most retrieval-useful concept is not always the exact symbol that appears in a component. In many cases, a positively enforced trial-side state implies a more canonical or retrieval-friendly diagnosis, finding, or treatment-related concept. When such implication structure is explicitly encoded in the SMT, S AT I R propagates positivity through it and retains the implied canonical target as well. The same idea is used for simple threshold-triggered conditions when a positively enforced numeric predicate implies a clinically meaningful canonical state. Finally, qualified or context-specific variants are collapsed to representative canonical stems, so that multiple logical variants of the same underlying concept contribute to a single nor- malized retrieval target.The resulting targets are then passed through the same conservative specificity filtering used elsewhere in retrieval: a target is removed only when a strictly more specific substitute from the same source-specific candidate set is already present. After filtering, each retained target concept is paired with an appropriate trial-intent relation from R t (for example, T R E AT, P R E V E N T, or D I A G N O S E) to form a canonical trial-side target predicate. In this way, positive literal recovery yields not just concepts, but formal retrieval targets that live in the same (r, k, q)-style representation as the rest of S AT I R. This procedure produces a set of retrieval targets that is broader and more semantically grounded than disease-list metadata alone. Disease lists capture coarse trial intent, but positive canonical literals recovered from the trial logic additionally expose the finer-grained clinical structure encoded in eligibility criteria, including prior interventions, treatment con- text, findings, and other non-disease states. In this sense, positive canonical literal extraction is best viewed as a semantic target recovery step: it reads the formal trial logic, identifies the canonical clinical states that the trial is positively seeking, and exports them into the unified trial–patient logic store as reusable retrieval signals. Example.Consider a trial whose linked SMT contains a retained requirement component that positively enforces a variable corresponding to active Graves’ hyperthyroidism, together with an auxiliary implication from that variable to a broader canonical diagnosis such as thyrotoxicosis due to Graves’ disease. A surface-level extractor might recover only the exact helper variable appearing in the component. In contrast, S AT I R first identifies that the component is positively about the active disease state, then propagates positivity through the auxiliary implication, and finally maps the result back to canonical retrieval targets. The final output is therefore a small set of clinically meaningful canonical literals, rather than a brittle set of internal SMT variable names. C.6 Disease List Processing and Canonicalization for Trial Target Conditions In addition to full eligibility criteria, many clinical trials provide short disease or condition fields that summarize the clinical problems a study aims to treat, mitigate, monitor, prevent, or examine longitudinally. These fields are useful for retrieval because they often expose the trial’s target disease space directly. However, they are substantially less structured than eligibility criteria and may contain formatting artifacts, mixed levels of specificity, or contextually related but non-target conditions. S AT I R therefore processes disease-list 63 Preprint. Under review. content with a dedicated lightweight pipeline rather than routing it through the full SMT compilation workflow used for eligibility criteria. The goal of this pipeline is to construct a faithful set of trial-side disease targets that can augment the target set used in retrieval. Concretely, S AT I R applies a staged procedure: Extractor→ Eliminator→ Preprocessor→ Canonicalizer. This pipeline is lightweight in the sense that it does not attempt to recover full logical struc- ture from disease-list text. Instead, it focuses on high-recall disease recovery, conservative filtering, stable string normalization, and ontology grounding. Extraction. The first stage extracts a comprehensive list of candidate diseases from trial context, using the summary, disease metadata, and inclusion-focused text. Extraction is intentionally recall-oriented, but constrained to explicit evidence: diseases must be explicitly mentioned in the summary or inclusion requirements rather than inferred from loosely related symptoms or background context. Existing disease-list items provided with the trial are preserved rather than dropped, even when their surface form is awkward or metadata- like. Elimination. Because trial summaries and metadata may mention diseases that are adja- cent to the study context but not actually part of the target disease set, S AT I R next applies a relevance-based elimination step. A disease is retained if it is explicitly relevant to the trial’s clinical focus, including treatment, mitigation, screening, prevention, diagnosis, surveillance, or longitudinal study. A disease is not removed merely because patients with that condi- tion may be excluded in some settings, or because only a subtype or stage is ultimately enrolled. This stage improves precision without collapsing away clinically meaningful target conditions. Preprocessing.After elimination, S AT I R applies conservative string-level preprocessing to normalize the retained disease list. This stage performs lightweight cleanup such as whitespace normalization, alias handling, optional synonym expansion, and deduplication. A key design choice is that disease entries are treated as atomic by default. In particular, the preprocessor does not split on commas, since many biomedical disease names use inverted modifier order, such as “Kidney Failure, Chronic” or “Pulmonary Disease, Chronic Obstructive.” Instead, such strings are preserved and normalized only in ways that do not alter their meaning. The purpose of preprocessing is therefore not semantic reinterpretation, but representational stability. Canonicalization. The final stage maps each retained disease mention to SNOMED CT. This step follows the same conservative grounding principle used elsewhere in S AT I R: a candidate concept is accepted only if it is either semantically identical to the intended disease string or a valid strict ancestor of it. Exact matches are preferred. If no exact match exists, the system selects the most specific valid ancestor. If no faithful match is available, the disease mention is retained without forcing an incorrect ontology assignment. This prevents false precision and preserves the original disease evidence for downstream use. The canonicalization workflow is roughly the same as the one described in Appendix C.2. Cohort-specific processing.When trials contain multiple enrollment cohorts, S AT I R can run this disease pipeline separately for each cohort using cohort-specific contextual text. This is important because different cohorts may correspond to different diseases, subtypes, or treatment settings. Cohort-aware disease processing therefore preserves distinctions that would be lost if the trial were treated as having a single flat disease list. Role in retrieval. The output of this pipeline is a set of normalized disease mentions together with their selected SNOMED concepts when faithful grounding is available. These disease-derived targets are incorporated into the trial-side target representation used during retrieval by pairing them with appropriate trial-intent relations fromR t , alongside targets recovered from the formal eligibility representation. 64 Preprint. Under review. Summary.Overall, S AT I R treats trial disease lists as a distinct semantic parsing problem. Rather than compiling them into full eligibility logic, the system extracts target disease mentions from trial context, removes irrelevant items, normalizes them conservatively, and grounds them to SNOMED CT under an exact-or-valid-ancestor policy. This yields a compact but faithful disease-target representation that complements the richer formal structure derived from trial eligibility criteria. C.7 Patient-Side Semantic Parsing Pipeline This appendix describes the patient-side semantic parsing pipeline that maps raw clinical notes directly into the symbolic space used for SMT-based trial matching. The central design goal is not merely to extract medical information from text, but to construct patient-side SMT-ready atomic evidence over the same ontology-backed symbolic vocabulary used on the trial side. In this sense, the patient-side problem is a semantic parsing problem into SMT from the outset. The pipeline is intentionally modular. Rather than asking a single model to map a free- text patient note directly into final formal assertions in one step, the system decomposes patient-side semantic parsing into a sequence of narrower transformations, each with its own output contract and verifier. This decomposition improves controllability, makes failure modes easier to localize, and yields intermediate artifacts that remain interpretable to both clinicians and system developers. At a high level, the pipeline takes as input a free-text patient note and progressively con- structs SMT-compatible patient evidence. Intermediate stages include fact extraction, fact normalization, entity grounding, atomic SMT declaration and verification. The key distinction from the trial side is that the patient-side pipeline does not compile a full eligibility formula. Trial text specifies compositional requirements and is therefore compiled into executable logical constraints. Patient notes instead provide evidence about one individual. The patient-side semantic parsing problem is therefore to recover atomic SMT-grounded assertions that can later be checked against the trial-side formula. These atomic outputs do not themselves encode eligibility logic; they provide the structured evidence that downstream SMT evaluation consumes. The prompts used for patient-side semantic parsing are listed in Appendix F.2 (Appendix F.2.1 - F.2.17). C.7.1 Design Goals The patient-side pipeline is designed around four requirements. First, it must preserve clinical faithfulness. Patient notes are often incomplete, indirect, and heterogeneous in style. The system therefore separates explicit statements from plausible but uncertain clinical inferences, and it requires every extracted diagnosis, fact, and atomic declaration to be justified by supporting evidence. Second, it must support direct symbolic executability. Downstream trial matching operates over typed variables and logical constraints rather than raw text alone. Patient-side outputs must therefore be normalized into ontology-grounded atomic forms that can be rendered directly as Boolean predicates, numeric assignments and temporalized SMT-ready evidence. Third, it must provide fine-grained auditability. Each stage emits an interpretable artifact with a strict schema, so that failures can be localized to a specific transformation step. Fourth, it must be conservative under uncertainty. On the patient side, unsupported overcom- mitment can lead to incorrect exclusions or spurious matches. The pipeline therefore prefers explicit support, preserves uncertainty where appropriate, and inserts dedicated verification stages before evidence is promoted into the formal symbolic representation. C.7.2 Patient Constraint Formal Representation In the main text, each patient recordp∈ Pis represented by a patient constraintPC( p), an SMT formula over canonical predicates inΠ(R M ∪ R P ,K,Q). The patient-side semantic 65 Preprint. Under review. parsing pipeline is thus the process of mapping free-text patient descriptions into the ontology-grounded symbolic space used by the formal representation in the main text. Specifically, the parser extracts grounded patient evidence in canonical form, with predicates π = (r, k, q),r ∈ R M ∪ R P , k∈ K, q∈ Q∪∅, and, when needed, atomic constraints a = (π, cmp, t)∈ A. These atoms form the building blocks of PC( p). This differs from the trial side. For each trialc ∈ C, the main text defines a trial constraint TC(c), an SMT formula over predicates inΠ(R M ∪ R T ,K,Q), often with richer logical struc- ture such as conjunction, disjunction, counting, and negation. Patient notes, by contrast, typically provide grounded evidence—diagnoses, findings, procedures, medications, mea- surements, histories, and chief complaints—rather than explicit eligibility logic. Accordingly, the role of patient-side semantic parsing is not to synthesize an independent eligibility program, but to construct SMT-consumable patient evidence in the same symbolic language used by the trial representation. Because bothPC( p)andTC(c)are grounded in the shared ontology O = (R, K, Q,⊑), their interaction can be evaluated in a uniform way through the subsumption family ⊑=⊑ R ∪⊑ K ∪⊑ causal ∪⊑ Q . In this sense, patient-side semantic parsing is the bridge from free text to the formal repre- sentation: it converts patient descriptions into canonical predicates and atomic constraints so they can be matched directly against trial constraints in the shared ontology-backed symbolic space. C.7.3 Pipeline Overview Before semantic parsing, the system may first infer likely diagnoses and possible preven- tion targets from the patient note; these stages are described in Appendix C.9.1 and Ap- pendix C.9.3. They are not part of the semantic parsing pipeline itself. The patient-side semantic parsing pipeline then proceeds in four main steps. Fact extraction. The note is broken into a set of self-contained patient facts. Each fact captures one clear piece of patient information together with directly attached details such as severity, location, marker status, or quantity. Each fact is also linked back to its source text for auditing. Fact normalization.The extracted facts are rewritten into a cleaner and more explicit form for downstream processing. This includes expanding shorthand expressions, making shared structure explicit, and preserving the original meaning while making the content easier to encode formally. Entity grounding. Normalized facts are processed by a medical entity recognizer and linked to SNOMED concepts. This step aligns patient evidence with the same canonical concept space used on the trial side. Atomic SMT declaration.The grounded facts are converted into typed atomic declarations for downstream matching. These include demographic variables such as age and sex, as well as canonical clinical facts such as conditions, findings, procedures, substances, and observables. Numeric values are kept in numeric form, and each declaration carries any relevant qualifiers and temporal scope. 66 Preprint. Under review. Verification. Lightweight checks are applied throughout the pipeline to ensure that ex- tracted facts stay faithful to the note, normalization does not change meaning, ontology relationships are valid, and final atomic declarations are supported by the source text. C.7.4 Temporal Representation Temporal information is attached throughout the patient pipeline. When timing is unclear, the system uses conservative broad intervals rather than inventing precise dates. Final patient declarations therefore record when a fact certainly holds or may hold, so that time- sensitive trial criteria can be evaluated later. C.7.5 Patient-Side Semantic Parsing into SMT The patient side does not build a full standalone SMT formula like the trial side. Instead, it produces typed, ontology-grounded, time-aware atomic facts that are meant to be consumed directly by downstream SMT evaluation. In this sense, the patient pipeline is still a form of semantic parsing into SMT: its output is not generic structured data, but formal symbolic evidence. C.7.6 Resulting Patient Representation The final output is a structured patient representation consisting of source-linked facts, normalized facts, grounded medical entities, and atomic SMT-ready evidence with values, qualifiers, and time scope. The trial side provides the logical structure, and the patient side provides the grounded evidence used to evaluate it. C.8 Patient-side time intervalization Figure 21: Time intervalization converts implicit temporal information in patient notes into explicit, conservative time windows used for eligibility evaluation. From each patient fact, we extract two temporal intervals: (i) a may-hold window, representing the time interval during which the patient may have progressive dysphagia, and (i) a must-hold window, representing the time interval during which the patient must have progressive dysphagia. When an inclusion criterion has any time-interval overlap with the may-hold window, the patient is eligible under this criterion. When an exclusion criterion has any time-interval overlap with the must-hold window, the patient is ineligible under this criterion. Prompt implementation can be found at Appendix F.2.13 and F.2.12 C.8.1 Two-window representation Each extracted patient factfis represented with two time windows: (i) a certain window W C E R T ( f )during which the fact definitely holds, and (i) a possible windowW P O S S ( f )that upper-bounds where the fact may hold. Both windows are encoded as start/end bounds with direction (past, now, future), magnitude, units, and inclusivity. 67 Preprint. Under review. C.8.2 Normalization to numeric bounds We normalize bounds to hours relative to the note timestamp (“now”): (direction, magnitude, unit)7→ t∈ R∪±∞, with past mapped to negative hours and future to positive hours. We reject invalid windows (future times for diagnoses; start>end) and clip/approximate unbounded windows using a large sentinel when required for engineering convenience. C.8.3 SMT encoding For a Boolean predicateprepresenting a fact and a window[t s ,t e ], we compile a time- aware assertion using an explicit time variable or a window-qualified predicate, depend- ing on the chosen SMT signature. Our implementation carries the four window fields (start_time_in_hours,end_time_in_hours,start_time_inclusive,end_time_inclusive) with each fact and uses them for (a) rule-based entailment reuse and (b) deduplication. C.8.4 Deduplication key Derived and extracted facts are deduplicated by: (entity_variable_name, t s , t e , I[start inclusive], I[end inclusive]), so the same predicate under different windows is retained. C.9 Patient-side inference modules C.9.1 Differential diagnosis from full notes We run a differential diagnoser over the full note to propose diagnosis candidates with:diagnosis,confidence ∈ [0, 1], supporting evidence snippets, and time bounds (confirmable_latest_start_time,confirmable_earliest_end_time). We generate multiple stochastic samples and merge them by diagnosis name, keeping the maximum confidence and unioning evidence. We drop candidates whose inferred time bounds are in the future or temporally inconsistent. Prompt implementation can be found in Appendix F.4.1. C.9.2 Inferring procedures-to-undergo Note that this component is not used in the current experiments, but our failure-case analysis suggests that reintroducing it may be beneficial. We separately infer significant procedures the patient likely needs to treat primary conditions (excluding routine diagnostics and logistics). Each inferred procedure is produced with confidence and a forward-looking time window; it is compiled into procedure predicates such aspatient_needs_to_undergo_proc with guarded activation analogous to diagnoses. Prompt implementation can be found in Appendix F.4.3. C.9.3 Diseases-to-prevent We identify diseases the patient explicitly seeks to prevent (or prevention goals that are near- universal consequences of an explicitly stated condition). These are encoded as prevention- intent predicates and used only in task modes that evaluate preventive matching. Prompt implementation can be found in Appendix F.4.2. 68 Preprint. Under review. D Database Retrieval Details D.1 Database Preparation for Retrieval and High-Level Execution Flow of Retrieval (assert symptomatic_carotid_stenosis) (assert carotid_stent) (assert (or carotid_plaque_ulceration unstable_neurologic_symptoms)) (assert (or prior_tia minor_ischemic_stroke)) (assert (not intracranial_hemorrhage)) Formalize Eligibility Criteria Canonicalize Disease List Items Title: Preventive therapy for recurrent ischemic stroke in adults with symptomatic carotid stenosis undergoing carotid artery stenting. Diseases: ["ischemic stroke, recurrent"] Eligibility Criteria: Eligible patients must have symptomatic carotid stenosis and planned carotid artery stenting. Patients must have either residual carotid plaque ulceration on imaging or investigator-documented unstable neurologic symptoms. Patients must also have either prior transient ischemic attack or minor ischemic stroke. Intracranial hemorrhage is excluded. Extract Positive Canonical Literals Project into Gate Formula Recurrent ischemic stroke symptomatic_carotid_stenosis carotid_stent carotid_plaque_ulceration prior_tia minor_ischemic_stroke (assert symptomatic_carotid_stenosis) (assert carotid_stent) (assert (or prior_tia minor_ischemic_stroke)) (assert (not intracranial_hemorrhage)) Schematize Retrieval Targets Prevents recurrent ischemic stroke Mitigates procedure-associated risk of carotid artery stenting Treats downstream complication of symptomatic carotid stenosis Selects patients with carotid plaque ulceration Selects patients with prior transient ischemic attack Selects patients with minor ischemic stroke Schematize SatIR Unified Trial-Patient Logic Store Ingest w/ Salience Enrichment Ingest w/ Salience Enrichment Figure 22: Offline construction of the trial-side retrieval database in S AT I R. From each trial, S AT I R derives canonical disease-list targets, canonical targets recovered from the formalized eligibility logic, and a recall-preserving eligibility gate formula projected from the full SMT representation. These artifacts are normalized, schematized into retrieval targets , and ingested into the unified trial–patient logic store for query-time retrieval and pruning. SatIR Unified Trial-Patient Logic Store Query Constructor Relevance Query Executor Per-Patient Query Gate Formula Query Executor Figure 23: Online query-time retrieval in S AT I R. Given a patient record and retrieval objective, S AT I R retrieves topically relevant trials by objective-conditioned matching against precomputed trial-side targets, evaluates recall-preserving gate formulas whose disjunctive salience structure is retained on the trial side against the patient’s sparse observed facts, and passes the remaining candidates to full SMT-based eligibility checking. As shown in Figure 22, S AT I R builds retrieval around an offline-constructed trial-side index stored in a unified trial–patient logic store. Each trial contributes two kinds of relevance targets, together with an additional gate formula used for high-recall pruning at query time. The first source of relevance targets is the trial’s formalized eligibility logic. From the SMT representation, S AT I R extracts positive canonical literals that represent clinically meaningful targets explicitly expressed in the criteria, including not only disease conditions but also prior procedures, prior treatments, and other eligibility-defining clinical states. The second source is the trial disease list. These disease-list items are canonicalized through the same concept normalization pipeline described in Section 2.3, but are generated independently of the SMT-derived literals and mapped into the same retrieval schema. This distinction matters: disease-list targets contribute only disease-oriented trial intent, whereas SMT- derived literals capture a broader set of clinically relevant retrieval signals. In practice, the disease list is especially useful for trials whose central condition is implicit in the eligibility logic, such as prevention or diagnosis-oriented studies. After canonicalization, both sources are schematized into a shared target representation and filtered conservatively for specificity before ingestion into the store (Figure 22). A target 69 Preprint. Under review. is removed only when a strictly more specific substitute already exists within the same source-specific candidate set; otherwise it is retained to preserve recall. In addition to relevance targets, each trialcis assigned a gate formulaΨcderived offline from its full eligibility formulaΦ c , as illustrated in Figure 22. The gate formula is a recall- preserving projection of the full SMT program onto efficiently testable canonical atoms, satisfying Φ c ⇒Ψc. It therefore captures necessary, but generally not sufficient, conditions for full eligibility. Importantly, clinically acceptable salience alternatives are compiled intoΨcon the trial side and retained as disjunctive structure, rather than being exhaustively enumerated on the patient side. At query time, the patient’s sparse observed evidence is checked against this retained structure, so whole-fact missingness and specificity-aware uncertainty are handled through which trial-side branches can or cannot be satisfied. Appendix D.2 describes how these projected gate formulas are ingested, stored, and executed, and Figure 24 shows a concrete example. At query time, retrieval proceeds in two stages, shown in Figure 23. Given a patient record and retrieval objective, S AT I R first performs objective-conditioned matching against the precomputed trial-side targets to identify topically relevant trials. It then evaluates each retained trial’s gate formula as a lightweight high-recall filter by checking the patient’s sparse observed evidence against the gate’s retained trial-side disjunctive structure. The surviving candidates are passed to the full SMT-based eligibility checker, along with lightweight explanations of why each trial was retrieved or filtered. D.2 Projected CNF Storage and SQL-Style Retrieval Execution This appendix explains how the executable projected constraints from Section 5 are stored and evaluated in S AT I R. The key idea is to compile the retrieval-relevant part of each trial or patient constraint into a relational representation that can be executed efficiently with SQL-style joins and aggregations. This yields a scalable database retrieval layer over the projected constraint space. As described in Section 5, each original constraint formula is conservatively converted into an executable quantifier-free formula over canonical atoms that can be represented and matched in the database while preserving full recall. The executable formula is then written in conjunctive normal form (CNF), so retrieval can be implemented by evaluating atom compatibility, clause support, and all-clause satisfaction directly over relational tables. A key design choice is that clinically acceptable alternatives—such as ontology-supported generalizations or other retrieval-side substitutions—are materialized on the trial side as explicit disjunctions in the executable CNF. We do not exhaustively materialize all such alternatives on the patient side. Online retrieval therefore evaluates the patient’s sparse projected evidence against the stored trial-side disjunctive structure. Projected CNF representation.For each entitye∈ C∪ P, letC N F(e)denote its executable projected CNF constraint: C N F(e) = m e i=1 d i ,d i = n i _ j=1 a ij , where each atomic constrainta ij uses only canonical predicates and retained canonical qualifier fields. Boolean and numerical atoms are stored separately, but both participate in the same clause-level and CNF-level retrieval procedure. Relational storage. As described in Section 5, executable CNF constraints are stored as first-class relational objects using five tables: E C N F(e, cnf),C N F D(cnf, d),D A(d, a),A B(a, π, cmp, t),A N(a, π, cmp, t). 70 Preprint. Under review. eπ val patient 1patient 2 123has_bipolar10 123has_depression10 123has_schizo01 123has_undergone_PCI00 123is_smoking01 123Is_drinking01 Inclusion Criteria cnf1: (has_bipolar OR has_depression OR has_schizo) AND (NOT has_undergone_PCI) AND ((NOT is_smoking) OR (NOT is_drinking)) Patient 1 facts: has_bipolar has_depression aπ cmp a11has_bipolar1 a12has_depression1 a13has_schizo1 a21has_undergone_PCI0 a31is_smoking0 a32Is_drinking0 d1 d2 d3 Conjunctive (∧) d1 ∧ d2 ∧ d3 Disjunctive (∨) d1 = a11 v a12 v a13 d2 = (-a21) d3 = (-a31) v (-a32) Patient 1: SATISFIED Patient Fact Tables (P) Boolean Atom Table AB(a, π, cmp, t) ∧ (and) d a d1a11 d1a12 d1a13 d2a21 d3a31 d3a32 cnfd cnf1d1 cnf1d2 cnf1d3 constraints Eval clause (d) Eval a Eval d Eval cnf Eval atom (a) Eval cnf If polarity == patient fact val Take maximum across disjunctive Take minimum across conjunctive ∧ Clause Eval (d) patient 1patient 2 d111 d211 d310 cnf cnf Eval patient 1patient 2 cnf110 Patient 2: UNSATISFIED Patient 2 facts: has_schizo is_smoking is_drinking Atom Match (a) patient 1patient 2 10 10 01 11 10 10 DA CNFD pidVariable val patient 1patient 2 123has_bipolar10 123has_depression10 123has_schizo01 123has_undergone_PCI00 123is_smoking01 123Is_drinking01 Inclusion Criteria C1: (has_bipolar OR has_depression OR has_schizo) AND (NOT has_undergone_PCI) AND ((NOT is_smoking) OR (NOT is_drinking)) Patient 1 facts: has_bipolar has_depression V∧Variable Is positive o1a1has_bipolar1 o2a1has_depression1 o3a1has_schizo1 o4a2has_undergone_PCI0 o5a3is_smoking0 o6a3Is_drinking0 a1 a2 a3 Conjunctive (∧) a1 ∧ a2 ∧ a3 Disjunctive (∨) a1 = o1 v o2 v o3 a2 = (-o4) a3 = (-o5) v (-o6) Patient 1: SATISFIED Patient Fact Tables (P) Trial Variable Polarity Table (AB) ∧ (and) ∧ ∨ a1o1 a1o2 a1o3 a2o4 a3o5 a3o6 C∧ c1a1 c1a2 c1a3 constraints Eval ∧ Eval v Eval ∧ Eval constr- aint Eval v Eval constraint If polarity == patient fact val Take maximum across disjunctive Take minimum across conjunctive ∧ ∧_eval patient 1patient 2 a111 a211 a310 C C_eval patient 1patient 2 C110 Patient 2: UNSATISFIED Patient 2 facts: has_schizo is_smoking is_drinking ∨-Eval patient 1patient 2 10 10 01 11 10 10 DACNFD ecnf 123cnf1 ECNF Figure 24: Example execution of the projected-constraint retrieval procedure in the SQL layer. Execution proceeds in three stages: compatible atom matching, clause-level support, and all-clause aggregation over the trial CNF. Here,E C N Flinks an entityeto its executable CNF identifiercnf;C N F Dlinks a CNF to its disjunctive clauses; andD Alinks a clause to its member atoms. TablesA BandA N store Boolean and numerical atoms, respectively, together with their canonical predicateπ, comparison fieldcmp, and retained qualifier fieldst. Entity type is determined by whether e∈ C or e∈ P. This representation allows executable constraints to be stored once and evaluated repeatedly by relational joins, rather than reconstructing logical structure at query time. It is also natural for trial-side alternatives: if a trial clause admits multiple acceptable support paths, these are stored directly as multiple atoms linked to the same clause through D A. Objective-conditioned retrieval semantics. Retrieval is defined with respect to an objec- tiveθ, which determines which trial-side projected clauses are retrieval-relevant and which patient-side projected atoms may be used to support them. Thus, the SQL layer does not match all stored atoms indiscriminately. Instead,θinduces an objective-specific admissibility relation over trial and patient atoms. For a trialc, letD θ (c)denote the set of retrieval-relevant projected clauses inC N F(c)under objectiveθ. Retrieval proceeds by identifying retrieval-relevant trial atoms and admissible patient atoms, forming compatible atom matches, lifting these matches to supported trial clauses, and retaining only those trial–patient pairs for which every clause inD θ (c)is supported. Patient-side evidence. At query time, the patient contributes a sparse set of observed projected atoms. Boolean evidence corresponds to canonical Boolean atoms stored inA B, while numerical evidence corresponds to canonical numerical atoms stored inA N. In both cases, the patient-side representation remains sparse: the retrieval layer uses only the projected evidence explicitly retained after patient-side conversion, rather than exhaustively generating all ontology-induced alternatives. This design is important for both efficiency and control. Trial-side flexibility is represented through disjunction in the stored executable CNF, while the patient side contributes only the projected atoms supported by the patient record. SQL-style execution. Given a retrieval objectiveθ, execution follows the projected CNF structure directly. 71 Preprint. Under review. Atom level. We first identify retrieval-relevant trial atoms and admissible patient atoms from the stored CNF objects. Concretely, trial and patient entities are linked to CNFs through E C N F, CNFs to clauses throughC N F D, and clauses to atoms throughD A; Boolean and numerical atom contents are read fromA BandA N. Trial and patient atoms are matched when the objective permits the corresponding support relation, their retained qualifier fields are compatible, and their comparison fields are mutually compatible. This yields a relation of compatible atom pairs. Clause level. Compatible atom pairs are lifted throughD A(d,a)to recover the trial clauses containing those atoms. A retrieval-relevant trial clause is treated as supported if at least one of its member atoms has a compatible patient-side match. CNF and entity level. Supported trial clauses are aggregated back throughC N F D(cnf,d) andE C N F(e,cnf). A trial–patient pair is retained only if every retrieval-relevant trial clause of the trial is supported. Equivalently, retrieval returns (c, p) only if ∀d∈D θ (c),d is supported by p. This semantics maps directly to SQL execution: compute supported trial clauses for each trial–patient pair, then retain only those pairs for which the number of supported retrieval- relevant trial clauses equals the total number of retrieval-relevant trial clauses. The following pseudo-SQL sketch illustrates the structure: WITH − R e t r i e v a l − r e l e v a n t t r i a l a t o m s u n d e r o b j e c t i v e Î ÿ T h e t a T r i a l A t o m s AS ( SELECT e c . eAS t r i a l _ i d , c f . dAS t r i a l _ c l a u s e _ i d , da . aAS t r i a l _ a t o m _ i d , ab . p iAS p i , ab . cmp AS cmp , ab . tAS t FROM ECNF e c JOIN CNFD c f ON e c . c n f = c f . c n f JOIN DAda ON c f . d = da . d JOIN ABab ON da . a = ab . a WHERE e c . e IN T r i a l E n t i t i e s AND T r i a l A t o m R e l e v a n t ( ab . p i , Î ÿ ) UNION ALL SELECT e c . eAS t r i a l _ i d , c f . dAS t r i a l _ c l a u s e _ i d , da . aAS t r i a l _ a t o m _ i d , an . p iAS p i , an . cmp AS cmp , an . tAS t FROM ECNF e c JOIN CNFD c f ON e c . c n f = c f . c n f JOIN DAda ON c f . d = da . d JOIN ANan ON da . a = an . a WHERE e c . e IN T r i a l E n t i t i e s AND T r i a l A t o m R e l e v a n t ( an . p i , Î ÿ ) ) , − A d m i s s i b l e p a t i e n t a t o m s u n d e r o b j e c t i v e Î ÿ T h e t a P a t i e n t A t o m s AS ( 72 Preprint. Under review. SELECT e c . eAS p a t i e n t _ i d , da . aAS p a t i e n t _ a t o m _ i d , ab . p iAS p i , ab . cmp AS cmp , ab . tAS t FROM ECNF e c JOIN CNFD c f ON e c . c n f = c f . c n f JOIN DAda ON c f . d = da . d JOIN ABab ON da . a = ab . a WHERE e c . e IN P a t i e n t E n t i t i e s AND P a t i e n t A t o m A d m i s s i b l e ( ab . p i , Î ÿ ) UNION ALL SELECT e c . eAS p a t i e n t _ i d , da . aAS p a t i e n t _ a t o m _ i d , an . p iAS p i , an . cmp AS cmp , an . tAS t FROM ECNF e c JOIN CNFD c f ON e c . c n f = c f . c n f JOIN DAda ON c f . d = da . d JOIN ANan ON da . a = an . a WHERE e c . e IN P a t i e n t E n t i t i e s AND P a t i e n t A t o m A d m i s s i b l e ( an . p i , Î ÿ ) ) , CompatibleAtomPairs AS ( SELECT t . t r i a l _ i d , p . p a t i e n t _ i d , t . t r i a l _ c l a u s e _ i d , t . t r i a l _ a t o m _ i d , p . p a t i e n t _ a t o m _ i d FROM T h e t a T r i a l A t o m s t JOIN T h e t a P a t i e n t A t o m s p ON O b j e c t i v e A l l o w s ( t . p i , p . p i , Î ÿ ) AND Q u a l i f i e r C o m p a t i b l e ( t . t , p . t , Î ÿ ) AND ComparisonCompatible ( t . cmp , p . cmp ) ) , S u p p o r t e d T r i a l C l a u s e s AS ( SELECT DISTINCT t r i a l _ i d , p a t i e n t _ i d , t r i a l _ c l a u s e _ i d FROM CompatibleAtomPairs ) , A l l T h e t a T r i a l C l a u s e s AS ( SELECT DISTINCT t r i a l _ i d , t r i a l _ c l a u s e _ i d FROM T h e t a T r i a l A t o m s ) , 73 Preprint. Under review. R e t u r n e d P a i r s AS ( SELECT a . t r i a l _ i d , s . p a t i e n t _ i d FROM A l l T h e t a T r i a l C l a u s e s a LEFT JOIN S u p p o r t e d T r i a l C l a u s e s s ON a . t r i a l _ i d = s . t r i a l _ i d AND a . t r i a l _ c l a u s e _ i d = s . t r i a l _ c l a u s e _ i d GROUP BY a . t r i a l _ i d , s . p a t i e n t _ i d HAVING COUNT( DISTINCT a . t r i a l _ c l a u s e _ i d ) = COUNT( DISTINCT s . t r i a l _ c l a u s e _ i d ) ) SELECT * FROM R e t u r n e d P a i r s ; Here,TrialEntitiesandPatientEntitiesdenote the sets of trial and patient entity iden- tifiers, respectively. The helper predicatesTrialAtomRelevant,PatientAtomAdmissible, ObjectiveAllows,QualifierCompatible, andComparisonCompatiblestand in for the objective-specific admissibility test and the atom-level compatibility checks described in Section 5. Equivalent relational-algebra view.The same procedure can be expressed more abstractly in relational-algebra terms. First form the retrieval-relevant trial-atom relation and the admissible patient-atom relation by joining E C N F ▷◁ C N F D ▷◁ D A ▷◁ (A B∪ A N) and filtering by the objectiveθ. Then join these two relations using the atom-level compati- bility predicate to obtain compatible atom pairs. Next, project to supported trial clauses by retaining(c,p,d)whenever some atom in trial clausedhas a compatible patient-side match. Finally, group by(c,p)and retain only those pairs for which the number of supported trial clauses equals|D θ (c)|. Why this preserves full recall. The full-recall guarantee comes from the conservative conversion step in Section 5. Conversion removes or weakens parts of the original formulas only in a recall-safe direction, so every true match under the full SMT constraints remains satisfiable in the executable projected representation. The SQL retrieval layer then evaluates those executable constraints by checking support for every retrieval-relevant trial clause in D θ (c). It may admit extra trial–patient pairs that are later ruled out by deeper reasoning, but it does not eliminate any pair that could satisfy the original constraints. This is exactly the full-recall property proved in Appendix D.3. Role in the retrieval pipeline.This SQL layer is the executable realization of the projected CNF representation introduced in Section 5. Offline, it materializes trial and patient con- straints as reusable clause-based relational objects inE C N F,C N F D,D A,A B,A N. Online, it evaluates objective-conditioned compatibility between patient-side and trial-side projected atoms, lifts compatible atom matches to supported trial clauses, and returns only those trial–patient pairs whose retrieval-relevant trial clauses are all supported. The surviving candidates are then passed to the downstream reasoning stage for more exact relevance and eligibility evaluation. Prompts for target schematization on trial side could be found in Appendix F.1.43, Ap- pendix F.1.44, Appendix F.1.45, Appendix F.1.46, and Appendix F.1.47, D.3 Why the Retriever Has Full Recall We show that every truly matching trial–patient pair is returned by S AT I R. The argument has two parts. First, conversion from the full SMT constraints to the executable CNF con- straints stored in the database is conservative, so any true match remains compatible after 74 Preprint. Under review. conversion. Second, the join-based retrieval test is itself a conservative relaxation of exact compatibility over these executable constraints. Theorem 1 (Full recall of S AT I R). Assume the atom-level compatibility test used in the database join is sound in the following sense: whenever a trial atom and a patient atom can both hold under the same assignment, the join procedure marks them as compatible. Then every true match under the full SMT formulation is returned by S AT I R. Equivalently, if (c, p)∈ C T M(O, T, PT, OT), then (c, p)∈ S AT I R(T R I A L R E P R(O, T, PT, OT)). Proof. Let(c,p) ∈ C T M(O,T,PT,OT). By definition of the clinical trial matching task, there exists a satisfying interpretation under which the formalized match objective and the full trial and patient constraints all hold. LetTC(c)andPC( p)denote the full SMT constraints derived from the free-text trial and patient descriptions, and letθbe the formalized objective produced by T R I A L R E P R(O, T, PT, OT). Thus the full constraints are jointly satisfiable. We show that (c, p) is returned by S AT I R in two steps. Step 1: Conservative conversion to executable CNF constraints. LetC N F(c)andC N F( p) be the executable quantifier-free CNF constraints stored in the database for trialcand patientp. By construction, the conversion from the full SMT constraints to these executable constraints is conservative: any satisfying assignment ofTC(c)also satisfiesC N F(c), and any satisfying assignment ofPC( p)also satisfiesC N F( p). Hence the executable constraints for c and p are jointly satisfiable. Denote this exact compatibility by Compat(c, p). Step 2: Exact compatibility implies join-based compatibility. AssumeCompat(c,p). Then there exists an assignment under which both C N F(c) and C N F( p) are satisfied. Since each CNF is a conjunction of disjunctive clauses, every clause on each side is satisfied under that assignment. Since each clause is a disjunction of atoms, each satisfied clause contains at least one atom that is true under that same assignment. Consider any satisfied trial clause and any satisfied patient clause. Leta t be a true atom from the trial clause anda p a true atom from the patient clause under the common satisfying assignment. Becausea t anda p are simultaneously satisfiable, the soundness assumption implies that the database join marks (a t , a p ) as compatible. Therefore every satisfied clause is supported by at least one compatible joined atom pair. Since this holds for all required clauses, the pair(c,p)passes the join-based retrieval test. Denote this relational compatibility by RelCompat(c, p). Thus Compat(c, p)⇒ RelCompat(c, p). Combining the two steps, we obtain (c, p)∈ C T M(O, T, PT, OT) ⇒ Compat(c, p) ⇒ RelCompat(c, p). By definition, S AT I R returns exactly those trial–patient pairs that satisfy the join-based com- patibility test over the executable representation derived fromT R I A L R E P R(O,T,PT,OT). Hence (c, p)∈ S AT I R(T R I A L R E P R(O, T, PT, OT)). Therefore every true match is returned by S AT I R. 75 Preprint. Under review. E Others E.1 Limitations. S AT I R has several limitations. First, our experiments are limited to the SIGIR 2016 bench- mark, which contains only 59 synthetic patient vignettes and 3,621 trials. Although this benchmark is useful for controlled comparison, it does not fully capture the scale, hetero- geneity, and documentation style of real clinical records. Broader validation on real-world EHR data and larger trial corpora remains necessary. Second, our main evaluation relies on an LLM judge with clinician validation on a sampled subset rather than exhaustive clinician review of all retrieved trial–patient pairs. We adopted this protocol because the original benchmark labels are incomplete and not tied to an explicit retrieval objective, while full clinician adjudication at our evaluation scale would be prohibitively expensive. Nevertheless, this means that our evaluation still depends in part on the quality of the LLM judge. Third, our formal representation is intentionally conservative. When clinically meaningful content cannot be safely canonicalized into the ontology-backed schema, we often preserve it as non-canonical information but do not fully project it into the symbolic retrieval layer. This choice helps avoid unsupported formal commitments, but it can also leave potentially useful information underutilized. Future work could explore richer handling of such con- tent, for example through ontology extension or retrieval components based on learned representations. Fourth, S AT I R relies heavily on the availability and quality of a medical ontology, especially for canonicalization, subsumption, and retrieval-time matching. It is therefore unclear how well the approach would transfer to domains where such ontology support is weaker. One possible direction is to replace or supplement ontology neighborhoods with neighborhoods induced by learned embeddings, though this would likely trade away some interpretability and formal control. Fifth, some parts of the system require deployment-specific tuning and policy choices, including the definition of retrieval objectives and the context used for salience judgments. This is both a strength and a limitation: it allows the system to be explicit, controllable, and adaptable to clinical goals, but it also means that deployment requires careful task definition rather than a single universally correct configuration. Finally, S AT I R incurs substantially more upfront semantic-parsing and formalization cost than embedding-based retrieval pipelines. This overhead is the price of constructing an interpretable symbolic representation. In return, the retrieval layer enjoys a formal full-recall guarantee with respect to the formalized constraints and their conservative projection, but the practical benefit of this guarantee still depends on the accuracy of upstream semantic parsing and knowledge grounding. E.2 Natural-Language Trial–Patient Matching Our formal SMT-based T R I A L R E P R is designed to capture strict eligibility and relevance constraints accurately and to support high-recall, high-precision retrieval. However, some aspects of trial–patient matching remain difficult to formalize completely from free text, including nuanced clinical judgments, partially specified cohort definitions, and implicit relationships between patient characteristics and trial intent. To account for these cases, we perform the final matching step directly on the original free-text trial and patient descriptions using an LLM. Two-stage matching procedure.The natural-language matching procedure is decomposed into two stages. First, the LLM is asked to identify all trial cohorts that are relevant to the patient under a predefined relevance definition. This stage considers only whether a cohort is clinically relevant to the patient and does not assess eligibility. The model returns a structured list of relevant cohorts together with a brief clinician-facing explanation. 76 Preprint. Under review. In the second stage, the LLM evaluates eligibility separately for each relevant cohort returned by the first stage. This cohort-level design is important because many trials contain multiple arms, cohorts, or expansion groups with different disease targets or eligibility requirements. Evaluating eligibility only after relevance identification helps prevent conflating disease or intent mismatch with failure of entry criteria. Eligibility instructions.The eligibility prompt provides detailed prescreening instructions that constrain how the LLM should reason over patient notes and trial text. In particular, it instructs the model to: (1) use clinical inference when appropriate, rather than relying only on explicitly stated facts; (2) project away operational, administrative, and logistics-only requirements that do not reflect the patient’s substantive current or past clinical state; (3) reason only over the current and past patient state, rather than assuming future changes in disease status; and (4) apply explicit missingness rules when the patient note does not directly mention a required fact. These rules are intended to make the natural-language matching process more stable, more clinically plausible, and more consistent across trials. Structured outputs. Both stages use structured outputs to support downstream parsing and review. The relevance stage returns the set of relevant cohorts and a short summary of the relevance decision. The eligibility stage returns a brief reasoning block followed by cohort-level eligibility decisions with concise justifications. This structure makes it possible to audit the final matching decision at the level of individual trial cohorts. See Appendix F.5.1 and F.5.2 for prompt implementation details. E.3 An Example of the SMT Semantic Parser Output Here we show the trial input together with the generated SMT programs. For readability, we omit variable-level metadata comments from the displayed SMT programs and retain only the declarations and logical constraints. Selected trial: NCT00362869. Trial input. Summary: Enteroaggregative E. coli (EAEC) is a bacterium that can cause diarrhea. The purposes of this study are to: determine how much EAEC is needed to cause diarrhea in a healthy person, determine if a genetic factor is important in causing diarrhea, and to see how the body's defenses control EAEC. Participants include 25 healthy adults, ages 18-40. Volunteers will be assigned to 1 of 4 dose levels in groups of 5 volunteers each. One volunteer in each group will receive a sodium bicarbonate placebo solution. Volunteers will be admitted to the University Clinical Research Unit for up to 8 days. Volunteers will receive therapy with levofloxacin to treat the infection either once they develop diarrhea or at Day 5 if they remain asymptomatic. Study procedures will include saliva, blood, and fecal sample collection. An optional study procedure will include an intestinal biopsy. Participants will be involved in study related procedures for up to 223 days. ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ Inclusion criteria: inclusion criteria: Sign an Institutional Review Board-approved consent prior to any study-related activities. Initiate screening 21 +/- 7 days prior to admission or enrollment. Must accomplish all laboratory and diagnostic examinations at 21 +/- 7 days prior to admission or enrollment. Be at least 18 years of age but not older than 40 years of age at the time of enrollment. Be otherwise healthy with a stable address and telephone where the volunteer can be contacted. Be able to read and write English. Possess a social security number in order to receive compensation. Female participants must have a negative serum pregnancy test at screening and a negative urine pregnancy test on the morning of the challenge and use effective birth control during the entire study period. Methods of effective birth control include: complete abstinence, the use of a licensed hormonal method, intrauterine device, barrier method plus spermicide, or having sexual relations exclusively with a vasectomized partner. Appropriate barrier methods include condoms, cervical sponge, and diaphragm. Females who are not of childbearing potential are defined as those who are physiologically incapable of becoming pregnant, including any female with tubal ligation or who is postmenopausal. For purposes of this study, postmenopausal status will be defined as absence of menses for at least 1 year. ,→ ,→ ,→ ,→ ,→ ,→ ,→ 77 Preprint. Under review. Be seronegative for antibodies to dispersin. Have normal laboratory screening values including a white blood cell (WBC) count, hemoglobin, hematocrit, platelets, blood urea nitrogen, glucose, creatinine, alanine aminotransferase (ALT), aspartate aminotransferase (AST), quantitative immunoglobulins, T cell subsets (CD4 and CD8), urinalysis. ,→ ,→ Have normal chest x-ray and electrocardiogram. Have negative serologies for HIV, hepatitis B virus (HBV), and hepatitis C virus (HCV), and a negative rapid plasma reagin (RPR).,→ Have a negative stool examination for pathogenic ova and pathogenic parasites, and bacterial enteropathogens (EAEC, Salmonella, Shigella, Campylobacter).,→ Have the -251 A IL-8 genotype. Exclusion criteria: : Has acute or chronic medical illness (i.e., renal or hepatic disease, hypertension, diabetes mellitus, coronary artery disease, malnutrition, obesity (body mass index >30 kg/m2), HIV, corticosteroid use, cancer or receiving chemotherapy, chronic debilitating illness, syphilis). ,→ ,→ Has used antibiotics within 7 days of challenge. Has used medications or drugs, including over-the-counter medications such as decongestants, antacids (calcium carbonate or aluminum-based antacids, H2 blockers), anti-diarrheal medications (such as bismuth subsalicylate or loperamide), antihistamines within 7 days of challenge. ,→ ,→ Has a history of chronic gastrointestinal illness, intra-abdominal surgery, chronic functional dyspepsia, chronic gastroesophageal reflux, documented peptic ulcer disease, gastrointestinal hemorrhage, gallbladder disease, inflammatory bowel disease (Crohn's and ulcerative colitis), diverticulitis, irritable bowel syndrome or frequent diarrhea. ,→ ,→ ,→ Has a history any of the following psychiatric illness(es): Depression not controlled with current drug therapy or involving institutionalization Schizophrenia or psychosis Suicide attempt. Has a history of or current alcohol or illicit drug abuse. Is unable to remain as an inpatient in the University Clinical Research Unit for up to 8 days. Has a known hypersensitivity to latex, heparin, opiates, antiemetics, benzodiazepines, lidocaine, magnesium citrate, or Fleet enema.,→ Has a known hypersensitivity to antibiotics that could be used to treat EAEC infection including fluoroquinolones, amoxicillin, cephalosporins or rifaximin.,→ Has serum antibodies to EAEC dispersin. Recently traveled to a developing country (within 6 months). Has household contacts who are less than 4 years of age or more than 80 years of age. Has household contacts that are infirmed or immunocompromised due to any of the following reasons: Corticosteroid therapy HIV infection Cancer chemotherapy Other chronic debilitating diseases. Works as health care personnel with direct patient care. Works in a day care center for children or the elderly. Is a food handler. Has factors that, in the opinion of the investigator or research personnel, would interfere with the study objectives or increase the risk to the volunteer or his contacts.,→ Is currently participating in a clinical study or had receipt of an investigational drug in the past 30 days. Is pregnant or has a risk of pregnancy or is lactating. Has current excessive use of alcohol or drug dependence. 78 Preprint. Under review. Has evidence of impaired immune function. Has a new positive reaction to purified protein derivative (PPD) (volunteers who are known to be PPD positive that have a negative chest x-ray and have received isoniazid prophylaxis will be eligible).,→ Has a stool culture that demonstrates the presence of pathogenic ova, pathogenic parasites, or bacterial enteropathogens (EAEC, Salmonella, Shigella, and Campylobacter), or that is devoid of normal flora.,→ Has self-reported lactose or soy intolerance or allergy Is a smoker and cannot stop smoking for the duration of the inpatient study. Has abnormal lab results for screening beyond the normal range as defined below: Hematology Hemoglobin: 13-15.0 gm/dL (Females) 14.5-17.0 gm/dL (Males) Hematocrit: 37-46 % Chemistry BUN 5-25 mg/dL Creatinine 0.5-1.4 mg/dL Glucose (fasting) 69-99 mg/dL ALT 0-40 U/L AST 0-40 U/L Immunology IgG: 596-1584 mg/dL IgA: 71-350 mg/dL IgM: 35-213 mg/dL CD4 T cells: 660-1500 cells/mcl CD8 T cells: 360-850 cells/mcl,→ Urinalysis Urine color: Yellow Turbidity: Clear pH: 5.0-8.0 Protein: Negative Sp. Gravity: 1.003-1.030 Glucose: Negative WBC: 0-2 Cells per HPF RBC: 0 Cells per HPF Bacteria: Rare Ketones: Negative The urinalysis will initially be evaluated for the quality of collection. If urinalysis is found to be poorly collected and demonstrates the presence of squamous epithelial cells and bacteria, results will not be used and a repeat urinalysis will be requested. In the case of menstruating women, the urinalysis collection will be postponed temporarily. A urinalysis may also be repeated once if traces of bile, protein, trace ketones, or Hb are identified. In the case of a properly collected urinalysis, the presence of leukocyte esterase glucose, or nitrates will exclude the participation of the subject. ,→ ,→ ,→ ,→ ,→ ,→ ,→ Occult blood (Hemoccult) positive stools on admission to the CRU. Develops gastrointestinal symptoms including nausea, vomiting, anorexia, abdominal pain, cramping, bloating, excessive gas or flatulence, diarrhea, constipation, urgency or tenesmus between the screening period and prior to challenge. ,→ ,→ Develops a febrile illness during the period of time screening period and prior to challenge. SMT program outputs. NCT00362869_inclusion_program.smt2 (subcohort:main, side: inclusion) ;; ===================== Declarations for the criterion (REQ 0) ===================== (declare-const patient_has_signed_irb_approved_consent_prior_to_study_activities Bool) ;; "To be included, the patient must sign an Institutional Review Board-approved consent prior to any study-related activities.",→ ;; ===================== Constraint Assertions (REQ 0) ===================== (assert (! patient_has_signed_irb_approved_consent_prior_to_study_activities :named REQ0_COMPONENT0_NOT_REQUIREMNET_OR_ALWAYS_SATISFIABLE_WITH_ACTION)) ;; "To be included, the patient must sign an Institutional Review Board-approved consent prior to any study-related activities.",→ ;; ===================== Declarations for the criterion (REQ 1) ===================== (declare-const patient_has_undergone_screening_procedure_inthehistory Bool) ;; "Boolean procedure variable indicating whether the patient has undergone a screening procedure at any time in the past (without specifying the exact time window relative to admission/enrollment)." "when_to_set_to_true":"Set to true if the patient has undergone a screening procedure at any time in the past, regardless of the exact timing relative to admission or enrollment.","when_to_set_to_false":"Set to false if the patient has not undergone a screening procedure at any time in the past.","when_to_set_to_null":"Set to null if it is unknown, not documented, or cannot be determined whether the patient has undergone a screening procedure in the past.","meaning":"Boolean indicating whether the patient has undergone a screening procedure at any time in the past." ,→ ,→ ,→ ,→ ,→ ,→ ,→ (declare-const patient_has_undergone_screening_procedure_inthehistory@@temporalcontext_within_14_to_28_days_befo ⌋ re_admission_or_enrollment Bool) ;; "Boolean procedure variable indicating whether the patient has undergone a screening procedure in the past, specifically within the window of at least 14 days and at most 28 days before admission or enrollment." "when_to_set_to_true":"Set to true if the patient has undergone a screening procedure at least 14 days and at most 28 days before admission or enrollment.","when_to_set_to_false":"Set to false if the patient has not undergone a screening procedure within this window.","when_to_set_to_null":"Set to null if it is unknown, not documented, or cannot be determined whether the patient has undergone a screening procedure within this window.","meaning":"Boolean indicating whether the patient has undergone a screening procedure at least 14 days and at most 28 days before admission or enrollment." ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ (declare-const screening_to_admission_or_enrollment_interval_value_in_days Real) ;; "Numeric variable representing the number of days between the date the patient initiated screening and the date of admission or enrollment." "when_to_set_to_value":"Set to the number of days between the date the patient initiated screening and the date of admission or enrollment.","when_to_set_to_null":"Set to null if either the date of screening initiation or the date of admission/enrollment is unknown, not documented, or cannot be determined.","meaning":"Numeric value representing the interval in days between screening initiation and admission or enrollment." ,→ ,→ ,→ ,→ ,→ ,→ ;; ===================== Auxiliary Assertions (REQ 1) ===================== ;; The qualifier variable is true iff the interval is at least 14 and at most 28 days (assert 79 Preprint. Under review. (! (= patient_has_undergone_screening_procedure_inthehistory@@temporalcontext_within_14_to_28_days_before_admi ⌋ ssion_or_enrollment,→ (and (>= screening_to_admission_or_enrollment_interval_value_in_days 14.0) (<= screening_to_admission_or_enrollment_interval_value_in_days 28.0) patient_has_undergone_screening_procedure_inthehistory)) :named REQ1_AUXILIARY0)) ;; "Boolean procedure variable indicating whether the patient has undergone a screening procedure in the past, specifically within the window of at least 14 days and at most 28 days before admission or enrollment." ,→ ,→ ;; ===================== Constraint Assertions (REQ 1) ===================== ;; Component 0: at least 14 days prior to admission or enrollment (assert (! (>= screening_to_admission_or_enrollment_interval_value_in_days 14.0) :named REQ1_COMPONENT0_NOT_REQUIREMNET_OR_ALWAYS_SATISFIABLE_WITH_ACTION)) ;; "To be included, the patient must initiate screening at least 14 days prior to admission or enrollment.",→ ;; Component 1: at most 28 days prior to admission or enrollment (assert (! (<= screening_to_admission_or_enrollment_interval_value_in_days 28.0) :named REQ1_COMPONENT1_NOT_REQUIREMNET_OR_ALWAYS_SATISFIABLE_WITH_ACTION)) ;; "To be included, the patient must initiate screening at most 28 days prior to admission or enrollment.",→ ;; ===================== Declarations for the criterion (REQ 2) ===================== (declare-const patient_has_undergone_laboratory_test_inthehistory Bool) ;; "laboratory examinations" (declare-const patient_has_undergone_laboratory_test_inthehistory@@temporalcontext_within_14_to_28_days_before_a ⌋ dmission_or_enrollment Bool) ;; "laboratory examinations at least 14 days and at most 28 days prior to admission or enrollment" ,→ ,→ (declare-const patient_has_undergone_diagnostic_assessment_inthehistory Bool) ;; "diagnostic examinations" (declare-const patient_has_undergone_diagnostic_assessment_inthehistory@@temporalcontext_within_14_to_28_days_be ⌋ fore_admission_or_enrollment Bool) ;; "diagnostic examinations at least 14 days and at most 28 days prior to admission or enrollment" ,→ ,→ ;; ===================== Constraint Assertions (REQ 2) ===================== ;; To be included, the patient must accomplish all laboratory examinations at least 14 days prior to admission or enrollment.,→ (assert (! patient_has_undergone_laboratory_test_inthehistory@@temporalcontext_within_14_to_28_days_before_admission_o ⌋ r_enrollment,→ :named REQ2_COMPONENT0_NOT_REQUIREMNET_OR_ALWAYS_SATISFIABLE_WITH_ACTION)) ;; "To be included, the patient must accomplish all laboratory examinations at least 14 days prior to admission or enrollment.",→ ;; To be included, the patient must accomplish all laboratory examinations at most 28 days prior to admission or enrollment.,→ (assert (! patient_has_undergone_laboratory_test_inthehistory@@temporalcontext_within_14_to_28_days_before_admission_o ⌋ r_enrollment,→ :named REQ2_COMPONENT1_NOT_REQUIREMNET_OR_ALWAYS_SATISFIABLE_WITH_ACTION)) ;; "To be included, the patient must accomplish all laboratory examinations at most 28 days prior to admission or enrollment.",→ ;; To be included, the patient must accomplish all diagnostic examinations at least 14 days prior to admission or enrollment.,→ (assert (! patient_has_undergone_diagnostic_assessment_inthehistory@@temporalcontext_within_14_to_28_days_before_admis ⌋ sion_or_enrollment,→ :named REQ2_COMPONENT2_NOT_REQUIREMNET_OR_ALWAYS_SATISFIABLE_WITH_ACTION)) ;; "To be included, the patient must accomplish all diagnostic examinations at least 14 days prior to admission or enrollment.",→ ;; To be included, the patient must accomplish all diagnostic examinations at most 28 days prior to admission or enrollment.,→ (assert (! patient_has_undergone_diagnostic_assessment_inthehistory@@temporalcontext_within_14_to_28_days_before_admis ⌋ sion_or_enrollment,→ :named REQ2_COMPONENT3_NOT_REQUIREMNET_OR_ALWAYS_SATISFIABLE_WITH_ACTION)) ;; "To be included, the patient must accomplish all diagnostic examinations at most 28 days prior to admission or enrollment.",→ ;; ===================== Declarations for the criterion (REQ 3) ===================== (declare-const patient_age_value_recorded_now_in_years Real) ;; "at least 18 years of age AND at most 40 years of age at the time of enrollment",→ ;; ===================== Constraint Assertions (REQ 3) ===================== ;; The patient must be at least 18 years of age at the time of enrollment. (assert (! (>= patient_age_value_recorded_now_in_years 18.0) :named REQ3_COMPONENT0_PRESCREEN_NOTES_MUST_COMPLETELY_SUFFICE)) ;; "To be included, the patient must be at least 18 years of age at the time of enrollment.",→ ;; The patient must be at most 40 years of age at the time of enrollment. (assert (! (<= patient_age_value_recorded_now_in_years 40.0) 80 Preprint. Under review. :named REQ3_COMPONENT1_PRESCREEN_NOTES_MUST_COMPLETELY_SUFFICE)) ;; "To be included, the patient must be at most 40 years of age at the time of enrollment.",→ ;; ===================== Declarations for the criterion (REQ 4) ===================== (declare-const patient_has_finding_of_fit_and_well_now Bool) ;; "To be included, the patient must be otherwise healthy.",→ (declare-const patient_has_stable_address_now Bool) ;; "To be included, the patient must have a stable address." (declare-const patient_has_stable_telephone_now Bool) ;; "To be included, the patient must have a stable telephone where the patient can be contacted.",→ ;; ===================== Constraint Assertions (REQ 4) ===================== ;; Component 0: The patient must be otherwise healthy. (assert (! patient_has_finding_of_fit_and_well_now :named REQ4_COMPONENT0_OTHER_REQUIREMENTS)) ;; "To be included, the patient must be otherwise healthy." ;; Component 1: The patient must have a stable address. (assert (! patient_has_stable_address_now :named REQ4_COMPONENT1_OTHER_REQUIREMENTS)) ;; "To be included, the patient must have a stable address." ;; Component 2: The patient must have a stable telephone where the patient can be contacted. (assert (! patient_has_stable_telephone_now :named REQ4_COMPONENT2_OTHER_REQUIREMENTS)) ;; "To be included, the patient must have a stable telephone where the patient can be contacted.",→ ;; ===================== Declarations for the criterion (REQ 5) ===================== (declare-const patient_is_able_to_read_english_now Bool) ;; "To be included, the patient must be able to read English.",→ (declare-const patient_is_able_to_write_english_now Bool) ;; "To be included, the patient must be able to write English.",→ ;; ===================== Constraint Assertions (REQ 5) ===================== ;; Component 0: Patient must be able to read English (assert (! patient_is_able_to_read_english_now :named REQ5_COMPONENT0_PRESCREEN_NOTES_MUST_COMPLETELY_SUFFICE)) ;; "To be included, the patient must be able to read English.",→ ;; Component 1: Patient must be able to write English (assert (! patient_is_able_to_write_english_now :named REQ5_COMPONENT1_PRESCREEN_NOTES_MUST_COMPLETELY_SUFFICE)) ;; "To be included, the patient must be able to write English.",→ ;; ===================== Declarations for the criterion (REQ 6) ===================== (declare-const patient_has_social_security_number Bool) ;; "To be included, the patient must possess a social security number in order to receive compensation.",→ ;; ===================== Constraint Assertions (REQ 6) ===================== (assert (! patient_has_social_security_number :named REQ6_COMPONENT0_NOT_REQUIREMNET_OR_ALWAYS_SATISFIABLE_WITH_ACTION)) ;; "To be included, the patient must possess a social security number in order to receive compensation.",→ ;; ===================== Declarations for the criterion (REQ 7, Component 5) ===================== (declare-const patient_is_postmenopausal_now Bool) ;; "postmenopausal status is defined as absence of menses for at least 1 year",→ (declare-const patient_has_absence_of_menses_duration_value_recorded_now_in_years Real) ;; "absence of menses for at least 1 year",→ (declare-const patient_has_absence_of_menses_duration_value_recorded_now_in_years@@duration_at_least_1_year Bool) ;; "absence of menses for at least 1 year",→ ;; ===================== Auxiliary Assertions (REQ 7) ===================== ;; Definition: duration_at_least_1_year is true iff absence of menses duration >= 1 year (assert (! (= patient_has_absence_of_menses_duration_value_recorded_now_in_years@@duration_at_least_1_year (>= patient_has_absence_of_menses_duration_value_recorded_now_in_years 1.0)) :named REQ7_AUXILIARY0)) ;; "absence of menses for at least 1 year" ;; Definition: postmenopausal status is equivalent to absence of menses for at least 1 year (assert (! (= patient_is_postmenopausal_now patient_has_absence_of_menses_duration_value_recorded_now_in_years@@duration_at_least_1_year) :named REQ7_AUXILIARY1)) ;; "postmenopausal status is defined as absence of menses for at least 1 year" ;; ===================== Constraint Assertions (REQ 7, Component 5) ===================== (assert (! patient_is_postmenopausal_now :named REQ7_COMPONENT5_PRESCREEN_NOTES_MUST_COMPLETELY_SUFFICE)) ;; "To be included, for purposes of this study, postmenopausal status is defined as absence of menses for at least 1 year.",→ 81 Preprint. Under review. ;; ===================== Declarations for the criterion (REQ 8) ===================== (declare-const patient_is_exposed_to_antibody_now@@specific_to_dispersin Bool) ;; "To be included, the patient must be seronegative for antibodies to dispersin.",→ (declare-const patient_is_seronegative_for_antibodies_to_dispersin_now Bool) ;; "To be included, the patient must be seronegative for antibodies to dispersin.",→ ;; ===================== Auxiliary Assertions (REQ 8) ===================== ;; Definition: seronegative for antibodies to dispersin means NOT exposed to antibodies to dispersin (assert (! (= patient_is_seronegative_for_antibodies_to_dispersin_now (not patient_is_exposed_to_antibody_now@@specific_to_dispersin)) :named REQ8_AUXILIARY0)) ;; "To be included, the patient must be seronegative for antibodies to dispersin." ;; ===================== Constraint Assertions (REQ 8) ===================== (assert (! patient_is_seronegative_for_antibodies_to_dispersin_now :named REQ8_COMPONENT0_OTHER_REQUIREMENTS)) ;; "To be included, the patient must be seronegative for antibodies to dispersin.",→ ;; ===================== Declarations for the criterion (REQ 9) ===================== (declare-const patient_has_undergone_white_blood_cell_count_now_outcome_is_normal Bool) ;; "including a white blood cell count",→ (declare-const patient_has_finding_of_hemoglobin_finding_now@@is_normal Bool) ;; "including a hemoglobin value" (declare-const patient_has_undergone_hematocrit_determination_now_outcome_is_normal Bool) ;; "including a hematocrit value",→ (declare-const patient_has_undergone_platelet_count_now_outcome_is_normal Bool) ;; "including a platelet count" (declare-const patient_has_undergone_blood_urea_nitrogen_measurement_now_outcome_is_normal Bool) ;; "including a blood urea nitrogen value",→ (declare-const patient_has_undergone_glucose_measurement_now_outcome_is_normal Bool) ;; "including a glucose value",→ (declare-const patient_has_finding_of_creatinine_level_finding_now@@is_normal Bool) ;; "including a creatinine value",→ (declare-const patient_has_undergone_alanine_aminotransferase_measurement_now_outcome_is_normal Bool) ;; "including an alanine aminotransferase value",→ (declare-const patient_has_undergone_aspartate_aminotransferase_measurement_now_outcome_is_normal Bool) ;; "including an aspartate aminotransferase value",→ (declare-const patient_has_undergone_immunoglobulin_measurement_now_outcome_is_normal Bool) ;; "including a quantitative immunoglobulin value",→ (declare-const patient_has_finding_of_t_cell_subsets_now@@is_normal Bool) ;; "including a T cell subset value (CD4 T cell subset AND CD8 T cell subset)",→ (declare-const patient_has_finding_of_cd4_t_cell_subset_now@@is_normal Bool) ;; "CD4 T cell subset" (declare-const patient_has_finding_of_cd8_t_cell_subset_now@@is_normal Bool) ;; "CD8 T cell subset" (declare-const patient_has_undergone_urinalysis_now_outcome_is_normal Bool) ;; "including a urinalysis" ;; ===================== Auxiliary Assertions (REQ 9) ===================== ;; The umbrella variable for T cell subset is normal if and only if both CD4 and CD8 T cell subset findings are normal.,→ (assert (! (= patient_has_finding_of_t_cell_subsets_now@@is_normal (and patient_has_finding_of_cd4_t_cell_subset_now@@is_normal patient_has_finding_of_cd8_t_cell_subset_now@@is_normal)) :named REQ9_AUXILIARY0)) ;; "T cell subset value (CD4 T cell subset AND CD8 T cell subset)" ;; ===================== Constraint Assertions (REQ 9) ===================== (assert (! patient_has_undergone_white_blood_cell_count_now_outcome_is_normal :named REQ9_COMPONENT0_OTHER_REQUIREMENTS)) ;; "including a white blood cell count" (assert (! patient_has_finding_of_hemoglobin_finding_now@@is_normal :named REQ9_COMPONENT1_OTHER_REQUIREMENTS)) ;; "including a hemoglobin value" (assert (! patient_has_undergone_hematocrit_determination_now_outcome_is_normal :named REQ9_COMPONENT2_OTHER_REQUIREMENTS)) ;; "including a hematocrit value" (assert 82 Preprint. Under review. (! patient_has_undergone_platelet_count_now_outcome_is_normal :named REQ9_COMPONENT3_OTHER_REQUIREMENTS)) ;; "including a platelet count" (assert (! patient_has_undergone_blood_urea_nitrogen_measurement_now_outcome_is_normal :named REQ9_COMPONENT4_OTHER_REQUIREMENTS)) ;; "including a blood urea nitrogen value" (assert (! patient_has_undergone_glucose_measurement_now_outcome_is_normal :named REQ9_COMPONENT5_OTHER_REQUIREMENTS)) ;; "including a glucose value" (assert (! patient_has_finding_of_creatinine_level_finding_now@@is_normal :named REQ9_COMPONENT6_OTHER_REQUIREMENTS)) ;; "including a creatinine value" (assert (! patient_has_undergone_alanine_aminotransferase_measurement_now_outcome_is_normal :named REQ9_COMPONENT7_OTHER_REQUIREMENTS)) ;; "including an alanine aminotransferase value" (assert (! patient_has_undergone_aspartate_aminotransferase_measurement_now_outcome_is_normal :named REQ9_COMPONENT8_OTHER_REQUIREMENTS)) ;; "including an aspartate aminotransferase value" (assert (! patient_has_undergone_immunoglobulin_measurement_now_outcome_is_normal :named REQ9_COMPONENT9_OTHER_REQUIREMENTS)) ;; "including a quantitative immunoglobulin value" (assert (! patient_has_finding_of_t_cell_subsets_now@@is_normal :named REQ9_COMPONENT10_OTHER_REQUIREMENTS)) ;; "including a T cell subset value (CD4 T cell subset AND CD8 T cell subset)",→ (assert (! patient_has_undergone_urinalysis_now_outcome_is_normal :named REQ9_COMPONENT11_OTHER_REQUIREMENTS)) ;; "including a urinalysis" ;; ===================== Declarations for the criterion (REQ 10) ===================== (declare-const patient_has_finding_of_tomography_chest_normal_now Bool) ;; "have a normal chest x-ray" (declare-const patient_has_finding_of_ecg_normal_now Bool) ;; "have a normal electrocardiogram" ;; ===================== Constraint Assertions (REQ 10) ===================== ;; Component 0: To be included, the patient must have a normal chest x-ray. (assert (! patient_has_finding_of_tomography_chest_normal_now :named REQ10_COMPONENT0_OTHER_REQUIREMENTS)) ;; "To be included, the patient must have a normal chest x-ray." ;; Component 1: To be included, the patient must have a normal electrocardiogram. (assert (! patient_has_finding_of_ecg_normal_now :named REQ10_COMPONENT1_OTHER_REQUIREMENTS)) ;; "To be included, the patient must have a normal electrocardiogram.",→ ;; ===================== Declarations for the inclusion criterion (REQ 11) ===================== (declare-const patient_has_finding_of_hiv_negative_now Bool) ;; "have negative serologies for human immunodeficiency virus infection",→ (declare-const patient_has_finding_of_type_b_viral_hepatitis_now@@determined_by_negative_serologies Bool) ;; "have negative serologies for hepatitis B virus infection",→ (declare-const patient_has_finding_of_hepatitis_c_antibody_test_negative_now Bool) ;; "have negative serologies for hepatitis C virus infection",→ (declare-const patient_has_undergone_rapid_plasma_reagin_test_now_outcome_is_negative Bool) ;; "have a negative rapid plasma reagin test",→ ;; ===================== Constraint Assertions (REQ 11) ===================== ;; Component 0: Negative serologies for HIV infection (assert (! patient_has_finding_of_hiv_negative_now :named REQ11_COMPONENT0_OTHER_REQUIREMENTS)) ;; "have negative serologies for human immunodeficiency virus infection",→ ;; Component 1: Negative serologies for hepatitis B virus infection (assert (! patient_has_finding_of_type_b_viral_hepatitis_now@@determined_by_negative_serologies :named REQ11_COMPONENT1_OTHER_REQUIREMENTS)) ;; "have negative serologies for hepatitis B virus infection" ;; Component 2: Negative serologies for hepatitis C virus infection (assert (! patient_has_finding_of_hepatitis_c_antibody_test_negative_now :named REQ11_COMPONENT2_OTHER_REQUIREMENTS)) ;; "have negative serologies for hepatitis C virus infection" ;; Component 3: Negative rapid plasma reagin test (assert (! patient_has_undergone_rapid_plasma_reagin_test_now_outcome_is_negative :named REQ11_COMPONENT3_OTHER_REQUIREMENTS)) ;; "have a negative rapid plasma reagin test" 83 Preprint. Under review. ;; ===================== Declarations for the inclusion criterion (REQ 12) ===================== (declare-const patient_has_undergone_evaluation_of_stool_specimen_now_outcome_is_negative Bool) ;; "To be included, the patient must have a negative stool examination for pathogenic ova, pathogenic parasites, and bacterial enteropathogens." ,→ ,→ (declare-const patient_has_undergone_evaluation_of_stool_specimen_now_outcome_is_negative@@for_pathogenic_ova Bool) ;; "To be included, the patient must have a negative stool examination for pathogenic ova.",→ (declare-const patient_has_undergone_evaluation_of_stool_specimen_now_outcome_is_negative@@for_pathogenic_parasites Bool) ;; "To be included, the patient must have a negative stool examination for pathogenic parasites." ,→ ,→ (declare-const patient_has_undergone_evaluation_of_stool_specimen_now_outcome_is_negative@@for_bacterial_enterop ⌋ athogens_with_exhaustive_subcategories Bool) ;; "To be included, the patient must have a negative stool examination for bacterial enteropathogens (Enteroaggregative Escherichia coli, Salmonella species, Shigella species, Campylobacter species)." ,→ ,→ ,→ ;; ===================== Auxiliary Assertions (REQ 12) ===================== ;; Qualifier variables imply corresponding stem variable (assert (! (=> patient_has_undergone_evaluation_of_stool_specimen_now_outcome_is_negative@@for_pathogenic_ova patient_has_undergone_evaluation_of_stool_specimen_now_outcome_is_negative) :named REQ12_AUXILIARY0)) ;; "To be included, the patient must have a negative stool examination for pathogenic ova.",→ (assert (! (=> patient_has_undergone_evaluation_of_stool_specimen_now_outcome_is_negative@@for_pathogenic_parasites patient_has_undergone_evaluation_of_stool_specimen_now_outcome_is_negative) :named REQ12_AUXILIARY1)) ;; "To be included, the patient must have a negative stool examination for pathogenic parasites.",→ (assert (! (=> patient_has_undergone_evaluation_of_stool_specimen_now_outcome_is_negative@@for_bacterial_enteropathoge ⌋ ns_with_exhaustive_subcategories,→ patient_has_undergone_evaluation_of_stool_specimen_now_outcome_is_negative) :named REQ12_AUXILIARY2)) ;; "To be included, the patient must have a negative stool examination for bacterial enteropathogens (Enteroaggregative Escherichia coli, Salmonella species, Shigella species, Campylobacter species)." ,→ ,→ ;; ===================== Constraint Assertions (REQ 12) ===================== ;; Component 0: negative stool exam for pathogenic ova (assert (! patient_has_undergone_evaluation_of_stool_specimen_now_outcome_is_negative@@for_pathogenic_ova :named REQ12_COMPONENT0_OTHER_REQUIREMENTS)) ;; "To be included, the patient must have a negative stool examination for pathogenic ova.",→ ;; Component 1: negative stool exam for pathogenic parasites (assert (! patient_has_undergone_evaluation_of_stool_specimen_now_outcome_is_negative@@for_pathogenic_parasites :named REQ12_COMPONENT1_OTHER_REQUIREMENTS)) ;; "To be included, the patient must have a negative stool examination for pathogenic parasites.",→ ;; Component 2: negative stool exam for bacterial enteropathogens (exhaustive: Enteroaggregative E. coli, Salmonella, Shigella, Campylobacter),→ (assert (! patient_has_undergone_evaluation_of_stool_specimen_now_outcome_is_negative@@for_bacterial_enteropathogens_w ⌋ ith_exhaustive_subcategories,→ :named REQ12_COMPONENT2_OTHER_REQUIREMENTS)) ;; "To be included, the patient must have a negative stool examination for bacterial enteropathogens (Enteroaggregative Escherichia coli, Salmonella species, Shigella species, Campylobacter species)." ,→ ,→ ;; ===================== Declarations for the criterion (REQ 13) ===================== (declare-const patient_has_interleukin_8_genotype_minus_251_a Bool) ;; "To be included, the patient must have the -251 A interleukin-8 genotype.",→ (declare-const patient_is_exposed_to_interleukin_8_now Bool) ;; variable set includes exposure to interleukin-8 (declare-const patient_is_exposed_to_interleukin_8_now@@genotype_minus_251_a Bool) ;; variable set includes exposure to interleukin-8 with genotype -251 A,→ ;; ===================== Auxiliary Assertions (REQ 13) ===================== ;; If the patient is exposed to interleukin-8 with genotype -251 A, then the patient must have the -251 A genotype of interleukin-8.,→ (assert (! (=> patient_is_exposed_to_interleukin_8_now@@genotype_minus_251_a patient_has_interleukin_8_genotype_minus_251_a) :named REQ13_AUXILIARY0)) ;; "To be included, the patient must have the -251 A interleukin-8 genotype." ;; ===================== Constraint Assertions (REQ 13) ===================== ;; The patient must have the -251 A interleukin-8 genotype. (assert (! patient_has_interleukin_8_genotype_minus_251_a :named REQ13_COMPONENT0_OTHER_REQUIREMENTS)) ;; "To be included, the patient must have the -251 A interleukin-8 genotype.",→ 84 Preprint. Under review. NCT00362869_exclusion_program.smt2 (subcohort: main, side: exclusion) ;; ===================== Declarations for the exclusion criterion (REQ 0) ===================== (declare-const patient_has_finding_of_acute_disease_now Bool) ;; "the patient has an acute medical illness" (declare-const patient_has_finding_of_chronic_disease_now Bool) ;; "the patient has a chronic medical illness" (declare-const patient_has_finding_of_kidney_disease_now Bool) ;; "renal disease" (declare-const patient_has_finding_of_disease_of_liver_now Bool) ;; "hepatic disease" (declare-const patient_has_finding_of_hypertensive_disorder_now Bool) ;; "hypertension" (declare-const patient_has_finding_of_diabetes_mellitus_now Bool) ;; "diabetes mellitus" (declare-const patient_has_finding_of_coronary_arteriosclerosis_now Bool) ;; "coronary artery disease" (declare-const patient_has_finding_of_malnutrition_now Bool) ;; "malnutrition" (declare-const patient_has_finding_of_obesity_now Bool) ;; "obesity (body mass index > 30 kilograms per square meter)",→ (declare-const patient_has_finding_of_human_immunodeficiency_virus_infection_now Bool) ;; "human immunodeficiency virus infection",→ (declare-const patient_is_taking_corticosteroid_and_corticosteroid_derivative_containing_product_now Bool) ;; "corticosteroid use",→ (declare-const patient_has_finding_of_malignant_neoplastic_disease_now Bool) ;; "cancer" (declare-const patient_is_undergoing_administration_of_antineoplastic_agent_now Bool) ;; "is receiving chemotherapy",→ (declare-const patient_has_finding_of_chronic_debilitating_illness_now Bool) ;; "chronic debilitating illness" (declare-const patient_has_finding_of_syphilis_now Bool) ;; "syphilis" ;; ===================== Auxiliary Assertions (REQ 0) ===================== ;; Non-exhaustive examples imply umbrella term for chronic medical illness (assert (! (=> (or patient_has_finding_of_kidney_disease_now patient_has_finding_of_disease_of_liver_now patient_has_finding_of_hypertensive_disorder_now patient_has_finding_of_diabetes_mellitus_now patient_has_finding_of_coronary_arteriosclerosis_now patient_has_finding_of_malnutrition_now patient_has_finding_of_obesity_now patient_has_finding_of_human_immunodeficiency_virus_infection_now patient_is_taking_corticosteroid_and_corticosteroid_derivative_containing_product_now patient_has_finding_of_malignant_neoplastic_disease_now patient_is_undergoing_administration_of_antineoplastic_agent_now patient_has_finding_of_chronic_debilitating_illness_now patient_has_finding_of_syphilis_now) patient_has_finding_of_chronic_disease_now) :named REQ0_AUXILIARY0)) ;; "chronic medical illness with non-exhaustive examples ((renal disease) OR (hepatic disease) OR (hypertension) OR (diabetes mellitus) OR (coronary artery disease) OR (malnutrition) OR (obesity (body mass index > 30 kilograms per square meter)) OR (human immunodeficiency virus infection) OR (corticosteroid use) OR (cancer) OR (is receiving chemotherapy) OR (chronic debilitating illness) OR (syphilis))" ,→ ,→ ,→ ,→ ;; ===================== Constraint Assertions (REQ 0) ===================== (assert (! (not patient_has_finding_of_acute_disease_now) :named REQ0_COMPONENT0_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has an acute medical illness.",→ (assert (! (not patient_has_finding_of_chronic_disease_now) :named REQ0_COMPONENT1_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has a chronic medical illness with non-exhaustive examples ((renal disease) OR (hepatic disease) OR (hypertension) OR (diabetes mellitus) OR (coronary artery disease) OR (malnutrition) OR (obesity (body mass index > 30 kilograms per square meter)) OR (human immunodeficiency virus infection) OR (corticosteroid use) OR (cancer) OR (is receiving chemotherapy) OR (chronic debilitating illness) OR (syphilis))." ,→ ,→ ,→ ,→ ;; ===================== Declarations for the exclusion criterion (REQ 1) ===================== (declare-const patient_has_undergone_antibiotic_therapy_inthepast7days Bool) ;; "antibiotics within 7 days prior to challenge",→ (declare-const patient_has_undergone_antibiotic_therapy_inthepast7days@@temporalcontext_within7days_before_challenge Bool) ;; "antibiotics within 7 days prior to challenge" ,→ ,→ 85 Preprint. Under review. ;; ===================== Auxiliary Assertions (REQ 1) ===================== ;; Qualifier variable implies corresponding stem variable (assert (! (=> patient_has_undergone_antibiotic_therapy_inthepast7days@@temporalcontext_within7days_before_challenge patient_has_undergone_antibiotic_therapy_inthepast7days) :named REQ1_AUXILIARY0)) ;; "antibiotics within 7 days prior to challenge" ;; ===================== Constraint Assertions (REQ 1) ===================== (assert (! (not patient_has_undergone_antibiotic_therapy_inthepast7days@@temporalcontext_within7days_before_challenge) :named REQ1_COMPONENT0_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has used antibiotics within 7 days prior to challenge.",→ ;; ===================== Declarations for the exclusion criterion (REQ 2) ===================== (declare-const patient_is_exposed_to_drug_or_medicament_inthepast7days Bool) ;; "medications or drugs within 7 days prior to challenge",→ (declare-const patient_is_exposed_to_drug_or_medicament_inthepast7days@@is_over_the_counter_medication Bool) ;; "over-the-counter medications such as decongestants",→ (declare-const patient_is_exposed_to_decongestant_inthepast7days Bool) ;; "decongestants" (declare-const patient_has_taken_antacid_inthepast7days Bool) ;; "antacids" (declare-const patient_has_taken_calcium_carbonate_containing_product_inthepast7days Bool) ;; "calcium carbonate antacids",→ (declare-const patient_has_taken_aluminum_containing_product_inthepast7days Bool) ;; "aluminum-based antacids" (declare-const patient_is_taking_histamine_h2_receptor_antagonist_containing_product_inthepast7days Bool) ;; "H2 blockers",→ (declare-const patient_is_exposed_to_drug_or_medicament_inthepast7days@@is_anti_diarrheal_medication Bool) ;; "anti-diarrheal medications",→ (declare-const patient_is_exposed_to_bismuth_subsalicylate_inthepast7days Bool) ;; "bismuth subsalicylate" (declare-const patient_is_exposed_to_loperamide_inthepast7days Bool) ;; "loperamide" (declare-const patient_is_exposed_to_histamine_receptor_antagonist_inthepast7days Bool) ;; "antihistamines" ;; ===================== Auxiliary Assertions (REQ 2) ===================== ;; Non-exhaustive examples: decongestants imply OTC medication exposure (assert (! (=> patient_is_exposed_to_decongestant_inthepast7days patient_is_exposed_to_drug_or_medicament_inthepast7days@@is_over_the_counter_medication) :named REQ2_AUXILIARY0)) ;; "over-the-counter medications such as decongestants" ;; Qualifier variable implies stem variable (assert (! (=> patient_is_exposed_to_drug_or_medicament_inthepast7days@@is_over_the_counter_medication patient_is_exposed_to_drug_or_medicament_inthepast7days) :named REQ2_AUXILIARY1)) ;; "over-the-counter medications" ;; Non-exhaustive examples: calcium carbonate, aluminum, H2 blockers imply antacid exposure (assert (! (=> (or patient_has_taken_calcium_carbonate_containing_product_inthepast7days patient_has_taken_aluminum_containing_product_inthepast7days patient_is_taking_histamine_h2_receptor_antagonist_containing_product_inthepast7days) patient_has_taken_antacid_inthepast7days) :named REQ2_AUXILIARY2)) ;; "antacids with non-exhaustive examples (calcium carbonate antacids OR aluminum-based antacids OR H2 blockers)",→ ;; Non-exhaustive examples: bismuth subsalicylate, loperamide imply anti-diarrheal medication exposure (assert (! (=> (or patient_is_exposed_to_bismuth_subsalicylate_inthepast7days patient_is_exposed_to_loperamide_inthepast7days) patient_is_exposed_to_drug_or_medicament_inthepast7days@@is_anti_diarrheal_medication) :named REQ2_AUXILIARY3)) ;; "anti-diarrheal medications with non-exhaustive examples (bismuth subsalicylate OR loperamide)",→ ;; Qualifier variable implies stem variable (assert (! (=> patient_is_exposed_to_drug_or_medicament_inthepast7days@@is_anti_diarrheal_medication patient_is_exposed_to_drug_or_medicament_inthepast7days) :named REQ2_AUXILIARY4)) ;; "anti-diarrheal medications" ;; ===================== Constraint Assertions (REQ 2) ===================== ;; Exclusion: patient must NOT have used any drug or medicament within 7 days prior to challenge (assert (! (not patient_is_exposed_to_drug_or_medicament_inthepast7days) :named REQ2_COMPONENT0_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has used medications within 7 days prior to challenge ... OR (the patient has used drugs within 7 days prior to challenge).",→ 86 Preprint. Under review. ;; ===================== Declarations for the exclusion criterion (REQ 3) ===================== (declare-const patient_has_diagnosis_of_chronic_digestive_system_disorder_inthehistory Bool) ;; "the patient has a history of chronic gastrointestinal illness",→ (declare-const patient_has_undergone_abdominal_cavity_operation_inthehistory Bool) ;; "the patient has a history of intra-abdominal surgery",→ (declare-const patient_has_diagnosis_of_nonulcer_dyspepsia_inthehistory Bool) ;; "the patient has a history of chronic functional dyspepsia",→ (declare-const patient_has_diagnosis_of_gastroesophageal_reflux_disease_inthehistory Bool) ;; "the patient has a history of chronic gastroesophageal reflux",→ (declare-const patient_has_diagnosis_of_peptic_ulcer_inthehistory Bool) ;; "the patient has a history of documented peptic ulcer disease",→ (declare-const patient_has_diagnosis_of_gastrointestinal_hemorrhage_inthehistory Bool) ;; "the patient has a history of gastrointestinal hemorrhage",→ (declare-const patient_has_diagnosis_of_disorder_of_gallbladder_inthehistory Bool) ;; "the patient has a history of gallbladder disease",→ (declare-const patient_has_diagnosis_of_inflammatory_bowel_disease_inthehistory Bool) ;; "the patient has a history of inflammatory bowel disease",→ (declare-const patient_has_diagnosis_of_crohn_s_disease_inthehistory Bool) ;; "Crohn's disease" (declare-const patient_has_diagnosis_of_ulcerative_colitis_inthehistory Bool) ;; "ulcerative colitis" (declare-const patient_has_diagnosis_of_diverticulitis_inthehistory Bool) ;; "the patient has a history of diverticulitis",→ (declare-const patient_has_diagnosis_of_irritable_bowel_syndrome_inthehistory Bool) ;; "the patient has a history of irritable bowel syndrome",→ (declare-const patient_has_history_of_frequent_diarrhea Bool) ;; "the patient has a history of frequent diarrhea" ;; ===================== Auxiliary Assertions (REQ 3) ===================== ;; Exhaustive subcategories: inflammatory bowel disease ⼹ (Crohn's disease OR ulcerative colitis) (assert (! (= patient_has_diagnosis_of_inflammatory_bowel_disease_inthehistory (or patient_has_diagnosis_of_crohn_s_disease_inthehistory patient_has_diagnosis_of_ulcerative_colitis_inthehistory)) :named REQ3_AUXILIARY0)) ;; "with exhaustive subcategories (Crohn's disease OR ulcerative colitis)" ;; ===================== Constraint Assertions (REQ 3) ===================== (assert (! (not patient_has_diagnosis_of_chronic_digestive_system_disorder_inthehistory) :named REQ3_COMPONENT0_OTHER_REQUIREMENTS)) ;; "the patient has a history of chronic gastrointestinal illness" (assert (! (not patient_has_undergone_abdominal_cavity_operation_inthehistory) :named REQ3_COMPONENT1_OTHER_REQUIREMENTS)) ;; "the patient has a history of intra-abdominal surgery" (assert (! (not patient_has_diagnosis_of_nonulcer_dyspepsia_inthehistory) :named REQ3_COMPONENT2_OTHER_REQUIREMENTS)) ;; "the patient has a history of chronic functional dyspepsia" (assert (! (not patient_has_diagnosis_of_gastroesophageal_reflux_disease_inthehistory) :named REQ3_COMPONENT3_OTHER_REQUIREMENTS)) ;; "the patient has a history of chronic gastroesophageal reflux" (assert (! (not patient_has_diagnosis_of_peptic_ulcer_inthehistory) :named REQ3_COMPONENT4_OTHER_REQUIREMENTS)) ;; "the patient has a history of documented peptic ulcer disease" (assert (! (not patient_has_diagnosis_of_gastrointestinal_hemorrhage_inthehistory) :named REQ3_COMPONENT5_OTHER_REQUIREMENTS)) ;; "the patient has a history of gastrointestinal hemorrhage" (assert (! (not patient_has_diagnosis_of_disorder_of_gallbladder_inthehistory) :named REQ3_COMPONENT6_OTHER_REQUIREMENTS)) ;; "the patient has a history of gallbladder disease" (assert (! (not patient_has_diagnosis_of_inflammatory_bowel_disease_inthehistory) :named REQ3_COMPONENT7_OTHER_REQUIREMENTS)) ;; "the patient has a history of inflammatory bowel disease with exhaustive subcategories (Crohn's disease OR ulcerative colitis)",→ (assert (! (not patient_has_diagnosis_of_diverticulitis_inthehistory) :named REQ3_COMPONENT8_OTHER_REQUIREMENTS)) ;; "the patient has a history of diverticulitis" 87 Preprint. Under review. (assert (! (not patient_has_diagnosis_of_irritable_bowel_syndrome_inthehistory) :named REQ3_COMPONENT9_OTHER_REQUIREMENTS)) ;; "the patient has a history of irritable bowel syndrome" (assert (! (not patient_has_history_of_frequent_diarrhea) :named REQ3_COMPONENT10_OTHER_REQUIREMENTS)) ;; "the patient has a history of frequent diarrhea" ;; ===================== Declarations for the exclusion criterion (REQ 4) ===================== (declare-const patient_has_diagnosis_of_depressive_disorder_inthehistory Bool) ;; "depression" (declare-const patient_has_diagnosis_of_depressive_disorder_inthehistory@@not_controlled_with_current_drug_therapy Bool) ;; "depression not controlled with current drug therapy" ,→ ,→ (declare-const patient_has_diagnosis_of_depressive_disorder_inthehistory@@involving_institutionalization Bool) ;; "depression involving institutionalization",→ (declare-const patient_has_diagnosis_of_schizophrenia_inthehistory Bool) ;; "schizophrenia" (declare-const patient_has_diagnosis_of_psychotic_disorder_inthehistory Bool) ;; "psychosis" (declare-const patient_has_history_of_suicide_attempt Bool) ;; "suicide attempt" ;; ===================== Auxiliary Assertions (REQ 4) ===================== ;; Qualifier variables imply corresponding stem variables (assert (! (=> patient_has_diagnosis_of_depressive_disorder_inthehistory@@not_controlled_with_current_drug_therapy patient_has_diagnosis_of_depressive_disorder_inthehistory) :named REQ4_AUXILIARY0)) ;; "depression not controlled with current drug therapy" (assert (! (=> patient_has_diagnosis_of_depressive_disorder_inthehistory@@involving_institutionalization patient_has_diagnosis_of_depressive_disorder_inthehistory) :named REQ4_AUXILIARY1)) ;; "depression involving institutionalization" ;; ===================== Constraint Assertions (REQ 4) ===================== ;; Exhaustive subcategories: history of at least one of the following psychiatric illnesses (assert (! (not (or patient_has_diagnosis_of_depressive_disorder_inthehistory@@not_controlled_with_current_drug_therapy patient_has_diagnosis_of_depressive_disorder_inthehistory@@involving_institutionalization patient_has_diagnosis_of_schizophrenia_inthehistory patient_has_diagnosis_of_psychotic_disorder_inthehistory patient_has_history_of_suicide_attempt)) :named REQ4_COMPONENT0_OTHER_REQUIREMENTS)) ;; "has a history of at least one of the following psychiatric illnesses with exhaustive subcategories ((depression not controlled with current drug therapy) OR (depression involving institutionalization) OR (schizophrenia) OR (psychosis) OR (suicide attempt))." ,→ ,→ ;; ===================== Declarations for the exclusion criterion (REQ 5) ===================== (declare-const patient_has_finding_of_alcohol_abuse_inthehistory Bool) ;; "the patient has a history of alcohol abuse",→ (declare-const patient_has_finding_of_illicit_medication_use_inthehistory Bool) ;; "the patient has a history of illicit drug abuse",→ (declare-const patient_has_finding_of_alcohol_abuse_now Bool) ;; "the patient has current alcohol abuse" (declare-const patient_has_finding_of_illicit_medication_use_now Bool) ;; "the patient has current illicit drug abuse",→ ;; ===================== Constraint Assertions (REQ 5) ===================== (assert (! (not patient_has_finding_of_alcohol_abuse_inthehistory) :named REQ5_COMPONENT0_OTHER_REQUIREMENTS)) ;; "the patient has a history of alcohol abuse" (assert (! (not patient_has_finding_of_illicit_medication_use_inthehistory) :named REQ5_COMPONENT1_OTHER_REQUIREMENTS)) ;; "the patient has a history of illicit drug abuse" (assert (! (not patient_has_finding_of_alcohol_abuse_now) :named REQ5_COMPONENT2_OTHER_REQUIREMENTS)) ;; "the patient has current alcohol abuse" (assert (! (not patient_has_finding_of_illicit_medication_use_now) :named REQ5_COMPONENT3_OTHER_REQUIREMENTS)) ;; "the patient has current illicit drug abuse" ;; ===================== Declarations for the exclusion criterion (REQ 6) ===================== (declare-const patient_has_finding_of_hospital_patient_now Bool) ;; "inpatient" (declare-const patient_has_finding_of_hospital_patient_now@@in_university_clinical_research_unit Bool) ;; "inpatient in the University Clinical Research Unit",→ (declare-const patient_has_finding_of_hospital_patient_now@@can_remain_for_up_to_8_days Bool) ;; "able to remain as an inpatient for up to 8 days",→ (declare-const patient_has_finding_of_hospital_patient_now@@in_university_clinical_research_unit@@can_remain_for ⌋ _up_to_8_days Bool) ;; "inpatient in the University Clinical Research Unit and able to remain for up to 8 days",→ ;; ===================== Auxiliary Assertions (REQ 6) ===================== ;; Qualifier variable implies stem variable (assert 88 Preprint. Under review. (! (=> patient_has_finding_of_hospital_patient_now@@in_university_clinical_research_unit patient_has_finding_of_hospital_patient_now) :named REQ6_AUXILIARY0)) ;; "inpatient in the University Clinical Research Unit" ;; Qualifier variable implies stem variable (assert (! (=> patient_has_finding_of_hospital_patient_now@@can_remain_for_up_to_8_days patient_has_finding_of_hospital_patient_now) :named REQ6_AUXILIARY1)) ;; "able to remain as an inpatient for up to 8 days" ;; Double qualifier variable implies both single qualifiers (assert (! (=> patient_has_finding_of_hospital_patient_now@@in_university_clinical_research_unit@@can_remain_for_up_to_8 ⌋ _days,→ (and patient_has_finding_of_hospital_patient_now@@in_university_clinical_research_unit patient_has_finding_of_hospital_patient_now@@can_remain_for_up_to_8_days)) :named REQ6_AUXILIARY2)) ;; "inpatient in the University Clinical Research Unit and able to remain for up to 8 days",→ ;; ===================== Constraint Assertions (REQ 6) ===================== (assert (! (not patient_has_finding_of_hospital_patient_now@@in_university_clinical_research_unit@@can_remain_for_up_to_ ⌋ 8_days),→ :named REQ6_COMPONENT0_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient is unable to remain as an inpatient in the University Clinical Research Unit for up to 8 days.",→ ;; ===================== Declarations for the exclusion criterion (REQ 7) ===================== (declare-const patient_has_hypersensitivity_to_latex_now Bool) ;; "The patient has a known hypersensitivity to latex.",→ (declare-const patient_has_finding_of_allergy_to_heparin_now Bool) ;; "The patient has a known hypersensitivity to heparin.",→ (declare-const patient_has_hypersensitivity_to_opioid_receptor_agonist_now Bool) ;; "The patient has a known hypersensitivity to opiates.",→ (declare-const patient_has_hypersensitivity_to_antiemetic_now Bool) ;; "The patient has a known hypersensitivity to antiemetics.",→ (declare-const patient_has_finding_of_allergy_to_benzodiazepine_now Bool) ;; "The patient has a known hypersensitivity to benzodiazepines.",→ (declare-const patient_has_finding_of_allergy_to_lidocaine_now Bool) ;; "The patient has a known hypersensitivity to lidocaine.",→ (declare-const patient_has_hypersensitivity_to_magnesium_citrate_now Bool) ;; "The patient has a known hypersensitivity to magnesium citrate.",→ (declare-const patient_has_hypersensitivity_to_fleet_enema_now Bool) ;; "The patient has a known hypersensitivity to Fleet enema.",→ ;; ===================== Constraint Assertions (REQ 7) ===================== (assert (! (not patient_has_hypersensitivity_to_latex_now) :named REQ7_COMPONENT0_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has a known hypersensitivity to latex.",→ (assert (! (not patient_has_finding_of_allergy_to_heparin_now) :named REQ7_COMPONENT1_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has a known hypersensitivity to heparin.",→ (assert (! (not patient_has_hypersensitivity_to_opioid_receptor_agonist_now) :named REQ7_COMPONENT2_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has a known hypersensitivity to opiates.",→ (assert (! (not patient_has_hypersensitivity_to_antiemetic_now) :named REQ7_COMPONENT3_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has a known hypersensitivity to antiemetics.",→ (assert (! (not patient_has_finding_of_allergy_to_benzodiazepine_now) :named REQ7_COMPONENT4_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has a known hypersensitivity to benzodiazepines.",→ (assert (! (not patient_has_finding_of_allergy_to_lidocaine_now) :named REQ7_COMPONENT5_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has a known hypersensitivity to lidocaine.",→ (assert (! (not patient_has_hypersensitivity_to_magnesium_citrate_now) :named REQ7_COMPONENT6_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has a known hypersensitivity to magnesium citrate.",→ (assert (! (not patient_has_hypersensitivity_to_fleet_enema_now) 89 Preprint. Under review. :named REQ7_COMPONENT7_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has a known hypersensitivity to Fleet enema.",→ ;; ===================== Declarations for the exclusion criterion (REQ 8) ===================== (declare-const patient_has_finding_of_allergic_reaction_caused_by_antibacterial_agent_now Bool) ;; "hypersensitivity to antibiotics",→ (declare-const patient_has_finding_of_allergic_reaction_caused_by_antibacterial_agent_now@@known_hypersensitivity Bool) ;; "known hypersensitivity",→ (declare-const patient_has_finding_of_allergic_reaction_caused_by_antibacterial_agent_now@@antibiotics_could_be_ ⌋ used_to_treat_enteroadherent_escherichia_coli_gastrointestinal_tract_infection Bool) ;; "antibiotics that could be used to treat enteroaggregative Escherichia coli infection" ,→ ,→ (declare-const patient_has_hypersensitivity_to_quinolone_antibacterial_now Bool) ;; "fluoroquinolones" (declare-const patient_has_hypersensitivity_to_amoxicillin_now Bool) ;; "amoxicillin" (declare-const patient_has_hypersensitivity_to_cephalosporin_now Bool) ;; "cephalosporins" (declare-const patient_has_hypersensitivity_to_rifaximin_now Bool) ;; "rifaximin" ;; ===================== Auxiliary Assertions (REQ 8) ===================== ;; Non-exhaustive examples imply umbrella term (assert (! (=> (or patient_has_hypersensitivity_to_quinolone_antibacterial_now patient_has_hypersensitivity_to_amoxicillin_now patient_has_hypersensitivity_to_cephalosporin_now patient_has_hypersensitivity_to_rifaximin_now) patient_has_finding_of_allergic_reaction_caused_by_antibacterial_agent_now@@antibiotics_could_be_used_to_ ⌋ treat_enteroadherent_escherichia_coli_gastrointestinal_tract_infection),→ :named REQ8_AUXILIARY0)) ;; "with non-exhaustive examples (fluoroquinolones OR amoxicillin OR cephalosporins OR rifaximin).",→ ;; Qualifier variables imply corresponding stem variables (assert (! (=> patient_has_finding_of_allergic_reaction_caused_by_antibacterial_agent_now@@antibiotics_could_be_used_to_ ⌋ treat_enteroadherent_escherichia_coli_gastrointestinal_tract_infection,→ patient_has_finding_of_allergic_reaction_caused_by_antibacterial_agent_now) :named REQ8_AUXILIARY1)) ;; "antibiotics that could be used to treat enteroaggregative Escherichia coli infection",→ (assert (! (=> patient_has_finding_of_allergic_reaction_caused_by_antibacterial_agent_now@@known_hypersensitivity patient_has_finding_of_allergic_reaction_caused_by_antibacterial_agent_now) :named REQ8_AUXILIARY2)) ;; "known hypersensitivity" ;; ===================== Constraint Assertions (REQ 8) ===================== (assert (! (not (and patient_has_finding_of_allergic_reaction_caused_by_antibacterial_agent_now@@known_hypersensitivity patient_has_finding_of_allergic_reaction_caused_by_antibacterial_agent_now@@antibiotics_could_be_us ⌋ ed_to_treat_enteroadherent_escherichia_coli_gastrointestinal_tract_infection)),→ :named REQ8_COMPONENT0_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has a known hypersensitivity to antibiotics that could be used to treat enteroaggregative Escherichia coli infection with non-exhaustive examples (fluoroquinolones OR amoxicillin OR cephalosporins OR rifaximin)." ,→ ,→ ;; ===================== Declarations for the exclusion criterion (REQ 9) ===================== (declare-const patient_is_exposed_to_antibody_now Bool) ;; "antibodies" (declare-const patient_is_exposed_to_antibody_now@@present_in_serum Bool) ;; "serum antibodies" (declare-const patient_is_exposed_to_antibody_now@@specific_to_enteroaggregative_escherichia_coli_dispersin Bool) ;; "antibodies to enteroaggregative Escherichia coli dispersin",→ ;; ===================== Auxiliary Assertions (REQ 9) ===================== ;; Qualifier variables imply corresponding stem variable (assert (! (=> patient_is_exposed_to_antibody_now@@present_in_serum patient_is_exposed_to_antibody_now) :named REQ9_AUXILIARY0)) ;; "serum antibodies" (assert (! (=> patient_is_exposed_to_antibody_now@@specific_to_enteroaggregative_escherichia_coli_dispersin patient_is_exposed_to_antibody_now) :named REQ9_AUXILIARY1)) ;; "antibodies to enteroaggregative Escherichia coli dispersin" ;; ===================== Constraint Assertions (REQ 9) ===================== ;; Exclusion: patient must NOT have serum antibodies to enteroaggregative Escherichia coli dispersin (assert (! (not (and patient_is_exposed_to_antibody_now@@present_in_serum patient_is_exposed_to_antibody_now@@specific_to_enteroaggregative_escherichia_coli_dispersin)) :named REQ9_COMPONENT0_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has serum antibodies to enteroaggregative Escherichia coli dispersin.",→ ;; ===================== Declarations for the exclusion criterion (REQ 10) ===================== (declare-const patient_has_traveled_to_developing_country_within_past_6_months Bool) ;; "has recently traveled to a developing country within the past six months.",→ (declare-const patient_travel_to_developing_country_date_value_recorded_in_past_6_months_withunit_days Real) ;; "date (in days ago) when the patient traveled to a developing country, recorded if the travel occurred within the past six months." ,→ ,→ 90 Preprint. Under review. ;; ===================== Constraint Assertions (REQ 10) ===================== (assert (! (not patient_has_traveled_to_developing_country_within_past_6_months) :named REQ10_COMPONENT0_OTHER_REQUIREMENTS)) ;; "A patient is excluded if the patient has recently traveled to a developing country within the past six months.",→ ;; ===================== Declarations for the exclusion criterion (REQ 11) ===================== (declare-const household_contact_age_value_recorded_now_in_years Real) ;; "age in years of a household contact at the current time",→ (declare-const patient_has_household_contact_now Bool) ;; "the patient currently has at least one household contact",→ ;; ===================== Auxiliary Assertions (REQ 11) ===================== ;; None needed: all logic is directly encoded in the constraints. ;; ===================== Constraint Assertions (REQ 11) ===================== ;; Exclusion: The patient is excluded if the patient has at least one household contact who is less than four years of age.,→ (assert (! (not (and patient_has_household_contact_now (< household_contact_age_value_recorded_now_in_years 4))) :named REQ11_COMPONENT0_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has at least one household contact who is less than four years of age.",→ ;; Exclusion: The patient is excluded if the patient has at least one household contact who is more than eighty years of age.,→ (assert (! (not (and patient_has_household_contact_now (> household_contact_age_value_recorded_now_in_years 80))) :named REQ11_COMPONENT1_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has at least one household contact who is more than eighty years of age.",→ ;; ===================== Declarations for the exclusion criterion (REQ 12) ===================== (declare-const patient_has_household_contact_infirmed_now Bool) ;; "the patient has at least one household contact who is infirmed",→ (declare-const patient_has_household_contact_immunocompromised_now Bool) ;; "the patient has at least one household contact who is immunocompromised",→ (declare-const patient_has_household_contact_immunocompromised_now@@due_to_corticosteroid_therapy Bool) ;; "the patient has at least one household contact who is immunocompromised due to corticosteroid therapy",→ (declare-const patient_has_household_contact_immunocompromised_now@@due_to_human_immunodeficiency_virus_infection Bool) ;; "the patient has at least one household contact who is immunocompromised due to human immunodeficiency virus infection" ,→ ,→ (declare-const patient_has_household_contact_immunocompromised_now@@due_to_cancer_chemotherapy Bool) ;; "the patient has at least one household contact who is immunocompromised due to cancer chemotherapy",→ (declare-const patient_has_household_contact_immunocompromised_now@@due_to_other_chronic_debilitating_diseases Bool) ;; "the patient has at least one household contact who is immunocompromised due to other chronic debilitating diseases" ,→ ,→ ;; ===================== Auxiliary Assertions (REQ 12) ===================== ;; Qualifier variables imply corresponding stem variable for household contact immunocompromised (assert (! (=> patient_has_household_contact_immunocompromised_now@@due_to_corticosteroid_therapy patient_has_household_contact_immunocompromised_now) :named REQ12_AUXILIARY0)) ;; "the patient has at least one household contact who is immunocompromised due to corticosteroid therapy",→ (assert (! (=> patient_has_household_contact_immunocompromised_now@@due_to_human_immunodeficiency_virus_infection patient_has_household_contact_immunocompromised_now) :named REQ12_AUXILIARY1)) ;; "the patient has at least one household contact who is immunocompromised due to human immunodeficiency virus infection",→ (assert (! (=> patient_has_household_contact_immunocompromised_now@@due_to_cancer_chemotherapy patient_has_household_contact_immunocompromised_now) :named REQ12_AUXILIARY2)) ;; "the patient has at least one household contact who is immunocompromised due to cancer chemotherapy",→ (assert (! (=> patient_has_household_contact_immunocompromised_now@@due_to_other_chronic_debilitating_diseases patient_has_household_contact_immunocompromised_now) :named REQ12_AUXILIARY3)) ;; "the patient has at least one household contact who is immunocompromised due to other chronic debilitating diseases",→ ;; ===================== Constraint Assertions (REQ 12) ===================== (assert (! (not patient_has_household_contact_infirmed_now) 91 Preprint. Under review. :named REQ12_COMPONENT0_OTHER_REQUIREMENTS)) ;; "the patient has at least one household contact who is infirmed",→ (assert (! (not patient_has_household_contact_immunocompromised_now@@due_to_corticosteroid_therapy) :named REQ12_COMPONENT1_OTHER_REQUIREMENTS)) ;; "the patient has at least one household contact who is immunocompromised due to corticosteroid therapy",→ (assert (! (not patient_has_household_contact_immunocompromised_now@@due_to_human_immunodeficiency_virus_infection) :named REQ12_COMPONENT2_OTHER_REQUIREMENTS)) ;; "the patient has at least one household contact who is immunocompromised due to human immunodeficiency virus infection",→ (assert (! (not patient_has_household_contact_immunocompromised_now@@due_to_cancer_chemotherapy) :named REQ12_COMPONENT3_OTHER_REQUIREMENTS)) ;; "the patient has at least one household contact who is immunocompromised due to cancer chemotherapy",→ (assert (! (not patient_has_household_contact_immunocompromised_now@@due_to_other_chronic_debilitating_diseases) :named REQ12_COMPONENT4_OTHER_REQUIREMENTS)) ;; "the patient has at least one household contact who is immunocompromised due to other chronic debilitating diseases",→ ;; ===================== Declarations for the exclusion criterion (REQ 13) ===================== (declare-const patient_is_health_care_personnel Bool) ;; "works as health care personnel" (declare-const patient_is_health_care_personnel@@provides_direct_patient_care Bool) ;; "with direct patient care" ;; ===================== Auxiliary Assertions (REQ 13) ===================== ;; Qualifier variable implies corresponding stem variable (assert (! (=> patient_is_health_care_personnel@@provides_direct_patient_care patient_is_health_care_personnel) :named REQ13_AUXILIARY0)) ;; "with direct patient care" implies "works as health care personnel" ;; ===================== Constraint Assertions (REQ 13) ===================== (assert (! (not patient_is_health_care_personnel@@provides_direct_patient_care) :named REQ13_COMPONENT0_OTHER_REQUIREMENTS)) ;; "A patient is excluded if the patient works as health care personnel with direct patient care.",→ ;; ===================== Declarations for the exclusion criterion (REQ 14) ===================== (declare-const patient_works_in_day_care_center_for_children_now Bool) ;; "the patient works in a day care center for children",→ (declare-const patient_works_in_day_care_center_for_the_elderly_now Bool) ;; "the patient works in a day care center for the elderly",→ ;; ===================== Constraint Assertions (REQ 14) ===================== (assert (! (not patient_works_in_day_care_center_for_children_now) :named REQ14_COMPONENT0_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient works in a day care center for children.",→ (assert (! (not patient_works_in_day_care_center_for_the_elderly_now) :named REQ14_COMPONENT1_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient works in a day care center for the elderly.",→ ;; ===================== Declarations for the exclusion criterion (REQ 15) ===================== (declare-const patient_is_food_handler_now Bool) ;; "the patient is a food handler" ;; ===================== Constraint Assertions (REQ 15) ===================== (assert (! (not patient_is_food_handler_now) :named REQ15_COMPONENT0_OTHER_REQUIREMENTS)) ;; "A patient is excluded if the patient is a food handler." ;; ===================== Declarations for the exclusion criterion (REQ 16) ===================== (declare-const patient_has_factor_that_would_interfere_with_study_objectives_in_opinion_of_investigator_now Bool) ;; "The patient is excluded if the patient has factors that, in the opinion of the investigator, would interfere with the study objectives." ,→ ,→ (declare-const patient_has_factor_that_would_increase_risk_to_patient_in_opinion_of_investigator_now Bool) ;; "The patient is excluded if the patient has factors that, in the opinion of the investigator, would increase the risk to the patient." ,→ ,→ (declare-const patient_has_factor_that_would_increase_risk_to_patients_contacts_in_opinion_of_investigator_now Bool) ;; "The patient is excluded if the patient has factors that, in the opinion of the investigator, would increase the risk to the patient's contacts." ,→ ,→ (declare-const patient_has_factor_that_would_interfere_with_study_objectives_in_opinion_of_research_personnel_now Bool) ;; "The patient is excluded if the patient has factors that, in the opinion of the research personnel, would interfere with the study objectives." ,→ ,→ 92 Preprint. Under review. (declare-const patient_has_factor_that_would_increase_risk_to_patient_in_opinion_of_research_personnel_now Bool) ;; "The patient is excluded if the patient has factors that, in the opinion of the research personnel, would increase the risk to the patient." ,→ ,→ (declare-const patient_has_factor_that_would_increase_risk_to_patients_contacts_in_opinion_of_research_personnel_now Bool) ;; "The patient is excluded if the patient has factors that, in the opinion of the research personnel, would increase the risk to the patient's contacts." ,→ ,→ ,→ ;; ===================== Constraint Assertions (REQ 16) ===================== (assert (! (not patient_has_factor_that_would_interfere_with_study_objectives_in_opinion_of_investigator_now) :named REQ16_COMPONENT0_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has factors that, in the opinion of the investigator, would interfere with the study objectives.",→ (assert (! (not patient_has_factor_that_would_increase_risk_to_patient_in_opinion_of_investigator_now) :named REQ16_COMPONENT1_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has factors that, in the opinion of the investigator, would increase the risk to the patient.",→ (assert (! (not patient_has_factor_that_would_increase_risk_to_patients_contacts_in_opinion_of_investigator_now) :named REQ16_COMPONENT2_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has factors that, in the opinion of the investigator, would increase the risk to the patient's contacts.",→ (assert (! (not patient_has_factor_that_would_interfere_with_study_objectives_in_opinion_of_research_personnel_now) :named REQ16_COMPONENT3_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has factors that, in the opinion of the research personnel, would interfere with the study objectives.",→ (assert (! (not patient_has_factor_that_would_increase_risk_to_patient_in_opinion_of_research_personnel_now) :named REQ16_COMPONENT4_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has factors that, in the opinion of the research personnel, would increase the risk to the patient.",→ (assert (! (not patient_has_factor_that_would_increase_risk_to_patients_contacts_in_opinion_of_research_personnel_now) :named REQ16_COMPONENT5_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has factors that, in the opinion of the research personnel, would increase the risk to the patient's contacts.",→ ;; ===================== Declarations for the exclusion criterion (REQ 17) ===================== (declare-const patient_is_undergoing_clinical_trial_now Bool) ;; "the patient is currently participating in a clinical study",→ (declare-const patient_is_exposed_to_drug_or_medicament_inthepast30days Bool) ;; "the patient has received an investigational drug in the past thirty days",→ ;; ===================== Constraint Assertions (REQ 17) ===================== (assert (! (not patient_is_undergoing_clinical_trial_now) :named REQ17_COMPONENT0_OTHER_REQUIREMENTS)) ;; "the patient is currently participating in a clinical study" (assert (! (not patient_is_exposed_to_drug_or_medicament_inthepast30days) :named REQ17_COMPONENT1_OTHER_REQUIREMENTS)) ;; "the patient has received an investigational drug in the past thirty days",→ ;; ===================== Declarations for the exclusion criterion (REQ 18) ===================== (declare-const patient_is_pregnant_now Bool) ;; "the patient is pregnant" (declare-const patient_is_lactating_now Bool) ;; "the patient is lactating" (declare-const patient_is_at_risk_of_pregnancy_now Bool) ;; "the patient is at risk of pregnancy" (declare-const patient_has_finding_of_contraception_now@@effective Bool) ;; "effective birth control" (declare-const patient_is_able_to_be_pregnant_now Bool) ;; "physiologically incapable of becoming pregnant" ;; ===================== Constraint Assertions (REQ 18) ===================== ;; Exclusion: patient is currently pregnant (assert (! (not patient_is_pregnant_now) :named REQ18_COMPONENT0_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient is pregnant." ;; Exclusion: patient is currently lactating (assert (! (not patient_is_lactating_now) :named REQ18_COMPONENT1_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient is lactating." ;; Exclusion: patient is at risk of pregnancy AND (does not meet effective birth control OR is not physiologically incapable of becoming pregnant),→ (assert (! (not (and patient_is_at_risk_of_pregnancy_now (or (not patient_has_finding_of_contraception_now@@effective) patient_is_able_to_be_pregnant_now))) :named REQ18_COMPONENT2_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient is at risk of pregnancy and does not meet the inclusion criteria for effective birth control or is not physiologically incapable of becoming pregnant as defined in the inclusion criteria." ,→ ,→ 93 Preprint. Under review. ;; ===================== Declarations for the exclusion criterion (REQ 19) ===================== (declare-const patient_has_finding_of_alcohol_intake_above_recommended_sensible_limits_now Bool) ;; "the patient has current excessive use of alcohol",→ (declare-const patient_has_finding_of_psychoactive_substance_dependence_now Bool) ;; "the patient has drug dependence",→ ;; ===================== Constraint Assertions (REQ 19) ===================== (assert (! (not patient_has_finding_of_alcohol_intake_above_recommended_sensible_limits_now) :named REQ19_COMPONENT0_OTHER_REQUIREMENTS)) ;; "the patient has current excessive use of alcohol" (assert (! (not patient_has_finding_of_psychoactive_substance_dependence_now) :named REQ19_COMPONENT1_OTHER_REQUIREMENTS)) ;; "the patient has drug dependence" ;; ===================== Declarations for the exclusion criterion (REQ 20) ===================== (declare-const patient_has_finding_of_disorder_of_immune_function_now Bool) ;; "impaired immune function" ;; ===================== Constraint Assertions (REQ 20) ===================== (assert (! (not patient_has_finding_of_disorder_of_immune_function_now) :named REQ20_COMPONENT0_OTHER_REQUIREMENTS)) ;; "A patient is excluded if the patient has evidence of impaired immune function.",→ ;; ===================== Declarations for the exclusion criterion (REQ 21) ===================== (declare-const patient_has_finding_of_mantoux_positive_now Bool) ;; "positive reaction to purified protein derivative",→ (declare-const patient_has_finding_of_mantoux_positive_now@@new Bool) ;; "new positive reaction to purified protein derivative",→ (declare-const patient_has_finding_of_mantoux_positive_now@@known Bool) ;; "the patient is known to be purified protein derivative positive",→ (declare-const patient_has_undergone_plain_chest_x_ray_now_outcome_is_negative Bool) ;; "the patient has a negative chest x-ray",→ (declare-const patient_has_taken_isoniazid_containing_product_now Bool) ;; "isoniazid" (declare-const patient_has_taken_isoniazid_containing_product_now@@used_as_prophylaxis Bool) ;; "the patient has received isoniazid prophylaxis",→ ;; ===================== Auxiliary Assertions (REQ 21) ===================== ;; Qualifier variables imply corresponding stem variables (assert (! (=> patient_has_finding_of_mantoux_positive_now@@new patient_has_finding_of_mantoux_positive_now) :named REQ21_AUXILIARY0)) ;; "new positive reaction to purified protein derivative" (assert (! (=> patient_has_finding_of_mantoux_positive_now@@known patient_has_finding_of_mantoux_positive_now) :named REQ21_AUXILIARY1)) ;; "the patient is known to be purified protein derivative positive" (assert (! (=> patient_has_taken_isoniazid_containing_product_now@@used_as_prophylaxis patient_has_taken_isoniazid_containing_product_now) :named REQ21_AUXILIARY2)) ;; "the patient has received isoniazid prophylaxis" ;; ===================== Constraint Assertions (REQ 21) ===================== ;; Exclusion: (new positive reaction to PPD) AND NOT (known PPD positive AND negative chest x-ray AND received isoniazid prophylaxis),→ (assert (! (not (and patient_has_finding_of_mantoux_positive_now@@new (not (and patient_has_finding_of_mantoux_positive_now@@known patient_has_undergone_plain_chest_x_ray_now_outcome_is_negative patient_has_taken_isoniazid_containing_product_now@@used_as_prophylaxis)))) :named REQ21_COMPONENT0_OTHER_REQUIREMENTS)) ;; "A patient is excluded if (the patient has a new positive reaction to purified protein derivative) AND (NOT ((the patient is known to be purified protein derivative positive) AND (the patient has a negative chest x-ray) AND (the patient has received isoniazid prophylaxis)))." ,→ ,→ ;; ===================== Declarations for the exclusion criterion (REQ 22) ===================== (declare-const patient_has_undergone_stool_culture_now Bool) ;; "stool culture" (declare-const patient_has_undergone_stool_culture_now@@demonstrates_presence_of_pathogenic_ova Bool) ;; "demonstrates the presence of pathogenic ova",→ (declare-const patient_has_undergone_stool_culture_now@@demonstrates_presence_of_pathogenic_parasites Bool) ;; "demonstrates the presence of pathogenic parasites",→ (declare-const patient_has_undergone_stool_culture_now@@demonstrates_presence_of_bacterial_enteropathogens_with_ ⌋ exhaustive_subcategories Bool) ;; "demonstrates the presence of bacterial enteropathogens with exhaustive subcategories (enteroaggregative Escherichia coli, Salmonella, Shigella, Campylobacter)" ,→ ,→ (declare-const patient_has_undergone_stool_culture_now@@is_devoid_of_normal_flora Bool) ;; "stool culture that is devoid of normal flora",→ (declare-const patient_has_finding_of_enteropathogenic_bacteria_isolated_now Bool) ;; "bacterial enteropathogens" ;; ===================== Auxiliary Assertions (REQ 22) ===================== 94 Preprint. Under review. ;; Exhaustive subcategories: bacterial enteropathogens ⼹ (enteroaggregative Escherichia coli âĹĺ Salmonella âĹĺ Shigella âĹĺ Campylobacter),→ (assert (! (= patient_has_undergone_stool_culture_now@@demonstrates_presence_of_bacterial_enteropathogens_with_exhaustiv ⌋ e_subcategories,→ patient_has_finding_of_enteropathogenic_bacteria_isolated_now) :named REQ22_AUXILIARY0)) ;; "bacterial enteropathogens with exhaustive subcategories (enteroaggregative Escherichia coli, Salmonella, Shigella, Campylobacter)",→ ;; Qualifier variables imply corresponding stem variables (assert (! (=> patient_has_undergone_stool_culture_now@@demonstrates_presence_of_pathogenic_ova patient_has_undergone_stool_culture_now) :named REQ22_AUXILIARY1)) ;; "demonstrates the presence of pathogenic ova" (assert (! (=> patient_has_undergone_stool_culture_now@@demonstrates_presence_of_pathogenic_parasites patient_has_undergone_stool_culture_now) :named REQ22_AUXILIARY2)) ;; "demonstrates the presence of pathogenic parasites" (assert (! (=> patient_has_undergone_stool_culture_now@@demonstrates_presence_of_bacterial_enteropathogens_with_exhausti ⌋ ve_subcategories,→ patient_has_undergone_stool_culture_now) :named REQ22_AUXILIARY3)) ;; "demonstrates the presence of bacterial enteropathogens with exhaustive subcategories",→ (assert (! (=> patient_has_undergone_stool_culture_now@@is_devoid_of_normal_flora patient_has_undergone_stool_culture_now) :named REQ22_AUXILIARY4)) ;; "stool culture that is devoid of normal flora" ;; ===================== Constraint Assertions (REQ 22) ===================== (assert (! (not patient_has_undergone_stool_culture_now@@demonstrates_presence_of_pathogenic_ova) :named REQ22_COMPONENT0_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has a stool culture that demonstrates the presence of pathogenic ova.",→ (assert (! (not patient_has_undergone_stool_culture_now@@demonstrates_presence_of_pathogenic_parasites) :named REQ22_COMPONENT1_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has a stool culture that demonstrates the presence of pathogenic parasites.",→ (assert (! (not patient_has_undergone_stool_culture_now@@demonstrates_presence_of_bacterial_enteropathogens_with_exhaust ⌋ ive_subcategories),→ :named REQ22_COMPONENT2_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has a stool culture that demonstrates the presence of bacterial enteropathogens with exhaustive subcategories (enteroaggregative Escherichia coli, Salmonella, Shigella, Campylobacter)." ,→ ,→ (assert (! (not patient_has_undergone_stool_culture_now@@is_devoid_of_normal_flora) :named REQ22_COMPONENT3_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has a stool culture that is devoid of normal flora.",→ ;; ===================== Declarations for the exclusion criterion (REQ 23) ===================== (declare-const patient_has_finding_of_intolerance_to_lactose_now@@self_reported Bool) ;; "the patient has self-reported lactose intolerance",→ (declare-const patient_has_intolerance_to_soya_bean_now@@self_reported Bool) ;; "the patient has self-reported soy intolerance",→ (declare-const patient_has_allergy_to_lactose_now@@self_reported Bool) ;; "the patient has self-reported lactose allergy",→ (declare-const patient_has_finding_of_allergy_to_soy_protein_now@@self_reported Bool) ;; "the patient has self-reported soy allergy",→ ;; ===================== Constraint Assertions (REQ 23) ===================== (assert (! (not patient_has_finding_of_intolerance_to_lactose_now@@self_reported) :named REQ23_COMPONENT0_OTHER_REQUIREMENTS)) ;; "the patient has self-reported lactose intolerance" (assert (! (not patient_has_intolerance_to_soya_bean_now@@self_reported) :named REQ23_COMPONENT1_OTHER_REQUIREMENTS)) ;; "the patient has self-reported soy intolerance" (assert (! (not patient_has_allergy_to_lactose_now@@self_reported) :named REQ23_COMPONENT2_OTHER_REQUIREMENTS)) ;; "the patient has self-reported lactose allergy" (assert (! (not patient_has_finding_of_allergy_to_soy_protein_now@@self_reported) :named REQ23_COMPONENT3_OTHER_REQUIREMENTS)) ;; "the patient has self-reported soy allergy" 95 Preprint. Under review. ;; ===================== Declarations for the exclusion criterion (REQ 24) ===================== (declare-const patient_has_finding_of_smoker_now Bool) ;; "smoker" (declare-const patient_has_finding_of_tobacco_smoking_behavior_finding_now Bool) ;; "smoking" (declare-const patient_has_finding_of_tobacco_smoking_behavior_finding_now@@cannot_stop_for_duration_of_inpatient_study Bool) ;; "cannot stop smoking for the duration of the inpatient study" ,→ ,→ ;; ===================== Auxiliary Assertions (REQ 24) ===================== ;; Being a smoker implies engaging in tobacco smoking behavior (assert (! (=> patient_has_finding_of_smoker_now patient_has_finding_of_tobacco_smoking_behavior_finding_now) :named REQ24_AUXILIARY0)) ;; "smoker" âĞŠ "engaging in tobacco smoking behavior" ;; Qualifier variable implies corresponding stem variable (assert (! (=> patient_has_finding_of_tobacco_smoking_behavior_finding_now@@cannot_stop_for_duration_of_inpatient_study patient_has_finding_of_tobacco_smoking_behavior_finding_now) :named REQ24_AUXILIARY1)) ;; "cannot stop smoking for the duration of the inpatient study" âĞŠ "engaging in tobacco smoking behavior",→ ;; ===================== Constraint Assertions (REQ 24) ===================== ;; Exclusion: patient is a smoker AND cannot stop smoking for the duration of the inpatient study (assert (! (not (and patient_has_finding_of_smoker_now patient_has_finding_of_tobacco_smoking_behavior_finding_now@@cannot_stop_for_duration_of_inpatient_ ⌋ study)),→ :named REQ24_COMPONENT0_OTHER_REQUIREMENTS)) ;; "the patient is a smoker AND the patient cannot stop smoking for the duration of the inpatient study.",→ 96 Preprint. Under review. F Prompts This section presents the prompts used in S AT I R. Contents of this section F.1Prompts for Trial-Side Semantic Parsing . . . . . . . . . . . . . . . . . . . . .97 F.2Prompts for Patient-Side Semantic Parsing . . . . . . . . . . . . . . . . . . . 192 F.3Prompts for Trial-Side Salience-Based Constraint Augmentation . . . . . . . 216 F.4Prompts for Patient-Side Inferential Constraint Augmentation . . . . . . . . 219 F.5Prompts for Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 F.1 Prompts for Trial-Side Semantic Parsing F.1.1 Preprocessing: Trial Cohort Extractor Purpose.This prompt identifies whether a clinical trial defines multiple enrollment groups, where a patient can qualify through any one group. When such structure is present, it separates the trial into explicit cohorts, each with its own inclusion and exclusion criteria, while preserving shared trial-level conditions. This makes the enrollment structure explicit so that each cohort can be processed independently in downstream parsing. === ROLE === You are an expert clinician reviewing clinical trial texts. === TASKS === Determine whether the text describes disjunctive enrollment cohorts (i.e., meeting any one cohort's criteria makes a participant eligible).,→ For each cohort, extract its context, inclusion criteria, and exclusion criteria. Also extract any shared context that applies across all cohorts.,→ === RULES === 1. Minimal edits & fidelity: Use only the provided contextual_text; make no external assumptions. Preserve original wording where feasible; lightly clean formatting (e.g., bullets, deduping) when needed.,→ 2. Detect cohorts (explicit or implicit): Create a new cohort for each labeled arm/part/group or for implicit alternatives on the same concept (see Implicit Cohortizer).,→ 3. Implicit Cohortizer (required): if inclusion bullets give alternative ways to qualify on the same entity/measure, make separate cohorts even without labels. Triggers:,→ - Comparator splits on same variable (e.g., > 2 cm vs < 2 cm (+ risk)), - Conditional gates (``if risk factors…′,``either/or′, ICU vs non-ICU, cases vs controls), - Partitioning qualifiers (e.g.,``with ICU need′ vs``not in need of ICU′). Name unlabeled cohorts as Cohort A: <verbatim headline>, Cohort B: <verbatim headline>, ... 4. Shared vs per-cohort + propagation (must): Put trial-level fields (brief_title, phase, drugs, enrollment, summary) in shared_context.If an inclusion/exclusion applies to all participants, copy it verbatim into every cohort and also summarize it in shared_context. ,→ ,→ 5. Cleanup placeholders: Remove dangling cross-refs like``defined below/above′; if a section would be empty, set it to "".,→ 6. Output schema (strict) - inclusion_criteria and exclusion_criteria are single strings containing bullet lists (each line starts with - ).,→ - Do not use arrays. - Do not nest shared_context under enrollment_cohorts. - Only return "Overall" if there are no explicit labels and no implicit cues (Rule 3). 7. Self-check before finalizing - Any implicit cues? Then $≥$2 cohorts. - Shared criteria replicated into each cohort? - Placeholders removed? - JSON matches schema? - Count of cohorts matches what you inferred? # === Cues & Fallback === 1. Create separate cohorts for labeled arms/parts or when bullets present alternative ways to qualify on the same measure/entity (e.g., > 2 cm vs < 2 cm + risk,``either/or′, ICU vs non-ICU, cases vs controls). Name unlabeled cohorts: Cohort A: <verbatim>, Cohort B: <verbatim>. ,→ ,→ 2. Use a single "Overall" cohort only if none of the above cues appear. # === Cleanup & propagation === 1. Copy any inclusion/exclusion that applies to all participants into every cohort and summarize it in shared_context.,→ 97 Preprint. Under review. 2. Remove placeholders like``defined below/above′; leave empty sections as "". === EXAMPLES === Use the followings as examples of how we will go about subcohorting. Some subcohorting may be implicit. <example_1> <example_1_input> "_id": "NCT01387828", "title": "Comparison Between Open and Laparoscopic Splenic Aneurysms Repair", "text": "Summary: The purpose of this study is compare two different surgical treatments of splenic artery aneurysms: open and laparoscopic approach. criteria: inclusion criteria: Splenic artery aneurysm with diameter greater than 2 cm Splenic artery aneurysm with diameter smaller than 2 cm if risk factors for rupture are associated (child bearing age, pregnancy, blister or saccular shape, increasing diameter) criteria: : Complex aneurysm involving the celiac trunk American Society of Anesthesiologists (ASA) Score > 3", "metadata": "brief_title": "Comparison Between Open and Laparoscopic Splenic Aneurysms Repair", "phase": "Phase 3", "drugs": "['Laparoscopic splenic aneurysm repair, eventual splenectomy','Laparotomic splenic artery aneurysm repair, eventual artery reconstruction or splenectomy']", "drugs_list": ["Laparoscopic splenic aneurysm repair", "eventual splenectomy", "Laparotomic splenic artery aneurysm repair", "eventual artery reconstruction or splenectomy"], "diseases": "['Splenic Artery Aneurysm']", "diseases_list": ["Splenic Artery Aneurysm"], "enrollment": "29.0", "inclusion_criteria": "inclusion criteria: Splenic artery aneurysm with diameter greater than 2 cm Splenic artery aneurysm with diameter smaller than 2 cm if risk factors for rupture are associated (child bearing age, pregnancy, blister or saccular shape, increasing diameter) ", "exclusion_criteria": ": Complex aneurysm involving the celiac trunk American Society of Anesthesiologists (ASA) Score > 3", "brief_summary": "The purpose of this study is compare two different surgical treatments of splenic artery aneurysms: open and laparoscopic approach." ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ </example_1_input> <example_1_output> "shared_context": "brief_title: Comparison Between Open and Laparoscopic Splenic Aneurysms Repair : Phase 3 : ['Laparoscopic splenic aneurysm repair, eventual splenectomy','Laparotomic splenic artery aneurysm repair, eventual artery reconstruction or splenectomy'] : ['Splenic Artery Aneurysm'] : 29.0 _summary: The purpose of this study is compare two different surgical treatments of splenic artery aneurysms: open and laparoscopic approach. exclusion criteria (apply to all cohorts): - Complex aneurysm involving the celiac trunk - American Society of Anesthesiologists (ASA) Score > 3", ,→ ,→ ,→ ,→ ,→ "enrollment_cohorts": [ "shared_context": "brief_title: Comparison Between Open and Laparoscopic Splenic Aneurysms Repair : Phase 3 : ['Laparoscopic splenic aneurysm repair, eventual splenectomy','Laparotomic splenic artery aneurysm repair, eventual artery reconstruction or splenectomy'] : ['Splenic Artery Aneurysm'] : 29.0 _summary: The purpose of this study is compare two different surgical treatments of splenic artery aneurysms: open and laparoscopic approach. exclusion criteria (apply to all cohorts): - Complex aneurysm involving the celiac trunk - American Society of Anesthesiologists (ASA) Score > 3", ,→ ,→ ,→ ,→ ,→ ,→ "enrollment_cohorts": [ "cohort_name": "Cohort A: Splenic artery aneurysm diameter > 2 cm", "inclusion_criteria": "- Splenic artery aneurysm with diameter greater than 2 cm", "exclusion_criteria": "- Complex aneurysm involving the celiac trunk - American Society of Anesthesiologists (ASA) Score > 3",,→ "context": "" , "cohort_name": "Cohort B: Splenic artery aneurysm diameter < 2 cm with rupture risk factors", "inclusion_criteria": "- Splenic artery aneurysm with diameter smaller than 2 cm if risk factors for rupture are associated (child bearing age, pregnancy, blister or saccular shape, increasing diameter)",,→ "exclusion_criteria": "- Complex aneurysm involving the celiac trunk - American Society of Anesthesiologists (ASA) Score > 3",,→ "context": "" ] ] </example_1_output> <example_2> <example_2_input> 98 Preprint. Under review. "title": "Evidence Based Diagnostics and Treatment Planning Solution for Traumatic Brain Injuries", "text": "Summary: Adult patients, age 2265 18 years, with clinically diagnosed mild, moderate or severe brain trauma will be asked to participate in the study. This prospective database will consist of 400 subjects with TBI, 200 from both TUCH and Cambridge Addenbrooke's Hospital. In addition, 100 controls will be recruited, with 50 from both centres.This study is a prospective clinical observational study with detailed data collecting. All patients will be treated according to the accepted, standardized, existing guidelines that are based on national and international recommendations. New treatment interventions will NOT be evaluated during the data acquisition for this study. criteria: inclusion criteria: Severe or moderate brain trauma subjects with need of ICU care: Glasgow Coma Score (GCS) 2264 8 after the primary stabilization has been performed in the field (= patient not hypoxic or hypotensive) and at least 30 min interval from the moment of injury. GCS 9 - 13 and the patient is deteriorating The patient has GCS 2264 13 and has other injuries, which require interventions for hemodynamic or ventilatory incidents The patient is in urgent need of neurosurgery (craniotomy, impression skull fracture, severe haemorrhagic contusion, or ICP measurement) Moderate or mild brain trauma not in need of ICU care: - All other patients who fulfil the diagnostic criteria for an acute TBI but without any criteria: defined below ", "metadata": "brief_title": "Evidence Based Diagnostics and Treatment Planning Solution for Traumatic Brain Injuries", "phase": "", "drugs": "", "drugs_list": [], "diseases": "['Traumatic Brain Injury']", "diseases_list": ["Traumatic Brain Injury"], "enrollment": "396.0", "inclusion_criteria": "inclusion criteria: Severe or moderate brain trauma subjects with need of ICU care: Glasgow Coma Score (GCS) 2264 8 after the primary stabilization has been performed in the field (= patient not hypoxic or hypotensive) and at least 30 min interval from the moment of injury. GCS 9 - 13 and the patient is deteriorating The patient has GCS 2264 13 and has other injuries, which require interventions for hemodynamic or ventilatory incidents The patient is in urgent need of neurosurgery (craniotomy, impression skull fracture, severe haemorrhagic contusion, or ICP measurement) Moderate or mild brain trauma not in need of ICU care: - All other patients who fulfil the diagnostic criteria for an acute TBI but without any ", "exclusion_criteria": " defined below ", "brief_summary": "Adult patients, age 2265 18 years, with clinically diagnosed mild, moderate or severe brain trauma will be asked to participate in the study. This prospective database will consist of 400 subjects with TBI, 200 from both TUCH and Cambridge Addenbrooke's Hospital. In addition, 100 controls will be recruited, with 50 from both centres.This study is a prospective clinical observational study with detailed data collecting. All patients will be treated according to the accepted, standardized, existing guidelines that are based on national and international recommendations. New treatment interventions will NOT be evaluated during the data acquisition for this study." ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ </example_2_input> <example_2_output> "shared_context": "brief_title: Evidence Based Diagnostics and Treatment Planning Solution for Traumatic Brain Injuries : : [] : ['Traumatic Brain Injury'] : 396.0 _summary: Adult patients, age $≥$ 18 years, with clinically diagnosed mild, moderate or severe brain trauma will be asked to participate in the study. This prospective database will consist of 400 subjects with TBI, 200 from both TUCH and Cambridge Addenbrooke's Hospital. In addition, 100 controls will be recruited, with 50 from both centres.This study is a prospective clinical observational study with detailed data collecting. All patients will be treated according to the accepted, standardized, existing guidelines that are based on national and international recommendations. New treatment interventions will NOT be evaluated during the data acquisition for this study. logic: Disjunctive (ICU subpaths are alternatives; non-ICU is a separate path). inclusion criteria (apply to all cohorts): - Adult patients, age $≥$ 18 years, with clinically diagnosed mild, moderate or severe brain trauma", ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ "enrollment_cohorts": [ "cohort_name": "Cohort A: GCS $≤$ 8 after primary stabilization (not hypoxic/hypotensive) and $≥$ 30 min from injury",,→ "inclusion_criteria": "- Adult patients, age $≥$ 18 years, with clinically diagnosed mild, moderate or severe brain trauma - Glasgow Coma Score (GCS) $≤$ 8 after the primary stabilization has been performed in the field (= patient not hypoxic or hypotensive) and at least 30 min interval from the moment of injury.", ,→ ,→ "exclusion_criteria": "", "context": "Severe or moderate brain trauma subjects with need of ICU care" , "cohort_name": "Cohort B: GCS 9 - 13 and the patient is deteriorating", "inclusion_criteria": "- Adult patients, age $≥$ 18 years, with clinically diagnosed mild, moderate or severe brain trauma - GCS 9 - 13 and the patient is deteriorating",,→ "exclusion_criteria": "", "context": "Severe or moderate brain trauma subjects with need of ICU care" , "cohort_name": "Cohort C: GCS $≤$ 13 with other injuries requiring hemodynamic/ventilatory interventions", "inclusion_criteria": "- Adult patients, age $≥$ 18 years, with clinically diagnosed mild, moderate or severe brain trauma - The patient has GCS $≤$ 13 and has other injuries, which require interventions for hemodynamic or ventilatory incidents", ,→ ,→ "exclusion_criteria": "", "context": "Severe or moderate brain trauma subjects with need of ICU care" , "cohort_name": "Cohort D: Urgent need of neurosurgery", "inclusion_criteria": "- Adult patients, age $≥$ 18 years, with clinically diagnosed mild, moderate or severe brain trauma - The patient is in urgent need of neurosurgery (craniotomy, impression skull fracture, severe haemorrhagic contusion, or ICP measurement)", ,→ ,→ "exclusion_criteria": "", "context": "Severe or moderate brain trauma subjects with need of ICU care" , "cohort_name": "Cohort E: Moderate or mild brain trauma not in need of ICU care", 99 Preprint. Under review. "inclusion_criteria": "- Adult patients, age $≥$ 18 years, with clinically diagnosed mild, moderate or severe brain trauma - All other patients who fulfil the diagnostic criteria for an acute TBI",,→ "exclusion_criteria": "", "context": "Moderate or mild brain trauma not in need of ICU care" ] </example_2_output> </example_2> === INPUTS === <contextual_text> #CONTEXTUAL_TEXT# </contextual_text> === OUTPUT FORMAT === "shared_context": "<shared cleaned context information that applies to all cohorts (retain brief_title, phase, drugs, etc. if present)>",,→ "enrollment_cohorts": [ "cohort_name": "<label from text (e.g.,'Cohort A: AD')>", "inclusion_criteria": "<bullet/numbered list; include shared + cohort-specific here>", "exclusion_criteria": "<bullet/numbered list; include shared + cohort-specific here>", "context": "<cohort-specific context: design elements, dosing, endpoints, visit windows, etc.>" // repeat for each detected cohort ] F.1.2 Preprocessing: Inclusion Requirements Extractor Purpose.This prompt extracts inclusion criteria from free-text eligibility text and converts them into a list of self-contained requirement statements. Each requirement is rewritten into a standardized form with explicit inclusion meaning and clear patient-level phrasing, while preserving the original text span for traceability. This ensures that each requirement can be directly translated into a logical condition in downstream processing. # === ROLE === You are an expert requirement extractor. Task: Turn the free text in requirement_text to a list of requirements for later processing. Usually, this can be done by breaking by newlines, but relying on newline breaking can be imprecise. Therefore, we would like to have you do the list conversion intelligently. ,→ ,→ # === BACKGROUND === You are being inputted with inclusion criteria. If an inclusion criteria is satisfied (i.e., has value True), the participant may be included. If an inclusion criteria is not satisfied (i.e., has value False), the participant is not included. ,→ ,→ # === INPUTS === <contextual_text> #CONTEXTUAL_TEXT# </contextual_text> <requirement_text> #REQUIREMENT_TEXT# </requirement_text> # === RULES === 1. Use only information that is verbatim in the texts or unambiguously entailed. 2. Do NOT rely on external knowledge or assumptions. 3. Extract inclusion requirements from requirement_text only, do NOT extract contextual_text. 3. Each requirement must be self-contained and small enough to map directly to a logical clause. 4. Provide exact provenance: quote the sentence(s) or phrase(s) that support each requirement. 5. Always phrase the subject as the goal and a single patient (e.g.,``To be included, the patient must ...′), even if the source text says``patients′, to ensure logical preciseness in later SMT translation.,→ 6. Do not alter the meaning of the requirements! 7. Do not skip, ignore, or omit any part of the requirement text (even if requirements repeat). 8. You should just mimic breaking by new lines. It is very simple. You just also address the noisy parts (e.g., also include examples/explanations broken by newlines and put them together as a single contiguous requirement).,→ 100 Preprint. Under review. 9. If the text introduces subgroup labels (e.g., AD group:, non-AD group:, Arm A:, Cohort 1:), prepend that label as a condition to every requirement under it until another label or the section ends. Phrase it as``A patient is included if the patient is in the <GROUP> group and …′. Treat each group separately (even if requirements repeat). Requirements outside a group label apply globally without modification. Always include the group header in the provenance. ,→ ,→ ,→ ,→ 10. You should rewrite everything into strictly requirement format. Sometimes the input is not in the imperative requirement format. We want to reword those into imperative requirement format. For example, "patients with a cardiac history including myocardial infarction, heart failure, or coronary artery disease should have a cardiology review" must be reworded to "patients with a cardiac history including myocardial infarction, heart failure, or coronary artery disease must have undergone cardiology review". ,→ ,→ ,→ ,→ 11. Note that some criteria may not be about the patient themselves, but rather someone that is related to the patient. In those cases, the requirements should be like "To be included, the patient must have a caregiver / parent / child who is ...". Everything should still be framed with the patient being the subject! ,→ ,→ =================== OUTPUT FORMAT =================== Note that these examples are solely for the purpose of demonstration!!!!!!! You should be sticking to the input blocks for your own analysis. Think independently. Only use these as examples.,→ <example_1> <input_free_text_eligibility_example_1> A sore and scratchy throat and/or pain on swallowing (odynophagia) together with at least 2 of the following clinical signs:,→ Tonsil and/or pharyngeal erythema and/or exudate; Cervical adenopathy; Uvular edema; Fever </input_free_text_eligibility_example_1> <output> "requirements": [ "requirement": "To be included, the patient must have a sore and scratchy throat and/or pain on swallowing (odynophagia) together with at least 2 of the following clinical signs: tonsil and/or pharyngeal erythema and/or exudate, cervical adenopathy, uvular edema, or fever.", ,→ ,→ "text_span": "A sore and scratchy throat and/or pain on swallowing (odynophagia) together with at least 2 of the following clinical signs:Tonsil and/or pharyngeal erythema and/or exudate; Cervical adenopathy; Uvular edema; Fever" ,→ ,→ ] </output> </example_1> <example_2> <input_free_text_eligibility_example_2> AD group : Male or female patient, aged $≥$ 40 years old included at entry. Patients having a clinical diagnosis of probable AD according to DSM-IV TR [F00.x] and National Institute of Neurological and Communicative Disorders and Stroke/Alzheimer's Disease and Related Disorders Association (NINCDS-ADRDA) criteria. ,→ ,→ Non AD demented group : Male or female patient, aged $≥$ 40 years old included at entry. Cognitive impairment-free control group : Male or female subject, aged $≥$ 60 years old included at entry. Written informed consent obtained from the subject. </input_free_text_eligibility_example_2> <output> "requirements": [ "requirement": "To be included, the patient has Alzheimer's Disease and is male or female, aged $≥$ 40 years old at entry.",,→ "text_span": "AD group : Male or female patient, aged $≥$ 40 years old included at entry." , "requirement": "To be included, the patient has Alzheimer's Disease and has a clinical diagnosis of probable AD according to DSM-IV TR [F00.x] and National Institute of Neurological and Communicative Disorders and Stroke/Alzheimer's Disease and Related Disorders Association (NINCDS-ADRDA) criteria.", ,→ ,→ ,→ "text_span": "Patients having a clinical diagnosis of probable AD according to DSM-IV TR [F00.x] and National Institute of Neurological and Communicative Disorders and Stroke/Alzheimer's Disease and Related Disorders Association (NINCDS-ADRDA) criteria." ,→ ,→ , "requirement": "To be included, a patient has non-AD dementia and is male or female, aged $≥$ 40 years old at entry.",,→ "text_span": "Non AD demented group : Male or female patient, aged $≥$ 40 years old included at entry.",→ 101 Preprint. Under review. , "requirement": "To be included, a patient is cognitive impairment-free and is male or female, aged $≥$ 60 years old at entry.",,→ "text_span": "Cognitive impairment-free control group : Male or female subject, aged $≥$ 60 years old included at entry.",→ , "requirement": "To be included, a patient is cognitive impairment-free and has written informed consent obtained from the subject.",,→ "text_span": "Written informed consent obtained from the subject." , ], </output> </example_2> # === OUTPUT FORMAT === <requirements> [ "text_span": "<exact supporting text>", "requirement": "A patient is excluded if <R1>", ``applicable_cohort′:``patients that are <some qualifier>′, "text_span": "<exact supporting text>", "requirement": "A patient is excluded if <R2>",,→ ... ] </requirements> F.1.3 Preprocessing: Exclusion Requirements Extractor Purpose.This prompt extracts exclusion criteria from free-text eligibility text and converts them into a list of self-contained requirement statements. Each requirement is rewritten into a standardized form with explicit exclusion meaning and clear patient-level phrasing, while preserving the original text span for traceability. This ensures that each requirement can be directly translated into a logical condition in downstream processing. # === ROLE === You are an expert requirement extractor. Task: Turn the free text requirement_text to a list of requirements for later processing. Usually, this can be done by breaking by newlines, but relying on newline breaking can be imprecise. Therefore, we would like to have you do the list conversion intelligently. ,→ ,→ # === BACKGROUND === You are being inputted with exclusion criteria. If an exclusion criteria is satisfied (i.e., has value True), the participant must be excluded. If an exclusion criteria is not satisfied (i.e., has value False), the participant may not be excluded (may be included). ,→ ,→ # === INPUTS === <contextual_text> #CONTEXTUAL_TEXT# </contextual_text> <requirement_text> #REQUIREMENT_TEXT# </requirement_text> # === RULES === 1. Use only information that is verbatim in the texts or unambiguously entailed. 2. Do NOT rely on external knowledge or assumptions. 3. Each requirement must be self-contained enough to map directly to a logical clause. 4. Provide exact provenance: quote the sentence(s) or phrase(s) that support each requirement. 5. Always phrase the subject as the goal and a single patient (e.g.,``A patient is excluded if the patient ...′), even if the source text says``patients′, to ensure logical preciseness in later SMT translation.,→ 6. Do not alter the meaning of the requirements! 7. Do not skip, ignore, or omit any part of the requirement text (even if requirements repeat). 8. You should just mimic breaking by new lines. It is very simple. You just also address the noisy parts (e.g., also include examples/explanations broken by newlines and put them together as a single contiguous requirement).,→ 9. Under some cases, one requirement may be only applicable to a subset of patients (e.g., using nested bullet points structure where the top level lines specify where all the nested requirements apply to). There may also be cases that specify those restrictions in a different way. Be careful of those cases! When extracting requirements, make sure to apply the applicable_cohort information to the umbrellaed requirement. In the final extracted requirement, append the nested requirement in the following way:``A patient is included if the patient are <subset cohort information> and <nested requirement>′. Noted that <subset cohort information> should be rephrased to medical terms. For example, "AD group" should be rephrased to "has Alzheimer's disease (AD)". ,→ ,→ ,→ ,→ ,→ ,→ ,→ 102 Preprint. Under review. 10. You should rewrite everything into strictly requirement format. Sometimes the input is not in the imperative requirement format. We want to reword those into imperative requirement format. For example, "patient should ..." should be rewritten into "patient must have ..." format. ,→ ,→ 11. Note that some criteria may not be about the patient themselves, but rather someone that is related to the patient. In those cases, the requirements should be like "A patient is excluded if the patient has a caregiver / parent / child who is ...". Everything should still be framed with the patient being the subject! ,→ ,→ =================== OUTPUT FORMAT =================== Note that these examples are solely for the purpose of demonstration!!!!!!! You should be sticking to the input blocks for your own analysis. Think independently. Only use these as examples.,→ <example_1> <input_free_text_eligibility_example_1> Any of the following pulmonary conditions that may preclude interpretation of study results: Cystic fibrosis Primary lung cancer or another malignancy metastatic to the lungs Known bronchial obstruction or a history of post-obstructive pneumonia Known or suspected active tuberculosis. </input_free_text_eligibility_example_1> <output> "requirements": [ "text_span": "Any of the following pulmonary conditions that may preclude interpretation of study results: Cystic fibrosis Primary lung cancer or another malignancy metastatic to the lungs Known bronchial obstruction or a history of post-obstructive pneumonia Known or suspected active tuberculosis.", ,→ ,→ ,→ "requirement": "A patient is excluded if the patient has any of the following pulmonary conditions that may preclude interpretation of study results: cystic fibrosis, primary lung cancer or another malignancy metastatic to the lungs, known bronchial obstruction or a history of post-obstructive pneumonia, or known or suspected active tuberculosis." ,→ ,→ ,→ , ] </output> </example_1> <example_2> <input_free_text_eligibility_example_2> AD group : Any pathology, medical condition or symptoms that may lead to reconsider the initial diagnosis of probable AD, or that may rend the initial diagnosis of probable AD doubtful at entry, according to the opinion of the investigator. ,→ ,→ Current or recent history of drug or alcohol abuse or dependence. Non-AD demented group : Current diagnosis of brain tumour. Current or recent history of drug or alcohol abuse or dependence. Pregnancy. Cognitive impairment-free control group : Subject spontaneously complaining from significant cognitive impairment. Known family history of dementia. </input_free_text_eligibility_example_2> <output> "requirements": [ "text_span": "AD group : Any pathology, medical condition or symptoms that may lead to reconsider the initial diagnosis of probable AD, or that may rend the initial diagnosis of probable AD doubtful at entry, according to the opinion of the investigator.", ,→ ,→ "requirement": "A patient is excluded if the patient has AD and has any pathology, medical condition, or symptoms that may lead to reconsider the initial diagnosis of probable AD, or that may render the initial diagnosis of probable AD doubtful at entry, according to the opinion of the investigator." ,→ ,→ ,→ , "text_span": "AD group : Current or recent history of drug or alcohol abuse or dependence.", "requirement": "A patient is excluded if the patient has AD and has a current or recent history of drug or alcohol abuse or dependence.",→ , "text_span": "Non-AD demented group : Current diagnosis of brain tumour.", "requirement": "A patient is excluded if the patient has non-AD dementia and has a current diagnosis of brain tumour.",→ , "text_span": "Non-AD demented group : Current or recent history of drug or alcohol abuse or dependence.",,→ "requirement": "A patient is excluded if the patient has non-AD dementia and has a current or recent history of drug or alcohol abuse or dependence.",→ , 103 Preprint. Under review. "text_span": "Cognitive impairment-free control group : Subject spontaneously complaining from significant cognitive impairment.",,→ "requirement": "A patient is excluded if the patient is cognitive impairment-free and spontaneously complains of significant cognitive impairment.",→ , "text_span": "Known family history of dementia.", "requirement": "A patient is excluded if the patient is cognitive impairment-free and has a known family history of dementia.",→ , ], </output> </example_2> # === OUTPUT FORMAT === <requirements> [ "text_span": "<exact supporting text>", "requirement": "A patient is excluded if <R1>", "text_span": "<exact supporting text>", "requirement": "A patient is excluded if <R2>", ... ] </requirements> F.1.4 Preprocessing: Inclusion Extraction Checker Purpose. This prompt verifies that the extracted inclusion requirements fully cover the source text, preserve the intended inclusion meaning, and follow the required patient-level format. In particular, it checks that no criteria are omitted, that the set of requirements correctly reflects the "all conditions must be satisfiedâ ̆ A ̇ I logic of inclusion criteria, and that each requirement is expressed in a consistent, standardized form for downstream processing. # === ROLE === You are an expert technical editor. # === BACKGROUND === You are being inputted with inclusion criteria. If an inclusion criteria is satisfied (i.e., has value True), the participant may be included. If an inclusion criteria is not satisfied (i.e., has value False), the participant is not included. ,→ ,→ # === TASK === Given the raw eligibility-criteria text in <CRITERIA_TEXT> and a JSON array of the machine-extracted requirements (from inclusion criteria) in <EXTRACTED_JSON>, work through the following checklist to see if the extraction is correct.,→ # === CHECKLIST === 1. Check if extraction covers every bullet / numbered line in the source. Answer true or false in "all_covered". 2. Verify that the set of extracted requirements, when considered together, fully represents the meaning of the original inclusion text. Because inclusion requires all conditions to be satisfied, mark anding_list_gives_same_meaning = true only if the combined interpretation matches the original intent, even if there is overlap or redundancy. ,→ ,→ ,→ 3. Check if everything correctly starts with "To be included, the patient must ...". Answer true or false in "starts_with_semantic_template".,→ 4. If all of the above are true, mark "overall_good_extraction" as true and leave "explanation" empty. Otherwise, mark "overall_good_extraction" as false and explain in "explanation" what went wrong.,→ # === RULES === If there are no requirements, and we correctly extracted no requirement, just set everything to be True. # === FORMAT === Return ONLY a JSON object: "all_covered": true | false, "anding_list_gives_same_meaning": true | false, "starts_with_semantic_template": true | false, "overall_good_extraction": true | false, "explanation": "...explain what went wrong..." # === INPUT === <CRITERIA_TEXT> CRITERIA </CRITERIA_TEXT> <EXTRACTED_JSON> 104 Preprint. Under review. EXTRACTED </EXTRACTED_JSON> F.1.5 Preprocessing: Exclusion Extraction Checker Purpose. This prompt verifies that the extracted exclusion requirements fully cover the source text, preserve the intended exclusion meaning, and follow the required patient-level format. In particular, it checks that no criteria are omitted, that the set of requirements correctly reflects the "exclude if any condition is met" logic, and that each requirement is expressed in a consistent, standardized form for downstream processing. # === ROLE === You are an expert technical editor. # === BACKGROUND === You are being inputted with exclusion criteria. If an exclusion criteria is satisfied (i.e., has value True), the participant must be excluded. If an exclusion criteria is not satisfied (i.e., has value False), the participant may not be excluded (may be included). ,→ ,→ # === TASK === Given the raw eligibility-criteria text in <CRITERIA_TEXT> and a JSON array of the machine-extracted requirements (from exclusion criteria) in <EXTRACTED_JSON>, work through the following checklist to see if the extraction is correct.,→ # === CHECKLIST === 1. Check if extraction covers every bullet / numbered line in the source. Answer true or false in "all_covered". 2. Verify that the set of extracted exclusion requirements, when interpreted together, accurately represents the meaning of the original exclusion section. Because exclusion is triggered when any single requirement is met, mark oring_list_gives_same_meaning = true only if the combined interpretation preserves that intent, even if there is overlap or redundancy. ,→ ,→ ,→ 3. Check if everything correctly starts with "The/A patient is excluded if the patient ...". Answer true or false in "starts_with_semantic_template".,→ 4. If all of the above are are true, mark "overall_good_extraction" as true and leave "explanation" empty. Otherwise, mark "overall_good_extraction" as false and explain in "explanation" what went wrong.,→ # === RULES === If there are no requirements, and we correctly extracted no requirement, just set everything to be True. # === FORMAT === Return ONLY a JSON object: "all_covered": true | false, "oring_list_gives_same_meaning": true | false, "starts_with_semantic_template": true | false, "overall_good_extraction": true | false, "explanation": "...explain what went wrong..." # === INPUT === <CRITERIA_TEXT> CRITERIA </CRITERIA_TEXT> <EXTRACTED_JSON> EXTRACTED </EXTRACTED_JSON> F.1.6 Preprocessing: Entity Expander Purpose. This prompt rewrites each requirement so that every medically meaningful entity is expressed as a clear, standalone phrase. It expands compressed or coordinated mentions (e.g., shared heads, abbreviations) while preserving the original wording and logical structure. This makes entity boundaries explicit, allowing each entity to be reliably matched to ontology concepts in downstream processing. # === ROLE === You are a careful, deterministic clinical-trial text editor. Task: For each requirement, expand coordinated medical-entity spans in noun form so every medically relevant entity becomes a single, contiguous phrase (duplicate shared heads where needed).,→ Goal: Later, we will replace these entities with their SNOMED canonical names. Therefore, ensure that every medically relevant entity appears as an independent text span and that no other wording or logic is altered.,→ 105 Preprint. Under review. # === INPUT === <contextual_text> #CONTEXTUAL_TEXT# </contextual_text> <original_requirement_list> #REQUIREMENT_TEXT# </original_requirement_list> # === Example Guidelines === 1. Shared-head expansion of entities -- "fracture of tibia and fibula" should be rewritten to "fracture of tibia and fracture of fibula" -- "retropharyngeal or buccal cellulitis" should be rewritten to "retropharyngeal cellulitis or buccal cellulitis",→ 2. Do not duplicate non-entity action phrases -- "submission of a throat swab specimen for bacterial culture, identification, and antibiotic-susceptibility testing" stays exactly the same (the medical act is one unit; only the purpose list is medical).,→ - "Patients with cough or shortness of breath" **stays exactly the same**. 3. Convert adjectival medical descriptors into explicit noun-form expressions (e.g.,``hypertensive patients′ should be rewritten to``patients with hypertension′).,→ 4. Remove clauses that always evaluate to true: for example, "of any race" and "of any sex/gender" can be safely omitted as it is not meaning anything useful.,→ - "the patient must be male or female" cannot be safely omitted. 5. Preserve original logical relationships after rewriting (ANDs should stay ANDs, ORs should stay ORs), depending on the context:,→ - "A sore and scratchy throat" should be rewritten to "A sore throat AND a scratchy throat". The adjectives describe distinct findings, so they should be split.,→ - If multiple medical descriptors jointly used to qualify a medical term (e.g. 2-year, double-blind, placebo-controlled ASA study), it should not be expanded.,→ - "Clinical diagnosis of acute tonsillitis/pharyngitis caused by Streptococcus pyogenes" should be rewritten to "Clinical diagnosis of acute tonsillitis caused by Streptococcus pyogenes OR clinical diagnosis of pharyngitis caused by Streptococcus pyogenes". ,→ ,→ 6. Mutually Exclusive Diagnostic Findings: If multiple descriptors within a diagnostic result represent mutually exclusive findings (i.e., the same test cannot show both at once), rewrite them using OR rather than AND.,→ - Example: "Patients of chronic stable angina with abnormal Exercise Myocardial Perfusion Spect Scan with reversible and partially reversible ischemic changes." should be rewritten to "Patients of chronic stable angina with abnormal Exercise Myocardial Perfusion Spect Scan showing reversible ischemic changes OR abnormal Exercise Myocardial Perfusion Spect Scan showing partially reversible ischemic changes." ,→ ,→ ,→ 6. Turn abbreviations into full names; keep only the full name if both appear. 7. If two alternative, equivalent names exist, keep only the one that is more likely to match to a SNOMED concept using SapBert-based embedding serach.,→ 8. Beware that "and/or" means "or", and should always be expanded as "or". For example, "a contraindication to EGD and/or biopsies" should be expanded as "a contraindication to EGD or a contradication to biopsies".,→ 9. Rewrite each requirement using only its own content. Do not import details from any other requirements. Do not import details from trial context.,→ 10. All pronoun's should be fully expanded. 10.1. Example: "A patient is excluded if the patient has an infection of the deep tissues of the upper respiratory tract or of the suprapharyngeal respiratory tract and its connecting structures.": "A patient is excluded if the patient has an infection of the deep tissues of the upper respiratory tract or of the suprapharyngeal respiratory tract and the connecting structures of the suprapharyngeal tract." ,→ ,→ ,→ 11. Be careful about pluarity and singularity, be sure to preserve. # === EDGE CASE EXAMPLE ==== DO NOT Change the original requirement's meaning. Particularly, preserve all parantheses, explanation relationships, and qualifier relationships. Don't drop parantheses in the original requirement.,→ <example_1> <example_input_1> "A patient is excluded if the patient was previously enrolled in the study during prior hospitalization (for multiple admissions; only data from the first admission will be used).",,→ </example_input_1> <example_output_1> "A patient is excluded if the patient was previously enrolled in the study during prior hospitalization (for multiple admissions; only data from the first admission will be used).",,→ </example_output_1> </example_1> <example_2> <example_input_2> "A patient is included if the patient has chronic stable angina and has an abnormal Exercise Myocardial Perfusion Spect Scan with reversible and partially reversible ischemic changes.",,→ </example_input_2> <example_output_2> "A patient is included if the patient has chronic stable angina and has an abnormal exercise myocardial perfusion single-photon emission computed tomography scan showing reversible ischemic changes or has an abnormal exercise myocardial perfusion single-photon emission computed tomography scan showing partially reversible ischemic changes.", ,→ ,→ ,→ </example_output_2> </example_2> 106 Preprint. Under review. <example_3> <example_input_3> [00] To be included, the patient must be at average risk or higher for colorectal cancer and scheduled for colonoscopy with any of the following indications: prior colorectal cancer, prior colorectal adenoma, strong family history of colorectal neoplasia, or iron deficiency. ,→ ,→ [01] To be included, the patient must be aged between 40 and 100 years inclusive. [02] To be included, the patient must have known or highly suspected primary colorectal neoplasms greater than 10 m.,→ [03] To be included, the patient must be at higher than average risk for colorectal cancer and scheduled for colonoscopy with any of the following indications: prior colorectal cancer, prior colorectal adenoma, strong family history of colorectal neoplasia, or iron deficiency. ,→ ,→ </example_input_3> <example_output_3> [00] To be included, the patient must be at average risk for colorectal cancer or must be at higher than average risk for colorectal cancer, and the patient must be scheduled for colonoscopy with any of the following indications: prior colorectal cancer, prior colorectal adenoma, strong family history of colorectal neoplasia, or iron deficiency. ,→ ,→ ,→ [01] To be included, the patient must be aged between 40 and 100 years inclusive. [02] To be included, the patient must have known primary colorectal neoplasms greater than 10 m or must have highly suspected primary colorectal neoplasms greater than 10 m.,→ [03] To be included, the patient must be at higher than average risk for colorectal cancer and scheduled for colonoscopy with any of the following indications: prior colorectal cancer, prior colorectal adenoma, strong family history of colorectal neoplasia, or iron deficiency. ,→ ,→ </example_output_3> </example_3> # === RULES === Return the same number of lines, each prefixed with its original 0-based index: [00] rewritten requirement [01] rewritten requirement [02] rewritten requirement # === OUTPUT FORMAT (output exactly these two blocks) === <rewritten_requirement_list> [00] … [01] … [02] … </rewritten_requirement_list> F.1.7 Preprocessing: Entity Expansion Checker Purpose.This prompt verifies that entity expansion is correct and meaning-preserving. It checks that all medically relevant entities are expressed as clear, standalone phrases, and that the rewritten requirements remain semantically identical to the originals. In particular, it ensures that no information is lost or added, and that the set of patients described by each requirement remains unchanged. # === GOAL === You are an expert clinical-trial text auditor. In the last module, for each requirement, coordinated medical-entity spans have been expanded in noun form so every medically relevant entity becomes a single, contiguous phrase (duplicate shared heads where needed).,→ Your task is two-fold: Verify that every medically relevant entity has been correctly rewritten as a single, contiguous phrase (shared heads duplicated as needed).,→ Ensure each rewritten requirement is semantically and logically identical to its original, with absolutely no new errors or changes in meaning.,→ # === INPUTS === <contextual_text> #CONTEXTUAL_TEXT# </contextual_text> ORIGINAL trial requirements: ORIGINAL_LIST EXPANDED trial requirements (after entity-span expansion): EXPANDED_LIST # === CHECKLIST === Check each pair line-by-line according to ALL six rules: 1. No information is lost. 2. No extra information is added. 107 Preprint. Under review. 3. Shared-head / coordinated entities are fully expanded. 4. Abbreviations are fully expanded. 5. Pronouns are resolved to their explicit referents. 6. The original requirement and the rewritten requirements map to the same pool of patients. # === GUIDELINES === 1. For each requirement in the list, walk through the checklist one rule at a time, totalling the above 6 rules. Write the result of each to the corresponding "rule x": <true|false> field.,→ 2. If all are satisfied, we call it a good expansion, and mark the "good_expansion" field as true. If any rule is not satisfied, we mark good_expansion as false.,→ 3. In the field of "explanation", explain why you came up with the final decision on "good_expansion". 4. It is fine to remove redundant information. Don't go down the rabbit hole. 5. Note that we use "or" for inclusive or (equivalent to and/or), and we use XOR for exclusive or. Be lenient to rewriting and/or to or.,→ 6. Note that two concepts are the same under our discussion if they are "close enough", meaning that the rewritten term is a reasonable representation of the extracted_span/extracted_entity. Keep it as long as they are reasonably the same thing (in SNOMED). For example, "android obesity" is a reasonable entity match for "abdominal obesity" in SNOMED. ,→ ,→ ,→ === OUTPUT FORMAT === Return **valid JSON** with these keys ONLY: "<requirement_index_1>": "rule 1": <true|false>, "rule 2": <true|false>, "rule 3": <true|false>, "rule 4": <true|false>, "rule 5": <true|false>, "rule 6": <true|false>, "good_expansion": <true|false>, // true $→$ every line passes every rule "explanation": "...your explanation...", "<requirement_index_2>": ... If all_passed is true, failed_reqs & reasons MUST be empty arrays. Respond with the JSON alone --- no extra commentary. F.1.8 Preprocessing: Inclusion Requirement Logic Rewriter Purpose. This prompt rewrites inclusion requirements to make their logical structure fully explicit and unambiguous. It surfaces logical operators (e.g., AND, OR, NOT), clarifies scope using parentheses, and makes qualifiers and conditions precise, while preserving the original clinical meaning. The result is a standardized form that can be directly translated into formal logical assertions in downstream processing. # === ROLE === You are a careful, deterministic clinical-trial text editor. # === BACKGROUND === You are being inputted with inclusion criteria. If an inclusion criteria is satisfied (i.e., has value True), the participant may be included. If an inclusion criteria is not satisfied (i.e., has value False), the participant is not included. ,→ ,→ # === TASK === For each requirement, make implicit logical details explicit (qualifiers, numerical comparators, inclusive/exclusive OR, etc.) and precise without changing the intended medical meaning.,→ Goal: These rewritten requirements will be translated into SMT assertions. 1. Ensure every requirement is phrased from the perspective of one screened patient (singular), not from the perspective of the entire recruitment pool.,→ 2. Treat each medically relevant entity phrase as an indivisible span; do **not** alter, duplicate, or remove any entity wording.,→ # === INPUT === <contextual_text> #CONTEXTUAL_TEXT# </contextual_text> <original_requirement_list> #REQUIREMENT_TEXT# </original_requirement_list> # === GUIDELINES === 108 Preprint. Under review. 0. Make hierarchies/priorities between logical connectives (ANDs, ORs, XORs, and NOTs) are explicit by adding parantheses (think about how we add paranetheses when doing arithmetics; similarly, logical connectives for the inner parantheses are evaluated before those for the outer parantheses). ,→ ,→ 1. Convert abbreviations to full names. If both abbreviations and full names exist (e.g., if one explains the other), only keep the full name.,→ 2. Remove clauses that always evaluate to TRUE (e.g.,``of any race′,``of any sex/gender′) or are meaningless (e.g., simply for clarification or noting).,→ 3. Replace vague plurals with explicit quantifiers - "one of the following" should be rewritten to "at least one of the following" - If patients have lesions" should be rewritten to "If a patient has $≥$ 1 lesion" 4. Spell out numerical bounds and comparators - "50 % - "blood pressure < 140/90 mmHg" should be rewritten to "systolic blood pressure < 140 mmHg **and** diastolic blood pressure < 90 mmHg",→ 5. Only use the following logical connectives: XOR, OR, AND, NOT. Never use other logical connectives or other ways to express logical connectives.,→ - For example, "and/or" or "AND/OR" should always be rewritten as "OR" for disambiguation. 6. When one qualifier qualifies multiple entities but only show up once (due to underspecification in human language), duplicate the qualifier to make sure that it shows up together with every entity it qualifies. Especially, we want to make sure that a qualifier never lives outside the parantheses corresponding to the subject it qualifies. Similarly, if one example enumeration suits multiple entities, add the enumeration immediately after each of these entities. ,→ ,→ ,→ ,→ 7. Always preserve the semantic template in the beginning (i.e., "To be included, the patient must ..."). 8. If a medical term and its plain language term both exist at the same place, only preserve the medical term. 9. Put explanations, definitions into a paranthese right after the subject it targets. 10. When a sentence names an umbrella term followed by items, replace ambiguous markers (``such as,′``i.e.,′ ``e.g.,′``including,′``like′) by making the listing relationship explicit as either:,→ 10.1 with exhaustive subcategories (...): the listed items are the complete set under the umbrella; nothing outside the list qualifies. Treat these cues as exhaustive unless context clearly contradicts it: "i.e.", "only", "limited to", "must be one of", "consisting of", rewrite as with exhaustive subcategories (...). ,→ ,→ 10.2 with non-exhaustive examples (...): the listed items are illustrative only; other items in the category may also qualify. Treat these cues as non-exhaustive unless the text explicitly states completeness: "e.g.", "such as", "including", "like", "for example", rewrite as with non-exhaustive examples (...). ,→ ,→ 10.3 If context is ambiguous, default to non-exhaustive examples. <example> <original> The patient is included if the patient is being treated with drugs permitted by the study protocol ie, A, B, or Class I antiarrhythmic agents (eg, C, D).,→ </original> <rewritten> The patient is included if the patient is being treated with drugs permitted by the study protocol with exhaustive subcategories (A, B, or Class I antiarrhythmic agents (with non-exhaustive examples (C, D))).,→ </rewritten> </example> *A*, *B*, and *Class I agents* form the **exhaustive subcategories** of``drugs not permitted by the study protocol.′ By contrast, *C* is a **non-exhaustive example** of``Class I agents.′,→ 11. Put explanations and definitions into a paranthese right after the subject it targets. 12. Refer to <original_requirement_list> as the input, use the contextual text requirement blocks oly as a reference for correctness.,→ # === EXAMPLES === <example_0> <original_0> To be included, the patient must have a sore throat AND a scratchy throat AND/OR pain on swallowing (odynophagia).,→ </original_0> <rewritten_0> To be included, the patient must have (a sore throat AND a scratchy throat) OR (odynophagia). </rewritten_0> </example_0> <example_1> <original_1> To be included, the patient must be aged 1-18 years and present with persistent abdominal pain lasting for $≥$2 weeks, which may be localized abdominal pain, diffuse abdominal pain, intermittent abdominal pain, or recurrent abdominal pain. ,→ ,→ </original_1> <rewritten_1> To be included, the patient must be (aged 1-18 years) AND (present with persistent abdominal pain lasting (which may be localized abdominal pain OR diffuse abdominal pain OR intermittent abdominal pain OR recurrent abdominal pain) for $≥$2 weeks, ). ,→ ,→ </rewritten_1> </example_1> <example_2> <original_2> To be included, the patient must not have had prior abdominal radiotherapy or prior thoracic radiotherapy. </original_2> <rewritten_2> To be included, the patient must NOT have had prior abdominal radiotherapy AND NOT have had prior thoracic radiotherapy.,→ 109 Preprint. Under review. </rewritten_2> </example_2> # === RULES === Return the same number of lines, each prefixed with its original 0-based index: [00] rewritten requirement [01] rewritten requirement [02] rewritten requirement # === OUTPUT FORMAT (output exactly these two blocks) === <rewritten_requirement_list> [00] To be included, the patient must ... [01] To be included, the patient must ... [02] To be included, the patient must ... </rewritten_requirement_list> F.1.9 Preprocessing: Exclusion Requirement Logic Rewriter Purpose. This prompt rewrites exclusion requirements to make their logical structure fully explicit and unambiguous. It surfaces logical operators (e.g., AND, OR, NOT), clarifies scope using parentheses, and makes qualifiers and conditions precise, while preserving the original clinical meaning. The result is a standardized form that can be directly translated into formal logical assertions in downstream processing. # === ROLE === You are a careful, deterministic clinical-trial text editor. # === BACKGROUND === You are being inputted with exclusion criteria. If an exclusion criteria is satisfied (i.e., has value True), the participant must be excluded. If an exclusion criteria is not satisfied (i.e., has value False), the participant may not be excluded (may be included). ,→ ,→ # === TASK === For each requirement, make implicit logical details explicit (qualifiers, numerical comparators, inclusive/exclusive OR, etc.) and precise without changing the intended medical meaning.,→ Goal: These rewritten requirements will be translated into SMT assertions. 1. Ensure every requirement is phrased from the perspective of one screened patient (singular), not from the perspective of the entire recruitment pool.,→ 2. Treat each medically relevant entity phrase as an indivisible span; do **not** alter, duplicate, or remove any entity wording.,→ # === INPUT === <contextual_text> #CONTEXTUAL_TEXT# </contextual_text> <original_requirement_list> #REQUIREMENT_TEXT# </original_requirement_list> # === GUIDELINES === 0. Make hierarchies/priorities between logical connectives (ANDs, ORs, XORs, and NOTs) are explicit by adding parantheses (think about how we add paranetheses when doing arithmetics; similarly, logical connectives for the inner parantheses are evaluated before those for the outer parantheses). ,→ ,→ 1. Convert abbreviations to full names. If both abbreviations and full names exist (e.g., if one explains the other), only keep the full name.,→ 2. Remove clauses that always evaluate to TRUE (e.g.,``of any race′,``of any sex/gender′) or are meaningless (e.g., simply for clarification or noting).,→ 3. Replace vague plurals with explicit quantifiers - "one of the following" should be rewritten to "at least one of the following" - If patients have lesions" should be rewritten to "If a patient has $≥$ 1 lesion" 4. Spell out numerical bounds and comparators - "50 % - "blood pressure < 140/90 mmHg" should be rewritten to "systolic blood pressure < 140 mmHg **and** diastolic blood pressure < 90 mmHg",→ 5. Only use the following logical connectives: XOR, OR, AND, NOT. Never use other logical connectives or other ways to express logical connectives.,→ - For example, "and/or" or "AND/OR" should always be rewritten as "OR" for disambiguation. 6. When one qualifier qualifies multiple entities but only show up once (due to underspecification in human language), duplicate the qualifier to make sure that it shows up together with every entity it qualifies. Especially, we want to make sure that a qualifier never lives outside the parantheses corresponding to the subject it qualifies. Similarly, if one example enumeration suits multiple entities, add the enumeration immediately after each of these entities. ,→ ,→ ,→ ,→ 7. Always preserve the semantic template in the beginning (i.e., "The patient is excluded if the patient ..."). 8. If a medical term and its plain language term both exist at the same place, only preserve the medical term. 110 Preprint. Under review. 9. If the text states that patients are eligible under a certain condition, rewrite that condition as a NOT clause in the exclusion logic.,→ - For example, "patients with malignancies in remission are eligible" should be rewritten as "The patient is excluded if the patient does NOT have malignancies in remission".,→ 10. When a sentence names an umbrella term followed by items, replace ambiguous markers (``such as,′``i.e.,′ ``e.g.,′``including,′``like′) by making the listing relationship explicit as either:,→ 10.1 with exhaustive subcategories (...): the listed items are the complete set under the umbrella; nothing outside the list qualifies. Treat these cues as exhaustive unless context clearly contradicts it: "i.e.", "only", "limited to", "must be one of", "consisting of", rewrite as with exhaustive subcategories (...). ,→ ,→ 10.2 with non-exhaustive examples (...): the listed items are illustrative only; other items in the category may also qualify. Treat these cues as non-exhaustive unless the text explicitly states completeness: "e.g.", "such as", "including", "like", "for example", rewrite as with non-exhaustive examples (...). ,→ ,→ 10.3 If context is ambiguous, default to non-exhaustive examples. <example> <original> The patient is excluded if the patient is being treated with drugs not permitted by the study protocol ie, A, B, or Class I antiarrhythmic agents (eg, C, D).,→ </original> <rewritten> The patient is excluded if the patient is being treated with drugs not permitted by the study protocol with exhaustive subcategories (A, B, or Class I antiarrhythmic agents (with non-exhaustive examples (C, D))).,→ </rewritten> </example> *A*, *B*, and *Class I agents* form the **exhaustive subcategories** of``drugs not permitted by the study protocol.′ By contrast, *C* is a **non-exhaustive example** of``Class I agents.′,→ 11. Put explanations and definitions into a paranthese right after the subject it targets. 12. Refer to <original_requirement_list> as the input, use the contextual text requirement blocks oly as a reference for correctness.,→ # === EXAMPLES === <example_0> <original_0> A patient is excluded if the patient has clinically significant cardiac disease, such as symptomatic coronary artery disease or myocardial infarction within the last 12 months.,→ </original_0> <rewritten_0> The patient is excluded if the patient has clinically significant cardiac disease with non-exhaustive examples ((symptomatic coronary artery disease within the last 12 months) OR (myocardial infarction within the last 12 months)). ,→ ,→ </rewritten_0> </example_0> <example_1> <original_1> A patient is excluded if the patient has progressive neoplastic disease (patients with malignancies in remission are eligible).,→ </original_1> <rewritten_1> A patient is excluded if (the patient has progressive neoplastic disease) AND (the patient does NOT have malignancies in remission).,→ </rewritten_1> </example_1> <example_2> <original_2> A patient is excluded if the patient is unable to tolerate ceftriaxone or has a history of allergy to beta-lactam antibiotics (history of rash alone does not exclude the patient).,→ </original_2> <rewritten_2> A patient is excluded if the patient (is unable to tolerate ceftriaxone) OR ((has a history of allergy to beta-lactam antibiotics) AND (does NOT only have a history of rash)).,→ </rewritten_2> </example_2> <example_3> <original_3> The patient is excluded if the patient is being treated with drugs not permitted by the study protocol ie, A, B, or Class I antiarrhythmic agents (eg, C, D).,→ </original_3> <rewritten_3> The patient is excluded if the patient is being treated with drugs not permitted by the study protocol with exhaustive subcategories (A, B, or Class I antiarrhythmic agents (with non-exhaustive examples (C, D))).,→ </rewritten_3> </example_3> <example_4> 111 Preprint. Under review. <original_4> A patient is excluded if the patient has symptoms that collectively suggest nonstreptococcal tonsillitis or symptoms that collectively suggest nonstreptococcal pharyngitis (e.g., laryngitis, coryza, conjunctivitis, diarrhea, cough). ,→ ,→ </original_4> <rewritten_4> A patient is excluded if the patient has (symptoms that collectively suggest nonstreptococcal tonsillitis with non-exhaustive examples (laryngitis, coryza, conjunctivitis, diarrhea, cough)) OR (symptoms that collectively suggest nonstreptococcal pharyngitis with non-exhaustive examples (laryngitis, coryza, conjunctivitis, diarrhea, cough)). ,→ ,→ ,→ </rewritten_4> </example_4> <example_5> <original_5> The patient is excluded if the patient was previously enrolled in the study during a prior hospitalization (for multiple hospital admissions; only data from the first hospital admission will be used).,→ </original_5> <rewritten_5> The patient is excluded if the patient was previously enrolled in the study during a prior hospitalization. </rewritten_5> <explanation_example_5> "for multiple admissions, only data from the first hospital admission will be used" is not a valid exclusion criteria, it is only here for noting; it should be removed.,→ </explanation_example_5> </example_5> # === RULES === Return the same number of lines, each prefixed with its original 0-based index: [00] rewritten requirement [01] rewritten requirement [02] rewritten requirement # === OUTPUT FORMAT (output exactly these two blocks) === <rewritten_requirement_list> [00] A patient is excluded if the patient ... [01] A patient is excluded if the patient... [02] A patient is excluded if the patient ... </rewritten_requirement_list> F.1.10 Preprocessing: Inclusion Logic Rewrite Checker Purpose. This prompt verifies that the rewritten inclusion requirements are logically cor- rect, meaning-preserving, and suitable for formal translation. It checks that logical operators and scope are explicitly and correctly represented, that the rewritten requirement corre- sponds to the same set of patients as the original, and that no information is lost, added, or misinterpreted. # === ROLE === You are an expert in clinical criteria and logic. Your goal is to check if logical rewrite of clinical eligibility criteria is correct. # === BACKGROUND === You are being inputted with inclusion criteria. If an inclusion criteria is satisfied (i.e., has value True), the participant may be included. If an inclusion criteria is not satisfied (i.e., has value False), the participant is not included. ,→ ,→ # === INPUT === <original_rewrite_pairs> #ORIGINAL_REWRITE_PAIRS# </original_rewrite_pairs> # === CHECKLIST === Work through the following list, put your results (either "YES" or "NO") in the output json: 0. HIERARCHIES_CAPTURED: Are all hierarchies between logical connectives captured and correctly captured by parantheses? That is, logical expressions in inner parantheses are evaluated before those in the outer parantheses. ,→ ,→ 1. SAME_PATIENT_POOL_MAPPING: Does the rewritten requirement map to the same pool of patients as does the original requirement?,→ 2. AND_OR_XOR_NOT: Does the requirement only use the following set of logical connectives after rewrite: AND, OR, XOR, NOT?,→ 3. ABBREVIATIONS_EXPANDED: Does the rewrite correctly expand all abbreviations? 4. REMOVE_REDUNDANT_CLAUSES: Does the rewrite remove clauses that always evaluate to TRUE (e.g.,``of any race′, ``of any sex/gender′) or are meaningless (e.g., simply for clarification or noting)?,→ - Redundant information includes clauses that are themselves not criteria but are solely here for auxillary noting purposes (e.g., "only data from the first admission will be used").,→ - Redundant information does not include logic phrases that clarify listing relationships (e.g. "with non-exhaustive examples/categories").,→ 112 Preprint. Under review. 5. DUPLICATE_QUALIFIERS: When a qualifier qualifies multiple entities simultanouesly, does the rewrite correctly duplicate the qualifier to make sure that it shows up together with every entity it qualifiers?,→ 6. PRESERVE_SEMANTIC_TEMPLATE: Does the rewrite preserve the "To be included, the patient must ..." in the beginning"?,→ 7. NO_NEW_INFORMATION:Does the requirement NOT add new information that was not present in the original requirement?,→ 8. NO_AND/OR: The rewrite correctly rewrites AND/ORs into ORs; we should never see AND/ORs in the final output. Make a final judgement in "ALL_GOOD", which is "YES" if all these checklist items are "YES", and "NO" if any of these checklist items is "NO".,→ If "ALL_GOOD", put down the explanation in "explanation" and a candidate requirement that would make the checklist items all "YES" in the "corrected_requirement" field.,→ # === OUTPUT FORMAT (output exactly these two blocks) === <rewritten_requirement_list> "by_index": "0": "HIERARCHIES_CAPTURED": "YES" | "NO", "SAME_PATIENT_POOL_MAPPING": "YES" | "NO", "AND_OR_XOR_NOT": "YES" | "NO", "ABBREVIATIONS_EXPANDED": "YES" | "NO", "REMOVE_REDUNDANT_CLAUSES": "YES" | "NO", "DUPLICATE_QUALIFIERS": "YES" | "NO", "PRESERVE_SEMANTIC_TEMPLATE": "YES" | "NO", "NO_NEW_INFORMATION": "YES" | "NO", "NO_AND/OR": "YES" | "NO", "ALL_GOOD": "YES" | "NO", "explanation": "<explain what is not good>", "corrected_requirement": "<rewrite that would make all items YES>" // include every index present in the input ... ... </rewritten_requirement_list> F.1.11 Preprocessing: Exclusion Logic Rewrite Checker Purpose.This prompt verifies that the rewritten exclusion requirements are logically cor- rect, meaning-preserving, and suitable for formal translation. It checks that logical operators and scope are explicitly and correctly represented, that the rewritten requirement corre- sponds to the same set of patients as the original, and that no information is lost, added, or misinterpreted. # === ROLE === You are an expert in clinical criteria and logic. Your goal is to check if logical rewrite of clinical eligibility criteria is correct. # === BACKGROUND === You are being inputted with exclusion criteria. If an exclusion criteria is satisfied (i.e., has value True), the participant must be excluded. If an exclusion criteria is not satisfied (i.e., has value False), the participant may not be excluded (may be included). ,→ ,→ # === INPUT === <original_rewrite_pairs> #ORIGINAL_REWRITE_PAIRS# </original_rewrite_pairs> # === CHECKLIST === Work through the following list, put your results (either "YES" or "NO") in the output json: 0. HIERARCHIES_CAPTURED: Are all hierarchies between logical connectives captured and correctly captured by parantheses? That is, logical expressions in inner parantheses are evaluated before those in the outer parantheses. ,→ ,→ 1. SAME_PATIENT_POOL_MAPPING: Does the rewritten requirement map to the same pool of patients as does the original requirement?,→ 2. AND_OR_XOR_NOT: Does the requirement only use the following set of logical connectives after rewrite: AND, OR, XOR, NOT?,→ 3. ABBREVIATIONS_EXPANDED: Does the rewrite correctly expand all abbreviations? 4. REMOVE_REDUNDANT_CLAUSES: Does the rewrite remove clauses that always evaluate to TRUE (e.g.,``of any race′, ``of any sex/gender′) or are meaningless (e.g., simply for clarification or noting)?,→ - Redundant information includes clauses that are themselves not criteria but are solely here for auxillary noting purposes (e.g., "only data from the first admission will be used").,→ - Redundant information does not include logic phrases that clarify listing relationships (e.g. "with non-exhaustive examples/categories").,→ 5. DUPLICATE_QUALIFIERS: When a qualifier qualifies multiple entities simultanouesly, does the rewrite correctly duplicate the qualifier to make sure that it shows up together with every entity it qualifiers?,→ 113 Preprint. Under review. 6. PRESERVE_SEMANTIC_TEMPLATE: Does the rewrite preserve the "To be included, the patient must ..." in the beginning"?,→ 7. NO_NEW_INFORMATION:Does the requirement NOT add new information that was not present in the original requirement?,→ 8. NO_AND/OR: The rewrite correctly rewrites AND/ORs into ORs; we should never see AND/ORs in the final output. Make a final judgement in "ALL_GOOD", which is "YES" if all these checklist items are "YES", and "NO" if any of these checklist items is "NO".,→ If "ALL_GOOD", put down the explanation in "explanation" and a candidate requirement that would make the checklist items all "YES" in the "corrected_requirement" field.,→ # ===== EXAMPLES ====== These are edge cases. Example 0 is an exclusion criterion includes a negated statement, indicating an exception. Treat the negated clause as an exception and use the example below as a template to validate the correctness of the rewrite.′ ,→ ,→ <example_0> <input_example_0> ORIGINAL: A patient is excluded if the patient has progressive neoplastic disease (patients with malignancies in remission are eligible).,→ REWRITTEN: The patient is excluded if the patient has progressive neoplastic disease whose malignancies are NOT in remission.,→ </input_example_0> <rewritten_requirement_list_example_0> "by_index": "0": "HIERARCHIES_CAPTURED": "YES", "SAME_PATIENT_POOL_MAPPING": "YES", "AND_OR_XOR_NOT": "YES", "ABBREVIATIONS_EXPANDED": "YES", "REMOVE_REDUNDANT_CLAUSES": "YES", "DUPLICATE_QUALIFIERS": "YES", "PRESERVE_SEMANTIC_TEMPLATE": "YES", "NO_NEW_INFORMATION": "YES", "NO_AND/OR": "YES", "ALL_GOOD": "YES", "explanation": "Parentheses correctly capture precedence; the parenthetical eligibility exception ('malignancies in remission are eligible') is properly represented as a negated exception combined with the exclusion trigger, yielding AND(NOT remission) with progressive neoplastic disease. The rewrite uses only AND/NOT, introduces no new information, contains no abbreviations or redundant clauses, preserves the exclusion-style template, and avoids'AND/OR'.", ,→ ,→ ,→ ,→ "corrected_requirement": "The patient is excluded if the patient has progressive neoplastic disease whose malignancies are NOT in remission.",→ </rewritten_requirement_list_example_0> </example_0> <example_1> <input_example_1> ORIGINAL: A patient is excluded if the patient is unable to provide informed consent (impairment of mental status, unable to speak English).,→ REWRITTEN: The patient is excluded if the patient is unable to provide informed consent with non-exhaustive examples (impairment of mental status OR unable to speak English).,→ <rewritten_requirement_list_example_1> "by_index": "0": "HIERARCHIES_CAPTURED": "YES", "SAME_PATIENT_POOL_MAPPING": "YES", "AND_OR_XOR_NOT": "YES", "ABBREVIATIONS_EXPANDED": "YES", "REMOVE_REDUNDANT_CLAUSES": "YES", "DUPLICATE_QUALIFIERS": "YES", "PRESERVE_SEMANTIC_TEMPLATE": "YES", "NO_NEW_INFORMATION": "YES", "NO_AND/OR": "YES", "ALL_GOOD": "YES", "explanation": "The rewrite preserves the exclusion criterion and clarifies that listed reasons are non-exhaustive examples. No change in patient pool, no disallowed connectives, and no redundant clauses.", ,→ ,→ "corrected_requirement": "The patient is excluded if the patient is unable to provide informed consent with non-exhaustive examples (impairment of mental status AND unable to speak English).",→ 114 Preprint. Under review. </rewritten_requirement_list_example_1> </example_1> # === OUTPUT FORMAT (output exactly these two blocks) === <rewritten_requirement_list> "by_index": "0": "HIERARCHIES_CAPTURED": "YES" | "NO", "SAME_PATIENT_POOL_MAPPING": "YES" | "NO", "AND_OR_XOR_NOT": "YES" | "NO", "ABBREVIATIONS_EXPANDED": "YES" | "NO", "REMOVE_REDUNDANT_CLAUSES": "YES" | "NO", "DUPLICATE_QUALIFIERS": "YES" | "NO", "PRESERVE_SEMANTIC_TEMPLATE": "YES" | "NO", "NO_NEW_INFORMATION": "YES" | "NO", "NO_AND/OR": "YES" | "NO", "ALL_GOOD": "YES" | "NO", "explanation": "<explain what is not good>", "corrected_requirement": "<rewrite that would make all items YES>" // include every index present in the input ... </rewritten_requirement_list> F.1.12 Preprocessing: Inclusion Requirement Decomposer Purpose. This prompt decomposes each inclusion requirement into a set of independent component conditions. Each component is defined so that if it is satisfied, the original inclusion criterion is satisfied. The decomposition preserves the original meaning while producing smaller, self-contained units that can be evaluated independently in downstream processing. # === ROLE === You are an expert in human language logic and logical decomposition. # === BACKGROUND === You are being inputted with inclusion criteria. If an inclusion criteria is satisfied (i.e., has value True), the participant may be included. If an inclusion criteria is not satisfied (i.e., has value False), the participant is not included. ,→ ,→ # === TASK === Your task is to decompose each inclusion criterion into independent component requirements that have to be satisfied simultaneously to make the original requirement satisfied. That is, as long as one of these components are not satisfied, the whole requirement can never be satisfied. ,→ ,→ # === INPUT === <requirements> ##REQUIREMENTS_JSON## </requirements> # === GENERAL GUIDELINES === GENERAL.INSTRUCTION_0. Logical connectives (ANDs, ORs, NOTs) have their priorities shown with paranetheses, where expressions in inner parantheses are evaluated before those belonging to outerparantheses. Think of it as inside out recursive evaluation. Also, preserve as many of them as possible after the decomposition. ,→ ,→ GENERAL.INSTRUCTION_1. NEVER NEVER NEVER decompose examples, explanations, purposes, or qualifiers into separete components!,→ For example: "severe hepatic impairment including hepatic failure and cirrhosis" should never be split into "severe hepatic impairment including hepatic failure" and "severe hepatic impairment including cirrhosis",→ Becasue the decomposition splits'severe hepatic impairment' into'hepatic failure' and'cirrhosis,' which are examples or subcategories of severe hepatic impairment. This is not a valid decomposition because satisfying one component does not necessarily satisfy the original requirement." ,→ ,→ GENERAL.INSTRUCTION_2. Keep the leading "To be included, the patient must ..." part in every component from decomposition.,→ GENERAL.INSTRUCTION_3. Make sure that you decompose the requirements into the finest statement (note: not examples or explanations) granularity!,→ GENERAL.INSTRUCTION_4. Be sure to distinguish between cases where "statements are NOT WRAPPED BY A'NOT'" and cases where "statements are WRAPPED BY A'NOT'". See guidelines for each category below.,→ # === GUIDELINES FOR STATEMENTS NOT WRAPPED BY A "NOT" === NOT_WRAPPED_BY_NOT.INSTRUCTION_0. If two component requirements are linked by "or", "OR", or "either ... or" (i.e., any disjunctive logic), under NO circumstances split them!,→ - Treat the whole clause as ONE atomic requirement. - This rule overrides every other instruction. 115 Preprint. Under review. NOT_WRAPPED_BY_NOT.INSTRUCTION_1. Separate component requirements only by "AND"s. That is, if two component requirements are linked by conjunctive logic, you can confidently seprate them.,→ # === EXAMPLES STATEMENTS NOT WRAPPED BY A "NOT" === NOT_WRAPPED_BY_NOT.EXAMPLE_0: "To be included, the patient must not have received ((prior abdominal radiotherapy)) or ((prior thoracic radiotherapy)).": [,→ "To be included, the patient must not have received ((prior abdominal radiotherapy)) or ((prior thoracic radiotherapy))",,→ ], NOT_WRAPPED_BY_NOT.EXAMPLE_1: "To be included, the patient must be able to speak English, where \"able to speak English\" means the patient can communicate effectively in spoken English without assistance.": [,→ "To be included, the patient must be able to speak English, where \"able to speak English\" means the patient can communicate effectively in spoken English without assistance.",,→ ], NOT_WRAPPED_BY_NOT.EXAMPLE_2: "To be included, the patient must have cognitive impairment based on cognitive screening at the time of hospital admission, where \"cognitive impairment\" is determined exclusively by the results of the cognitive screening conducted during the hospital admission process.": [ ,→ ,→ "To be included, the patient must have cognitive impairment based on cognitive screening at the time of hospital admission, where \"cognitive impairment\" is determined exclusively by the results of the cognitive screening conducted during the hospital admission process.", ,→ ,→ ] NOT_WRAPPED_BY_NOT.EXAMPLE_3: "To be included, the patient must have a pre-treatment stage of ((clinical T1 AND node-positive disease AND no distant metastasis) OR (clinical T2 OR clinical T3 OR clinical T4a) AND (node-negative disease OR node-positive disease) AND no distant metastasis).": [ ,→ ,→ "To be included, the patient must have a pre-treatment stage of ((clinical T1 AND node-positive disease AND no distant metastasis) OR (clinical T2 OR clinical T3 OR clinical T4a)).",,→ "To be included, the patient must have a (node-negative disease OR node-positive disease).", "To be included, the patient must have no distant metastasis.", ] NOT_WRAPPED_BY_NOT.EXAMPLE_4: "To be included, the patient must have (signed an informed consent form) OR (have a parent OR guardian who has signed an informed consent form).": [,→ "To be included, the patient must have (signed an informed consent form) OR (have a parent OR guardian who has signed an informed consent form).",→ ], NOT_WRAPPED_BY_NOT.EXAMPLE_5: "To be included, the patient must have adequate respiratory function AND, if the patient is symptomatic, the patient must have pulmonary function tests with forced expiratory volume in one second (FEV1) > 65%,→ "To be included, the patient must have adequate respiratory function." "To be included, if the patient is symptomatic, the patient must have pulmonary function tests with forced expiratory volume in one second (FEV1) > 65%,→ ], # === GUIDELINES FOR STATEMENTS WRAPPED BY A "NOT" === IS_WRAPPED_BY_NOT.INSTRUCTION_0. If two component requirements are linked by "and", "AND", or "as well as" (i.e., any conjunctive logic), under NO circumstances split them!,→ - Treat the whole clause as ONE atomic requirement. - This rule overrides every other instruction. IS_WRAPPED_BY_NOT.INSTRUCTION_1. Separate component requirements only by "OR"s. That is, if two component requirements are linked by disjunctive logic, you can confidently seprate them.,→ # === EXAMPLES FOR STATEMENTS WRAPPED BY A "NOT" === IS_WRAPPED_BY_NOT.EXAMPLE_0. "To be included, the patient must not have ((significant cardiopulmonary disease) or (other contraindication to esophagogastroduodenoscopy)).": [,→ "To be included, the patient must not have significant cardiopulmonary disease" "To be included, the patient must not have contraindication to esophagogastroduodenoscopy". ] # === NEVER SPLIT STATEMENTS WITHIN EXAMPLES, EXPALANTIONS,PURPOSES, OR DEFINITIONS === DONT_SPLIT_DEFINITIONS.EXAMPLE_0: "The patient must have adequate bone marrow function, defined as ((WBC > 3x10^9/l)) and ((Hb > 9 g/dl)) and ((platelets > 100x10^9/l)).": [,→ "The patient must have adequate bone marrow function, defined as ((WBC > 3x10^9/l)) and ((Hb > 9 g/dl)) and ((platelets > 100x10^9/l)).",→ ], DONT_SPLIT_DEFINITIONS.EXAMPLE_1: 116 Preprint. Under review. "To be included, the patient must have adequate liver function, defined as ((serum bilirubin < 1.5x Upper Level of Normal (ULN)) and (AST < 2.5x ULN) and (ALT < 3x ULN)) (ULN as per institutional standard).": [,→ "To be included, the patient must have adequate liver function, defined as ((serum bilirubin < 1.5x Upper Level of Normal (ULN)) and (AST < 2.5x ULN) and (ALT < 3x ULN)) (ULN as per institutional standard).",→ ] DONT_SPLIT_EXAMPLES.EXAMPLE_2: "The patient is excluded if the patient has severe hepatic impairment, including ((hepatic failure) or (cirrhosis)) (inclusive).": [,→ "The patient is excluded if the patient has severe hepatic impairment, including ((hepatic failure) or (cirrhosis)) (inclusive).",→ ] DONT_SPLIT_EXAMPLES.EXAMPLE_3: "To be included, the patient must submit a throat swab specimen for (bacterial culture) AND (bacterial identification) AND (bacterial antibiotic-susceptibility testing).": [,→ "To be included, the patient must submit a throat swab specimen for (bacterial culture) AND (bacterial identification) AND (bacterial antibiotic-susceptibility testing).",→ ], # === OUTPUT (JSON only) === [ "requirement_index": 1, "components": [ "<component 1>", "<component 2>", "..." ] , ... ] F.1.13 Preprocessing: Exclusion Requirement Decomposer Purpose. This prompt decomposes each exclusion requirement into a set of independent component conditions. Each component is defined so that if it is satisfied, the original exclusion criterion is satisfied. The decomposition preserves the original meaning while producing smaller, self-contained units that can be evaluated independently in downstream processing. # === ROLE === You are an expert in human language logic and logical decomposition. # === BACKGROUND === You are being inputted with exclusion criteria. If an exclusion criteria is satisfied (i.e., has value True), the participant must be excluded. If an exclusion criteria is not satisfied (i.e., has value False), the participant may not be excluded (may be included). ,→ ,→ # === TASK === Your task is to decompose each exclusion criterion into independent component requirements that - once any one of them are satisfied - the whole requirement is satisfied. That is, only when all components are NOT SATISFIED, can the original requirement be NOT SATISFIED. ,→ ,→ # === INPUT === <requirements> ##REQUIREMENTS_JSON## </requirements> # === GENERAL GUIDELINES === GENERAL.INSTRUCTION_0. Logical connectives (ANDs, ORs, NOTs) have their priorities shown with paranetheses, where expressions in inner parantheses are evaluated before those belonging to outerparantheses. Think of it as inside out recursive evaluation. Also, preserve as many of them as possible after the decomposition. ,→ ,→ GENERAL.INSTRUCTION_1. NEVER decompose examples, explanations, purposes, or qualifiers into separete components! For example: "severe hepatic impairment like hepatic failure or cirrhosis" should never be split into "severe hepatic impairment like hepatic failure" and "severe hepatic impairment like cirrhosis",→ Becasue the decomposition splits'severe hepatic impairment' into'hepatic failure' and'cirrhosis,' which are examples or subcategories of severe hepatic impairment. This is not a valid decomposition because satisfying one component does not necessarily satisfy the original requirement." ,→ ,→ GENERAL.INSTRUCTION_2. Keep the leading "The patient is excluded if the patient ..." part in every component from decomposition.,→ GENERAL.INSTRUCTION_3. Make sure that you decompose the requirements into the finest statement (note: not examples or explanations) granularity!,→ GENERAL.INSTRUCTION_4. Be sure to distinguish between cases where "statements are NOT WRAPPED BY A'NOT'" and cases where "statements are WRAPPED BY A'NOT'". See guidelines for each category below.,→ 117 Preprint. Under review. GENERAL.INSTRUCTION_5. If there are phrases such as "has a history of" at the front of requirements as top level logic, make sure to include this logic to every umbrellaed component requirements.,→ # === GUIDELINES FOR STATEMENTS NOT WRAPPED BY A "NOT" === NOT_WRAPPED_BY_NOT.INSTRUCTION_0. If two component requirements are linked by "and", "AND", or "as well as" (i.e., any conjunctive logic), under NO circumstances split them!,→ - Treat the whole clause as ONE atomic requirement. - This rule overrides every other instruction. NOT_WRAPPED_BY_NOT.INSTRUCTION_1. Separate component requirements only by "OR"s. That is, if two component requirements are linked by disjunctive logic, you can confidently seprate them.,→ # === EXAMPLES STATEMENTS NOT WRAPPED BY A "NOT" === NOT_WRAPPED_BY_NOT.EXAMPLE_0: "The patient is excluded if ((the patient has a contradiction to esophagogastroduodenoscopy and the patient has a contradiction to biopsies (inclusive))) such as Boerhaave's syndrome, or ((the patient has a history of bleeding disorder or the patient has a history of elevated international normalized ratio (inclusive))).": [ ,→ ,→ "A patient is excluded if the patient has a contradiction to esophagogastroduodenoscopy and the patient has a contradiction to biopsies (inclusive) such as Boerhaave's syndrome.",,→ "A patient is excluded if the patient has a history of bleeding disorder.", "A patient is excluded if the patient has a history of elevated international normalized ratio (inclusive)." ], NOT_WRAPPED_BY_NOT.EXAMPLE_1: "The patient is excluded if the patient has ((clinically significant lung disease, defined as forced expiratory volume in 1 second (FEV1) <65%,→ "The patient is excluded if the patient has ((clinically significant lung disease, defined as forced expiratory volume in 1 second (FEV1) <65%,→ ], NOT_WRAPPED_BY_NOT.EXAMPLE_2: "The patient is excluded if the patient has a history of (heart failure within the preceding six months) OR (unstable angina within the preceding six months)": [,→ "The patient is excluded if the patient has a history of heart failure within the preceding six months.", "The patient is excluded if the patient has a history of unstable angina within the preceding six months." ] # === GUIDELINES FOR STATEMENTS WRAPPED BY A "NOT" === IS_WRAPPED_BY_NOT.INSTRUCTION_0. If two component requirements are linked by "or", "OR", or "either ... or ..." (i.e., any disjunctive logic), under NO circumstances split them!,→ - Treat the whole clause as ONE atomic requirement. - This rule overrides every other instruction. IS_WRAPPED_BY_NOT.INSTRUCTION_1. Separate component requirements only by "AND"s. That is, if two component requirements are linked by conjunctive logic, you can confidently seprate them.,→ # === EXAMPLES FOR STATEMENTS WRAPPED BY A "NOT" === IS_WRAPPED_BY_NOT.EXAMPLE_0. "The patient is excluded if the patient does not have disease A and cancer B": [ "The patient is excluded if the patient does not have disease A", "The patient is excluded if the patient does not have cancer B". ] # === NEVER SPLIT STATEMENTS WITHIN EXAMPLES, EXPALANTIONS, AND DEFINITIONS === DONT_SPLIT_EXAMPLES.EXAMPLE_0: "The patient is excluded if the patient has ((a contraindication to esophagogastroduodenoscopy) or (a contraindication to biopsies)) such as ((Boerhaave's syndrome) or (a history of bleeding disorder) or (a history of elevated international normalized ratio)).": [ ,→ ,→ "The patient is excluded if the patient has ((a contraindication to esophagogastroduodenoscopy) or (a contraindication to biopsies)) such as ((Boerhaave's syndrome) or (a history of bleeding disorder) or (a history of elevated international normalized ratio))." ,→ ,→ ] DONT_SPLIT_EXAMPLES.EXAMPLE_1: "The patient is excluded if the patient has severe hepatic impairment, including ((hepatic failure) or (cirrhosis)) (inclusive).": [,→ "The patient is excluded if the patient has severe hepatic impairment, including ((hepatic failure) or (cirrhosis)) (inclusive).",→ ] DONT_SPLIT_EXAMPLES.EXAMPLE_2: "The patient is excluded if the patient (is in respiratory failure OR is in incipient respiratory failure) AND (is NOT a candidate for mechanical ventilation for any reason).": [,→ 118 Preprint. Under review. "The patient is excluded if the patient (is in respiratory failure OR is in incipient respiratory failure) AND (is NOT a candidate for mechanical ventilation for any reason).",→ ] DONT_SPLIT_EXAMPLES.EXAMPLE_3: "The patient is excluded if the patient has clinically significant cardiac disease (such as symptomatic coronary artery disease OR myocardial infarction within the last 12 months).": [,→ "The patient is excluded if the patient has clinically significant cardiac disease (such as symptomatic coronary artery disease OR myocardial infarction within the last 12 months).",→ ] # === OUTPUT (JSON only) === [ "requirement_index": 1, "components": [ "<component 1>", "<component 2>", "..." ] , ... ] F.1.14 Preprocessing: Inclusion Decomposition Checker Purpose. This prompt checks that the decomposition of each inclusion requirement is logically correct, complete, and meaning-preserving. It checks that components are split according to logical structure (e.g., respecting AND/OR behavior under negation), that no information is lost or added, and that the set of patients defined by the decomposed components is equivalent to the original requirement. # === TASK === You are a logical transformation auditor and a clinical criteria expert. Your job is to decide whether each decomposition of an inclusion criterion is logically correct and complete.,→ # === INPUT DATA === You will receive a JSON array, one entry per original criterion, in the form [ "requirement_index": <int>, // 1-based index "text": "<original requirement>", "components": ["<comp-1>", "<comp-2>", …] , ] # === INPUT === <original_decomposed_pair> #ORIGINAL_DECOMPOSED_PAIR# </original_decomposed_pair> Please refer to the above <last_module_instructions_examples> block for more concrete explanation of what we want. # === BACKGROUND === You are being inputted with inclusion criteria. If an inclusion criteria is satisfied (i.e., has value True), the participant may be included. If an inclusion criteria is not satisfied (i.e., has value False), the participant is not included. ,→ ,→ In the last module, you were asked to decompose requirement into components in the following way. # === CHECKLISTS === For every input requirement (pair of original requirement and decomposed components), answer the following questions:,→ <wrapped_by_nots> 1.1 PARTS_WRAPPED_BY_NOTS: State all parts of the requirement that are wrapped by NOTs (statements that ARE negated). Copy those parts verbatim in the PARTS_WRAPPED_BY_NOTS field.,→ 1.2. ALL_ANDS_WRAPPED_BY_NOTS_NOT_DECOMPOSED: for statements wrapped by a NOT (refer to the immediately preceding PARTS_WRAPPED_BY_NOTS), no components originally connected by ANDs are decomposed into separate components. Again, note that we mean IS wrapped by a NOT, which means the statement SHOULD be inside a higher level NOT. ,→ ,→ </wrapped_by_nots> <not_wrapped_by_not> 119 Preprint. Under review. 2.1. PARTS_NOT_WRAPPED_BY_NOTS: State all parts of the requirement that are NOT wrapped by NOTs (statements that ARE NOT negated). Copy those parts verbatim in the PARTS_NOT_WRAPPED_BY_NOTS field.,→ 2.2. ALL_ORS_NOT_WRAPPED_BY_NOTS_NOT_DECOMPOSED: for statements not wrapped by a NOT (refer to the immediately preciding PARTS_NOT_WRAPPED_BY_NOTS), no components originally connected by ORs are decomposed into separate components. Again, note that we mean NOT wrapped by a NOT, which means the statement should NOT be inside a higher level NOT. ,→ ,→ ,→ </not_wrapped_by_not> 3. ALL_EXAMPLES_DEFINITIONS_PURPOSES_EXPLANATIONS_NOT_DECOMPOSED: no conitguous examples, definitions, purposes, or explanations are decomposed into finer components. For example, this means that "To be included, a paitnet must have clinically significant lung disease (defined as forced expiratory volume in 1 second (FEV1) < 65% ,→ ,→ 4. NO_INFORMATION_IS_ADDED: no information is added from this decomposition. 5. ANDING_COMPONENTS_EQUIVALENT_TO_ORIGINAL: does ANDing (i.e., connecting all components with ANDs / conjunctive logic) all components from the decomposition form a requirement that map to the same patient pool as the original requirement does? ,→ ,→ Answer YES or NO in the corresponding fields in the output json. If all of these check items are YES, mark "overall_good_decomposition" as "YES" and leave "issues" empty.,→ # === IF NOT OKAY, PROVIDE A FIX === If "overall_good_decomposition" would be NO, explain the issues in "issues", then propose a corrected decomposition that:,→ - Preserves the original semantics. - Respects NOT scoping (no splitting ORs under a NOT; no splitting ANDs outside NOT). - Does not add or drop information. Return it in`suggested_components` and also provide a ready-to-verify`next_round_rewrite_pair` in the same schema as the input pair.,→ # === OUTPUT === Respond ONLY with JSON, using the exact structure below---no extra keys, no commentary outside the JSON block: [ "requirement_index": <int>, // copy from the input "wrapped_by_nots": "PARTS_WRAPPED_BY_NOTS": "state parts of the requirements that are negated", "ALL_ANDS_WRAPPED_BY_NOTS_NOT_DECOMPOSED": "YES" | "NO", // If PARTS_WRAPPED_BY_NOTS is empty, this is always YES.,→ "not_wrapped_by_not": "PARTS_NOT_WRAPPED_BY_NOTS": "state parts of the requirements that are NOT negated (i.e., are positive)", "ALL_ORS_NOT_WRAPPED_BY_NOTS_NOT_DECOMPOSED": "YES" | "NO", // If PARTS_NOT_WRAPPED_BY_NOTS is empty, this is always YES.,→ "ALL_EXAMPLES_DEFINITIONS_PURPOSES_EXPLANATIONS_NOT_DECOMPOSED": "YES" | "NO", "NO_INFORMATION_IS_ADDED": "YES" | "NO", "ANDING_COMPONENTS_EQUIVALENT_TO_ORIGINAL": "YES" | "NO", "overall_good_decomposition":"YES" | "NO", "issues": "<explain_issue_here>". "suggested_components": ["<comp-1>", "<comp-2>", "..."], // REQUIRED if overall_good_decomposition == "NO"; else [],→ "next_round_rewrite_pair": // REQUIRED if overall_good_decomposition == "NO" "requirement_index": <int>, // same as input "text": "<original requirement>", // same as input (do not rewrite the text) "components": ["<corrected-comp-1>", "<corrected-comp-2>", "..."] , , ... ] F.1.15 Preprocessing: Exclusion Decomposition Checker Purpose. This prompt checks that the decomposition of each exclusion requirement is logically correct, complete, and meaning-preserving. It checks that components are split according to logical structure (e.g., respecting AND/OR behavior under negation), that no information is lost or added, and that the set of patients defined by the decomposed components is equivalent to the original requirement. # === TASK === You are a logical transformation auditor and a clinical criteria expert. Your job is to decide whether each decomposition of an exclusion criterion is logically correct and complete.,→ # === BACKGROUND === 120 Preprint. Under review. You are being inputted with exclusion criteria. If an exclusion criteria is satisfied (i.e., has value True), the participant must be excluded. If an exclusion criteria is not satisfied (i.e., has value False), the participant may not be excluded (may be included). ,→ ,→ In the last module, you were asked to decompose requirement into components in the following way. # === INPUT DATA === You will receive a JSON array, one entry per original criterion, in the form [ "requirement_index": <int>, // 1-based index "text": "<original requirement>", "components": ["<comp-1>", "<comp-2>", …] , ] # === INPUT === <original_decomposed_pair> #ORIGINAL_DECOMPOSED_PAIR# </original_decomposed_pair> # === CHECKLISTS === For every input requirement (pair of original requirement and decomposed components), check the following items. <wrapped_by_nots> 1.1. PARTS_WRAPPED_BY_NOTS: State all parts of the requirement that are wrapped by NOTs (statements that ARE negated). Copy those parts verbatim in the PARTS_WRAPPED_BY_NOTS field.,→ 1.2. ALL_ORS_WRAPPED_BY_NOTS_NOT_DECOMPOSED: for statements wrapped by a NOT (refer to the immediately preceding PARTS_WRAPPED_BY_NOTS), no components originally connected by ORs are decomposed into separate components. Again, note that we mean IS wrapped by a NOT, which means the statement SHOULD be inside a higher level NOT. ,→ ,→ </wrapped_by_nots> <not_wrapped_by_not> 2.1. PARTS_NOT_WRAPPED_BY_NOTS: State all parts of the requirement that are NOT wrapped by NOTs (statements that ARE NOT negated). Copy those parts verbatim in the PARTS_NOT_WRAPPED_BY_NOTS field.,→ 2.2. ALL_ANDS_NOT_WRAPPED_BY_NOTS_NOT_DECOMPOSED: for statements not wrapped by a NOT (refer to the immediately preceding PARTS_NOT_WRAPPED_BY_NOTS), no components originally connected by ANDs are decomposed into separate components. Again, note that we mean NOT wrapped by a NOT, which means the statement should NOT be inside a higher level NOT. ,→ ,→ ,→ </wrapped_by_nots> <not_wrapped_by_not> 3. ALL_EXAMPLES_DEFINITIONS_PURPOSES_EXPLANATIONS_NOT_DECOMPOSED: no conitguous examples, definitions, purposes, or explanations are decomposed into finer components. For example, this means that "The patient is excluded if the patient has clinically significant lung disease (defined as forced expiratory volume in 1 second (FEV1) < 65% ,→ ,→ ,→ Take another example, this means that "The patient is excluded if the patient has clinically significant cardiac disease (such as symptomatic coronary artery disease OR myocardial infarction within the last 12 months)." should not decompose the examples inside "such as". ,→ ,→ 4. NO_INFORMATION_IS_ADDED: no information is added from this decomposition. 5. ORING_DECOMPOSED_EQUIVALENT_TO_ORIGINAL: does ORing (i.e., connecting the components by disjunctive connectives/ ORs) all components from the decomposition form a requirement that map to the same patient pool as the original requirement does? ,→ ,→ Answer YES or NO in the corresponding fields in the output json. If all of these check items are YES, mark "overall_good_decomposition" as "YES" and leave "issues" empty.,→ # === IF NOT OKAY, PROVIDE A FIX === If "overall_good_decomposition" would be NO, explain the issues in "issues", then propose a corrected decomposition that:,→ - Preserves the original semantics. - Respects NOT scoping (no splitting ORs under a NOT; no splitting ANDs outside NOT). - Does not add or drop information. Return it in`suggested_components` and also provide a ready-to-verify`next_round_rewrite_pair` in the same schema as the input pair.,→ Please refer to the above <last_module_instructions_examples> block for more concrete explanation of what we want. # === OUTPUT === Respond ONLY with JSON, using the exact structure below---no extra keys, no commentary outside the JSON block: [ "requirement_index": <int>, // copy from the input "wrapped_by_nots": "PARTS_WRAPPED_BY_NOTS": "state parts of the requirements that are negated", 121 Preprint. Under review. "ALL_ORS_WRAPPED_BY_NOTS_NOT_DECOMPOSED": "YES" | "NO", // If PARTS_WRAPPED_BY_NOTS is empty, this is always YES.,→ "not_wrapped_by_not": "PARTS_NOT_WRAPPED_BY_NOTS": "state parts of the requirements that are NOT negated (i.e., are positive)", "ALL_ANDS_NOT_WRAPPED_BY_NOTS_NOT_DECOMPOSED": "YES" | "NO", // If PARTS_NOT_WRAPPED_BY_NOTS is empty, this is always YES.,→ "ALL_EXAMPLES_DEFINITIONS_PURPOSES_EXPLANATIONS_NOT_DECOMPOSED": "YES" | "NO", "NO_INFORMATION_IS_ADDED": "YES" | "NO", "ORING_DECOMPOSED_EQUIVALENT_TO_ORIGINAL": "YES" | "NO", "overall_good_decomposition":"YES" | "NO", "issues": "<explain_issue_here>". "suggested_components": ["<comp-1>", "<comp-2>", "..."], // REQUIRED if overall_good_decomposition == "NO"; else [],→ "next_round_rewrite_pair": // REQUIRED if overall_good_decomposition == "NO" "requirement_index": <int>, // same as input "text": "<original requirement>", // same as input (do not rewrite the text) "components": ["<corrected-comp-1>", "<corrected-comp-2>", "..."] , , ... ] F.1.16 Preprocessing: Inclusion Requirement Classifier Purpose. This prompt classifies each inclusion component based on how it should be handled during prescreening. It distinguishes criteria that must be explicitly supported by patient notes, criteria that are non-binding or can be satisfied through simple actions, and criteria that may be unknown at prescreening but should not exclude a trial unless contradicted. This allows the system to enforce only the most informative constraints early while maintaining high recall under incomplete patient information. # === ROLE === You are an expert doctor in pairing patients with clinical trials. # === INPUT FORMAT === You are given two blocks of information. Input 1: <requirements> This is the list of requirements with their conjunctive components laid out (decomposed with conjunctive normal form). You will be asked to label each component of them independently.,→ Input 2: <trial_context> this is the whole text of this trial that you should be using for understanding the context. Primarily, you should be using this for understanding which criteria are more important in deciding the relevance of a patient and a trial. ,→ ,→ # === INPUT === <requirements> ##COMPONENTS_JSON## </requirements> <trial_context> ##TRIAL_CONTEXT## </trial_context> # === TASK === We are categorizing requirement components to decide their roles during the initial information retrieval phase of patient-trial matching. Different requirements and components of requirements play different roles in deciding if a patient-trial pair is relevant. ,→ ,→ When we are performing patient-trial matching, not all information is available. This is a nuance we need to consider. For trials and patients to be meainingfully relevant to each other, some criteria in the trial requirement are mandated/necessary to be explicitly satisfied, while we may tolerate some "not enough information" conditions for other requirements/components. ,→ ,→ ,→ Your task is to label each requirement component with one of the following categories, taking examples as references:,→ Label 1 -- PRESCREEN_NOTES_MUST_COMPLETELY_SUFFICE: All patients to whom this trial is relevant must have all information to satisfy this criterion in their patient notes during prescreening.,→ - Example 1.1: To be included, the patient must be male OR the patient must be female. Label 2 -- NOT_REQUIREMNET_OR_ALWAYS_SATISFIABLE_WITH_ACTION: Use for items that do not determine patient--trial relevance. They're either not true eligibility requirements or can always be fulfilled by a simple, one-time action during prescreening. Do not treat these as inclusion/exclusion gates. Here are some examples: ,→ ,→ - Example 2.1: Completing required paperwork (e.g., signing an updated informed-consent form or providing vaccination records) -- aka submitting missing documentation | finalising paperwork | providing proof of immunisation. ,→ ,→ 122 Preprint. Under review. - Example 2.2: Observing a short-term abstinence (e.g., avoiding alcohol for 24 h) aka temporary lifestyle adjustment | behavioural compliance | brief abstention.,→ - Example 2.3: Fasting as instructed before baseline assessments (e.g., $≥$ 8 h pre-test fast) -- aka observing protocol-mandated fast | undertaking required fasting | pre-lab fasting.,→ - Example 2.4: Attending a follow-up visit or screening procedure (e.g., receiving a booster injection, undergoing an ECG) -- aka returning for clinic visit | completing mandatory screening test | attending scheduled appointment. ,→ ,→ - Example 2.5: Initiating or adjusting contraception to meet study requirements -- aka beginning reliable contraception | starting birth-control regimen | implementing contraceptive measures.,→ - Example 2.6: Using or wearing a study-mandated device/app as instructed -- aka complying with device usage | adopting required study device | wearing activity tracker.,→ - Example 2.7: Having access to the internet Label 3 -- OTHER_REQUIREMENTS: These are the requirment components that we can assume to be satisfied in prescreening as long as they are not explicitly contradicted. That is, when retrieving relevant trials for a patient, we permit relevant trials to have these criteria unknown. ,→ ,→ - Example 3.1: To be included, the patient must have a Mini-Mental State Examination score $≥$ 27 at entry. - Example 3.2: To be included, the patient must have leukocyte count $≥$ 3000 cells/$μ$L. # === BACKGROUND === You are being inputted with inclusion criteria. If an inclusion criteria is satisfied (i.e., has value True), the participant may be included. If an inclusion criteria is not satisfied (i.e., has value False), the participant is not included. ,→ ,→ # === GUIDELINES === 1. For NOT_REQUIREMNET_OR_ALWAYS_SATISFIABLE_WITH_ACTION (and only this category), Note that we are ONLY interested in if an inclusion criterion can be turned from False (not satisfied) to True (is satisfied); we never care about the other way around. ,→ ,→ 2. After you label a component, explain why you made that labelling choice in the "reason" field. 3. If a component is labelled as NOT_REQUIREMNET_OR_ALWAYS_SATISFIABLE_WITH_ACTION, explicitly state what correction is required to turn a criterion from False to True in the "correction" field. If the component adopts the other two labels, keep the field empty. ,→ ,→ 4. Fill the label in the "label" field. 5. In "not_satisfied_meaning", state what it means for this requirement to be not satisfied; In "satisfied_meaning", state what it means for this requirement to be satisfied; In "correctable_meaning", state what is means to go from "not_satisfied_meaning" to "satisfied_meaning". ,→ ,→ 6. Noted the case of requiring single or multiple test/examinations and specifys an expected outcome (e.g. have a positive result from a rapid detection throat swab test for Group A streptococcal antigen). The focus should be the test result. Performing/submitting a test does NOT guarentee obtaining a specific result, so such requirement should NOT be categorized to "NOT_REQUIREMNET_OR_ALWAYS_SATISFIABLE_WITH_ACTION". ,→ ,→ ,→ - Evaluate the test expectation based on the requirement's significance to the clinical trial, and by default categorize it as "OTHER_REQUIREMENTS". The only exception is when the requirement explicitly stated that the test result is an anchoring phenotype of the trial, and that result is reasonably expected to be already known during prescreening. In that case, apply the stricter categorization. If a patient does not yet have the specified result at prescreening, it can be assumed they may obtain it later during the formal screening process, even if the eventual outcome turns out contrary to the expected result. Only the most critical prescreening factors explicitly required by the trial should not be overlooked. ,→ ,→ ,→ ,→ ,→ ,→ 7. Requirement like "all eligibility is be required" is not a standard requirment, and should always be categorized to "NOT_REQUIREMNET_OR_ALWAYS_SATISFIABLE_WITH_ACTION",→ 8. For the requirements that include numberic examination result (that does NOT belong to age/weight, e.g. leukocyte count $≥$ 3000; Mini-Mental State Examination score $≥$ 27 at entry; body temperature >38$ $C), ALWAYS classifiy it to "OTHER_REQUIREMENTS". These results are likely unknown during the prescreening stage. It can be assumed patient obtain it later during the formal screening process, even if the eventual outcome turns out contrary to the expected result. Therefore should NOT be categorized into "PRESCREEN_NOTES_MUST_COMPLETELY_SUFFICE". ,→ ,→ ,→ ,→ ,→ 9. If the requiement is wrapped by "NOT" in the top-level logic (for example, "To be included, the patient must not have any other contraindication to esophagogastroduodenoscopy"), always classify it to OTHER_REQUIREMENTS.,→ 10. Requirements that related to gender should always be categorized to "PRESCREEN_NOTES_MUST_COMPLETELY_SUFFICE" 11. PRESCREEN_NOTES_MUST_COMPLETELY_SUFFICE should never be used on criteria that patients don't usually find it interesting/meaningful/useful to report! For example, patients won't report if they are living in a community (assume to be true); similarly, for statements that are always true (e.g., of any race), there is no point for the patient to report (the patient won't say that they are of'any race'). These are not requirements and should be labelled NOT_REQUIREMNET_OR_ALWAYS_SATISFIABLE_WITH_ACTION. ,→ ,→ ,→ ,→ 12. All demographics-related assertions should be treated as OTHER_REQUIREMENTS. This includes where the patient lives, what's the ethnicity/race of the patients, age, gender, etc.,→ 13. If an assertion is about an observable entity that would usually not be taken/measured for the sake of prescreening, mark it as OTHER_REQUIREMENTS.,→ # === OUTPUT (JSON only) === [ "requirement_index": 1, "components": [ "text": "<component>", "not_satisfied_meaning": "<not_satisfied_meaning>", "satisfied_meaning": "<satisfied_meaning>", "correctable_meaning": "how to go from <not_satisfied_meaning> to <satisfied_meaning>?", "relationship_between_this_trial_and_requirement": "<reflection on the relationship between this trial and this requirement, for labelling in the next field",,→ "label": "PRESCREEN_NOTES_MUST_COMPLETELY_SUFFICE" | "NOT_REQUIREMNET_OR_ALWAYS_SATISFIABLE_WITH_ACTION" | "OTHER_REQUIREMENTS",,→ "reason": "<why>", 123 Preprint. Under review. "correction": "<action>" // required if NOT_REQUIREMNET_OR_ALWAYS_SATISFIABLE_WITH_ACTION ] ] F.1.17 Preprocessing: Exclusion Requirement Classifier Purpose. This prompt classifies each exclusion component based on whether it should be enforced during early-stage matching. It distinguishes true eligibility constraints that determine patientâ ̆ A ̧Strial relevance from requirements that are non-binding or can be satisfied through simple actions. This allows the system to enforce only the most informative constraints during prescreening while deferring others, improving recall when patient information is incomplete. # === ROLE === You are an expert in clinical-trial eligibility criteria. # === BACKGROUND === You are being inputted with exclusion criteria. If an exclusion criteria is satisfied (i.e., has value True), the participant must be excluded. If an exclusion criteria is not satisfied (i.e., has value False), the participant may not be excluded (may be included). ,→ ,→ # === TASK === Eligibility criteria are noisy. Some phrases in the criteria are not really hard constraints. To better match patients with clinical trials, we would like to identify which components - once have value True (i.e., are satisfied) at screening time - can not become unsatisfied (i.e., value False), which components may be reverted to be unsatisfied depending on the outcome on the patient's state, and which components can always go from satisfied (True) to satisfied (False). ,→ ,→ ,→ ,→ Note that we are doing this to filter down to only the "hard" constraints so as to maximize the recall on matching patients when we do trial-patient matching.,→ Here is your task: Label each disjunctively linked component of a requirement as NOT_REQUIREMNET_OR_ALWAYS_SATISFIABLE_WITH_ACTION OTHER_REQUIREMENTS # === LABEL DEFINITIONS & EXAMPLES ==== (Consider, if a criterion is satisfied at screening, can it possibly be not satisfied before randomization of the trial? Then choose among the following two labels. Take examples as references),→ 1. NOT_REQUIREMNET_OR_ALWAYS_SATISFIABLE_WITH_ONEOFF_ACTION: Use for items that do not determine patient--trial relevance. They're either not true eligibility requirements or can always be fulfilled by a simple, one-time action during prescreening. Do not treat these as inclusion/exclusion gates. ,→ ,→ - Example 1.1: Completing required paperwork (e.g., signing an updated informed-consent form or providing vaccination records) -- aka submitting missing documentation | finalising paperwork | providing proof of immunisation. ,→ ,→ - Example 1.2: Observing a short-term abstinence (e.g., avoiding alcohol for 24 h) aka temporary lifestyle adjustment | behavioural compliance | brief abstention.,→ - Example 1.3: Fasting as instructed before baseline assessments (e.g., $≥$ 8 h pre-test fast) -- aka observing protocol-mandated fast | undertaking required fasting | pre-lab fasting.,→ - Example 1.4: Attending a follow-up visit or screening procedure (e.g., receiving a booster injection, undergoing an ECG) -- aka returning for clinic visit | completing mandatory screening test | attending scheduled appointment. ,→ ,→ - Example 1.5: Initiating or adjusting contraception to meet study requirements -- aka beginning reliable contraception | starting birth-control regimen | implementing contraceptive measures.,→ - Example 1.6: Using or wearing a study-mandated device/app as instructed -- aka complying with device usage | adopting required study device | wearing activity tracker.,→ 2. OTHER_REQUIREMENTS: Requirements that used to determine patient-trial relevance. They cannot be fulfilled by a simple, one-time action during prescreening.,→ - Example 2.1: The patient is excluded if the patient has a history of treatment with any antimalarial drug, including at least one of the following: (chloroquine) OR (quinine) OR (mefloquine) OR (Malarone) OR (sulfadoxine-pyrimethamine) OR (artemisinin compounds), within two weeks prior to enrollment into the study. ,→ ,→ - Example 2.2: The patient is excluded if the patient is breastfeeding. # === GUIDELINES === 1. Note that we are ONLY interested in if an exclusion criterion can be turned from True (satisfied) to False (not satisfied); we never care about the other way around.,→ 2. After you label a component, explain why you made that labelling choice in the "reason" field. Use the following template for your explanation":,→ - "By doing [something] [some results] may occur, so the criterion can be turned from True to False". 3. Explicitly state what correction is required to turn a criterion from True to False in the "correction" field. If a component cannot be turned from satisfied to not satisfied, keep the field empty.,→ 4. Fill the label in the "label" field. 5. If the "correction" is related to medical interventions (e.g. treatement, medicine, etc.), it should NOT be labelled as NOT_REQUIREMNET_OR_ALWAYS_SATISFIABLE_WITH_ONEOFF_ACTION, because any medical-related correction is NOT simple oneoff action. ,→ ,→ 6. In "satisfied_meaning", state what it means for this requirement to be satisfied; In "not_satisfied_meaning", state what it means for this requirement to be not_satisfied; In "correctable_meaning", state what is means to go from "satisfied_meaning" to "not_satisfied_meaning". ,→ ,→ 124 Preprint. Under review. 7. Note that the constraint you assign to suspicion, possibility, clinical signs, and symptoms of a disease (or more generally, a finding) should be decided by the constraint you would assign to that disease. This is because having a disease (or a finding) ALWAYS implies having suspicion, possibility, clinical signs, and symptoms of a disease under our context. Reaching a concrete diagnosis of a disease/finding NEVER cancels the suspicion, possibility, clinical signs, or symptoms of it. Rather, it confirms these aspects. Therefore, it should NOT be categorized to "NOT_REQUIREMNET_OR_ALWAYS_SATISFIABLE_WITH_ACTION". ,→ ,→ ,→ ,→ ,→ 8. If the requirement is "having history of <disease/symptom/treatement>" without any time restrictions (such as within 2 weeks), this requirement should be categorized to "OTHER_REQUIREMENTS". Because a disease history or treatement history can NOT be undone by any action. Waiting for a period does NOT turn the fact of treatment history from true to false. ,→ ,→ ,→ 9. Evaluate action needed for correction by its difficulty in reality and ethical feasibility. Although some correction action is oneoff theoretically, they are not always satisfiable in reality (e.g. losing/gaining weight; getting married; abstain from drug use, etc.). Similarly, requirements such as breastfeeding and pregnancy should also be labeled under OTHER_REQUIREMENTS, since cessation is technically possible but ethically and practically infeasible for most participants. ,→ ,→ ,→ ,→ # === INPUT === <requirements> ##COMPONENTS_JSON## </requirements> # === OUTPUT (JSON only) === [ "requirement_index": 1, "components": [ "text": "<component>", "satisfied_meaning": "<satisfied_meaning>", "not_satisfied_meaning": "<not_satisfied_meaning>", "correctable_meaning": "how to go from <satisfied_meaning> to <not_satisfied_meaning>?", "label": "NOT_REQUIREMNET_OR_ALWAYS_SATISFIABLE_WITH_ACTION" | "OTHER_REQUIREMENTS" "reason": "<why>", "correction": "<action>" ] ] F.1.18 Entity Canonicalization: Free Entity Extraction Purpose.This prompt performs residual high-recall extraction to recover medically mean- ingful entity spans that were missed during initial canonicalization. Its purpose is to ensure that all constraint-relevant information is captured before downstream linking and filtering, since omissions at this stage cannot be recovered later and may lead to false negatives in retrieval or eligibility reasoning. # ROLE You are an expert in identifying medical entities from free text. # TASK Given a clinical trial criterion and a list of spans that are ALREADY canonicalized, extract additional spans that are: - CONTIGUOUS substrings of the criterion (no gaps, no re-ordering), - MOST-SPECIFIC when overlaps occur (keep the longest that best captures the concept), - MEANINGFUL to form constraints (e.g., qualifiers, attributes, values, sites, severity, temporal markers), - NON-OVERLAPPING with any of the ALREADY canonicalized spans. # RULES 1) Only include contiguous spans present verbatim in the criterion. 2) Resolve overlaps among your candidates by keeping the MOST-SPECIFIC (longest); output no overlaps. 3) Do NOT include spans that overlap any ALREADY canonicalized offsets. 4) No explanations, no extra keys, only a JSON array. # INPUT <criterion> CRITERION </criterion> <already_canonicalized> CANON_JSON </already_canonicalized> # OUTPUT FORMAT (JSON array only) Each item: "text": "<exact substring from criterion>", "offset": [START, END] // 0-based, END is exclusive; must match EXACTLY criterion[START:END] 125 Preprint. Under review. F.1.19 Entity Canonicalization: Primary High-Recall Mention Extractor Purpose.This prompt performs the primary high-recall extraction of medically meaningful entity mentions from clinical trial eligibility criteria. Its goal is to over-generate all plausible constraint-relevant spans, including overlapping candidates, to ensure that no clinically meaningful information is lost prior to ontology linking and downstream reasoning. # === ROLE === You are a Medical Entity Recognizer. Task: Our goal is to optimize for medical entity recognition recall. Place all medically relevant entity you recognize from clinical-trial eligibility criterion below into "entity_name" and record the contiguous span you recognized this entity from in "extracted_span". Then return ONLY a JSON array specifying the surface / text span of each entity and the explanation of what it (potentially) means as an entity. ,→ ,→ ,→ # === INPUT === <requirements> #REQ_JSON# </requirements> # === EXTRACTION RULES === 1. Our goal is to optimize for entity recognition recall. Identify as many entities as possible. 2. Again, our goal is to optimize for entity recognition recall. For situations under which multiple entities have overlapping text spans, extract all of them.,→ 3. Place all entity you recognize from text into "entity_name" and record the contiguous span you recognized this entity from in "extracted_span", exactly as the output format. The definition to entity is the smallest contiguous span needed to completely identify this identity. ,→ ,→ 4. If you know the concept name is in SMOWMED, then put down the snowmed concept as the entity name. 5. Medical entities we want to extract include but are not limited to drugs, procedures, symptoms, diseases, organisms, anatomy/body structure, events, specimen, and substance.,→ 6. For each extracted entity, explain what it potentially means as a medical entity. 7. Make sure that you keep the extracted entity surface AS IS. Do not modify, paraphrase, or abbreviate any extracted entity.,→ 8. Comparators (e.g., greater than, equal to) and numerical values should usually not appear in any extracted surface string unless they are necessary components of an entity name.,→ 8.a. e.g., from "Patients aged $≥$18 years and $≤$90 years presenting with dysphagia or presenting with food impaction.", we should not extract "Patients aged $≥$18 years and $≤$90 years" or "aged $≥$18 years"; rather, we should only extract "dysphagia" and "food impaction". ,→ ,→ 9. Phrases such as "diagnosis of", "patients with", "clinical suspicion of", "history of",``prior", "current", "in the future", and "ability to" are redundant information and do not help to form seperate meaninful entities.,→ 9.a. e.g., from requirement "Clinical diagnosis of hypertension.", we should only extract "hypertension", not "clinical diagnosis of hypertension".,→ 9.b. e.g., from requirement "Patients with the ability to undergo esophagogastroduodenoscopy and the ability to undergo esophageal biopsies.", we should not extract "Patients with the ability to undergo esophagogastroduodenoscopy", "ability to undergo esophagogastroduodenoscopy", or "ability to undergo esophageal biopsies"; instead, we should extract "esophagogastroduodenoscopy", "esophageal biopsies", and "biopsies". ,→ ,→ ,→ ,→ 9.c. e.g., from "Patients aged $≥$ 18 years of either sex.", you should extract nothing. e.g., from "Age of the patient is 65 years or older.", you should extract nothing.,→ 10. Do not extract anything sheerly related to gender, informed consent, study procedures, study restrictions, pregnancy status, ability to get pregnant, or voluntariness of participation.,→ 10.a., e.g., from requirement "Patient and/or patient's parents or patient's guardian signed an informed consent form.", you should extract nothing.,→ 11. Do not extract standalone obvious qualifiers (e.g., ECOG performance status, NYHA classes) 11.a., e.g., from "chronic heart failure classified as New York Heart Association class I", we should only extract "chronic heart failure" and "heart failure", not "New York Heart Association class I".,→ # === EXTRACTION EXAMPLES === <example_1> Input: <example_input> "Contradiction to esophagogastroduodenoscopy or contradiction to esophageal biopsies, such as presence of Boerhaave's syndrome, or history of bleeding disorder, or elevated international normalized ratio (INR).",→ </example_input> Identified Entities: <identified_medical_entities> [ "entity_name": "contradiction to esophagogastroduodenoscopy", "extracted_span": "Contradiction to esophagogastroduodenoscopy",,→ "entity_name": "esophagogastroduodenoscopy", "extracted_span": "esophagogastroduodenoscopy", "entity_name": "contradiction to esophageal biopsies", "extracted_span": "contradiction to esophageal biopsies",,→ "entity_name": "esophageal biopsy", "extracted_span": "esophageal biopsies", "entity_name": "biopsy", "extracted_span": "biopsies", "entity_name": "Boerhaave's syndrome", "extracted_span": "Boerhaave's syndrome", "entity_name": "bleeding disorder", "extracted_span": "bleeding disorder", "entity_name": "International Normalized Ratio raised", "extracted_span": "elevated international normalized ratio (INR)",,→ "entity_name": "International normalized ratio", "extracted_span": "international normalized ratio (INR)", 126 Preprint. Under review. ] </identified_medical_entities> </example_1> <example_2> Input: <example_input> "Clinical diagnosis of acute tonsillitis caused by Streptococcus pyogenes and clinical diagnosis of acute pharyngitis caused by Streptococcus pyogenes.",→ </example_input> Identified Entities: <identified_medical_entities> [ "entity_name": "Acute staphylococcal tonsillitis", "extracted_span": "acute tonsillitis caused by Streptococcus pyogenes",,→ "entity_name": "acute tonsillitis", "extracted_span": "acute tonsillitis", "entity_name": "tonsillitis", "extracted_span": "tonsillitis", "entity_name": "streptococcus pyogenes infection", "extracted_span": "Streptococcus pyogenes", "entity_name": "acute infective pharyngitis caused by Streptococcus", "extracted_span": "acute pharyngitis caused by Streptococcus pyogenes",,→ "entity_name": "acute pharyngitis", "extracted_span": "acute pharyngitis", "entity_name": "pharyngitis", "extracted_span": "pharyngitis" ] </identified_medical_entities> </example_2> <example_3> Input: <example_input> "Adequate liver function defined as serum bilirubin <1.5x upper level of normal (ULN), aspartate aminotransferase (AST) <2.5x ULN, and alanine aminotransferase (ALT) <3x ULN, with ULN defined as per institutional standard." ,→ ,→ </example_input> Identified Entities: <identified_medical_entities> [ "entity_name": "liver normal", "extracted_span": "Adequate liver function", "entity_name": "Serum bilirubin level", "extracted_span": "serum bilirubin", "entity_name": "bilirubin", "extracted_span": "bilirubin", "entity_name": "AST - aspartate transaminase", "extracted_span": "aspartate aminotransferase (AST)", "entity_name": "ALT - alanine aminotransferase", "extracted_span": "alanine aminotransferase (ALT)" ] </identified_medical_entities> </example_3> <example_4> Input: <example_input> "Patients with standard analytical parameters defined by: leukocyte count $≥$ 3000 cells/$μ$L, neutrophil count $≥$ 1500 cells/$μ$L, platelet count $≥$ 100,000 cells/$μ$L, aspartate aminotransferase (AST) level $≤$ 1.5 times the standard institutional range, alanine aminotransferase (ALT) level $≤$ 1.5 times the standard institutional range, and creatinine level $≤$ 1.5 mg/dL." ,→ ,→ ,→ </example_input> Identified Entities: <identified_medical_entities> [ "entity_name": "standard analytical parameters", "extracted_span": "standard analytical parameters", "entity_name": "white blood cell count", "extracted_span": "leukocyte count", "entity_name": "Leukocyte component of blood", "extracted_span": "leukocyte", "entity_name": "neutrophil count", "extracted_span": "neutrophil count", "entity_name": "platelet count", "extracted_span": "platelet count", "entity_name": "Platelet component of blood", "extracted_span": "platelet", "entity_name": "AST - aspartate transaminase", "extracted_span": "aspartate aminotransferase (AST)", "entity_name": "ALT - alanine aminotransferase", "extracted_span": "alanine aminotransferase (ALT)", "entity_name": "creatinine level", "extracted_span": "creatinine level", "entity_name": "creatinine", "extracted_span": "creatinine" ] </identified_medical_entities> </example_4> <example_5> Input: <example_input> "The results of the patient's pap smear showed positive human papillomavirus results (indicating the presence of human papillomavirus DNA in the cervical sample).",→ </example_input> Identified Entities: <identified_medical_entities> [ 127 Preprint. Under review. "entity_name": "pap smear", "extracted_span": "pap smear", "entity_name": "High risk human papillomavirus positive", "extracted_span": "positive human papillomavirus results",,→ "entity_name": "Human papillomavirus DNA", "extracted_span": "human papillomavirus DNA", "entity_name": "Human papillomavirus", "extracted_span": "human papillomavirus", ] </identified_medical_entities> </example_5> <example_6> Input: <example_input> "Male patients OR female patients." </example_input> Identified Entities (none!): <identified_medical_entities> [] </identified_medical_entities> </example_6> <example_7> Input: <example_input> "Clinical diagnosis of at least one risk factor, such as clinical diagnosis of diabetes, clinical diagnosis of smoking habit, clinical diagnosis of lipid metabolism abnormality, clinical diagnosis of history of ischemic heart disease (IHD), clinical diagnosis of history of cerebrovascular disease, clinical diagnosis of obesity with body mass index (BMI) > 25, clinical diagnosis of chronic heart failure classified as New York Heart Association (NYHA) class I or NYHA class I, or clinical diagnosis of electrocardiogram (ECG) abnormality showing left ventricular hypertrophy (LVH)." ,→ ,→ ,→ ,→ ,→ </example_input> Identified Entities (none!): <identified_medical_entities> [ "entity_name": "risk factor", "extracted_span": "risk factor", "entity_name": "diabetes", "extracted_span": "diabetes", "entity_name": "risk factor", "extracted_span": "risk factor", "entity_name": "smoking", "extracted_span": "smoking habit", "entity_name": "lipid metabolism disorder", "extracted_span": "lipid metabolism abnormality", "entity_name": "ischemic heart disease", "extracted_span": "ischemic heart disease (IHD)", "entity_name": "cerebrovascular disease", "extracted_span": "cerebrovascular disease", "entity_name": "obesity", "extracted_span": "obesity", "entity_name": "BMI - Body mass index", "extracted_span": "BMI", "entity_name": "chronic heart failure", "extracted_span": "chronic heart failure", "entity_name": "ECG abnormality showing left ventricular hypertrophy", "extracted_span": "ECG abnormality showing left ventricular hypertrophy",,→ "entity_name": "abnormal ECG", "extracted_span": "ECG abnormality", "entity_name": "left ventricular hypertrophy", "extracted_span": "left ventricular hypertrophy (LVH)", ] </identified_medical_entities> </example_7> <example_8> Input: <example_input> "Adults aged $≥$18 years weighing $≤$150 kg." </example_input> Identified Entities (none!): <identified_medical_entities> [] </identified_medical_entities> </example_8> <example_9> Input: <example_input> "The patient has positive urine protein." <example_input> Identified Entities (none!): <identified_medical_entities> [ "entity_name": "urine", "extracted_span": "urine", "entity_name": "protein", "extracted_span": "protein", "entity_name": "positive urine protein", "extracted_span": "positive urine protein", "entity_name": "urine protein", "extracted_span": "urine protein", ] </identified_medical_entities> </example_9> # === OUTPUT FORMAT === 128 Preprint. Under review. <identified_medical_entities> [ "index": 0, "requirement": "Clinical diagnosis of acute tonsillitis caused by Streptococcus pyogenes.", "entities": [ "entity_name": "Acute staphylococcal tonsillitis", "extracted_span": "acute tonsillitis caused by Streptococcus pyogenes",,→ "entity_name": "acute tonsillitis", "extracted_span": "acute tonsillitis", "entity_name": "tonsillitis", "extracted_span": "tonsillitis", "entity_name": "streptococcus pyogenes infection", "extracted_span": "Streptococcus pyogenes", ] ... ] </identified_medical_entities> F.1.20 Entity Canonicalization: Context-Aware Concept Reranker Purpose.This prompt performs context-sensitive concept disambiguation by selecting the single best-matching SNOMED concept for each extracted span. Its purpose is to ensure that each link preserves the exact meaning of the span in its local context, rejecting semantically related but incorrect candidates to avoid introducing erroneous structured representations into downstream reasoning. # === ROLE === You are a SNOMED concept linker. For EACH extracted span choose EXACTLY ONE best matching candidate, depending on its usage in criterion's context.,→ # === INPUT === <criterion> #CRITERION# </criterion> <candidates> #CANDIDATES# </candidates> # === GUIDELINES === 1. Do not drop any input entry! 2. You MUST copy the "offset" array you receive. Do **NOT** change the numbers. 3. You shall never link a query text span(extracted_span) to a concept that ((a. is of the type of observable entity) and (b. is not a numerical observable entity)). That is, if a concept satisfies both a. and b., never link to that concept. ,→ ,→ # === OUTPUT === JSON array: [ "entity_1": "extracted_span": "...", "entity_name": "...", "offset": [26, 33], "concept": "conceptId": "123456", "preferred_term": "...", "fully_specified_name": "...", "top_type": "Clinical finding" , ... ] F.1.21 Entity Canonicalization: Semantic Equivalence Verifier Purpose. This prompt verifies candidate SNOMED links by enforcing exact semantic equivalence between each extracted span and its linked concept in the local criterion context. Its purpose is to reject candidates that introduce, omit, or alter clinically relevant meaning, ensuring that only meaning-preserving links are passed to downstream selection and reasoning. # === ROLE === 129 Preprint. Under review. You are a SNOMED link auditor. # === RULE === Return "KEEP" if the concept's meaning is identical to the extracted span within the criterion context. Otherwise "REJECT". # === GUIDELINES === 1. Use the provided synonyms/definition only as background; do NOT echo them in the answer. 2. Note that we are linking to SNOMED nomenclature, so if a candidate means the same thing as the extracted span in the SNOMED context, we should keep the candidate.,→ 3. You should compare the meaning of the candidate to the extracted span, and you should disregard anything that accompanies the corresponding extracted span in the criterion. As long as the candidate means what the extracted span means in the criterion, keep it. ,→ ,→ 4. Every match is LOCAL! No candidate should attend to extracted spans that do not correspond to it. 5. Do not consider if there are more specific terms for a extracted span. Just focus on if the extracted span and the retrieved candidate match or not.,→ 6. COPY the "offset" array from the input pair unchanged; do NOT invent or drop it. 7. No information should be requried to be added or removed to match the extracted span with the linked term. For example, "heart failure" never means the same thing as "heart failure within the preceding six months". Therefore, drop all candidates which do not mean EXACTLY the same as the extract span (i.e., if we need to add/substract any qualifiers for the two parties to match, DROP!). ,→ ,→ ,→ 8. If the extracted span is "symptoms/diagnosis of disease" and the preferrerd term is the "disease", the decision is always REJECT. For example, "symptoms of laryngitis" does not mean "laryngitis".,→ 9. Note that two concepts are the same under our discussion if they are "close enough", meaning that the preferred term is a reasonable representation of the extracted_span/extracted_entity. Sometimes the SNOMED terminology (the concept we are linking to) may have slightly different meaning than what we are searching for. But you are already given the closest match in SNOMED. Keep it as long as they are reasonably the same thing. For example, "android obesity" is a reasonable entity match for "abdominal obesity" in SNOMED. ,→ ,→ ,→ ,→ # === INPUT === <criterion> #CRITERION# </criterion> <pairs> #PAIRS# </pairs> # Each object has: extracted_span, conceptId, preferred_term, # top_type, synonyms[], definition # === OUTPUT === JSON array: [ "extracted_span": "...", "entity_name": "...", "offset": [26, 33], "decision": "KEEP|REJECT", "preferred_term": "...", "synonyms": [ "...", "..." ], "definition": "...", "why": "" , ... ] F.1.22 Entity Canonicalization: Final Canonicalization Arbiter Purpose. This prompt performs final canonicalization by filtering candidate entity map- pings, resolving overlapping spans, enforcing schema and policy constraints, and selecting the most specific faithful representations. It also generates schema-aware variable names for each retained entity, producing a compact symbolic representation suitable for downstream logical reasoning. # === ROLE === You are a extracted span checker and variable-name generator (with SNOMED terminology knowledge). # === TASK === For each candidate object 1. Apply Rules 1-6: HAS_STRING_APPERANCE_IN_CRITERION_TEXT, BELONG_TO_ALLOWED_TYPES, IS_NOT_AGE_SEX_PREGNANCY_CONSENT_PERSONAL_RULE, CONTAINS_NO_CLASS_OR_STAGE_WORDS, EXTRACTED_SPAN_PREFERRED_TERM_SAME_THING, and IS_THE_MOST_SPECIFIC_MAPPED_TO_PHRASE_AMONG_ALL_OVERLAPPED_ENTRIES. ,→ ,→ ,→ 2. Attempt to build a variable_name according to NAMING CONVENTIONS and correspond to the entry's usage in criterion text (<criterion>). Build a variable_name that uses the preferred_term verbatim and,→ follows NAMING CONVENTIOS. If that succeeds, Rule 7 (CAN_BE_EXPRESSED_WITH_CORRESPONDING_NAMING_CONVENTIONS) = "YES"; else "NO". 3. keep = "YES" only if Rules 1-7 are all "YES". 130 Preprint. Under review. # === INPUT === <criterion> #CRITERION# </criterion> <candidate_objects> #STRINGS# </candidate_objects> # Each object has: extracted_span, preferred_term, type, offset (pair of integers) # === RULES === 1. HAS_STRING_APPERANCE_IN_CRITERION_TEXT: The extracted span or entity name appears in criterion text. 2. BELONG_TO_ALLOWED_TYPES: The mapped-to preferred term belong to one of the allowed top types: Clinical finding / Finding, Procedure, Observable entity, Substance, Product.,→ 3. IS_NOT_AGE_SEX_PREGNANCY_CONSENT_PERSONAL_RULE: Reject age / sex / pregnancy / consent / person-role terms. 4. CONTAINS_NO_CLASS_OR_STAGE_WORDS: If string contains class/stage words (NYHA, ECOG, GOLD, CCS, Child-Pugh, etc.) keep = NO unless the qualifier ALONE is required. 5. EXTRACTED_SPAN_PREFERRED_TERM_SAME_THING: The extracted span or entity name and the matched preferred term of this entry mean EXACTLY the same thing: no information added; no information lost.,→ 6. CAN_BE_EXPRESSED_WITH_CORRESPONDING_NAMING_CONVENTIONS -- we can express how the entry is being used in <criterion> (the criterion text) using our naming conventions (see NAMING CONVENTIONS section below); make sure to use the naming convention of the corresponding entity type! For example, findings should use the naming conventions of clinical findings. ,→ ,→ ,→ 7. IS_THE_MOST_SPECIFIC_MAPPED_TO_PHRASE_AMONG_ALL_VALID_OVERLAPPED_ENTRIES: Among all entries overlapping with this entry's extracted span whose preferred terms mean the same thing as their extracted spans, this extracted span and mapped preferred term are the most specific (COMPARE WITH OTHER ENTRIES THAT HAVE OVERLAPPING OFFSETS!). ,→ ,→ ,→ 8. IS_THE_MOST_SPECIFIC_MAPPED_TO_PHRASE_AMONG_ALL_OVERLAPPED_ENTRIES: First list ONLY the extracted spans that (a) overlap AND (b) are all-YES on rules 1-6 above in "ALL_VALID_OVERLAPPED_EXTRACTED_SPANS". Among all entries overlapping with this entry's extracted span and are valid, this extracted span and mapped preferred term are the most specific (COMPARE WITH OTHER ENTRIES THAT HAVE OVERLAPPING OFFSETS AND ARE VALID!). ,→ ,→ ,→ 9. Note that two concepts are the same under our discussion if they are "close enough", meaning that the preferred term is a reasonable representation of the extracted_span/extracted_entity. Sometimes the SNOMED terminology (the concept we are linking to) may have slightly different meaning than what we are searching for. But you are already given the closest match in SNOMED. Keep it as long as they are reasonably the same thing. For example, "android obesity" is a reasonable entity match for "abdominal obesity" in SNOMED. ,→ ,→ ,→ ,→ # === ADDITIONAL GUIDELINES === COPY the "offset" array from the input object unchanged; do NOT invent or drop it. === NAMING SYSTEM / NAMING TEMPLATES === Stems (lowercase snake_case; strip punctuation; numerals normalized). The timeframe token MUST appear exactly once inside the stem and match the "timeframe" field.,→ <stems_templates> Finding: <stems_templates::findings> patient_has_diagnosis_of_entity_canonical_form_timeframe | patient_has_finding_of_entity_canonical_form_timeframe | patient_has_symptoms_of_entity_canonical_form_timeframe | patient_has_clinical_signs_of_entity_canonical_form_timeframe | patient_has_suspicion_of_entity_canonical_form_timeframe </stems_templates::findings> Procedure: <stems_templates::procedures> patient_has_undergone_entity_canonical_form_timeframe | patient_has_undergone_entity_canonical_form_timeframe_outcome_is_positive | patient_has_undergone_entity_canonical_form_timeframe_outcome_is_negative | patient_has_undergone_entity_canonical_form_timeframe_outcome_is_normal | patient_has_undergone_entity_canonical_form_timeframe_outcome_is_abnormal | patient_is_undergoing_entity_canonical_form_timeframe | patient_needs_to_undergo_entity_canonical_form_timeframe | patient_will_undergo_entity_canonical_form_timeframe | patient_can_undergo_entity_canonical_form_timeframe | </stems_templates::procedures> Observable Entities (numeric): <stems_templates::observable_entities_numeric> patient_entity_canonical_form_value_recorded_timeframe_withunit_unit </stems_templates::observable_entities_numeric> Product: <stems_templates::product> patient_is_taking_entity_canonical_form_timeframe | patient_has_taken_entity_canonical_form_timeframe | patient_has_hypersensitivity_to_entity_canonical_form_timeframe | 131 Preprint. Under review. patient_has_intolerance_to_entity_canonical_form_timeframe | patient_has_allergy_to_entity_canonical_form_timeframe | patient_has_nonimmune_hypersensitivity_to_entity_canonical_form_timeframe | </stems_templates::product> Substance: <stems_templates::substance> patient_is_exposed_to_entity_canonical_form_timeframe | patient_has_hypersensitivity_to_entity_canonical_form_timeframe | patient_has_intolerance_to_entity_canonical_form_timeframe | patient_has_allergy_to_entity_canonical_form_timeframe | patient_has_nonimmune_hypersensitivity_to_entity_canonical_form_timeframe | </stems_templates::substance> </stems_templates> <timeframe> Timeframe : now | inthehistory | inthefuture | inthepastnunits | inthefuturenunits | foradurationofnunits,→ Time Units: minutes | hours | days | weeks | months | years </timeframe> <qualifiers> Attach with: stem@@qualifier_snake_case Qualifiers must NOT repeat timeframe/value/unit; they encode leftover semantics (e.g., temporal anchors other than``today′, context like``at baseline′, or dependencies like``after percutaneous coronary intervention′). Use qualifiers sparingly and ONLY when needed for later assertions. ,→ ,→ </qualifiers> # === EXAMPLE === <example_input> <example_criterion> To be included, the patient must have (an elevated total peripheral white blood cell count > 10,000/m$^3$) OR (> 15%,→ </example_criterion> <example_candidate_objects> [ "extracted_span": "elevated total peripheral white blood cell count", "offset": [42, 90], "preferred_term": "Increased blood leukocyte number", "type": "Clinical finding" , "extracted_span": "total peripheral white blood cell count", "offset": [51, 90], "preferred_term": "Total white blood count", "type": "Procedure" , "extracted_span": "white blood cell count", "offset": [68, 90], "preferred_term": "White blood cell count", "type": "Procedure" , "extracted_span": "total peripheral white blood cell count", "offset": [159, 198], "preferred_term": "Total white blood count", "type": "Procedure" , "extracted_span": "white blood cell count", "offset": [176, 198], "preferred_term": "White blood cell count", "type": "Procedure" , "extracted_span": "total peripheral white blood cell count", "offset": [220, 259], "preferred_term": "Total white blood count", "type": "Procedure" , "extracted_span": "white blood cell count", "offset": [237, 259], "preferred_term": "White blood cell count", "type": "Procedure" , 132 Preprint. Under review. "extracted_span": "immature neutrophils (bands)", "offset": [115, 143], "preferred_term": "Neutrophil band count", "type": "Procedure" , "extracted_span": "leukopenia", "offset": [204, 214], "preferred_term": "Decreased blood leukocyte number", "type": "Clinical finding" ] </example_candidate_objects> </example_input> <example_output> [ "extracted_span": "elevated total peripheral white blood cell count", "offset": [42, 90], "preferred_term": "Increased blood leukocyte number", "HAS_STRING_APPERANCE_IN_CRITERION_TEXT": "YES", "BELONG_TO_ALLOWED_TYPES": "YES", "IS_NOT_AGE_SEX_PREGNANCY_CONSENT_PERSONAL_RULE": "YES", "CONTAINS_NO_CLASS_OR_STAGE_WORDS": "YES", "EXTRACTED_SPAN_PREFERRED_TERM_SAME_THING": "YES", "variable_name": "has_finding_of_increased_blood_leukocyte_number_now", "CAN_BE_EXPRESSED_WITH_CORRESPONDING_NAMING_CONVENTIONS": "YES", "ALL_VALID_OVERLAPPED_EXTRACTED_SPANS": ["total peripheral white blood cell count", "white blood cell count"], "IS_THE_MOST_SPECIFIC_MAPPED_TO_PHRASE_AMONG_ALL_VALID_OVERLAPPED_ENTRIES": "YES", "keep": "YES", "why": "Abnormal finding (elevated WBC) is more specific than overlapping generic test mentions." , "extracted_span": "total peripheral white blood cell count", "offset": [51, 90], "preferred_term": "Total white blood count", "HAS_STRING_APPERANCE_IN_CRITERION_TEXT": "YES", "BELONG_TO_ALLOWED_TYPES": "YES", "IS_NOT_AGE_SEX_PREGNANCY_CONSENT_PERSONAL_RULE": "YES", "CONTAINS_NO_CLASS_OR_STAGE_WORDS": "YES", "EXTRACTED_SPAN_PREFERRED_TERM_SAME_THING": "YES", "variable_name": "has_undergone_total_white_blood_count_now", "CAN_BE_EXPRESSED_WITH_CORRESPONDING_NAMING_CONVENTIONS": "YES", "ALL_VALID_OVERLAPPED_EXTRACTED_SPANS": ["elevated total peripheral white blood cell count", "white blood cell count"],,→ "IS_THE_MOST_SPECIFIC_MAPPED_TO_PHRASE_AMONG_ALL_VALID_OVERLAPPED_ENTRIES": "NO", "keep": "NO", "why": "Overlapped and less specific than the abnormal finding mention." , "extracted_span": "white blood cell count", "offset": [68, 90], "preferred_term": "White blood cell count", "HAS_STRING_APPERANCE_IN_CRITERION_TEXT": "YES", "BELONG_TO_ALLOWED_TYPES": "YES", "IS_NOT_AGE_SEX_PREGNANCY_CONSENT_PERSONAL_RULE": "YES", "CONTAINS_NO_CLASS_OR_STAGE_WORDS": "YES", "EXTRACTED_SPAN_PREFERRED_TERM_SAME_THING": "YES", "variable_name": "has_undergone_white_blood_cell_count_now", "CAN_BE_EXPRESSED_WITH_CORRESPONDING_NAMING_CONVENTIONS": "YES", "ALL_VALID_OVERLAPPED_EXTRACTED_SPANS": ["elevated total peripheral white blood cell count", "total peripheral white blood cell count"],,→ "IS_THE_MOST_SPECIFIC_MAPPED_TO_PHRASE_AMONG_ALL_VALID_OVERLAPPED_ENTRIES": "NO", "keep": "NO", "why": "Generic test mention; less specific than the overlapping abnormal finding." , "extracted_span": "total peripheral white blood cell count", "offset": [159, 198], "preferred_term": "Total white blood count", "HAS_STRING_APPERANCE_IN_CRITERION_TEXT": "YES", "BELONG_TO_ALLOWED_TYPES": "YES", "IS_NOT_AGE_SEX_PREGNANCY_CONSENT_PERSONAL_RULE": "YES", "CONTAINS_NO_CLASS_OR_STAGE_WORDS": "YES", "EXTRACTED_SPAN_PREFERRED_TERM_SAME_THING": "YES", "variable_name": "has_undergone_total_white_blood_count_now", "CAN_BE_EXPRESSED_WITH_CORRESPONDING_NAMING_CONVENTIONS": "YES", "ALL_VALID_OVERLAPPED_EXTRACTED_SPANS": ["white blood cell count"], "IS_THE_MOST_SPECIFIC_MAPPED_TO_PHRASE_AMONG_ALL_VALID_OVERLAPPED_ENTRIES": "YES", "keep": "YES", "why": "More specific than overlapping generic'white blood cell count' at this location." 133 Preprint. Under review. , "extracted_span": "white blood cell count", "offset": [176, 198], "preferred_term": "White blood cell count", "HAS_STRING_APPERANCE_IN_CRITERION_TEXT": "YES", "BELONG_TO_ALLOWED_TYPES": "YES", "IS_NOT_AGE_SEX_PREGNANCY_CONSENT_PERSONAL_RULE": "YES", "CONTAINS_NO_CLASS_OR_STAGE_WORDS": "YES", "EXTRACTED_SPAN_PREFERRED_TERM_SAME_THING": "YES", "variable_name": "has_undergone_white_blood_cell_count_now", "CAN_BE_EXPRESSED_WITH_CORRESPONDING_NAMING_CONVENTIONS": "YES", "ALL_VALID_OVERLAPPED_EXTRACTED_SPANS": ["total peripheral white blood cell count"], "IS_THE_MOST_SPECIFIC_MAPPED_TO_PHRASE_AMONG_ALL_VALID_OVERLAPPED_ENTRIES": "NO", "keep": "NO", "why": "Less specific than'total peripheral white blood cell count' in the same span range." , "extracted_span": "total peripheral white blood cell count", "offset": [220, 259], "preferred_term": "Total white blood count", "HAS_STRING_APPERANCE_IN_CRITERION_TEXT": "YES", "BELONG_TO_ALLOWED_TYPES": "YES", "IS_NOT_AGE_SEX_PREGNANCY_CONSENT_PERSONAL_RULE": "YES", "CONTAINS_NO_CLASS_OR_STAGE_WORDS": "YES", "EXTRACTED_SPAN_PREFERRED_TERM_SAME_THING": "YES", "variable_name": "has_undergone_total_white_blood_count_now", "CAN_BE_EXPRESSED_WITH_CORRESPONDING_NAMING_CONVENTIONS": "YES", "ALL_VALID_OVERLAPPED_EXTRACTED_SPANS": ["white blood cell count"], "IS_THE_MOST_SPECIFIC_MAPPED_TO_PHRASE_AMONG_ALL_VALID_OVERLAPPED_ENTRIES": "YES", "keep": "YES", "why": "More specific than overlapping'white blood cell count' for the leukopenia clause." , "extracted_span": "white blood cell count", "offset": [237, 259], "preferred_term": "White blood cell count", "HAS_STRING_APPERANCE_IN_CRITERION_TEXT": "YES", "BELONG_TO_ALLOWED_TYPES": "YES", "IS_NOT_AGE_SEX_PREGNANCY_CONSENT_PERSONAL_RULE": "YES", "CONTAINS_NO_CLASS_OR_STAGE_WORDS": "YES", "EXTRACTED_SPAN_PREFERRED_TERM_SAME_THING": "YES", "variable_name": "has_undergone_white_blood_cell_count_now", "CAN_BE_EXPRESSED_WITH_CORRESPONDING_NAMING_CONVENTIONS": "YES", "ALL_VALID_OVERLAPPED_EXTRACTED_SPANS": ["total peripheral white blood cell count"], "IS_THE_MOST_SPECIFIC_MAPPED_TO_PHRASE_AMONG_ALL_VALID_OVERLAPPED_ENTRIES": "NO", "keep": "NO", "why": "Less specific than overlapping'total peripheral white blood cell count'." , "extracted_span": "immature neutrophils (bands)", "offset": [115, 143], "preferred_term": "Neutrophil band count", "HAS_STRING_APPERANCE_IN_CRITERION_TEXT": "YES", "BELONG_TO_ALLOWED_TYPES": "YES", "IS_NOT_AGE_SEX_PREGNANCY_CONSENT_PERSONAL_RULE": "YES", "CONTAINS_NO_CLASS_OR_STAGE_WORDS": "YES", "EXTRACTED_SPAN_PREFERRED_TERM_SAME_THING": "YES", "variable_name": "has_undergone_neutrophil_band_count_now", "CAN_BE_EXPRESSED_WITH_CORRESPONDING_NAMING_CONVENTIONS": "YES", "ALL_VALID_OVERLAPPED_EXTRACTED_SPANS": [], "IS_THE_MOST_SPECIFIC_MAPPED_TO_PHRASE_AMONG_ALL_VALID_OVERLAPPED_ENTRIES": "YES", "keep": "YES", "why": "Directly names the test for band neutrophils; no valid overlaps." , "extracted_span": "leukopenia", "offset": [204, 214], "preferred_term": "Decreased blood leukocyte number", "HAS_STRING_APPERANCE_IN_CRITERION_TEXT": "YES", "BELONG_TO_ALLOWED_TYPES": "YES", "IS_NOT_AGE_SEX_PREGNANCY_CONSENT_PERSONAL_RULE": "YES", "CONTAINS_NO_CLASS_OR_STAGE_WORDS": "YES", "EXTRACTED_SPAN_PREFERRED_TERM_SAME_THING": "YES", "variable_name": "has_finding_of_decreased_blood_leukocyte_number_now", "CAN_BE_EXPRESSED_WITH_CORRESPONDING_NAMING_CONVENTIONS": "YES", "ALL_VALID_OVERLAPPED_EXTRACTED_SPANS": [], "IS_THE_MOST_SPECIFIC_MAPPED_TO_PHRASE_AMONG_ALL_VALID_OVERLAPPED_ENTRIES": "YES", "keep": "YES", "why": "Clinical finding encoding low WBC; stands alone without overlaps." ] </example_output> 134 Preprint. Under review. # === OUTPUT === Return ONLY a JSON array: [ "extracted_span": "...", "entity_name": "...", "offset": [..., ...], "preferred_term": "...", "HAS_STRING_APPERANCE_IN_CRITERION_TEXT": "YES" | "NO", "BELONG_TO_ALLOWED_TYPES": "YES" | "NO", "IS_NOT_AGE_SEX_PREGNANCY_CONSENT_PERSONAL_RULE": "YES" | "NO", "CONTAINS_NO_CLASS_OR_STAGE_WORDS": "YES" | "NO", "EXTRACTED_SPAN_PREFERRED_TERM_SAME_THING": "YES" | "NO", "variable_name": "patientHasFindingHeartFailureHistory", "CAN_BE_EXPRESSED_WITH_CORRESPONDING_NAMING_CONVENTIONS": "YES" | "NO", "ALL_VALID_OVERLAPPED_EXTRACTED_SPANS": [/* list ONLY the extracted spans that (a) overlap AND (b) are all-YES on rules above */],,→ "IS_THE_MOST_SPECIFIC_MAPPED_TO_PHRASE_AMONG_ALL_VALID_OVERLAPPED_ENTRIES": "YES" | "NO", "keep": "YES" | "NO", "why": "...explain..." , ... ] F.1.23 SMTProgrammer: Free Entity Extractor Purpose. This prompt identifies medically relevant entities in each eligibility criterion that were not captured by earlier extraction steps. Its goal is to recover meaningful clinical concepts that would otherwise be missed, ensuring that important information is not lost before SMT translation. # === ROLE === You are an expert in identifying medical entities from free text. # === TASK === Given multiple clinical trial criteria and, for each one, a list of spans that are ALREADY captured, identify ALL OTHER medically relevant entities that are present in each criterion. # === INPUT FORMAT === A JSON array of objects with fields: - "id": an INTEGER requirement index (use this value verbatim in your output keys). - "criterion": the criterion free text. This is where you should be extracting the entities from. - "already_captured": a JSON array of strings that are already captured. These are the already captured medical entities that you should never repeat or have new extracted medical entities overlapping with.,→ # === INPUT === ITEMS_JSON # === GUIDELINES === 1. Never extract any entity that overlaps with already_captured medical entities. 2. We want medically relevant entities, not qualifiers. 3. When recognizing entities, strip out qualifiers/comparators/numbers; return only the noun entity. 4. Do not include standalone severity/stages/phases (e.g., "stage cT1N+", "M0", "cT2-4a", "N0", "N+", TNM categories).,→ 5. Every returned string MUST be an exact substring of the corresponding "criterion" text (verbatim match). 6. Deduplicate results per criterion and keep only the most specific forms (drop strict substrings of other returned entities).,→ # === OUTPUT FORMAT (JSON object only) === Return a single JSON object mapping each input id to a JSON array of strings. - Keys MUST match the input "id" values (use JSON string keys of those integers). - If no entities are found for an id, map it to an empty array []. - No explanations or extra keys. Example: "0": ["entity span 1", "entity span 2"], "1": [] F.1.24 SMTProgrammer: Free Entity Qualifier Identifier Purpose. This prompt identifies constraint phrases attached to each medical entity in a requirement. These constraints specify how the entity is restricted in context (e.g., time, 135 Preprint. Under review. location, severity, or cause), ensuring that the entityâ ̆ A ́ Zs meaning is fully captured before translation into SMT. === ROLE === You are a clinical NLP annotator. Task: The input is A <requirement_entity_list> including a trial eligibility criterion requirement and a pre-identified list of medical entities (subject) in the criterion.,→ The output is a single JSON object. For each entity in the requirement, include only those qualifiers that are necessary, mutually exclusive, and self-contained, and that directly and unambiguously narrow that entity's scope as specified by the requirement. ,→ ,→ Goal: This step is part of an LLM-based pipeline that encodes requirement text into SMT assertions using logical propositions and SNOMED nomenclature (for entities and qualifiers). At this stage, extract only those qualifiers that are necessary to precisely constrain the referenced entity so its representation captures the full, context-specific meaning. Include a qualifier only if it directly and unambiguously narrows the entity's scope---i.e., it filters which instances of the entity are admissible. ,→ ,→ ,→ ,→ === INPUT === <requirement_entity_list> requirement_entities </requirement_entity_list> === GUIDELINES === 1. Extract only those qualifiers that directly and unambiguously narrow the scope of the referenced entity. 1.1 The referenced entity can be located using entity's "start" and "end" offsets from each entity's json object. Extract qualifiers only for that specific occurrence. Don't extract qualifiers for any other occurrence of the same wording at different offsets at this stage. ,→ ,→ 1.2 For each referenced entity, extract qualifiers across seven perspectives: Time, Space, Cause, Scale, Source, Definition and Other.,→ 1.2.1 Each qualifier should have self-contained meaning. If the qualifier has multiple internally dependent parts, keep it together as one qualifier. If the qualifier consists of multiple parts that are independent of each other, separate them into multiple qualifiers.,→ 1.2.2 If a modifier is already embedded within the entity's extracted_span, do not extract it again as a qualifier; only capture modifiers that occur outside the entity's extracted_span.,→ 1.3 For every qualifier, output: a standalone sentence in the form "<Entity> has constraints that … ", a qualifier_span: copy the evidence verbatim from the source text. Spans need not be contiguous; if multiple fragments are indeed required, list them in order of appearance, separated by semicolons (;).; ,→ ,→ a rationale that explains how the span narrows the entity's scope. 2. Seven Perspectives for Entity-Scoped Qualifier Extraction 2.1 Time (entity-bound temporality) Definition: Specifies when the entity itself occurs/exists (time point or window). If the time window depends on an anchor event, the anchor must be included in the qualifier to make the qualifier self-contained.,→ <Example> requirement:``The patient is excluded if the patient has (ischemic heart disease within 6 months after percutaneous coronary intervention).′,→ entity:``ischemic heart disease′ qualifier:``Ischemic heart disease has constraints that it occurred within 6 months after percutaneous coronary intervention.′,→ qualifier_span:``within 6 months after percutaneous coronary intervention′ </Example> 2.2 Space (anatomy / laterality / site) Definition: Constrains where the entity is located (anatomic site, extent, or laterality). <Example> requirement:``pulmonary infiltrate in the left lower lobe′ entity:``pulmonary infiltrate′ qualifier:``Pulmonary infiltrate has constraints that it is located in the left lower lobe.′ qualifier_span:``in the left lower lobe′ </Example> 2.3 Cause (etiology) Definition: Constrains the cause or etiology of the entity. <Example> requirement:``The patient is excluded if the patient has fever due to non-infectious diseases (such as rheumatic autoimmune disease).′,→ entity:``fever′ qualifier:``Fever has constraints that it is caused by non-infectious diseases.′ qualifier_span:``due to non-infectious diseases′ </Example> 2.4 Scale (severity / grade / stage / course / status) Definition: Constrains the entity's intensity, grade, stage, status, clinical course(e.g., major, severe, Grade $≥$2, cT2--4a, acute, recurrent, suspected, stable).,→ <Example> requirement:``The patient is excluded if the patient has major cardiovascular disease.′ 136 Preprint. Under review. entity:``cardiovascular disease′ qualifier:``Cardiovascular disease has constraints that it is major.′ qualifier_span:``major′ </Example> <Example> requirement:``The patient is excluded if the patient has ischemic heart disease and is stable but is going to implement percutaneous coronary intervention.′,→ entity:``ischemic heart disease′ qualifier:``Ischemic heart disease has constraints that it is stable.′ qualifier_span:``is stable′ </Example> 2.5 Source (finding method / measurement method / definition system) Definition: Constrains how the entity is confirmed or measured, and/or the definition/grading system used. 2.6 Definition Clauses that defines, confirms or diagnose an entity, such as measurement, test result (e.g., lab/vital/sign/score thresholds,``defined as/diagnosed if/meeting criteria …′).,→ 2.7 Other Definition: Any other qualifier that truly reduces the entity's scope but does not fit the six categories above. Include only clearly restrictive modifiers of the entity. If you are not sure whether a qualifier narrows the scope of the entity, still keep it. ,→ ,→ <Example> requirement:``The patient is excluded if the patient has (specific systemic diseases) OR (other medical conditions) that would interfere with the evaluation of the therapeutic response or safety of the study drug.′,→ entity:``systemic diseases′ Not a qualifier_span:``specific′ (content-empty here; does not constrain which systemic diseases). Valid qualifier_span:``that would interfere with the evaluation of the therapeutic response or safety of the study drug′ --- this restrictive clause filters which systemic diseases are relevant.,→ qualifier:``Systemic diseases have constraints that they would interfere with the evaluation of the therapeutic response or safety of the study drug.′,→ qualifier_span:``that would interfere with the evaluation of the therapeutic response or safety of the study drug′,→ </Example> 3. You are not required to find a qualifier for every category. Extract a qualifier only when it truly narrows the entity. If a category has no qualifier, output an empty array for that category (e.g., "Time": []).,→ 4. If a candidate qualifier could belong to multiple categories, assign it to the single best-fitting category only. Do not duplicate the same qualifier across categories.,→ 5. Even if a qualifier will be captured by other assertions, still include it!!! For example, if a trial asks for "abdominal obesity" but the "abdominal" part is also defined by waist size by some numerical measures, and we have the entity "obesity", still include "abdominal" as a qualifier of "obesity". ,→ ,→ <Example> requirement:``To be included, the patient must have abdominal obesity (waist circumference cut-off depending on the recently published ethnic-based variations).′,→ entity:``obesity′ qualifier:``must have abdominal obesity.′ qualifier_span:``abdominal′ </Example> === WHAT YOU SHOULD NOT TREAT AS QUALIFIER === 1. Do not capture any phrase that is already inside the entity's own extracted_span as qualifier_span. If a modifying word is embedded in the entity surface (e.g.,``reversible′ in``reversible ischemic changes′), treat it as part of the entity, not a qualifier. ,→ ,→ === OUTPUT === Return one JSON array (no Markdown, no extra keys). If a category has no qualifier, output an empty array for that category (e.g., "Time": []). Follow exactly this schema (key names and order): "requirement_id": <copy verbatim from input>, "requirement": <copy verbatim from input>, "entities": [ "entity_id": <copy verbatim from input>, "extracted_span": <copy verbatim from input>, "start": <copy verbatim from input>, "end": <copy verbatim from input>, "type": <copy verbatim from input>, "Time": [ "qualifier":"<Entity> has constraints that … ", "qualifier_span": <copy the evidence verbatim from the source text. Spans need not be contiguous; if multiple fragments are required, list them in order of appearance, separated by semicolons (;).>,,→ "rationale": <how the span narrows the entity's scope>, , //...repeat for more than one qualifier under this category ], "Space": [ 137 Preprint. Under review. "qualifier":"<Entity> has constraints that … ", "qualifier_span": "rationale": <how the span narrows the entity's scope>, , //... ], "Scale": [ "qualifier":"<Entity> has constraints that … ", "qualifier_span": "rationale": <how the span narrows the entity's scope>, , //... ], "Source": [ "qualifier":"<Entity> has constraints that … ", "qualifier_span": "rationale": <how the span narrows the entity's scope>, , //... ], "Cause": [ "qualifier":"<Entity> has constraints that … ", "qualifier_span": "rationale": <how the span narrows the entity's scope>, , //... ], "Definition": [ "qualifier":"<Entity> has constraints that … ", "qualifier_span": "rationale": <how the span narrows the entity's scope>, , //... ], "Other": [ "qualifier":"<Entity> has constraints that … ", "qualifier_span": "rationale": <how the span narrows the entity's scope>, , //... ], , //...repeat for other entities in the requirement ] , F.1.25 SMTProgrammer Free Entity Qualifier Identifier Checker Purpose.This prompt checks whether each extracted constraint correctly and meaningfully restricts the referenced entity. It verifies that the constraint truly narrows the entityâ ̆ A ́ Zs scope, is attached to the correct entity, and does not simply restate inherent properties or unrelated context. === ROLE === You are an expert in analyzing qualifer-entity relations in the medical domain. Your task is to check if the extraction of qualifiers for entities in a clinical trial eligibility criteria text are correct and really narrowing the scope of the entity, sometimes the qualifier is just a fact or inherent property of the entity. ,→ ,→ === INPUT === <requirement_entity_qualifiers> #REQUIREMENT_ENTITY_QUALIFIER# <requirement_entity_qualifiers> === CHECKLIST === For each extracted qualifier, check if: 1. SELFCONTAINED: It depends on NO other extracted qualifier to recover its meaning in the criterion requirement. That is, it is a self-contained qualifier that standalone narrows the entity counts.,→ 2. qualified_entity: the referenced entity constrained by the qualifier span (i.e., entity $ $ qualifier), expressed as a self-contained noun phrase.,→ 138 Preprint. Under review. 3. QUALIFIED_ENTITY_REFERENCED_ENTITY_IS_SAME_ENTITY_UNDER_DIFFERENT_SCOPE: The qualified_entity preserves the ontological identity of the referenced entity (same type/class); the qualifier only adds scope constraints (time, site, laterality, stage, severity, subtype, dose/formulation, etc.) without changing the entity into a different concept (e.g., a condition, relation, or meta-fact). ,→ ,→ ,→ YES:``pneumonia′ $→$``pneumonia during hospitalization′;``biopsy′ $→$``liver biopsy′.,→ NO:``EGD (procedure)′ $→$``contraindication to EGD′ (becomes a contraindication fact, not the procedure).,→ 4. QUALIFIED_ENTITY_NARROWER_THEN_REFERENCED_ENTITY: The qualified_entity is a proper subset of the referenced entity's denotation set: every instance of the qualified_entity is an instance of the referenced entity, and not all instances of the referenced entity satisfy the qualifier. ,→ ,→ 5. QUALIFIER_IS_NOT_AN_INHERENT_PROPERTY_OF_ENTITY: Decide whether a candidate qualifier truly adds new, narrowing information about the entity, rather than restating something already true of every instance of that entity (or already guaranteed by the requirement's context). Mark YES iff the qualifier is not (a) intrinsic to the entity type, and not (b) entailed by the requirement context. ,→ ,→ ,→ For example, the requirement declares a category with property P and then enumerates items; each item inherits P by construction. Adding P to any item does not shrink its denotation.,→ NO: The patient is excluded if the patient requires treatment with at least one of the following during the study that might interfere with the evaluation of the study drug: (nelfinavir), (digoxin), (ergot alkaloids). ,→ ,→ entity: nelfinavir, qualifier span: might interfere with the evaluation of the study drug. Why: The clause modifies the list header; by membership, each listed item already satisfies this property. Adding it to nelfinavir does not narrow its scope. ,→ ,→ YES: the patient must have histologically verified adenocarcinoma of the esophagus (according to the Union for International Cancer Control (UICC) definition, Tumor Node Metastasis (TNM) classification, 7th edition).,→ entity: adenocarcinoma of the esophagus qualifier span: histologically verified. Not every adenocarcinoma case in practice is histologically verified (could be suspected/pending). Counterexample exists $→$ YES.,→ qualifier span: according to UICC TNM7. The edition is not intrinsic to the disease; some trials use AJCC 8th, TNM 8th, etc. Counterexample exists $→$ YES.,→ 6. MAKE_ENTITY_SCOPE_MORE_SPECIFIC: The qualifier narrowly constrains the entity rather than merely describe the entity's intrinsic property/fact so it matches how the requirement expresses it---i.e., it reduces the entity's denotation set (via site, laterality, stage, severity, timing, subtype, dose/formulation). ,→ ,→ 7. TARGETS_THIS_ENTITY: The qualifier must unambiguously modify the current entity mention, not the patient or another entity in the sentence. Reject qualifiers whose syntactic head attaches to a different entity.,→ 8. CORRECT: The qualifier is correct - the parsing/paraphrasing of the qualifier gives exactly the same information (nothing added, nothing dropped, nothing tweaked) as the qualifer embedded in the original requirement text.,→ 9. NOT_IN_ENTITY_SURFACE_STRING: This qualifier is not already embedded in the entity surface string itself. That is, it adds information to the entity to narrow down its scope.,→ 10. NOT_GENERIC_RELATIONSHIP: The qualifier is not for generic relationship or container phrase that links the patient to the medical concept but does not describe a property of the entity itself. (Examples of phrases to exclude:``clinical diagnosis of′,``symptoms of′,``evidence of′,``history of′,``signs of′.) ,→ ,→ 11. NOT_EXAMPLES_TO_ILLUSTRATE_ENTITY: The qualifier is not merely introduced examples for an entity. If the qualifier span is behind triggers including, such as, like, for example, for instance, do not capture it as qualifier_span. For example,``A, including B, C, and D′, Do not capture "B", "C", and "D′ as a qualifier_span for A. ,→ ,→ ,→ 12. NOT_SUPERCLASS_AS_QUALIFIER_FOR_EXAMPLE: The qualifier must not be a superclass/category that merely introduces the entity as an example. If a qualifier is the noun phrase before triggers like including, such as, like, for example, mark "NO". ,→ ,→ NO: infection of the deep tissues of the upper respiratory tract, including epiglottitis …, entity: epiglottitis, qualfier: of the deep tissues of the upper respiratory tract 13. NOT_A_DEFINITION_QUALIFIER: Mark a span as a definition qualifier only if it contains an explicit definitional/confirmation trigger (e.g.,``defined as,′``confirmed by,′``diagnosed when,′ ``meets/satisfies criteria′) and an operational measurement element (e.g., a numeric comparator or range with units, or a named scale threshold). ,→ ,→ ,→ NO: Requirement: "The patient is excluded if the patient has severe renal impairment (defined as serum creatinine greater than 3.0 mg/dl).",→ Entity: renal impairment Qualifier_span: "defined as serum creatinine greater than 3.0 mg/dl" Make a final judgement in "ALL_GOOD": - "YES" if **all** checklist items are "YES" - "NO" if **any** checklist item is "NO" If "ALL_GOOD" is "NO", provide: - "explanation": a brief reason of what failed and why === OUTPUT === [ "requirement_id": <copy verbatim from input>, "requirement": <copy verbatim from input>, "entity_qualifier": "entity_id": <copy verbatim from input>, "extracted_span": <copy verbatim from input>, "start": <copy verbatim from input>, "end": <copy verbatim from input>, "type": <copy verbatim from input>, "qualifier": <copy verbatim from input>, "qualifier_span": <copy verbatim from input>, 139 Preprint. Under review. "rationale": <how the span narrows the entity's scope>, "SELFCONTAINED": "YES" | "NO", "qualified_entity": "<the referenced entity constrained by the qualifier span>", "QUALIFIED_ENTITY_REFERENCED_ENTITY_IS_SAME_ENTITY_UNDER_DIFFERENT_SCOPE": "YES" | "NO", "QUALIFIED_ENTITY_NARROWER_THEN_REFERENCED_ENTITY": "YES" | "NO", "QUALIFIER_IS_NOT_AN_INHERENT_PROPERTY_OF_ENTITY": "YES" | "NO", "MAKE_ENTITY_SCOPE_MORE_SPECIFIC": "YES" | "NO", "TARGETS_THIS_ENTITY": "YES" | "NO", "CORRECT": "YES" | "NO", "NOT_IN_ENTITY_SURFACE_STRING": "YES" | "NO", "NOT_GENERIC_RELATIONSHIP": "YES" | "NO", "NOT_EXAMPLES_TO_ILLUSTRATE_ENTITY": "YES" | "NO", "NOT_SUPERCLASS_AS_QUALIFIER_FOR_EXAMPLE": "YES" | "NO", "NOT_A_DEFINITION": "YES" | "NO", "ALL_GOOD": "YES" | "NO", "explanation": "<explain what is not good>" , //... ] F.1.26 SMTProgrammer: Top Level Entity Filter Purpose.This prompt determines which extracted entities represent independent clinical conditions in a requirement and which only serve to refine another entity. It keeps only entities that stand on their own as eligibility conditions, ensuring that only meaningful concepts are carried forward for variable construction. # === ROLE === You are an expert in clinical NLP and ontology-grounded information extraction. # === TASK === For each clinical trial requirement and entities with "all_modifying_information" list, decide for each entity whether it is:,→ "KEEP": a top-level subject of the requirement OR "DROP": only functioning as a modifier of another entity because its text appears as an entry inside that other entity's all_modifying_information.,→ Be conservative: keep if ambiguous. === INPUT DESCRIPTIONS=== You receive a list of requirements in <"requirements">. Each item has: requirement_id, requirement_text, entities (list of objects). For each entity: id (int) text (string, entity's text) start (int, entity's start index in requirement_text) end (int, entity's end index in requirement_text) is_canonical_entity (bool) all_modifying_information (list[string]) --- natural-language modifiers about this entity # === INPUT === <requirements> REQUIREMENTS_JSON </requirements> # === RULES === 1. Use ONLY the provided "all_modifying_information" fields to detect modifier relations (site, laterality, severity, timing, location, stage, etc.). Do not INFER new relations.,→ If an entity does not appear in any other entity's "all_modifying_information" (function as other entity's modifier), KEEP it---even if it``looks like′ a modifier.,→ If an entity does appear inside some other entity's "all_modifying_information", DROP it (record the owner entity and modifier).,→ 2. Don't drop an entity text just because its surface string reappears inside "all_modifying_information". Only drop if the reappearance makes that string function as a modifier of another subject, with no standalone fact asserted about itself. ,→ ,→ Example 3.1 (Keep): The entity text is``angiotensin receptor blocker (ARB)′. The modifier says the ARB has already been administered. The entity name appears in the modifier, but it's just the subject; the attribute-value is administration status = already administered. So ARB is KEPT. ,→ ,→ 3. If entity A appears in B's "all_modifying_information" and B appears in A's "all_modifying_information", choose a single core entity to KEEP and DROP the other as the kept's entity's "all_modifying_information", using this precedence: ,→ ,→ 3.a Effect over cause: keep sign/symptom/diagnosis; drop etiology/exposure/cause. 3.b Base finding over attribute: keep disease/finding; drop site/laterality/stage/grade/histology/timing/severity/evidence/procedure/substance.,→ 3.c If still tied, if exactly one has is_canonical_entity=true, keep that one. 3.d If still ambiguous, KEEP BOTH (conservative). Example 3.1: 140 Preprint. Under review. Requirement: The patient is excluded if the patient has fever due to a tumor. Entities: fever with modifiers: Fever has constraints that it is due to a tumor. tumor with modifiers: Tumer has constraints that it caused fever Decision: KEEP fever as an entity(core symptom/effect), DROP tumor as an entity(etiology of fever). Do not drop both.,→ 4. Scratchpad usage: Use the "scratchpad" field for THIS entity only. It must contain 2--4 compact bullets, each following the definitions below:,→ 1. Possibly modifies: Name the other entity in the requirement that this entity could be modifying (e.g., laterality``left′ modifies``breast metastasis′). If it does not modify anything and is a stand-alone subject, write NONE. ,→ ,→ 2. Evidence: Copy the minimal modifier fragment from the text that supports your judgment (e.g., "left" or "within 6 months"). Do not summarize --- use the raw phrase.,→ 3. Role: State whether this entity is functioning as a TOP-LEVEL subject (it stands on its own, e.g., a disease, procedure, or drug that is the subject of the requirement) OR as a MODIFIER (it qualifies some aspect of another entity, e.g., site, laterality, severity, timing, stage). ,→ ,→ 4. Verdict: Write only one of two words --- TOP-LEVEL if the entity is independent, or MODIFIER if it only qualifies another entity. This should be consistent with the Role.,→ <Scratchpad_Example> "id": 4, "text": "insulin resistance", "start": 288, "end": 306, "is_canonical_entity": true, "all_modifying_information": [ "Insulin resistance has constraints that it must be documented in the index subject by oral glucose tolerance test (OGTT) or intravenous glucose tolerance test (IVGTT).",→ ], "scratchpad": "- Possibly modifies: NONE - Evidence: NONE - Role: TOP-LEVEL - Verdict: TOP-LEVEL", , "id": 5, "text": "intravenous glucose tolerance test (IVGTT)", "start": 389, "end": 431, "is_canonical_entity": false, "all_modifying_information": [] , "scratchpad": "- Possibly modifies: insulin resistance - Evidence: "by intravenous glucose tolerance test (IVGTT)" - Role: MODIFIER - Verdict: MODIFIER",,→ </Scratchpad_Example> 5. Output JSON only. Do NOT include prose outside the JSON or any comments inside the JSON. # === OUTPUT === Return an array where each item corresponds to one input requirement: [ "requirement_id": 0, // integer, copied from input "decisions": [ "id": 0, // entity id from input "text": "<entity text span>", // copied exactly from input "start": 13, // copied exactly from input "end": 64, // copied exactly from input "is_canonical_entity": , "all_modifying_information": , "scratchpad": "- Possibly modifies: <entity or NONE> - Evidence: \"<fragment>\" - Role: <TOP-LEVEL or MODIFIER> - Verdict: <TOP-LEVEL|MODIFIER>",,→ "KEEP": "YES" | "NO", // YES if TOP-LEVEL; NO if MODIFIER "explanation": "<explain why you came to this decision>" // ... more entities for this requirement ] // ... more requirements ] F.1.27 SMT Programmer: Canonical Variable Namer Purpose. This prompt constructs standardized variables for canonical medical entities in a requirement. It determines which variables should be introduced or reused, assigns consistent names based on predefined templates, and attaches any necessary qualifiers so that each variable accurately represents the intended clinical meaning. 141 Preprint. Under review. === ROLE === You are an expert SMT engineer and doctor. Your task is to declare variables (Boolean and numeric) and qualifier variables needed to encode ONE eligibility requirement into an existing SMT-LIB program. You DO NOT write assertions here --- only output new canonical variables with canonicalizable entities and their qualifiers (qualifiers don't need to be canonical). ,→ ,→ ,→ === INPUT DESCRIPTIONS=== You will be given the following inputs: 1. <current_requirement>: This is the current requirement you want to reuse or declare variables for. 2. <canonical_forms>: This is a json object containing all entities in <current_requirement> for whom we found their canonical forms.,→ 2.1. Please use "span" field for understanding what surface span from <current_requirement> we are talking about. 2.2. Please use "entity_canonical_form" to plug into entity_canonical_form in the naming templates. 2.3. Please use "type" for undersatnding which templates you should use. 2.4. In cases under which multiple occurances of the same span exist, refer to "start" and "end" (positional indices of the span) to see which instance we are referring to.,→ 3. <reusable_variables>: This is the list of identified variables that already exist in the SMT program and are thus reusable. You should never redeclare these variables(without adding qualifier predicates), even if they correspond to entries in <canonical_forms>. If the requirement needs constraints on a reusable variable, you may include an item in <new_canonical_variable_declarations> only to attach qualifiers. ,→ ,→ ,→ === INPUTS === <current_requirement> #REQUIREMENT# </current_requirement> <canonical_forms> #CANONICAL_FORMS# </canonical_forms> <reusable_variables> #REUSABLE_VARIABLES# </reusable_variables> === NAMING SYSTEM / NAMING TEMPLATES === Stems (lowercase snake_case; strip punctuation; numerals normalized). The timeframe token MUST appear exactly once inside the stem and match the "timeframe" field.,→ <stems_templates> Clinical Finding: <stems_templates::findings> patient_has_diagnosis_of_entity_canonical_form_timeframe | patient_has_finding_of_entity_canonical_form_timeframe | patient_has_symptoms_of_entity_canonical_form_timeframe | patient_has_clinical_signs_of_entity_canonical_form_timeframe | patient_has_suspicion_of_entity_canonical_form_timeframe </stems_templates::findings> Procedure: <stems_templates::procedures> patient_has_undergone_entity_canonical_form_timeframe | patient_has_undergone_entity_canonical_form_timeframe_outcome_is_positive | patient_has_undergone_entity_canonical_form_timeframe_outcome_is_negative | patient_has_undergone_entity_canonical_form_timeframe_outcome_is_normal | patient_has_undergone_entity_canonical_form_timeframe_outcome_is_abnormal | patient_is_undergoing_entity_canonical_form_timeframe | patient_needs_to_undergo_entity_canonical_form_timeframe | patient_will_undergo_entity_canonical_form_timeframe | patient_can_undergo_entity_canonical_form_timeframe | </stems_templates::procedures> Observable Entities (numeric): <stems_templates::observable_entities_numeric> patient_entity_canonical_form_value_recorded_timeframe_withunit_unit </stems_templates::observable_entities_numeric> Product: <stems_templates::product> patient_is_taking_entity_canonical_form_timeframe | patient_has_taken_entity_canonical_form_timeframe | patient_has_hypersensitivity_to_entity_canonical_form_timeframe | patient_has_intolerance_to_entity_canonical_form_timeframe | patient_has_allergy_to_entity_canonical_form_timeframe | patient_has_nonimmune_hypersensitivity_to_entity_canonical_form_timeframe | </stems_templates::product> Substance: <stems_templates::substance> patient_is_exposed_to_entity_canonical_form_timeframe | patient_has_hypersensitivity_to_entity_canonical_form_timeframe | 142 Preprint. Under review. patient_has_intolerance_to_entity_canonical_form_timeframe | patient_has_allergy_to_entity_canonical_form_timeframe | patient_has_nonimmune_hypersensitivity_to_entity_canonical_form_timeframe | </stems_templates::substance> </stems_templates> <timeframe> Timeframe : now | inthehistory | inthefuture | inthepastnunits | inthefuturenunits Time Units: minutes | hours | days | weeks | months | years </timeframe> <qualifiers> Attach with: stem@@qualifier_snake_case Qualifiers must NOT repeat timeframe/value/unit; they encode leftover semantics (e.g., temporal anchors other than``today′, context like``at baseline′, or dependencies like``after percutaneous coronary intervention′). Use qualifiers sparingly and ONLY when needed for later assertions. ,→ ,→ </qualifiers> === GUIDELINES === 1. ONLY entities present in <canonical_forms> should appear in <new_canonical_variable_declarations>. NEVER DECLARE IN <new_canonical_variable_declarations> ENTITIES THAT ARE NOT PRESENT IN <canonical_forms>!!!!! This means that if <canonical_forms> is empty, <new_canonical_variable_declarations> is automatically empty. ,→ ,→ 1. MAXIMIZING RECALL: You should use as many entries in <canonical_forms> as possible. 2. MAXIMIZING PRECISION: Nevertheless, ONLY use entries from <canonical_forms> when the variable you intend to define has meaning matching exactly with that entity's. All naming templates are anchored to the index patient; do not create variables that describe anyone else (e.g., sibling, parent). ,→ ,→ 2. If an entity in <canonical_forms> already has a declared variable in <reusable_variables> and the requirement adds additional constraints beyond that variable's stem meaning (i.e., a gap that can be closed by qualifiers, which means in <canonical_forms>, the entity's "qualifiers" is not empty), then include the same variable in <new_canonical_variable_declarations> only to attach qualifiers needed for this requirement. ,→ ,→ ,→ 3. Every stem name contains exactly one timeframe token from the closed vocab, and it matches the <timeframe> field.,→ 4. Style guide: use lowercase snake_case; numerals normalized; timeframe units canonicalized. 5. Variable names should exactly match what they mean. 5.1 The variable stem must exactly encode its meaning. 5.2 If the same canonical entity appears multiple times and you declare the same stem, keep variable_meaning identical across all occurrences; capture mention-specific nuances via qualifiers, not by changing the stem's meaning. ,→ ,→ 6. Numeric-first: whenever the requirement expresses a quantity (threshold/range/value), declare numeric stems (e.g., entity_value_recorded_timeframe_withunit_unit). Threshold/range logic is asserted later.,→ 7. Timeframes: 7.a. If the requirement includes a relative window anchored to an event (e.g.,``within 6 months after PCI′), put the fine-grained window in a qualifier:,→ temporalcontext_withinndays|weeks|months|yearsafter|beforeanchor (expand abbreviations: pci $→$ percutaneous_coronary_intervention). Keep stem timeframe coarse (now/inthehistory/inthepastNunits/inthefutureNunits).,→ 7.b. If an anchor is essential but cannot be encoded in timeframe, it MUST appear as a qualifier. 8. ONLY define variables if their usages in the original requirement can be EXACTLY map to the template's semantic meaning. Be conservative on this.,→ 9. First plan the meaning for the entity's variable and write a "planned_variable_meaning" that states the required semantics in the requirement for this entity. That is, what kind of variables should be declared about this entity to implement SMT assertions later. Then build the variable stem and add qualifier predicates only for constraints not already captured by the stem. ,→ ,→ ,→ 10. Note that we have already identified the list of qualifiers for each entity. You don't need to use all of them in your qualifier variable declarations, but thse are good for your references. You only define variables when they will form meaningful variables later in implementing SMT assertions. Note that you only define qualifiers with semantics NOT already captured by the naming templates. ,→ ,→ ,→ 11. USE QUALIFIERS SPARINGLY! ONLY USE QUALIFIERS THAT ARE STRICTLY NECESSARY TO IMPLEMENT THE SMT ASSERTION. Also, again, don't define qualifiers that are already captured by in the variable templates.,→ 12. In "qualifier_predicates_for_semantics_not_already_captured_with_stem", declare variables for all MEANINGFUL qualifiers that are not ALREADY captured by the naming templates. Reflect first about what qualifiers are not already captured with the stem template before outputting. For example, if the stem already states "inthehistory", then we should ignore qualifiers like "prior". ,→ ,→ ,→ 13. If a qualifier is about DEFINITION of the entity variable, NEVER define separate variables! This includes - prominently - using numerical thresholds to define the entity variable.,→ 14. If a qualifier is about numerical ranges/comparisons, NEVER make the whole comparison clause (quantitycomparatorvalue) a standalone variable! Just define the numeric quantity and let the later assertion handle the arithmetics! ,→ ,→ 15. After finishing "variable_name" and "variable_meaning" or "qualifier_variable_snake_case_form" and "qualifier_meaning", comment with a single JSON object on the same line for "variable_declaration" and "qualifier_variable_declaration". This object explains when the variable should be given each possible value and what it represents. When commenting the object, make sure the comments are only based on the variable meaning and the variable, don't add any other information to the comment, since it change the variable meaning. ,→ ,→ ,→ ,→ -- For Boolean variables, include five keys: (1) when_to_set_to_true (2) when_to_set_to_false (3) when_to_set_to_null (4) meaning.,→ -- For numeric variables, include four keys: (1) when_to_set_to_value. (2) when_to_set_to_null (3) meaning. 143 Preprint. Under review. Keep this JSON object on the same line as the declaration; do not wrap it onto a new line and do not surround it with extra punctuation.,→ === EXAMPLE === <example_1> <example_1_current_requirement> To be included, the patient must have (an elevated total peripheral white blood cell count, defined as white blood cell count > 10,000/m$^3$) OR (an elevated count of > 15%,→ <example_1_canonical_forms> [ "entity_canonical_form_from_entity_canonical_forms_block": "increased_blood_leukocyte_number", "type": "Clinical finding", "span": "elevated total peripheral white blood cell count", "start": 42, "end": 90, "qualifiers": [], "canon_index": 0 , "entity_canonical_form_from_entity_canonical_forms_block": "immature_white_blood_cells", "type": "Clinical finding", "span": "immature neutrophils", "start": 171, "end": 191, "qualifiers": [], "canon_index": 1 , "entity_canonical_form_from_entity_canonical_forms_block": "decreased_blood_leukocyte_number", "type": "Clinical finding", "span": "leukopenia", "start": 260, "end": 270, "qualifiers": [], "canon_index": 2 ] </example_1canonical_forms> ,→ ,→ ,→ ,→ ,→ ,→ ,→ <example_1_reusable_variables> [] </example_1reusable_variables> <example_1_new_canonical_variable_declarations> [ "index_in_canonical_forms": "0", "entity_canonical_form_from_entity_canonical_forms_block": "increased_blood_leukocyte_number", "span": "elevated total peripheral white blood cell count", "planned_variable_meaning": "Boolean clinical finding indicating the patient currently has an increased total peripheral white blood cell count (elevated WBC).",,→ "usage_description": "Used as a finding flag for the OR-branch corresponding to elevated WBC; exact thresholding (>10,000/m3) will be handled in assertions or via auxiliary links to measurements if present.", ,→ ,→ "entity_type": "Clinical finding", "template": "patient_has_finding_of_entity_canonical_formtimeframe", "timeframe": "now", "entity_variable_name": "patient_has_finding_of_increased_blood_leukocyte_number_now", "variable_meaning": "Boolean clinical finding indicating the patient currently has an increased total peripheral white blood cell count (elevated WBC).",,→ "variable_declaration": "variable_declaration": "\"when_to_set_to_true\":\"Set to true if the patient currently has the clinical finding of increased total peripheral white blood cell count.\",\"when_to_set_to_false\":\"Set to false if the patient currently does not have the clinical finding of increased total peripheral white blood cell count.\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether the patient currently has the clinical finding of increased total peripheral white blood cell count.\",\"meaning\":\"Boolean indicating whether the patient currently has increased total peripheral white blood cell count.\"", ,→ ,→ ,→ ,→ ,→ ,→ "scratchpad_reflect_what_qualifiers_not_already_captured_with_entity_variable_stem": "No additional temporal/context qualifiers are required; the definition by numeric threshold (>10,000/m3) is not a qualifier and will not be encoded here.", ,→ ,→ "qualifier_predicates_for_semantics_not_already_captured_with_stem": [] , "index_in_canonical_forms": "1", "entity_canonical_form_from_entity_canonical_forms_block": "immature_white_blood_cells", "span": "immature neutrophils", "planned_variable_meaning": "Numeric observable capturing the percentage of immature neutrophils (bands) recorded now.",,→ "usage_description": "Provides the numeric quantity to express the criterion'> 15% "entity_type": "Clinical finding", "template": "patient_entity_canonical_form_value_recordedtimeframewithunitunit", "timeframe": "now", "entity_variable_name": "patient_immature_white_blood_cells_value_recorded_now_withunit_percent", "variable_meaning": "Numeric observable capturing the percentage of immature neutrophils (bands) recorded now.",,→ "variable_declaration": "\"when_to_set_to_value\":\"Set to the measured percentage value if a numeric measurement of the percentage of immature neutrophils (bands) recorded now is available.\",\"when_to_set_to_null\":\"Set to null if no such percentage measurement recorded now is available or the value is indeterminate.\",\"meaning\":\"Numeric percentage representing the patient's current proportion of immature neutrophils (bands).\"", ,→ ,→ ,→ ,→ "scratchpad_reflect_what_qualifiers_not_already_captured_with_entity_variable_stem": "The clause'regardless of total WBC' is logical context, not a qualifier. No extra temporal anchors beyond'now'.",,→ "qualifier_predicates_for_semantics_not_already_captured_with_stem": [] , "index_in_canonical_forms": "2", "entity_canonical_form_from_entity_canonical_forms_block": "decreased_blood_leukocyte_number", "span": "leukopenia", "planned_variable_meaning": "Boolean clinical finding indicating the patient currently has decreased total peripheral white blood cell count (leukopenia).",,→ "usage_description": "Used as a finding flag for the OR-branch corresponding to leukopenia; the defining threshold (<4,500/m3) will be enforced in assertions or aligned via auxiliary mapping to measurements if available.", ,→ ,→ "entity_type": "Clinical finding", "template": "patient_has_finding_of_entity_canonical_form_timeframe", "timeframe": "now", "entity_variable_name": "patient_has_finding_of_decreased_blood_leukocyte_number_now", 144 Preprint. Under review. "variable_meaning": "Boolean clinical finding indicating the patient currently has decreased total peripheral white blood cell count (leukopenia).",,→ "variable_declaration": "\"when_to_set_to_true\":\"Set to true if the patient currently has the clinical finding of decreased total peripheral white blood cell count.\",\"when_to_set_to_false\":\"Set to false if the patient currently does not have the clinical finding of decreased total peripheral white blood cell count.\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether the patient currently has the clinical finding of decreased total peripheral white blood cell count.\",\"meaning\":\"Boolean indicating whether the patient currently has decreased total peripheral white blood cell count.\"", ,→ ,→ ,→ ,→ ,→ ,→ "scratchpad_reflect_what_qualifiers_not_already_captured_with_entity_variable_stem": "Numeric threshold (<4,500/m3) is part of assertion logic, not a qualifier. No additional qualifiers needed.",,→ "qualifier_predicates_for_semantics_not_already_captured_with_stem": [] ] </example_1_new_canonical_variable_declarations> </example_1> <example_2> <example_2_current_requirement> To be included, the patient must be ((a sibling of a patient with insulin resistance) OR (a parent of a patient with insulin resistance)) AND (insulin resistance must be documented in the index subject by either (oral glucose tolerance test (OGTT)) OR (intravenous glucose tolerance test (IVGTT))). ,→ ,→ </example_2_current_requirement> <example_2_canonical_forms> [ "entity_canonical_form_from_entity_canonical_forms_block": "insulin_resistance", "type": "Clinical finding", "span": "insulin resistance", "start": 66, "end": 84, "qualifiers": [], "canon_index": 0 , "entity_canonical_form_from_entity_canonical_forms_block": "insulin_resistance", "type": "Clinical finding", "span": "insulin resistance", "start": 117, "end": 135, "qualifiers": [], "canon_index": 1 , "entity_canonical_form_from_entity_canonical_forms_block": "insulin_resistance", "type": "Clinical finding", "span": "insulin resistance", "start": 143, "end": 161, "qualifiers": [ "Insulin resistance has constraints that it must be documented in the index subject by either oral glucose tolerance test (OGTT) or intravenous glucose tolerance test (IVGTT).",→ ], "canon_index": 2 ] </example_2_canonical_forms> <example_2_reusable_variables> [ "variable_name": "patient_has_finding_of_insulin_resistance_now", "variable_declaration": "\"when_to_set_to_true\":\"Set to true if the index subject currently has insulin resistance.\",\"when_to_set_to_false\":\"Set to false if the index subject currently does not have insulin resistance.\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether the index subject currently has insulin resistance.\",\"meaning\":\"Boolean indicating whether the index subject currently has insulin resistance.\"", ,→ ,→ ,→ ,→ "why": "This variable indicates whether the patient currently has insulin resistance, which matches the meaning of'insulin resistance is documented in the index subject' at the core; the current requirement further constrains the documentation method (OGTT/IVGTT)." ,→ ,→ ] </example_2_reusable_variables> <example_2_new_canonical_variable_declarations> [ "index_in_canonical_forms": "2", "entity_canonical_form_from_entity_canonical_forms_block": "insulin_resistance", "span": "insulin resistance", 145 Preprint. Under review. "planned_variable_meaning": "The index subject currently has insulin resistance documented by either an oral glucose tolerance test (OGTT) or an intravenous glucose tolerance test (IVGTT).",,→ "usage_description": "Reuse the existing insulin-resistance flag and attach method-of-documentation qualifiers required by this requirement. (Family relationship constraints---sibling/parent---are modeled elsewhere, not as qualifiers of this finding.)", ,→ ,→ "entity_type": "Clinical finding", "template": "patient_has_finding_of_entity_canonical_form_timeframe", "timeframe": "now", "entity_variable_name": "patient_has_finding_of_insulin_resistance_now", "variable_meaning": "Boolean clinical finding indicating whether the index subject currently has insulin resistance.",,→ "variable_declaration": "\"when_to_set_to_true\":\"Set to true if the index subject currently has insulin resistance.\",\"when_to_set_to_false\":\"Set to false if the index subject currently does not have insulin resistance.\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether the index subject currently has insulin resistance.\",\"meaning\":\"Boolean indicating whether the index subject currently has insulin resistance.\"", ,→ ,→ ,→ ,→ "scratchpad_reflect_what_qualifiers_not_already_captured_with_entity_variable_stem": "The stem captures presence and timeframe; the documentation method (OGTT/IVGTT) must be carried as qualifiers.",,→ "qualifier_predicates_detailed": [ "qualifier_variable_snake_case_form": "@@documented_by_oral_glucose_tolerance_test", "qualifier_meaning": "Boolean clinical finding indicating whether the index subject currently has insulin resistance and the finding is documented by an oral glucose tolerance test (OGTT).",,→ "qualifier_variable_declaration": "\"when_to_set_to_true\":\"Set to true if the index subject's insulin resistance is documented by an oral glucose tolerance test (OGTT).\",\"when_to_set_to_false\":\"Set to false if the index subject's insulin resistance is not documented by an oral glucose tolerance test (OGTT).\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether an oral glucose tolerance test (OGTT) documents the index subject's insulin resistance.\",\"meaning\":\"Boolean indicating whether the index subject's insulin resistance is documented by an oral glucose tolerance test (OGTT).\"", ,→ ,→ ,→ ,→ ,→ ,→ , "qualifier_variable_snake_case_form": "@@documented_by_intravenous_glucose_tolerance_test", "qualifier_meaning": "Boolean clinical finding indicating whether the index subject currently has insulin resistance and the finding is documented by an intravenous glucose tolerance test (IVGTT).",,→ "qualifier_variable_declaration": "\"when_to_set_to_true\":\"Set to true if the index subject's insulin resistance is documented by an intravenous glucose tolerance test (IVGTT).\",\"when_to_set_to_false\":\"Set to false if the index subject's insulin resistance is not documented by an intravenous glucose tolerance test (IVGTT).\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether an intravenous glucose tolerance test (IVGTT) documents the index subject's insulin resistance.\",\"meaning\":\"Boolean indicating whether the index subject's insulin resistance is documented by an intravenous glucose tolerance test (IVGTT).\"", ,→ ,→ ,→ ,→ ,→ ,→ ,→ ], "qualifier_predicates_for_semantics_not_already_captured_with_stem": [ "documented_by_oral_glucose_tolerance_test", "documented_by_intravenous_glucose_tolerance_test" ], ] </example_2_new_canonical_variable_declarations> </example_2> === OUTPUT FORMATS === Emit EXACTLY the following block: 1. <new_canonical_variable_declarations>. This refers to everything that uses templates from <stems_templates::findings>, <stems_templates::procedures>, <stems_templates::observable_entities_numeric>, <stems_templates::product>, <stems_templates::substance>, as well as their <qualifiers>. ,→ ,→ Note if things are empty, just emit empty blocks. But make sure that all blocks are present. Similarly, if a field is empty, still emit an empty version of that field.,→ <new_canonical_variable_declarations> [ "index_in_canonical_forms": "<index_from_canonical_forms>", "entity_canonical_form_from_entity_canonical_forms_block": "<exact string from canonical_forms>", // NOTE must be an entry present in canonical forms,→ "span": "<copy from canonical_forms>", "planned_variable_meaning": "plan the meaning for the entity's variable, one sentence stating the exact, requirement-specific semantics that must hold for this entity's variable.",,→ "usage_description": "<mechanistic role in the future assertion>", "entity_type": "<which SNOMED type the entity_canonical_form_used belongs to, used to aid template selection>". "template": "<reiterate the exact template you use>, "timeframe": "<now|inthehistory|inthefuture|inthepastnunits|inthefuturenunits>", "entity_variable_name": "<stem>", // THIS IS JUST THE STEM! No @@ qualifiers. Also note that you must include timeframe here!!!!!!!!!!! Everything shold be snakecase as well.,→ "variable_meaning": "<exact stem-only meaning of entity_variable_name>", // Describe only what the variable *stem* itself denotes. Do not add any meaning the stem does not encode.,→ 146 Preprint. Under review. "variable_declaration": "explains when the variable should be given each possible value and what it represents",,→ "scratchpad_reflect_what_qualifiers_not_already_captured_with_entity_variable_stem": "... reflections for later output ...",→ "qualifier_predicates_for_semantics_not_already_captured_with_stem": [ "qualifier_variable_snake_case_form": "<@@qualifier1>", // Note that this must start with @@ and is a variable snake case form",→ "qualifier_meaning": "... meaning of qualifier 1 ... ", // When giving the "qualifier_meaning", first include the "variable_stem_meaning", then add the qualifier's meaning.,→ "qualifier_variable_declaration": "explains when the variable should be given each possible value and what it represents",,→ ], // may be [], this means all things that qualify this entity that are not already captured by the naming template. Note that you don't need stem here.,→ ] </new_canonical_variable_declarations> F.1.28 SMT Programmer: Demographics Variable Namer Purpose.This prompt constructs standardized variables for patient demographic at- tributes, such as age, sex, and reproductive status. It identifies which demographic variables are required for the current requirement and ensures they are represented using consistent templates for downstream SMT encoding. === ROLE === You are an expert SMT engineer and doctor. Your task is to declare DEMOGRAHIC variables needed to encode ONE eligibility requirement into an existing SMT-LIB program. You DO NOT write assertions here --- only output new canonical demographic variables. ,→ ,→ === INPUT DESCRIPTIONS=== You will be given the following inputs: 1. <current_requirement>: This is the current requirement you want to reuse or declare variables for. 2. <reusable_variables>: This is the list of identified variables that already exist in the SMT program and are thus reusable. You should never redeclare these variables. If you need exactly these variabes, you will always be able to use them without redeclaring. ,→ ,→ === INPUTS === <current_requirement> #REQUIREMENT# </current_requirement> <reusable_variables> #REUSABLE_VARIABLES# </reusable_variables> === NAMING SYSTEM / NAMING TEMPLATES === Stems (lowercase snake_case; strip punctuation; numerals normalized). The timeframe token MUST appear exactly once inside the stem and match the "timeframe" field.,→ <stems_templates> patient_age_value_recorded_timeframe_in_years | patient_age_value_recorded_timeframe_in_months | patient_age_value_recorded_timeframe_in_days | patient_sex_is_sex_timeframe | patient_is_pregnant_timeframe | patient_is_able_to_be_pregnant_timeframe | patient_has_childbearing_potential_timeframe | patient_is_breastfeeding_timeframe | patient_is_lactating_timeframe | patient_is_postmenopausal_timeframe | patient_is_in_transition_to_menopausal_timeframe | patient_is_infertile_timeframe | patient_is_inpatient_timeframe | patient_is_outpatient_timeframe | patient_has_been_inpatient_timeframe | patient_has_been_outpatient_timeframe | patient_has_been_inpatient_timeframe | patient_is_child_timeframe patient_is_adolescent_timeframe patient_is_adult_timeframe patient_is_middle_aged_timeframe patient_is_older_adult_timeframe patient_is_neonate_timeframe patient_is_toddler_timeframe patient_is_preschooler_timeframe patient_is_school_aged_timeframe patient_is_premenopausal_timeframe patient_is_perimenopausal_timeframe 147 Preprint. Under review. patient_is_postpartum_timeframe patient_is_postabortion_timeframe patient_is_emergency_department_patient_timeframe patient_is_long_term_care_resident_timeframe patient_is_nursing_home_resident_timeframe patient_is_assisted_living_resident_timeframe patient_was_born_preterm_timeframe patient_was_born_at_term_timeframe patient_was_born_postterm_timeframe patient_has_history_of_preterm_delivery_timeframe patient_has_history_of_term_delivery_timeframe patient_has_history_of_postterm_delivery_timeframe patient_has_history_of_recurrent_preterm_delivery_timeframe patient_has_history_of_preterm_premature_rupture_of_membranes_timeframe patient_has_history_of_stillbirth_timeframe patient_has_history_of_spontaneous_abortion_timeframe </stems_templates> <sex> Choose from male / female / other. </sex> <timeframe> Timeframe : now | inthehistory | inthefuture | inthepastnunits | inthefuturenunits | foradurationofnunits,→ Time Units: minutes | hours | days | weeks | months | years </timeframe> === EXAMPLES === <example_1> <current_requirement> To be included, the patient must be aged $≥$ 18 years. </current_requirement> <reusable_variables> </reusable_variables> <new_age_sex_pregnancystatus_declarations> [ "span": "aged $≥$ 18 years", "template": "patient_age_value_recorded_timeframe_in_years", "timeframe": "now", "variable_meaning": "Numeric value indicating the patient's current age in years.", "variable_declaration": "\"when_to_set_to_value\":\"Set to the patient's current age in years if it is known and documented.\",\"when_to_set_to_null\":\"Set to null if the patient's current age in years is unknown, not documented, or cannot be determined.\",\"meaning\":\"Numeric value indicating the patient's current age in years.\"", ,→ ,→ ,→ "usage_description": "Used to determine if the patient meets the age eligibility requirement of being 18 years or older.",→ "entity_variable_name": "patient_age_value_recorded_now_in_years", ] </new_age_sex_pregnancystatus_declarations> </example_1> === GUIDELINES === 1. You are ONLY allowed to define variables that strictl follow the given templates. 2. Style guide: use lowercase snake_case; numerals normalized; timeframe units canonicalized. 3. Variable names should exactly match what they mean. 4. ONLY define variables if their usages in the original requirement can be EXACTLY map to the template's semantic meaning. Be conservative on this.,→ 5. Replace the corresponding sex and <timeframe> blocks with <sex> and <timeframe> entries. 6. These are all the templates you should use. NEVER declare any variable that is not about age, sex, pregnancy status, and potential to be pregnant.,→ 7. After finishing "variable_name" and "variable_meaning", comment with a single JSON object on the same line for "variable_declaration". This object explains when the variable should be given each possible value and what it represents. When commenting the object, make sure the comments are only based on the variable meaning and the variable, don't add any other information to the comment, since it change the variable meaning. ,→ ,→ ,→ -- For Boolean variables, include five keys: (1) when_to_set_to_true (2) when_to_set_to_false (3) when_to_set_to_null (4) meaning.,→ -- For numeric variables, include four keys: (1) when_to_set_to_value. (2) when_to_set_to_null (3) meaning. Keep this JSON object on the same line as the declaration; do not wrap it onto a new line and do not surround it with extra punctuation.,→ === OUTPUT FORMATS === Emit <new_age_sex_pregnancystatus_declarations>. This refers to everything that ses templates from <stems_templates::demographics> that you have to newly declare (does not exist in <smt_program_by_far>).,→ Note if things are empty, just emit empty blocks. But make sure that all blocks are present. Similarly, if a field is empty, still emit an empty version of that field.,→ 148 Preprint. Under review. <new_age_sex_pregnancystatus_declarations> [ "span": "<relevant span>", "template": "<which template name>", "timeframe": "<now|inthehistory|inthefuture|inthepastnunits|inthefuturenunits>", "variable_meaning": "<meaning of the variable>", "variable_declaration": "explains when the variable should be given each possible value and what it represents",,→ "usage_description": "<mechanistic role in the future assertion>" "entity_variable_name": "<stem>", ] </new_age_sex_pregnancystatus_declarations> F.1.29 SMT Programmer: Free Variable Namer Purpose.This prompt constructs variables for clinically meaningful content that cannot be mapped to canonical representations. It introduces flexible, verbatim-aligned variables to ensure that important information is preserved, even when standardization is not possible. === ROLE === You are an expert SMT engineer and doctor. Your task is to declare ALL REMANINGs entity variables (Boolean and numeric), qualifier variables, and miscellaneous variables needed to encode ONE eligibility requirement into an existing SMT-LIB program. You DO NOT write assertions here --- only output new variables needed. ,→ ,→ === INPUT DESCRIPTIONS=== You will be given the following inputs: 1. <current_requirement>: This is the current requirement you want to reuse or declare variables for. 2. <already_declared_variables>: This is the json for all of the already declared variables. 2.1 Do not redeclare any variable whose exact name already appears in <already_declared_variables>. Adding qualifiers produces a new variable name; see 2.2.,→ 2.2 If the current requirement adds constraints that are not captured by a variable's stem meaning, you may attach the appropriate qualifiers to that stem and include the composed variable (stem + qualifiers) in <new_variable_declarations>. Do this only when the qualified variant will better support subsequent SMT assertions. ,→ ,→ ,→ 3. <entity_qualifier_pairs>: This is the json object for all entities and qualifiers identified that you should refer to for defining the remaining variables that are meaningful for forming the SMT constraints.,→ === INPUTS === <current_requirement> #REQUIREMENT# </current_requirement> <already_declared_variables> #ALREADY_DECLARED_VARIABLES# </already_declared_variables> <entity_qualifier_pairs> #ENTITY_QUALIFIER_PAIRS# </entity_qualifier_pairs> === GUIDELINES === 1. No redeclarations. You should not be defining variables that already exist in <already_declared_variables> again.,→ 1.1 The only exception is that you may declare a new qualified variant---the stem plus newly required qualifiers---in <new_variable_declarations> only when the requirement introduces constraints not captured by the stem meaning; the original stem and its meaning must remain unchanged. Do this only when the qualified variant will better support subsequent SMT assertions!!! ,→ ,→ ,→ 2. Style guide: use lowercase snake_case; numerals normalized; timeframe units canonicalized. 3. Variable names should exactly match the semantic meanings of the corresponding variables. You don't need to stick to the templates of the variables <already_declared_variables>. Instead, you should name variables in the most verbatim way, such that no semantic drift happens. ,→ ,→ 4. In "variable_meaning", put down the self-contained meaning of the variable you are defining. 5. Numeric-first: whenever the requirement expresses a quantity (threshold/range/value), declare numeric stems (e.g., entity_value_recorded_timeframe_withunit_unit and age_value_recorded_timeframe_in_years|months|days). You must make clear the unit used. Threshold/range logic is asserted later. ,→ ,→ ,→ 6. You should declare all qualifier variables related to an entity variable's entity in its "qualifier_variables" JSON subfield. Start qualifier variable declarations with "@@", and put the self-contained meaning of the qualifier variable under "qualifier_variable_meaning". ,→ ,→ 7. Note that we have already identified the list of qualifiers for each entity. You don't need to use all of them in your qualifier variable declarations, but thse are good for your references. You only define variables whenever they will form meaningful variables later in implementing SMT assertions. Note that you only define qualifiers with semantics NOT already captured by the naming templates. ,→ ,→ ,→ 149 Preprint. Under review. 8. Make sure to maximally capture variables as entity-qualifier groups, rather than defining qualifiers as standalone variables.,→ 9. USE QUALIFIERS SPARINGLY! ONLY USE QUALIFIERS THAT ARE STRICTLY NECESSARY TO IMPLEMENT THE SMT ASSERTION. Also, again, don't define qualifiers that are already captured by in the variable templates.,→ 10. If a qualifier is about DEFINITION of the entity variable, NEVER define separate variables! This includes - prominently - using numerical thresholds to define the entity variable. For example,,→ 11. If a qualifier is about numerical ranges/comparisons, NEVER make the whole comparison clause (quantitycomparatorvalue) a standalone variable! Just define the numeric quantity and let the later assertion handle the arithmetics! ,→ ,→ 12. After finishing "variable_name" and "variable_meaning" or "qualifier_variable_snake_case_form" and "qualifier_meaning", comment with a single JSON object on the same line for "variable_declaration" and "qualifier_variable_declaration". This object explains when the variable should be given each possible value and what it represents. When commenting the object, make sure the comments are only based on the variable meaning and the variable, don't add any other information to the comment, since it change the variable meaning. ,→ ,→ ,→ ,→ -- For Boolean variables, include five keys: (1) when_to_set_to_true (2) when_to_set_to_false (3) when_to_set_to_null (4) meaning.,→ -- For numeric variables, include four keys: (1) when_to_set_to_value. (2) when_to_set_to_null (3) meaning. c. Keep this JSON object on the same line as the declaration; do not wrap it onto a new line and do not surround it with extra punctuation.,→ === Examples === <example_1> <current_requirement_example_1> The patient is excluded if the patient does NOT have cognitive impairment based on cognitive screening at the time of hospital admission.,→ </current_requirement_example_1> <already_declared_variables_example_1> [ "variable_name": "patient_has_finding_of_impaired_cognition_now", "variable_meaning": "Boolean clinical finding indicating whether the patient currently has cognitive impairment.",,→ "variable_declaration": "\"when_to_set_to_true\":\"Set to true if the patient currently has cognitive impairment.\",\"when_to_set_to_false\":\"Set to false if the patient currently does not have cognitive impairment.\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether the patient currently has cognitive impairment.\",\"meaning\":\"Boolean indicating whether the patient currently has cognitive impairment.\"", ,→ ,→ ,→ ,→ , "variable_name": "patient_has_undergone_cognitive_assessment_in_the_history", "variable_meaning": "Boolean procedure indicating whether the patient has undergone cognitive screening in the history.",,→ "variable_declaration": "\"when_to_set_to_true\":\"Set to true if the patient has undergone cognitive screening in the past.\",\"when_to_set_to_false\":\"Set to false if the patient has not undergone cognitive screening in the past.\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether the patient has undergone cognitive screening in the past.\",\"meaning\":\"Boolean indicating whether the patient has undergone cognitive screening in the history.\"", ,→ ,→ ,→ ,→ ,→ , "variable_name": "patient_is_undergoing_hospital_admission_now", "variable_meaning": "Boolean procedure indicating whether the patient is currently at the time of hospital admission.",,→ "variable_declaration": "\"when_to_set_to_true\":\"Set to true if the patient is currently at the time of hospital admission.\",\"when_to_set_to_false\":\"Set to false if the patient is not currently at the time of hospital admission.\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether the patient is currently at the time of hospital admission.\",\"meaning\":\"Boolean indicating whether the patient is currently at the time of hospital admission.\"" ,→ ,→ ,→ ,→ , ] </already_declared_variables_example_1> <entity_qualifier_pairs_example_1> </entity_qualifier_pairs_example_1> <new_variable_declarations_example_1> [ "variable_name": "patient_has_finding_of_impaired_cognition_now", "variable_meaning": "Boolean clinical finding indicating whether the patient currently has cognitive impairment.",,→ "variable_declaration": "\"when_to_set_to_true\":\"Set to true if the patient currently has cognitive impairment.\",\"when_to_set_to_false\":\"Set to false if the patient currently does not have cognitive impairment.\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether the patient currently has cognitive impairment.\",\"meaning\":\"Boolean indicating whether the patient currently has cognitive impairment.\"" ,→ ,→ ,→ ,→ "qualifier_variables": [ "qualifier_variable_name": "@@based_on_cognitive_screening_at_hospital_admission", 150 Preprint. Under review. "qualifier_variable_meaning": "Boolean clinical finding indicating whether the patient currently has cognitive impairment. And the coginitive impairment is identified based on the cognitive screening at the time of hospital admission.", ,→ ,→ "qualifier_variable_declaration": "\"when_to_set_to_true\":\"Set to true if the patient's current cognitive impairment is identified based on cognitive screening at the time of hospital admission.\",\"when_to_set_to_false\":\"Set to false if the patient's current cognitive impairment is not identified based on cognitive screening at the time of hospital admission.\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether cognitive screening at the time of hospital admission identifies the patient's current cognitive impairment.\",\"meaning\":\"Boolean indicating whether the patient's current cognitive impairment is identified based on cognitive screening at the time of hospital admission.\"", ,→ ,→ ,→ ,→ ,→ ,→ ,→ ] , "variable_name": "patient_has_undergone_cognitive_assessment_in_the_history", "variable_meaning": "Boolean procedure indicating whether the patient has undergone cognitive screening in the history.",,→ "variable_declaration": "\"when_to_set_to_true\":\"Set to true if the patient has undergone cognitive screening in the past.\",\"when_to_set_to_false\":\"Set to false if the patient has not undergone cognitive screening in the past.\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether the patient has undergone cognitive screening in the past.\",\"meaning\":\"Boolean indicating whether the patient has undergone cognitive screening in the history.\"", ,→ ,→ ,→ ,→ ,→ "qualifier_variables": [ "qualifier_variable_name": "@@at_the_time_of_hospital_admission", "qualifier_variable_meaning": "Boolean procedure indicating whether the patient has undergone cognitive screening in the history, which is at the time of hospital_admission",,→ "qualifier_variable_declaration": "\"when_to_set_to_true\":\"Set to true if the patient's cognitive screening in the history occurred at the time of hospital admission.\",\"when_to_set_to_false\":\"Set to false if the patient's cognitive screening in the history did not occur at the time of hospital admission.\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether the patient's cognitive screening in the history occurred at the time of hospital admission.\",\"meaning\":\"Boolean indicating whether the patient's cognitive screening in the history occurred at the time of hospital admission.\"" ,→ ,→ ,→ ,→ ,→ ,→ ] , ] </new_variable_declarations_example_1> </example_1> <example_2> <current_requirement_example_2> To be included, the patient must have (a clinical diagnosis of diabetes) OR (a clinical diagnosis of smoking habit) OR (a clinical diagnosis of lipid metabolism abnormality) OR (a clinical diagnosis of history of ischemic heart disease) OR (a clinical diagnosis of cerebrovascular disease) OR (a clinical diagnosis of obesity (body mass index > 25)) OR (a clinical diagnosis of chronic heart failure (New York Heart Association Class I OR Class I)) OR (a clinical diagnosis of electrocardiogram abnormality (left ventricular hypertrophy)). ,→ ,→ ,→ ,→ </current_requirement_example_2> <already_declared_variables_example_2> [ "variable_name": "patient_has_finding_of_cerebrovascular_disease_now", "variable_meaning": "Boolean clinical finding indicating whether the patient currently has a clinical diagnosis of cerebrovascular disease.",,→ "variable_declaration": "\"when_to_set_to_true\":\"Set to true if the patient currently has a clinical diagnosis of cerebrovascular disease.\",\"when_to_set_to_false\":\"Set to false if the patient currently does not have a clinical diagnosis of cerebrovascular disease.\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether the patient currently has a clinical diagnosis of cerebrovascular disease.\",\"meaning\":\"Boolean indicating whether the patient currently has a clinical diagnosis of cerebrovascular disease.\"" ,→ ,→ ,→ ,→ ,→ , "variable_name": "patient_has_finding_of_diabetes_mellitus_now", "variable_meaning": "Boolean clinical finding indicating whether the patient currently has a clinical diagnosis of diabetes mellitus.",,→ "variable_declaration": "\"when_to_set_to_true\":\"Set to true if the patient currently has a clinical diagnosis of diabetes mellitus.\",\"when_to_set_to_false\":\"Set to false if the patient currently does not have a clinical diagnosis of diabetes mellitus.\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether the patient currently has a clinical diagnosis of diabetes mellitus.\",\"meaning\":\"Boolean indicating whether the patient currently has a clinical diagnosis of diabetes mellitus.\"" ,→ ,→ ,→ ,→ ,→ , "variable_name": "patient_has_finding_of_disorder_of_lipid_metabolism_now", "variable_meaning": "Boolean clinical finding indicating whether the patient currently has a clinical diagnosis of a disorder of lipid metabolism.",,→ 151 Preprint. Under review. "variable_declaration": "\"when_to_set_to_true\":\"Set to true if the patient currently has a clinical diagnosis of a disorder of lipid metabolism.\",\"when_to_set_to_false\":\"Set to false if the patient currently does not have a clinical diagnosis of a disorder of lipid metabolism.\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether the patient currently has a clinical diagnosis of a disorder of lipid metabolism.\",\"meaning\":\"Boolean indicating whether the patient currently has a clinical diagnosis of a disorder of lipid metabolism.\"" ,→ ,→ ,→ ,→ ,→ ,→ , "variable_name": "patient_has_finding_of_ischemic_heart_disease_now", "variable_meaning": "Boolean clinical finding indicating whether the patient currently has a clinical diagnosis of ischemic heart disease.",,→ "variable_declaration": "\"when_to_set_to_true\":\"Set to true if the patient currently has a clinical diagnosis of ischemic heart disease.\",\"when_to_set_to_false\":\"Set to false if the patient currently does not have a clinical diagnosis of ischemic heart disease.\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether the patient currently has a clinical diagnosis of ischemic heart disease.\",\"meaning\":\"Boolean indicating whether the patient currently has a clinical diagnosis of ischemic heart disease.\"" ,→ ,→ ,→ ,→ ,→ , "variable_name": "patient_has_finding_of_left_ventricular_hypertrophy_now", "variable_meaning": "Boolean clinical finding indicating whether the patient currently has a clinical diagnosis of left ventricular hypertrophy.",,→ "variable_declaration": "\"when_to_set_to_true\":\"Set to true if the patient currently has a clinical diagnosis of left ventricular hypertrophy.\",\"when_to_set_to_false\":\"Set to false if the patient currently does not have a clinical diagnosis of left ventricular hypertrophy.\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether the patient currently has a clinical diagnosis of left ventricular hypertrophy.\",\"meaning\":\"Boolean indicating whether the patient currently has a clinical diagnosis of left ventricular hypertrophy.\"" ,→ ,→ ,→ ,→ ,→ ,→ , "variable_name": "patient_has_finding_of_obesity_now", "variable_meaning": "Boolean clinical finding indicating whether the patient currently has a clinical diagnosis of obesity.",,→ "variable_declaration": "\"when_to_set_to_true\":\"Set to true if the patient currently has a clinical diagnosis of obesity.\",\"when_to_set_to_false\":\"Set to false if the patient currently does not have a clinical diagnosis of obesity.\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether the patient currently has a clinical diagnosis of obesity.\",\"meaning\":\"Boolean indicating whether the patient currently has a clinical diagnosis of obesity.\"" ,→ ,→ ,→ ,→ ,→ , "variable_name": "patient_has_finding_of_tobacco_smoking_behavior_finding_now", "variable_meaning": "Boolean clinical finding indicating whether the patient currently has a clinical diagnosis of tobacco smoking behavior.",,→ "variable_declaration": "\"when_to_set_to_true\":\"Set to true if the patient currently has a clinical diagnosis of tobacco smoking behavior.\",\"when_to_set_to_false\":\"Set to false if the patient currently does not have a clinical diagnosis of tobacco smoking behavior.\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether the patient currently has a clinical diagnosis of tobacco smoking behavior.\",\"meaning\":\"Boolean indicating whether the patient currently has a clinical diagnosis of tobacco smoking behavior.\"" ,→ ,→ ,→ ,→ ,→ ] </already_declared_variables_example_2> <entity_qualifier_pairs_example_2> [ "entity": "surface_string": "clinical diagnosis of chronic heart failure", "type": "FreeEntity", "start": 356, "end": 399, "preferred_term": null, "conceptId": null , "qualifiers": [] ] </entity_qualifier_pairs_example_2> <new_variable_declarations_example_2> [ "variable_name": "patient_has_finding_of_chronic_heart_failure_now", "variable_meaning": "Boolean clinical finding indicating whether the patient currently has chronic heart failure.",,→ 152 Preprint. Under review. "variable_declaration": "\"when_to_set_to_true\":\"Set to true if the patient currently has chronic heart failure.\",\"when_to_set_to_false\":\"Set to false if the patient currently does not have chronic heart failure.\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether the patient currently has chronic heart failure.\",\"meaning\":\"Boolean indicating whether the patient currently has chronic heart failure.\"", ,→ ,→ ,→ ,→ "qualifier_variables": [ "qualifier_variable_name": "@@classified_as_nyha_class_i_or_i", "qualifier_variable_meaning": "Boolean clinical finding indicating whether the patient currently has chronic heart failure, which is classified as New York Heart Association Class I or Class I.",,→ "qualifier_variable_declaration": "\"when_to_set_to_true\":\"Set to true if the patient's current chronic heart failure is classified as New York Heart Association Class I or Class I.\",\"when_to_set_to_false\":\"Set to false if the patient's current chronic heart failure is not classified as New York Heart Association Class I or Class I.\",\"when_to_set_to_null\":\"Set to null if it is unknown, not documented, or cannot be determined whether the patient's current chronic heart failure is classified as New York Heart Association Class I or Class I.\",\"meaning\":\"Boolean indicating whether the patient's current chronic heart failure is classified as New York Heart Association Class I or Class I.\"" ,→ ,→ ,→ ,→ ,→ ,→ ,→ ] ] </new_variable_declarations_example_2> </example_2> === OUTPUT FORMATS === Emit EXACTLY the following block: 1. <new_variable_declarations>. All remaining free entity variables (Boolean and numeric), qualifier variables, and any other variables required to encode ONE eligibility requirement into SMT-LIB program declared at this stage. ,→ ,→ Note if things are empty, just emit empty blocks. But make sure that all blocks are present. Similarly, if a field is empty, still emit an empty version of that field.,→ <new_variable_declarations> [ "variable_name": "...", "variable_meaning": "...", "variable_declaration": "explains when the variable should be given each possible value and what it represents",,→ "qualifier_variables": [ "qualifier_variable_name": "@@<qualifier_1>", "qualifier_variable_meaning": "first include variable meaning, then include qualifier meaning", "qualifier_variable_declaration": "explains when the variable should be given each possible value and what it represents",,→ ] ] </new_variable_declarations> F.1.30 SMT Programmer: New Variable Filter Purpose.This prompt removes proposed variables that do not represent standalone clini- cal concepts in the requirement. Its role is to keep only variables that function independently in the eligibility logic, while filtering out variables whose meaning is purely to modify another variable. # === ROLE === You are an expert in clinical NLP and ontology-grounded information extraction. # === TASK === For each clinical trial requirement and entities with "all_modifying_information" list, decide for each entity whether it is:,→ "KEEP": a top-level subject of the requirement OR "DROP": only functioning as a modifier of another entity because its text appears as an entry inside that other entity's all_modifying_information.,→ Be conservative: keep if ambiguous. === INPUT DESCRIPTIONS=== You receive a list of requirements in <"requirements">. Each item has: requirement_id, requirement_text, entities (list of objects). For each entity: id (int) text (string, entity's text) 153 Preprint. Under review. start (int, entity's start index in requirement_text) end (int, entity's end index in requirement_text) is_canonical_entity (bool) all_modifying_information (list[string]) --- natural-language modifiers about this entity # === INPUT === <requirement> REQUIREMENT </requirement> <new variable declarations before filter> NEW_VARIABLE_DECLARATIONS_BEFORE_FILTER </new variable declarations before filter> # === RULES === 4. Output JSON only. Do NOT include prose outside the JSON or any comments inside the JSON. 5. Scratchpad usage: Use the "scratchpad" field for THIS entity only. It must contain 2--4 compact bullets, each following the definitions below:,→ 1. Possibly modifies: Name the other entity in the requirement that this entity could be modifying (e.g., laterality``left′ modifies``breast metastasis′). If it does not modify anything and is a stand-alone subject, write NONE. ,→ ,→ 2. Evidence: Copy the minimal modifier fragment from the text that supports your judgment (e.g., "left" or "within 6 months"). Do not summarize --- use the raw phrase.,→ 3. Role: State whether this entity is functioning as a TOP-LEVEL subject (it stands on its own, e.g., a disease, procedure, or drug that is the subject of the requirement) OR as a MODIFIER (it qualifies some aspect of another entity, e.g., site, laterality, severity, timing, stage). ,→ ,→ 4. Verdict: Write only one of two words --- TOP-LEVEL if the entity is independent, or MODIFIER if it only qualifies another entity. This should be consistent with the Role.,→ # === OUTPUT === Return an array where each item corresponds to one input requirement: [ "variable_id": <variable id>, // integer, copied from input "span": "<copied exactly from input>", "variable_name": "<copied exactly from input>", "variable_meaning": "<copied exactly from input>", "type": "<copied exactly from input>>" "decisions": [ "scratchpad": "- Possibly modifies: <entity or NONE> - Evidence: \"<fragment>\" - Role: <TOP-LEVEL or MODIFIER> - Verdict: <TOP-LEVEL|MODIFIER>",,→ "KEEP": "YES" | "NO", "explanation": "<explain why you came to this decision>" ] // ... more variables ] F.1.31 SMT Programmer: Reusable Variable Identifier Purpose.This prompt identifies previously declared variables in the current SMT program that can be reused for the new requirement. Its goal is to preserve consistency across require- ments by reusing existing symbols whenever they already capture the needed meaning, rather than introducing unnecessary new variables. === ROLE === You are an expert SMT engineer and an experienced doctor. For the ONE eligibility requirement below, LIST ONLY variables that ALREADY exist in <smt_program_by_far> and are reusable to encode this requirement. Do NOT declare any new variables. ,→ ,→ === INPUT DESCRIPTIONS === 1. <smt_program_by_far>: this is the existing SMT Program. This is where you should be finding reusable variables for implementing the new <current_requirement> in SMT.,→ 2. <current_requirement>: this is the new requirement we want to translate to SMT. You should be analyzing what variables we need to implement the SMT version of this requirement and see if there exist any variables in <smt_program_by_far> with exactly the same semantic meanings you want that you can reuse. ,→ ,→ === INPUTS === <smt_program_by_far> #SMT_PROGRAM_BY_FAR# </smt_program_by_far> <current_requirement> #REQUIREMENT# </current_requirement> 154 Preprint. Under review. === GUIDELINES === 1. Identified reusable variables must exist <smt_program_by_far>. 2. Any reusable variable must have the same meaning as the corresponding intended variable to declare for implementing the new SMT constraint for <current_requirement>.,→ 3. Identify as many reusable variables as possible. === SCRATCHPAD STRUCTURE === You should be outputting a scratchpad before the list of reusable variables. Follow the following structure in writing the scratchpad.,→ 1. Enumerate exhaustively all variables needed to implement <current_requirement> in SMT. 2. For each variable you intend to declare, check if there are exisitng variables in <smt_program_by_far> that you can use to fulfill the exactly semantic meaning. Note that it is fine if the reusable variable has semantic meaning as a subset of the intended declaration - as long as there is a way to implement the SMT version of <current_requriement> with that variable, it should be counted as reusable. ,→ ,→ ,→ 3. Finalize the list of reusable variables. === OUTPUT === Output exactly the following three blocks. <scratchpad> is for writing the scratchpad, while <reusable_variable> is the json list for all reusable variables.,→ <scratchpad> ...scratchpad here... </scratchpad> <reusable_variables> [ "variable_name": "<name>", "variable_declaration":"(declare-const variable_name Bool) ;; "when_to_set_to_true"...... copy from <smt_program_by_far>" , "why": "<reuse rationale>" // Replace with your values, leave empty if no reusable variable. ,→ ,→ ] </reusable_variables> F.1.32 SMT Programmer: Translator Exclusion Purpose.This prompt translates a single exclusion requirement into SMT-LIB code. It generates the corresponding declarations and assertions using previously constructed variables, ensuring that the resulting logic faithfully encodes the requirementâ ̆ A ́ Zs meaning and integrates correctly with the existing SMT program. # === ROLE === You are an expert in SMT programming (with SMT-LIB) and bioinformatics. You job is to translate a single reqruiement from a clinical trial into Z3-compatible SMT-LIB code using canonical variable naming conventions and append it to a partial program.,→ You are a part of a pipeline of translating natural language eligibility criteria to SMT code for patient-trial matching.,→ # === BACKGROUND === You are being inputted with exclusion criteria. If an exclusion criteria is satisfied (i.e., has value True), the participant must be excluded. If an exclusion criteria is not satisfied (i.e., has value False), the participant may not be excluded (may be included). As SMT-LIB assumes a top-level AND across all assertions, you would need to wrap each top-level exclusion criteria assertion in a NOT to negate it. That is, the original requirements are connected by a NOT of OR, but we would love to cast it into an AND. ,→ ,→ ,→ ,→ # === MEANING OF THE SMT PROGRAM === With coded SMT assertions based on patient facts, the SMT-LIB program evaluates to SAT if a patient IS ELIGIBLE. # === GUIDELINES === 1. Never, never use ENUMS! Instead, always introduce one variable per atomic fact and use logical relationships to bridge them together.,→ 2. Variable Annotations a. After every declaration and after every assertion, add a comment that quotes the exact words from the requirement text that motivated that SMT line.,→ b. For each variable declaration, comment with a single JSON object on the same line. If the input <new_variable_declarations> already contains that declaration, use it verbatim---do not modify the declaration. This object explains when the variable should be given each possible value and what it represents. When commenting the object, make sure the comments are only based on the variable meaning and the variable, don't add any other information to the comment, since it change the variable meaning. ,→ ,→ ,→ ,→ -- For Boolean variables, include five keys: (1) when_to_set_to_true (2) when_to_set_to_false (3) when_to_set_to_null (4) meaning.,→ -- For numeric variables, include four keys: (1) when_to_set_to_value. (2) when_to_set_to_null (3) meaning. c. Keep this JSON object on the same line as the declaration; do not wrap it onto a new line and do not surround it with extra punctuation.,→ 3. Declare numeric variables as Real unless the unit implies integer counts. Note that whenever you can define a variable as Boolean / numeric variable, never define it as function.,→ 155 Preprint. Under review. 4. Note that the incoming variable set (in <reusable_variables> and <new_variable_declarations>) may not be complete. Whenever needed to preserve the original meaning of the requirement, you should declare new variables for your implmenetation, beyond what you receive as input. It is fine to declare more variables for the completeness of the meaning (unless you can already use the variables that are already present). ,→ ,→ ,→ 4.a Every variable you use should be declared! Make sure that the vaiable names map exactly to the meaning they encode.,→ 5. When declaring and using qualifier variables, make sure to preserve how they are inputted. The form of qualifier variable is entity_variable_declarations@@qualifier_snake_case. Note that the @@ part is to be strictly followed, and should never be replaced by other characters/separators. This form is to ease parsing and for making sure we later understand which entity a qualifier refers to. Also note that you don't have to use ALL qualifiers -- only use those that are meaningful. ,→ ,→ ,→ ,→ 5.a., Particularly, you should not be using variables that merely restate what has already been captured by the naming template. For example, if the naming template already states "inthehistory", then we don't need any timeframe qualifiers related to "prior", "in the history", "previous", unless they encode different meanings. ,→ ,→ 6. Assertion tagging (must match exactly) We have two type of assertions: 6.DEFINITION.(1) CONSTRAINT ASSERTIONS, which in most cases map to components we provide. These narrow down the pool of participants.,→ 6.DEFINITION.(2) AUXILIARY ASSERTIONS, which are definitional or linking assertions that do not narrow down the pool of participants. That is, they are here to clarify relationships; they don't implement the constraint components themselves. ONLY USE THOSE FOR ASSERTIONS THAT DONT COUNT AS CONSTRAINT ASSERTIONS! ,→ ,→ Here is the rules for tagging assertions for these two types of requirements, respectively: 6.TAGGING_RULE.(1) CONSTRAINT ASSERTIONS: <tagging_constraint_assertions> For every CONSTRAINT ASSERTION, you emit: (assert (! <boolean-or-numeric-term> :named REQREQ_IDX_COMPONENTCOMPONENT_IDX_CONSTRAINT)) Use REQ_IDX (0-based) from <requirement_index>. Start COMPONENT_IDX at 0 and increment within the same requirement. COMPONENT_IDX resets to 0 for each new requirement.,→ CONSTRAINT comes from the component's "constraint" label field, and the allowed set is OTHER_REQUIREMENTS or CAN_ALWAYS_GO_FROM_SATISFIED_TO_NOTSATISFIED.,→ </tagging_constraint_assertions> 6.TAGGING_RULE.(2) AUXILIARY ASSERTIONS: <tagging_auxiliary_assertions> For every AUXILIARY ASSERTION, you emit: (assert (! <boolean-or-numeric-term> :named REQREQ_IDX_AUXILIARYAUXILIARY_IDX)) Use REQ_IDX (0-based) from <requirement_index>. Start AUXILIARY_IDX at 0 and increment within the same requirement. AUXILIARY_IDX resets to 0 for each new requirement.,→ </tagging_auxiliary_assertions> 7. Preserve a one-to-one correspondence between requirement components and constraint assertions (explained below)! If multiple components are present in the requirement, implement assertions for all of them! Add whatever variables you need, but make sure that all components are implemented! ,→ ,→ 8. Be sure to preserve the original meaning of the requirement after translation. 9. Do not omit any detail! If a very long list exists, be sure to encode every entry!!!! One trick you can use is that you can first reiterate all the elements before the translation.,→ 10. After you implement each exclusion criteria, make sure to negate it with NOT as SMT-LIB assumes top-level AND. If there is very complicated logic, make sure you don't do logical transformations yourself. Just wrap an outermost NOT. ,→ ,→ 11. Declare all variables you will need to use that are not reusable from <reusable_variables>. Never declare variables that are in <reusable_variables>.,→ 12. Never draw any relationships between variables on your own!!!!! Only logic explicitly stated in the requirement should be implemented.,→ 13. For a Umbrella term followed by a list (e.g.,``such as,′``i.e.,′``e.g.,′``including,′``like′), before translating, classify the list as one of two types---even if earlier stages didn't label it explicitly:,→ 13.1 Exhaustive subcategories. The listed items fully enumerate the set under the umbrella; nothing outside the list qualifies.,→ SMT mapping: umbrella $≡$ (item1 $ $ item2 $ $ …) (use equivalence). Reference: <example_2_umbrella_exhaustive_subcategories>. 13.2 Non-exhaustive examples. The listed items are only examples; other items may also qualify. SMT mapping: (item1 $ $ item2 $ $ …) $ $ umbrella_subclass (use one-way implication, no equivalence).,→ Reference: <example_1_umbrella_non_exhaustive_examples>. 13.3 Ambiguous context. Default to non-exhaustive examples. 14. When the requirement provides a definition or explanatory equivalence for an entity, translate it as a definitional equality.,→ SMT mapping: define the target concept in terms of its stated conditions. Reference: <example_3_definition>. 15. Be sure to define all non-reusable variables you will use in assertions! 16. Use variables in <reusable_variables> and <new_variable_declarations> whenever suitable, but never use it in places that will cause semantic drift. For example, if the variable means has_finding_of_x_inthehistory, and the requirement says the patient has a PREVIOUS EPISODE of x, they are not the same thing, and the variable should not be used. Note that things that is not the current episode must have qualifier e.g., @@prior_to_current_episode. ,→ ,→ ,→ ,→ 156 Preprint. Under review. =================== OUTPUT FORMAT =================== Note that these examples are solely for the purpose of demonstration!!!!!!! You should be sticking to the input blocks for your own analysis. Think independently. Only use these as examples.,→ <example_1_umbrella_non_exhaustive_examples> <requirement_json_example_1> "requirement": "The patient is excluded if the patient has clinically significant cardiac disease with non-exhaustive examples (symptomatic coronary artery disease OR myocardial infarction within the last 12 months).", ,→ ,→ "components": [ "text": "The patient is excluded if the patient has clinically significant cardiac disease with non-exhaustive examples (symptomatic coronary artery disease OR myocardial infarction within the last 12 months).", ,→ ,→ "constraint": "OTHER_REQUIREMENTS" , ] </requirement_json_example_1> <reusable_variables_example_1> [] </reusable_variables_example_1> <new_variable_declarations_example_1> [ "patient_has_finding_of_heart_disease_now", "patient_has_finding_of_heart_disease_now@@clinically_significant", "patient_has_finding_of_coronary_arteriosclerosis_now", "patient_has_finding_of_coronary_arteriosclerosis_now@@symptomatic", "patient_has_finding_of_myocardial_infarction_inthepast12months" ] </new_variable_declarations_example_1> <smt_fragment_example_1> ;; ===================== Declarations for the exclusion criterion (REQ 5) ===================== (declare-const patient_has_finding_of_heart_disease_now Bool) ;; omitted for example (declare-const patient_has_finding_of_heart_disease_now@@clinically_significant Bool) ;; omitted for example (declare-const patient_has_finding_of_coronary_arteriosclerosis_now Bool) ;; omitted for example (declare-const patient_has_finding_of_coronary_arteriosclerosis_now@@symptomatic Bool) ;; omitted for example (declare-const patient_has_finding_of_myocardial_infarction_inthepast12months Bool) ;; omitted for example ;; ===================== Auxiliary Assertions (REQ 5) ===================== ;; Non-exhaustive examples imply umbrella term (assert (! (=> (or patient_has_finding_of_coronary_arteriosclerosis_now@@symptomatic patient_has_finding_of_myocardial_infarction_inthepast12months) patient_has_finding_of_heart_disease_now@@clinically_significant) :named REQ5_AUXILIARY0)) ;; "with non-exhaustive examples (symptomatic coronary artery disease OR myocardial infarction within the last 12 months)."",→ ;; Qualifier variables imply corresponding stem variables (assert (! (=> patient_has_finding_of_heart_disease_now@@clinically_significant patient_has_finding_of_heart_disease_now) :named REQ5_AUXILIARY1)) ;; ;; Qualifier variables imply corresponding stem variables (assert (! (=> patient_has_finding_of_coronary_arteriosclerosis_now@@symptomatic patient_has_finding_of_coronary_arteriosclerosis_now) :named REQ5_AUXILIARY2)) ;; ;; ===================== Constraint Assertions (REQ 5) ===================== (assert (! (not patient_has_finding_of_heart_disease_now@@clinically_significant) :named REQ5_COMPONENT0_OTHER_REQUIREMENTS)) ;; "clinically significant cardiac disease with non-exhaustive examples...",→ </smt_fragment_example_1> </example_1_umbrella_non_exhaustive_examples> <example_2_umbrella_exhaustive_subcategories> <requirement_json_example_2> "requirement": "The patient is excluded if the patient is being treated with drugs not permitted by the study protocol with exhaustive subcategories (A, B, or Class I antiarrhythmic agents (with non-exhaustive examples (C, D))).", ,→ ,→ "components": [ 157 Preprint. Under review. "text": "The patient is excluded if the patient is being treated with drugs not permitted by the study protocol with exhaustive subcategories (A, B, or Class I antiarrhythmic agents (with non-exhaustive examples (C, D))).", ,→ ,→ "constraint": "OTHER_REQUIREMENTS" ] </requirement_json_example_2> <reusable_variables_example_2> [] </reusable_variables_example_2> <new_variable_declarations_example_2> [ "patient_is_being_treated_with_nonpermitted_drug_now", "patient_is_being_treated_with_A_now", "patient_is_being_treated_with_B_now", "patient_is_being_treated_with_class_I_antiarrhythmic_agent_now", "patient_is_being_treated_with_drug_C_now", "patient_is_being_treated_with_drug_D_now" ] </new_variable_declarations_example_2> <smt_fragment_example_2> ;; ===================== Declarations for the exclusion criterion (REQ 1) ===================== (declare-const patient_is_being_treated_with_nonpermitted_drug_now Bool) ;; (declare-const patient_is_being_treated_with_A_now Bool) ;; (declare-const patient_is_being_treated_with_B_now Bool) ;; (declare-const patient_is_being_treated_with_class_I_antiarrhythmic_agent_now Bool) ;; (declare-const patient_is_being_treated_with_drug_C_now Bool) ;; (declare-const patient_is_being_treated_with_drug_D_now Bool) ;; ;; ===================== Auxiliary Assertions (REQ 1) ===================== ;; Exhaustive subcategories define the umbrella exactly: (assert (! (= patient_is_being_treated_with_nonpermitted_drug_now (or patient_is_being_treated_with_A_now patient_is_being_treated_with_B_now patient_is_being_treated_with_class_I_antiarrhythmic_agent_now)) :named REQ1_AUXILIARY0)) ;; Non-exhaustive examples imply the Class I subcategory (assert (! (=> (or patient_is_being_treated_with_drug_C_now patient_is_being_treated_with_drug_D_now) patient_is_being_treated_with_class_I_antiarrhythmic_agent_now) :named REQ1_AUXILIARY1)) ;; ===================== Constraint Assertions (REQ 1) ===================== ;; Exclusion: patient must NOT be on any not-permitted drug (as per exhaustive subcategories) (assert (! (not patient_is_being_treated_with_nonpermitted_drug_now) :named REQ1_COMPONENT0_OTHER_REQUIREMENTS)) </smt_fragment_example_2> </example_2_umbrella_exhaustive_subcategories> <example_3_definition> <requirement_json_example_3> "requirement": "The patient is excluded if the patient has severe shock ((systolic blood pressure < 90 mmHg) AND (duration > 30 minutes) AND (not corrected by fluid bolus)).",,→ "components": [ "text": "The patient is excluded if the patient has severe shock ((systolic blood pressure < 90 mmHg) AND (duration > 30 minutes) AND (not corrected by fluid bolus)).",,→ "constraint": "OTHER_REQUIREMENTS" ] </requirement_json_example_3> <reusable_variables_example_3> [] </reusable_variables_example_3> <new_variable_declarations_example_3> [ "patient_has_finding_of_shock_now", "patient_has_finding_of_shock_now@@severe", "patient_shock_corrected_by_fluid_bolus_now", "patient_shock_duration_value_recorded_now_in_minutes", 158 Preprint. Under review. "patient_systolic_blood_pressure_value_recorded_now_withunit_mmhg", ] </new_variable_declarations_example_3> <smt_fragment_example_3> ;; ===================== Declarations for the exclusion criterion (REQ 3) ===================== (declare-const patient_has_finding_of_shock_now Bool) ;; omitted for example ;; "shock" (declare-const patient_has_finding_of_shock_now@@severe Bool) ;; omitted for example ;; "severe shock" (declare-const patient_shock_corrected_by_fluid_bolus_now Bool) ;; omitted for example ;; "not corrected by fluid bolus",→ (declare-const patient_shock_duration_value_recorded_now_in_minutes Real) ;; omitted for example ;; "duration > 30 minutes",→ (declare-const patient_systolic_blood_pressure_value_recorded_now_withunit_mmhg Real) ;; omitted for example ;; "systolic blood pressure < 90 mmHg",→ ;; ===================== Auxiliary Assertions (REQ 3) ===================== ;; Definition in the requirement (assert (! (= patient_has_finding_of_shock_now@@severe (and (< patient_systolic_blood_pressure_value_recorded_now_withunit_mmhg 90) (> patient_shock_duration_value_recorded_now_in_minutes 30) (not patient_shock_corrected_by_fluid_bolus_now))) :named REQ3_AUXILIARY0)) ;; "severe shock = (systolic blood pressure < 90 mmHg) AND (duration > 30 minutes) AND (not corrected by fluid bolus)",→ ;; Qualifier variables imply corresponding stem variables (assert (! (=> patient_has_finding_of_shock_now@@severe patient_has_finding_of_shock_now) :named REQ5_AUXILIARY2)) ;; ;; ===================== Constraint Assertions (REQ 3) ===================== (assert (! (not patient_has_finding_of_shock_now@@severe) :named REQ3_COMPONENT0_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has severe shock ((systolic blood pressure < 90 mmHg) AND (duration > 30 minutes) AND (not corrected by fluid bolus)).",→ </smt_fragment_example_3> </example_3_definition> <example_4> <requirement_json_example_4> "requirement": "The patient is excluded if the patient was previously enrolled in the study during a prior hospitalization.",,→ "source": "A patient is excluded if the patient was previously enrolled in the study during prior hospitalization (for multiple admissions; only data from the first admission will be used).",,→ "components": [ "text": "The patient is excluded if the patient was previously enrolled in the study during a prior hospitalization.",,→ "constraint": "OTHER_REQUIREMENTS" ] </requirement_json_example_4> <reusable_variables_example_4> [] </reusable_variables_example_4> <new_variable_declarations_example_4> [ "span": "previously enrolled in the study during a prior hospitalization", "variable_name": "patient_was_previously_enrolled_in_study", "variable_meaning": "Indicates whether the patient was previously enrolled in the study during any prior hospitalization.",→ ] </new_variable_declarations_example_4> <smt_fragment_example_4> ;; Declare variable for the exclusion criterion (declare-const patien_was_previously_enrolled_in_study Bool) ;; omitted for example ;; ===================== Constraint Assertions (REQ 7) ===================== (assert 159 Preprint. Under review. (! (not patient_was_previously_enrolled_in_study) :named REQ7_COMPONENT0_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient was previously enrolled in the study during a prior hospitalization.",→ </smt_fragment_example_4> </example_4> # === INPUTS === <requirement_json> #REQUIREMENT# </requirement_json> <reusable_variables> #REUSABLE_VARIABLES# </reusable_variables> <new_variable_declarations> #NEW_VARIABLE_DECLARATIONS# </new_variable_declarations> ;; Note that The SMT assertion shold use variables defined in <new_variable_declarations> as much as possible. That is, whenever we want to express meanings that are able to be covered by variables in <new_variable_declarations>>, we always use variables in <new_variable_declarations>>. ,→ ,→ <requirement_index> #REQ_IDX# </requirement_index> =================== OUTPUT =================== Output the new SMT snippet in the following one, contiguous block of <smtfragment>. Be sure to follow SMT-LIB format. <smtfragment> ...SMT Program (declarations and assertions) here.. // Always prefer using booleans and numeric first for encoding a single fact,→ </smtfragment> F.1.33 SMT Programmer: Translator Inclusion Purpose.This prompt translates a single inclusion requirement into SMT-LIB code. It generates the corresponding declarations and assertions using available variables, ensuring that the resulting logic faithfully encodes the requirementâ ̆ A ́ Zs meaning and integrates correctly with the existing SMT program. # === ROLE === You are an expert in SMT programming (with SMT-LIB) and bioinformatics. You job is to translate a single reqruiement from a clinical trial into Z3-compatible SMT-LIB code using canonical variable naming conventions and append it to a partial program.,→ You are a part of a pipeline of translating natural language eligibility criteria to SMT code for patient-trial matching.,→ # === BACKGROUND === You are being inputted with inclusion criteria. If an inclusion criteria is satisfied (i.e., has value True), the participant may be included. If an inclusion criteria is not satisfied (i.e., has value False), the participant is not included. For inclusion criteria, the SMT-LIB language already works seamlessly, as SMT-LIB assumes a top-level AND. ,→ ,→ ,→ # === MEANING OF THE SMT PROGRAM === With coded SMT assertions based on patient facts, the SMT-LIB program evaluates to SAT if a patient IS ELIGIBLE. # === GUIDELINES === 1. Never, never use ENUMS! Instead, always introduce one variable per atomic fact and use logical relationships to bridge them together.,→ 2. Variable Annotations a. After every declaration and after every assertion, add a comment that quotes the exact words from the requirement text that motivated that SMT line.,→ b. For each variable declaration, comment with a single JSON object on the same line. If the input <new_variable_declarations> already contains that declaration, use it verbatim---do not modify the declaration. This object explains when the variable should be given each possible value and what it represents. When commenting the object, make sure the comments are only based on the variable meaning and the variable, don't add any other information to the comment, since it change the variable meaning. ,→ ,→ ,→ ,→ -- For Boolean variables, include five keys: (1) when_to_set_to_true (2) when_to_set_to_false (3) when_to_set_to_null (4) meaning.,→ -- For numeric variables, include four keys: (1) when_to_set_to_value. (2) when_to_set_to_null (3) meaning. c. Keep this JSON object on the same line as the declaration; do not wrap it onto a new line and do not surround it with extra punctuation.,→ 160 Preprint. Under review. 3. Declare numeric variables as Real unless the unit implies integer counts. Note that whenever you can define a variable as Boolean / numeric variable, never define it as function.,→ 4. Note that the incoming variable set (in <reusable_variables> and <new_variable_declarations>) may not be enough. Whenever needed to preserve the original meaning of the requirement, you should declare new variables for your implmenetation, beyond what you receive as input. It is fine to declare more variables for the completeness of the meaning. ,→ ,→ ,→ 4.a Every variable you use should be declared! Make sure that the vaiable names map exactly to the meaning they encode.,→ 5. When declaring and using qualifier variables, make sure to preserve how they are inputted. The form of qualifier variable is entity_variable_declarations@@qualifier_snake_case. Note that the @@ part is to be strictly followed, and should never be replaced by other characters/separators. This form is to ease parsing and for making sure we later understand which entity a qualifier refers to. Also note that you don't have to use ALL qualifiers -- only use those that are meaningful. ,→ ,→ ,→ ,→ 5.a., Particularly, you should not be using variables that merely restate what has already been captured by the naming template. For example, if the naming template already states "inthehistory", then we don't need any timeframe qualifiers related to "prior", "in the history", "previous", unless they encode different meanings. ,→ ,→ 6. Assertion tagging (must match exactly) We have two type of assertions: 6.DEFINITION.(1) CONSTRAINT ASSERTIONS, which in most cases map to components we provide. These narrow down the pool of participants.,→ 6.DEFINITION.(2) AUXILIARY ASSERTIONS, which are definitional or linking assertions that do not narrow down the pool of participants. That is, they are here to clarify relationships; they don't implement the constraint components themselves. ,→ ,→ Here is the rules for tagging assertions for these two types of requirements, respectively: 6.TAGGING_RULE.(1) CONSTRAINT ASSERTIONS: <tagging_constraint_assertions> For every CONSTRAINT ASSERTION, you emit: (assert (! <boolean-or-numeric-term> :named REQREQ_IDX_COMPONENTCOMPONENT_IDX_CONSTRAINT)) Use REQ_IDX (0-based) from <requirement_index>. Start COMPONENT_IDX at 0 and increment within the same requirement. COMPONENT_IDX resets to 0 for each new requirement.,→ CONSTRAINT comes from the component's "constraint" label field, and the allowed set is OTHER_REQUIREMENTS or CAN_ALWAYS_GO_FROM_SATISFIED_TO_NOTSATISFIED.,→ </tagging_constraint_assertions> 6.TAGGING_RULE.(2) AUXILIARY ASSERTIONS: <tagging_auxiliary_assertions> For every AUXILIARY ASSERTION, you emit: (assert (! <boolean-or-numeric-term> :named REQREQ_IDX_AUXILIARYAUXILIARY_IDX)) Use REQ_IDX (0-based) from <requirement_index>. Start AUXILIARY_IDX at 0 and increment within the same requirement. AUXILIARY_IDX resets to 0 for each new requirement.,→ </tagging_auxiliary_assertions> 7. Preserve a one-to-one correspondence between requirement components and constraint assertions (explained below)! If multiple components are present in the requirement, implement assertions for all of them! Add whatever variables you need, but make sure that all components are implemented! ,→ ,→ 8. Be sure to preserve the original meaning of the requirement after translation. 9. Do not omit any detail! If a very long list exists, be sure to encode every entry!!!! One trick you can use is that you can first reiterate all the elements before the translation.,→ 10. Declare all variables you will need to use that are not reusable from <reusable_variables>. Never declare variables that are in <reusable_variables>.,→ 11. Never draw any relationships between variables on your own!!!!! Only logic explicitly stated in the requirement should be implemented.,→ 12. For a Umbrella term followed by a list (e.g.,``such as,′``i.e.,′``e.g.,′``including,′``like′), before translating, classify the list as one of two types---even if earlier stages didn't label it explicitly:,→ 12.1 Exhaustive subcategories. The listed items fully enumerate the set under the umbrella; nothing outside the list qualifies.,→ SMT mapping: umbrella $≡$ (item1 $ $ item2 $ $ …) (use equivalence). Reference: <example_2_umbrella_exhaustive_subcategories_vs_umbrella_non_exhaustive_examples>. 12.2 Non-exhaustive examples. The listed items are only examples; other items may also qualify. SMT mapping: (item1 $ $ item2 $ $ …) $ $ umbrella_subclass (use one-way implication, no equivalence).,→ Reference: <example_2_umbrella_exhaustive_subcategories_vs_umbrella_non_exhaustive_examples>. 12.3 Ambiguous context. Default to non-exhaustive examples. 13. When the requirement provides a definition or explanatory equivalence for an entity, translate it as a definitional equality.,→ SMT mapping: define the target concept in terms of its stated conditions. Reference: <example_1>. 14. Be sure to define all non-reusable variables you will use in assertions! 15. Use variables in <reusable_variables> and <new_variable_declarations> maximally. Even when you are trying to define new variables, prioritize using these variables and add qualifiers to them (through @@<qualifier>), instead of coming up with a completely new variable. Note everything that you want to write as like "patient_has_current_finding_of_x" should be written as canonicalized expressions like "patient_has_finding_of_x_now". ,→ ,→ ,→ ,→ =================== OUTPUT FORMAT =================== 161 Preprint. Under review. Note that these examples are solely for the purpose of demonstration!!!!!!! You should be sticking to the input blocks for your own analysis. Think independently. Only use these as examples.,→ <example_1> <requirement_json_example_1> "requirement": "To be included, the patient must exhibit at least two of the following clinical symptoms of pneumonia on history OR physical examination: Cough, Production of purulent sputum or change in character of sputum, Auscultatory findings on pulmonary examination of rales or evidence of pulmonary consolidation (dullness to percussion, bronchial breath sounds, or egophony), Dyspnea or tachypnea, Documented fever, defined as body temperature >38.0 $ $C (100.4 $ $F) taken orally; >38.5 $ $C (101.2 $ $F) tympanically; or >39.0 $ $C (102.2 $ $F) rectally or hypothermia, defined as core body temperature of <35.0 $ $C (95.0 $ $F) ,→ ,→ ,→ ,→ ,→ ,→ "source": "...", "components": [ "text": "...same as requirement...", "constraint": "PRESCREEN_NOTES_MUST_COMPLETELY_SUFFICE" ] </requirement_json_example_1> <reusable_variables_example_1> [] </reusable_variables_example_1> <new_variable_declarations_example_1> [ "patient_has_symptoms_of_pneumonia_now", "patient_has_symptoms_of_cough_now", "patient_has_symptoms_of_purulent_sputum_now", "patient_has_symptoms_of_change_in_character_of_sputum_now", "patient_has_symptoms_of_rales_now", "patient_has_symptoms_of_lung_consolidation_now", "patient_has_symptoms_of_dullness_to_percussion_now", "patient_has_symptoms_of_bronchial_breath_sounds_now", "patient_has_symptoms_of_egophony_now", "patient_has_symptoms_of_dyspnea_now", "patient_has_symptoms_of_tachypnea_now", "patient_has_finding_of_fever_now", "patient_oral_body_temperature_value_recorded_now_withunit_celsius", "patient_rectal_body_temperature_value_recorded_now_withunit_celsius", "patient_tympanic_body_temperature_value_recorded_now_withunit_celsius", "patient_has_finding_of_hypothermia_now", "patient_core_body_temperature_value_recorded_now_withunit_celsius", ] </new_variable_declarations_example_1> <smtfragment_example_1> ;; ===================== Declarations for the criterion (REQ 3) ===================== (omitted for example) ;; ===================== Auxiliary Assertions (REQ 3) ===================== ;; Definition in the requirement (assert (! (= patient_has_finding_of_fever_now (or (> patient_oral_body_temperature_value_recorded_now_withunit_celsius 38.0) (> patient_tympanic_body_temperature_value_recorded_now_withunit_celsius 38.5) (> patient_rectal_body_temperature_value_recorded_now_withunit_celsius 39.0))) :named REQ3_AUXILIARY0)) ;; Definition in the requirement (assert (! (= patient_has_finding_of_hypothermia_now (< patient_core_body_temperature_value_recorded_now_withunit_celsius 35.0)) :named REQ3_AUXILIARY1)) ;; Non-exhaustive examples imply umbrella term (assert (! (=> (or patient_has_symptoms_of_dullness_to_percussion_now patient_has_symptoms_of_bronchial_breath_sounds_now patient_has_symptoms_of_egophony_now) patient_has_symptoms_of_lung_consolidation_now) :named REQ3_AUXILIARY2)) (define-fun symptoms_count () Int (+ (ite patient_has_symptoms_of_cough_now 1 0) 162 Preprint. Under review. (ite (or patient_has_symptoms_of_purulent_sputum_now patient_has_symptoms_of_change_in_character_of_sputum_now) 1 0) (ite (or patient_has_symptoms_of_rales_now patient_has_symptoms_of_lung_consolidation_now) 1 0) (ite (or patient_has_symptoms_of_dyspnea_now patient_has_symptoms_of_tachypnea_now) 1 0) (ite (or patient_has_finding_of_fever_now patient_has_finding_of_hypothermia_now) 1 0))) (assert (! (=> (>= symptoms_count 2) patient_has_symptoms_of_pneumonia_now) :named REQ3_AUXILIARY3)) ;; ===================== Constraint Assertions (REQ 3) ===================== (assert (! (>= symptoms_count 2) :named COMPONENT0_PRESCREEN_NOTES_MUST_COMPLETELY_SUFFICE)) </smtfragment_example_1> </example_1> <example_2_umbrella_exhaustive_subcategories_vs_umbrella_non_exhaustive_examples> <requirement_json_example_2> "requirement": "The patient is included if the patient is being treated with drugs permitted by the study protocol with exhaustive subcategories (A, B, or Class I antiarrhythmic agents (with non-exhaustive examples (C, D))).", ,→ ,→ "components": [ "text": "The patient is included if the patient is being treated with drugs permitted by the study protocol with exhaustive subcategories (A, B, or Class I antiarrhythmic agents (with non-exhaustive examples (C, D))).", ,→ ,→ "constraint": "OTHER_REQUIREMENTS" ] </requirement_json_example_2> <reusable_variables_example_2> [] </reusable_variables_example_2> <new_variable_declarations_example_2> [ "patient_is_being_treated_with_permitted_drug_now", "patient_is_being_treated_with_A_now", "patient_is_being_treated_with_B_now", "patient_is_being_treated_with_class_I_antiarrhythmic_agent_now", "patient_is_being_treated_with_drug_C_now", "patient_is_being_treated_with_drug_D_now" ] </new_variable_declarations_example_2> <smt_fragment_example_2> ;; ===================== Declarations for the inclusion criterion (REQ 1) ===================== (declare-const patient_is_being_treated_with_permitted_drug_now Bool) ;; umbrella (permitted) (declare-const patient_is_being_treated_with_A_now Bool) ;; exhaustive subcategory A (declare-const patient_is_being_treated_with_B_now Bool) ;; exhaustive subcategory B (declare-const patient_is_being_treated_with_class_I_antiarrhythmic_agent_now Bool) ;; exhaustive subcategory: Class I A,→ (declare-const patient_is_being_treated_with_drug_C_now Bool) (declare-const patient_is_being_treated_with_drug_D_now Bool) ;; ===================== Auxiliary Assertions (REQ 1) ===================== ;; Exhaustive subcategories define the umbrella exactly: (assert (! (= patient_is_being_treated_with_permitted_drug_now (or patient_is_being_treated_with_A_now patient_is_being_treated_with_B_now patient_is_being_treated_with_class_I_antiarrhythmic_agent_now)) :named REQ1_AUXILIARY0)) ;; Non-exhaustive examples imply the Class I subcategory (assert (! (=> (or patient_is_being_treated_with_drug_C_now patient_is_being_treated_with_drug_D_now) patient_is_being_treated_with_class_I_antiarrhythmic_agent_now) :named REQ1_AUXILIARY1)) ;; ===================== Constraint Assertions (REQ 1) ===================== ;; Inclusion: patient MUST be on a permitted drug (as per exhaustive subcategories) 163 Preprint. Under review. (assert (! patient_is_being_treated_with_permitted_drug_now :named REQ1_COMPONENT0_OTHER_REQUIREMENTS)) </smt_fragment_example_2> </example_2_umbrella_exhaustive_subcategories_vs_umbrella_non_exhaustive_examples> <example_3> <requirement_json_example_3> "requirement": "To be included, the patient must have histologically verified adenocarcinoma of the esophagus (according to the Union for International Cancer Control (UICC) definition, Tumor Node Metastasis (TNM) classification, 7th edition).", ,→ ,→ "source": "To be included, a patient must have histologically verified adenocarcinoma of the esophagus according to the UICC definition (TNM7).",,→ "components": [ "text": "To be included, the patient must have histologically verified adenocarcinoma of the esophagus (according to the Union for International Cancer Control (UICC) definition, Tumor Node Metastasis (TNM) classification, 7th edition).", ,→ ,→ "constraint": "PRESCREEN_NOTES_MUST_COMPLETELY_SUFFICE" , ] </requirement_json_example_3> <new_variable_declarations_example_3> [ "span": "adenocarcinoma of the esophagus", "variable_name": "patient_has_finding_of_adenocarcinoma_of_esophagus_now", "variable_meaning": "Boolean clinical finding indicating the patient currently has adenocarcinoma of the esophagus.",→ , "span": "", "variable_name": "patient_has_finding_of_adenocarcinoma_of_esophagus_now@@histologically_verified", "variable_meaning": "Indicates that the adenocarcinoma of the esophagus is histologically verified." , "span": "", "variable_name": "patient_has_finding_of_adenocarcinoma_of_esophagus_now@@uicc_definition_tnm_classification_7th_edition",,→ "variable_meaning": "Indicates that the adenocarcinoma of the esophagus is defined according to the UICC definition, TNM classification, 7th edition.",→ ] </new_variable_declarations_example_3> <smtfragment_example_3> ;; ===================== Declarations for the criterion (REQ 0) ===================== (declare-const patient_has_finding_of_adenocarcinoma_of_esophagus_now Bool) ;; ... (declare-const patient_has_finding_of_adenocarcinoma_of_esophagus_now@@histologically_verified Bool) ;; ... (declare-const patient_has_finding_of_adenocarcinoma_of_esophagus_now@@uicc_definition_tnm_classification_7th_edition Bool) ;;... ,→ ,→ ;; ===================== Auxiliary Assertions (REQ 0) ===================== ;; Qualifier variables imply corresponding stem variables (assert (! (=> patient_has_finding_of_adenocarcinoma_of_esophagus_now@@histologically_verified patient_has_finding_of_adenocarcinoma_of_esophagus_now) :named REQ0_AUXILIARY0)) ;; ;; Qualifier variables imply corresponding stem variables (assert (! (=> patient_has_finding_of_adenocarcinoma_of_esophagus_now@@uicc_definition_tnm_classification_7th_edition patient_has_finding_of_adenocarcinoma_of_esophagus_now) :named REQ0_AUXILIARY1)) ;; ;; ===================== Constraint Assertions (REQ 0) ===================== ;; Component 0 (assert (! (and patient_has_finding_of_adenocarcinoma_of_esophagus_now@@histologically_verified patient_has_finding_of_adenocarcinoma_of_esophagus_now@@uicc_definition_tnm_classification_7th_edition) :named REQ0_COMPONENT0_NEED_TO_BE_STRICTLY_ENFORCED_IN_INFORMATION_RETRIEVAL)) ;; </smtfragment_example_3> </example_3> # === INPUTS === 164 Preprint. Under review. <requirement_json> #REQUIREMENT# </requirement_json> <reusable_variables> #REUSABLE_VARIABLES# </reusable_variables> <new_variable_declarations> #NEW_VARIABLE_DECLARATIONS# </new_variable_declarations> ;; Note that The SMT assertion shold use variables defined in <new_variable_declarations> as much as possible. That is, whenever we want to express meanings that are able to be covered by variables in <new_variable_declarations>>, we always use variables in <new_variable_declarations>>. ,→ ,→ <requirement_index> #REQ_IDX# </requirement_index> =================== OUTPUT =================== Output the new SMT snippet in the following one, contiguous block of <smtfragment>. Be sure to follow SMT-LIB format. MAKE SURE YOU DEFINE ALL VARIABLES YOU NEED! Use ;; as prefix for comments. ; Use this exact pattern: (assert (! <BOOLEAN-OR-NUMERIC-TERM> :named REQ<REQ_IDX>_<KIND><IDX>_<TAG>)) <variable_planning> ...Plan all variables you need here... </variable_planning> <smtfragment> ;; all declarations you need to implement the assertions, make sure to define all variables you need. ... ;; all assertions you are implemeting ... </smtfragment> F.1.34 SMT Programmer: Verifier Exclusion Purpose.This prompt verifies that the generated SMT fragment for an exclusion re- quirement faithfully captures the original meaning. It checks semantic correctness, polarity, completeness of entities and qualifiers, and consistency with existing variables before the fragment is accepted into the program. # === ROLE === You are an expert formal-methods auditor. # === TASK ==== We are translating natural language criteria in clinical-trial eligibility criteria incrementally. You are given: - the criterion text (<requirement_to_translate>) - the candidate SMT snippet (<candidate_smt_snippet>) - the canonicalizable variable list (<canonicalizable_variable_list>) - the current existing declared variables (<partial_program>) Verify the snippet against EVERY checklist item and report the results. # === BACKGROUND === You are being inputted with exclusion criteria. If an exclusion criteria is satisfied (i.e., has value True), the participant must be excluded. If an exclusion criteria is not satisfied (i.e., has value False), the participant may not be excluded (may be included). As SMT-LIB assumes a top-level AND across all assertions, you would need to wrap each top-level exclusion criteria assertion in a NOT to negate it. That is, the original requirements are connected by a NOT of OR, but we would love to cast it into an AND. ,→ ,→ ,→ ,→ # === INPUT DESCRIPTION === 1. <requirement_to_translate> is the current requirement to translate into SMT snippet to be appended to the existing declared variables (<partial_program>).,→ 2. <candidate_smt_snippet> is the candidate SMT snippet we translated from <requirement_to_translate>: if it passes the checks it will be appeneded to <partial_program>.,→ 165 Preprint. Under review. 3. <canonicalizable_variable_list> is the list of canonical variables the SMT translation can choose from. The SMT snippet does not necessarily have to use all variables in this list, but should use variables in the list whenever it can (i.e,. has to use the meaning of these variables). ,→ ,→ 4. <partial_program> is the existing declared variables for all previous requirements in the eligibility criteria section of the clinical trial.,→ === NAMING SYSTEM / NAMING TEMPLATES === Stems (lowercase snake_case; strip punctuation; numerals normalized). The timeframe token MUST appear exactly once inside the stem and match the "timeframe" field.,→ <stems_templates> Finding: <stems_templates::findings> patient_has_diagnosis_of_entity_canonical_form_timeframe | patient_has_finding_of_entity_canonical_form_timeframe | patient_has_symptoms_of_entity_canonical_form_timeframe | patient_has_clinical_signs_of_entity_canonical_form_timeframe | patient_has_suspicion_of_entity_canonical_form_timeframe </stems_templates::findings> Procedure: <stems_templates::procedures> patient_has_undergone_entity_canonical_form_timeframe | patient_has_undergone_entity_canonical_form_timeframe_outcome_is_positive | patient_has_undergone_entity_canonical_form_timeframe_outcome_is_negative | patient_has_undergone_entity_canonical_form_timeframe_outcome_is_normal | patient_has_undergone_entity_canonical_form_timeframe_outcome_is_abnormal | patient_is_undergoing_entity_canonical_form_timeframe | patient_will_undergo_entity_canonical_form_timeframe | patient_can_undergo_entity_canonical_form_timeframe | </stems_templates::procedures> Observable Entities (numeric): <stems_templates::observable_entities_numeric> patient_entity_canonical_form_value_recorded_timeframe_withunit_unit </stems_templates::observable_entities_numeric> Product: <stems_templates::product> patient_is_taking_entity_canonical_form_timeframe | patient_has_taken_entity_canonical_form_timeframe | patient_has_hypersensitivity_to_entity_canonical_form_timeframe | patient_has_intolerance_to_entity_canonical_form_timeframe | patient_has_allergy_to_entity_canonical_form_timeframe | patient_has_nonimmune_hypersensitivity_to_entity_canonical_form_timeframe | </stems_templates::product> Substance: <stems_templates::substance> patient_is_exposed_to_entity_canonical_form_timeframe | patient_has_hypersensitivity_to_entity_canonical_form_timeframe | patient_has_intolerance_to_entity_canonical_form_timeframe | patient_has_allergy_to_entity_canonical_form_timeframe | patient_has_nonimmune_hypersensitivity_to_entity_canonical_form_timeframe | </stems_templates::substance> </stems_templates> <timeframe> Timeframe : now | inthehistory | inthefuture | inthepastnunits | inthefuturenunits | foradurationofnunits,→ Time Units: minutes | hours | days | weeks | months | years </timeframe> <qualifiers> Attach with: stem@@qualifier_snake_case Qualifiers must NOT repeat timeframe/value/unit; they encode leftover semantics (e.g., temporal anchors other than``today′, context like``at baseline′, or dependencies like``after percutaneous coronary intervention′). Use qualifiers sparingly and ONLY when needed for later assertions. ,→ ,→ </qualifiers> # === CHECKLIST === 1. MEANING_FAITHFULNESS. The SMT fragment <candidate_smt_snippet> faithfully encodes the natural-language requirement <requirement_to_translate>. Note that you should allow for some imperfections in the code as long as the meaning is kept equivalent. ,→ ,→ 1.a., for example, it is perfectly viable to define two separate variables for one value for cases such as the upper bound and lower bound are defined in different units.,→ 2. ENTITY_AND_QUALIFIER_COMPLETENESSS: No meaningful entity or qualifier is missing. 166 Preprint. Under review. 3. NO_VARIABLE_DUPLICATION: The snippet introduces no symbol with meaning that duplicates one already present in the partial program.,→ 4. POLARITY_CORRECTNESS. If the snippet (<candidate_smt_snippet>) evaluates to SAT, then the patient MAY BE INCLUDED. If the snippet (<candidate_smt_snippet>) evaluates to UNSAT, the patient IS EXCLUDED.,→ 5. VARIABLE_NAME_VERBATIMNESS: Variable names and their definitions EXACTLY match up. Note ths has nothing to do with the <canonicalizable_variable_list>,→ 6. USE_CANONICALIZABLE_LIST_AS_MUCH_AS_POSSIBLE: The SMT assertion used variables defined in <canonicalizable_variable_list> as much as possible. That is, whenever we want to express meanings that are able to be covered by variables in <canonicalizable_variable_list>, we always use variables in <canonicalizable_variable_list>. ,→ ,→ ,→ 6.a., !!!!! Note that it is FINE for the SMT program to use variables that are NOT in the list. 6.b., !!!!! Also note that the only source of truth for this is <canonicalizable_variable_list>. 7. QUALIFIER_ENTITY_RELATIONSHIPS_CAPTURED: Note this applies to ALL variables in the SMT implemetation. Make sure that qualifiers of entities are not defined independently without specifying what entity it refers to (i.e., without using the stem@@qualifier template). Anything that narrows or qualifies the entity counts as a qualifier span. Qualifier span can cover etiology, disease course, anatomical site, morphology, stage, severity, and so on. ,→ ,→ ,→ ,→ 8. OVEARLL_OK: If all of the above checklists are true. # === EXAMPLES === <example_polarity_1> <requirement_to_translate> The patient is excluded if the patient has (previous enrollment in this study) OR (previous treatment with telithromycin). </requirement_to_translate> <candidate_smt_snippet> ;; Declare variable for previous enrollment in this study (declare-const has_previous_enrollment_in_this_study Bool) ;; "when_to_set_to_true":"Set to true iff the patient has previously enrolled in this study.","when_to_set_to_false":"Set to false iff the patient has not previously enrolled in this study.","when_to_set_to_null":"Never set to null.","meaning":"The patient has previously enrolled in this study.","use_variable_from_new_variable_declarations": false ;; "The patient is excluded if the patient has previous enrollment in this study." ;; Declare variable for previous treatment with telithromycin (declare-const is_exposed_to_telithromycin_inthehistory Bool) ;; "when_to_set_to_true":"Set to true iff the patient has been exposed to telithromycin in the past.","when_to_set_to_false":"Set to false iff the patient has not been exposed to telithromycin in the past.","when_to_set_to_null":"Never set to null.","meaning":"The patient has been exposed to telithromycin in the past.","use_variable_from_new_variable_declarations": true ;; "The patient is excluded if the patient has previous treatment with telithromycin." ;; ===================== Constraint Assertions (REQ 14) ===================== (assert (! (not has_previous_enrollment_in_this_study) :named REQ14_COMPONENT0_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has previous enrollment in this study." (assert (! (not is_exposed_to_telithromycin_inthehistory) :named REQ14_COMPONENT1_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has previous treatment with telithromycin." </candidate_smt_snippet> ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ <output> "MEANING_FAITHFULNESS": true, "ENTITY_AND_QUALIFIER_COMPLETENESSS": true, "NO_VARIABLE_DUPLICATION": true, "POLARITY_CORRECTNESS": true, "VARIABLE_NAME_VERBATIMNESS": true, "variables_in_canonicalizble_variable_list": "...", "USE_CANONICALIZABLE_LIST_AS_MUCH_AS_POSSIBLE": true, "QUALIFIER_ENTITY_RELATIONSHIPS_CAPTURED": true, "OVEARLL_OK": true, "explanations": "MEANING_FAITHFULNESS": "The NL requirement is an OR of two exclusion conditions. The snippet negates each atom separately ((not A) and (not B)), which is equivalent to $ $(A$ $B) under the top-level AND convention, preserving meaning.", ,→ ,→ "ENTITY_AND_QUALIFIER_COMPLETENESSS": "Both atoms are represented: prior enrollment (captured in the stem) and prior telithromycin treatment (captured as exposure with timeframe'inthehistory'). No additional qualifiers are implied by the text.", ,→ ,→ "NO_VARIABLE_DUPLICATION": "Neither has_previous_enrollment_in_this_study nor is_exposed_to_telithromycin_inthehistory is declared elsewhere in the provided partial program; no redeclarations detected.", ,→ ,→ "POLARITY_CORRECTNESS": "Because each exclusion atom appears under NOT, SAT implies the patient lacks both conditions (hence may be included), and UNSAT occurs if either exclusion holds.",,→ "VARIABLE_NAME_VERBATIMNESS": "Names match their meanings:'has_previous_enrollment_in_this_study' $ $ previously enrolled in this study;'is_exposed_to_telithromycin_inthehistory' $ $ previously treated/exposed.", ,→ ,→ "USE_CANONICALIZABLE_LIST_AS_MUCH_AS_POSSIBLE": "The telithromycin variable exactly matches the canonicalizable entry and is used. The enrollment concept has no canonicalizable entry, so a new variable is appropriate.",,→ "OVEARLL_OK": "All checklist items pass; the snippet is semantically correct, uses canonical variables where available, and follows exclusion-as-NOT conventions.",→ </output> </example_polarity_1> <example_polarity_2> <requirement_to_translate> The patient is excluded if the patient does NOT have cognitive impairment based on cognitive screening at the time of hospital admission.,→ </requirement_to_translate> 167 Preprint. Under review. <candidate_smt_snippet> ;; Declare variables for the exclusion criteria (declare-const patient_has_finding_of_impaired_cognition_now Bool) ;; "when_to_set_to_true":"Set to true iff the patient has cognitive impairment at the current time.","when_to_set_to_false":"Set to false iff the patient does not have cognitive impairment at the current time.","when_to_set_to_null":"Never set to null.","meaning":"The patient has cognitive impairment.","use_variable_from_new_variable_declarations": true ;; "cognitive impairment" ,→ ,→ ,→ ,→ (declare-const patient_has_finding_of_impaired_cognition_now@@based_on_cognitive_screening_at_hospital_admission Bool) ;; "when_to_set_to_true":"Set to true iff the cognitive impairment is determined based on cognitive screening at the time of hospital admission.","when_to_set_to_false":"Set to false iff the cognitive impairment is not determined based on cognitive screening at the time of hospital admission.","when_to_set_to_null":"Never set to null.","meaning":"The cognitive impairment is determined based on cognitive screening at the time of hospital admission.","use_variable_from_new_variable_declarations": true ;; "based on cognitive screening at the time of hospital admission" ,→ ,→ ,→ ,→ ,→ ,→ ;; ===================== Auxiliary Assertions (REQ 6) ===================== (assert (! (=> patient_has_finding_of_impaired_cognition_now@@based_on_cognitive_screening_at_hospital_admission patient_has_finding_of_impaired_cognition_now) :named REQ6_AUXILIARY0)) ;; "If impairment is determined by admission screening, impairment holds." ;; ===================== Constraint Assertions (REQ 6) ===================== ;; Exclusion predicate E = (not Q), where Q := qualified impairment at admission screening. ;; Encode AND-of-NOT by asserting (not E) = (not (not Q)) $≡$ Q. (assert (! (not (not patient_has_finding_of_impaired_cognition_now@@based_on_cognitive_screening_at_hospital_admission)) :named REQ6_COMPONENT0_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient does NOT have cognitive impairment based on admission screening.",→ </candidate_smt_snippet> <output> "MEANING_FAITHFULNESS": true, "ENTITY_AND_QUALIFIER_COMPLETENESSS": true, "NO_VARIABLE_DUPLICATION": true, "POLARITY_CORRECTNESS": true, "VARIABLE_NAME_VERBATIMNESS": true, "variables_in_canonicalizble_variable_list": "has_finding_of_impaired_cognition_now (allowed qualifier: @@based_on_cognitive_screening_at_hospital_admission)", "all_variables_used_in_the_smt_snippet": "has_finding_of_impaired_cognition_now; has_finding_of_impaired_cognition_now@@based_on_cognitive_screening_at_hospital_admission", "USE_CANONICALIZABLE_LIST_AS_MUCH_AS_POSSIBLE": true, "QUALIFIER_ENTITY_RELATIONSHIPS_CAPTURED": true, "OVEARLL_OK": true, "explanations": "MEANING_FAITHFULNESS": "Let Q be'impaired cognition based on admission screening'. The NL exclusion is E := $ $Q. The snippet asserts $ $E = $ $($ $Q) = Q, which is equivalent under the top-level AND convention.", "ENTITY_AND_QUALIFIER_COMPLETENESSS": "Both the entity (impaired cognition) and its qualifier (based on cognitive screening at hospital admission) are explicitly modeled via the stem@@qualifier template.", "NO_VARIABLE_DUPLICATION": "The introduced symbols are local to this snippet and do not redeclare anything else (example context).", "POLARITY_CORRECTNESS": "Because we assert (not E) where E is the exclusion predicate, SAT $ $ Q holds (patient may be included); UNSAT when Q is false (exclusion applies).", "VARIABLE_NAME_VERBATIMNESS": "Names match meanings: base variable encodes current impairment; the qualified variable encodes that the impairment is determined by admission screening.", "USE_CANONICALIZABLE_LIST_AS_MUCH_AS_POSSIBLE": "We use the canonical stem 'has_finding_of_impaired_cognition_now' with the allowed qualifier '@@based_on_cognitive_screening_at_hospital_admission'.", "OVEARLL_OK": "All checklist items pass; the encoding correctly demonstrates double-negation polarity handling for an exclusion of the form'exclude if NOT Q'." </output> </example_polarity_2> ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ # === CORRECT EXAMPLE FOR ENCODING FAITHFULNESS === <requirement_json> "requirement": "The patient is excluded if the patient has (stage cT1N0 esophageal adenocarcinoma) OR (stage cT4b esophageal adenocarcinoma).",,→ "source": "A patient is excluded if the patient has stage cT1N0 esophageal adenocarcinoma or stage cT4b esophageal adenocarcinoma.",,→ "components": [ "text": "The patient is excluded if the patient has stage cT1N0 esophageal adenocarcinoma.", "constraint": "OTHER_REQUIREMENTS" , "text": "The patient is excluded if the patient has stage cT4b esophageal adenocarcinoma.", "constraint": "OTHER_REQUIREMENTS" ] </requirement_json> <candidate_smt_snippet> ;; ===================== Declarations for the exclusion criterion (REQ 2) ===================== 168 Preprint. Under review. (declare-const patient_has_stage_ct1n0_esophageal_adenocarcinoma Bool) ;; "when_to_set_to_true": "Set to true if the patient has stage cT1N0 esophageal adenocarcinoma.", "when_to_set_to_false": "Set to false if the patient does not have stage cT1N0 esophageal adenocarcinoma.", "when_to_set_to_null": "Set to null if the stage cT1N0 esophageal adenocarcinoma status is unknown or cannot be determined.", "meaning": "Boolean variable indicating whether the patient has stage cT1N0 esophageal adenocarcinoma." ,→ ,→ ,→ ,→ (declare-const patient_has_stage_ct4b_esophageal_adenocarcinoma Bool) ;; "when_to_set_to_true": "Set to true if the patient has stage cT4b esophageal adenocarcinoma.", "when_to_set_to_false": "Set to false if the patient does not have stage cT4b esophageal adenocarcinoma.", "when_to_set_to_null": "Set to null if the stage cT4b esophageal adenocarcinoma status is unknown or cannot be determined.", "meaning": "Boolean variable indicating whether the patient has stage cT4b esophageal adenocarcinoma." ,→ ,→ ,→ ,→ ;; ===================== Constraint Assertions (REQ 2) ===================== (assert (! (not patient_has_stage_ct1n0_esophageal_adenocarcinoma) :named REQ2_COMPONENT0_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has stage cT1N0 esophageal adenocarcinoma.",→ (assert (! (not patient_has_stage_ct4b_esophageal_adenocarcinoma) :named REQ2_COMPONENT1_OTHER_REQUIREMENTS)) ;; "The patient is excluded if the patient has stage cT4b esophageal adenocarcinoma.",→ </candidate_smt_snippet> # === INPUTS === <requirement_to_translate> #REQUIREMENT# </requirement_to_translate> <candidate_smt_snippet> #CANDIDATE_SMT# </candidate_smt_snippet> <canonicalizable_variable_list> #CANONICALIZABLE_VARIABLE_LIST# </canonicalizable_variable_list> <partial_program> #SMT_VARIABLES_BY_FAR# </partial_program> # === OUTPUT FORMAT === Reply only with a JSON object: "MEANING_FAITHFULNESS": true|false, "ENTITY_AND_QUALIFIER_COMPLETENESSS": true|false, "NO_VARIABLE_DUPLICATION": true|false, "POLARITY_CORRECTNESS": true|false, "VARIABLE_NAME_VERBATIMNESS": true|false, "variables_in_canonicalizble_variable_list": "...reiterate all the variables present in the <canonicalizable_variable_list>...",,→ "all_variables_used_in_the_smt_snippet": "...reiterate all variables used, used to help decide USE_CANONICALIZABLE_LIST_AS_MUCH_AS_POSSIBLE...",,→ "USE_CANONICALIZABLE_LIST_AS_MUCH_AS_POSSIBLE": true|false, // ONLY variables in <canonicalizable_variable_list> is under discussion here.,→ "QUALIFIER_ENTITY_RELATIONSHIPS_CAPTURED": true|false, "OVEARLL_OK": true|false, "explanations": "MEANING_FAITHFULNESS": "...brief rationale...", "ENTITY_AND_QUALIFIER_COMPLETENESSS": "...brief rationale...", "NO_VARIABLE_DUPLICATION": "...brief rationale...", "POLARITY_CORRECTNESS": "...brief rationale...", "VARIABLE_NAME_VERBATIMNESS": "...brief rationale...", "USE_CANONICALIZABLE_LIST_AS_MUCH_AS_POSSIBLE": "...brief rationale...", "OVEARLL_OK": "...brief rationale...", F.1.35 SMT Programmer: Verifier Inclusion Purpose.This prompt verifies that the generated SMT fragment for an inclusion re- quirement faithfully captures the original meaning. It checks semantic correctness, polarity, completeness of entities and qualifiers, and consistency with existing variables before the fragment is accepted into the program. # === ROLE === 169 Preprint. Under review. You are an expert formal-methods auditor. # === TASK ==== We are translating natural language criteria in clinical-trial eligibility criteria incrementally. You are given: - the criterion text (<requirement_to_translate>) - the candidate SMT snippet (<candidate_smt_snippet>) - the current existing declared variables (<partial_program>) - the canonicalizable variable list (<canonicalizable_variable_list>) Verify the snippet against EVERY checklist item and report the results. # === BACKGROUND === You are being inputted with inclusion criteria. If an inclusion criteria is satisfied (i.e., has value True), the participant may be included. If an inclusion criteria is not satisfied (i.e., has value False), the participant is not included. For inclusion criteria, the SMT-LIB language already works seamlessly, as SMT-LIB assumes a top-level AND. ,→ ,→ ,→ # === INPUT DESCRIPTION === 1. <requirement_to_translate> is the current requirement to translate into SMT snippet to be appended to the existing declared variables (<partial_program>).,→ 2. <candidate_smt_snippet> is the candidate SMT snippet we translated from <requirement_to_translate>: if it passes the checks it will be appeneded to <partial_program>.,→ 3. <canonicalizable_variable_list> is the list of canonical variables the SMT translation can choose from. The SMT snippet does not necessarily have to use all variables in this list, but should use variables in the list whenever it can (i.e,. has to use the meaning of these variables). ,→ ,→ 4. <partial_program> is the existing declared variables for all previous requirements in the eligibility criteria section of the clinical trial.,→ # === INPUTS === <requirement_to_translate> #REQUIREMENT# </requirement_to_translate> <candidate_smt_snippet> #CANDIDATE_SMT# </candidate_smt_snippet> <canonicalizable_variable_list> #CANONICALIZABLE_VARIABLE_LIST# </canonicalizable_variable_list> <partial_program> #SMT_VARIABLES_BY_FAR# </partial_program> === NAMING SYSTEM / NAMING TEMPLATES === Stems (lowercase snake_case; strip punctuation; numerals normalized). The timeframe token MUST appear exactly once inside the stem and match the "timeframe" field.,→ <stems_templates> Finding: <stems_templates::findings> patient_has_diagnosis_of_entity_canonical_form_timeframe | patient_has_finding_of_entity_canonical_form_timeframe | patient_has_symptoms_of_entity_canonical_form_timeframe | patient_has_clinical_signs_of_entity_canonical_form_timeframe | patient_has_suspicion_of_entity_canonical_form_timeframe </stems_templates::findings> Procedure: <stems_templates::procedures> patient_has_undergone_entity_canonical_form_timeframe | patient_has_undergone_entity_canonical_form_timeframe_outcome_is_positive | patient_has_undergone_entity_canonical_form_timeframe_outcome_is_negative | patient_has_undergone_entity_canonical_form_timeframe_outcome_is_normal | patient_has_undergone_entity_canonical_form_timeframe_outcome_is_abnormal | patient_is_undergoing_entity_canonical_form_timeframe | patient_will_undergo_entity_canonical_form_timeframe | patient_can_undergo_entity_canonical_form_timeframe | </stems_templates::procedures> Observable Entities (numeric): <stems_templates::observable_entities_numeric> patient_entity_canonical_form_value_recorded_timeframe_withunit_unit </stems_templates::observable_entities_numeric> Product: 170 Preprint. Under review. <stems_templates::product> patient_is_taking_entity_canonical_form_timeframe | patient_has_taken_entity_canonical_form_timeframe | patient_has_hypersensitivity_to_entity_canonical_form_timeframe | patient_has_intolerance_to_entity_canonical_form_timeframe | patient_has_allergy_to_entity_canonical_form_timeframe | patient_has_nonimmune_hypersensitivity_to_entity_canonical_form_timeframe | </stems_templates::product> Substance: <stems_templates::substance> patient_is_exposed_to_entity_canonical_form_timeframe | patient_has_hypersensitivity_to_entity_canonical_form_timeframe | patient_has_intolerance_to_entity_canonical_form_timeframe | patient_has_allergy_to_entity_canonical_form_timeframe | patient_has_nonimmune_hypersensitivity_to_entity_canonical_form_timeframe | </stems_templates::substance> </stems_templates> <timeframe> Timeframe : now | inthehistory | inthefuture | inthepastnunits | inthefuturenunits | foradurationofnunits,→ Time Units: minutes | hours | days | weeks | months | years </timeframe> <qualifiers> Attach with: stem@@qualifier_snake_case Qualifiers must NOT repeat timeframe/value/unit; they encode leftover semantics (e.g., temporal anchors other than``today′, context like``at baseline′, or dependencies like``after percutaneous coronary intervention′). Use qualifiers sparingly and ONLY when needed for later assertions. ,→ ,→ </qualifiers> # === CHECKLIST === 1. MEANING_FAITHFULNESS. The SMT fragment <candidate_smt_snippet> faithfully encodes the natural-language requirement <requirement_to_translate>. Note that you should allow for some imperfections in the code as long as the meaning is kept equivalent. ,→ ,→ 1.a., for example, it is perfectly viable to define two separate variables for one value for cases such as the upper bound and lower bound are defined in different units.,→ 2. ENTITY_AND_QUALIFIER_COMPLETENESSS: No meaningful entity or qualifier is missing. 3. NO_VARIABLE_DUPLICATION: The snippet introduces no symbol with meaning that duplicates one already present in the partial program.,→ 4. POLARITY_CORRECTNESS. If the snippet (<candidate_smt_snippet>) evaluates to SAT, then the patient MAY BE INCLUDED. If the snippet (<candidate_smt_snippet>) evaluates to UNSAT, the patient IS NOT INCLUDED.,→ 5. VARIABLE_NAME_VERBATIMNESS: Variable names and their definitions EXACTLY match up. 6. USE_CANONICALIZABLE_LIST_AS_MUCH_AS_POSSIBLE: The SMT assertion used variables defined in <canonicalizable_variable_list> as much as possible. That is, whenever we want to express meanings that are able to be covered by variables in <canonicalizable_variable_list>, we always use variables in <canonicalizable_variable_list>. ,→ ,→ ,→ 6.a., !!!!! Note that it is FINE for the SMT program to use variables that are NOT in the list. 6.b., !!!!! Also note that the only source of truth for this is <canonicalizable_variable_list>. 7. QUALIFIER_ENTITY_RELATIONSHIPS_CAPTURED: Note this applies to ALL variables in the SMT implemetation. Make sure that qualifiers of entities are not defined independently without specifying what entity it refers to (i.e., without using the stem@@qualifier template). Anything that narrows or qualifies the entity counts as a qualifier span. Qualifier span can cover etiology, disease course, anatomical site, morphology, stage, severity, and so on. ,→ ,→ ,→ ,→ - Note that we must prioritize using canonical variables before defining new, non-canonical variables. That is, we prefer canonical variable + new qualifier over completely new, non-canonical variables.,→ 8. OVEARLL_OK: If all of the above checklists are true. # === CORRECT EXAMPLES === <example_1> <requirement_to_translate_example_1> "requirement": "To be included, the patient must have (an Eastern Cooperative Oncology Group (ECOG) Performance Status of 0) OR (an ECOG Performance Status of 1) OR (an ECOG Performance Status of 2).",,→ "source": "To be included, a patient must have an ECOG Performance status of 0, an ECOG Performance status of 1, or an ECOG Performance status of 2.",,→ "components": [ "text": "To be included, the patient must have (an Eastern Cooperative Oncology Group (ECOG) Performance Status of 0) OR (an ECOG Performance Status of 1) OR (an ECOG Performance Status of 2).",,→ "constraint": "PRESCREEN_NOTES_MUST_COMPLETELY_SUFFICE" ] </requirement_to_translate_example_1> <candidate_smt_snippet_example_1> ;; ============================================================ 171 Preprint. Under review. ;; Declarations (from <new_variable_declarations>) ;; ============================================================ (declare-const patient_has_undergone_radiotherapy_to_abdomen_inthehistory Bool) ;; "when_to_set_to_true":"The patient has undergone abdominal radiotherapy in the past.","when_to_set_to_false":"The patient has not undergone abdominal radiotherapy in the past.","when_to_set_to_null":"It is unknown whether the patient has undergone abdominal radiotherapy in the past.","meaning":"Boolean procedure indicating the patient has undergone abdominal radiotherapy in the past." ,→ ,→ ,→ ,→ (declare-const patient_has_undergone_radiotherapy_to_thorax_inthehistory Bool) ;; "when_to_set_to_true":"The patient has undergone thoracic radiotherapy in the past.","when_to_set_to_false":"The patient has not undergone thoracic radiotherapy in the past.","when_to_set_to_null":"It is unknown whether the patient has undergone thoracic radiotherapy in the past.","meaning":"Boolean procedure indicating the patient has undergone thoracic radiotherapy in the past." ,→ ,→ ,→ ,→ ;; ============================================================ ;; CONSTRAINT assertions (1:1 with components) ;; ============================================================ ;; Component 0: "must NOT have undergone prior abdominal radiotherapy AND NOT have undergone prior thoracic radiotherapy.",→ (assert (! (and (not patient_has_undergone_radiotherapy_to_abdomen_inthehistory) (not patient_has_undergone_radiotherapy_to_thorax_inthehistory)) :named REQ3_COMPONENT0_NEED_TO_BE_STRICTLY_ENFORCED_IN_INFORMATION_RETRIEVAL)) ;; From "To be included, the patient must NOT have undergone prior abdominal radiotherapy AND NOT have undergone prior thoracic radiotherapy." ,→ ,→ </candidate_smt_snippet_example_1> </example_1> # === OUTPUT FORMAT === Reply only with a JSON object: "MEANING_FAITHFULNESS": true|false, "ENTITY_AND_QUALIFIER_COMPLETENESSS": true|false, "NO_VARIABLE_DUPLICATION": true|false, "POLARITY_CORRECTNESS": true|false, "VARIABLE_NAME_VERBATIMNESS": true|false, "variables_in_canonicalizble_variable_list": "...reiterate all the variables present in the <canonicalizable_variable_list>...",,→ "all_variables_used_in_the_smt_snippet": "...reiterate all variables used, used to help decide USE_CANONICALIZABLE_LIST_AS_MUCH_AS_POSSIBLE...",,→ "USE_CANONICALIZABLE_LIST_AS_MUCH_AS_POSSIBLE": true|false, "QUALIFIER_ENTITY_RELATIONSHIPS_CAPTURED": true|false, "OVEARLL_OK": true|false, "explanations": "MEANING_FAITHFULNESS": "...brief rationale...", "ENTITY_AND_QUALIFIER_COMPLETENESSS": "...brief rationale...", "NO_VARIABLE_DUPLICATION": "...brief rationale...", "POLARITY_CORRECTNESS": "...brief rationale...", "VARIABLE_NAME_VERBATIMNESS": "...brief rationale...", "USE_CANONICALIZABLE_LIST_AS_MUCH_AS_POSSIBLE": "...brief rationale...", "OVEARLL_OK": "...brief rationale...", F.1.36 Fix Overly Strict or Misinterpreted Criteria Purpose. This prompt corrects broad semantic drift introduced during the initial trans- lation from natural-language eligibility criteria to SMT. It focuses on cases where literal or overly rigid interpretations make the program too restrictive, causing patients to be incorrectly excluded. The prompt refines the SMT encoding by aligning it with the clinical intent expressed in the eligibility text. This includes resolving context-dependent meanings, distinguishing current index conditions from prior episodes, and introducing appropriate qualifiers (e.g., clinically significant conditions or prior-event qualifiers) to avoid unintended over-exclusion. It may also adjust how umbrella concepts and example lists are represented to better match their intended scope. All edits are conservative and minimal, aiming to restore fidelity to the natural-language criteria without introducing new assumptions or weakening valid constraints. # === ROLE === 172 Preprint. Under review. You are an expert bioinformatician. Your task is to repair and refine an SMT program representing the eligibility criteria of a clinical trial to make sure that the SMT program is contextualized and not being overly strict so that it accidentally excludes patients. You are given the program representing SIDE criteria in this case. ,→ ,→ # === TASK === Your task is to address semantic drifts from parsing natural language eligibility criteria to SMT-LIB v2. # === CONTEXT === Note that each trial may recruit multiple subcohorts of participants (e.g., control group vs non-control group; AD vs Dementia group). Here, we provide in <shared_context> the shared context of the whole trial, and in <subcohort_context> the context specific to the current subcohort of interest. Additional narrative around the cohort may appear in <contextual_text>. ,→ ,→ ,→ <shared_context> SHARED_CONTEXT </shared_context> <subcohort_context> CONTEXT </subcohort_context> <contextual_text> CONTEXTUAL_TEXT </contextual_text> # === ELIGIBILITY CRITERIA FOR THIS SUBCOHORT & SIDE === Here, you are given the natural language description of inclusion criteria in <inclusion_criteria> and that of exclusion criteria in <exclusion_criteria>, for this subcohort only.,→ <inclusion_criteria> INCLUSION_CRITERIA </inclusion_criteria> <exclusion_criteria> EXCLUSION_CRITERIA </exclusion_criteria> # === CURRENT SMT-LIB PROGRAM === The following SMT-LIB v2 program encodes the eligibility criteria for this (trial, subcohort, side). It may or may not have some semantic drifts from the meanings expressed in natural language.,→ <current_smt_program> SMT_PROGRAM </current_smt_program> # === GUIDELINES === 1. Do minimal fixes to address semantic drifts. Prefer the smallest set of edits that makes the SMT program faithful to the clinical intent.,→ 2. Reuse existing symbols as much as possible. Treat existing symbols as stems and prefer adding qualifiers of the form <stem>@@<qualifier> over introducing unrelated new stems. If both <stem> and <stem>@@<qualifier> are booleans, add: ,→ ,→ (assert (=> <stem>@@<qualifier> <stem>)) so the qualifier is a subset of the stem. 3. Literal translations often over-exclude. Example patterns: - Trial *studies* bipolar disorder but exclusions say "history of medical illness": interpret this as "clinically significant comorbid illnesses beyond the target bipolar disorder", not "any illness ever".,→ - Trial *requires* current pneumonia but exclusions say "pneumonia in the past": this usually means previous episodes relative to the index episode, not the current one. Use qualifiers (e.g., @@clinically_significant, @@previous_episode) to narrow stems accordingly. ,→ ,→ 4. For an umbrella term followed by a list (e.g., "such as," "i.e.," "e.g.," "including," "like"), classify the list:,→ 4.1 **Exhaustive subcategories** (list fully enumerates the set): umbrella ⼹ (item1 âĹĺ item2 âĹĺ âĂę) ; use equivalence. 4.2 **Non-exhaustive examples** (most common): (item1 âĹĺ item2 âĹĺ âĂę) âĞŠ umbrella_subclass ; one-way implication only. 4.3 Ambiguous context âĘŠ default to non-exhaustive examples. 5. Preserve structure: keep existing assertion tags, :named labels, and comment style (e.g., ;; comments, REQ* labels).,→ 6. If, after careful review, you conclude that the current SMT program already matches the natural language criteria and does not introduce harmful semantic drift or over-restriction, do NOT rewrite or echo the SMT program. Instead, return: ,→ ,→ - "repaired_smt": "NO MODIFICATION REQUIRED" - "notes": a short explanation (1âĂŞ3 sentences) of why no changes are needed (e.g., "Checked inclusion/exclusion, temporal qualifiers, and umbrella terms; SMT already matches described criteria.").,→ 7. When you DO modify the SMT program, you MUST return the entire updated SMT-LIB v2 program in "repaired_smt" (not a diff), and ensure it is a self-contained, valid SMT-LIB v2 script.,→ 173 Preprint. Under review. 8. **Index condition + prior history pattern (general rule).** When inclusion criteria define a CURRENT "index" condition (e.g., solitary or single lesion; current suspected or proven DVT/PE; current MI or infection), and the exclusion criteria talk about the *same* condition using phrases like: ,→ ,→ - "previous history of âĂę", "prior history of âĂę" - "has had âĂę in the preceding N years / in the past N years" - "has had âĂę before", "previous episodes of âĂę" you MUST interpret the exclusion as referring to **previous episodes relative to the current index event** (not the index event itself).,→ In such cases: - Treat umbrella stems like <stem>_inthehistory or <stem>_inthepastNyears as "any occurrence in that window (including the index)".,→ - Introduce <stem>@@previous_episode to encode "prior episodes before the current index event". - Add subset axiom: (assert (=> <stem>@@previous_episode <stem>)) - Rewrite the exclusion constraints to use <stem>@@previous_episode (not the broader <stem>), so patients whose only event is the current index event remain eligible.,→ 8B. Trauma-specific and injury-specific temporal exclusions (MANDATORY). If inclusion criteria imply evaluation for a CURRENT traumatic or injurious index event (e.g., "evaluated for blunt trauma," "current injury," "current accident," "current episode"), and an exclusion criterion contains a temporal phrase involving the same type of trauma/injury, such as: ,→ ,→ - "trauma in the last N days/weeks/months," - "injury in the past N days/weeks/months," - "abdominal/chest/head trauma in the last month," - "has had [injury] in the preceding N intervals," - "recent [injury] in the past N intervals," then you MUST interpret this exclusion as referring to previous episodes of trauma/injury relative to the CURRENT index trauma event, NOT the current event itself.,→ 9. **Solitary / single-lesion special case (e.g., solitary brain metastasis).** If: - Inclusion requires a solitary / single lesion or event (e.g., "single presumed brain metastasis", "solitary brain metastasis", "single index lesion"), AND,→ - Exclusion says "previous history of <same condition>" or similar prior-episode phrasing, then: - Treat the solitary/single lesion as the CURRENT index event required for eligibility. - Interpret "previous history" as "prior episodes before the current solitary/index lesion". - Introduce <stem>@@previous_episode on the "history" stem (e.g., patient_has_diagnosis_of_secondary_malignant_neoplasm_of_brain_inthehistory@@previous_episode), add:,→ (assert (=> <stem>@@previous_episode <stem>)) - Base the exclusion ONLY on <stem>@@previous_episode. 10. **Self-check before âĂŸNO MODIFICATION REQUIREDâĂŹ.** Before concluding that no changes are needed, explicitly check: - Does inclusion define a current index condition that is also mentioned in exclusion? - Does exclusion use "previous history / prior history / has had / in the past N years / previous episodes" for that same condition?,→ If yes, you MUST consider whether a <stem>@@previous_episode refinement is needed; do not use the umbrella <stem> alone in exclusions.,→ 11. Please only focus on your side. If you are given SIDE criteria, you should only be parsing SIDE criteria to SMT. The other side will be taken care of by another file.,→ 12. Do not do the modification if all you need to modify are just some annotations. Only do modifications if you see significant SMT logic issues or significant variable declaration issues.,→ 13. Even if you have nothing to modify, you must return according to instructions in 6. 14. Note that the translation and variable meanings should be self-contained, such that they don't depend on each other for understanding (semantic recovery), nor do they depend on the trial context. For example, parent 1 and parent 2 are dependent on each other because we need to nail down one to know the other, and this case should be avoided. ,→ ,→ ,→ # === SMT FORMATTING === STRICT FORMAT & ANNOTATION REQUIREMENTS (MUST MATCH EXACTLY) These are hard formatting constraints. If any are violated, you MUST output a full corrected SMT (do NOT return "NO MODIFICATION REQUIRED").,→ A) Allowed declaration forms / types (HARD) - You MUST only use: (declare-const <sym> Bool) (declare-const <sym> Int) (declare-const <sym> Real) - Do NOT introduce declare-fun, define-fun, Strings, enums, Datatypes, Arrays, or uninterpreted sorts. B) Variable declaration annotation (HARD) - EVERY (declare-const ...) line MUST have a single JSON object comment on the SAME LINE. - If an existing declaration already has a JSON object comment, keep it verbatim (do NOT rewrite or rewrap it). - JSON must be valid (double quotes) and based ONLY on variable meaning. Required JSON keys (exact): - For Bool: "when_to_set_to_true":"...","when_to_set_to_false":"...","when_to_set_to_null":"...","meaning":"..." 174 Preprint. Under review. - For Int/Real: "when_to_set_to_value":"...","when_to_set_to_null":"...","meaning":"..." C) "NO MODIFICATION REQUIRED" gate (HARD) - You may return "NO MODIFICATION REQUIRED" ONLY if: (1) there are no polarity flips AND (2) the CURRENT SMT already satisfies (A) and (B). - Otherwise you MUST return the full corrected SMT program. # === EXAMPLE 1 (compressed: DVT/PE + @@previous_episode) === Natural language: - Inclusion: current suspected/proven DVT/PE with planned anticoagulation (defines a CURRENT index thromboembolic event).,→ - Exclusion: "has had deep vein thrombosis in the preceding three years"; "has had pulmonary embolism in the preceding three years".,→ Naive SMT (problem): - Stems: (declare-const patient_has_diagnosis_of_deep_venous_thrombosis_inthepast3years Bool) (declare-const patient_has_diagnosis_of_pulmonary_embolism_inthepast3years Bool) - Exclusion: (assert (! (not patient_has_diagnosis_of_deep_venous_thrombosis_inthepast3years) :named REQ0_COMPONENT0_OTHER_REQUIREMENTS)),→ (assert (! (not patient_has_diagnosis_of_pulmonary_embolism_inthepast3years) :named REQ0_COMPONENT1_OTHER_REQUIREMENTS)),→ âĘŠ This may exclude the index event itself if diagnosed within 3 years. Repaired pattern: - Add qualifiers: (declare-const patient_has_diagnosis_of_deep_venous_thrombosis_inthepast3years@@previous_episode Bool) (declare-const patient_has_diagnosis_of_pulmonary_embolism_inthepast3years@@previous_episode Bool) - Subset axioms: (assert (! (=> patient_has_diagnosis_of_deep_venous_thrombosis_inthepast3years@@previous_episode patient_has_diagnosis_of_deep_venous_thrombosis_inthepast3years) :named REQ0_AUXILIARY0)) (assert (! (=> patient_has_diagnosis_of_pulmonary_embolism_inthepast3years@@previous_episode patient_has_diagnosis_of_pulmonary_embolism_inthepast3years) :named REQ0_AUXILIARY1)) - Exclusions now: (assert (! (not patient_has_diagnosis_of_deep_venous_thrombosis_inthepast3years@@previous_episode) :named REQ0_COMPONENT0_OTHER_REQUIREMENTS)) (assert (! (not patient_has_diagnosis_of_pulmonary_embolism_inthepast3years@@previous_episode) :named REQ0_COMPONENT1_OTHER_REQUIREMENTS)) Key lesson: when inclusion defines a CURRENT index event and exclusion says "has had âĂę in the preceding N years", use @@previous_episode so the index event itself is not excluded.,→ # === EXAMPLE 2 (compressed: bipolar / metabolic + @@clinically_significant) === Natural language: - Trial population: patients with bipolar disorders (I, I, NOS), in remission, with antipsychotic-induced weight gain.,→ - Exclusion includes: "history of neurological and medical illness". Naive SMT (problem): - Stems: (declare-const patient_has_diagnosis_of_disorder_of_nervous_system_inthehistory Bool) ;; "neurological illness" (declare-const patient_has_diagnosis_of_illness_inthehistory Bool) ;; "medical illness" - Exclusions: (assert (! (not patient_has_diagnosis_of_disorder_of_nervous_system_inthehistory) :named REQ1_COMPONENT0_OTHER_REQUIREMENTS)),→ (assert (! (not patient_has_diagnosis_of_illness_inthehistory) :named REQ1_COMPONENT1_OTHER_REQUIREMENTS)),→ âĘŠ Literally excludes almost everyone (bipolar disorder is itself an illness; many have common comorbidities). Repaired pattern: - Add qualifiers: (declare-const patient_has_diagnosis_of_disorder_of_nervous_system_inthehistory@@clinically_significant Bool) (declare-const patient_has_diagnosis_of_illness_inthehistory@@clinically_significant Bool) - Subset axioms: (assert (! (=> patient_has_diagnosis_of_disorder_of_nervous_system_inthehistory@@clinically_significant patient_has_diagnosis_of_disorder_of_nervous_system_inthehistory) :named REQ1_AUXILIARY0)) (assert (! (=> patient_has_diagnosis_of_illness_inthehistory@@clinically_significant patient_has_diagnosis_of_illness_inthehistory) :named REQ1_AUXILIARY1)) - Use qualifiers in exclusions: (assert (! (not patient_has_diagnosis_of_disorder_of_nervous_system_inthehistory@@clinically_significant) :named REQ1_COMPONENT0_OTHER_REQUIREMENTS)) (assert (! (not patient_has_diagnosis_of_illness_inthehistory@@clinically_significant) :named REQ1_COMPONENT1_OTHER_REQUIREMENTS)) 175 Preprint. Under review. Key lesson: when the *target disease under study* is itself an illness, generic "history of medical illness" stems must usually be narrowed to a clinically significant subset via qualifiers like @@clinically_significant.,→ # === OUTPUT FORMAT (STRICT) === Return ONLY a single JSON object, with **no extra text**, no Markdown fences, no comments, exactly in this shape: "repaired_smt": "<FULL SMT-LIB v2 program for this subcohort and side> OR the exact string \"NO MODIFICATION REQUIRED\" if no changes are needed",,→ "notes": "<short explanation (1âĂŞ3 sentences or bullet points) of what you changed and why, or why no changes are needed>",→ Constraints: âĂć Normally, the value of "repaired_smt" MUST be the entire SMT-LIB program in a single string (you may include newlines inside the string). âĂć Exception: if no modification is required, set "repaired_smt": "NO MODIFICATION REQUIRED" and do NOT include any SMT code there. âĂć The value of "notes" should briefly summarize the main repairs, or state why no repairs were necessary. - e.g., "Fixed missing NOT on exclusion assertion for prior MI; added variable declaration for BMI threshold; corrected <= vs < typo.",→ - or, "No semantic drift found; SMT encoding already matches inclusion/exclusion with correct temporal qualifiers.",→ âĂć Do NOT wrap the JSON in```json or any other backticks. âĂć Do NOT include any other top-level keys. âĂć Do NOT output multiple JSON objects or any prose before/after the JSON. F.1.37 Fix Reversed Exclusion Logic Purpose. This prompt identifies and corrects polarity errors in exclusion-side SMT pro- grams that arise from the "not excluded" encoding convention. Such errors occur when a condition is encoded in a way that makes the program satisfiable when the patient should actually be excluded, thereby reversing the intended clinical meaning. The prompt operates at a fine granularity, repairing only those assertions whose logical direction is clearly incorrect while leaving correctly encoded conditions unchanged. All edits are minimal and local, preserving the existing program structure, symbols, and annotations. If no polarity errors are detected, the program is left unchanged. # === ROLE === You are an expert bioinformatician and logic expert. Your task is to fix the polarities of assertions in the SMT version of exclusion criteria. You are given the program representing SIDE criteria in this case.,→ # === CONTEXT === Note that each trial may recruit multiple subcohorts of participants (e.g., control group vs non-control group; AD vs Dementia group). Here, we provide in <shared_context> the shared context of the whole trial, and in <subcohort_context> the context specific to the current subcohort of interest. Additional narrative around the cohort may appear in <contextual_text>. ,→ ,→ ,→ <shared_context> SHARED_CONTEXT </shared_context> <subcohort_context> CONTEXT </subcohort_context> <contextual_text> CONTEXTUAL_TEXT </contextual_text> # === ELIGIBILITY CRITERIA FOR THIS SUBCOHORT & SIDE === Here, you are given the natural language description of exclusion criteria in <exclusion_criteria>, for this subcohort only.,→ <exclusion_criteria> EXCLUSION_CRITERIA </exclusion_criteria> # === CURRENT SMT-LIB PROGRAM === The following SMT-LIB v2 program encodes the eligibility criteria for this (trial, subcohort, side). It may or may not have some polarity flips from the meanings expressed in natural language.,→ <current_smt_program> 176 Preprint. Under review. SMT_PROGRAM </current_smt_program> # === POLARITY SPECIFICATION === The patient is ELIGIBLE iff SMT programs of both inclusion constraints and exclusion constraints are SAT. So exclusion constraints are SAT under the "NOT excluded" encoding used here. A lot of times, some criteria will be mistakenly encoded in the other way around. That is, a criterion may be encoded in a way that the SMT program will be evaluated to be SAT if the patient is excluded. We would like to correct these criterion. Note that it is possible that some criteria have their polarities flipped but others do not. Be careful and operate on a fine granularity. ,→ ,→ ,→ ,→ ,→ # === GUIDELINES === 1. Do minimal fixes to address polarity flips. Prefer the smallest set of edits that makes the SMT program faithful to the clinical intent.,→ 2. Reuse existing symbols as much as possible. Treat existing symbols as stems and prefer adding qualifiers of the form <stem>@@<qualifier> over introducing unrelated new stems. If both <stem> and <stem>@@<qualifier> are booleans, add: ,→ ,→ (assert (=> <stem>@@<qualifier> <stem>)) so the qualifier is a subset of the stem. 3. Preserve structure: keep existing assertion tags, :named labels, and comment style (e.g., ;; comments, REQ* labels).,→ 4. If, after careful review, you conclude that the current SMT program does not have polarity flips, do NOT rewrite or echo the SMT program. Instead, return:,→ - "repaired_smt": "NO MODIFICATION REQUIRED" - "notes": a short explanation (1âĂŞ3 sentences) of why no changes are needed (e.g., "Checked inclusion/exclusion, temporal qualifiers, and umbrella terms; SMT already matches described criteria.").,→ 5. When you DO modify the SMT program, you MUST return the entire updated SMT-LIB v2 program in "repaired_smt" (not a diff), and ensure it is a self-contained, valid SMT-LIB v2 script.,→ 6. Keep all comments for variable declarations and all comments for unchanged assertions. You may adjust the comments for the modified assertion, but you still need to write the assertion. Note that if you declare new variables, you should define what they mean following the same comment conventions. ,→ ,→ 7. Please only focus on your side. If you are given exclusion criteria, you should only be parsing exclusion criteria to SMT. The other side will be taken care of by another file.,→ 8. Do not do the modification if all you need to modify are just some annotations. Only do modifications if you see significant SMT logic issues or significant variable declaration issues.,→ 9. Even if you have nothing to modify, you must return according to instructions in 4. 10. Note that the translation and variable meanings should be self-contained, such that they don't depend on each other for understanding (semantic recovery), nor do they depend on the trial context. For example, parent 1 and parent 2 are dependent on each other because we need to nail down one to know the other, and this case should be avoided. ,→ ,→ ,→ # === SMT FORMATTING === STRICT FORMAT & ANNOTATION REQUIREMENTS (MUST MATCH EXACTLY) These are hard formatting constraints. If any are violated, you MUST output a full corrected SMT (do NOT return "NO MODIFICATION REQUIRED").,→ A) Allowed declaration forms / types (HARD) - You MUST only use: (declare-const <sym> Bool) (declare-const <sym> Int) (declare-const <sym> Real) - Do NOT introduce declare-fun, define-fun, Strings, enums, Datatypes, Arrays, or uninterpreted sorts. B) Variable declaration annotation (HARD) - EVERY (declare-const ...) line MUST have a single JSON object comment on the SAME LINE. - If an existing declaration already has a JSON object comment, keep it verbatim (do NOT rewrite or rewrap it). - JSON must be valid (double quotes) and based ONLY on variable meaning. Required JSON keys (exact): - For Bool: "when_to_set_to_true":"...","when_to_set_to_false":"...","when_to_set_to_null":"...","meaning":"..." - For Int/Real: "when_to_set_to_value":"...","when_to_set_to_null":"...","meaning":"..." C) "NO MODIFICATION REQUIRED" gate (HARD) - You may return "NO MODIFICATION REQUIRED" ONLY if: (1) there are no polarity flips AND (2) the CURRENT SMT already satisfies (A) and (B). - Otherwise you MUST return the full corrected SMT program. # === OUTPUT FORMAT (STRICT) === Return ONLY a single JSON object, with **no extra text**, no Markdown fences, no comments, exactly in this shape: "repaired_smt": "<FULL SMT-LIB v2 program for this subcohort and side> OR the exact string \"NO MODIFICATION REQUIRED\" if no changes are needed",,→ "notes": "<short explanation (1âĂŞ3 sentences or bullet points) of what you changed and why, or why no changes are needed>",→ 177 Preprint. Under review. Constraints: âĂć Normally, the value of "repaired_smt" MUST be the entire SMT-LIB program in a single string (you may include newlines inside the string). âĂć Exception: if no modification is required, set "repaired_smt": "NO MODIFICATION REQUIRED" and do NOT include any SMT code there. âĂć The value of "notes" should briefly summarize the main repairs, or state why no repairs were necessary. - e.g., "Fixed missing NOT on exclusion assertion for prior MI; added variable declaration for BMI threshold; corrected <= vs < typo.",→ - or, "No semantic drift found; SMT encoding already matches inclusion/exclusion with correct temporal qualifiers.",→ âĂć Do NOT wrap the JSON in```json or any other backticks. âĂć Do NOT include any other top-level keys. âĂć Do NOT output multiple JSON objects or any prose before/after the JSON. F.1.38 Fix Misinterpreted or Mis-scoped Logic Purpose. This prompt corrects logical encoding errors in the SMT program where the structure of the constraints does not faithfully reflect the natural-language eligibility crite- ria. These errors include incorrect scoping of qualifiers, misplaced conditions, dropped or improperly grouped components, and other context-dependent misinterpretations. The prompt uses trial and subcohort context to resolve how conditions should be applied, ensuring that constraints are attached to the correct entities and combined with the intended logical structure. All edits are conservative and local, modifying only the parts of the program that clearly deviate from the natural-language meaning, while preserving the overall structure, symbols, and annotations. If no logical inconsistencies are found, the program is left unchanged. # === ROLE === You are an expert bioinformatician and logic expert. Your task is to fix logical encoding issues in the SMT version of natural language eligibility criteria, and you should be aware of the context in this process. For example, you should fix incorrect qualification in the SMT encoding of eligibility criteria, the correctness of many of which depend on the context. For example, some age constraints that should really be applied to both genders -- male and female -- get incorrectly applied to only one gender that is closer to the qualifier, but the context really demands both genders to have age qualification. If you see other logical encoding errrors, you should also fix; but be relative conservative so as to not introduce unnecessary errors. ,→ ,→ ,→ ,→ ,→ ,→ You are given the program representing SIDE criteria in this case. # === CONTEXT === Note that each trial may recruit multiple subcohorts of participants (e.g., control group vs non-control group; AD vs Dementia group). Here, we provide in <shared_context> the shared context of the whole trial, and in <subcohort_context> the context specific to the current subcohort of interest. Additional narrative around the cohort may appear in <contextual_text>. ,→ ,→ ,→ <shared_context> SHARED_CONTEXT </shared_context> <subcohort_context> CONTEXT </subcohort_context> <contextual_text> CONTEXTUAL_TEXT </contextual_text> # === ELIGIBILITY CRITERIA FOR THIS SUBCOHORT & SIDE === Here, you are given the natural language description of inclusion criteria in <inclusion_criteria> and that of exclusion criteria in <exclusion_criteria>, for this subcohort only.,→ <inclusion_criteria> INCLUSION_CRITERIA </inclusion_criteria> <exclusion_criteria> EXCLUSION_CRITERIA </exclusion_criteria> # === CURRENT SMT-LIB PROGRAM === The following SMT-LIB v2 program encodes the eligibility criteria for this (trial, subcohort, side). It may or may not have some semantic drifts from the meanings expressed in natural language.,→ 178 Preprint. Under review. <current_smt_program> SMT_PROGRAM </current_smt_program> # === GUIDELINES === 1. Do minimal fixes to address polarity flips. Prefer the smallest set of edits that makes the SMT program faithful to the clinical intent.,→ 2. Reuse existing symbols as much as possible. Treat existing symbols as stems and prefer adding qualifiers of the form <stem>@@<qualifier> over introducing unrelated new stems. If both <stem> and <stem>@@<qualifier> are booleans, add: ,→ ,→ (assert (=> <stem>@@<qualifier> <stem>)) so the qualifier is a subset of the stem. 3. Preserve structure: keep existing assertion tags, :named labels, and comment style (e.g., ;; comments, REQ* labels).,→ 4. If, after careful review, you conclude that the current SMT program does not have polarity flips, do NOT rewrite or echo the SMT program. Instead, return:,→ - "repaired_smt": "NO MODIFICATION REQUIRED" - "notes": a short explanation (1âĂŞ3 sentences) of why no changes are needed (e.g., "Checked inclusion/exclusion, temporal qualifiers, and umbrella terms; SMT already matches described criteria.").,→ 5. When you DO modify the SMT program, you MUST return the entire updated SMT-LIB v2 program in "repaired_smt" (not a diff), and ensure it is a self-contained, valid SMT-LIB v2 script.,→ 6. Keep all comments for variable declarations and all comments for unchanged assertions. You may adjust the comments for the modified assertion, but you still need to write the assertion. Note that if you declare new variables, you should define what they mean following the same comment conventions. ,→ ,→ 7. Please only focus on your side. If you are given SIDE criteria, you should only be parsing SIDE criteria to SMT. The other side will be taken care of by another file.,→ 8. Do not do the modification if all you need to modify are just some annotations. Only do modifications if you see significant SMT logic issues or significant variable declaration issues.,→ 9. Even if you have nothing to modify, you must return according to instructions in 4. 10. Note that the translation and variable meanings should be self-contained, such that they don't depend on each other for understanding (semantic recovery), nor do they depend on the trial context. For example, parent 1 and parent 2 are dependent on each other because we need to nail down one to know the other, and this case should be avoided. ,→ ,→ ,→ # === SMT FORMATTING === STRICT FORMAT & ANNOTATION REQUIREMENTS (MUST MATCH EXACTLY) These are hard formatting constraints. If any are violated, you MUST output a full corrected SMT (do NOT return "NO MODIFICATION REQUIRED").,→ A) Allowed declaration forms / types (HARD) - You MUST only use: (declare-const <sym> Bool) (declare-const <sym> Int) (declare-const <sym> Real) - Do NOT introduce declare-fun, define-fun, Strings, enums, Datatypes, Arrays, or uninterpreted sorts. B) Variable declaration annotation (HARD) - EVERY (declare-const ...) line MUST have a single JSON object comment on the SAME LINE. - If an existing declaration already has a JSON object comment, keep it verbatim (do NOT rewrite or rewrap it). - JSON must be valid (double quotes) and based ONLY on variable meaning. Required JSON keys (exact): - For Bool: "when_to_set_to_true":"...","when_to_set_to_false":"...","when_to_set_to_null":"...","meaning":"..." - For Int/Real: "when_to_set_to_value":"...","when_to_set_to_null":"...","meaning":"..." C) "NO MODIFICATION REQUIRED" gate (HARD) - You may return "NO MODIFICATION REQUIRED" ONLY if: (1) there are no polarity flips AND (2) the CURRENT SMT already satisfies (A) and (B). - Otherwise you MUST return the full corrected SMT program. # === OUTPUT FORMAT (STRICT) === Return ONLY a single JSON object, with **no extra text**, no Markdown fences, no comments, exactly in this shape: "repaired_smt": "<FULL SMT-LIB v2 program for this subcohort and side> OR the exact string \"NO MODIFICATION REQUIRED\" if no changes are needed",,→ "notes": "<short explanation (1âĂŞ3 sentences or bullet points) of what you changed and why, or why no changes are needed>",→ Constraints: âĂć Normally, the value of "repaired_smt" MUST be the entire SMT-LIB program in a single string (you may include newlines inside the string). âĂć Exception: if no modification is required, set "repaired_smt": "NO MODIFICATION REQUIRED" and do NOT include any SMT code there. âĂć The value of "notes" should briefly summarize the main repairs, or state why no repairs were necessary. 179 Preprint. Under review. - e.g., "Fixed missing NOT on exclusion assertion for prior MI; added variable declaration for BMI threshold; corrected <= vs < typo.",→ - or, "No semantic drift found; SMT encoding already matches inclusion/exclusion with correct temporal qualifiers.",→ âĂć Do NOT wrap the JSON in```json or any other backticks. âĂć Do NOT include any other top-level keys. âĂć Do NOT output multiple JSON objects or any prose before/after the JSON. F.1.39 Check if This Side Has Real Eligibility Criteria Purpose. This prompt determines whether a side-specific SMT program meaningfully encodes real eligibility criteria for the current trial subcohort. It acts as a conservative filter to identify cases where the SMT file is empty, placeholder-only, unrelated to the target side, or otherwise fails to represent the natural-language criteria. The decision is intentionally cautious: the SMT file is marked for removal only when there is strong evidence that no substantive criteria exist for this side. If the program contains any plausible encoding of the target-side eligibility conditions, it is retained. This prevents accidental deletion of valid but incomplete encodings while removing spurious files that would otherwise degrade retrieval and matching quality. You are a conservative auditor for a clinical-trial SMT eligibility pipeline. We have an EXISTING SMT program for this (EFFECTIVE_TRIAL_ID, TARGET_SIDE). Decide whether the SMT program SUBSTANTIVELY encodes the TARGET SIDE criteria for the same trial/cohort. Conservative policy: - Mark coverage_ok=false ONLY when you are very sure the SMT does NOT encode the TARGET SIDE criteria (e.g., wrong side, placeholder/tautology, empty/unrelated). - If uncertain, choose coverage_ok=true. Definition (coverage_ok): - true => SMT contains meaningful constraints plausibly corresponding to at least some TARGET SIDE criteria. - false => SMT clearly fails to encode the TARGET SIDE criteria (not just incomplete). Return ONLY JSON (no markdown, no extra text): "coverage_ok": true|false, "reason": "short" TRIAL_ID=TRIAL_ID EFFECTIVE_TRIAL_ID=EFFECTIVE_TRIAL_ID TARGET_SIDE=SIDE # === BLOCK 1: CONTEXT BUNDLE (best-effort) === <shared_context> SHARED_CONTEXT </shared_context> <subcohort_context> SUBCOHORT_CONTEXT </subcohort_context> <side_criteria> SIDE_CRITERIA </side_criteria> # === BLOCK 2: CORPUS ITEM (raw, unprocessed; all subcohorts) === <corpus_item_json> CORPUS_ITEM_JSON </corpus_item_json> # === BLOCK 3: SMT PROGRAM (canonical) === <smt_program> SMT_TEXT </smt_program> F.1.40 Check if This Subcohort Has Any Eligibility Criteria Purpose. This prompt determines whether any real eligibility criteria exist for the target side (inclusion or exclusion) for a specific trial subcohort. It operates directly on natural- language criteria and subcohort context, before considering the SMT representation. The decision is strictly scoped to the current subcohort. Criteria belonging to other arms or cohorts must not be counted. The prompt uses a conservative policy: it marks the criteria as 180 Preprint. Under review. absent only when there is strong evidence that the target side is missing, placeholder-only, or contains no substantive conditions. If there is any plausible eligibility requirement, even a single condition, the criteria are considered present and retained. This stage serves as a safeguard against propagating empty or non-substantive side def- initions, while avoiding accidental deletion when subcohort attribution is uncertain or upstream preprocessing is incomplete. You are a conservative gatekeeper for a clinical-trial eligibility pipeline. Conservative policy: - Mark criteria_present=false ONLY when you are very sure the TARGET SIDE criteria for THIS SUBCOHORT is not present.,→ - If uncertain, choose criteria_present=true (KEEP). Deletion is destructive. TARGET SIDE: SIDE (inclusion OR exclusion) CRITICAL: subcohort scope - This trial may have multiple subcohorts/arms. - You MUST judge ONLY the subcohort identified by COHORT_ID/COHORT_LABEL and described in <subcohort_context>. - Do NOT count criteria that clearly belong to other subcohorts. - If you cannot confidently attribute a criterion to THIS subcohort, assume it is NOT safe to delete; choose KEEP. Two-block input: - Block 1 (authoritative) is the subcohort-scoped bundle, including ONLY the requested side's criteria. - Block 2 is the raw corpus JSONL item for the whole trial (may include all subcohorts). Use it only as a safety check (e.g., if Block 1 seems empty due to preprocessing misses). Still respect subcohort scope.,→ Definition (criteria_present): - true => ANY real eligibility content for the TARGET SIDE for THIS SUBCOHORT exists (even one condition like "Age >= 18").,→ - false => the TARGET SIDE criteria for THIS SUBCOHORT is effectively missing/placeholder-only/boilerplate. Return ONLY JSON (no markdown, no extra text): "criteria_present": true|false, "reason": "short" TRIAL_ID=TRIAL_ID EFFECTIVE_TRIAL_ID=EFFECTIVE_TRIAL_ID COHORT_ID=COHORT_ID COHORT_LABEL=COHORT_LABEL # === BLOCK 1: SUBCOHORT SIDE BUNDLE (authoritative) === <shared_context> SHARED_CONTEXT </shared_context> <subcohort_context> CONTEXT </subcohort_context> <side_criteria> SIDE_CRITERIA </side_criteria> # === BLOCK 2: CORPUS ITEM (raw, unprocessed; all subcohorts) === <corpus_item_json> CORPUS_ITEM_JSON </corpus_item_json> F.1.41 Tighten Missing or Weak Requirements Purpose.This prompt identifies and fixes cases where the SMT program is too permissive relative to the natural-language eligibility criteria, leading to false positives. It ensures that all clinically relevant requirements for the current side are properly enforced by (i) adding missing conditions, (i) restoring weakened logical structure, and (i) correcting variable definitions that are too narrow, mis-scoped, or insufficiently contextualized. In addition to repairing constraints, this stage may refine the underlying representation by introducing broader umbrella concepts, appropriate qualifiers (e.g., suspected or clinically supported conditions), or correct temporal scopes when required by the natural language. 181 Preprint. Under review. All changes are conservative and limited to what is explicitly supported by the eligibility text, with the goal of tightening the program without introducing unsupported restrictions. # === ROLE === You are an expert clinician + bioinformatician + formal-methods debugger. # === PRIMARY GOAL === Fix UNDERCONSTRAINTS in an SMT-LIB v2 eligibility program: cases where the SMT is TOO LAX and incorrectly marks patients eligible (false positives),,→ because it (a) omitted requirements present in natural language, (b) weakened them, (c) used stems that are too narrow / undercontextualized, or,→ (d) failed to model "strong clinical support" exclusions that a prescreen clinician would apply. You are given the program representing SIDE criteria in this case. # === SECONDARY GOAL === Do not introduce restrictions that are NOT supported by the natural-language criteria for THIS SIDE. We want faithfulness to NL, not extra rules. # === CONTEXT === Note that each trial may recruit multiple subcohorts of participants (e.g., control group vs non-control group; AD vs Dementia group).,→ We provide <shared_context> for the whole trial and <subcohort_context> for the current subcohort. Additional narrative may appear in <contextual_text>.,→ <shared_context> SHARED_CONTEXT </shared_context> <subcohort_context> CONTEXT </subcohort_context> <contextual_text> CONTEXTUAL_TEXT </contextual_text> # === ELIGIBILITY CRITERIA FOR THIS SUBCOHORT & SIDE === Here, you are given the natural language description of inclusion criteria in <inclusion_criteria> and that of exclusion criteria in <exclusion_criteria>,,→ for this subcohort only. You MUST focus ONLY on SIDE criteria. The other side will be handled elsewhere. <inclusion_criteria> INCLUSION_CRITERIA </inclusion_criteria> <exclusion_criteria> EXCLUSION_CRITERIA </exclusion_criteria> # === CURRENT SMT-LIB PROGRAM === The following SMT-LIB v2 program encodes the eligibility criteria for this (trial, subcohort, side). It may be underconstrained relative to NL.,→ <current_smt_program> SMT_PROGRAM </current_smt_program> # === UNDERCONSTRAINT AUDIT (MANDATORY) === Before editing, you MUST audit for these underconstraint failure modes and fix any that apply: (U1) Missing gates: - A requirement exists in the NL for THIS SIDE but is missing in SMT (no variable, no assertion, or assertion is vacuous).,→ (U2) Weakened logic / wrong structure: - NL implies AND but SMT encoded OR or dropped conjuncts. - NL implies a threshold, comparator, or window but SMT omits it or flips comparator (<= vs <, etc). (U3) Too-narrow medical meaning vs NL umbrella: - NL uses broad umbrella terms (e.g., "other respiratory disease", "clinical condition requiring hospitalization"), but SMT encodes a narrower stem (e.g., "chronic respiratory disease") that fails to cover intended acute or non-chronic conditions.,→ - Fix by broadening to match NL (see U5 below), and ensure the actual constraints reference the broadened concept. (U4) Evidence strength at prescreen (allowed only when NL + prescreen practice support it): - For EXCLUSION: If NL excludes a condition and the patient note provides strong clinical support / clinician-documented suspicion at prescreen,,→ the SMT should be capable of triggering exclusion via a qualifier like @@suspected or @@strong_clinical_support, unless NL explicitly requires confirmed diagnosis / a specific modality. - For INCLUSION: Do NOT "invent" missing inclusion facts; but do not require post-screen tests unless NL says so. 182 Preprint. Under review. (U5) Undercontextualized or mis-scoped variable meanings (KEY UNDERCONSTRAINT SOURCE): Sometimes SMT is underconstrained because the *variables themselves* are defined too narrowly or with the wrong scope/timeframe,,→ so mining never sets them to true (or always leaves them null), and constraints donâĂŹt fire. You MUST audit variable meanings for undercontextualization in these ways: (U5.1) Scope too narrow vs NL: - NL umbrella ("other respiratory disease", "new therapeutic intervention", "symptoms suggesting acute bronchitis"),→ is encoded as a narrower concept ("chronic respiratory disease", "new COPD therapy only", etc). - Fix by introducing an umbrella symbol and bridging it from narrower ones: (assert (=> <narrow> <umbrella>)) and then use the umbrella symbol in the actual criterion. Prefer adding symbols + bridge axioms over renaming symbols. (U5.2) Evidence channel mismatch: - NL allows clinician suspicion/strong support at prescreen, but the SMT variable meaning implies "diagnosed/confirmed".,→ - Fix by introducing a qualifier variant: <stem>@@suspected or <stem>@@strong_clinical_support and add subset axiom (qualifier âĞŠ stem) if Bool. Use the qualifier in constraints only if NL/prescreen policy supports suspicion-level triggering. (U5.3) Timeframe mismatch: - NL says "history free of âĂę" / "in past 72 hours" / "current symptoms" but SMT uses the wrong window ("now" vs "inthehistory" vs "inthepastNdays").,→ - Fix by adding the correct-window symbol (reuse stem + @@window if possible) and rewrite constraints to reference the correct window.,→ IMPORTANT: - Undercontextualization fixes are permitted only when they restore faithfulness to an NL phrase for THIS SIDE and plausibly explain a false positive.,→ - You are fixing representation/coverage, not inventing new criteria. # === EDITING PRINCIPLES === 1) Minimal-but-sufficient tightening: Make the smallest set of edits that eliminates the underconstraint and restores faithfulness to NL for THIS SIDE.,→ Underconstraint fixes often require ADDING constraints, not relaxing them. 2) Reuse existing symbols as much as possible: Treat existing symbols as stems and prefer adding qualifiers of the form <stem>@@<qualifier> over introducing unrelated new stems.,→ If both <stem> and <stem>@@<qualifier> are Bool, add: (assert (=> <stem>@@<qualifier> <stem>)) so the qualifier is a subset of the stem. 3) Umbrella + list handling (match NL intent): For an umbrella term followed by a list (e.g., "such as," "i.e.," "e.g.," "including," "like"): 3.1 Exhaustive subcategories (rare): umbrella ⼹ (item1 âĹĺ item2 âĹĺ âĂę) 3.2 Non-exhaustive examples (default): (item1 âĹĺ item2 âĹĺ âĂę) âĞŠ umbrella 3.3 Ambiguous âĘŠ default to non-exhaustive examples. 4) Preserve structure: Keep existing assertion tags, :named labels, and comment style (e.g., ;; comments, REQ* labels). If you add new assertions, use REQ*_AUXILIARY* labels that do NOT collide with existing labels. 5) Side isolation (HARD): Only modify THIS SIDEâĂŹs SMT program. Do not assume the other side will compensate. 6) Meaning edits allowed ONLY to fix underconstraints: If a variableâĂŹs meaning is clearly undercontextualized relative to NL, you MAY introduce an umbrella stem and bridge it,,→ or introduce qualifiers (e.g., @@suspected). Prefer adding/bridging over renaming. 7) If, after careful review, you conclude that the current SMT program already matches the NL for THIS SIDE (no missing/weakened gates,,→ no too-narrow meanings, no timeframe mismatches) and does not allow harmful false positives, do NOT rewrite or echo the SMT program.,→ Instead, return: - "repaired_smt": "NO MODIFICATION REQUIRED" - "notes": 1âĂŞ3 sentences explaining why. # === SMT FORMATTING === STRICT FORMAT & ANNOTATION REQUIREMENTS (MUST MATCH EXACTLY) These are hard formatting constraints. If any are violated, you MUST output a full corrected SMT (do NOT return "NO MODIFICATION REQUIRED").,→ A) Allowed declaration forms / types (HARD) - You MUST only use: (declare-const <sym> Bool) 183 Preprint. Under review. (declare-const <sym> Int) (declare-const <sym> Real) - Do NOT introduce declare-fun, define-fun, Strings, enums, Datatypes, Arrays, or uninterpreted sorts. B) Variable declaration annotation (HARD) - EVERY (declare-const ...) line MUST have a single JSON object comment on the SAME LINE. - If an existing declaration already has a JSON object comment, keep it verbatim (do NOT rewrite or rewrap it). - JSON must be valid (double quotes) and based ONLY on variable meaning. Required JSON keys (exact): - For Bool: "when_to_set_to_true":"...","when_to_set_to_false":"...","when_to_set_to_null":"...","meaning":"..." - For Int/Real: "when_to_set_to_value":"...","when_to_set_to_null":"...","meaning":"..." C) "NO MODIFICATION REQUIRED" gate (HARD) - You may return "NO MODIFICATION REQUIRED" ONLY if: (1) the current SMT already satisfies (A) and (B), AND (2) it encodes ALL NL requirements for THIS SIDE (no missing/weakened constraints), AND (3) it is not too narrow vs NL umbrella terms (no undercontextualized meanings), AND (4) there are no polarity flips needed. # === OUTPUT FORMAT (STRICT) === Return ONLY a single JSON object, with **no extra text**, no Markdown fences, exactly in this shape: "repaired_smt": "<FULL SMT-LIB v2 program for this subcohort and side> OR the exact string \"NO MODIFICATION REQUIRED\" if no changes are needed",,→ "notes": "<1âĂŞ5 bullet points (as a single string) describing what you changed and which NL phrase each change restores, or why no changes are needed>",→ Constraints: âĂć Normally, the value of "repaired_smt" MUST be the entire SMT-LIB program in a single string (may include newlines).,→ âĂć Exception: if no modification is required, set "repaired_smt": "NO MODIFICATION REQUIRED" and do NOT include any SMT code there.,→ âĂć Do NOT output multiple JSON objects or any prose before/after the JSON. F.1.42 Clarify and Complete Variable Definitions Purpose.This prompt ensures that every variable in the SMT program has a complete, self- contained, and machine-readable definition. It operates only on variable declarations, adding or repairing inline JSON annotations so that each symbol can be consistently interpreted and populated by downstream patient-data extraction components. In addition to filling missing or invalid definitions, this stage clarifies variable meanings by incorporating relevant context such as time windows, thresholds, units, and evidence sources when supported by the program or eligibility text. It also resolves ambiguity by making implicit assumptions explicit, while avoiding the introduction of unsupported details. The program logic itself is left unchanged; the goal is solely to make each variable definition precise, interpretable, and operational for downstream use. # === ROLE === You are an expert bioinformatician and logic engineer for SMT-based patientâĂŞtrial matching. Note that you are not allowed to change the program itself.,→ # === TASK (VARIABLE DEFINITIONS ONLY) === You are given one SMT-LIB v2 program. Your ONLY task is to repair **variable definitions** for declarations in that program, and to **contextualize** them enough that a downstream coder can set values consistently. Concretely: ensure that **EVERY**`(declare-const ...)` line has a valid inline JSON definition comment on the **same line** (after`;;`), following the schema below. You MUST NOT change the meaning of the SMT by editing asserts, adding/removing constraints, or modifying any non-declaration lines (except for purely comment-only fixes). Do NOT do polarity fixes in this stage. # === INPUT FIELDS === You will receive these filled fields: - SHARED_CONTEXT inside <shared_context> - CONTEXT inside <subcohort_context> - CONTEXTUAL_TEXT inside <contextual_text> - INCLUSION_CRITERIA inside <inclusion_criteria> - EXCLUSION_CRITERIA inside <exclusion_criteria> 184 Preprint. Under review. - SMT_PROGRAM inside <current_smt_program> # === CONTEXT === <shared_context> SHARED_CONTEXT </shared_context> <subcohort_context> CONTEXT </subcohort_context> <contextual_text> CONTEXTUAL_TEXT </contextual_text> # === ELIGIBILITY CRITERIA FOR THIS SUBCOHORT === <inclusion_criteria> INCLUSION_CRITERIA </inclusion_criteria> <exclusion_criteria> EXCLUSION_CRITERIA </exclusion_criteria> # === CURRENT SMT-LIB PROGRAM (ONE SIDE ONLY) === <current_smt_program> SMT_PROGRAM </current_smt_program> # === HARD RULE: INCLUSION AND EXCLUSION ARE INDEPENDENT === Inclusion and exclusion programs are processed in separate runs. - If the given SMT program is an INCLUSION program: use ONLY <inclusion_criteria> to infer variable meanings; IGNORE <exclusion_criteria>.,→ - If the given SMT program is an EXCLUSION program: use ONLY <exclusion_criteria> to infer variable meanings; IGNORE <inclusion_criteria>.,→ Do NOT copy variable meanings across sides if they differ in time window, threshold, or scope. # === WHAT TO EDIT === Edit ONLY`(declare-const ...)` lines by: - Adding an inline JSON object if missing, OR - Replacing the inline JSON object if invalid, inconsistent with program use, OR under-contextualized (see invalid definition below).,→ You may also edit nearby comment-only lines ONLY if needed to move a JSON block inline, but the final result MUST have the JSON on the declare-const line. DO NOT: - rename variables - change sorts - add or remove declarations - edit assertions or any non-declaration code - introduce new constraints or helper symbols # === WHAT COUNTS AS "UNDEFINED / INVALID DECLARATION" (YOU MUST FIX) === A declare-const line is invalid if ANY holds: - No JSON object appears on the same line as`(declare-const ...)`. - The JSON exists but is not a valid JSON object (parse failure / not an object/dict). - The JSON is missing required keys (see schema below). - Any required field exists but is not a string. - A JSON block appears above the declaration (nearby comment block / group block / direct lookback), but the declare-const line itself lacks JSON. IMPORTANT: Do NOT rely on nearby JSON. Always inline it. - The JSON passes the schema but is UNDER-CONTEXTUALIZED such that a downstream coder cannot apply it consistently, i.e., it omits any qualifier/detail that is supported by at least one of: (a) the symbol name, (b) the SMT usage, (c) side-specific eligibility text, (d) provided context, AND that detail is needed to interpret/codify the patient-fact meaning. Examples include: - temporality implied by suffixes like`_now`,`_ever`,`_within_30_days`,`_baseline` - comparator/threshold context when the symbol is compared in asserts (>=, >, <=, <) - index semantics for arrays when used with`(select arr i)` if inferable - units when explicitly present in the name or criteria (do NOT invent if absent) - Note that this includes defining what "normal", "control", "healthy", "volunteer", and so forth mean. - Make sure that all abstract concepts that may result in ambiguity are concretely defined. - Be explicit about endpoints situations; this includes whether things like "in the history" and "in the future" includes now.,→ This includes common "skipped" cases: - "auto-synthesized variable" markers - nearby JSON comment blocks - group-fit variable blocks - direct JSON comment above 185 Preprint. Under review. Your output should eliminate the need for skip modes by making every declare-const self-contained. # === CONTEXT LADDER FOR DEFINITIONS (NEW) === When writing a declarationâĂŹs JSON, derive details in this priority order: 1) From the symbol name itself (e.g., suffixes like`_now`,`_within_30_days`,`_ever`,`_baseline`,`_mg_dl`). 2) From the SMT usage in asserts: - If used in`(>= x 10)` /`(<= x 10)` /`(< x 10)` /`(> x 10)`, then x is a numeric measurement and the comparator/threshold context must be reflected.,→ - If used in arithmetic like`(+ x y)` or`(/ x 2)`, then x is numeric with arithmetic semantics. - If used as`(select arr i)`, then arr is an array indexed by i; define what i refers to if inferable. - If used only as a Boolean literal inside`and/or/not`, then it is a patient-fact predicate. 3) From the eligibility text for this side (inclusion OR exclusion only, per the independence rule). 4) From <shared_context>/<subcohort_context>/<contextual_text> only to resolve cohort-specific interpretation, but do not introduce new medical constraints.,→ If you cannot find a detail (time window, unit, measurement procedure), do not invent itâĂŤuse conservative wording and push ambiguity into the relevant "when_to_set_to_null".,→ # === HARD RULE: DEFINITIONS MUST MATCH PROGRAM USE (NEW) === A declaration is considered invalid (and MUST be fixed) if its JSON meaning is inconsistent with how the symbol is used in the SMT program.,→ Examples: - JSON says "within 30 days" but the variable name/usage indicates "ever" or "current". - JSON says "boolean patient fact" but the symbol is used as numeric or array. - JSON omits a threshold/comparator even though the program uses one directly with that symbol (e.g.,`(>= lab 5)`).,→ # === SEMANTICS: HOW TO DEFINE VARIABLES === Variable definitions are ALWAYS "patient facts", NOT "eligibility flags". Note that the translation and variable meanings should be self-contained, such that they don't depend on each other for understanding (semantic recovery), nor do they depend on the trial context. For example, parent 1 and parent 2 are dependent on each other because we need to nail down one to know the other, and this case should be avoided. ,→ ,→ ,→ - "meaning" describes what the symbol states about the patient or a patient-derived measurement. - Bool semantics are patient-fact semantics (independent of side): - true = the fact is PRESENT / statement holds. - false = the fact is ABSENT / statement clearly does not hold. - null = unknown / missing / ambiguous / cannot be determined. Be explicit about: - temporality (e.g., "within 30 days prior to Day 0"), - thresholds/comparators (âĽě, >, âĽď, <), - negation and scope ("no history ofâĂę", "ever", "current"), - units and measurement context, - evidence type/source when inferable (diagnosis/problem list, medication list, lab result, imaging, procedure note).,→ # === NO-INVENTED-SPECIFICS (NEW) === You may ONLY add temporality, thresholds, comparators, scopes, or units if they are supported by at least one of: - the eligibility text for this side, - the symbol name, - the SMT usage (comparators/arithmetic/indexing), - explicit cohort/context text. Otherwise: - keep "meaning" minimal and faithful, - describe what evidence would be needed, - use "when_to_set_to_null" to capture missing/ambiguous context. # === JSON SCHEMA (STRICT) === All JSON values must be STRINGS. Use double quotes. No trailing commas. Allowed base sorts: Bool, Int, Real, String Allowed array sort form: (Array Int Bool|Int|Real|String) ## If sort == Bool: REQUIRED KEYS EXACTLY: - "meaning" - "when_to_set_to_true" - "when_to_set_to_false" - "when_to_set_to_null" ## If sort != Bool (including Arrays): REQUIRED KEYS EXACTLY: - "meaning" - "when_to_set_to_value" - "when_to_set_to_null" Do NOT add extra keys. # === WHERE TO PUT THE JSON === 186 Preprint. Under review. - The JSON must be on the SAME LINE as the`(declare-const ...)`. - Put it after`;;`. Example: (declare-const foo Bool) ;; "meaning":"...","when_to_set_to_true":"...","when_to_set_to_false":"...","when_to_set_to_null":"...",→ If the line already has JSON and it is wrong, REPLACE it. # === HOW TO WRITE "WHEN_TO_SET..." FIELDS === Write operational instructions for downstream patient coding. For Bool: - when_to_set_to_true: explicit evidence consistent with meaning AND within the stated timeframe (if any). - when_to_set_to_false: explicit denial/rule-out or clear evidence of absence within timeframe (if any). - when_to_set_to_null: no mention, ambiguous/conflicting, timeframe mismatch, cannot verify, or missing context needed to apply meaning.,→ For numeric/string/array: - when_to_set_to_value: how to extract/compute the value (include units and timeframe if supported). - when_to_set_to_null: when extraction is impossible or unreliable; missing units/timeframe needed to interpret; ambiguous/conflicting evidence; timeframe mismatch.,→ Arrays (still use non-Bool schema): - meaning: explain index semantics (what index i refers to) if inferable; otherwise keep minimal and state unknown. - when_to_set_to_value: how to populate elements; if you cannot reliably populate, set to null. # === CONTEXTUALIZATION CHECKLIST === For each declaration, ensure the JSON captures ALL applicable explicit or implicit qualifiers and contextual information that constrain the patient-fact meaning, BUT ONLY when supported by symbol name / SMT usage / side-specific eligibility text / provided context (do NOT invent). ,→ ,→ Examples of qualifiers to capture when supported: - Time window (current/ever/within X days/baseline; pre/post treatment; screening period). - Comparator + threshold if used in numeric comparisons (âĽě, >, âĽď, <), including "at least/at most", ranges, and "normal/abnormal" only if defined.,→ - Units if present; otherwise do NOT invent. - Negation & scope ("no history ofâĂę", "priorâĂę", "activeâĂę", "rule outâĂę", "without evidence ofâĂę"). - Episode/severity/frequency qualifiers (e.g., "acute", "chronic", "refractory", "severe", "recurrent", "âĽě2 episodes").,→ - Modality/method qualifiers (e.g., "by biopsy", "MRI-confirmed", "lab test type", "ECG", "imaging"). - Route/dose/duration qualifiers for therapies (e.g., "systemic", "oral", "IV", "âĽě10 mg/day prednisone equivalent for âĽě14 days").,→ - Population/cohort qualifiers that affect interpretation (e.g., "non-control cohort", "metastatic", "post-menopausal") ONLY if they change what the variable denotes as a patient fact (not as an eligibility flag). ,→ ,→ - Data source type (labs/diagnosis/medication/procedure) if inferable. - Other contextual information that would be important to make the variable meaning self-contained. - Abstract concepts that may lead to ambiguity are all clearly and concretely defined. - Be explicit about endpoints situations; this includes whether things like "in the history" and "in the future" includes now.,→ # === EXAMPLES OF GOOD CONTEXTUALIZATION === Example 1 Candidate meaning: "Whether the patient has conditions that could confound study evaluation." If the trial context clearly says the study evaluates zolpidem tartrate sublingual tablet for improving sleep onset in adult patients with insomnia,,→ a good rewritten meaning is: "Whether the patient has a condition that could confound evaluation of the efficacy or safety of zolpidem tartrate sublingual tablet for improving sleep onset in adult patients with insomnia.",→ Why this is good: - it resolves "study evaluation" - it names the intervention, goal, and trial subject/context - it remains a variable meaning rather than a trial summary Example 2 Candidate meaning: "Whether the patient has a disease likely requiring antibiotic treatment that could interfere with assessment." If the trial context clearly indicates a study of antibacterial treatment for a target infection, a good rewritten meaning is: "Whether the patient has another disease or infection, apart from the study-target infection, that is likely to require antibiotic treatment and could interfere with assessment of the study intervention.",→ If the intervention is clear enough, an even better standalone rewrite is: "Whether the patient has another disease or infection, apart from the infection under study, that is likely to require antibiotic treatment and could interfere with assessment of the study antibiotic regimen.",→ Example 3 Candidate meaning: 187 Preprint. Under review. "Whether the patient is newly diagnosed with chronic obstructive pulmonary disease." Good rewrite: "Whether the patient has been newly diagnosed with chronic obstructive pulmonary disease." Do not reduce this to: "Whether the patient currently has chronic obstructive pulmonary disease." # === OUTPUT FORMAT (STRICT) === Return EITHER: Option A: exactly this plain string, with no quotes and no extra text: NO_MODIFICATION_REQUIRED OR Option B: a single JSON object, with no extra text, no Markdown fences: "repaired_smt": "<FULL SMT-LIB v2 program with ONLY declare-const line edits (plus necessary comment moves) as a single string>",,→ "notes": "<short summary of how many declarations were fixed and any tricky interpretations>" Rules: - Return NO_MODIFICATION_REQUIRED only if every declare-const line already has a valid, self-contained, sufficiently contextualized inline JSON definition and no comment-block-to-inline move is needed.,→ - Otherwise return the JSON object. - Do NOT include any other top-level keys. - Do NOT output multiple JSON objects. F.1.43 Database Preparation: Disease Categorization Purpose.This prompt determines how each disease is relevant to the clinical trial by label- ing the trialâ ̆ A ́ Zs intended relationship to that disease (e.g., treating, preventing, monitoring, or not relevant). The goal is to distinguish which diseases represent true trial targets versus incidental mentions, so that only clinically meaningful disease signals are retained for downstream retrieval. This helps ensure that disease-based matching reflects the trialâ ̆ A ́ Zs actual intent rather than noisy or background conditions. # === ROLE === You are a professional clinician reviewing clinical trial eligibility requirements. You'l be provided with two input:,→ (1) <clinical_trial_description> summarizes a clinical trial, (2) <input_disease> contains list of disease. # === TASK === Your task is to evaluate each disease and determine how the clinical trial acts upon it. Assign at least one category (A/B/C/D) that describes the intended effect of the trial on each disease.,→ You must produce exactly one output item for each input disease. The number of objects in the output JSON array must be identical to the number of diseases provided in <input_disease>.,→ # === INPUT === <clinical_trial_description> #CLINICAL_TRIAL_DESCRIPTION# </clinical_trial_description> <input_disease> #DISEASE# </input_disease> # === CATEGORIES AND GUIDELINES === A - Clinically addresses (symptom/condition/finding): The trial intervention is intended to improve, resolve, control, or reduce the severity/frequency of the target clinical state y (a symptom, diagnosis, abnormal finding, functional impairment, or measurable biomarker) in population x. ,→ ,→ B - Prevents: The trial intervention is intended to reduce the probability of first onset of clinical state y in population x, relative to no intervention or standard care. Use this category only when y is not currently present at baseline. ,→ ,→ C - Other (Finding): The trial intervention is intended to affect y in a clinically relevant way that is not primarily improvement/control or prevention (e.g., diagnose, detect, monitor, predict, stratify risk, measure response, or characterize y) for population x. ,→ ,→ 188 Preprint. Under review. D - Not of clinical interest: The clinical state y is not a clinically meaningful focus of the trial. y is only incidental, overly broad/unspecific, or unrelated background context.,→ Use this category only if the disease does not fall into categories A, B, or C. If category D is assigned, it must be the only category selected for that disease (i.e., do not combine D with A, B, or C).,→ # === OUTPUT === [ "disease": <disease_verbatim>, "disease_idx": "<disease_index_verbatim>", "trial_effect_category": ["A" | "B" | "C" | "D", "..."], # must be a non-empty list "rationale": "... why you make this classification ..." , ] F.1.44 Database Preparation: Remove Redundant or Overly General Targets Purpose.This prompt filters the list of candidate diseases and clinical targets by removing items that are too general or redundant given more specific alternatives in the same list. The goal is to keep only the most informative and specific targets for each trial while preserving recall. General items are retained unless a clearly more precise target already captures the same clinical meaning. This step ensures that the final target set remains concise and meaningful for retrieval without discarding potentially useful signals. You are filtering redundant or overly-general target items for a clinical trial, using the trial description. GOAL: Return KEEP/DROP decisions for each candidate disease and each candidate positive literal. We are NOT building an entailment graph. We only decide which items to drop because they are too general or not the most specific form, conditioned on the trial context and the full candidate list.,→ IMPORTANT RULES: - Default to KEEP when uncertain. - DROP only if the trial context makes it unambiguous that a more specific target in the candidate list is what the trial is about AND the more general item adds no extra meaning.,→ - If a general item has multiple plausible children targets and the trial could be targeting multiple or is ambiguous, KEEP the general item.,→ - If the trial targets both general and specific concepts explicitly (e.g., multiple conditions), KEEP both unless the general one is clearly redundant.,→ - Do not invent new items. Only reference indices given. - Note that you should ONLY compare within the lists given to you. If the an item is a more general form of the trial's target but there isn't a more specific term left in the item lists, we should still keep the item, not drop it. ,→ ,→ OUTPUT FORMAT: Return a single JSON object with this structure: "diseases": "<idx>": "decision":"KEEP|DROP","reason":"...","kept_because_of":["<idx>", ...], ... , "positive_literals": "<idx>": "decision":"KEEP|DROP","reason":"...","kept_because_of":["<idx>", ...], ... - "kept_because_of" is optional. Use it mainly when you DROP something because other items already capture the specific meaning.,→ TRIAL DESCRIPTION: #CLINICAL_TRIAL_DESCRIPTION# DISEASE CANDIDATES (index -> disease name): #DISEASES_JSON# POSITIVE LITERAL CANDIDATES (index -> object with name/template/entity_text): #POSLITS_JSON# 189 Preprint. Under review. F.1.45 Database Preparation: Label How the Trial Relates to Each Clinical Findings Purpose.This prompt determines how each extracted clinical target (from eligibility crite- ria) is relevant to the trial by labeling the trialâ ̆ A ́ Zs intended relationship to that target (e.g., treating, preventing, monitoring, or not relevant). The goal is to identify which eligibility-derived signals represent meaningful trial targets versus incidental conditions, so that only clinically relevant targets are retained for retrieval. This complements disease-based labeling by capturing non-disease clinical factors (e.g., treatments, procedures, biomarkers) that reflect the trialâ ̆ A ́ Zs true intent. # === ROLE === You are a professional clinician reviewing clinical trial eligibility requirements. You'l be provided with two input:,→ (1) <clinical_trial_description> summarizes a clinical trial, (2) <positive_literal_list> contains canonicalized variables extracted from trial's inclusion criteria. Each variable encodes a requirement fact about a procedure.,→ # === TASK === Your task is to evaluate each variable and determine how the clinical trial acts upon it. Assign at least one category (A/B/C/D) that describes the intended effect of the trial on each variable.,→ You must produce exactly one output item for each input positive literal. The number of objects in the output JSON array must be identical to the number of positive literals provided in <positive_literal_list>.,→ # === CATEGORIES AND GUIDELINES === A - Clinically addresses (symptom/condition/finding): The trial intervention is intended to improve, resolve, control, or reduce the severity/frequency of the target clinical state y (a symptom, diagnosis, abnormal finding, functional impairment, or measurable biomarker) in population x. ,→ ,→ B - Prevents: The trial intervention is intended to reduce the probability of first onset of clinical state y in population x, relative to no intervention or standard care. Use this category only when y is not currently present at baseline. ,→ ,→ C - Other (Finding): The trial intervention is intended to affect y in a clinically relevant way that is not primarily improvement/control or prevention (e.g., diagnose, detect, monitor, predict, stratify risk, measure response, or characterize y) for population x. ,→ ,→ D - Not of clinical interest: The clinical state y is not a clinically meaningful focus of the trial. y is only incidental, overly broad/unspecific, or unrelated background context.,→ Use this category only if the disease does not fall into categories A, B, or C. If category D is assigned, it must be the only category selected for that disease (i.e., do not combine D with A, B, or C).,→ # === INPUT === <clinical_trial_description> #CLINICAL_TRIAL_DESCRIPTION# </clinical_trial_description> <positive_literal_list> #POSITIVE_LITERAL_LIST# </positive_literal_list> # === GUIDELINES === 1. Please return strictly the same number of outputs as the number of inputs! # === OUTPUT === [ "entity_variable_name": <entity_variable_name verbatim>, "entity_variable_idx": "<entity_variable_index_verbatim>", "target_category": ["A" | "B" | "C" | "D", "..."], "rationale": "... why you make this classification ..." , ] F.1.46 Database Preparation: Label How the Trial Relates to Each Procedure Purpose. This prompt determines how each procedure-related variable is relevant to the clinical trial by labeling the trialâ ̆ A ́ Zs intended relationship to that procedure (e.g., improving effectiveness, reducing complications, modifying delivery, or not relevant). 190 Preprint. Under review. The goal is to identify which procedure-related signals represent meaningful trial targets versus incidental mentions, so that only clinically relevant procedural aspects are retained for retrieval. This ensures that the system captures trials focused on interventions involving procedures, not just diseases or general clinical conditions. # === ROLE === You are a professional clinician reviewing clinical trial eligibility requirements. You'l be provided with two input:,→ (1) <clinical_trial_description> summarizes a clinical trial, (2) <canonicalized_variable_list> contains canonicalized variables and their description extracted from trial's inclusion criteria. Each variable encodes a requirement fact about a procedure.,→ # === TASK === Your task is to evaluate each variable and determine how the clinical trial acts upon it. Assign at least one category (A/B/C/D) that describes the intended effect of the trial on each variable.,→ You must produce exactly one output item for each input positive literal. The number of objects in the output JSON array must be identical to the number of positive literals provided in <positive_literal_list>.,→ # === RELEVANCE CATEGORIES === A- Improves effectiveness of (procedure) The trial intervention is intended to increase the success rate, completeness, durability, precision, or clinical benefit of procedure p (or its peri-procedural protocol) for population x.,→ B- Reduces procedure-related adverse effects (side effects/complications/conditions_in_recovery): The trial intervention is intended to decrease the incidence, severity, duration, or downstream consequences of adverse events a caused by or associated with procedure p, including peri-operative complications and recovery-phase conditions, for population x. ,→ ,→ C- Other (Procedure): The trial intervention is intended to modify how procedure p is delivered or experienced in ways not captured above (e.g., shorten recovery time, reduce resource use, improve adherence, improve tolerability, optimize timing/dose, improve workflow/safety monitoring) for population x. ,→ ,→ D - Not of clinical interest: The procedure p is not a clinically meaningful focus of the trial. p is only incidental, overly broad/unspecific, or unrelated background context.,→ Use this category only if the disease does not fall into categories A, B, or C. If category D is assigned, it must be the only category selected for that disease (i.e., do not combine D with A, B, or C).,→ # === INPUT === <clinical_trial_description> #CLINICAL_TRIAL_DESCRIPTION# </clinical_trial_description> <canonicalized_variable_list> #POSITIVE_LITERAL_LIST# </canonicalized_variable_list> # === GUIDELINES === 1. Please return strictly the same number of outputs as the number of inputs! # === OUTPUT === [ "entity_variable_name": <entity_variable_name verbatim>, "entity_variable_idx": "<entity_variable_index_verbatim>", "target_category": ["A" | "B" | "C" | "D", "..."], "rationale": "... why you make this classification ..." , ] F.1.47 Database Preparation: Label How the Trial Relates to Each Substance Use Purpose. This prompt determines how each substance-related variable is relevant to the clinical trial by labeling the trialâ ̆ A ́ Zs intended relationship to that substance (e.g., reducing use, mitigating harms, enhancing benefits, or not relevant). The goal is to identify which substance-related signals represent meaningful targets of the trial versus incidental mentions, so that only clinically relevant substance-use factors are 191 Preprint. Under review. retained for retrieval. This ensures the system captures trials focused on substance exposure, treatment, or management, rather than unrelated background information. # === ROLE === You are a professional clinician reviewing clinical trial eligibility requirements. You'l be provided with two input:,→ (1) <clinical_trial_description> summarizes a clinical trial, (2) <positive_literal_list> contains canonicalized variables extracted from trial's inclusion criteria. Each variable encodes a requirement fact about a product or substance.,→ Your task is to evaluate each variable and determine how the clinical trial acts upon it. Assign at least one category (A/B/C/D/E) that describes the intended effect of the trial on each variable.,→ You must produce exactly one output item for each input positive literal. The number of objects in the output JSON array must be identical to the number of positive literals provided in <positive_literal_list>.,→ # === CATEGORIES === A- Reduces exposure/use: The trial intervention is intended to decrease the amount, frequency, intensity, or likelihood of exposure to or use of substance s (including cessation/reduction behaviors) in population x.,→ B- Mitigates harms of exposure/use: Given exposure to or use of substance s, the trial intervention is intended to reduce the negative health effects y attributable to s (e.g., toxicity, withdrawal symptoms, organ damage, overdose risk) in population x.,→ C- Enhances benefits of exposure/use: Given exposure to or use of substance s, the trial intervention is intended to increase a desired effect y or improve the benefitâĂŞrisk profile associated with s (e.g., improve therapeutic response, improve absorption/bioavailability, increase protective effect) in population x. ,→ ,→ D- Other (Substance): The trial intervention is intended to change the relationship between x and substance s in a way not captured above (e.g., monitor use, detect exposure, predict response, personalize dosing, prevent relapse, reduce cravings without explicit reduction endpoint) for population x. ,→ ,→ E - Not of clinical interest: The substance s is not a clinically meaningful focus of the trial. s is only incidental, overly broad/unspecific, or unrelated background context.,→ Use this category only if the disease does not fall into categories A, B, C, or D. If category E is assigned, it must be the only category selected for that disease (i.e., do not combine E with A, B, C, or D).,→ # === INPUT === <clinical_trial_description> #CLINICAL_TRIAL_DESCRIPTION# </clinical_trial_description> <positive_literal_list> #POSITIVE_LITERAL_LIST# </positive_literal_list> # === GUIDELINES === 1. Please return strictly the same number of outputs as the number of inputs! # === OUTPUT === [ "entity_variable_name": <entity_variable_name verbatim>, "entity_variable_idx": "<entity_variable_index_verbatim>", "target_category": [ "A" | "B" | "C" | "D" | "E", "..."], "rationale": "... why you make this classification ..." , ] F.2 Prompts for Patient-Side Semantic Parsing F.2.1 Preprocesing: Patient Fact Extraction Purpose.This prompt is used to turn a patient note into a clear list of distinct patient facts. Its goal is to make sure each fact is complete on its own, includes the details that belong with it, does not overlap with other facts, and stays faithful to the original note. It also requires each fact to be tied to the exact supporting text so the extraction can be checked later. 192 Preprint. Under review. === ROLE === You are an expert patient fact extractor. Task: produce a mutually-exclusive, collectively-exhaustive (MECE) list of self-contained patient facts from the given note.,→ === INPUTS === <contextual_text> #CONTEXTUAL_TEXT# </contextual_text> <patient_note> #PATIENT_NOTE# </patient_note> === RULES === 1. A single patient fact must describe one core medical entity together with every qualifier that directly qualifies it (e.g., stage, marker, value, location). If several parallel qualifiers refer to the same entity, keep them in the same fact, do not split them. ,→ ,→ 2. Obey the MECE (Mutually-Exclusive, Collectively-Exhaustive) principle. The final fact list must cover all information without overlap or omission. 2.1 Merge details that belong to the same entity into one fact. 2.2 Split any information that (1) refers to different entities, or (2) represents different semantic levels of the same entity (e.g., a laboratory measurement vs. the clinical diagnosis derived from it) into separate, self-contained facts. ,→ ,→ <2.Example> Patient notes: "Pericardial fluid was kappa light-chainâĂŞrestricted CD10-positive monotypic B cells expressing FMC-7, CD19, CD20 and MYC rearrangement, consistent with BurkittâĂŹs lymphoma.",→ fact: "Pericardial fluid contained kappa light-chainâĂŞrestricted, CD10-positive monotypic B cells expressing FMC-7, CD19, CD20 and MYC rearrangement.",→ fact: "Findings in the pericardial fluid were consistent with BurkittâĂŹs lymphoma." </2.Example> 3. Every extracted fact must make complete sense when read in isolation: 3.1. Spell out the entity or intervention instead of relying on pronouns like "it" or "this treatment." 3.2. Ensure all references are explicit, leaving no doubt about who or what the fact describes. 4. Use only information that appears verbatim in the inputs or is unambiguously entailed by the contextual text. 5. Do NOT rely on external knowledge or assumptions. 6. Provide exact provenance: quote the sentence(s) or phrase(s) that support each extracted fact. 7. Do not alter the meaning of the patient note. 8. Each extracted fact must be self-contained. === OUTPUT FORMAT === <patient_facts> [ "fact": "<Fact 1>", "text_span": "<exact supporting text>", "fact": "<Fact 2>", "text_span": "<exact supporting text>", ... ] </patient_facts> F.2.2 Preprocessing: Patient Fact Extraction Checker Purpose. This prompt is used to check whether the extracted patient facts are a faithful and usable summary of the original note. It verifies that nothing important was missed, nothing new was added, and each fact can stand on its own, then gives a simple pass or fail result with an explanation only when there is a problem. === ROLE === You are an expert technical editor. === TASK === Given the raw patient note and a JSON array of the machine-extracted patient facts, decide whether the extraction is complete and does not alter the original meaning of the patient note. The patient note extraction is for later matching to satisfying clinical trials --- so as long as the extracted list keeps the same set of information, it should be counted as good extraction. ,→ ,→ ,→ === CHECKLIST === Join all extracted fact by AND's and place it at "combined_extracted_facts". For every extracted JSON, work through the following checklist:,→ 1. ALL_FACTS_DETAILS_EXTRACTED: Compare original notes to "combined_extracted_facts". Are all patient facts and patient details extracted? YES or NO.,→ 2. NO_INFORMATION_ADDED: Is there NO new information added (in comparison to the original JSON note) in the extracted JSON? YES or NO.,→ 3. ALL_EXTRACTIONS_SELFCONTAINED: Are all extracted patient fact self-contained? YES or NO If all 3 items are YES, set "OVERALL_GOOD_EXTRACTION" to YES and set "explanation" to empty (""). Otherwise, set "OVERALL_GOOD_EXTRACTION" to NO and explain what went wrong in "explanation".,→ 193 Preprint. Under review. === INPUT === <PATIENT_NOTE> NOTE </PATIENT_NOTE> <EXTRACTED_JSON> EXTRACTED </EXTRACTED_JSON> === OUTPUT FORMAT === Return ONLY a JSON object: "combined_extracted_facts": "combined_extracted_facts" "ALL_FACTS_DETAILS_EXTRACTED": "YES" | "NO", "NO_INFORMATION_ADDED": "YES" | "NO", "ALL_EXTRACTIONS_SELFCONTAINED": "YES" | "NO", "OVERALL_GOOD_EXTRACTION": "YES" | "NO", "explanation": "...your explanation here", F.2.3 Preprocessing: Entity Expander Purpose.This prompt rewrites each patient fact so that every medical condition or finding appears as its own clear, standalone phrase, making later concept matching easier and more reliable. It expands combined entities, spells out shorthand when needed, removes irrelevant always-true wording, and keeps the original meaning and logic unchanged while preserving one rewritten line for each input fact. # === ROLE === You are a careful, deterministic clinical-text editor. Task: For each patient fact, expand coordinated medical-entity spans in noun form so every medically relevant entity becomes a single, contiguous phrase (duplicate shared heads where needed).,→ Goal: Later, we will replace these entities with their SNOMED canonical names. Therefore, ensure that every medically relevant entity appears as an independent text span and that no other wording or meaning in the fact is altered. ,→ ,→ # === INPUT === <contextual_text> #CONTEXTUAL_TEXT# </contextual_text> <original_patient_fact_list> #PATIENT_FACT_TEXT# </original_patient_fact_list> # === Example Guidelines === 1. **Shared-head expansion of entities** âĂŞ "fracture of tibia and fibula" âĘŠ "fracture of tibia and fracture of fibula" âĂŞ "retropharyngeal or buccal cellulitis" âĘŠ "retropharyngeal cellulitis or buccal cellulitis" 2. **Do not duplicate non-entity action phrases** âĂŞ "submission of a throat swab specimen for bacterial culture, identification, and antibiotic-susceptibility testing" stays exactly the same.,→ âĂŞ "patient presents with cough or shortness of breath" stays exactly the same. 3. **Convert adjectival medical descriptors into explicit noun-form expressions** âĂŞ "hypertensive patient" âĘŠ "patient with hypertension". 4. **Remove clauses that always evaluate to true** (e.g., "of any race", "of any sex/gender"). 5. **Preserve original logical relationships after rewriting** âĂŞ "sore and scratchy throat" âĘŠ "sore throat AND scratchy throat". âĂŞ "acute tonsillitis/pharyngitis caused by Streptococcus pyogenes" âĘŠ "acute tonsillitis caused by Streptococcus pyogenes OR pharyngitis caused by Streptococcus pyogenes".,→ 6. **Turn abbreviations into full names**; keep only the full name if both appear. 7. **If two alternative, equivalent names exist**, keep only the one more likely to match a SNOMED concept via SapBert-based embedding search.,→ # === RULES === Return the same number of lines, each prefixed with its original 0-based index: [00] rewritten patient fact [01] rewritten patient fact [02] rewritten patient fact 194 Preprint. Under review. # === OUTPUT FORMAT (output exactly these two blocks) === <rewritten_patient_fact_list> [00] âĂę [01] âĂę [02] âĂę </rewritten_patient_fact_list> F.2.4 Preprocessing: Logic Rewriter Purpose.This prompt rewrites each patient fact into a more precise and logically explicit form so it can be converted into formal rules later. It keeps the medical meaning the same, makes relationships like AND, OR, NOT, and numeric thresholds clear, preserves each medical entity exactly as written, and outputs one cleaned, unambiguous line for each original fact. # === ROLE === You are a careful, deterministic clinical-text editor. # === BACKGROUND === You are being inputted with factual statements describing a single patientâĂŹs condition or state. Your task is to make implicit logical details explicit (qualifiers, numerical comparators, inclusive/exclusive OR, etc.) and precise without changing the intended medical meaning.,→ # === TASK === For each patient fact, rewrite it so that logical structure is explicit and unambiguous while preserving the original medical intent.,→ Goal: These rewritten facts will be translated into SMT assertions. 1. Ensure every fact is phrased from the perspective of one patient (singular). 2. Treat each medically relevant entity phrase as an indivisible span; do **not** alter, duplicate, or remove any entity wording.,→ # === INPUT === <contextual_text> #CONTEXTUAL_TEXT# </contextual_text> <original_patient_fact_list> #PATIENT_NOTE# </original_patient_fact_list> # === GUIDELINES === 0. Make hierarchies/priorities between logical connectives (AND, OR, XOR, NOT) explicit by adding parentheses (inner parentheses evaluated before outer ones).,→ 1. Convert abbreviations to full names; if both exist, keep only the full name. 2. Remove clauses that are meaningless. 3. Spell out numerical bounds and comparators: - "50 % - "blood pressure < 140/90 mmHg" âĘŠ "systolic blood pressure < 140 mmHg AND diastolic blood pressure < 90 mmHg" 4. Use only: XOR, OR, AND, NOT. Rewrite other forms ("and/or", "AND/OR") as either AND or OR depending on meaning. 5. When a qualifier applies to multiple entities but is stated once, duplicate it so it appears directly with each qualified entity. Keep qualifiers inside the parentheses of the subject they qualify.,→ - If an example enumeration applies to multiple entities, repeat it for each entity. - "The patient has systemic amyloidosis with involvement of the lungs, involvement of the tongue, involvement of the bladder, and involvement of the heart." âĘŠ "The patient has systemic amyloidosis with involvement of the lungs AND systemic amyloidosis with involvement of the tongue AND systemic amyloidosis with involvement of the bladder AND systemic amyloidosis with involvement of the heart" ,→ ,→ ,→ 6. Always preserve the core semantic subject of the original fact. 7. If a medical term and a plain-language synonym are both present, keep only the medical term. 8. Keep explanations, definitions, or examples in parentheses immediately after the entity they describe, or find the best way to make their references clear.,→ # === OUTPUT FORMAT (output exactly these two blocks) === Return the same number of lines in the following way inside the <rewritten_patient_fact_list> tags, each prefixed with its original 0-based index:,→ <rewritten_patient_fact_list> [00] The patient ... [01] The patient ... [02] The patient ... </rewritten_patient_fact_list> 195 Preprint. Under review. F.2.5 Preprocessing: Logic Rewrite Checker Purpose.This prompt checks whether each rewritten patient fact is logically clearer with- out changing what the original fact meant. It reviews each original-and-rewritten pair for issues like missing parentheses, unclear logic, missed abbreviation expansion, added infor- mation, or lost qualifiers, and then returns a pass or fail result for each one, along with a corrected rewrite when needed. # === ROLE === You are an expert in clinical text and logic. Your goal is to check whether the logical rewrite of clinical **patient facts** is correct. # === BACKGROUND === You are being inputted with factual statements describing a single patientâĂŹs condition or state. The rewrite should make implicit logical details explicit (qualifiers, numerical comparators, inclusive/exclusive OR, etc.) **without changing the intended medical meaning**.,→ # === INPUT === <original_rewrite_pairs> #ORIGINAL_REWRITE_PAIRS# </original_rewrite_pairs> # === CHECKLIST === Work through the following list for each indexed pair (ORIGINAL vs REWRITTEN). Record results as "YES" or "NO": 0. HIERARCHIES_CAPTURED: Are all hierarchies between logical connectives made explicit and correct via parentheses (inner parentheses evaluated before outer parentheses)?,→ 1. ABBREVIATIONS_EXPANDED: Are abbreviations correctly expanded to full names (keeping only the full name if both appear)?,→ 2. REMOVE_REDUNDANT_CLAUSES: Are clauses that are meaningless removed? 3. DUPLICATE_QUALIFIERS: When a qualifier applies to multiple entities but was stated once, is it duplicated so it appears with each entity it qualifies (and remains inside the parentheses of the subject it qualifies)?,→ 4. PRESERVE_SEMANTIC_MEANING: Does the rewrite preserve the semantic meaning of the original requirement? 5. NO_NEW_INFORMATION: Does the rewrite not add information that wasnâĂŹt present in the original? 6. NO_LOGICAL_AMBIGUITY: Are ambiguous logical connectives rewritten to clear forms? Make a final judgement in "ALL_GOOD": - "YES" if **all** checklist items are "YES" - "NO" if **any** checklist item is "NO" If "ALL_GOOD" is "NO", provide: - "explanation": a brief reason of what failed and why - a candidate correction that would pass all checks in **both** fields: - "corrected_requirement": "<candidate rewrite>" - "corrected_fact": "<candidate rewrite>" # === OUTPUT FORMAT (output exactly these two blocks) === <verifier_output> "by_index": "0": "HIERARCHIES_CAPTURED": "YES" | "NO", "ABBREVIATIONS_EXPANDED": "YES" | "NO", "REMOVE_REDUNDANT_CLAUSES": "YES" | "NO", "DUPLICATE_QUALIFIERS": "YES" | "NO", "PRESERVE_SEMANTIC_MEANING": "YES" | "NO", "NO_NEW_INFORMATION": "YES" | "NO", "NO_LOGICAL_AMBIGUITY": "YES" | "NO", "ALL_GOOD": "YES" | "NO", "explanation": "<explain what is not good>", "corrected_requirement": "<candidate rewrite that makes all items YES>", "corrected_fact": "<same candidate rewrite>" // include every index present in the input ... </verifier_output> F.2.6 Entity Canonicalization: Medical Entity Recognizer Purpose. This prompt is used to find as many medically meaningful entity mentions as possible in a piece of clinical text. It extracts the exact text span for each entity, allows overlapping entities to improve recall, avoids pulling in non-entity wording like age, sex, consent, or study logistics, and returns each recognized entity with a brief note about what medical concept it may refer to. 196 Preprint. Under review. # === ROLE === You are a Medical Entity Recognizer. Task: Our goal is to optimize for medical entity recognition recall. Place all entity you recognize from text into "entity_name" and record the contiguous span you recognized this entity from in "extracted_span". Then return ONLY a JSON array specifying the surface / text span of each entity and the explanation of what it (potentially) means as an entity. ,→ ,→ ,→ # === INPUT === <criterion> #REQUIREMENT_TEXT# </criterion> # === EXTRACTION RULES === 1. Our goal is to optimize for entity recognition recall. Identify as many entities as possible. 2. Again, our goal is to optimize for entity recognition recall. For situations under which multiple entities have overlapping text spans, extract all of them.,→ 3. Place all entity you recognize from text into "entity_name" and record the contiguous span you recognized this entity from in "extracted_span", exactly as the output format. The definition to entity is the smallest contiguous span needed to completely identify this identity. ,→ ,→ 4. If you know the concept name is in SMOWMED, then put down the snowmed concept as the entity name. 5. Medical entities we want to extract include but are not limited to drugs, procedures, symptoms, diseases, organisms, anatomy/body structure, events, specimen, and substance.,→ 6. For each extracted entity, explain what it potentially means as a medical entity. 7. Make sure that you keep the extracted entity surface AS IS. Do not modify, paraphrase, or abbreviate any extracted entity.,→ 8. Comparators (e.g., greater than, equal to) and numerical values should usually not appear in any extracted surface string unless they are necessary components of an entity name.,→ 8.a. e.g., from "Patients aged âĽě18 years and âĽď90 years presenting with dysphagia or presenting with food impaction.", we should not extract "Patients aged âĽě18 years and âĽď90 years" or "aged âĽě18 years"; rather, we should only extract "dysphagia" and "food impaction". ,→ ,→ 9. Phrases such as "diagnosis of", "patients with", "clinical suspicion of", "history of", "prior", "current", "in the future", and "ability to" are redundant information and do not help to form seperate meaninful entities.,→ 9.a. e.g., from requirement "Clinical diagnosis of hypertension.", we should only extract "hypertension", not "clinical diagnosis of hypertension".,→ 9.b. e.g., from requirement "Patients with the ability to undergo esophagogastroduodenoscopy and the ability to undergo esophageal biopsies.", we should not extract "Patients with the ability to undergo esophagogastroduodenoscopy", "ability to undergo esophagogastroduodenoscopy", or "ability to undergo esophageal biopsies"; instead, we should extract "esophagogastroduodenoscopy", "esophageal biopsies", and "biopsies". ,→ ,→ ,→ ,→ 9.c. e.g., from "Patients aged âĽě 18 years of either sex.", you should extract nothing. e.g., from "Age of the patient is 65 years or older.", you should extract nothing.,→ 10. Do not extract anything sheerly related to gender, informed consent, study procedures, study restrictions, pregnancy status, ability to get pregnant, or voluntariness of participation.,→ 10.a., e.g., from requirement "Patient and/or patientâĂŹs parents or patientâĂŹs guardian signed an informed consent form.", you should extract nothing.,→ 11. Do not extract standalone obvious qualifiers (e.g., ECOG performance status, NYHA classes) 11.a., e.g., from "chronic heart failure classified as New York Heart Association class I", we should only extract "chronic heart failure" and "heart failure", not "New York Heart Association class I".,→ # === EXTRACTION EXAMPLES === <example_1> Input: <example_input> "Contradiction to esophagogastroduodenoscopy or contradiction to esophageal biopsies, such as presence of Boerhaave's syndrome, or history of bleeding disorder, or elevated international normalized ratio (INR).",→ </example_input> Identified Entities: <identified_medical_entities> [ "entity_name": "contradiction to esophagogastroduodenoscopy", "extracted_span": "Contradiction to esophagogastroduodenoscopy",,→ "entity_name": "esophagogastroduodenoscopy", "extracted_span": "esophagogastroduodenoscopy", "entity_name": "contradiction to esophageal biopsies", "extracted_span": "contradiction to esophageal biopsies",,→ "entity_name": "esophageal biopsy", "extracted_span": "esophageal biopsies", "entity_name": "biopsy", "extracted_span": "biopsies", "entity_name": "Boerhaave's syndrome", "extracted_span": "Boerhaave's syndrome", "entity_name": "bleeding disorder", "extracted_span": "bleeding disorder", "entity_name": "International Normalized Ratio raised", "extracted_span": "elevated international normalized ratio (INR)",,→ "entity_name": "International normalized ratio", "extracted_span": "international normalized ratio (INR)", ] </identified_medical_entities> </example_1> <example_2> Input: <example_input> "Clinical diagnosis of acute tonsillitis caused by Streptococcus pyogenes and clinical diagnosis of acute pharyngitis caused by Streptococcus pyogenes.",→ 197 Preprint. Under review. </example_input> Identified Entities: <identified_medical_entities> [ "entity_name": "Acute staphylococcal tonsillitis", "extracted_span": "acute tonsillitis caused by Streptococcus pyogenes",,→ "entity_name": "acute tonsillitis", "extracted_span": "acute tonsillitis", "entity_name": "tonsillitis", "extracted_span": "tonsillitis", "entity_name": "streptococcus pyogenes infection", "extracted_span": "Streptococcus pyogenes", "entity_name": "acute infective pharyngitis caused by Streptococcus", "extracted_span": "acute pharyngitis caused by Streptococcus pyogenes",,→ "entity_name": "acute pharyngitis", "extracted_span": "acute pharyngitis", "entity_name": "pharyngitis", "extracted_span": "pharyngitis" ] </identified_medical_entities> </example_2> <example_3> Input: <example_input> "Adequate liver function defined as serum bilirubin <1.5x upper level of normal (ULN), aspartate aminotransferase (AST) <2.5x ULN, and alanine aminotransferase (ALT) <3x ULN, with ULN defined as per institutional standard." ,→ ,→ </example_input> Identified Entities: <identified_medical_entities> [ "entity_name": "liver normal", "extracted_span": "Adequate liver function", "entity_name": "Serum bilirubin level", "extracted_span": "serum bilirubin", "entity_name": "bilirubin", "extracted_span": "bilirubin", "entity_name": "AST - aspartate transaminase", "extracted_span": "aspartate aminotransferase (AST)", "entity_name": "ALT - alanine aminotransferase", "extracted_span": "alanine aminotransferase (ALT)" ] </identified_medical_entities> </example_3> <example_4> Input: <example_input> "Patients with standard analytical parameters defined by: leukocyte count âĽě 3000 cells/ÎL, neutrophil count âĽě 1500 cells/ÎL, platelet count âĽě 100,000 cells/ÎL, aspartate aminotransferase (AST) level âĽď 1.5 times the standard institutional range, alanine aminotransferase (ALT) level âĽď 1.5 times the standard institutional range, and creatinine level âĽď 1.5 mg/dL." ,→ ,→ ,→ </example_input> Identified Entities: <identified_medical_entities> [ "entity_name": "standard analytical parameters", "extracted_span": "standard analytical parameters", "entity_name": "white blood cell count", "extracted_span": "leukocyte count", "entity_name": "Leukocyte component of blood", "extracted_span": "leukocyte", "entity_name": "neutrophil count", "extracted_span": "neutrophil count", "entity_name": "platelet count", "extracted_span": "platelet count", "entity_name": "Platelet component of blood", "extracted_span": "platelet", "entity_name": "AST - aspartate transaminase", "extracted_span": "aspartate aminotransferase (AST)", "entity_name": "ALT - alanine aminotransferase", "extracted_span": "alanine aminotransferase (ALT)", "entity_name": "creatinine level", "extracted_span": "creatinine level", "entity_name": "creatinine", "extracted_span": "creatinine" ] </identified_medical_entities> </example_4> <example_5> Input: <example_input> "The results of the patient's pap smear showed positive human papillomavirus results (indicating the presence of human papillomavirus DNA in the cervical sample).",→ </example_input> Identified Entities: <identified_medical_entities> [ "entity_name": "pap smear", "extracted_span": "pap smear", "entity_name": "High risk human papillomavirus positive", "extracted_span": "positive human papillomavirus results",,→ "entity_name": "Human papillomavirus DNA", "extracted_span": "human papillomavirus DNA", "entity_name": "Human papillomavirus", "extracted_span": "human papillomavirus", ] </identified_medical_entities> </example_5> 198 Preprint. Under review. <example_6> Input: <example_input> "Male patients OR female patients." </example_input> Identified Entities (none!): <identified_medical_entities> [] </identified_medical_entities> </example_6> <example_7> Input: <example_input> "Clinical diagnosis of at least one risk factor, such as clinical diagnosis of diabetes, clinical diagnosis of smoking habit, clinical diagnosis of lipid metabolism abnormality, clinical diagnosis of history of ischemic heart disease (IHD), clinical diagnosis of history of cerebrovascular disease, clinical diagnosis of obesity with body mass index (BMI) > 25, clinical diagnosis of chronic heart failure classified as New York Heart Association (NYHA) class I or NYHA class I, or clinical diagnosis of electrocardiogram (ECG) abnormality showing left ventricular hypertrophy (LVH)." ,→ ,→ ,→ ,→ ,→ </example_input> Identified Entities (none!): <identified_medical_entities> [ "entity_name": "risk factor", "extracted_span": "risk factor", "entity_name": "diabetes", "extracted_span": "diabetes", "entity_name": "risk factor", "extracted_span": "risk factor", "entity_name": "smoking", "extracted_span": "smoking habit", "entity_name": "lipid metabolism disorder", "extracted_span": "lipid metabolism abnormality", "entity_name": "ischemic heart disease", "extracted_span": "ischemic heart disease (IHD)", "entity_name": "cerebrovascular disease", "extracted_span": "cerebrovascular disease", "entity_name": "obesity", "extracted_span": "obesity", "entity_name": "BMI - Body mass index", "extracted_span": "BMI", "entity_name": "chronic heart failure", "extracted_span": "chronic heart failure", "entity_name": "ECG abnormality showing left ventricular hypertrophy", "extracted_span": "ECG abnormality showing left ventricular hypertrophy",,→ "entity_name": "abnormal ECG", "extracted_span": "ECG abnormality", "entity_name": "left ventricular hypertrophy", "extracted_span": "left ventricular hypertrophy (LVH)", ] </identified_medical_entities> </example_7> <example_8> Input: <example_input> "Adults aged âĽě18 years weighing âĽď150 kg." </example_input> Identified Entities (none!): <identified_medical_entities> [] </identified_medical_entities> </example_8> <example_9> Input: <example_input> "The patient has positive urine protein." <example_input> Identified Entities (none!): <identified_medical_entities> [ "entity_name": "urine", "extracted_span": "urine", "entity_name": "protein", "extracted_span": "protein", "entity_name": "positive urine protein", "extracted_span": "positive urine protein", "entity_name": "urine protein", "extracted_span": "urine protein", ] </identified_medical_entities> </example_9> # === OUTPUT FORMAT === <identified_medical_entities> [ "entity_name": <entity_name1>, extracted_span: <exact_span1>, "entity_name": <entity_name2>, extracted_span: <exact_span2>, "entity_name": <entity_name3>, extracted_span: <exact_span3>, 199 Preprint. Under review. ] </identified_medical_entities> F.2.7 Entity Canonicalization: Medical Concept Reranker Purpose.This prompt picks one best SNOMED concept for each extracted medical entity mention. It uses the surrounding criterion text and candidate list to choose either an exact match or, if that is not available, the most specific broader concept, while keeping every input entity in the output even when no suitable concept can be linked. # === ROLE === You are a SNOMED concept linker. For EACH extracted span choose EXACTLY ONE best matching candidate, depending on its usage in criterion's context and identified entity name.,→ # === INPUT === <criterion> #CRITERION# </criterion> <candidates> #CANDIDATES# </candidates> # === GUIDELINES === 1. Do not drop any input entry! 2. Make sure the output json and the input candidates list have same amount entities. Even the entity's candidate list is empty, still keep the entity in the output json.,→ 3. Among all the candidates for the entity, 3.a Prioritize EXACT semantic match. Select the SNOMED CT concept identical in meaning to the input disease. Mark select_reason = "Exact".,→ 3.b If no exact match exists, choose the most specific valid ancestor of the entity. By "ancestor," we mean a concept that is a more general and broader verision of the entity. Mark select_reason = "Ancestor".,→ 3.c If no candidate satisfies 3.a or 3.b, do not drop the input entity, still include that entity and set `"concept": null`.,→ 4. The output JSON array must contain **exactly one element for every entity present in the <candidates> list** (counts must match 1-for-1).,→ - If an entityâĂŹs candidate list is empty or no candidate fits, still include that entity and set`"concept": null`.,→ 5. You MUST copy the "offset" array you receive. Do **NOT** change the numbers. # === OUTPUT === JSON array: [ "entity_1": "extracted_span": "...", "entity_name": "...", "offset": [26, 33], "concept": "conceptId": "123456", "preferred_term": "...", "fully_specified_name": "...", "top_type": "Clinical finding", "select_reason": "Exact" or "Ancestor" , ... ] F.2.8 Entity Canonicalization: Semantic Equivalence Verifier Purpose. This prompt checks whether a proposed SNOMED concept is acceptable for a given extracted entity mention. It keeps a candidate only if it means the same thing as the extracted span in context or is a broader concept that still correctly covers it, and it records that judgment in a structured output. # === ROLE === You are a SNOMED link auditor. # === RULE === Return "KEEP" iff the conceptâĂŹs meaning is identical or ancestor(broader) to the extracted span within the criterion context. Otherwise "REJECT".,→ 200 Preprint. Under review. # === GUIDELINES === 1. Use the provided synonyms/definition only as background; do NOT echo them in the answer. 2. Note that we are linking to SNOMED nomenclature, so if a candidate means the same thing as the extracted span or is ancestor(broader) to the extracted span in the SNOMED context, we should keep the candidate. Only when "candidate_is_identical_to_entity" is "YES" or "candidate_is_broader_to_entity" is YES should you make the "KEEP" decision. ,→ ,→ ,→ 3. You should compare the meaning of the candidate to the extracted span or entity name, and you should disregard anything that accompanies the corresponding extracted span in the criterion. As long as the candidate means what the extracted span or entity name means in the criterion or is broader than what the extracted span or entity name means in the criterion, keep it. ,→ ,→ ,→ 4. Every match is LOCAL! No candidate should attend to extracted spans that do not correspond to it. 5. Do not consider if there are more specific terms for a extracted span. Just focus on if the extracted span and the retrieved candidate match(identical or candidate is broader) or not.,→ 6. COPY the "offset" array from the input pair unchanged; do NOT invent or drop it. # === INPUT === <criterion> #CRITERION# </criterion> <pairs> #PAIRS# </pairs> # Each object has: extracted_span, conceptId, preferred_term, # top_type, synonyms[], definition # === OUTPUT === JSON array: [ "extracted_span": "...", "entity_name": "...", "offset": [26, 33], "candidate_is_identical_to_entity": "YES | NO", "candidate_is_broader_to_entity": "YES | NO", "decision": "KEEP|REJECT", "preferred_term": "...", "synonyms": [ "...", "..." ], "definition": "...", "why": "" , ... ] F.2.9 Entity Canonicalization: Final Canonicalization Arbiter Purpose.This prompt is the final filter for entity canonicalization. It decides whether each extracted span and linked concept is precise enough, medically appropriate, and usable in your naming scheme for later formal encoding. It checks that the span really appears in the criterion, maps to an allowed medical concept type, is not just demographic or consent language, does not rely on class or stage labels, matches the linked concept in meaning, can be turned into a valid standardized variable name, and is the most specific valid choice among overlapping candidates. Only entries that pass all checks are kept. # === ROLE === You are a extracted span and entity name checker and variable-name generator. # === TASK === For each candidate object 1. Apply Rules 1-6: HAS_STRING_APPERANCE_IN_CRITERION_TEXT, BELONG_TO_ALLOWED_TYPES, IS_NOT_AGE_SEX_PREGNANCY_CONSENT_PERSONAL_RULE, CONTAINS_NO_CLASS_OR_STAGE_WORDS, EXTRACTED_SPAN_PREFERRED_TERM_SAME_THING, and IS_THE_MOST_SPECIFIC_MAPPED_TO_PHRASE_AMONG_ALL_OVERLAPPED_ENTRIES. ,→ ,→ ,→ 2. Attempt to build a variable_name according to NAMING CONVENTIONS and correspond to the entry's usage in criterion text (<criterion>). Build a variable_name that uses the preferred_term verbatim and,→ follows NAMING CONVENTIOS. If that succeeds, Rule 7 (CAN_BE_EXPRESSED_WITH_CORRESPONDING_NAMING_CONVENTIONS) = "YES"; else "NO". 3. keep = "YES" only if Rules 1-7 are all "YES". # === RULES === 1. HAS_STRING_APPERANCE_IN_CRITERION_TEXT: The extracted span or entity name appears in criterion text. 2. BELONG_TO_ALLOWED_TYPES: The mapped-to preferred term belong to one of the allowed top types: Clinical finding / Finding, Procedure, Observable entity, Substance, Product.,→ 3. IS_NOT_AGE_SEX_PREGNANCY_CONSENT_PERSONAL_RULE: Reject age / sex / pregnancy / consent / person-role terms. - Entities that does not directly related to sex or pregnancy (e.g. "menstrual cycles", "regular periods", "menopause") keep = yes,→ 4. CONTAINS_NO_CLASS_OR_STAGE_WORDS: If string contains class/stage words (NYHA, ECOG, GOLD, CCS, Child-Pugh, etc.) keep = NO unless the qualifier ALONE is required. 201 Preprint. Under review. 5. EXTRACTED_SPAN_PREFERRED_TERM_SAME_THING: The extracted span or entity name and the matched preferred term of this entry mean EXACTLY the same thing: no information added; no information lost.,→ 6. CAN_BE_EXPRESSED_WITH_CORRESPONDING_NAMING_CONVENTIONS âĂŞ we can express how the entry is being used in <criterion> (the criterion text) using our naming conventions (see NAMING CONVENTIONS section below); make sure to use the naming convention of the corresponding entity type! For example, findings should use the naming conventions of clinical findings. ,→ ,→ ,→ 7. IS_THE_MOST_SPECIFIC_MAPPED_TO_PHRASE_AMONG_ALL_VALID_OVERLAPPED_ENTRIES: Among all entries overlapping with this entry's extracted span whose preferred terms mean the same thing as their extracted spans, this extracted span and mapped preferred term are the most specific (COMPARE WITH OTHER ENTRIES THAT HAVE OVERLAPPING OFFSETS!). ,→ ,→ ,→ 7. IS_THE_MOST_SPECIFIC_MAPPED_TO_PHRASE_AMONG_ALL_OVERLAPPED_ENTRIES: First list ONLY the extracted spans that (a) overlap AND (b) are all-YES on rules 1-6 above in "ALL_VALID_OVERLAPPED_EXTRACTED_SPANS". Among all entries overlapping with this entry's extracted span and are valid, this extracted span and mapped preferred term are the most specific (COMPARE WITH OTHER ENTRIES THAT HAVE OVERLAPPING OFFSETS AND ARE VALID!). ,→ ,→ ,→ # === ADDITIONAL GUIDELINES === COPY the "offset" array from the input object unchanged; do NOT invent or drop it. # === NAMING CONVENTIONS === Stems (lowercase snake_case; strip punctuation; numerals normalized). The timeframe token MUST appear exactly once inside the stem and match the "timeframe" field.,→ <stems_templates> Finding: <stems_templates::findings> patient_has_diagnosis_of_entity_canonical_form_timeframe | patient_has_finding_of_entity_canonical_form_timeframe | patient_has_symptoms_of_entity_canonical_form_timeframe | patient_has_clinical_signs_of_entity_canonical_form_timeframe | patient_has_suspicion_of_entity_canonical_form_timeframe </stems_templates::findings> Procedure: <stems_templates::procedures> patient_has_undergone_entity_canonical_form_timeframe | patient_has_undergone_entity_canonical_form_timeframe_outcome_is_positive | patient_has_undergone_entity_canonical_form_timeframe_outcome_is_negative | patient_has_undergone_entity_canonical_form_timeframe_outcome_is_normal | patient_has_undergone_entity_canonical_form_timeframe_outcome_is_abnormal | patient_is_undergoing_entity_canonical_form_timeframe | patient_will_undergo_entity_canonical_form_timeframe | patient_can_undergo_entity_canonical_form_timeframe | </stems_templates::procedures> Observable Entities (numeric): <stems_templates::observable_entities_numeric> patient_entity_canonical_form_value_recorded_timeframe_withunit_unit </stems_templates::observable_entities_numeric> Observable Entities (status / categorical): <stems_templates::observable_entities_status> patients_entity_canonical_form_is_positive_timeframe | patients_entity_canonical_form_is_negative_timeframe | patients_entity_canonical_form_is_normal_timeframe | patients_entity_canonical_form_is_abnormal_timeframe | </stems_templates::observable_entities_status> Product: <stems_templates::product> patient_is_taking_entity_canonical_form_timeframe | patient_has_taken_entity_canonical_form_timeframe | patient_has_hypersensitivity_to_entity_canonical_form_timeframe | patient_has_intolerance_to_entity_canonical_form_timeframe | patient_has_allergy_to_entity_canonical_form_timeframe | patient_has_nonimmune_hypersensitivity_to_entity_canonical_form_timeframe | </stems_templates::product> Substance: <stems_templates::substance> patient_is_exposed_to_entity_canonical_form_timeframe | patient_has_hypersensitivity_to_entity_canonical_form_timeframe | patient_has_intolerance_to_entity_canonical_form_timeframe | patient_has_allergy_to_entity_canonical_form_timeframe | patient_has_nonimmune_hypersensitivity_to_entity_canonical_form_timeframe | </stems_templates::substance> </stems_templates> <timeframe> Timeframe : now | inthehistory | inthefuture | inthepastnunits | inthefuturenunits | foradurationofnunits,→ 202 Preprint. Under review. Time Units: minutes | hours | days | weeks | months | years </timeframe> <qualifiers> Attach with: stem@@qualifier_snake_case Qualifiers must NOT repeat timeframe/value/unit; they encode leftover semantics (e.g., temporal anchors other than "todayâĂİ, context like "at baselineâĂİ, or dependencies like "after percutaneous coronary interventionâĂİ). Use qualifiers sparingly and ONLY when needed for later assertions. ,→ ,→ </qualifiers> # === INPUT === <criterion> #CRITERION# </criterion> <candidate_objects> #STRINGS# </candidate_objects> # Each object has: extracted_span, preferred_term, type, offset (pair of integers) # === OUTPUT === Return ONLY a JSON array: [ "extracted_span": "...", "entity_name": "...", "offset": [..., ...], "preferred_term": "...", "HAS_STRING_APPERANCE_IN_CRITERION_TEXT": "YES" | "NO", "BELONG_TO_ALLOWED_TYPES": "YES" | "NO", "IS_NOT_AGE_SEX_PREGNANCY_CONSENT_PERSONAL_RULE": "YES" | "NO", "CONTAINS_NO_CLASS_OR_STAGE_WORDS": "YES" | "NO", "EXTRACTED_SPAN_PREFERRED_TERM_SAME_THING": "YES" | "NO", "variable_name": "patientHasFindingHeartFailureHistory", "CAN_BE_EXPRESSED_WITH_CORRESPONDING_NAMING_CONVENTIONS": "YES" | "NO", "ALL_VALID_OVERLAPPED_EXTRACTED_SPANS": [/* list ONLY the extracted spans that (a) overlap AND (b) are all-YES on rules above */],,→ "IS_THE_MOST_SPECIFIC_MAPPED_TO_PHRASE_AMONG_ALL_VALID_OVERLAPPED_ENTRIES": "YES" | "NO", "keep": "YES" | "NO", "why": "...explain..." , ... ] F.2.10 Entity Canonicalization: Diagnosis Concept Reranker Purpose. This prompt links each diagnosis string to the single best matching SNOMED concept from a provided candidate list. It uses the meaning of the diagnosis as written in the note, keeps only one choice per diagnosis, and returns null when none of the candidates correctly represent that diagnosis. # === ROLE === You are a SNOMED concept linker for DIAGNOSIS STRINGS. # === TASK === For EACH diagnosis, choose ONE best SNOMED concept from its candidate list. If NO candidate correctly represents the diagnosis (as meant in this note), set "choice": null. # === INPUT === <diagnoses_with_candidates> DIAG_BLOCK </diagnoses_with_candidates> # === OUTPUT (JSON array) === [ "diagnosis": "<original diagnosis string>", "choice": "conceptId": "<SNOMED ID>", "preferred_term": "<PT>", "fully_specified_name": "<FSN>", "type": "<top semantic type>" // or null ] 203 Preprint. Under review. F.2.11 Entity Canonicalization: Diagnosis Concept Semantic Equivalence Verifier Purpose. This prompt checks whether a chosen SNOMED concept is a good match for a diagnosis string from the patient note. It determines whether the concept means the same thing as the diagnosis, whether it is a broader parent concept, and whether the two are at least medically related, then returns those judgments with a short explanation. # === ROLE === You are a SNOMED link auditor for DIAGNOSIS STRINGS. # === GUIDELINES === 1. Set "SNOMED_CONCEPT_AND_DIAGNOSIS_SEMANTICALLY_EQUIVALENT" to true if the chosen conceptâĂŹs meaning is semantically equivalent to the diagnosis,→ as intended in the patient note context. Otherwise set it to false. 2. Set "SNOMED_CONCEPT_IS_ANCESTOR_OF_DIAGNOSIS" to true if the chosen snomed concept is an ancestor of the diagnosis. Otherwise set it to false.,→ 3. Set "SNOMED_CONCEPT_AND_DIAGNOSIS_ARE_RELATED" to true if the snomed concept and the diagnosis are related. Otherwise set it to false.,→ # === PAIR === PAIR # === OUTPUT (JSON object) === "SNOMED_CONCEPT_AND_DIAGNOSIS_SEMANTICALLY_EQUIVALENT": true | false, "SNOMED_CONCEPT_IS_ANCESTOR_OF_DIAGNOSIS": true | false, "SNOMED_CONCEPT_AND_DIAGNOSIS_ARE_RELATED": true | false, "why": "... explanations ..." F.2.12 SMT Programming: Demographic Variable Constructor Purpose.This prompt identifies demographic variables in a patient fact and converts them into a small set of standardized SMT-ready variables. It only handles age, sex, pregnancy- related status, and ability to be pregnant, and it outputs conservative, template-based vari- able declarations with values and time windows, without writing any assertions. === ROLE === You are an expert SMT engineer and doctor. Your task is to declare DEMOGRAPHIC variables needed to encode patient facts (i.e., a patient fact note requirement) into an existing SMT-LIB program. You DO NOT write assertions here âĂŤ only output new canonical demographic variables (stems + values). ,→ ,→ === INPUT DESCRIPTIONS === You will be given the following inputs: 1. <patient_fact>: This is the source patient fact you should be doing variable codings for. === INPUTS === <patient_fact> #PATIENT_FACT# </patient_fact> === NAMING SYSTEM / NAMING TEMPLATES === Stems (lowercase snake_case; strip punctuation; numerals normalized). <stems_templates> patient_age_value_recorded_in_years | patient_age_value_recorded_in_months | patient_age_value_recorded_in_days | patient_sex_is_sex | patient_is_pregnant | patient_is_able_to_be_pregnant | patient_has_childbearing_potential | patient_is_breastfeeding | patient_is_lactating | patient_is_postmenopausal | patient_is_in_transition_to_menopausal | patient_is_infertile | patient_is_inpatient | patient_is_outpatient | patient_has_been_inpatient | patient_has_been_outpatient | patient_has_been_inpatient | patient_is_child | patient_is_adolescent | patient_is_adult | patient_is_middle_aged | 204 Preprint. Under review. patient_is_older_adult | patient_is_neonate | patient_is_toddler | patient_is_preschooler | patient_is_school_aged | patient_is_premenopausal | patient_is_perimenopausal | patient_is_postpartum | patient_is_postabortion | patient_is_emergency_department_patient | patient_is_long_term_care_resident | patient_is_nursing_home_resident | patient_is_assisted_living_resident </stems_templates> <sex> Choose from male / female / other. </sex> Time Units: minutes | hours | days | weeks | months | years === GUIDELINES === 1. ONLY define variables that strictly follow the above templates. 2. Style: lowercase snake_case; numerals normalized; no temporal information. 3. Variable names must exactly match their meanings (no overloading). 4. ONLY define variables if their usage in <current_requirement> maps EXACTLY to a templateâĂŹs semantic meaning (be conservative).,→ 5. Fill sex in the stem when applicable. 6. NEVER declare anything outside age, sex, pregnancy status, or ability to be pregnant. 7. NEVER redeclare anything listed in <reusable_variables>; omit those from new declarations. 8. For every canonicalized entity, put down two temporal fields describing the time span of an event or patient state: (1) "timewindow_this_patient_fact_certainly_holds": timewindow during which we can certainly assert that this patient fact holds; (2) "largest_timewindow_this_patient_fact_may_hold": the largest time window wherein the finding may exist; ,→ ,→ ,→ 9. Rules apply to both temporal fields: 9.1. Consistency between "now" and zero magnitude: if temporal_direction is "now", set temporal_magnitude to 0.0; if temporal_magnitude is 0.0, set temporal_direction to "now".,→ 9.2. Default temporal units: if you are uncertain about temporal units, set to "hours". 9.3. Decide whether timepoints are inclusive independently and based on contextual cues. 9.4. Temporal ordering: for both timeframe pairs, ensure that the start_time is not later than the end_time. 9.5. Make sure the timewindow_this_patient_fact_certainly_holds is a subset of largest_timewindow_this_patient_fact_may_hold.,→ 10. Timewindow special cases: 10.1. timewindow_this_patient_fact_certainly_holds is always [0.0, 0.0] unless explicitly contradicted. 10.2. largest_timewindow_this_patient_fact_may_hold for age/pregnancy entity is [-1 years, +1 years]. === OUTPUT FORMAT === Emit EXACTLY one block: <new_age_sex_pregnancystatus_declarations>. If there are no new variables to declare, emit an empty JSON array in the block. <new_age_sex_pregnancystatus_declarations> [ "span": "<trigger span or canonical string if available>", "template": "<findings|procedures|observable_entities_numeric|observable_entities_status|product|substance>", "entity_variable_name": "<stem>", "type": "<Bool | Int | Real>", "extracted_value": "<extracted value for the variable from the patient fact>", "usage": "<How this variable creates a stable, indexable marker of the patient note that IR can retrieve.>", "timewindow_this_patient_fact_certainly_holds": "start_time": "temporal_direction": "past | now | future", "temporal_magnitude": <value: Real | "Inf">, "units": "<temporal_unit_in_plural>", "inclusive": true | false, "end_time": "temporal_direction": "past | now | future", "temporal_magnitude": <value: Real | "Inf">, "units": "<temporal_unit_in_plural>", "inclusive": true | false, , "largest_timewindow_this_patient_fact_may_hold": "start_time": "temporal_direction": "past | now | future", "temporal_magnitude": <value: Real | "Inf">, "units": "<temporal_unit_in_plural>", "inclusive": true | false, "end_time": "temporal_direction": "past | now | future", 205 Preprint. Under review. "temporal_magnitude": <value: Real | "Inf">, "units": "<temporal_unit_in_plural>", "inclusive": true | false, , ] </new_age_sex_pregnancystatus_declarations> === EXAMPLE OUTPUT === <example1> <example_patient_note1> "The patient is a 58-year-old African-American woman." <example_patient_note1/> <example_output_list1> [ "span": "The patient is a 58-year-old African-American woman.", "template": "observable_entities_numeric", "entity_variable_name": "patient_age_value_recorded_in_years", "type": "Int", "extracted_value": 58, "usage": "Encodes the patient's age in years as a stable, indexable marker for retrieval and analysis.", "timewindow_this_patient_fact_certainly_holds": "start_time": "temporal_direction": "now", "temporal_magnitude": 0.0, "units": "hours", "inclusive": true, "end_time": "temporal_direction": "now", "temporal_magnitude": 0.0, "units": "hours", "inclusive": true, , "largest_timewindow_this_patient_fact_may_hold": "start_time": "temporal_direction": "past", "temporal_magnitude": 1.0, "units": "years", "inclusive": true, "end_time": "temporal_direction": "future", "temporal_magnitude": 1.0, "units": "hours", "inclusive": true, , "span": "The patient is a 58-year-old African-American woman.", "template": "observable_entities_status", "entity_variable_name": "patient_sex_is_female", "type": "Bool", "extracted_value": true, "usage": "Encodes the patient's sex as female for retrieval and analysis.", "timewindow_this_patient_fact_certainly_holds": "start_time": "temporal_direction": "now", "temporal_magnitude": 0.0, "units": "hours", "inclusive": true, "end_time": "temporal_direction": "now", "temporal_magnitude": 0.0, "units": "hours", "inclusive": true, , "largest_timewindow_this_patient_fact_may_hold": "start_time": "temporal_direction": "past", "temporal_magnitude": "Inf", "units": "hours", "inclusive": true, "end_time": "temporal_direction": "now", "temporal_magnitude": 0.0, "units": "hours", "inclusive": true, ] <example_output_list1/> 206 Preprint. Under review. <example1/> F.2.13 SMT Programming: Canonical Variable Constructor Purpose. This prompt converts canonicalized medical entities in a patient fact into stan- dardized SMT variable declarations. It creates Boolean or numeric variables only for entities that already have approved canonical forms, uses the exact canonical strings provided, extracts the corresponding values, and attaches time-window information and any needed qualifiers so the fact can later be encoded and retrieved in a consistent way. === ROLE === You are an expert SMT engineer and doctor. Your task is to declare variables (Boolean and numeric) and qualifier variables needed to encode patient facts from a patient note.,→ === INPUT DESCRIPTIONS=== You will be given the following inputs: 1. <patient_fact>: This is the source patient fact you should be doing variable codings for. 2. <canonical_forms>: A JSON list of entities from <current_requirement> for which canonical forms were found. 2.1 Use "span" to identify the surface substring in <current_requirement>. 2.2 Use "entity_canonical_form" (exact string) to plug into entity_canonical_form in stems. 2.3 DO NOT use preferred terms anywhere. DO NOT invent or alter canonical forms. 2.4 Use "type" to guide which template(s) to use. 2.5 If multiple identical spans occur, consult "start" and "end" character offsets. 2.6 You can refer to "select_reason" to see the relationship between the entity_canonical_form and the === INPUTS === <patient_fact> #PATIENT_FACT# </patient_fact> <canonical_forms> #CANONICAL_FORMS# </canonical_forms> === NAMING SYSTEM / NAMING TEMPLATES === Stems (lowercase snake_case; strip punctuation; numerals normalized). <stems_templates> Clinical Finding: <stems_templates::findings> patient_has_diagnosis_of_entity_canonical_form | patient_has_finding_of_entity_canonical_form | patient_has_symptoms_of_entity_canonical_form | patient_has_clinical_signs_of_entity_canonical_form | patient_has_suspicion_of_entity_canonical_form </stems_templates::findings> Procedure: <stems_templates::procedures> patient_has_undergone_entity_canonical_form | patient_has_undergone_entity_canonical_form_outcome_is_positive | patient_has_undergone_entity_canonical_form_outcome_is_negative | patient_has_undergone_entity_canonical_form_outcome_is_normal | patient_has_undergone_entity_canonical_form_outcome_is_abnormal | patient_is_undergoing_entity_canonical_form | patient_needs_to_undergo_entity_canonical_form_timeframe | patient_will_undergo_entity_canonical_form | patient_can_undergo_entity_canonical_form | </stems_templates::procedures> Observable Entities (numeric): <stems_templates::observable_entities_numeric> patient_entity_canonical_form_value_recorded_withunit_unit </stems_templates::observable_entities_numeric> Observable Entities (status / categorical): <stems_templates::observable_entities_status> patients_entity_canonical_form_is_positive | patients_entity_canonical_form_is_negative | patients_entity_canonical_form_is_normal | patients_entity_canonical_form_is_abnormal | </stems_templates::observable_entities_status> Product: <stems_templates::product> patient_is_taking_entity_canonical_form | patient_has_taken_entity_canonical_form | patient_has_hypersensitivity_to_entity_canonical_form | 207 Preprint. Under review. patient_has_intolerance_to_entity_canonical_form | patient_has_allergy_to_entity_canonical_form | patient_has_nonimmune_hypersensitivity_to_entity_canonical_form | </stems_templates::product> Substance: <stems_templates::substance> patient_is_exposed_to_entity_canonical_form | patient_has_hypersensitivity_to_entity_canonical_form | patient_has_intolerance_to_entity_canonical_form | patient_has_allergy_to_entity_canonical_form | patient_has_nonimmune_hypersensitivity_to_entity_canonical_form | </stems_templates::substance> </stems_templates> Temporal Units: minutes | hours | days | weeks | months | years <qualifiers> Attach with: stem@@qualifier_snake_case Qualifiers must NOT repeat value/unit; they encode leftover semantics (e.g., temporal anchors other than "today", context like "at baseline", or dependencies like "after percutaneous coronary intervention"). Use qualifiers sparingly and ONLY when needed for later assertions. ,→ ,→ </qualifiers> === GUIDELINES === 1) SCOPE & GATING: ONLY entities present in <canonical_forms> may appear in <new_canonical_variable_declarations>. If <canonical_forms> is empty, output an empty array.,→ 1.1) Canonical-only: You must use entity_canonical_form (exact string) wherever a canonical string is needed. Never use preferred terms.,→ 2) MATCH THE FACT: Declare variables only for meanings that match <current_requirement> exactly (be conservative). The original note is context only.,→ 3) STYLE: lowercase snake_case; numerals normalized; no temporal information; 4) For every canonicalized entity, put down two temporal fields describing the time span of an event or patient state: (1) "timewindow_this_patient_fact_certainly_holds": timewindow during which we can certainly assert that this patient fact holds; (2) "largest_timewindow_this_patient_fact_may_hold": the largest time window wherein the finding may exist; ,→ ,→ ,→ 5) Rules apply to both temporal fields: 5.1) Consistency between "now" and zero magnitude: if temporal_direction is "now", set temporal_magnitude to 0.0; if temporal_magnitude is 0.0, set temporal_direction to "now".,→ 5.2) Default temporal units: if you are uncertain about temporal units, set to "hours". 5.3) Decide whether timepoints are inclusive independently and based on contextual cues. 5.4) Temporal ordering: for both timeframe pairs, ensure that the start_time is not later than the end_time. 5.5) Make sure the timewindow_this_patient_fact_certainly_holds is a subset of largest_timewindow_this_patient_fact_may_hold.,→ 5.6) Both timewindows cannot be in future, unless explicitly stated in the patient notes. 6) NUMERIC-FIRST: When the requirement expresses a quantity (threshold/range/value), declare numeric stems (e.g., entity_value_recorded_withunit_unit). Threshold/range logic is asserted later, not here.,→ 7) QUALIFIERS: Only encode semantics not already captured by the stem template; never encode numeric thresholds or the whole comparator clause as a qualifier. If there is a relative window anchored to an event, represent it as a qualifier (e.g., temporalcontext_within6months_after_percutaneous_coronary_intervention). Do not include qualifier in "entity_variable_name" field. ,→ ,→ ,→ 8) TYPES: Choose "Bool" for findings/procedures/status/category flags; "Int" or "Real" for numeric quantities as appropriate. Note that you should be using input concept type as the only source of truth when choosing the concept type and should never infer types based on the concept name yourself. For example, if the input type in <canonical_forms> is "Clinical finding", you may only use templates listed under clinical finding ,→ ,→ ,→ === OUTPUT FORMAT === Emit EXACTLY one block: <new_canonical_variable_declarations>. If there are no new variables, emit an empty JSON array in the block.,→ <new_canonical_variable_declarations> [ "span": "<copy from canonical_forms>", "entity_canonical_form_used": "<exact string from canonical_forms>", "template": "<findings|procedures|observable_entities_numeric|observable_entities_status|product|substance>", "entity_variable_name": "<stem>", "type": "<Bool | Int | Real>", "extracted_value": "<extracted value for the variable from the patient fact>", "usage": "<<How this variable creates a stable, indexable marker of the patient note that IR can retrieve.>", "qualifier_predicates": ["<stem@@qualifier>", ...]ïŇ "timewindow_this_patient_fact_certainly_holds": "start_time": "temporal_direction": "past | now | future", "temporal_magnitude": <value: Real | "Inf">, "units": "<temporal_unit_in_plural>", "inclusive": true | false, "end_time": "temporal_direction": "past | now | future", 208 Preprint. Under review. "temporal_magnitude": <value: Real | "Inf">, "units": "<temporal_unit_in_plural>", "inclusive": true | false, , "largest_timewindow_this_patient_fact_may_hold": "start_time": "temporal_direction": "past | now | future", "temporal_magnitude": <value: Real | "Inf">, "units": "<temporal_unit_in_plural>", "inclusive": true | false, "end_time": "temporal_direction": "past | now | future", "temporal_magnitude": <value: Real | "Inf">, "units": "<temporal_unit_in_plural>", "inclusive": true | false, ] </new_canonical_variable_declarations> === EXAMPLE OUTPUT === <example1> <example_patient_fact1> "The patient denies a family history of ischemic heart disease." <example_patient_fact1/> <example_output_list1> [ "span": "ischemic heart disease", "entity_canonical_form_used": "ischemic_heart_disease", "template": "findings", "entity_variable_name": "patient_has_diagnosis_of_ischemic_heart_disease", "type": "Bool", "extracted_value": false, "usage": "This variable encodes the patient's denial of a family history of ischemic heart disease, providing a stable marker for retrieval and reasoning about the absence of this clinical finding.",,→ "qualifier_predicates": [], "timewindow_this_patient_fact_certainly_holds": "start_time": "temporal_direction": "now", "temporal_magnitude": 0.0, "units": "hours", "inclusive": true , "end_time": "temporal_direction": "now", "temporal_magnitude": 0.0, "units": "hours", "inclusive": true , "largest_timewindow_this_patient_fact_may_hold": "start_time": "temporal_direction": "past", "temporal_magnitude": "Inf", "units": "hours", "inclusive": true , "end_time": "temporal_direction": "now", "temporal_magnitude": 0.0, "units": "hours", "inclusive": true ] <example_output_list1/> <example1/> <example2> <example_patient_fact2> "The patient denies a family history of smoking." <example_patient_fact2/> <example_output_list2> [ 209 Preprint. Under review. "span": "smoking", "entity_canonical_form_used": "tobacco_smoking_behavior_finding", "template": "findings", "entity_variable_name": "patient_has_finding_of_tobacco_smoking_behavior_finding", "type": "Bool", "extracted_value": null, "usage": "This variable encodes the patient's history of heavy smoking as a clinical finding, providing a stable marker for retrieval and indexing in IR systems.",,→ "qualifier_predicates": [], "timewindow_this_patient_fact_certainly_holds": "start_time": "temporal_direction": "now", "temporal_magnitude": "0.0", "units": "hours", "inclusive": true , "end_time": "temporal_direction": "now", "temporal_magnitude": 0.0, "units": "hours", "inclusive": true , "largest_timewindow_this_patient_fact_may_hold": "start_time": "temporal_direction": "past", "temporal_magnitude": "Inf", "units": "hours", "inclusive": true , "end_time": "temporal_direction": "now", "temporal_magnitude": 0.0, "units": "hours", "inclusive": true ] <example_output_list2/> <example2/> F.2.14 SMT Programming: Diagnosis Clinical Strength Classifier Purpose. This prompt reviews a full patient note and judges whether each possible di- agnosis is strong and clear enough to safely use as an exclusion condition for clinical trial matching. It is designed to be conservative: a diagnosis is marked usable for exclusion only when the note clearly supports that the patient truly has that condition in a clinically meaningful way, and not when the diagnosis is uncertain, negated, historical, or weakly supported. # === ROLE === You are an experienced clinician. You are reviewing a full patient note and deciding, for each possible diagnosis, whether it is strong enough and specific enough to be treated as a trial-excluding diagnosis.,→ # === PATIENT NOTE === #PATIENT_NOTE# # === POSSIBLE DIAGNOSES === <possible_diagnosis_list> #POSSIBLE_DIAGNOSES# </possible_diagnosis_list> # === TASK === You are given a shortlist of possible diagnoses (a differential diagnosis) that have been derived from the patient note.,→ For EACH diagnosis in the list: - Carefully read the patient note. - Decide whether this diagnosis can safely be used as a basis for EXCLUDING the patient from a clinical trial. - Concretely: if a trial has an exclusion criterion that excludes patients with this specific diagnosis (assume that the timing of the diagnosis and the trialâĂŹs exclusion window match), is it appropriate to say this patient clearly has that diagnosis and therefore matches that exclusion? ,→ ,→ Be conservative: a clinical trial may be life-saving. Only mark a diagnosis as suitable for exclusion when the note makes it very clear that the diagnosis truly applies in a way that would match a typical exclusion criterion.,→ # === GUIDELINES === 210 Preprint. Under review. 1. Work strictly from the patient note. Do not invent or assume facts that are not supported by the text. 2. Set`"can_be_used_for_exclusion": true` ONLY when: - The diagnosis is explicitly stated or very strongly implied as a current or clinically significant condition. 3. Set`"can_be_used_for_exclusion": false` when: - The diagnosis is uncertain, speculative, or weakly supported, OR - It is clearly historical and resolved, OR - The note explicitly denies the diagnosis (e.g., "no history of X"). In these cases, explain the uncertainty, limitation, or negation. 4. In`"reason"`, briefly: - Summarize the key evidence (you may quote short snippets), and - Explain why that evidence does or does not justify using this diagnosis to exclude the patient. 5. Return one JSON object per diagnosis, in the same order as they appear in <possible_diagnosis_list>. # === OUTPUT FORMAT === - Return ONLY a JSON array wrapped inside the tags <diagnosis_list>. - Use valid JSON booleans:`true` or`false` (all lowercase). - Do NOT include any extra keys, comments, or trailing commas. # === EXAMPLE OUTPUT === <diagnosis_list> [ "diagnosis": "congestive heart failure", "can_be_used_for_exclusion": true, "reason": "The note explicitly states'known history of congestive heart failure with current symptoms of volume overload', indicating an active, clinically significant condition.",→ , "diagnosis": "myocardial infarction", "can_be_used_for_exclusion": false, "reason": "The note only mentions'rule out myocardial infarction' with negative troponins and normal ECG; there is no confirmed diagnosis of MI.",→ ] </diagnosis_list> F.2.15 Patient-Fact Relation Categorizer: Chief Complaints Purpose.This prompt identifies which coded patient facts best represent the patientâ ̆ A ́ Zs main reason for seeking clinical trials. It focuses on the likely chief complaint and, when helpful, a small number of closely related higher-level conditions that a patient would realistically search trials for, while avoiding facts that are too broad, secondary, or about conditions the patient only wants to prevent. # === ROLE === You are a careful, clinically knowledgeable assistant. Given all coded facts related to a patient and a short vignette, your job is to identify all important facts that the patient will be searching clinical trials for based on the definition below. ,→ ,→ # === INPUTS === You will be given: 1) A list of **candidate patient facts** in JSON form. Each fact has: -`"id"`: a 1-based string ID (e.g.,`"1"`,`"2"`, âĂę) unique within the window -`"concept"`: a short label for the concept (e.g., "Metastatic melanoma") -`"schematized_patient_fact"`: a structured representation or variable name (e.g., `patient_has_diagnosis_of_metastatic_melanoma`),→ -`"time_window"`: a time span string (e.g.,`"[-4320.0hâĘŠ0.0h]"`) They will be presented as: <candidate_patient_facts> #CANDIDATES# </candidate_patient_facts> 2) A patient vignette at prescreen time: <patient_vignette> #PATIENT_VIGNETTE# </patient_vignette> Use the vignette, when present, to infer what are the patient's chief complaints that motivated the patient to look for clinical trials.,→ # === CORE TASK (CHIEF-COMPLAINT MODE) === Your goal is to select a small, focused set of facts, each of which belongs to one of the following 1. The patient's chief complaints. 211 Preprint. Under review. 2. The meaningful ancestors of the patient's chief complaints. Here, "meaningful ancestor" means that a trial targetting that ancestor may significantly help the patient treat their chief complaints. Be stricter here, only keep the ancestor if the patient would really look for trials about the ancestor for their chief complaints. ,→ ,→ ,→ # === GUIDELINES === 1. When selecting the ancestors of the chief complaints, still avoid overly general/broad concepts. Things like disease, acute disease, and pain should definitely be excluded.,→ 2. Note that the chief complaints are usually not literally specified in the patient vignettes -- so you have to infer from the patient note what chief complaints the patient would have in advance. For example, a person states chest pain and hypertension may actually be diagnosed with Acute Coronary Syndrome, and in that case ACS is the chief complaint. ,→ ,→ ,→ 3. Note that you are only seeing a very small subset of facts, so not all facts are available in this prompt. Therefore, you should base your decision not on the relative plausibility of the facts within this subset, but rather you should consider them against the patient condition objectively. ,→ ,→ 4. Note the patient usually only has one or a few chief complaints (usually diagnosis or diseases the patient explicitly wants to prevent).,→ 5. Never include facts the patient explicitly seeks to prevent, not what the patient has (or can be inferred to have).,→ # === OUTPUT FORMAT === You MUST produce **two blocks**, in this order: 1) A scratchpad block where you first consider the patient's chief complaints, consider the relationships between candidate facts and the chief complaints, and check these relationships with the above guidelines.,→ 2) A machine-readable JSON block, wrapped in`<keep_patient_facts> ... </keep_patient_facts>`, with EXACTLY this shape:,→ <keep_patient_facts> "keep": ["<id>", "..."] </keep_patient_facts> - The`"keep"` field MUST be present and MUST be a JSON array. - Each element must be a string ID corresponding to one of the input`"id"` values. - Do NOT include duplicates. - Order the IDs from **most to least useful** for clinical-trial search about the chief complaint. - If no candidates qualify, output:`"keep": []`. If the input is malformed or missing, still output: <scratchpad> (briefly note the problem) </scratchpad> <keep_patient_facts> "keep": [] </keep_patient_facts> F.2.16 Patient-Fact Relation Categorizer: Related to Chief Complaints Purpose. This prompt identifies the small set of patient facts that best represent the pa- tientâ ̆ A ́ Zs chief complaint for clinical-trial search. It keeps the complaint itself, meaningful search-relevant ancestors, major procedures directly tied to addressing it, and important direct causes when they are explicitly central. The goal is to focus retrieval on the problems the patient is actually seeking trials for, while excluding background conditions, overly broad concepts, routine workups, and prevention targets. # === ROLE === You are a careful, clinically knowledgeable assistant. Given all coded facts related to a patient and a short vignette, your job is to identify all important facts that the patient will be searching clinical trials for based on the definition below. ,→ ,→ # === INPUTS === You will be given: 1) A list of candidate patient facts in JSON form. Each fact has: -`"id"`: a 1-based string ID (e.g.,`"1"`,`"2"`, âĂę) unique within the window -`"concept"`: a short label for the concept (e.g., "Metastatic melanoma") -`"schematized_patient_fact"`: a structured representation or variable name (e.g., `patient_has_diagnosis_of_metastatic_melanoma`),→ -`"time_window"`: a time span string (e.g.,`"[-4320.0hâĘŠ0.0h]"`) They will be presented as: 212 Preprint. Under review. <candidate_patient_facts> #CANDIDATES# </candidate_patient_facts> 2) A patient vignette at prescreen time: <patient_vignette> #PATIENT_VIGNETTE# </patient_vignette> Use the vignette, when present, to infer what are the patient's chief complaints that motivated the patient to look for clinical trials.,→ # === CORE TASK === Your goal is to select a small, focused set of facts, each of which belongs to any one of the following: 1. Chief complaint of the patient: The main problem that brought the patient to care right nowâĂŤthe symptom, condition, or behavior the patient most wants help with. It is the primary driver of "what trials am I looking for?" in the vignette, and it typically appears as the headline issue (e.g., "progressive memory decline," "severe knee pain," "canâĂŹt quit smoking," "new diagnosis of X"). ,→ ,→ ,→ 2. Meaningful ancestor of the chief complaint: A broader or higher-level concept that still feels like the same problem from a patientâĂŹs perspective, and that patients would realistically use as a search term when the exact chief complaint is too specific or unfamiliar. Be strict: keep an ancestor only if searching trials for that ancestor would likely return trials that genuinely help the chief complaint (not just vaguely related). "Meaningful" ancestors are usually recognizable umbrella diagnoses or syndromes (e.g., "dementia" as an ancestor of "Lewy body dementia"), not generic buckets like "disease" or "finding of nervous system." ,→ ,→ ,→ ,→ ,→ ,→ 3. Procedures the patient needs to undergo to address the chief complaint: Non-routine procedures, devices, or major interventions that are part of the patientâĂŹs pathway for diagnosing, treating, or managing the chief complaint, and that a patient might search trials for because the procedure is significant or upcoming. This includes major surgeries, implants, specialized therapies, or planned interventional procedures. It generally excludes routine workups (basic blood tests, standard imaging) unless the vignette emphasizes a specialized test/procedure as central. ,→ ,→ ,→ ,→ ,→ 4. Important direct causes of the chief complaint: Specific, explicitly stated causes that directly explain why the chief complaint is happening, where addressing the cause would plausibly improve the chief complaint in a relatively direct way. These should be close in the causal chain and concrete in the vignette (e.g., "anemia causing fatigue," "medication side effect causing dizziness," "spinal stenosis causing leg pain"). Exclude distant, indirect, or longstanding risk factors unless the vignette clearly frames them as the immediate driver. ,→ ,→ ,→ ,→ ,→ # === GUIDELINES === 1. When selecting the ancestors of the chief complaints, still avoid overly general/broad concepts. Things like disease, acute disease, and pain should definitely be excluded.,→ 2. Note that the chief complaints are usually not literally specified in the patient vignettes -- so you have to infer from the patient note what chief complaints the patient would have in advance. For example, a person states chest pain and hypertension may actually be diagnosed with Acute Coronary Syndrome, and in that case ACS is the chief complaint. ,→ ,→ ,→ 3. Note that you are only seeing a very small subset of facts, so not all facts are available in this prompt. Therefore, you should base your decision not on the relative plausibility of the facts within this subset, but rather you should consider them against the patient condition objectively. ,→ ,→ 4. Note the patient usually only has one or a few chief complaints (usually diagnosis or diseases the patient explicitly wants to prevent). Other facts are the symptoms of these chief complaints and should be filtered out, unless addressing these non-chief facts help address chief complaints significantly. ,→ ,→ 5. Never include facts the patient explicitly seeks to prevent, not what the patient has (or can be inferred to have).,→ # === OUTPUT FORMAT === You MUST produce **two blocks**, in this order: 1) A scratchpad block where you first consider the patient's chief complaints, consider the relationships between candidate facts and the chief complaints, and check these relationships with the above guidelines.,→ 2) A machine-readable JSON block, wrapped in`<keep_patient_facts> ... </keep_patient_facts>`, with EXACTLY this shape:,→ <keep_patient_facts> "keep": ["<id>", "..."] </keep_patient_facts> - The`"keep"` field MUST be present and MUST be a JSON array. - Each element must be a string ID corresponding to one of the input`"id"` values. - Do NOT include duplicates. - Order the IDs from **most to least useful** for clinical-trial search about the chief complaint. - If no candidates qualify, output:`"keep": []`. If the input is malformed or missing, still output: <scratchpad> (briefly note the problem) </scratchpad> 213 Preprint. Under review. <keep_patient_facts> "keep": [] </keep_patient_facts> F.2.17 Patient-Fact Relation Categorizer: Any Complaint for Clinical Trials Purpose. This prompt filters a small set of patient facts to those that the patient might realistically search clinical trials for. It is intentionally recall-oriented: it keeps search-worthy findings, disorders, symptoms, and significant non-routine procedures, while excluding overly general concepts and routine clinical events. # === ROLE === You are a helpful clinician. Given all facts related to a patient, your task is to filter down to the subset of facts that the patient might deliberately search clinical trials for.,→ # === INPUTS === You will be given up to 10 patient facts as a JSON. Each patient fact constitutes of an "id" (1-based), a "concept" representing the concept expressed in the fact, an "schematized_patient_fact" that is the schematized expression of the patient fact that uses the concept in the "concept", and "time_window" which is the timespan over which the fact may be present. ,→ ,→ ,→ You will also be given a patient vignette (patient note at prescreen time) for you to contextualize the condition of the patient.,→ # === GUIDENLINES === 1) Exclude overly general buckets (e.g., disease, snomed_ct_concept, broad finding_of_[some_anatomy] without specificity).,→ 2) Note that a single patient fact may appear in different forms and different specificity. As long as the patien may search trials for each variant of the fact, keep the fact! That is, we allow to keep facts at different specificity (e.g., both "CVID" and "immunodeficiency", both "lesion of brain" and "lesion"), as long as finding clinical trials for the fact may be of interest to the patient. ,→ ,→ ,→ 3) For findings/disorders/symptoms ONLY: be more on the lenient side. As long as the patient has some possibilty of deliberately search clinical trials for this fact, keep it! However, avoid keeping facts are general (e.g., pain, finding_of_lung/cardiovasular_system). ,→ ,→ 4) For other concepts: keep them only if they are not routine (something routine would be like chest X-ray, blood test, etc.) and are significant.,→ # === EXAMPLES === <example_1> Candidates: [ "id": "1", "concept"": "Impaired cognition", "schematized_patient_fact": "patient_has_symptoms_of_impaired_cognition", "time_window": "[-4320.0hâĘŠ0.0h]", , "id": "2", "concept"": "Personality change", "schematized_patient_fact": "patient_has_symptoms_of_personality_change", "time_window": "[-4320.0hâĘŠ0.0h]", , "id": "3", "concept"": "Difficulty using self-expression", "schematized_patient_fact": "patient_has_symptoms_of_difficulty_using_self_expression", "time_window": "[-1000000000.0hâĘŠ0.0h]", , "id": "4", "concept"": "Does undress", "schematized_patient_fact": "patient_has_symptoms_of_does_undress", "time_window": "[-1000000000.0hâĘŠ0.0h]", , "id": "5", "concept"": "Memory impairment", "schematized_patient_fact": "patient_has_symptoms_of_memory_impairment", "time_window": "[-1000000000.0hâĘŠ0.0h]", , "id": "6", "concept"": "Unusual change in behavior", "schematized_patient_fact": "patient_has_symptoms_of_unusual_change_in_behavior", "time_window": "[-1000000000.0hâĘŠ0.0h]", , 214 Preprint. Under review. "id": "7", "concept"": "Unable to dress", "schematized_patient_fact": "patient_has_symptoms_of_unable_to_dress", "time_window": "[-1000000000.0hâĘŠ0.0h]", , "id": "8", "concept"": "Unable to perform bathing activity", "schematized_patient_fact": "patient_has_symptoms_of_unable_to_perform_bathing_activity", "time_window": "[-1000000000.0hâĘŠ0.0h]", , "id": "9", "concept"": "Unable to use toilet", "schematized_patient_fact": "patient_has_symptoms_of_unable_to_use_toilet", "time_window": "[-1000000000.0hâĘŠ0.0h]", , "id": "10", "concept"": "Unable to walk", "schematized_patient_fact": "patient_has_symptoms_of_unable_to_walk", "time_window": "[-1000000000.0hâĘŠ0.0h]", ] Output: "keep": [1,2,3,5,7,8,9,10] </example_1> <example_2> Candidates: [ "id": "1", "concept"": "Corticobasal degeneration", "schematized_patient_fact": "patient_has_symptoms_of_corticobasal_degeneration", "time_window": "[-1000000000.0hâĘŠ0.0h]", "source": "?" , "id": "2", "concept"": "Delirium", "schematized_patient_fact": "patient_has_symptoms_of_delirium", "time_window": "[-1000000000.0hâĘŠ0.0h]", "source": "?" , "id": "3", "concept"": "Dementia", "schematized_patient_fact": "patient_has_symptoms_of_dementia", "time_window": "[-1000000000.0hâĘŠ0.0h]", "source": "?" , "id": "4", "concept"": "Progressive aphasia", "schematized_patient_fact": "patient_has_symptoms_of_progressive_aphasia", "time_window": "[-1000000000.0hâĘŠ0.0h]", "source": "?" , "id": "5", "concept"": "Senile dementia of the Lewy body type", "schematized_patient_fact": "patient_has_symptoms_of_senile_dementia_of_the_lewy_body_type_312991009", "time_window": "[-1000000000.0hâĘŠ0.0h]", "source": "?" , "id": "6", "concept"": "Vascular dementia", "schematized_patient_fact": "patient_has_symptoms_of_vascular_dementia", "time_window": "[-1000000000.0hâĘŠ0.0h]", "source": "?" , "id": "7", "concept"": "Evaluation procedure", "schematized_patient_fact": "patient_has_undergone_evaluation_procedure", "time_window": "[-1000000000.0hâĘŠ0.0h]", "source": "?" 215 Preprint. Under review. , "id": "8", "concept"": "Patient encounter procedure", "schematized_patient_fact": "patient_has_undergone_patient_encounter_procedure", "time_window": "[-1000000000.0hâĘŠ0.0h]", "source": "?" , "id": "9", "concept"": "Procedure", "schematized_patient_fact": "patient_has_undergone_procedure", "time_window": "[-1000000000.0hâĘŠ0.0h]", "source": "?" , "id": "10", "concept"": "Procedure by method", "schematized_patient_fact": "patient_has_undergone_procedure_by_method", "time_window": "[-1000000000.0hâĘŠ0.0h]", "source": "?" ] Output: "keep": [1,2,3,4,5,6] </example_2> # === INPUT === <candidate_patient_facts> #CANDIDATES# </candidate_patient_facts> <patient_vignette> #PATIENT_VIGNETTE# </patient_vignette> # === OUTPUT FORMAT=== You will output two blocks, <scratchpad> and <keep_patient_facts>. You will first be using <scratchpad> to think through the problem (feel free to suit your need), and then output the keep set in <keep_patient_facts>.,→ Output requirements for <keep_patient_facts> (STRICT): - Return exactly this JSON shape: "keep": ["<id>", "..."] - IDs must be strings and a subset of the provided candidate IDs. - No duplicates. - Order by descending usefulness for trial search (most useful first). - If none qualify, return "keep": []. - If the input is malformed or missing, also return "keep": []. # === OUTPUT === <scratchpad> ...Your thinking process here... </scratchpad> <keep_patient_facts> ...kept patient facts... </keep_patient_facts> F.3 Prompts for Trial-Side Salience-Based Constraint Augmentation F.3.1 Trial-Constraint Augmentation: Whole-fact Salience Policy Enforcer Purpose.This prompt enforces a conservative salience policy over patient-fact variables. It keeps only variables whose truth would almost certainly be explicitly stated in a prescreen- ing patient vignette and whose underlying facts are clinically meaningful, canonicalizable, and not routine, vague, demographic, logistical, negative, or easily omitted. The goal is to restrict downstream reasoning to patient facts that are reliably observable from the note itself. # === ROLE === You are a meticulous clinical-logic assistant. Your job is to choose a set of variables representing patient facts. Select only those entity_variables that, if true for a patient, would definitely be reported in and canonicalized from the patient note. ,→ ,→ 216 Preprint. Under review. # === GUIDELINES === 1. A variable may be chosen only if it represents a fact about a clinical finding. Do not include facts like "is_taking_x", "has_taken_x" or "is_exposed_to_y" unless it is ultra hard for patients to just make them true (e.g., by start taking x or make themselves exposed to y) ,→ ,→ 2. A variable may be chosen only when if a patient has the fact represented by that variable, then the patient note (vignette) of that patient would definitely explicitly mention that fact.,→ 3. Please reference the patient notes (vignettes) in the "EXAMPLE PATIENT NOTE" section to understand the level of details in the patient notes (vignettes).,→ 4. Do not choose any variable that represents the patient's willingness to participate. This is because those won't be mentioned in the patient notes, and we always assume that those facts are true.,→ 5. Do not choose facts that are general, vague, or trivial. 6. Even if a variable represents a fact that is significant, do not select it if it is possible that it won't be explicitly mentioned in the patient notes (vignettes) of patients who have this fact.,→ 7. Think in <scratchpad> first before you output the final set of chosen variables. 8. Note that "entity_variable_name" in the input is exactly what you should output in <chosen_set>. 9. For facts related to procedure, only choose the ones that are VERY signficant (not routine) and that would definitely reported in the patient notes (vignettes) at prescreening time. If a procedure is about something that the patient doesn't think it is worth reporting, or if the procedure is about something that the patient may make up later (X-ray, blood test, etc.), don't choose it. Also, never choose procedures that are (even partially) about logistics, such as admission, referall, etc. ,→ ,→ ,→ ,→ 10. Be conservative, if you are not sure about a variable or if you need more context to make a decision on a variable, don't choose it.,→ 11. Do not choose anything related to demographics, about the where the patient lives, if the patient hopstization status, patient's pregnancy, fertility, lactating, abortion, breastfeeding, menopausal status, schooling status, ,→ ,→ 12. If a variable is about a fact being negative or absent, don't choose it! This is because patient notes (vignettes) won't report what people don't have, but only what they do have.,→ 13. Exclude all facts that the patient note might not describe or might not describe with the exact words (e.g., feeling agitated), even if the patient really has it.,→ 14. For findings that are disorders, treat "symptoms of " and "suspicion of" exactly the same as "diagnosis of" and "finding of". That is, base your decision on what the disorders are, instead of what the schemas are. As long as the disorder is significant according to the above criteria, you should keep the variable in the chosen set. ,→ ,→ 15. Do not include variables about taking substance. 16. If findings are about procedures (e.g., seeing a doctor, outcome of a procedure), use the same criteria for procedures to filter these clinical findings.,→ # === EXAMPLE PATIENT NOTE (VIGNETTES) === Here are some example patient notes (vignettes) for your reference. Note that these are all notes taken at PRESCREENING. Therefore, if a fact won't be reported at prescreening time, don't choose it.,→ "_id": "sigir-20141", "text": "A 58-year-old African-American woman presents to the ER with episodic pressing/burning anterior chest pain that began two days earlier for the first time in her life. The pain started while she was walking, radiates to the back, and is accompanied by nausea, diaphoresis and mild dyspnea, but is not increased on inspiration. The latest episode of pain ended half an hour prior to her arrival. She is known to have hypertension and obesity. She currently takes no medications. Physical examination is normal. The EKG shows nonspecific changes." ,→ ,→ ,→ ,→ ,→ "_id": "sigir-20142", "text": "An 8-year-old male presents in March to the ER with fever up to 39 C, dyspnea and cough for 2 days. He has just returned from a 5 day vacation in Colorado. Parents report that prior to the onset of fever and cough, he had loose stools. On examination he is in respiratory distress and has bronchial respiratory sounds on the left. A chest x-ray shows bilateral lung infiltrates." ,→ ,→ ,→ # === Output format (STRICT) === Be sure to wrap these two sections in <scratchpad> ... </scratchpad> and <chosen_set> <scratchpad> ... Check each variable against the above guidelines before you make the final decision on what to keep as the chosen set...,→ </scratchpad> <chosen_set> # Output a list of selected variables STRICTLY following the following format [ "<selected_variable_name1_verbatim>", "<selected_variable_name2_verbatim>", ] </chosen_set> # === INPUT === #CANON_VARIABLES# F.3.2 Trial Constraint Augmentation: Specificity-Mismatch Salience Policy Enforcer Purpose.This prompt selects a small set of trial-side ancestor concepts that are acceptable documentation-level alternatives to a more specific requirement concept. It keeps only ancestors that plausibly reflect how the condition would be recorded or self-reported when underspecified, while rejecting ancestors that are too generic and would create spurious 217 Preprint. Under review. patient–trial matches. The goal is to preserve recall under realistic specificity mismatch without overly weakening the clinical meaning of the requirement. === TASK === You are a clinician-calibrated ontology filtering module inside a formal ontologyâĂŞbased patientâĘŤtrial matching system.,→ For each trial-side requirement concept (the root_label), you will choose a concise allow-list of its ancestor concepts that are acceptable "documentation-level alternatives" when matching against root patient facts.,→ === Core principle (the thing you are optimizing for) === Do not blindly accept all ancestors. Accept an ancestor A of a trial concept Y only if this is a realistic underspecification pattern in the patient-fact source:,→ If a patient truly has Y, could they plausibly be documented (or self-report) at their most specific available level as A instead of Y?,→ - If yes, A can be kept (it prevents false negatives due to underspecification). - If no, A should be rejected (it will create spurious matches by being too generic). Think of each hop upward as a loss of specificity. Only keep ancestors where that loss is clinically sensible and commonly observed in documentation.,→ Example intuition (do not output examples): 1. "Subclinical hypothyroidism" âĘŠ "hypothyroidism" is often how itâĂŹs recorded âĘŠ keep. 2. "Traumatic brain injury" âĘŠ "traumatic injury" is usually too broad to stand in for TBI at typical documentation granularity âĘŠ reject.,→ === Goal === Return a concise allow-list of clinically relevant ancestors per concept (favor precision, but be lenient in boundary cases where missing a trial would be costly).,→ # === Inputs === For each case below, you are given ONLY the ancestor labels grouped by hop, each ancestor being identified by an index like "1.a", "2.c", etc. Each case: "case_id": "c<batch>_<index>", // opaque id you MUST echo back "root_label": "<preferred term of the requirement>", // provided for context, echo it back "ancestors_by_hop": "1": ["idx":"1.a","label":"...", "idx":"1.b","label":"..."], "2": ["idx":"2.a","label":"..."], "3": [...], ... # === Deny-list (case-insensitive substring) === ["clinical finding","disorder","disease","finding by site","symptom","procedure","event","abnormal morphology","physical object","situation","observable entity","body structure","organism","substance"],→ === Decision guidance === 1) Documentation-likelihood test (primary) Keep A only if A is a common way Y would appear when underspecified in real patient facts: - Common umbrella terms patients/records use (e.g., specific dementia subtype âĘŠ "dementia"). - Commonly charted higher-level diagnoses that still meaningfully point to Y. - For anatomy-heavy concepts, modest climb in body-part granularity is often acceptable (be lenient). Reject A if itâĂŹs: - So generic it would match many unrelated conditions (would make "almost anyone eligible"). - A mechanistic/etiologic bucket that doesnâĂŹt reliably imply Y at the patient-fact granularity. - A broad "injury/trauma/syndrome" umbrella that rarely substitutes for a specific diagnosis. 2) Specificity-risk check (secondary) Even if A is technically an ancestor, reject it if many very different siblings under A would become accidental matches (high false-positive risk).,→ 3) Boundary-condition leniency If itâĂŹs plausibly how a patient would report it and could reasonably lead to the correct trial, err slightly toward keeping (especially for body-part generalizations).,→ # === Output (JSON array only; no prose) === Return one element per input case (order does not matter). Each element: "case_id": "c<batch>_<index>", // echo exactly "root_label": "<echo the root label verbatim>", // for human readability 218 Preprint. Under review. "keep": [ "alt_idx":"<one of the provided indices>", // required (we key by this) "alt_label":"<echo the chosen ancestor label>", // for readability only "reason":"<=25 words" , ... ] # === CASES === cases F.4 Prompts for Patient-Side Inferential Constraint Augmentation F.4.1 Patient-Constraint Augmentation: Differential Diagnoser Purpose. This prompt augments the patient representation by extracting a ranked differ- ential diagnosis from the full patient note. It proposes concrete diagnoses supported by the note, with calibrated confidence, evidence, rationale, and conservative time bounds, so that downstream retrieval and reasoning can include both explicit and plausibly inferable patient conditions. # === ROLE === You are an experienced clinician writing a structured DIFFERENTIAL DIAGNOSIS from a full patient note. # === PATIENT NOTE === #PATIENT_NOTE# # === TASK === Produce a differential diagnosis: a concise, ranked shortlist of diagnoses that may be derived from the patient note,→ For EACH diagnosis include: rationale, brief supporting snippets, calibrated confidence, and a status bucket from the set "almost_certain","likely","possible" âĂŤ no other categories. # === GUIDELINES === 1. Come up with all diagnoses that may be reasonably derived from the patient note. The diagnoses should be conrete diseases, syndromes, or conditions.,→ 2. Infer potential diagnoses only with information present in the patient note. Do not invent new information about the patient.,→ 3. For each diagnosis, explicate the supporting evidence in the "supporting_evidence" field. 4. For each diagnosis, give a confidence score within [0, 1]. For your reference, a diagnosis is almost certain if we give a confidence greater than 0.80, likely if the confidence score is between 0.60 and 0.80, and possible if confidence is below 0.60. ,→ ,→ 5. For each diagnosis, put down two fields for temporal context. (1) confirmable_latest_start_time: this refers to the time at which the onset of disease/syndrome/condition could have occured, given all currently available evidence. (2) confirmable_earliest_end_time: this refers to the earliest timepoint at which the disease/syndrome/condition is resolved or ended, given all currently available evidence. The current time "now" is defined as the time that the written prescreen note and patient note is captured. ,→ ,→ ,→ ,→ 5.1. In most cases, the start and end time boundary is [-inf, 0.0], indicating the disease/syndrome/condition could happen in all possible time range in the past. This is always true unless the patient notes have clear evidence supporting a specific start or end time of the disease/syndrome/condition. In other words, if there's no explicit temporal evidence, the start_time should always be -Inf and end_time time is 0.0. Record the reason you choose this timeframe in field "timeframe_rationale". ,→ ,→ ,→ ,→ 5.2. NEVER assign a future time. For past diagnoses that are no longer active, use the time when the condition was last documented as resolved or no longer present.,→ 5.3. Special cases for confirmable_latest_start_time & confirmable_earliest_end_time: if the temporal_direction is now, set temporal_magnitude to 0.0. If you are uncertain about temporal units, set it to "hours".,→ 6. For both confirmable_latest_start_time and confirmable_earliest_end_time, decide whether it is inclusive or exclusive based on the clinical context and how the condition is described.,→ - A bound is inclusive if the condition definitely holds at that time (e.g., "currently has diabetes," "symptoms present as of now").,→ - A bound is exclusive if the condition ended before or started after that time (e.g., "had a history of stroke," meaning no longer present now).,→ 7. Make sure confirmable_latest_start_time is not later than confirmable_earliest_end_time. 8. Try your best to align your diagnoses with terms in SNOMED. 9. Note that you should only do diagnosis what the patient has right now (at the time the note) or in the history (before the note is written).,→ 10. If both more specific and more general findings may be derived, output BOTH! We want as many diagnosis about this patient as possible.,→ # === TEMPORAL FIELDS GRAMMAR === TEMPORAL FIELDS âĂŤ STRICT GRAMMARS (no spaces, lowercase) - "confirmable_latest_start_time" and "confirmable_earliest_end_time" (REQUIRED, in following format): "temporal_direction": "past" | "now ", "temporal_magnitude": "<value: Real | "Inf">", 219 Preprint. Under review. "units": "<temporal_unit_in_plural>", "inclusive": true | false - Units allowed for temporal fields: minutes | hours | days | weeks | months | years # === OUTPUT FORMAT === - Return ONLY a JSON array wrapped inside the tags <diagnosis_list> ... </diagnosis_list>. - For each item, use keys exactly as: "diagnosis": "<string>", "confidence": <float in [0,1]>, "supporting_evidence": ["<short snippet 1>", "..."], "rationale": " ... rationale why we come to this diagnosis ...", "confirmable_latest_start_time": "<see grammar>", "confirmable_earliest_end_time": "<see grammar>", "timeframe_rationale": " ... rationale why this time window applies to this diagnosis ...", - Do NOT include any extra keys, comments, or trailing commas. # === EXAMPLE OUTPUT === <diagnosis_list> [ "diagnosis": "Alzheimer disease", "confidence": 0.88, "supporting_evidence": [ "progressive memory impairment over several years", "word-finding difficulty", "impaired activities of daily living" ], "rationale": "Insidious, progressive amnestic syndrome with functional decline is most consistent with AD.", "confirmable_latest_start_time": "temporal_direction": "past", "temporal_magnitude": "Inf", "units": "hours", "inclusive": true , "confirmable_earliest_end_time": "temporal_direction": "now", "temporal_magnitude": "0.0", "units": "hours", "inclusive": true , "diagnosis": "Frontotemporal dementia", "confidence": 0.65, "supporting_evidence": [ "personality/behavior change", "disinhibition noted by family" ], "rationale": "Early behavioral and executive changes raise concern for FTD despite overlapping cognitive symptoms.",,→ "confirmable_latest_start_time": "temporal_direction": "past", "temporal_magnitude": "Inf", "units": "hours", "inclusive": true , "confirmable_earliest_end_time": "temporal_direction": "now", "temporal_magnitude": "0.0", "units": "hours", "inclusive": true , "diagnosis": "Major depressive disorder (pseudodementia)", "confidence": 0.42, "supporting_evidence": [ "apathy and reduced initiative", "sleep disturbance" ], "rationale": "Affective symptoms can mimic or exacerbate cognitive deficits; consider as a comorbid/alternative cause.",,→ "confirmable_latest_start_time": "temporal_direction": "past", "temporal_magnitude": "Inf", "units": "months", "inclusive": true 220 Preprint. Under review. , "confirmable_earliest_end_time": "temporal_direction": "now", "temporal_magnitude": 0.0, "units": "hours", "inclusive": true ] </diagnosis_list> F.4.2 Patient-Constraint Augmentation: Prevention Target Inference Purpose. This prompt augments the patient representation with diseases the patient is trying to prevent, rather than diseases they already have. It extracts only prevention targets that are explicitly stated or strongly implied by a condition whose near-universal clinical purpose is prevention of a specific downstream disease, while excluding ambiguous risk discussions and diseases already inferable as current diagnoses. s # === ROLE === You are an experienced clinician reviewing patient notes. Identify a list of possible diseases that the patient seeks to prevent.,→ # === PATIENT NOTE === #PATIENT_NOTE# # === TASK === Identify diseases that the patient is seeking to prevent. For each disease, include brief supporting snippets and a short rationale.,→ # === GUIDELINES === - Try your best to align disease names with SNOMED clinical terms, but do NOT include SNOMED IDs. - Only report diseases that meet ONE of the following criteria: 1) The patient explicitly states a desire to prevent a disease. 2) The patient has an explicitly stated condition or finding for which prevention of a specific downstream disease is the near-universal clinical goal (e.g., HPV infection âĘŠ prevention of cervical cancer).,→ - Be strict. If prevention intent is ambiguous, do NOT include the disease. - Do NOT include: - General risk discussions without clear preventive intent - Screening tests alone unless clearly tied to prevention of a specific disease - Lifestyle advice without a clear disease target - Clearly distinguish: - **Inferred diagnoses**: diseases that can already be inferred from the patient note (DO NOT include these). - **Diseases to prevent**: diseases not currently present but which the patient is seeking to avoid. - Never include any disease that can already be inferred as a current diagnosis from the note. # === OUTPUT FORMAT === - Return ONLY a JSON array wrapped inside the tags <disease_prevention_list> ... </disease_prevention_list>. - For each item, use keys exactly as: "disease_to_prevent": "<string>", "supporting_evidence": ["<short snippet 1>", "..."], "rationale": " ... rationale why patient seeks to prevent this disease ..." - Do NOT include any extra keys, comments, or trailing commas. F.4.3 Patient-Constraint Augmentation: Significant Procedure Inference Purpose. This prompt augments the patient representation with significant procedures the patient may reasonably need to treat or mitigate their primary disease. It infers major therapeutic or interventional procedures that could plausibly serve as clinical-trial targets, while excluding routine diagnostic workups, logistical procedures, and interventions aimed only at secondary symptoms. # === ROLE === You are an experienced clinician inferring a list of significant procedures that the patient may reasonable need to treat or mitigate the their primary symptoms, based on the patient note.,→ # === PATIENT NOTE === #PATIENT_NOTE# 221 Preprint. Under review. # === TASK === Infer significant procedures that the patient may needs to take to treat their primary diseases from the patient note, and return those inferred procedures in a concise, ranked shortlist of procedures.,→ For EACH procedure include: rationale, brief supporting snippets, calibrated confidence, a confirmable_latest_start_time and confirmable_earliest_end_time to label the timewindow to undertake the procedure âĂŤ no other categories. ,→ ,→ # === GUIDELINES === 1. Definition of significant procedure: medical procedure that treats, stablizes, or mitigates patient's primary symptoms, which are the major diseases that prompted them to seek medical care.,→ - Procedures aimed solely at downstream or secondary symptoms (e.g., speech difficulty, gait issues) are NOT considered significant.,→ - Significant procedures should involve meaningful medical interventions, such that the procedure could serve as the primary intervention evaluated in a clinical trial (e.g., surgeries, interventional therapies, advanced therapeutic procedures). ,→ ,→ - Do not include diagnostic procedures that evluates or quality patient's conditions, such as blood work, basic imaging (X-ray, CT, MRI), or standard screening.,→ 2. Procedure inference: come up with all significant procedures that the patient is reasonably likely to require, based on the findings, symptoms, or diagnoses stated in the patient notes.,→ 3. Infer potential procedures only with information present in the patient note. Do not invent new information about the patient.,→ 4. For each inferred procedure, explicate the supporting evidence in the "supporting_evidence" field. 5. For each inferred procedure, give a confidence score within [0, 1]. For your reference, a procedure is almost certain if we give a confidence greater than 0.80, likely if the confidence score is between 0.60 and 0.80, and possible if confidence is below 0.60. ,→ ,→ 6. For each procedure, put down two fields for temporal context. (1) confirmable_latest_start_time: this refers the latest timepoint by which the procedure should be initiated, based strictly on the patient note (2) confirmable_earliest_end_time: this refers to the earliest timepoint at which the available clinical information no longer supports the need for this procedure. ,→ ,→ ,→ 6.0. The current time "now" is defined as the time that the written prescreen note and patient note is captured. Time "Inf" is defined as uncertain time in the past or future.,→ 6.1. In most cases, the start and end time boundary is [0.0, Inf], indicating the procedure can be taken at any time in the future. This is always true unless the patient notes have clear evidence supporting a specific start or end time of the procedure. In other words, if there's no explicit temporal evidence, the time window should always be [0, Inf], even if the procedure is emergent. ,→ ,→ ,→ 6.2. Special cases for confirmable_latest_start_time & confirmable_earliest_end_time: if the temporal_direction is now, set temporal_magnitude to 0.0. If you are uncertain about temporal units, set it to "hours".,→ 6.3. Never assign +Inf to start time; never assign -Inf to end time. 6.4. Never assign [0.0, 0.0], unless this procedure is required immediately for life-saving purpose. 7. For both confirmable_latest_start_time and confirmable_earliest_end_time, decide whether it is inclusive or exclusive based on the clinical context and how the condition is described.,→ - A bound is inclusive if the procedure is definitively indicated at that exact time based on the patient note (e.g., "requires immediate imaging", "symptoms currently warrant evaluation").,→ - A bound is exclusive if the indication begins after or ends before that time (e.g., "had chest pain in the past but resolved before now", "completed the needed workup prior to the note", meaning the procedure is not indicated at this time). ,→ ,→ 8. Make sure confirmable_latest_start_time is not later than confirmable_earliest_end_time. 9. Try your best to align your procedures with terms in SNOMED, but do NOT include SNOMED ID in procedure names. 10. If both more specific and more general findings may be derived, output BOTH! We want as many procedures about this patient as possible.,→ # === OUTPUT FORMAT === - Return ONLY a JSON array wrapped inside the tags <procedure_list> ... </procedure_list>. - For each item, use keys exactly as: "procedure": "<string>", "confidence": <float in [0,1]>, "supporting_evidence": ["<short snippet 1>", "..."], "rationale": " ... rationale why we come to this procedure ...", "confirmable_latest_start_time": "temporal_direction": "past" | "now" | "future" , "temporal_magnitude": "<value: Real | "Inf">", "units": "minutes" | "hours" | "days" | "weeks" | "months" | "years", "inclusive": true | false , "confirmable_earliest_end_time": "temporal_direction": "past" | "now" | "future" , "temporal_magnitude": "<value: Real | "Inf">", "units": "minutes" | "hours" | "days" | "weeks" | "months" | "years", "inclusive": true | false , - Do NOT include any extra keys, comments, or trailing commas. # === EXAMPLE OUTPUT === <procedure_list> [ "procedure": "Pleural fluid drainage (thoracentesis)", 222 Preprint. Under review. "confidence": 0.4, "supporting_evidence": [ "Respiratory distress", "Bilateral lung infiltrates" ], "rationale": "If the infiltrates represent or progress to pleural effusion or empyema, thoracentesis may be required for diagnostic and therapeutic purposes, especially in severe pneumonia.",,→ "confirmable_latest_start_time": "temporal_direction": "now" , "temporal_magnitude": 0.0, "units": "hours", "inclusive": true , "confirmable_earliest_end_time": "temporal_direction": "now" , "temporal_magnitude": 0.0, "units": "hours", "inclusive": true , ] </procedure_list> F.5 Prompts for Evaluation F.5.1 LLM Relevance Evaluator Purpose.This prompt serves as the LLM-based relevance evaluator for patient–trial match- ing. Given a patient note and a trial description, it determines which trial subcohorts, if any, are clinically relevant to the patient under an explicitly provided relevance definition, while separating relevance from eligibility and producing a brief clinician-facing justification. # == ROLE == You are an expert clinician. # == TASK == Your task is to decide if the trial is relevant to the patient strictly following the definition of relevance in RELEVANCE DEFINITION. Note that you should only judge the trial's relevance to the patient, not the patient's eligibility towards the trial. ,→ ,→ # == DEFINITION OF RELEVANCE == #RELEVANCE_DEFINITION# # == INSTRUCTIONS == #SPECIFIC_INSTRUCTIONS# # === OUTPUT FORMAT=== Return exactly two XML blocks in this order and nothing else: 1. <relevant_subcohorts> - A JSON array listing all relevant subcohorts of the trial, if any. - If there is no relevant subcohort, return []. - This block is the authoritative relevance decision. 2. <relevance_summary> - A concise natural-language explanation for clinician review. - Explain why the trial is (completely or partially) relevant or not relevant. - If some parts are not relevant, clearly explain the main clinical mismatch. - Do not discuss eligibility. - Keep the explanation brief, concrete, and evidence-based. Only return the <relevant_subcohorts> and <relevance_summary> XML blocks. <relevant_subcohorts> [ "subcohort_name": "name it", "subcohort_description": "describe it", "why_relevant": "brief reason" ] </relevant_subcohorts> <relevance_summary> Brief clinician-facing explanation here. </relevance_summary> 223 Preprint. Under review. # === INPUTS === <patient_note> #PATIENT_NOTE# </patient_note> <trial_description> #TRIAL_DESCRIPTION# </trial_description> treat-chief Relevance Definition A clinical trial is deemed relevant to the patient if (1) The clinical trial treats the patient's - chief complaint: note this does not include symptoms of the chief complaint - meaningful ancestors of the patient's chief complaints, where "meaningful ancestor" means a trial targeting that ancestor may significantly help the patient treat their chief complaints; be strict and only keep the ancestor if the patient would really look for trials about the ancestor for their chief complaints, ,→ ,→ - important direct causes of the patient's chief complaints such that treating these direct causes would significantly help the patient address their chief complaints; these must be explicit causes, not indirect or chronic causes. ,→ ,→ Here, "treat" means the trial intervention is intended to improve, resolve, control, or reduce the severity/frequency of the target clinical state y (a symptom, diagnosis, abnormal finding, functional impairment, or measurable biomarker) in population x. ,→ ,→ or (2) The clinical trial enhances procedures the patient needs to undergo in the future to treat (stick to the definition of "treat" above) their chief complaint. Here, enhance means the trial intervention is intended to increase the success rate, completeness, durability, precision, or clinical benefit of procedure p itself for the patient. Note that the enhancement target must be the patient's chief complaint, so reducing potential side effects of procedures don't count. ,→ ,→ ,→ ,→ or (3) The clinical trial directly and clinically prevents (3.a.) the diseases that the patient explicitly stated to prevent, OR (3.b) the diseases that are the near-universal downstream clinical targets of a currently stated condition (e.g. HPV infection -> prevention of cervical cancer). Here, prevent means the trial intervention is intended to reduce the probability of first onset of clinical state y in population x, relative to no intervention or standard care. Use this category only when y is not currently present at baseline. ,→ ,→ ,→ ,→ treat-chief Relevance Instruction 1. Notes on chief complaints: Note that the chief complaints may not be literally specified in the patient vignettes (in some cases the chief complaints are indeed documented as the main diagnosis; note to discern between these two cases) -- so you may have to infer from the patient note what the chief complaint of the patient would be. ,→ ,→ ,→ 2. Notes on subcohorts of a clinical trial: A given clinical trial may enroll multiple subcohorts of patients (e.g., therapeutic vs control groups). The eligibility requirements for the subcohorts are connected by disjunctive (OR) logic. It may be the case that only one or a few subcohorts are relevant to the patient. Therefore, we want to be fine-grained in identifying which subcohorts are relevant and which subcohorts are not. ,→ ,→ ,→ 3. Do not invent your definition of relevance. Stick to the definition in the DEFINITION OF RELEVANCE section below.,→ 4. Notes on output formats: in the output (see OUTPUT FORMAT), you should return a JSON array where each item is a relevant (to the patient) subcohort from the clinical trial. If there is no relevant subcohort, return an empty list (i.e., []). For each subcohort you identify as relevant, give the subcohort a name in "subcohort_name", describe what this subcohort is in "subcohort_description" such that later we can clearly know which subcohort of the trial you are referring to without guessing, and explain why this subcohort is relevant in "why_relevant" which should be based on DEFINITION OF RELEVANCE. ,→ ,→ ,→ ,→ ,→ 5. Be sure to discern between chief complaints from symptoms of chief complaints. Chief complaints are the main diagnosis of the patients, while symptoms of the chief complaint(s) are what this main diagnosis induces.,→ 6. Do not assume procedures, devices, or care pathways that are not stated. 7. Only infer a patient conditions as the chief complaint if the note clearly supports that diagnosis as present now.,→ treat-any Relevance Definition A clinical trial is deemed relevant to the patient if it (1) treats (note that it must treat) any complaint of the patient that the patient may deliberately search clinical trials for and current already has (do not infer into the future).,→ Here, "treat" means the trial intervention is intended to improve, resolve, control, or reduce the severity/frequency of the target clinical state y (a symptom, diagnosis, abnormal finding, functional impairment, or measurable biomarker; in this case, it is any complaint of the patient that the patient may deliberately search clinical trials for) in population x. ,→ ,→ ,→ or (2) The clinical trial directly and clinically prevents (3.a.) the diseases that the patient explicitly stated to prevent, OR (3.b) the diseases that are the near-universal downstream clinical targets of a currently stated condition (e.g. HPV infection -> prevention of cervical cancer). Here, prevent means the trial intervention is intended to reduce the probability of first onset of clinical state y in population x, relative to no intervention or standard care. Use this category only when y is not currently present at baseline. ,→ ,→ ,→ ,→ treat-any Relevance Instructions 224 Preprint. Under review. 1. Notes on chief complaints: Note that the chief complaints may not be literally specified in the patient vignettes (in some cases the chief complaints are indeed documented as the main diagnosis; note to discern between these two cases) -- so you may have to infer from the patient note what the chief complaint of the patient would be. Only infer a specific diagnosis as the chief complaint if the note clearly supports that diagnosis as present now. ,→ ,→ ,→ ,→ 2. Notes on subcohorts of a clinical trial: A given clinical trial may enroll multiple subcohorts of patients (e.g., therapeutic vs control groups). The eligibility requirements for the subcohorts are connected by disjunctive (OR) logic. It may be the case that only one or a few subcohorts are relevant to the patient. Therefore, we want to be fine-grained in identifying which subcohorts are relevant and which subcohorts are not. ,→ ,→ ,→ 3. Do not invent your definition of relevance. Stick to the definition in the DEFINITION OF RELEVANCE section below.,→ 4. Notes on output formats: in the output (see OUTPUT FORMAT), you should return a JSON array where each item is a relevant (to the patient) subcohort from the clinical trial. If there is no relevant subcohort, return an empty list (i.e., []). For each subcohort you identify as relevant, give the subcohort a name in "subcohort_name", describe what this subcohort is in "subcohort_description" such that later we can clearly know which subcohort of the trial you are referring to without guessing, and explain why this subcohort is relevant in "why_relevant" which should be based on DEFINITION OF RELEVANCE. ,→ ,→ ,→ ,→ ,→ 5. Do not assume procedures, devices, or care pathways that are not stated. 6. Only infer a patient conditions as the chief complaint if the note clearly supports that diagnosis as present now.,→ relevant-to-any Relevance Definition A clinical trial is deemed relevant to the patient if it is meaningfully and clinically related to / targets any complaint of the patient that the patient may deliberately search clinical trials for and current already has (do not infer into the future). ,→ ,→ Note: - A trial is relevant only if the patient note supports that the patient currently has, or is currently being evaluated/managed for, the same disease, syndrome, or clinical problem that the trial targets.,→ - Relevance must be based on the trialâĂŹs underlying clinical target, not merely on overlap in one or more symptoms, care setting, urgency, organ system, diagnostic pathway, or inclusion-screening features.,→ - If the trial targets a specific suspected diagnosis or clinical syndrome, do not mark it relevant unless that diagnosis/syndrome is supported as a current clinical problem in the patient note.,→ - When the patient note is nonspecific and compatible with many etiologies, do not upgrade the patient to a more specific target condition based only on a trialâĂŹs inclusion examples.,→ relevant-to-any Relevance Instructions 1. Notes on chief complaints: Note that the chief complaints may not be literally specified in the patient vignettes (in some cases the chief complaints are indeed documented as the main diagnosis; note to discern between these two cases) -- so you may have to infer from the patient note what the chief complaint of the patient would be. Only infer a specific diagnosis as the chief complaint if the note clearly supports that diagnosis as present now. ,→ ,→ ,→ ,→ 3. Do not invent your definition of relevance. Stick to the definition in the DEFINITION OF RELEVANCE section below.,→ 4. Notes on output formats: in the output (see OUTPUT FORMAT), you should return a JSON array where each item is a relevant (to the patient) subcohort from the clinical trial. If there is no relevant subcohort, return an empty list (i.e., []). For each subcohort you identify as relevant, give the subcohort a name in "subcohort_name", describe what this subcohort is in "subcohort_description" such that later we can clearly know which subcohort of the trial you are referring to without guessing, and explain why this subcohort is relevant in "why_relevant" which should be based on DEFINITION OF RELEVANCE. ,→ ,→ ,→ ,→ ,→ 5. Do not assume procedures, devices, or care pathways that are not stated. 6. Only infer a patient conditions as the chief complaint if the note clearly supports that diagnosis as present now.,→ F.5.2 LLM Eligibility Evaluator Purpose.This prompt serves as the LLM-based eligibility evaluator for patient–trial match- ing. Given a patient note, a trial description, and specific trial subcohorts of interest, it deter- mines subcohort-level eligibility by applying a detailed set of clinical inference, missingness, and projection rules to the patientâ ̆ A ́ Zs current and past clinical state, and returns concise clinician-facing justifications for each decision. # == ROLE == You are an expert clinician. # == TASK == Your task is to decide if the eligible to (some specific subcohorts) of a clinical trial based on the following eligibility guidelines.,→ # == INSTRUCTIONS == 1. Note that you are specifically only asked to evaluate eligibility of the patient towards the subcohorts of clinical trials listed in <subcohorts_of_interest>, and you should evaluate the eligibility of the patient on a fine-grained, subcohort-by-subcohort basis. You can identify what subcohorts we are referring to with "subcohort_name" and "subcohort_description". ,→ ,→ ,→ 225 Preprint. Under review. 2. In the output, write eligibility decisions by a subcohort-by-subcohort basis, with the subcohort set and sequence being the same as in the <subcohorts_of_interest> block of input. For each such subcohort, copy over "subcohort_name" and "subcohort_description" from the input block, and output if the patient is eligible to this subcohort in "eligibility_decision" and the underlying rationale in "eligibility_reason". ,→ ,→ ,→ 3. Stick to ELIGIBILITY GUIDELINES below! Do not invent your own eligibility assumptions. ///////////// START: OVERARCHING MATCHING GUIDELINES ///////////// # === Use of Clinical Inferences === You should use clinical inferences for requirement checking (both inclusion and exclusion requirements). The patient notes (prescreen vignettes) may not explicitly contain some patient facts, and you have to use clinical inference for deriving these facts. You should be imposing the same inference strength (i.e., the threshold beyond which an inference is reasonable) for both inclusion and exclusion criteria. However, do not infer high-acuity patient complaints or states from nonspecific severity signs alone. ,→ ,→ ,→ ,→ # === On Inferring Into the Future === This section concerns inferring into the future. You should not derive facts that require change of patient states in the future.,→ On the other hand, you should always assume that any atomic requirement that requires only some logistical actions in addition to the current patient state is satisfied or can be satisfied. This includes both (1) atomic requirements that are completely requirements on logistical actions and (2) atomic requirements that are some combination of logistical actions and some requirements on the patient state which the patient note already satisfies. ,→ ,→ ,→ ,→ # Note on procedure requirements #: If a requirement asks for the patient to have already undergone or to be already undergoing some procedure and this requirement is substantive and can not be made up later, then do not assume this requirement can be satisfied and please refer to or infer from the patient note -- these are concrete eligibility requirements. ,→ ,→ ,→ If a requirement asks for the patient to be able or willing to undergo some procedure, then assume this requirement can be satisfied unless there is or can be inferred to be contraindication towards this procedure. ,→ ,→ # === Only Evaluate the Projection of the Eligibility Criteria onto the Current Patient State === You should only care about requirements that are the eligibility criteria's projection onto the current and past patient state, which includes is the space formed by the patient's medical state (which includes both medical events related to this patient and the patient's physical state - confirmed or inferred as per the clinical inference section) and time (anything that has happened up until and including now). Dimensions that will be projected away include evidence strength (e.g., documented/confirmed/noted/assessed) and criteria of determination (e.g., GOLD standard for COPD). For disease-state variables, wording such as "has diagnosis of X" should be interpreted as the patient clinically having X now, not as requiring the note to explicitly state the diagnostic label. After projecting away diagnosis/documentation wording, apply inference and missingness to the underlying disease state itself. Do not set such variables to false solely because the note does not explicitly name the diagnosis. ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ # === Project Away Operational / Administrative Framing === When a variable primarily reflects study operations, administrative cohort construction, healthcare-record structure, or timing defined relative to study events rather than the patient's substantive current or past clinical state, project away the operational framing; assign null only if, after that projection, no clinically meaningful current/past patient-state proposition remains, but if a substantive result/outcome/state remains, can be evaluated from the vignette, and must be known at prescreen time (not something that can be made up later), evaluate that remaining proposition under the ordinary support, inference, and missingness rules. ,→ ,→ ,→ ,→ ,→ Examples include care setting, hospitalization status, visit intent, continuous enrollment, index-event definitions, intake/pre-index/treatment-assessment windows, prescription-claim structure, same-day claims, and similar operational framing. ,→ ,→ Keep a variable in scope only if, after removing the administrative or study-operational framing, it still clearly expresses a substantive patient-state fact.,→ Do not fail a disease-state variable solely because the note lacks formal documentation wording, named diagnostic labeling, or explicit staging / scoring / classification / determination language.,→ # === Addressing Missing Information ==== This section concerns how you should handle information missingness in the patient notes. Particularly, this section enforces guidelines on how you should assign default values to atomic requirements.,→ Note the patient notes you are given are short prescreen vignettes. These patient notes usually mention significant patient facts if such patient facts are present, explicating what are positive/present but not what are negative/absent. However, if we only use explicitly positive facts for requirement checking, too many requirements will be trivially satisfied. Hence, if a significant patient fact is not supported anywhere (i.e., absent/negative), we must let the corresponding atomic requirement that concerns it fall back to default values through commonsense reasoning. ,→ ,→ ,→ ,→ ,→ You should assign values to different atomic requirements through different mechanisms. - If an atomic requirement would most likely be mentioned or inferred whenever it is satisfied, then you should assign false as the atomic requirement's value upon the absence of satisfaction of the atomic requirement from the patient note. ,→ ,→ 226 Preprint. Under review. - If an atomic requirement would most likely be mentioned or inferred whenever it is contradicted, then you should assign true as the atomic requirement's value upon the absence of satisfaction of the atomic requirement from the patient note. ,→ ,→ - If there is no explicit support or contradiction to an atomic requirement, but you - by clinical judgement - can confidently rule out the clinical possibility the patient satisfying the atomic requirement, set the requirement to false. ,→ ,→ - If an atomic requirement belows to none of the above three categories, then you should assign null as the atomic requirement's value upon the absence of satisfaction of the atomic requirement from the patient note. ,→ ,→ Note that don't apply missingness policies to formal documentation wording, named diagnostic labeling, or explicit staging / scoring / classification / determination language. Assume that the guidelines / confirmations / stagings can always be done later (with logistical actions) and thus shouldn't be any meaningful criteria or parts of criteria. ,→ ,→ ,→ >>> Addressing information incompleteness for numerical variables<<< the same guideline generalizes to numerical variables, if there is a strong reason to assign default values to numerical variables, following the same line of thinking. ,→ ,→ Prescreening precision rule for threshold helpers: - If a threshold helper corresponds to a major trial-defining gate condition and that thresholded condition would likely be mentioned or inferable if satisfied, then unsupported-from-silence should usually be mapped to false rather than null. ,→ ,→ # === Addressing the Case in which the Patient Only Partially Satisfies an Atomic Requirements === There may be cases under which an atomic requirement is only satisfied partially, either explicitly or through clinical inference. In other words, we need to confirm that the patient satisfies some extra information / qualification to really be sure that the patient satisfies requirement wholly. That said, missing such information / qualification does not necessarily mean that the patient fails this criteria; rather, it may just be the case that some details are to be determined. ,→ ,→ ,→ ,→ To handle such cases, we would love to have you apply clinical judgements again. That is, we would love to have you decide - as an expert clinician in the specific subject concerned - if you would still love to consider the patient as potentially able to satisfy the partially satisfied requirements, pending further determination. (Scenario P.A) If yes, don't fail the patient because of this requirement. (Scenario P.B) If you decide - as per your clinical judgements - that the required further determination is unlikely to translate to satisfaction of the atomic requirement (i.e., you are able to confidently rule out the clinical possibility of the patient satisfying the pending partial requirement), then you should perceive this atomic requirement as not satisfied. ,→ ,→ ,→ ,→ ,→ ,→ ,→ # === Don't Cares === 1. Stick to the verbatim inclusion and exclusion criteria sections for this analysis. Requirements on geographical locations should never be considered, even when they are explicitly mentioned.,→ 2. Again, requirements that necessitate logistics or some single-off actions only should never be considered (always satisfied).,→ 3. Requirements on care settings and existing enrollments in clinical trials should never be considered. 4. Do not consider any requirement that is impossible to evaluate when only given prescreen patient vignettes. 5. If a requirement does not add any meaning (i.e., additional constraints) to the set of eligibility requirements, ignore it.,→ 6. Hospitalization, care settings, and patient intent for visit should not be considered. ///////////// END: OVERARCHING MATCHING GUIDELINES ///////////// # === Output format === First, provide a free-text clinical reasoning block summarizing how you arrived at the eligibility decision. Then, list all relevant subcohorts and rate the patientâĂŹs eligibility towards each relevant subcohort. Return <subcohort_eligibility_decisions>.,→ Requirements: - The reasoning block should be plain free text, not JSON. - The reasoning block should briefly discuss the key inclusion and exclusion considerations, important inferences, and the main reason the patient is eligible or ineligible.,→ - The final JSON must remain concise and machine-readable. - In the JSON block, "explanation" should be a clinician-facing explanation of about 3âĂŞ6 sentences summarizing the key inclusion considerations, key exclusion considerations, important inferences, and the main basis for the final decision. ,→ ,→ - Output exactly these two blocks in this order: <reasoning> ...your free-text reasoning here... </reasoning> <subcohort_eligibility_decisions> [ "subcohort_name": "name it", "subcohort_description": "describe it ", "eligibility_decision": "eligible/ineligible", 227 Preprint. Under review. "eligibility_reason": "...", , "subcohort_name": "name it", "subcohort_description": "describe it ", "eligibility_decision": "eligible/ineligible", "eligibility_reason": "...", , ] </subcohort_eligibility_decisions> # == INPUTS == <patient_note> #PATIENT_NOTE# </patient_note> <trial_description> #TRIAL_DESCRIPTION# </trial_description> <subcohorts_of_interest> #SUBCOHORTS_OF_INTEREST# </subcohorts_of_interest> 228