Data Sharing Throughout the Research Lifecycle

Consistent data organization enables efficiency and collaboration for the study team and any future data re-users.

Lessons learned: Inconsistent file organization can lead to outdated or incorrect file use, hinder collaboration, and reduce reproducibility. Clear, consistent file and folder naming conventions, folder structures (e.g., organized by grant aim or data type), versioning, co-located metadata, and documentation explaining how the data was collected, processed, and structured make data easier to manage and use. Some data repositories require specific deposition structures; adopting these early will speed data sharing later.

What to do:

• Adopt file/folder naming and organization conventions. See MIT Libraries file organization guidance, and/or follow repository guidance.
• Define minimum documentation needs for each data asset, including data dictionaries (aka codebooks); data processing code, scripts, markdown files, and programs; README files; and blank data collection instruments.
• Store documentation with the data it describes. Include README files, data dictionaries, and version histories to support interpretation.
• Implement version control to prevent accidental data loss and improve traceability.

Data standards, including Common Data Elements (CDEs), improve interoperability and enable integration with similar datasets. The NIH HEAL Initiative requires pain clinical studies to use HEAL core CDEs and encourages other studies to use HEAL CDEs or more broad NIH CDEs when possible.

Lessons Learned: Using required CDEs from the start is important. Some HEAL repositories mandate data conformity as a deposition requirement (e.g., NIMH Data Archive). HEAL also requires pain clinical studies to use certain core Common Data Elements (CDEs) for human subjects data. Failing to deploy required CDEs when collecting data creates additional data preparation needs before sharing and may lead to conversion difficulties resulting in data loss. Even small changes to CDEs can result in non-compliance, so studies should ideally deploy data standards exactly as specified.

What to do:

• Identify your study’s CDE / data standard requirements, being mindful of pain study core HEAL CDEs and any additional HEAL-compliant repositoryy data standards / CDE requirements.
• When using Common Data Elements (CDEs), implement them exactly as specified in the data collection instrument(s), rather than planning to transform data after collection.
• If CDE deviation is necessary (for example, translating into a new language), document deviations and their justifications and discuss them with your NIH PO.
• Conform data to data standards early. Do not wait until you are sharing data.

Additional resources:

• HEAL core CDEs (required for pain clinical studies)
• HEAL CDE Repository
• NIH Common Data Elements repository
• Variable Standards Finder (HEAL Stewards)

Data very often undergoes processing between when it’s collected and when it’s analyzed. Some common types of processes are cleaning, merging, de-identifying, annotating, or otherwise transforming data. The output data from these processes may be referred to as “clean” or “derived” or “analytic” data (vocabulary differs across disciplines). Processed, or derived, data should be reproducible, and traceable back to its raw inputs through code or other documentation.

Lessons Learned: Failure to adequately document and describe data processing hampers reproducibility. Studies that rely heavily on manual processes—like point-and-click operations in Excel—create data outputs that are difficult to reproduce without extensive documentation. This limits transparency, increases the risk of human error, and makes both data quality control and reproducibility challenging. By contrast, code-based processing creates a repeatable chain of transformations, enhancing both credibility and reproducibility.

What to do:

• Avoid point-and-click and manual data manipulation processes as much as possible**.** Instead, use computational approaches (e.g. code / scripts) to perform data processing.
• Share code / scripts as part of data sharing. Some data repositories accept code files as part of data deposits. If your study’s repository doesn’t accept code, use a suitable HEAL-compliant repository like GitHub to share code.
• Store code with the dataset in a repository or include a link to an external repository where code is shared (e.g., GitHub).
• Provide comments or separate documentation to explain processing steps in further detail, when appropriate.

Sharing data becomes more complex when all or part of the dataset was acquired from external sources. Researchers may assume that once data is in their possession, it can be freely shared—but acquired data typically comes with restrictions. These limitations are often specified in Data Use Agreements (DUAs), license terms, repository conditions, or other contracts that govern the data's original release. Studies that incorporate previously collected data must factor in these limitations when sharing data.

Lessons Learned: If secondary and primary data are combined without carefully addressing these constraints, it can lead to noncompliance with legal or ethical requirements and may prevent the study from sharing its data publicly. Studies must carefully assess which portions of acquired data can be shared (if any), transform data files to omit or redact data points that cannot be shared, and reflect any restrictions in their Data Management and Sharing Plan (DMSP).

What to do:

• When a study combines data from multiple sources into an aggregated dataset, and some of that data is acquired data (not generated by the study), it may not be appropriate to share the aggregated dataset. Refer to any restrictions placed on sharing the secondary data. In some cases, the study may be able to share data elements it generated, but not data elements from secondary data assets.
• Clearly distinguish between generated and acquired data in documentation and DMSPs.
• Note any sharing limitations in the DMSP.

Additional resource:

• HEAL Sensitive Data

The software used to collect and analyze data may affect how accessible and reusable data are. Using proprietary software introduces dependencies on specific platforms, licenses, or file formats that may not be accessible to all users.

Lessons Learned: Data, code, or documentation saved in proprietary formats can become inaccessible to researchers who lack the necessary tools. This creates financial, geographic, or institutional barriers to reuse, limiting the reach of shared data and producing unequal opportunities to use data. In contrast, open-source tools and formats promote transparency, reduce barriers to access, and support broader reuse. Choosing open-source options whenever feasible helps ensure that research outputs remain usable and accessible over time.

What to do:

• Choose open-source software over proprietary software for data workflows whenever possible. This includes tools used for data collection, management, and analysis.
• If proprietary tools are used, share copies of outputs like code and data files in accessible formats (e.g., export data to CSV, save code in a TXT).

Additional resource:

• Best practices for sharing research software