Participant management

The Participants area is where you register people into your study, organise them, and open any individual participant's record. It has up to three tabs: Participants (the table), Participant groups, and Participant resources where that feature is enabled.

The participants table

One row per participant, with a count badge on the tab showing how many there are.

Column What it shows
ID The participant's identifier — click it to open their record, or the eye beside it to preview them without leaving the table
% Progress through their scheduled stages, as a ring
Status Badges (see below)
Seen When they last opened the study, when they first logged in to the app, and roughly where from
Sites Site tags, with controls to add and remove
Groups Group tags, with controls to add and remove

Status badges tell you the participant's state at a glance: Archived, Withdrawn, and Unallocated are written out, and the rest are small icons — hover over any of them for the detail:

  • a green person with a tick — they have joined (opened the study at least once); the tooltip gives the date they first did
  • a purple flag — they have been marked as recruited; the tooltip gives the date (see Marking participants as recruited)
  • a blue shuffle arrow — they have been randomised; the tooltip gives when, and in which stratum (see Randomising participants). Everyone who can see the table sees it, including in a study that conceals its allocation: it says that they were randomised, not into which arm
  • a purple bell — their device is registered for push notifications
  • a red clock with an exclamation mark — they are behind on at least one stage; the tooltip says how many stages and how late
  • a blue clock — something is due soon; the tooltip gives the dates
  • a book — the casebook's signature status: green with a tick when every response is signed, otherwise the number signed out of the total
  • a logo or watch per connected wearable service, with when it last synced; a green dot means it synced in the last 12 hours, and an orange dot on the Garmin Connect logo means no Garmin data has arrived for two days or more
  • a red watch — Garmin is switched on for this participant (for the whole trial, or for one of their groups) but they haven't connected their Garmin account yet

Sort by ID, progress, or last seen using the column headers. The download icon at the right of the header row exports the table as a CSV, including each participant's first login date, the date they were marked as recruited, and when they were randomised, if they were.

Finding people

Search matches on participant ID.

Filter opens a panel with these groups of options:

  • Schedule: behind schedule, on schedule, or due soon. Due soon means something falls due in the next 7 days (see Due soon). Participants with something due soon carry a blue clock in the table, and hovering over it gives the dates.
  • Allocation — unallocated, or allocated.
  • Joined — not joined, or joined.
  • Withdrawn — withdrawn, or not withdrawn.
  • Recruited — recruited, or not recruited, counted the way the overview's recruitment chart counts them: by what your study counts as recruited (Settings > Participation > Recruitment targets), plus anyone marked as recruited by hand. Its count is always the overview's. Unallocated and archived participants are in neither: the overview doesn't count them at all.
  • Randomised — randomised, or not randomised. Offered in studies with study arms, to everyone who can see the table, so a recruiter in a blinded study can list who still needs randomising.
  • Show archived — archived participants are hidden by default; this brings them back.

Alongside are site and group filters. Group filters are three-state — click once to include that group, again to exclude it, and a third time to clear. There is also a No group option for finding participants who have not been assigned to any. Applied filters appear as removable chips above the table, with a count on the Filter button, and Clear filters resets everything.

You can also click any site or group tag in the table to filter to it directly.

Saved filters

Once you have a view you use regularly — "behind schedule at my site", "not yet joined" — Saved filters stores it under a name, including the search term and sort order.

Any saved filter can be marked as your default, in which case it is applied automatically whenever you open the participants table. You can also overwrite an existing saved filter with your current settings rather than creating a new one.

Creating participants

Register participants offers three routes.

One at a time

Enter a participant ID, and optionally a password, a group and a site.

If you set a password, make a note of it — Trialflare cannot reveal it later. Leave it blank to use the study-wide password, if you have one.

In bulk, generated

Say how many you want (up to 2000 at a time) and choose how IDs are generated:

  • Random three-word phrase — memorable, easy to read out over the phone.
  • Sequential pattern — {n} becomes a sequential number, and {3p} pads it with leading zeros to three digits, so p{3p}{n} gives p001, p002.
  • Random alphanumeric — of a length you choose, five characters by default.

If you have groups defined, you can also choose a grouping strategy at the same time: add everyone to one group, or round robin through them in turn. There is deliberately no random option. An allocation made while creating participants is seen in full by whoever makes it, before anyone has been found eligible, and nothing records how it was drawn, so it can't stand as a trial's randomisation: use randomisation instead. In a study that conceals its allocation, its study arms are offered only to people who can see them.

If you have sites, you can add everyone you are creating to one of them.

Ticking Generate random passwords downloads a CSV of IDs and passwords as soon as the participants are created. Keep it safe — those passwords cannot be retrieved afterwards.

From a CSV

Upload a file with a participantId column, and optionally group, site and password columns. To put someone in more than one group or site, separate the names with a semicolon. A site can be given by its name or its ID. A group or site that doesn't match one of yours is marked as an error, and that row is left out of the import rather than the participant being created without it. So is a site name that more than one site has: use the site's ID instead.

In all three routes, duplicate participant IDs are ignored rather than causing an error, so re-uploading a file only creates the rows that are genuinely new.

If you register participants with site.registerParticipants rather than across the whole trial, you can only choose from the sites you hold it on, and anyone you don't choose a site for is added to all of them, including any you hold it on but can't see.

You can only choose from sites you can see. trial.readSites or trial-wide read access shows all of them; otherwise you see those where you hold site.access. If you can't see any, the site option doesn't appear, and a site value in a CSV is marked as an error.

Creating participants in advance is normal. Many studies pre-create a pool of participant records and allocate them as people are recruited — which is exactly what the Unallocated status is for, and what screening questionnaires draw from when they turn a submission into a participant.

Sites and groups

Groups are tags for organising participants — study arms, cohorts, or any label you find useful. Sites are the locations taking part; see Sites.

Both work the same way from the table:

  • On a single row, the + button adds the participant to a site or group, and the × on an existing tag removes them.
  • Selecting several participants with the checkboxes puts Add to and Add to site: in the bulk menu.

A participant can belong to any number of groups and sites — with one exception: study arms, below.

Managing groups

The Participant groups tab is where groups are created and edited. Each has a name and a colour, which is what you see on tags throughout the interface — worth choosing deliberately if you have several arms. View participants jumps to the table filtered to that group.

Study arms

Most groups are tags. If participants are allocated into a group — intervention and control, say — tick This group is a study arm when you create or edit it. Arms are listed separately from tags on the tab, and a participant can be in only one at a time: adding them to a second is refused.

Marking your arms is also what the concealment setting and randomisation below work from.

Concealing the allocation

For a blinded study, turn on Conceal which study arm each participant is in under Participants > Randomisation. It applies to every group marked as a study arm, including ones you add later, whether participants are randomised into them or put in by hand. Turning it off asks you to confirm first, because it unblinds the study for everyone straight away; who turned it off, and when, is recorded in the event log.

With it on, only people whose role includes trial.readAllocation can see which arm a participant is in. Everyone else sees the participant and their other groups as normal, but:

  • no arm tag on the participants table or the participant's record
  • no arm in the participants CSV, the trial data export or the study record
  • no arm in the event log, no arm breakdown in the participant journey figures, and no arm to choose under Trial at a glance on the overview
  • no arm on a pack: a pack set aside for an arm shows Concealed arm in the Packs list instead of the arm's name
  • no arm breakdown in Scorch's charts, and no charting by an arm
  • arms are not offered as table filters, and not offered in the Add to group menus or when registering participants

Nor can they put anyone into an arm or take anyone out of one, whether through the app, a CSV upload or the API. Changing a participant's other groups leaves their arm as it is. They also can't make a pack available to an arm, or change which groups a pack for an arm is available to, and they can't aim an automatic message or an automatic query's Participant group rule at an arm.

Being a trial administrator does not grant the permission. That is deliberate, so an administrator who should stay blinded does. Someone has to be given trial.readAllocation explicitly — see Roles and permissions.

What is not concealed is whether a participant is in an arm at all, only which one. Other groups are never concealed, so in a blinded study don't create one that would give the allocation away on its own, such as a dispensing batch named after its arm.

What the study shows a participant can still give their arm away. Trialflare conceals the arm itself, but not what you set up for each arm. If a stage is available only to one arm, its responses show which participants answered it; if an automatic message or automatic query is aimed at one arm, it shows who it reached; if Garmin is switched on for one arm, so does who connected a watch. A pack's name and batch number are shown to everyone who can see packs, so don't put the arm in them. In a blinded study, give every arm the same forms and messages wherever the protocol allows.

Breaking the code in an emergency

When someone's care depends on knowing what a participant was given, such as a serious adverse event or an overdose, a person whose role includes trial.breakCode can break the code for that participant. Like trial.readAllocation, it isn't granted by being a trial administrator, so give it to the people your protocol names, such as the principal investigator and the on-call clinicians.

On a randomised participant's record, under Randomisation, press Break code…, give a reason, and confirm it's you with your passkey or authenticator. Trialflare shows the participant's study arm, and any pack they were given when randomised. It is shown once: closing the dialog hides it again, and you stay blinded to every other participant. It works even when the trial database is locked.

Breaking the code is never silent:

  • it is recorded in the event log as breakCode, with who did it, when and why. The arm is on the entry, and withheld from anyone who can't see arms;
  • the participant is marked Code broken, with the date, on their record and in the participants table, for everyone who can see them, so outcome assessors know they have been unblinded;
  • the participants CSV, the trial data export and the study record gain a Code broken at column, so the analysis can account for them;
  • the trial's administrators are emailed who broke the code, for which participant and why, but not the arm.

Breaking the code for the same participant again works the same way, and is recorded again. The dialog says who broke it before, and when.

Randomising participants

Trialflare can assign each participant's study arm for you, at the moment they are ready to be randomised, from an allocation sequence it generates and keeps — or from a list your statistician produced, if your protocol requires the list to be made independently (see Uploading a list made elsewhere). For a small trial with several factors to balance, it can instead allocate each participant to the arm that best balances them, with no list at all (see Minimisation). For a walkthrough of the whole set-up, see the recipes for an open-label study stratified by site and a blinded trial that dispenses kits.

Setting it up. Under Participants > Randomisation, a trial administrator chooses a Method: Generate a sequence in Trialflare, Upload a sequence, or Minimisation. For a generated sequence they then choose:

  • Study arms and ratio — which arms participants are randomised into, and in what proportion: 1 and 1 for equal arms, 2 and 1 for twice as many in the first.
  • Block sizes — the sequence is built in blocks that each hold the arms in that ratio, shuffled, so the arms stay balanced as you recruit. Each block's size is picked at random from the sizes you tick, so nobody can tell where a block ends and work out the next allocation.

  • Stratify by (optional) — up to four factors to balance the arms within, such as site and sex. Each combination of their levels is a stratum, randomised from its own sequence: stratifying by sex and by two sites makes four, such as "Female / Leeds". Give each factor a Name and a Level source:

    • Participant's site — one level per site the trial has, labelled by the site's ID (or its name if it has none).
    • Participant's group — tick the groups that are the factor's levels, such as Female and Male. Study arms, and groups whose members are concealed, can't be used.
    • Chosen when randomising — add each level by typing it and pressing Add, and whoever randomises picks one. Two levels can't differ only in capitals, since an uploaded list's levels are matched ignoring them.

    Site and group levels are read from the participant's record, so they can't be picked wrongly. A participant must be at exactly one of the factor's sites, or in exactly one of its groups, to be randomised. A group that is a factor's level can be renamed but not deleted, made a study arm or concealed, and the stratum keeps the name it had when the sequence was set up. - Entries per stratum — how many participants each stratum can randomise before it needs extending.

Generate sequence creates it, and the tab shows a green tick from then on. Nobody can see the sequence itself in Trialflare, trial administrators included — only how many entries each stratum has used and has left. Until the first participant is randomised you can change the settings and generate a new one; after that it is fixed, and a stratum that is running low can only be extended, which carries on the same sequence.

Randomising. On a participant's record, under Randomisation, press Randomise. The dialog shows each factor's level and the stratum they will be randomised in; choose any levels that are picked by hand, check the stratum, and confirm. If their site or groups don't give one clear level, it says what to fix instead. They are put in the next arm in the sequence. In an open study you are told the arm straight away. In a study that conceals its allocation, you are told only that they were randomised, unless your role includes trial.readAllocation.

It can't be undone. Nobody can move a randomised participant to another arm or take them out of theirs, however they try — on the record, from the participants table or through the API. A participant randomised in error should be withdrawn. Their other groups can still be changed as normal. An arm the sequence uses can't be deleted or turned back into a tag.

Resetting after a trial run. If you tried your set-up out by randomising test participants before going live, Reset randomisation on the same tab takes the arm off everyone randomised so far and lets you set up a new sequence. It is only for that: on a live study it would undo real participants' allocations. It needs a trial administrator whose role also includes trial.readAllocation, a written reason, and confirming it's you with your passkey or authenticator, and it isn't possible once the database is locked. The old sequence isn't deleted: it is kept with who was randomised from it, and the reset is recorded in the event log as resetAllocationSequence, with who did it, why, and which participants it affected. Packs that randomising gave them are put back in stock, while packs assigned by hand stay assigned, and any Code broken marker from the trial run is removed (the code-break itself stays in the event log). Test participants themselves aren't deleted; remove them as you would any other. The safest way to rehearse is in a copy of the trial.

How the sequence is generated and validated

For your randomisation plan or statistical analysis plan, the method is stratified permuted-block randomisation with randomly chosen block sizes:

  • Each stratum has its own sequence, built from blocks that each hold every arm in the trial's ratio, in a random order. The arms are therefore balanced at the end of every block, and a sequence is never further out of balance than half its largest block.
  • Each block's size is chosen at random, with equal probability, from the sizes you ticked.
  • The order within a block comes from a Fisher–Yates shuffle. The random numbers come from the Mersenne Twister generator, seeded for each block from a 128-bit seed that Trialflare chooses when the sequence is generated, together with the stratum and the block's number. Nobody chooses the seed or can see it, trial administrators included.
  • The seed and settings are kept with the sequence, so the sequence can be regenerated exactly and compared with what was used, for example at the end of the trial. Each sequence records the version of the method that produced it.

How it was tested. Before release, the generator was checked with chi-square goodness-of-fit and independence tests over 120,000 blocks per check, for 1:1, 2:1 and 1:1:1 ratios and a range of block sizes. All 26 checks passed (p > 0.001). Together they show that:

  • every possible order of a block is equally likely;
  • no position within a block favours any arm;
  • each block size is chosen equally often;
  • one block's arms and size say nothing about the next block's;
  • the same block in two different strata are independent;
  • trials with different seeds start with each order equally often.

To confirm the tests would catch a fault, they were also run against a deliberately flawed shuffle, a well-known mistake that favours some orders over others, which failed 17 of the 26 checks. A smaller version of the same tests runs automatically before every release.

Separately, many randomisations made at the same moment were tested against the live database software, to show that two people randomising at once are always given different entries, and different packs, and that pressing Randomise repeatedly randomises a participant only once.

Uploading a list made elsewhere

Some protocols require the randomisation list to be produced independently of the trial management system, by a statistician or a randomisation service. Under Method, choose Upload a sequence. This needs a trial administrator whose role also includes trial.readAllocation, because whoever uploads the list can see every allocation in it; when Trialflare generates the sequence, nobody ever sees it.

Set up Stratify by first, as for a generated sequence, then Download a template and give it to whoever makes the list. The list is a CSV file with a row for each entry:

  • Sequence — the order entries are used in within their stratum. Numbers needn't start at 1 or be consecutive, so a list numbered within each stratum and one numbered across the whole file both work, but a number can't appear twice in the same stratum.
  • Arm — the arm the entry allocates to. It can be the arm's name or a code such as A or B.
  • the stratum, if you stratify: either a column for each factor, named as the factor is (Sex, Site), or a single Stratum column such as Male / Leeds. Levels are matched ignoring capitals. The template has a row for each stratum, spelt as Trialflare expects.

A Block column is kept if there is one. Any other column, such as a kit number, is ignored, and the preview says so. Excel's CSV files work as saved, including with semicolons.

When you choose the file, Trialflare reads it and shows the rows in each stratum, by arm code, before anything is stored. Match each code to one of your study arms (a code that is an arm's name is matched for you), check the counts, and press Use this list. A file with a problem is refused with each problem listed by row number, and every stratum needs rows of its own. The preview also shows the file's SHA-256 fingerprint, which you can compare with the statistician's copy to show it is byte-for-byte the list they signed off.

Once uploaded, randomising works exactly as for a generated sequence, and nobody else can see the list. The file itself is kept with the trial, and the sequence shows each file's name, row count and upload time, with its fingerprint to anyone holding trial.readAllocation. A stratum that is running low can't be extended by Trialflare, since it didn't make the list: Add rows from a file uploads more rows of the same list, using the same arm codes, numbered on from where each stratum's rows end. Setting up and adding rows are recorded in the event log as createAllocationSequence and extendAllocationSequence, with the file's name and fingerprint but never its contents.

Minimisation

Stratifying by many factors makes many strata, most with a handful of participants, and a stratum whose blocks never fill doesn't balance anything: four factors of three levels make 81. Minimisation balances each factor on its own instead, so it suits a small trial that needs to balance several. Under Method, choose Minimisation, then:

  • Study arms — minimisation allocates the arms equally. For an unequal ratio, such as 2:1, use a sequence instead.
  • Probability of the best-balancing arm — from 50% to 95%; 80% is the usual choice. 100% isn't allowed: if every participant went to the best-balancing arm, anyone who knew who was enrolled could work out the next allocation.
  • Minimise on — up to six factors, set up as for stratifying (a Name, a Level source and its levels), each with a Weight from 1 to 10. A factor with weight 2 counts twice as much as one with weight 1 when the arms are compared.

Set up minimisation saves it. Until the first participant is randomised you can change the settings; after that they are fixed, and only resetting starts again.

When someone presses Randomise, the dialog shows the participant's level of each factor, as it would their stratum. Trialflare then looks at everyone randomised so far who shares each of those levels, and for each arm works out how unbalanced the arms would be if the participant went to it: for each factor, the difference between the largest and smallest arm at the participant's level, multiplied by the factor's weight, added up across the factors. The arm with the lowest total gets the probability you set, and the other arms share the rest equally. Arms tied for lowest share it, so the first participant, and anyone the arms are tied for, is allocated purely at random. A random number then picks the arm.

Earlier participants count where they were randomised, even if they later move site or withdraw, as an intention-to-treat analysis expects.

The tab shows how many have been randomised, at each level of each factor, so you can see the balance. The count for each arm is shown only in an open study, or to people whose role includes trial.readAllocation. Packs, concealment, breaking the code and resetting all work as they do for a sequence.

How it is validated. For your randomisation plan, the method is Pocock–Simon minimisation with the range measure. Each allocation is stored with everything it was decided on: the participant's levels, the counts it saw, each arm's total and probability, and the random number. The random number comes from the Mersenne Twister generator, seeded from a 128-bit seed that nobody chooses or can see, together with the allocation's position, so every allocation can be recalculated and checked afterwards. Before release, the calculation was checked against a worked example done by hand, and simulated trials showed that:

  • the best-balancing arm is chosen as often as the probability says;
  • tied arms are chosen equally often;
  • minimisation keeps every factor far more closely balanced than simple randomisation.

Many randomisations made at the same moment were also tested against the live database software. Each one was balanced against all the others, with none skipped or counted twice.

Downloading the allocation record

Once participants have been randomised, people whose role includes trial.readAllocation can Download the allocation record from the Randomisation tab: a CSV file listing every participant randomised so far, their arm, when and by whom. For a sequence, each row also has its stratum and position. For minimisation, each row also has everything the allocation was decided on, so a statistician can recalculate it. It never includes entries of a sequence that haven't been used yet. It names every participant's arm, so it unblinds whoever opens it. Each download is recorded in the event log as downloadAllocationRecord.

Giving out packs

If your study uses packs (medication kits, devices), each participant can be given one as they are randomised. Under Participants > Randomisation, the Packs card's Set up chooses the pack type and whether there is:

  • Packs differ by arm, such as active and placebo kits. Each pack must be made available to the one arm it is for. Only those packs are used, never one that is open to every group.
  • Every participant gets the same pack, such as a device everyone receives. Any pack of the type not kept for an arm is used.

Choose by what your packs are, not by what is in stock: if the packs differ by arm, choose that even before they are all imported. A kit imported without its arm is then never given out, rather than given to whoever is randomised next. If some packs of the type don't match the choice (kits with no arm, or packs kept for an arm when everyone gets the same), the card says how many won't be given out.

When someone presses Randomise, Trialflare picks one of the packs the participant could be given, at random, and assigns it to them. The dialog then says which pack to hand over or post, by its name and batch number. In a study that conceals its allocation, that is all the person randomising learns: the pack, not the arm. Because the pack is chosen at random, how your kits are numbered doesn't give the arm away, but don't put the arm in a pack's name or batch number.

A pack can come from those held at the participant's site or at the trial level, which serve every site, whether or not you stratify by site. For a remote study posting kits from one place, leave packs unassigned to a site.

Nobody is randomised without a pack. If a participant's site has no pack ready for any one of the arms, randomising them is refused until more are added, whichever arm they would have had, so running short of one arm's kits doesn't reveal anyone's allocation. The Packs card shows how many more participants the packs can cover, by where they are held: one row for the packs held for all participants, and one for each site holding any. A site's participants can be given packs from its own row or from the all-participants row. People who can see arms also see the count for each arm; everyone else sees only the lowest. In the rare case that two people randomise at the same moment and take the last pack, the second randomisation still stands and the dialog asks for a pack to be assigned by hand.

To set up kits from a kit list, give the pack import an arm column naming the study arm each kit is for (see Bulk create packs on the pack type's page). In a study that conceals its allocation, only someone holding trial.readAllocation can do this.

Packs given out this way are recorded in the event log as assignPack, marked as given by randomisation, and on the participant's randomiseParticipant entry. Changing the setting is recorded as setRandomisationPacks.

Who can do what

Archived, withdrawn and unallocated participants can't be randomised, nor can anyone already put in an arm by hand. Every randomisation is recorded in the event log as randomiseParticipant, with the arm withheld from anyone who can't see it, and setting up or extending the sequence as createAllocationSequence and extendAllocationSequence.

Automatic membership

A group can fill itself. When editing the group, tick Add participants automatically and choose what adds them:

  • When they give a particular answer on a form. Choose a stage and set the condition, such as "Procedure type is equal to one of E_POEM" on the Diagnosis stage. The condition works exactly like a field's Show if condition on a stage.
  • When they complete a particular stage. Choose the stage, and for one that repeats or is anchor-scheduled, optionally which occurrence, such as the fourth follow-up. A participant joins once they have a response to it, and leaves if that response is deleted.
  • When all their stages are complete. The same as Completed on the trial overview: every stage that counts towards their progress is done. Ad-hoc stages never count, and staff-only stages count only if the study counts them.
  • When they complete their first stage. The same as Started on the overview: at least one stage that counts towards their progress is done. Useful for an "Onboarded" group.

A group that follows progress can't also be used to decide which stages participants see: scoping a stage to it would change their progress, which would move them in and out of the group. Such groups aren't offered when scoping a stage.

For a rule based on an answer, from then on:

  • A participant joins when one of their responses to that stage meets the condition, whoever entered it. On a form filled in more than once, one matching submission is enough: a later one that doesn't match doesn't take them out.
  • A participant leaves if the answer changes, or the response is deleted, so that none of their responses meets it any more. Correcting a mistyped answer moves them to the right group.
  • A response must actually answer the field. A blank answer never puts anyone in a group, even with "is not equal to".
  • People you add by hand stay. Adding someone to the group yourself takes their membership out of the rule's hands: the rule never removes them.
  • People you remove by hand can come back. Taking someone out of the group only lasts while they don't meet the rule. If they still do, they rejoin the next time the rule is checked for them, for example when their form is saved again or the rule is changed. To move someone for good, correct the answer the rule reads, or turn the rule off.
  • Participants already in the study are checked straight away, in the background, when you save a new or changed rule.
  • Turning the rule off leaves everyone it added in the group, as though you had added them yourself.

A rule based on progress follows it the same way. A participant joins when their progress reaches the point, and leaves if it falls back, for example because a response is deleted or a new stage is scheduled for them. The same exceptions apply: people added by hand stay, people removed by hand rejoin if they still meet the rule, and turning the rule off keeps its members.

In the participants table, a group a rule added someone to carries a small lightning icon on its tag; hover over it to confirm. Adding someone by hand clears it, because the membership is then yours rather than the rule's.

Every automatic join and leave appears in the trial's event log as a group membership change made by the system, with the rule that caused it.

A study arm cannot be filled automatically — participants are allocated into an arm, not moved into it by an answer — so the option is not offered on a group marked as one.

Combined with stage scoping, this routes participants to their own forms without anyone having to place them: scope each set of forms to a group, and let the answer that decides which forms apply fill the group. Recipe: branching a study on an answer walks through it end to end.

Acting on several participants at once

Select participants with the checkboxes, then use the menu in the header row. Select all on page selects the current page only.

Action Effect
Send push notification Notifies the selected participants
Add to group / Add to site Assigns all of them
Archive / un-archive See below
Mark as withdrawn / unmark See below
Mark as recruited / unmark See Marking participants as recruited
Delete participants Permanent

Archiving hides participants from the table by default, stops any new data being submitted, stops stage reminders and automatic messages, and excludes their data from exports. It is the right tool for records created in error or participants who never started.

Withdrawing stops stage reminders and automatic messages, and prevents the participant submitting anything further — but staff can still update data on their behalf, and their existing data stays in exports. Your team can still message a withdrawn participant by hand, for example to confirm their withdrawal. This is the tool for someone who has withdrawn from the study proper.

Both are reversible, and both skip participants already in the target state, so re-archiving does not reset the original timestamp.

Marking participants as recruited

What counts as recruited on the overview's recruitment chart and target is a study-wide choice under Settings > Participation > Recruitment targets: participants added, participants who joined the app, participants who gave consent through eConsent, or only those marked by hand. Whatever is chosen, you can also mark a participant as recruited yourself, on a date you give, and they count from that date. Use it for someone recruited on paper who will never use the app, or to correct a date.

On the participant's page, Marked as recruited shows the date, with Mark as recruited (or Change) to set it and Unmark to remove it. To mark several at once, select them in the table and choose Mark as recruited from the header menu, where you pick one date for all of them. The date can't be in the future.

Marking needs trial.writeParticipants, isn't possible while the database is locked, and is recorded in the trial's event log with the participant's other changes. The overview's recruitment figures are recounted straight away, which takes a moment.

Deleting is not reversible and removes the participant along with their data. You are asked for a reason, which is recorded in the trial's event log (Settings > Audit > Logs) with the participant's ID and the list of responses removed — so the log shows who was deleted and why — and to confirm it's you with your passkey or authenticator. The participant's record itself is not copied into the log: deleting a participant is how you honour a request to erase their data. That includes any of their responses that were reset earlier, whose copies in the study record are removed too. Nothing can be deleted while the trial's database is locked.

Archiving or withdrawing a participant takes them out of the Participant journey figures on the trial overview, and out of the behind-schedule count under Needs attention on your home page. Completion percentages therefore describe the participants still taking part. The home page count changes straight away; the Participant journey panel catches up at its next refresh.

The participant record

Clicking a participant ID opens their record, which has its own set of tabs.

Previewing a participant

On pages where leaving would lose your place, clicking a participant ID opens a preview that slides in from the right instead: the conversation on the Messages page; the participant column of Consent > Signed consents, a questionnaire's responses, the Queries list, the Packs list and the trial's event log (Settings > Audit > Logs); and the Follow-ups tab on a site's page. In the participants table, where clicking a row opens the full record, the eye beside each ID opens the preview instead. The preview shows what the Information tab's details panel does (contact details if you hold the PII permission, timezone, status, dates, groups and sites, and any connected services such as Garmin with when they last synced), their schedule, and their notes, which you can read and add to there. The schedule lists the forms open for them now, with how late any overdue one is, and what comes up next (forms, video meetings and calendar events, in date order). Dates and times are in the participant's own timezone, as their reminders are; the preview says so when that isn't yours. Open timeline and calendar takes you to their Timeline tab, which is where to reschedule anything. Open full record takes you to the record itself; closing the preview (or pressing Escape, or clicking the page behind it) leaves you where you were.

To go straight to the full record from one of those pages, ctrl-click (cmd-click on a Mac) or middle-click the ID to open it in a new tab.

A preview shows the same personal details as the record, so opening one is logged in the same way (see Permissions). Reopening the participant you last previewed, without leaving the page, shows them as they were loaded rather than logging another view.

Information

The main summary, and where most day-to-day management happens.

At the top: their ID, status badges, when they were last seen, whether a password is set, which contact channels are available (push, email, SMS, WhatsApp), their groups and sites, and, in a study that randomises, whether and when they were randomised (with the Randomise button for those who can). Personal details — name, date of birth, email, phone, WhatsApp — appear here only if you hold the PII permission.

Edit details opens a dialog covering:

  • Participant ID — changeable after creation.
  • Personal details — name, date of birth, and contact details.
  • Timezone — which governs when scheduled stages and reminders reach them.
  • Login password — set a new one, or save while blank to remove it.
  • Anchor dates — set or clear each anchor for this participant, which recalculates any stages scheduled from it.

Login link generates a direct link the participant can use to get into the study, and can be re-generated if needed.

Further down: Packs assigned to them, connected services such as wearables (with when each was connected and last synced, and the same green or orange dot as the Participants tab on the Garmin Connect logo), their messages with the study team, notes (staff-only, and permission-gated separately from the rest of the record), and a recent activity log.

Typing @ in a note offers the people on your study, and whoever you name is notified. Only people who can already read this study's notes can be mentioned; the notification says who mentioned you and on which participant, and doesn't carry the note's text. See Mentioning people.

Responses

Everything they have submitted, and where staff enter data on their behalf. If you have defined stage groups, they appear here as tabs — one per visit — which is the main reason to set them up. Add data for this stage form opens the form for staff entry.

Timeline

Their schedule: timepoints with a completion percentage, plus any ad-hoc stages. By default it lists the stages available to the participant; if the study counts staff-completed forms, it lists those too. Each timepoint shows as Completed, Available, Pending, or Expired — expired meaning its availability window has closed, so the participant can no longer submit but staff still can.

Wearable responses

Data from connected devices, where the participant has linked one.

Their signed consent, with a download link, plus identity verification details where that was used. Requires the participant consent permission.

Other tabs

Food diaries appear where the feature is enabled for the study, Meetings lists their video calls, and Incentives shows any vouchers issued to them.

Permissions

To do this You need
See the participants table trial.readParticipants — also implied by trial.read
Register new participants trial.registerParticipants, or site.registerParticipants on a site
Edit participant details trial.writeParticipants
Add and remove groups trial.tagParticipants
Randomise a participant trial.randomiseParticipants, or trial administrator
See which arm they are in, in a study that conceals its allocation trial.readAllocation (not implied by trial administrator)
Download the allocation record trial.readAllocation
Assign sites trial.write; choosing a new participant's site is part of registering them
Mark allocated / unallocated trial.allocateParticipants
Archive and un-archive trial.archiveParticipants
Mark as withdrawn trial.withdrawParticipants
Mark as recruited trial.writeParticipants
Delete participants Trial administrator, or trial.deleteParticipants
See names, contact details and dates of birth trial.readParticipantPersonalInformation (PII)
See their consent record trial.readParticipantConsent (PII)
View and add notes trial.readParticipantNotes / trial.writeParticipantNotes
View their responses trial.readParticipants, or site.readParticipants on one of their sites. trial.readParticipantStudyData covers the trial-wide Results, not a participant's record
Enter data on their behalf trial.writeParticipantStudyData, or site.writeParticipantStudyData or site.write on one of their sites, or group.write on one of their groups
Set or clear their anchor dates trial.writeParticipantStudyData, or site.writeParticipantStudyData or site.write on one of their sites, or group.write on one of their groups
Reschedule their stages trial.rescheduleParticipants
Export the table as CSV trial.read

Opening a participant's record, or a preview of it, while you hold trial.readParticipantPersonalInformation is itself recorded in the trial's event log (Settings > Audit > Logs), as a readParticipantPersonalInformation entry naming the fields that were shown. Nobody without that permission sees those fields, and nothing is logged for them.

Site-scoped staff can do much of the above for participants at their own site without any trial-wide keys. See Roles and permissions.