Getting started — Part 7: How do I get participant response data?

Background

Your participants are away submitting their responses - this is great! But where are they going? How do you keep track of what stages and forms they have completed? When are their next ones? What if you haven't heard from them and you don't know if they are even being compliant? These many questions we will address here in this section.

Where are the data?

Heading back to the administrator view, you will be able to look into participant records in the Participants tab on the left.

Viewing Participant Data

Each participant will be highlighted in a purple box. Clicking on the participant box, in the example below "p1", you will be able to bring up participant data and metadata.

Viewing Participant Timelines

When you want to see what responses are due from participants, and what they have completed you can view the Timeline tab. Here, you'll know if participants have missed a stage and can prompt them accordingly if they have. You can even see a percentage completion of their journey.

Creating Useful Summaries

As data come in from participants over time, you might want to visualise the results. In the Dashboards tab, you are able to create summaries of individual data types. If you're collecting data over time (For example, Week 1... Week 8) in various groups, you might want to see if there are effects. These effects could be intervention-specific - though you won't know if you are blinded to the specific interventions which one is which. You might want to use this feature to monitor participant well-being. If an intervention is causing harm, you might see some side effects appearing in the data. These potential adverse and harmful effects can be caught quickly with data summaries and can reduce longitudinal harm to participants.

Exporting Data

While Trialflare holds all your data securely on the cloud, we appreciate that you will want to run your own analysis with spreadsheet or statistics software. Everything below is under Results > Export.

Spreadsheets and raw data

  • CSV — one row per response, one column per field. Separate downloads for your core responses, food diaries and each kind of wearable data.
  • Excel workbook — the same data as a .xlsx, with the wearable data on its own sheets. Numbers, dates and times arrive as real cells, so you can sum and sort them without converting anything first.
  • Raw JSON — the underlying records, for anything the columns don't cover. Wearable data is prepared in the background and downloads as a zip.

Statistics packages

These need the advanced export feature on your team plan.

  • SPSS (.sav) and Stata (.dta) — a native data file. Your field names come through as variable labels, and choice options, Likert scale points and rating labels as value labels, so a rating stored as 4 reads as Good. Each variable is marked scale, ordinal or nominal. Nothing needs recoding before you can run an analysis.
  • GraphPad Prism (.pzfx) — a Prism project with a data table already laid out for every numeric measure you collect, one column per study group. Where a stage repeats, the table has a row per visit and keeps each participant in the same position across them, so a repeated-measures analysis pairs the right rows.
  • R — a zip holding your data as a CSV and a script that reads it in with the right column types, factor levels and column labels. It uses base R only, so there is nothing to install. Unzip both files into the same folder and source("load_trial_data.R").

A few things worth knowing about how fields come across:

  • A single-choice field becomes a numbered code with a label for each option, including any option nobody has picked yet. That means two exports of the same trial number the options the same way.
  • A multiple-choice field becomes one yes/no variable per option, which is what lets you count and cross-tabulate the answers.
  • A Likert statement answered Not applicable is recorded as -99 and marked as a missing value, so it is left out of averages but you can still see how many people declined the question. One that was never answered is simply blank.
  • A Stroop, PAL or RAVLT test gets the number of trials, the number correct, the accuracy and the mean reaction time alongside the full transcript of the run, so the results can go straight into an analysis.
  • Field names are shortened to something the package will accept as a variable name — SPSS allows 64 characters, Stata 32 — and made unique. Your original wording is kept as the variable's label, so that is what you will see in the output.

The study record

For the trial master file, an audit, or when a study ends, Results > Export > Study record builds everything about the study into one zip file — not just the responses. It is built in the background (a study with a long history takes a minute or two; you can carry on working) and downloads when ready, and building it is recorded in the event log.

Inside:

  • README.txt — what the archive is, when and by whom it was generated, the version of Trialflare, and which of the layers below it contains.
  • manifest.json — every file with its size and SHA-256 checksum, so a copy can be verified later.
  • configuration/ — the trial's settings, the data dictionary (every data type with its format, constraints, options, PII/restricted flags, formula and the stages it appears in), every stage's components in order with their conditions, and the groups, sites, anchors, consent forms and automatic rules — plus every configuration version (below): a register of them and each version's full snapshot with what changed.
  • access/ — who currently has access to the trial, at which scope, with which permissions or role. Grants and revocations over time are in the event log.
  • participants/ — every participant, their groups, sites and status.
  • responses/ — the stage responses (the same CSV as Download results as CSV), the history of every response — each submission, who made it, the sign-off note, and each field's value with the value it replaced — and the source data verifications.
  • queries/ — every query and its comment thread.
  • consents/ — every consent given and the signed PDFs, with the checksum recorded when each was generated.
  • files/ — an index of the eTMF files (the files themselves are downloaded from the Files tab).
  • event-log/ — the complete event log, with no row limit.

The record contains what you are permitted to see, under the same permissions as the rest of Trialflare: participants' personal information, restricted and PII data types, and consents are each included only if you hold that permission, and the README says which. Only a trial administrator who can export data can build it.

It does not include wearable data or the eTMF files, because each has its own download (above and on the Files tab) and can be very large.

The same record is built automatically each time the trial's database is locked, and kept under Settings > Locks > Locked datasets with a checksum for every file — the dataset that was locked, identifiable and verifiable later.

Configuration versions

The study's configuration — its settings, stages, data types, groups, sites, consent forms and automatic rules — is edited in place, so the event log can tell you what changed and when, but not what the whole configuration looked like when the study went live. Configuration versions answer that. Each time the trial or its database is locked, Trialflare takes a numbered snapshot of the whole configuration and records what changed since the previous version; the lock itself is recorded in the event log with the version number it was taken under, so the lock's justification ("Go-live approved by the sponsor, 3 March") and the configuration it approved are tied together. If nothing has changed since the last version, no new one is made — relocking an unchanged study refers to the existing version.

You can also record a version at any time under Settings > Locks > Configuration versions (Record version, with a note saying why), for instance to mark a configuration as approved before you lock it. The table there lists every version with when, who, what triggered it, its note, and a summary of the changes since the one before; Changes shows those changes field by field with the value before and after, and JSON downloads the version in full. Any two versions can be compared. Unlocking to make a change and then relocking produces a new version whose changes list is exactly what was altered while unlocked — the record of a post-go-live change.

Integrating Data to your Workspace

A truly unique feature of Trialflare is that we are able to securely synchronise to your organizations workspace. If you're using Microsoft (OneDrive), Google G-suite or Dropbox, you can use single sign-on (SSO) to have Trialflare synchronise the data to your workspace in real time.

Viewing Data in your Workspace

The below example uses Google, however, if you're a Microsoft-based organization (Outlook, Teams, OneDrive), the principle is the same. Once you click through to your sign-on portal, you can begin viewing your data elsewhere!

Important: If you synchronise your data to your workspace, any time a new response is recorded, the data will be overwritten. If you want to play with the data, we suggest you make a copy

If a Sync Fails

If Trialflare cannot write to the file — the connection has expired, consent was withdrawn, or the file has been moved or deleted — the reason is shown against the connection under Results > Integrations, and we email whoever set the connection up. Trialflare tries again each time new data is submitted, and after three failed attempts in a row it disconnects the service so it stops retrying. Failures less than ten minutes apart are treated as one attempt, so a short outage at Google, Microsoft or Dropbox won't disconnect a connection that is working.

No data is lost when a sync fails. Trialflare writes out the whole dataset every time it syncs, so once you have reconnected the service the file is brought completely up to date at the next response.