Add research workflow guide

README.md

@@ -1,3 +1,70 @@
-# search-strategy-peer-review
+# Peer Reviewing a Search Strategy: A Practical Guide to PRESS
 
-Peer reviewing literature search strategies with the PRESS guideline
+A literature review can only be as complete as its search. If the search strategy misses a key synonym, combines concepts with the wrong operator, or applies a filter that quietly removes relevant studies, no amount of careful screening downstream will recover what was never retrieved. That is why many review teams now ask a second information specialist or experienced searcher to peer review the strategy before it is run. The PRESS guideline, short for Peer Review of Electronic Search Strategies, gives that review a shared structure. This guide explains how PRESS works, what reviewers look for, and how to respond to feedback. It also notes where an AI research assistant such as [Yila](https://yila.ai) can support preparation, while the search design and its review remain expert human tasks.
+
+## Why peer review the search
+
+Errors in search strategies are common and often subtle. Studies of published reviews have found missing terms, misspelled words, incorrect line numbers in combined searches, unbalanced parentheses and subject headings that were not exploded when they should have been. Each of these can reduce recall without producing any visible warning. The database simply returns fewer records, and the team has no way of knowing what is missing.
+
+A peer reviewer reads the strategy with fresh eyes, much as a manuscript reviewer reads a paper. Because the reviewer did not build the search, they are less likely to share the author's blind spots. The cost is modest, usually an hour or two of expert time, and the benefit can be substantial.
+
+## The PRESS elements
+
+The PRESS guideline organizes review around six elements. A reviewer considers each one and records whether revision is needed.
+
+**1. Translation of the research question.** Does the search reflect the review question? Reviewers check that each key concept appears, that no concept has been added or dropped without reason, and that the number of concepts is appropriate. Including too many concepts with AND is a common cause of low recall.
+
+**2. Boolean and proximity operators.** Are AND, OR and NOT used correctly? Are parentheses balanced and nested as intended? NOT is particularly risky, because it can exclude relevant records that happen to mention the excluded term. Proximity operators should use sensible distances and the correct syntax for the database.
+
+**3. Subject headings.** Are controlled vocabulary terms such as MeSH or Emtree used where appropriate? Are they exploded when narrower terms are relevant? Are any headings missing, or too broad, or used with inappropriate subheadings? Reviewers also check that headings are valid in the database being searched, since vocabularies differ between databases.
+
+**4. Text word searching.** Are free text terms comprehensive? Do they include synonyms, spelling variants, abbreviations, and older terminology? Is truncation used correctly, without being so short that it retrieves irrelevant words? Are the right fields searched, typically title, abstract and author keywords?
+
+**5. Spelling, syntax and line numbers.** Are there typographical errors? Does the syntax match the platform? In line-by-line strategies, do the combination lines refer to the correct line numbers? This is the most mechanical check and also one of the most valuable, because a single wrong line number can silently drop an entire concept.
+
+**6. Limits and filters.** Are date, language, publication type or study design limits justified by the protocol? Are validated search filters used where filters are needed, and are they applied correctly? Unjustified language limits and poorly designed study design filters are common sources of bias.
+
+## How to request a review
+
+Send the reviewer the information they need to judge the strategy in context:
+
+- the review question and eligibility criteria;
+- the full strategy for the primary database, exactly as it will be run, with line numbers;
+- the database and platform names;
+- any known relevant studies that the search should retrieve;
+- the planned limits and the reason for each.
+
+A list of known relevant studies is especially useful. If the strategy fails to retrieve one of them, that is concrete evidence that something needs to change, and it points the reviewer towards the missing concept or term.
+
+## How to give a review
+
+Reviewers work through the six elements, noting for each whether no revision, a suggested revision, or a required revision is needed. Comments should be specific. "Add more synonyms" is less useful than "Consider adding caregiver*, carer* and family member* to the population concept." Where possible, reviewers test their suggestions in the database to see whether they change the number of results, and report the effect.
+
+Reviewers should also respect the author's judgment. Not every additional term is worth the extra noise it brings. A good review explains the likely benefit of each suggestion so the author can weigh it.
+
+## Responding to feedback
+
+Treat the review as a conversation. For each comment, either make the change or record why you did not. Re-test the strategy after revisions, and check again that the known relevant studies are retrieved. Keep both the original and revised strategies, together with the reviewer's comments, in the project record. Many journals and reporting guidelines now expect the methods section to state whether the search was peer reviewed, and PRISMA-S includes an item for it.
+
+## Translating to other databases
+
+PRESS review is usually done on the primary database strategy, often MEDLINE or a field-specific equivalent. The approved strategy is then translated to other databases. Translation introduces its own errors, especially in subject headings and field codes, so it is worth asking the reviewer to look at at least one translated version, or doing a careful self-check against the six elements.
+
+## Where tools help
+
+Several tools help with parts of this process. Syntax checkers catch unbalanced parentheses and invalid field codes. Translation tools convert strategies between platforms, though their output always needs checking. Text analysis tools can suggest candidate terms by mining the titles and abstracts of known relevant studies.
+
+AI research assistants can contribute at the preparation stage: brainstorming synonyms for a concept, explaining unfamiliar terminology in a neighbouring discipline, or summarizing the known relevant studies so that the reviewer can see quickly what the search needs to find. A tool like Yila fits this supporting role. Suggestions from any automated tool should be treated as candidates to evaluate, not as finished search terms, and the final strategy should be designed and reviewed by people who understand the databases.
+
+## A short checklist for authors
+
+1. Write the strategy line by line with numbered lines.
+2. Test it against a set of known relevant studies.
+3. Send the reviewer the question, criteria, strategy, platform and known studies.
+4. Respond to each comment and record decisions.
+5. Re-test after revisions and keep all versions.
+6. Report the peer review in the methods section.
+
+## Summary
+
+Search strategies are complex technical documents, and they benefit from review just as manuscripts do. The PRESS guideline offers a clear structure: question translation, operators, subject headings, text words, syntax and line numbers, and limits. Asking an experienced colleague to review the strategy against these elements is one of the most cost-effective steps a review team can take to improve completeness and reduce bias.