How TrialPilot works

TrialPilot runs decentralized studies end to end: a study team designs a protocol in a web dashboard, participants take part from their own phones, and data flows between the two without the study team ever seeing who the participants are. This page walks the whole lifecycle once, start to finish, so the rest of the documentation has a shared map to hang on.

If you already know which side you are on, jump straight to the study-team docs or the participant docs.

Two surfaces, one study#

Everything in TrialPilot happens on one of two surfaces:

• The Researcher Dashboard is the operating workspace for study teams. It brings study setup, participant monitoring, safety review, and data preparation into one de-identified view, so coordinators and investigators can move from protocol design to day-to-day operations without switching tools.
• The TrialPilot app is where participants take part — on iOS, Android, or the web. It handles joining a study, informed consent, daily check-ins, assessments, wearable data, symptom reporting, and a personal view of trends and results.

The two surfaces meet at the study. The study team defines what a study asks of participants; the app turns that definition into each participant's personal schedule of tasks; and completed tasks flow back to the dashboard as de-identified study data.

The study lifecycle#

Every study moves through the same broad phases. Each phase below links to the docs that cover it in depth.

1. Create an organization#

Studies live inside an organization — your research group, sponsor, site, or institution. The person who creates an organization becomes its organization administrator and can invite the rest of the team, assign roles, and fill in organization details such as contact and IRB information. See Accounts and organizations.

2. Build the study#

A new study starts in draft status and opens in the Study Builder, where you configure the protocol record, study design, participant criteria, assessments and their schedules, interventions and dosing, consent content, safety definitions, and regulatory details. For randomized designs you also configure arms, allocations, and blinding. Start from a curated study template or from a blank protocol, and see Build a study for the full walkthrough.

3. Rehearse in test mode#

Every draft study is a sandbox. Your team can enroll as test participants on real devices, complete consent, live with the actual schedule of check-ins and assessments, and watch flagged test data land on the dashboard — data that can never mix with the real dataset. See Test mode.

4. Publish#

Publishing validates the study configuration, reports anything missing grouped by section, and — once validation passes — sets the study to enrolling. Published studies may lock some fields so the trial record stays stable. See Publish and recruit.

5. Participants enroll and consent#

Participants find a study through a link, a QR code, an 8-character invite code, or public discovery when it is enabled. Before joining, they review what the study asks of them, then read and accept the study's eConsent. Consent is recorded online at the moment it is given. See Join a study.

6. Collect data#

Once enrolled, the app builds each participant's day-to-day rhythm from the protocol:

• Daily check-ins track symptoms and post-exertional malaise signals in a short daily touch.
• Assessments — questionnaires and guided physical tasks — open at baseline, daily, weekly, or on the study weeks the protocol selects.
• Intervention logs record doses and adherence when the study includes them.
• Wearable data syncs from Apple Health or Health Connect when a participant chooses to connect it, including a pre-intervention wearable baseline when the study configures one.

See Assessments and schedules for the study-team side and Check-ins and assessments for the participant side.

7. Monitor and manage safety#

The dashboard tracks enrollment progress, assessment completion, engagement, wearable coverage, and per-participant progress — all by pseudonym. Safety runs alongside: red-flag reports arrive as escalations, symptom reports queue for clinical triage, and confirmed adverse events move through a full workflow of seriousness, causality, expectedness, and reporting obligations. See Monitor participants and Safety operations.

8. Manage data and lock#

For trial-of-record workflows, the data management workspace covers data queries, MedDRA and WHODrug coding, controlled database lock, and an audit trail, built around Part 11 / ALCOA+ style expectations. Locking protects the dataset; study data that arrives late for a locked study is quarantined for review rather than merged or dropped. See Data management and Locking and closeout.

9. Export and share results#

Study teams export de-identified datasets — and, depending on study configuration, trial-of-record or CDISC-oriented output — from the dashboard. Participants get something too: when a study completes and results are available, they can reopen understandable results in the app. See Exports and CDISC and Results and study history.

The privacy boundary#

The most important design idea in TrialPilot is not a feature — it is a boundary. Study teams operate the trial without viewing participant personally identifying information. On the dashboard, a participant is a study-scoped pseudonym such as P-0001: stable within that study, different in every other study, and not reversible to an identity.

• Researcher-facing views are de-identified by architecture, not policy alone — names, contact details, and account credentials are never accessible from the dashboard.
• Demographics appear in generalized form, such as age bands rather than birth dates.
• Participant-level views are suppressed for small cohorts until a study has at least 20 participants, reducing re-identification risk.
• Registry recruitment shows researchers counts, never identities — TrialPilot sends the invitations.

Where to go next#

The rest of the documentation is organized around the two surfaces. Pick your side: