What a clinical study app needs

The GDPR treats health data as a special category of personal data: it can only be processed in the cases the regulation allows, such as scientific research with appropriate safeguards or the participant's explicit consent. Which legal basis applies is decided by the research team with its ethics committee and data protection officer (DPO).

For whoever builds the app, that turns into design decisions:

• Collect only what the protocol asks for. If the study doesn't need the participant's name, the app doesn't ask for it. Every extra field is a risk and one more thing to justify to the committee.
• Pseudonymise from the start. Participants sign in with a code from the team, and the link between codes and people is kept by the centre, not the app. Exports for analysis carry the code, with no identifying data.
• Protect the data wherever it lives: encrypted in transit and at rest, with backups and a log of who accesses it.
• Decide what happens when the study ends: how long the data is kept, how it is handed over to the team and when it is deleted.

What works best for us is keeping the environments separate:

• Development and staging, on our servers in Barcelona. That is where we build and test each version with the project team, without depending on the centre’s systems.
• Production, on the centre's infrastructure. We install the app and its server on the hospital's or institute's own systems, usually on its Kubernetes. Participant data never leaves the centre and is covered by the security measures the centre already applies to health data. For a Spanish public hospital, that includes the National Security Framework (ENS), worth asking about or checking in the tender.

If the centre has nowhere to host the app, production can run on servers contracted for the project, always within the EU. That adds one more provider to the data processing agreement and to the committee documentation.

The hospital or research institute is the data controller: it decides why and how the data is processed. Whoever develops and maintains the app, if they can access that data, acts as a data processor, and both sign a data processing agreement that sets out what the processor may do with it and which security measures apply.

It should be signed before the first real data comes in, and reviewed by the centre's DPO. With a private centre it is usually signed together with the project contract; with a public hospital, it often comes formalised with the award of the tender.

When health data is processed, the centre will usually need to carry out a data protection impact assessment (DPIA) before starting. The centre does it, with its DPO, but it needs technical information only the app builder has: what data is collected, where it is stored, who accesses it and how it is protected. That information should be in writing from the proposal onwards.

No study with people starts without a favourable opinion from a research ethics committee. The committee doesn't only assess the protocol: it also wants to know how data is collected and what participants see. It usually asks for:

• A description of the app and the data it collects.
• The participant information sheet and consent text, as the participant will see them.
• How the data is protected and pseudonymised, and who has access to it.
• Screenshots or a prototype of the key screens.

The committee's calendar tends to set the project's: if the app has to be ready on the day the study is approved, this documentation has to be prepared alongside development, not at the end. We prepare the technical part for the research team to submit.

If consent is given in the app, it has to be easy to read calmly and understand: a summary and the full text, a clear step to accept and the option to withdraw later. The app should record which version of the text each participant accepted and when, because the text may change during the study.

An app that collects questionnaires for a study usually is not. But if it calculates doses, helps with diagnosis or recommends a treatment, it may be a medical device and fall under the European rules that govern them, which changes the project completely. It is worth clarifying at the start, with the team and, if needed, a regulatory expert, because it affects scope, timeline and budget.

Apple and Google review health apps more closely:

• They require a public privacy policy explaining what data is collected and why, and a way to delete the account and the data.
• For apps that run research with people, they may ask for evidence of participants' consent and ethics committee approval.
• Google Play also requires a specific declaration for health apps.

A closed study doesn't stop the app from being public. Anyone can download Cohorte ARCA, but only people who receive the code their doctor texts them when enrolling them in the study can sign in. Installing it is like installing any app, and the team controls access.

The best legal design is useless if participants stop answering. What helps most, in our experience:

• Short questionnaires with one question per screen, or in a chat format, as in ARCA.
• Reminders at the right moment, configurable by the team.
• Working offline: participants answer whenever they like and the app sends the answers when coverage returns.
• Thinking about who answers: children with their families, older people, patients at a difficult time. Readable type, plain language and each participant's own language.