TrialPilot is built on one architectural decision: participant identity and study data live behind a deliberate boundary, and the researcher product operates entirely on the study-data side of it. Study teams monitor engagement, review safety reports, and export datasets without ever seeing who a participant is. Participants appear to researchers only as study-scoped pseudonyms like P-0001.
This page describes how that boundary works: where it is enforced, what crosses it in generalized form, and what never crosses it at all. If you are a participant, Your data and privacy covers the same ground from your side.
Identity lives apart from study data#
Participant accounts — names, email addresses, sign-in credentials, and contact details — are stored separately from the study definitions and research workflows that power the Researcher Dashboard. The researcher surface has no pathway to direct identifiers: the access it holds is denied, at the database layer itself, to identity fields, contact fields, credentials, and the account-linking records that could connect a pseudonym back to a person.
Enforcing this in the database, not only in application code, is deliberate defense in depth. Even if a bug in the researcher product attempted to query a name or an email address, the database refuses the request. The separation does not depend on every line of dashboard code being correct.
- Never accessible to researchers: participant names, email addresses, passwords and sign-in secrets, linked sign-in records, and direct contact details.
- Accessible in de-identified form: enrollment, withdrawal, and completion dates; study responses and health outcome data needed for authorized research and safety workflows; and generalized demographics — all keyed to the study-scoped pseudonym.
Every field that crosses the boundary is explicitly classified as identifying or not, and automated checks run against every change to the platform: a new field cannot reach the researcher surface without a classification, and a raw value that requires generalization is blocked from researcher-facing data until a generalized version exists.
Study-scoped pseudonyms#
Researchers work with pseudonymous participant IDs such as P-0001. These identifiers are assigned automatically at enrollment and have three properties that matter:
- Stable within a study. The same participant always carries the same ID within a given study, so longitudinal analysis works — a researcher can follow all of
P-0042's data across the whole study. - Not linkable across studies. A person enrolled in two studies receives a different pseudonym in each. Researchers cannot connect the two records, even across studies run by the same organization.
- Not reversible. The pseudonym cannot be turned back into the underlying account identity from the researcher surface.
What researchers see vs what stays protected#
| Researchers see | What stays protected |
|---|---|
Study-scoped pseudonym (P-0001) | The participant’s name, account identity, and the raw internal identifier behind the pseudonym. |
| Enrollment, withdrawal, and completion dates | Email address, contact details, and any way to reach the participant directly. |
| Age band at enrollment | Exact birth date. |
| Assigned sex and gender identity as structured categories | Free-text demographic descriptions. |
| Tracked illnesses as structured data | Free-text health narrative tied to identity. |
| Device family and app version channel (for example, a 1.x release) | The exact device model string and exact app version. |
| Coarse time-zone region (for example, Americas) | The participant’s exact time zone or location. |
| Study responses, check-ins, and health outcomes, keyed to the pseudonym | Sign-in credentials, session records, and account-linking data — denied entirely. |
The generalized values in the left column are the point, not a limitation. Exact birth dates, device model strings, and precise time zones are quasi-identifiers — values that are not identifying alone but can contribute to re-identification when combined. TrialPilot exposes bands and categories instead of raw values so the researcher dataset is useful for analysis while staying resistant to re-identification by design.
Small-cohort suppression#
De-identification weakens when a cohort is small: in a five-person study, an age band plus an enrollment date can be enough to guess who someone is. TrialPilot therefore holds back participant-level detail until a study reaches 20 participants. Below that threshold, researchers see aggregate progress rather than individual rows.
Test cohorts are different
Registry recruitment privacy#
When a study team recruits from the TrialPilot research registry, the same principle applies: researchers learn how many people match, never who they are.
- Feasibility queries return counts, not identities.
- TrialPilot sends the invitations. The study team never receives a contact list, and a person only becomes visible to a study by choosing to enroll in it.
- Registry members are not contacted more than once every two weeks, across all studies, and large campaigns may deliver gradually.
See Publish and recruit for how recruitment fits into running a study.
What participants control#
The boundary protects participants automatically, but participants also hold active controls over their own data. From the app, a participant can review what they are sharing and with whom, export their data, and delete it. Your data and privacy walks through each of these from the participant's perspective.
What this protects against#
The architecture is designed to protect against realistic failure modes: a bug in the researcher product that would otherwise expose identity, compromise of researcher-side credentials, over-broad access granted by mistake, and accidental cross-boundary access during development. Because the boundary is structural — enforced in the database and verified by automated classification checks — it reduces re-identification risk by design, not by policy alone.
An honest scope statement