Stages

A stage is a form. Other systems call these instruments, forms, CRFs, visits or questionnaires; in Trialflare everything you collect data on is a stage, whether it is completed by a participant on their phone (ePRO) or by a member of staff at a site (eCRF).

Stages are built from data types — you add a data type to a stage, and write the question wording there. Find them under Stages in your study.

The Stages area has four tabs: Stages, Stage groups, Anchors and Food diaries. This article covers the first.

The stage list

Each stage shows its name and a set of badges telling you how it is configured at a glance: how many data types it contains, whether it repeats and how often, whether it is ad-hoc, how many reminders it has, and whether questionnaire mode is on.

Stages have an order, set with the up and down arrows. This is the order participants see them in, so it is worth getting right.

The box above the list filters it by name as you type. The arrows are switched off while a filter is on — reordering moves a stage past its neighbour in the full list, which may be one the filter is hiding — so clear the filter to change the order. Select all picks out the stages currently shown rather than every stage in the trial.

Clicking a row opens that stage for editing. From the row menu you can edit, make a copy, copy to another trial (any data types the stage uses are re-created in the destination study), download as PDF or Word — useful for source documentation and ethics submissions — or delete.

Deleting a stage loses any data collected against it. There is no undo. You can also select several stages with the checkboxes and delete them together.

Creating a stage

Create a new stage opens the editor. Depending on what is enabled for your team, the Import or generate menu may also offer:

  • Generate stages — describe the forms you need in plain English, or paste content from a document, and have them built for you: the stages, their data types, the branching between questions and each form's schedule. See Generating stages from a description.
  • Browse the questionnaire library — import a standard instrument, with its licence terms, validation notes and scoring shown before you commit.
  • Import from REDCap CSV — bring in an existing data dictionary.

All three produce ordinary stages you then edit normally.

The editor has four tabs. A stage is saved as a whole, with the Save stage button at the bottom — the tabs are sections of one form, not separate saves.

Content

Where you set the stage's name and description (general instructions shown at the top), and build the form itself.

Adding fields

Add a field opens the picker. Choose an existing data type — searchable, and filterable by tag — or use Create a new data type (variable) to build one without leaving the editor. A data type created that way is added to the form at the position you were inserting at, and its field opens straight away for you to write the question.

You can also add three things that are not data types and collect nothing:

  • Title area — a heading, for breaking up a long form.
  • Section divider — a heading with a description, for a more substantial break.
  • Scheduled notification — fires a notification to the participant a set number of seconds after they reach this point in the form. Useful for timed tasks: "take your reading now, we'll remind you in 15 minutes".

Fields can be reordered, and new ones inserted at any position using the Add a field control that appears between existing fields.

Configuring a field

Opening a field gives you:

  • Question title and description or instructions — the participant-facing wording. This is where the actual question text lives, not on the data type.
  • Required — whether it must be answered.
  • A guidance or informational video — uploaded and shown with the question.
  • Data type (variable) settings — which data type the field collects, and that data type's own settings: a number's limits, a choice's options, a slider's range, a Likert's scale and statements, and so on. Whatever the chosen format offers on the data types screen is offered here. New data type (variable) creates one from scratch and selects it.
  • Conditions — show this field only when another field in the same stage has a particular answer. Conditional fields that stay hidden are not required, do not score, and do not count towards completion.
  • Scoring — points awarded based on the answer. This drives the total score used by questionnaire rules and by automatic queries. For a Likert matrix, the answer being scored is the total across its statements.

Conditions and scoring on a table field can only test whether it has been answered: its answer is a set of rows rather than a single value, so exists and does not exist are the only operators offered.

A does not exist scoring rule awards its points when the field was on the form and left blank, so it can be used to score a missing answer. A field hidden by a condition is not scored either way — nobody was asked it.

Data types are shared between stages, so editing one from inside a stage changes it everywhere it is collected — the same care applies as when editing it on the data types screen. Those settings are saved when you save the field, whereas the question wording and the rest of the field is only saved when you save the stage.

Trialflare flags a field with a warning triangle if it is incomplete, or if the same data type has been used twice in one stage.

Automatic queries on a score

An automatic query can be raised from a score as well as from an answer. Two rules do this:

  • Response score — the total for the whole submission, added up from the scoring on every field the participant was asked. It is about the submission rather than any one field, so a query using it does not have to name a data type: leave Data type as No data type — use the response score and the query is raised against the submission itself.
  • Data type score — the points the query's own data type scored on that submission, which is not the same as the total it contributes to.

A query with no data type must also name a trial stage. Without one it would be judged against every submission in the trial, including stages that award no points at all — those score zero rather than nothing, so a less than rule would query all of them.

The submission is judged as it stands. On a stage that allows a partial submission that means a part-finished form is judged on what it scores so far, with the fields still to come counting as blank — so a rule can be written to catch exactly those, in the same way a does not exist scoring rule awards points for a missing answer.

Any query using a response score rule is raised once per response, however many times that response is added to or corrected. The score is recalculated on every submission, so it would otherwise be raised over again; the query records the score at the moment it was raised.

Either rule can be combined with the rest, so a query can ask about an answer and the score of the submission it arrived in at once.

Conditions on titles, dividers and notifications

Title areas, section dividers and scheduled notifications each take a Conditions tab of their own, set up exactly as a field's is: the component appears only when another field in the same stage has a particular answer. Use it to keep a heading from introducing a section that isn't there — a "Medication details" divider above a set of fields that only appear for participants taking medication, say — or to offer a timed reminder only to the participants it applies to.

Hiding a divider hides the divider itself, not the fields beneath it. There is no concept of a section that collapses as a unit, so to hide a whole section put the same condition on the divider and on each field under it.

A hidden scheduled notification is never offered, so the participant cannot set its timer. A timer they set before the condition stopped being met still arrives — setting one schedules it there and then.

As for a field, the answer being branched on has to come from a field above the component in the form, and a component whose condition depends on a field that is itself hidden is hidden too.

Post-submission text

Rich text shown to the participant immediately after they submit this stage. Good for "thank you, your next form is due on Tuesday" or instructions for what to do next.

Submission rules

Allow partial submission lets the stage be submitted with required fields left blank. Per-field validation — valid choices, number ranges — still applies. Use it where getting a partial record is better than getting none.

Display

By default a stage is shown to participants as a single form they scroll through. Show one question per screen shows one question at a time instead, with Next and Back buttons to move between them and a final screen to submit from. Title areas and section dividers are shown above the question that follows them, so a heading still introduces its section.

This applies in the participant app and on questionnaire links. It does not change how staff enter responses on a participant's behalf, which is always the full form.

A participant can't move past a required question until they have answered it, so they aren't sent back through the stage on submit; Allow partial submission lifts that, as it lifts the check on submit. Conditional questions still appear and disappear as answers change, and the count of questions adjusts with them.

Show a progress bar — available once one question per screen is on — adds a bar along the top of the stage, with a "Question 3 of 10" count, showing how far through the participant is.

Reminders

Reminders nudge participants to complete the stage on each day it is available.

Add a reminder, pick an hour in the participant's local time, and choose the channels: push, SMS, WhatsApp, email. SMS and WhatsApp only appear if enabled for your team. Each reminder has its own title and body, so a morning nudge can read differently from an evening one.

You can have several reminders per stage, but only one per hour.

Two things to know:

  • Push reminders only reach participants who have allowed notifications on their device. See Push notifications — that article is written for participants, so you can send it to them directly.
  • WhatsApp ignores your title and body. WhatsApp's rules on templated messaging mean a generic reminder is sent instead. If the wording matters, use another channel.

Availability

This tab decides who can complete the stage, when it appears, and how often.

Stage scope

By default a stage reaches every participant in the trial. Add scoping rule narrows it, and you can add one rule for sites and one for groups:

  • Site — only participants at the sites you pick. Useful when sites use different variants of a form.
  • Group — only participants in the groups you pick. Useful for a stage that only one study arm or cohort completes.

Within a rule the sites or groups are alternatives: a participant at any of the chosen sites matches. Between the two rules they combine, so a stage scoped to Leeds and to the Treatment group reaches only participants who are both at Leeds and in Treatment. The summary line under the rules spells this out.

A participant with no site matches no site rule, and a participant in no group matches no group rule — in either case the stage never appears for them. Every rule you add is a rule someone can fail, so keep them to what you need.

Scoping hides the stage from the participant's timeline entirely, so it is hidden from staff viewing that participant too — there is no row to enter data against. Use scope for stages that genuinely do not apply to those participants, and the availability settings below for a stage that everyone has but only staff complete.

Stage availability

Three options:

  • Not available to participants — the stage does not appear in the participant app at all. This is the eCRF case: staff enter the data on the participant's behalf.
  • Available to participants — appears immediately.
  • Make available after… — appears once a trigger is met, so it can fall on a different date for each participant. The trigger is either stage completion (optionally a specific recurrence of a repeating stage, or "match recurrence" to pair up two repeating stages) or an anchor date. Either can be offset by a number of days.

If questionnaire mode is on, these settings only govern the participant app and portal. Anyone with the public link can submit at any time regardless.

Schedule stage

How often the stage can be completed:

  • Will not repeat — once only.
  • Will repeat — every n days, for a given number of occurrences. Each occurrence is tracked separately, and you can name each one (see below).
  • Ad-hoc input — completable any number of times, whenever the participant likes. Ad-hoc stages are excluded from progress and behind-schedule calculations, since there is nothing to be late for.
  • Anchor-scheduled — appears on specific days relative to an anchor date. Add one slot per appearance, each with an anchor and a day offset (which can be negative). This is how you build a visit schedule: day −7, day 0, day 30, day 90.

Naming each occurrence

Every occurrence of a repeating stage carries the stage's name, with %n in the name replaced by the occurrence number: a stage called "Recall %n" that repeats three times reaches participants as "Recall 1", "Recall 2" and "Recall 3".

If you would rather give particular occurrences their own names, choose Name occurrences individually under This stage will repeat and fill in the ones you want to change — "First recall", "Second recall". Any occurrence you leave blank keeps the %n name, so you can rename just the first and last if that is all you need. The names appear wherever the occurrence does: in the participant app and portal, on a form link, and on the participant's timeline in the web app. They also show up wherever you pick out a single occurrence — an automatic message, an anchor rule, a stage group, a Make available after… trigger, and the buttons for entering data or generating a form link on a participant's record. Occurrences you have not named still read as "Recurrence 1", "Recurrence 2" in those pickers. Renaming an occurrence is safe once responses are in — exports continue to identify occurrences by their number.

Availability time

Stages become available at midnight on their scheduled day by default. Set a different time here — in the participant's local timezone — if you would rather a form appeared at, say, 08:00.

Availability window

By default a stage stays available until it is completed. Set Available for n hours to close it after a fixed period: once the window passes, the stage disappears from the participant's app and no new submissions are accepted.

Two consequences worth knowing:

  • Data can still be entered on the participant's behalf in the web app after the window closes.
  • An expired stage stops counting towards that participant's progress, so letting a window lapse nudges their completion percentage up. See Trial overview.

The window does not apply to ad-hoc stages, which are always on demand.

Behind status

Participants are marked behind when they have not completed a stage in time. Two settings control how this stage contributes:

  • Exempt from "behind" status — this stage never makes anyone behind, however overdue. Use for optional or opportunistic forms.
  • Behind cutoff time — by default a stage counts as behind from midnight at the end of the day it was due. Set a cutoff time to mark it behind as soon as that time passes on the day itself, with no grace period.

Questionnaire

Turns the stage into a public web form with its own link, for polls and screening. This has its own article: Screening questionnaires.

Editing a live stage

Stages can be edited at any time while the study is unlocked, and changes take effect immediately for every participant.

Adding a field to a stage that participants have already completed means their existing responses simply have nothing recorded for it. Removing or repurposing a field on a live stage is where trouble starts, and is usually better handled by adding a new field and retiring the old one.

No stage configuration can be changed while the study or database is locked.

Permissions

To do this You need
View stage configuration trial.readStages — also implied by trial.read
Create, edit, reorder, copy, import and delete stages trial.write (or trial administrator)
View data collected on stages trial.readParticipantStudyData

See Roles and permissions.