STROBE-RDS (STROBE Extension for Respondent-Driven Sampling)

What it is

— STROBE-RDS (Strengthening the Reporting of Observational Studies in Epidemiology for Respondent-Driven Sampling) is a 2015 reporting-guideline extension of the parent STROBE statement, published by White, Hakim, Salganik and colleagues in the Journal of Clinical Epidemiology. It supplies STROBE's 22-item core checklist with RDS-specific reporting items so that a study using respondent-driven sampling — a chain-referral, coupon-based recruitment method for hidden or hard-to-reach populations (people who inject drugs, men who have sex with men, female sex workers, undocumented migrants) — can be read, appraised, and reproduced. RDS is not a convenience sample dressed up: it recruits in waves from a small set of seeds, tracks who recruited whom via coupons, measures each participant's network/degree size, and then re-weights the resulting sample with an RDS estimator (RDS-I, RDS-II, or Successive-Sampling/SS) to approximate a probability-based prevalence estimate. STROBE-RDS exists because none of that machinery — and the strong assumptions it rests on — is visible in a generic STROBE report. Like other STROBE extensions it is hosted within the EQUATOR Network and is a reporting checklist, not a design or analysis recipe.

When to use

— Apply STROBE-RDS whenever the sampling mechanism is respondent-driven: the study starts from seeds, recruits through peer-distributed coupons, records recruitment chains, and uses an RDS estimator to produce population-level prevalence, behavioral, or biomarker estimates. This is the correct checklist for an RDS-based HIV/HCV bio-behavioral surveillance study reported in a peer-reviewed journal, for the prevalence inputs to a global-health or disease-burden model, and for any cross-sectional survey of a hidden population where the recruitment is network-driven rather than frame-based. Decision rule: choose STROBE-RDS over plain STROBE only when recruitment is respondent-driven; a venue-based (TLS) or facility sample of the same population uses STROBE (or the relevant STROBE extension for the design), not STROBE-RDS. STROBE-RDS governs reporting — it is used alongside, not instead of, the survey protocol and the statistical analysis plan that pre-specify the estimator and weighting scheme.

What it requires

— On top of STROBE's core items (title/abstract, background, objectives, eligibility, variables, data sources/measurement, bias, study size, statistical methods, descriptive and outcome data, limitations, generalizability, funding), STROBE-RDS enforces the RDS-specific reporting that determines whether the estimates can be believed: (1) formative assessment and the rationale for choosing RDS for this population; (2) seed selection — how many seeds, how chosen, and their characteristics, because seed dependence is the dominant threat to RDS validity; (3) coupon management — number of coupons per recruit, coupon tracking, and the recruitment incentive structure; (4) recruitment-chain / wave structure — depth and breadth of the trees, number of waves reached, and convergence behavior; (5) network/degree-size measurement — the exact personal-network-size question used (it feeds RDS-II/SS weights directly); (6) diagnostics — equilibrium (whether the sample composition stabilized across waves), homophily (in-group recruitment tendency), bottlenecks, and recruitment-tree visualization; (7) estimator and weighting — which RDS estimator was used (RDS-I/RDS-II/SS), the assumptions invoked (random recruitment, accurate degree report, with-replacement vs finite-population correction), and the software; (8) uncertainty and design effect — confidence intervals computed with an RDS-appropriate method (bootstrap that respects the tree structure) and the design effect versus simple random sampling; and (9) sensitivity analyses to seed choice, degree-measurement error, and recruitment-bias assumptions. Framed in RWE terms, the burden is fitness-for-purpose of a non-probability sample: design transparency (the recruitment process), the estimand (a population prevalence/proportion), selection and weighting (the RDS estimator is the confounding/selection control), and quantitative sensitivity analysis to the assumptions the weights depend on.

When NOT to use — limitations and common misapplications

— (1) It is not for standard claims/EHR/registry HEOR RWE. A retrospective cohort or comparative-effectiveness study in administrative claims, EHR, or a disease registry uses STROBE, RECORD, RECORD-PE, or HARPER — never STROBE-RDS, which has no items for those data and omits everything those guidelines require (database provenance, code lists, phenotype validation, time-zero alignment, confounding by indication). (2) It is not for non-RDS samples. Using STROBE-RDS for a venue-based, facility-based, or probability survey misreports the design; conversely, reporting an RDS study with plain STROBE hides the seeds, coupons, network-size question, equilibrium and homophily diagnostics, and the estimator — the canonical misapplication the extension was written to prevent. (3) It is a reporting checklist, not a risk-of-bias instrument or a quality score. A fully STROBE-RDS-compliant paper can still rest on a biased sample: complete reporting of seed dependence, failure to reach equilibrium, or inaccurate degree reports documents the problem, it does not fix it. (4) Completing the checklist does not make the estimate population-representative or causal. RDS approximates a probability sample only when its assumptions hold; the checklist forces those assumptions into the open so reviewers can judge them. (5) Checklist-as-theater — ticking items while leaving the network-size question, equilibrium diagnostics, or the estimator choice vague defeats the purpose; the value is the substantive disclosure, not the page count.

How it maps to this catalog

— STROBE-RDS sits with the cross-sectional, prevalence-estimation corner of this repo, not the comparative-effectiveness corner: - The study type it reports: cross-sectional. - The estimand it targets: prevalence-point-period-annual-rwe — RDS exists to produce a population prevalence/proportion, and the checklist's estimator/weighting items are how that estimand is made defensible from a non-probability sample. - The selection-and-weighting machinery: selection-bias-sensitivity-analysis-rwe — RDS-II/SS weighting and the required seed/degree/recruitment-bias sensitivity analyses are precisely quantitative bias/selection analysis applied to a chain-referral sample. - External validity: generalizability-transportability-external-validity-rwe — seed dependence and failure to reach equilibrium are external-validity threats the checklist forces a study to confront. - The pre-specification spine: picots-framework-rwe (the population/outcome/setting frame the formative assessment must declare) and database-feasibility-attrition-funnel-rwe as the RWE analog of RDS formative assessment and recruitment accounting (seeds → coupons issued → coupons returned → eligible → analyzed).

Applied note (RDS operational depth, with the HEOR caveat)

For an RDS HIV/HCV bio-behavioral surveillance study, the reportable operational chain is: justify RDS in formative work; document seed count and selection; fix coupons-per-recruit and track the recruitment tree; ask a validated personal-network-size question; assess equilibrium across waves and homophily before trusting any estimate; report the chosen estimator (RDS-II or Successive-Sampling), its assumptions, and the software; compute CIs with a tree-aware bootstrap and report the design effect; and run sensitivity analyses to seed choice and degree misreport. The one-line HEOR caveat that belongs in any catalog cross-walk: if your real-world study draws on claims, EHR, or a registry, STROBE-RDS is the wrong tool — use STROBE/RECORD/RECORD-PE/HARPER; STROBE-RDS is reserved for studies whose sampling is respondent-driven.