← All resources

Research Data Partnerships: Setting Them Up and Analyzing the Data

15 min read
research data partnerships
Research Data Partnerships: Setting Them Up and Analyzing the Data

Research Data Partnerships: Setting Them Up and Analyzing the Data

Researchers reviewing a data-sharing agreement

A research data partnership is a formal arrangement in which a data provider (a hospital system, a university, a school district, a company) gives your team access to data for a defined research purpose, under written terms. Getting one to work takes four things: a data sharing agreement, a legal basis for processing, a realistic approval timeline, and an analysis workflow that keeps the data protected and the results reproducible. This guide walks through each, with the sources we relied on.

Plotstudio
Keep Research Analysis Reproducible
PlotStudio AI helps researchers analyze tabular data with reviewable methods, code, and results, with local analysis for privacy-sensitive workflows.
Visit PlotStudio AI

TL;DR

  • Put every partnership under a written data sharing agreement (DSA) that defines purpose, data types, security, and intellectual property.
  • Ask only for the data you must have. A narrower request is easier to review and shows data minimization.
  • For health research under UK GDPR, you need both an Article 6 lawful basis and an Article 9 condition. Consent is usually not the recommended basis.
  • Treat data acquisition as its own project with its own timeline. It routinely takes longer than researchers expect.
  • Record provenance from day one, so a supervisor, reviewer, or the provider can see how each number was produced. Local, agentic analytics tools such as PlotStudio AI are built for this.

Table of Contents

What a research data partnership actually is

The phrase covers a wide range. At one end sits a single PhD student negotiating access to a clinical registry. At the other sits a multi-institution consortium, or a public-private arrangement such as the one NIH described in 2018 when it planned to work with commercial cloud providers to improve access to biomedical data. What they share is structure: someone holds data, someone wants to analyze it, and a document says who may do what.

The providers you will meet in practice are usually the organizations that originally collected the data, for example NHS Trusts or universities. According to the NHS AI and Digital Regulations Service, the original purpose of collection may have been clinical care or earlier research, and that history shapes what the provider can lawfully share with you.

The most useful framing comes from a guide to developing data sharing agreements from MDRC, written for postsecondary institutions sharing individual-level data with research teams. It argues that effective agreements rest on shared goals and mutual benefit, not on one-way data extraction. That is practical advice, not etiquette: partners who benefit from the work answer emails, correct data dictionaries, and renew access.

Start with the written agreement

The Future of Privacy Forum’s best practices for sharing data with academic researchers recommends that sharing personal data with academic researchers be subject to a written contract. That contract should define the scope and purpose of the research and describe the types of data provided. It should also contain binding provisions on security, privacy, and intellectual property.

In practice, a workable DSA covers these items:

Clause What to pin down Why it matters later
Purpose and scope The research question and any permitted secondary uses Prevents disputes when you want to extend the analysis
Data description Tables, variables, time window, level of identifiability Anchors the data dictionary and your minimization argument
Ownership and permitted use Who holds the data, what you may do with derived outputs Determines what you can publish or deposit
Security safeguards Encryption, access controls, where analysis may happen Decides which tools you are allowed to use
Breach notification Who is told, how fast A contractual duty, not a courtesy
Publication and review Whether the provider sees drafts, and for how long Avoids a surprise delay at submission
End of project Retention, return, or destruction Often forgotten until an audit

The security row deserves particular attention. If the agreement says data may not leave a controlled environment or be uploaded to third-party services, that constrains your software choices before you write a line of code. Plain-language overviews of why these obligations exist, such as this data privacy guide for IT decision-makers, are useful to share with a non-technical sponsor or departmental IT contact who has to sign off on the arrangement.

Ask for less

The MDRC guide’s advice is to avoid requesting everything available. Prioritize your must-haves. A shorter variable list reduces the complexity of legal review, speeds negotiation, and demonstrates data minimization, which is a core principle for sensitive research data. If you realize midway that you need an extra variable, an amendment is usually easier to justify than an overbroad first request.

A simple test: for each requested variable, write the analysis step that uses it. Variables with no step attached come off the list.

Requested variables matched to analysis steps

If your data include health records or other special category data, UK GDPR requires two things. The Health Research Authority describes the structure: a lawful basis under Article 6, and a specific condition under Article 9. For research, the Article 9 condition most commonly relied on is 9(2)(j), scientific research in the public interest, with appropriate safeguards.

The common misunderstanding is that consent is the safest Article 6 basis. The NHS AI and Digital Regulations Service states that the ICO and the HRA strongly recommend against using consent as the lawful basis for health and social care research. They point instead to task in the public interest for public bodies, or legitimate interests for others. Note that this is separate from consent to participate in a study, which is an ethical and common-law matter. Confirm which applies to your project with your data protection officer and sponsor.

This guidance is specific to the UK. If your partnership involves US data, different rules apply (HIPAA and your institution’s IRB, for example), so ask your IRB and privacy office which regime governs the provider’s data. If you work with EU data, the same GDPR structure applies, with national variations.

If you are documenting this for a controller or an ethics committee, our guide on logging Article 6 and 9 proof for GDPR PII categories shows how to keep that record alongside the analysis.

Legal basis: what health researchers get wrong — overview diagram

Trusted Research Environments

Where data cannot go to standard cloud platforms, the NHS guidance on complying with UK GDPR describes applying to intermediaries such as NHS Digital, a research database, or a Trusted Research Environment or Secure Data Environment. Both terms refer to a controlled digital environment. If your provider offers one, plan your analysis to fit inside it. If it does not, ask what local processing arrangements the DSA will allow.

Plan the approval timeline as its own project

The NHS guidance on getting data from data providers is blunt about timing: researchers often underestimate how long institutional approval takes. Our reading is that you should run acquisition as a parallel project with its own schedule, contingency, and named people.

For a thesis with a fixed deadline, that translates into a few habits:

  1. Start the data request before the protocol is finished. Open the conversation with the provider’s data office early, even if the analysis plan is rough.
  2. Write the statistical analysis plan while you wait. Use synthetic or public data to test code paths so the real data run is a rerun, not a first attempt.
  3. Map who decides what. The ten simple rules for organizations supporting data sharing describes a RACI matrix (Responsible, Accountable, Consulted, Informed) used in research data management services. Borrow it: for each approval, name the person who is responsible and the person who is accountable.
  4. Build in a slip. If you need data by month three of a twelve-month analysis, plan as though it arrives in month five.

Make the partnership FAIR from the start

Funders and journals increasingly expect that outputs stay findable and verifiable after a project ends. Science Europe’s practical guide to research data management asks plans to say how and when data will be shared, and whether restrictions or embargoes apply, including deposit in a trustworthy repository.

For partnership data that cannot be deposited, FAIR still applies to everything around it. A paper in Philosophical Transactions of the Royal Society A on a FAIR data pipeline describes a chain of trust connecting primary data to research outputs through open, publicly accessible analysis and modelling code. You may not be able to publish the patient-level table. You can almost always publish the code, the metadata, and the method.

In practice, put these in the DSA or a schedule attached to it:

  • A data dictionary with variable definitions and units.
  • The version or extract date of the data, so reruns refer to the same snapshot.
  • Whether derived, aggregated, or synthetic outputs may be shared, and under what conditions.
  • Persistent identifiers for yourself (an ORCID) and for any outputs that can be deposited.

Where analysis happens decides what you can promise

Many partnership problems surface at the analysis stage. The agreement permits research use, but the researcher pastes an extract into a cloud chatbot, and the DSA’s security clause is quietly breached. Before choosing tools, ask three questions:

  • Does the DSA permit the data to leave the machine or environment it was delivered to?
  • Can you show, for every figure in the manuscript, the code and data version that produced it?
  • If the provider asks for an audit, can you hand over something other than a folder of scripts named final_v7?

Tools that run analysis locally answer the first question by design. Reproducible outputs answer the second and third. We cover the principles in more detail in our pieces on on-device data analysis and audit-ready data lineage, and the broader landscape in our guide to data collaboration platforms.

An agentic layer, not a replacement

R, Python, Stata, SPSS, SAS, RStudio, and Jupyter provide the statistical computing in most research groups, and that does not change. What many teams lack is time and coding fluency, especially clinicians and PhD students who were never trained to program. Agentic analytics adds a layer on top of those tools: agents that plan an investigation, write and run real code, inspect intermediate results, and document the whole thing. That is different from one-shot chat with a dataset, where you get an answer and a chart with little record of how they were produced.

Our perspective

We build PlotStudio AI, so we see the same pattern repeatedly. A partnership gets signed, the data arrive, and the weak point is not the legal text. It is the gap between what the DSA promises and what the analysis workflow can demonstrate.

Four convictions come out of that:

  • Local execution is a governance feature. When analyses run on the researcher’s own machine, the question of where patient or participant data went has a short answer. That matters for clinical researchers and anyone handling GDPR special category data.
  • The plan should be reviewable before the code runs. In PlotStudio AI, Plan Mode lets you read and change the proposed methods, assumptions, and steps before execution. A supervisor or a data provider’s statistician can disagree with the approach at the right moment, not after the numbers are in the draft.
  • Methodology should be encoded, not remembered. Skills let a lab or group record its required procedures, statistical conventions, and reporting expectations, so analyses follow the group’s method rather than a generic workflow.
  • The output is the audit trail. Analysis Pages, notebooks, and PDF reports keep the methodology, code, statistics, and visualizations available to anyone who needs to inspect how a result was produced.

None of this removes the need for a biostatistician’s judgment. It reduces the time between a signed agreement and an inspectable result, and it leaves evidence behind.

— Aymen

A worked example: from signed DSA to defensible results

Consider a hypothetical clinical PhD student with a DSA covering a de-identified extract from an acute medicine registry. The study asks whether a treatment variable is associated with time to readmission. The sequence below shows how the pieces fit together. This is an illustration, not a real study.

  1. Scope the request. The student lists the outcome, exposure, and covariates, and drops everything without an analysis step. The DSA names those variables and the extract date.
  2. Confirm the legal footing. The sponsor and data protection officer record the Article 6 basis and Article 9(2)(j) condition, as the HRA describes.
  3. Write the plan. A time-to-event question points to survival methods, such as Kaplan-Meier curves and a Cox proportional hazards model, with the proportional hazards assumption checked. The student writes the objective and constraints (for example, handling of missingness and any multiple-comparison correction) before touching the data.
  4. Review before execution. The supervisor reads the plan, and the student edits the approach where needed.
  5. Run locally and inspect. The analysis runs on the machine the DSA permits. Intermediate output (model diagnostics, missingness patterns) is checked before the final model is accepted.
  6. Export the record. A notebook and a report capture the code, outputs, and statistics. The provider or a reviewer can follow the same steps.

Every stage leaves a document, which is what a partnership needs when someone later asks how a number was produced.

Trying PlotStudio AI in a partnership workflow

PlotStudio AI is an AI-powered desktop analytics application for researchers, with privacy-first local processing, reproducible audit trails, and export to PDF and Jupyter Notebook. It supports Python and R workflows, and statistical methods including regression, ANOVA, mixed-effects models, survival analysis, and Cox proportional hazards models.

The published options, as listed on our site:

Option Price Notes
Free Trial No published price Start on the pricing page
Bring Your Own Key $39.99 per month Monthly plan on the pricing page
Bring Your Own Key (annual) $399.90 per year Available on the academic page
Managed Credits $69.99 per month See the pricing page
Enterprise pilot $500 one-off pilot fee Details on the enterprise page

If your group is a research team that wants to work with us directly, see our research partners program. For the healthcare setting specifically, our guide to secure analytics for healthcare researchers and the privacy-first analytics guide explain how local agentic workflows fit.

A checklist before you sign

  • The DSA states purpose, data types, security safeguards, ownership, permitted use, and breach notification.
  • Your variable list is justified line by line.
  • The legal basis and special category condition are recorded and agreed with your data protection officer.
  • The agreement says where analysis may take place, and your tools match.
  • Your timeline treats acquisition as a separate project, with a buffer.
  • You know who is responsible and accountable for each approval.
  • The data version, dictionary, and provenance plan are attached to the agreement.
  • The publication and end-of-project terms are clear.

For more on the ethics and privacy side of this work, browse our articles on ethical data usage and data privacy considerations, or the wider research data analysis collection.

FAQ

Do I always need a data sharing agreement?

For personal data shared with academic researchers, best practice is a written contract. The Future of Privacy Forum recommends one that defines scope, purpose, data types, and binding security, privacy, and intellectual property terms. Your institution may also require one regardless of the data’s sensitivity, so ask your research office.

Usually not. The ICO and the HRA strongly recommend against consent as the lawful basis for health and social care research, pointing instead to task in the public interest or legitimate interests. This is different from consent to take part in a study. Confirm the correct basis with your sponsor and data protection officer.

How long does it take to get data from a provider?

No single figure applies, and NHS guidance warns that researchers often underestimate it. Plan acquisition as a separate project with its own timeline and contingency. Start the request as early as possible, and prepare your code on synthetic or public data in the meantime.

What should I do if my data cannot be uploaded to cloud tools?

Check whether the provider offers a Trusted Research Environment or Secure Data Environment, and fit your analysis to it. Otherwise, ask what local processing the agreement permits. Tools that run analysis on your own machine, such as PlotStudio AI, can suit that constraint, but confirm with your data protection officer that the arrangement meets the agreement.

Sources

Research Data Partnerships: Setting Them Up and Analyzing the Data | PlotStudio AI