# A research participant portal that protects participants first

> From our 2012 to 2023 work with TwinsUK: separate routes for participants and researchers, with recorded human decisions on data access.

Source: https://lastdoorsolutions.com/blog/research-participant-portal

**A research participant portal serves two groups who want different things: the volunteers who give the data, and the researchers who ask for it.** Volunteers give their time, their answers and their samples. Researchers want access to what those volunteers gave.

From 2012 to 2023 we built and looked after the web tools for both at TwinsUK, the UK's largest adult twin registry, at King's College London. **The lesson: put the participants first, and make every route to their data pass a person and leave a record.**

## What a research participant portal has to do

- **Give participants their own way in,** shaped for what they come to do: update details, answer questionnaires, see results.
- **Give researchers a separate one,** that shows what exists before they ask.
- **Put people between a request and the data.** Usually a data access committee.
- **Record every decision** at the moment it is made, where it can be found years later.
- **Protect what it holds,** in ways participants never see.

![Two lanes. Volunteers: Twin Zone, signed in with a study number and PIN, then their own record of details, questionnaires, results and visits. Researchers: see what exists, then one application in seven sections, then the committee where people decide, then a PDF record to the applicant and the data access manager.](/images/blog/two-ways-in.png)

*Two ways in at TwinsUK, and the path a request for data took.*

## Two groups, two ways in

**A twin signed in to Twin Zone, the members' site, with their study number and a PIN.** Inside, they could update their details, answer questionnaires, see their research results, meet their study team and prepare for a visit to St Thomas' Hospital.

![Twin Zone: the About page, the member sign-in with study number and PIN, and the home page on a phone.](/images/twins-uk/twins-zone-2026-10-19.webp)

*Twin Zone, launched in November 2017; captured in October 2026.*

A researcher came in another way: an account on the data access system, which we later rebuilt as its own application. **Each group got a way in shaped for what it came to do.**

## Show what exists before researchers ask

Researchers could see what the registry held before they asked for any of it. We rebuilt twinsuk.ac.uk, the research site, in 2017 and 2018. **On it, a researcher could search every publication since 1987 by year, author and keyword.** They could also browse the data the registry holds, including the DietMetab study by metabolite and food type.

![The research site's publications page, searchable by year, author and keyword.](/images/twins-uk/twins-publications-2026-10-19.webp)

*Publications since 1987, searchable by year, author and keyword.*

A researcher who can see what exists can ask for the part they need, by name. A vague request for "the data" is harder to judge and harder to refuse.

## Every request goes past people

The application replaced a chain of forms and emails with one form in seven sections. Among them: the applicants and their institution, funding, ethical approval, the data or samples needed, and the scientific proposal. The draft saved until it was ready, and a dashboard showed every request and where it stood.

![The data and material access form for researchers, with its instructions.](/images/twins-uk/twins-data-access-2026-10-19.webp)

*The data and material access form.*

**Then it left the software.** Each application went to the registry's committee for a decision. The system carried the request; people made the call.

## Every decision leaves a record

**Each decision sent a PDF to the applicant and to the data access manager. That PDF was the record.**

A registry that runs for decades can be asked, years later, who approved access to what, and on what grounds. A record made at the moment of the decision answers that without anyone having to remember.

We built the system first on WordPress, then rebuilt it as a Laravel application that checks each researcher's ORCID iD, the identifier researchers carry across institutions. **The application linked the request to an ORCID record.** That identifier supported the committee’s review; it did not replace it.

## Protect what you hold

The REST API behind Twin Zone and the apps we began for twin volunteers had 23 endpoints, and **it stored personal details encrypted.** Participants' trust rests on decisions like that, and they never see them.

## Five questions for your own portal

1. **Do participants and researchers come in by different doors?**
2. **Can a researcher see what exists before asking?**
3. **Who decides each request,** and is that a person or a rule in the software?
4. **Where is each decision recorded,** and could you find it in ten years?
5. **What is stored encrypted,** and who checked?

Our [academic research](/industries/academic-research) page covers the other research work we do, and [the TwinsUK case study](/work/twins-uk) shows the members' site and the data access system.

Researcher convenience matters, and the one form saved them a chain of emails. But a portal built on people's data is judged by its order of decisions, and participants come first in it.

## Building a portal on people's research data?

Tell us who signs in and who asks for the data. We will say how we would separate the two, and where the record of each decision should live.

[Talk to us about your study](https://lastdoorsolutions.com/contact?service=product-engineering)