Form Building Guide

An Overview and a Central Guide for Building Forms

Accessing the Form Builder

There are two form builders in TrialKit. Host Level and Study Level.  Selecting one over the other depends on what type of form needs to be built. The type of form being built is determined by the data being collected.

Host-Level Forms

• User - Data collected about a user of a host account

• Site - Data collected about a site being used for one or more studies within the host

• Study - Data collected about a study within the host

The form builder for those form types is located under the Host menu.

Study Level Forms 

• Subject - Data collected about a subject within a study. These are the most common form types used to conduct study data collection

• Site - Data collected about a site within the context of the study where the form exists

• Study - Data collected about a study. The difference between this and the study forms at the host level is that study users can be granted access.

The form builder for those form types is located under the Study menu.

Web Browser:

Expand the Study menu and tap on the Form Builder option.

Mobile App: 

Form Builder Map of Functions (App)

Reference the annotated image below for an overview of the page layout and links to more descriptive articles on each item.

1. Form Library access and saving

   1. Open form library list

   2. Save current form

   3. Save the current form as something new

   4. Start a new form

2. Basic form properties

   1. Form name

   2. Page name (see item 9 for multi-page forms)

   3. Form version

   4. Width and Height of the overall page

3. Open conditional action builder for the currently selected form or field. Quick access is also provided via the small window on the right.

4. Preview form and collapse the top properties panel. These are helpful to increase canvas area when building.

5. Width and height of the currently selected field. Text labels will also include wrapping and font options.

6. The field name and field reporting label for the currently selected field.

7. Tap to open either the advanced form properties or the advanced field properties for the currently selected form/field. To select the form, just tap anywhere outside of any field on the form.

8. Object editing tools:

   1. Basic tools: Cut, copy, paste, select all, undo, redo, and delete

   2. Align selected objects right or left

   3. Create a group conditional action

   4. Create a rapid sum computation on number fields

   5. Select multiple objects manually

9. Add or remove pages. See item 2 for page naming.

10. Toolbox of form elements that the user can drag onto the form.

11. Form canvas/working area.

12. Export and view options:

    1. Data dictionary table - exportable

    2. Display query icons on the workspace. This helps to see how the form appears to Monitors when additional icons are put on the form.

    3. Download the blank PDF to iCloud.

    4. Annotated PDF of the current form. This produces an annotated PDF with the data dictionary.

13. Merge all checkboxes with their associated text labels. This is not required but makes it so the user can tap the text to check a box, rather than tapping directly on the box itself.

14. List of conditional actions on the current selected object

Form Builder Map of Functions (Web)

1. Form Name and Type of All Existing Forms. By default, only parent forms will be displayed in the list. Use the table filter to access child forms.

2. Sequence

3. Export/Import Forms

4. Data Dictionary

5. Annotate forms

6. Version selection - for studies using versioning

7. Design Tools - Visual objects

8. Field Types - Data storing objects

9. Form or Field Properties, depending on what is currently selected in the workspace (10)

10. Form Workspace - Drag and drop field types (7 & 8) here

11. Editing tools

12. Save Form - Saves current work in the workspace. This is not automatic, so be sure to save changes regularly if working on the same form for an extended period of time

13. Re-run Edit Checks - Only appears for non-versioned studies. This re-runs all conditional actions on all records in the study database.

14. Replicate Form - This can be used to copy the form to another study that the user belongs to

15. Auto-Validate forms

16. Setup notification messages and distribution lists for use in conditional actions

17. Field Source Verification

18. Child Form - Displays the name of the child form based on which device - as defined in the device dictionary - that it was built for. This will be blank for parent forms

Form Building Guide

This section serves as a simple guide to building forms. Use the links to open the respective topic.

1. Creating New or Editing Forms

2. Repeat step 1 for all forms needed in the study

3. Add additional needed fields and labels

4. Ensure the registration form for the study is defined and has at least one log field identified

5. Build Form Logic and Edit Checks

6. Identify which forms are log forms. These are forms that can be collected anytime

7. As forms are modified, they can be tested within an Admin site in the Subject Manager

8. Making form changes after moving the study live

9. Other optional form-building topics:

   1. Auto-validation

   2. Automated email notifications

   3. Form Preview

What to Avoid

Combining forms into larger forms

• One big form will produce one big data export file with a high number of columns. This makes data analytics harder because variables aren't split up based on the topic. For example, an Eligibility form could be combined with the medical history and demographics which are all done during an initial visit. However, the data exports are easier to make sense of when they are built as separate forms.

• The bigger the form, the slower it will be to load and perform data entry. You won't notice it with 100 fields, but you will with 1000 fields.

• If the form is a log form, you won't be able to display as much in the log table because it would all be one long table.

• If the form is a lab form, you won't be able to have multiple labs collected on the same form if you use the "Labs" option in TrialKit.  They use fixed-length normalized tables and need to be one per eCRF.

• Less configurability with form dynamics. Typically, one form can determine what happens on another form. If all the fields are combined into one form, that cross-referencing is lost.

• Required forms can only be tracked as entered/missing if separate. In the example in the first point, medical history might be entered, so the form is entered, but demographics are missing. The system won't count demographics as missing if it's in one form.

• If one of the forms is repeating across visits, the data would need to be split across two separate forms if one was a combined form.

Form Size Limitations:

The underlying database limits forms from containing more than 1,170 fields. Additionally, there is a limit in table memory which could be possible to reach if there are, for example, 1,169 fields on the form and each one contains multiple edit checks. Keep this in mind if you are considering combining multiple forms into one large form.