Descriptions of the Various Tools Available for Form Builders
Table of Contents
Working with Forms and Tools For Editing
Form Design is made very easy with its drag and drop functionality and editing tools.
Adding New Fields or Labels
This is done by dragging objects out from the toolbox.
Selecting objects is necessary for moving them on the form, copying/cutting, or accessing the field properties for a given field.
Tap any object on the workspace to select it, or drag a box around several objects to select all of them. On the mobile app, this is done by tapping and holding for 1 second before dragging your finger or stylus.
Select a field or group of objects and tap the delete button
When deleting fields on a Live study, this will remove the data and any external variables that depended on that field. It normally only makes sense to delete a field on a study in its initial development. An alternative to deleting is using the hidden field property or blinding the field to users.
Copying and Pasting
Select one or more objects and then the copy or cut function above the form.
Then tap paste and drag the new objects to where they are needed. If the objects need to be pasted on another tab, navigate to that tab first before pasting.
Conditional actions will not be carried over when pasting fields. Those can separately be copied and pasted as needed (detailed in the conditional actions help article).
The data dictionary is a system-generated blueprint of the forms and their properties. These are especially valuable when performing validation of the various behaviors which have been built on a form.
These files can be used to perform requirements testing and validation documentation.
The data dictionary details every characteristic of the form content across three categories:
- Form properties and form level conditional actions
- Field properties
- Field conditional actions
These are accessible via the following link (only on the web browser):
Select which study version or other form types, followed by the export button for the type of details needed:
The exported file name will contain the date exported and the study name.
Normally the options above are the best for a detailed layout of form content. Other times, a summarized version is sufficient for quick review. If you have a form open, you can create a summarized data dictionary for that form, focusing only on the field conditional actions and primary field components. Use the quick link, Data Dictionary, found above the form workspace shown here:
You can also get a summary of the entire summarized dictionary for all forms with the link, Summarized Data Dictionary, as shown below:
Forms can be imported from or exported to central form libraries so they do not need to be rebuilt for every study. Read more about the Form Libraries.
Importing and exporting is done from the Forms Manager table (web browser only) shown in the example below.
Once you select "Import" or "Export" you will be prompted to choose which library to Import/Export with.
Public Libraries can only be imported from. These are managed by TrialKit.
Private Libraries are specific to the current Host and can be freely imported into or exported from.
Annotated forms can be produced in various ways depending on the objective. The following three options are available:
- Export a single annotated form with complete data dictionary
- Annotating All Forms With Complete Data Dictionary
- Annotated Forms as a Casebook View
The mobile app can also export blank PDFs - individual forms
Exporting a Single Annotated Form With Complete Data Dictionary in PDF Format
The single annotated form provides the CRF and additional information about each field including the Field Number, Label associated with the field if applicable, Name of the field, Type of field, Length of the field, Choices for the field if applicable, and any Conditional Actions.
To export a single form, start on the Form Builder page. Select the desired form to open in the workspace, and tap the 'Annotate' option above the form:
The PDF will download to the computer's downloads folder. The Annotated PDF document shows the layout of the CRF with a field number displayed by red-colored numbering. The field number corresponds to the Field Number displayed on the Form Summary listed directly below the form in the exported PDF file.
Annotating All Forms
On the forms screen, there will be an option to ANNOTATE ALL FORMS on the right side of the screen as shown below.
Do not select any versions on the screen that follows if you want to annotate study/site type forms.
If conditional actions are not included, a simplified data dictionary will be produced, which leaves out conditional action details.
By default the system will not include child forms built for device/language optimization. If these are needed, check the box shown below to include Child forms.
Annotated Forms as a Casebook View
To export all the PDFs in visit order based on how it would look under a study subject, use the casebook view. This leaves out all data dictionary details and exports a single file of only the forms as they would appear in a physical visit-based binder.
When exporting the casebook view of the scheduled visits, its important to select which visit schedule cohort is desired.
Unscheduled visits and log forms must be separately exported. They will be exported by sequence and alphabetically.
The PDF file includes embedded bookmarks by Visit for convenient navigation within the PDF.
Export Blank CRFs - Individual Forms
This is done from the mobile app if a single form is needed as a blank PDF.
Tapping the button highlighted below will automatically open the PDF preview and also export the PDF instantly to the device's iCloud TrialKit folder (iOS only). No further action is needed.
If the form content goes off the page due to the parent form design, it's simple to create a targeted child form for the purpose of paper data entry. This way you can have separate layouts for PDF without impacting the validated electronic version.
To create a targeted PDF version of the form, follow these steps:
- Create a PDF size option in the device dictionary. If paper width is 8 inches (accounting for .25 inch margins) and there are 100 dots per inch, then any forms targeting this size would screen width setting of 800 pixels wide. Dots per inch x paper width = CRF width.
- Open the parent form in the form builder (do not tap save).
- Open the form properties.
- Target the form to the PDF size option. A message will indicate when complete.
- Without tapping the save button on the parent form, open the form library list and select the newly created PDF child version of the form.
- Change the layout as desired for the paper version of the form. 300 DPI is generally a good setting to display all content of most forms.
- Save the changes.
- Tap the PDF export button shown above.
If some of the content is off the boundaries of the PDF page, adjust the DPI settings in the form properties to a higher value. Normally, a value of 200 is enough to fit most forms on a PDF page.
From the IOS app, these are exported to the device’s iCloud folder. If the margins are off the page, the form properties DPI setting can be adjusted.
Notifications and Distribution Lists
Notifications and Distribution Lists must be configured prior to utilizing them within Conditional Actions. This tool provides users with information they need to know as data entry requires. A common example being notifications for new enrollments or for adverse events.
Read more here on this topic.
Replicating a Form
Form replication is a quick tool to copy a form either in the current study or into another study (of which you are a member) even if the other study is part of a separate host. Access is based on access to the form builder and it can be found on the right side of the screen in the form builder as shown below.
When choosing a destination Form, keeping it blank will create a new form in the destination study. If a form is selected, it will be overwritten with the source content being replicated.
Re-Run Edit Checks
The re-run edit checks screen allows a study builder to selectively run all conditional actions on specific forms or fields. This is helpful when new edit checks are added or existing ones are modified. It allows an Administrative user to centrally run the edit checks that are needed, without forcing all edit checks across the study to be run as would normally be done through a version migration.
In a versioned study, version migration is still necessary. The function covered here makes version migrations much faster and allows the Study Administrator to selectively run only the conditional actions that are needed (i.e. new ones in the most recent version).
Re-run edit checks can be found within the form builder on the web by any user with form builder access as shown below.
Granularity - Select which level to run edit checks (the Granularity). This could be all conditional actions on specific fields, forms, or entire visits. Anything more would be the entire subject, which can be done during version migration.
Validation Granularity Definitions:
- All - Run validations for all fields in all forms in all visits.
- Form - Run validations for all fields in the selected forms for all visits.
- Visit - Run validations for all fields for the selected forms in the selected visits.
- Field - Run validations for selected fields in selected forms for all visits.
Validation Range - As an optional specification, choose which records to run the checks on based on the visit date range. For example, if an edit check on a field was modified on the Demographics form, and they only need to be rerun for subjects that had their screening/demographics visit after January 15th, the date range can help with this. Otherwise, it can be left blank to simply rerun the checks on all records.
In the example above, a validation (edit check) was added on the Date field of the Physical Exam form because the site was entering future dates. The Study Manager would like to run that validation on existing data at the Clairemont site for records with dates between January and February.
Running this will cause the edit check to fire system queries on that date field for any data that is a future date.
ALL conditional actions will be run for the field selected. Caution should be used when running checks on fields that also contain an email notification or computation. This would have the potential to send email notifications or update data on a computed field. It will also run the visit outside of window checks to compare the visit date to the scheduled visit window if the form is in a scheduled visits. Other types of conditional actions will not be run (hide, disable, populate).
Rerunning the validation will have the potential to create new queries on existing records. This can be verified through the Queries report. Some conditional actions will not apply because a form save is required via manual form entry. Those include Hide, Disable, and Populate CAs.
Auto-validating a form is a quick way to run volumes of test data against the edit checks on a form. Read more about that here.
Setting Field Source Verification
Field Level Source Verification, or "FLSV" is similar to SDV (Source Data Verification). Configuration of FLSV on forms is done as part of the study workflow configuration.