Summary

Subject statuses refer to the different states that a subject can be in throughout a clinical trial such as “Screened,” “Enrolled” and “Completed.” With this feature, a subject’s status can be tracked as the subject moves through the clinical trial. The Software Implementation Specialist (SIS) can also configure the status flow to meet the requirements of the trial. 

Table of Contents

• Default Configuration
• Trial Design
  • App Properties
    • Set Subject Status Priority Order
    • Set Subject Status System Order
    • Set Subject Status Expressions
    • Change Subject Status Names
  • Roles
    • Add Activation Action
    • Add Subject Status History Actions
  • Dynamically Generated Casebooks
    • Roles
    • Forms-Template
    • System
    • Forms-Template
    • App Properties
• Definitions
  • Trial Design Status Names
  • Translation Keys
    • Default Translation Keys
    • Additional Translation Keys

Design | System

Default Configuration

Nine default subject statuses are available for all new trials and any existing trials that activate the subject status feature. The following is a list of the nine default subjects statuses listed in order from lowest to highest priority based on the finality of the status. If a subject meets the requirements for two or more statuses at once, the subject will be assigned the status with the highest priority. For example, based on the subject status expressions, a subject may meet the requirements for both the “Screened” and the “Screen Failure” statuses. Since “Screen Failure” has a higher priority, the subject will have the status, “Screen Failure.”

• Pre-Screened
• Screened
• Run In
• Enrolled
• Treated
• Completed
• Early Termination
• Run In Failure
• Screen Failure

By default, these statuses have no expressions or predefined way to change from one status to another. The Trial Design section will guide you through the process of configuring the subject statuses and setting status expressions.

Trial Design

Subject statuses can be customized to meet the needs of a trial by configuring the Data Architect (DA) file. The worksheets required to configure subject statuses and the fields that must be completed on each worksheet are explained in this section.

App Properties

Set Subject Status Priority Order

If a subject status order other than the default order are used when setting the subject status, or if fewer statuses are included in the list, you can reconfigure the list as described below. Otherwise, you can skip this section.

1. Name: Enter ‘recordStatusList’
2. Value: Enter a comma-separated list of the statuses’ trial design names in order from lowest to highest priority.

Set Subject Status System Order

If you want to specify the order that the subject statuses are displayed on the study homepage, you can configure the list as explained below. Otherwise, you can skip this section.

1. Name: Enter ‘recordStatusUIOrder’
2. Value: Enter a comma-separated list of the statuses’ trial design names in the order that they should appear on the study homepage.
3. To add lines to the display to visually group the statuses, add a forward-slash (/) between the groups of statuses.

In the following example, the left configuration uses no forward-slashes and creates no lines to group the statuses while the right configuration does.

Note: The initial status of a subject is not set until the first form in the casebook is saved. If a user enrolls a patient but does not save any forms, the 'Total' value will be higher than the combined total of the 'Current' status count.

Set Subject Status Expressions

For all but the first subject status in the recordStatusList an expression must be set in order for the subject to be assigned the status.

1. Name: Enter ‘recordStatusExpression-’ followed by the trial design name of the status.
2. Value: Using the Fountayn expression language, enter a boolean expression that can be evaluated for a subject.

Example: The following expression checks the value of a specific question on the Enrollment form. A subject would be assigned the status of ‘ScreenFail’ if this expression evaluated to true: #preproc.enroll.enrollyn == 2

Note: Fields dependent on script calculations should not be used as part of the expression. Using such fields can result in erroneous subject status settings because scripts are not run until after the check for subject status changes.

3. Repeat these steps for every subject status except for the first status. No expression is evaluated for the first status since all subjects begin with this status.

Note: Expressions for forms that do not exist at the time of casebook creation (dynamic forms) should be included as part of the expression as a check to see if the form has been created. For example, if the form, ‘Complete,’ is created dynamically with a script, the following expression would check if the form existed: #complete.termdt != ‘#complete.termdt’ as shown for the EarlyTerm status in the following example.

Change Subject Status Names

If you want to change the names of the statuses to something other than the default, two different properties can be used to change the names for a subject’s current status and past statuses. Otherwise, you can skip this section.

Note: Using different names for the statuses does not change the internal meaning and usage elsewhere in the system where these statuses are reported. Where context is provided in standard reports, the name of the status should match the meaning associated with the status.

1. Name: Enter ‘recordStatusLabel-’ followed by the trial design name of the status.
2. Value: Enter the new name for the status.

Note: If configuring the trial to be translated into multiple languages, enter the defined translation key instead.

3. Name: Enter ‘recordStatusLabelNow-’ followed by the trial design name of the status.
4. Enter the new name for the status.

Note: If configuring the trial to be translated into multiple languages, enter the defined translation key instead.

5. Repeat these steps for every subject status that needs a different name. 

Roles

To add the subject status feature to an existing study, one action related to activation must be included on the Roles worksheet. Additionally, actions related to viewing and deleting the subject status history can be included.

Add Activation Action

1. Actions: Enter ‘Record Status Activation’
2. Actions Required: Enter ‘activateRecordStatus’
3. Screens Required: Leave this field blank.
4. Select the Roles that should be able to activate the feature by placing an ‘X’ in the appropriate columns.

Add Subject Status History Actions

1. Actions: Enter ‘Record Status’
2. Actions Required: Enter ‘viewRecordStatusHistory, deleteRecordStatusHistory’

Note: These actions can be separated into two separated permission rows if the roles do not have the ability to perform both actions.

3. Screens Required: Enter ‘viewRecordStatusHistory’
4. Select the Roles that able to perform these actions by placing an ‘X’ in the appropriate columns.

Dynamically Generated Casebooks

If the subject casebooks in the trial are dynamically generated through scripts, extra steps must be taken to configure subject status dependencies. If the casebooks in the trial are not dynamically generated, you can skip this section.

Roles

To configure subject status dependencies, the Software Implementation Specialist (SIS) must first configure the trial to display the status dependencies.

1. Actions: Enter ‘Record Status Dependencies’
2. Actions Required: Enter ‘showRecordStatusDependencies’
3. Screens Required: Leave this field blank.
4. Select the Roles that should perform this action by placing an ‘X’ in the appropriate columns.

Forms-Template

In order for the system to correctly display all subject status dependencies, every form’s ‘autoCreate’ attribute must be set to ‘true’ or left blank.

1. Take note of all forms with ‘autoCreate’ set to ‘false.’ 

Note: To assure no configuration errors occur at a later date, it is recommended that you copy the Forms-Template worksheet as a backup.

2. Set all ‘autoCreate’ attributes to ‘true.’ 

Note: After generating the dependencies in the following steps, this attribute will need to be set back to what it was before the change for each form. It is recommended that you keep the dA file open so that you can undo the changes after publishing it.

System

After the trial has been configured to show subject status dependencies and all form ‘autoCreate’ attributes have been set to ‘true’, the Software Implementation Specialist (SIS) can obtain a list of the dependencies generated by the system.

1. Publish the DA file to Design.
2. Add a new site to the study or remove all subjects from an existing site.
3. Enroll a new subject.
   Notice that all forms are created for the subject.
4. Navigate to the Subject Manager.
5. Select the checkbox next to the newly created subject.
6. In the Actions dropdown menu select ‘Show Subject Status Dependencies.’
   
7. Click the ‘Go’ button.

The system will display a table with all of the dependencies generated for the specified subject.

Note: The number of dependencies provided will vary based on the number and location (s) of the variables included in the expressions. 

Forms-Template

Once the status dependencies have been generated, the form’s ‘autoCreate’ attribute can be changed back to what it was before the change.

1. Set ‘autoCreate’ back to ‘false’ for all forms that are generated dynamically.

App Properties

1. Using the list of dependencies generated by the system, copy each dependency into the DA file.
2. 
3. Publish the DA file to Design. 

Definitions

Trial Design Status Names

Subject status names are displayed in two different ways within the system. The subject’s current status is displayed as the current name while all past subject statuses are displayed as the historical name.

Translation Keys

Default Translation Keys

The following translation keys are used automatically unless a Software Implementation Specialist (SIS) specifies a different name for the subject status.

Additional Translation Keys

Other keys can also be used in place of the default subject status names. However, using different names for the statuses does not change the meaning and usage elsewhere in the system. In such cases, the subject status expressions should be changed as well.

Need more help?

Please visit the Fountayn Contact Information page.