Randomization
- TK Support
- TK Support
TrialKit is capable of randomizing study subjects to allocated groups for the purpose of assigning investigatory products accordingly without human intervention or bias.
Study builders can do the following:
- 1 Define Randomization
- 2 Setting up/Importing Randomization Schema files
- 3 Importing a Randomization File
- 4 Updating Randomization Schemas Mid-study
- 5 Randomization Conditions
- 6 Define User Permissions for Randomization
- 7 View and decode the randomization allocations
- 8 Un-allocating subjects:
- 9 Removing allocations entirely
Define Randomization
This article describes how to define randomization prior to uploading the randomization list/schedule. First, open the page "Define Randomization" from the Study menu:
In the table below, randomization has been configured and the form is available to create an additional one.
Enter a name for the randomization - this will be a reference shown throughout the system and exported data
Blinding - Leaving this box unchecked will blind all user roles by default so they do not see the allocation to which the subject was randomized. Individual roles can be unblinded by unchecking the box next to that role (Checked role = Blinded role).
If a new role is created in the study, later on, the role will be assumed as blinded and automatically added to the list of blinded roles.
The blinded user roles cannot be edited after randomization is configured, so be sure to verify the correct roles are being blinded prior to deploying on a live study.
Any user role with access to view the randomization allocation report (separate permission) will be unblinded regardless of the randomization configuration blinding that user role.
Randomization Blinding is supported by the system in the following areas:
Form save dialog indicating if randomization was successful
Subject information panel within the subject’s file
Ad-hoc reports in the report builder
For any fields in the forms which have been configured to populate randomization information or display based on a randomization group - these are the users' responsibility to blind accordingly. Blinded fields are supported within forms, ad-hoc reports, and the queries report.
Return Subject ID - The system can optionally return a new Subject Profile ID with a new allocation. When a subject is successfully randomized, the system will pull the Subject Profile ID from the randomization schedule and overwrite the system-generated Subject Profile ID. If you want to save both the system-generated ID and the randomization ID from the schedule, see the next item below.
Return Randomization ID - This will provide an option for text fields in the Form Builder to define for populating the subject's Randomization ID into a CRF. This allows for maintaining the system-generated ID as the subject ID and still having reference to the randomization ID in the subject data.
Centralized - Some studies may require that the pool of randomization allocations not be site-based. Most randomization will evenly distribute arms among sites. However, in some cases, you may want to remove that layer of site stratification. This will mean that when randomizing, the system will pull the allocation based on any other level of stratification (or no stratification at all).
Stratify By Site ID - If the randomization is not centralized, that means it is stratified by site. By default, this site stratification will block subjects based on the sequence in which the sites randomize their first subject. In order to dictate specific site IDs for the randomization blocks, check this option.
Trigger Form - Select which form the randomization will occur on.
Trigger Visit - Select which visit the randomization should occur on.
Field To Randomize On - Select which field(s) the randomization is based on. These need to be the same stratification fields included in the uploaded file described below.
Deploy Randomization Confirmation Emails
Define which roles should receive randomization details and confirmation emails as subjects are randomized in the study.
Confirmation Emails are Un-blinding, so be sure the blinded roles (if applicable) are not selected here.
Setting up/Importing Randomization Schema files
TrialKit users are responsible for creating their own randomization schedules. This is usually done by a biostatistician supporting the study. Randomization files dictate how TrialKit will distribute randomization allocations over sites or the entire study, depending on how the randomization is defined.
This section will explain the exact file format necessary to import a randomization file. The file needs to be in a comma-separated (.csv) file format.
The following figure displays the file layout of the file to be imported into TrialKit.
Column | Type | Description |
site_no | Integer
| The site number. This will repeat for every allocation slot for a given site. NOTE: When using central randomization, this column should be omitted from the Randomization Table. The Site ID used in this column can either be sequential or correspond to specific site IDs within the system, depending on the randomization behavior desired. |
sub_no | Integer | The subject number within the current site. This will be marked sequentially starting at 1 and ending at the last subject number. It will restart for each new site in the table. |
stratification 1 | Integer | For each level of stratification, enter the coded stratification. For example, if 1= Male and 2= Female, then a series of 1’s and 2’s would fill this column for each subject for each site. The codes do not have to be in order but is preferred to have the codes in order. For example, if the user is allocating 50 randomization slots per site, 25 males and 25 females, then the first 25 rows should be male while the next 25 rows should be female. Each stratification level will get an additional column. If you are stratifying by gender and BMI group, then you would have two columns. Obviously, the more stratification levels you have, the more complex the randomization file. |
stratification 2,3,4,... | Integer | See above, additional stratification fields will have their own columns, these extra columns will not be here if the user defines the randomization to have 1 layer of stratification. |
allocation | Integer | This is the coded allocation that is returned to the randomize subject. When a randomized form is saved, the system will look for the first slot available and claim that randomization allocation and assign it to the subject. For example, if a user has randomization that is stratified by Gender and BMI; the system will look for the first gender and BMI group slot available within the subject’s site. |
Subject profile ID (Optional) | String | If the user chooses to have the system return the subject profile id upon successful randomization, add a column here. This column should be omitted if the user is not returning the Subject Profile ID. |
Randomization ID (Optional) | String | If there is a separate randomization ID that needs to be collected and populated within the subject data (as described in the defined randomization), it can be identified here in the last column. The system then uses this ID to populate within a subject form as defined in the Form Builder. |
Importing a Randomization File
To upload a randomization file, select the "Import Randomization File..." option from the Study Menu.
Select which randomization schema to import a file for.
After importing the file, a message will indicate if there were any errors in the file when applied to the defined schema.
Simple Example
The table below has 10 subjects and is 2-arm randomization. It is central randomization that returns no subject profile id and does no stratification (Simply saving the randomization trigger form will allocate the subject)
Patient | Randomization |
1 | 0 |
2 | 1 |
3 | 1 |
4 | 0 |
5 | 0 |
6 | 1 |
7 | 0 |
8 | 1 |
9 | 1 |
10 | 0 |
More Complex Example
Randomizing based on site ID blocks with dual stratification, using the coded values for the stratification variables (found in the form builder)
Site | Patient | Strat1 | Strat2 | Randomization |
1 | 1 | 1 | 1 | 0 |
1 | 2 | 1 | 2 | 1 |
1 | 3 | 1 | 1 | 1 |
1 | 4 | 1 | 2 | 0 |
1 | 5 | 1 | 1 | 0 |
2 | 1 | 1 | 2 | 1 |
2 | 2 | 1 | 1 | 0 |
2 | 3 | 1 | 2 | 1 |
2 | 4 | 1 | 1 | 1 |
2 | 5 | 1 | 2 | 0 |
Updating Randomization Schemas Mid-study
The randomization file can easily be updated if needed. Do this by exporting the existing schedule, modifying as needed, and re-uploading. The system will only update ‘slots’ that have not already been filled, so its okay if filled slots are part of the file when its re-imported. This helps the user in verifying proper spread of allocations, even if some have already been used.
Randomization Conditions
For studies that use randomization, TrialKit allows study builders to dictate form logic according to where subjects are randomized. For example, each subject's randomization assignment can dictate if specific intervals, forms, or fields are displayed.
After defining randomization, the conditional action builder will display that randomization name as a constant. In the example shown here, a condition is being built on a field to hide the field if the subject is randomized into group 1. For group definitions, reference the randomization allocations.
Define User Permissions for Randomization
There are two application permissions needed for the role that will be setting up randomization.
Randomization Configuration
Under the Study>Study Configuration menu click on the Role Security tab
Now select the role you want to grant access to randomization to
Check the setting called "Grant Access to Randomization"
Save Right (see below)
Randomization View
Under the Study>Study Configuration menu click on the Role Security tab
Now select the role you want to grant access to randomization to
Check the settings for
Grant Access to Randomization View
Un-allocate Subject
Save Right (see below)
View and decode the randomization allocations
After randomization has been set up on a study, the allocation table can be viewed. With the appropriate permissions in Role Security, this page is found under the Subject menu:
The following example shows the View Randomization Allocations interface that allows the user to decode the randomization file and display all planned and assigned randomization allocations. If there is more than one randomization schedule being used in a study, the selector at the top of the page allows for switching between those schedules.
The Randomization Allocation data table on the View Randomization Allocations page, shown above, displays all planned and actual randomization allocations. The user can see the randomization file that was uploaded by viewing the first four columns of the Randomization Allocation data table (Please Note: This particular randomization scheme is returning a Subject Profile ID). The last three columns in the Randomization Allocation data table contain the actual allocations including the site, subject, and date of allocation.
When a user saves a form that was defined for particular randomization, the system will find the next available slot based on the site and stratification(s). The system then claims that slot by assigning the user’s site, subject, and date of allocation to that slot. The system also associates this randomization allocation to the subject's visit. This information can be used to enforce randomization arms using Conditional Actions.
The View Randomization Allocations page gives the user the ability to decode the randomization allocations. For each allocation that was imported for given randomization, the user can enter text to be displayed whenever this allocation is shown in TrialKit. To decode randomization, the user simply enters the text for each allocation and presses the "Save" button below the last allocation text box. The decoded text will show in the Allocation column in the main data table.
The View Randomization Allocations page allows the user to view only randomizations that have been allocated. If a user has a large randomization table, the user can click the View Only Randomized Subjects link above the Randomization Allocation data table to view just those subjects that have been allocated. The user can then toggle back to view all randomizations by clicking the View All Subjects link.
At any time, by selecting the Export link located above the Randomization Allocations data table, the user can export the entire randomization table to Excel. This gives the user a permanent archive of exactly how the randomizations were allocated for the duration of the study. It is also a method for updating the file, where additional randomization slots can be added to an existing schedule. Note, if editing or adding to a schedule, only empty slots can be modified.
Below are all the same functions accessed via the mobile app:
Un-allocating subjects:
The un-allocation of subjects allows a user with the proper permissions to open the randomization table (shown above) and individually clear existing subjects from the randomization slots they exist in. For Example, a study may have a withdrawal that requires that allocation be re-used by another subject, or accidental randomization was made.
The study permission to unallocate subjects is needed to perform this action.
On the web, it can be done via the Unallocate links in the randomization table.
On the app, it can also be done in the randomization table by swiping left on any row (mobile app only) within the table. An “Unallocate” button will appear on the right side. Tap on the button to complete the action.
Removing allocations entirely
It’s usually advised to maintain the randomization schedule as it was designed and keep all slots, even if they aren’t needed anymore (e.g. A subject was randomized accidentally and the slot cannot be re-used). This can be done by filling the slot with a ‘placeholder’ subject, updating the subject’s ID to something that will not ever exist for a real subject, like “01-005ZZ” where “ZZ” is appended to the end of the ID. Then delete that subject. It will still fill the randomization slot and prevent a real subject from re-using it.
The alternative method is to un-allocate the subject from the slot that needs to be removed and then updating the randomization schedule by re-importing it (explained in sections above).
Read here about how subject randomization is performed by the site
Related articles