What this is, and who it is for
Everything Trialion cannot do, or does only in part, in one place. Other pages point here rather than keep their own partial lists. It is for the person deciding whether a study can run on the system today, and for the person writing a procedure who needs to know what the system will not do for them.
Every entry was checked against the implementation, not assumed. An entry that was true of an earlier version of the product and is no longer true has been removed; where a feature is smaller than its name suggests, the page says how much smaller.
The short version
Trialion has a solid data-capture and oversight core: versioned study design with a test cycle and three sign-offs before release, an eCRF builder, field-level audited data entry with a reason for every change, an executing set of field checks and cross-form rules, queries with separation of duties, targeted source data verification, electronic signatures on records, visits, casebooks and version sign-offs, delegation of authority signed by the investigator, consent and re-consent tracking for amendments, a safety trail for serious events (report, follow-ups, medical review, reconciliation), a two-person database lock, a document register and a tamper-evident audit trail.
What it does not have is the part of a randomized, blinded drug trial that sits around the data: no randomization and no blinding, no drug supply, no medical coding, and no safety gateway or E2B file. It also supplies no validation package.
- You could run today a non-randomized, open-label study, or a randomized one whose allocation and supply are run by another system and whose arm is typed in, with coding done outside.
- You could not yet run a blinded study (the system does not hide the arm from anyone who may read participants), and you could not run a trial whose regulator expects the sponsor's validation package from the vendor.
Where to find it
This page. The status column of the Part 11 matrix, the framework matrix and the Q&A index send you here for the entries marked Not built yet or Partly built.
What you can do
Read it before you sign a contract, before you write a data management plan, and when a sponsor's audit checklist names a function. Each entry below says what exists instead and what to do about the gap.
Every gap
Not built at all
| What | What exists instead | What to do |
|---|---|---|
| Randomization | When a participant is randomized you type the arm that was allocated elsewhere, and Trialion issues the next randomization number (RAND-0000001 in Live, RAND-UAT-0000001 in UAT). The arm is free text chosen from a list in the screen; the server does not check it against the study's arms. There is no randomization list, no block or stratified allocation, no stock-aware allocation | Allocate in your randomization system; enter the result; keep that system's log as the source |
| Blinding (ADR 0020, proposed, nothing built) | The study has a blinding type (open label, single, double, triple) that is stored and shown. No code reads it to hide anything. The arm is returned to every role that may read participants: in the participant list and detail, the casebook, the dashboard's balance by arm and the participants export | Do not run a blinded study on Trialion until ADR 0020 is built. If you must, the arm must not be entered at all (the randomization system holds it) |
| Emergency unblinding | None. There is nothing to unblind | As above |
| Drug supply (kits, lots, shipments, resupply, accountability) | The Pharmacy role and the dispensing forms (a form in the EX or CM domain) exist, so dispensing can be recorded as data. There is no inventory behind it | Keep supply in the supply system; record dispensing on the form |
| Investigational product model | None: no product, dose or arm definition for a form field to refer to | As above |
| Medical coding (MedDRA, WHODrug) | None: no dictionary import, no auto-coding, no coding queue, no re-coding on a new dictionary version. Adverse events and medications are free text, or options a designer typed. The AI service no longer advertises coding suggestions: it was removed so that the claim does not appear in a validation reviewer's reading | Code outside; load the codes back as a form field if you need them in the data |
| E2B and safety gateway | The safety trail ends at what is recorded in Trialion: the initial report's clock and status, follow-up reports, the medical review and a manual reconciliation record. Nothing is generated or submitted; no E2B file, no gateway, no automatic reconciliation with the safety database, no aggregate safety signalling | Submit from your safety system; record the sending and the reconciliation here as the screens allow (Review a serious event) |
| Central laboratory loading, LOINC, age- and sex-specific reference ranges | Normal ranges are set per field by the designer, one range per field | Enter lab values by hand or hold them in the lab system |
| ePRO and eCOA | None | Use a dedicated system |
| EHR, imaging, wearable and CTMS connectors | The API is the only way in; there are no connectors | Integrate through the API |
| CDISC beyond ODM-XML | ODM-XML 1.3.2 export works. There is no SDTM mapping, define.xml, annotated CRF, CDASH template set or managed controlled-terminology library. A form may carry a free-text CDISC domain tag and a field a free-text annotation; that is all | Map downstream |
| SAS and PDF export; signed exports | A request for either is refused with a clear message rather than producing a mislabeled file (Exports reference) | Use CSV, Excel or ODM-XML; print the casebook from its screen |
| A per-site rollout of an amendment | A version goes Live for the whole study. A participant moves to it one at a time, after they have consented again where the amendment asks for it (Record consent and re-consent). There is no "site A on version 2 while site B finishes on version 1", and no gate that requires a site's fresh ethics approval before the amendment reaches it. The ethics reference and date on a version are details that are recorded, not a gate | Keep the site's approval in your site file; the re-consent record is the control that exists |
| Monitoring-visit reports and central monitoring | Targeted source data verification, the verification plan and the SDV screens are built. There are no key risk indicators, no central statistical monitoring, no automated risk signals and no monitoring-visit report | Use your monitoring system |
| Data review listings and a participant profile for medical review | A participant's casebook and a printable status report for a participant exist. There are no listings across participants and no longitudinal profile | Export and review in your tool |
| eTMF | The document register versions and controls the documents the study needs in the system. It has no TMF reference model, no expected-document checklist, no completeness scoring and no read acknowledgement | Keep the TMF in a TMF system |
| Notifications beyond a few | The e-mails and the two in-app notifications on the notifications page. There is no alert for a query response clock, an overdue or out-of-window visit, a serious event's reporting deadline, a record awaiting signature, a stale verification or a version awaiting sign-off, and no notification preferences | Your procedure has to say who looks at which screen, and when |
| A computer-system validation package | Trialion is the software. IQ/OQ/PQ protocols, a requirements traceability matrix and executed validation evidence are not supplied | The customer validates for intended use; see GAMP 5 and validation |
| A record of who read what | The audit trail records changes, sign-ins, signatures, locks and refusals. A successful read (opening a participant, a report, the audit trail, the casebook) is not recorded in it. Document downloads and previews are the exception. The API's structured access log (request id, route, status) exists in the hosting's logs, with the retention the hosting gives it | Control reading through roles and site confinement; if your procedure needs a read log, keep and review the API access log, and say so in your data management plan |
Partly built
| What | What is built | What is not |
|---|---|---|
| Locking | A record locks when it is signed, and the casebook shows the form as Locked. A visit and a casebook can be signed (a version setting: off, optional or required) and the signature seals what it covers until something under it changes, when it is shown as superseded. The whole study freezes at the two-person database lock | There is no soft-lock and hard-lock tier, no batch lock and unlock of many visits or participants, and no lock of a visit that is not a signature |
| A visit that finishes | A visit's window state is worked out from the calendar every time it is read, and gates data entry. A visit can be signed by the investigator when the version asks for it | Nothing marks a visit done, closed or reconciled as a unit, and nothing checks that the forms the protocol requires at the visit were collected. A visit's stored status does not move. See Statuses |
| Rules | Rules run on entry and on save and can block, warn, raise a query or flag | The triggers at enrollment and on schedule and the actions derive and show form exist in the data model and do not run; the editor refuses to save an active rule that uses them (Rules reference). Use a field formula or conditional visibility |
| Server-side form logic | The server checks required, minimum and maximum, normal range, format, dates and the study's rules, each with its severity. It recalculates every formula field and every calculated table cell with the same engine as the browser and stores its own result (a difference is written to the audit trail as form.derived_value_overridden). A field hidden by its visibility condition is not validated, as in the browser | Value assignment and the auto-populate of a checkbox or toggle run in the browser only; the server stores the value it is sent. A person using the API directly can store any value in such a field, subject to the field's own checks |
| Training | Completion of GCP training is a condition of activating a site, and a team assignment has a training complete flag that a person with the training permission sets | The flag blocks nothing. Someone with the flag unset can still work. There is no per-person training record with versions and expiry |
| Safety | The initial report's clock, status and due time; follow-up reports with their own window; the medical monitor's review with causality and expectedness (a related and unexpected event is flagged as a suspected unexpected serious adverse reaction); a manual reconciliation record; the subject's safety follow-up | No E2B, no submission, no automatic reconciliation (above) |
| AI | Two helpers, each behind a screen that works without it: form generation from a description (an eCRF Designer, in the form builders) and the role assistant that suggests permissions for a custom role and explains a warning. Neither touches clinical data or decides anything; everything it proposes is validated and shown to a person first | Nothing else: no coding suggestions, no query suggestions, no summarization. They were removed from the code rather than left as stubs. Form generation needs the organization's ai.crf_builder feature switch and a configured provider (without one the request answers 501); the role assistant says up front that it is not available when no provider is wired |
| Importing | Sites can be registered one at a time or in a batch: the Sites screen's Import reads a CSV file, shows which rows are valid and registers the valid ones. Participants can be imported into a site the same way (the site page's Import): consent date and version are required on every row, and eligibility and an external randomization number can be carried only by someone who may determine eligibility | There is no bulk import of form data (visit results) through the screens |
| File upload field | A form can have a File Upload field (Field types) | The field records the file's name only. The file itself is not uploaded or stored by the form, and the size limit set on the field is shown, not enforced. Keep source documents in the document register or the site's own system |
Built, with limits worth knowing
| What | The limit |
|---|---|
| Audit trail | Every clinical change is recorded in the same transaction and chained; the chain is verified by the platform. It is the application's own trail: a database administrator with access to the database host is outside it, and your hosting controls cover that |
| Electronic signatures | The signer re-authenticates with a code sent to their address, and the meaning is recorded with the name and the time. The sign-in method is a one-time code by e-mail; there is no password, no authenticator application and no hardware key, and no second factor beyond the code |
| Document content check | A file's first bytes are compared with its name and a program is refused. It is not a malware scan |
| Exports | The ODM-XML was not validated against the CDISC schema |
| Backups and recovery | The application raises an alert when no backup has been taken or the last is stale; taking and restoring backups is done on the database host and is the operator's |
What the system records
Nothing on this page is recorded, because nothing here is a feature. What the system does for the parts that are built is recorded in Audit events.
What you cannot do, and why
- Rely on a function listed as not built. It is not in the product; a procedure that depends on it fails the first time it is used.
- Switch on a function by setting. A setting that looks like a control (the blinding type, the randomized flag of a study) records what the study is; it does not turn on a behavior that has not been built.
- Ask for a missing feature through the interface. A request for an export format that is not built is refused with a clear message; a rule with a trigger that does not run cannot be saved. The product refuses rather than produce something that looks right and is not.
Compliance Q&A
No. The arm is typed in from the randomization system and the platform issues the next randomization number. There is no allocation list and no inventory of kits or lots.
Evidence: server/src/modules/study/subjects/domain/subject.ts (randomize takes the arm as given)pg-sequence-issuer.ts (the randomization number only)
No. There is no MedDRA or WHODrug dictionary, no auto-coding and no coding queue. Events and medications are captured as free text or as options a designer entered. Code outside the system.
Evidence: server/src/infrastructure/ai/ai-service.ts (the coding capability was removed)no dictionary tables in db/schema.sql
In part. The clock, the status of the initial report, follow-up reports, the medical monitor's review (with expectedness and a flag for a suspected unexpected serious adverse reaction) and a manual reconciliation record are kept, with who and when.
Limits: nothing is generated or transmitted: no E2B file, no gateway, and no automatic comparison with the safety database. The reporting deadline is shown on the screen; nobody is told when it nears.
Evidence: server/src/modules/study/events, safety-logs (report clock, follow-ups, medical review, reconciliation record)no E2B generator in server/src
Only at one point: a site cannot be activated until its GCP training is confirmed. A team assignment carries a training complete flag, but nothing reads it to refuse work.
Limits: there is no per-person training record with versions and expiry. Training of users is your organization's responsibility and record.
Evidence: server/src/modules/study/sites/domain/site.ts (activation needs GCP training complete)team/domain/role-assignment.ts (trainingComplete flag, read by no gate)
Not supplied. The software is tested by the vendor (see Testing and quality), and a UAT cycle with three sign-offs controls every study's own configuration. A package for the customer's intended use is the customer's to author and execute, from the vendor's documentation.
No. Changes, sign-ins, refusals and signatures are recorded in the tamper-evident trail; a read is not. Who may read is controlled by role and by site, and refused attempts are recorded as access decisions, but a review of who opened which record has to come from the hosting's access logs.
Not applicable in the sense Annex 11 uses: batch release is the certification of a manufactured medicinal product's batch, and a data-capture system does not do it. There is no product batch, certification or release function in Trialion, and no drug supply module (above).
Related
Notifications · Rules reference · Exports reference · Documents reference · Statuses · Compliance