The position
This is the most important page of this section, and the shortest to summarize: Trialion does not supply a validation package, and a regulated trial cannot rely on it until one exists. The software, the tooling that supports validation and the evidence of engineering quality are real and listed below. The validation itself is a documented, executed and signed exercise by qualified people, against your protocol and your configuration. Nobody can hand you a pre-validated system, because performance qualification is specific to your study by definition.
What GAMP 5 expects
GAMP 5 classifies a system by how much it is configured or customized and asks for validation in proportion. An EDC system is Category 4 (configured) at the least. A typical package contains:
| Deliverable | Purpose | Supplied? |
|---|---|---|
| Validation plan | What is validated, how, and by whom | No |
| User requirements specification | What the system must do | No |
| Functional and design specifications | How it does it | Partly: ADRs 0001 to 0020 and module notes, not written to a validation standard (Architecture decisions) |
| Risk assessment | Which functions matter to patient safety and data integrity | No |
| Requirements traceability matrix | Every requirement traced to a test | No (there is no requirements specification to trace to) |
| IQ installation qualification | Installed as specified | Tooling: an automated script whose output is evidence for an IQ you execute |
| OQ operational qualification | Works as specified across its range | No |
| PQ performance qualification | Works for your protocol, configuration and users | No, and yours by definition |
| Executed, signed test evidence | With defects and resolutions | No |
| Validation summary report | The conclusion | No |
| Change control and periodic review procedures | Keeping it valid | No |
What exists, and what it is worth
- Automated engineering tests and release gates: 430 unit and 137 integration test files on the server against a real database, 327 on the client, and a gate on the control plane, with tests that hold the audit-trail, least-privilege, tenant-isolation and no-delete rules in place (Testing and quality).
- Installation qualification script (
npm run validate:iq): checks the platform versions, that every migration is applied, database-level append-only enforcement on the audit ledger, row-level security on clinical tables and the application role's inability to bypass it, the ledger's size and recorded breaks, whether a backup is restorable and whether alerting has a recipient. It exits non-zero on a failure and can print JSON. It is unsigned, covers installation only, and has no approved specification behind it. Use it as an appendix to an executed protocol, not as the protocol. - Backup and restore evidence (
backup_runs, the weekly restore verification) and audit-chain evidence (the worker's verification and recorded breaks). - A hand-run test sheet: a shared workbook of cases written from the way trials are run, with runs, evidence and defects (Testing and quality). It is evidence of what was done by hand on one build, not a validation record.
- Load-test reports at four study sizes (Testing and quality).
None of these is validation evidence. They are not written to a pre-approved protocol, not executed by a named person under signature, and not traced to requirements.
What the software gives a validation effort
- Deterministic state machines for every lifecycle, enforced on the server (Statuses).
- A tamper-evident audit trail that can evidence test execution (Audit trail and evidence).
- UAT and Live kept apart by the database, so an OQ or PQ can run against realistic data without touching live data (Test a version in UAT).
- A sealed, versioned study configuration. A study's forms, visits, mappings, rules and settings are one unit with a content fingerprint, released after three independent sign-offs bound to the exact design approved; a change after sign-off withdraws the approvals instead of riding along. So "what configuration was in force on this date, and who approved it?" has a definite answer, which is often the hardest question in a validated EDC (Review and release a study).
- Controlled change to the platform itself: the schema changes only by a numbered migration that is tested from zero, the committed schema baseline is checked against the migrations, and a revision is deployed only after its gate passes (Running it).
A workable route
- Write the URS from what your protocol needs, using the task guides and the reference as the functional description.
- Risk-assess against patient safety and data integrity. The controls in 21 CFR Part 11 and ALCOA+ map onto most of what you will identify.
- Qualify the installation (it depends on where and how it is deployed), with the IQ script as an appendix.
- Execute OQ against a UAT workspace; the audit trail is your evidence of what was done.
- Execute PQ against your actual study configuration in UAT before releasing it to Live. The UAT cycle and the three sign-offs are designed for exactly this.
- Put change control around amendments and platform releases. The sign-offs and the sealed version give you the mechanism; your SOP gives the procedure.
- Schedule periodic review. No built-in feature supports it: your evidence will come from the audit trail, the configuration version history, the signatures register and your own record of the platform releases you accepted.
Compliance Q&A
Not by the vendor, and not supplied. Engineering tests, an installation-qualification script, backup and chain evidence and a hand-run test sheet exist, and the system provides the controlled configuration, the audit trail and the separate UAT workspace that a validation needs. The plan, requirements, risk assessment, OQ and PQ with executed evidence, traceability and summary report are the customer's to write and execute.
Evidence: server/docs/validation/README.md (no validation package exists)scripts/validation/installation-qualification.mjs (IQ tooling only)
Yes. A study's design is a versioned unit with a content fingerprint, released after three independent sign-offs, and never edited in place; the version in force on any date, its sign-offs and its signatures can be read back (View the live design).
Limits: this controls each study's design. It is not the customer's change control over the platform: deciding when to accept a new release of Trialion, and re-qualifying after it, is the customer's procedure.
Evidence: server/src/modules/study/versions (sealed config snapshots with content hash, three sign-offs, immutable versions)form_version_snapshotsstudy_versions
No feature schedules or records a periodic review. The evidence for one is available (the audit trail, the version history, the signatures register and your own record of the platform releases you accepted), and the review and its schedule belong to the customer's quality system.
Related
21 CFR Part 11 · Testing and quality · Review and release a study · Not built yet