Cohorts in TrialKit are simply defined as different visit schedules, whereby subjects can each exist on separate visit schedule parameters. Here are a couple examples:

  • Some subjects will need a 6-month follow up visit, but others will not. 
  • After some determining event, some subjects will get a couple extra visits which subjects in the study don't have by default.


An important point to understand is that Cohorts are independent of study versioning. All cohorts that are setup in a study will exist across ALL study versions. In other words, as an example, even if some subjects exist on version 1 and others exist on version 2, all subjects on both versions can be moved between all cohorts. In summary:

  • Visit schedule design can be changed via cohorts
  • Form design can be changed via study versions


All studies have at least one visit cohort. If only one visit schedule exists in the study protocol, it may still be necessary in some scenarios to utilize cohorts. One common example is when visits need to be hidden. Rather than utilize several conditional actions to hide forms and/or visits, different visit schedule designs can be used.

As soon as its determined that more than one cohort is needed, it's simple to setup new ones.

Cohorts are initially setup, naturally, in the same place where visit schedules are defined. First, you'll need to make sure a couple things are enabled:

1. The functionality in the study settings

2. The role permission to change subjects from one cohort to another (so you can test everything out)


The images below walk through how new cohorts can be created and existing ones can be edited.

Note, whichever cohort is defined as the "Default" cohort will be the one that new study subjects are placed on when they are first registered in the study. In other words, you'll want to make sure the default cohort is the one that subjects should be starting on before they are eventually determined to be moved to another cohort.




To Edit the visit schedule and forms collected within each visit, just tap on a visit or form to make any adjustments. This can be done at anytime throughout the study as changes to the visit schedule are needed. A few important points:


1. Be aware that making changes to an existing cohort where there is live study data - particularly if deleting a visit - can cause data to become inaccessible, but is reversible and data is not lost.


2. The name of a visit in one cohort must match its respective visit in another cohort in order for the system to recognize them as the same visit. Each visit, in actuality, across each cohort, has unique IDs, but rather than treating them as unique, the system relates them by name. For this reason, for example, in a multi-cohort study, you will never see multiple "Baseline" visit options in the list of filters in the Queries Report.


3. If adding a new form to a visit(s), be sure that form exists on a version of the study where subjects in that cohort will be added. As an example, if a new form is created in version 2 and added to all the cohorts, but a site still only exists on version 1 where that form does not exist, the subjects at that site will get errors when opened.



When adding or changing the default cohort, a window will be seen similar to the one below. If a new cohort is being created, an existing cohort must initially be copied. The default cohort will always be labeled as such to avoid confusion when new subjects are added.





Continue reading on how to manage study subjects and change visit cohorts.




Explanation for studies running prior to web v5.0 (February 29, 2020):

For studies which were migrated to make this function available, a concept to understand is that scheduled visits, like CRFs, used to be under version control. Upon migrating to v5.0, those versioned visits became cohorts. In other words, if a study has a version 1.0, 2.0 and 3.0, it still has that version control on the CRFs, but the visit schedule now has 3 different cohorts instead of versions. If the subjects are all on the latest version 3.0, they will also be on cohort 3.0, and this will be transparent to the users. In this common scenario, it will be important to avoid giving out the user role permission, switch cohorts. 

As long as the cohort function is not enabled on the study and users don't have access to switch subjects between cohorts, the subjects will remain, in this example, on version 3.0.

Moving forward in this example, if a new study version 4.0 is created, it will be important to understand that the most recent cohort (3.0) can be changed on-the-fly if any changes are needed to the visit schedule. 

As new subjects get added, whichever cohort is set as the default cohort will be what new subjects are on upon registration. If their are subjects on different study versions, those will be unaffected, but if certain sites are on different study versions (not common), then subjects will need to be manually placed on the appropriate cohort as they are added - assuming the new subjects are not desired to be on the default cohort.