Data types

A data type is a single piece of information you want to collect — a blood pressure reading, a date of birth, a satisfaction rating. If you have come to Trialflare from another system, you may know these as variables, fields, items, or questions. REDCap users can think of them as roughly equivalent to a field in the data dictionary.

The important thing about data types in Trialflare is that they exist independently of your forms. You define a data type once, then use it in as many stages as you like. Every response to that data type — whatever form it was collected on — is the same variable when you come to analyse your data.

Find them under Data in your study.

Anatomy of a data type

Every data type has three parts.

A name. The internal identifier you will see in exports and when building forms. It is never shown to participants, so use something short and consistent — sleep_quality, last_visit_date. Many teams follow their statistician's naming convention here.

A nickname (optional). A friendlier label, shown throughout the admin interface in place of the name. Sleep Quality reads better than sleep_quality in a list of two hundred variables. The underlying name is still shown underneath, so nothing is hidden.

A format. What kind of value it holds, and how it is presented and validated. This is chosen when you create the data type — see below.

The question text is not part of the data type. How a question is worded, and any instructions that go with it, are set on the stage when you add the data type to a form. That is what lets you ask the same variable differently in different contexts — a baseline form and a follow-up form, for example — while still collecting one variable.

Choosing a format

Formats are grouped into four categories. Which are available depends on what is enabled for your team.

Essential

The everyday inputs.

Format Use for
Short text A word, phrase or sentence
Long text A paragraph or more
Choice Selecting one or more options from a list
Integer A whole number
Decimal number A number with decimal places
Slider A whole number on a range you define
Rating One thing rated on a single scale of stars, numbers or smileys (see Rating settings)
Likert matrix Several statements rated on one shared scale (see Likert settings)
Date A calendar date
Date & time A date with a time
Time A time of day only, with no date

You do not need a data type for the date a form was submitted — Trialflare records that automatically for every response.

Advanced

Format Use for
Temperature, Weight, Height Measurements, with unit handling
BMI Collects height and weight, and calculates body-mass index (see BMI settings)
File Uploads — PDFs, spreadsheets, documents
Image Image uploads; on mobile, the participant can use the camera
Video Video uploads
Nutrition input A food or drink item, entered or scanned by barcode
Calculation A value computed from a formula over other data types (see Calculated fields)
Teeth chart Dental chart annotations per tooth
Table Several rows of structured data, with columns you define (see Table settings)

Cognition

Interactive cognitive tests that run in the participant app and record their own results: Stroop, PAL (paired associates learning) and RAVLT (Rey Auditory Verbal Learning Test).

Exports carry the full transcript of a run — every trial, what was shown, what was chosen and how long it took — and, beside it, the numbers you would usually analyse: how many trials there were, how many were correct, the accuracy and the mean reaction time. RAVLT gets the number of learning trials, the best single trial's recall, and the recall after the interruption list.

PROMIS

Validated NIH patient-reported outcome measures, administered through the Assessment Center: a PROMIS Form (a single instrument) or a PROMIS Battery (several administered in sequence). These are scored for you — forms produce a T-score, and eligible batteries produce a PROPr score.

BMI settings

The BMI format has one setting of its own: Hide the BMI indication from this field.

By default, as soon as someone enters a height and weight the field shows the calculated BMI, a dial, and a category label — Underweight, Healthy, Overweight or Obese. Ticking this box removes all three, leaving just the height and weight inputs.

Use it where showing participants a verdict on their body would be inappropriate or could influence what they report — eating disorder research and body image studies are the obvious cases, but it is worth considering in any study where the BMI is incidental to what you are actually measuring.

The BMI is still calculated and stored either way, so your data is unaffected, and staff still see the figure and category when reviewing responses and results. The setting only changes what is shown on the field itself, and it applies everywhere that data type is used — the participant app, the participant portal, public questionnaires, and staff data entry.

Rating settings

A rating asks about one thing on a single scale — how would you rate your sleep last night? — answered by tapping one of a row of symbols. It is the single-question counterpart to a Likert matrix: use a Likert when you have a set of statements sharing one scale, and a rating when you have one question.

How many points the scale has, from three to six. Five is the default.

How it is drawn: stars, numbers or smileys. This is presentation only — it changes nothing about what is stored, and you can switch between them at any time, including mid-study. Stars fill up to the point chosen, the way a star rating does everywhere else; numbers and smileys highlight only the point chosen.

The labels, one per point, lowest first. These start from a sensible set for the number of points you picked — Very poor through to Excellent on a five-point scale — and you can edit any of them. Use the default labels puts them back. Labels are what a respondent reads, and what your exports use to label each value.

A preview of the finished field appears underneath as you build it, so you can see what your choice of symbol and point count actually looks like before saving.

What gets stored is the number, from 1 up to the number of points — never the label. That is what makes a rating usable as a number everywhere else: conditions, scoring rules, calculations, dashboards, automatic queries and exports all treat it like any other whole number. In the SPSS, Stata and R exports the labels come through as value labels, so a 4 reads as Good without you having to recode anything.

If you need a scale running from zero, a bipolar scale from −2 to +2, or a range wider than six points, use a slider or a Likert instead — a rating always runs from 1 upwards.

Changing a rating after it has collected data

Re-wording a label is safe, and it applies to the ratings already collected. Nothing is stored against the label, so changing point 3 from Fair to Acceptable means every response that chose point 3 now reads Acceptable — everywhere, including in past exports you generate again. Fixing a wording mid-study costs you nothing. Changing the symbol is safe for the same reason.

Reducing the number of points is the one edit to think twice about. A rating above the new maximum stays in your data and in exports, but nobody can choose it any more, and a response holding one cannot be re-saved until that field is answered again. Increasing the number of points is safe — existing answers keep the position they were given, though be aware that a 4 on a scale that used to have five points does not mean the same thing as a 4 on a scale that now has six.

Editing anything on a field nobody has answered yet is always safe.

Ratings work on the web, in the participant portal, on public questionnaires, and for staff data entry. Support in the participant app ships with the next app release; the data-type list shows which formats participants can use on their phone today. On a phone the labels for each individual point are not shown — six of them would be too narrow to read — so the two ends of the scale are labelled instead, and the label for whichever point has been chosen appears underneath.

Table settings

A table collects several rows of structured data in one field — a medication list, a set of readings, a log of events. Use it instead of a run of numbered fields when you don't know in advance how many entries there will be.

The columns are what you define. Each has a name and a format: short text, integer, decimal number, or date. Add them one at a time, reorder them with the arrows, and edit the name in place. A table can have up to twenty columns. A preview of the finished field appears underneath as you build it.

Optional marks a column a row may be entered without. Every column that isn't optional has to be filled in for a row to count — so if a respondent starts a row and leaves a required cell empty, the form won't submit until they either finish it or clear the row. A row left entirely blank is ignored rather than stored, so a half-started row can always be emptied to get rid of it.

Maximum rows is the most rows a respondent may fill in, between 1 and 50. Exports get a column for every row and column, so a five-column table allowing ten rows adds fifty columns to your export — set the maximum to what you actually expect rather than to the highest number you can imagine.

If the field is marked required, the respondent has to enter at least one complete row before the form will submit.

Changing a table after it has collected data

Renaming a column is safe, and so is reordering them. Each column keeps its own identity behind the scenes, so the cells already collected stay attached to it however you edit the name or move it left and right.

Removing a column orphans the cells recorded against it, the same way removing an option from a choice field does. They stay in the database but stop appearing in exports and in responses. Changing a column's format has much the same effect on the data already there: cells that no longer fit the new format stop being read back. Both are the edits to think twice about once responses are in — the editor warns you about them.

Editing anything on a field nobody has answered yet is always safe.

Where table data shows up

  • Exports get one column per row slot per column, named like Meds (table [row 1: Dose]). Every response gets the same set of columns, so rows line up whether a respondent filled in one row or all ten; slots nobody used are blank.
  • Responses show the rows as a small grid when you review a submission, and the printed and Word versions of a form draw the same grid — blank, ready to fill in, on a paper form.
  • Conditions and scoring rules on a table can only test whether it has been answered. A table answer is a set of rows rather than a single value, so is equal to and the rest have nothing to compare against; exists (and, for scoring, does not exist) is what you get, and it is met once the table has at least one complete row.
  • Explore and dashboards don't chart a table for the same reason. Use the export to analyse one.
  • Queries are raised against the field as a whole rather than against a particular cell. An automatic query rule on a table can use exists or does not exist — a query when the participant recorded any entries, or when they were asked and recorded none — but not the value comparisons, since there is no single value. Does not exist fires only when the form actually carried the field and it was on screen, so a rule doesn't raise a query on every submission that happens not to include it. Where smart automatic queries are switched on, the anomaly check reads a table's rows by column name and can flag a cell that is implausible for its column, or rows that contradict one another. It never flags a row for being incomplete, because an incomplete row is not stored.

Tables work on the web, in the participant portal, on public questionnaires, and for staff data entry. Support in the participant app ships with the next app release; the data-type list shows which formats participants can use on their phone today. On a phone the grid is turned on its side — each entry is shown as its own block with the columns listed down it, rather than as columns too narrow to tap and type into accurately.

Likert settings

A Likert matrix asks several statements at once, all answered on the same scale — the shape most questionnaires take. Instead of building seven near-identical choice fields, you build one field with seven statements.

The scale is shared by every statement. Start from a ready-made one — 5- or 7-point agreement, 5-point satisfaction, the 0–3 frequency scale that GAD-7 and PHQ-9 are scored on, or a bipolar Much worse to Much better — and then edit it, or build your own from scratch. Each point has a label and a value.

The value is the number stored when a participant picks that point, and it is what gets added up when the field is scored, exported or used in a calculation. So set it to whatever the instrument you are reproducing expects: 0–3 where the questionnaire scores its lowest answer as zero, 1–5 for a plain agreement scale, or −2 to 2 where the middle answer means "no change". A scale can have between two and eleven points, and each point needs a different value.

The statements are the rows. Add them one at a time, reorder them with the arrows, and edit the wording in place. A field can have up to thirty.

Include a "Not applicable" option on each row adds an extra column so a participant can say a statement does not apply to them, rather than having to pick a point on the scale or leave it blank. The two are recorded differently: not applicable is a deliberate answer, blank means unanswered.

A preview of the finished field appears underneath as you build it.

If the field is marked required, the participant has to answer every statement before the form will submit — one or two is not enough. Where some statements may genuinely not apply, turn on the "Not applicable" option so there is something for them to choose.

Changing a Likert after it has collected data

Re-wording a statement is safe, and so is reordering them. Each statement keeps its own identity behind the scenes, so the answers already collected stay attached to it however you edit the wording or move it up and down the list. Fixing a typo in a question mid-study costs you nothing.

Removing a statement orphans the answers given against it, the same way removing an option from a choice field does. They stay in the database but stop appearing in exports, in Explore and in the total. That is the one edit to think twice about once responses are in.

Changing a scale point's label re-reads existing responses rather than orphaning them: an answer stored as 2 shows whatever 2 is labelled as today, not what it said when the participant chose it. Changing a point's value is the riskier one — past answers stored against the old value no longer match the scale, so they drop out of the totals and out of the columns beside them.

Editing anything on a field nobody has answered yet is always safe.

Where Likert data shows up

  • Exports get one column per statement, plus a (likert total) column. Unanswered statements are blank; ones answered Not applicable read N/A in a CSV or spreadsheet, and are recorded as a missing value of -99 in the SPSS, Stata and R exports so they stay out of your averages. The total always matches the sum of the columns beside it.
  • Explore offers each statement as its own column, and the total as another.
  • Scoring rules on a stage component compare against the total across the statements that were answered, so a rule like is more than 12 means the whole matrix, not any single row.
  • Calculations work the same way: a {{placeholder}} for a Likert field resolves to that total. See Calculated fields.
  • Automatic queries can be set against the total too, so a rule like greater than 12 raises a query on the matrix as a whole. No single statement can trip the threshold on its own. A rule that just checks the field exists is met as soon as any statement has been answered — including one answered Not applicable, which is an answer rather than a blank.
  • Conditions can branch on a Likert either way. Pick a statement to branch on that statement's answer — show this field if "I have been in pain" is more than 2 — or leave the picker on total across statements to branch on the whole matrix. Zero is a value like any other, so is equal to 0 works on a scale scored from zero.

Likert fields work on the web, in the participant portal, on public questionnaires, and for staff data entry. On a narrow screen the grid is broken up automatically — each statement is shown with the scale listed underneath it, rather than as columns that would be too narrow to tap accurately.

Format-specific settings

Once you pick a format, a third section appears with its own settings — minimum and maximum lengths for text, value ranges for numbers, the options list for a choice field, earliest and latest dates, and so on. Choice fields can additionally allow multiple selections, include a "none of the above" option, or display as a dropdown.

A choice field's options are listed one per row in the order participants see them. Use the arrows on a row to move an option up or down, and the bin to remove it. Reordering only changes how the options are presented — the answers already given are unaffected, since what is stored is the option's text — so it is safe at any point in a study. Removing one is not: it orphans the answers given against it, the same way removing a Likert statement does. The same option cannot be added twice, since two identical options would be indistinguishable in the data.

Once a choice field exists, an automatic query can target a particular option rather than only checking whether the field was answered: pick is one of or is none of and select the options the rule is about. Is one of raises the query when the participant selected any of them, is none of when they selected none. On a field that allows multiple selections, that means a rule naming Nausea fires whether nausea was picked alone or alongside other options. The extra "None" option can be targeted like any other.

Leave a number field's minimum or maximum blank — or use Remove minimum / Remove maximum — for no limit in that direction. 0 counts as a limit, so a minimum of 0 rejects negative numbers.

Not every format works everywhere. A few formats are not available on the mobile app, and a few are not available on public questionnaires. The stage editor warns you if a form uses one in a context that cannot render it, so build the form and check for warnings before publishing.

Look-back

Number, slider and rating fields can show a participant the value they last entered, so they can judge today's answer against it — useful on a diary or any stage that repeats, where how does this compare with last week? is the question you actually want answered. Tick Enable look-back for this data type on the field itself.

Look-back is a participant-app and portal feature. It changes nothing about staff data entry, nothing about what is stored, and nothing about exports; the participant simply sees their previous answer alongside the field.

There is also a trial-wide Enable look-back in the trial's general settings, which turns look-back on for every number, slider and rating field in the trial. While that is on, the per-field setting makes no difference either way — a field shows a look-back whether or not its own box is ticked. Turn the trial-wide setting off if you want to choose field by field.

Restricted and PII data types

Two checkboxes on every data type control who can see the responses.

Restrict this data type — responses are only visible to users who additionally hold trial.readParticipantStudyDataRestricted. Use it for anything that should be hidden from monitors or blinded staff.

This data type contains PII — responses are only visible to users who hold trial.readParticipantStudyDataPii. Use it for direct identifiers: names, addresses, NHS numbers, dates of birth.

Both are applied at the field level, so a single form can mix ordinary, restricted and PII fields, and each user sees only the layers they are entitled to. Flagged data types are badged in the list so you can audit them at a glance.

Flagged fields are also never sent to an AI model. Smart automatic queries, participant and trial insights, Scorch and any connected AI assistant all leave them out — regardless of the permissions held by the person asking — so ticking either box is also the way to keep a field out of Trialflare's AI features.

Creating data types

One at a time

Click Create a new data type (variable), fill in the name (and nickname), choose a format, and configure it. That's it.

You don't have to come to this screen to do it: the same dialog is available from the field picker and from a field's own settings inside the stage editor, which is usually the quicker route when you are building a form.

In bulk, from a CSV

Bulk create data types takes a CSV with name, type and optionally nickname columns, and creates them all in one go. The type column takes the format's internal key — slider, date, integer, and so on. Download the sample file from the dialog to get the shape right.

Bulk creation is the quickest route when you have a data dictionary from your statistician, but it only sets the name, format and nickname. Anything format-specific — the options on a choice field, a slider's range, a Likert's scale and statements, a table's columns — still needs setting on each one afterwards. (A bulk-created Likert starts with a 5-point agreement scale and no statements, so it needs editing before it can be used; a bulk-created table starts with a single short-text column called "Value" and ten rows. A bulk-created rating is the exception — it arrives as a usable five-point star scale with default labels, so it only needs editing if you want something different.)

By copying an existing one

The copy button on any row clones it, settings and all. This is much the fastest way to build a set of similar fields, such as ten identically-configured 1–5 sliders.

Editing and deleting

Editing works at any time — click the row, or use its Edit button. Be careful changing the format or the constraints of a data type that already has responses against it: existing data is not migrated or re-validated, so you can end up with responses that no longer fit the current definition. Renaming is safe; narrowing a range or removing a choice option needs thought.

Deleting is blocked while a data type is used by any stage — Trialflare will refuse and tell you so. Remove it from the stages that reference it first. This applies to bulk deletion too.

There is no undo, and deleting a data type that has collected responses loses that data, so treat deletion as a study-setup activity rather than a live-study one.

Tags

Tags are a way of grouping data types for your own convenience — by domain, by visit, by instrument, by whoever owns them. A data type can carry as many tags as you like.

Create and edit tags from the Filter by tag menu, where each tag gets a name and a colour. Then either add tags to a single data type from its row, or select several with the checkboxes and use the bulk menu to tag them all at once.

Tags do not change behaviour anywhere — nothing is scheduled, scored or restricted by them. They exist to make a long list navigable, and they matter more than you would expect once a study has a few hundred variables. They also filter the data type picker when you are building a form, which is where you will feel the benefit most.

Finding things in a long list

The list supports:

  • Search by name or nickname.
  • Filter by tag, and filter by format (only formats actually in use are offered).
  • Sort by name or format, ascending or descending.
  • Pagination at 100 per page.

Permissions

To do this You need
View the Data area trial.readDataTypes — also implied by trial.read
Create, edit, delete, copy, bulk-import, and manage tags trial.write (or trial administrator)
View responses collected against ordinary data types trial.readParticipantStudyData
View responses for restricted data types trial.readParticipantStudyDataRestricted
View responses for PII data types trial.readParticipantStudyDataPii

Data types cannot be changed at all while the study or database is locked.

See Roles and permissions for the full list.