# How to Write a Data Sharing Plan for a Multi-Institutional Grant A data sharing plan tells your funder what data the grant will produce and where it will end up, while a consortium data sharing agreement tells your partner institutions who may use that data, when, and under what conditions. The rule of thumb for choosing your approach is simple: write the funder-facing plan around what a partner-facing agreement can actually deliver, and negotiate the agreement before the grant is awarded, because collaborations that defer these decisions until data exists reliably run into disputes that guidelines do not resolve [1]. ## Why Multi-Institutional Grants Need a Different Kind of Plan Single-lab data sharing is mostly a logistics problem. Multi-institutional research data sharing is a negotiation problem layered on top of a logistics problem. Each site brings its own institutional review board, its own data governance office, and often its own national privacy law. A review of multi-national, multi-institutional genomic collaborations found that international guidelines are largely silent on intra-consortium issues, such as when partners may publish from pooled data, who may access raw records versus summaries, and what happens to data when the grant ends. The authors concluded that a data sharing policy should be negotiated prospectively, as early as possible, and that the absence of such a policy threatens the success of the collaboration itself [1]. Funder requirements add a second layer. The NIH [Data Management](/blog/guides/data-management-basics-principles-processes-and-best-practices) and Sharing Policy requires grant applications to include a plan describing what data will be shared, in what format, under what access terms, and in which repository. NSF requires a data management plan as a supplementary document with each proposal. Horizon Europe requires beneficiaries to manage research data according to the FAIR principles (findable, accessible, interoperable, reusable) and to submit a data management plan within the first months of the project. None of these funders tells you how to coordinate twenty sites, which is why the plan you write must do work that the funder template does not. ## What Your Plan Must Cover Before You Pick an Option Before comparing sharing options, write down the facts that constrain every option: 1. **The data types and their sensitivity.** De-identified genomic sequences, imaging files, survey responses, and physical measurements carry very different legal exposure. 2. **The jurisdictions involved.** Cross-border transfer rules differ by country and province. Canadian initiatives linking data across provinces found that each jurisdiction imposes its own safeguards, and that multi-regional projects need tailored data sharing agreements rather than one template reused everywhere [2]. 3. **The consent and ethics boundaries.** Participant consent forms often specify whether data may leave the originating institution, whether commercial reuse is allowed, and whether re-identification is prohibited. 4. **The harmonization status of the data itself.** Institutions describe patients, samples, or measurements differently. A multinational analysis of clinical decision support systems across 20 institutions in 4 nations identified 131 data elements in use and showed that heterogeneity in information models and terminologies is a genuine barrier to pooling data across sites [3]. 5. **The timeline.** When does each site's data become available, and when does the funder expect release? Once these constraints are on paper, you can evaluate the realistic options rather than the ideal one. ## The Main Options for Multi-Institutional Research Data Sharing The table below is the core of this article. It compares the six practical options that appear repeatedly in collaborative grants, from fully open deposit to approaches where no raw data moves at all. | Option | What moves between institutions | Strengths | Drawbacks | Best fit | |--|--|--|--|--| | Public repository deposit | Full datasets to an external repository | Maximum reuse, satisfies open-science policies, [persistent identifiers](/knowledge/bioinformatics/persistent-identifiers-in-bioinformatics-selection-criteria-and-implementation-workflow) | Often impossible for human data, consent and law may forbid it | Non-sensitive environmental, chemical, and model data | | Controlled-access repository | Data held by a repository, access granted case by case | Legal and ethical compliance with reuse control, professional curation | Access committees add delay, some repositories charge fees | Human genomic and clinical data | | Consortium-internal sharing under an agreement | Data flows only among named partners | Fast analysis, preserves partner control | Funder release obligations may be hard to meet, agreement quality varies | Multi-site intervention studies and registries | | Federated or privacy-preserving analysis | Model parameters and summaries, never raw data | Avoids data-transfer legal barriers, keeps data at the owning site | Technical setup cost, unequal site data volumes can bias models | Multi-hospital imaging, genomics, and machine learning | | Synthetic or differentially private shared datasets | Statistically faithful synthetic records | Can be released openly, protects individual records | Synthetic data quality varies, utility loss for rare patterns | Supporting open release when raw data cannot move | | Metadata-only sharing | Descriptions of each site's data, with contact points | Always feasible, helps future collaborations, satisfies minimal funder rules | No immediate reuse value for other researchers | Projects where every other option is blocked | ### Option 1: Public Repository Deposit Deposit in a public, discipline-based repository is the default expectation under NIH, NSF, and Horizon Europe policies whenever data can be shared without restriction. It is the cleanest answer a plan can give: named repository, named license, named timeline. This option works best when the data carry no personal or proprietary constraints. The Chilean Soil Organic Carbon database (CHLSOC) illustrates the model at national scale. Thirteen institutions compiled 13,612 soil organic carbon data points from published and previously inaccessible sources into a single freely available database released with a persistent digital object identifier, filling spatial gaps that no single institution could have filled alone [4]. The pros and cons are the most lopsided of any option. The pros are long-term persistence, citation through the persistent identifier, independence from any single grant's lifespan, and automatic credibility with reviewers. The cons are that consent, privacy law, and prior publication agreements usually block it for human-subject data, and that deposition still requires harmonized formats and documentation, which takes budgeted staff time. ### Option 2: Controlled-Access Repository When data are sensitive, a controlled-access repository holds the data and grants use to approved applicants. Your plan names the repository, describes the access committee and its criteria, and states the maximum embargo period. This is the standard answer for human genomic data in NIH applications. The drawback is institutional rather than technical. Access decisions add latency, and every partner institution must agree that the chosen repository's access policy matches its own consent and ethics obligations. Budget for data submission, which for large imaging or sequencing collections is a real cost, and specify in the consortium agreement which partner pays for it. ### Option 3: Consortium-Internal Sharing Under a Data Sharing Agreement Here data moves only among the named partner institutions, governed by an intra-consortium agreement. The Singh and Daar review of international genomic collaborations recommends covering, at minimum, the scope of data shared, the purposes for which partners may use it, publication and acknowledgment rules, ownership of derived datasets, and what happens when the collaboration ends [1]. Experience from multi-regional administrative data projects in Canada shows why agreements cannot be copy-pasted. Health Data Research Network Canada and its provincial partners pursued three separate approaches to multi-jurisdictional sharing, including harmonized agreements between a national longitudinal study and ten provincial data centers, four individual agreements for one regional cohort, and coordinated sharing between provincial government departments and a national data center. Each approach required its own innovations to satisfy local privacy legislation [2]. For a grant application, the lesson is to budget lead time for agreement negotiation and to describe that process in the plan rather than pretending a single template will cover all sites. ### Option 4: Federated and Privacy-Preserving Analysis ![Calculation comparing the federated Dice coefficient of 0.852 with the centralized 0.862 to show a difference of 0.010.](/article-images/illustrations/data-sharing-plan-multi-institutional-grant-nih-nsf-horizon-europe-federated-dice-gap.webp) Federated analysis distributes computation to the data-owning institutions so that raw data never leaves them. The feasibility study that introduced federated learning to multi-institutional brain tumor segmentation reported nearly identical performance between a federated semantic segmentation model (Dice coefficient 0.852) and a model trained on centrally pooled data (Dice 0.862), while two alternative collaborative learning methods failed to match federated performance [5]. A follow-up study across 10 institutions found that federated models reached 99 percent of the quality of centrally trained models, and that access to more diverse data through federation benefited model quality more than the collaborative method cost it [6]. The pros and cons deserve honest framing in your plan: - **Pros.** No cross-border raw data transfer, which removes the single largest legal obstacle, and each site retains control of its own records. - **Cons.** The federation needs coordination infrastructure, agreement on model architecture, and governance of who owns the resulting model. Decentralized frameworks such as DeCaPH extend this further by removing the central coordinating server entirely, letting hospitals train jointly without transferring datasets or relying on any central party [7]. Federated approaches have spread beyond medicine. A chemistry collaboration framework combines federated learning with secure multi-party computation, using homomorphic encryption and secret sharing so organizations train machine learning models on distributed chemical data without exchanging raw records, remaining competitive with centralized learning in accuracy and convergence time [8]. ### Option 5: Synthetic and Differentially Private Shared Data When partners cannot release raw records but want to share something reusable, they can generate [synthetic datasets](/blog/data-analysis/synthetic-datasets) that preserve statistical structure while protecting individual records. The ATLAS framework extends generative adversarial networks to multiple parties, with each party holding a discriminator under a semi-honest curator, and adds adaptive gradient perturbation to reduce the utility cost of differential privacy noise on the final shared dataset [9]. This option satisfies a funder's sharing requirement without violating partner constraints. Its weakness is that synthetic data faithfully reproduce common patterns but can distort rare ones, which are often the patterns that matter most in disease or anomaly research. State in your plan what analyses the synthetic data will and will not support. ### Option 6: Metadata-Only Sharing Some collaborations, particularly those involving legally restricted records, can share only descriptions. This is still a legitimate plan component. Multi-institutional digital library work on collections as data showed that even metadata strategies need active governance, including standardized rights statements and community dialogue among contributing institutions, so that computationally usable metadata is also ethically grounded [10]. In a grant plan, metadata-only sharing typically pairs with a pathway for bona fide researchers to request access through each holding institution. ## How to Run a Data Repository Comparison for Your Application Reviewers reward plans that name a specific destination and justify it. A useful data repository comparison evaluates candidates on five criteria: 1. **Certification and sustainability.** Look for repositories with documented long-term curation commitments rather than ad hoc hosting. 2. **Access model.** Open, registered-user, or controlled-access, and whether that model matches every partner's consent language. 3. **Metadata standards.** Whether the repository enforces community metadata schemas, because multi-institutional collections fail on interoperability before they fail on anything else [3]. 4. **Persistent identifiers.** Whether deposits receive DOIs or equivalent identifiers that survive grant closure, as the CHLSOC database demonstrates [4]. 5. **Cost and submission support.** Whether curation, format validation, and long-term storage are funded, and by which partner. Record the comparison in an appendix or internal document. Your plan itself should simply state the winner and why. ## Negotiating the Intra-Consortium Agreement ![Flow of the clauses an intra-consortium data sharing agreement should cover, from data scope to exit terms.](/article-images/illustrations/data-sharing-plan-multi-institutional-grant-nih-nsf-horizon-europe-agreement-clauses.webp) The agreement is the instrument that makes every option enforceable, so a strong plan describes its status explicitly. Pediatric oncology offers a structural lesson. The INSTRuCT consortium, formed by three large cooperative clinical trial organizations to study pediatric soft tissue sarcomas, began by agreeing on a common language to describe patient cohorts and consensus standards for diagnosis and treatment before attempting broader data sharing, patterning itself on the successful International Neuroblastoma Risk Group model [11]. Harmonize definitions and data elements first, then negotiate flow. Cover these clauses even in small consortia: - Which data categories move, in which direction, and at what stage of the project - Permitted and prohibited uses, including secondary analysis by partner staff - Publication rules, including who must be offered authorship and embargo windows - Ownership and reuse rights for derived datasets and trained models - Security controls each site must maintain - Data destruction or archiving obligations at project end - Dispute resolution and exit terms if a partner withdraws Projects that span countries with different privacy statutes should expect iterative legal review, as the Canadian multi-regional initiatives did, and should present that iteration to funders as evidence of feasibility rather than delay [2]. ## Building Release Workflows, Quality Control, and Infrastructure A plan that says "data will be deposited upon publication" without a workflow is a promise, not a process. Materials science consortium work on collaborative data release developed a methodological approach that automates release according to contractual rules while integrating quality queries and reusability checks, implemented as a modular plugin in the open-source Kadi4Mat research data infrastructure [12]. The transferable lesson is to define, per data type, who validates quality, who approves release, and what software executes the check. Infrastructure performance also deserves a sentence in your plan. Multi-institutional cloud-based sharing systems have been analyzed for their coordination performance, and federated projects must account for communication overhead across sites [13]. For consortia distributing shared analytical outputs, structured benchmarking of key metrics across institutions has proven workable at scale, as demonstrated by a 22-institution pediatric antimicrobial stewardship collaborative that shared quarterly benchmarking reports covering 32.4 million encounters and observed measurable changes in prescribing behavior during the benchmarking period [14]. ## Worked Scenarios **Scenario A: A four-country hospital imaging consortium applying to NIH.** Raw scans cannot leave two of the four countries. The plan proposes a federated learning approach with model aggregation at the lead site, citing the evidence that federated models approach centralized performance [5][6]. The consortium agreement, negotiated before submission, assigns model ownership jointly and commits each site to contribute documentation of its imaging protocols to a shared metadata catalog. **Scenario B: A materials science network applying to NSF.** Data are non-sensitive but format heterogeneity is severe. The plan commits to automated release through the consortium's research data infrastructure, with a quality-review gate before each deposit, drawing on established release-workflow methods [12]. The repository comparison in the appendix selects a materials-focused repository on the basis of metadata enforcement and persistent identifiers. **Scenario C: A European multi-omics consortium under Horizon Europe.** Consent permits controlled sharing but not open deposit. The plan names a controlled-access repository, commits to a metadata record with a DOI for every dataset regardless of access tier, and evaluates blockchain-based consent tracking as a governance layer, since multi-omics governance work has proposed combining permissioned ledgers, smart-contract consent enforcement, and off-chain storage to manage provenance and access across jurisdictions [15]. ## Common Mistakes and Limitations - **Treating the funder plan and the partner agreement as one document.** They answer different questions. Reviewers read the plan, courts read the agreement. - **Negotiating after the award.** Post-award negotiation consumes the exact months when data collection should start. - **Promising open deposit for consent-restricted data.** This is the most common plan error and reviewers and ethics boards both catch it. - **Ignoring data heterogeneity.** Assuming sites collect compatible data without documenting element-level differences delays pooling by years [3]. - **Adopting federated methods without budgeting them.** Federation reduces legal risk but adds engineering coordination, and unequal data distributions across sites affect model quality in ways the plan should acknowledge [6]. - **Leaving release logistics to the end.** Automated, quality-gated release workflows take setup time and should exist before the first dataset is ready [12]. - **A limitation worth stating plainly:** any plan is a set of commitments about future behavior, and real collaborations require case-by-case legal and ethics review for each partner's situation. Build that review into the timeline instead of wishing it away. ## Frequently Asked Questions ### When should the consortium sign its data sharing agreement? Before the grant is awarded. Reviews of multi-institutional collaborations consistently recommend prospective negotiation, because waiting until data exists creates disputes that no external guideline resolves [1]. ### Can we write one plan if our partners sit in different countries? You write one funder plan, but expect a set of partner agreements rather than a single document, because each jurisdiction imposes its own privacy safeguards, as multi-regional Canadian projects demonstrated [2]. ### Do privacy-preserving methods really perform as well as pooling data? Published evidence says they come close. Federated models across ten medical institutions reached 99 percent of centralized model quality, and the original brain tumor segmentation study showed a difference of only 0.010 on the Dice coefficient [5][6]. ### What is the difference between the data sharing plan and the data management plan? In NIH and NSF usage the terms largely overlap, describing data types, formats, standards, access, and preservation. In a multi-institutional grant, your data management plan should additionally name the consortium agreement and each partner's role in deposit and access decisions. ### How do we choose between open and controlled-access repositories? Match the access model to the strictest consent language among all partner institutions, then choose among qualifying repositories using certification, metadata standards, persistent identifiers, and cost. A documented comparison strengthens the application. ### What do we write if our data legally cannot leave the institutions? Describe a federated or privacy-preserving analysis approach, or metadata-only sharing with a documented access-request pathway. Funders accept these options when the restriction is justified by consent or law and the alternative analysis path is concrete. ## Sources 1. [Intra-consortium data sharing in multi-national, multi-institutional genomic studies: gaps and guidance](https://pubmed.ncbi.nlm.nih.gov/20535402/) 2. [Addressing multi-region data linkage needs through data sharing agreements - Three Canadian initiatives.](https://doi.org/10.23889/ijpds.v7i3.2093) 3. [Multi-National, Multi-Institutional Analysis of Clinical Decision Support Data Needs to Inform Development of the HL7 Virtual Medical Record Standard.](https://pubmed.ncbi.nlm.nih.gov/21347004/) 4. [CHLSOC: the Chilean Soil Organic Carbon database, a multi-institutional collaborative effort](https://doi.org/10.5194/essd-2019-161) 5. [Multi-Institutional Deep Learning Modeling Without Sharing Patient Data: A Feasibility Study on Brain Tumor Segmentation](https://pubmed.ncbi.nlm.nih.gov/31231720/) 6. [Federated learning in medicine: facilitating multi-institutional collaborations without sharing patient data](https://pubmed.ncbi.nlm.nih.gov/32724046/) 7. [Decentralised, collaborative, and privacy-preserving machine learning for multi-hospital data](https://pubmed.ncbi.nlm.nih.gov/38377795/) 8. [Collaborative Chemical Data Analysis Integrating Federated Learning and Secure Multi-Party Computation](https://doi.org/10.64972/dea.2025.v4i3.2452d:13-26) 9. [ATLAS: GAN-Based Differentially Private Multi-Party Data Sharing](https://doi.org/10.1109/TBDATA.2023.3277716) 10. [Metadata for Collections as Data in a Multi-Institutional Digital Library](https://doi.org/10.1080/19386389.2023.2229229) 11. [Introducing INSTRuCT: An international effort to promote cooperation and data sharing](https://pubmed.ncbi.nlm.nih.gov/32918788/) 12. [Sharing Research Data in Collaborative Material Science and Engineering Projects](https://doi.org/10.3390/data10040053) 13. [Performance analysis of multi-institutional data sharing in the Clouds4Coordination system](https://doi.org/10.1016/J.COMPELECENG.2017.02.015) 14. [Identifying Successful Pediatric Outpatient Antimicrobial Stewardship Strategies through Benchmarking: A Multi-Institutional Project.](https://pubmed.ncbi.nlm.nih.gov/40907705/) 15. [Big Data Governance for Multi-Omics Data Sharing: A Blockchain, Smart Contract, and Off-Chain Storage Framework](https://doi.org/10.63646/vemr4744)