1. Help Center
  2. Study Configuration and Form Building

Study Functionality Settings

A Description of the Various Functionality and Master Settings That can be Controlled by a Study Administrator

The study functionality settings area defines the list of study settings that allow for defining, selecting, and disabling the core functions for a particular study.

Prerequisite: User has access to Study Configuration functionality

Jump to any section in this article:

Accessing Study Functionality Settings

Controlling Study Status

Functionality Settings:

Audit Settings

Query Configuration


Integration Hooks

Accessing Study Functionality Settings

Configuration settings can be accessed under the Study Menu by selecting Study Configurations.

The annotated numbers in the images below are detailed in the remainder of this article.

Web Browser:


Mobile App:



1. Study Status 

This controls data entry within Provider sites.

Study Status is used to control site record entries for provider sites. Read Site Management to learn about the difference between Provider sites and Administrative sites.

Prerequisite: User must have access to Study Configuration

How to Change a Study Status

Status Definitions

In Development - When a new study is created, its status will be "In Development." Test subjects can be enrolled and tested from any Administrative site.

Live - When the study is Live, any site can enroll new subjects.  The study design can enforce IRB approval and site documents are completed prior to enrolling, which is recommended.  Only production (licensed) studies can be moved to Live status.

Once a study has been moved to "Live", it will not be able to go back to "In Development" unless the study status is reset.

Suspended - This option will not appear unless the study is live. Suspending a study can be done at any time to temporarily close the study. During this time, provider sites will be unable to enroll new subjects or edit existing subject records. 

To make modifications/changes to a study, suspending it is not necessary. Study version control allows for making changes and validating those changes, all while the existing study continues to remain live.

Locked - When a study is Locked, provider sites cannot enroll new subjects or create new records for existing subjects after the lock date. Using this option is a good way to shut down a study but still allow sites to complete data entry on existing records and for study team members to perform reviews of existing data. 

Completed - When a study is completed provider sites cannot enter any data. All records are read-only. Completed studies cannot be switched back to live.

To close a study entirely, please submit a Study Closeout Form.  See How to Close a Study. 

Resetting Status and Removing Data

These options are available from the Study Configuration (accessed via the "Study" menu).

1. Reset Study Status is used to control record entry for provider sites. There may be testing scenarios where a study builder wishes to clear all the data and reset the study status.

2. Remove All Study Data - Removing study data of any kind can be a risk if not careful. This allows you to remove all data from the study's database. It comes in handy when testing a study and you need to get rid of test data and start clean.


2. General Configurations / Functions

Site Document Manager
All Studies will have this enabled regardless of this option being checked.

Must be selected if you plan to randomize subjects in the study.

Use Inventory Management System
This enables inventory-related functions if products will be dispensed or tracked in conjunction with the study.

Enforce Version Control*
This enables study versioning and should be used in most studies as it allows for making controlled post-production changes to the study or form design.

This option cannot be changed after data is entered into the study.

Subject Events Page
This should be enabled in most studies as it allows access to a subject's records. Occasionally studies are simple enough that scheduled visits and other forms are not required. In these cases, a single form can be managed from the subject enrollment table alone.

Study Timeout
Enforced only on the Mobile App. This causes the user's session to time out from inactivity.

Mobile App operating systems will always cause the app to sign out when it is stopped in memory, regardless of this setting.

Enable Two-factor Authentication
This forces all users in the study to use two-factor authentication. The system sends an email to the user for verification anytime they sign in on a new device.

ePRO Enabled Study
This enables a new column in the subject enrollment table with a link to each subject's ePRO sign-in information.

Grouped Scheduled Visits
This replaces a standard visit schedule with a Grouped Visit model.

Adjudication - Enables the adjudication function for the study.

Display Participant timeline - For ePRO studies, this Provides a visual timeline chart on the Participant’s home screen.

Blind Participant Email Address - This blinds the email address of participant users in the Sign In Audit, the Host’s User Manager, and the Study Site/User Manager.

Default Font - This is used within the mobile app form builder. When creating new labels on forms, this default font will be used, unless there is a default already set for the form.

3. Subject Profile ID

Force Subject Profile ID Auto-Generate
Forces users to use a link on the subject enrollment table for the system to automatically generate a profile ID for a newly enrolled subject. If this option is not checked, the auto-generated link may still be available, but the system will also allow the user to manually change or enter a profile ID.

Auto-generating the ID will give each new subject a sequential ID within each site. The format (number of digits) depends on the "starting sequence number" described below. So the first subject at each site, for example, would be 001. If the site ID number is being used, the first subject at each site will be SITEID-001.

Omit Subject Profile ID Auto-Generate
Removes the auto-generated link option from the subject enrollment table. Users will need to manually enter a profile ID for new subjects.

Use Site ID Number for Subject Profile ID Auto-Generate
Uses the site ID number from the Site Manager as part of auto-generated subject profile IDs.

This will not be enforced if manual Subject IDs are allowed.

Study Wide Subject Profile ID Sequencing*
When auto-generation of profile IDs is used with this option enabled, the system will sequence subject profile IDs across all sites of the study. With this option not checked, the system will default to sequencing subject IDs independently within each site.

Starting Sequence Number*
When auto-generation of profile ID is used, the system will begin with the "0001" unless another format such as "001" is specified herein which case the first subject generated would be "001".

*Items marked with an asterisk cannot be changed after subjects exist in the study, even if they are test subjects. To start with a clean study, either create a new study (copy) or clear all subject data.  

4. Subject Events and Records

Subject Events Page 
This is normally enabled and allows for tapping a subject to open the casebook of all other forms. If the study only collects a registration form, this could be disabled to simplify it for study users.

Allow Subject Forms to be Saved as Draft 
This places an option on each form to “save as a draft”. This option will allow users to save data entered on forms without the system running any edit checks or firing unnecessary queries on forms before they are finished completing the form. 

Possibility of 21 CFR Part 11 compliance loss:

Draft saving does not track the data changes in a form if data is changed. Only saving data as final will start the "Data Changes" audit and you may be prompted to input a reason for data change per 21 CFR Part 11 guidelines. 

Use Interval Date Entry 
Allows for dates to be entered on scheduled visit intervals so users do not need to enter a date on every form within the intervals. If this option is enabled, the individual forms must also be configured for Interval Date Entry in the Form Builder.

Suppress Visit Outside Window (VOW) Error Checking 
Forces the system to NOT check the dates entered on scheduled visits as being within their scheduled window. This option is normally left unchecked as forms can individually be configured to suppress VOW error checking in the Form Builder.

Field Level Verification 
Field-level source verification, sometimes called risk-based monitoring, is enabled here and then set up in the Workflow and Form Builder areas in the Study Configuration Settings.

Omit Record Index 
This will disable a link built into forms that allows users to view the list of forms collected for the current subject without needing to leave the form they are currently working on.  It allows the user to arrow forward/backward to the next form in sequence order by DATE of the form (if entered).  A warning message is there to remind you to save data to prevent data entry loss.  

Lab Range Validation 
Enables the study to use site-specific lab range checks.

Omit Date from Scheduled Visit Table 
Hides the date windows and target date that are normally displayed in the scheduled visit grid within a subject's records.

NOTE: All date calculations continue to be done in the background - including missed visits or forms that are entered outside the allowed window.

Use ICD-10 Dictionary 
Enables an ICD-10 Lookup button on the top of all eCRFs for users to reference ICD-10 diagnosis and procedure codes/terms.

Enable Study Cohorts 
Enables functionality to add multiple cohorts within the visit schedule configuration and adds a new column in the subject manager to see which cohort each subject is currently on. 

Allow ePRO Users Access to Unlocked Forms 
For ePRO studies, this allows Participants to access from the home screen previously entered forms that are not "review locked".

NOTE: If participants update existing forms from the list, the visit date on that form will not be updated.

Allow ePRO Users Access to Expired Forms 
For ePRO studies, this allows Participants to access missing forms from the home screen. These are ePRO forms collected within a visit schedule where the windows have expired.

Default to Single Interval Page 
When users open a subject to view records, the system default view is the full visit schedule grid table. This setting makes it so only one visit at a time can be viewed. This is helpful for large visit schedules to prevent slowness of page loading every time a user opens a subject's casebook.

Enable Next-Generation Forms - Updates forms to the more modern interface made available in 2023. Read more here.

Hide Subject Progress Status Bar - Prevents the subject status from displaying on the subject manager screen, for studies where visit schedules or required forms are not applicable.

Enable Participant Payments Via Nmible - This will display a "Payments" button in the Participant web portal for Participant users. It should only be enabled if the study is licensed with Nmible Patient reimbursement system. Contact CDS if you would like to learn more about this function.

5. Record Audit Settings

Audit Changes to CRF 
This causes the system to track events that occur on forms and is recommended.

Require Reason for Any Change to CRF 
This forces users to provide a reason after making changes to existing (previously saved) data. This must be enabled for full change audit tracking and is recommended.

Use Coded Field for the reason 
This provides the users with pre-defined reasons for changing data, to save them time typing a free text reason, particularly when reasons are most often the same.

Change Reason Coding 
Configure the reasons users can provide for changing data. 

The reasons for change should normally not be changed during the course of a study. Doing so could alter the meaning of reasons already provided on data changes.

Allow the First Reason to be Used on all Others 
This adds convenience for users to quickly apply one reason to all other changes that occurred in that same save event. Otherwise, the user must individually provide a separate for each change.

Query Configuration

Query configuration allows for defining the following:

  • Automatic email notices related to queries
  • Query coding
  • Default deployment roles

NOTE: There are various permissions related to what users are able to do with queries - like creating manual queries or closing them. Those permissions are controlled in Role Security.

Query Email Notices

TrialKit can auto-send e-mails to users to notify them of new queries or query responses. 

Send Notification E-Mail for Each New Query

Each time a query is generated, regardless of whether it is manual or automatic, a notification e-mail can be generated and sent to all or some of the relevant parties. This works in conjunction with the other settings.

Send Notification E-Mail for Each Query Message

Each query will have a series of messages. Messages can either be sent from the author or recipients. These messages form a query dialog. Each time a message is added to the query, a notification email can be sent to all or some of the relevant parties. This works in conjunction with the other settings.

Do Not Send E-Mail Notifications to the Site

If you are concerned about spamming your Site, you can check this setting so email notifications will not be sent to the Site. Remember the My Queries report will report all open queries and allow users to access the entire query dialog. Therefore, it is often not necessary to send query notifications to site users.

Only Send E-Mail Notifications for Manual Queries

This sends notifications to all users who are part of the distribution for the query that triggers the notification. All queries and their dialog are available in the Queries Report, which is why you may only want to send out notifications when queries are generated manually by a user such as a Monitor.

Query Coding

Query codes allow for standardizing queries based on the possible reason(s) for the query. There are 4 types of queries in TrialKit. Each can have its own unique coded reasons:

  • Interval Queries
  • Visit/Event Queries (form level)
  • Field Queries
  • Close Query Reasons

When a query is created or closed manually, it provides the user with a list of possible reasons for creating or closing the query.

On the query configuration screen, select a type and then fill in the text to add a new reason.
To remove a reason on the mobile app, swipe left to delete.

Default Deployment Roles

When queries are created, they are deployed to specific user roles at the corresponding site. Those roles are set in this section. When a user creates a manual query, they also have the option of changing these default roles, so only the necessary users can access the query. 

If specific edit checks should only deploy queries to specific roles, these default settings can be overridden on a per-query basis.

Subject users can only see system queries by design. The reason is they can not interact (post comments) with Clinician queries - as that is beyond the scope of that type of user. A manual query can be posted to a subject's form for other Clinician users to interact with.


Metrics settings are used by the system in various areas as a variable to measure study progress-related metrics. These are shown in the Dashboard Report.

There are two factors to set: the total number of expected sites and the total number of subjects planned for enrollment. 


Integration Hooks

Hooks can be used to integrate an external platform for receiving real-time information based on some event - such as the saving of a form - that has occurred within TrialKit.

Hooks work by sending a JSON string to an external restful web service endpoint (example https://www.companyname.com/trialkit/3) when a TrialKit record is created/updated or has its review level (status) changed. An example string is passed to the external application as follows:{"trans_id":"70","form_id":"282","form_name":"Enrollment","OnUpdate":true}{"trans_id":"476","form_id":"304","form_name":"Adverse Event","OnInsert":true}{"trans_id:"68","form_id":"282","form_name":"Enrollment","OnReview":true,"wf_id":2,"wf_status":12,"LockBroken":false}

Once the external endpoint receives this information, the endpoint can utilize other APIs in the TrialKit library to get the additional desired information and/or to perform additional tasks.

To Configure Hooks, use the screen accessible via the Web Browser as shown below.

Hooks are currently only triggered based on changes made to records via the web browser. The mobile app and API do not yet support hooks.