Summary

This article describes best practices to follow when configuring each section of the DataArchitect file. 

Table of Contents

• General
• Trial Manager – When Compiling
• Application Setup
• App Properties
• Form Types Definition and Template
• Display
• Question Types – Definition
• Dependencies – Definition
• Standard Dependencies
• Role defaults
• Scripts
• Form Flow
• Exports
• Medical Coding configuration
• Randomization
• Unit Testing
• Study Amendments
• Design Services Peer Review Process
  • Format Convention
  • QuestionType and FormType Fields

The tables below describes best practices to follow when configuring each section of the DataArchitect file. Keep in mind each study is unique and may require a deviation from these practices.

General

• Auto Filter is not set for any column in the DataArchitect file
• No misspellings throughout the DataArchitect file
• Use of correct grammar and consistent punctuation
• Consistency should be used in the naming of questions. e.g. all camelCase, all lowercase or _ used throughout.
• Eliminate excessive dependencies, forms, questions etc.

Trial Manager – When Compiling

Application Setup

App Properties

Form Types Definition and Template

Forms should be ordered in the Question Layout – Template as they appear on the Forms – Template. Else warnings will appear when compiling.Dynamic forms shouldn’t have a parent. If a parent is specified for a dynamic, the first instance of a dynamic form would be treated as a static form. This would cause issues with reporting and/or possible deletion of the dynamic form.——————–

Practice	Explanation	Example (Sample Images Below)
Form Rename added for dynamics must contain at least one hard-coded component.	A hard-coded component is needed or else the form rename can potentially be left blank.	Image Below
Form Rename needs a leading space or double single quotes.	Excel will remove beginning single quotes.	Image Below
Form Type Name needs to be spell checked.	Misspellings are an easy mistake but also an easy fix.	Image Below
formTypeIds should not be the same as Microsoft reserved names.	formTypeIds cannot be the same as the following: CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9 Note: formTypeIds can contain these words (i.e. conmed).	More information around Microsoft reserved names can be found here.
FormIds and dynamic forms should not end in digits.	FormIds of dynamic forms cannot end in digits because the number will cause problems when the form is incremented. If a formId ends in a digit, subject status can also be affected. Subject status requires record status dependencies to be programmed if dynamic casebook scripts are being used to dynamically generate the visit schedule. Record status dependencies when retrieved from the system will have a path with a [n] if a formId ends with a digit. Having a path with [n] will prevent subject status from functioning properly in this case.	A dynamic form is named ‘ae3′. When that dynamic form is created for the first time it is then referenced as ‘ae3′. When that form is created the second time, it is referenced as ‘ae32′. When it is created the third time, it will cause an error because the system thinks ‘ae3′ already exists. It will not create a form referenced as ‘ae33′.
Questions should be ordered in the Question Types – Definition worksheet by form.	This keeps questions organized.

Display

Question Types – Definition

Dependencies – Definition

Standard Dependencies

• Check for duplicate subject numbers or IDs. Each subject should be unique either by site or by trial. Duplicate subject numbers cause errors when making running reconcile, running imports, mid study changes etc.
• Check for correct format of subject’s number or ID
• Check for correct format for subject’s initials
• Check for correct date format
• Check for correct time format
• Check for dates occurring in the future
• Check if a question is blank
• Check if Visit Date is on or after Consent date
• Check if Consent date is on or after study start date

Role defaults

• Created Query Status = new
• Query View History = X
• Generate PDF of eCRF = X
• Multiple Query PDF = X
• Tool Level = *
• Object Level = *

Scripts

• Description of the script should contain the script name
• Each script name and description is unique
• For all assignment scripts, there must be an ELSE clause. Example: IF set, assign a value, else assign a blank value.
• Scripts that increment local properties should be set shouldReconcile=’false’
• ID checks should be used to restrict when a script should fire. Best practice is to use this in trials that utilize the same questionType or formType as a target. For further explanation and an example please refer to the ‘:id’ section of the Attributes: For Path Fountayn Knowledge Base page.
• Dynamic casebook scripts should not create a parent and child in the same script. In some cases, the child will generate before the parent causing the script to fail.

Form Flow

• FTYN TD role should be granted view role to all forms; FTYN Debug role should have write access to all forms.
• Restricting view access to a parent form will also hide the children forms; however, metadata (alerts, queries) will appear in the (alert, queries) managers. Therefore, if the intent is to trully hide everything, then form flow should be configured on all forms (the parent and the children).
• If MSC: form flow Status Id should never be changed, ‘activation’ atribute must be present, role must have the activateFormFlow permission.

Exports

• Alike forms are combined
• PDF Archival standard export configured
• Set export Depth to 3
• Set for the std SAS export: zipDir = &Libpath libName = &libname libPath = &Libpath
• Excel exports should have the formatter parameter ‘exportAudits’ set to ‘false’ unless otherwise specified by the client. If enabled, the row limit in excel could be reached based on the number of subjects and datapoints that exist in the study.

Medical Coding configuration

• Make Preferred Term and Ingredients standard. DD or MP + (PREFERRED_NAME|INGREDIENTS),ATC1…. (make sure std Txt export delimiter is not ‘,’ only as ingredients are separated by comma)
• Levels to export should be set std.

Randomization

• If dealing with a blinded study, the blinded drug name should not hint to the unblinded name of the medication/treatment
• Difference between threshold and stock level should always be greater than 1
• Initial Activation ID should be either non-numeric (Ex: R001) or should be set to a value not less than the maximum number of expected randomizations (Ex if 100 subjects expected start at 100)

Unit Testing

• Every form should be opened and eyed for accuracy. Should ensure all forms are included in tree structure and layout is acceptable for client.
• All occurrences of study specific dependencies should be tested.
• All custom and application specific code should be tested and verified that all specifications are developed accurately.
• Imports (ECG and Lab) – Verify the file provided imports when the proper parameters are met. When these parameters are not met ensure the file does not import and the system provides details on why the file could not import.
• Randomization – Verify a patient can be randomized according to the specifications. Any project specific features for the randomization should be tested.
• Inventory – Verify the settings for the inventory are working properly. Randomize a patient to make sure the inventory decrements and the re-order process works per study specifications.
• Export – Verify all exports run properly and all tables are configured as specified.
• Reports – Verify that all reports run correctly and display the accurate data.
• Bugs found during any phase of a study should be tested upon completion of the fix to ensure the error reported no longer occurs in the application.

Study Amendments

• Changes made to an application after the initial deployment requires review of all changes made.
• If any update utilities are required on production to update existing patients, the updates should be tested on Design to ensure proper care is taken to update the existing application.
• All form, question and dependency changes should be tested.
• All custom code should be reviewed and/or retested to ensure the change made to the application does not affect the existing code.
• Question(s) removed from the display of a form should be added an “Annotated CRF Note” on the Question Layout – Template tab.
• Question(s) removed from the display: dependencies must be turned off to not fire on the location from where the question is removed from as the update question display will also reconcile/close those.

Design Services Peer Review Process

Format Convention

• Practice -Validated forms are identified in the specifications
  • Explanation –Validated forms are marked on Schedule of Events, in the form ID column with an asterisk, as well as on the form tab in the upper right hand corner.

• Practice– Punctuation convention is used on all questions on non-validated forms
  • Explanation – Whatever convention is specified on the Format Convention tab of the specifications should be followed on all questions on non-validated forms.

• Practice– Correct case is used for all question text on non-validated forms
  • Explanation – Whatever convention is specified on the Format Convention tab of the specifications should be followed on all questions on non-validated forms.
• Practice– CDISC standard data type of string has been correctly used on all applicable questions
  • Explanation– If CDISC standard data type of string is specified on the Format Convention tab of the specifications, check questions to confirm that in all instances where the data type of string is applicable that string is used.
    • Example – For example if the question answer option is part of a calculation and the variable will be used in an equation, the data type of string will not be applicable.

• Practice– Check for self-evident spelling and punctuation errors on all forms, if applicable
  • Explanation – Run spell check in Excel and correct any errors that are spelling or punctuation if specified on the Format Convention tab of the specifications. Note this best practice does NOT apply to medical and industry terminology. All issues found on validated forms will be verified against the source documents and only updated if there was an error of transferring the information from the source docs to the specs.

QuestionType and FormType Fields

• Practice– The FormTypeID field is filled out for all questions and is identical in all occurrences in the specifications
  • Explanation – The FormTypeID must be present for all questions on all form tabs and is the same on the form tab and Schedule of Events tab for each respective form

• Practice– The QuestionTypeID ID field is filled out for each question
  • Explanation – The QuestionTypeID must be filled out for each question present on each form tab in the specifications

• Practice– The Question text field is filled out for each question
  • Explanation – The Question text must be filled out for each question present on each form tab in the specifications

• Practice– The code list field is filled out for each question that requires answer options
  • Explanation– The code list must be filled out for each question on each form tab in the specifications when preconfigured answer options will be selectable. Additionally the answer option variables must be logically consistent with the data type.
    • Example – For example an integer field must have answer options with variables that are integers.

• Practice– The data type field is present for each question and the data type and answer option variables are logically consistent with associated variables.
  • Explanation– The data type field must be filled out for each question present on each form tab in the specifications. Additionally the answer option and question answer option variables must be consistent with the data type.
    • Example – For example an integer field must have answer options with variables that are integers. Also a question asking for the date of a procedure needs a data type of Date/partial date

• Practice– The date/time format field is present for each question that has a data type of date/partial date.
  • Explanation – must be specified or question will not function correctly.

• Practice– The date/time format field must be present in question text if question has a data type of date
  • Explanation – This provides end user’s clarity.

• Practice– All helper text is on its own row in question text.
  • Explanation – This adds to readability and clarity for end users

• Practice – Auto populated fields are specified.
  • Explanation – This provides end user’s clarity and increases usability.
• Practice– If “Other” is in a question’s code list a question with text of “Other, specify” question will be immediately after
  • Explanation – If an answer option of “Other” is listed for a question there will most likely be follow up and clarification of that the “Other” specifies.

• Practice– Main form header text is the same as schedule of events form name
  • Explanation – This references the same form and should be consistent throughout

Need more help?

Please visit the Fountayn Contact Information page.