What this is, and who it is for
Trialion has three places called settings, and they are different in kind.
| Settings | Whose | Can it be changed? |
|---|---|---|
| Your settings (the Settings entry of the main menu) | Yours, as a person | No: it shows your account and the sign-in rules. Nothing on it is a switch |
| Study Settings (Settings in a study's menu) | The study's, kept in the version being built | Yes, by a person with study.write, while a version is in Build |
| Organization | The organization's | Not on a screen of the application. See below |
The idea behind all of them: a setting that changes what a study does is part of the design, so it is versioned, tested and signed off like a form. It cannot be edited on a Live study except by an amendment.
Where to find it
- Your settings: the Settings entry in the main menu (every signed-in user), with two tabs, Account and Security and policy, and a page behind it, Where you are signed in.
- Study Settings: inside a study, at the study level (outside UAT and Live), Settings in the study menu. It appears for a person who holds
study.write.
Held by: Organization Admin, Project Manager (study.write).
What you can do
Your settings
Read your name and sign-in address, read how you are signed in, see the devices you are signed in on and end any of them.
Study Settings
- Open Settings in the study menu. The page is about one version: the one in Build, if there is one (editable); otherwise the Live one (read-only); a study with neither shows nothing to edit. The page says which.
- Change the fields in General Information and in Regulatory, Design & Oversight.
- Choose Save study metadata. The values are saved to the version in Build, as a revision of it. Discard drops what is not saved.
- The third block, Study Design, is not a setting: it counts the visits, forms, visit bindings and rules the version has and links to each.
To change a setting of a Live study, start an amendment: the new version in Build is the one this page edits. At go-live the settings of the version are carried to the study.
Every option
Your settings
| Tab / block | What it shows | Can you change it? |
|---|---|---|
| Account · Full name, Email | Your name and sign-in address, as the system holds them | No. Your organization's administrator keeps them |
| Security and policy · Sign-in method | One-time code sent to your address. There is no password | Set by the deployment |
| · Code | The code's length, how long it is valid, the attempts for each code, the wait before a new one, and how many codes one address may ask for in a window | Set by the deployment |
| · Inactivity sign-out | Minutes without activity after which you are signed out, and the warning given before | Set by the deployment (SESSION_IDLE_TIMEOUT_MIN, default 15) |
| · Longest session | Minutes after which a session ends whatever you were doing | Set by the deployment (SESSION_ABSOLUTE_TIMEOUT_MIN, default 720) |
| · Electronic signatures | Every signature needs a fresh code that is valid for that record and that meaning only, and your typed name | Fixed |
| Your devices · Signed in now | How many devices, and when you last acted on this one | Link to Where you are signed in |
| Where you are signed in | Each live sign-in with its device kind, where and when; this device is first | You can end another sign-in, or all the others, at once |
Every value is read from the server, so the page says only what the server enforces. Single sign-on, a code at every sign-in as a switch, notification channels, branding and display preferences are not settings of this release and are not shown. The values are the operator's, in Configuration.
Study Settings: General Information
| Field | Required | What it holds |
|---|---|---|
| Study code | (fixed) | The study's identifier. Immutable; shown, never edited |
Title (title) | Yes | The study's title. Cannot be blank |
Phase (phase) | Yes | Free text, up to 32 characters. Cannot be blank |
Protocol number (protocolNumber) | Yes | The sponsor's identifier, distinct from the study code. Cannot be blank |
Sponsor (sponsorName), CRO (croName) | Names of the organizations (up to 255 characters) | |
Study type (studyType) | Descriptive: for example interventional, observational | |
Therapeutic area (therapeuticArea) | ||
Study description (description), Protocol summary (protocolSummary) | Up to 4,000 characters each | |
Protocol version (protocolVersion) | The protocol's own version label. A controlled change of the design is made in Study versions, not here | |
Target enrollment (targetEnrollment) | A positive whole number | |
Study dates (startsAt, estimatedEndsAt) | Start and estimated end | |
Randomized study (randomized) | A flag the study carries (see below) |
Study Settings: Regulatory, Design & Oversight
| Field | What it holds |
|---|---|
Indication (indication) | The disease or condition, distinct from the therapeutic area |
IRB / Ethics Committee reference (ethicsRef) and Ethics approval date (ethicsApprovedOn) | The central or lead committee's reference and date. Recorded, not a gate: nothing checks them, and the per-site approval is recorded at site activation |
Blinding (blindingType) | Open-label, single-blind, double-blind or triple-blind (stored as open_label, single_blind, double_blind and triple_blind). Recorded only: no code reads it to hide anything (Not built yet) |
Randomization method (randomizationMethod) | Free text, up to 1,000 characters |
Primary endpoint (primaryEndpoint), Secondary endpoints (secondaryEndpoints) | Text; one secondary endpoint per line (up to 50) |
Data Monitoring Committee (DMC/DSMB) (hasDmc) | A flag: an independent committee oversees the study |
| Reporting a serious adverse event | Initial report due within N hours of becoming aware (saeInitialReportHours) (1 to 720, default 24) and Follow-up report due within N hours of new information (saeFollowUpReportHours) (1 to 2,160, default 360, which is 15 days). The window is the version's and is fixed when a report is recorded: changing it later moves none already recorded |
Signatures (signatures.visit, signatures.casebook) | For a visit and for a casebook: Off (default), Optional or Required. Required blocks nothing: it lists the visits and casebooks that are unsigned in the readiness check of the database lock |
| Sponsor contact, CRO contact | Name, e-mail (checked as an address) and phone (sponsorContactName, sponsorContactEmail, sponsorContactPhone, croContactName, croContactEmail, croContactPhone) |
The randomized flag, the blinding type and the randomization method describe the study; they do not switch behavior on. The platform issues a randomization number whatever they say, and nothing reads the blinding type.
Study Design (progress, not a setting)
Four areas, each with a count and a state: Visits, Forms, Visit mapping, Rules and edit checks. A state is Ready, In progress, Not started, Optional or Access restricted (you do not hold the permission to see it), with a bar of how many visible required areas are ready.
When a setting can be saved
| The version is | Study Settings |
|---|---|
| In Build | Editable by a holder of study.write |
| Submitted to UAT, awaiting sign-off, approved, or Live | Read-only: the design is frozen from the submission to UAT on |
| None in Build and none Live (a new study) | The page has no version to edit; start the build |
The server refuses a change to anything but a version in Build, and refuses a blank title, protocol number or phase, a target that is not a positive whole number, an SAE window outside its range and a signature requirement that is not off, optional or required.
Organization settings
There is no organization settings screen in the application. What an organization is (its name, type, country and status) is managed from the platform console (Manage an organization); the application has a route for an administrator to update it (PATCH /platform/organizations/{orgId}, org.manage) and no screen that calls it. The features an organization has are the feature switches. What an Organization Admin sets for the organization is done on its own screens: the roles it uses and custom roles (Roles), the team (Invite and manage members) and the form library. The organization's setup wizard keeps where the organization is in its first steps, and nothing else.
What the system records
- A change of a version's settings is an audit entry,
study.version.settings_updated, in the study's trail, with who and when, the names of the settings changed and, for each, its earlier and new value (a long value is cut at 200 characters in the entry; the whole is in the revision). The same transaction records a design revision of the version, so the settings at any save can be read back. If another person saved the version since you opened the page, your save is refused as stale rather than overwriting theirs. A change of a study's details through the API (PATCH /studies/{studyId}) isstudy.metadata_updated, with each field's old and new value and, once the study has left Setup, a reason; it is refused when the study is locked or archived. - Ending a sign-in is
auth.session.revoked. - The values on Security and policy are not recorded anywhere as settings: they come from the deployment's configuration, which is under the operator's change control.
What you cannot do, and why
- Edit the settings of a version that is not in Build. The design is frozen from the submission to UAT, so what was tested is what goes Live.
- Edit the study code. It is the study's identity.
- Change your own name or e-mail. Your administrator does; the sign-in is tied to the address.
- Choose how you sign in, or switch off the code for a signature. The policy is the deployment's and is the same for everyone.
- Switch on a behavior by setting the blinding type or the randomized flag. They are recorded descriptions.
- Make "Required" signatures block the lock. They are reported as not ready; the lock itself is decided by the people who confirm it (Close and lock a study).
Compliance Q&A
No. The settings are part of the version. They are editable only while it is in Build, frozen from the submission to UAT, tested, signed off by three people and carried to the study at go-live; a change to a Live study is a new version that goes through the same gates. Each save is in the audit trail.
Evidence: server/src/modules/study/versions/domain/version.ts (applySettingsChangessettings belong to a version in Build)audit event study.version.settings_updated
Yes. A session ends after inactivity (the user is warned first) and after an absolute time, whatever the activity. Limits: the values are the deployment's and are the same for everyone; your organization sets them with its operator and should record the chosen values in its procedure. A user can end other sign-ins of their own account from Where you are signed in.
Evidence: server/src/config/env.ts (SESSION_IDLE_TIMEOUT_MIN, SESSION_ABSOLUTE_TIMEOUT_MIN)client lib/cdms/auth/policy-words.ts (the Settings page reads the values from /auth/me)
No passwords exist, so no password rules apply. Sign-in is a one-time code sent to the person's address, with limits on attempts and requests. There is no single sign-on, no authenticator application and no hardware key. A signature asks for a fresh code and the typed name. If your policy requires a second factor, a federated sign-in or a managed identity provider, it is not available in this release.
Evidence: client lib/cdms/auth/policy-words.ts (There is no password)server auth module (one-time code by e-mail)
Related
Build a study · Amend a live study · Sign records · Who can and cannot · Configuration · Statuses