Summary

This article covers the components of the FormsTypes - Definition worksheet. 

Table of Contents

• FormTypes Definition
  • formTypeId
  • Form Type Name
  • Form Type Description
  • Allowed Dynamic Forms
  • Forward To
  • Rename To

FormTypes Definition

The FormTypes – Definition worksheet is used to define the form types and their corresponding attributes.

formTypeId

This is the unique Id of the form type; i.e., “registrationForm”. It is a database setup file, which allots for a certain number of questions (slots) in the database for each form and what specifically goes there; mapping between form types and individual questions that appear on forms. Name this the same as the formId (for simplicity) in single-occurrence forms. It can be used as a basic container and renamed later, such as defining a form called “visit” and then changing the name to “screening” and/or “baseline.” formTypeIds determine the database tables in a standard export.

Note: formTypeIds should not end with an integer and should not exceed 32 characters.

Form Type Name

This is the friendly name of this type of form; i.e., “Registration Form.”

Form Type Description

The Form Type Description is a field that allows a description for the form. This description is an internal description and does not appear in the application.

Allowed Dynamic Forms

This function is useful when the user needs to insert forms into the workbook; e.g., a form, such as a concomitant medication form may be added for each medication. The concomitant medication form would function as a subform of a Concomitant Medication Summary form, which serves as a container for all medication forms for a patient. There could be a need to add one or ten medication forms. Dynamic forms may be added by supplying a comma-separated list of formTypeIds as they do not have parent forms.

Forward To

This is a formTypeId or a path to that formTypeId to forward the user to upon submission of the form. If this field is left blank (recommended), the default setting, a dot (.) will be implemented. This indicates “go up one level.” In other words, the user will be taken “up” one level after saving the form.

This attribute will process if a branching expression fails or a branch does not exist. If Forward To is not set then the forwardToNextForm is used on the App Properties tab (if configured).

Best Practices: Make sure that a valid formTypeId is defined in this field and other placeholders like ‘XX’ are not being used. If the formTypeId specified is not valid, the user gets an error page. If the formTypeId is valid but does not exist in the casebook, the user will be directed to the parent.

Rename To

This is an expression field that can be evaluated when the form is saved, which allows the user to rename a form to an answered question. Useful with dynamic forms; e.g., if an Adverse Event is HEADACHE, and you want to rename the form to reflect for which AE the form exists, you can enter the questionId for the events question. This will display the text entered into the string, or “‘AE: (‘ + event + ‘)’” can be entered, which will rename the form to AE: (HEADACHE).

Never use just the variable name because the potential exists for the form to appear blank in the Form Links tree when the form is saved, without the question field completed. Always use an identifier in front of the question to avoid not having an identifier in the Form Links tree with no means of accessing it via the interface. Multiple questions may be used.
We do not recommend referencing questions with MultiLineText Display Types due to potential display issues and very long form names.
We do not recommend referencing questions with Reference Data Types due to incorrect form names when reference questions are updated.

Note: When specifying ids (including formTypeId, formId, questionId and questionTypeId), the id must not be or contain the following reserved words:

Ids should not start with numbers or ‘@@’.

Need more help?

Please visit the Fountayn Contact Information page.