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 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.
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.
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.
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
- Do participants and researchers come in by different doors?
- Can a researcher see what exists before asking?
- Who decides each request, and is that a person or a rule in the software?
- Where is each decision recorded, and could you find it in ten years?
- What is stored encrypted, and who checked?
Our academic research page covers the other research work we do, and the TwinsUK case study 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.
