Data Sharing Agreements for Collaborative Projects

By Dr. Zubair Khalid, DVM, MS, PhD · 2026-11-11

By the end of this article you will be able to draft and review a data sharing agreement (DSA) for a collaborative life science project, work through a complete pre-signature checklist, choose between centralized, federated, and trusted research environment models for moving data, and recognize the failure points that stall multi-institution studies before they start. To use the checklist well, have these items on hand: the grant terms and funder data policies for your project, the approved consent language from your ethics or IRB submission, the contact for your institution's contracting or tech transfer office, a draft data dictionary listing every variable you plan to exchange, and the full list of participating sites with their country and institution type.

A data sharing agreement is a written contract between institutions that defines what data will be shared, for what purpose, under what safeguards, and with what rights and obligations for each party. It is not the same as a material transfer agreement, which covers physical samples such as blood or tissue, and it is not the same as a confidentiality agreement, which protects exchanges of ideas and unpublished findings. When a collaboration involves both samples and derived data, you may need both documents, and each should reference the other.

Why Collaborative Projects Need an Agreement Before Data Moves

The strongest argument for settling data terms early comes from genomic consortia. A review of multi-national, multi-institutional genomic studies found that international guidelines were largely silent on intra-consortium data sharing issues, that these gaps threatened the success of collaborative ventures, and that a data sharing policy should be prospectively negotiated and concluded between collaborators as early as possible [1]. In practice, "as early as possible" means before the first dataset leaves the first site, because retroactive agreements are harder to negotiate once expectations have formed and data has already moved.

The practical barriers are well documented. In a pediatric rheumatology collaboration spanning Canada and the Netherlands, expert consultation identified lack of standardized consent, ethics review processes for multi-site projects, difficulty building data governance frameworks that align with institutional and regulatory requirements, differing data standards, and limited interoperability as the main obstacles to sharing health data across borders [2]. Multi-institutional teams in the HMO Research Network faced a similar maze of administrative and regulatory requirements before scientific work could begin, and developed novel approaches to secure and maintain institutional review board approvals, enable data sharing, and expedite subawards, showing that research, regulatory, and administrative staff are essential contributors whose flexibility and communication can prevent project delays [3].

The pattern across these reports is consistent. Projects that treat the DSA as a signature formality discover the real disagreements later, at the worst possible time, usually when a paper is ready for submission or a dataset must be deposited. Projects that negotiate the agreement during study design can build consent language, data standards, and governance around it from day one.

The Data Sharing Agreement Checklist for Life Science Projects

The checklist below covers the elements that repeatedly cause problems in collaborative research. Use it as a drafting outline and as a pre-signature review tool. A compact copy-paste version follows, then each section is explained.

# Data Sharing Agreement Checklist - Life Science Projects

## 1. Parties and roles
- [ ] Full legal names of every sending and receiving institution
- [ ] Named data provider(s), data recipient(s), and any custodian or hub
- [ ] Named scientific leads and administrative contacts per site
- [ ] Subrecipient or consortium status clarified for each site

## 2. Purpose and permitted uses
- [ ] Research purpose stated specifically (disease, question, analysis type)
- [ ] Permitted secondary uses listed or explicitly excluded
- [ ] Commercial use allowed, restricted, or excluded, stated plainly
- [ ] Data linking with external datasets allowed or forbidden

## 3. Data description
- [ ] Datasets enumerated with version and date
- [ ] Data dictionary attached, with units and allowed values
- [ ] Standards named (for example CDISC, HL7, BIDS, MIATA, SEER fields)
- [ ] Metadata and provenance requirements specified

## 4. Consent, privacy, and de-identification
- [ ] Consent language copied verbatim into an appendix
- [ ] Broad sharing consent confirmed or limited sharing documented
- [ ] De-identification method specified (codes, keys, who holds the key)
- [ ] Re-identification explicitly prohibited
- [ ] Small-cell or group-harm protections described if applicable

## 5. Security and access
- [ ] Storage location and environment named (local, cloud, TRE)
- [ ] Encryption at rest and in transit required
- [ ] Access list process and audit logging required
- [ ] Breach notification timeline and responsible party defined

## 6. Ownership, output, and credit
- [ ] Data ownership stated (usually retained by source institution)
- [ ] Intellectual property in derived results addressed
- [ ] Authorship and acknowledgment rules referenced to a policy
- [ ] Publication and presentation review window defined

## 7. Compliance
- [ ] Funder data policies cited (NIH, NSF, Wellcome, EU, as applicable)
- [ ] Repository deposition plans named, with controlled-access terms
- [ ] Applicable privacy law acknowledged at a level both parties accept
- [ ] Export control and sanctioned-party screening confirmed

## 8. Term, changes, and disputes
- [ ] Effective date and duration, tied to grant period
- [ ] Data retention and destruction schedule after project end
- [ ] Amendment procedure for adding sites or datasets
- [ ] Governing law and dispute process stated
- [ ] Signatures authorized to bind each institution

Parties, Roles, and Governance

List every institution by its full legal name, not its common name, and state who sends data, who receives it, and who, if anyone, acts as a custodian or hub. In consortium research, governance structure matters as much as contract language. The Eastern Pediatric Surgery Network, a consortium that grew from 13 pediatric surgery divisions to 24 participating centers over five years, organized itself around explicit pillars including legal ownership of aggregate data, a horizontal leadership structure, and mandatory participation in adopted studies, and this clarity supported 12 peer-reviewed publications without dedicated extramural support for most projects [4]. Your DSA does not need that full structure, but it does need to answer the same underlying question, which is who decides what happens to the combined dataset.

Purpose and Permitted Uses

State the research purpose specifically enough that a compliance officer at the data provider could decide whether a proposed analysis falls inside it. A purpose such as "to identify biomarkers distinguishing progressive from non-progressive pulmonary sarcoidosis using proteomic and transcriptomic profiling" is workable, because a study protocol with that scope exists as a multi-center design across defined biological compartments [5]. A purpose such as "general research" is not workable, because it gives the recipient unlimited discretion. Decide now whether secondary analyses, meta-analyses pooling the data with other cohorts, and commercial tool development are in scope, and write the answer down.

Data Description and Standards

Attach a data dictionary and name the standards you will follow. This is where many collaborations lose months. The Oncoshare project, which integrated breast cancer records from multiple institutions for comparative effectiveness research, found that the data dictionary should be based on existing registry standards such as Surveillance, Epidemiology and End Results (SEER) fields when applicable, and that even with electronic data immediately available, building a validated multi-institution research database took as long as two years [6]. Agreeing on a standard early compresses that timeline. The value of harmonization extends across life sciences. In dairy cattle genomics, a review of sensor-derived phenotyping found that integration into international breeding programs was limited by fragmentation across sensor brands, lack of standardization, and governance issues, and that standardized data collection and sharing protocols were a central requirement [7]. In clinical decision support, a multi-national analysis of 20 institutions across 4 nations identified 131 clinical data elements in actual use, precisely to build community consensus on what should be exchanged, which informed the HL7 Virtual Medical Record standard [8].

Consent, Privacy, and De-identification

Copy the approved consent language into an appendix, verbatim. If participants gave broad consent for future data sharing, say so and describe where the data may go. If consent was narrower, the agreement must restrict sharing accordingly. The eMERGE-IV network, a multi-site consortium collecting genomic and medical data with a focus on underrepresented groups, concluded that participant agreement to broad data sharing in informed consent is often required to make data as open as possible, while no consent form can fully define the "as closed as necessary" side, which requires ongoing judgment [9]. That network also shows what protective decisions look like in practice, including cell suppression for race and ethnicity data and choosing not to extract certain diagnostic codes from electronic health records after legal developments raised the risk of individual and group-level harms [9].

Your checklist should also fix the de-identification mechanics. Specify whether recipients receive coded data with a linkage key held only at the source site, or fully de-identified data with no key, and prohibit re-identification attempts explicitly. For genomic data, note that privacy frameworks in some jurisdictions treat sequence data as inherently identifiable, which shapes what transfers are even permissible [10].

Security and Access Control

Name the environment where the data will live, require encryption at rest and in transit, define who may be granted access and through what approval, and set a breach notification timeline. If the project uses a platform with its own governance model, such as a trusted research environment, the DSA should reference the platform's terms and allocate responsibility for user vetting.

Ownership, Output, and Credit

State that each institution retains ownership of the data it contributes, which is the default expectation in academic collaborations, then address intellectual property in derived results, authorship expectations, and a review window for manuscripts, commonly 30 to 60 days, though the specific number belongs in your consortium policy rather than being assumed. The European Pediatric Surgery example shows that settling ownership of aggregate data up front is one of the pillars a functioning consortium rests on [4].

Compliance With Funder and Repository Rules

Cite the funder policies that bind the project and name the intended repositories. The PRIMED Consortium, an NIH-funded effort to improve polygenic risk score performance across diverse populations, implemented two primary data sharing mechanisms, coordinated dbGaP applications and a Consortium Data Sharing Agreement, and used federated analyses as an alternative where individual-level data could not be shared, all while adhering to pre-existing sharing policies for each integrated dataset and respecting participant consent [11]. If your data will land in a controlled-access repository, the repository's own access terms become part of your compliance picture, and the DSA should say who is responsible for submission and who approves access requests.

Termination, Updates, and Dispute Resolution

Set the agreement's duration, typically matching the grant period, define what happens to shared data when the project ends, establish a simple amendment procedure for adding sites, and name a governing law. International collaborations need extra care here, because the parties operate under different legal systems. The Canadian-Dutch pediatric collaboration resolved this by building data governance frameworks aligned with institutional and regulatory requirements on both sides, rather than assuming one country's rules would suffice [2].

Choosing How the Data Will Move

The DSA must describe not only what is shared but how. Four models dominate collaborative life science projects, and they carry very different agreement obligations.

A federated architecture keeps source data inside each institution and exchanges only queries and summary statistics. The Federated Aggregate Cohort Estimator (FACE), developed by the University of Alabama at Birmingham, Ohio State University, the University of Massachusetts Medical School, and Denver Health, federated diverse SQL sources and an i2b2 instance through easily deployed virtual machines to estimate combined research subject availability while addressing privacy and security requirements of every participating organization [12]. The WiNGS-API platform applies the same logic to rare disease genomics, sharing variant-level data across institutions without centralized transfer, which matters because the General Data Protection Regulation treats genomic data as inherently identifiable, and the platform has been deployed across seven centers managing more than 6,400 samples with single-nucleotide variant calls [10].

A trusted research environment is a middle path. The Human Intracerebral EEG Platform, built within the Human Brain Project and EBRAINS frameworks, gives each of its 34 participating institutions private spaces and shared collaborative spaces inside a cloud-based TRE, standardizes data organization with the BIDS-iEEG specification, controls access through a secure web interface, enables institutional participation through formal data sharing agreements, and aligns with FAIR principles [13]. Notice that even inside a shared platform, the formal DSA remains the entry ticket, which is a useful precedent for any consortium building on shared infrastructure.

Centralized models still have a place when analyses genuinely need record-level data in one place. The Ouest Data Hub, a cooperation of university hospitals in western France, operates clinical data warehouses and data centers that supported access to health data from over 9.3 million patient records in 2023, while its developers flag data quality and interoperability as continuing challenges requiring ongoing harmonization [14]. If you choose centralization, budget for that harmonization explicitly.

Data Repository Comparison

When a project's endpoint is a deposited dataset, compare repositories on four criteria before your DSA names one.

First, access model. Open repositories let anyone download, while controlled-access repositories such as dbGaP require applications, and consortium-managed access lets the data contributors review requesters. PRIMED used coordinated dbGaP applications so that access requests for integrated datasets were handled through a shared process rather than negotiated dataset by dataset [11].

Second, scope and standards fit. A repository built for genotype-phenotype datasets expects different metadata than one built for imaging or for clinical registries. Matching your data dictionary to an existing standard, as Oncoshare did with SEER registry fields, reduces both repository preparation time and reviewer friction [6].

Third, computing environment. Cloud platforms such as the NHGRI Analysis Visualization and Informatics Lab-space (AnVIL), which PRIMED used for technical implementation of consortium data sharing, let researchers analyze data in place rather than downloading it, which changes what your DSA needs to say about local copies [11]. A TRE-based platform such as the Human Intracerebral EEG Platform similarly keeps analysis inside the governed environment [13].

Fourth, long-term stewardship. Ask who maintains the repository, what happens if funding ends, and whether persistent identifiers are issued. These questions belong in the compliance section of your checklist.

Worked Example

Consider a realistic scenario. Three universities want to pool de-identified electronic health record and genomic data from 2,000 participants each to study a rare inflammatory disease. Here is the sequence.

Step 1. Draft the shared checklist. The three leads circulate the checklist above and fill it in together during a video call, marking every item as decided, open, or not applicable. Expected output, a partially completed file that looks like this:

## 2. Purpose and permitted uses
- [x] Purpose: [biomarker discovery](/knowledge/molecular-biology/biomarker-discovery) for rare inflammatory disease,
      proteomic and transcriptomic analysis of plasma and PBMC samples
- [ ] Secondary uses: OPEN, leads to decide by 15 March
- [x] Commercial use: excluded
- [x] External data linking: forbidden without written amendment

Step 2. Freeze the data dictionary against a standard. Each site exports its candidate variables and the team reconciles them. A minimal dictionary row looks like this:

variable_name,description,units,allowed_values,source_standard
age_y,age at enrollment,years,18-90,none
fev1_pct,forced expiratory volume percent predicted,percent,0-150,ATS/ERS spirometry
smoke_status,smoking status,none,current-former-never,none

Expected output after reconciliation is one file, version controlled, with every disputed variable either mapped to the shared standard or dropped. When sites disagree on definitions, the default is the external standard, not the largest site's local habit, because standard alignment is what made registry-based integration work in prior multi-institution builds [6].

Step 3. Write the agreement around the checklist answers. The contract office at the lead site drafts the DSA using the checklist as its section outline. Two clauses in the final document might read:

4.2 Permitted Uses. Recipient may use the Shared Data solely for the
Research Purpose described in Appendix A. Recipient shall not attempt
to re-identify de-identified data, link the Shared Data to external
datasets, or use the Shared Data for commercial purposes, except with
prior written amendment to this Agreement.

5.3 Security. Recipient shall store the Shared Data within its
approved research computing environment, require encryption in transit
and at rest, maintain a log of all persons granted access, and notify
Provider of any suspected breach within 72 hours of discovery.

Step 4. Validate the transferred data mechanically. Before the first real transfer, each site runs a field check script so format errors surface before the agreement's data provisions are tested by a messy file:

import pandas as pd

required = {"participant_pseudonym", "consent_broad_sharing",
            "collection_site", "age_y"}
df = pd.read_csv("site01_batch001.csv")

missing = required - set(df.columns)
assert not missing, f"Missing required columns: {sorted(missing)}"
assert df["consent_broad_sharing"].isin([0, 1]).all(), \
    "consent_broad_sharing must be 0 or 1"
assert df["participant_pseudonym"].is_unique, "Duplicate pseudonyms found"
print("Batch 001 validated:", len(df), "rows,", len(df.columns), "columns")

Expected output:

Batch 001 validated: 2000 rows, 41 columns

If instead you see Missing required columns: ['consent_broad_sharing'], the transfer stops and the sending site corrects its export. This check belongs in the DSA's data description section as a named validation step, so that refusing a nonconforming batch is enforcing the contract, not starting an argument.

Step 5. Register the governance rhythm. Set a recurring call for the data governance group, agree that new sites join by written amendment to the DSA, and log every dataset version in a shared register with date, site, row count, and dictionary version. Consortium experience shows that flexibility and effective communication among research, regulatory, and administrative staff are what keep multi-institution approvals moving [3], and a standing meeting is the cheapest way to supply both.

Common Mistakes and Limitations

• Signing after data has moved. Retroactive agreements invite disagreement about what was actually consented and what was promised. Negotiate prospectively, as genomic consortium experience recommends [1].
• Treating consent as someone else's problem. If the receiving institution's planned analyses exceed what participants agreed to at the sending site, no clever contract language fixes it. Copy consent language into the agreement and constrain uses to match it [9].
• Skipping the data dictionary. A DSA that says "de-identified clinical data" without a variable list, units, and standards guarantees months of reconciliation. Budget for the possibility that validated multi-institution data takes far longer than expected, up to two years in one documented oncology build [6].
• Assuming one governance template fits all sites. Multi-site ethics review, differing institutional requirements, and jurisdictional differences were leading barriers in a real cross-border collaboration [2]. Ask each site's compliance office early.
• Choosing centralized transfer by default. When analyses allow it, federated designs avoid moving identifiable-risk data entirely and have been shown to work for cohort discovery and rare disease variant matching [12], [10]. The choice should follow the analysis plan, not habit.
• Forgetting the exit. Agreements that never specify data destruction or retention after the grant ends leave datasets in limbo and can violate institutional policy. Write the retention schedule into the term section.
• Over-relying on the platform to handle governance. Even platforms built for collaboration require formal data sharing agreements for institutional participation [13]. The platform is infrastructure, not a substitute for a contract.
• One limitation to state plainly. This checklist is a drafting and review aid, not legal advice. Every institution's contracting office and privacy office must review the final agreement, and individual projects may face requirements no generic checklist anticipates.

Frequently Asked Questions

What is a data sharing agreement in life science research?

A written contract between institutions that defines what research data will be shared, for what purpose, under what privacy and security safeguards, and with what rights over ownership, publication, and future use. It sits alongside, and is distinct from, material transfer agreements and confidentiality agreements.

When should a data sharing agreement be signed?

Before any data leaves any site. Consortium experience shows agreements negotiated during study design prevent disputes, while retroactive agreements are harder to reach and can undermine the collaboration.

What should a data sharing agreement checklist include?

At minimum, parties and roles, purpose and permitted uses, a data description with standards, consent and de-identification provisions, security and access rules, ownership and publication terms, funder and repository compliance, and termination or amendment procedures. The full checklist in this article expands each of these into checkable items.

Is there a standard template or format for these agreements?

There is no single universal template, but the checklist format above, expanded into numbered contract sections with appendices for consent language and the data dictionary, is the most common working format in academic collaborations. Your institution's contracting office may have a preferred template to start from.

Should data be centralized or analyzed in a federated way?

Choose centralization when analyses require record-level data in one place, and federation when privacy rules, consent limits, or data volume make transfer impractical. Federated platforms let institutions answer queries and share aggregates while data never leaves the source site.

How does participant consent affect what can be shared?

Consent sets the ceiling on every downstream use. Broad sharing consent enables deposit and wide reuse, while narrow consent restricts the data to the original purpose. The agreement should quote the consent language and prohibit uses beyond it.

What is a trusted research environment?

A secure computing environment where approved researchers analyze data in place, through controlled access, without downloading it. Consortium platforms built this way assign each institution private and shared workspaces and rely on formal data sharing agreements to govern participation.

How long does it take to build a shared multi-institution dataset?

Plan for it to take substantially longer than a single-site dataset. One documented multi-institution oncology database took as long as two years to produce validated, reliable research data, even with electronic records already available.

Sources

1. Intra-consortium data sharing in multi-national, multi-institutional genomic studies: gaps and guidance.
2. A roadmap for navigating child health research data sharing across Canada and beyond - building on UCAN CAN-DU.
3. Accelerating regulatory progress in multi-institutional research.
4. The Eastern Pediatric Surgery Network: Creation and implementation of a comprehensive clinical research collaborative in pediatric surgery.
5. Molecular characterisation of progressive pulmonary sarcoidosis: protocol for a longitudinal multi-centre study to develop peripheral blood circulating biomarkers for predicting pulmonary sarcoidosis progression.
6. Oncoshare: lessons learned from building an integrated multi-institutional database for comparative effectiveness research.
7. Invited review: Using data from sensors and other precision farming technologies to enhance the sustainability of dairy cattle breeding programs.
8. Multi-National, Multi-Institutional Analysis of Clinical Decision Support Data Needs to Inform Development of the HL7 Virtual Medical Record Standard.
9. Navigating data sharing in research.
10. WiNGS-API: a federated genome/phenome data sharing platform enabling gene discovery and variant classification for rare diseases.
11. Data sharing in the PRIMED Consortium: Design, implementation, and recommendations for future policymaking.
12. Federated Aggregate Cohort Estimator (FACE): an easy to deploy, vendor neutral, multi-institutional cohort query architecture.
13. The Human Intracerebral EEG Platform: A Cloud-Based Trusted Research Environment for Collaborative SEEG Research in Epilepsy and Neuroscience.
14. The Ouest Data Hub: An Interregional Health Data Sharing Ecosystem for Research.