Scheduled Visits and Visit Cohorts Setup/Design
Scheduled Subject Visits setup screen allows Study Designers to create scheduled visit intervals, respective windows, and define which forms are collected at each visit.
For multiple possible visit schedules in a single study, read more about Visit Cohorts below.
Table of contents:
Setting up a visit schedule
The setup page is accessed from the Study Configuration menu, assuming the user has access to the corresponding Role Security Permission > Subject Record Page Design
Website:
Mobile App: Right side slide-out menu
If this is a first study build, there is a pre-set example of a visit schedule already in place. You can begin by editing the current rows and then adding additional visits depending on the number of visits needed. The examples following are done via the mobile app but are also accessible on the web.
Tapping on the header of any visit will allow for editing the parameters of that visit (all defined below). New visit intervals can be added via the "New Interval" button at the top.
Scheduled visit interval parameter Definitions:
Interval Name - Name the Interval that will display in the subject records
Time Post Treatment - Amount of time the interval will occur AFTER the interval indicated in the "Relative to Which Visit" parameter.
Visit Time Unit - Unit of time measurement (Days or Hours) applicable to the Time post-treatment in column 2.
Low Range of Visit Window - Acceptable time window prior to the target time from column 2.
High Range of Visit Window - Acceptable time window beyond the target time from column 2.
Relative to Interval - The Interval, which "Time Post Treatment", is calculated from. In other words, the dependency of the interval calculation.
Be sure to set a visit that comes PRIOR TO the visit being configured. Date windows only compute in a forward-moving progression.
Visit Date Form - Any interval which is relative to the current interval will also need to know which form specifically to calculate off of.
Sequence - Set the order the Intervals display in Scheduled Visits/Event Forms Table. Note, visit date calculations work only moving forward through the sequence. On the mobile app, the sequence is set simply by tapping, holding, and dragging a visit column to a different location.
As the parameters are changed, there is a "Preview" option to see how that schedule looks in different scenarios. This is merely a quick testing function without needing to go into a test subject and enter data.
Other options:
Do not show date - Checking this box or indicating Yes will hide the date window for the corresponding visit. This is helpful in instances where a window is not applicable.
Included Forms - Forms that will be included and/or required in that particular interval.
Edit - Click Edit to edit any of the settings of that interval.
Delete - Click to delete the interval row.
TrialKit offers two types of scheduled visit interfaces when users are viewing the subject records:
The Traditional Type is a grid of all scheduled visits and the forms that need completion within each visit interval.
The Single Interval Selection drop-down is a grid by interval and creates a listing of forms only for the interval selected. This is useful if you have many visits in an interval or huge amounts of data in many forms in a data-intensive study. It is more efficient in the performance of the site to only show forms per interval.
Changing the visit schedule mid-study
Over the period of a study, if changes need to be made to the visit schedule, the best way to do this is by simply making edits to the current working version. Alternatively, a separate visit cohort can be created and subjects can then be moved to that new cohort as needed.
Viewing visit schedule within the subjects' casebook
Scheduled visits are a key component of most studies, where specific forms need to be collected at specific date/time ranges for each subject. Examples of subject casebooks are shown below from the web interface, but can also be viewed in the mobile app:
Each cell contains an icon to indicate the status of the record and existing queries. The icon legend is always available for user reference.
The red asterisk * in each cell indicates the form is not being collected in that particular visit.
Each visit window is defined with a specific target date/time (that's the yellow date), and a low/high range that is acceptable for the data to be collected (The "Time Range"). The date enforced by this date window will be the visit transaction date (See Form Properties) on each form within the visit unless the form is set up to ignore visit window checking.
If a TBD or "Awaiting" is displayed, it's because that visit depends on some other visit's form to be completed first.
Two factors to note:
The system still computes a default visit window based on the visit schedule configuration even when the screen indicates “TBD”. For example, if a visit window is still awaiting its dependency, and that dependency is not yet entered, the window will fall back on the registration form date in order to compute a visit window.
Visit windows are computed only in a forward-progressing direction. If Visit 1 depends on a date being entered in Visit 2, the visit 2 date window will not work as expected and will default to computing off the Registration date.
Visit schedules may also vary. For example, some subjects may have forms or entire visits that other subjects don't have. In other words, it's not the same exact schedule for all subjects in the study. This is handled through cohorts.
Required Forms - Track What Is Missing
If a form is required in a visit and it's not being conditionally hidden, the system will count it as missing once the visit window has passed. This is then reflected in the Action Items Report.
Visit Dates Outside of Window (“VOW”)
When a form is saved, the form’s visit date will be checked against the corresponding visit window. If the date is outside that window a form query will fire. Blank dates will not be considered outside of the visit window. To catch blank dates, make it a required field or add a separate edit check.
To prevent the behavior of visit windows being compared to the visit date on forms, disable the function at either the study level or per-form level.
If the visit window is “TBD” - or still awaiting its dependency to compute a final window - a hypothetical date will still be used for that visit. When the dependency date does not exist, the system will fall back on the registration form as the driving factor to compute the visit window.
In other words, a visit may be awaiting a previous visit but can still have forms missing or outside of window.
To
Define multiple visit cohorts
Cohorts in TrialKit are simply defined as different visit schedules, whereby subjects can each exist on separate visit schedule parameters. Here are a couple of 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 of 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 set up 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 for 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 it's determined that more than one cohort is needed, it's simple to set up new ones.
Cohorts are initially set up, naturally, in the same place where visit schedules are defined. First, you'll need to make sure a couple of things are enabled:
The 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 any time throughout the study as changes to the visit schedule are needed. A few important points:
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.
When creating new cohorts, consider 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.
When editing visit names in existing cohorts, if a visit name “ACME” exists in both cohorts 1 and 2, updating the name “ACME” to “ACME2” will automatically update the name in both cohorts.
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.
Grouped Scheduled Visits
Grouped scheduled visits take the standard scheduled visits described above and add the additional layer of “groups”. An applicable example would be something like an Oncology protocol where visits exist in cycles, where each cycle has a specific number of treatments. In that example, Groups can be used as the cycles. This way the study designer only needs to set up one complete cycle/group and then create copies of it to account for the number of treatment cycles.
This function also simplifies data entry at the site because the casebook only needs to display one visit group at a time, rather than loading hundreds of collective visits across multiple groups.
Related articles