What this is, and who it is for
Every status in Trialion, with what it means, what moves it, and what it allows. If a move is not listed, the system refuses it. The transition tables below are read from the code by a script, so they cannot drift from it; the wording around them is checked by hand.
Where a status has two names, the code name (in monospace) is what the API and the exports carry, and the screen name is what people see.
Where to find it
Statuses appear as coloured labels on the screens: the state chip on a study's Overview, the version cards, the status of a participant in the Subjects list, the status of a query, a site, an export. A status you cannot change shows as a plain label; one you can change opens a menu of the moves that are allowed for your role. Which role may make which move is on Who can and cannot.
The study
A study has one state at a time. A study moves Setup → Active by itself when version 1.0 goes Live; every other move is a person's act with a written reason.
| Action | From | To | Permission | Two people |
|---|---|---|---|---|
| hold | Active | On hold | study.state.change | no |
| resume | On hold | Active | study.state.change | no |
| close enrollment | Active, On hold | Closed to enrolment | study.state.change | no |
| complete | Closed to enrolment | Completed | study.state.change | no |
| lock | Completed | Locked | study.lock | yes |
| unlock | Locked | Completed | study.lock | yes |
| archive | Locked | Archived | study.archive | no |
| State (screen name) | Code name | What it is |
|---|---|---|
| Setup | setup | The study exists and is being prepared: the team, the documents, the design of version 1.0. There is no Live data yet |
| Active | active | Version 1.0 is Live. Participants are screened and enrolled and data is captured |
| On hold | on_hold | Enrollment is paused; everything already enrolled carries on |
| Closed to enrolment | closed_to_enrolment | No new participants; data entry and cleaning continue |
| Completed | completed | Data entry has ended; only queries, source data verification, signatures, safety reporting and deviations continue; a value is corrected only by answering a query. No version work |
| Locked | locked | The database is frozen by two people with e-signatures. Nothing can be written |
| Archived | archived | Read-only for retention. This cannot be undone in the interface |
What each state allows is a table on Who can and cannot. A written reason is required for every move.
A version of the design
A version moves through Build, UAT, sign-off and Go live; a study has at most one version in flight at a time.
| State | Moves it offers |
|---|---|
| build | submit to uat, withdraw |
| uat | pass cycle, fail cycle, withdraw |
| awaiting signoff | sign, reject, withdraw |
| approved | go live, withdraw |
| live | (none: final) |
| superseded | (none: final) |
| withdrawn | (none: final) |
| State | Code name | What it is |
|---|---|---|
| Build | build | The design can be edited. This is the only state in which it can |
| UAT | uat | The design is frozen and under test in a cycle against test data |
| Awaiting sign-off | awaiting_signoff | A cycle passed; the three sign-offs (author, QA, approver) are being collected |
| Approved | approved | All three signed, bound to the design the passed cycle tested; waiting for Go live |
| Live | live | The released version. Its design is sealed; a change is an amendment |
| Superseded | superseded | Replaced by a newer Live version. Data stays bound to it |
| Withdrawn | withdrawn | Set aside before it went Live, with a reason |
A UAT cycle is open, passed or failed; a failed cycle returns the version to Build. See Test a version in UAT and Sign off a version and go live.
A site
| From | Can move to |
|---|---|
| registered | active, closed |
| active | suspended, closed |
| suspended | active, closed |
| closed | (none: final) |
A site is registered first, which lets it do nothing; it is activated with an ethics approval reference and date and a confirmation of training; suspended and closed need a written reason. Only an active site can enroll. A closed site takes no team. See Open a site.
A participant
| From | Can move to |
|---|---|
| screening | enrolled, screen failed |
| enrolled | active, randomization failed, withdrawn, lost to follow up |
| active | completed, withdrawn, lost to follow up |
| screen failed | (none: final) |
| randomization failed | (none: final) |
| completed | (none: final) |
| withdrawn | (none: final) |
| lost to follow up | (none: final) |
| Status | Code name | What it is |
|---|---|---|
| Screening | screening | Consent and screening are recorded; the investigator has not yet decided eligibility |
| Screen failed | screen_failed | The investigator found the participant ineligible, with a coded reason. Data is kept |
| Enrolled | enrolled | Eligible and enrolled; the visit schedule is generated from the baseline date |
| Randomization failed | randomization_failed | Enrolled but never randomized (randomized studies only) |
| Active | active | On study |
| Completed | completed | Finished the study. Completion lists any unsigned forms and needs an acknowledgement |
| Withdrawn | withdrawn | Left the study, with a coded reason and a safety follow-up state |
| Lost to follow-up | lost_to_follow_up | Cannot be reached, with a reason |
A reason is required for screen failed, randomization failed, withdrawn and lost to follow-up. Data can be captured while a participant is screening, enrolled or active only; a completed participant's record is corrected only by answering a query. Eligibility is separate: pending, eligible or ineligible, decided by the investigator alone. See Change a participant's status.
A participant's visit
A visit has a stored status set when it is created (scheduled, or in_window for an unscheduled visit) and a window state that is worked out from the calendar every time it is read, so it is never stale. Only the window state gates data entry.
| Window state | When | Data entry |
|---|---|---|
Not yet open (not_yet_open) | Before the scheduled date minus the days allowed before it | Blocked unless an early-access exception with a reason has been recorded |
In window (in_window) | Inside the allowed range | Allowed |
Missed (missed) | After the range | Allowed: a late visit must still be recordable |
The stored-status vocabulary also lists completed and out_of_window; the window state above is what governs data entry. A visit is never closed by being late, and nothing marks a visit "done": how far it has got is read from the records captured against it, and locking is per record.
A form's design and its records
| From | Can move to |
|---|---|
| draft | active, archived |
| active | draft |
| archived | (none: final) |
A form in the design is a draft until it is made active; an archived form is retired. Only a draft form's content can be edited; reopening an active form for editing sets its visit bindings aside (see Versions, reopening and publishing). A record (one participant's answers to one form at one visit) is in progress or complete, and separately unsigned or signed and locked.
A query
| From | Can move to |
|---|---|
| open | answered, escalated |
| answered | closed, reopened, escalated |
| reopened | answered, escalated |
| closed | reopened |
| escalated | answered, closed |
Open, answered, reopened, escalated and closed; priority and response time are on Work with queries.
A serious adverse event's reports
| Status | Code name | Meaning |
|---|---|---|
| Pending | pending | The initial report has not been made |
| Reported | reported | The initial report was made. Terminal: a mis-filed report is a supervised correction, not a status write |
| Not required | not_required | The event does not need an expedited report |
| From | Can move to |
|---|---|
| pending | reported, not required |
| not required | pending, reported |
| reported | (none: final) |
A follow-up report is pending, sent or not required; the medical review is agreed, disagreed or needs information; the reconciliation with the safety database is matched or discrepancy. See Review and reconcile a serious adverse event.
A protocol deviation
| Status | Meaning |
|---|---|
| Open | Reported |
| Under Review | Being assessed |
| Resolved | Closed out |
| Reportable | Needs reporting to a regulator or an ethics committee |
Any status can be set from any other, with a written reason: a move to Resolved or Reportable is a QA decision and must be attributable. Severity is Minor, Major or Critical. See Report a deviation.
A document
| Status | Meaning |
|---|---|
| draft | Uploaded, not yet controlled |
| approved | The version in force |
| archived | Superseded or withdrawn, kept |
An export
| From | Can move to |
|---|---|
| queued | running, failed |
| running | ready, failed |
| ready | expired |
| failed | (none: final) |
| expired | (none: final) |
A ready export expires after seven days, after which its file is no longer served. See Export data.
Source data verification
Worked out per value when read:
| Status | Meaning |
|---|---|
| pending | Targeted by the plan and never acted on |
| verified | Checked against the source, and the value has not changed since |
| stale | Was verified, but the value has changed since |
| discrepancy | Checked and did not match; stays until it is verified again |
A rule
| From | Can move to |
|---|---|
| active | disabled, retired |
| disabled | active, retired |
| retired | (none: final) |
A retired rule is immutable and never deleted. A visit in the schedule is a draft, active or archived.
People, invitations and mail
| What | Statuses |
|---|---|
| An organization | active, suspended (reversible; never deleted) |
| A person in the directory | active, invited (invited, not yet signed in), suspended, locked |
| A membership | invited, active, suspended, ended |
| An invitation | pending (valid for 72 hours from the mail), accepted, revoked; a link that has expired or been replaced says so |
| A custom role | active, suspended |
| A mail | queued → sent → delivered; bounced, failed and cancelled are the ends. With plain SMTP nothing reports a delivery, so a mail stops at sent and the screens say so |
What the system records
A move of a study, a version, a site, a participant, a deviation, a query or a document is written to the audit trail with the person, the time and the reason (see Audit events). The status itself is never edited in place: the previous value stays in the history.
What you cannot do, and why
- Move to a status that is not in the table. The system refuses it with
validation.invalid_state_transitionnaming the status and the move. - Change a final status. Screen failed, completed, withdrawn, lost to follow-up, superseded, withdrawn (version), archived (study), closed (site) and reported (report status) are final in the interface.
- Skip the two-person steps. Lock, unlock and the three version sign-offs need different people.
Compliance Q&A
The order is enforced. Each lifecycle is a table in the code that names the moves allowed from each status; a move outside it is refused with a clear message, and for the lifecycles that matter most (versions, queries, signatures, team membership) the same rule is held by the database, so a different client or a direct connection cannot get round it. The tables on this page are read from that code.
Limits: a deviation's status is the one place where any status can follow any other; it is a classification with a written reason, not a sequence of steps.
Evidence: the *-lifecycle.ts, study-state.ts and version-state.ts filesdatabase triggers for versions (P0021 to P0023) and queries (P0027)tests of each lifecycle
Related
Who can and cannot · Change the state of a study · Audit events · Screens