Generating stages from a description
Rather than building a stage field by field, you can describe the forms you need in plain English — or paste the contents of a document — and have Trialflare build them for you: the stages, the data types behind their fields, the branching between questions, and the schedule each form runs on. What arrives is a set of ordinary stages that you then check and edit exactly as if you had made them yourself.
Generating stages is a team feature. If your team has it, Generate stages appears under Import or generate on the Stages page. If it doesn't, ask your account manager.
Writing a description
Open Stages > Import or generate > Generate stages, write your description in the box, and click Generate. If you would rather start from something than from a blank box, Give me an example fills it with a worked description to edit.
A description can be as short as a sentence or as long as a pasted document. What matters is that it says, for each form:
- what it is called — "a screening form", "a weekly symptom diary", "an adverse event report";
- what it asks, roughly in order — the questions, and for a choice question, the options;
- when a question only applies — "if yes, ask how many a day", "for smokers only", "women only";
- who completes it and when — "the participant fills it in daily for two weeks", "completed by the research nurse at the baseline visit", "a month after baseline", "whenever it happens".
For example:
A screening form completed by the study team with Age (integer) and Sex (choice: Male, Female, Other). Ask whether the participant smokes, and only if they do, how many a day. A baseline form with weight (kg), height (cm), and blood pressure. Then a daily check-in the participant completes themselves for 14 days: mood on a 0–10 slider and hours slept.
Several forms can go in one description, as above; each becomes its own stage.
You can also paste content from a document — a questionnaire from a Word file, a table of variables from a spreadsheet — and it is built from what the document says. Questions and their response options are kept as written.
What gets built
Stages and data types. Each form becomes a stage, and each question a data type of the type the description implies — a number, a choice with the options you gave, a date, a slider, a rating, and so on. Data types are named from the form and the question ("screening_age"), and made unique if a name is already taken. If a question asks for a type your team doesn't have, or one that couldn't be recognised, it is created as a short text field and the report tells you which.
Section headers. A description that groups questions — "Demographics first: … Then vital signs: …" — gets a section divider for each group.
Required fields. Questions the description marks as required are set as required; the rest are optional, so it is worth saying which must be answered.
Branching. A question that only applies in certain circumstances gets a condition on the question it depends on, so it is only shown — and only required — when that answer is given. The condition can point at any earlier question in the same form; it can't refer to a later question or one in another form. A branch that can't be built is listed in the report and that question is left showing to everyone, which is the safe way to be wrong.
Participant identifiers are left out. Every response already records which participant it came from, so a "Subject ID" or "Study Number" field is not added unless you ask for it.
Schedule and availability. Where the description says who completes a form and when, the stage is set up to match:
| You say | The stage gets |
|---|---|
| "the participant fills it in", "a diary", "a questionnaire for participants" | Available to participants |
| "completed by the study team", "a nurse-completed form", "a case report form" | Not available to participants — an eCRF |
| "daily for two weeks", "weekly for 12 weeks" | Repeats every n days, that many times |
| "at weeks 0, 6 and 12" | Repeats at that interval, with each occurrence named "Week 0", "Week 6", "Week 12" |
| "a month after baseline", "the day after the screening form" | Made available after that form is completed, with the delay — for a form participants complete; on a staff form the rule is left out, since it would make the form available to participants |
| "whenever it happens", "at any time" | Ad hoc |
| "must be completed within 24 hours" | An availability window of that length |
A form participants complete on a schedule also gets a morning and an afternoon push reminder, which you can edit or remove like any other. A form whose timing you don't mention is left at the defaults, exactly as a stage you created yourself would be. "Made available after" can only point at a form earlier in the same description, since that is the only one guaranteed to exist by then.
The import report
When the stages have been built, an Import report shows how many stages and data types were created and lists anything that didn't go to plan:
- a stage that already existed with that name, and was skipped rather than created twice;
- a question created as text because its type wasn't available or wasn't recognised;
- a branch that couldn't be built, and why;
- a schedule that couldn't be applied — a repeat with no gap, a "make available after" naming a form that isn't there.
None of these stop the rest arriving: the stage is created with everything else in place, and the report tells you what to look at.
Checking what arrived
Generated stages are drafts. Before making a stage available to participants, open it and check:
- the field types — a question meant as a scale may have arrived as a number, or the other way round;
- the options on choice questions, and their spelling;
- the branching, by reading each condition against the question it points at;
- the schedule on the Availability tab, and the reminders on Reminders;
- the data type names, if you have naming conventions for exports.
Everything can be changed in the stage editor as normal.
Tips
- One form at a time is fine. A description can hold several forms, but if a long one isn't coming out right, generate the forms one or two at a time with clearer wording.
- Name the options. "Severity (Mild, Moderate, Severe)" gives you a choice with those three options; "severity" on its own may give you a text box.
- Say when things happen. Timing is the part most often left out of a description, and the part that takes longest to set up by hand afterwards.
- Pasting a questionnaire works well. For a standard instrument, though, check the questionnaire library first — it comes with its licence terms, validation notes and scoring.
- Regenerating creates new stages. Generating again with the same names skips the ones that already exist, so delete a draft you don't want before trying a new description for it.