The task and its users
RT Clinica provides data collection, role-based review and export workflows for clinical research. Data-entry users complete forms; reviewers move from summaries to individual records and inspect fields that need checking. Field changes and their reasons are retained in audit records.
An answer also needs to identify its study centre, visit and form version. When research teams hand data over, they need both the current contents and a way back to the original question and subsequent changes. Within each role’s permissions, that context helps data-entry users and reviewers continue working on the same record.
Why we designed it this way
Zero, unanswered, invalid and not applicable have different meanings. Displaying all of them as blanks makes an answer indistinguishable from data not yet collected. The system therefore presents these states separately. An absent visit date stays empty; a creation timestamp is not used as a substitute.
After a form changes, old answers should still use the original questions, groups and labels. Saving only current values, or interpreting old answers with the latest form, loses the basis for review. Retaining form versions and reasons for field changes lets reviewers inspect how records evolved. This changes representation and traceability; the validity of clinical conclusions still requires the relevant study and professional judgement.
What happens in practice
- Organise collection by study. Arrange records by study, centre, visit and form version, preserving the actual state of each field.
- Open a record for review. Read-only roles can move from summaries to specific forms, inspect questions and groups, and locate fields needing checks. Read access does not become edit access.
- Retain the basis for changes and exports. The audit interface associates field changes with their reasons. Historical forms and exports use the questions, groups and labels of the relevant version, within the agreed permission scope.
What can be checked now
The current stage is Live product. Existing software-release acceptance records cover field-level review, visits and form versions, scoped exports and denial of unauthorised access.
The first illustration comes from the public product homepage; its workspace is illustrative. The other two combine actual interface components with synthetic study data from an isolated environment to show role entry points and field auditing. Studies, identities, participant counts, dates and DEMO-A / Example PI records are all synthetic. Screenshots show how to view tasks and question changes; full feature acceptance requires the corresponding software-check records.
Limits and next steps
This page contains no real participant data and provides no study accounts. Data collection and collaboration do not mean AI has performed diagnosis or made treatment decisions. A live release and software tests are not clinical-effectiveness research, medical-device certification or regulatory certification.
New research-collaboration tasks first need an agreed protocol, data dictionary, visits and form versions, centre and role permissions, and review and export rules. A specific AI feature would also need its own intended use, data conditions, professional review and acceptance scope. Clinical judgement and research responsibility remain with the relevant professionals.