STROCSS (Strengthening the Reporting of Cohort, Cross-Sectional and Case-Control Studies in Surgery)

What it is

— STROCSS (Strengthening the Reporting of Cohort, Cross-Sectional and Case-Control Studies in Surgery) is a surgery-specific reporting checklist for observational research. It is a domain extension of the generic STROBE statement, adapted by the STROCSS Group to capture items that matter when the exposure is a surgical procedure or technique: a clear description of the intervention/operative technique, surgeon experience and the learning curve, peri-operative and longer-term follow-up of operated patients, and registration of the study. STROCSS is maintained as a living guideline — the STROCSS 2024 statement (Rashid et al., International Journal of Surgery) is the current version, superseding STROCSS 2021 (Mathew et al.) and the earlier 2017/2019 iterations — and is indexed in the EQUATOR Network reporting-guideline library. Like all EQUATOR checklists, its job is transparency of reporting: it tells authors, peer reviewers, and readers the minimum that a surgical observational manuscript must disclose so the study can be appraised and, in principle, reproduced. It is not an Avalere/agency product and carries no regulatory mandate; its authority is editorial (journals require or recommend it).

When to use

— Apply STROCSS when you are reporting a completed observational surgical study — a cohort (prospective or retrospective), a cross-sectional study, or a case-control study — in which the exposure, comparison, or population is defined by a surgical intervention, operative approach, device implantation, or peri-operative pathway, and you are submitting to a surgical journal. Decision rule for picking the right member of the STROBE family: use plain STROBE for a general (non-surgical) observational study; use STROCSS when the study is surgical cohort/cross-sectional/case-control; use CARE for a single surgical case report and a case-series reporting tool for a case series (STROCSS covers analytic designs with a comparison or denominator, not pure case reports/series); use RECORD / RECORD-PE when the surgical cohort is built from routinely-collected health data (claims, EHR, registries) and pharmacoepidemiologic exposures, because those extensions add the data-provenance and code-list items STROCSS does not. STROCSS sits at the manuscript-reporting stage; it is not a protocol tool and not a risk-of-bias instrument.

What it requires

— STROCSS inherits the STROBE backbone (title/abstract; structured background, objectives, and hypotheses; design, setting, and dates; eligibility and selection of participants; clearly defined exposures, outcomes, predictors, and confounders; data sources and measurement; bias; study size; quantitative handling of variables; statistical methods including subgroup, missing-data, and sensitivity analyses; a participant-flow account; descriptive, outcome, and other analyses; key results; limitations; interpretation; generalizability; and funding) and layers on surgery-specific items: explicit registration of the study, a precise description of the intervention/operative technique sufficient for replication, surgeon/operator experience and learning-curve considerations, and follow-up of the operated population. Read through a real-world-data lens, the demanding items are the design-transparency and measurement items: an unambiguous time-zero/index definition (date of the index operation), how the surgical exposure and any comparator were ascertained, how outcomes were defined and validated, how confounding (including confounding by surgical indication and operator/center effects) was handled, and how attrition/loss to follow-up and missing data were reported. STROCSS asks you to state these things clearly; it does not tell you the analytic method to use — that is what the catalog concepts below supply.

When NOT to use — limitations and common misapplications

— STROCSS is a reporting checklist, and the most common errors come from treating it as something it is not. (1) It is not a risk-of-bias instrument and not a quality score. A fully STROCSS-compliant paper can still be badly confounded; appraise validity with ROBINS-I (or Newcastle-Ottawa / JBI tools), not with a STROCSS tick-list. (2) Completing the checklist does not make an observational study causal — transparent reporting of a biased comparison is still a biased comparison; STROCSS reports the design, it does not fix immortal time, selection on the operated, or confounding by indication. (3) Wrong family member — using generic STROBE where STROCSS is required (losing the surgical intervention/learning- curve items), or using STROCSS for a routinely-collected-data pharmacoepidemiology study where RECORD-PE is the appropriate STROBE extension (losing the database, code-list, and data-cleaning items). (4) Wrong design class — forcing STROCSS onto a case report or uncontrolled case series (use CARE / a case-series tool) or onto a randomized surgical trial (use CONSORT, not an observational-study checklist). (5) Checklist-as-theater — listing page numbers against 30-odd items while the operative technique, the index date, the comparator, or the loss-to-follow-up remain vague defeats the purpose; the value is the substance disclosed, not the completed grid.

How it maps to this catalog

— STROCSS states what must be reported; these catalog concepts implement each reporting requirement for surgical RWE built on claims/EHR/registry data: - Design transparency & time-zero: the index-operation date and aligned follow-up are operationalized by time-zero-index-date-alignment-rwe and, for a trial-grade comparison of surgical strategies, target-trial-emulation; a clean comparator/new-initiator structure is active-comparator-new-user. - Exposure & procedure ascertainment: identifying and dating the operation in routine data is procedure-identification-and-measurement-in-claims-ehr; building the analytic cohort and observable time uses continuous-enrollment-observable-time-rwe. - Outcome/phenotype definition & validation: the STROCSS outcome items map to diagnosis-phenotype-algorithm-1ip-2op-time-window-rwe and outcome-algorithm-construction-rwe, with validity quantified via claims-outcome-algorithm-ppv-sensitivity-rwe and algorithm-validation. - Confounding control: STROCSS asks you to report confounder handling; implement it with high-dimensional-propensity-score-hdps-rwe, propensity-score-methods-psm-iptw, and design-stage thinking via dags-backdoor-criterion-drug-studies. - Estimands & intercurrent events: making the surgical estimand explicit (and handling reoperation, crossover, death) is estimands-ate-att-intercurrent-events-rwe. - Attrition & missing data: the participant-flow and follow-up items map to attrition-and-loss-to-follow-up-rwe and database-feasibility-attrition-funnel-rwe. - Sensitivity / quantitative bias analysis: the limitations/sensitivity items are implemented by e-value-sensitivity-analysis and quantitative-bias-analysis-toolkit-rwe. - Underlying data substrate: claims-analysis for the claims-specific operational caveats.

Applied note (claims/EHR/registry RWE)

A retrospective cohort comparing two surgical approaches in administrative claims should, to satisfy STROCSS in substance and not just in form, define the index operation by procedure codes (CPT/ICD-10-PCS/HCPCS) with a dated time zero, require continuous enrollment across the baseline and follow-up windows so absence of prior events is observed rather than missing, validate the outcome phenotype (PPV/sensitivity) rather than asserting it, control confounding by surgical indication and center/operator volume with a propensity approach, pre-state the estimand and how reoperation/death are handled as intercurrent events, report the attrition funnel and loss to follow-up explicitly, and probe residual confounding with an E-value or negative-control analysis. STROCSS forces these disclosures; the catalog concepts above tell you how to do each one.