# Resolving Data Ownership Disputes in Collaborative Research The most common cause of a data ownership dispute in collaborative research is simple and preventable. The collaboration began without a written agreement that says who owns the data, who may use it, and under what conditions. Reviews of multi-national, multi-institutional genomic collaborations found that international guidelines are largely silent on data sharing questions that arise inside a consortium, and that the absence of guidance threatens the success of research ventures that depend on trust between investigators [1]. The first thing to check is the written record. Pull the collaboration agreement, the subaward terms, the consortium bylaws, the grant application, and any email that describes what each site agreed to contribute. Most disputes soften once both parties can see what was actually promised, because many disputes are about use rights, credit, or privacy constraints rather than legal ownership itself. This article walks through the causes in order of frequency, gives you a troubleshooting table, a short diagnostic sequence, and the fixes that multi-institutional consortia have actually used. ## What Data Ownership Means in a Research Collaboration Data ownership is the set of legal rights over a dataset, including the right to control access, copy it, transfer it, and license it. In academic settings, ownership usually sits with the institution that employed the investigators and funded the infrastructure, not with the individual researcher. Data stewardship, sometimes called custodianship, is the operational responsibility to store, secure, document, and share the data according to agreed rules. A dataset can have one owner and several stewards. Three distinctions prevent most confusion before it starts. First, legal ownership is different from the right to use data. A collaborator can hold a license to analyze a dataset without owning it. Second, ownership of raw source data, such as hospital electronic health records, is different from ownership of aggregate results, such as a summary table produced from pooled analysis. Consortia often treat these differently. The Eastern Pediatric Surgery Network, for example, made legal ownership of aggregate data one of the four pillars on which its entire governance structure rests [2]. Third, ownership is different from credit. Authorship, acknowledgement, and inventorship are separate questions that get tangled into ownership arguments when they were never settled in writing. A data use agreement is a contract between institutions that spells out permitted uses, security obligations, publication rights, and restrictions on redistribution. A data sharing plan is the section of a grant or protocol that describes what data will be shared, with whom, and when. These two documents are the main tools for resolving and preventing disputes, and the rest of this article shows how to use them. ## Why Data Ownership Disputes Happen Understanding the mechanism behind each cause tells you which fix will work. **No prospective agreement.** This is the dominant cause. When investigators at multiple institutions begin a project on goodwill alone, every later question about access, reuse, and credit has no written answer. Guidance on intra-consortium data sharing developed for international genomic collaborations concludes that a data sharing policy should be negotiated and concluded between collaborators as early as possible, before data exist and positions harden [1]. **Institutional ownership surprises investigators.** Researchers often assume the data belong to them because they generated them. In most funded research, the institution holds the rights, and the principal investigator controls the data only as the institution's delegate. When a collaborator asks for the dataset, the individual scientist may want to share it but cannot, because the transfer decision belongs to a legal or compliance office. The dispute then looks personal when it is actually institutional. **Regulatory barriers get read as refusal.** Before multi-site work can begin, a complex set of administrative and regulatory requirements must be navigated, including institutional review board (IRB) approvals, data sharing permissions, and subawards. Staff involved in several multi-institutional comparative effectiveness studies developed novel approaches to secure IRB approvals, enable data sharing, and expedite subawards for minimal risk studies, precisely because these steps delay projects when handled one site at a time [3]. A collaborator who says "I cannot send the data yet" may be describing a compliance queue, not a claim of ownership. **Standards and harmonization friction.** Heterogeneous information models and terminologies across institutions are a recognized barrier to combining clinical data. An international effort to define clinical data elements for clinical decision support found 131 data elements in current use across 20 institutions in 4 nations, and built consensus standards around them [4]. When one site's "surgery date" is defined differently from another's, arguments about who may merge or transform the data often mask a deeper technical problem. Projects that skip harmonization discover it late, and dataset development itself can take as long as two years to produce validated, reliable data even when electronic sources already exist [5]. **Credit and secondary use were never defined.** A site contributes patients, samples, or effort, then watches another group publish the analysis without them. The dispute is framed as ownership but is really about authorship and about whether the original agreement permits secondary analyses on new questions. **Privacy and cross-border law.** Health data, genomic data, and identifiable records carry legal restrictions on transfer that differ by jurisdiction. European experience with regional health data ecosystems shows that legal and interoperability constraints shape what can leave an institution, even inside a single country's research network [6]. When international partners face these constraints, silence over transfer rights turns into a standoff. ## Troubleshooting Table Use this table to match the symptom you are seeing to the likely cause and the fastest fix. | Symptom | Likely cause | How to confirm | Fix | |--|--|--|--| | A collaborator stops sharing data after analysis begins | No written data sharing terms were set before work started | Search grant applications, emails, and bylaws for any written commitment | Draft a retroactive data sharing agreement covering use, publication, and credit [1] | | An institutional legal or compliance office blocks the transfer | The institution, not the investigator, holds the rights | Ask the tech transfer or legal office which policy and award terms apply | Negotiate a data use agreement with defined permissions rather than demanding an ownership transfer | | Conflict erupts only at manuscript submission | Authorship and credit were never tied to data contribution | Review the contribution record and any consortium authorship policy | Add credit rules to the governance document before the next dataset is assembled [2] | | Each site sends incompatible files and the merge fails | No shared data dictionary or standard | Compare variable definitions, units, and coding across sites | Build the data dictionary on an existing standard such as a registry standard where one applies [5][4] | | IRB review stalls the transfer for months | Regulatory process, not ownership, is the bottleneck | Check whether a reliance agreement or IRB approval covering data sharing exists | Use single IRB reliance and streamlined data-only pathways for minimal risk research [3] | | A site insists raw data stay behind its firewall | Privacy or legal constraints on transfer | Ask directly which constraint applies, legal or policy | Propose federated analysis in which only aggregate results leave the site [7][8] | | Nobody can identify the master copy of the dataset | No coordinating center or custodian was appointed | Map who holds which file version and when it was last updated | Appoint a coordinating center as the neutral custodian of record [9] | | A partner objects to reuse of the data for a new question | The original agreement is silent on secondary use | Re-read the consent language and the agreement | Negotiate secondary use terms prospectively for all future projects [1] | | An international collaborator cannot ship data at all | Cross-border transfer restrictions under privacy law | Identify which country's law governs the agreement | Adopt a hub-and-node design in which data stay local and only queries or models move [10][6] | | Sites distrust the pooled dataset because quality differs | Harmonization and validation were skipped or rushed | Run a cross-site comparison on a small sample of records | Invest in harmonization and validation before analysis, and budget the real timeline [5][11][12] | ## A Short Diagnostic Sequence ![Steps from reading the written record through sorting the issue and choosing a fix to writing down the resolution.](/article-images/illustrations/data-ownership-dispute-resolution-collaborative-research-diagnostic-sequence.webp) Work through these five steps in order. Each step narrows the problem. 1. **Read the written record.** Collect every governing document: the collaboration or material transfer agreement, subaward terms, consortium bylaws, IRB approvals, consent forms, and [data management](/blog/guides/data-management-basics-principles-processes-and-best-practices) plan. Note what each says about ownership, use, and publication. 2. **Classify the real issue.** Sort the disagreement into one or more of five buckets: legal ownership, permission to use, credit and authorship, privacy or regulatory limits, or technical incompatibility. Disputes that mix buckets stay unresolved until you separate them. 3. **Identify the data holder of record.** Confirm which institution legally holds the data and which office can authorize a transfer. A verbal promise from a co-investigator does not move data between institutions. 4. **Choose the class of fix.** Legal fixes are agreements and governance rules. Structural fixes are coordinating centers and governance bodies. Technical fixes are federated architectures and standardized data models. Match the fix to the bucket from step 2. 5. **Document the resolution.** Whatever you agree, write it down, have institutional signatories sign it, and file it with the project's regulatory records. An undocumented handshake resolves today's dispute and plants next year's. ## How to Fix Data Ownership Disputes: Solutions in Order of Usefulness ### Write or rewrite the data sharing agreement If no agreement exists, the fix is to create one now, even if data collection has already started. Agreements negotiated after a dispute carries a cost in trust, so keep the first draft narrow and concrete. Cover who holds legal ownership, who may use the data for which analyses, how results and manuscripts are credited, whether secondary use is allowed and under what approval, and how long each party retains the data. The international genomics review that diagnosed the absent-agreement problem also recommends that sponsors, including sponsors in developing countries, issue detailed guidance on intra-consortium data sharing so that collaborators have a template instead of improvising under pressure [1]. If an agreement exists but is ambiguous, amend it rather than argue from memory. A one-page amendment that defines the disputed term, for example what "aggregate data" means, is faster than renegotiating the whole contract. ### Put ownership rules into consortium governance Single-project agreements do not cover the next project. Consortia that last solve this structurally. The Eastern Pediatric Surgery Network organized itself around four pillars: legal ownership of aggregate data, a horizontal leadership structure, mandatory participation in adopted studies, and a broad research portfolio. Starting from a written vision statement and rules of governance at thirteen divisions in 2020, the network grew to 24 participating centers, produced 28 national conference abstracts and 12 peer-reviewed publications over five years, most without dedicated external funding [2]. The lesson is that settling the ownership question once, in the bylaws, removes it from every future negotiation. ### Appoint a coordinating center as neutral custodian When several sites each hold copies, version chaos invites disputes. A coordinating center (CC) is a designated organizational hub that manages collaboration development, operations, statistical and data management, and communications infrastructure. Experience from the Asia Cohort Consortium shows that a well-run CC prevents many conflicts by giving the collaboration a single authoritative location for harmonized data and a defined process for access requests [9]. If your collaboration has no CC, appoint one institution or one neutral third party, define its authority in writing, and route all data deposits and access decisions through it. ### Standardize the data dictionary early Many ownership arguments are really arguments about whose data definition wins. Build the shared data dictionary on an existing standard where one exists. The Oncoshare project, which integrated longitudinal breast cancer records from multiple institutions, found that basing the data dictionary on established registry standards was one of its key lessons, along with using an authoritative external source for mortality ascertainment rather than local clinical records [5]. The Clinical Sequencing Evidence-Generating Research consortium faced the same problem with survey measures and resolved it by creating a core set of harmonized measures that all sites could share, while minimizing participant burden and allowing data sharing by design [11]. Agreeing on definitions before data flow makes the downstream ownership conversation almost unnecessary. ### Route around the regulatory maze If the dispute is really about approvals, use the mechanisms built for this. Multi-institutional teams in the HMO Research Network accelerated IRB approvals, enabled data sharing, and expedited subawards by developing shared approaches across their research, regulatory, and administrative staff, while maintaining human subjects protections [3]. Ask whether your institutions can enter a reliance agreement so one IRB covers the analysis, and whether the study qualifies for a data-only minimal risk pathway that avoids full review at every site. ### Use federated architectures so data never leave home When the sticking point is the transfer itself, the strongest modern solution is to stop transferring. A federated architecture sends the question to the data instead of the data to the question. The Federated Aggregate Cohort Estimator (FACE) is a reference implementation developed by four institutions that federated diverse SQL sources and an i2b2 instance to estimate combined research subject availability without moving patient-level data, using easily deployed virtual machines that met each site's security requirements [7]. Federated learning extends the same idea to model training. Algorithms let institutions train machine learning models collaboratively on their local datasets without sharing them, and evaluations of federated models for genetic variant classification showed performance generally comparable to or better than centralized training while respecting privacy and legal constraints [8]. The FLAME platform developed in the German PrivateAIM project adds a policy layer to this design, using a hub-and-node architecture with fine-grained access control, audit logging, and distributed enforcement of rules about what each node may execute, demonstrated on clinical and genomic data at university hospitals [10]. The same pattern works for simpler workflows. A cloud-native radiology research platform kept each institution's images and metadata on a local edge server and proxied only critical metadata to a shared cloud database, removing the need for complicated network setups [13]. The ImageMiner pathology platform exposed grid-enabled services so that multiple instances at different institutions could be accessed and federated remotely [14]. If a collaborator cannot or will not release data, offer federation as the alternative. It converts an ownership standoff into an engineering task. **Data safety note.** Any transfer of human subject data, even a "small pilot" file, creates risk if it bypasses the approved pathway. Move data only through mechanisms named in your IRB approval and data use agreement, keep identifiers encrypted in transit and at rest, and log every access. An unauthorized transfer is both a compliance violation and a dispute accelerant. ### Use centralized repositories where trust already exists Federation is not always necessary. When consortium members have a durable governance structure, a central repository with defined access rules is simpler. The ALL ALS consortium, established by the National Institutes of Health, built a centralized infrastructure for collection and storage of longitudinal clinical data and biofluids, deliberately designed for community engagement and equitable access [15]. The Merkel Cell Carcinoma Patient Registry combined a REDCap-based database with a secure, open-access data sharing platform provided by Project Data Sphere, LLC, so that multiple investigators could examine real-world outcome data in real time [16]. Regional ecosystems follow the same logic at larger scale. The Ouest Data Hub in France coordinates clinical data warehouses and data centers across university hospitals, harmonizing data and adhering to standards, and in 2023 it supported access to data from more than 9.3 million patient records for both single-center and multi-center research [6]. Even veterinary and behavioral science uses shared platforms, with the ZooMonitor Community tool giving zoos and aquariums a common system for multi-institutional data sharing and project management [17]. ### Compare repository models before choosing one The right structure depends on trust, privacy law, and technical maturity. Use this comparison to choose deliberately instead of by habit. | Model | Where data live | What moves between sites | Best fit | |--|--|--|--| | Centralized repository | One trusted institution or coordinating center | Full record-level datasets flow in, results flow out | Consortia with strong governance and minimal legal transfer barriers [15][16] | | Federated analysis | Each site keeps its own data | Queries, aggregate counts, or model parameters only | Privacy-sensitive clinical or genomic data, cross-border collaborations [7][8][10] | | Hub-and-node with policy layer | Local nodes under institutional control | Models and analysis code, governed by enforced policies | Multi-institutional AI development with audit requirements [10] | | Registry-based pooling | Harmonized data contributed under registry standards | Curated, standardized variables | Rare disease and long-term outcome research where standardization matters [5][16] | International biobank collaborations illustrate the trade-offs in practice. The StoP project on stomach cancer connects 33 research teams from 15 countries with associated biobanks. A Latvian case study from the project found key challenges in data collection, harmonization, storage, funding, and sustainability, and showed that participation strengthened local infrastructure by updating standard operating procedures and harmonizing retrospective datasets [12]. Choose the model your consortium can actually sustain, not the most ambitious one. ## Prevention Practices Prevention costs far less than resolution, and the practices below come directly from consortia that learned these lessons in production. - **Negotiate before the first byte moves.** Every experienced consortium review converges on the same recommendation: settle data sharing terms as early as possible [1]. Add a data ownership and sharing clause to the collaboration agreement template your department uses by default. - **Write governance, not just contracts.** Adopt the consortium model of fixed pillars, including explicit rules on who owns aggregate data, so that each new study inherits the answer instead of reopening the debate [2]. - **Plan for the real timeline.** Building a validated multi-institutional database took up to two years in one well-documented effort [5]. Budget governance and harmonization time explicitly so that schedule pressure does not push teams into undocumented shortcuts. - **Harmonize measures with sharing in mind.** Select validated instruments that permit data sharing, and distinguish site-specific measures from the consensus core, as the CSER consortium did [11]. - **Give sponsors a role.** Funders and sponsors can issue detailed guidance on intra-consortium data sharing, which gives collaborators a default position to start from rather than a blank page [1]. - **Invest in the coordinating function.** Collaboration development, operations management, data management, and communications infrastructure are the activities that keep a coordinating center useful, and they deserve named staff and funding [9]. - **Document every data flow.** Keep a living inventory of which institution holds which dataset, under which agreement, approved by which IRB. This single artifact resolves most disputes in minutes instead of weeks. ## Common Mistakes and Limitations **Treating the dispute as personal.** Most blocked transfers are institutional policy, compliance queues, or privacy law operating as designed. Assuming bad faith escalates a solvable problem. **Conflating ownership, access, and credit.** Teams burn months arguing about ownership when the actual disagreement is about authorship or reuse rights. Separate the three issues on paper and resolve them one at a time. **Sign the deal after the data exist.** Retroactive agreements are weaker and harder to negotiate fairly, because each party now knows what the data are worth. Early negotiation preserves goodwill [1]. **Skipping the data dictionary.** Teams that merge files without agreed definitions generate a second wave of disputes about whose transformed values are correct. Harmonization is a governance task as much as a technical one. **Assuming federation is free.** Federated designs avoid transfer but add engineering and governance overhead, including policy enforcement and audit logging [10]. Estimate that cost honestly. **One limitation applies to everything above.** The right resolution depends on your specific agreements, institutional policies, and funding terms, and individual cases need review by your institution's legal and compliance offices. The patterns in this article tell you where to look and what has worked for others, not what your signature obligates you to do. ## Frequently Asked Questions ### Who legally owns research data produced under a grant? In most funded academic research, the grantee institution owns the data and the principal investigator manages them on the institution's behalf. Confirm by reading the award terms and your institution's intellectual property policy, because ownership language varies by sponsor and by agreement. ### Can a collaborator refuse to share data and still be a co-author? Yes, co-authorship reflects intellectual contribution to the published work, not unconditional access to the underlying dataset. The practical answer is to settle both access and authorship expectations in the data sharing agreement before analysis begins [1]. ### What should a data sharing agreement include? At minimum, it should name the data owner, define permitted uses, address secondary use, set publication and credit rules, specify security requirements, and state how long each party retains the data. Early, prospective negotiation of these terms is the single strongest recommendation from published consortium experience [1]. ### Is federated analysis a real alternative to transferring data? Yes. In federated designs, each site runs the analysis locally and only aggregates or model parameters are shared, which has been demonstrated for cohort estimation [7], machine learning on genomic variants [8], and privacy-preserving analytics with policy enforcement [10]. ### What is the difference between a data repository and a coordinating center? A data repository is where harmonized data are stored and accessed. A coordinating center is the organizational hub that manages collaboration, operations, data management, and communications across sites [9]. Many large consortia need both, with the coordinating center governing access to the repository. ### How do IRB and privacy rules relate to ownership disputes? They often cause disputes that look like ownership conflicts, because a compliance office may block a transfer the investigator wants to make. Streamlined multi-site approaches such as IRB reliance agreements and data-only minimal risk pathways exist specifically to remove these delays [3]. ### When should a data ownership dispute be escalated, and to whom? ![Decision path asking whether direct negotiation has stalled, then routing to the governance body or to institutional legal offices.](/article-images/illustrations/data-ownership-dispute-resolution-collaborative-research-escalation-path.webp) Escalate to the designated governance body, such as the consortium steering committee or coordinating center, once direct negotiation stalls [9]. If no governance body exists, escalate to the institutional research legal or tech transfer offices, which have authority to bind the institutions that own the data. ### How long does it take to build a shared multi-institutional database? Even when electronic data already exist, one documented multi-institutional effort took up to two years to produce validated, reliable data for research [5]. Plan governance, harmonization, and validation time explicitly from the start. ## Sources 1. [Intra-consortium data sharing in multi-national, multi-institutional genomic studies: gaps and guidance.](https://pubmed.ncbi.nlm.nih.gov/20535402/) 2. [The Eastern Pediatric Surgery Network: Creation and implementation of a comprehensive clinical research collaborative in pediatric surgery.](https://pubmed.ncbi.nlm.nih.gov/41111943/) 3. [Accelerating regulatory progress in multi-institutional research.](https://pubmed.ncbi.nlm.nih.gov/25848593/) 4. [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/) 5. [Oncoshare: lessons learned from building an integrated multi-institutional database for comparative effectiveness research.](https://pubmed.ncbi.nlm.nih.gov/23304372/) 6. [The Ouest Data Hub: An Interregional Health Data Sharing Ecosystem for Research.](https://pubmed.ncbi.nlm.nih.gov/39176533/) 7. [Federated Aggregate Cohort Estimator (FACE): an easy to deploy, vendor neutral, multi-institutional cohort query architecture.](https://pubmed.ncbi.nlm.nih.gov/24316052/) 8. [Federated learning for the pathogenicity annotation of genetic variants in multi-site clinical settings.](https://pubmed.ncbi.nlm.nih.gov/40973651/) 9. [Coordinating centers in cancer epidemiology research: the Asia Cohort Consortium coordinating center.](https://pubmed.ncbi.nlm.nih.gov/21803842/) 10. [Enabling Privacy-Preserving Federated Learning in Healthcare: The FLAME Architecture and Policy Framework.](https://pubmed.ncbi.nlm.nih.gov/42175157/) 11. [Lessons learned about harmonizing survey measures for the CSER consortium.](https://pubmed.ncbi.nlm.nih.gov/33948230/) 12. [Strengthening biobank networks: A Latvian case study within the StoP project.](https://pubmed.ncbi.nlm.nih.gov/41933653/) 13. [Radiology research platform: automating multicenter radiological research workflows using a cloud-native platform.](https://pubmed.ncbi.nlm.nih.gov/42844398/) 14. [ImageMiner: a software system for comparative analysis of tissue microarrays using content-based image retrieval, high-performance computing, and grid technology.](https://pubmed.ncbi.nlm.nih.gov/21606133/) 15. [Access for ALL in ALS: A large-scale, inclusive, collaborative consortium to unlock the molecular and genetic mechanisms of amyotrophic lateral sclerosis.](https://pubmed.ncbi.nlm.nih.gov/39295118/) 16. [The Merkel Cell Carcinoma Patient Registry: From Promise to Prototype to Patient.](https://pubmed.ncbi.nlm.nih.gov/37260629/) 17. [ZooMonitor Community: A Tool for Evaluating Population-Level Behavior Questions.](https://pubmed.ncbi.nlm.nih.gov/42353431/)