Data Sharing Throughout the Research Lifecycle

Well-documented workflows and consistent organization ensure transparency, continuity, and reproducibility. Undocumented workflows lead to confusion, errors, and hindered reproducibility.

Lessons learned: Inconsistent file structures, missing metadata, and undocumented processing increase the risk of errors and make it harder to track data provenance. Well-documented workflows enable validation, replication, and continuity, which supports compliance with the NIH DMS Policy’s emphasis on maximizing data sharing “of sufficient quality to validate and replicate the research findings.”

What to do:

• Document each step of data processing and analysis through SOPs, annotated code and clear file naming, so they can be understood, replicated, and validated.
• **Use version-controlled platforms (**GitHub, GitLab, or institutional equivalents) to track code, store it, and maintain reproducibility. Many data repositories version control deposited files.
• Leverage software tools that capture and support workflow transparency, such as Laboratory Information Management Systems (LIMSs), electronic lab notebooks, workflow management tools (like Jupyter or R Markdown), and version-controlled repositories.
• Refer to data type-specific guidance in resources like curation primers, scholarly articles, or data type-specific repository documentation.

Additional resources:

• NIH Pragmatic Trials Collaboratory Living Notebook
• Data Curation Network Data Curation Primers
• Turing Way Guide to Reproducible Research

Transparent interpretation of research findings depends on clearly stating the assumptions, decisions, and frameworks that shaped the analysis.

Lessons learned: Unrecorded choices about how to handle missing data, which variables to include, and model selection can lead to data misinterpretation, misuse, or reproducibility concerns. Secondary users risk drawing invalid conclusions without this context.

What to do:

• Document model selection criteria and explain the rationale for using a particular model (e.g., linear regression, mixed effects, logistic).
• Specify inclusion/exclusion criteria (e.g., age thresholds, incomplete records), how they were applied, and any exceptions.
• Explain treatment of missing data, whether they were excluded, imputed, or modeled, and how this may affect interpretability or generalizability.
• Define analytic timepoints, measurement intervals, and units of analysis. For example, "30-day follow-up visits were used to define primary outcome."
• Provide README files, inline code comments, or analysis notes/memos to capture assumptions for secondary users and reviewers.

Additional resource:

• Software supporting code annotation: R Markdown, Jupyter Notebook

Use version control to connect datasets, scripts, and outputs to specific analyses and published findings. Clearly labeled, well-structured outputs (e.g. tables, charts, graphs, and other visualizations) support reproducibility and interpretability across publications, presentations, posters, and other mediums. The same data may apply to multiple similar outputs; for example, analytic results may appear on a poster several months before a different version is published in a journal.

Lessons learned: HEAL studies must share both data and research outputs appropriately. Outputs that lack context or links to underlying data and code limit reproducibility. Overwriting code or modifying data without documenting changes also impedes reproducibility and validation, undermining trust in the findings. Because the same data may generate multiple outputs, the study team and secondary users must be able to distinguish which versions of data and code files produced an output. For example, if a dataset is cited in a journal article, the version in the repository should match the one used in the publication.

What to do:

• Use descriptive, consistent filenames and folder structures aligned with project phases or outputs**.** See “Organizing data…” under the Generate/Collect phase.
• Employ version control (like GitHub), committing changes with descriptive messages and using releases to differentiate versions. Or, keep a changelog describing changes, like added variables, updated exclusion criteria, or software updates.
• Include contextual metadata or a README with each output, noting the inputs, code / script used, file(s) containing associated VLMD, and other notes.
• Link published outputs to underlying data using persistent identifiers, such as DOIs.