Study Configuration and Form Building
      Back to home
      1. Help Center
      2. Study Configuration and Form Building

      Study Database Design and Modeling

      The Process of Converting a Written Protocol and Case Report forms (CRFs) into a Workable EDC Study to Produce a Coherent and Logical Study Workflow of Forms, Visits, Data Extracts, and Submission-Ready Data Output

      Why Design the Forms and Workflow Upfront?

      Forms (CRFs, ePROs, Consent, site documents, etc.) facilitate complete and standardized data collection that promotes efficient processing, analysis, and reporting of information, as well as the exchange of data across sites and to the Sponsor/Principal Investigator/Data Coordinating Center.  (cc web)

      Upfront planning for your build is a must.  Taking the time to plan out your study workflow and CRF build and CRF sequence is key, not only to a successful study but to a more enjoyable building effort.

      For example, some study Builders will build different forms to collect the same data at different visits or time intervals. This is not recommended. The creation of one form with conditional logic to hide/display the questions that pertain to a given interval will ensure "like data" is in the same table and make the data much easier to analyze in the long run. Your statisticians will also thank you for this!

      DOs

      • Configure your study exit form on the subject manager page, not inside the subject.  This allows you to manage study entries and exits from the study manager page.  You also can see in one place who is enrolled and who has completed (and why) without having to open the subject record. The system only allows you one Study Exit form from the dynamically created subject ID list  (as you exit a subject the ID goes off the dropdown of subjects, ensuring one exit per subject).
      • Be aware that your visit transaction dates on forms are what drive the visit intervals.
      • How many CRFs do you have and what is the sequence? Set your sequencing of forms in the form builder in the order they naturally appear in the workflow.
      • Delete or export to the sponsor's private cloud library any forms not being used in the study to more easily manage testing and validation.
      • Knowing your audience is most important.  Are you working with Web-only, App-only, or a hybrid study?  (Hybrid = Both web and App will build/use/view forms).

        DON'Ts

        • Do not design similar or "like" forms for each visit interval. Instead, design one form that covers all scenarios and visits using show and hide conditions for fields, tabs, forms, etc. The system is smart enough to show intervals and dates to easily filter out what event form belongs with.
        • Do not use study visit schedules to drive the collection of ePRO forms. Instead, ePRO forms should be collected through diary configurations or event schedules.
        • Do not use Normalized Tables for collecting common things like concomitant med, adverse events, or protocol deviations.  Instead set each up as a log form so each AE, ConMed, or Deviation is a separate reportable entity.  Normalized tables are very good at collecting Medical/Surgical History like the below:


          FAQ's

           

          Q. What's the point of building separate forms in some cases where I could just combine groups of content into one unified form?

          A. That's a good question and one that should be considered carefully with the following points:

          • 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.
          • Less configurability with form dynamics. Normally 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 they are separate forms. In the example in the first point, medical history might be entered, so the form is entered, but demographics are missing. If it's in one form, the system won't count demographics as missing.
          • If one of the forms is repeating across visits, the data would need to be split across two separate forms if one of them was a combined form.