Data Protection in Clinical Research: nFADP, HRA and GCP for Electronic Forms

Ask a Swiss study team which law governs their data and you will usually get one answer. In reality there are at least three, they apply simultaneously, and they were written by different people for different reasons. The Human Research Act and its ordinances govern the research itself — authorisation, consent, participant protection. The nFADP governs the personal data, including everything the research rules do not mention. And ICH-GCP governs how the sponsor expects the data to be produced and preserved. Most compliance failures in this field are not violations of any one of them; they are the seams between them.

Which Rules Apply, and in Which Order

Start by classifying the project, because the answer changes what you owe. A clinical trial of a medicinal product, a trial of a medical device, a non-interventional study, a further-use project on existing samples and data, and a quality-improvement survey inside a hospital are five different regulatory animals, and only some of them need an authorisation before they start.

A useful discipline: for every form in the study, write down which of these four rows it sits under. The consent form and the eCRF sit under all four. A recruitment landing form, a site-feedback questionnaire or a logistics form for study visits often sits only under the nFADP — and that is precisely why those forms are so often built in whatever tool was nearest, with nobody reviewing them.

Coded Is Not Anonymised — the Distinction That Decides Everything

This is the single most consequential misunderstanding in the field, and it is usually made in good faith. In everyday speech, replacing a name with «Subject 014» feels like anonymising. In law it is not: coded data is data whose link to the person has been replaced by a key, and while the key exists the data remains attributable and therefore remains personal data. Anonymised data is data where re-identification is impossible with reasonable effort — which normally requires the key to be destroyed and the residual dataset to be checked for the indirect identifiers that would give people away anyway.

• Coded — a key links «Subject 014» to a person. Personal data, full nFADP scope, participant rights apply, breach notification applies. The overwhelming majority of research data is here.
• Anonymised — the key is destroyed and the dataset itself does not single anyone out. No longer personal data, so the nFADP stops applying. This is the only status that genuinely reduces your obligations.
• «Anonymised» in the loose sense — the key was kept «just in case», or the dataset holds a rare diagnosis, a birth date and a canton. This is coded data with an optimistic label, and it is the version that appears in study documentation most often.

The distinction also drives consent. Under Art. 32 HRA, the further use of health-related personal data for research depends on this status: uncoded data requires informed consent, coded data requires consent that may be given in general terms for further use, and anonymised data may be used where the person has not objected after being informed. Getting the status wrong therefore does not just mislabel a dataset — it puts the project on the wrong consent basis, which is the kind of finding that stops an ethics submission.

Study Consent and Data Protection Consent Are Not the Same Document

Research consent under the HRA is about participation: the nature, purpose, duration and foreseeable risks of the project, the right to refuse and to withdraw at any time without disadvantage. Data protection transparency under Art. 19 nFADP is about processing: who the controller is, what happens to the data, who receives it, which countries it may go to, and how long it is kept. In practice the two are usually merged into one participant information sheet — which is fine, as long as both sets of content are actually present.

The gap that recurs in real submissions is the recipient and transfer paragraph. «Data will be processed confidentially» is not a statement of recipients. A CRO in another country, a sponsor's central database abroad, a statistician at a second university, an eCRF vendor's cloud region and a courier for biological samples are all recipients or transfers, and each belongs in the sheet — as well as in the record of processing that the sponsor or the institution has to maintain. Our post on informed consent in the digital age covers the drafting side; the transfer analysis is in which form data can legally leave Switzerland.

eCRF, eSource and What GCP Expects of an Electronic Form

The revised ICH-GCP guideline, E6(R3), is explicit that data governance covers the whole life cycle and that computerised systems used in a trial must be fit for purpose, with the sponsor able to demonstrate it. That expectation lands directly on any tool used to capture trial data — and it is a much heavier expectation than «the vendor has ISO 27001».

• Fitness for purpose, demonstrated. Validation appropriate to risk, a documented configuration, and evidence that the system does what the protocol needs — not a marketing page.
• Audit trail. Who entered or changed what, when, and why, with the original value still visible. A form tool that silently overwrites an answer cannot produce trial data.
• Access control by role, with a current, reviewable list of who has which permission at each site, and prompt removal when staff change.
• A defined source. If the electronic record is the source (eSource), that must be stated and the system must be able to hold that position under inspection. If paper is the source, the transcription step needs its own controls.
• ALCOA+ as the standard the data must meet — attributable, legible, contemporaneous, original and accurate, plus complete, consistent, enduring and available. Most of these are properties of the system, not of the person typing.
• Archiving. The record must remain readable and intact for the retention period, which for trial documentation runs in the ten-year range under the Swiss clinical-trial rules — confirm the exact period and its starting point for your trial category, and confirm that your vendor's export survives the vendor.

Where an Encrypted Form Platform Genuinely Fits

There is a real and under-served set of collection points in and around a study that are not the eCRF, are not inspected as trial records, and today usually run on whatever generic tool was to hand — frequently one that stores health data readable by the provider.

1. Recruitment and pre-screening. People send symptoms, diagnoses and medication lists before they are participants and before any protocol covers them. This is sensitive data in the ordinary nFADP sense, collected in the open, and it is the single most exposed form in most studies.
2. Expressions of interest and registries of willing volunteers, which accumulate health information over years with no trial to justify it and often no retention rule.
3. Participant-facing questionnaires outside the eCRF — satisfaction, burden, feedback on visits — where identification is unnecessary and often actively harmful to the answers.
4. Site and investigator forms — feedback, protocol deviation reports before they become formal records, logistics and scheduling — where the content is confidential but not a trial record.
5. Post-marketing and pharmacovigilance intake from patients and healthcare professionals, which our pharmacovigilance use case covers in detail.

For each of these, the reasoning is the same: the data is sensitive, the number of people who need to read it is small and known, and no inspector will ever ask a provider to produce it. That is exactly the shape of problem end-to-end encryption solves, and the research and clinical trial use case describes how we handle it.

What the Ethics Committee Will Ask About Your Tool

Submissions to the competent cantonal ethics committee run through the national portal, and the data protection section is where generic answers get sent back. Committees are not asking for a security whitepaper; they are asking whether you can describe your own data flow. Prepare six answers before you submit.

Sponsors, CROs and the Cross-Border Question

Multicentre research is cross-border by construction: a sponsor in one country, a CRO in another, a central laboratory in a third, an eCRF hosted somewhere else entirely. The nFADP does not forbid this — Art. 16 permits disclosure abroad to states the Federal Council has recognised as adequate, or on the basis of standard data protection clauses, binding corporate rules or a treaty, with narrow exceptions in Art. 17. What it does require is that you can name the mechanism for each recipient, in advance, and that it appears in the participant information.

Two research-specific complications are worth flagging. First, the professional secrecy duty under Art. 321 StGB sits on top of data protection law for the treating physicians involved, and it extends to their auxiliary persons — which includes the staff of a vendor with access to readable data. Second, coded data going abroad is still personal data going abroad; a common misconception is that pseudonymisation converts an international disclosure into something that does not need a basis. It does not.

Five Findings That Recur

• The recruitment form nobody reviewed. Built outside the protocol, collecting health data from non-participants, retained indefinitely, hosted wherever. It is the most common real exposure in an otherwise well-run study.
• «Anonymised» in the protocol, coded in reality. Check who still holds a key — including the site, the CRO and the statistician's laptop — before writing the word.
• The key kept in the same system as the data. A code list stored in the same folder, database or backup as the coded dataset makes the coding decorative.
• Screening data that outlives the screening. People who were not enrolled still have their health data in your files. Define a separate, short retention rule for them and apply it.
• Consent that does not match the eCRF. The sheet promises deletion on withdrawal; the system cannot delete a record without breaking the audit trail. Resolve this on paper before it happens in practice.

Bottom Line

Three regimes, one dataset, and one distinction that determines most of your obligations: coded data is personal data, and only real anonymisation changes that. Get the classification right, name your recipients and transfer mechanisms, treat the eCRF as the regulated computerised system it is, and give the forms that sit around the trial the same seriousness as the ones inside it — because the recruitment questionnaire usually holds the same health data with none of the governance.

And be sceptical of any tool sold as the answer to all of it, including ours. A validated EDC system exists to make trial data inspectable; an encrypted form platform exists to make sensitive intake unreadable by anyone but you. Those are opposite design goals, and a serious study uses each where it belongs.