Having conducted a detailed analysis of my team's monthly Elicit usage, I've identified a significant bottleneck in our systematic review workflows: the management of exclusion criteria. The current method of adding exclusion terms to the search query feels analogous to managing AWS Reserved Instances with a spreadsheet—necessary but cumbersome, lacking the granular control and audit trail required for reproducible, large-scale research.
My primary concern is the lack of a structured, persistent, and reviewable layer for exclusion logic. When we run a search for "effects of mindfulness on anxiety," we might iteratively add exclusion terms like `-child* -adolescent -cancer -review -meta-analysis`. This approach presents several operational inefficiencies:
* **Reproducibility Risk:** The exclusion string is buried within the search query. If a colleague revisits the search weeks later, the rationale for each exclusion is not documented alongside the term.
* **Lack of Hierarchy:** There is no way to categorize exclusions (e.g., Population, Intervention, Study Design) or indicate if a term is a mandatory exclusion versus a tentative filter for later screening.
* **Iterative Workflow Friction:** To test the impact of removing or modifying a single exclusion criterion, one must manually edit the query string and re-run the search, rather than toggling a rule on/off.
In a cost-optimized cloud architecture, we tag resources and define clear policies. I propose a similar framework for Elicit: a dedicated "Exclusion Criteria" panel that operates as a separate layer from the primary search semantics. This panel could allow for:
1. **Structured Rule Entry:**
```yaml
Criterion: Exclude by Study Population
Terms: [pediatric, adolescent, child, teenager]
Field: Title/Abstract
Status: Active | Inactive
Notes: Added 2024-05-15; Focus on adult populations per protocol.
```
2. **Impact Analytics:** A summary showing how many papers were excluded by each active criterion, providing immediate insight into the selectivity of each rule.
3. **Versioning:** The ability to save named exclusion profiles (e.g., "Adult Clinical Trial Filter") and apply them to new searches, ensuring consistency across related projects.
Without this, managing complex, protocol-driven reviews requires external documentation and manual query reconstruction, which introduces error and reduces the platform's efficiency gains. Has anyone else formalized a workaround for this, perhaps using the API to manage query strings programmatically? I am interested in comparing workflows to quantify the potential time savings a native feature would provide.
-cc
every dollar counts
Totally get what you're saying about the buried exclusion string. We run into similar issues with A/B test filters, where you need to document why a certain user segment was excluded. That audit trail is crucial.
Have you tried using a separate "exclusion log" document, even a simple shared sheet, to track the rationale for each term? It's a manual band-aid, but it creates that persistent layer you mentioned. You could tag each term with a category and a confidence level. It's extra work upfront, but saves headaches during peer review.
The lack of hierarchy really is the killer. Makes me wonder if building a simple tagging system outside the tool, then importing a consolidated block of terms, would add any efficiency.
✌️