---
title: 'Submitted-Trial Loop: Iterative Trial Matching'
url: https://www.emergentmind.com/topics/submitted-trial-loop
type: topic
---

# Submitted-Trial Loop: Iterative Trial Matching

Submitted-Trial Loop denotes an iterative workflow for patient–clinical trial matching in which eligibility is treated as a dynamic, reviewable state rather than a one-shot automated verdict. In the proof-of-concept system that most explicitly articulates the concept, patient data are ingested from the EHR, candidate trials are broadly retrieved, each patient–trial pair is evaluated by a locally deployed reasoning-enabled large language model, the results are packaged for expert review, and cases that are not immediately enrollable are retained as interpretable states such as “Could Be Eligible in Future” or “Need More Information,” together with next-step recommendations. The central significance of this formulation is that it reframes trial matching from static classification into an iterative operational process [2512.08026].

## 1. Definition and conceptual basis

The Submitted-Trial Loop arises from a specific critique of conventional clinical trial screening. The underlying paper describes the traditional workflow as manual, slow, and dependent on specialized coordinator expertise: staff search trial registries, often through keyword search in ClinicalTrials.gov, and then manually compare complex inclusion and exclusion criteria against fragmented patient records combining structured fields and unstructured notes. Two bottlenecks are emphasized. First, trial discovery is difficult because registry search depends on carefully chosen terms and lacks semantic similarity support, so equivalent disease descriptions may fail to retrieve the right studies. Second, eligibility adjudication is burdensome because EHR evidence is heterogeneous, incomplete, and clinically nuanced. The resulting delays narrow matching efforts and create missed opportunities for both patients and trial recruitment [2512.08026].

Within that setting, the Submitted-Trial Loop is the paper’s operational answer to the observation that many patients are neither clearly eligible nor permanently excluded at first pass. Instead of collapsing each patient–trial pair into a binary label, the workflow preserves contingent opportunities, surfaces missing evidence, and supports later reconsideration. The loop is therefore not a philosophical reformulation of eligibility; it is an operational design in which screening, expert review, follow-up action, status update, and rematching become repeated cycles [2512.08026].

## 2. Pipeline architecture

The architecture is described as a four-step pipeline. First, heterogeneous EHR data are ingested and processed by a Patient Information Extraction template using DeepSeek, a reasoning-enabled open-source LLM, with prompts rendered through Jinja2. Initial experiments used synthetic patient records deliberately constructed to resemble real EHR variability, including missing fields, free text, tables, and PDF-style layouts, especially for genomic reports. A dedicated parsing module acts as preprocessing to normalize these varying formats before LLM extraction. The output is a structured patient report spanning 14 clinical categories: Primary Diagnosis, Base Diagnosis, Diagnosis Synonyms, Patient Demographics, Current Interventions, Treatment History, Search Terms, Biomarkers / Molecular Profile, Performance Status, Laboratory Values, Comorbidities, Family History, Treatment Goals, and Eligibility Factors [2512.08026].

Second, the structured patient report drives candidate retrieval from the ClinicalTrials.gov REST API. The retrieval strategy is explicitly multi-pass and recall-oriented. The system does not rely on a single narrow diagnosis string; it first queries the exact primary diagnosis, then broader diagnosis terminology and diagnosis synonyms, while constraining by recruiting status, age, sex, and default geography within the United States. Results from multiple API calls are consolidated, deduplicated, and stored trial-by-trial as structured JSON objects containing metadata such as `NCT_ID` and `Trial_Title` together with protocol fields including description, inclusion criteria, and exclusion criteria. In the proof-of-concept run on 30 synthetic EHRs, candidate retrieval averaged 950 trials per patient, which the authors describe as roughly a tenfold increase after synonym-based expansion [2512.08026].

Third, each patient is evaluated against each candidate trial by a second templated LLM prompt, the Patient-Trial Eligibility Evaluator. This template operationalizes review in three sections: minimum eligibility criteria, inclusion criteria, and exclusion criteria. The model is instructed to confirm demographic prerequisites, compare the broader clinical profile against inclusion rules, assess exclusion conditions separately, and produce supporting reasoning, certainty based on data completeness and clarity, and explicit identification of information gaps. Fourth, the system transforms the raw JSON output into Word and PDF reports organized in a hierarchical documentation style. Each report includes metadata such as assessment date, `trial_ID`, `patient_ID`, and `assessor_information`, meaning which model and which template version were used. This structure is presented as essential for auditability and workflow interpretability [2512.08026].

## 3. Dynamic eligibility states and resubmission logic

The mechanism that makes the workflow a loop is its four-state output schema. Rather than reducing a patient–trial pair to an irreversible yes/no determination, the system aggregates criterion-level reasoning into one of four overall states [2512.08026].

| State | Operational meaning |
|---|---|
| “Eligible Now” | Key criteria are met |
| “Could Be Eligible in Future” | Current deficits are temporal or remediable |
| “Not Eligible” | Key criteria fail |
| “Need More Information” | Decisive data are absent or ambiguous |

“Could Be Eligible in Future” captures cases where protocol prerequisites are not yet met but may become satisfied with time, treatment completion, additional tests, or clarification of uncertain findings. “Need More Information” captures unresolved cases where missing evidence prevents a confident conclusion. These states preserve candidate trials that would otherwise be lost in a reject-only workflow and convert trial matching into a resubmission process [2512.08026].

The paper’s pancreatic adenocarcinoma example illustrates the logic. A synthetic patient was assessed against trial NCT05764720. The model recognized that the patient had completed only one two-week cycle of FOLFIRINOX, while the trial required at least two months of chemotherapy. Rather than assign “Not Eligible,” the system returned “Could Be Eligible in Future” with medium confidence. It also identified unresolved items including imaging confirmation, the ability to interrupt systemic therapy, and breath-hold capability, and it generated corresponding follow-up recommendations: complete chemotherapy, verify therapy interruption feasibility, obtain imaging, and test breath-hold capacity. In loop form, such outputs become triggers for future rematching after the patient’s status changes [2512.08026].

## 4. Interpretability, human review, and deployment constraints

Interpretability is implemented at both model and output levels. DeepSeek is described as an open-source reasoning-capable model with a 128,000-token context window and intermediate reasoning steps in `<think>` tags. In this system, that capability is used to articulate how specific patient characteristics support or violate specific trial criteria. The structured JSON schema shown in the paper includes fields such as `"eligibility_summary"`, `"eligibility_status"`, `"confidence_level"`, `"primary_criteria_assessment"`, `"clinical_criteria_assessment"`, `"exclusion_criteria_assessment"`, `"actionable_recommendations"`, and `"missing_data_points"`. Criterion-level sub-assessments include a `name` or `criterion`, a `status`, and a `reasoning` string, allowing reviewers to inspect the logic beyond the final verdict [2512.08026].

Human-in-the-loop review is the intended operating mode, not a fallback. The system narrows and structures the matching problem, but clinicians and coordinators remain responsible for validating matches, resolving ambiguities, and deciding whether to pursue a study. High-certainty matches can be verified efficiently, while “Need More Information” and “Could Be Eligible in Future” cases direct expert attention to missing tests, unresolved protocol nuances, or opportunities for later reevaluation. Subject matter experts were involved in designing both templates, including the extracted variables and the interpretation of trial criteria. Future work identified in the paper includes explicit source citation down to report date and page number, a web-based interface for expert review, and systematic capture of reviewer feedback that could eventually be used for reinforcement learning [2512.08026].

Security, privacy, and auditability are treated as core deployment constraints. The paper explicitly rejects dependence on externally hosted commercial LLMs for PHI-bearing workflows because HIPAA compliance cannot be guaranteed in that setting. Instead, the system uses open-source models deployed locally on institutionally approved infrastructure within a NIST-compliant data center, with strict data-use controls and containerized deployment. Auditability is supported through structured outputs, report generation, and metadata capture, and the paper emphasizes “comprehensive auditability of all AI-generated outputs” as a design goal [2512.08026].

## 5. Empirical behavior, scalability, and limitations

The evaluation is a proof-of-concept on synthetic EHRs rather than a clinical validation study. Across 30 synthetic patient records, the system produced 28,575 patient–trial evaluations. Of these, 25,192, or 88%, were labeled “Not Eligible,” which the authors interpret as clinically plausible because most trials do not fit most patients and trial availability is uneven across disease types. Sixteen of the 30 patient personas received at least one “Eligible Now” trial. The paper also gives two scale examples: a synthetic Hodgkin lymphoma patient was evaluated against over 5,000 candidate trials and yielded eight matches, whereas a synthetic patient with adenoid cystic carcinoma of the salivary gland was reviewed against nearly 800 trials and yielded one match [2512.08026].

Scalability is supported by modular orchestration and multithreaded execution. Intermediate and final structured data are represented in JSON, post-processing and report generation are handled with Python scripts, and the main orchestration is described as an overarching `run_pipeline` script. The authors justify multithreading on the grounds that LLM pipelines are inference-latency bound, so concurrent completions improve throughput. The architecture is also intentionally modular: the extraction template can be extended with new data elements, retrieval can search the full registry or evaluate a pre-identified trial list, and the eligibility template can be adjusted for stricter or more permissive reasoning modes [2512.08026].

The limitations are equally explicit. The system has only been evaluated on synthetic data. Source-level traceability is incomplete because extracted facts are not yet explicitly linked back to precise source locations. There is not yet a dedicated web interface for natural expert review and correction. Retrieval still depends on handcrafted search-expansion logic because the underlying registry lacks semantic search. Broad retrieval also increases downstream computational burden, and any LLM-based system may misread clinical nuance, especially in ambiguous or incomplete records. For those reasons, the paper insists on human review and conservative recommendation categories [2512.08026].

## 6. Related loop formulations in adjacent trial informatics

Although the Submitted-Trial Loop is most explicitly articulated in AI-assisted patient–trial matching, related loop structures appear elsewhere in the clinical-trial informatics literature. “CliniDigest” maps naturally onto a submitted-trial monitoring loop in which newly registered ClinicalTrials.gov studies are repeatedly batched, recursively summarized, and surfaced for ongoing review; its reported implementation is a batch summarization method rather than a specified streaming architecture [2307.14522]. This suggests a complementary loop focused on surveillance of incoming trials rather than matching patients to them.

A different but related layer is evidence verification. The NLI4CT shared task formalizes claim adjudication over clinical trial reports as linked tasks of evidence selection and entailment, requiring multi-evidence biomedical and numerical reasoning. This suggests that a Submitted-Trial Loop can include not only retrieval and matching, but also fact-level verification of trial claims and supporting evidence [2305.02993].

Loop-based logic also appears in trial protocol control. “Dose-Escalation Trial Protocols that Extend Naturally to Admit Titration” models dose assignment as a monotone map from observed trial states to doses and uses a right Kan extension to convert rigid cohort rules into a rolling-enrollment workflow with pending outcomes and within-patient titration [2507.01370]. In another direction, “ClinicalReTrial” frames protocol redesign itself as a closed-loop, reward-driven optimization problem in which failed protocols are iteratively diagnosed, modified, safety-filtered, evaluated in a learned simulation environment, and resubmitted within a bounded search budget [2601.00290]. These adjacent formulations do not use the Submitted-Trial Loop label in the same way, but they show that loop-based trial workflows can govern monitoring, evidence adjudication, enrollment control, and protocol redesign as well as patient matching.

Taken together, these related systems suggest that the Submitted-Trial Loop is best understood not as a single software artifact but as an operational pattern: a trial-related object is submitted in a provisional state, evaluated against structured criteria, returned with interpretable status and actionable feedback, and then reconsidered after new evidence, new protocol state, or new data become available. In the primary patient-matching formulation, that object is the patient–trial pair itself, and the loop is driven by dynamic eligibility states rather than binary screening outcomes [2512.08026].

Source: https://www.emergentmind.com/topics/submitted-trial-loop