# How to Create a Data Sharing Plan That Maximizes Reuse By the end of this article you will be able to draft a data sharing plan that a funder will accept and a stranger will actually use. You will inventory your data, pick standards and metadata formats, compare repositories against concrete criteria, define access terms, and validate the plan with a checklist. Nothing here requires special software. You need your dataset inventory, your funder's sharing policy, a text editor, and access to a spreadsheet program. The core argument is simple. Depositing data somewhere is easy. Getting a stranger to reuse that data for a new analysis is hard, and the difference comes from decisions you make before the deposit. OpenNeuro, a public archive for brain imaging data, links the reuse of its more than 600 shared datasets directly to one design decision, the adoption of a common data structure that makes curation and reuse straightforward [1]. A plan that bakes those decisions in from day one is the goal. ## Why Reuse Depends on Planning, Not Just Deposit Research data sharing is now a requirement at most funders and many journals, but the stated purpose is rarely the deposit itself. The purpose is secondary analysis, merged analyses across organizations, and more precise answers to old questions [2]. Data that sits in a repository with no documentation produces none of those benefits. The gap between deposit and reuse shows up in the literature. Analysts of the WorldWide Antimalarial Resistance Network, a malaria data platform with a decade of operation, argue that mandated sharing alone increases the volume of available data but does not enable the secondary analyses needed to deliver public benefit. Their solution is deliberate curation, structured collaboration through study groups, and explicit reward for people who share and who reuse [3]. The lesson for your plan is that curation effort and governance are planned inputs, not afterthoughts. The same logic applies to code and workflows. Life science research increasingly runs on large-scale computational analysis, and recommendations for open data science stress that data, code, and software must all be transparent and available for a study to be reproducible or reusable [4]. A plan that covers data but not the code that processed it leaves the reuse problem half solved. ## What Goes in the Plan: A Reusable Format Most funder templates (the US National Science Foundation, the National Institutes of Health, and major European funders all publish their own) ask for the same core content under different headings. A data sharing plan format that works across funders and maximizes reuse contains seven sections: 1. **Data description.** What data will be produced, in what types and formats, and what volume. 2. **Standards.** Which community data formats and vocabularies the data will follow. 3. **Metadata.** What descriptive information will accompany the data and in what machine-readable form. 4. **Repository and access.** Where the data will live, who can access it, and under what conditions. 5. **Reuse conditions.** Licenses, citation expectations, and any controlled-access or consent constraints. 6. **Preservation.** How long data will be retained and in what format for the long term. 7. **Roles and resources.** Who curates, who answers reuse questions, and what time or budget is allocated. Two of these sections do most of the work for reuse. Standards make your data interoperable, so it can be combined with other people's data. Metadata makes it findable and interpretable. The FAIR principles, which stand for findable, accessible, interoperable, and reusable, name these properties explicitly, and well-run archives operationalize all four rather than just the first one [1][5]. ## Step-by-Step: Building the Plan ### Step 1. Inventory every data object List each file type, its format, its approximate size, and whether it contains identifiable information. Write the inventory into the plan. A pharmacometrics example makes the point concrete. Sharing individual-level longitudinal data for drug-disease modeling raises legal, ethical, and proprietary issues, and it also raises format questions specific to the field, which is why standards bodies work on data exchange standards for exactly this kind of data [2]. Your inventory is where those constraints first become visible. A simple inventory table inside the plan looks like this: | Data object | Format | Volume | Identifiable | Reuse barrier | |--|--|--|--|--| | Participant visits | CSV | 4 GB | Coded IDs | Consent scope | | Imaging series | NIfTI | 180 GB | Coded IDs | None, de-identified | | Analysis scripts | Python, R | 2 MB | None | None | | Model code | Nonmem control streams | 300 KB | None | Proprietary software dependency | ### Step 2. Choose standards before choosing a repository Pick the data standard your community already uses. Do not invent a format. In neuroscience, the Brain Imaging Data Structure (BIDS) standard is the reason one archive can curate and serve data from multiple species, measurement modalities, and phenotypes effectively [1]. In clinical research, the Clinical Data Interchange Standards Consortium and related organizations publish the exchange standards used for individual-level clinical and modeling data [2]. In population health, the Data Documentation Initiative (DDI) Codebook standard documents survey metadata, and the Observational Medical Outcomes Partnership (OMOP) Common Data Model harmonizes data for unified analysis [6]. Record your standard in the plan with a sentence like: "All imaging data will be converted to the Brain Imaging Data Structure specification before deposit." If no standard exists in your niche, say what you will use instead, such as a documented community schema or a formal ontology. ### Step 3. Write metadata in machine-readable form Human-readable README files help people. Machine-readable metadata helps both people and software, and this is what enables discovery and integration across platforms [6]. A metadata framework built on standardized formats, vocabularies, and protocols can make population health data discoverable and integrable in ways that free-text documentation cannot [6]. Concretely, pair a README for humans with a structured metadata file for machines. A minimal data package descriptor looks like this: ```yaml name: cohort-cognitive-aging-2024 title: Longitudinal cognitive aging cohort, baseline through year 3 licenses: - name: CC-BY-4.0 resources: - name: participant-visits path: data/participant_visits.csv format: csv mediatype: text/csv schema: fields: - name: subject_id type: string description: Coded participant identifier - name: visit_date type: date - name: mmse_score type: integer description: Mini-Mental State Examination total, 0-30 ``` When you validate the structure, the expected output confirms every field resolves against a type and description: ``` $ frictionless validate datapackage.yaml valid: participant-visits 12,480 rows checked 3 fields checked summary: 1 resource, 0 errors ``` If the output reports an error such as `field "mmse_score" has 3 invalid values: "NA", "n/a", "-9"`, fix the file so missing values use one declared code, then rerun. Inconsistent missing-value codes are among the most common reasons a secondary analyst discards a dataset. ### Step 4. Compare repositories against reuse criteria ![A two-question decision path leading either to an open archive or a managed platform with tiered access.](/article-images/illustrations/data-sharing-plan-maximize-reuse-repository-choice.webp) A data repository comparison should never be done on name recognition. Compare candidates on five criteria: the data types accepted, the standards supported, the access model, the persistence commitment, and the curation services offered. | Repository or platform | Domain | Standard used | Access model | Notable reuse feature | |--|--|--|--|--| | OpenNeuro | Brain imaging | Brain Imaging Data Structure | Open | Standardized structure enables curation and reuse across modalities [1] | | Brain-CODE | Neuroscience, Ontario | Standardization at capture and release | Tiered, including secure compute | Multiple access paths for metadata, in-platform analysis, and export [5] | | WWARN platform | Malaria | Community study-group curation | Managed collaboration | Study group model organizes secondary analysis and credits contributors [3] | | Disease-specific databases (ADNI, PPMI, WWARN and others) | Neurodegeneration, malaria, tuberculosis, oncology | Field-specific exchange standards | Varies by program | Built for drug-disease modeling with merged datasets [2] | The table shows a real pattern. Open archives maximize the number of potential reusers. Managed platforms maximize the depth of curation and the quality of each reuse event, at the cost of slower access. Your choice follows from your data. Imaging data with an existing standard and wide reuse potential fits an open archive. Sensitive individual-level clinical data fits a tiered platform with controlled access. ### Step 5. Define access and reuse terms precisely State the license by name. State what consent covers and what it does not. If data will be controlled access, describe who reviews requests and how long approval takes. Brain-CODE separates access into distinct mechanisms, distinguishing metadata access, data access within a secure computing environment, and data export, which lets requesters work at the level their question requires [5]. You can borrow that structure even if you deposit in a general repository, by describing which data objects fall under which access tier. For reuse conditions, name the citation you expect (a data DOI and the associated publication) and say whether secondary users may redistribute derivatives. Vague terms like "please contact the authors" suppress reuse. Precise terms enable it. ### Step 6. Document code, models, and workflows List every script, model file, and workflow, and state where each will be deposited. For pharmacometric modeling, organized sharing of executable model code and associated information has historically been sparse, which is exactly why dedicated model repository efforts emerged, and why your plan should name a home for model files rather than treat them as loose attachments [2]. If a script depends on proprietary software, say so, and note the version, so a reuser knows what environment to recreate. ### Step 7. Plan curation time and credit Curation is not free. Budget hours for formatting, documentation, and de-identification, and name the person responsible. The malaria platform case study is blunt on this point. Academic advancement seldom recognizes or rewards data sharing, so plans that rely on goodwill alone fail, and models that reward curators and reusers perform better [3]. If your institution has a data library or informatics core, name it in the plan as the curation partner. ### Step 8. Validate the plan before submission Run this checklist. Every unchecked item is a sentence you still need to write. ``` CHECKLIST [ ] Every data object in the inventory has a named format and standard [ ] Metadata is available in a machine-readable format, not just a README [ ] A specific repository is named, with a fallback [ ] License named exactly (for example CC-BY-4.0, not "open license") [ ] Consent scope stated for every human-subject data object [ ] Code and model files have a named home [ ] Curation responsibility and hours assigned [ ] Timeline states when each deposit happens relative to publication ``` A completed plan that passes this list is usually 3 to 6 pages. Longer plans rarely get read, and reuse depends on reusers reading. ## Making Metadata Machine-Readable in Practice This is the step most plans skip and the step that most determines reuse. Metadata describe and provide context for other data, and comprehensive machine-readable descriptions let both machines and human users discover, access, integrate, and reuse data across platforms [6]. Three practical routes, in increasing order of effort: 1. **Use a documentation standard.** DDI Codebook provides a structured way to document survey and study metadata so tools can parse it [6]. 2. **Map into a common data model.** The OMOP Common Data Model harmonizes heterogeneous health data into a shared structure that supports unified analysis across sites [6]. 3. **Use an ontology.** An ontology gives standardized definitions and explicit relationships between entities, which a flat database does not provide. In the cancer vaccine field, a knowledge base of more than 670 manually annotated vaccines was extended by mapping its content into the Vaccine Ontology using a design pattern, generating terms in RDF/OWL and SPARQL query scripts that let researchers query vaccines by their features [7]. The ontology route sounds abstract until you see the payoff. A structured query can return every vaccine in a class with its associated entities, something a keyword search over free text cannot do reliably [7]. The same principle holds in clinical modeling, where the openEHR approach captures the tacit knowledge of domain experts in explicit, reviewable clinical models precisely to achieve interoperability and data reuse [8]. Expert-reviewed archetypes went through repeated review rounds until reviewers and editors agreed the model was publishable, and the interviews afterward highlighted interoperability and reusability as core motivations [8]. If your domain has a comparable modeling community, use its artifacts rather than inventing your own field names. ## Worked Example: A Data Sharing Plan That Maximizes Reuse Here is a condensed data sharing plan maximize reuse example for a hypothetical longitudinal imaging and cognition study, written the way the final document would read. > **Data description.** The study produces 180 GB of magnetic resonance imaging series for 120 participants across three visits, 4 GB of tabular cognitive and demographic variables, and analysis code in Python and R. > > **Standards.** Imaging series will be organized and named according to the Brain Imaging Data Structure specification before deposit. Tabular variables follow the project data dictionary, published alongside the data. Analysis code is deposited as a versioned software archive with a pinned environment file. > > **Metadata.** Each dataset carries a machine-readable descriptor file listing field names, types, units, and missing-value codes, plus a human README. Study-level metadata uses the project's institutional schema and is exposed to harvesting so external catalogs can index it. > > **Repository and access.** Imaging and [tabular data](/blog/research-skills/tabular-data-what-it-is-and-how-to-analyze-it) deposit in a public archive that supports the chosen standard. A fallback general repository is named in case the primary archive cannot accept a data type. > > **Reuse conditions.** Data are released under CC-BY-4.0. Reusers cite the dataset DOI and the primary publication. No redistribution of participant-level data outside the archive. > > **Preservation.** Data are retained for 10 years post-publication in archival formats, with format migration handled by the repository. > > **Roles.** The project data manager spends 60 hours across the project on curation. The institutional data library reviews the metadata before deposit. This example mirrors the design logic that made large neuroscience sharing work. The archive's growing record of published reuses, more than 150 publications citing shared datasets, follows from standardized structure, open access, and explicit reuse tracking [1]. Every element in the example traces to a decision that a reuser will encounter directly. For modeling-heavy projects, extend the example with a model section. Name the model repository, state the software version, and describe what a reuser needs to run the model end to end. The pharmacometrics community moved toward exactly this, with organizations coordinating on formats and a shared model repository to replace years of sparse, ad hoc code sharing [2]. ## Common Mistakes and Limitations ![Four cards naming the mistakes that most often stop a deposited dataset from being reused by others.](/article-images/illustrations/data-sharing-plan-maximize-reuse-reuse-blockers.webp) - **Writing the plan after data collection ends.** Standards and consent language must be settled at study design. Retrofitting a data structure onto finished imaging data is weeks of work, and retrofitting consent is often impossible. - **Treating a PDF as metadata.** A narrative PDF is findable by people but not by machines. Machine-readable metadata is what enables integration across platforms, and frameworks built for this purpose show measurable gains in discoverability and reuse readiness [6]. - **Naming a repository that cannot accept the data.** Check data-type support, size limits, and access models against your inventory from Step 1 before you commit in the plan. - **Confusing openness with reuse.** Mandated open deposit increases volume, not usability. The malaria platform's experience indicates that without curation and organized collaboration, secondary analysis does not materialize even when data are technically available [3]. - **Leaving code and model files out.** Reproducibility and reuse require data, code, and software together, and omitting any one of them limits what a reuser can do [4]. - **Inventing a data format.** Community standards exist because shared structure is what allows merging and comparison across studies. Using them is the single highest-return decision in the plan. - **Ignoring consent scope.** Data shared beyond what participants consented to is a legal and ethical failure, not a plan detail. State consent boundaries in the reuse section explicitly. - **Assuming one plan fits every funder.** Funder templates differ in emphasis, so maintain the seven-section core and map it into each template at submission time. A final limitation. A plan is a document, and documents do not curate data. The workload estimates here come from the operational experience of established platforms, and your institution's costs will differ. Whatever the number, put it in the budget line, because unresourced curation is the most common reason plans exist on paper only [3]. ## Frequently Asked Questions ### What is a data sharing plan and when should I write one? A data sharing plan is a short document describing what data a project will produce, where it will be deposited, how it will be documented, and who can reuse it under what conditions. Write it at proposal stage, because standards and consent decisions affect study design itself. ### What format should a data sharing plan follow? Use a seven-section format covering data description, standards, metadata, repository and access, reuse conditions, preservation, and roles. This core maps cleanly onto the templates published by major funders, so you adapt rather than rewrite for each submission. ### Where can I find a template I can fill in? Use the numbered walkthrough in this article as your template, starting with the YAML descriptor in Step 3 and the checklist in Step 8. Funder portals also provide official templates, and the seven-section core fills them without restructuring. ### Can you show a finished example? Yes. The worked example section shows a complete plan for a longitudinal imaging and cognition study, condensed to the language you would actually submit. Adapt the structure, not the content, to your own data types. ### How do I choose between data repositories? Compare candidates on data types accepted, standards supported, access model, persistence commitment, and curation services. Open archives suit standardized, widely reusable data. Managed platforms with tiered access suit sensitive clinical data that needs curation. ### What metadata standard should I use? Use the standard your community already maintains, whether that is a documentation standard for surveys, a common data model for health records, or a formal ontology for a defined entity domain. Machine-readable metadata is the goal, and the format matters less than its parseability. ### Do I have to share everything openly? No. Many repositories and platforms offer controlled access tiers for sensitive data, and consent scope can restrict what is shared at all. Your plan should state which data objects are open, which are controlled, and which are excluded, with the reason for each. ### How do I know whether my plan actually maximized reuse? Track it. Count derived publications, external requests, and data downloads against the dataset DOI. Established archives do exactly this, reporting published reuses as a measure of impact, and the same metric works at single-project scale. ## Sources 1. [The OpenNeuro resource for sharing of neuroscience data.](https://pubmed.ncbi.nlm.nih.gov/34658334/) 2. [Open innovation: Towards sharing of data, models and workflows.](https://pubmed.ncbi.nlm.nih.gov/28684136/) 3. [Strength in Numbers: The WWARN Case Study of Purpose-Driven Data Sharing.](https://pubmed.ncbi.nlm.nih.gov/30350772/) 4. [Recommendations for open data science.](https://pubmed.ncbi.nlm.nih.gov/27195107/) 5. [FAIR in action: Brain-CODE - A neuroscience data sharing platform to accelerate brain research.](https://pubmed.ncbi.nlm.nih.gov/37274750/) 6. [Making Metadata Machine-Readable as the First Step to Providing Findable, Accessible, Interoperable, and Reusable Population Health Data: Framework Development and Implementation Study.](https://pubmed.ncbi.nlm.nih.gov/39088253/) 7. [Empowering standardization of cancer vaccines through ontology: enhanced modeling and data analysis.](https://pubmed.ncbi.nlm.nih.gov/38890666/) 8. [An openEHR Approach to Detailed Clinical Model Development: Tobacco Smoking Summary Archetype as a Case Study.](https://pubmed.ncbi.nlm.nih.gov/30919398/)