The trial module is designed for managing of independent, controlled clinical trials, conducted at a trial site in parallel. The lifecycle of each trial is mapped by a walkthrough of predefined states.
A state transition can cause an action to be performed such as creating a digital signature value of the trial’s entire object graph. Lockdown states will render the \myac{ui} in readonly mode.
Trials can be categorized by the type of investigation/investigational product and the sponsoring type.
Each trial can be tagged with details such as registration codes assigned during the formal trial registration processes. The trial team comprises involved persons and organisations.
For the team member list to meet the \enquote{delegation of authority log}, roles are assigned and access to the trial is controlled per member in the style of an \myac{acl}.
The project management aspect is considered by predefined and individual events and phases with an optional reminder notification each. Email notification of trial state changes and event reminders
can be enabled per team member. Events, phases and visit appointments of concurrent trials can be
surveyed in an interactive timeline view.
After a number of visits (as specified by the trial protocol)
and a number of proband groups (as considered by the trial coordinators\footnote{Groups of subjects serve an organisational purpose and are not to be mistaken with
verum and control groups, whose allocation is kept secret by the sponsor in the case of double-blinded trials.}) are set up, a visit schedule can be created. The visit schedule
consists of visit appointments, defining a time period for each combination of visit and group.
Aside the timeline view, visit appointments are displayed in the duty roster calendar view in order to align created duties.
Every single duty associated with the trial can be marked to allow self-allocation of employee users.
The trial’s self-allocable duties can be fixated up to a given date. This date will be increased by the dispatching user in stages, whenever a new batch of duties is going to be prepared for the trial.
Inventory allocated to the trial is listed in another inventory bookings view.
The enrollment of subject is effectively managed by the \enquote{proband list}. Candidate subjects are selected by querying the proband database and can be added in \emph{reproducible random order} subsequently.
If a blocking period is specified for the trial, the system will reject probands, who participated in other trials managed by the system during this time period before.
The query for candidates typically reflects
a coarse definition of the trial’s eligibility criteria given by the trial protocol. Since criteria attributes will vary from trial to trial, an individual inquiry input form can be
composed per trial. A preview allows testing the input form in advance. When registering a new proband entry during recruitment, data is captured by entering answers to questions and values of parameters presented in the inquiry form (first \myac{edc} use case).
After adding a matching subject to the trial’s proband list, it will walk through enrollment states, starting with the \enquote{candidate} state. The enrollment progress is visualized
by an enrollment chart, showing the distribution of the subjects’ status over time. Each subject is assigned to a proband group, so relevant appointments of the visit schedule can be listed
and checked for collision with a proband’s availability. User-defined checklists are supported by means of individual columns, which can be added to the trial’s proband list (second \myac{edc} use case).
Hyperlinks can be stored to bookmark \myacp{sop} or other trial-related material maintained in the corporate \myac{cms}. Selected (or all) documents of the \enquote{trial master file}
can be made available online to Phoenix \myac{ctms} users by uploading or a file system import.