Getting started — Part 9: Creating an eCRF or Adding Participant Data Yourself

Background

As well as participant-reported outcomes (ePRO), you will probably want to conduct some record-keeping in-house and not show these to participants. You can keep things extremely simple and do this on Trialflare in the exact same way as you set up your questions for participants to fill in off-site (ePRO).

Authenticated members of your team (that perhaps you have allocated permissions to based on your delegation log), will be able to enter participant records through the Participant tab and add data.

Crucially, this will all be audit logged so you will always know who has entered what data and when.

Adding Data for Participants

Your stages can be as simple or as complicated as you need them to be and will depend on the nature of your research or study. Navigating to your participant and under the Responses tab and selecting the "Add data for this date" button will enable you to enter data for the participant. Things like section dividers in your stage designer will help in breaking up large forms.

Changing Participant Responses

Should you need to make changes, these will all be audit-logged. The only difference between submitting data the first time and the second time (amending) is that you will have to provide your sign-off note.

To see what changed, open the response and use the History button in the header of its table, or the clock icon beside a field's date. Both show every submission that wrote to the response or that field, newest first: when, who (a team member by name, or the participant), the sign-off note, and the value each field was given with the value it replaced struck through beside it. Fields you cannot see in the response — restricted or PII data types you don't hold the permission for — are left out of the history too.

When an answer was recorded

The date beside each answer in the response viewer is when Trialflare recorded it — the server's clock, which no one can set. Underneath, entered … is when the device says that particular answer was given, to the second: read down the column and it shows the participant's journey through the form and how long each question took, and a large gap means the answer reached Trialflare later (a diary filled in offline and synced at home, say). It is the device's own report rather than a recorded time, and it is left out if the device's clock was clearly wrong. Answers recorded before 21 September 2026 show the time the device reported, as that was what Trialflare then kept.

Signing responses

Where a study needs the investigator to attest to the data — a CTIMP, say — a response can be electronically signed. Signing is off until a trial administrator turns it on under Settings > Casebook (Enable response and casebook signing); a study that never asks sees nothing of it. Once on, under the response's table a user holding trial.signResponses (granted to the investigator explicitly; trial administrators do not get it by default) chooses a meaning — I confirm this data is accurate and complete, Reviewed or Approved — and clicks Sign. Trialflare then asks them to confirm it's them: with their passkey, or the six-digit code from their authenticator app, and their password as well if they signed in more than a day ago. A session alone is never enough to sign.

The signature records who signed, when (UTC), the meaning, how they confirmed, the version of Trialflare, and a fingerprint (SHA-256) of exactly what the response held at that moment. It is shown under the response — Signed by Ada Lovelace on 20 Sep 2026 14:02 UTC — I confirm this data is accurate and complete — and in the response export as Signed by, Signed at and Signature columns.

If the response is amended after signing, the signature is superseded: it stays in the record, marked as superseded with the date and reason, the signer is emailed, and the response shows it needs signing again. Nothing is ever removed — a superseded signature is part of the audit trail, and the study record export lists every signature, valid and superseded, with its fingerprint so a copy can be verified.

Signing a casebook

In practice an investigator signs a participant's whole casebook — every response collected for them so far — rather than visit by visit. At the top of a participant's page, the Casebook card shows the signing status: Signed when every response carries a valid signature, Partly signed 5/7 when some are new since the last signing or were amended after it, Unsigned when none are. Sign casebook signs every response that isn't already validly signed, in one act with one confirmation; responses already signed are left as they are. The same status appears as a badge in the participants list, so you can see before locking a database which casebooks still need signing.

Because the casebook status is worked out from the responses, a new submission or an amendment to one visit takes the participant back to partly signed, and only that visit needs signing again.

Settings > Casebook also holds the list of signature meanings the signer chooses from (the defaults are I confirm this data is accurate and complete, Reviewed and Approved; add your own or remove ones you don't use), and Require every casebook to be signed before the database can be locked — with that on, locking the database is refused while any participant with responses has an unsigned or partly signed casebook, and the participants list shows which.

Adding Notes for Participants

Anything not in a form? No problem - you can add a note to your participant records to indicate something which was outside the main scope of the data collection. Once you're in the Participants Information tab, click the "New note" button to add something.