RECORD-NLP (anticipated RECORD extension for NLP-derived data)
An anticipated, not-yet-published extension of the RECORD reporting guideline intended to govern reporting of observational studies on routinely collected health data whose exposures, covariates, or outcomes are derived by natural language processing of clinical free text. No finalized checklist exists as of mid-2026; the defensible reporting stack today is RECORD/RECORD-PE plus algorithm-validation and NLP-specific practice reporting.
What it is
— RECORD-NLP denotes an anticipated extension of the RECORD statement (REporting of studies Conducted using Observational Routinely-collected health Data; Benchimol et al., 2015), aimed at observational/real-world-evidence (RWE) studies in which exposures, covariates, eligibility criteria, or outcomes are derived from natural language processing (NLP) of clinical free text (notes, discharge summaries, pathology and radiology reports). It would sit in the EQUATOR Network's STROBE→RECORD family, parallel to the published pharmacoepidemiology extension RECORD-PE (Langan et al., 2018). Critical status caveat: as of mid-2026 there is no finalized, published RECORD-NLP checklist. No consensus statement, no item list, and no EQUATOR-hosted maintained checklist exists under that name. The closest active, EQUATOR-registered effort for clinical-text NLP reporting is the CINEX guideline (Clinical Information EXtraction; development protocol Reichenpfader et al., 2025), and the most usable interim practice recommendations for NLP-assisted observational research are the Fu et al. (2023) scoping-review recommendations. This catalog entry is therefore a forward pointer and a reporting-stack recommendation, not a citation of an existing instrument: it tells you what to report now when NLP feeds an RWE study, and what guideline to watch for.
When to use
— Treat this entry as the lookup you reach for when a study using routinely collected health data depends on NLP to define any analytic variable — a phenotype, an outcome, a comorbidity covariate, a severity measure, or an eligibility flag — and you must report it for a peer-reviewed journal, an HTA/payer dossier, a regulatory (FDA/EMA, ENCePP) submission, or a registered protocol/PASS. Because the named checklist does not yet exist, the decision rule is a stacking rule rather than a single-instrument choice: (1) report the observational study itself against RECORD (or RECORD-PE if it is pharmacoepidemiologic); (2) report the NLP/algorithm-derived variables against the catalog's algorithm-validation and phenotyping concepts; (3) add the Fu (2023) NLP-specific practice items; and (4) if a machine-learning or large-language model produces the variable, add a model-reporting standard (TRIPOD+AI or MI-CLAIM) for the development and validation of that model. Use RECORD-NLP-as-a-pointer precisely when a reader or reviewer asks "which guideline covers the NLP part?" — the honest answer is "none is finalized; here is the stack that covers it."
What it requires
— Anticipated domains, by analogy to RECORD/RECORD-PE plus the documented NLP-specific gaps; these are not items from a published RECORD-NLP checklist and should be read as the substance such an extension would have to cover, not as an enforceable list. Beyond the generic RECORD items (data-source provenance, linkage, population/codes used, cleaning and flow), an NLP-aware reporting standard would compel: the corpus and text source (which document types, sections, time windows, and what fraction of the cohort had usable text — text availability is itself a selection mechanism); the NLP method (rule-based vs statistical vs transformer/LLM; model name, version, training data, and whether it was developed in-sample or ported from another institution); the annotation and reference standard (how gold-standard labels were created, annotator agreement, the chart-review sample); validation metrics with confidence intervals (PPV, sensitivity, specificity, F1) measured in the target population and time period, not borrowed from the model's origin study; error analysis and misclassification characterization, including whether errors are differential by arm, subgroup, site, or calendar time; drift and portability (performance decay over time and across institutions/EHR versions); and how NLP-derived measurement error was propagated into the analysis (quantitative bias analysis or sensitivity analyses). These layer onto the standard RWE requirements an extension would still inherit: time-zero alignment, estimands and intercurrent events, confounding control, and attrition/missing-data accounting.
When NOT to use — limitations and common misapplications
— (1) Do not cite "RECORD-NLP" as a completed checklist in any FDA/EMA/HTA/journal submission or protocol today; it does not exist as a finalized instrument, and claiming compliance with it is misrepresentation. Cite RECORD/RECORD-PE plus the NLP-specific stack instead, and, if you want a named NLP reporting effort, watch and reference CINEX. (2) A reporting checklist — actual or anticipated — is not a risk-of-bias instrument and not a quality score; completing items does not make an NLP-derived observational estimate valid, unconfounded, or causal. Bias in the included NLP study is judged with ROBINS-I and with the algorithm-validation evidence, not by a reporting tally. (3) Wrong guideline for the design: a primary RWE study without NLP needs RECORD/RECORD-PE, not an NLP extension; a systematic review of NLP-RWE studies needs PRISMA-P/PRISMA 2020; a trial uses CONSORT/SPIRIT. (4) Reporting-the-model is not reporting-the-study: TRIPOD+AI or MI-CLAIM describe how the NLP model was built and validated, but they do not cover the epidemiologic design that consumes its output — you need both. (5) Checklist-as-theater: stating "NLP was used to identify outcomes" with no corpus description, no in-sample validation metrics, and no error analysis is the exact gap these efforts exist to close; the value is the operational detail, not the sentence.
How it maps to this catalog
— Because the named checklist is not yet available, the substance of an NLP-aware RECORD extension is implemented today by concepts in this repo, which together form the recommended reporting stack: - The NLP/algorithm-derived variables — the core of what RECORD-NLP would add — map to ehr-phenotyping-algorithms-rwe (NLP and structured phenotype construction), outcome-algorithm-construction-rwe (building outcome definitions), algorithm-validation (the chart-review/reference-standard validation an NLP variable demands), claims-outcome-algorithm-ppv-sensitivity-rwe (PPV/sensitivity reporting and how misclassification biases estimates), and diagnosis-phenotype-algorithm-1ip-2op-time-window-rwe (the code/window logic an NLP signal is often blended with or compared against). - The inherited RWE-design requirements an extension would still enforce map to target-trial-emulation (design transparency and time-zero), active-comparator-new-user (confounding control and incident-user structure), estimands-ate-att-intercurrent-events-rwe (estimand and intercurrent-event specification), high-dimensional-propensity-score-hdps-rwe (confounding adjustment, including NLP-augmented covariates), and attrition-and-loss-to-follow-up-rwe (flow and missing data). - The data-substrate context maps to claims-analysis (and EHR linkage), where text availability and document capture govern whether an NLP variable can even be measured.
Applied note (claims/EHR/registry RWE)
NLP variables live almost entirely in EHR and linked claims–EHR substrates: claims carry codes but no free text, so an NLP-derived phenotype is only measurable for the subset with available notes, and that subset is differentially captured (sicker, more-engaged, single-institution patients). A defensible report therefore states what fraction of the analytic cohort had usable text, validates the NLP variable against a chart-reviewed gold standard in that cohort and calendar window (PPV and sensitivity with CIs), checks whether misclassification is differential across arms, and propagates the measurement error through a quantitative bias analysis — exactly the items a finalized RECORD-NLP would be expected to require, and exactly the items the algorithm-validation concepts in this catalog already operationalize.