A Template for a Genomics Data Sharing Agreement: What to Include

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

By the end of this guide you will be able to draft a complete genomics data sharing agreement (DSA), fill in every clause with defensible values, and verify with checksums that the data you shipped is the data you promised. For the verification steps you need a Linux or macOS shell with rsync, GNU coreutils (which provides md5sum), samtools, and bcftools installed. For the drafting steps you need four things on hand: the consent form language your participants signed, your ethics or Institutional Review Board (IRB) approval number, a current file inventory for the release, and the contact for your institution's contracts office.

A genomics data sharing agreement is a binding contract between whoever controls a dataset and every party that receives it. It records what the data are, what recipients may and may not do with them, how the data must be stored and protected, and what happens when the project ends. It is distinct from a material transfer agreement (MTA), which governs physical biospecimens, and from a general confidentiality agreement, which governs information exchange without defining a dataset.

The pressure to get this document right is real. Funders and journals increasingly mandate sharing, which forces research teams to balance openness against the risk of harm to participants in a changing legal and social environment [1]. Large consortia run on these agreements. The NIH-funded PRIMED Consortium used two primary mechanisms, coordinated applications to the controlled-access repository dbGaP and a Consortium Data Sharing Agreement, to aggregate data from heterogeneous sources while respecting each dataset's pre-existing policies [2]. National pathogen genomics programs list national ethics and data sharing agreements among the enablers that made integrated surveillance possible [3]. And in some jurisdictions a DSA is not optional. The Uganda National Council for Science and Technology requires data sharing agreements for collaborative research [4].

What a Genomics Data Sharing Agreement Actually Governs

A DSA governs the movement and use of data, not the biology. In genomics that typically means individual-level sequence files (CRAM, a compressed alignment format that stores reads relative to a reference genome), variant calls (VCF, the standard format for variant records, usually bgzipped so it can be indexed), harmonized phenotype tables, and derived files such as summary statistics or polygenic risk scores (estimates of genetic predisposition that combine many variants). The agreement should cover every artifact a recipient can touch, because a contract that names only the raw reads leaves the derived files unregulated.

An evaluation of eight genomic data sharing agreements at three research-intensive institutions in Uganda assessed the documents against five domains: data ownership, protection and security, access, intellectual property, and benefit sharing [4]. The same study surfaced three cross-cutting themes, informed consent, legal enforceability, and potential community harms, that belong in any template as design checks rather than afterthoughts [4].

The eMERGE-IV Network, a US multi-site consortium that assembles genomic and medical record data to refine disease risk prediction, frames the underlying balance as "as open as possible, as closed as necessary" [1]. A template is the instrument that makes "as closed as necessary" concrete. Consent forms rarely can be, because no consent form can define the terms of that phrase in advance [1].

The Clauses That Do the Work

Sixteen clauses cover the ground. For each one, know the decision you are making and the failure mode you are avoiding.

1. Parties and recitals. Full legal entity names and authorized representatives for every site that will hold or touch the data. An agreement signed by a principal investigator rather than an institutional official may not bind the institution at all.

1. Definitions. Define dataset, release version, derived data, re-identification (linking coded genomic data back to an identified person), and security incident. Ambiguity here is what disputes feed on.

1. Description of the data. Dataset name and version, file types, identifiability tier, volume, checksum manifest, and explicitly excluded fields. eMERGE-IV suppressed small race and ethnicity cells and declined to extract certain diagnostic codes from electronic health records, decisions made to prevent individual and group level harms from genomic analyses [1]. Your exclusion list belongs in the contract, not in an email.

1. Purpose and permitted use. One research question, one project title, one funder. Permitted uses and prohibited uses in separate lists. Recent US legal developments, including the Dobbs decision and bans on gender-affirming care, forced eMERGE-IV to rethink its strategies for preventing individual and group level harms [1]. That is a concrete argument for writing prohibited uses down now, while you control the text.

1. Access model and sub-sharing. Whether the data move at all, who can see individual-level records, and whether the recipient may pass data to third parties. Sub-sharing without a named appendix is how consortium data end up in uncontrolled places.

1. Consent and human subjects basis. Cite the consent form version and protocol number, and bind the recipient to the consent's limits, including any rules on returning results to participants.

1. Data standards and format. File formats, reference genome build with its checksum, and the data model. Cross-border collaborations repeatedly report differing data standards as a barrier to sharing [5]. The clause that prevents that problem costs one paragraph.

1. Storage and security. Encryption in transit and at rest, named accounts, audit logging, approved environments, and an incident notification clock.

1. Intellectual property. The provider retains ownership of the dataset, the recipient owns its derived analyses, and the patent position for inventions resting on the dataset alone is stated, not implied. The Uganda evaluation found intellectual property handled unevenly across institutions, with legal enforceability a persistent challenge [4].

1. Publication and attribution. Citation text, pre-submission review windows, and co-authorship rules.

1. Benefit sharing. Non-monetary returns such as training, shared code, and aggregate results back to communities, plus any monetary terms. Benefit sharing is one of the five domains regulators actually check [4].

1. Breach, audit, and compliance. Audit rights for the provider and an annual certification from the recipient that use remains in scope.

1. Retention, return, and destruction. An end date and a written destruction certification. This clause is routinely missing in practice. In a review of 200 genomics and biobanking protocols in Zimbabwe, only 44 (22%) included plans for destruction of collected samples [6]. Do not inherit that gap.

1. Termination. Termination for material breach, with clause 13 as the landing procedure.

1. Liability, indemnity, and governing law. Negotiated text your contracts office owns, not text you draft alone.

1. Signatures and version control. Any change is a new numbered version, distributed to all parties and logged in a governance register.

A Copyable Genomics Data Sharing Agreement Template

This is the template format in full. Bracketed fields are the decisions you make in the walkthrough that follows. Keep the clause numbering stable across versions so that audits and emails can cite clause numbers.

GENOMICS DATA SHARING AGREEMENT
Version [X.X], dated [YYYY-MM-DD]

1. PARTIES
   Data Provider: [legal entity, address, authorized representative]
   Data Recipient: [legal entity, address, authorized representative]
   (One executed copy per party. Repeat the block for each site.)

2. RECITALS
   The Provider controls the dataset described in Section 3, collected
   under the consent described in Section 6. The Recipient requires
   access for the purpose stated in Section 4.

3. DEFINED DATA
   3.1 Dataset name and release version: [name, v1.0]
   3.2 Data types: [CRAM alignments, joint-called VCF, phenotype
       tables, derived summary statistics]
   3.3 Identifiability tier: [coded individual-level / aggregate only]
   3.4 Volume and manifest: [n] files, [size], manifest.md5
   3.5 Excluded fields: [free-text clinical notes, geography below
       [state] level, suppressed cells below [n] individuals]

4. PURPOSE AND PERMITTED USE
   4.1 Permitted: analyses addressing [research question] under the
       project [title], funded by [funder, grant number].
   4.2 Prohibited: re-identification, linkage to datasets not named
       in Appendix A, commercial product development, redistribution,
       and uses that could enable harms to [named populations],
       including [law enforcement, insurance underwriting,
       immigration enforcement].

5. ACCESS MODEL AND SUB-SHARING
   5.1 Access tier: [open / controlled / federated]
   5.2 Named analysts: [list, or a named-role rule]
   5.3 Sub-sharing: [not permitted / permitted only to sites named
       in Appendix A under the same terms]
   5.4 Approved environments: [institutional cluster / named cloud
       tenancy and region]

6. CONSENT AND HUMAN SUBJECTS BASIS
   6.1 Consent basis: [broad consent for genomic research and
       sharing, form version, IRB protocol number]
   6.2 The Recipient honors all consent limits, including
       [return of individual results: none / aggregate only].
   6.3 Aggregate protections: [cell suppression below [n],
       no reporting of [excluded codes]].

7. DATA STANDARDS AND FORMAT
   7.1 Formats: [CRAM, bgzipped and indexed VCF, TSV or JSON
       metadata]
   7.2 Reference: [build, FASTA file with checksum]
   7.3 Data model: [consortium data model name and version]
   7.4 Required metadata: [sample join key, assay platform,
       pipeline version]

8. STORAGE AND SECURITY
   8.1 Encryption: [AES-256 or equivalent] at rest, [TLS] in transit.
   8.2 Access control: named individual accounts, least privilege,
       no shared logins.
   8.3 Logging: audit logs retained [n] months, available to the
       Provider on request.
   8.4 Incident notification within  hours of discovery of
       unauthorized access, with a written report to follow.
   8.5 No copies outside the environments named in 5.4.

9. INTELLECTUAL PROPERTY
   9.1 The Provider retains ownership of the dataset. The Recipient
       owns its derived analyses.
   9.2 Patent filings on inventions resting on the dataset alone:
       [Provider / joint / case-by-case negotiation].
   9.3 No commercial license is granted by this agreement.

10. PUBLICATION AND ATTRIBUTION
   10.1 The Recipient cites the dataset and funding source using the
       text in Appendix B in every output.
   10.2 Manuscripts are shared with the Provider [n] days before
       submission for comment on privacy and accuracy only.
   10.3 Authorship: [named analysts / consortium authorship policy].

11. BENEFIT SHARING
   11.1 Non-monetary: [training for Provider-site staff, shared
       code, aggregate results returned to communities].
   11.2 Monetary: [none / stated terms].
   11.3 For non-human or biodiversity data: the parties comply with
       applicable benefit-sharing requirements for digital sequence
       information.

12. BREACH, AUDIT, AND COMPLIANCE
   12.1 The Provider may audit compliance [annually / on cause].
   12.2 The Recipient certifies annually that use remains in scope.

13. RETENTION, RETURN, AND DESTRUCTION
   13.1 End date: [YYYY-MM-DD] or [grant end date].
   13.2 At the end date: destroy all copies and certify destruction
       in writing within  days, or archive under a successor
       agreement.

14. TERMINATION
   Either party may terminate for material breach on  days
   written notice. Section 13 applies on termination.

15. LIABILITY, INDEMNITY, AND GOVERNING LAW
   15.1 Liability and indemnification: [negotiated text].
   15.2 Governing law: [jurisdiction]. Venue: [city].

16. SIGNATURES AND VERSION CONTROL
   Authorized signatures and dates. Any amendment is a new numbered
   version that supersedes prior versions and is logged in the
   governance register.

Appendix A: approved sites, sub-recipients, and linked datasets
Appendix B: dataset citation text and accession or DOI
Appendix C: checksum manifest reference and verification procedure

Filling In the Template: A Worked Walkthrough

The running example, which doubles as a filled-in template example, is a consortium release of 1,000 whole genomes with harmonized phenotypes, moving from a coordinating center to two university analysis sites. The same steps work for a two-party transfer or a ten-site consortium.

Step 1: Inventory the Data

List every file you intend to share, with sizes, before you write a word of the contract.

cd /data/consortium/release_v1/
find . -type f \( -name "*.cram" -o -name "*.vcf.gz" -o -name "*.tsv" \) -printf "%s\t%p\n" | sort -k2 > data_inventory.tsv
wc -l data_inventory.tsv

The find options mean this: -type f selects regular files, the parenthesized -name tests select CRAM alignments, bgzipped VCFs, and TSV tables, and -printf "%s\t%p\n" writes each file's size in bytes, a tab, and its path. sort -k2 orders by path so the inventory is stable across runs. Expected output:

1287 data_inventory.tsv

Total the volume:

awk -F"\t" '{s+=$1} END {printf "%.1f TB\n", s/1e12}' data_inventory.tsv

24.6 TB

Every file in this inventory is a file the DSA must describe in Section 3. A file that appears on disk but not in the consent registry is a stop signal, not a footnote.

Step 2: Classify Identifiability and Pick the Access Model

Genomic data resist anonymity. The General Data Protection Regulation (GDPR), the European Union's data protection law, treats genomic data as inherently identifiable and imposes strict limits on sharing them [7]. Classify your release honestly, then pick the access model that matches.

Coded means direct identifiers are replaced with a study ID, while the genome itself remains identifying. For coded individual-level human genomics, controlled access is the default. PRIMED paired coordinated dbGaP applications with its Consortium Data Sharing Agreement, and used federated analyses as the alternative when individual-level data could not be shared at all [2]. Write your choice into Section 5.1, and write the analyst names or the role-based rule into 5.2.

Step 3: Map Consent to Permitted Use

Build a two-column mapping before you touch Section 4. Left column, each operative element of the consent. Right column, the clause that will enforce it.

The mapping exposes the single most dangerous drafting error, a permitted use clause broader than the consent that underwrites it. Section 4 can never exceed Section 6.

Broad consent is achievable when the form is concrete. On a pan-European real-world data platform, 74.9% of rheumatology outpatients (292 of 390) signed a broad consent for data donation [8]. Practice varies widely elsewhere. Across 200 genomics and biobanking protocols reviewed in Zimbabwe, 99 (49.5%) used specific consent, 37 (18.5%) used broad consent, and 37 (18.5%) used blanket consent [6]. Whatever your mix, the DSA inherits the narrowest element, not the broadest.

Step 4: Size Storage and Write the Security Clause

Size storage before you promise return and destruction, because the end-of-project clause is only credible if the recipient can actually comply. A 30x human whole genome stored as CRAM against a shared reference commonly occupies tens of gigabytes. For planning, assume 25 gigabytes per genome. One thousand genomes need about 25 terabytes of primary storage. Add roughly 20 percent for indices, working copies, and the next release, and you provision about 30 terabytes.

Then write the security clause with values, not adjectives. Encryption at rest means the data are encrypted on disk and decryption requires a key held separately, for which AES-256 is the common standard. Encryption in transit means Transport Layer Security (TLS) on every transfer channel. Require named individual accounts, least privilege, audit logs the provider can inspect, and an incident notification clock. Seventy-two hours is a common drafting choice, and any fixed number beats the word promptly. Pin the approved environments in Section 5.4 so that no copy can legally land on a laptop. PRIMED implemented its sharing on the NHGRI Analysis Visualization and Informatics Lab-space (AnVIL) cloud platform, an example of naming the tenancy in advance [2].

Step 5: Pin the Data Standards

Name formats, reference build, and data model with version numbers. The GREGoR Consortium built a common Consortium Data Model to standardize participant, family, phenotype, and assay level metadata across distributed rare disease sites, with a modular architecture that links multiple data versions from multiple omic technologies to a single individual [9]. Its harmonized, analysis-ready release now covers 12,292 participants in 5,029 families, and other rare disease efforts have begun adopting the model [9]. You do not need their model, you need a named one. Section 7.2 should read like the template, a build plus a checksum, because a reference mismatch silently changes alignment statistics and variant calls.

Required metadata minimums for Section 7.4: the sample join key that links sequence files to phenotypes, the assay platform, and the processing pipeline version. Without those three, harmonization across sites fails for reasons nobody can debug later.

Step 6: Manifest, Transfer, and Verify

Generate the manifest at the source, before any transfer. A checksum is a fixed-length fingerprint of a file's bytes, and any change to the file changes the fingerprint. A manifest is the list of files with their checksums.

cd /data/consortium/release_v1/
find . -type f ! -name manifest.md5 -exec md5sum {} \; | sort -k2 > manifest.md5
head -n 3 manifest.md5

Expected output:

3f5a8c2e91b74d0f6a2c8e1d904b7f33  ./WGS/sample_0001/final/sample_0001.cram
c41d9e77a02b3f5c8d6e1a904b7f352  ./WGS/sample_0002/final/sample_0002.cram
9b2e4d1c8a7f3e50b6c2d914a8f7e331  ./WGS/sample_0003/final/sample_0003.cram

Transfer with rsync, which copies efficiently and can verify as it goes:

rsync -avcP /data/consortium/release_v1/ [email protected]:/data/incoming/release_v1/

The flags matter. -a is archive mode, which recurses and preserves times and permissions. -v prints each file. -c compares checksums rather than timestamps and sizes before skipping a file, which is slower and correct. -P combines progress display with partial-transfer resumption.

On the receiving side, verify:

cd /data/incoming/release_v1/
md5sum -c manifest.md5 | head -n 2
md5sum -c manifest.md5 | grep -cv ": OK$"

Expected output:

./WGS/sample_0001/final/sample_0001.cram: OK
./WGS/sample_0002/final/sample_0002.cram: OK
0

Zero is the only acceptable result from the second command. Then confirm the files are structurally sound, not just byte-identical:

samtools quickcheck -v WGS/*/final/*.cram && echo "All CRAM headers OK"
bcftools stats variants/joint/joint_call.vcf.gz | grep "^SN" | head -n 4

Expected output:

All CRAM headers OK
SN	0	number of records:	48219374
SN	0	number of no-ALTs:	4012533
SN	0	number of SNPs:	39874221
SN	0	number of MNPs:	1024587

The record counts here are illustrative. What matters is that the recipient's counts match the provider's stated counts in Appendix C. Finally, confirm the sample set matches the consent registry:

grep "cram" data_inventory.tsv | cut -d/ -f3 | sort -u | wc -l

1000

Common errors and their fixes:

Checksum mismatch after transfer.

md5sum: WARNING: 1 computed checksum did NOT match

Compare byte sizes at both ends with stat -c %s, re-run the rsync, and never rebuild the manifest on the receiving side to make the warning go away. A rebuilt manifest verifies nothing.

Truncated CRAM.

sample_0007.cram was truncated

The transfer was cut off mid-file. Re-transfer that file, then rerun quickcheck.

Permission failure during transfer.

rsync: send_files failed to open "/data/consortium/release_v1/WGS/sample_0003/final/sample_0003.cram": Permission denied (13)

Grant the transfer account read access through the group or ACL, or pull as a user who already has read rights.

Step 7: Execute, Version, and Register

Have an authorized institutional official on each side sign, not the analyst. Store the executed PDF alongside the manifest in immutable storage, and log the agreement version, signatories, and end date in a governance register. Calendar two dates now: the annual certification under Section 12.2 and the destruction date under Section 13.1. When the science changes, cut a new numbered version rather than annotating the old one.

Storage, Security, and Bioinformatics Data Management in Practice

The security clause in the template is a floor, and day-to-day bioinformatics data management is where it gets enforced. Treat the release of record as immutable. Once manifest.md5 is generated for version 1.0, nothing under that release directory changes. Corrections go into version 1.1 with a fresh manifest, and a new agreement version if the change is material. Keep three artifacts in a separate, access-restricted store: the manifest, the consent registry, and the executed agreements. Those are the documents an auditor asks for first, and they are the ones that prove which genome belonged to which consent.

Genomics data storage deserves stricter treatment than ordinary research data, because treating genomic data as inherently identifiable matches the technical reality as well as the legal position under the GDPR [7]. Practical consequences for the storage clause: encryption at rest with keys managed outside the storage system, no direct human access to raw buckets, workspaces for analysis instead, and log retention long enough to reconstruct who touched what. Recipients also inherit the aggregate protections in Section 6.3. Cell suppression, hiding counts below a threshold so that small groups cannot be singled out, only protects participants if every recipient honors it in every publication, which is why the duty lives in the contract rather than in a data dictionary.

Consent, Governance, and the Limits of a Contract

Participant agreement to broad data sharing in informed consent is often required for research participation, because it is what makes data as open as possible [1]. The contract's job is the other half, as closed as necessary, and no consent form can define that in advance [1]. The DSA, the governance register, and the audit cycle carry that weight.

A signed PDF is not enforcement. The Uganda evaluation found that although all three institutions had DSAs, legal enforceability remains challenging [4]. The practical response is to make compliance observable: annual certifications, audit rights, versioned releases, and a destruction certificate at the end. Consent practice itself varies more than most teams assume, and the DSA inherits the narrowest element of whatever consent applies.

Cross-Border Transfers and Benefit Sharing

Cross-border sharing adds three layers: consent standards that differ by country, ethics review for multi-site projects, and governance frameworks that must align with institutional and regulatory requirements on both sides [5]. The UCAN CAN-DU collaboration, which moves phenotypic, genomic, health economic, and patient-reported data between centers in Canada and the Netherlands, turned those barriers into a practical playbook by pairing expert consultation across bioethics, privacy, law, and bioinformatics with a real operating collaboration [5]. The lesson for your template is to name the legal basis on each side. The Uganda evaluation built its DSA checklist from the Malabo Convention and the Uganda Data Protection and Privacy Act [4], and your agreement should cite its own named instruments with the same precision.

If your agreement covers non-human or biodiversity genomic data, add the benefit-sharing layer. In October 2024, parties to the United Nations Convention on Biological Diversity agreed a multilateral mechanism to fund conservation through benefit sharing from digital sequence information (DSI), the genetic and biological sequence data held in databases [10]. Decision 16/2 asks databases to notify users and submitters about the mechanism, improve metadata on the geographic location of sample collection, and keep terms of use consistent with open access [10]. Section 11.3 of the template exists for exactly this, and non-monetary benefits such as training, publications, interoperability, and capacity building are the currency most collaborations can actually deliver [10].

When a Federated Design Beats a Transfer

Sometimes the right answer is that the data never move. The WiNGS-API platform for rare disease genomics connects seven centers in a federated design, holding over 6,400 samples with single-nucleotide variant calls, 1,500 with copy-number variant calls, and 500 with structural variant calls from long-read sequencing, and answers variant-level queries without any central transfer of genomes [7]. Federated querying finds additional carriers and false positives and improves variant interpretation in ways single-institution data cannot [7].

Federated computing generalizes the idea. Analytic code travels to each institution's data, and only encrypted, aggregated results come back, which preserves institutional control and can reduce or eliminate the need for complex data-use agreements [11]. PRIMED used federated analyses as its fallback whenever individual-level data could not be shared within the Consortium [2].

A caveat from practice: federated designs change Section 5 of the agreement, not the whole document. You still need clauses for query scope, output review with small-cell suppression, intellectual property, publication, and audit. The data staying put does not make the governance optional.

Common Mistakes and Limitations

1. Permitted use broader than consent. If Section 4 grants anything Section 6 does not, Section 4 is the clause that changes.
2. Silent sub-sharing. Any downstream transfer without a named entry in Appendix A is a violation waiting to be discovered. Write 5.3 as a prohibition with a named exception list.
3. Missing retention and destruction terms. The end of a grant is the moment data leak, because nobody owns the shutdown. Put the date and the certification in the contract.
4. Vague intellectual property. Stating that the recipient owns derived results without defining derived data invites a dispute over whether a derived model is a product. Define derived data in Section 2.
5. No named data standards. Differing standards are a documented barrier to sharing across borders and sites [5], and a named data model with a version number is the fix [9].
6. Treating the signature as enforcement. Enforceability is a known weak point even where agreements exist [4], so fund the audits and certifications that make compliance observable.
7. Assuming coded genomics is anonymous. Genomic data are treated as inherently identifiable under the GDPR [7], and your security clause should be written as if that were true everywhere.
8. Manifests generated after transfer. A manifest built on the receiving side verifies nothing. Generate it at the source and ship it with the data.
9. One-version-forever agreements. Consent, law, and personnel change. Re-execute a numbered version on material change, and log it.
10. The limitation of any template. This guide is drafting guidance from a bioinformatics perspective, not legal advice. Individual agreements turn on consent language, institutional policy, and jurisdiction in ways no template can see, so every executed version needs review by your institution's counsel.

Frequently Asked Questions

What is the difference between a genomics data sharing agreement and a data use agreement?

A data sharing agreement covers the whole lifecycle of a transfer, including the data description, security duties, sub-sharing rules, retention, and destruction. A data use agreement usually refers to the use restrictions placed on a recipient. One signed instrument can serve both purposes, and the template in this guide is built that way.

Can I use a free genomics data sharing agreement template as-is?

Use a free template as a drafting scaffold, not as a signature-ready contract. Enforceability, consent scope, and liability terms are institution and jurisdiction specific, so your contracts office or counsel must review the final text before anyone signs.

Which clauses matter most for human genomic data?

Consent scope, the re-identification prohibition, storage and security duties, sub-sharing restrictions, and retention with destruction. Get those five right and most disputes never start.

How does the agreement interact with participant consent?

The consent sets the outer limit of what any recipient may do, and the agreement operationalizes that limit in contract language. If the permitted use clause is broader than the consent, the permitted use clause is the one that changes.

What should the storage and security clause say?

Name the encryption standard for data at rest and in transit, require named individual accounts, require audit logs the provider can inspect, pin the approved computing environments, and set a fixed clock for breach notification.

When should we choose federated analysis instead of transferring data?

Choose federated designs when law, consent, or institutional policy blocks the transfer, or when only summary results are needed for the science. The data stay at each center and only aggregated or encrypted results move.

What file formats and standards should the agreement name?

Name the alignment format (CRAM), the variant format (bgzipped VCF), the reference build with its checksum, and the consortium data model with a version number. Versioned standards keep releases comparable across sites and across years.

Who should sign the agreement and how is it enforced?

An authorized institutional official signs on each side, not the analyst who will touch the data. Enforcement comes from audit rights, annual use certifications, and termination for material breach, backed by the destruction procedure.

Sources

1. Navigating data sharing in research.
2. Data sharing in the PRIMED Consortium: Design, implementation, and recommendations for future policymaking.
3. Implementing a national programme of pathogen genomics for public health: the Australian Pathogen Genomics Program (AusPathoGen).
4. An evaluation of the ethical- regulatory practices for genomic data sharing at three research-intense institutions in Uganda.
5. A roadmap for navigating child health research data sharing across Canada and beyond - building on UCAN CAN-DU.
6. Strengthening ethical oversight in genomics and biobanking: a retrospective analysis of research practices in Zimbabwe.
7. WiNGS-API: a federated genome/phenome data sharing platform enabling gene discovery and variant classification for rare diseases.
8. High Patient Willingness to Grant Broad Consent for Real-World Data Use in Rheumatology-Implications for Real-World Data Platform Governance: Cross-Sectional Study.
9. Building an Interoperable Rare Disease Multi-omic Resource: The GREGoR Data Model and Dataset.
10. How can biological databases support the new UN mechanism for benefit-sharing from digital sequence information?
11. Federated Computing in Orthopaedic Surgery: A Paradigm Shift in Collaborative Multicenter Research.