Form Properties

_{Share or Open on Web}

Form properties define the overall functionality and behavior of the form. This article describes all functions defined within a form’s properties.

Use the links below to jump to a specific property definition:

Accessing Form Properties

To see the form properties, tap anywhere on the form canvas (outside of any field on the form). On both the web and app this is displayed in a panel on the left side of the screen.

On the Web

When the Form Builder is accessed from the Study menu, the Form Builder page is displayed (below). 

1. Form Fields and objects which can be placed on the screen

2. Form/Page Properties with their associated Properties are displayed in the Toolbox located on the left side of the Form Builder page.

Open

 

The Properties applicable to a “Form” will be discussed in the following section. The subsequent sections include an explanation of each of the individual Form Fields (Text, Number, Drop Down, Radio Group, Date/Time, Memo, Checkbox, Email Address, and File Upload) that can be placed on a “Form” to capture data and the Properties associated with each Form Field.

Form Properties

On the web

The following figure shows the Form/Page Properties that can be used for a form on the web. The app form builder provides some additional properties. All are listed and described in this article.

Each Form/Page property is explained below.

Form ID

This is assigned by the system and cannot be changed. Form IDs display in data exports and data dictionaries to reference the form as an alternative to the Form Name which can be changed over time.

Form Name

This is the title of the form that will appear in the corresponding pages and related applications where the form is used. Note: The Form Name is how the form is characterized in the database. It is always smart to add the same title to the top of the form workspace as well. This way the end-user of the form will clearly see which form is currently open as it is completed.

Line Height App only

This sets the default field height when new fields are added to the form, rather than needing to edit the size/height of each field individually after they’ve been added.

Description

This serves as an internal note for the form designer and is not displayed anywhere else.

Form Type

• Study Level Forms - The Form Type drop-down choices when the Form Builder application is used at the Study level are: Subject, Site, and Study as shown in the figure below. These form types correspond to various Study level applications. Forms designated as Site Forms appear in the Site Document Manager application accessed from the Study menu. Forms designated as Subject Forms appear in the Subject Manager application accessed from the Subject menu. Forms designated as Study Forms appear in the Access Study Related Forms application accessed from the Subject menu.

• Host Level Forms - The Form Type drop-down choices when the Form Builder application is used at the Website Host level are: User, Site, and Study as shown in the figure below. Forms designated as User forms populate the Current Users data table on the User Manager page. Forms designated as Site forms populate the Current Sites data table on the Site Manager page. Forms designated as Study forms populate the Current Studies data table on the Study Manager page. The User Manager, Site Manager, and Study Manager applications are all accessed from the Website Host menu.

Sequence 

This is a number assigned to determine the order in which the forms will appear in both the Existing Forms data table and related applications. 

Save Button Text 

This property allows the Form Designer to determine the text that appears on the “Save” buttons for each form. (Below) "Save Demographics"

1. When rendered on the form, the button text will appear as shown in the following figure. Notice the text “Final” was automatically added to the Save Button Text entered in the field.  (Below)

Keep in mind that depending on how a study is configured “Draft” or “Final” may be appended to the Save Button text entered. (“Draft” will be appended to Subject type forms if in the Study Configuration application, Allow Subject Case Report Forms to be Saved as Draft checkbox has been checked on the Functionality tab. 

That will allow any form to be saved multiple times in draft mode before a final submission is made.  (except enrollment form)

Field Prefix - App Only

If a common field naming convention is being used on all fields of the form, a common prefix can be set to make field naming easier as fields are added to the form. For example AESTDT and AEENDT are fields collected on an Adverse Event form. They both start with the same prefix “AE”.

Width and Height

The width and height of the form area. This can be adjusted over time to fit the layout of the fields on the form.

ToolTip or "Hover Help" - Web Only

This tool is used to enter text into a dialogue box that will appear when the mouse hovers over the field.

1. Highlight filed with marching ants highlighting the field.

2. Click on View/Edit on ToolTip

To set up the tooltip or "hover help", select the desired field and click the View/Edit control. Clicking the View/Edit control displays the ToolTip pop up window where the desired help or extra definition of the term for the field can be defined. 

Currently, ToolTips are only available at the field level. 

Omit Review Levels

Forms created at the Study level can be set up to require up to five review levels using the Study Configuration in the Study menu. 

1. Selecting one or more of the checkboxes of these review levels will prevent the selected review level requirement for the form.  (see below)

2. Conditional Actions – View/Edit

Clicking the View/Edit control opens the Conditional Actions window in the Form Builder body/grid 

The Conditional Actions window allows the Form Designer to create simple to complex validations or edit checks for the selected form. Please refer to the help pages for complete instructions about how to create Conditional Actions.

A “0” preceding the View/Edit control as shown in the previous figure above, indicates there are no (zero) Conditional Actions for the form. For each Conditional Action that has been defined, the number that precedes the View/Edit control increments by one as shown in the following figure where we now have 1 condition set for form. 

Record Relation

This only applies if a form is a log form. It tells the system how many records should be allowed for entry within a given subject’s casebook.

• One – A relationship of “One” means the form is not related to any other form in the system and can be completed only once throughout the Study.  An example is the Procedure form.  Only one procedure form usually is made.

• Many – A relationship of “Many” means the form can be completed multiple times throughout the Subject record. An example is an AE or Deviation Form.  Many AE's can happen per subject

• Batch – A relationship of “Batch” means it can be filled out once as part of a group of forms. This group of forms (or batch) can be completed multiple times. For example, a batch form might be used if the research lab is conducting a study that involves receiving subjects in batches, rather than simply one at a time.

• Enter the enrollment data

• Enter the Batch size

• Enroll new subjects to add subjects as shown below.

One to One Location 

This is applicable only to forms which will be displayed/accessed via the web, and only applies to Log Forms.

• Registration - The log form will display for access on the main subject manager page for quick access. Only possible with log forms which have a relation of ONE.

• Subject Record - The log form will display within the log forms section of the subject’s casebook

Study Form Type - App Only

This is used to define which purpose a form will serve based on common key types. This is not required, but defines for the system which form, for example, is the study exit form so study exits can be tracked primarily for reporting purposes. The following key types are available:

• Registration

• Deviation

• Withdrawal (Study Exit)

• Medications Log

• Adverse Event

DDE (Double Data Entry)

The number of data entry passes will be taken on the form. This is only applicable if the study as a whole is setup to support double data entry.

Date Granularity/Precision

The Date Granularity selected from the dropdown list (Second, Minute, Hour, or Day) determines the extent to which dates and times on the form will be factored within potential computations.

Visit/Transaction Date 

The Visit/Transaction date field is required only for Subject type forms created in the Study Form Builder due to the longitudinal nature of clinical trial data collection. The Study Form Builder requires a date field to be selected from the dropdown list which relates it to the Scheduled Visit/Event Forms Interval table displayed on the Subject Visits and Events Manager page (accessed from the Subject link in the Subject Manager Subject Registration data table).  The field drop-down choices are populated with the Date/Time fields that appear in the form. The Visit/Transaction Date field does not appear in the Data Section of the Form/page Properties when in the Website Host Form Builder application.

To auto-compute and hide visit/Transaction Date to users during data entry:

1. Select Compute Value on the date field on the form to hide

2. Pick any field to fire calculation [Any field [blank]]

3. Choose Constant from options in CA

4. Select Current Date from the drop-down

5. Hit Ok - Don't forget to save the form!!

Now go to the Study drop-down and select the "Role Security" tab.

1. Select Study drop-down menu

2. Select the Role Security tab

3. Select Role to edit

4. Click on Blind Form Fields by Role (see fig 3)

5. Save Study Configuration

 Fig 2

To Blind Fields by Role, click the following link: Blind Form Fields by Role.

1. Select Form to Blind Fields from the drop-down

2. Check fields you want to blind on that form

3. Save Field Blinding

 Fig 3

Log Form 

Selecting the “Log Form” checkbox designates that a form can be completed multiple times. Log Forms can be created using the Study Form Builder. Subject Forms designated as Log Forms populate the Log Forms section of the Subject Visits and Events Manager page (accessed from the Subject link in the Subject Manager Subject Registration data table on the Subject Manager page). Site and Study forms can also be collected in a log rather than single instances. Read more about defining log forms.

Interval Date Entry 

Select this checkbox to allow for multiple date entries when interval visits are required in the study. Interval Date Entry, or IDE, allows a Study Designer to enable Data Coordinators (or someone with a similar role) to enter visit dates at the Visit Interval rather than on the actual form. IDE is designated on the Functionality tab in the Study Configuration application. Additional information about Interval Date Entry is available using the search help bar at the top of this page.

Suppress VOW 

The Suppress Visit Outside Window checkbox can be selected to allow for visits outside the date window as specified in the Create Scheduled Visits application by the Study Designer. Many studies will have a scheduled subject visit table that defines specific visit intervals. Each of those intervals will have a window within which a visit must occur. If a subject visit falls outside the specified window, the system will deploy a Visit Outside Window query. Some studies will not require such queries to be produced. If that is the case for your study, then check this option.

Omit Error Msg 

The Omit Error Msg checkbox can be selected to prevent an error message from displaying on the form, regardless of the reason the error message would have been fired.

ePRO Form

This defines the form as one which will be made accessible to a participant/patient user. Read more about ePRO setup here.

Save as Draft and Next - App Only

Save and Next allow the study builder to optionally add a window at the bottom of a form containing more than one tab/page. This allows the data-entry user to easily navigate forward or backward in the pages, as an alternative to tapping the tab/page at the top of the form. There is also a button in the middle of the window that allows the user to save the form in draft and advance to the next page. If the user is on the last page of the form and they arrived there by using the save and next button, then the button will say save and quit. Doing so will perform a final save, along with any edit checks on the form, similar to the save button at the top.

Preserve Deleted 

The Preserve Deleted option allows you to set hidden conditions per eCRF that will preserve the data from the fields that are hidden.  This is a good option for scoring fields that are autogenerated for sections of data that need to be hidden from end-users.  The score will preserve in the data set and not clear like normally hidden fields.  See below from web form builder:

Do Not Send ePRO Notifications

Only applicable for ePRO forms. Enabling this property will prevent the system from sending automated notifications when the form becomes due for completion. Read more about ePRO Notifications.

Default Font (Mobile App Only)

Similar to Line Height, this sets a default setting on the font for new text labels which are added to the form. This saves time of updating label font properties individually after the labels have already been added. An alternative to this is to use the Select All icon on the form and edit the font property on everything at once.

Adjudication - App Only

1. Adjudicator Form

Select to define the form as one which Adjudicators will complete when applicable

2. Adjudicate this Form

Select to make the form one which will be adjudicated via the Adjudicator form above

3. Adjudicator Role

Only applicable for the two selections above. This defines the role which will be serving as an Adjudicator.

4. Moderator Role

This defines which role will be serving as the Moderator (commonly referred to as CEC Committee)

5. Adjudicate after which level

Applicable only on the form which will be adjudicated (#2). Define what the form status should be of the form before it becomes adjudicatable by the Adjudicator form.

6. Adjudicator Form

Applicable only on the form which will be adjudicated (#2). Define which form will adjudicate the current form. This dropdown of choices is populated based on other forms which have already been defined as Adjudicator forms (#1), so performing that step would be necessary first.

Device Targeting - App Only

Device Targeting takes a form and creates a “child” version of the same form for displaying in a different layout/appearance or language. Select a device and tap the button to build the targeted form. The system will automatically create a child version of the same form in the defined layout.

Device

Choose a device type to target the form to. This list is populated via the Device Dictionary.

Single Column

When creating a targeted form, the system can be forced to line all objects up in one column. Applicable for narrow form widths.

Form Footer - App Only

Set a footer on the forms similar to setting a footer in a word processor. For example, if a licensed form is built, the copyright can be named.

Dots Per Inch - App Only

Dots per inch (DPI) allows for defining a scale which the form will display on PDF outputs - applicable for annotating the form or exporting the PDF. The default value here is 100 to cover most form designs. Changing the value to something smaller will cause the form to scale larger on a PDF. If the DPI value is too small, some of the form may go off the page.

Translation Tools - App Only

The app form builder provides a function for one-tap auto-translation of all the text on a form to create a different language version of the parent form. This is done via device targeting discussed above. Once that is done to create a child form, the following translation update tool can be used.

Translation tools allow for easily exporting all the text from a form for the purpose of validating or editing the previous system-provided translations. Then import the file back in to have all text instantly update. This is a rapid alternative to manually updating all text within the form manually - particularly when the translator does not have access to the TrialKit form builder.

To export the text, open the form properties of the Child form, and tap the export button.

The translation file is exported with four columns as a .tsv file (to avoid issues with comma separation that can occur in text labels). This will go to the device’s iCloud folder.

The following columns are exported:

• Label or Field ID - System ID for the text label or choice field text

• Original text - From the main parent form. The original language.

• System-translated text - Original text already translated via Google Translate API

• Verified translated text - This is a blank column to be completed by a translator. If there are no changes, just copy the system text over to this column.

After completing the last column of the file (Verified text), it can be saved to the device’s iCloud folder and accessed via the import option within this property. Importing and saving the form will cause the text to update immediately.

A confirmation popup will appear to indicate the number of updated text objects.

Related articles