Summary

This article will show you how to create your first basic form, as if you were creating a study from scratch.

Table of Contents

Forms are the basis for nearly everything you can do in the Fountayn

 clinical research platform. Without them, there can be no data points, and of course no data to report on. This goal of this tutorial is to help you create your first basic form, as if you were creating a study from scratch. After completing this tutorial, you should have a better understanding of some of the simpler question types and how to add a form to an eClinical study. We recommend that you start with this tutorial before attempting any of the others.

Concepts Covered

This tutorial covers the following topics:

  • Creating Forms
  • Creating Basic Questions
  • Configuring a Study

Step 1: Open the DataArchitect Template

The DataArchitect is an Excel spreadsheet that contains all the information needed to create a study in the Fountayn

 software suite. It is separated into several different worksheets, that each contain a different part of a study’s configuration.

When creating a new study, you will need to obtain the latest version of the DataArchitect template. The DataArchitect template is mostly empty, but contains all the information you need to get started designing a study.

Step 2: Create a new Form

Watch the Video!

Each eClinical study is made of a series of forms that are defined in the DataArchitect file. These forms are analogous to the paper CRFs in a traditional paper study. A study in eClinical must have at least one form, but typically they have tens or even hundreds of forms per patient. Note that every patient in your study will use the same basic form structure defined in DataArchitect, although advanced scripting and other methods can give certain patients unique forms.

To create a new form, navigate to the FormTypes – Definition worksheet in DataArchitect. This is where the information for each unique form is stored. Typically, the first form you create will be the patient’s Enrollment form, where the patient’s identifiers, initials, and other pertinent information are stored.


The forms and questions used in this series of tutorials come from the CDISC Clinical Data Acquisition Standards Harmonization (CDASH) project. It describes recommended (minimal) data collection sets for 16 domains, including demographic, adverse events, and other safety domains that are common to all therapeutic areas and types of clinical research. More information can be found here: http://www.cdisc.org/standards/cdash/index.html
  1. Begin by entering a suitable formTypeId for your enrollment form. This is normally not seen by the end user, but is used behind the scenes in things like dependencies, scripts, and export mapping. For our purposes, choose sc. 
  2. Next, enter an appropriate Form Type Name, such as Enrollment. The Form Type Name is simply a plain-english description of your form. 
  3. You can leave the other columns blank for now.

Step 3: Add the new Form to the Forms Template Worksheet

Watch the Video!
After a new formType has been created, you must select where it will appear in the Form Links navigation tree on the left side of the user’s screen. This is where DataArchitect begins to become extremely powerful, as you can reuse one formType in many places, for instance if you had a Vital Signs form that you wanted to occur at every visit. However, in this tutorial you will only be using the form once (which makes sense for an Enrollment form).

Go to the Forms – Template worksheet in DataArchitect. The first two columns are formId and formTypeId. The formTypeId corresponds to the column you just entered on the FormTypes worksheet, so you would want to enter sc here.


Note: Be careful, all of the fields in DataArchitect are case sensitive.
  1. The formId column is similar, but must be unique for every form. In our case, you can enter sc again as you won’t be creating more than one Enrollment form.
  2. Give the form an appropriate Form Name (we suggest Enrollment). This is the name each user will see when they navigate the patient in eClinical. You want to be sure not to enter too long of a name, or the Form Links navigation tree on the left will become hard to read. 
  3. The Parent column specifies under which form your form will be placed in the navigation tree. Our parent will be record, which is the highest possible level for any form. 
  4. Set AutoCreate to true, so this form will be created for every patient upon enrollment.

Step 4: Create a few Questions

Watch the Video!
Of course, your Enrollment form won’t do any good if there aren’t any questions on it! Let’s add some of those now. Adding questions is similar to the way forms are added, in that first you must create the base QuestionType, and then you decide where the question appears in the application. 

For this exercise, we’re going to create two common enrollment questions: subject id number and subject initials.

  1. First, go to the Question Types – Definition worksheet in DataArchitect. This is where the information for every unique question is stored. 
  2. Enter an appropriate, unique questionTypeId for each question (we suggest subjid and subjinit). 
  3. Similar to the FormType, end users will not see the questionTypeId; it is used for behind-the-scenes purposes. 
  4. Enter appropriate question text, such as Subject ID: and Subject initials (XXX):. This is what the users will see on their screen when they open the form.


Note: For any questions that require data entered in a specific format, it is a good idea to notify the user of that format in the question text. For example, Subject Initials almost always requires three characters, so (XXX) was appended to the end of the question text. Other common examples include date and time questions, or lab values requiring a decimal place.


  • We will introduce the most basic data type in this tutorial: 
    1. String. A string is simply any text the user can enter with their keyboard, either numbers, letters, or punctuation. Select the Data Type for each of the questions to be String. 
    2. Next, select Text for the Display Type. This will give the user a simple text box in which to enter the information. 
    3. Leave the remaining blank columns empty; they are not applicable for these questions. 
    4. You can ignore logChange, logAlert, and logSkip for now.


Step 5: Add the new Questions to the Question Layout

Watch the Video!
Similar to the way you created your first form, now that you have our new questions defined, you need to put them in the right place in the application. Again, just like with forms, it is possible to reuse a question over many different forms, or even multiple times on the same form. Of course, in our example the questions will only be used once.
  1. First, go to the Question Layout – Template worksheet. Two of the columns you have already defined in previous steps: the questionTypeId and formId. You need to enter those to match what is on the other worksheets, specifically the Forms – Template and Question Types – Definition worksheets. In our case, the formId was sc and the questionTypeIds were subjid and subjinit. Now the system knows on which form to place the questions, and what questions to place.
  2. Next, you must assign a questionId to each questionType. The questionId must be unique per form. In our case, you can simply reuse the names you had for the questionTypes. You can leave the Annotated CRF Note column blank for now.

Step 6: Add the new Questions to the Display Worksheet

Watch the Video!
At a technical level, the Question Layout worksheet only defines on which tables the questions are located in the database, and not what questions appear on the form to the users. Therefore, you need to go to the Display worksheet and define how you want the questions to appear. The formTypeId and questionId columns should be entered to match what you have on the other worksheets. The formTypeId you have been using for the Enrollment form is sc, and the questionIds were subjid and subjinit.


Note: How you choose to divide up the groups on a form is up to you. In our case, you decided the subject initials and id number would be in separate groups. In certain cases, you might put seemingly related questions into different groups because it makes them easier to read on the form.

The Group Id defines how questions are grouped on the form. You should enter this in a reasonable manner, i.e. if two or more questions are related, keep them in the same group, otherwise start a new group. The Group Title can be used to define certain sections of a form. It is a best practice to state the name of the form as the group title for the first group on a form. In our case, that would be Enrollment. Be sure to include horizontal rules before and after the title. You can leave the Dividers column blank.

Step 7: Configure the Application Setup Worksheet

Watch the Video!
Before you can view a study for the first time, you must make some minor configurations in the DataArchitect file. The Application Setup worksheet contain some basic information about the study, including how to identify patients.
  1. First, go to the Application Setup worksheet. We are going to set up the primaryQuestion and secondaryQuestion for this study. These are what will identify each patient, and determine how the patients appear in the Patient Manager and on each form. The primaryQuestion and secondaryQuestion must point to a question somewhere in the study. We will use the Subject ID and Subject Initials questions you created earlier. The paths to those two questions are #sc.subjid and #sc.subjinit.
  2. The recordName and recordNamePlural fields define how patients will be referred to throughout the application (Subject Manager, Enroll a Subject, etc). Leave recordName as Subject and enter recordNamePlural as Subjects.
  3. Set the initialFormToDisplay to be #sc, which is our Enrollment form. You can leave the other fields as default.

Step 8: Configure the App Properties Worksheet

Watch the Video!
The last configuration step involves the App Properties worksheet, which contains information about the study’s name, duration, date format, and Trial Summary.
  1. First, go to the App Properties worksheet and enter an appropriate name for your study. This is typically the study’s protocol name, but for our purposes, you can use TutorialStudy. Next, choose appropriate values for the Start Date, Date Format, Study Duration, and Duration Unit. We’ve chosen 01-JUL-2008, dd-MMM-yyyy, 4, and month, respectively.
  2. Next, enter some basic information for the Trial Summary. The exact numbers don’t matter right now, we will go into more detail on the Trial Summary at a later time. For now, you can get by with copying the numbers in the screen shot below.

In Conclusion

After completing this tutorial, you should feel comfortable in the following topics:

  • Creating Forms
  • Creating Basic Questions
  • Configuring a Study

Now that you’re armed with this information, we suggest you take the next tutorial: Creating Visits (Part 1).

Need more help?

Please visit the Fountayn Contact Information page.